I must admit that when I sat down to write this article, I was tempted to say, “If you want to manage your browser’s configuration from Group Policy, migrate to Firefox.” Why would a dyed-in-the-wool Group Policy fan such as myself make such a statement? Well, Internet Explorer (IE) configuration through Group Policy has been a mess for a long time.
With no fewer than three separate and sometimes conflicting methods for configuring IE through Group Policy, I would be hard-pressed to tell anyone that using this technology is easy. But given the importance of locking down IE in many organizations, you must face this challenge and make the best of it. In this article, I’m going to offer some tips and best practices to help navigate the morass that is Group Policy management of IE. (See also, "Browser Apps and the Future of Web Browser Management").
Pick Your Poison
As I mentioned, there are three main methods for managing IE configuration through Group Policy:
- Administrative Templates settings under Computer Configuration (or User Configuration)\Administrative Templates\Windows Components\Internet Explorer: These settings are the typical Administrative Templates policy lockdowns, which set certain options in IE and which cannot be changed by the user.
- User Configuration\Windows Settings\Internet Explorer Maintenance: This is the original mechanism by which you could configure IE through Group Policy. Early versions of this mechanism had lots of bugs, and configuration behavior was unpredictable. The Windows 7 version is more reliable.
- User Configuration\Preferences\Control Panel Settings\Internet Settings: This Group Policy Preferences–based IE configuration method fills the gaps of the previous two methods, but it doesn’t cover some key areas.
The bottom line is that, for most scenarios you’re likely to encounter, you can’t get away with using only one of these methods. Instead, you will probably have to use two, and possibly all three, to fully control IE behavior on your desktops and servers. I’ll take a look at what each of these methods brings to the table and at some of the behaviors you need to be aware of in each case. Additionally, I’ll mention areas where I’ve seen other folks take a different tack to work around the behavior of one of these three methods. For example, I’ve seen people simply write registry scripts to modify the underlying registry values of the IE options they want to control (e.g., proxy settings) rather than relying on the poor behavior of IE Maintenance policy.
Administrative Templates Policy
The IE Administrative Templates options are available under both the Computer Configuration and User Configuration sections of a Group Policy Object (GPO). This means that you can set them to apply to all users of a given set of machines (Computer Configuration) or to specific targeted users (User Configuration). It’s generally a good idea to avoid conflicts between per-computer and per-user policies for a particular user who is logged on to a particular machine. When conflicts occur, the per-computer settings usually win, but that’s not always the case, and you should verify this behavior if you find that you are unavoidably put in a conflict situation. I usually stick to defining only per-user IE Administrative Templates settings, especially if I plan to use the other two policy areas in conjunction with this one. I do this because the other two are per-user only, and that keeps things cleaner when it comes to targeting IE-related policy.
When you upgrade to a new version of IE, that upgrade process will typically install a new ADM or ADMX template file on the system where you perform the upgrade. I’m sure the forthcoming IE 9 will be no different in this respect. If you’re installing on Windows XP or Windows Server 2003, the updated file that contains all the relevant settings is named inetres.adm, and it will be saved in the C:\Windows\inf folder on the system where you perform the IE upgrade. You’ll have to manually copy the inetres.adm file to a domain-based GPO if you want to start using those new settings. If you’re working on Windows Vista, Windows 7, Windows Server 2008, or Server 2008 R2, you probably know that Microsoft shifted to the new ADMX template file format. Therefore, when you install a new version of IE, an updated inetres.admx file is saved in the C:\Windows\policydefinitions folder on your upgraded Windows system. If you’ve deployed an ADMX Central Store in your Active Directory (AD) domain, you’ll have to manually copy the inetres.adm file into it, overwriting the existing version of this file.
Administrative Templates strengths. The IE Administrative Templates settings, like other Administrative Templates settings, are primarily designed to enforce behaviors on your IE users. When you configure an IE Administrative Templates setting, the user typically cannot undo it—the setting appears dimmed, or a corresponding tab is removed. For example, you can hide the Security tab in the Internet Options dialog box of this policy area, and the user won’t see those options at all. In fact, when it comes to settings for disabling IE configuration features, you’ll most likely find them all in this policy area, as Figure 1 shows.
Generally, it works best to use Administrative Templates to configure a particular setting and to remove that setting from the menu altogether so that the user can’t even access it. Table 1 lists some common tasks that you can perform with this policy area and describes where you can access those settings.
Administrative Templates weaknesses, The biggest weakness of IE Administrative Templates is that you can’t use this functionality to configure many areas of IE behavior. The list of items you can’t configure includes the home page, proxy settings, and the options on the Advanced tab of the Internet Options dialog box (on the IE Tools menu). Additionally, if you want to configure a setting but also want to leave the user free to modify it, IE Administrative Templates is probably not where you’re going to do this, since none of its mandates can be changed by the user.
IE Maintenance Policy
As I mentioned earlier, I have a love-hate relationship with this policy area. Older versions of IE Maintenance were super buggy, and this led to a lot of frustration. That said, this mechanism was the only policy-based method for configuring settings such as proxy addresses until Internet Settings in Group Policy Preferences came along. Additionally, it’s still the only way to configure site-to-zone assignments that doesn’t prevent your users from adding their own sites to zones if they need to.
However, there’s still some irritating behavior in IE Maintenance. When you first configure an IE Maintenance policy and you want to define, for example, Security Options, you open the interface in Group Policy Editor (GPE) to find a dialog box that resembles Figure 2.
This seemingly innocuous interface is important to understand. When you choose to import settings into the policy, the UI takes your current IE security settings from the machine on which you’re editing the GPO and imports them all—lock, stock, and barrel—into the IE Maintenance tool. If you go to another machine that’s running a different version of Windows, it will import those IE settings into your policy. If that second machine has a different version of IE installed, you might see different options as well. This could have many unintended consequences. Therefore, I strongly recommend that you always create and edit IE Maintenance policy from the same machine or at least from the same version of Windows and of IE every time. In most cases, if you’re editing IE Maintenance policy from a newer version of Windows (e.g., Windows 7 and IE 8), those settings are down-level compatible (e.g., setting a trusted sites zone from IE Maintenance on Windows 7 and IE 8 will still work when processed by a machine running XP SP3 and IE 7), but it’s always best to test this behavior for any settings that you want to deliver.
IE Maintenance Policy strengths. By and large, I recommend that people use this tool only when they need to control settings that can’t be controlled from anywhere else. IE Maintenance policy is not really policy, in that it doesn’t prevent the user from changing settings that you define. If you want to then prevent the user from changing those settings, you must also use the restrictions I mentioned in the Administrative Templates section. For example, if I use IE Maintenance to deliver proxy settings, I must also enable the User Configuration\Administrative Templates\Windows Components\Internet Explorer\Disable Changing Proxy Settings policy. Think of IE Maintenance policy as a way to set preferences that users can change unless you prevent them from doing so. However, these preferences will be reinforced upon any refresh of Group Policy, unless you’re explicitly using IE Maintenance in what’s called Preference mode, which can be enabled by right-clicking the Internet Explorer Maintenance node in GPE and selecting that option. When Preference mode is enabled, your IE Maintenance policy preferences are applied once to the user and then never again.
Table 2 lists some of the common areas that people often use IE Maintenance Policy to control.
IE Maintenance Policy weaknesses. I’ve already indicated that IE Maintenance policy is a poor choice for many IE configuration options because it doesn’t really enforce its settings unless you disable those UI elements by using Administrative Templates policy. If there are IE settings that you have to configure through IE Maintenance (e.g., privacy), just be aware that the behavior of this policy area can be a bit flaky. If you find that your users aren’t getting some settings you think they should, try issuing a Gpupdate /force command at the client workstation for any user who is having issues. Doing so might sometimes jumpstart IE Maintenance policy into doing what it’s supposed to do. Additionally, IE Maintenance does automatically maintain diagnostic logs in %userprofile\Appdata\local\Microsoft\Internet Explorer (in Windows 7) or in %userprofile%\application data\Microsoft\Internet Explorer (in XP) in the brndlog.txt file, as Figure 3 shows.
Group Policy Preferences Internet Settings
Group Policy Preferences is a relatively new feature that Microsoft added to Group Policy for the Server 2008 release. You don’t need Server 2008 to use the feature—any XP-and-later client can process Group Policy Preferences settings by using the correct Windows update that adds the Group Policy Preferences Client Side Extensions. However, you do need at least one Server 2008, Server 2008 R2, Windows 7, or Vista system to define and manage Group Policy Preferences settings. That can’t be done from XP or Windows 2003. The most recent release of Group Policy Preferences, which shipped with Windows 7 and Server 2008 R2, provides support for configuring IE 5, IE 6, IE 7, and IE 8. I suspect that when IE 9 ships, Microsoft will update Group Policy Preferences to support that version as well (although you might have to wait for a new OS for this to be added).
The Internet Settings capability is kind of an odd duck. As the name implies, many of the settings are actually preferences that configure but do not enforce IE options, just like IE Maintenance policy. On the other hand, the Group Policy Preferences Internet Settings policy area provides some features that IE Maintenance doesn’t, such as the Item-Level Targeting feature that is common to all Group Policy Preferences settings and that lets you deliver preference settings based on very granular targeting (e.g., by OS version or by laptop vs. desktop categories). Additionally, it contains some areas of IE control that the two previously mentioned policy areas don’t. Table 3 highlights some of these areas.
Group Policy Preferences Internet Settings strengths. The ability to leverage item-level targeting is a big advantage to using Group Policy Preferences Internet Settings, assuming you need that kind of granularity for targeting IE configuration settings. Group Policy Preferences Internet Settings also provides a much more straightforward UI in GPE, literally emulating the configuration tabs in the actual IE product for each supported version. And it explicitly supports various IE configuration options for the last four major versions of IE in a single UI, which is not something you can find in the other two policy areas unless you really work at it. Finally, as illustrated in the table above, this is the only policy area that lets you configure all the settings on the Advanced tab in the Internet Options dialog box.
Group Policy Preferences Internet Settings weaknesses. Similar to IE Maintenance, Group Policy Preferences Internet Settings suggests but does not enforce IE settings. You still need to use Administrative Templates to lock down UI areas that you configure through Group Policy Preferences. Additionally, there is a curious inconsistency about which settings are supported here. For example, on the Security tab, you can configure zone levels (e.g., high, medium-high), but you can’t configure site-to-zone assignments on the very same page—they’re inexplicably unavailable (appear dimmed). The same holds true on the Privacy tab, where you can configure pop-up allow lists but not any cookie-handling options. I can only imagine that Microsoft chose this approach to avoid muddying the already dark waters of IE configuration in the other two areas.
Getting on Top of IE
As I think I’ve illustrated, the policy picture isn’t altogether clear where configuring IE is concerned. For example, it’s unfortunate that Microsoft didn’t choose to use Group Policy Preferences as a platform for exposing all IE configuration settings and for really cleaning up their implementation. As a result, you have to choose your options carefully from the three different policy areas that I’ve discussed. Or, if the behavior of these three areas doesn’t suit your needs, you might have to resort to registry scripts or to the IE Administration Kit (IEAK) to muck with IE configurations.