Migrating a server operating system is somewhat trickier than installing an update or patch to run-of-the-mill software. This article is the second part of our multi-part series focusing on the migration to Windows Server 2008. The first part covered the preliminary basics and glanced at the business factors and other considerations that it implied. This part will focus on performing the actual migration.
Per the previous article, we are assuming the following: we already have a primary domain controller that manages all of the FSMO roles, and even has other server roles like DHCP and DNS. This server is running Windows Server 2000/2003 and we want to upgrade it to Windows Server 2008. We want the new server to take over its server roles.
We can do this by installing the new server running Windows Server 2008 individually and transfer each of the roles one by one, configure the services, and promoting the server into the position of primary domain controller, while simultaneously demoting the already-existing Windows Server 2000/2003 to the status of backup domain controller (BDC/RODC). This is a wise choice, because we will still have our old server that can act as a back up.
But we can also upgrade the old server running Windows Server 2000/2003 to the new operating system. This means that the old server is going to be technically replaced by the new Windows Server 2008. In this case, the IP address and host name remain the same. And the old server must be demoted and removed from the domain.
In the first segment we covered the necessary considerations regarding the staging process and discussed the virtual lab (virtualization). Along with these recommendations, the first route is highly advised. Why? Because if the migration fails, then you can promote the old server once again, re-transfer the FSMO roles, and it's going to be lock and loaded-up and running just like it was before. This is much safer.
Now let's cover the actual technical aspects of how to accomplish the entire migration.
The most important consideration is that the steps of the migration must be accomplished in a somewhat strict order. There is a general step-by-step guide to the entire process that should be followed. First of all, the already-existing Active Directory® (AD) forest schema must be prepared ("adprep /forestprep") for the introduction of a new Domain Controller running on Windows Server 2008.
Once this is done, the next step is to prepare the infrastructure master of the domain ("adprep /domainprep"). This prepares the domain for the introduction of a new domain controller. These commands should be run as administrators under the server that holds the FSMO roles (flexible single master operations). If there is more than one domain, then don't forget to run the latter command on each of them. Think about it like this: each one of them must be prepared individually. From this perspective, it all makes sense.
A few pointers regarding these commands: the first one must be run under a user that is part of the Schema Admins and Enterprise Admins, while the latter needs the administrator user to be a member of the Domain Admins group. Not meeting these requirements will result in an error due to not having the necessary credentials.
The first forest preparation is going to take a while...be patient. However, the second domain preparation is much faster-almost instantaneous. We should also point out that if your current domain controller isn't running on native mode (i.e.; mixed), then fire up your "AD Domains and Trusts" MMC snap-in and raise the domain functional level to native (such as Windows Server 2000 native, Windows Server 2003, etc.).
Technically, after performing these two preliminary steps, the forest schema and the domain(s) are prepared for Windows Server 2008. This means that you just need to join this new server into the domain(s). For the sake of simplicity, we'll assume that we're working only with one domain. Now that you have joined the server to the domain you need to promote it up to Domain Controller (DC).
The next step is transferring the DNS records. Fortunately, all of the DNS zones data and server configuration files are fully compatible from Windows Server 2003 to Windows Server 2008. This simplifies the process. All that's left to do is create secondary zones on your new Server 2008 for all of your existing zones. But to do this on Windows Server 2008, it must have installed the role of DNS.
After all of the DNS records are transferred to Windows Server 2008 (meaning the zone transfers are finished), then you need to convert these secondary zones to primary ones. Ideally, you should integrate them into Active Directory Domain Services (AD DS). These are called AD-integrated DNS zones. But you can only do this if the DNS service runs on the same server that is a Domain Controller (DC).
Optionally, if you are planning to continue running the existing primary masters as DNS servers, then just convert the DNS zones to secondary zones on those servers. Now this step sums up the migration of DNS role; it's time to move on.
Transferring FSMO roles is what we are going to do next. This is very important; before we demote your already-existing domain controller running Windows Server 2000/2003, we need to transfer the FSMO roles to the new Windows Server 2008. When we talk about FSMO roles we refer to the Schema Master, Domain Naming Master, Infrastructure Master, RID (Relative ID) Master, and PDC Emulator.
There are various ways to transfer these roles, either by using the Ntdsutil.exe command-line utility or the built-in MMC snap-ins. We usually recommend that nifty Ntdsutil tool because it is a bit more advanced and gives detailed error messages (logs to work with). The snap-in method is explained in the official Microsoft documentation. The documentation applies to Server 2008 because the process is almost identical.
If you are following the command line, then this paragraph should aid you in the process. As a side note, you can always type "?" for a list of possible commands. First, just run the Ntdsutil.exe. Once it's up and running, type "roles." After that, type "connections." Now you need to connect to the server; to do this, type: "connect to server name_goes_here." Of course, replace that latter field with the respective host.
It should appear that the utility have established a successful connection to the server. Now you are required to type "q" to quit from the connections menu, since you want to work on the previous menu (which was roles, as you may recall). Now you are in the roles menu; type "?" to see the available commands for further information.
In order to transfer all of the FSMO roles, you need to execute the following:
Transfer domain naming master
Transfer infrastructure master
Transfer pdc
Transfer rid master
Transfer schema master
During the process, carefully follow the messages. If there are any errors, chances are that they are related to not having necessary credentials and/or permissions. You should run the Ntdsutil as an Administrator. Also remember, running the command "Adprep /forestprep" already required the Admin user to be member of the Enterprise Admins and Schema Admins, while the "Adprep /domainprep" required Domain Admin.
For further information regarding FSMO roles and how to use Ntdsutil, please read the official documentation. Now we are going to move on. Windows Server 2008 only supports domain functional levels that are either Windows Server 2003 (native) or above, as mentioned earlier when we discussed Adprep. This means that if there are other DCs in the domain running Windows NT or 2000, you should demote them.
Once they are demoted to member servers, the overall functional level of the domain can be raised to meet the requirements (at least Windows Server 2003). Once this step is also done, you can join the domain with the new Windows Server 2008. The FSMO roles are going to be managed by the new server, including the DNS roles. Everything should work fine after a full server restart (or just Netlogon service restart).
But we aren't done yet. You should set the IP address and host name of the new server to your needs. If it is going to replace the old domain controller, then ideally it should receive the same name and IP address; in this case, disjoin the existing domain controller, since you can't have duplicate servers under the same host name and IP. If it's going to work along with it, then just call it differently and set another IP.
Before we finish this article we are going to also set up and migrate the DHCP service onto Windows Server 2008. This process has actually become much easier than it was back in the days of Windows Server 2003. To begin, start up the DHCP Management snap-in (or run "dhcpmgmt.msc"). This should be run from the source/old server where the DHCP is still active and configured.
Once the snap-in launches, right-click on the server's name, and select Backup from the pane. You need to specify the destination path. Copy the backed-up file onto Windows Server 2008. Verify that the DHCP service role is set up; if not, you must specify this need, and let the system install itself. Once you are sure that the new server is capable of DHCP service, launch the DHCP management snap-in again.
This time you are executing it from the destination/new server. Select its name, right-click on it, and select Restore. Specify the path and watch as the entries are imported. The DHCP service must be restarted to take over the job and become fully functional. Don't forget to uninstall any DHCP service(s) running on any other server(s) that may have any conflicting scope.
As you can see, we've already reached the end of this article. Hopefully by now you have a fully functional primary domain controller running on Windows Server 2008 that is able to manage all of the FSMO roles along with DNS and DHCP services. If you have run into some issues and can't find your way out then don't hesitate to ask for help.
While technically we have finished this series, new articles are going to be published as sequels here on ASP Free. In our next segment we'll set up WSUS 3.0.
As mentioned at the end of the previous article, you are free to join our helpful forums at DevHardware Forums. We've a strong base of resident professionals, enthusiasts, and tech experts. If you want to hear opinions on some service or ask some clarifications regarding some details just shoot us your questions. We'll do our best to help. And you may also want to pay a visit to the forums of our sister sites, DevShed and ASPFree.
The Importance of a Domain
