NT4 Domain migration to Win2k AD

We have an Existing NT4 domain structure with 1 PDC, 3 BDC's, 4 x Exchange 5.5 Servers and 5000 user accounts. The existing PDC's and BDC are used for file-sharing but are too old to run Win2k. Out of the existing 4 Exchange servers one which was the original 5.5 installed server is running WinNT4 and is too old for Win2k the other 3 are all running Win2k.
At the moment we are running 1 main NT4 domain to serve the 5000 users on the LAN but have a trusted link into another NT4 domain over a WAN link. After the upgrade we would still need to maintain the trusted link to allow file-sharing both ways between our new 2003 AD and the existing NT4 domain over the WAN. In the future the NT4 domain over the WAN link will be upgraded to it's own Win2000/2003 AD but will still need to maintain file-sharing with our new domain.
We are looking to install Windows 2003 AD onto 3 new servers which will be for AD/DNS/DHCP use only, and install Exchange 2003 onto the Existing 3 Win2k 5.5 servers migrating the existing 5000 NT & E-Mail user accounts over with the least amount of distuption to the users as possible. Can you give us an idea of the process involved and any problems we may encounter.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chris DentPowerShell DeveloperCommented:

I've tried to include a big pile of information - please let me know if you have any questions or anything isn't clear.

The two most popular and well known options for migration are:

1. In-Place Upgrade

Process (very basic overview):

On a new server capable of supporting Windows 2003:

1. Install the Server as an NT BDC
2. Promote the Server to PDC
3. Perform an upgrade to Windows 2003 on that server which will also install Active Directory and upgrade the rest of the domain to 2003.


- Everything on the existing domain is migrated to 2003
- Lowest Administrative Cost for migration


- A single step upgrade like this can be problematic if things go wrong

Once the upgrade is complete your NT BDCs will continue to operate as BDCs, the 2003 Domain must remain in Mixed mode to support this functionality. These BDCs can then be upgraded or decommisioned as time and resources permit.

Some steps can be introduced to help cope with problems including:

Prior to migration add a spare server to the domain as a Windows NT BDC. Once replicated unplug this DC from the domain and put it in a safe place. In the event of domain failure this DC can be brought online, promoted to PDC and used to recover the domain.

2. Domain Migration


1. Install a new Windows 2003 Domain in parallel with your current NT Domain.
2. Set up a Trust between your NT domain and the new 2003 Domain
3. Use the Active Directory Migration Tool to move User Accounts etc to the new domain.
4. Once the move is complete decommision the old NT Domain.


- This gives you a very clean domain, free of any historic configurations of the old domain
- Failure during install is non-fatal as the Domain is entirely seperate


- The Domain Names you use cannot be the same as a Trust is required to use ADMT
- Computer Accounts will have to be manually rejoined to the new domain (either at the machine or using NetDom).

General / Common Issues:

-= DNS =-

Correct DNS configuration is an absolute requirement for Active Directory Domains. DNS stores everything from the normal address records to the Service Records that allow you to locate servers like the Kerberos Servers (Authentication Protocol that replaced NTLM in Windows 200x Domains), LDAP Servers and Global Catalogs.

Because of this your Internal DNS Servers must be the ones used by all of your Internal Clients and Servers.

- External Name Resolution -

Since those Internal Servers are a requirement then you must also ensure that they can resolve External Domain Names. There are two options for this:

Root Hints:

This performs a full lookup for each requested Domain Name that your DNS doesn't know about. It uses the contents of the Root Hints tab (13 root servers) to find directions for the next.

Once an address is known to your DNS it caches the information and responds from the cache until the TTL (Time to Live) for the address expires.

Since this pulls information from many different places your server must have Outbound access on Port 53 to Everything on your Firewall.


This passes requests for unknown names onto a specified server (specified in the DNS Config). This Forwarder then performs the full lookup for you, or responds from it's own cache.

As with using Root Hints addresses obtained from Forwarders are also cached (again based on the TTL).

For Forwarders to function the server you Forward requests to must support Recursive Queries.

This method requires only outbound Port 53 access to the Forwarder you specify.

- Internal Domain Naming -

Be careful when selecting your Domain Name for Active Directory - problems you may get include:

Single Label Domain Name - this can cause all manner of obscure problems and should be avoided. For reference a single label domain name is one without a suffix:

domain  -  This is a single label name
domain.com  -  This a a full domain name

Next, if you run Internal Servers in any form you may get Name Resolution Problems. So selecting the Domain Name isn't quite as easy as ensuring it has a .com suffix.

There are reserved private suffixes such as .local which can be used to ensure your private and public name space are always entirely seperate:


But, if you use NATing on your Network to allow External Access to Public Servers then you may find you are required to add an Internal DNS set for your External Zone to allow them to resolve Internal Addresses for External Names.

-= FSMO Roles and the Global Catalog =-

Each of the FSMO (Flexible Single Master Operation) Roles is in charge of a seperate aspect of your network - these roles are essential to the well-being of your network.

The Microsoft Documentation on these roles is available here:


In such a large environment placement of these roles should be considered. The main consideration is probably that the Infrastructure Master should not be configured as a Global Catalog.

The Global Catalog is responsible for Universal Group Membership - because of this one of these must be available on the Domain for users to log on. You can have as many Global Catalogs as you require.


Domain Migration:


Group Policy:


General Active Directory:






Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Chris DentPowerShell DeveloperCommented:

There's a bit missing from:

Next, if you run Internal Servers in any form you may get Name Resolution Problems. So selecting the Domain Name isn't quite as easy as ensuring it has a .com suffix.

And it should read:

Next, if you run Public Servers in any form on your Internal Network you may get Name Resolution Problems. So selecting the Domain Name isn't quite as easy as ensuring it has a .com suffix.

Sorry about that.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 2000

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.