Microsoft

Documenting your network prior to an upgrade from Windows NT to Windows Server 2003

Migrating from Windows NT to Windows Server 2003 is a huge task. Thoroughly documenting your network before you begin is a critical step that can make the migration much easier.


Migrating your network servers from Windows NT to Windows Server 2003 can be a pretty complicated process, especially if you aren’t used to the Active Directory environment. If you're considering making the upgrade, it's absolutely imperative that you document your network thoroughly prior to the upgrade. There are a lot of differences between Windows NT and Windows Server 2003, and your documentation will help you to set up your new network to resemble the structure of your Windows NT network. Here are some of the things you need to consider documenting prior to the upgrade.

Hardware inventory
In the first part of the process, the hardware inventory, your goal is to make sure that all of your servers have the necessary hardware to run Windows Server 2003. This step is critical because Windows Server 2003 has more demanding hardware requirements than Windows NT does. You might not even be able to install, much less run, Windows Server 2003 on a server that has no trouble running Windows NT.

For example, I have an old Windows NT server that I keep around for writing NT-related articles. That server is a Pentium 133 with a 1-GB hard disk and 32 MB of RAM. The server does a great job of running NT, but there’s no way that this box could run Windows Server 2003 without a major hardware upgrade.

The hardware requirements for Windows Server 2003 vary widely, depending on the version you select. The absolute minimum hardware for installing Windows Server 2003 Standard Edition is a Pentium 133 with 128 MB of RAM and 1.5 GB of available hard disk space. You can find the detailed hardware requirements for the various versions at Microsoft's Windows Server 2003 Web site.

Keep in mind that the minimums listed are barely adequate for installing the server software. They are inadequate for actually doing anything with the server. To achieve any sort of decent performance, you'll need more powerful hardware than what’s listed.

Let’s assume for a moment that all of your hardware is up to date and is capable of running Windows 2003 in an efficient manner. There's still another reason for documenting all of your hardware: to compare it against the Hardware Compatibility List (HCL) prior to upgrading. Unless a component is on the HCL, Microsoft makes no guarantee that it will work with Windows Server 2003.

In reality, if a piece of hardware is supported by Windows NT, it’s probably going to be supported by Windows Server 2003 as well. Furthermore, just about any hardware you buy these days comes with drivers that will allow it to run under Windows 2003. The truth is that the HCL isn’t really as important as it used to be. I know a lot of people who have installed hardware into Windows XP machines (XP uses an NT-based kernel) and never even knew that the HCL existed—yet the machine worked perfectly. Although you can usually get away with ignoring the HCL, it just isn’t a good idea to take chances with mission-critical servers. Therefore, I recommend verifying the hardware compatibility for all of your servers.

Perhaps the most important reason for documenting your server hardware is that you need to know not only how much free disk space the machine has, but also how much disk space is available on each partition. When Windows NT was initially released, Microsoft recommended creating a 2-GB partition for Windows NT. Remember that it takes a minimum of 1.8 GB to install Windows Server 2003. So if your system partition is 2 GB in size and half of the partition is already consumed by Windows NT, the partition will be inadequate.

It's important to check the partition sizes and disk space available prior to the upgrade to avoid these serious problems. You may find yourself having to use a partition management utility to resize some partitions, or you might even have to format the server’s hard disk and start from scratch.

Domain structure
Verifying that your servers have adequate hardware is only the beginning of the documentation process. It's also very important to document your organization’s domain structure. Remember that the ways a Windows NT domain and a Windows Server 2003 domain work are as different as night and day. It is essential to your organization’s security that you have a firm understanding of your current domain structure.

The first step in documenting your organization’s domains is to make a list of which servers belong to which domains. As you create this list, you should also note which server in each domain is the PDC and which are BDCs.

Next, you should perform a thorough security audit of each domain. You need to know who has administrative permissions over the domain, who has accounts within the domain, and finally, who has access to which resources.

Once you have compiled this basic user and server information, you need to check to find out what kinds of trust relationships exist between local domains, and between local domains and external domains.

Documenting the domains is important because of the way the Windows Server 2003 domain structure works. In Windows NT, a domain was an entirely self-contained entity. A domain might have a trust relationship with another domain, but aside from that, the domain had no formal ties to any other domains or organizational structures.

In Windows Server 2003, however, each domain is a member of a forest. Typically, Windows Server 2003 networks are designed in a way that allows the forest to span the entire company, and all of the various domains are members of the company-wide forest.

The implication of such a structure is that all domains within the forest trust each other—and that's why it’s especially important to know who has administrative access within each domain. Since every domain in the forest trusts the users from every other domain, if you had a domain with a non-trustworthy administrator, it could cause some serious problems. The best way to deal with a situation like that is either to replace the administrator with someone who is trustworthy or to place that domain into its own forest.

