>I'm sure there's a reason the IE Maintenance Policies were created and behave 
>the way they do

If you figure that out, let us know :)

They are one of the most maligned contraptions MS has ever come up with. A few 
years ago I belabored the point with the GP PM and the answer was basically, 
"We know, GPP will be the solution"

We tried it briefly on Citrix a long time ago and went a different direction. 
We do have them on some specialized workstations and they sort of work but the 
desktop folks complain that if they have to move the PC out of the policy's 
scope, some elements of the policy linger no matter what they do and the 
easiest solution is to re-image.

"IE Maintenance, is, to put it bluntly, a pile of crap code. So, you often have 
to torture it to get it to do what you want." Darren Mar-Elia -- Group Policy 
MVP

From: Sean Martin [mailto:[email protected]]
Sent: Monday, December 20, 2010 1:30 PM
To: NT System Admin Issues
Subject: IE Maintenance Policies

After a few years of dealing with IE Maintenance Policies, I've finally gotten 
fed up dealing with their apparent "flakiness" in Citrix environments where IE 
is launched as a published app. It wasn't until recently that I found out there 
are known issues with certain policy settings applying correctly in this 
scenario.

By flakiness, I'm referring to proxy settings, security zone and privacy 
settings not applying correctly.

The issues being faced were recently brought to light when we migrated one of 
our departments to a new roaming profile environment. We currently use roaming 
profiles in a Citrix environment with multiple application silos. This has led 
to many profile related issues mostly due to LWW scenarios. We've deployed new 
policies so that users logging into each application silo will access a 
specific profile for that silo.

Anyway, we wanted to be certain no lingering issues were brought into the 
user's new profile so their old profiles were deleted. Upon their next login, 
the migrated users had new profiles created. This highlighted the issue where 
certain IE policy settings were not being applied correctly. I worked with 
Microsoft for a couple of days and tried different solutions (switching between 
preference mode and no preference mode), running a login script with 
"runonce.exe /alternateshellstartup", etc. Nothing appears to be working and 
RSOP shows no issues.

As a result of all this, I decided to put together my own .adm templates with 
the relavant policy settings. My initial testing indicates everything works 
perfectly. Although trusted sites are correctly configured, they do not appear 
within the IE options dialogue, which is something I can live with. Other than 
the additional overhead incurred whenever  a change needs to be made, and 
possibly having to redo my .adm templates if newer versions of IE change the 
locations of these settings, can anyone think of a reason why I would not want 
to move forward with my custom policies? I'm sure there's a reason the IE 
Maintenance Policies were created and behave the way they do. I just want to be 
sure I'm not missing out on some important aspect.

 - Sean

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
[email protected]<mailto:[email protected]>
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

Reply via email to