Win2k client cannot find domain controller name after domain upgrade

[dmandell]

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

 

[dmandell]

One more thing I forgot to mention. I was able to remove this computer from the domain, delete it's domain account, and remotely re-add it to the domain without problem.

 

[brontosaurus]

Hi Dana, just want to make sure I'm following you. One machine has this problem when using the VPN, but the other machine's problem goes away when using the VPN?

 

[dmandell]

Close.
Our home office users have hardware firewalls with a firewall to firewall IPSEC VPN running. As a backup, if that ever should fail, we have the Microsoft PPTP VPN setup on the user's computer that can be started.

The errors happen when using the firewall VPN, but only after we moved to AD domains.

It's really odd. I don't think it's the firewall. It's already patched to the latest OS, and there are some settings that were added to fix known NetBIOS issues related to packet fragmentation, but they are all set as well.

As I said, the machines have no trouble registering in both DNS and WINS. I even added the \0x1b entry to the LMHOSTS file just to make sure there was no question what was the domain. (As seen in Q180094)

I'm sending the user with the indefinite hang (wouldn't you know, our legal council!) another laptop to see if it's some odd specific OS issue and will have an answer if it works tomorrow morning.

Thanks for any thought you may have.
Dana

 

[brontosaurus]

Try editing the local HOSTS file as well (these are W2K clients, right?). I've seen errors like this before, and sometimes it's fragmentation (as you stated), but it seems that DNS info just isn't getting to these clients in a timely manner.
Anyway, I'd be interested to hear if another machine makes a difference, so let me know.
Thanks
Bronto

 

[dmandell]

I can try adding entries to local HOSTS for grins, but forward and reverse nslookup queries to all internal servers do resolve correctly from these Win2k workstation computers.
Thanks, I'll let you know the outcome.

Dana
P.S. I did run into a similar "hanging" on profile load issue with a win2k workstation yesterday, but the user had just put in some other DNS entries that caused it, and the eventvwr logs showed a different error anyway.

 

[dmandell]

Bad news, A freshly installed laptop computer sent home with the user for testing, exhibited the exact same behaviour from his location.
I'm stumped. I guess I can try posting on the Netscreen forum and see if anything turns up (we are using all netscreen firewalls.)
Dana

 

[brontosaurus]

Good Idea. I know you don't think it's the firewall, but obviously, this points to it. Can you get any debugging on it? Might be a good idea to start a debug, log to the console, and fire up one of these affected machines...

 

[dmandell]

Well, so far no go. Replaced the Netscreen firewall, replaced the netscreen firewall software with a newer version, replaced the laptop with a different computer and Windows installation, still no go. Any computer from his location exhibits the same issues.

This user has SBC DSL with PPPoE assigned IP.
This only started to happen after upgrade to AD.

Still a stumper.
Dana

P.S. the computer with the 30 second "hang" is now working after netscreen OS upgrade, but the installation with the indefinite hang is still at issue.

 

[brontosaurus]

wow...question though...what happens if you bypass the user's home firewall and connect via the MS PPTP VPN?

 

[dmandell]

It works fine!
(The user is, of course, using a cached password for domain authentication until the PPTP VPN is started)

Dana

 

[brontosaurus]

yeah, the cached password thing is fine...now, that's good news (right?) as I believe it provides more evidence that the firewall is at issue? It would be great if you could get a packet trace going during logon attempts...

 

[hewissa]

An intersting thread...you guys must me replying all at once! I to was going to suggest the direct PPTP connection. As it turns out, as Dana has mentioned it worked.

Is the MS PPTP VPN connection being made to the firewall on the domain side or to a VPN server? How is the Firewall set to resolve authenticated users? Are you using Radius or IAS?

Hewissa

MCSE, CCNA, CIW

 

[dmandell]

The PPTP server is a Win2k box running RRAS and static NAT throught the firewall to a routable IP. It is authenticating against the user's domain account.

