IE 8 forces changes enhanced security configuration to permanent on for users, 2008 terminal server

The machine is networked and in a domain.
There is one host machine, and four virtual servers on the machine. The terminal server is one of the virtual machines.
I have not touched any Group Policy on the machine or in the domain regarding Internet Explorer. I haev simply disabled the enhanced security on the machine for IE in the server manager. (As mentioned it works for administartors, but not for users and it was ok before the IE8 upgrade)

I have same problem on a W2003 Terminal server. I followed this document, but it is still not working ok.:

http://www.microsoft.com/downloads/details.aspx?FamilyID=d41b036c-e2e1-4960-99bb-9757f7e9e31b&DisplayLang=en

New created profiles have no problems, but old users have many difficulties to view websites. Grrr Microsoft.

Dvreede - yes, I have seen others on the web note that new profiles are OK, and existing users not.
Those whoh have policies in GPO say that they have no effect and changes are ignored.

Obviously unpalatable and unacceptable to have to delete and re-create all profiles!

If you set these registry settings to "0" for each user it will free up the security settings so the user can adjust the internet security level in internet options from high to medium

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zonemap

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings

Hope this helps. It certainly sorted the issue out for our terminal servers users (using IE8 and Window Server 2003).

Hi,

We are experiensing the same thing.  We run two terminal servers (on server 2003) with loadbalancing.. I upgraded one of the servers to IE8 and are unable to turn off the enhanced security configuration for my users.

Have tried to disable via add/remove windows components (wich worked with IE7), but no luck.

I haven't tried Cudmore's solution because we have to many users and it will be impractical.
Anyone else got an idea?

Update:

This "error" will also affect users who roames between a terminalserver with ie7 and one with ie8.  The problem will propagate over to servers with IE7 also.

Start REGEDIT on the terminal server and check the folllowing registry-setting:[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]

If you find this IEHarden-value to 1 ("IEHarden"=dword:00000001) then you should change it to 0 ("IEHarden"=dword:00000000)

After performing this on my servers i deleted my profile and logged back in again.  It worked.
So the problem i partially fixed.  The "dumb" thing is that you have to delete every users profile and recreate it.

Hi,

We run four terminal servers (server 2003) with load balancing across them. We applied IE8 across all the servers and are experiencing the same problems with none admin users. It will be impractical for us to have to delete every user profile from each of the Terminal servers and then recreate them.

Is there anybody that has a better solution to this problem? Why O why do Micrsoft do this to us?

I didn't worry about setting up new profiles... too hard and too many users.  I just setup the registry changes to run as part of the users logon scripts.

I ran this reg change from a good old fasion bat file (silently of course)...
----
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"IEHardenIENoWarn"=dword:00000000

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]
"IEHarden"=dword:00000000
----

Not too much work really.

The script in following article should resolve the problem, it calls the installer to forcibly remove Enhanced Security for all users. Tested okay on a 2003 Terminal Server just now, however it should work on 2008 with no problems also.

http://blogs.msdn.com/askie/archive/2009/06/23/how-to-disable-ie-enhanced-security-on-windows-2003-server-silently.aspx

NB, the script below removes the IEHarden registry entry for HKEY_CURRENT_USER - I found we didn't need to do this, as the entry didn't exist, but we were still having the problem anyway. See attached for the script which which fixed the problem for us.

P.S. the related Microsoft KB article for this is: http://support.microsoft.com/kb/933991. From reading the article I get the impression they're not exactly sure under what situations this problem occurs. We've certainly installed IE8 on many terminal servers without experiencing the problem.

::Ensure IE Enhanced Security registry keys exist
 
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}" /v "IsInstalled" /t REG_DWORD /d 0 /f
 
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}" /v "IsInstalled" /t REG_DWORD /d 0 /f
 
::Forcibly uninstall IE Enhanced Security from Add/Remove Programs
 
Rundll32 iesetup.dll,IEHardenUser
 
Rundll32 iesetup.dll,IEHardenAdmin
 
Rundll32 iesetup.dll,IEHardenMachineNow
 
::Delete registry values for Enhanced Security
 
REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}" /f /va
 
REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}" /f /va

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

TeamMacleon has it figured out.  

IE 8 was needed for Exchange OWA calendars, but destroyed ESC.

Manually setting the levels in GPEDIT solved the problem.

Note:  IE8 doesn't seem to fully install on the Terminal Server.  The Registry IE Version settings for IE 8 are not updated at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073} and related keys.  It lists:  7,0,6001,18000

It should be:  8.0.6001.18813

I'll bet this is at the core of the problem.    Regardless, thanks to TeamMacleod for finding a solution.  

Best solution found