Re: GPO to prevent IE, OE, and Address Book menu items?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Just-In-Time setup is what runs when a new user is created. It is Active Setup.

The Security settings for the Zone are what control the prompt.

The key thing is to 1) Determine if the shortcuts are actually *considered* to be running in the Local Intranet Zone as a limited user, and 2) to check the security settings for the zone.

The answer to the above questions would give us a clue as to what is being changed/set during the per-user setup (Active Setup). It is possible that the defaults for what is considered Local Intranet are not being set until the ie4uinit.exe is being run.

Or, the security setting is defaulting to "Prompt" unless the ie4uinit.exe is run.

Are you unable to view the security settings for the Local Intranet Zone, using the Custom Level... button, when logged on as a limited user?

I have been using these reg settings for many years. Windows 2000, 2003 RTM/SP1 Standard & Enterprise. Standalone TS servers, member TS servers, and DC TS servers. I have not seen the behavior you are experiencing with any of them.

However, an important thing to keep in mind though is the strict prompts are relatively new.

Are you using Group Policy to set IE Security Preferences? Have you ever set them?

How about in your Default User profile?

Did you define what is considered Local Intranet Zone via your Group Policy, or did you just add the UNC path when logged on as an administrator?

If you just added it while logged on as an admin, this applies *only* to that account.

Are you using IE Enhanced Security? I have it installed on most servers (of those that are 2003).

I just tested on a server where I have not implemented any IE Security preferences via Group Policy, and it works fine as well.

If you are happy with deleting the icons, then leave it alone. My feelings will not be hurt.

-TP

Gregg Hill wrote:
TP,

I am not sure what you mean by Just-In-Time setup.

I imported this GPO from another system that works just fine. This GPO
prevents users from running IE, and it prevents access to the C:
drive of the TS. None of my other setups has this problem using the
identical GPO. The only thing I did differently was to add the reg
file that you supplied to get rid of the IE, OE, and Address Book
menu items when users are created.

That being said, I have already set the GPO per Vera's suggestion to
add the UNC path to the Local Intranet zone, and it shows up there
when viewed from an admin login to the TS. For testing, I have now
allowed running IE, but it will not let me change the Local Intranet
zone sites.

So just for giggles, I deleted the GPO, recreated it, imported the
settings from a freshly-downloaded backup from a known-good server,
deleted the user profile so it would get recreated, and Presto!, the
same behavior. That got me thinking, which is often a dangerous
thing. The only other thing I had done with this GPO was use the
rem_icons reg file that you had attached (converted to an ADM with
RegToAdm). I looked at what it does, and it basically deletes the
initialization of the IE, OE, and Address Book by removing the stub
path to those setup files.

So, I exported those registry entries from a known-good server, then
imported them into this one. I deleted the user's profile again,
logged back in as that user, and I now have normal access to the
desktop icons without the warning prompt.

OK, just finished more testing. I created three versions of your reg
file, one for each stub path for IE, OE, and Address Book. Then I
deleted the test user's profile before each of the following
attempts. I deleted the stub path for OE, then logged into the TS
again, getting a new profile. The desktop icons worked. I did the
same for the Address Book stub path (after deleting the profile, of
course), and the desktop icons worked normally. I then did it again
after deleting the IE stub path and the user profile, and the desktop
icons pop the warning. I did this several times with the same
behavior, then restored the stub path only for IE and tried again
after deleting the profile. Bingo! The desktop icons work normally.

My conclusion: there is something that the IE initialization does that
escapes me, but it must be there in order for the icons to work
properly. So I will just leave it and clean up the icons after each
new user logs into the TS.

Any idea why the reg file you supplied to delete the stub paths would
have this effect, but only if the IE stub is deleted?

Gregg Hill


.

Quantcast