DCPROMO Fails to Create FQDN in DNS

After I used Dcpromo to successfully promote a Windows 2000 standalone server to a second domain controller (DC) in an existing domain, Active Directory (AD) wouldn't replicate. AD Sites and Services contained the connection objects to and from both servers, but right-clicking either connection object and selecting Replicate Now generated the message The RPC server is unavailable. In addition, several 414 DNS Single Label Hostname events showed up in the DNS event log on the new DC.

I reproduced this problem in a test environment consisting of two Win2K servers with Service Pack 3 (SP3) installed. The first server is named server1.mydomain.com and is a DC running AD-integrated DNS. Server1 uses only itself for DNS resolution, and its DNS service has forwarders to the Internet. The second server is named server2 and is a standalone server in a workgroup with DNS installed but no active zones. Server2 uses server1 for DNS resolution.

I discovered that the problem I encountered is known as disjointed namespace, in which a DC's DNS suffix might not match the domain name that the DC belongs to. (For more information about disjointed namespace, see the Microsoft article "Domain Controller's Domain Name System Suffix Does Not Match Domain Name" at http://support.microsoft.com/?kbid=257623.) This problem typically occurs if you neglect to select the Change primary DNS suffix when domain membership changes check box in the Network Identification properties before you run Dcpromo. I know that I selected the check box--but when server2 came back up, server1's DNS and server2's netlogon.dns file displayed SRV records for server2 as server2, rather than as the Fully Qualified Domain Name (FQDN) server2.mydomain.com., as you'd expect. Server2 had a single label host name even after the Dcpromo process, which caused replication to fail. Unfortunately, I couldn't demote server2 and try again because at that point server2 couldn't contact server1.

I had encountered this problem once before; this time, I resolved to dig deeper for a solution before I rebuilt everything. I searched the registry and discovered that the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDNSRegisteredAdapters\{xxxx-xxxx-xxxx-xxx}DomainName registry subkey, where xxxx-xxxx-xxxx-xxx is the Class ID (CLSID) of the network adapter, specifies a Win2K computer's domain name. This registry subkey was undefined on server2. I set the subkey to mydomain.com on server2, removed server2's SRV records from server1's DNS, deleted server2's netlogon.dns file, and rebooted server2. The two servers then started replicating, and server2's SRV records were fully qualified in DNS and the netlogon.dns file.

After I submitted my solution for publication, Microsoft updated the article "Domain Controller's Domain Name System Suffix Does Not Match Domain Name," at http://www.support.microsoft.com/default.aspx?scid=kb;en-us;257623. The solution in this Microsoft article works well, encompasses my solution, and is officially supported by Microsoft.

—Richard Dayton
[email protected]