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

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










"TP" <tperson.knowspamn@xxxxxxxxxxxxxxx> wrote in message
news:%23BTrUd$QGHA.224@xxxxxxxxxxxxxxxxxxxxxxx
Cool!

Now that you are an expert on Just-In-Time setup, you get to become an
expert on security zone settings.

Let's break this down into smaller chunks so we can figure out what is
happening.

* Determine the Zone *

First thing we need to determine is what security zone the shortcuts are
actually running in. Log on as a problem user, and open up Internet
Explorer.

In the Address box, type in the path to where the shortcut is located, not
including the shortcut file name. For example, if my shortcut is located
at S:\, I would type S:\ in the address field and press enter.

Make sure the status bar is turned on by using the View menu if necessary.
Look down at the lower right corner of the IE status bar and read the
zone. In my case it says Local Intranet, because S: is located on a
server that I have defined as part of the Local Intranet.

Does yours say Local Intranet? If not, you need to fix this first by
adding the UNC path to the list of Local Intranet Sites. We are fixing a
single user at the moment, but later we can change the settings for all
users using Group Policy.
l
This is what Vera's FAQ you referred to explains how to do, so I will not
cover this (unless you need me to go over it in more depth, or are having
problems).

* Check Security Settings *

Above we made sure that the path to our shortcut is in the Local Intranet
Zone. The second thing we need to do is check the relevant security
settings to make sure they are correct.

For your particular issue, the security setting we are concerned with is
called "Launching applications and unsafe files". To check this setting
for the Local Intranet Zone, follow these steps:

Open up Internet Options from the control panel
On the Security tab, single-click Local Intranet
Click on the Custom Level button
Begin typing the phrase launching...
Launching applications and unsafe files should be selected

What is it set at?

If you do not want the user to be prompted, you should choose Enable.

After saving the above changes, retry double-clicking the shortcut.

* Setting for All Users via Group Policy *

This is set on the Group Policy object for the users. The setting is
under:
User Config\Windows Settings\IE\Security\Security Zones

-TP

Gregg Hill wrote:
I Googled and found Vera's suggestion to add \\servername to the Local
Intranet zone, which I did, with no change in behavior.

Gregg Hill




.