I was recently approached with a work proposal by a client whom I'll call Tony. Tony works at a sizeable organization which I'll call Gozoba.com (it seemed like a fun word) in a position of some authority. Gozoba runs Exchange 2010 and has several hundred users running Outlook 2010.
Tony was planning on going into semi-retirement and wanted to know if it was possible to relocate his email environment and that of his secretary Eileen to his own personal domain, including his messages, calendar and contacts. Tony's goal was to preserve his familiar email setup and possibly pursue some independent consulting when the time came to leave Gozoba, thereby ensuring an easy "stepping off the boat onto the dock" kind of transition. These are always preferable to the "dive overboard and start swimming to shore" versions.
I said this endeavor was certainly possible and Tony asked, "Can we migrate my email and Eileen's to my own domain but also make it so that Gozoba employees can still email us through the global address list and view our schedules to book meetings with us? I'd really like to make the process as invisible as possible to everyone. I don't even think it's necessary to notify company employees of my new email address."
That concept was a bit trickier but I knew that I could probably work out the first part of the request using email forwarding/updated global address list entries for Tony and Eileen. The second part would require calendar sharing between the two domains. Since Tony has a Google Apps for Business account I researched this and found that Google's Calendar Interop function could fulfill this need.
As we talked further and gathered requirements it became apparent that the project would be almost like a surgical procedure. I've discussed the email migration process to Google Apps in the past but this was a unique situation since only these two users were to be migrated. The goal was to conduct a sort of "search and replace" of Tony and Eileen's current Gozoba Exchange accounts to make the new Google Apps accounts as similar to the Exchange accounts as possible.
The full requirement list was as follows:
- Tony wanted a new email domain set up for this purpose which I'll call tonysdomain.com. This would be associated with his existing Google Apps for Business domain.
- Mail sent from outsiders to Tony and Eileen's gozoba.com accounts should be redirected to their Tonysdomain.com accounts.
- Gozoba employees could email Tony and Eileen at their tonysdomain.com addresses from the company Global Address List or respond to older emails without having to do anything different.
- Gozoba employees could continue to book meeting requests with Tony and Eileen while viewing their calendar schedule data, and vice versa.
- Tony and Eileen wanted to continue using Outlook 2010 as their primary email clients.
- Eileen needed to be able to access Tony's messages, calendar and contacts with full control so she could make changes which Tony could then see.
- Eileen's Blackberry needed to be able to receive her new Google Apps mail (she has an iPhone but prefers the Blackberry to be used for work-related email). The same applied to Tony's iPhone and iPad, as well as his laptop.
Seven requirements. Pretty simple, right? Only two people to migrate, right? Should be a walk in the park, right? Well... not so fast.
The preliminary process
The beauty of an email migration is that you can conduct much of the setup and prep work beforehand and then minimize the amount of work needed at cutover time. The less downtime and disruption for the users, the better.
I conducted these steps without any impact on the current email setup:
- Registered the new domain and associated it with Tony's existing Google Apps for Business account.
- Set up an account for Eileen in Google Apps (Tony already had one).
- Created mailboxes for Tony and Eileen on Tonysdomain.com and provided them with their passwords.
- Delegated access to Tony's calendar for Eileen (which involved accessing Tony's calendar and sharing it with Eileen as discussed in the link).
- Delegated access to Tony's mail and contacts for Eileen (which involved accessing Tony's Gmail settings and granting Eileen access to his account as discussed in the link).
- Set up Google Apps Calendar Interop for Microsoft Exchange. The details (which are provided in the link but this presentation provides a better overview) would involve another full article, but this involved two sets of steps on the Exchange and Google Apps sides:
- Setting up a public folder database
- Configuring a role account user in Exchange for the Google Apps account to exchange calendar data
- Setting up mail-enabled contacts for the Google Apps accounts in Exchange
- Setting up the availability address space for the Google Apps domain
- Google Apps
- Configuring an API scope to permit third party Oath access
- Configuring Calendar interop settings
- Configuring Calendar interop users
- Migrated email using Google Apps Migration tool (which copied, not moved, email, calendar and contacts):
Now it's showtime
Everything was set up in Google Apps so it was time to cut over after one final data sync immediately beforehand.
I mentioned that Tony and Eileen wanted to use Outlook for their email. Google provides a utility called Google Apps Sync which synchronizes Google Apps email (e.g. Gmail) with a local Outlook client, by creating a personal storage (PST) file which is then continually synchronized. It works reasonably well but I'm a fan of simplicity - if it were my account I would simply opt to use the Gmail interface. However, the Gmail look and feel takes some getting used to, and people who have run Outlook for well over a decade are understandably attached to its functionality. As a bonus, if you have existing PST files you can access these in Outlook, of course (although the Google Apps Migration tool also provides the option to migrate these to Gmail).
Installing Google Apps Sync requires you to provide approval for the app to access your data. It then sets up a new Outlook profile and starts downloading data from Gmail (you can also choose an installation option to use an existing profile if you have local data you want to add to your account). I set this up for Tony (on both his desktop and laptop) and Eileen and the following screen appeared for each:
Each user could have had a cup of coffee and made a phone call or two during this process then gotten back to work; that's how quickly the cutover was conducted.
Once this was done both users were fully connected to their Google Apps accounts at tonysdomain.com and had access to all of their data. Since this data is stored in a PST file this means it will remain available even if their systems were offline, such as with the case of Tony's laptop.
I added Tony's mailbox to Eileen's Google Apps Sync settings and this sync'ed up as well, providing access to his email and calendar (but not contacts, an important detail I'll cover further in a bit).
It was then time for me to put on my miner's helmet and enter the tunnels to get everything reconfigured below ground.
Working behind the scenes
I proceeded to perform the following tasks to complete the transition:
- Accessed the Google Calendar Interop settings to add Tony and Eileen's accounts in the list of users to synchronize so that their schedule data would be exchanged with the rest of the company (I did not want to take these steps until their Google Apps accounts went live). This involved entering their Exchange contacts along with their legacyExchangeDN attribute from the Active Directory. For example:
Tony@tonysdomain.com,GOOGLE, /o=Gozoba.com/ou=First Administrative Group/cn=Recipients/cn=tony
Eileen@tonysdomain.com,GOOGLE, /o=Gozoba.com/ou=First Administrative Group/cn=Recipients/cn=Eileen
Since I needed to wait a bit to ensure this was working I went forward with these other actions:
- Activated and tested a rule in the Gozoba email gateway to redirect inbound email to Tony and Eileen's Google Apps accounts (redirection was important since I didn't want these outside emails to reach the internal Exchange mailboxes for these users, since they would then receive duplicates per the next step).
- Activated and tested a forwarding rule in Exchange to redirect inside Gozoba email to Tony and Eileen's Google Apps accounts so that email sent by Tony/Eileen before the cutover could be replied to by internal users on a later date (you'd be amazed how often this happens).
- Hid the existing Exchange accounts for Tony/Eileen in the Gozoba global address list.
- Created mail-enabled external contacts in the Gozoba global address list for Tony and Eileen, each of which used their Google Apps email address. This in conjunction with hiding the existing Exchange accounts meant anyone who sought to email them via the global address list would do so directly to their current email addresses.
- You might be wondering why I didn't just delete their Exchange mailboxes. Two reasons: in case something went wrong and we had to revert back to the original configuration, and I wanted those mailboxes handy just in case we needed to look for any missing data. Eventually these will be archived to PST files and deleted.
I then completed the migration via the following steps:
- Set up access to the Google Apps accounts on Tony's iPhone/iPad and Eileen's Blackberry (the original Exchange-based accounts were disabled on all of these).
- Informed Tony and Eileen that they could still access email via the Gmail interface if necessary. Since Eileen administers Tony's contacts, this was now the only option available to her to do so other than periodically exporting his contacts in Outlook to a PST file and then importing them to her Outlook profile. That would require doing the same in reverse if she made any changes, of course, which is not particularly feasible.
- Confirmed that calendar information was being synchronized between Tony/Eileen and Gozoba users.
All's well that ends well - except for a few snags
This seemed to complete the process and all was working as we had planned... so far. Internal users saw no difference when communicating with Tony and Eileen via email or meeting requests and the same applied in reverse. Mobile devices were humming along sending and receiving email and checks of Gmail and Outlook showed the data was synchronizing nicely.
However, whenever I conduct migration work I make sure to keep paper and pen handy to record the details when the phone rings with some unexpected post-migration development. As it turned out, it rang the next day and my pen got very busy. Rather than exhaustively analyze each issue I'll provide a problem description and solution (where applicable).
Problem: Gozoba Cisco Unity voicemail messages weren't being emailed to Tony and Eileen's new accounts.
Solution: None as of yet. Cisco Unity doesn't merely forward voicemails as email messages; it actually writes these to the mailboxes directly, meaning auto-forwarding to outside accounts doesn't work (however, it's possible to forward the messages manually). An apparent permissions issue prevents the items from being delivered to Tony and Eileen's Google Apps accounts even if specific Outlook rules are written for this purpose. Documentation and Cisco support forums turned up no worthwhile leads, which is disappointing to say the least given the fact we simply can't be the first people to try out such an endeavor.
As of now the voicemails are being forwarded to the receptionist who manually forwards them to the recipients. This is a workaround, not a solution, but since it involves only 1-2 voicemails per day this is not a hardship.
Problem: Eileen found that meeting requests to some Gozoba users failed with "None of your e-mail accounts could send to this recipient" errors.
Solution: Purge the cached address entries for these users in Outlook by starting a new email, typing their name, letting Outlook autofill in the cached address entry then clicking the black "X" to the right and starting over.
Problem: Tony's Sent Items were disappearing from the corresponding folder.
Solution: Eileen had an Outlook rule to move all email from Tony into a separate folder - and since she was a delegate with access to his mailbox this applied to his Sent Items as well! We tweaked the rule to only copy email from Tony to Eileen into this folder.
Problem: Tony was unable to email his original Gozoba email address and have this message auto-forward to his new Google Apps email address.
Solution: None found; this appears to have been a weird addressing glitch (or possible bounceback prevention feature) but it only applied to email from Tony's new address to his old one. I advised him not to send himself messages in this fashion.
Problem: Tony reported his Draft emails weren't synchronizing between Outlook and Gmail.
Solution: This does not work by default; the Google Apps Sync program doesn't synchronize Drafts.
Once these issues were knocked down we then had a minor flare-up of what's known as "Project Scope Creep." Scope creep can be a disaster when it rears its head after a migration because the desire for new features can threaten the success (or the perception thereof) of the entire mission. In this case the following ideas were brought up:
Question: Is it possible to synchronize Tony's contacts with Eileen's Outlook account so she can edit them directly rather than work through Gmail?
Question: Can Tony's junk mail settings synchronize between his desktop Outlook client and that of his laptop?
Answer: Again, not by default and the only way to really accomplish this would be registry export/import from his desktop to his laptop and vice versa. It's possible to rig up something involving Dropbox and a scheduled task, but might require some care and feeding to administer. I advised Tony to manage junk email settings directly from the Gmail interface under Settings/Filters.
Closing the book
The requirements of the migration were met and so the project was concluded successfully. I feel the Cisco Unity issue was a bit of a thorn in our sides and hope to find a more permanent fix for this eventually, since I hate loose ends no matter how minor. As you can see, it's critical to keep things simple as possible, scope out all of the details in advance (a project like this should involve 90% planning and 10% execution), have a backout option and prepare yourselves for (and warn users that there will be) post-migration questions or problems. Last but not least, document the entire process so your client (or whoever might support them down the road) knows what you know.
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.