How to configure Group Policy Preference settings for Internet Explorer 11 in Windows

This article explains how to configure Internet Explorer 11 Group Policy Preference (GPP) settings to apply on computers running Windows operating system.

Original product version: В Internet Explorer 11, Windows 8.1, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard
Original KB number: В 2898604

More information

Pre-requisite: Install Remote Server Administration Tools (RSAT)](/windows-server/remote/remote-server-administration-tools) on your system.

After installing the tools, you can use the following procedure to configure Internet Explorer 11 Group Policy Preference (GPP) settings on your computer.

Open Group Policy Management Console (GPMC.MSC)

Create a new Group Policy Object (GPO) or select an existing Group Policy Object (GPO) to modify.

Right-click the selected Group Policy Object (GPO) and select Edit and browse to:

User Configuration\Preferences\Control Panel Settings\Internet Settings

Select Internet Settings and then right-click to select New and choose the option of Internet Explorer 10.

Configure the desired Internet Explorer Preference settings and select Apply and then OK.

Run the following command at a command prompt on clients where you want the settings to apply or wait for the group policy background refresh:

You need to select the option of Internet Explorer 10 in Group Policy Preference (GPP) to apply the settings for Internet Explorer 11 as the same settings apply to Internet Explorer 11.

Group Policy Overview

Applies To: Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 8

Use this topic to find the documentation resources and other technical information you need to accomplish key Group Policy tasks. You can learn about new and updated functionality for Group Policy in Windows Server 2012 R2 and Windows 8.1and ways to automate common Group Policy tasks by using Windows PowerShell.

Did you mean…

Feature description

Group Policy is an infrastructure that allows you to specify managed configurations for users and computers through Group Policy settings and Group Policy Preferences. To configure Group Policy settings that affect only a local computer or user, you can use the Local Group Policy Editor. You can manage Group Policy settings and Group Policy Preferences in an Active Directory Domain Services (ADВ DS) environment through the Group Policy Management Console (GPMC). Group Policy management tools also are included in the Remote Server Administration Tools pack to provide a way for you to administer Group Policy settings from your desktop.

Windows PowerShellВ В В When the GPMC is installed on servers or client computers, the Windows PowerShell module is also installed. You have full Windows PowerShell functionality. If you install the Remote Server Administration Tools pack, the latest Windows PowerShell cmdlets for Group Policy are also installed. For more information about Windows PowerShell cmdlets and scripts that you can use to manage Group Policy, see Group Policy Cmdlets.

You can configure the Group Policy feature by using Windows PowerShell cmdlets. For more information about using Server Manager cmdlets to install the Group Policy Management Console, see Install or Uninstall Roles, Role Services, or Features and Server Manager deployment cmdlet module.

Practical applications

By using Group Policy, you can significantly reduce your organization’s total cost of ownership. Various factors, such as the large number of policy settings available, the interaction between multiple policies, and inheritance options, can make Group Policy design complex. By carefully planning, designing, testing, and deploying a solution based on your organization’s business requirements, you can provide the standardized functionality, security, and management control that your organization needs.

Here are some Windows Server 2012 scenarios that use Group Policy to implement a solution:

New and changed functionality

Group Policy designs can become very complex. Various factors, such as the large number of policy settings and preference items available, the interaction between multiple policies, and inheritance options, can make it difficult to determine if Group Policy is functioning correctly on each computer.

In Windows Server 2012, Group Policy focused on improving the Group Policy troubleshooting experience. Windows Server 2012 R2 expands the support for IPv6 networking, adds policy caching to reduce sign-in times in synchronous mode, and provides more detailed event logging. For more details about these changes and more information about the additional changes in functionality that are not listed here, see What’s New in Group Policy in Windows Server 2012 [redirected] and What’s New in Group Policy in Windows Server.

WSUS — Управление клиентами с помощью Group Policy Preferences

Если вы имеете разветвлённую инфраструктуру WSUS с центральным сервером и некоторым количеством подчинённых серверов то, возможно, вы используете для централизации управления клиентами WSUS групповые политики. С появлением механизмов Group Policy Preferences (GPP) у нас появилась возможность вместо множества групповых политик настраивающих разные наборы клиентских компьютеров на ближайшие к ним WSUS сервера, — использовать одну групповую политику с рядом соответствующих настроек в зависимости от тех или иных условий.

Рассмотрим пример создания такой единой групповой политики с следующими исходными данными:

