This article was previously published under Q296951
This article has been archived. It is offered "as is" and will no longer be updated.
The SYSVOL share on a newly-promoted Windows 2000 replica domain controller (DC) has not been created within the expected amount of time following the use of the Dcpromo.exe tool. Note that this is typically less the 15 minutes on domains with default domain and DCs policy that is connected at LAN link speeds.
The advertising of the newly-promoted replica DC for logon authentication, global catalog searches and other domain and forest-wide roles is delayed.
When you run the dcdiag /test:advertising DC name command, you may receive the following error message
Warning : DsGetDcName returned information for \\source server\domain name, when we were trying to reach DC name
Server is not responding or is not considered suitable
where DC name is the name of the newly-promoted replica DC, source server is the name of the DC that is used by the new replica to source the schema, config and domain naming contexts, and domain name is the fully qualified domain that the replica DC was promoted into.
During the promotion of replica DCs to an Active Directory domain, a registry key (Replica Set Parent), under the NTFRS section of the registry is populated with the name of the DC that is used to source the Active Directory. FRS uses this key to source the SYSVOL share. Initial SYSVOL replication occurs following the reboot after promotion.
Because of a faulty compare of the Microsoft Windows NT 4.0-style domain name that is returned by DsCrackNames and the server principle name that is returned by RpcMgmtInqServerPrincName, FRS fails to join the volatile connection. This results in a delay to share out sysvols after the promotion.
The reason that the new replica DC is not joining with the existing DC is because of an SID mismatch. The SID from the RPC call from replica to source DC is known, but the SID that the source DC gets by calling DsCrackName is <unknown> or NULL.
To see this, increase the FRS debug log verbosity to look at severity 4 NTFRS debug logs.
To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
260910 How to Obtain the Latest Windows 2000 Service Pack
The sysvol will be shared once KCC generates automatic connections (typically 15 to 30 minutes after the reboot following Active Directory promotion) and FRS successfully completes a synchronization.
FRS will use automatic connection objects that are created by KCC, or manual connections that are created by the administrator for sysvol synchronization.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 3.