Microsoft Exchange and Blackberry Server Specialists

Migration from Exchange 2003 to Exchange 2010

On This Page

  • Introduction
  • Guide Presumptions
  • Pre-Migration Checks
  • Consultancy
  • Stage 1 - Get the data and tasks off Exchange 2003
  • Stage 2 - Redirect SMTP Traffic
  • Stage 3 - Drop the Public Folder and Mailbox Stores
  • Stage 4 - Disable Mailbox Management
  • Stage 5 - Removing Exchange 2003 Completely
  • Stage 6 - Tidying up the Domain
  • Stage 7 - Post Upgrade Steps
  • Introduction

    Migration from Exchange 2003 to 2010 is a pretty straight forward process, as long as you remember the key rules:

    • Check at every step
    • Take your time

    Guide Suitability

    • 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.
      If you have Outlook 2007 or higher deployed, then autodiscover can also assist with this process.

    Guide Presumptions

    This guide presumes the following:

    • You have installed Exchange 2010 already, which has been tested and shown to work correctly, and are migrating to another server in the same Exchange organisation (ie the same domain and/or forest).
    • You are NOT using an Edge server, or other appliance.
    • That OWA, Outlook Anywhere (RPC over HTTPS) and ActiveSync traffic is already going through the new server.

    Pre-Migration Checks

    • 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.

    Consultancy

    If you are in the UK and feel unsure on carrying out this process, then Sembee Ltd can assist you with Exchange consultancy from the author of this article. Please contact us through our main business web site. This approach can often be quicker and more cost effective than attempting the process yourself.

    Stage 1 - Get the data and tasks off Exchange 2003

    Before you can remove Exchange 2003, you need to get the data off Exchange 2003. As with an Exchange 2003 to 2003 swing migration, this means replicating the public folders, then moving the mailboxes, finally removing the public folders from the old server.

    1. Replicate the public folders from Exchange 2003 to Exchange 2010.
      In the guides from Microsoft on migration, some of them say to use the Move All Replicas commands and scripts. However if you are having a co-existence period, this isn't really suitable as it MOVES the data from Exchange 2003 to Exchange 2010. This will cause problems for clients connected to Exchange 2003.
      Instead, use the AddReplicaToPFRecursive.ps1 script which you will find in the Scripts directory of the Exchange installation. You will need to run it from an Exchange Management Shell session as you have to run some options.
       

      Where E2010 is the name of your Exchange 2010 server.

      Note: If you have a very large number of public folders, then this method can cause a high amount of traffic to go across. To manage the process, use the Manage Settings wizard which is on the right click menu of the public folder in Exchange 2003 ESM to add the Exchange 2010 server to the top level of part of the tree, then the same wizard to propagate the settings down.
      For individual folders, simply add the Exchange 2010 server and public folder mailbox to the list of replicas.

      When it comes to checking the public folder content has fully replicated, only item count is reliable.
      Compare the output of get-publicfolderstatistics on the new server with the list of public folders in ESM under Server, Public Folder Store, Public Folders.
      A small difference is not unusual as corrupt items will not be replicated.
      It can take some time, hours if not days is not unusual.
      Once all of the public folders are replicated across, then you can consider moving mailboxes.
       

    2. Move mailboxes to Exchange 2010.
      Of course the first mailbox that is moved is your own. To move the mailbox, use Exchange Management Console on the Exchange 2010 server. Test and verify that you are able to mail between yourself and other users on the Exchange 2003 server.
      You can then select the mailboxes in bulk to move them to the new server. The move mailbox process will only move four at any one time, but will move on to the next one automatically. However if you are using multiple databases then you will need to move the users on a per database basis.
      Note - once over half of the users have been moved, you can consider completing stage 2 below - redirecting SMTP traffic. It doesn't make sense to have most of the email traffic the Exchange 2003 server receives simply passed on to the Exchange 2010 server.
      If you haven't configured an RPC CAS Array, then do so before you move any mailboxes. It could save you a lot of headaches if you introduce a second server later.
       
    3. Change the Offline Address Book generation server.
      Only one server in the Exchange org generates the Offline Address Book. This will need to be changed to the Exchange 2010 server.
      In ESM, open Recipients, Offline Address Book. In the right pane you will see the Offline Address Lists shown. Right click and choose Properties. Where it says "Offline Address List server", right click and choose Browse. Enter the name of your Exchange 2010 server, then check names. Once it is underlined, click ok.
      Wait about 30 minutes for that change to fully replicate, then on the Exchange 2010 server, force it to generate the OAB. This ensures everything is working correctly.
      To force the regeneration, in the Exchange Management Shell, run:
       

      Again wait for a little while (it varies depending on the size of your Exchange org) and check the event viewer for OAB generation errors.
       

    4. Remove the Public Folder content from Exchange 2003.
      With all users moved off Exchange 2003, you can now remove the Public Folder content.
      There are three ways to do this, and you may want to use one or both of them.
      Method 1 is to remove the Exchange 2003 server from the list of replicas on each folder or tree individually. This can be done using the Manage Settings wizard in ESM. A little slow, but allows complete control, and if some folders have replicated and others have not completed, allows you to remove the ones that have replicated and have only the incomplete ones listed.
      Method 2 is to use the RemoveReplicaFromPFRecursive.ps1 script. This basically does the same as above, but in a more automated manner.
      Method 3 is to use the Move All Replicas command in Exchange 2003. This will be required at some point because it allows you to move some system folders.

      After starting this process, keep track on how it is doing through ESM, Public Folder Store, Public Folder instances. You have to wait for that to be empty before you can move on.
       
    5. At this point Microsoft recommend that you can drop the public folder store. This can cause problems and therefore should be dropped later in the process after the SMTP traffic has been redirected.

    Stage 2 - Redirect SMTP Traffic

    There are two parts to SMTP traffic, inbound and outbound.

    For inbound traffic, simply change the NAT on your firewall to direct port 25 traffic to the new server. Ensure that the Default Receive Connector has anonymous enabled on it. Change NOTHING on the Exchange 2003 server. More information on the Receive Connector.

    For outbound traffic, create a new Send Connector. This will be identical to your SMTP connector that you have already on Exchange 2003. Instructions on creating the Send Connector are here. If you have multiple SMTP connectors, then create additional Send Connectors, replacing like for like.
    Then delete the SMTP connectors from Exchange 2003 ESM. All traffic will then go out through the Exchange 2010 server.

    Stage 3 - Drop the Public Folder and Mailbox Stores

    Once the SMTP traffic has been redirected, you can drop the public folder and mailbox stores. Do note that once this has been done, the server cannot process SMTP traffic, even from internal resources, so ensure that nothing internal is using the server for email delivery.

    Public Folders

    To be able to drop the public folder store, the list in Public Folder Instances must be empty.

    Right click on the Public Folder Store and choose Delete. If you get a prompt about it being the public folder store for a mailbox store, accept the prompt and choose the Exchange 2010 public folder store.

    Mailbox Store

    As with the Public Folder store, right click and choose Delete. If you get a prompt about a mailbox being on this store which needs to be removed, you probably have a hidden or unused account on it. For information on finding these, click here.

    Stage 4 - Disable Mailbox Management

    Disabling Mailbox Management is easy to miss, but can cause a problem when you attempt to update the Email Address Policies in Exchange 2010.
    In ESM, open Recipients, Recipient Policy. Right click on each one and choose Change Properties Pages. Deselect Mailbox Management. If you have any Recipient Policies that are used for Mailbox Management Exclusively (ie they don't control email addresses has no "E-mail Addresses (Policy)" tab) then those should be deleted. They can be recreated in Exchange 2007 with a Managed Folder Mailbox Policy.

    Stage 5 - Removing Exchange 2003 Completely

    Until you reach this point, the Exchange 2003 server could still be used. From this point on, you are now removing Exchange 2003.
    Therefore you need to ensure that the server is not being used for anything - such as service accounts, or having SMTP traffic from internal resources routing through it.

    1. Remove the routing group connectors.
      The routing group connectors provide the link between the Exchange 2003 and Exchange 2007 platforms.
      To remove them, run the remove-routinggroupconnector command in an Exchange 2007 management shell. To remove the connectors in one hit, use the following command:

       
       
    2. Move the Public Folder Hierarchy to the Exchange 2010 Server.
      This step is required if you want public folders to continue to work if you remove the original Exchange 2003 admin group. However removing the Exchange 2003 admin group is not a required step and does not affect the operation of the server. However as this step is almost impossible to complete with Exchange 2010 tools, to ensure that problems do not occur in the future this change should be made before the removal of Exchange 2003 when it is quick and easy.
      1. Open ESM, Admin Groups. (If you do not see Admin Groups, right click on the Exchange org and the top of the tree, choose Properties and select to View Admin groups, then restart ESM).
      2. Right click on the "Exchange Administrative Group (FYDIBOHF23SPDLT)" and select New then select Public Folders Container.
      3. Open the 2003 admin group that has the current public folder tree, then open Folders so you see "Public Folders" and probably the tree below it. Drag "Public Folders" to Folders under the Exchange 2010 admin group.
        No other tasks should be done on the Exchange 2010 admin group through ESM.
         
    3. Remove the Domain Recipient Update Services
      The domain recipient update services need to be removed as they are not required by Exchange 2010.
      Open ESM, Recipient Update Services. Right click on each domain policy and choose Delete. You will be unable to delete the Enterprise update service, which has to be removed by using adsiedit.
       
    4. Remove the Enterprise Update Services.
      This step requires using adsiedit, which can be quite dangerous to use, as it is the core of your domain. Therefore only touch the section that is listed and nothing else.
      Adsiedit is part of the Support Tools which can be installed from the Windows 2003 CD. In this command, example.local is the name of the WINDOWS domain, and therefore you should see your own domain listed.
      1. Run adsiedit.msc and go to Configuration, "CN=Configuration, CN=example, DC=local", then "CN=Services", "CN=Microsoft Exchange".
        Open "CN=Example Exchange Organisation", then "CN=Address Lists Container" and then select CN=Recipient Update Services.
      2. In the right pane, you should see only one result listed, "Recipient Update Service (Enterprise Configuration)". Right click on it and choose Delete, and then click Yes to confirm the deletion.
      3. Close adsiedit.msc
         
    5. Update the Email Policies to the Exchange 2010 version.
      On the Exchange 2010 server, you should now update the Email Policies to the new Exchange 2010 version. This allows you to manage them through the Exchange Management Console. To do this, run the following command:

      Adjust the name of the policy to match any others that you might have.
      DO THIS BEFORE REMOVING REMOVING EXCHANGE 2003 - then if you have missed the step above about disabling the Mailbox Management setting you can go back and correct it.
       

    6. Remove Exchange 2003
      You are now ready to remove Exchange 2003 itself. Before you do so, remove anything that is using Exchange. This could include Antivirus, Antispam, disclaimer tools, backup agent and other third party plugins. These could have hooks which could stop the Exchange uninstall process from running correctly.
      The uninstaller process requires the original Exchange 2003 CD, so you will need to have that to hand, or a copy of the installation files somewhere that you can point the uninstaller to.
      Choose Exchange 2003 from add/remove programs and select Change. Then on each part, choose Uninstall. If it will not let you, it should give you a prompt for a reason why. Correct whatever the prompt is about.
       
    7. Remove Global Catalog functionality (Domain Controllers only)
      If the server was also a domain controller and is going to be removed, then once the Exchange 2003 uninstall has been completed, use Active Directory Sites and Services to remove the global catalog functionality from the server. Then immediately restart the Exchange System Attendant Service on the Exchange 2010 server.
      When Exchange is installed on a domain controller it will only use that DC for domain functionality. That applies to other Exchange servers in the Org as well. Exchange will also only use a GC/DC. Therefore taking the GC role from the server and restarting the services forces the new server to find and use another DC.

    Stage 6 - Tidying up the Domain

    There are a couple of additional things that you can do to tidy the domain up.

    1. Removing Permissions that are not required.
      The WriteDACL inherited permission for Exchange 2003 Enterprise Servers allows the Exchange 2003 Servers permissions for certain tasks in the domain, which are not required by Exchange 2007 and could be abused.
      To remove these permissions, run the following command:

      Where example.local is the FQDN of the domain, and EXAMPLE is the netbios name of the domain.
       

    2. Remove the legacy groups.
      There are two groups that are used by Exchange 2003, which are not used by Exchange 2010. As long as these groups aren't used by anything else (so have no members, or the members are SIDs (random numbers)) then they can be removed. The two groups are:
      • Exchange Domain Servers
      • Exchange Enterprise Servers
         
    3. Assisting clients haven't redirected
      If you have to remove Exchange 2003 before you are sure that all Outlook clients have connected once and been redirected to the new server, then you can assist them in finding their way to the new server.
      Once the server has been removed completed, and dropped from the domain, configure its previous DNS entry to point to the new server, and setup a NETBIOS alias so that the old server name also applies to the new server.

    Stage 7 - Post Upgrade Steps

    Once you have removed the legacy servers you can upgrade your distribution groups to the Exchange 2010 format. This allows management with Exchange 2010 tools.

    Use this command to upgrade them all: