Last weekend I successfully upgraded, ahem, migrated the lab infrastructure from Microsoft Exchange 2003 to Exchange 2010.  This upgrade has been on my agenda for quite some time but I had been delaying it mainly due to lack of time and thorough knowledge of the steps.  I had a purchased the Microsoft Exchange Server 2010 Administrator’s Pocket Consultant (ISBN: 978-0-7356-2712-3) in January and marked up a few pages with a highlighter.  However, the deeper I got in the book, the more daunting the task seemed to have become, even for a simple one-server environment like mine.  In my mind, Exchange has always been somewhat of a beast, with increasing levels of difficulty as new editions emerged.  The pocket consultant series of books are wonderfully technical, but they haven’t been able to fit in my pocket for about a decade. They contain so much content that it has become difficult to rely on them as a CliffsNotes guide for platform upgrades, especially when it comes to Exchange.

Then two things happened miraculously at the same time.  First, I was invited to a private beta test of a virtualization related iPad application.  As part of this test, I needed to be able to send email from my iPad.  I had been unsuccessful thus far in getting Microsoft Exchange ActiveSync to work with the iPad (even after following Stephen Foskett’s steps) and could only assume that it was due to several years of wear and tear on my Exchange 2003 Server.  I needed to get that upgrade to Exchange 2010 done quickly.  Second, the May 2010 issue of Windows IT Pro magazine showed up in my mailbox.  To my delight, it was chock full of Exchange 2010 goodness, including a cover story of “Exchange 2003 to Exchange 2010 Step-by-Step Exchange Migration”. I’m pretty sure this was divine intervention with the message being “Get it done this weekend, you can do this.”

The upgrade article by Michael B. Smith started on page 26 and was 100% in scope.  The focus was a single server Exchange environment upgrade from 2003 to 2010.  I read the seven page artile in its entirety, marking up key “to-do” steps with a highlighter.  Following are some things I learned along the way:

1. Naturally the Exchange server is virtualized on VMware vSphere.
2. My Exchange environment is built upon a foundation that dates back as far as Exchange 5.5 (pre-Active Directory).  There would be no in place upgrades.  Exchange hasn’t provided an upgrade since Exchange 2003.  That suited me just fine as the Exchange 2003 server has been through so much neglect, although it had gotten pretty slow, it’s a miracle it was still functional.  The Exchange migration will consist of bringing up a fresh OS with a new installation of Exchange, and then migrating the mailboxes and services, and then retiring the old Exchange Server.  Microsoft calls this a migration rather than an upgrade.
3. Exchange must be running in Native mode.  Not a problem, I was already there.
4. Pre-migration, there exists a hotfix from Microsoft which is recommended to be installed on the Exchange 2003 server.  http://support.microsoft.com/kb/937031/
5. The Schema Master mast be running Windows Server 2003 SP1 or higher.
6. There needs to be at least one Global Catalog server at Windows Server 2003 SP1 or higher in the Exchange site.
7. The AD forest needs to be at Server 2003 Forest Functional Level or higher.
8. The AD domain needs to be at Server 2003 Domain Functional Level or higher.
9. For migration flexibility purposes, Exchange 2003 and Exchange 2010 both support DFL and FFL up to Server 2008 R2.
10. Exchange 2010 requires 64-bit hardware.  No problem, that requirement was met with vSphere .
11. Exchange 2010 can be installed on Windows Server 2008 or Windows Server 2008 R2.  I naturally opted for R2.  No sense in deploying a two-year old OS when a more current one exists and is supported.  Plus, I personally need more exposure to 2008 and R2… 2003 is getting long in the tooth.
12. Copy the Exchange DVD to a data/utility drive on the server.  Reason being, you can drop the most recent rollup available into the \Updates\ folder and basically perform a slipstream installation of Exchange with the most recent rollup applied out of the gate.  As of this writing, the most current is Rollup 3.
13. Here’s a big time saver, install the server roles and features Exchange 2010 requires using the provided script on the DVD:
    \scripts\ServerManagerCmd -ip Exchange-Typical.xml -restart
    Other sample pre-requisite installer scripts can be found here.
14. The 2007 Office System Converter: Microsoft Filter Pack (x64) is required to be installed.  This is downloadable from Microsoft’s website.  A little strange, but I’ll play along.  It’s required for the Exchange full-text search engine to search Office format documents.
15. Run the following commands for good measure. It may or may not be required depending on what’s been done to the server so far:
    sc config NetTcpPortSharing start= auto
    net start NetTcpPortSharing
