Breathe New Life Into Your Server! From Windows NT To Windows Server 2003
At a Glance:
- Developing a Windows NT to Windows Server 2003 migration plan
- How Active Directory compares with domains in Windows NT
- Averting problems with the migration
Windows Server 2003
A lot of companies that currently use Windows NT are now considering an upgrade to the latest server product from Microsoft, Windows Server 2003.
After all, Windows NT 4.0 support expired in December 2004 (with the exception of extended support contracts), making this an excellent time to consider upgrading (for more info, see Retiring Windows NT Server 4.0: Changes in Product Availability and Support).
Things to Consider Before Migrating
If you currently have a Windows NT® domain and haven't yet investigated Active Directory® (the directory service that Microsoft first introduced in Windows® 2000 Server) then there's a lot in store for you. Active Directory is superior to Windows NT-style domains in a number of ways, not the least of which is easier management. You can divide your directory into specific domains and organizational units and manage similar sets of objects with ease. Active Directory is more robust and fits better into more distributed environments, particularly in organizations with branch offices in multiple locations. It is also more secure for your users and is the foundation of many newer versions of Microsoft server products, including Microsoft® Exchange Server 2003.
There are several different steps in moving from Windows NT to Windows Server 2003™ and Active Directory. First, you'll want to analyze your current Windows NT domain environment. Are you on a single domain or multiple domain model, with accounts and computers located in each domain, or do you have a single master or multi-master domain model, with separate domains each for user accounts and machine resources?
The single domain model is the easiest to upgrade, since the existing domain simply becomes the root of the Active Directory forest. However, if you have a particularly large domain or a network that might be restructured one day, then you may want to consider a dedicated forest root model (sometimes called an empty root), in which you create a root domain within a forest and then create child domains from that root. This allows you to change domains in the forest without scrapping your entire Active Directory structure. If you have a single master domain and child domains containing machines, you really don't need to continue that structure upon moving to Active Directory, since you can create organizational units to store specific types of objects within the directory. Multiple masters will want to use the dedicated forest root strategy, since complex networks should still be broken up by domains, even in Active Directory, for easier management.
What sort of trust relationships have you built up with other domains in your environment? Trust relationships can make moving to Active Directory somewhat more complicated, but they don't have to be difficult. If you have trust relationships among a multi-master domain model, such that every domain trusts every other domain, you need do nothing, as all trusts are created automatically.
If you have one-way trusts that you want to preserve for logistical reasons, then you'll need to create multiple forests, which can be a headache. You should make sure that's the route you'd like to take before embarking on it. Figure 1 shows some sample trust relationships in Active Directory and how they fit together.
Figure 1 Trust Relationships within Active Directory
How many Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs) do you have, and where are they located? All at one location or at separate sites? In Active Directory, there are really no distinctions between PDCs and BDCs (with a couple of minor exceptions). In addition, Windows Server 2003 is more robust than Windows NT 4.0, so you can likely consolidate multiple domain controllers at a single location into a smaller number, depending on their load. Your main concern with domain controllers is their location.
Part of the Active Directory technology is a replication algorithm that sends updated contents of the directory to all domain controllers within the forest, even at different sites. If you have offices in different locations with slow links, you can define these within Active Directory, allowing it to control your replication speed and how quickly those users at the remote offices can get authenticated and receive access to domain or forest resources. You'll want to look at how these locations will play into where you allocate domain controllers. Figure 2 shows how sites and replication works within a sample company's Active Directory structure.
Figure 2 Active Directory Structure
If you have DNS deployed internally, what namespaces are you using and how are they assigned? You'll want to catalog all of these internal domain namespaces and decide how they will "map" into your new Active Directory structure. Of particular importance are how you may want DNS subdomains (for example, corp.acme.com) to map to actual Active Directory domains in a forest and if you'd like to have external DNS services separated from internal DNS services. Of course, DNS is a major component of Active Directory and entire books are written about planning and using DNS in Active Directory environments, so be sure to read up on best practices, or bring in someone experienced in DNS planning to assist you in your migration efforts.
Do you have any Windows NT 4.0 servers that are running the Routing and Remote Access Service (RRAS) or the LAN Manager Replication Service? Computers running Windows NT RAS, be they domain controllers or just ordinary member servers, really don't integrate well within an Active Directory environment. If you have a member server functioning as a RAS machine, you should upgrade it to Windows Server 2003 before the last domain controller is upgraded. The RAS machine has certain security requirements that are incompatible with the different operating system versions. This also means that if you only have one DC in your domain, you need to upgrade your RAS server before beginning any DC upgrades. Also, the LAN Manager Replication Service is incompatible with the new File Replication Service found in Active Directory, so disable that as well. However, you should note that disabling the service means that there will be no further replication to LAN Manager servers. This is fine if the files being replicated are static and will not change during migration, but clearly it's not fine if those files are changing. Therefore, all files replicated by the LAN Manager Replication Service must be static and not subject to change once the service has been disabled.
Do you have any servers that are running versions of Windows NT earlier than 4.0? If you do, unfortunately, you need to bite the bullet and simply rid yourself of these servers, as they're not compatible with either Windows Server 2003 or an Active Directory environment.
By its nature, any migration process is risky, since your environment is changing. In this section, I'll take a look at some prudent strategies to mitigate that risk and ensure that the entire move from Windows NT domains to Windows Server 2003 and Active Directory goes smoothly.
First, you'll want to make sure that for all Windows NT domains you're touching with the migration, you have both the BDC and PDC up to date. If the PDC for some reason fails to upgrade, then the BDC can be promoted to PDC and nothing is lost but some time. If you have two BDCs, then the best strategy is to leave one online during the migration, so users more or less don't notice anything is going on, and take the other offline during the upgrade. This way, the offline BDC isn't touched by anything happening during the upgrade and can be plugged in should everything go haywire. Figure 3 shows this procedure.
Figure 3 Taking a BDC Offline
Make sure to synchronize your BDCs with their partner PDCs before proceeding. Out-of-date replication partners don't help anything when it comes to restoring service in the event of an outage. In the course of the migration, be sure to keep track of any changes you make after you take your BDCs offline. If your migration fails and you promote your BDC to a PDC, you will lose any changes you made since you took the BDC offline, and you'll need to manually recreate any changes you made in that period.
Take some time to look specifically at the PDC for each domain and decide whether it's sufficiently powerful. When I mentioned earlier that there are virtually no distinctions between domain controllers anymore, there are a couple of exceptions. The first domain controller upgraded into Active Directory will take on some roles that others don't have and will require a bit more operational horsepower.
If you're in doubt as to whether your PDC is powerful enough, a common suggestion is to buy a new machine and load it with Windows NT 4.0 and Service Pack 6 and configure it as a BDC. Then, promote it to a PDC and put it on the network to let the changes settle out and replication finish (usually about 48 hours). Then, take it offline and upgrade the computer to Windows Server 2003. This is the closest strategy to a clean install and usually gives you the best results. If you have more than one domain, do this for each. Note that if you decide to use the dedicated forest root strategy, you'll need to have a native Windows Server 2003 machine with Active Directory and create the forest and root domain first before upgrading any PDCs.
Performing the Move
It's remarkably easy to upgrade any type of Windows NT installation to Windows Server 2003, whether it be a PDC, BDC, or a regular member server. Microsoft has taken great pains to ensure that the upgrade to Windows Server 2003 is as painless as possible. The installation procedure follows a normal clean install of Windows Server 2003 reasonably closely and, in fact, requires less hands-on work. The program doesn't prompt you at all after the installation begins and there is little to no reconfiguration required with an upgrade installation. Existing users, settings, groups, rights, and permissions are saved and automatically applied during the upgrade process. You also don't need to remove files or reinstall applications with an operating system version upgrade. At the beginning, you're only asked for the CD Key and to acknowledge any compatibility issues, and then some time later the upgrade is complete. There are, however, a few points to note.
Service pack levels The Windows NT installation must be running SP5 or greater. The most recent update, SP6a, can be downloaded from Windows NT 4.0 Service Pack 6a. Other acceptable Windows NT versions include Terminal Server Edition with SP5 or later, and Server Enterprise Edition, also with SP5 or later.
Evaluating immediate setup issues On a computer that's a candidate for Windows Server 2003, insert the Windows Server 2003 CD and run winnt32.exe with the checkupgradeonly switch. This will present a report to you with issues that the setup program detects may cause problems with an upgrade to Windows Server 2003.
There are also some storage issues which you should examine before upgrading.
Partition sizes On computers upgrading from Windows NT to Windows Server 2003, ensure there is plenty of disk space on the system partition of each machine. This is especially true of domain controllers, since converting a Security Accounts Manager (SAM) database to an Active Directory database full of the latter's capabilities can increase the size of the SAM by as much as 10 times.
File systems Domain controllers require their system partitions to be formatted with the NTFS file system. While as a general procedure I recommend formatting all partitions on all servers with NTFS, you are not required to do so unless the machine in question is a domain controller.
Volume, mirror, and stripe sets Upgrading to Windows Server 2003 Enterprise Edition from Windows NT on a system with volume, mirror, or stripe sets (including stripe sets with parity) which were created under Windows NT requires some modifications to those sets. Since Windows Server 2003 includes new dynamic disk technologies, support for older enhanced disk features has been removed. This is indeed a change from Windows 2000. You will need to break any mirror sets or, for all other media sets, back up any data on the set, and then delete the set. When setup is complete, you can then replicate your existing disk configuration using native Windows Server 2003 tools and restore any data required from the backups.
Moving Domains to Active Directory
The upgrade procedure for a Windows NT domain is relatively straightforward. You must initially choose the first server to upgrade in your Windows NT domain. As you upgrade different computers, depending on their existing role in the domain, features and capabilities become available with Windows Server 2003 on the upgraded machine. In particular, upgrading a Windows NT PDC enables all the included Active Directory features, as well as the other capabilities inherent in any server running Windows Server 2003, such as improved Routing and Remote Access service features, no matter the role. Note that you can upgrade Windows NT member servers at any time during your migration plan, and most migration plans specify that member servers are last on the list to receive the upgrade. However, no matter your order, when you begin upgrading Windows NT domain controllers to Windows Server 2003, you must upgrade the PDC before any other DC machines.
Here's a checklist of some steps to take immediately prior to your move to ensure that your Windows NT to Windows Server 2003 migration goes smoothly:
- Make sure that all PDCs and BDCs are running Windows NT 4.0 with at least SP5, or better, SP6a.
- Clean up your domain account list for both users and computers. We all know these lists can be cluttered with inactive users, multiple accounts for the same user, and other unnecessary entries. Take this opportunity to eliminate excess baggage from your directories before moving these objects into Active Directory.
- Remove any unused software using its uninstallation facility, and defragment the hard disk to take advantage of any unused space. Active Directory migrations can use a lot of disk space, and contiguous free areas of the disk can increase the speed of Active Directory query response time.
- Kill any trusts between domains that you don't want preserved over the migration process.
DNS on Windows Server 2003 by Cricket Liu, Matt Larson, and Robbie Allen (O'Reilly, 2003), a comprehensive guide to DNS configuration and administration.
Active Directory, 2nd Edition, by Robbie Allen and Alistair G. Lowe-Norris (O'Reilly, 2003), highlights specific DNS requirements and how they pertain to operating in an Active Directory-based environment.
Mastering Windows Server 2003 by Mark Minasi, Christa Anderson, Michele Beveridge, C.A. Callahan, Lisa Justice (Sybex, 2003).
Microsoft Windows Server 2003 Inside Out by William R. Stanek (Microsoft Press, 2004).
Domain controllers in Windows Server 2003 digitally sign network communications and verify the authenticity of parties to a transaction by default. This helps to prevent communications between machines from being hijacked or otherwise interrupted. Certain older operating systems are not capable of meeting these security requirements, at least by default, and as a result are unable to interact with Windows Server 2003 domain controllers. Such operating systems are Windows for Workgroups, Windows 95 machines without the Directory Services client pack, and Windows NT 4.0 machines prior to Service Pack 4. You'll also find that Windows Server 2003 DCs require all clients to digitally sign their server message block (SMB) communications by default. The SMB protocol allows Windows systems to share files and printers, and enables various remote administration functions, as well as login authentication over a network. If your clients are running one of the operating systems mentioned previously, and upgrading them to a later revision is not an option, then you'll need to turn off the digital signing and SMB signing requirements by disabling the "Digitally sign communications" policy in the Default Domain Controller group policy object (GPO) that applies to the Organizational Unit where the domain controllers are. Alternatively, rather than disabling this feature, it can be reconfigured to be preferred but not required. This supports backward compatible clients while preserving security on supported clients.
Additionally, Windows Server 2003 domain controllers similarly require that all secure channel communications be either signed or encrypted. Secure channels are encrypted tunnels of communication through which Windows-based machines interact with other domain members and controllers, as well as among domain controllers that have a trust relationship. Computers running Windows NT 4.0 prior to SP4 are not capable of signing or encrypting secure channel communications. If Windows NT 4.0 machines at a revision earlier than SP4 must participate in a domain, or a domain must trust other domains that contain pre-SP4 DC machines, then the secure channel signing requirement needs to be removed. This is also in the domain controllers' security policy, under the GPO entitled "Digitally encrypt or sign secure channel data."
By using the strategies found in this article and a bit of common sense, you can relax with the knowledge that you likely won't need backups restored or disaster recovery plans activated.
Jonathan Hassell is an author and consultant specializing in Windows administration and security. He is the author of Learning Windows Server 2003 and RADIUS (O'Reilly), and Hardening Windows (Apress). Reach Jonathan at firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.