Problem with Slow logon after entering username and password in Active directory environment (W2K3)

Also are the laptops connecting via wireless? If so the download speed is obviously going to be a lot slower than using a desktop machine connected via the wired network.

Also are the laptops connecting via wireless? If so the download speed is obviously going to be a lot slower than using a desktop machine connected via the wired network.

The laptops support Wireless connection, but in this particular problem are logging in connected via copper cable.

The slow logon exists even if they are disconnected from the network


thanks,

Mark

Check the size of the user profiles on the local Documents & Settings folder.
Also check the environmental settings under properties of my computer advanced to see if there are any network paths in here that no longer exist?

By the way, we don't user roaming profiles

OK, can you check for path entries for UNC names or network locations that no longer exist?
This will slow logins down

how many dc's do you have in your ad environment? is your DNS 100%i ntegrated with AD?

and wich os are you running on the laptops??

are you using static or dynamic ip-add, on your dc and dns???

This is a DNS problem.  You must do the following:

-  Your W2k3 server must be the ONLY DNS server listed on the client's network cards

-  Your W2k3 server, must be listed as it's own DNS server, and no external servers, on the servers loca area connection.

-  Then in your DNS server snap in, configure your DNS server for forwarders to the external DNS servers.  You must set it to resolve all internal requests itself, and then forward all else to the external DNS servers.

This is of course assuming that this is the only DC in the domain, and the only local DNS server in the domain.  

The reason why it takes so long if you have external DNS listed on the clients is, when the clients attempt to resolve authentication information at logon, the request is attempting to use external DNS servers first, to resolve authentication, which takes forever to fail, and then finally going to the internal server.

I am not convinced it is DNS if it were then you would also be experiencing lots of other issues, explore tha path options from a command prompt type PATH and hit return, are there any UNC names in there?

I also had a case a few months ago when a lot of machines were updated from wayback they received another tab when you right cluck on properties of network card there is an authentication tab and the check box to use smartcard and IeEE 802.x were enabled and for some reason this impacted on performace, if your not using smartcards try unchecking this box and see if it helps.

We'll see I guess, but I am betting DNS all the way.  Incorrect DNS configurations are the number one cause of all MS related network problems.  Most admins will put external DNS on the clients, so their users can still get the Internet in the event the internal DNS server goes down.  This almost always causes slooooooow logons.  Since he is not using roaming profiles here, incorrect DNS is most certainly the problem.  Keep it local, and use forwarders on the DNS server.  

I agree and most networks that have been configured correctly will be setup as you describe.

However if it was a DNS problem it would have always been there and wouldn't have happened suddenly but also it wouldn't effect laptops when they are nit attatched to the network as DNS doesn't come into it.

The reason I am discounting DNS is because the requester has advised they are not using roaming profiles so nothing is being loaded from servers it's all local.

I think the UNC path in the environmental settings is the way to go especially as it happened since a new piece of virus software went on as this is probably updating from a server and maybe put a Inc path in the search path which is probably unnecessary.

I see what you are saying, but it seems any request that is to the local network is slow.  The Outlook clients are taking a long time to connect to Exchange.  I would think that is because they are not easily resolving the internal exchange address.  In addition Trend Micro worry free biz security clients are controlled server side, so again they could be looking for an internal server address but the DNS is sending them outside first.  If he has network drives mapped, they too will cause a performance problem until they can reconnect....

The requestor did not specify if he changed any DNS settings recently.  It is possible he had his head bashed for the clients losing the internet connection, during an internal server outage, and he changed the settings.  : )  who knows, but we shall see ....

Hi,

Thanks for the comments / discussion. Here is some additional information:

1. Active Directory with 2 DC's
2. DNS installed on each DC
3. Clients have Windows XP installed
4. Exchange 2003 installed on its own box (application server)
5. Each client gets its network information through DHCP
6. DHCP only provides private network settings; e.g. no public DNS, etc.
7. DNS appears ot be configured properly and does not seem to be the issue

Well refer to what Dmatzter said then.

Take a look on the dc's event-viewer probably I will recommend that you check the GC (global catalog) DC event-viewer and one client that have the problem.

I prefer to check the following stuffs.

1) To make sure that authentication is fine, you should try running as program using runas from command prompt without loading profile. If that happens within few seconds (I see <10 sec usually, authentication part is fine)

2) Makesure that DNS is fine and the entries for ldap,kerbros and all are pointing to the correct DCs.
Also, I prefer to clear the DNS cache - some times DNS will get affected with DNSPoisioning.

3) Connect a laptop on the same switch which has a DC and configure manual IP address and DNS pointing to that DC. Try logging in and see the perfomance. This is to make sure that the network is absolutely fine.

4) Run netdiag and dcdiag on DCs. Just to make sure that everythign is fine.

5) Make sure that netlogin share is properly accessible from desktops. Also, disable any Grouppolicy just for few hours - to test the perfomance.

Hope this help.

Cheerio
Shaba

try this real quick, assign the main dns server ip as a static in client machines, see if the speed improves or not.

That is a good call cirlare, as I am still convinced this is a DNS issue.  Using DHCP from the server "should" work but I would always set static information client side, especially the DNS.  

Also make sure you have your forwarders set correctly in the DNS server, and that the setting "DNS domain" in the forwarders tab is set to  "all other domains."

Then make sure you flush dns client side and server side, on all stations, or at least the ones you are testing until you get the fix.  

Hi Guys, there shouldn't be a problen with DHCP assigning DNS servers, I would hate to install static addresses on all of the machines at some of my clients (1200 is the biggest)
The requester has already stated that all DNS is working so we need to look somewhere else.

I am going with the UNC names in the path!

There shouldn't be a problem with DHCP, but maybe there is.  It can't hurt to test static on one client, and see the results.  If the issue happens to resolve on that client, then he can TS his DHCP server, and / or assign statics manually.  

I am  also curious to know what kind of errors / warnings are showing in your event logs during the log on sessions.  

Hi,

I have checked the event viewer on the local pc as well as the DC's (two of them). all are clean.

So I decided to do the following:

1. Rebuild a laptop (Dell Latitude D430) from scratch.
2. Install windows XP with SP3
3. Install Office 2003 SBE, Acrobat 7.0 standard, Winzip 8, Smart Sync pro, and our VPN client
4. Configure system to connect to wireless adapter
5. Connect to network via enternet cable

I did these steps with the Ethernet cable and logon time before disk stopped turning was 20 seconds.

I did the samething with the network cable disconnected (no communications to LAN) and it took almost two minutes ot complete the logon process. The system is searching for the domain and obviously can't find it.

Does anyone have any suggestions on how to speed up domain search when systems is offline?

My next test will involve install anti-virus software and see what impact it has on the logon process.

Thanks,

Mark

What I really want is for the laptops to be able to log on in cached mode - i.e. they do not search for the domain.

Each user is a domain account, and has  a network logon script which maps a drive.

For remote users, I would like the system to logon them on in cached mode.

They might have a network connection from save a public wifi or even their personal home network. They do not have a connection (cannot communicate) with domain at this point.

Is there anyway at all I can prevent the search for the logon domain when it is not availalble (whenthe local computer detects any network connection)? Seems odd that Micrososoft would not have a value to delay the d0omain logon and go immediately to cached mode

Thanks,

Mark

You may want to have the laptop users sign onto "this computer" option at the logon screen instead of the domain, when they are away from a location that is unable to contact the domain controller.

Thank you for your ideas. Your comments were very helpful