Migrating to Active Directory in Windows Server 2003 (part 1) - Moving from Windows NT Domains

9/24/2012 1:12:38 AM
A primary reason businesses are purchasing Windows Server 2003 is to move away from other, older operating systems. In this section, I will look at moving to Active Directory from Windows NT and Windows 2000, including steps on planning, actually moving, and then keeping your systems running smoothly.

1. Moving from Windows NT Domains

A lot of companies are finding themselves jumping the sinking Windows NT ship and considering an upgrade to the latest server product from Microsoft, Windows Server 2003. After all, the end-of-life date for the NT Workstation product was in mid-2003 and NT Server's death is fast approaching as well, so it's very possible that your organizations have some machines running NT that are worth upgrading.

Microsoft released Windows Server 2003 in late April 2003, and since then the product has matured via various updates and out-of-band releases into a server product that is more stable, reliable, and secure than any previous version of Windows. It is usually not until after the first service pack of a new Microsoft operating system ships that companies really start looking to upgrade existing systems, and Service Pack 1 for Windows Server 2003 shipped in mid-2005. So, this would be an excellent time to consider upgrading.

1.1. Items to consider before migrating

If you have an NT domain and haven't investigated Active Directory, the new directory service Microsoft introduced in Windows 2000 Server, there's a lot in store for you. Active Directory is superior to NT-style domains in many ways, not the least of which is easier management. You can divide your directory into specific domains and OUs and manage like 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. Active Directory is more secure for your users and is also the foundation of many newer versions of Microsoft server products, including the new Microsoft Exchange Server 2003.

Moving from NT to Windows Server 2003 and Active Directory requires several steps. First, you'll want to analyze your current NT domain environment. Specifically, you'll need to find answers to these questions:

  • Are you on a single domain, are you on a 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 because the existing domain simply becomes the root of the Active Directory domain. However, if you have a particularly large domain or a network that might be restructured one day, you might 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 off of that root, which 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 because you can create OUs to store specific types of objects within the directory. Multiple masters will want to use the dedicated forest root strategy because even in Active Directory, complex networks still should be broken up by domains 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 more complicated, but they don't have to be difficult. If you have trusts among a multi-master domain model, in that every domain trusts every other domain, you don't have to do anything if you put all these domains into a single forest—all of these trusts between domains are transitive automatically. If you have one-way trusts that you want to preserve for logistical reasons, you'll need to create multiple forests, which can be a headache; make sure this is the route you want to take before taking it. Figure 5-50 shows some sample trust relationships in Active Directory and how they fit together.

  • How many PDCs and BDCs do you have, and where are they located—all at one location, or at separate sites? In Active Directory, the notion of the PDC and BDC has gone away (with a couple of minor exceptions). Plus, Windows Server 2003 is more robust than 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 Active Directory's 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, which you can define within Active Directory, this will affect 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.

  • If you have DNS deployed internally, what namespaces are you using and how are they assigned? You'll want to catalog all these internal domain namespaces and decide how they will "map" into your new Active Directory structure. Particularly of note are how you want DNS subdomains (for example, to map to actual Active Directory domains in a forest and if you want 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 someone experienced in DNS planning to assist you in your migration efforts.

  • Do you have any NT 4.0 servers that are running the Routing and Remote Access Service (RRAS) or the LAN Manager Replication Service? The NT RAS machines, 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 an 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 between the different operating system versions. Also, if you have only one domain controller in your domain, you need to upgrade your RAS server before beginning any domain controller upgrades. Plus, the LAN Manager Replication Service is incompatible with the new File Replication Service found in Active Directory, so disable that as well.

  • Do you have any machines running versions of NT earlier than 4.0? You really need to simply rid yourself of these machines, as they're just not compatible with Windows Server 2003 or an Active Directory environment.

Figure 1. How trust relationships can be created and used within Active Directory

1.2. Migration strategies

Of course, any migration process is risky because 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 NT domains to Windows Server 2003 and Active Directory will go smoothly.

