Google dropping ActiveSync support for most corporate email servers.

(Disclaimer: I was a Microsoft employee for six years and love my Windows Phone)

If you have an Android Phone, and sync with your work email, keep an eye on updates from your IT department – you’re going to have to change some settings.

Until recently, all smart phones used a Microsoft protocol called “ActiveSync” that made it easy to keep email, appointments, contacts, and tasks all updated with mail servers. (In the link below, note that soon the only phones not to support EAS will be Android phones) Pretty much everyone supported it because it’s powerful and easy, and very easy on users. And they had to pay a licensing fee to Microsoft to use it.

Google Dropping ActiveSync

Google decided to drop support for ActiveSync, which means Android phones won’t work with Exchange (a large number of corporate email systems). Instead they’re going to use a bunch of different protocols – one for email, a fifteen year old piece of junk called calDAV, and some proprietary gmail extensions because these protocols don’t make it easy to push email. They are saying “it’s because Google supports open protocols” but the obvious reason is to hurt Microsoft, and who cares what happens to their users.

Microsoft is scrambling to get the protocols implemented on Exchange, but shame on them – when handling your email, they want to be sure they do it right, and they’re asking Google to extend the date when they drop ActiveSync. I don’t think Google has responded yet – this may be because nobody can figure out how to get an actual person at Google to talk to.

In the meantime, if you’re shopping for a new phone and plan to use it with your office email, iPhones and Windows Phones (and Blackberries) support Exchange. And if you want web mail that works really well with your iPhone or Windows Phone, check out Outlook.com, because Gmail hasn’t changed in six years and will be using a cobbled-together bunch of old technologies.

Have a nice day. [grin]

SharePoint 2010: Rename Content Databases and the Configuration Database

SharePoint 2010 Rename Content Database and the Configuration Database: This is part 2 of an attempt to create an omnibus resource for renaming things in SharePoint. Part 1 (and the index) can be found here:

How to Rename SharePoint 2010… Everything!

Configuration Database

Don’t rename the configuration database. If you think you want to rename it, then don’t. There are a few articles that discuss detaching the database to rename it. Personally I’ve tried this three times and failed three times; and the price of failure is rebuilding your farm from scratch.

(Note that there can be more to this than just the farm name – the farm also encrypts data based on the farm password, and I believe changing the name of the Configuration Database may affect this. Since renaming the configuration database isn’t supported by Microsoft, it’s pretty tough to dig out information on this)

Content Databases

Next on the list are the content databases. Again let me reiterate – back up your farm before embarking on these changes…

To rename a content database, we’re going to remove the database in SharePoint, then detach the database in SQL Server, and reattach it with the new name. Finally, we’ll reattach the database.

Take the Content Database offline

  1. Open Central Admin
  2. Application Management –> Databases / Manage content databases
  3. Make sure you have your web application selected in the top right, then click on the content database.
  4. In the Content Database Settings page, change the database status from “Ready” to “Offline” then click “OK”
  5. Go back to the Content Database Settings page again, and check the box for “Remove content database” – note this means to remove the association from SharePoint; it doesn’t delete the database.

Rename the Database in SQL Server

  1. Open SQL Server Management Studio and find the database.
  2. Right-click on the database, select “Tasks” then “Detach…”
  3. In the Detach Database dialog, check “Drop Connections” but do not check “Update Statistics.” Then click “OK”
  4. Open Explorer and find the mdf and ldf files for the database.
  5. Rename the two files to matching names complying with your naming standard (in my case I changed WSS_Content_{GUID}.mdf to WSS_Content_01.mdf)
  6. Right-click on the “Databases” folder in SSMS, and click “Attach”
  7. Click the “Add…” button, then select the (new) mdf file, then click “OK”
  8. You’ll have to change the “Attach As,” Data, and Log file paths:
  9. Click “OK”
  10. Your database should now show up in SSMS – refresh the Object Explorer pane if it doesn’t.

Add the Content Database Back to SharePoint 2010

  1. Now back to Central Admin, and “Manage Content Databases.”
  2. Click “Add a content database”
  3. Enter the Database Name you created, then click “OK”
  4. Once that’s complete, you’ll see the database listed, and if you run “get-spdatabase” in the SharePoint 2010 Management Shell, we should have one GUID less to deal with!

Renaming Central Admin Content Database

So now you may have two questions:

1) What was all that talk about using PowerShell? We did this in Central Admin!

2) And hey – how do I rename the Central Administration content database?

This section should address both of those concerns – we’ll cover renaming the Central Administration content database in PowerShell, which will also show you how to rename any other content database in PowerShell. (Which gets important when you have a large number of databases to rename…)

What we’re going to do is create a new content database with the name we want, then move the sites from the existing content database into the new one, and finally delete the old content database.

Create a new Content Database

This is simply one PowerShell cmdlet:

New-SPContentDatabase -Name SharePoint_CA
     -WebApplication http://server:CentralAdminPort

This command provisions a database in the Farm’s SQL Server, then mounts it as a content database in SharePoint for the Central Admin web application. Now we need to move the Central Admin site from the existing content database to the one we just created. To do this we need the IDs (GUIDs, not the names) of the respective databases.

You can see the databases with a Get-SPDatabase, but if you try Get-SPContentDatabase then you’ll see other content databases in the farm, but you won’t see the Central Admin content databases. Central Admin content databases are excluded from listing in the Get-SPContentDatabase cmdlet as a security measure.

However, you can use the –webapplication parameter to explicitly get the content databases for the specific (Central Admin) web application. So:

Get-SPContentDatabase –WebApplication http://[server]:[port]

Will return the existing content database and the one we just created, so we can run:

Get-SPSite –ContentDatabase {GUID of old database} |
    Move-SPSite -DestinationDatabase {GUID of new database}

The first cmdlet selects all the SharePoint sites which are in the content database with the “evil” name. The pipe sends those sites as the input for the Move-SPSite cmdlet, with the GUID of the new database. Once you’ve moved the sites to the new database and verified them, then you can take the old content database offline, delete it from SharePoint, and delete it in SQL Server.