Looking at the Forums, I noticed a significant number of people complaining about slow logon speeds. This can be irritating at the best of times. However, I always have the feeling that home time is a more valuable time given our crazy pace of life.
So, if you are struggling with slow logons from home, consider the following:
Is your laptop in a domain?
Does it have wireless?
Does your home network IP Addressing Scheme overlap with your corporations IP Addressing Scheme (e.g. RFC 1918 addresses 10.x.y.z, 127.16.y.z - 172.31.y.z; 192.168.y.z)
If the above are yes, yes & yes, then try disabling your wireless card on your laptop while you are booting it up and logging on from home. Only turn on your wireless once you are logged on.
After a successful domain logon, information is cached; this means that later a user can log on to the computer with the domain account even if the domain controller that authenticated the user is not available. Because the user has already been authenticated, Windows uses the cached credentials to log the user on locally. For example, if a mobile user logs on to a portable computer that is a domain member with a domain account and then takes the portable computer to a location where the domain is unavailable, Windows will attempt to use the cached credentials from the last successful logon with a domain account to locally log on the user and allocate access to local computer resources.
Why should I do this? : Your laptop is looking for a Domain controller to logon to. This is why it is taking ages to logon. Let’s take a quick look at the logon process for a user logging on to a machine which is a member of a domain:
When you try to logon, the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service which in turn implements the Locator DsGetDcName API call.
At work, the client collects the information that is needed to select a domain controller, and then passes the information to the Netlogon service by using the DsGetDcName call. However, when you are at home, this information is not available and the client will attempt using cached information about the previously known Domain Controllers.
At work, the Netlogon service queries DNS by using the IP/DNS-compatible Locator - that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and "A" records from DNS after the domain name is appended to the appropriate string that specifies the SRV records. However, at home, it is HIGHLY unlikely that your ISP knows anything about your organizations internal Domain Controllers. Additionally, this is a potential security vulnerability in that you are effectively telling your ISP which Active Directory domain you belong to.
At work, the Netlogon service sends a datagram to the computers that registered the name. However, these Domain Controllers are not contactable from home and more dead time is caused.
At work, each available domain controller responds to the datagram to indicate that it is working and returns the information to DsGetDcName. At home, this is just dead time.
The Netlogon service caches the domain controller information so that subsequent requests do not need to repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory. At home, it is these cached credentials which allow you to log on eventually.
To test that you can contact a Domain Controller for your Domain, run the following command:
Note: This will only work when you are at work. At home, it will not find a DC. If it does, you have serious security issues…
Something else worth mentioning – Windows XP Fast Logon – This allows an XP Machine to log a user on by default using cached credentials. However, if you have a roaming profile or if the Network Admin has included a logon script in your usre Active Directory account, Fast Logon is disabled.
How Interactive Logon Works -
Windows XP Fast Logon -
Group Policy Processing -
Hope this helps,