Situation:
recently upgraded from NT domain to AD domain.
All computers and users in the same domain, site, etc.
Using Win2k DNS as primary (non AD integrated)
Using Win2k WINS servers.
Almost all clients working correctly. A few remote clients are having issues.
1. Remote Win2k computer connected to main office through 3DES firewall to firewall VPN.
Bootup computer and user logs in. There is a hang on loading the users perrsonal settings for 30 sec. or so. The following error shows in the client's event log.
Windows cannot obtain the domain controller name for your computer network. Return value (59).
This error presents itself in the log twice, one when the computer boots up and tried to reach the domain and also when the user tries to log in.
What works:
Access to file servers, shared directories, windows browsing, Exchange server access, internal DNS resolution, internal WINS resolution.
What I have checked.
DNS correctly registers on the server for this client in both forward and reverse zones.
WINS registers correctly for this client in WINS database.
What I have tried:
Checked DNS and WINS settings for correctness.
Setup lmhosts file with (domain and server settings)
(reset DNS and WINS cache on client)
remove and reinstall net card drivers
remove and reinstall TCP/IP
Refreshed service packs
This seems trivial, but there is a second client computer (laptop) that is exhibiting the same issue, but it will hang indefinitely while trying to load the user's "personal settings" (instead of just 30 seconds.) If the network cable is unplugged, the user login process completes (with eh same error in the logs) After plugging back in the cable the user then has access to the LAN, but not most Microsoft services. Here's the odd thing, if the user then starts a Microsoft PPTP VPN to our VPN server access to all services is available.
If this user plugs directly into the main office LAN with his laptop. (comes in to the office) the computer and access works correctly without error. These errors only started happening after the in place AD domain upgrade.
Anyone seen this kind of errors before?
Thanks, Dana
recently upgraded from NT domain to AD domain.
All computers and users in the same domain, site, etc.
Using Win2k DNS as primary (non AD integrated)
Using Win2k WINS servers.
Almost all clients working correctly. A few remote clients are having issues.
1. Remote Win2k computer connected to main office through 3DES firewall to firewall VPN.
Bootup computer and user logs in. There is a hang on loading the users perrsonal settings for 30 sec. or so. The following error shows in the client's event log.
Windows cannot obtain the domain controller name for your computer network. Return value (59).
This error presents itself in the log twice, one when the computer boots up and tried to reach the domain and also when the user tries to log in.
What works:
Access to file servers, shared directories, windows browsing, Exchange server access, internal DNS resolution, internal WINS resolution.
What I have checked.
DNS correctly registers on the server for this client in both forward and reverse zones.
WINS registers correctly for this client in WINS database.
What I have tried:
Checked DNS and WINS settings for correctness.
Setup lmhosts file with (domain and server settings)
(reset DNS and WINS cache on client)
remove and reinstall net card drivers
remove and reinstall TCP/IP
Refreshed service packs
This seems trivial, but there is a second client computer (laptop) that is exhibiting the same issue, but it will hang indefinitely while trying to load the user's "personal settings" (instead of just 30 seconds.) If the network cable is unplugged, the user login process completes (with eh same error in the logs) After plugging back in the cable the user then has access to the LAN, but not most Microsoft services. Here's the odd thing, if the user then starts a Microsoft PPTP VPN to our VPN server access to all services is available.
If this user plugs directly into the main office LAN with his laptop. (comes in to the office) the computer and access works correctly without error. These errors only started happening after the in place AD domain upgrade.
Anyone seen this kind of errors before?
Thanks, Dana