Slow network (AD) response.
We are having a problem where when you open "My Computer" it takes forever to populate the first time, subsiquesnts are fine. If you leave for a while and come back it may or may not happen again. Kind of like it's waiting for something. We have 2 drives mapped to the UK, if we disconnect them the problem goes away. This does not happen to everyone, and it seems if you create a net profile for the user that fixes it as well, at least for the short term. We also have a problem where runas takes just as long to come up and ask for credentials. I think they are linked, and I think it has something to do with the AD and maybe replication?
Justin Owens
It is just Windows XP machines which do this (Server 2003, Vista, Windows 7, etc. are all OK)?
Make 100% sure that your first DNS server for your network card is the IP address of a Domain Controller (a local one is best). If it is set to your router, you will encounter slow logons, AD queries, etc.
ASKER
Just XP's yes. The 7 and 2003-2008's do not seem to have the problem.
We have a Non DC DHCP server and 2 separate DC's running WINS and DNS for us. The DHCP serves the DNS server IP's to the clients. I have to say, all DNS tools and actions seem to run quick like a bunny.
We have a Non DC DHCP server and 2 separate DC's running WINS and DNS for us. The DHCP serves the DNS server IP's to the clients. I have to say, all DNS tools and actions seem to run quick like a bunny.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
We have DC's at each location, We find it odd that it happens some of the time but not all of the time. Removing the mapped drives will solve the "My Computer" problem, but it doesn't tell us why. Also we still have the runas problem, I think it is related. We have 2 DC's here, and those are what we use as login servers, I don't get why it takes so long to find one of them to authenticate for a runas.
When you have a mapped drive in Windows XP, it tries to enumerate it before displaying the request. A better use would be to have shortcuts to shares using UNC paths, as pwindell suggested. I won't go so far as to say they need to die the death of the dinosaurs, because there are some legacy apps which require drive letters, but I do understand his sentiment. An alternative is to use a registry hack to force XP to create all network connections before presenting the desktop. This would probably get rid of your issue, but it would slow down log in times as a trade off. Let me know if you are interested in that path, and I can tell you how to do that.
Justin
Justin
The runas problem you have is pretty much the same thing. It is just re-enumerating the path before it runs under the alternate profile.
ASKER
That's what I was thinking, but how do the paths enumerate, is there a way to see what the computer is doing when I make a request so I can track if it is failing at some point?
We have DC's at each location, We find it odd that it happens some of the time but not all of the time. Removing the mapped drives will solve the "My Computer" problem, but it doesn't tell us why. Also we still have the runas problem, I think it is related. We have 2 DC's here, and those are what we use as login servers, I don't get why it takes so long to find one of them to authenticate for a runas.
My posts answered all of that,...and cures most of it (not all is curable,...WANs "are what they are").
I still have a few mapped drives for the same reasons DrUltima mentioned, but none of them run over a WAN link. I couldn't kill all the dinorsaurs, but I killed all of them I could.
In the end both DrUltima and I are saying the same thing and basically just re-enforcing each other. But he replied first, he should get the points of any,..I'm not worried about points, I still have a stack of T-shirts I haven't even opened yet. :-)
My posts answered all of that,...and cures most of it (not all is curable,...WANs "are what they are").
I still have a few mapped drives for the same reasons DrUltima mentioned, but none of them run over a WAN link. I couldn't kill all the dinorsaurs, but I killed all of them I could.
In the end both DrUltima and I are saying the same thing and basically just re-enforcing each other. But he replied first, he should get the points of any,..I'm not worried about points, I still have a stack of T-shirts I haven't even opened yet. :-)
ASKER
I agree with you that is a fix, I was just looking for something deeper in, that's all. We have fixed a whole lot of problems recently, from Replication to DNS and beyond. Maybe we'll fix it eventually and not even know it. Thanks all.
A fix implies that something is broke. Nothing is broke,..it is acting exactly like it is expected to do with the methods you are using. As I said,...WAN links "are what they are",...so they,... "do what they do".
Use different methods as DrUltima and I suggested and you should be fine. Having DCs physically located where they should be and using Active Directory Sites & Services to make it "behave" properlyy is a must. That is what the AD Sites & Services was invented for. That covers the lag in authentication, which includes the lag in authenticatio when using "Runs As",...but the file execution that happens after the "Run As" is subject to the paragraph below if the WAN LInk is between the user and the Executable.
Beyond that pulling files across a WAN Link is always going to be "what it is". Coping a Files,...Opening a File,...Executing a File,...is effectively the same thing,,,it has to move the entire file across the WAN to perform the process and it is going to "take what it takes" due to the limited bandwidth of the WAN Link.
Use different methods as DrUltima and I suggested and you should be fine. Having DCs physically located where they should be and using Active Directory Sites & Services to make it "behave" properlyy is a must. That is what the AD Sites & Services was invented for. That covers the lag in authentication, which includes the lag in authenticatio when using "Runs As",...but the file execution that happens after the "Run As" is subject to the paragraph below if the WAN LInk is between the user and the Executable.
Beyond that pulling files across a WAN Link is always going to be "what it is". Coping a Files,...Opening a File,...Executing a File,...is effectively the same thing,,,it has to move the entire file across the WAN to perform the process and it is going to "take what it takes" due to the limited bandwidth of the WAN Link.
ASKER
I think there is more going on in the background than just that. I am going to keep investigating.