First, you'll want to make sure that your BDC and PDC are up to date for all NT domains you're touching with the migration. If the PDC fails to upgrade for some reason, the BDC can be promoted to PDC and nothing is lost but some time. If you have two BDCs, the best strategy is to leave one online during the migration, so users more or less don't notice that 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 2 shows this procedure.

Figure 2. Taking a synchronized BDC offline as a failure recovery strategy

Also, 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 redo any changes you made in that period.

Take some time to look specifically at the PDC for each domain and figure out if it's sufficiently powerful. When I said earlier that there are virtually no distinctions between domain controllers nowadays, I also said there were a couple of exceptions: the first domain controller upgraded into Active Directory will take on some roles that others don't have that 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 NT 4.0 and Service Pack 6 and configure it as a BDC. Promote it to a PDC and put it on the network for a bit to let the changes settle out and to let replication finish, and then take it offline and upgrade the machine to Windows Server 2003. This is the strategy closest to a clean install and usually gives you the best results. If you have more than one domain, do this for each domain. (Do 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 before upgrading any PDCs.)

1.3. Performing the move

It's remarkably easy to upgrade any type of Windows NT installation, whether a PDC, BDC, or regular member server, to Windows Server 2003. Microsoft has taken great pains to ensure 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 inception of the installation; little to no reconfiguration is required with an upgrade installation because existing users, settings, groups, rights, and permissions are saved and applied automatically during the upgrade process. You also don't need to remove files or reinstall applications with an operating system version upgrade. So, at the beginning, you're asked for only the CD Key and to acknowledge any compatibility issues, and then sometime later the upgrade is complete.

There are, however, a few points of which to take note:

Service pack levels

The Windows NT installation must be running Service Pack 5 or higher. You can download the most recent update, Service Pack 6a, from:

Other acceptable Windows NT versions include NT Terminal Server Edition with SP5 or later, and NT Server Enterprise Edition, also with SP5 or later.

Evaluating immediate Setup issues

On a machine 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 with issues that the Setup program detects might cause problems with an upgrade to Windows Server 2003. A sample report is shown in Figure 5-52.

Also, regarding storage, you might want to examine the following disk issues before upgrading.

Partition sizes

On machines upgrading from NT to Windows Server 2003, ensure that there is plenty of disk space on the system partition of each machine. This is especially true of domain controllers because converting a 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.


Domain controllers require that their system partitions be formatted with the NTFS filesystem. Although as a general procedure I recommend formatting all partitions on all server machines 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 NT on a system with volume, mirror, or stripe sets (including stripe sets with parity) that were created under NT requires some modifications of those sets. Because Windows Server 2003 includes new dynamic disk technologies, support for older enhanced disk features has been removed—and 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 replicate your existing disk configuration using native Windows Server 2003 tools and restore any data required from the backups.

Figure 3. Using the Check Upgrade function of Windows Server 2003's setup to look for issues to correct

1.4. Moving domains to Active Directory

The upgrade procedure for an NT domain is relatively straightforward. Initially you must choose the first server to upgrade in your Windows NT domain. As you upgrade different machines, depending on their existing role in the domain, features and capabilities become available with Windows Server 2003 on the upgraded machine. In particular, upgrading an NT PDC enables all the included Active Directory features, as well as the other capabilities inherent in any Windows Server 2003 server, such as improved RRAS 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 NT domain controllers to Windows Server 2003, you must upgrade the PDC before any other domain controller machines.

Here's a checklist of some steps to take immediately prior to your move to ensure that your NT-to-Server-2003 migration goes smoothly:

  • Make sure that all PDCs and BDCs are running Windows NT 4.0 with at least Service Pack 5, or better, Server Pack 6a.

  • 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 so on. Take this opportunity to eliminate excess baggage from your directories before moving these objects into Active Directory.

  • Remove any unused software via 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—sometimes upward of 10 times the size of the SAM database for an NT domain—and contiguous free areas of the disk can speed Active Directory query response time.

  • Kill any trusts between domains that you don't want preserved over the migration.

