Trench Tales (Part 2) – Troubleshooting Slow Logons

If you would like to read the other parts in this article series please go to:

Introduction

This series of articles leverages the expertise of IT pros from around the world who have shared their stories with me through my role as editor of WServerNews, the world’s largest newsletter focused on system admin and security issues for Microsoft Windows Servers, and also through several other channels such as my connections with IT pros through my activities as a Microsoft Most Valuable Professional (MVP). These stories have been edited for length and clarity where needed.

Tip:
If you haven’t subscribed yet to WServerNews you should do so today!

Lengthy Logons

To set the stage for the stories that follow, you should begin by reading my editorial Lengthy Logons in the January 23, 2012 issue of WServerNews. Then read the From the Mailbag section of the January 30 issue where some newsletter readers respond by sharing their own tips for troubleshooting slow logons. Some of the stories readers sent me however were too long or detailed to include in my Mailbag column, so here is a selection of them for your education and enjoyment.

RUP/FR and the Application Data folder

A reader named Steven shared the following story with me:

On the subject of the lengthy logons, I think the Roaming User Profile (and its brother file synchronization) deserves more than a mention in passing. In my previous life as a network administrator, we always used roaming profiles for our users and redirected their Desktop, Start Menu, and My Documents folders to network shares (and aside this is a great way to control the icons/programs available to users but I digress). We sometimes noticed that user logins would take considerably longer than normal and determined the cause was the file synchronization process that occurs during login (and logoff but again I digress). We always left the Application Data folder in the user’s local machine profile but the problem is some programs would put their temporary/application data files under the user’s My Documents folder. Over time these could build up to a large number of files and cause a dramatic increase in login time due to the file synchronization process between the local and remote profile. Once we determined this was our problem, a simple addition to our login script to remove the offending files easily corrected the issue.

What are some lessons can we learn from Steven’s story?

  • Watch for any unexpected growth of the Application Data folder when implementing Roaming User Profiles (RUP) with Folder Redirection (FR).
  • Issues with slow logons when using RUP/FR deserve more treatment, so look for a discussion of this matter in a future issue of WServerNews.

Note:
For a detailed explanation of the differences between the two Application Data folders in Windows XP user profiles and the AppData folder with its three subfolders in Windows Vista and Windows 7 user profiles, see Chapter 15 of the Windows 7 Resource Kit from Microsoft Press.

Don’t Ignore Slow Logons!

John, a programmer analyst from the UK, describes how he works around the issue of slow logons due to RUP being used in his company environment:

We have the slow reboot problem here where I work. At least part of the issue is down to the roaming user profile issue, as the majority of users in our organization have thin clients. A few of us, including us programmers, still have actual pc’s but the ICT department seem to be unable – or unwilling – to exclude us from the roaming profiles. I eventually became so frustrated with their inability to fix our problem that I now disconnect the computer from the network every time I have to reboot. Not a very satisfactory solution as it prevents a number of things in the group policy from running, but it works for me.

What are the lessons we can learn from John’s story? Well first, we can probably conclude that if roaming isn’t implemented properly in your environment, your users may get so frustrated that they may try to find ways to work around slow logon issues. The result may be that Group Policies might not get properly applied to their computers, which can result in various other types of issues arising. So from an IT perspective, the lesson here is to take any issue of slow logons very seriously and try to resolve these issues as soon as possible!

Search the Knowledge Base!

Bengt, the IT-Chef (I assume that means “IT Chief”) for a Swedish company, shared the following:

KB2525332 has a hotfix that specifically addresses the combination of folder redirection, off-line folders and slow logons for Windows 7. We had a few machines that took 15 minutes to sign on to the network (but started offline in 2 minutes). And yes, they already had SSDs! After the hotfix was applied it changed logon time to 10 seconds (from 15 minutes both times clocked!).

What are the lessons here?

Check your DNS/DHCP Configuration

Finally, reader Dave from the USA shares in detail how your DNS and DHCP settings in a Small Business Server (SBS) environment can be responsible for any slow logons your users might be experiencing:

