Preparing for an NT Domain Upgrade
Figure 9.1 shows a fairly simple classic NT domain configuration consisting of a single account domain with a primary domain controller (PDC) in the main office and BDCs in the outlying areas to handle local logons. Member servers in this domain validate user credentials via pass-through authentication to their respective BDCs.
Figure 9.1. Single domain with multiple BDCs to handle logon in remote locations.
In this configuration, an upgrade starts by having a little conversation with the PDC that goes something like a scene out of The Sopranos:
You sit down in front of the server and say, "You took an oath, PDC, but you broke it. First you got slow, then you stopped talking to the BDCs, and now I hear you're leaking information to the password crackers."
"I tried to keep you out of harm's way. I really did," PDC says back, bezel lights flashing mournfully.
"It's too late," you say. "We're going to have to make some changes." You reach inside your jacket and pull out a copy of the Windows Server 2003 CD.
"Okay," it replies, "only just . . . just . . . not in the console, okay? Leave me my eyes."
You slide open the CD-ROM caddy, put in the disk, and when the splash screen asks you if you want to upgrade, you give a final little salute with your eyebrows and click Yes. About an hour later, the job is done. You light a candle for the old PDC and start configuring Active Directory parameters.
It takes a good bit of planning to get to this point, so let's back up a little and start with a checklist of the upgrade prerequisites. Then, we'll trace through what you can expect to happen when you upgrade the PDC and how to proceed when upgrading the remaining domain controllers and shifting the domain and forest functional levels to Windows Server 2003.
Before you upgrade, you must have a DNS infrastructure deployed that supports service locator (SRV) records and, hopefully, dynamic registrations. The second item is not an absolute requirement, but it saves you from manually importing long lists of SRV records. As discussed in Chapter 5, "Managing DNS," you do not need Windows Server 2003 running DNS or even Windows 2000 DNS servers to support Active Directory. Any version of BIND starting with 8.1.3 will do very nicely, and this includes the latest versions of Lucent QIP.
If you are currently running Windows 2000 DNS servers, and they are not domain controllers, you may want to upgrade them to Windows Server 2003 running DNS to get support for conditional forwarding and stub zones.
If you have not yet decided on the DNS name of your Active Directory domain, it's time to get everyone around a table so you can come to a consensus. Unlike Windows 2000, Windows Server 2003 will let you change a domain name after it has been deployed, but the change is not simple and it is better to avoid the work, if possible.
Remember that if you are upgrading an existing NT domain, the leftmost element of the fully qualified DNS name must match the current flat NetBIOS domain name. Also, if you are installing a separate Windows Server 2003 domain, the leftmost element of the domain name cannot match the existing flat name of any domain, server, or user. This will cause duplicate name errors when you attempt to promote the first domain controller in the new domain.
Configure the TCP/IP properties of your NT domain controllers to point at the dynamic DNS servers before doing the upgrade. This ensures that the servers will register their SRV records during the domain controller promotion phase that follows the upgrade. Also make sure that your clients point at these same DNS servers so they can find the SRV records and use them to locate the newly promoted domain controllers.
Domain Controller Requirements
Your existing NT PDC might date back to the origins of NT4 in the dark ages of the middle 1990s when Pentium 90 servers were considered state of the art and you had to fight to get approval for mirrored 2GB SCSI drives to hold the operating system.
Chapter 1, "Installing and Configuring Windows Server 2003," lists the minimum recommended hardware requirements for Windows Server 2003, including CPU speed, system memory, L2 cache, I/O performance, disk capacity, and network connections. A domain controller should be sized for I/O performance and reliability rather than raw CPU speed. If you have fewer than ten thousand users and the domain controller handles only a few hundred users logging on concurrently in the morning, then you can get by with a single-processor server, 600MHz or higher, with 256MB of RAM and dual mirrored drives for the operating system along with dual mirrored drives for the Active Directory database files. You can find such machines in a 1U form factor from major vendors for less than $3000.
If you have tens of thousands of users in the domain and thousands who authenticate in one location in the morning, and you have lots of group policies to deploy to those users, you need more than one domain controller and each of them needs multiple processors and lots of memory.
You must be running Service Pack 6a to upgrade any NT server to Windows Server 2003, including domain controllers.
Before upgrading an NT domain controller, check for the presence of Hosts and Lmhosts files. Entries in these files might cause name resolution problems after the server has been upgraded to Windows Server 2003. It's easy to forget that you have these files. They lie there quietly, like a Stephen King character lurking under a bridge, waiting . . . to . . . pounce.
You should find the files in \WINNT\System32\Drivers\Etc unless someone has changed the Registry setting for the default location. This Registry setting is HKLM | System | CurrentControlSet | Services | TCPIP | Parameters | DataBasePath.
You must have at least one NTFS volume on the domain controller to hold Sysvol. If an NT4 domain controller you plan on upgrading has only FAT partitions, it's best to convert the partitions to NTFS prior to doing the upgrade. That way, if something goes wrong, you aren't trying to diagnose two problems, the upgrade and the file system conversion.
Always put the Active Directory database files on a separate set of mirrored drives. Most of the I/O involving Active Directory is read rather than write, so mirroring improves performance. If you have hundreds and hundreds of users authenticating on a domain controller at the same time in the morning, and therefore pulling their group policies from Sysvol on that domain controller, you might want to put Sysvol on a separate set of mirrored drives, as well.
Application Compatibility Considerations
Even if your existing server hardware is capable of supporting a full-fledged Windows Server 2003 domain controller, you might not want to do a direct upgrade because of incompatible applications running on the server, or a Registry that resembles an old bulletin board with layers and layers of entries that no one has ever seen fit to remove, or an operating system volume choked with old management software and analytical tools you've experimented with over the years.
A domain controller can act as a file-and-print server and even run small applications such as TCP/IP support services, but it should not be used for heavy-duty client/server applications. This is not so much a limitation of the operating system as it is a logistical decision. If you are running a mail server and you need to shut it down to do maintenance on the information store, you don't want that evolution to affect the authentication services provided by a domain controller.
If you want to do a direct upgrade of your domain, you cannot simply place Windows Server 2003 on the wire and promote it to be a domain controller in that domain. You must always upgrade the existing PDC, then you can introduce as many new Windows Server 2003 domain controllers as you like. If your PDC is a little wheezy, the workaround is to leapfrog the upgrade (see Figure 9.2).
Figure 9.2. Leapfrogging a PDC to introduce a new server for upgrading.
First, spec out the hardware for a server that is adequate for your domain controller needs. Do a test installation of Windows Server 2003 on this server just to make sure you have no compatibility issues. Make sure you test all the SCSI channels and drives that you will eventually use to store Active Directory files.
Now, wipe the operating system drive on the new server and install NT4 as a BDC in your existing NT domain. Make sure you verify that you get steady replication between this server and the PDC. Leave the new server on the wire for a day or two to check for complications prior to upgrading.
Promote the new server to PDC with User Manager. This automatically demotes the existing PDC to a BDC. Again, let the system bake for a couple of days to make sure everything works as you would expect.
When you're ready to upgrade the domain, start by upgrading the new PDC to Windows Server 2003. You already know the hardware works with Windows Server 2003, so the upgrade should proceed without complication barring any pre-existing corruption in the Security Account Manager (SAM) or a power failure during the upgrade.
After the upgrade, you can either upgrade or replace the existing BDCs in the domain. The example in the diagram shows a Windows Server 2003 member server waiting in the wings to take over for the old BDC.
Upromote and NT Domain Controllers
If you are running applications on NT domain controllers, it is often impractical to upgrade the server to a Windows Server 2003 domain controller. You have the option following the upgrade to leave the server as a member server rather than complete the Domain Controller Promotion Wizard (Dcpromo) to upgrade to a Windows Server 2003 domain controller.
If you prefer, you can demote the NT BDC to a standard member server prior to the upgrade. This can be done using a third-party tool called Upromote from Algin Technologies. Using Upromote, you can demote a classic NT BDC to a member server, and you can also promote a standard server to a BDC. This gives you quite a bit of flexibility.
Use caution when changing the status of a domain controller if you have added domain local groups to access control lists (ACLs) on files and Registry keys on the server. Standard member servers do not recognize domain local groups, and you could cause users to lose access to files.
Protect the SAM
Upgrades can go sour for a variety of reasons:
Hardware incompatibilities with Windows Server 2003 that prevent upgrading the operating system
Hardware failures during the operating system upgrade or domain controller promotion
SAM or Local Security Authority (LSA) corruption that prevents migrating accounts and policies to Active Directory
Inadequate DNS and Windows Internet Name Service (WINS) preparation
In all of these potential failure scenarios, your prime concern is protecting the account database. The PDC has the only read-write copy of the SAM and Security Registry hives. This is where the accounts and account policies are stored along with trust relationship information. If the upgrade fails and the PDC cannot be recovered, users can still log on to the domain via the BDCs but you cannot change passwords, group memberships, or user privileges.
You can speed up recovery by making an image of the operating system partition just prior to starting the upgrade using imaging tools such as Ghost from Symantec or DriveImage from PowerQuest. Or, you can do a standard tape backup using Ntbackup or, better yet, a backup utility with an emergency restore feature.
Another potential problem is corruption of the SAM and Security hives that doesn't come to light until after the promotion. If the corrupted entries get replicated to the BDCs, you could cause users to lose access to the domain. To prepare for this type of failure, many organizations use an offline BDC as an insurance policy. Here's how it works.
Install NT Server as a BDC on a spare machine. It does not need to be a server-class machine. All you want is a live copy of the SAM and Security hives. After you've verified that the BDC is functioning properly, take it offline. If the SAM or Security hives should become corrupted during the upgrade or in the days just following the upgrade, you can take the following actions to recover:
Take the Windows Server 2003 domain controllers and NT4 BDCs offline.
Put the offline BDC back on the wire.
Promote the BDC to PDC using Server Manager.
Verify in WINS that the server is listed as the PDC for the domain. Delete other domain controller listings, if necessary.
Put the NT4 BDCs back on the wire one at a time and force replication. Check the Event log to verify that they were able to find the new PDC and replicate from it.
Restore the original PDC from tape or image.
When you put the original PDC back on the wire, it will see that another server is now the PDC and will not start Netlogon.
Demote the original PDC to a BDC then promote it to PDC to return the system to status quo ante.
After you've restored full functionality to the network, you can assess what went wrong and start over again. You'll need to wipe and reinstall any new Windows Server 2003 domain controllers you introduced into the system.
The offline BDC is only good insurance for a few days. As time goes by, the passwords and group memberships it holds get more and more out of date. One of the first things you should do after you complete the upgrade of the PDC and each BDC is to get a good backup so that you can keep the system running on Windows Server 2003 domain controllers rather than roll back completely to NT4 should a disaster occur.
When you promote an NT PDC to Windows Server 2003, the domain functional level is set to Windows 2000 Mixed. This retains compatibility with NT4 domain controllers. The following new features are available in Windows 2000 Mixed functional level:
Discrete Application naming contexts for Active Directory integrated DNS zones
Ability to save queries in AD Users and Computers
A new Trust Wizard that simplifies trust creation
Windows 2000 Native functional level disables replication to NT4 BDCs and enables the following features:
Global group nesting
Policy-based remote access permissions
Per-user remote access addressing and routing
Universal group membership caching
Transitive cross-domain resource access for downlevel clients and member servers
Retaining SID History for migrated security principals
Shifting a domain to Windows 2000 Native functional level does not prevent downlevel clients from operating. A Windows 9x/ME or NT4 desktop can authenticate to the domain and access resources just as it would do in an NT domain. Make sure you're running the most current service packs on the NT desktops, though, to avoid compatibility issues with the older NTLMv1 authentication. You should also seriously consider upgrading any member servers and desktops that are running NT 3.51 so you can use NTLMv2.
When all Windows 2000 domain controllers have been upgraded or decommissioned, you can shift the domain functional level to Windows Server 2003. This enables the following features:
Renaming domain controllers
Updates to the logon timestamp
Full security principal treatment for InetOrgPerson objects
Kerberos Key Distribution Center (KDC) key version numbers
When all domains have been shifted to Windows Server 2003 functional level, you can shift the forest functional level to Windows Server 2003. This enables the following features:
Restructuring forests by renaming domains to change parent/child hierarchies
Creating transitive trusts between forests
Special schema operations, including disabling schema objects, creating dynamic auxiliary classes, and modifying the characteristics of the inetOrgPerson class
Individual group member replication, part of an overall change to the way linked values are replicated
Modified Global Catalog (GC) replication
Improved replication topology management
If a domain has only Windows Server 2003 and NT domain controllers, you can set the functional level to Interim. This enables discrete group membership replication.
The shift to Windows Server 2003 functional level for the domain is done using AD Users and Computers. Right-click the top of the tree and select RAISE DOMAIN FUNCTIONAL LEVEL from the flyout menu. This opens a Raise Domain Functional window as shown in Figure 9.3.
Figure 9.3. Raise Domain Functional Level window showing current functional level and the next available level.
The shift to Windows Server 2003 functional level for the domain uses the AD Domains and Trusts console. Right-click the top of the tree and select RAISE FOREST FUNCTIONAL LEVEL from the flyout menu. Figure 9.4 shows the Raise Forest Functional Level window.
Figure 9.4. Raise Forest Functional Level window showing current forest functional level and the next available level.
While running in Windows 2000 Mixed functional level, you can introduce a new classic NT BDC into the domain, but you must first create the computer account using AD Users and Computers. When creating the new object, select the Allow Pre-Windows 2000 Backup Domain Controllers To Use This Account option. Figure 9.5 shows an example.
Figure 9.5. Computer object in Active Directory created for classic BDC.
Mixed Domains and Group Policies
A Windows desktop running Windows 2000 or XP could find itself in one of the following situations regarding access to domain controllers for authentication and group policy access:
Strictly NT4 domain
Windows 2000 Mixed domain with NT4 and Windows 2000 domain controllers
Windows 2000 Mixed domain with NT4 and Windows Server 2003 domain controllers
Windows 2000 Mixed domain with NT4 and Windows 2000 and Windows Server 2003 domain controllers
Windows 2000 Native domain with strictly Windows 2000 domain controllers or with a mix of Windows 2000 and Windows Server 2003 domain controllers
Windows Server 2003 functional level with strictly Windows Server 2003 domain controllers
In a purely NT domain, group policies are not available from the domain so Windows 2000 and XP desktops use local policies stored in template files on the local drive and classic system policies downloaded from their logon server in the form of Ntconfig.pol files. In an Active Directory domain, modern Windows clients do not download or process classic system policies.
The situation gets more complex in the other scenarios where group policies from Windows 2000, XP, and Server 2003 get mixed together. It is worth spending a little time to understand how policies are created and modified so you can avoid situations where group policy objects contain policy files that lack crucial settings.
Microsoft designed Windows 2000 and XP clients to "seek out" Active Directory domain controllers in preference to classic NT BDCs. Each time a modern Windows desktop starts up, it queries DNS to see if this is the day when an Active Directory domain controller has finally registered SRV records in its zone. If it gets back a negative reply from DNS, it heaves a sigh and falls back on classic NT LanMan (NTLM) authentication with a classic BDC.
If DNS returns SRV records pointing at Active Directory-based domain controllers, Windows 2000 and XP clients happily go to them to authenticate. This ensures that the modern clients get group policies at logon.
After a modern client has a taste of logging on using Active Directory, it does not go back to classic BDCs. If no AD-based domain controllers are available, the clients use cached credentials (and cached group policies) rather than ask a BDC for authentication.
Stop a moment and count up the number of modern Windows desktops you have running in your NT4 domain. Do they number 20 percent of your fleet? 40 percent? All of them? Where are they located? All your offices in the U.S.? Overseas? Oil platforms in the Gulf? Military outposts in Diego Garcia? Are they connected to the main network by WAN links? Satellites? Virtual private networks over broadband?
Imagine that you upgrade your PDC this evening. You start at 6:00 p.m. after the last user has left the office and you finish up a couple of hours later. You go home feeling very pleased with yourself. The next morning, here's what happens. All those modern Windows desktops in your network, situated throughout the world, wake up to find SRV records in DNS. They clap their hands like little kids who find presents under the tree from Santa; then they converge on that single, new Windows Server 2003 domain controller with their logon requests.
You may want to avoid this onslaught by delaying support for Kerberos authentication and group policy deployment for a while until you have sufficient Windows Server 2003 domain controllers to handle the demand. You can do this by setting a Registry entry that makes a newly promoted Windows Server 2003 domain controller pretend to be classic NT4 domain controller. Here is the entry:
Key: HKLM | System | CurrentControlSet | Services | Netlogon | Parameters
Data: 1 (REG_DWORD)
It is important that you put this entry in place on all NT domain controllers before you upgrade them. The domain controller will still register its SRV records, but when the modern Windows clients go to authenticate, the domain controller will only respond with an NTLM authentication sequence. If you wait until after the upgrade, when the clients have already logged on with Kerberos and reset their local LSA configuration, it's too late. You've released the troubles from Pandora's box and you won't be able to put them back again.
During the time that you have the NT4Emulator switch in place, your XP and Windows 2000 desktops will continue to use NTLMv2 authentication rather than Kerberos. This means you will not be able to use MMC-based Active Directory management tools, which require Kerberos to support Lightweight Directory Access Protocol (LDAP) binding. Also, you cannot promote a server to domain controller or introduce another domain into the forest because the servers cannot bind to LDAP on the existing domain controller.
You can force an individual desktop or server to bypass the NT4Emulator behavior of the domain controller and perform a Kerberos logon by putting this entry into the Registry at the desktop:
Key: HKLM | System | CurrentControlSet | Services | Netlogon | Parameters
Data: 1 (REG_DWORD)
After putting this entry in place, log off then back on again. The desktop will find the Windows Server 2003 domain controller and use Kerberos to authenticate and the MMC-based consoles will start functioning. You can toggle NeutralizeNT4Emulator off if you want to stop using the desktop for management.
When you have sufficient Windows Server 2003 domain controllers deployed to handle the expected volume of Kerberos authentications and group policy deliveries, flip the NT4Emulator switch to 0 in the Registry of each domain controller and restart it.
XP Policy Placement
To understand how XP desktops will get XP-related group policies in a mixed environment of Windows 2000 and Windows Server 2003 domain controllers, we need to review how group policies are constructed.
When you create a new Group Policy Object, the Group Policy Editor creates two sets of items:
Both of these sets of items are created at the PDC Emulator, regardless of where you actually run the Group Policy Editor. This ensures that two administrators don't step on each other's policies because of synchronization differences.
Now, when you first open the Group Policy Editor, it needs to know what Registry-based policy options to display under the Administrative Templates icon. It obtains this list of policy settings from ADM files stored in the \WINNT\Inf folder on Windows 2000 machines and the \Windows\Inf folder on Windows Server 2003 or XP machines.
Here's where things get interesting. Refer to Figure 9.6, which shows a domain running at Windows 2000 Native functional level with both Windows 2000 and Windows Server 2003 domain controllers in operation. Let's say that Bob, working at a Windows 2000 desktop, creates a new Group Policy Object (GPO) using the AD Users and Computers console utility that comes as part of the Windows 2000 Adminpak.msi toolkit.
Figure 9.6. Deploying XP-based policies in mixed Windows 2000 and Windows Server 2003 domain.
The Administrative Template settings in the GPO created by Bob come from ADM files on Bob's Windows 2000 desktop and therefore have no XP policy settings. If Alice modifies the GPO from her XP desktop, the ADM files on her desktop have timestamps later than the Windows 2000 ADM files and overwrite the files in the ADM folder under the policy folder in Sysvol. The GPO now contains XP policy settings. If Bob installs a service pack on his Windows 2000 desktop then modifies the GPO, the timestamp on the ADM files could be later than those from Alice's XP desktop, and the XP policy settings disappear.
If Chester modifies the GPO from a server running Windows Server 2003, the timestamp on the ADM files might be later than the Windows 2000 service pack files and the policy settings would change again. To avoid this constant changing of group policies, you should adopt the following operating procedures:
Only create new group policies from clients that have the most current ADM files.
Always put the latest service packs on the machines used to update group policies.
Do not change the content of existing ADM files because that will change the timestamp and potentially overwrite existing ADM files. Instead, create custom ADM files.
You may never encounter this problem, but if you do, you can spend a while thinking how much more difficult this is going to be when Longhorn, the next version of Windows, comes on the market in 2004.
Support for Classic NT4 RAS Access
As described in Chapter 20, "Managing Remote Access and Internet Routing," when a user dials into a Windows remote access server, the server authenticates the user using one of a variety of methods. The default method, at least for Windows clients, is Microsoft's proprietary Challenge Handshake Authentication Protocol, version 2, or MS-CHAPv2. This protocol is used in classic NT RAS and Windows 2000 RRAS, as well.
MS-CHAPv2 authentication requires the remote access server to make a secure connection to a domain controller so it can obtain a copy of the user's NT password hash. The RRAS service in Windows Server 2003 and Windows 2000 is capable of making this connection using the Kerberos credentials belonging to the underlying computer account. Classic NT4 RAS servers are not so fortunate. They know nothing about Kerberos.
In NT, RAS servers create secure connections to NT4 domain controllers using what is called a null session. A null session is a special connection type where the entity requesting the connection provides no credentials. An NT4 domain controller is coded to create a local thread for this null session. It assigns access permissions to the thread using an access token containing the Everyone group and the Network group. The Everyone group in NT has permission to execute certain function calls designed to set up a secure connection.
In Windows Server 2003 and Windows 2000, null session connections to Active Directory are not permitted. Therefore, under normal circumstances, a classic NT4 RAS server that is a member of an Active Directory-based domain cannot authenticate dial-in users.
If upgrading your NT4 RAS servers to Windows Server 2003 or Windows 2000 is not an option for some reason, you can elect to retain classic RAS authentication by selecting the Retain Pre-Windows 2000 Compatible Access option during the domain controller promotion. This option, in Windows Server 2003, puts the Everyone group and the Anonymous Logon group into a group called Pre-Windows 2000 Compatible Access (PW2CA). The PW2CA group has sufficient permissions in Active Directory to retrieve a user's credentials and verify a user's dial-in permissions.
Windows 2000 adds only the Everyone group to the Pre-Windows 2000 Compatible Access group. This is not sufficient in Windows Server 2003 because the Everyone group is not assigned to null sessions. For more information on the specific permissions assigned to the Pre-Windows 2000 Compatible Access group, see Chapter 20, Managing Remote Access and Internet Routing."
After you have upgraded your NT4 RAS servers, you can return security to normal by removing the Everyone group and Anonymous Logon group from the Pre-Windows 2000 Compatible Access group. You must restart all domain controllers before the change takes effect.
Supporting Classic Scripts and Policies
Classic NT logon scripts are identified by entries in each user's account in the SAM. For example, if you want user Rdangerfield to run a logon script called Logon.cmd each time he authenticates on the domain, you must enter the name logon.cmd into the Scripts field of the user's profile.
When a Windows user has a logon script defined in his account, the Windows network client looks for the script in a share called Netlogon at the domain controller that authenticates the user. The script must reside in that share. If it does not, the network client skips the script and continues on with the network logon.
Classic system policies are also stored in the Netlogon share. These policy files, Config.pol for Windows 9x/ME clients and Ntconfig.pol for NT-based clients, are downloaded by downlevel Windows client whenever they authenticate onto the domain.
In Windows Server 2003, the Netlogon share points at \Windows\Sysvol\domain\Scripts. Because the contents of Sysvol are kept in sync on all domain controllers by the File Replication Service, clients can log on at any Windows Server 2003 domain controller and be assured of finding their logon scripts and system policies.
The same is not true of clients that log on at classic BDCs in a Mixed domain. There is no service in Windows Server 2003 to replicate the contents of the Netlogon share to downlevel BDCs. Classic NT has such a service, Lmrepl, but it is not supported on either Windows Server 2003 or Windows 2000.
If you have downlevel BDCs and you use logon scripts or system policies, you must create a "bridge" between a Windows Server 2003 domain controller and the downlevel BDCs. This is done by configuring one of the BDCs as the Lmrepl export server. Configure the other BDCs to pull their updates from the $Repl share on this server. The $Repl share points at \WINNT\System32\Repl\Export.
Next, set up an automated copy utility such as Robocopy from the Resource Kit to keep the contents of the $Repl share in sync with the Netlogon share at the Windows Server 2003 domain controller. Using this workaround, you can continue to use classic system policies and logon scripts for your downlevel clients.
Placement of Flexible Single Master Operations (FSMO) Servers
When you upgrade the PDC in the first account domain, it will hold all five FSMO roles. These are as follows:
Domain Naming Master
As you deploy your new Windows Server 2003 domain controllers, it is important to ensure that these FSMOs are assigned to appropriate domain controllers.
In Windows 2000 Mixed functional level, the PDC Emulator and RID Master roles should always be hosted by the same domain controller because the PDC Emulator is the only domain controller that can create and modify user, group, and computer objects. After shifting the functional level to Windows 2000 Native, you can split the roles between domain controllers, but this is not recommended.
Another important duty of the PDC Emulator is to act as a "court of last resort" for password verification. If an administrator resets a user's password, the change is communicated immediately to the PDC Emulator, where it is written to its replica of Active Directory. If the user submits a bad password to any domain controller in the domain, the domain controller consults the PDC Emulator before denying access to the user. For this reason, make sure the PDC Emulator is at a well-connected location in your WAN.
If you have multiple domains in a forest, it is important that the Infrastructure Master in each domain be assigned to a domain controller that is not a Global Catalog server. The Infrastructure Master is responsible for verifying that names on phantom records representing security principals in other domains in the forest match the names in the Global Catalog. Domain controllers hosting the Global Catalog do not have phantom records so they must not be assigned as Infrastructure Master.
There is only one Schema Master and one Domain Naming Master for an entire forest. Microsoft recommends assigning these roles to the same domain controller to simplify management. The Domain Naming Master must be assigned to a Global Catalog server to get access to all Domain naming contexts.
Unsupported Domain Operations
The following operations are not supported by Windows Server 2003 or Windows 2000:
You cannot break a Domain trust or a Tree Root trust to form an independent forest. If you want to pull apart domains into separate forests, you must create new forests and migrate security principals between them.
Moving Domain Controllers Between Domains.
There is no utility for moving a domain controller between domains. You must demote it to a standard server, join it to the new domain, and then promote it to a domain controller in the new domain.
Additional Deployment Issues
Here are some additional checklist items for upgrading a classic PDC:
SAM and LSA databases.
All user, group, and computer accounts are copied from the SAM into Active Directory. LSA secrets for trust relationships, computer account passwords, and so forth are copied into Active Directory, as well. Security information in LSA, such as User Rights and Policy Rights, are transferred to the Security Editor database where they are implemented as domain and domain controller group policies.
Classic trust relationships.
Any classic NT trust relationships that exist between the domain you are about to upgrade and other domains are converted to External trusts. This includes one-way trusts from resource domains and two-way trusts between account domains.
User and Group SIDs do not change, so all access permissions remain intact. Users and groups from other NT domains can still be recognized via the External trust.
Allotted time for the upgrade.
The Netlogon service is disabled at the PDC from the time you start the operating system upgrade until you complete the domain controller promotion and restart the server. During this time, the server cannot authenticate users or accept changes to elements of the SAM or LSA, nor can it replicate to BDCs.
Privileges required to perform the upgrade.
You need full Administrator privileges in the NT domain to perform the upgrade. Be absolutely sure you know the password of the Administrator account in case something goes wrong and other accounts get locked out.
You need at least 1GB of free space in the operating system partition to upgrade an NT server to Windows Server 2003. You'll need another partition, preferably on another spindle, to store the Active Directory database files. The required size of this partition depends on the expected size of the Ntds.dit file that holds the database. A mirrored 9GB drive is adequate for anything less than a quarter million users. All partitions should be formatted with NTFS and defragmented thoroughly.
The classic NT PDC is also the Domain Master Browser (DMB). During the relatively lengthy upgrade, a browse election may occur during which one of the BDCs will obtain control of the browse database, but the PDC will remain registered in WINS as the DMB. As soon as the server restarts for the final time as a full-fledged domain controller, it forces another browse election, takes back the copy of the browse database, and takes over once again as DMB.