Problem : DCPromo fails with “The wizard cannot gain access to the list of domains in the forest”; “The RPC server is unavailable.”

Problem : DCPromo fails with “The wizard cannot gain access to the list of domains in the forest”; “The RPC server is unavailable.”

We are having great difficulty promoting a Windows 2003 Server to a Domain Controller at a remote site.   Attempts to run DCPromo fails with “The wizard cannot gain access to the list of domains in the forest….The RPC server is unavailable.”   If we attempt to just join it to the domain, we receive the message “The following error occurred attempting to join the domain “XXXXX.com”  The specified network name is no longer available.”

In addition, we are unable to join any XP workstations to the domain from this remote site.  We receive the same message of “The following error occurred attempting to join the domain “XXXXX.com  The specified network name is no longer available.”

Background information:

This problematic DC was “semi-functional” at one point.   By this, I mean it was built and DCPromo’d at our central office a few months ago but “sat around” until our remote office was built.  During the time it sat around, we had a DC fail at a different site.  (USN Rollback problem that required a forceful demotion & metadata cleanup)

While the DC was in transit to the remote site, we had an urgent need to get 50+ workstations up and running before the DC even arrived there.  They joined to the domain OK and users were able to login to the domain fine by us associating the subnet out there with our central office subnet (Active Directory Sites and Services)

When the DC was finally installed out there, the SYSVOL and NETLOGON folders would not share out.  We used Ultrasound, Sonar, FRSDiag, etc. to troubleshoot but could not narrow it down.   We tried an authoritative restore of the SYSVOL, (D4) as well as a non-authoritative restore (D2) per MS articles, a fresh build of the box, and had our network engineers tweak both ends of the VPN tunnel from the central office to this remote site to no avail.   (BTW, all of our other remote sites are Point-to-Point T1 to/from our central office)  We’ve checked and cleaned up DNS, checked time syncronization, changed preferred DNS servers on the problematic DC and many other things and have made adjustments here and there to the routers on each end of the tunnel, but are now left with the errors listed at the top of this post.

We are able to ping all other DC’s and perform nslookups successfully from this problematic former-DC.   We believe it could be a DNS problem or a router related, but have no clue as to what specifically to check for.  (which ports are required to be open when joining workstations to the domain over a VPN)  Or how DNS should be setup when we have everything at the remote site associated with our central office’s subnet.   Users can login fine and when checked at the command prompt, (set logonserver) it does reflect that they are authenticating to our central office DC.   It’s just the workstations and this former DC we can’t join to the domain.   If we unjoin a workstation out there, and try to join it back to the domain we error with the above.  So we’re very hesitant to unjoin anything out there because we know it won’t rejoin.

Experts – can you please point us in the right direction?  We do not know if it’s a VPN problem, corrupt AD, DNS, etc.


Solution: DCPromo fails with “The wizard cannot gain access to the list of domains in the forest”; “The RPC server is unavailable.”

It’s a design decision and doesn’t really matter, but it had given easier single management if only having 168.192.in-addr.arpa instead one zone for each subnet.
Zone transfer isn’t related to the dynamic registration problem.
netdiag/fix will register the SRV-records, and isn’t necessary when the server isn’t DC.

Good point about DHCP as the DNS-registration process is done through the DHCP-protocol. The WAN-link neads to allow DHCP-traffic to be able to let the remote computer do dynamic registration. DHCP is using the ports 67-68 (UDP) and can temporary be enabled, but isn’t necessary when you get the remote DC promoted and running as DNS. Also check that the DHCP client service is started, as it’s the service responsible for DNS registration.

The reason for the problem with both DNS-registration and joining to the domain seams to be that the WAN-link doesn’t allow some necessary protocols/ports.
See http://support.microsoft.com/kb/555381 about what ports nead to be open for DC-replication to work over firewall.
When the new DC has been joined to the domain, you can change the DNS-zones to only allow secure updates to increase the DNS-security.