As an IT service provider for many small offices over the last ten years, I have often experienced this (long-to-very-long login times) in a Small Business Server domain environment. One of the first things I look at, which often makes a dramatic difference, is how DNS and DHCP are configured on the Small Business Server, on the gateway router, and on client workstations.

In a nutshell, performance is best if the Small Business Server is configured to provide both DNS and DHCP services on the network. DHCP services on the gateway router should be turned off, but the router’s DNS services should remain active. The DHCP server on the SBS machine should be configured to provide its own LAN IP address to DHCP clients as the Preferred DNS server, and to provide the gateway router’s IP address as the Alternate DNS server. The gateway router should have its DNS forwarder entries pointing to public DNS servers, preferably high performance ones (e.g. Google 8.8.8.8, OpenDNS 208.67.222.222). All client machines should be configured to obtain both IP addresses and DNS server settings from the SBS DHCP server. The Microsoft DHCP server provides much more flexibility than most routers, and using it can have major impact, reducing configuration and maintenance efforts in some increasingly common scenarios (e.g. by using DHCP Option 66 to provide the local IP PBX server address to IP telephones for automatic configuration). If the DNS settings on the client machines are configured manually, the Primary DNS server should be set to the IP address of the SBS server and the Secondary DNS IP address should be the gateway router’s local IP address (though you would not want to configure DNS manually on a laptop computer that leaves the office; if you did so, however, then you would be best off setting a public DNS server as the Alternate DNS server).

But I have quite often found that the gateway router is set up to be the DHCP server for the network. Hopefully, the DHCP server on the SBS machine has not also been turned on as it’s VERY important to be sure that you only have a single DHCP server active on the local network, unless you have a good reason for it and know what you’re doing. In this case (router is the DHCP server) it is also VERY important for the router to provide the IP address of the SBS machine to its DHCP clients as the Primary/ Preferred DNS server. As for the Secondary/Alternate DNS address provided by the router’s DHCP server:

1) If the DNS settings on the router are NOT separately configurable for a) the DNS settings it provides to DHCP clients and b) the (public) DNS servers used by the router’s own DNS forwarder, then the Secondary/Alternate DNS server setting for the router’s DHCP server should be a public DNS server (this type of basic router DNS function is sometimes referred to as “DNS Proxy services”).

2) On the other hand, if they CAN be configured separately (implying that the router has a “true” DNS server rather than just forwarder entries), then the DNS forwarder settings in the router should be set up to point to these public DNS servers, but the DHCP server should be configured to provide the IP address of the SBS machine as the Primary, and the router’s own LAN address as the Secondary DNS server.

With either type of router providing DHCP services, then, all DHCP clients on the LAN will be certain to have the IP address of the SBS machine as their Preferred DNS server, so it will be almost certain that they’ll get immediate name resolution for local hosts, and for sure will get immediate name resolution for the SBS machine itself (unless it’s offline, of course).

To recap: the two different Secondary DNS server settings on the router’s DHCP server are intended to best deal with this “server down” scenario, where the SBS machine is not reachable. When that’s the case, it’s usually VERY important to be able to provide DNS services for hosts on the public Internet, since most people can still get a lot done while the server is down as long as they can reach hosts on the Internet. If the router has a “real” DNS server that’s separately configurable from its DHCP server (case 2 above), then great – it will likely be able to do both local and public name resolution; if not (case 1 above), then having a public DNS server as Secondary/Alternate will insure that clients can still reach hosts on the public Internet. When (not if) this happens, management will be very glad you had the foresight to set it up this way (and so will you, even if you don’t get any recognition or reward for it!).

Notice that no matter which host (SBS server or gateway router) provides DHCP services, all clients will ideally have their IP address and DNS server settings configured by DHCP rather than manually. If the “server side” is properly configured, this approach provides the least effort to maintain, the most flexibility when machines are taken offline or out of the office, and the best performance.

Thanks for sharing this in such detail!

Conclusion

Send me an email if you’d like to contribute your own troubleshooting “trench tale” for an upcoming issue of WServerNews or for a future article here in my column on WindowsNetworking.com.

 

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top