IE7 Group Policy Settings

After when deploying Internet Explorer 7 around your site through a service such as WSUS, there are immediate considertaions that have to be dealt with. The main one being configuring settings for IE7.

It is possible to download the Internet Explorer Administration Toolkit (IEAK), but when dealing with IE7 that has been installed on computers automatically – that’s not what you want to hear.

After installing IE7 on one of our servers, I went to the group policy to see if there were any new settings. As such, the important ones didn’t seem to exist:

  • Configure the phishing filter
  • Disable the ‘First run’ Page

Obviously, there are a number of settings that administrators would want to take control of.

Thankfully, there are two ways of getting these settings in group policy. The first is to simply install Windows Vista as a workstation and use the Group Policy Management Console (GPMC.MSC) which is bundled with Vista. This has all of the IE settings.

If you don’t have a Vista system, you can download an up-to-date MSI of the Administrative Templates for Internet Explorer 7 for Windows. This will install the inetres.adm file in the specified folder.

To apply it to the machine you are working on (pre-Vista, of course), copy the ADM file to %systemroot%\inf. Run gpedit.msc and navigate to User Configuration > Administrative Templates > Windows Components > Internet Explorer.

Some of the useful settings are:

  • Prevent Performance of First Run Customized settings to disable the first run page
  • Turn of Managing Phishing filter to enable the phishing filter and configure its actions
  • Turn on the menu bar by default to stop people asking you where the menu bar is
  • Prevent Participation in the Customer Experience Improvement Program, another default from the first run page
  • Moving the menu bar above the navigation bar to put the menu bar in its proper place, above the address bar

Using the group policy configuration is a much more practical way of configuring IE7 than the registry hacks that I’ve seen floating around where people are struggling to find the group policy settings for IE7.

There are there! Honest!

Windows Vista in “Dude, Where’s my Start Menu?”

When dropping Windows Vista into an existing network, you may notice some unusual issues that weren’t apparent in Windows 2000 or Windows XP.

The main cause of a headache for me was the new interpretation of the Group Policy settings that Vista utilises.

Because most of the networks that I manage rely on roaming user profiles, it’s not uncommon for me to use folder redirection to redirect the Start Menu and Desktop. These are set so that the user cannot change the contents of these folders, and they specifically show programs that only I allow.

So, all is good. Until Vista came along and the contents of the Start Menu suddenly disappeared. Clicking on the ‘All Programs’ links showed nothing at all. Eeep!

After about 2 hours of searching as to why this might happen, I eventually discovered it was a group policy setting that works differently (and by its interpretation, correctly) to Windows XP.

Group Policy EditorThe setting in question is User Configuration > Adimistrative Templates > Start Menu and Taskbar > Remove User’s Folders from the Start Menu

In Windows 2000 and Windows XP, the setting prevents the user’s profile folders from appearing. This is useful if you are using folder redirection and don’t want the default Start Menu icons to appear. However, Vista includes the redirected folders as excluded, and as such – nothing appears.

The difficulty hunting this down of course is that the group policy results show a successful redirect, which of course is exactly what it’s doing

The Case of the Disappearing CD Drives

I had a bit of a problem with a restored computer where the CD drives would not appear in My Computer in Windows XP.

After a little bit of grief, I found that the problem was a simple registry setting: http://www.siliconguide.com/qa/forum/messages/71.shtml

To resolve the issue

  • Open up the registry editor (Start > Run > regedit and click ‘OK’)
  • Navigate to the following folder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325 -11CE-BFC1-08002BE10318}
  • Delete the keys Upperfilters and Lowerfilters
  • Close the registry editor

Once you have deleted the registry keys, either reboot Windows, or scan for new devices in Device Manager. The CD drive(s) should now appear, and work as normal.

Group Policy Application Deployment Woes

I recently managed to cause myself a huge headache when removeing some software via group policy.

The worst part is, I only have myself to blame as the software was wrapped by me using Masai Installer.

If software uninstallation (or installation for that matter) goes bad, then a dialog window will open asking for some sort of input, which should never happen during silent installations.

If this happens while Windows is installing / uninstalling managed software, then Windows will hang and the only way to avoid the installation is to reset the computer.

The way around this is to make sure that you test the MSI by installing and then uninstalling.

The best way is to use these commands:

Install
msiexec /i msifile.msi /qb

Uninstall
msiexec /x msifile.msi /qb

Of course, replace msifile.msi with the name of your MSI installer.

If the MSI installs and uninstalls without any prompts for input, then you know that it will deploy correctly through group policy.

If there is a prompt, then you need to work out how to prevent the prompt appearing during the installation.

Terminal Server Install Mode Command

As I’m always forgetting these, I thought I’d make a note.

When installing software on a Microsoft Terminal Server, you need to set the server to be in installation mode to support folder virtualisation for users.

One way to make sure that this works is to install any new software through Add/Remove Programs, and then ‘Add New Programs’

A quicker way is to simply use the command line:

change user /install

This puts the server into install mode. After this, install any software that you need to install.

Once done, put the server back into execute mode:

change user /execute

This will switch the user session back to it’s normal mode which is used for running applications.

Easy.

Roaming Profiles in Windows Domains

Getting roaming profiles working on Windows Servers is a very simple process, and I generally include this in a script when creating users for the first time.

Here’s a quick ‘how to’ for those that are interested, based on a Windows 2000 or Server 2003 network.

Step 1 – Decide where you want the profiles to live on your file server

  • Log on to the Windows server as an administrator
  • Open the drive where you want your profiles the be stored for the user accounts. It’s worth noting that by default, Windows user profiles stores Application Data, My Documents, Cookies, a few other folders and the profile itself. Needless to say, if you are using the defaults, make sure that you have enough drive space.
  • Create a folder where you want your profiles to live. I generally store user profiles in D:\Users on a server. Make sure that the folder has user read privileges.
  • Right-click on the folder you have just created and click ‘Sharing…’. Call the share ‘Users’ and give all users full access to the share.

Step 2 – Configure a user profile to roam

  • Open ‘Active Directory Users and Computers’. You can find this in the ‘Administrative Tools’ folder on the start menu
  • Find the user that you want to set up a roaming profile for, and double-click
  • Click on the ‘Profile’ tab
  • In the ‘Profile Path’ field, enter the network path to the Users share, and then add the username to it. (eg. \\myServerName\Users\John)
  • Click ‘OK’ to apply the changes to the user account.

Step 3 – Check that the profile is saved back to the server

  • All we need to do now is check that the profile is going to be saved back to the server correctly. So log on to a client workstation with the user that we have just been tampering with. Once logged on, log off again.
  • On the server, goto the User profile folder (D:\Users\) and have a look. In our case, the user was called ‘John’, so you should see a folder called ‘John’. The profile is stored inside here. Well done!

A few pointers

  • Some of the settings in the profile tab directly conflict with the profile path and some other group-policy settings. Don’t be tempted to use the ‘Home Folder’ option if you are using profile path
  • You can replace the username with %username%. This will automatically put the username of the user in for you. This is especially handy when you want to change the path of multiple users at once.
  • If you have more than one domain controller, and the profiles and stored on there servers, you can use %logonserver% instead of \\myServerName. Just bear in mind that you should be using file replication for this to be useful.
  • You may not automatically have access the the profile folder that has been created. If you logged on for the first time in Windows XP SP2, then the default folder permissions will lock administrators out of the profile folder. You need to change a setting in the policy if you don’t want this to happen.
  • When Windows 2000/XP/Vista logs onto a network, the entire user profile is copied to the local machine. When you log out, the profile is copied back to the server. If the user has masses of data in the profile, then you should be using folder redirection to move folders