Upgrading from a Windows NT 4 networking environment requires a substantial amount of assessment and planning. The move from a network environment employing Windows NT domains to a network based upon Active Directory is a major change, and one with farreaching implications. In addition to the technical aspects of shifting from a NetBIOS-based network to one centered on DNS and LDAP, there are administrative issues for IT management, and the business side of the company is sure to have opinions concerning information management.
Although Active Directory might be the most significant change from Windows NT to Windows Server 2003, it is by no means the only one. Many additional services (particularly Internet-related ones) have been added—when Windows NT shipped, after all, the Internet was but a small blip on Microsoft Corporation radar.
Each Windows NT 4 domain is a single flat namespace with no internal or external hierarchy, while Active Directory domains exist within a DNS tree where each domain can map to a domain within the Active Directory tree. A single Windows NT domain can contain users and a few types of resources (such as file servers), and on many small networks, they do. There are significant limits on the number of objects per Windows NT domain—the theoretical limit is 40,000, yet few servers running Windows NT perform well when approaching that limit. Accordingly, many Windows NT 4 networks employ multiple domains linked by trust relationships that are manually configured (sometimes laboriously so) to allow user authentication and access to resources.
Active Directory transcends these Windows NT limitations: a single Active Directory domain can hold millions of users, servers, computers, and many additional kinds of objects—representing a major shift in network management. By providing effectively limitless domains and automatic trusts, Active Directory offers domain structures based on IT functionality, not product limitations.
You have to move your existing domain structure from one to the other—from multiple independent domains linked by explicit trust relationships to a single tree with a domain hierarchy, wherein all domains automatically trust each other.
This is a big change, and it is a good idea to take a step back from your existing domain design when considering what your Active Directory domain tree will look like. Domain design is different in Windows Server 2003; remember, the most common reason for adding an additional Windows NT domain—hitting the maximum number of objects—is no longer an issue. There are benefits to having fewer domains, such as faster searches, fewer domain controllers, simplified management, and a network that is easier to use. Unfortunately, there are also likely to be roadblocks to eliminating domains—politics and inertia, to start with.
Note
For more information about the Active Directory planning process, see Part 7.
You must design the DNS namespace(s) for Active Directory (the domains and domain trees), as well as any additional DNS domains you want to support. Determine which Windows NT domains will be maintained, whether additional domains will be added, and where in the DNS domain tree(s) each of your existing domains will go. When you upgrade each domain's primary domain controller, you must know where in the DNS namespace that specific domain is assigned.
Caution
Support for Windows NT 4 domain controllers is provided in the initial Active Directory configuration, but it is dropped once you switch the domain to Windows Server 2003 functional level. Make sure that you are really finished using Windows NT before making the switch. You can't go back once you make the change.
If you're upgrading domains from Windows NT 4 to Windows Server 2003 on a one-to-one basis, you will initially have multiple (perhaps many) domains. If so, you can collapse multiple domains into a single one to simplify your Active Directory implementation. You can perform the domain restructure operations at two times:
Restructuring domains after upgrading In most circumstances, you will want to upgrade the domain controller and then migrate the user, group, and computer accounts settings to domains in your actual Active Directory forest. This method frees you from the Windows NT 4 limitations and allows you to take advantage of the ADMT as a means of restructuring your domains.
Restructuring domains before upgrading If you have only a few domains to merge, you can restructure your Windows NT 4 domains prior to upgrading to Windows Server 2003. You must keep in mind, however, that all the standard Windows NT 4 limitations apply. This means that if the Security Accounts Manager (SAM) database will get too large or replication traffic will be an issue, you should wait to restructure domains until after you have upgraded the server.
Remember that the domain controllers from a domain that is subsumed go offline, so make sure there are no additional services or applications running on them before making the change.
Note
Windows NT 4 groups are converted for Active Directory
When upgrading Windows NT 4 to Windows Server 2003, local groups are upgraded to domain local groups, and global groups are upgraded to Active Directory global groups. Down-level clients continue to see the upgraded groups as their Windows NT 4 equivalents and will regard universal groups—which don't exist in Windows NT—as global groups.
When you're upgrading servers that run Windows NT 4, you are likely to encounter incompatible or inadequate hardware, so you should give the system hardware and installed software a thorough review. After all, the baseline requirements for Windows NT 4 server hardware are quite a bit lower than for Windows Server 2003, which requires a minimum of a Pentium 133-megahertz (MHz) processor, 128 MB of RAM, and more than 2 GB of disk space.
Another thing to remember is that Windows Server 2003 might not support some of the adapters and devices used in Windows NT 4 systems. As a result, you should expect to upgrade at least some components of the Windows NT 4 server hardware (upgrading the network adapter, for example, or adding a hard disk) to facilitate reasonable performance under Windows Server 2003.
Note
For more information about the compatibility of specific adapters and devices, see the Windows Server Catalog at http://www.microsoft.com/Windows/catalog/server and the Hardware Compatibility List at http://www.microsoft.com/whdc/hcl/search.mspx.
Inside Out: Minimum requirements do not yield optimal results
Technically, Windows Server 2003 will run on a 133-MHz Pentium with 128 MB of RAM. Performance would be far from optimal, however, and it is questionable whether such a server would actually make it into a production environment—or how long it would last if it did.
Consider the size of your network and the expected load on the server, and decide whether each upgraded server will perform adequately in your environment. If not, replace it if possible. Hardware is relatively inexpensive, especially when compared with the long-term costs and inconvenience brought about by using an outdated, inadequate, or unstable system.
The following are additional factors to review:
Disk partitions Assess the disk partitions on the servers you want to upgrade. Certain constraints apply to upgrades; you cannot upgrade servers on a FAT partition, for instance, or those using Windows NT 4 fault-tolerant configurations.
Windows services Consider whether you want to phase out some legacy services, such as WINS. Don't be too hasty, though; by leaving the service installed and running for a while after the upgrade, you can ensure that network operations will continue uninterrupted during the transition away from the old service.
Windows applications Look at your existing applications and assess their functionality and compatibility. Check compatibility issues carefully because there are likely to be issues with each application. Don't rely on just what the vendor has to say—do a bit of additional sleuthing, check out newsgroups (both at the vendor's site and public ones), ask colleagues what they have encountered, and so on.
Tip
No more POSIX or OS/2 support
If you currently have applications that are operating in either the POSIX or OS/2 subsystem in a Windows NT 4 environment, you must replace these applications, because those subsystems are no longer supported. Alternatively, you could leave a server, or a few servers, in place to support the older applications. In either case, this is a decision to make early in the process, so the changeover is completed in plenty of time, and the impact on the network can be managed.