The ipsec VPN is firewall to firewall.
We have pretty strict outbound rules for the firewall, but this sould have no effect as all traffic to the domain would be over the VPN. The only thing I can think of at this moment, is that because the client side gateway IP for the VPN is dynamic, the firewall-firewall VPN is setup in such a way that the tunnel can only be initiated by the client side. Once open, the tunnel is, of course, two way.

If during the whole AD authenication and registration process, any of it requires the session to be initiated by the server side, it could be an issue.

Other firewall users that are setup with static addresses (instead of PPPoE) do not have this problem. Will be able to test another PPPoE connection tonight or tomorrow to see if the same issue exists.

Dana

 

[dmandell]

OK, well, I found the cause, and the solution, but not the reason for the cause! (does that make any sense?

This user, like many others, but not all others, has his home directory mapped (H: drive) in his logon profile.

As soon as I removed the mapped drive from his user profile, the indefinite hang on loading his "user settings" while remote, went away!

I then re-added the same mapped drive back to his profile and had the user login from home multiple times with no problems.

The only guess I have is that something got corrupted in his profile during the migration from NT to AD.

The only other clue that I have is that I saw everything correctly going over the VPN tunnel except UDP PORT 389.

Anybody know what UDP PORT 389 is used for?

As soon as I reset the mapped drive in the user profile, UDP PORT 389 is now properly flowing too.

Thanks for all of your ideas. I guess sometimes it's more simple than one might think. Just like I tell the users; "Is it plugged in?"

Thanks,
Dana

 

[hewissa]

Not exactly sure about UDP port 389...I think it is used for LDAP.

Glad to hear you got it going...I'll keep how you resolved this in mind.

Hewissa

MCSE, CCNA, CIW

 

[dmandell]

Arg! Wouldn't you know I guess this is a symptom of the problem, but not the problem itself. The issue came right back!

If I leave the home directory mapping out of the user's profile, it's not an issue.

I'm starting to wonder if it is the ISP now, because any hardware or software that I provide to the user at that location has the issue. (but forget about dealing with Pacbell DSL (SBC) these guys don't seem to know how to tie their shoes) Anyone that knows anything has already been layed off!

This user at a different location does not have the issue, and other users setup the same way at different locations do not have the issue.

The only thing I have not tried is having the user log on as a different account from the same location. Worth a shot, I think.

Dana

 

[jallman1]

Did you ever find out if this is indeed an ISP Problem? How is that possible if all the traffic is encrypted inside a VPN tunnel. I am having the exact same problem with an ISP in france (You think Pac Bell is bad, at least they speak english!) We are using a Cisco Pix 501 which VPN's the french office network into our corporate network in the states using IPSEC, similair to what you described. I cannot get workstations to log on to the domain, unless you wait about 15 minutes for the logon to proceed. The software VPN client works great. I also cant get a domain controller set up in that office, DCPromo constantly fails. The symptons sound very similair, and I would greatly appreciate anything you have found out.

 

[dmandell]

Hmm, it sounds like a different issue.
I did not bother to persue it with the ISP, as it only affected one user and removing the static mapping in the profile solved the issue.

Sorry I could not be of more help.
Dana

 

[iamapollo]

Hi All

Came in late, but I think it is definately a windows 2000 domain issue because I have seen this issue in an internal network and similarly I found the only fix was to untick the mapped drive in the logon profile. I had this problem in a windows 2000 domain with all the win2k and xp clients but not with the win 95/98 and nt4 clients.

Port 389 has to do with active directory and can conflict with Exchange 5.5 as they use the same port number. Do you have Exchange 5.5?

I never resolved it completely except to update all the profiles on infected machines so they weren't mapped. Can do the same thing with a script instead without the problem. It seemed like some security issue related to the higher security in windows 2000 and above, maybe kerberos related.

I eventually upgraded the network to Windows SBS2000 server and now do not have the problem, if resolved would be interested to know though. Another question, is this a single server domain? as Microsoft said that could have been an issue as the one box was running everything.

Michael