For better or for worse, many Active Directory (AD) domains still contain down-level Windows NT Backup Domain Controllers (BDCs). Perhaps your BDCs are needed to support an older application or you've got a mission-critical application running on one. Whatever the case, it's usually important that the BDC continue to replicate changes from your AD domain, just as it used to do from your NT Primary Domain Controller (PDC). Sometimes, however, replication stops working. Fortunately, there are a fairly limited number of causes.
Easily the most common cause for BDC replication issues is a failure of some kind in the domain's PDC emulator. The PDC emulator is a Flexible Single Master Operation (FSMO) role that is assigned to one domain controller in the domain.
To troubleshoot this problem, first determine which domain controller holds the PDC emulator role. To do so, open Active Directory Users and Computers, right-click the domain, and select Operations Masters from the context menu. Select the PDC tab, which Figure 18.1 shows, and note the name of the server listed.
Figure 18.1: Identifying the domain's PDC emulator.
If the designated server is not available on the network or is not responding to ping commands from your NT BDC, you need to resolve that problem. You can either try restarting the PDC emulator to fix it or you might need to seize the PDC emulator role at another domain controller.
Make sure that there are no IPSec policies in effect that would prevent an NT computer from communicating with the PDC emulator. For example, applying certain IPSec policies to a Windows 2000 (Win2K) or later computer will prevent communications with down-level clients, which includes NT BDCs.
Other issues can occur when Win2K or later domain controllers don't replicate properly with the PDC emulator; see Microsoft article "Event 1586 Message: The Checkpoint with the PDC Was Unsuccessful" for more information.
A less common cause for BDC replication failure is when the BDC's domain computer account becomes locked out or out of synch. BDCs maintain a domain account in much the same way as users and other computers do. The BDC's accounts must be available and the BDC must know the account password in order for the BDC to participate in the domain.
Use Active Directory Users and Computers to ensure that the BDC's account is available and not locked out. Try logging on to the domain from the BDC's console; the BDC must first log on to the domain in order to process any domain user logons. If you can successfully log on to the domain from the BDC console, the BDC's domain account is probably fine. If you cannot or if the BDC's event logs contain domain logon errors, you might need to reset the BDC's domain account, which is a particularly tricky task with a BDC.
BDC domain accounts might appear as users rather than computers; see the Microsoft article "HOW TO: Create a Computer Object in the Active Directory for a Windows NT 4.0 BDC" for more information.
Hopefully, your Win2K domain is running in mixed mode or your Windows Server 2003 domain is running in its Win2K mixed mode functional level. In Windows Server 2003, check the functional level by opening Active Directory Users and Computers, right-clicking the domain, and selecting Raise Domain Functional Level from the context menu. The resulting window will show you the current level (see Figure 18.2). Any level other than Win2K mixed mode will result in NT BDCs being unable to replicate. There is no solution for this problem other than decommissioning your NT BDCs or restoring every Win2K (or Windows Server 2003) domain controller from a backup—effectively performing forest-wide disaster recovery.
Figure 18.2: The domain's functional level.
Generally, Windows Server 2003 and Win2K will warn you if you attempt to change the domain mode or functional level and NT BDCs still exist in the domain. Windows Server 2003, in fact, will attempt to stop you outright. However, if you do change the mode or functional level, it's a one-way operation that can't be undone; any remaining NT BDCs will be useless.
If you inadvertently configure a Win2K domain to restrict anonymous connections, NT BDCs might be unable to locate a domain controller, replicate the domain database, start the Net Logon service, and so forth. Although restricting anonymous access to the domain is a valuable security technique (and is included in Microsoft's Hisecdc.inf security template), it can cause problems for NT BDCs. You can correct the problem with a registry edit or decommission the NT BDC.
For more information about this problem and its solution, see the Microsoft article "The Net Logon Service of a Windows NT 4.0 BDC Does Not Function In a Windows 2000 Domain". The article "How to Use the RestrictAnonymous Registry Value in Windows 2000" describes more about the RestrictAnonymous registry setting, which is included in the Hisecdc.inf security template.