SolutionBase: Upgrade from Exchange 5.5 on NT 4.0 to Exchange 2003 on Windows Server 2003

You can't do a direct, in-place upgrade from Exchange 5.5 on Windows NT 4.0 to Exchange 2003 on Windows Server 2003, but the upgrade can still be accomplished, as this article demonstrates.

I'm not only going to assist network administrators in the upgrading from Exchange 5.5 on Windows NT 4.0 to Exchange Server 2003 on Windows Server 2003, but I'm also going to help point out some issues that need to be addressed before that process is initiated. I will briefly explore NT4 domains and how they are different from Active Directory domains. I will explore what makes Exchange Server such a crucial part of the Active Directory installation, and how that affects the IT staff involved. And, finally I will share some Internet resources that can help in this process.

Understanding domain structure
Let’s start with a comparison of the Windows NT domain structure versus the Active Directory domain structure. Windows NT domains are not hierarchical, and therefore are not compliant with DNS. Without WINS (a Microsoft/IBM invention), NT4 networks have no system of name resolution. WINS is not compliant with DNS, but it will work in partnership with a DNS server.

When Microsoft turned out Windows 2000, the new Active Directory domain structure was fully integrated with DNS, and even included a cutting-edge DNS technology called dynamic DNS (DDNS). Windows 2003 has taken this further and provided an even more functional version of Active Directory. Almost all of the irritations we lived with in Windows 2000 have been addressed in Windows Server 2003. Plus, some very valuable management tools, such as Software Update Service and Group Policy Management Console, have been added. So there are now plenty of good reasons to upgrade from NT4 (especially since Microsoft says it will stop supporting it at the end of 2004), as long as the following has been planned for:
  • Hardware compatibility of servers
  • Staff training on Active Directory
  • Staff training on Exchange Server 2003 (and its integration with AD)
  • How current user accounts will be migrated to Active Directory (see below)
  • How many Active Directory domains to deploy

Starting the Exchange migration
Now we can look at the other big issue in our upgrade, which is how Exchange Server works. Exchange Server 5.5 has directory services built into it. That is a good thing, because it means that Exchange Server uses the Lightweight Directory Access Protocol (LDAP), which Active Directory also uses. So, before you break open your Exchange Server 2003 compact disk, you might want to understand how Microsoft has engineered “upgrades” of Exchange Server.

Exchange Server 2000 does not use directory services, because it was built to be completely reliant on an Active Directory domain. Likewise, Exchange Server 2003 can only be installed into an Active Directory domain. Although, there is, theoretically an upgrade path from Exchange Server 5.5 to 2003, it is not recommended because it is such a messy process, with many obstacles. The good news is that Exchange Server 2003 and 5.5 can coexist in an Active Directory domain. That not only provides redundancy, it provides a bit of fault tolerance during the upgrade process.

In the example in Table A, I started out with an NT4 Primary Domain Controller (PDC), an NT4 Backup Domain Controller (BDC), and a Windows 2000 member server that ran Exchange Server 5.5. To upgrade to Exchange 2003 with the least risk of loss of user accounts, I chose to start by installing two new Windows Server 2003 domain controllers (NewDC1 and NewDC2) and then joined the Windows 2000 member server to the new domain.

Table A
"OldDomain" (with 3 servers) "" (with 3 servers)
NT4PDC NT4PDC -- retired
NT4BDC NT4BDC -- retired
2KExchange55 (member server) 2KExchange55 (member server)

Steps to perform
Install NewDC1
  1. Install NT4 as BDC in OldDomain and apply Service Pack 6. The NIC and hardware must support NT4 and WS2K3.
  2. Make NewDC1 a WINS client of 2KExchange55.
  3. Promote NewDC1 to PDC.
  4. Upgrade to Windows Server 2003. This will lead directly into DCPROMO, where you choose to create a new domain called
  5. Apply service packs. Don’t forget to plan for network connectivity.
  6. Make sure OldDomain Exchange 5.5 user accounts made it into Active Directory Users And Computers on the new domain controller.
  7. Run CSVDE and export all Active Directory users in to an Excel file (this provides some fault tolerance).
  8. Set up a DNS server on NewDC1 with the primary zone as The primary reverse lookup zone will be for your subnet.

Install NewDC2
  1. Install Windows Server 2003 Server and service packs.
  2. Run DCPromo and make NewDC2 an additional domain controller to the existing domain
  3. Make it a WINS client to 2KExchange55.
  4. Set up a DNS server on NewDC2 with zones as secondaries to NewDC1.

Make changes on 2KExchange55
  1. Point to NewDC1 or 2 for DNS resolution.
  2. Find the user account that is the highest in Exchange Server 5.5 Admin role.

Integrate NewDC1 with Exchange
  1. Put the Exchange 5.5 Admin user into’s Domain Admins group, Enterprise Admins group, and Schema Admins Group.
  2. Install Active Directory Connector from your Exchange 2003 Server disk.
  3. Create a connection agreement from 2KExchange55.
  4. Run the Active Directory Connector.
  5. Check in Active Directory Users And Computers to make sure that users now have Exchange tabs on their account property sheets.

Retire NT4PDC
Turn it off.

Retire NT4BDC
Turn it off.

Install Exchange 2003 on NewDC1
  1. Raise domain functional level in AD Users And Computers to Native Windows 2000 (you don’t have to do this, but it is recommended).
  2. Install IIS 6.0, including NNTP, SMTP, and ASP.NET (Exchange Server 2003 requires all of these).
  3. Install Exchange Server 2003, using first screen of “autorun.” Choose the Exchange Deployment Tools link. This method takes you through a checklist of all of the steps to get your server ready for Exchange Server 2003. During this process you will choose to have your server installed in Co-existence With Mixed Mode, and you will run Forest Prep, Domain Prep, ADC Setup, and ADC Tools (via AD Connector management console).

Test it
Now you can test your Exchange servers by sending some mail between Outlook clients within your domain (there are some additional issues involved in implementing Exchange Server 2003 with Outlook 2000 versus Outlook 2003, but that's beyond the scope of this article).

Bring in a new DC
Once you are sure the Exchange servers are functioning, you can bring in one more member server to, and install Active Directory on it. Then, go to NewDC1 and re-run DCPROMO (which is really an uninstallation of Active Directory, in this case) so that Exchange Server 2003 is not living on a domain controller anymore. This is a best practice measure. Another best practice is that you will want to look at how you can lock down IIS on the Exchange Server 2003 without losing any mail functionality.

At this point you can also retire the Exchange 5.5 server, in most cases. Whether you continue to use the Exchange 5.5 server will depend on several factors, including whether your antivirus software upgrades will continue to support it.

Training issues
Just be warned that there is a large learning curve in moving to Exchange 2003 on Windows Server 2003 from Exchange 5.5 and Windows NT 4.0. Of course, an administrator also needs to deeply understand Active Directory in order to be able to fully manage Exchange 2003. I believe this upgrade will force many administrators to go outside of the organization for some professional training if they want to be able to use the many features of Exchange 2003 and monitor and administer it effectively.

End sum
I believe this plan is a safe and relatively-easy way to make the upgrade from NT4 to Active Directory and then upgrade Exchange from version 5.5 to 2003. Directly upgrading from Exchange 5.5 to 2003 is not supported (or recommended) by Microsoft. However, the solution outlined here is also more controlled and has better fault tolerance than a direct in-place upgrade. Nevertheless, you should still stage this in a testing environment before doing it on your production servers.

Additional resources
For more information, check out these relevant white papers from Microsoft. Here are some additional white papers from other sources that may also help: