Upgrading a Windows NT 4.0 domain to Active Directory
isn’t quite the three-click process that you perform when upgrading a
single Windows NT 4.0 workstation to Windows XP. In fact, considerable
planning is necessary before you even start Windows Setup on the first
computer. You must upgrade some computers, such as the PDC and BDCs, in a
specific order, while you can upgrade other computers, such as client
computers and Windows NT member servers, at any time.
The following
sections are essential for anyone planning a Windows NT 4.0 domain
upgrade. They cover documenting an existing network, making a recovery
plan, planning the Active Directory forest, and developing an upgrade
strategy. Subsequent sections cover preparing for the upgrade, the
actual upgrade process, and finally, switching an upgraded domain into
native Windows 2000 or Windows Server 2003 mode.
Note
You must upgrade the
Active Directory schema before adding Windows Server 2003 domain
controllers to an existing Windows 2000 Active Directory forest or
before adding Windows Server 2003 R2 domain controllers to a Windows
Server 2003 or Windows 2000 Active Directory forest.
Choosing Whether to Upgrade or Migrate
If your current
domain structure is unsatisfying, it might be tempting to start from
scratch, migrating accounts and resources into a fresh Active Directory
domain. Resist this impulse if possible.
When migrating to a new
domain, you must select a new domain name (a political nightmare in its
own right), update all existing links and e-mail addresses, and educate
users how to log on and find resources in the new domain. In addition,
it’s important to realize that everyone
needs to sign off on a decision of this magnitude, and that can be
tough. The decision to migrate to a new domain structure is political,
not technical.
With
that said, it makes sense to look at migrating to a new domain or
domain tree if doing so makes it possible to merge two or three separate
domains or trees into a single domain or tree. Just remember to
carefully weigh the pros and cons and get everyone’s approval before
tackling this complex issue. If you choose to migrate to a new domain,
refer to the Active Directory for Microsoft Windows Server 2003 Technical Reference for information about the Active Directory Migration Tool (ADMT) and other tools that can help make migration easier.
Note
An in-place
domain upgrade is a domain upgrade that you perform while leaving the
domain intact. You can also upgrade domains by removing the PDC from the
domain, and upgrading it offline. Meanwhile, the BDCs provide services
to the existing domain. After testing the upgraded PDC, bring it back
into the production domain and upgrade the remaining BDCs.
|
The Active Directory
Migration Tool (ADMT) is a powerful program that you can use to migrate
accounts, groups, trusts, profiles, and passwords from an existing
Windows NT 4.0, Windows 2000, or Windows Server 2003 domain structure to
a new Active Directory forest. This is useful when you want to perform a
major domain restructure while minimizing downtime.
Before you can use ADMT
to migrate to a new Active Directory forest, you must document the
existing domains, trusts, groups, user accounts, service accounts, and
computers: Then you must design and create the new Active Directory
forest and domain trees. Once the new forest is operating properly,
prepare for the migration by performing the following tasks (see the
Active Directory Migration Tool Help system for a complete list):
Enable remote registry access on all computers that you want to migrate. Switch
the functional level of the target domain to Windows 2000 native or
Windows Server 2003 functional level. (The source domain can be a Window
NT 4.0 domain or an Active Directory domain with any functional level.) Create
a temporary two-way trust between the source and target domains. A
two-way trust allows you to use an administrator account from the source
domain, which is more likely to have the proper permissions on the
source objects. At a minimum, the source domain must trust the target
domain. Add a
common administrator account to the local administrators group on every
workstation and member server that you want to migrate. (You can use
Active Directory Service Interfaces [ADSI] scripts to automate this.)
Then use this account in ADMT to migrate these computers. Disconnect any mapped network drives or connections between the source and target domains. Identify
or create a user account for the migration that has administrative
privileges in the source and target domains, as well as Exchange
Administrator privileges if you want to use the Exchange Directory
Migration Wizard.
After preparing the
source and target domains, install ADMT on a domain controller in the
new forest and then use the ADMT wizards to perform the following tasks
(ADMT installs the necessary agents on the source computers if you
created the appropriate trusts and permissions):
Perform a test run
of each migration task, such as migrating user or computer accounts.
ADMT allows you to perform a test migration without modifying the actual
domains. Create migration reports for each migration test run, and analyze the reports for any problems. Fix any problems, and rerun the tests. Perform the migration in stages, and test the results of each migration stage. Use
the Security Translation Wizard to update the access control lists
(ACLs) for migrated objects to grant them appropriate permissions in the
target forest.
See the
Active Directory Migration Tool Help for additional information about
migrating and restructuring domains using ADMT. You can download ADMT
from the Microsoft Web site at http://www.microsoft.com/downloads by searching for “ADMT”.
|
Documenting the Existing Network
The
first step in planning an in-place domain upgrade is to document the
current network structure. To do so, take an inventory of the following
network attributes:
The existing domain model
Existing trust relationships
Account and resource domains
DNS namespaces currently in use
Server software and compatibility issues
The sections that follow describe how to document each of these features.
Important
Windows Server
2003 digitally signs all server message block (SMB) protocol
communications by default for greater network security. Because of this,
Windows 9x systems must install the DS Client Pack (found on a Windows
2000 Server CD-ROM in the \clients\win9x folder) and Windows NT 4.0
systems must be running Service Pack 4 or newer to access Windows Server
2003 domain controllers. Computers running Microsoft Windows for
Workgroups or Mac OS X do not at present support SMB signing. If you
can’t upgrade or retire these systems, you can disable this setting
using Group Policy—the location is Computer Configuration\Windows
Settings\Security Settings\Local Policies\Security Options\Microsoft
Network Server: Digitally Sign Communications.
The Existing Domain Model
The type of
domain structure, or model, that the existing Windows NT domains use
determines how you implement Active Directory trees and forests. Table 1 summarizes the types of domain models that might be in use.
Table 1. Domain models available in Windows NT
| Domain Model | Description |
|---|
| Single-domain | A single Windows NT domain |
| Single-master | One account domain and multiple resource domains |
| Multiple-master | Multiple account domains with two-way trusts between them and multiple resource domains that trust all master domains |
| Complete trust | Every domain is a resource domain and an account domain, with each domain trusting every other domain |
Existing Trust Relationships
Document existing
trust relationships, and determine whether all trusts are still
necessary. Windows preserves existing trust relationships during an
upgrade to maintain compatibility with Windows NT 4.0 BDCs. However,
Windows doesn’t import trusts with Windows NT 4.0 domains into Active
Directory. Re-create these trusts in Active Directory before upgrading
or taking the last BDC in the domain offline.
If you upgrade any
domains into separate forests and want to maintain trust relationships
between the forests, delete the existing trusts (which use NetBIOS
domain names) after upgrading the PDC and re-create them using fully
qualified DNS domain names.
Account Domains and Resource Domains
Record
the current number of account domains and resource domains. Also think
about whether you want to restructure your domains, either before or
after you upgrade the network to Active Directory.
DNS Namespaces
If the company has
already deployed DNS, carefully document the namespaces currently in
use. You cannot easily rename domains after you create them, and they
must be unique on the network.
Server Software and Compatibility Issues
A crucial and
sometimes forgotten step in documenting a network is to make an
inventory of the servers. Record the server names, hardware
capabilities, locations, operating system version, and service pack
levels of the following types of servers, and evaluate any compatibility
issues or problems with the servers before you begin the upgrade
process:
Domain Controllers
You must upgrade the Windows NT 4.0 PDC before upgrading any other
domain controllers in the domain or adding any Windows 2000 or Windows
Server 2003 domain controllers if you want to maintain the existing
domain. You can upgrade the BDCs after that.
Windows
Server 2003 and Windows 2000 replace the LAN Manager Replication
Service feature of Windows NT with the file replication service (FRS),
which Windows installs automatically on all domain controllers. If you
must maintain compatibility with the LAN Manager Replication Service,
see Microsoft Knowledge Base Article 248358 or refer to the Microsoft Windows Server 2003 Resource Kit.
Note
The preferred way
to upgrade a domain is to purchase a new server to use as the PDC to
upgrade. (Install Windows as a BDC, and then promote it to PDC.) This
ensures that the computer is modern, compatible, and fast enough to
adequately run Windows Server 2003. It also minimizes the amount of junk
residing on the hard drive and in the registry, providing the
“closest-to-clean installation” experience possible.
File and Print Servers
You can easily upgrade file and print servers to Windows Server 2003 or
migrate the server settings and data to a server running Windows Server
2003. Migrating to a new server can yield performance gains from newer
hardware and can also help consolidate servers. Use the Microsoft File
Server Migration Toolkit (available for download at http://www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/msfsc.mspx) or Print Migrator to streamline the migration process.
DNS, DHCP, and Windows Internet Name Service (WINS) Servers Upgrade
Windows NT 4.0 DNS, DHCP, and WINS servers to Windows Server 2003 or
Windows 2000 Server to maximize functionality and to minimize problems.
Windows NT RRAS Servers Windows NT 4.0 Routing and Remote Access Service (RRAS) servers need access to a real
BDC for user information. They work erratically while on a mixed-mode
Active Directory domain, and cease to work entirely after you upgrade
the last BDC. For this reason, upgrade any Windows NT 4.0 RRAS servers
before you start the domain upgrade process (if practical), or
immediately after stabilizing the newly upgraded domain with two or more
domain controllers.
Note
When setting
up an Active Directory domain, the Active Directory Setup Wizard gives
you the option of weakening the security settings for Active Directory
to support pre–Windows 2000 clients. (They’re talking about Windows NT
4.0 RRAS servers here.) Don’t do it—instead upgrade or replace these
servers with Windows 2000 or Windows Server 2003 RRAS servers.
Windows NT 3.51 Servers
If there are still Windows NT 3.51 servers or clients on your network,
upgrade them or get rid of them. If you absolutely can’t part with your
Windows NT 3.51 (or earlier) computers, leave an existing domain running
under Windows NT 4.0 (or create one if necessary) and establish the
appropriate trust relationship between this domain and your Active
Directory structure. Just keep them off Active Directory domains.
Security Alert
Windows
NT 3.51 computers joined to an Active Directory domain can deny access
to user or group logon events, or they can incorrectly grant access to
users or groups to which you have denied access. These difficulties and
security breaches occur because of the way in which Windows NT 3.51
generates access tokens when a user logs on to the server. |
NetWare Servers
Determine whether you want to synchronize Active Directory with Novell
Directory Services (NDS). Check the release notes included on the
Windows Server 2003 CD-ROM for any compatibility issues with NetWare.
Samba Servers
Samba servers might require access to a real Windows NT 4.0 domain
controller (instead of a Windows Server 2003 running the PDC emulator).
Record the location and capabilities of any Samba servers on the
network, and make a special note of whether they require access to
Windows NT domain controllers. (If they do, postpone switching the
network to a native mode until this issue is cleared up.) Many Samba
servers also do not support SMB signing.
Other Application Servers Evaluate all application servers carefully for known issues with Windows 2000, Windows Server 2003, and Active Directory.
Important
Windows NT 4.0
Enterprise Edition clusters cannot perform a rolling upgrade directly to
Windows Server 2003. (A rolling upgrade allows the cluster to stay
online while you upgrade each node one at a time.) To deal with this,
either take the cluster offline and upgrade each node, or perform a
rolling upgrade to Windows 2000, and then Windows Server 2003.
Upgrading a server
preserves all settings and, when upgrading the PDC, allows you to keep
the domain and all its user accounts and resources. However, performing a
clean install yields the best performance and reliability. Here’s how
you can balance these tradeoffs:
Upgrade the PDC and any application servers that are difficult to set up.
Retire any aging Windows NT servers, or repurpose them as desktop machines running Windows XP.
Back
up any relevant data, and then perform clean installs of Windows Server
2003 on any other Windows NT servers that are powerful enough to run
Windows Server 2003. After installation is complete, restore the data.
The File Server Migration Toolkit and Print Migrator tools can help with
this process. (You can download them from http://www.microsoft.com/downloads.)
Replace any retired servers with new Windows Server 2003 systems that serve whatever role you need.
