Move Exchange overseas
So this is the first time I’ve done this, and I figured I would share this experience, as well as document it for myself. I will go into detail and modify this post as I get time, but here was my dilemma, as well as solution:
My company is downsizing and moving all HQ servers to another country, leaving us as a branch office. Exchange is one of many services we had to migrate, and I wanted to make Exchange seamless and painless, and provide uninterrupted mail flow throughout the process. I posted out on one of my favorite Exchange forums, http://www.msexchange.org, but did not get any replies. Either no one has done this, or those that have, are not looking at my post I thought. People suggested using a hosted Exchange service, which is viable, and being that I will ultimately be leaving the company, probably not a bad idea, BUT…
So the first thing I looked at was using an MX backup server. Unfortunately, these services had a 10 day window only, good for power failures, but not a migration of this magnitude. Shipping to China can take up to several weeks, worst case, depending on customs. Plus, MX backup servers just hold mail in a queue, and no one has access, so, I thought, why not create a backup mail server of my own? Which is what we did using open source Zimbra on the free CentOS. After getting Zimbra up and running on CentOS, we added a second MX record for our domain with a higher metric to begin with.
Migrating Exchange means migrating the domain controllers as well, or at least giving it access to a domain controller that is a global catalog server over on the other end if it exists. In our scenario, we are migrating all IT infrastructure, so we shipped both primary DC and our other DC. We built a new DC here in the U.S. and migrated the five FSMO roles over to it during the transition. The nice thing about Zimbra is that it will integrate with Active Directory so that you can maintain usernames and passwords as they were before for webmail access. Zimbra also provides the Zimbra desktop client which works well also. IMAP and POP3 are protocols that can be used, but we only employed IMAP connectivity for mobile users, and mobile handsets. I did not want people downloading mail “off” the server, so that we could sync email later. Once DC roles were migrated and Exchange prepared, we shut down Exchange, and saw a few issues that had to be sorted out before being able to fully shut down, mostly due to dcdiag issues. Might want to give yourself a few days for this so you can iron out any problems with AD and DC’s. Make sure to run dcdiag and any other directory or networking tools to ensure that your network is in working order.
OK, so the Exchange server is now shipped and on its way. We changed our MX record priority metrics around so the backup mail server had a higher priority so that mail came through faster, rather than waiting to time out on a non-existent server. Mail flow worked well, and people were able to log in fine. We had to make sure to set people’s passwords to “never expire” so they did not lose access during this time. Using ADModify did a great job of that, changing many objects at one time. We worked with Zimbra for two and a half weeks during the shipment and migration. It took a week to get Exchange back online due to vacation schedules and such. Once Exchange was back online, we made changes to the MX priorities, and just prior to shipment, made the DNS changes to point mail.domain.com to our new IP address in China. Once the hardware was back up and mail was flowing again to Exchange, we changed the authentication method on Zimbra from “external active directory” to “internal”. When I set users up on Zimbra, I exported our users from AD using CSVDE. Importing to Zimbra is fairly easy, it just requires the email address, first and last name and password (if I remember right). I set the password up as one password I could remember, but keep in mind that we used “external active directory” for authentication, so people used their familiar Windows username/password to access email until we switched at the end to “internal”.
I used MapiLab Native POP3 Connector to sync email. Using this you can use secure POP3 on port 993, but you have to create each user individually. Painstaking I know, but we only had a little over 100 users, so it worked in my scenario. Once mail flow was established on Exchange, and Zimbra was set to internal authentication, mail began merging from the Zimbra server to Exchange server, inbox to inbox ONLY. Sent items or email put into folders on Zimbra were not synced. Important to let the users know about this.
Some pitfalls:
We also use Barracuda hardware for spam filtering. During this transition, we had many email aliases. I configured the Barracuda to use LDAP to verify a user exists in AD before allowing it through. In our case, we use a strange naming convention. So say the username is jdoe, our primary email for this user would be johnd@domain.com. Don’t ask me why, but it was that way and that’s all I have to say about that. So we have aliases for both jdoe@domain.com and johnd@domain.com in most instances. The spam filter was having a hard time with the alias, so I had to add some aliases by hand for mail to flow properly.
Groups. Arg. Groups for ALL employees had to be re-created by hand. After creating, I came to realize that any external email could email this group. Not good, when you want to reduce spam sent to all@domain.com. In AD, we limited people that could send to that group by creating another group “Send-To-All” and allowed only that group to send email to that distro group. In this case there was a fix for postfix that allowed me to do the same thing. I will have to get back to this post to provide those details.
AD replication. Way out of whack now. DC’s are still out of sync because we tore down the hardware VPN’s between offices, so we have to make sure that AD replicates from China to us now. This will affect AD work, and passwords primarily. Another arg…
Not fun, but doable!

No Comments »