Member Avatar for Andrew Wiggin
Andrew Wiggin 0 Newbie Poster

Some of my WinXP laptops, after they have been undocked and booted into cached credentials far from home, take forever to log in when they get home - as ANY user. The slowness happens just after the user enters their credentials, but before the user log in process dialog pops up. So they are left staring at a grayed out log in dialog for several minutes.

This is what I have found:
- Disconnected from the network, the computer logs in speedily.
- If the computer is logged into, then logged out, then logged into again without shutting down it functions normally.
- If the computer is dissociated from the domain and then rejoined, it works fine until the computer is undocked and booted. Then when it is returned it is slow again.
- No abnormal slowness is apparent after log in.
- The first DNS server is the DHCP server and the DC. There are 4 others, 2 of ours on a pretty fast connection and 2 are our ISP's.
- Disabling the wireless network adapter for boot solves the problem, but my users aren't comfortable disabling and re-enabling their W-NICs every time they leave the office.
- Reinstalling the wlan card driver fixed the problem temporarily.
- The presence of preferred wireless networks or not does not make a difference - they use hard wire exclusively while in the office, but there is a wireless network they should be configured to connect to manually only.
- All the machines are using the latest updates, including the DC (Win 2k3)
- the users have both mapped drives and mapped printers - which are valid and on the same set of switches.

Edited by Andrew Wiggin because: n/a
  • 1 Contributor
  • 0 Replies
  • 222 Views

Dani AI

Generated

This pattern most commonly stems from domain-controller discovery or name-resolution timeouts combined with the laptop picking the “wrong” network interface at the moment Windows tries to contact the domain (authentication, Group Policy, mapped resources). Troubleshooting should focus on DNS/DC discovery, which is where multiminute stalls usually occur, and on which adapter Windows is actually using during the logon phase.

Helpful, quick diagnostic checklist:

  • Confirm what the machine is using for name resolution and interface configuration (run ipconfig /all and netsh interface ip show config) and remove any external/ISP DNS from client adapters so domain lookups go only to internal DNS servers.

  • Verify DC discovery with an SRV lookup or nltest. Example commands to try from an elevated prompt:

    nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com
nltest /dsgetdc:example.com

  • Inspect Event Viewer (System and Application) and the Netlogon log (%windir%\debug\netlogon.log) for Kerberos/Netlogon/Group Policy timeouts; enable Netlogon logging briefly to capture timings.

  • Force the wired NIC to be primary for logon (Network Connections → Advanced → Advanced Settings → Adapters and Bindings) or set clearer interface metrics so the LAN is used before any wireless adapter.

Practical remediations to try after diagnostics:

  • Ensure clients receive only internal DNS from DHCP and let internal DNS forward to the internet.
  • Prefer wired adapter binding order and/or disable automatic wireless association during boot.
  • Update WLAN drivers and vendor utilities (use either the vendor tool or Windows Zero Config, not both).
  • Make printer/drive mappings resilient (GPO preferences or non-blocking scripts) to avoid long synchronous timeouts at logon.

Capture timestamps from Netlogon and the System log to see exactly which operation is waiting — that will point to the specific timeout to eliminate.

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.