Member Avatar for dee101g

Platform: Windows Server 2008 R2 SP1 (Standard) for both host and VHD.

Use: Remote access for application. RDS uses both host and VHD to give separation for security in SMB environment.

Problem: DNS configuration was a nightmare here, and some issues may be part of that. The challenge, though, is that the VHD takes an inordinate time to connect to the host. I am concerned this will cause problems authenticating users (AD on host). An example of this is difficulty adding users to RDS because of not finding the domain (it looks like it is timing out because it does eventually resolve the list of user types on the domain to select from. Selecting any of these, again, does not "find the user" because the "domain is not found").

Any ideas on troubleshooting this? DCDIAG /V came back clean except for a reference to duplicate server / ip. NBTSTAT looks positive for that, but the name given only points to the domain.

I cannot add users until this is resolved but, more importantly, can't begin configuring RDS when users can't authenticate. Any ideas where to look?

  • 2 Contributors
  • 4 Replies
  • 304 Views
  • 1 Year Discussion Span
  • Latest Post Latest Post by dee101g

Dani AI

Generated

This thread documents a classic boot-time name-resolution delay that prevents a Hyper‑V guest from reaching Active Directory and completing RDS user lookups. ’s eventual reinstall indicates the problem was persistent; ’s pointer to Microsoft forums matches known Hyper‑V / DNS startup interactions. Below is a compact, prioritized troubleshooting approach and quick checks that were not detailed in the replies.

Checklist (run these in order and note timings)

  • Confirm the VM’s primary DNS points to an internal DC (avoid public DNS as primary) and that no stale hosts file entries exist.
  • Verify SRV and A records for domain controllers and reverse lookups; replication delays or scavenged records can cause lookups to timeout.
  • Check time sync on host, guest and DCs (Kerberos fails when clocks differ).
  • Inspect Event Viewer on both host and guest: System, DNS Client, Netlogon (guest), and Hyper‑V logs (VMMS, Worker).
  • Confirm the virtual switch type and VLANs — a mis‑configured switch (NAT/isolated) can delay AD reachability.
  • Ensure Hyper‑V Integration Services / VM NIC drivers are current and no MAC/IP collisions exist.
  • Temporarily disable advanced NIC offloads/checksum offload on the physical NIC to rule out driver offload issues.
  • Capture a short packet trace on the host virtual switch to see DNS/SRV/LDAP timing and retransmits.

Quick command set for initial evidence

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com
nltest /dsgetdc:example.com
w32tm /query /status
netdom verify %COMPUTERNAME% /domain:example.com

Notes and cautions
Make DNS and NIC changes during a maintenance window and document original settings. Reinstallation works but is last resort — capturing DNS/SRV timing or a short packet trace usually shows whether the delay is DNS, time sync, virtual switch, or driver related and allows a targeted fix without rebuilding.

Recommended Answers

All 4 Replies

Member Avatar for jingda

Hope you have your problem resolve soon, if you need more help just post. Good luck :)

Member Avatar for dee101g

Ended up reinstalling server.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.