You can tweak replication scheduling through several registry values under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey. (For more information about these values, see Tim Daniels, "General System Registry Secrets," http://www.WindowsITlibrary.com/content/69/01/5.html.) If you simply want to force an immediate replication to a specific BDC, open Server Manager on any computer and select the BDC. From the menu bar, select Computer, Synchronize with Primary Domain Controller. The BDC immediately pulls any recent changes from the PDC. (To force synchronization of all BDCs, select the PDC, then select Computer, Synchronize Entire Domain. You should avoid this type of synchronization on a domain with many BDCs, however, to conserve network bandwidth and maintain the PDC's responsiveness.)
BDC Promotion
The time might come when you want to promote a BDC to PDC status. When a PDC goes down, users can't change their passwords, the Help desk can't reset passwords or unlock accounts, and of course administrators can't make any domain changes. However, whether you should promote a BDC when your PDC goes down depends on the situation. If the PDC is going to be down for only a short time, you might not need to promote a BDC—especially for a small domain in which users probably won't notice the interruption. If you support thousands of users, though, you might need to promote a BDC to prevent interruption of service, regardless of the situation. (For a detailed discussion of the planning and steps involved in replacing a PDC, see Melissa Wise, "10 Steps for Replacing Your Aging PDC," March 15, 2001.)
To promote a BDC, open Server Manager, select the BDC you want to promote, then select Computer, Promote to Primary Domain Controller from the menu bar. When you promote a BDC to replace a functioning PDC, NT automatically replicates any recent changes to the selected BDC, demotes the outgoing PDC to a BDC, then promotes the selected BDC to be the new PDC. Therefore, you don't need to synchronize the domain before you promote a BDC to replace a functioning PDC.
If the outgoing PDC isn't functioning, NT can't demote it during the BDC-promotion process. Therefore, when the original PDC comes back up, it announces itself as the PDC, then discovers that a newer PDC is present. Contrary to popular belief, the original PDC doesn't automatically demote itself in this situation. Instead, the original PDC goes into a dormant mode (i.e., it doesn't serve authentication requests or share in replication). You must then manually demote the original PDC.
In this double-PDC situation, when you open Server Manager on the original PDC, it should display two PDCs: the new PDC and the original PDC. The original PDC's icon will be dimmed, which indicates that the Netlogon service hasn't started on that machine. (The Netlogon service provides DC functionality; because it doesn't start on the original PDC, you don't need to worry about that PDC corrupting domain replication or interfering with authentication requests.) To demote the original PDC, select the original PDC, then select Computer, Demote to Backup Domain Controller from the menu bar. The original PDC gets a fresh copy of the new PDC's SAM and begins functioning as a BDC. At this point, if you wish to go full circle and return the original PDC to its primary role, simply promote it as I described earlier.
A hitch exists in this simple process, however. In a double-PDC situation, Server Manager sometimes reports the original PDC as a BDC, even though you haven't yet manually demoted it. (The original PDC's icon will still be dimmed, and the Netlogon service won't start on the original PDC.) You can't demote the original PDC until Server Manager displays it as a PDC. In this situation, you need to click View, Refresh or possibly reboot the original PDC before Server Manager will display it as a PDC and let you demote it. Furthermore, Server Manager occasionally refuses to let you demote the original PDC and gives you only the option to demote the new PDC. Don't take the easy road; if you demote the new PDC, you'll lose any changes you made since promoting it. Instead, you'll need to reinstall NT on the original PDC and select the system as a BDC during installation. The possibility of encountering this problem reinforces the importance of dedicating your DCs to one purpose only: being a BDC or PDC.
Dedicated DCs
Technically, NT DCs can also serve as file and print servers or can host application services such as Oracle, Exchange, Microsoft IIS, or Microsoft SQL Server. However, for all but extremely small domains (i.e., those with two or three servers), I recommend that you dedicate your DCs to being only DCs. Aside from simplifying reinstallation if you have a PDC demotion problem, dedicating your DCs can forestall several potential security worries.
All the BDCs in a domain copy the same SAM from the PDC; thus, all the BDCs share the same audit policy that you defined for the PDC through User Manager for Domains. If you use a BDC for other services, you can't enable different audit policies to fit those other uses. This restriction can lead to a serious security problem.
A second, even more severe problem has to do with administrative authority. All DCs in a domain share the same local Administrators group. Therefore, you can't grant someone administrator authority over only one DC. Consider the domain that Figure 1 shows. The domain has a PDC and four BDCs, but each BDC handles a second role as well. Tom, the IT department's Exchange guru, administers BDC1, which runs Exchange. Alice, who is in the finance department, administers BDC2, which also serves as an Oracle financials server. BDC3 is also an IIS server that maintains human resources (HR) information on the company's intranet; Sally in HR administers BDC3. BDC4 also runs IIS and serves as the company's public Web server; Harry, an outside contractor, administers this BDC.
Register
