Exchange migration project (Part 1)

One of the bigger projects of my tenure at my current employer is firing up.  In this series of posts over the next couple of months, I'm hoping to highlight and document our methods, as well as go over any hurdles we run into, as well as how we resolved them.  This initial post will serve only as an introduction to the environment, and the overall plan of attack.

Currently our environment's email has always been hosted on an external mail host.  It has been this way for 10+ years, and unfortunately, we have just outgrown them.

Internally, we have been planning for this, and have turned up a new Exchange 2007 environment (yes, it's virtualized), and it is already hosting about 2000 mailboxes to some happy end-users that we migrated from a shoddy freeware platform called hMail earlier this year.  For them, OWA 2007 was a night-and-day difference to what they had before.

What we are now targeting is the corporate/regional backoffice staff that, while fewer in number, are the heavy hitters, with mailboxes ranging in size anywhere from 2GB to 40GB.  And while this is the second phase of this migration as a whole, this phase has many, many "sub-phases."

What I'd like to discuss initially is sub-phase 1, and the hurdles, and how we overcame them.

When dealing with Exchange, it's a fairly straightforward process to move email from one place to another.  What most people tend to NOT think about, especially over the course of TEN YEARS, is all of the little granular permissions, delegations, "EVP's admin asst can send email of his behalf, and view all calendars," etc etc etc.  We'll get to this in a later post, as it deserves its own.

To make things even a little more complicated, our host is still running Exchange 2003, and our current environment is Exchange 2007.  While there are defined upgrade paths from 2003 to 2007, there are not defined ways to take a 2003 edb and mount it on a 2007 mailbox server.  So, we were sold on the idea that tools would need to be leveraged, and trusts between forests would have to be established, in order to migrate the users, as if they were on a completely different mail platform altogether.

But wait...how the hell are we going to do all of that between a remote host and our internal domain?

Well, we could do a site-to-site tunnel, but that would require some complex networking and add add'l layers of complexity that we weren't interested in, or that the host might not even allow.

After exhausting all options, we resolved to the idea of physically relocating the Exch2k3 server, as well as a Domain Controller from that domain, into a private VLAN inside of our network, essentially hosting the additional domain short-term until we were able to migrate the data off of the mail server completely.  Why?  It seems to be much easier than trying to do complex tunneled solutions, the host was willing to let go of the old HP ML370 we're currently running on, and they were willing to replicate our domain information onto a DC that we could then bring in-house.

So, what's required to do this?

1) We need a private VLAN internally.  Coordination with the networking team to carve out ports and a space to host the new servers, and to avoid any crosstalk between the domains.  All outgoing mail would go out to the internet first and come right back in to the new 2007 server.  Could we get all super-cool with routing groups and SMTP connecters?  Sure, but why bother/overcomplicate for a server that has a remaining shelf-life of about a month.  We essentially just relocated the hosted solution, the same way they would if they moved datacenters.

2) Public access/interface:  MX records will have to be updated to our IP block, as well as building in new NAT/ACL rules into our firewalls for this solution.  Again, handled by the networking team but fairly straightforward, as if it were a new environment.

3) Physical move:  One of our admins is hauling a new box down in the morning that will be the new DC, and we will be taking an outage to relocate the servers.  During this time, the networking team will update Network Solutions, ZIX encryption gateway, and Sprint Spamshark to point to the new VLAN/Public IP.

At this point, we are at a hard cutover.  No more mail will flow to the host, even if we left the server there.  Once we plug in the hosts' gear and power it up in our datacenter, mail should resume delivery once again.


4) Power up the host's domain controller in our datacenter, and ensure that it is a GC.  Actually, this will be verified before it ever leaves the host's datacenter.

5) AD looks good?  Cool.  Check for EventID 13516 to ensure it can accept authentication, and upon success fire up the Exchange server.

That's the plan, and we'll see how it goes.

Upon success of this implementation/move, we'll take additional longer term outage over the weekend to attempt to P2V the box, and throw a ton of resources at it.  (It only has a 10/100 NIC, for example)

Further posts will include:

*Virtualizing Exch2k3 box with a P2V cold conversion.
*Virtualizing domain controller with a P2V cold conversion.
*Establish trusts between the two domains.
*Using 3rd party tools to move permissions, delegations, and data into existing domain.

Stay tuned...