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, corp.acme.com)
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.
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.
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:
- http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp
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.
Filesystems
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.
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."