If you place a domain into an independent forest, then the administrator of the isolated forest can establish a trust relationship with domains in your main forest. However, there are some safety devices in place that keep things from getting out of hand. First, creating a trust between forests is similar to creating a trust in Windows NT. The trust can be one-way or two-way, but a two-way trust requires both administrators to do something. There’s no way for a rogue administrator to create a two-way trust without your permission.

A second safety mechanism is that trusts between forests are created at the domain level, not at the forest level, and are nontransitive. For example, suppose that your main forests contained domains A, B, and C. Now suppose that domain D was in an isolated forest. You could create a trust between domain D and domain C. However, even though this trust exists, there is no trust relationship between domain D and domains A and B. In this arrangement, domains A, B, and C all still trust each other, though, because they are members of a common forest.

TCP/IP
You should also document each server’s TCP/IP configuration before you upgrade. When Windows NT was initially released, Microsoft’s primary method for associating host names (NetBIOS names) with IP addresses was by using a WINS server. Although you can use WINS with Windows Server 2003, the Active Directory is completely dependent on DNS. Every Windows Server 2003 domain controller must have its TCP/IP configuration set up in a way that points it to an Active Directory-aware DNS server.

If you don’t have a DNS server, you can have Windows Server 2003 create one for you during the installation of your first domain controller. Just keep in mind that doing so will place an additional burden on the server.

Choose your most significant domain
During the documentation process, you should have already made notes of which servers belong to which domains. As you look over this list, you need to take note of which domain you have the most control over. For example, there might be a couple of domains that you administer and a few domains that are administered by other people. You'll want to choose a domain that you administer as your most significant domain. It should also be reliable (don’t use a test domain) and secure.

You'll want to pick one of your domains because of the way that the Active Directory works. As I said earlier, all of the domains within an organization usually fall into a single forest. There are certain domain forest-related housekeeping tasks that Windows has to perform on a regular basis to keep the forest functional. Likewise, there are certain tasks that have to be performed at the domain level. These tasks are known as server roles.

Space doesn’t permit me to get into a full-blown discussion of server roles, but I want to at least make you aware of their existence and importance. As you might know, the Active Directory is basically a big database that is accessed through LDAP queries. Like many other types of databases, the Active Directory database has a related schema. The schema is maintained at the forest level by one of the domain controllers. The domain controller that’s responsible for maintaining the schema for the forest is said to have the schema master role.

The duties associated with the schema master role are critically important to the entire forest, and should not be performed by an unreliable or insecure server. There are a few other forest-level server roles that are also critically important.

You can change which server performs the various server roles, but by default the forest-level server roles are assigned to the first Windows 2000 or Windows 2003 domain controller that’s created within a forest. To someone who is upgrading from Windows NT, this means that the first domain controller you upgrade (or do a clean install on) will hold these critically important server roles. Therefore, it’s a good idea to use the documentation that you're compiling to determine which domain controller should be the first to be upgraded.

There are also server roles assigned at the domain level. These roles service only the domain that the domain controller belongs to. The first domain controller in each domain is assigned these roles by default, although the roles can be moved to another domain controller in a domain. Since the first domain controller within a forest is indeed a domain controller, this server holds both forest-level roles and domain-level roles. Now you can see why it’s so important to choose this machine carefully.

Application servers
In preparing for the upgrade, you should also list the applications each server is running and add it to your network documentation. The reason for this is that not all server applications will run under Windows Server 2003. If you have an incompatible application, you may have to move or upgrade the application prior to the server upgrade. (You can find a list of supported applications on Microsoft's Windows Server 2003 Supported Application Web site.)

The server application software issue can be a bit tricky. For example, this past weekend, I decided that the time had come to upgrade my main file and print server from Windows 2000 to Windows 2003. I started the upgrade and received a notification that the upgrade couldn’t be completed because the server was running Exchange 2000, and Exchange 2000 won’t run on Windows Server 2003.

I decided to upgrade Exchange and then upgrade Windows. However, my CD contained Exchange 2003 Standard Edition. Since my server was running Exchange 2000 Enterprise Edition, I couldn’t upgrade to Exchange 2003 with what I had, and therefore couldn't upgrade to Windows 2003 either. As this illustrates, server application upgrade issues can be tricky and expensive to deal with. Taking the time to properly document your software ahead of time and to investigate the compatibility of that software may save you a lot of heartache later on.

After the upgrade
So far I’ve talked a lot about the importance of documenting your network before an upgrade to Windows Server 2003, but it’s also important to update your documentation after the upgrade is complete. Normally, if you create thorough network documentation in the first place, the updated documentation pretty much writes itself as you plan the upgrade. However, real-world experience has shown me that things don’t always go according to plan. There will probably be small parts of the upgrade that differ from your plan. Be sure to make note of these differences and add them to your documentation.

It's crucial to have an accurate set of network documentation after the upgrade because Windows Server 2003 is very different from Windows NT. It's almost inevitable that some things won't work the way that you expected them to. Whether you're trying to track down these gremlins yourself or are working with Microsoft product support, an accurate set of documentation will greatly speed up the resolution process.

Editor's Picks