How to migrate from Exchange 2003 to 2010
Sometimes all the planning in the world won’t do. You know very well that Exchange Server 2003 is simply crumbling away in the face of demands in the late nineties. So you take a look at 2007, and then decide to wait for the first Service Pack, which popped out a little bit sooner than you’d expected. Before you know it 2010 is out, and you’ve made all these plans for migration.
Fret not: even if you have decided to abandon 2007 altogether, your blueprints will still be very useful. The important thing is to take note of the many legacy models in your incumbent server, and plan ahead with full knowledge of the new ways by which these old questions are addressed. In this article, we’ll take a look at the migration process, on both theory and practice.
Are you still fiddling around with administrative and routing groups? These dinosaurs are a reminder of those horrid days before Active Directory, where primitive men and women resorted to convoluted manual configuration in Exchange 5.5 in order to create administrators and route mail. The practice lingered on through 2000 and 2003, but in subsequent versions, Microsoft discovered it could simply delegate these tasks to corresponding roles built into Active Directory. Of course, the manpower savings are but a fortuitous side effect; the important thing is the irreversible tie-in and bundled sales. So, in order to migrate without glitches, it’s best to keep your Active Directory housekeeping in order.
For example, instead of distribution lists, you’d be utilizing Universal groups instead of global security groups. As for mail routing, the Active Directory Sites and Services configuration needs to describe the proper subnets and site links amongst them. Otherwise you can expect your mail to hop around aimlessly, instead of taking the path of least resistance as economy dictates.
There is also the question of orderly succession. You cannot dismantle anything in your old camp until everybody already crossed the river. Ease of migration is one thing and backward compatibility is another, so bear in mind that your new CAS, Hub Transport, and Mailbox servers would all refuse to work with Exchange 2003. Your bridgehead, front-end and back-end are better off staying with their contemporary peers for the moment. The 2010 version has a proxy service on the CAS server to aid in this temporary detour, so for instance, a user following a URL for Office Web Access can reach the 2010 CAS server. If the user’s mailbox has yet to be updates, the server would redirect the client to the 2003 OWA server.
Even after you’ve successfully hoarded the last of the mailboxes and broken out the champagne, it’s best to leave the old wares in for a suitable period of time, so that all of your users have had a chance logging in to their mailbox. This action triggers the old server to notify clients that the user’s mail has already been relocated, as well as automatically updating the user’s Outlook profile with what is essentially driving directions to the new destination server. It’s a one-time process, and in a week or two virtually all current users would have already accomplished it. This saves an enormous amount of manpower, since manually resetting Outlook profiles inevitably involves a degree of confusion at the user’s end, if not outright garment-rending and teeth-gnashing.
So as long as you migrate in an orderly manner – front-end to CAS, bridgehead to Hub Transport, and back-end to mailbox server – the whole process should be a seamless and non-disruptive experience. And of course, it will be all up to the adventurous administrator to take advantage of the multitude of new functionalities that Exchange Server 2010 has to offer. But one step at a time: even in these days of feature creep, Microsoft hasn’t really forgotten the humble roots of its gargantuan product that are electronic mail.
Here, we present a brief outline of the actual procedure. Depending on your specific configuration, you might want to fine-tune or rearrange the steps once you’ve grasped the main concept. First of all, bring the Exchange organization into native mode, and upgrade all of your servers to Service Pack 2, if you haven’t done so already. Then, access your Active Directory and promote its forest and domains to Windows Server 2003 functional levels or higher. Similarly, for each separate Active Directory site that will house Exchange Server, upgrade at least one global catalog domain controller to Windows Server 2003 SP2 or higher.
Now, find yourself a server that is capable of running Windows Server 2008 (RTM or R2), preferably with a 64-bit processor architecture, so you can install your first edition of Exchange 2010 server. You might have retired a server specifically for this purpose, or simply wiped an old one that happens to be lying around, it doesn’t matter though, as long as you’ve got a first instance lying around.
Now, install the Active Directory LDIFDE tools on your shiny new server, in order to upgrade the schema. When prompted, install other necessary prerequisites for additional roles, such as WWW capabilities for your CAS server.With everything at hand, you can now re-run setup on your Exchange server, upgrade your schema, and prepare your forests and domains. All these would be executed in one shot, unless you prefer tighter control and opt for separate controls at the good old command line prompt.
It’s not really counter-intuitive when you think about it: how can you install your CAS server roles properly without having to put first its requirements in place? So having prepared for its arrival in previous steps, you can go ahead and install them, configuring it to your heart’s content. Of course, it’s always a good idea to validate the majority of its functionalities, since it is an essential component. Once everything is in order, you can redirect the myriad traffic – OWA, ActiveSync, and Anywhere to your new servers.
Now it’s time to install and configure the Hub server, upon which you can transfer all emails, inbound and outbound. After the bridge is laid, you can then proceed at the two ends, and install mailbox servers and databases according to your organization’s needs. Instead of straightforward replication, the powers that be might be interested in trimming or expanding your server’s scope. Do it now while you’re at it. Of course, since we are talking about migration, there will be inevitable replication chores. Automate them using the pfmigrate.wsf script, AddReplicatoPFRecursive.ps1,or Exchange 2010 Public Folder tool, for mirror-perfect replications. Then while you’re at it, use the Move Mailbox Wizard to, as well, to move mailboxes.
Now that the grunt work is mostly done, you can move on to the finer things, such as relocating the Offline Address Book and the public folder hierarchy into the new Exchange Server and its Admin Group, respectively. Then it’s mainly housekeeping work, such as moving replicas to the public folder store, wiping information stores, routing group connectors, recipient update SAs, and for the finale,which is the uninstallation.
Easier than you thought, isn’t it? Do it before they come up with Exchange 2011, or the like.
