Slow logon time (again)

A common problem which delays logon times concerns IE branding. This issue seems random, effecting all Windows versions running IE 7.0 or IE 8.0. Testing this I found results not consistent, with some clients or servers showing a logon delay, but not a universal issue across all devices. On one system were the below fix was applied logon time was reduced from over 60 seconds to just 4 seconds!

By checking C:\Documents & Settings\%username%\Local Settings\Application Data\Microsoft\Internet Explorer\brndlog.txt shows if the problem exists. This log file records time taken for branding to be processed, from start to finish, this file should take nothing more than 2 to 4 seconds.

Microsoft reference this issuein: http://support.microsoft.com/kb/941158 which details a fix for IE 7.0 MS report the issue does not exist with IE 8.0. (support case open with MS for IE 8.0)

The fix for IE 7.0 requires a new registry entry adding to machines:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_PARSING_BRANDING_CMDLINE_FLAGS_KB941158
This key seems to completely disable branding, which I suppose is one why of bypassing the issue, although I’ve never come across a fix that requires a registry key with the KB number in the name, looks like a very rushed job. The file responsible for branding is iedkc32.dll which is located in System32 and SysWOW64.

From a fixed IE 7.0 server, I have copied the above files across to a IE 8.0 server and proved this resolves the issue, although that’s not really a logon term fix!

What size is your page file

Page file size is one of those questions that is often pushed to the bottom of the to do list. For a while with improvements in server hardware, the relevance and impact of this question faded, but with more servers running on x64 loaded with 16 GB or more memory, the question what size page file to use starts to crop up again. Should a server with 16GB memory really have a 4GB or larger page file? Looking just at terminal services, servers running SQL and Exchange have different requirements, it’s easy to see if you need to run a page file at all and if so what size. The simple way is to look at just three values:

Memory\Committed Bytes, (Committed Memory is just the total amount of memory all applications have requested)
Process\Working Set_Total (Working Set_total is what is actually been used)
Page File\% usage (page file usage should be the difference between the two values above)

So for example let’s take a Citrix server hosting 55 concurrent users ..
Memory\Committed Bytes = 6 GB
Process\Working Set_Total = 3.6 GB
Page File = 2 .4 GB
(Committed Memory minus Working Set = page file usage)

From these results we can see a server with 16 GB RAM only requires 6 GB memory to support the applications running, but in this example 2.4 GB is been paged out. So for this server the Page file could be reduce to a few hundred meg just to ensure if a process insists on accessing a page file it can.