Migrating to Exchange 2010 (Part 1)

Ah, upgrades and migrations. Nothing every happens the same way it does in the lab! First off though, I do have to say that my upgrade/migration from Exchange 2003 to Exchange 2010 SP1 was successful and relatively transparent to my end users. Of course, we have a pretty small office and only one server, so there were not a lot of moving parts.

Before working in production, I did two lab-based migrations using some older copies of my Active Directory and Exchange servers - probably a tad too old, since I ran into totally different troubleshooting hurdles in production. Also, there were several things I couldn't completely test in our lab environment, like our BlackBerry BES implementation or inbound and outbound mail connectors. But hey, I love flying by the seat of my pants.

One of the benefits of being late to Exchange 2010 was that there was lots of information on the Internet when I went search for solutions and nothing was insurmountable.
My primary source of guidance was the Microsoft Exchange Deployment Assistant, which is an online checklist of steps to follow. It asks a few questions about your environment and the produces a "customized" checklist. I have a few caveats about it though.

1. It assumes you are installing the various Exchange server roles on different machines or at different times. Since I was using the "typical" installation process my CAS, Hub and Mailbox roles were being installed together.
2. You must check off the completed steps in order. Sure, you can skip around and follow the instructions however you want, but if you like crossing things off a list as you go along and something early in the list is delayed, you can't check of any of the later tasks. For example, "Adding digital certificates on the CAS" is something that is listed very early in the checklist. I had to wait several days for my new SAN certificate to be issued but that didn't prevent me from moving forward with my migration. However, I couldn't play along with with the checklist.

These are small gripes and if you are a stickler for documentation, you can print, email or copy/paste the instructions from the deployment assistant into your own project plan.

In the lab, the typical installation went along with out a hitch. However, I was not blessed with such luck in production. The CAS and Hub Transport roles installed fine, but the installation choked on the Mailbox role with the following error.

Couldn't resolve the user or group "mydomain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.
I found the solution in several places, but it was very nicely documented here on Peter Schmidt's blog.

Just to clarify, you are deleting the "DiscoverySearchMailbox" user from Active Directory, rerunning your install for the mailbox role and then rerunning "setup /prepareAD" to recreate the user you deleted. Interestingly, I can't see the Discovery Search Mailbox in my Recipient Configuration in production, but I can in my test lab. (Odd... maybe one day I'll figure that out.)

At this point, Exchange 2010 is humming along right next my Exchange 2003 server and everything is happy and still working the way it did before, mostly because we have a Barracuda appliance that collects our inbound mail and delivers it to the Exchange 2003 server, so really nothing had changed.

I created a Receive Connector for the Barracuda, updated the Barracuda to deliver mail the Exchange 2010 server, then created my new Send Connector as per the Deployment Assistant and removed the Send Connector on the Exchange 2003 server.  Once I verified that inbound and outbound mail was still flowing it was time to take a breather and regroup for the next round.

Coming up - Getting BlackBerry BES to work again, fixing certificate errors with Outlook 2007, creating an external relay for some legacy devices on my network and figuring out why I couldn't mount an new database after I created it.  Stay tuned.