Speeding up login times – Group Policy v’s Branded IE

This is the age-old issue of balancing the need to get log in times as quick as possible v’s keeping the M in MOE. The Environment can be managed to the ‘nth degree but each extra tweak comes at the expense of an extra micro second at login.

For me Management is key as I look after around 3500 student facing and lecture theatre PCs. Due to SAN space issues we don’t provide roaming profiles, but do redirect Desktops and My Documents as well as a couple of system folders to user home drives. Further complexity arrives in the form of different settings required depending on the user type logging in to the PC. They can be a University Student, Teaching Staff, TAFE students or even the general public, and each needs a different home drive pointer, different proxy settings (configured for IE and Firefox), and in some cases unique wallpaper; and that’s just the start of it.

As a result, for a number a years I didn’t think too much about login times in the region of 90 – 120 seconds, but earlier this year it became a bit of a bug-bear for me and so the investigations began. It was sparked by a persistent message saying Personalized Settings – Setting up personalized settings for: Browser Customizations which was hanging around a bit too long.

To kick things off I enabled verbose messaging; see http://support.microsoft.com/kb/316243 (I actual like this level of messaging, even for end users; at least you know Windows is doing something when it’s doing its thing).

Analysing these logs didn’t show up any obvious error so I went delving for other logs written at login (system wide) to see it they would shine any light. I came across a few log files being written in the Local Application Data (%LOCALAPPDATA%LocalMicrosoftInternet Explorer), brndlog.* and rsoplog.*. Within these files I found some surprising data….

For each login there were two brndlog files generated, a brndlog.bak and a brndlog.bak. The run of the files seemed pretty normal until the very end:

Branding of IE is done using an IEAK (MS Link) usually by System Administrators or Application Packagers to package up the browser with pre-configured settings for deployment in a corporate or other environment. Branding is particularly useful in scenarios where Internet Explorer is deployed without the availability of a domain to deliver policy. The ‘branding’ can include settings like proxy configuration, favorites and security settings etc. The problem is though that in a managed environment using Group Policy for IE configuration, the branded settings seem to fight with the policy applied settings for the final say.

What to do when your SOE has a branded IE embedded in it?

My first thoughts were to strip out the branding. I found a page on this topic – http://www.enhanceie.com/ie/NoBrand.htm. One of the suggestions was to remove the install.ins file that holds the branding information. For me it was in %ProgramFiles(x86)% & %ProgramFiles%Internet ExplorerSIGNUPinstall.ins. Removing this caused the desktop not to load at all. Delving deeper I found that the branding file was for an older version of IE, Version=8,00,7601,17514. So next I tried replacing it with an up to date version as our SOE now has IE9. Again the desktop would not load. Plan C was to break the branding, i.e. inject an install.ins that would cause it to fail, e.g.:

I deploy this as a File Preference by Group Policy and amazingly it worked a treat. The Personalized Settings dialog that so bugged me disappears as quick as it appears. The brndlog files now appear as:

The IE browser settings deployed by Group Policy are applied as expected and the login process is down from over 90 seconds to around 25 seconds for a new profile including printer installation (no mandatory profiles used). As expected, all this effort generated exactly zero calls to the Service Desk, and exactly zero users calling to say how great things are running (it’s just expected), but the satisfaction of further streamlining the MOE is satisfaction enough.