DCPROMO over Remote Desktop not working

[Gordon Fecyk]

I shipped out a server to a remote location last week. It arrived today and
after the on-site tech got it on the LAN I was able to connect to it and
finish the job.

Or not.

First I had a pile of DNS-related problems which I believe are now
resolved - this is a replacement server for one that died, and I spent an
hour cleaning out old entries in the AD and DNS for it (KB216498). DCPROMO
now gets as far as configuring the machine account for the new DC and says
"Cannot locate domain controller for this domain."

Argh...

At least it added the computer to the domain as a member server - something
it wasn't able to do for several hours until I cleaned up a lot of old AD
and DNS entries.

The last time I ran into something like this was when I was trying to use
xcacls.vbs to change some ACLs on remote shares. I could do it on the local
console but not on a remote desktop session, something about "network path
not found." I believe these are related. In both cases the
RestrictAnonymous settings were set strong (2) so only explicit access to
network resources was allowed - not browsing - depending on the application
or script used.

Anyone want to confirm or deny that using DCPROMO over Remote Desktop is
possible or even supported?

 

[Herb Martin]

First I had a pile of DNS-related problems which I believe are now

resolved - this is a replacement server for one that died, and I spent an

Anyone want to confirm or deny that using DCPROMO over Remote Desktop is
possible or even supported?

I do it regularly. DNS is likely you real problem since
most authentication and replication problems are really
DNS (if the network/hardware are basically functional.)

DCPromo of additional DCs is both an authentication and
a replication issue too.



DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[Dan]

Tried "DNSLint.exe" ?
Also check,
FSMO availability
DCPromoUI.log
DCPromo.log
Netsetup.log

..

 

[Gordon Fecyk]

OK, it's not a DNS issue anymore anyway. DCPROMO gets as far as:

completing a time synch,
examining existing Enterprise service,
creating the NTDSA object for the new domain controller,
and starts to configure the server account when it eventually fails..

Who wants to see the dcpromo log file?

 

[Gordon Fecyk]

Turns out the network adapter in the server I was attempting to promote
wouldn't adjust MTU properly.

We have some pathetic routers - Nortel Instant Internet 100s - that don't
allow for MTU adjustments in IPSEC tunnels. I found it odd that quick
directory listings of netlogon, etc would work, but longer listings
wouldn't. Until I tried ping -f -l tests anyway.

The only thing that changed between the old system and the new system was
the hard drives, and the LAN card - I asked for a Win2K compatible card just
in case they couldn't get the existing LAN card working. I wish they chose a
better LAN card than a D-Link DL-538TX. I ended up hacking the MTU setting
on all three servers - that alone allowed dcpromo to finish.

I now have some DFS replication issues that I think will sort themselves out
once the directory's fully replicated on the replacement server.