16. Setup logs for Exchange are found in C:\ExchangeSetupLogs\  The main one is ExchangeSetup.log.  Hopefully you won’t have to rely on these logs and you are blessed with a trouble-free installation.
17. There are the usual Active Directory preparatory steps to expand the Schema which seem to have increased in quantity but I could be hallucinating:
    1. setup.com /PrepareLegacyExchangePermissions
    2. setup.com /PrepareSchema
    3. setup.com /PrepareAD
    4. setup.com /PrepareAllDomains
18. Installation can be invoked by CLI with setup.com /mode:install /roles:ca,ht,mb however, I chose a GUI installation which was more intuitive for me.
19. The article stated the installation would take at least 20 minutes on fast hardware.  My installation took less than 15 minutes on a VM hosted by four year old servers attached to fibre channel EMC Celerra storage – bitchin.
20. A Send connector is required before Exchange 2010 will route mailto the internet.
21. Exchange 2010 ships with two Receive connectors but they must be configured before they will accept anonymous email from the internet.
22. Exchange 2010 is managed by the Exchange Management Console which is called the EMC for short.  That will be easy to remember.
23. Exchange 2010 is also managed by PowerShell scripts (also called an Exchange Management Shell, or EMS for short).  There are some configuration tasks which can only be made via PowerShell script and not via the EMC.
24. Lend your end users and Helpdesk staff a hand by creating a meta-refresh document in C:\inetpub\wwwroot\ which points to https://<mail_server_fqdn>/owa effectively teleporting them into Outlook Web App (did you catch the name change? no more Outlook Web Access)
25. Mailboxes are no longer moved online due to their potential size and problems which may occur if a mailbox is accessed during migration.  Mailbox migrations are now handled via EMC by way of a Move Request (either local [same org] or remote[different org]).  When a move request is submitted, the process begins immediately but may take some time to complete obviously based on the size of the mailbox as well as the quantity of mailboxes multiple selected for the move request.  Tony Redmond wrote a decent article on how this is done.  Scheduled move requests can be instantiated via PowerShell script.
26. One of the final steps of a successful migration is properly decommissioning the old Exchange 2003 environment.  This is where things got a little hairy, and I half wasn’t surprised.  Upon attempting to uninstall Exchange 2003 to properly remove its tentacles from Active Directory and the Exchange organization, I was greeted by two errors in the following message:
    
    In the legacy Exchange 2003 System Manager, there are two Recipient Update policies which exist.  Going from memory, one was for the domain which I was able to remove easily, and one was an Enterprise policy which cannot be removed via the System Manager.  Follow the instructions near the end of this article for the procedure to modify Active Directory with adsiedit.
    The second error message deals with removal of the legacy Routing Group Connector.  There were actually two which needed to be removed.  The only way to remove the Routing Group Connector is via PowerShell and it is also described towards the end of this article.
27. After addressing the issues above, the uninstaller ran briefly and then failed for an unknown reason.  Upon attempting to re-run the uninstall, I noticed the ability uninstall Exchange 2003 via Add/Remove Programs in the Control Panel had disappeared, as if it was successfully uninstalled. Clearly it was not as the Exchange services still existed, were running, and I could launch System Manager and manage the organization.
28. ActiveSync doesn’t work out of the box on privileged administrator level accounts due to security reasons.  If you accept the risk, this behavior can be changed by enabling the inheritance checkbox on the user account security property sheet.

I’m pretty happy with the results.  The process took took quite a few steps but I am nonetheless pleased.  Careful work following a very nicely outlined procedure by Michael B. Smith has yielded both a snappy-fast Exchange 2010 server on Windows Server 2008 R2 as well as ActiveSync integration with my iPad.  Exchange 2010 is a beast.  I can’t imagine tackling an Exchange project for anything larger than the smallest of environments.  I’m not sure how I can have so many years experience managing my own small Exchange environment yet still lack the confidence in the technology.  I guess it mostly runs itself and as I said earlier, it’s quite resilient meaning it doesn’t require much care and feeding from me.  And thank God for that.

• Previous Entry: NetApp disk replacement – so easy a caveman and his tech savvy neighbor can do it
• Next Entry: P2V Milestone