• Имеется головной сервер WSUS и несколько подчинённых ему серверов;
• Все сервера расположены в разных физических локациях и обслуживают свой набор клиентских компьютеров, находящихся в разных IP диапазонах;
• Один сервер WSUS может обслуживать несколько разных локаций, по каждой из которых необходимо иметь раздельную статусную информацию;
• Есть необходимость разделения всех клиентов на всех WSUS серверах на логические категории для возможности разграничения процедур одобрения тех или иных наборов обновлений.

Для разграничения всех клиентов мы используем стандартный механизм создания групп компьютеров на сервере WSUS. Для примера создадим отдельные группы для каждой физической локации и дополнительно создадим две вспомогательные группы:

• KOM-All-Test-New-Updates — для тестирования новых обновлений
• KOM-All-Not-Install-IE9 – для настройки запрета установки IE9

Группы создаются на головном сервере и реплицируются с механизмом синхронизации на все подчинённые сервера.

Создание групп WSUS позволяет не только более гибко управлять одобрением/отклонением тех или иных обновлений но и получать сводную статусную информацию о результатах полноты установки обновлений в консоли WSUS

Итак, перейдём к настройке групповой политики. Для этого откроем консоль управления групповыми политиками (gpmc.msc) и создадим новый объект групповой политики, в котором сразу можно выключить настройки конфигурации пользователя, так как мы будем использовать только раздел конфигурации компьютера — Computer Configuration

В стандартных Административных шаблонах этой политики зададим основные параметры настройки клиента WSUS которые могут применяться ко всем без исключения клиентам WSUS. На скриншоте приведён пример настройки таких общих параметров:

Все остальные настройки, которые могут меняться в зависимости от условий, которые выдвигаются клиентами WSUS, мы вносим в GPP в раздел настроек Preferences > Windows Settings > Registry

Создадим в корне дерева этих настроек 2 параметра — 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:

Куст реестра: HKEY_LOCAL_MACHINE

Ключи реестра
для x86: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
для x64: SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Параметр: TargetGroupEnabled REG_DWORD = 1

Ключи реестра:
x86: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
x64: SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU

Параметр: UseWUServer REG_DWORD = 1

Эти два параметра вынесены на верхний уровень настроек специально для наглядности и будут применяться ко всем компьютерам на которые будет действовать данная политика

Параметры сделаны отдельно для 32-битных (x86) и 64-битных (x64) систем, так как в зависимости от битности ОС используются разные ветки реестра. Для 64-битных клиентов WSUS во всех идущих далее по описанию ключах реестра добавляется дополнительное условие нацеливания Item-level targeting

Это условие построено на проверке наличия ветки реестра SOFTWAREWow6432Node в кусте HKEY_LOCAL_MACHINE, то есть, если эта ветка существует, значит обработка политики происходит на 64-битном клиенте

Помимо указанных двух параметров в корне настроек вы можете видеть группы, которые сделаны для того, чтобы отделить клиентов в зависимости от сервера WSUS к которому они должны принадлежать. Для наглядности эти группы именованы так же как и сами сервера WSUS. Для того чтобы отнести клиентов к той или иной группе настроек мы включаем нацеливание по диапазонам IP адресов клиентов. То есть вложенные в эту группу настройки будут применяться к клиентам только в том случае, если они входят в соответствующие IP диапазоны.

Теперь заглянем внутрь любой из таких серверных групп. Внутри каждой группы сделаны настройки на конкретный сервер для того, чтобы клиенты знали куда им ходить за обновлениями и куда отправлять статусную информацию. Это 2 параметра — 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:

Куст реестра: HKEY_LOCAL_MACHINE

Ключ реестра:
x86: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
x64: SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Параметры:
WUServer REG_SZ = https://KOM-SRV-WSUS:8531
WUStatusServer REG_SZ = https://KOM-SRV-WSUS:8531

Внутри каждой группы уровня настроек серверов создаём подгруппы с помощью которых будут настроены параметры реестра для работы механизма WSUS client-side targeting, то есть для автоматического распределения клиентов по группам WSUS, о которых мы говорили в самом начале. В нашем случае нацеливание GPP выполнено опять-таки на IP адрес клиента, при этом надо понимать что IP диапазон который мы указываем в подгруппе должен входить в логику диапазонов группы верхнего уровня.

Внутри подгруппы создаём параметры для WSUS client-side targeting:

Куст реестра: HKEY_LOCAL_MACHINE

Ключи реестра:
x86: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
x64: SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Варианты указания параметра:

