Can't map drive after AD upgrade

[Shakedown 0]

We just upgraded one of our NT4 domains to W2K. We are currently running in a mixed mode as we have not migrated all domains yet.

 

We are having issues with users VPN'ing into the network. We are using Nortel's VPN solution, but that is not the problem. The problem is that users that were joind to the NT4 domain and not in the office for the migration can no longer map drives. They get an error that NO LOGON SERVERS ARE AVAILABLE TO PROCEESS THE REQUEST.

 

What is very strange is that it is sporadic. The users this is happening to very rarely come into the office and therefore are not connected directly to the LAN. They can connect to the Exchange server without issue.

 

At first we thought it may have been a router issue and had the user upgrade the firmware on their local router. Thius fixed the problem for some users but not all. I actually had 2 users on the same network and after the router upgrade one was fine but the other still could not map a drive.

 

This has been an issue on DSL, CABLE, and dial-up with AND without a local router present. There is no definate setup that this problem occurs on.

 

Users on a domain that has not been migrated yet are having no problems. It sounds like an authentication problem, but since the symptons are sporadic it is difficult to say exactly.

 

Has anyone else had this problem?

[duhmez 0]

Try this. Delete their machine account, then have them leave and ejoin the domain.

[Shakedown 0]

Tried that and problem still exists. Also, once they are removed from the domain and readded their cached account info is not there anymore so they still can't log in using the domain. They are able to log in locally, but then they are not able to change their domain account password when the time comes.

[clutch 1]

One of your DCs could be having difficulties replicating with the others. The intermittent failure would then come from people hitting the failing DC, which bombs out. When they try again, they might contact one of the others and get properly logged on. Check the logs and see if replication is occurring (NTFRS) between all of the controllers before you delete the machine accounts. It could be that the VPN solution is on a segment that is favoring one particular DC, and that one is not replicating properly. Also, make sure that the NETLOGON service is running on all of the DCs. The machine might be passing the existing cached credentials on the laptop to the Exchange server, and thus able to be validated.

 

Other areas of concern could be misconfiguration of Group Policies. Here's a good article on things to avoid:

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;823659

[clutch 1]

I had to dig up the command, but have the user try:

 

set logonserver

 

from the command prompt. It should return what DC he/she is connecting to. If the issue is occurring with the same DC, then you might have a weak link in your AD.

[Shakedown 0]

Clutch,

Thanks for the responses. At least now I think I was on the right track.

 

I am a desktop tech for our company and it's sometime difficult to convince the NT Security group and/or the NT admin group that it is NOT a desktop issue

 

I will check those out in the am.

[Shakedown 0]

AS,

We have not implemented DFS yet. We are looking into it, but that wouldn't happen till we were in native mode sometime in May.

 

I have a meeting with others next week to look at group policies. After reading the article Clutch mentioned and looking at a totally default AD setup I found we have some strange policies set.

 

Supposedly the NT admin folks used the same policies set in NT 4.0, but even if that's true something is still wacky!!

 

Thanks for all the help. I will let everyone know what happens next week.

[clutch 1]

Quote:

AS,
We have not implemented DFS yet. We are looking into it, but that wouldn't happen till we were in native mode sometime in May.

I have a meeting with others next week to look at group policies. After reading the article Clutch mentioned and looking at a totally default AD setup I found we have some strange policies set.

Supposedly the NT admin folks used the same policies set in NT 4.0, but even if that's true something is still wacky!!

Thanks for all the help. I will let everyone know what happens next week.

Policy translation is a huge issue. I am an engineer working on a migration strategy for the Army from NT4 to 2003, and right now we are ironing out the policy setups. There are so many options that people seem to feel the need to configure all of them. We have seen most of the proposed configurations trash the lab, and now we are going to design one from the current production baseline (a small fielding of Windows 2000 AD to about 2000 users) and translating it for Windows 2003. If you need a good product for policy lifecycle management, you should check out NetIQ's Group Policy Administrator. It has a simulator that looks for many common configuration flaws, has a vault for checking in/out templates, can deploy to a test lab before production, spans multiple domains and AD environments, and so on. Version 4 is due out soon, and we are waiting for the RTM from Full Armor to make it through NetIQ to us.

[Shakedown 0]

No doubt. Policies can be like the registry. One wrong move and your network goes to poop!

 

Not sure if they looked into the Group Policy Administrator. I know we use NetIQ's AppManager Suite to monitor our servers, but have not had a chace to get very involved in it.

 

Thanks!!! I'll have to look into that.

[Shakedown 0]

Well, so far fixing Group Policies has not seemed to fix the problem.

 

Mind you I am new at Active Directory so I have another direction I would like to ask about.

 

When looking at a netdiag log from a user connected via VPN with this issue it shows that the DNS registration for the PC did not occur. Does the PC have to be registered in DNS to connect to servers in an AD environment? BTW, any PCs that are in WORKGROUP mode do not have this problem.

 

This problem has really gotten me confused. It is only occuring on about 5% of the 3000 remote users we have.

[clutch 1]

Um, yeah. All of your clients and member servers need to be resolved via DNS in order for them to be serviced. That is in AD 101. Now, a cheat for that is to have DNS perform WINS and WINS-R lookups. Say a client can't register itself in DNS, but it does successfully register itself with WINS. DNS can be setup to query the WINS db for the hostname, resolve it from WINS, and then tack on the remaining TLD naming info.

 

For example, you have a Win98 box that can't register in DDNS, but it shows up fine in WINS. A Windows 2000 client pings win98.yourdomain.com and the W2K DDNS box can't find that name in its DDNS zone. It will then subtract the ".yourdomain.com" from it, query WINS for "win98", get the IP, and then return ".yourdomain.com" to the name and resolve the IP. This is what I used to do with NT domains while setting up NT DNS. Enabling both WINS and WINS-R (Reverse) lookups will let you perform forward and reverse lookups (reverse lookups aren't typically mandated in AD, but proper Kerberos configurations require it).

 

I am not sure how your VPN works, but are you pointing the clients to the internal DDNS servers when they come on? Is there any way that you can reserve an IP for a specific client, and then manually enter that client name into DDNS for AD? If you can do that, you can then see if it's a resolution issue.

[Shakedown 0]

OK.

 

Here is what has worked so far:

Knowledge Base Article #244474 "How to Force Kerberos to use TCP instead of UDP" http://support.microsoft.com/default.aspx?scid=kb;en-us;244474

 

We still have DNS issues, but with this reg hack and the value set to 100 the users are now able to map drives without issues.

 

Thanks for all your input. It's a neverending learning experience