Websites Timing Out – This Page Can’t Be Displayed


I came across this issue where a particular user was getting lots of timeouts for websites via Internet Explorer. The problem didn’t follow the user to other PCs, and I couldn’t see any firewall issues. The websites were random, but I did notice they were generally slow to load websites.

Another symptom was getting this same error when signing up for things or processing payments – all processes that can take a while to respond. Even loading pictures on emails sometimes timed out this way!

I did find a 3rd party search engine had been added to IE and removed that, but that made no difference.

After a bunch of testing and research being convinced it was a local profile issue, probably around IE timeout settings, I found this article which gave a registry setting around timeouts. I adjusted the value for KeepAliveTimeout in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings but it made no difference.

What I did notice though, was another registry value in the same spot –¬†ReceiveTimeout. This was set to 5000 which would equate to 5 seconds converted from milliseconds, similar to the KeepAliveTimeout setting.

Comparing it to another computer, that registry setting didn’t even exist. I tried upping the value to 60000 for a minute, and after lots more testing, the problem appeared to be fixed! I then deleted the registry key and the problem didn’t reoccur.

My assumption is that the 3rd party search engine (which seemed a bit dodgy) added certain registry settings under the user’s profile for their own purposes, and removing it didn’t clear it up.

Of course, deleting the profile would have had the same result, but then we wouldn’t understand why it broke!



How To Apply HKLM Settings Per User

Normally when you think of Windows Registry, you’re normally worried about the two sections: HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU).

It’s fairly obvious that settings under each area apply to either the PC itself (machine) or just to the currently logged in user. This is usually fine, but there are scenarios where there’s a setting that will only apply to a machine due to how the program is written, but you actually want to turn it on or off based on the logged on user.

With Group Policy Preferences (GPP) which was introduced with Windows Server 2008, this is much easier to do. Before this, you would have need to have written complex logon scripts using 3rd party tools to perform lookup commands, create variables and then adjust the registry accordingly, while providing administrator credentials.

GPP lets you apply registry settings rather easily. One of the main benefits of GPP is how flexible and granular you can be with the settings you apply.

This is how I would normally use to deploy a setting, but have it easily managable: Have two settings for the registry, one setting it on and the other off (normally done by a 1 for on, 0 for off but it depends on the setting). The targeting for having the setting on or off is based by user membership to an Active Directory (AD) group, but the setting is not applied in the user context meaning it’s applied by ‘System’ which will have full access to the HKLM registry.

This will then mean the HKLM setting changes from 0 to 1 and back based on which user logs in!

I prefer this than just applying particular users individually to the item because it will reduce processing time having a single check vs many, and that anyone can easily manage an AD group rather than mucking about with Group Policy and potentially doing something wrong, affecting the entire user base.

How to create a Group Policy that applies HKLM settings per user:

First, create a Policy. I’m going to assume you’re able to open Group Policy Management and create a Group Policy Object (GPO).

We’ll be working under User Configuration > Preferences > Windows Settings > Registry.

Here’s what you should see without my registry item already created:gpp1

Right click in the big open white space and choose New > Registry Item. Fill in the General tab for the registry item you want to create. Here’s an example:


Next, go to the Common tab and tick ‘Item Level Targeting’. Then click the ‘Targeting’ button and you’ll be taken to the Targeting Editor. This is where all the granular control is, and you’ll find many options on what criteria needs to be met to either apply, or not apply the registry item.

You can define what you like for the rules, but I’ll be doing ‘the user is a member of the security group’. You can click the ellipsis … button and find your group in Active Directory (or quickly go there to create it first).


After you’ve done this then pressed ‘OK’ twice, you’ll have your first registry entry ready to apply. We need a second one to do set the registry setting to a different value if a user is NOT in the group, so right click on the registry item and choose ‘copy’ then right click on the blank area and choose ‘paste’.

Go into the properties of your copied item, and change the value data to the second setting, and go into the ‘Targeting’ area and change the rule to ‘Is Not’ rather than ‘Is’ under the ‘Item Options’ dropdown menu.

One note is that AD group membership is checked when the user logs in, so if you’re testing and running ‘gpupdate’ to force a group policy check, it may not work as it won’t realise the user is in or out of the group. Just log off and back on to test instead.

I am a big fan of Group Policy Preferences and this is one of the examples of how powerful it can be, so if you are not already using it – get started!