TargetGroup REG_SZ = KOM-AD01
TargetGroup REG_SZ = KOM-AD01;KOM-All-Test-New-Updates
TargetGroup REG_SZ = KOM-AD01;KOM-All-Not-Install-IE9

Если клиент должен входить в несколько групп, то их названия перечисляются в значении через точку с запятой. При этом если группы WSUS имеют вложенную структуру, указывается конечное имя группы (без информации об иерархии). Эту особенность необходимо учитывать в процессе планирования и создания структуры групп WSUS.
Важно так же помнить, что порядок применения GPP (Order) тоже имеет своё определяющее значение.

На этом уровне в нашем примере мы комбинируем разные варианты значения одного и того же параметра реестра в зависимости от разных условий. Например, за дополнительное условие взято членство учетной записи компьютера в доменной группе безопасности. То есть в данном случае значение ключа TargetGroup будет установлено в “KOM-AD01;KOM-All-Test-New-Updates” при условии, если компьютер имеет 64-битную ОС и входит в соответствующую группу тестовых компьютеров в домене.

Обратите внимание на, то что при указании доменной группы безопасности лучше не вводить её название прямо в поле Group, а пользоваться кнопкой обзора, чтобы Tardeting Editor корректно определил SID этой группы.

На этом настройку GPP можно считать законченной и для того, чтобы параметры реестра для механизма авто-назначения в группы WSUS применившись на клиентских компьютерах начали работать, – необходимо переключить сервер WSUS в режим управления групповыми политиками. Для этого в консоли WSUS — Параметры > Компьютеры (Options > Computers) включим соответствующую настройку:

Обратите внимание, на то что эту настройку нужно изменить на всех серверах WSUS.

Результат в консоли WSUS мы сможем увидеть далеко не сразу, так как для вступления новых параметров реестра на клиентах в силу требуется как минимум перезапуск клиентской службы Windows Update (wuauserv), что например, на рабочих станциях достигается элементарным циклом выключения/включения компьютера пользователями. Возможно также на некоторых “непослушных” клиентах потребуется сбросить авторизацию на сервере WSUS

wuauclt /resetauthorization /detectnow

Не забывайте так же про то, что для того чтобы созданная нами групповая политика успешно работала, – клиенты должны уметь работать с GPP, особенно это касается уже устаревших на сегодня систем типа Windows XP.

Дополнение от 21.10.2011

Может возникнуть ситуация, когда потребуется отдельная настройка параметра групповой политики Allow non-administrators to receive update notifications из состава Административных шаблонов (в разделе Computer Configuration > Administrative Templates > Windows Components > Windows Update). Этот параметр обозначает возможность видеть непривилегированным пользователям оповещения клиента WSUS о доступности новых обновлений и инициировать процесс установки обновлений. Для рабочих станций это нормальная ситуация, а вот на терминальных серверах это может стать настоящей головной болью и поэтому для серверов этот параметр лучше выключать. То есть можно в Административных шаблонах этот параметр оставить ненастроенным, а настраивать его ключом реестра через вышеописанный механизм GPP:

Куст реестра: HKEY_LOCAL_MACHINE

Ключ реестра:
x86: SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
x64: SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Параметр: ElevateNonAdmins REG_DWORD 1 или 0

Возможные значения ключа:

• 1 – Включено. Пользователи получают оповещения клиента WSUS о доступности свежих обновлений и могут инициировать процесс установки обновлений
• 0 – Выключено. Пользователи не видят оповещений и только администраторы могут управлять процессом установки обновлений.

Таким образом можно создать соответствующие правила обработки GPP с нацеливанием например на версию ОС (серверная/не серверная) ну или например по имени компьютера если в вашей организации действуют какие-то жёсткие стандарты именования компьютеров. Тут уж всё зависит от вашей фантазии.

В своём случае я решил эту проблему немного иначе – для терминальных серверов у меня настроена отдельная групповая политика с замыканием обработки параметров на себя, то есть её параметры всегда будут перекрывать параметры общей политики WSUS. И уже в этой специальной политике этот параметр у меня выключен и пользователям терминального сервера не досаждают оповещения клиента WSUS.

В качестве эпилога, предвидя реплики типа “Всё гибче делается в SCCM”, отмечу сразу то, что эта заметка рассчитана на тех, кто по каким-то причинам не может использовать подобные решения. Как видите, все настройки сделаны в рамках стандартных функциональных возможностей Windows Server.

Дополнительные источники информации: