Microsoft Exchange-to-Google Apps migration survival guide

Switching from Microsoft Exchange to Google Apps may have many benefits, but the journey is definitely not the reward

Few IT resources have greater visibility within an organization than email. It's a service that's critical to every user, and email outages cause the user base to panic. Migrating from one email system to another is always a difficult proposition, and the move from an in-house Microsoft Exchange mail system to a cloud-based system like Google Apps is even more challenging. Dealing with the inevitable postmigration problems can try men's souls.

The migration from Exchange to Google Apps is built on two tools: Google Apps Directory Sync and Google Apps Migration for Microsoft Exchange. The former is necessary to synchronize user accounts, groups, shared contacts, and user profiles in an Active Directory domain with Google Apps, and the latter does the grunt work of actually copying email, calendar, and contact data from Microsoft Exchange to Google's service.

The first order of business (once you've set up your business account with Google) is to begin constructing your Google Apps Directory Sync configuration. This requires deep knowledge of your Active Directory structure, as well as general knowledge of LDAP and its query structures.

Exchange to Google Apps: Google Apps Directory Sync
The Google Apps Directory Sync tool is split into two main applications: the configuration manager and sync-cmd.exe. The configuration manager is a tool that can read and write Google Apps Directory Sync XML configuration files and run simulations of the synchronization task to check the viability of the configuration; sync-cmd.exe is a command-line tool that executes the real synchronization process.

Working with the Google Apps Directory Sync configuration manager is a double-edged sword. It makes certain items quite simple to configure, such as the basic settings of the Google account to use for the sync, the LDAP server to query for data, the base DN, and so forth. But it can be irksome in places where you're required to include or exclude a significant number of individual elements -- such as a list of users that have no commonality and need to be excluded from the sync. Adding these lengthy configuration elements line by line through the GUI tool gets old very quickly.

However, the configuration file is just XML, so I found that writing a bit of code that spits out valid XML and pasting it into the configuration file sped up this process significantly. As you move through the tool's quasi-wizard interface, you'll be presented with a series of required configuration parameters. I'll step through them here in the order they're presented.

LDAP settings. There's no preset for working with Microsoft Active Directory. It's treated just like any other LDAP data source and requires manual configuration. For a Windows Server 2003 domain, using the default port of 389 and simple, non-SSL communication works well. For most (but certainly not all) Active Directory implementations, the base DN will be ou=users,dc=company,dc=com. You'll want the base DN to be as specific as possible while still incorporating the LDAP objects that need to be synchronized, including all users and groups.

Org units. I ran into problems with the organization unit inclusion/exclusion rules. No matter how I structured these elements, Google Apps Directory Sync would still evaluate the OUs specified in the exclusion list. I didn't get any response from Google when I asked about this problem. Your mileage may vary.

Users. This is obviously a key element to the synchronization process. The email address and alias attributes are generally set to the default for a Microsoft Active Directory network, so these elements can stay as they are. The extended attributes are generally givenName and sn for first and last names, respectively. If there's a mailbox quota attribute in play, that can be added here, but it's not required.

It's important to note that users can be synchronized from Active Directory to Google Apps fairly easily, but their passwords cannot. There is a roundabout method to synchronize passwords that involves using sha1hexfltr, a custom DLL that must be installed on every domain controller in the organization. This DLL intercepts user password change events and places an SHA1 hash of the new password in the (generally) unused division attribute.

Using the sha1hexfltr method may be too much of a security risk for some, as it stores the SHA1 password hash in the user object. It's also quite kludgy. However, it's also the only practical way to achieve password synchronization at this time.

Groups. Group synchronization has the same basic requirements as user synchronization, with inclusion and exclusion rules. To include specific groups, it's probably easiest to select them with an LDAP query referencing the mail attribute, like this:


You can also use wild cards, like this:


You'll want to populate other Google Apps directory attributes such as Group Email, Group Display Name, and Group Description as well. To have that data carried over from Active Directory, map Active Directory's mail, displayName, and description attributes to these fields. Generally speaking, you'll use the member attribute in the Member Reference Attribute field as well, though this may change depending on your Active Directory configuration.

It's important to note that fundamental differences in how Google Apps Directory Sync deals with groups may force you to run two separate synchronization passes: one for groups and one for users.

The problem is that unless Google Apps Directory Sync can evaluate an LDAP object from the users scan, it will not properly synchronize that object even if it's specified in the group scan. This means that while you may have a perfectly functional user synchronization configuration, it may not be wide enough to evaluate the group objects, and you cannot widen the LDAP query without dragging in a pile of other nonsense.

This dependency is especially annoying because it's not immediately obvious why the group objects are not synchronizing. The log files simply state that the specified group does not have an associated email address and is therefore skipped.

Creating two separate Google Apps Directory Sync configurations, one for users and one for groups, gets around this problem. The groups configuration contains LDAP inclusion queries that specify a wide range of objects, but with user synchronization turned off. This allows the group inclusion queries to function normally, as the user query (within the groups configuration) evaluates the group objects properly, but does not try to synchronize all those user accounts. Again, it's a roundabout method, but it is functional.

I have run into strange problems with groups, however. Without a configuration file change, groups that used to evaluate as nested groups within others suddenly became simply email addresses. I've been requesting information on this sudden change from Google for weeks without an answer and have had to suspend group synchronization as a result. Getting info from Google -- even just a full list of configuration options -- on Google Apps Directory Sync problems has proven extremely difficult.

User profiles and shared contacts. These synchronization elements are similar in configuration to users and groups, but have a plethora of attributes that need to be entered. This is a good time to download an LDAP viewer like Active Directory Explorer and poke around in your directory to make sure that you get the attributes right. This will obviously take some time, but if you need to synchronize user profiles and shared contacts, it's a necessary evil.

Exchange to Google Apps: Running the sync
The Google Apps Directory Sync configuration tool will run only simulations, which are handy for testing your configurations. The simulation does everything but actually modify data, and it dumps out a log file and a results file.

Test and tweak your Google Apps Directory Sync configuration until you're certain you have it right, and then do a real run with the sync-cmd.exe tool. Assuming that sync-cmd.exe and the Google Apps Directory Sync configuration file prodsync-users.xml share the same directory, a normal invocation might look like this:

C:\Program Files\Google Apps Directory Sync\sync-cmd.exe -a -c prodsync-users.xml

This will run an actual Google Apps Directory Sync synchronization. Once it's done and you've checked the results in Google's app management page, you can configure this to run as a scheduled task.

In order to maintain consistency between Google Apps and Active Directory, you'll need to run the users and group syncs at least once a day, probably a few times. Otherwise new users won't be visible to Google Apps, and password changes will not occur in a timely fashion. It's generally a good idea to run the syncs at least twice a day.

It's also a very, very good idea to enable Google Apps Directory Sync email notifications. Google Apps Directory Sync is a worryingly fragile piece of software that can turn on you like a snake. I've had back-to-back synchronization runs produce wildly different results, and I've seen inexplicable errors arise out of nowhere, only to disappear a few minutes later without any configuration changes -- not to mention other very troubling issues with this tool. Google Apps Directory Sync is the only way to maintain synchronization between Active Directory and Google Apps, but it's also never to be trusted.

Google Apps Directory Sync is the single most problematic facet of a Google Apps migration.

Exchange to Google Apps: Moving the mail
Once you have all your users and groups synchronizing to Google, it's time to move all that mail. The Google Apps Migration for Microsoft Exchange tool is fairly straightforward, offering a relatively simple interface to migrate mail, contacts, and calendar data from Microsoft Exchange into Google Apps. It's not a fast process to be sure, but it works. Naturally, there are a few points to consider.

First, this tool can't be run from the Exchange server. Pick a relatively beefy box to run it on, because it will consume fairly significant CPU and RAM resources.

Second, it's important to note that while you can start and stop mail synchronization whenever you like without causing problems, you cannot stop and start contacts and calendar synchronization without creating duplicate objects. Thus, you should concentrate on getting a solid contacts and calendar sync at the last possible minute before the cutover. On the other hand, synchronizing the mail is easy and can run over a period of many days if need be.

Third, the Google Apps Migration tool can also migrate Outlook .pst files to Google Apps, so you can pull all of those personal archives out of mothballs and get that mail added to your users' Gmail mailboxes.

Finally, you might be surprised to find out how long it takes to migrate lots of Exchange mail. It may be on the order of weeks before the job is finished, depending on the size of the Exchange message store. Be sure to allocate enough time for the move.

Exchange to Google Apps: The cutover
Assuming you have all of the above in order and your mail is syncing properly, you can pull the trigger and cut your domain over to Google Apps. An ideal approach is to lower the TTL (time to live) of the MX record for the domain to five or ten minutes several days before the planned switchover. Then, when you finally modify the MX records to point mail at Google's servers, there will be very little delay in those records being recognized by other DNS servers. Your new MX record information, provided by Google, will be accessible through the Google Apps administrator console.

Note that if you plan on using the Postini filtering service, you'll be working with different MX records than the ones Google gives you. This is explained in the Postini setup pages that are accessible through the Google Apps admin console.

Once you've cut over the external MX records, mail should be flowing into the Google Apps mailboxes. Verify this with simple tests from other email accounts.

It would be nice to test your new Gmail accounts prior to the cutover, but Google will not deliver email addressed to a valid account and domain unless the MX records for that domain are correct. You can test to the Google test domain, which is, but making a direct connection to Google's SMTP service and sending a message to will result in that mail simply disappearing. You just have to do the MX change and cross your fingers. It's not exactly a comforting situation.

Exchange to Google Apps: Aftermath
After cutting over the domain, you'll be running on Google Apps. Your users will probably be in disarray, and you'll need to worry about getting mail applications to work with the new mail system, though you can push group policies to make some of those changes. Outlook integration is generally one of the hot topics following this migration. A good plan is to force everyone to use the Web interface for the first week or two, giving both you and the users time to settle into the new mail system.

1 2 Page 1
Page 1 of 2