Transitioning from 2003 Active Directory to 2008 R2

Finally, you got the green light for upgrading your Active Directory environment from 2003 to 2008 R2. As you might know the upgrade process is simple, if those domain controllers are 64 bit, because you can do an in-place upgrade. I talked about in-place upgrade of a domain controller here. Unfortunately the process is very different if your domain controllers are 32 bit. First because you need extra hardware; second, that hardware needs to support Windows 2008 R2; and third, you need play with some Active Directory advanced settings.

In this guide I am going to show you how to transition from a 2003 Active Directory to a 2008 R2 Active Directory. After the transition is complete and all FSMO (Flexible Single  Master Operations) roles are moved and working, we are going to decommission the old (2003) domain controller. More about FSMO roles on the way. Like I said, a separate server is needed, on which Windows Server 2008 R2 is already running.

Now put your Windows 2008 R2 installation media into the DVD drive of the domain controller, because we need to prepare the forest and the domain to support 2008 R2. If you have autorun enabled on the server and the compatibility message pops-up just ignore it and click OK, since we are not trying to do an in-place upgrade. Open a terminal and change the path to your support\adprerp directory located on the DVD, and type the following command:

adprep32 /forestprep

Hit c then ENTER on your keyboard to start extending the schema.

Now that our forest is prepared we need to take care of the domain too, by issuing the following command:

adprep32 /domainprep /gpprep

Yep… I forgot to raise the domain functional level, so I got an error when trying to prepare the domain.

Go to Administrative Tools and open Active Directory Domains and Trusts. Right click the domain name and choose Raise domain functional level. Select the domain functional level in the drop-down-box, click the Raise button, then OK twice. Be careful with this, because if you raise the domain level to high and still have old 2000, NT domain controllers in your domain they will became unavailable.

Now let’s try the command again. This time it worked, and the domain was prepared successfully.

There is an optional command if you plan to install RODC’s in your domain.

adprep32 /rodcprep

 

After we took care of the forest and domain, the next step is to promote the Windows 2008 R2 server as an additional domain controller in this domain. I have a post on how to promote a server as an additional domain controller, and you can find it here. Read it, then come back. We now need to move the FSMO roles, but first I want to talk a little about them. There are five FSMO roles that a domain controller can have; two of them are forest wide (the Schema Master and Domain Naming Master), and the rest of them (Infrastructure Master, PDC emulator, RID Master) are present in every domain in the forest.

Schema Master – controls updates and modifications to the schema. Once the schema is modified or updated, it will replicate to all domain controllers in the forest. As the best example of schema modification is Exchange, if you are familiar with the product. Before you install Exchange you need to extend the schema, and once is extended new tabs will appear on every user account, besides other things. There can be only one schema master in the whole forest.

Domain Naming Master – controls the addition and removal of domains in the forest. There can be only one domain naming master in the whole forest.

Infrastructure Master – when multiple domain exists in your forest, this role takes care of objects that reference objects in other domains. For example you can have a group in one domain that includes users from another domain. If members of that group are moved or renamed, the Infrastructure Master’s job is to identify those changes and update the group membership. The Infrastructure Master role needs to run on a domain controller that is not a Global Catalog (GC), or it will stop updating object information, since the Global Catalog server holds a partial replica of every object in the forest. Another way to eliminate this issue is to make all domain controllers a GC.  There is an Infrastructure Master in every domain and is held by only one domain controller in that domain.

PDC Emulator –  or Primary Domain Controller Emulator is a domain role that performs critical functions of a domain, like:

Password changes – when a user password is reset or changed, those changes are immediately replicated to the PDC emulator.

Backward compatibility – it gives a chance to those people who are still using Windows NT 4.0, to be able to locate a writable domain controller, since the domain controller that holds the PDC emulator registers itself as a PDC and performs all of the functionality that a Windows NT 4.0 Server performs for Windows NT 4.0 based clients.

Group Policy Objects –  every time you open for editing a GPO, is alway done from the SYSVOL folder of a PDC emulator. This is to avoid situations where two administrators might edit the same GPO at the same time on different domain controllers. Without a PDC emulator the two GPO versions could not be reconciled.