By default, domain controllers in Windows Server 2003 digitally sign network communications and verify the authenticity of parties to a transaction, which 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 domain controllers by default require all clients to digitally sign their SMB communications. The SMB protocol allows Windows systems to share files and printers, and enables various remote administration functions, as well as logon 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, 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 GPO that applies to the OU where the domain controllers are located. You certainly can turn this feature back on when the affected computers have been upgraded.

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. Windows NT 4.0 machines prior to Service Pack 4 are not capable of signing or encrypting secure channel communications. If 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 domain controller machines, the secure channel signing requirement needs to be removed. This is also in the domain controllers' security policy, under the GPO setting titled "Digitally encrypt or sign secure channel data."

  •  Smali Form Factor Cases (Part 3) - Silverstone TJ08-E
  •  Smali Form Factor Cases (Part 2) - Cubitek Mini Ice, In-Win BL641
  •  SmallForm Factor Cases (Part 1) - Akasa Crypto Vesa, Cooler Master Elite 120
  •  Portable Drive: WD My Passport Studio 2TB
  •  Linux Mint 13 - One Of The Best Linux Distros Around
  •  File and Disk Recover And Restore (Part 2) - PC Tools File Recover, Piriform Recuva, Ubuntu Rescue Remix
  •  File and Disk Recover And Restore (Part 1) - Binarybiz VirtualLab, Brian Kato Restoration, CGsecurity TestDisk and PhotoRec, Genie9 Timeline Pro 2012, O&O DiskRecovery 7
  •  Windows 7 : How to Use Built-In Diagnostics
  •  Windows 7 : Developing Migration Files, Using USMT in Microsoft Deployment Toolkit
  •  Windows Server 2003 : Using Backup - Planning for Failure, Handling Backup and Restore Problems, Third-Party Backup Utilities
    Most View
    BlackBerry Bold 9700 and 9650 Series : Connecting with Bluetooth (part 2) - Answering and Making Calls with the Headset, Bluetooth Setup Menu Commands
    How To Get More From AirPlay (Part 1)
    Web Security : Attacking AJAX - Subverting AJAX with Injected XML, Subverting AJAX with Injected JSON
    TP-Link SafeStream TL-ER6120
    Some Of The Biggest Brands In The World Had Their Products (Part 8) - Sennheiser HD700, Focal Spirit One, TDK TH-EC250
    Super-zoom Superstars – Q1 2013 (Part 1) : Canon PowerShot 5X50 HS, Fujifilm HS3OEXR, Olympus SP – 820UZ
    We Help You Find Your Ideal Smartphone (Part 1)
    Generation I (For Insecure)?
    Windows Server 2008 R2 Powershell Cmdlets (part 5) - Server Manager cmdlets
    New Smartphone Range From Kazam
    Top 10
    Sharepoint 2010 : InfoPath Forms Services - InfoPath Overview (part 5) - Using InfoPath Forms in SharePoint - Creating Document Information Panels
    Sharepoint 2010 : InfoPath Forms Services - InfoPath Overview (part 4) - Using InfoPath Forms in SharePoint - Adding Formulae to Fields, Publishing a Form Template to SharePoint
    Sharepoint 2010 : InfoPath Forms Services - InfoPath Overview (part 3) - Using InfoPath Forms in SharePoint - Creating Form Templates
    Sharepoint 2010 : InfoPath Forms Services - InfoPath Overview (part 2) - BrowserForm Web Part
    Sharepoint 2010 : InfoPath Forms Services - InfoPath Overview (part 1)
    Mercedes-Benz B180 CDI Edition 1 – Bells And Whistles
    The Mercedes-Benz A180 CDI Edition 1 – Classier A
    2015 BMW M3 & 2015 BMW M4 - Return Of The King (Part 3)
    2015 BMW M3 & 2015 BMW M4 - Return Of The King (Part 2)
    2015 BMW M3 & 2015 BMW M4 - Return Of The King (Part 1)