Exchange 2003 – Exchange 2003 Swing Migration Instructions
Moving your Exchange system to new hardware can seem daunting. Email is often considered one of the most critical applications within a company, so getting it wrong could cause problems. However with proper planning it is possible to migrate users to a new system with little or no downtime – they may not even know that they have been moved.
This is a brief guide on how to carry out a migration to new hardware and is known as a swing migration. It can also be adapted to update an existing machine from Exchange 2000 to Exchange 2003 if there is a spare machine available.
Read the entire guide before starting. There are lots of notes and tips on a successful migration throughout which can help ensure that your migration goes to plan.
For migration to Exchange 2007 from Exchange 2003, see our separate guide here.
- If after reading this guide it raises more questions than it answers, then it isn’t for you.
As with many of the articles on this web site, the process expects you to have some knowledge of how Exchange operates, how replication is carried out for public folders etc. It is not a HOW TO which shows you what you need to do on each small step.
- This guide is not suitable if you wish to retain the existing machine name and/or IP address.
However most people want to keep the same name as they believe that if they do not, they will have to visit all the desktops. This is not the case. As long as both the old and the new server are available (i.e. the server is on with Exchange installed) at the point the clients connect for the first time, they will automatically redirect to the new server – no user or admin interaction required.
Pre Migration Checks
Before you start the process you need to check three settings on the SMTP Virtual server.
- Smart Host Configuration on the “Default SMTP Virtual Server”.
If you have configured an entry in the Smart Host box on the SMTP virtual server then you need to remove it and replace it with an SMTP Connector. Exchange uses SMTP to communicate between the servers. Using a Smart Host on the “Default SMTP Virtual Server” will stop the messages going between the servers.
For information in setting up an SMTP Connector, please see
our dedicated page.
- External DNS on the “Default SMTP Virtual Server”
You should also ensure that you do not have any external DNS servers configured on the SMTP virtual server. This can stop DNS from finding your new server. If you find that DNS lookups don’t work correctly without those set, then configure forwarders on the DNS Server applet on your domain controllers.
- Connection Restrictions
If you are using any kind of email filtering that is external to Exchange, this could be an appliance or service, then you may have configured restrictions on the SMTP virtual server, under Access, Connection. Ensure that your new server is on the list, as the two servers need to communicate and exchange data over SMTP. It is not a one way traffic process.
For a successful migration, there are some general points to consider
- Take your time.
Trying to rush the migration only causes problems. The replacement Exchange server could be in production for a few years. Rushing things at this point to save a few days could cause you problems long term. A properly built Exchange server that has been built with care will give you years of trouble free service.
- Check everything is working correctly constantly.
An Exchange server should work straight out of the box. If it doesn’t appear to be working, stop the process, remove Exchange and start again. Particularly if the install doesn’t work immediately, gives you errors etc. Until you start moving mailboxes you can back out of the process at any point and start again. Even after moving mailboxes you can simply move them back. At no point is the data at risk. Exchange is a complex product, if you can see something isn’t working correctly, it could indicate a more serious issue that you cannot see inside the application.
- Plan Ahead.
With good planning this process can be carried out with little or no downtime, with most work done during production hours. It is not complex by any means, but cannot be carried out in a few hours. Be sure of what steps you are taking and when, in advance.
Each of these are covered in detail further in this article.
This process would ideally be spread over two weeks, with the mailboxes being moved over the middle weekend.
- Prepare new machine – installing Windows, Exchange and all relevant updates and patches, configuring the server.
- Configure replication of Public and System Folders
- Move the Mailboxes
- Move inbound SMTP
- Move Recipient Update Services (RUS)
- Change “Routing Group Master”
- Configure Public and System Folder replication to remove old server
- Remove old server
Using this process to update the existing server
You can also use this process if you want to update your existing server – for example to go from Windows 2000/Exchange 2000/2003 to Windows 2003/Exchange 2003.
For example, you have a server called “server1” which you want to update, and a standby server called “server2” .
Follow the same process as outlined below to move everything to “server2”, including removing the original server (server1) from the network. Remember to drop the machine in to a workgroup before wiping so that it has been removed from the domain.
Then build the machine with the new operating system, but use the same original name (server1). After installing Exchange, repeat the process to move all the data back.
By using the original name if you don’t have to wait around for all the clients to connect to the server to be redirected. Any clients that have not been redirected to the new server before the mailboxes were re-homed to the temporary server will still connect. For everyone else, they will get redirected in the usual way.
HTTP/HTTPS Services (Outlook Web Access, RPC over HTTPS and Exchange ActiveSync)
A significant issue with this process is the HTTP/HTTPS based services of Outlook Web Access (OWA), RPC over HTTPS and Exchange ActiveSync (EAS). Unless you are running a frontend / backend scenario the HTTPS services needs direct access from the client to the Exchange server that hosts the mailbox being accessed. It cannot be routed from one server to another (i.e. the user connects to the old server for OWA and the traffic is sent to the new server via the old server). This could mean that some users aren’t able to use the HTTP/HTTPS based services until the port mapping on your firewall has been changed.
Take in to account access to HTTP/HTTPS when planning your migration.
One option would be to put in a temporary Exchange server and configure it as a frontend server. This would then be used for HTTP/HTTPS access during the migration. If you take this option then ensure that you treat the server as you would any other Exchange server – so fully patched and service packed for both Windows and Exchange. Remember that a frontend server needs to be the same or higher than the backend servers. Therefore if you deploying Exchange 2003 SP2, then the frontend needs to be that version.
Upgrading an Exchange 2000 Frontend / Backend Scenario to Exchange 2003
If you are currently using Exchange 2000 in a frontend/backend scenario, then you need to upgrade the frontend first.
This either means the frontend server needs to be in place upgraded (not recommended) or the server should be de-selected as a frontend server, then the replacement Exchange 2003 frontend server is installed. Exchange 2003 can be a frontend for an Exchange 2000 server, but you do not get the Exchange 2003 OWA in that scenario.
The Migration Process
Prepare the New Machine
Preparing the new machine will depend on what you are migrating to.
If you are migrating to a new machine that is running the same version of Exchange then you can just install Exchange on the new machine.
If you are migrating to a new machine and also upgrading Exchange version then there is additional prep work required. The best way to go about this to allow the Exchange 2003 CD to auto play and then follow the checklist.
The key things are to run forest prep and domain prep. Allow at least 30 minutes between each prep for the changes to propagate. If you are simply migrating between versions then you do not need to run prep again.
Either way remember that Exchange works best on a member server – not a domain controller.
However if you do install Exchange on to a domain controller then running DCPROMO to remove the DC functionality after Exchange has been installed is not supported. Similarly if the machine was a member server at the point of install then making it a domain controller with Exchange installed is also not supported. In short – once Exchange is installed, never run DCPROMO either to add or remove the domain controller functionality.
If you do install Exchange on to a domain controller make sure that it is a global catalog as Exchange will not look to any other server for domain information.
Therefore install the base operating system (Windows 2000 Server for either Exchange 2000 or Exchange 2003 / Windows 2003 for Exchange 2003 only). Add the machine to the domain.
You will need to install the additional Windows components that Exchange requires.
Internet Information Services with NNTP, SMTP and World Wide Web. If Windows 2003 then ASP.NET also needs to be installed.
Before installing Exchange, make sure that the server is fully up to date with the latest service packs and automatic updates. It is easier to do this now than after the server has gone live.
Install Exchange – the installer will detect the existing Exchange organisation and automatically add the new server to it – no questions will be asked as you cannot have two Exchange organisations in the same domain. If you are installing on Windows 2003 SP2, then you will get a prompt about the version of Windows having compatibility issues, usually more than once. Everyone gets that error – it is not unique to you. Review the URL mentioned in the URL, but most users of Exchange can ignore it and carry on.
Don’t forget to update the server with the latest Exchange Service Pack, hot fixes and updates from Microsoft. Use Microsoft Update to download the updates after installing the service pack.
Moving Other Services/Configuration
Remember that all configuration on the new server will be close to default, except for settings that are set under “Global Settings”
- If you are using an SMTP connector, add the new server to the configuration as a bridgehead.
- If you are using alternative locations for the database, transaction logs and message tracking logs, move those before you migrate any data. The empty databases and small number of logs will move much quicker than trying to do so later on when you realise you haven’t done it half way through the migration.
- If OWA has an SSL certificate then export this from the old server and move it to the new server.
- If you have anti spam or antivirus tools on the original server then these need to be installed on to the new server. Look for migration instructions on copying the configuration to a new server. Most tools have these now and should be used to ensure that the new server operates in the same way as the original.
- Any other 3rd party applications installed on the original server should also be installed on to the new server.
- Backups should be configured after the data has been moved – but as soon as you have live data on the server you need to consider some kind of backup.
Minor Configuration Changes You May Miss
This process only moves the data, it does not move any configuration that is server specific. Therefore you should check the settings on the old server and ensure that they are matched on the new server. However you may also want to review the settings and ensure that they are still appropriate for your environment. Do not blindly copy the settings across to the new server.
These settings you should look at include (but are not limited to):
- SMTP virtual server: Connection restrictions, logging settings.
Enable IMF, Recipient and Connection filtering and the IP address being used.
- Limits on the mailbox sizes, message sizes etc.
- Deleted Item Retention settings
- Message tracking enabled
- RPC over HTTPS registry settings (Exchange 2003 only)
- Enabling Forms Based Authentication (Exchange 2003 only)
- Mailbox Manager settings (remember mailbox manager is configure through Recipient Policy, but is enabled on the server settings).
- Journaling settings
- Permissions set at the server of store level
- Also check any login scripts or other processes to ensure that nothing is pointing at the old server for Outlook profile creation.
Run the Exchange Best Practises Tool!
After installing Exchange and making the settings changes that you need, you should download and run the Exchange best practises tool. A link to the latest version is on our Exchange resources site at http://exbpa.com/ . This will point out settings that you may need to adjust to ensure that the server is configured for optimum performance.
Populating the New Server with Data
Configure Public and System Folder Replication
Before moving users you should configure the public folder data to replicate. This not only includes public folders but also system folders. If possible use the Exchange 2003 ESM (Exchange System Manager) as this is a little more advanced. When you open ESM on the Exchange 2003 system make sure you are looking at the original server by Right clicking on Public Folders and choosing “Connect to” and selecting the original server.
Configure the public folders on the replication tab in ESM so that both servers are listed. Use the Propagate settings where appropriate to send the replication setting to the sub folders.
If you have a large number of folders then you may want to look at the “pfmigrate.wsf” tool. More information on this script can be found here: http://support.microsoft.com/kb/822895
However be careful with this script or setting large numbers of folders to replicate. That could generate high levels of traffic on your network and slow down the performance of your existing Exchange server.
You also need to replicate some of the system folders. To access the system folder list, right click in Folders in ESM and choose View System Folders.
The folders that you need to replicate are:
- Offline Address Book (OAB) – don’t forget the sub folders
- Schedule + Free Busy
- Organization Forms (EFORMS Registry)
You don’t have to worry about any other system folders as they are unique to each server.
- Before moving any mailboxes you need to ensure that replication is complete. The replication status is notorious for not always showing that it is “In Sync” or for “In Sync” to show when the folders are not. Therefore do not rely on that status to confirm the content has replicated. Use ESM to verify that the number of items is the same on both servers using the “Status” tab. If you are using Exchange 2003 ESM, then selecting another folder will leave ESM on the “Status” tab making it quick and easy to scan lots of folders for the numbers.
However note that it is not unusual for the item count to be 100% identical, as corrupt items and other orphaned data can be dropped. Use your judgement. A folder with only 10 items in it should have the same number of items in it. A folder with 10,000 items in the source and 9,987 in the destination may reasonably considered to be in sync.
- If you are carrying out a Exchange 2003 to Exchange 2003 migration then you can use the “Send Hierarchy” and “Send content now” commands to speed things up. This can thrash the network, so do it at a quiet time.
- Be careful with antivirus applications that scan SMTP traffic. Unlike mailbox moves, the public folder content is sent over SMTP, and it isn’t uncommon for antivirus applications to quarantine the entire message due to its size (usually around 4mb) and content. Monitor any quarantine alerts to ensure that nothing from or to email addresses IS- is being quarantined in error.
- Message tracking is good for monitoring the replications status as the traffic stands out. You will need message tracking enabled on both servers to ensure that it is being delivered correctly to the store.
Note: Public Folders with Exchange 2000 as the source
Public folder replication where Exchange 2000 is the source is very slow and there is very little that can be done to make it go any quicker. If you are migrating from Exchange 2000 then allow as long as you can for public folder replication – at least a week, preferably more. However, once you have everything on to Exchange 2003, things move much faster. Therefore if you were planning to swing using an interim server, make the interim server Exchange 2003. It should then be possible to complete the move from the interim server back to the (now upgraded) production server in a weekend.
Once you have the public and system folder data on both servers, you can start to think about moving the mailboxes.
With careful planning this can be done with no disruption to the users. Perhaps doing it out of hours using remote control tools like remote desktop or terminal services.
There are two ways to call the move mailbox wizard.
- Active Directory Users and Computers. Right click on the User and choose Exchange Tasks. Select “Move Mailbox” from the choice.
- Using ESM on Exchange 2003, go down to Servers, , , Mailbox Store, Mailboxes. Right click on each mailbox and choose Exchange Tasks and then select “Move Mailbox”.
Use the latest ESM that you can – so if you are migrating from Exchange 2000 to Exchange 2003 use ESM on the Exchange 2003 server.
The second option is probably more efficient as it allows you to select mailboxes that are still on the server and it is quite easy to keep track of which mailboxes have been moved.
You can do multiple mailboxes at a time – the number will depend on the performance of the system and your network connection.
If you are using Exchange 2003 SP1 or higher then you can select all the mailboxes at once, run the Move Mailbox wizard and Exchange will then move a maximum of four at a time. This means that you can setup the process and leave it to get on with it. If there are any errors it will skip on to the next one. You can then look back later on and see which have an error.
You can also do each mailbox individually. While this can be more time consuming, it does allow you to easily achieve five or six mailboxes being moved at the same time.
- Set off the largest mailboxes at the same time, then leave the server to get on with it. When complete it shows a summary to confirm the move was successful. You can then do something else while it moves the largest mailboxes.
- You should always “eat your own dog food” and ensure that the first mailbox moved is your own. If you don’t have the confidence to store your own email on the server, then why inflict it on the users.
- Don’t forget that moving mailboxes generates a lot of transaction logs. Watch where you are storing your transaction logs and ensure that it doesn’t run out of space.
If you have a Blackberry server, then stop the Blackberry services before moving the BESADMIN account. Then move the BESADMIN mailbox in the usual way. However the Blackberry server may not update correctly to point to the new location. Use the profile tool to update the location of the mailbox with the new server name.
Don’t forget to set the permissions for the BESADMIN account before you move any mailboxes.
Additional Mailboxes Considerations
If you have additional mailboxes open in Outlook clients, then special consideration needs to be made to those.
Outlook will not update the location of additional mailboxes automatically. Therefore if you move the location of the primary mailbox to a different server, or you move the additional mailbox to a different server and do not move the primary mailbox, you will find that the additional mailbox may not open. In most cases if both the primary mailbox and the additional mailbox are moved at the same time, then Outlook will continue to open the additional mailbox correctly.
You need to remove the additional mailbox from the Outlook configuration, then add it back in again. Outlook will then find the mailbox in its current location.
There are a number of services that need to be moved to the server.
Moving Inbound SMTP
Exchange is quite capable of routing inbound SMTP messages to the correct server if they are delivered to the wrong one initially. This means that you don’t need to worry about having the messages delivered directly to your new server until you are ready.
Making the switch is as simple as reconfiguring the firewall to send inbound SMTP (port 25) traffic to the new server. No DNS or MX records need to be changed. This modification can be made at any point during the migration.
- TIP: Change the SMTP firewall configuration when over half the mailboxes have been moved. If Exchange is spending more of its time sending email to the other server than it keeps for its own mailboxes then it isn’t working as efficiently as it can.
If you are running a very tight firewall and restrict outbound traffic (always a good idea) then ensure that port 25 from your new server is allowed out.
The one other thing you should do is adjust what the server announces itself as to the outside world.
For example, if your server is known internally as mailserver.domain.local but the internet knows it as mail.domain.com then you need to ensure that it announces itself as mail.domain.com:
- Open the Properties of the “Default SMTP Virtual Server” (ESM, Servers, , Protocols, SMTP).
- Click on the tab marked “Delivery” and then the button “Advanced”.
- Enter the internet name (mail.domain.com) in the box marked “FQDN”.
- Apply/OK out.
Outlook Web Access (OWA), RPC over HTTPS, Exchange ActiveSync
Unlike SMTP the port mapping for the HTTP ports should be moved after the mailboxes have all been moved. However do take in to account the co-existence period as outlined above.
Once the data has been moved across you should reconfigure your backups as required.
Backups are also important for flushing the transaction logs. Moving mailboxes will generate a large number of logs which are only flushed by a backup. Watch your disk space and do a backup as soon as you can.
- NOTE: If you have to run both servers with mailboxes for a number of days, you need to ensure that both servers are backed up. If you don’t have the licences for your backup software, or the hardware needs to be relocated, use NTBACKUP on the new server and configure it to backup to a file.
For speed, configure it to backup to a local file, then use a batch script file to copy to the other server. Finally configure the other server to pickup that file as part of its file level backup.
Remember to leave enough time to ensure that the backup finishes on the new server before attempting to copy the file across or backing it up to tape.
Moving Unique Services
There are a number of services and configuration settings that can only be held by one server. These will need to be moved to the new server before the old one is shutdown.
Moving Recipient Update Services (RUS)
Recipient update services is the component of Exchange that adds email addresses to the user accounts and adjust others settings for the recipients.
RUS can only run on one server, which will be the old server at present. This needs to be moved to the new server and is a simple change.
- ESM, Recipients, Recipient Update Services.
- On the right you should see a number of entries. Right click on each one in turn and choose Properties.
- In the middle is an entry “Exchange Server”. Click the “Browse” button next to it.
- Enter the name of the new Exchange server and press “Check names”. Once it has found the new server press OK.
- Click Apply/OK to make the new setting stick.
- Repeat for other entries.
Changing the Routing Group Master
Another setting that can only be on one server and is easy to move is the “Routing Group Master”.
- ESM, Admin Groups, Routing Groups, Members.
- Right click on the new server and choose “Set as Master”.
If you unclear about the routing group server roles, then you may want to review this KB article: http://support.microsoft.com/kb/239556
Remove Old Server from Public and System Folder Replication
Once the public and system folders are fully replicated, and all mailboxes have been moved, you can remove the old server from the replication list. Simply repeat the processes used above to add the new server to the public and system folder replication in order to remove the old server from the replication list. Each folder needs to have at least one server listed in its replication – the new server.
Remove Old Server
To remove the old server correctly, use Add/Remove programs. Select the Exchange server from the list and choose Remove. If you get errors during the removal then you will have the opportunity to fix them.
Never just shutdown the old server and wipe the machine. Active Directory and the Exchange environment will still think the server exists and this could cause problems later on.
Q: I want to keep the same server name so that I don’t have to visit all of the clients to change the Exchange server setting.
A: No need. As long as both servers are running when the users connect for the first time then their Outlook will update automatically. No user intervention required. The key thing is that both servers must be available with Exchange installed and running when the users connect for the first time.
Q: I want to keep the same server name because some users will not connect to Exchange for weeks after I have removed the original server.
A: If you will have clients that are still hard configured to use the old machine name, then you need to get the new machine to adopt the identity of the old one, using a NETBIOS Alias and DNS changes. NETBIOS Alias Information.
Q: I cannot get the item count on some public folders to be the same, I have waited for replication to complete. The count is 1538 on one server and 1575 on the other.
A: That is actually close enough to consider in sync. You need to take in account corrupted items and deleted item retention (which are not replicated).
In many cases, if you use an account on the old server to view the public folders and and then a account on the new server, you will find the same folder count on both servers.
Q: When I try to remove the old Exchange server I get an error about mailboxes being on the machine:
“One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disable before uninstalling this server”
I am sure that I have moved all of the mailboxes, but how can I check?
A: You probably have hidden or unused mailboxes. Separate instructions for finding those are here.
Well that worked well!