Time synchronization –  every PDC emulator in each domain synchronizes its time with the forest root PDC emulator so critical service like Active Directory,  DFS-R, File Replication Service (FRS) function correctly.

Master Browser – acts as a domain master browser for the domain, and when clients browse the Windows Network, a list of computers, domain and servers will appear in that list.

There is a PDC emulator in every domain and is held by only one domain controller in that domain.

RID Master –  or Relative ID (RID) Master is responsible for processing RID pool requests from domain controllers for security principals like users, groups and computers. The RID Master allocates a pool of RIDs to domain controllers, then those domain controllers generate SIDs by assigning a unique RID to the domain SID. The SID of every security principal must be unique. There is a RID Master in every domain and is held by only one domain controller in that domain.

Now that you know the purpose of each FSMO role is time to move them to our new 2008 R2 domain controller. First we need to move the Schema Master, so open a Run command on the 2008 R2 server and type:

regsvr32 schmmgmt.dll

and hit OK, then OK again on the pop-up message.

Open a mmc using the Run command again,

and from the File menu choose Add/Remove Snap-in. From the left side, select Active Directory Schema then click Add and OK.

Right click Active Directory Schema and choose Change Active Directory Domain Controller.

From the list select our additional domain controller, which is the 2008 R2 server, then click OK.

On the message box that pops-up click OK. It appears because we are no longer connected to the Schema Master, since the 2008 R2 server is not holding this role, yet.

Now right-click Active Directory Schema and choose Operations Master.

On the Change Schema Master window you can see the current holder of the schema, which is our 2003 domain controller, and the targeted server selected for schema transfer, which is our additional domain controller. To change the schema holder just click the Change button, and YES on the warning message.

If everything went well a confirmation message will be displayed.

Now the holder of the schema is our 2008 R2 domain controller. You can close the window and the management console.

If you like, you can use the command line to transfer the schema. Press ENTER after every command.

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer schema master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

The next step is to transfer the Domain Naming Master. For that go to Start > Administrative Tools > Active Directory Domains and Trusts. Right click Active Directory Domains and Trusts and choose Change Active Directory Domain Controller.

Select the 2008 R2 server from the list and click OK.

Right click again Active Directory Domains and Trusts and choose Operations Master.

On the Operations Master window click the Change button to transfer the role to the our 2008 R2 domain controller. On the warning message just hit OK, because we are sure that we want to move the role.

If the operation was successful a message will be displayed.

Back to the Operations Master window you can now see the holder of the Domain Naming Master role, which is the 2008 R2 domain controller.

From a command line is like this:

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer naming master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

The next step is to move the domain roles, and this is done from Active Directory Users and Computers console. Here right-click Active Directory Users and Computers and choose Change Domain Controller.

From the list select the 2008 R2 domain controller and click OK.

Now right-click your domain and choose Operations Master.

On the Operations Master window you can see the holder of the domain roles for this domain.

         

Here on the RID tab, click the Change button to start transferring the role to our 2008 R2 domain controller. Repeat the operation for the other two roles.

         

And from a command line:

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer rid master
transfer pdc
transfer infrastructure master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

Before we start decommissioning our 2003 domain controller, I recommend you wait a while for the replication to finish between domain controllers. I can’t tell you how long because it depends on you replication topology between sites (if you have sites), so be careful before you decommission your old domain controller(s). You can check or troubleshoot replication using replmon and repadmin. If everything is all right, and replication took place is time to demote our 2003 domain controller. I have a post on how to remove a domain controller from a domain, and you can find it here. After the removal is successful there a couple of things that need to be done:

Remove the IP address of the 2003 server (former domain controller) from the DNS box on the new domain controller (2008 R2). This is only if you don’t want that server to act as a DNS server in your domain, like in this case.

Sometimes the records of the demoted domain controller(s) are not deleted from DNS, so you will have to do that manually. Expand every sub folder in your _msdcs. zone and delete those orphan records. Do the same for your domain zone too.

If you don’t have any 2003 domain controllers in your domain, or you don’t plan to ever add them in the future, you are ready to raise the domain and forest functional level.