Making a Recovery Plan
Upgrading a Windows NT
4.0 domain involves a fair amount of risk. If the PDC fails the upgrade
and there aren’t any BDCs available, the entire domain fails. To
protect your network from this unhappy possibility (and others), you
need a recovery plan.
The following sections provide specific recommendations for safeguarding a network from disasters.
Make Sure All Domains Have at Least One BDC
Be sure all domains
you plan to upgrade have at least one BDC in addition to the PDC. This
prevents the domain from being orphaned (or lost entirely) if the PDC
fails the upgrade. Having a working and recently synchronized BDC allows
the network to function (almost) normally while you upgrade the PDC.
(Some programs or services such as WINS don’t like it when the PDC is
gone.)
Back Up Each Computer Before Upgrading
Back up each
system before upgrading it. This is perhaps overly cautious on some
desktop systems that do not store any data locally, but it’s important
on servers, especially domain controllers. Also, make sure you test the
backups by restoring randomly selected data from the backup, or even
performing a full restoration into a Microsoft Virtual Server
environment.
Synchronize All BDCs with the PDC
Synchronize the
PDC with all its replication partners before upgrading it. If the PDC
fails the domain upgrade, you can promote a BDC to the PDC and the
domain won’t lose any changes.
Take a BDC Offline for Backup
Freshly synchronized
BDCs and new tape backups of the PDC protect you from most disasters.
However, it’s good insurance to take a freshly synchronized BDC offline
before upgrading the PDC. This provides you with a quickly available,
working backup of the domain as it existed before you started the
upgrade process. If the upgraded PDC replicates bad domain information
to the BDCs or the domain becomes damaged in some other way, having an
offline backup allows you to go back to a healthy copy of the domain.
To prepare a BDC to act as
an offline domain backup, synchronize the BDC with the PDC domain, back
up the BDC, and then disconnect the network cable to the BDC. If a
major disaster occurs after upgrading the PDC and it is necessary to
restore the domain to its pre–Active Directory state, use the following
steps:
1. | Demote any Windows 2000 or later domain controllers on the network back to member server status.
|
2. | Reconnect the offline BDC to the network.
|
3. | Promote the formerly offline BDC to a PDC.
|
4. | Synchronize
the new PDC with the other BDCs on the network. This returns the domain
to the state it was in immediately before you took the BDC offline.
|
Important
All changes to
the domain performed after taking the backup BDC offline are lost if you
bring the BDC back online and promote it to a PDC. Because of this,
keep a record of any changes you make (such as creating or deleting
accounts, and changing group memberships or trust relationships). By
doing so, in the event of a disaster you can manually recreate the lost
changes.
Relax
Don’t
let all these warnings dissuade you from performing an upgrade. If you
take precautions and the upgrade goes faultlessly, you won’t have to
resort to restoring backups or using other recovery mechanisms. However,
if you do encounter problems, you will be prepared.
Developing an Upgrade Strategy
After
documenting the existing network infrastructure, making a recovery plan,
and designing the Active Directory trees and sites, you’re ready to put
it all together and create an actual upgrade plan. This section
presents some general guidelines that apply to all domain upgrades, as
well as some tips for specific domain models.
Upgrading or Replacing Windows NT RAS Servers
As mentioned earlier in
this chapter, Windows NT 4.0 RAS servers don’t play well with Active
Directory networks. Because of this, upgrade or replace any Windows NT
4.0 RAS servers with Windows Server 2003 or Windows 2000 member servers
running Routing and Remote Access (RRAS) before
upgrading the PDC and starting the domain upgrade. If this isn’t
feasible, put all Windows NT 4.0 RAS servers near the top of the list of
servers to upgrade after you upgrade the PDC and a few BDCs.
Making Sure the PDC Is Sufficiently Powerful
Start the domain
upgrade by carefully examining the current PDC. Although Active
Directory uses peer-based, multiple-master domain controllers, the first
domain controller retains extra services that in some cases you cannot
easily move to other domain controllers. These services include the
global catalog server, the Operations Master, and the PDC emulator. (The
PDC emulator provides services for Windows NT, Windows 95, Windows 98,
and Windows Me clients, and also performs some tasks in a pure Windows
2000, Windows XP, and Windows Server 2003 environment.)
Because of these
additional roles the upgrade PDC must perform, the first PDC should be
especially fast, powerful, and reliable. The best way to ensure that the
PDC is fast enough is to buy a powerful new server and install Windows
NT 4.0 Server on it as a BDC with Service Pack 6a and the latest hot
fixes. Promote the server to your PDC, let it sit for a little while,
and then take it offline and perform the upgrade to Windows Server 2003.
This ensures that your first domain controller is on the most powerful
and up-to-date hardware you have available, and it provides the
closest-to-clean install experience possible from an upgrade.
Creating the Dedicated Forest Root Domain Before Upgrading the PDC
If
you want to create a dedicated forest root domain, you need to do this
before you upgrade the PDC. After you have the new domain up and running
with a couple of domain controllers, you can upgrade the PDC and join
it to this new tree as a child domain.
Upgrading or Retiring Any Incompatible Clients and Servers
If you have any
Windows NT 4.0 RAS servers or computers running Windows NT 3.51 or
earlier, upgrade or retire these systems as discussed earlier in this
chapter.
Disable the
LAN Manager Replication Service on all Windows NT 4.0 servers because
it’s incompatible with Active Directory networks. The file replication
service (FRS) feature of Windows 2000 and Windows Server 2003 domain
controllers replaces it. (Note that the new DFS Replication service of
Windows Server 2003 R2 does not replace FRS for domain controller
replication.)
More Info
If you want to
synchronize FRS with LAN Manager Replication Service, see the
“Synchronize File Replication Services” topic in the Windows Server 2003
Deployment Guide at here. This topic discusses a workaround using tools from the Windows Server 2003 Deployment Kit companion CD.
Upgrading the PDC First
The first server you
upgrade must be the Windows NT PDC in the account domain you want to use
as the root of the new Active Directory tree. This is true whether the
tree you’re creating is the first in the forest or the twentieth in the
third forest—upgrade the PDC first if you want to upgrade the Windows NT
domain instead of creating a new domain.
Note
If you’re going
straight from Windows NT to Windows Server 2003–based domain controllers
without passing “Go” (Windows 2000), consider using the Windows Server
2003 Interim functional level. This mode offers a number of advantages
over Windows 2000 mixed mode, and it still allows Windows NT BDCs (but
no Windows 2000 domain controllers) to operate in the domain.
Upgrading or Replacing the BDCs Quickly
It’s
important to get another Windows Server 2003 or Windows 2000 domain
controller online quickly after you upgrade the PDC. If the sole Windows
Server 2003 domain controller goes down, you’ll have to promote a BDC
to PDC and start over again (though most changes will survive, except
any changes incapable of being stored on a Windows NT BDC).
Another reason that
it’s important to quickly add additional domain controllers is because
computers running Windows 2000, Windows XP, or Windows Server 2003
authenticate preferentially with Windows Server 2003 and Windows 2000
domain controllers. If there are too few Windows Server 2003 or Windows
2000 domain controllers available, clients might not be able to
authenticate during busy times. (Most clients can log on using cached
credentials, but you should nonetheless add domain controllers quickly.)
If you can’t add additional Windows Server 2003 or Windows 2000 domain
controllers in a prompt manner, configure the Windows Server 2003 domain
controllers to appear to all clients as Windows NT 4.0 domain
controllers. To do so, refer to the Windows Server 2003 Resource Kit or Knowledge Base Article 298713.
Because the master copy
of the domain information is stored in Active Directory after you
upgrade the PDC, you don’t need to upgrade BDCs. Instead, you can
replace them with new Windows Server 2003 or Windows 2000 domain
controllers, or perform clean installations on BDCs and then install
Active Directory when finished.
If you do choose to upgrade
BDCs, do so one at a time, and pause before upgrading or retiring the
last BDC. Verify that you’ve dealt with all incompatible clients and
servers, re-create in Active Directory any trusts in that are
established with Windows NT 4.0 domains, and to be extra safe, take the
last BDC offline for a week or more before upgrading or retiring it. If
nothing erupts in flames, go ahead with your plan.
Important
Make sure that the
first domain controller is visible on the network when upgrading a BDC.
When you upgrade a BDC, it replicates only with the PDC emulator. If the
former PDC isn’t available, the BDC takes over the PDC emulator and
other roles, creating serious problems when the first domain controller
comes back online.
To
reduce the amount of replication traffic generated when upgrading or
deploying a new domain controller on the far end of a slow WAN link,
back up the system state information from an existing domain controller
and physically ship the backup media to the remote site. Then upgrade
the BDC to Windows Server 2003 (or perform a clean install) and, before
running the Active Directory Installation Wizard, restore the files to a
local hard drive (by specifying Restore Files To: Alternate Location In
Backup). Then run the Active Directory Wizard (Dcpromo.exe) with the /adv
switch and specify the location of the restored files. This seeds the
new or upgraded domain controller with a slightly out-of-date copy of
the Active Directory database, which Active Directory updates during the
first replication. This first replication is significantly faster than
if you replicated the entire Active Directory database. |
|
Upgrading Member Servers and Clients Independently
Upgrade member
servers and workstations whenever you want—either before or after you
upgrade the domain. Windows 2000, Windows XP, and Windows Server 2003
clients and member servers work perfectly well with Windows NT domains;
however, the benefits of Active Directory aren’t available to clients
and member servers until you upgrade the domain.
Scheduling the Domain Upgrade Appropriately
Schedule the domain upgrade
at a time that has the lowest impact on the user population. It’s best
to avoid upgrades during major projects and during the busiest times of
year if possible. Even perfect upgrades produce some impact on the
users, especially if you perform any domain restructuring or
consolidation.
Creating a Testing Criteria
It’s important
to ascertain whether Active Directory is functioning properly after a
domain upgrade, before it’s too late to back out and restore the Windows
NT 4.0 domain. Use these criteria as a starting point:
Users can log on successfully.
Users can access e-mail.
Users and groups can access resources for which they have permissions, including resources in other domains (when applicable).
Active Directory is functioning properly. (Use Dcdiag.exe.)
Replication works properly. (Use Repadmin.exe and Nltest.exe to verify this.)
