Member Avatar for troverman

I'm at a loss...leave work on Friday, everything is working fine. Some time over this last weekend, a problem develops...none of our XP Pro Workstations can connect to our domain network when they restart on Monday, and our Server 2003 with Exchange 2003 can't either. All of these systems cannot seem to find our DC server...also a Server 2003 machine. However, all of our Windows 7 Pro machines connect to the domain network just fine and are able to access all netowrk resources and shares (except email, of course). Nothing to interesting in the event logs. We run a virtual machine (Hyper-V) environment on a 2008 Server Host. There is only one DC. Exchange server will start up (after about 35 minutes of applying settings, etc) but Information Store, MTA Stacks, and System Attendant will not start. I think DNS is OK as well, but not totally sure what I should be looking for there.

  • 1 Contributor
  • 1 Reply
  • 347 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by troverman

Dani AI

Generated

Thread starter later reported the problem was resolved. The checklist below is a compact, practical post‑mortem for anyone who sees a Server 2003 / legacy‑client "cannot find domain controller" failure: focused diagnostics, quick commands to run, and short prevention tips so the cause can be found faster next time.

  1. Confirm basic networking and DNS on the affected machine(s). Run:

    ipconfig /all
nslookup <your-domain>

    Ensure the primary DNS server is an AD/DNS server for the domain and the DNS suffix is correct (Active Directory service location depends on correct DNS/SRV records). (learn.microsoft.com)

  2. Verify the client can locate a DC and that the secure channel is healthy. From the client or server run:

    nltest /dsgetdc:yourdomain
nltest /sc_verify:yourdomain

    Use these to confirm the DC returned by DNS is reachable and that the machine’s secure channel is valid. (learn.microsoft.com)

  3. Check DC and DNS health with DCDiag (run on the DC):

    dcdiag /v
dcdiag /test:DNS /s:<DCName>

    These tests verify DC discovery, LDAP/RPC binding, and SRV/A record registration used by clients. (learn.microsoft.com)

  4. Test RPC/endpoint mapper connectivity (RPC is used for many AD operations). From a client:

    portqry -n <DC_IP> -e 135

    PortQry shows whether the RPC endpoint mapper responds and lists dynamically assigned RPC ports for services. (learn.microsoft.com)

  5. If services (for example Exchange) fail to start or hang while “applying settings,” check Exchange/DSAccess logs and Netlogon/DNS registration. Use net stop netlogon && net start netlogon and ipconfig /registerdns, then review MSExchangeDSAccess / MSExchangeSA events to see topology/DSAccess errors. (learn.microsoft.com)

Quick notes on prevention and firewalls: older Windows (2000/XP/Server2003) use a low RPC ephemeral range (1025–5000) while Vista/Server2008+ use 49152–65535; mixed environments or perimeter filters must allow the correct ranges and TCP 135 for RPC endpoint mapper. Open/whitelist the needed ranges or limit RPC to a defined range on servers. Also run dcdiag regularly and avoid a single DC as a single point of failure. (learn.microsoft.com)

If those checks are clean but authentication still fails, capture a short network trace (RPC errors and TCP resets reveal filtering) and escalate with the DC logs and PortQry output attached. (learn.microsoft.com)

Member Avatar for troverman

Never mind, solved it. AVG Business edition started blocking RPC ports, preventing authentication. Just out of the blue - apparently the windows 7 machines weren't affected. All back up and running now.

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.