Category Archives: Internet Explorer 8

Apply Internet Explorer Settings with Group Policy without preventing users from making additional changes

Let’s say you want to roll out some default settings to IE, but you don’t want to prevent users from making additional changes. In the past I’ve seen this done through the Site to Zone Assignment List GPO but you end up with users who can’t modify those settings once they are set at the GPO level. The problem is this: say you’ve got a partial list of websites that should be placed in Trusted sites, but you don’t have the full list and you know users are going to need to add additional sites ad hoc.

Here is the better way to configure these settings:

  1. Open Group Policy Management Console, and Create a new GPO
  2. Expand User Configuration, Policies, Windows Settings, and Internet Explorer Maintenance, and finally Security
  3. Double click on “Security Zones and Content Rating”
  4. If and when the “Internet Explorer Enhanced Security Configuration” warning appears click on “Continue”
  5. Change the “Security and Privacy Settings” section to “Import the current security zones and privacy settings” and then click the “Modify Settings” button
  6. Make all of the appropriate changes for your environment and then press OK. These will now be the default settings for any users whom this GPO effects.

To be clear, I’ve not tested to see if these settings will re-apply if they are removed by the users, but my hunch is that if the users tries to remove any of these settings, they will be reapplied the next time the GPO is processed.

Internet Explorer 8 continually asking users to log into web sites in Terminal Services (2008 R2)

Ran into a super painful problem about 3 weeks ago. When users were logged onto a Terminal Server (Server 2008 R2) and running Internet Explorer 8 (Why, you ask, would I allow IE to run in Terminal Services? Normally I wouldn’t but the client’s app needs to be run within IE) any time they tried to download a file, or open a link that moved them to a new tab or window, the site “forgot” who they were and prompted them to re-authenticate.  This happened on many different sites, and not just on the app I mentioned.

We started down the normal troubleshooting path, allowing the site in Pop-up blocker, adding the site to the Trusted Sites list, lowering the security on the Trusted Sites list to “Low”, enabling Computability Mode, etc. Nothing would allow the file to be downloaded without having to re-login to the site.

As we continued testing, we removed all Group Policies that were locking down the Terminal Server, we created new users with fresh profiles, and double checked registry and file system permissions, again nothing would resolve the problem.

Finally, we came across this blog post over at the MSDN site, Here. Turns out, that when a new tab is opened, it starts running under a different process, combine that with users running on a Server 2008 R2 without “Power Users” permissions, like in the case of Terminal Services, and it creates a situation where the new process does not have permission to access the cookie that was stored by the other running process. This is not the case on Windows 7, as users without “Power Users” permissions don’t experience this same problem.

Internet Explorer changes it’s behavior of where it stores cookies and other data depending on the permissions for the user running the process. Any application which launches a new tab, in turn launches a new process and this will not have permission to access data like cookies from the process which launched it. Since the users are in a locked down environment, this Internet Explorer behavior should be turned off.

The registry value that we needed to change was located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN

We needed to create a new DWORD called “TabProcGrowth” and set it’s value to 0.

The reason we are setting this value at HKLM and not HKCU is so that every users who uses this machine will have this setting applied to them. I’m far too lazy to change it and every user’s HKCU level.

After making this changed we were able to log in with new test users, and existing users alike and verify that we were no longer seeing the problem!