Консоль управления групповыми политиками windows 10

Windows Group Policy allows you to run various script files at a computer startup/shutdown or during user logon/logoff. You can use GPOs not only to run classic batch logon scripts on domain computers (.bat, .cmd, .vbs), but also to execute PowerShell scripts (.ps1) during Startup/Shutdown/Logon/Logoff.

In modern versions of Windows, you can directly run logon/logoff PowerShell scripts from a GPO editor (previously it was necessary to call the .ps1 file from the .bat batch file as a parameter of the powershell.exe executable).

Run the Domain Group Policy Management console (GPMC.msc), create a new policy (GPO), and assign it to the target Active Directory container (OU) with users or computers (you can use WMI GPO filters for fine policy targeting). Switch to policy Edit mode.

You must select a GPO section to run the PowerShell script, depending on when you want to execute your PS1 script:

• If you want to run a PS script when a user logon (logoff) to a computer (to configure the user’s environment settings, or programs: for example, you want to automatically generate an Outlook signature based on the AD user properties, customize screensaver or Start screen settings), you need to go to the GPO section: User Configuration -> Policies -> Windows Settings -> Scripts (Logon / Logoff);
• If you want to run the PowerShell script at a computer startup (to disable legacy protocols: NetBIOS and LLMNR, SMBv1, configure computer security settings, etc.) or prior to the computer shutdown, you need to go to the GPO section with the computer settings: Computer Configuration -> Policies -> Windows Settings -> Scripts (Startup / Shutdown).

How to Run PowerShell Scripts on Windows Startup with Group Policy?

Suppose, we have to run the PowerShell script at a computer startup. Select the Startup policy, and go to the PowerShell Scripts tab.

Картинка с сайта: woshub.com

Now you need to copy the file with your PowerShell script to the domain controller. Copy your ps1 file to the Netlogon directory on the domain controller (for example, \\woshub.com\netlogon).

Since we configure the Startup PowerShell script, you need to check the NTFS “Read&Execute” permissions for the Domain Computers and/or Authenticated Users groups in the ps1 file permissions.

Now click Add and specify the UNC path to your ps1 script file in Netlogon.

Картинка с сайта: woshub.com

If you run multiple PowerShell scripts through a GPO, you can control the order in which the scripts are executed using the Up/Down buttons.

To correctly run PowerShell scripts during computer startup, you need to configure the delay time before scripts launch using the policy in the Computer Configuration -> Administrative Templates -> System -> Group Policy section. Enable the “Configure Logon Script Delay” policy and specify a delay in minutes before starting the logon scripts (sufficient to complete the initialization and load all necessary services). Usually, it is enough to put here 1 or 2 minutes.

Картинка с сайта: woshub.com

If your PowerShell script uses Windows networking, you need to enable the “Specify startup policy processing wait time” option for some GPOs (Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy). You can try starting from 60 seconds here. After enabling this policy, your computer will wait 60 seconds for network availability notifications before running your startup scripts. This is usually enough time to initialize the Windows networking stack.

Картинка с сайта: woshub.com

On Windows Server 2012R2 and Windows 8.1 and newer, PowerShell scripts in GPO are run from the NetLogon directory in the Bypass mode. This means that PowerShell Script Execution Policy settings are ignored. If you want to run a script from a different shared folder, or if you still have Windows 7 or Windows Server 2008R2 clients on your network, you need to configure the PowerShell script execution policy.

By default, Windows security settings do not allow running PowerShell scripts. The current value of the PowerShell script execution policy setting can be obtained using the Get-ExecutionPolicy cmdlet. If the policy is not configured, the command will return Restricted (any scripts are blocked). The security settings for running the PowerShell script can be configured via the “Turn On Script Execution” policy (in the GPO Computer Configuration section -> Administrative Templates -> Windows Components -> Windows PowerShell). Possible policy values:

• Allow only signed scripts (AllSigned) – you can run only signed PowerShell scripts (“How to digitally sign a PowerShell script?”) — this is the best option from a security perspective;
• Allow local scripts and remote signed scripts (RemoteSigned) – you can run any local and signed remote scripts;
• Allow all scripts (unrestricted) – the most insecure option, because allows running any PowerShell scripts.

Картинка с сайта: woshub.com

If not one of the settings of the PowerShell scripts execution policy is suitable for you, you can run PowerShell scripts in the Bypass mode (scripts are not blocked, and warnings do not appear).

To do this, run the PowerShell script from the Startup -> Scripts section. In this section, you can run your PS1 script by calling the powershell.exe executable (similar to the script described in the article). Set:

• Script Name: %windir%\System32\WindowsPowerShell\v1.0\powershell.exe
• Script Parameters: -Noninteractive -ExecutionPolicy Bypass -Noprofile -file %~dp0MyPSScript.ps1

The term %~dp0 is an environment variable that is automatically converted to a UNC path to the script directory (in this case, NETLOGON).

In this case, you are forced to allow any (even untrusted) PowerShell script to run using the Bypass parameter.

Reboot your computer to update the GPO settings and check that your PowerShell script runs after Windows boots.

Run Windows PowerShell Script at User Logon/Logoff

Let’s look at how to automatically run a PowerShell script when a user logs into (or logs out) Windows.

If you need to run the script not at computer startup, but after the user logs into Windows (for each user on the computer), you need to link the GPO to the Active Directory OU with users. In this case, the PowerShell script needs to be configured in the User Configuration section of your GPO.

If you want the policy to be applied to all users of a specific computer, you need to link the policy to the OU with computers and enable the Configure User Group Policy Loopback Processing mode parameter in Computer Configuration -> Administrative Templates -> System -> Group Policy). If you do not enable the loopback processing, then the parameters from the User Configuration section will not be applied to the user. For more information, check the post Group Policy Not Applying To User or Computer.

In this example, I will use a simple PowerShell script that writes the user’s login time to a text log file.

1. Copy your PowerShell script file to the\\woshub.com\NETLOGON\ folder on the Active Directory domain controller;
2. Go to User Configuration -> Policies -> Windows Settings -> Scripts -> Logon;
3. Go to the PowerShell Scripts tab and add your PS1 script file (use the UNC path, for example \\woshub.com\NETLOGON\UserLog.ps1 );
   

   Картинка с сайта: woshub.com

4. Re-login the user on the target computer;
5. Your PowerShell script will be launched automatically via GPO when the user logs in;
6. You can verify that the user logon script was executed successfully by the Event ID 5018u nder Microsoft-Windows-GroupPolicy/Operational section of Event Viewer:

   Completed Logon script for woshub\jsmith in 11 seconds.

   

   Картинка с сайта: woshub.com

If you want the user not to be able to access his desktop until the script is finished, you must enable the GPO parameter Run logon scripts synchronously (Computer Configuration –> Administrative Templates -> System -> Logon). In this case, the explorer.exe process will not start until all policies and logon scripts have been completed (this increases the user logon time!).

Note that the script runs with the current user permissions. If the user has administrative privileges on the computer and the User Account Control (UAC) settings are enabled, the PowerShell script cannot make changes that require elevated privileges.

In order to run PowerShell logon scripts with elevated user permissions, you can use the Scheduler Tasks.

1. Create a new Task Scheduler job under User Configuration -> Preferences -> Control Panel Settings -> Scheduled Task;
2. On the General tab, specify that the task will be started on behalf of the current user %LogonDomain%\%LogonUser and enable the Run with highest privileges option;
   

   Картинка с сайта: woshub.com

3. On the Trigger tab, specify that the task should be started At log on;
   

   Картинка с сайта: woshub.com

4. Specify the path to your PowerShell script file on the Actions tab:

Action: Start a program
Program/Script: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
Add Arguments (optional): -ExecutionPolicy Bypass -command "& \\woshub.com\Netlogon\Your_PS_Script.ps1"

Learn more about configuring Windows Scheduler tasks via GPO.

Such a PowerShell script will run as an administrator (if the domain user is added to the local Administrators group).

Some logon scripts need to be run for each user only once at the first login to the computer (initialization of the working environment, copying folders or configuration files, creating shortcuts, etc.). Here is a simple trick that allows you to run a script only once using GPO.

Картинка с сайта: habr.com

В очередной статье из цикла «конспект админа» мне хотелось бы освежить в памяти несколько нюансов использования групповых политик. Заодно поразвлекаемся с созданием своих шаблонов и с автоматизацией работы с этими самыми политиками.

Освежаем память

Я не буду рассказывать, что такое групповые политики, и остановлюсь лишь на основных моментах, которые стоит иметь в виду при работе с ними.

В системах Windows помимо доменных существуют и локальные групповые политики ― управлять ими можно при помощи оснастки gpedit.msc на системах редакции Professional и выше. Часто считается, что без домена можно настраивать локальные групповые политики только для всех пользователей на компьютере. Это не совсем верно ― с выходом Windows Vista появилась возможность использовать множественную локальную групповую политику или MLGPO. Этот механизм позволяет настраивать отдельные политики для разных пользователей.

Добраться до него можно через вызов консоли mmc: при добавлении оснастки «Управление объектами групповой политики» нажать кнопку «Обзор». Далее на вкладке «Пользователи» уже можно выбрать конкретного пользователя или группу «Администраторы» и «Не администраторы». К сожалению, управление для группы пользователей не реализовано.

Картинка с сайта: habr.com

Управление групповой политикой для отдельных пользователей.

Бывало и так, что на отдельностоящем терминальном сервере разворачивали Active Directory только для того, чтобы отдельному пользователю настроить поведение драйвера для EasyPrint. Не надо так.

При добавлении доменных групповых политик стоит помнить про порядок их применения ― политика, примененная последней, будет обладать наивысшим приоритетом (да и на собеседованиях часто спрашивают).

Итак, предположим, что у нас есть компьютер в домене и четыре групповые политики: локальная на этом компьютере; политика на подразделение, в котором находится компьютер; политика на домен и политика на лес. Порядок их применения будет следующим:

1. Локальная групповая политика.
2. Групповая политика сайта.
3. Групповая политика домена.
4. Групповая политика верхнего подразделения.
5. Групповая политика дочернего подразделения.

То есть чем ближе к объекту, тем приоритетнее, за исключением локальной групповой политики. Если надо отключить применение вышестоящих политик, то ставьте блокировку наследования.

Картинка с сайта: habr.com

Блокировка наследования.

Любую групповую политику можно условно разделить на две конфигурации ― пользователя и компьютера. Обычно политики с настройками компьютеров назначаются на подразделение, в котором находятся компьютеры. А политики с настройками пользователей ― на пользователей.

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

Работа замыкания настраивается непосредственно в политике ― «Настройка компьютера ― Административные шаблоны ― Система ― Режим обработки замыкания пользовательской групповой политики». Подробнее про механизм уже писали в статье про использование Merge\Replace в GPO. Я лишь добавлю, что режим замыкания групповой политики ― тоже частый вопрос на собеседовании.

Картинка с сайта: habr.com

Настройка замыкания групповой политики.

Физически доменные групповые политики находятся в папке SYSVOL на контроллерах домена. Папка реплицируется между контроллерами. Каждая групповая политика выглядит как папка с именем в виде GUID.

Картинка с сайта: habr.com

Групповые политики домена.

Правила фильтрации, настраиваемые через редактор групповой политики, соответствуют настройкам прав NTFS на соответствующую подпапку.

Говоря о правилах фильтрации, нельзя не упомянуть обновление MS16-072, которое «сломало» групповые политики. Теперь для того чтобы работали правила фильтрации, надо добавлять к каждому фильтру правило «на чтение», но не «на применение» группе Domain Computers.

В каждой папке с групповой политикой существуют подпапки Machine и User, соответствующие настройкам пользователя и компьютера. Если углубиться в подпапки, можно легко понять структуру групповой политики:

• В корне папки находится файл GPT.ini с настройками групповой политики, такими как ее название.
• В подпапках Machine и User сидят файлы registry.pol с настройками соответствующих веток реестра.
• По пути Microsoft\Windows NT\SecEdit можно найти шаблон настроек безопасности ― GptTmpl.inf.
• В подпапке Preferences находятся предпочтения групповых политик, представляющие из себя подпапки с файлами xml.
• В подпапке Applications сидят дистрибутивы для развертывания через групповые политики.
• В папке Scripts находятся скрипты на logon\logoff для пользователя и startup\shutdown для компьютера.
• В папке Documents and Settings есть настройки перенаправления пользовательских папок.
• Наконец, в папке Adm находятся устаревшие шаблоны групповой политики.

Подробнее про структуру можно почитать в материале Group Policy Basics, поэтому перейдем сразу к шаблонам.

Административные шаблоны

По сути своей административные шаблоны ― это специальные файлы с инструкциями по изменению клиентского реестра (ветки HKCU или HKLM) и настройками отображения изменяемых параметров через «Управление групповой политикой». В принципе, реестр можно менять и через «Предпочтения групповых политик». Но разница здесь не только в красивом интерфейсе.

Сравнение предпочтения групповых политик и административных шаблонов.

Другими словами, настройка реестра через шаблоны групповых политик более строгая. Тогда как настройка через предпочтения групповых политик напоминает периодическое применение reg-файла. Конечно, предпочтения позволяют не только менять параметры реестра, но и довольно гибко настраиваются. Тем и ценны.

Это актуально при изменении ветки Policies, и настраиваемое приложение должно хранить свои настройки в реестре. Простое изменение параметров через Предпочтения и Шаблоны будет работать схожим образом, только шаблоны могут оказаться удобнее.

До появления Windows Vista\2008 в качестве шаблона групповых политик брали исключительно стандарт .adm. Будучи с простой структурой, которую было легко редактировать вручную, этот стандарт обладал и рядом недостатков:

• Для каждого языка приходилось создавать отдельный файл шаблона.
• Файл шаблона физически находился в папке с групповой политикой. При использовании одного и того же шаблона он сохранялся в каждую папку, что увеличивало занимаемое место и время репликации.
• Не поддерживались мультистроковые параметры и параметры QWORD.

На замену устаревшему стандарту появился новый. Новые шаблоны представляют собой два файла: сам шаблон, не зависимый от языка ― .admx и языковой «пакет» к нему ― файл .adml. Теперь шаблоны можно «положить» в центральное хранилище, и обращаться к нему, не плодя одинаковые файлы в папке SYSVOL.

Не обошлось без ложки дегтя ― теперь содержимое файла представляет собой популярный в индустрии формат XML. И создавать новые шаблоны в блокноте стало уже не так удобно.

Под большинство параметров, которые могут понадобиться, шаблоны уже существуют. Кроме того, многие производители приложений выпускают свои административные шаблоны. Вот несколько примеров:

• MS Office 2016.
• FireFox и Thunderbird.
• Google Chrome.
• Adobe Acrobat и Reader.
• Каталог шаблонов для различного ПО.

Если возникает необходимость разработать и внедрить свой административный шаблон, то самый простой вариант ― это создать старый файл .adm и сконвертировать его в admx специальной утилитой. Вариант посложнее ― начинать сразу с .admx.

Создаем свой шаблон

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

Сразу скажу, что это можно провернуть через «Предпочтения групповых политик» ― в параметрах панели управления ― опции папки. Но мы легких путей не ищем и заодно не хотим, чтобы параметры отображения можно было менять вручную.

За необходимые нам параметры отвечают три ключа в реестре:

• Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden.
• Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\HideFileExt.
• Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden.

CLASS USER
CATEGORY !!ShowExplorer
    POLICY !!ShowHiddenFiles
        KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced"
        EXPLAIN !!ShowHiddenFilesExplanation
        VALUENAME "Hidden"
        VALUEON NUMERIC "1"
        VALUEOFF NUMERIC "2"
    END POLICY

    POLICY !!ShowFileExtensions
        KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced"
        EXPLAIN !!ShowFileExtensionsExplanation
        VALUENAME "HideFileExt"
        VALUEON NUMERIC "0"
        VALUEOFF NUMERIC "1"
    END POLICY

    POLICY !!ShowSuperHiddenFiles
        KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced"
        EXPLAIN !!ShowSuperHiddenFilesExplanation
        VALUENAME "ShowSuperHidden"
        VALUEON NUMERIC "1"
        VALUEOFF NUMERIC "0"
    END POLICY
END CATEGORY

[strings]
ShowExplorer="Отображение файлов в проводнике"
ShowHiddenFiles="Показывать скрытые файлы"
ShowHiddenFilesExplanation="Когда эта настройка включена, проводник будет показывать скрытые файлы."
ShowSuperHiddenFiles="Показывать системные файлы"
ShowSuperHiddenFilesExplanation="Когда эта настройка включена, проводник будет показывать системные файлы"
ShowFileExtensions="Показывать расширения файлов"
ShowFileExtensionsExplanation="Когда эта настройка включена, проводник будет показывать расширения файлов"

Разберем подробнее синтаксис файла.

• CLASS. Может принимать значение USER или MACHINE ― в зависимости от класса будет изменятся ветка реестра HKCU или HKLM соответственно.
• CATEGORY. Строка, в которой задается имя «папки» политики.
• POLICY. В строке задается название конкретной политики ― у нас таких будет три.
• KEYNAME. Путь в реестре к изменяемым параметрам.
• EXPLAIN. Отсылка к «переменной» с объяснением настройки.
• VALUENAME. Название изменяемого параметра в реестре.
• VALUEON**VALUEOFF**. Значение, которое будет принимать параметр при включении и выключении его в политике.
• [strings]. Секция со значениями переменных, которые я использовал для текстовых строк. Можно их не использовать, но тогда могут быть проблемы из-за русского языка.

Помимо задействованных опций есть и другие, например:

• EDITTEXT. Текстовое поле для ввода.
• NUMERIC. Поле для ввода цифр.
• CHECKBOX. Список, где можно отмечать параметры «галочками».
• COMBOBOX. Список с «переключателем»
• DROPDOWNLIST. Выпадающий список.
• LISTBOX. Список для ввода нескольких элементов.

Подробнее со всеми параметрами можно ознакомится в разделе MSDN ADM Format.

Установить новый шаблон не просто, а очень просто ― достаточно щелкнуть правой кнопкой мыши по пункту «Административные шаблоны», выбрать «Добавление и удаление шаблонов» и добавить наш свежесозданный шаблон.

Картинка с сайта: habr.com

Добавленный шаблон.

После установки шаблона он отобразится в ветке «Классические административные шаблоны».

Картинка с сайта: habr.com

Теперь можно сконвертировать наш шаблон в .admx с помощью утилиты faAdmxConv из ADMX Migrator.

Картинка с сайта: habr.com

Конвертируем шаблон.

После конвертации получившийся шаблон .admx и папку Ru-ru с файлом локализации .adml нужно скопировать в папку %Systemroot%\PolicyDefinitions для локальной политики или в папку Sysvol\PolicyDefinitions на контроллере домена.

Картинка с сайта: habr.com

Установленный шаблон .admx.

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="fullarmor" namespace="FullArmor.6fb075d6-ddee-4302-9d06-50c4d83e1910" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
  <supersededAdm fileName="E:\1\explorer.adm" />
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_NotSpecified" displayName="$(string.ADMXMigrator_NoSupportedOn)" />
    </definitions>
  </supportedOn>
  <categories>
    <category name="ShowExplorer" displayName="$(string.ShowExplorer)" />
  </categories>
  <policies>
    <policy name="ShowHiddenFiles" class="User" displayName="$(string.ShowHiddenFiles)" explainText="$(string.ShowHiddenFilesExplanation)" presentation="$(presentation.ShowHiddenFiles)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="Hidden">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
        <decimal value="2" />
      </disabledValue>
    </policy>
    <policy name="ShowFileExtensions" class="User" displayName="$(string.ShowFileExtensions)" explainText="$(string.ShowFileExtensionsExplanation)" presentation="$(presentation.ShowFileExtensions)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="HideFileExt">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="0" />
      </enabledValue>
      <disabledValue>
        <decimal value="1" />
      </disabledValue>
    </policy>
    <policy name="ShowSuperHiddenFiles" class="User" displayName="$(string.ShowSuperHiddenFiles)" explainText="$(string.ShowSuperHiddenFilesExplanation)" presentation="$(presentation.ShowSuperHiddenFiles)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="ShowSuperHidden">
      <parentCategory ref="ShowExplorer" />
      <supportedOn ref="SUPPORTED_NotSpecified" />
      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
  </policies>
</policyDefinitions>

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName></displayName>
  <description></description>
  <resources>
    <stringTable>
      <string id="ShowExplorer">Отображение файлов в проводнике</string>
      <string id="ShowHiddenFiles">Показывать скрытые файлы</string>
      <string id="ShowHiddenFilesExplanation">Когда эта настройка включена, проводник будет показывать скрытые файлы.</string>
      <string id="ShowSuperHiddenFiles">Показывать системные файлы</string>
      <string id="ShowSuperHiddenFilesExplanation">Когда эта настройка включена, проводник будет показывать системные файлы</string>
      <string id="ShowFileExtensions">Показывать расширения файлов</string>
      <string id="ShowFileExtensionsExplanation">Когда эта настройка включена, проводник будет показывать расширения файлов</string>
      <string id="ADMXMigrator_UnresolvedString">ADMX Migrator encountered a string that is not present in the source ADM string table.</string>
      <string id="ADMXMigrator_NoSupportedOn">ADMX Migrator encountered a policy that does not have a supportedOn value.</string>
    </stringTable>
    <presentationTable>
      <presentation id="ShowHiddenFiles" />
      <presentation id="ShowFileExtensions" />
      <presentation id="ShowSuperHiddenFiles" />
    </presentationTable>
  </resources>
</policyDefinitionResources>

Действительно, xml в новом формате читается чуть хуже, чем старый .adm. Для облегчения работы с новым форматом в поставке ADMX Migrator есть утилита faAdmxEditor.msc. Помимо этой утилиты есть и скрипты для конвертации reg-файлов в шаблоны, и сторонние платные утилиты.

Конечно же, можно обойтись без вот-этого-всего и разобраться самостоятельно ― оставлю это в качестве домашнего задания. Благо на портале MSDN есть подробное описание XML-схемы, и есть неплохие материалы с примерами в сети. Например, «Административные шаблоны групповой политики».

Теперь перейдем к автоматизации.

Автоматическое управление

Работать с групповыми политиками из командной строки довольно тоскливо. Основных инструментов можно выделить три.

PowerShell. Есть набор командлетов для резервного копирования, восстановления и управления групповыми политиками. Создание новых политик ограничено ― можно лишь изменять реестр. Впрочем, в большинстве случаев и этого достаточно. В качестве примера создадим групповую политику, которая отключит автоматическое обновление Adobe Reader DC.

За отключение автоматического обновления отвечает ключ реестра bUpdater в ветке [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown]. Установив параметр в 0, мы отключим опцию.

Создание групповой политики на PowerShell будет выглядеть так:

Import-module -Name GroupPolicy
Write-Host "Создаем новый объект политики с именем Adobe_Reader_disable_autoupdate"
New-GPO -Name Adobe_Reader_disable_autoupdate
Write-Host "Добавляем нужное нам значение реестра"
Set-GPRegistryValue -Name "Adobe_Reader_disable_autoupdate" -key "HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown" -ValueName  bUpdater -TypeDWord -value 0
Write-Host "Прилинковываем новый объект к нужному OU"
Set-GPLink -Name Adobe_Reader_disable_autoupdate -Target "ou=Computers,dc=domain,dc=com" -LinkEnabled Yes

Картинка с сайта: habr.com

Свежесозданная групповая политика.

Полный список и описание командлетов доступны в материале Technet Group Policy Cmdlets in Windows PowerShell.

Интерфейс COM к GPMC (консоли управления групповой политикой). Способ позволяет сделать с политиками многое, на любом языке программирования, поддерживающим COM-интерфейсы. К сожалению, популярность он не приобрел и примеров в сети довольно мало, несмотря на богатое описание методов интерфейса на портале MSDN. Немногочисленные примеры использования доступны для загрузки в галерее Technet.

LGPO.exe. Не так давно Microsoft заменил набор утилит для работы с локальными групповыми политиками на единую утилиту. Скачать ее можно на официальном сайте. Утилита удобна для копирования и развертывания локальных групповых политик. Заявлена и поддержка MLGPO. Создавать свои политики тоже можно. Также программа удобна для создания и изменения файлов реестра registry.pol. Для примера изменим локальную групповую политику, добавив в нее отключение обновления несчастного Acrobat Reader DC.

Сделаем бэкап локальной групповой политики командой

lgpo.exe /b C:\Temp /n "Backup"

В папке C:\Temp появится подпапка с GUID по структуре схожая с доменными групповыми политиками:

Теперь развернем registry.pol в текстовый файл:

LGPO.exe /parse /m C:\temp\{GUID}\DomainSysvol\GPO\Machine\registry.pol >> reg.txt

Синтаксис текстового файла очевиден. Добавим в него значения реестра для отключения автоматического обновления «Акробата»:

Картинка с сайта: habr.com

Добавленный в файл параметр реестра.

Теперь останется завернуть наш reg.txt обратно в registry.pol и импортировать изменившийся файл обратно в локальную групповую политику:

LGPO.exe /r C:\Temp\reg.txt /w C:\Temp\registry.pol
LGPO.exe /m C:\Temp\registry.pol​

Все эти махинации, конечно же, можно завернуть в один скрипт и использовать для массового изменения локальной групповой политики привычным инструментом для запуска команд на удаленных компьютерах. Подробнее про методы запуска команд можно почитать в нашей статье «1000++ способ запуска команд на удаленном компьютере».

Конечно же, зная структуру доменной групповой политики, ничто не мешает сделать удобный именно вам инструмент для создания и управления политиками. Поделитесь в комментариях, есть ли у вас свои способы настройки реестров пользовательских машин?

Групповая политика — это способ настройки параметров компьютера и пользователя для устройств, которые присоединены к доменным службам Active Directory (AD), а также к учетным записям локальных пользователей. Она контролирует широкий спектр параметров и может использоваться для принудительного применения и изменения настроек по умолчанию для соответствующих пользователей. Локальная групповая политика — это базовая версия групповой политики для компьютеров, не входящих в домен. Параметры локальной групповой политики хранятся в следующих папках: 

• C:\Windows\System32\GroupPolicy 
• C:\Windows\System32\GroupPolicyUsers.

Когда в Windows 10 вам необходимо открыть редактор локальной групповой политики, для этого вы можете использовать командную строку, команду выполнить, поиск на панели задач, меню Пуск или с помощью консоли управления (MMC).

Рассмотрим самые простые варианты:

1. C помощью меню Пуск.
2. C помощью команды Выполнить.
3. C помощью Проводника Windows.
4. С помощью командной строки или PowerShell
5. Открыть редактор локальной групповой политики в качестве оснастки консоли управления.
6. Открыть редактор локальной групповой политики в Windows 10 Home.

Открыть редактор локальной групповой политики с помощью меню «Пуск».

1. Откройте меню «Пуск» и введите gpedit.msc в верхней части меню появится значок, при клике, на котором, откроется редактор политики.

Картинка с сайта: g-ek.com

Картинка с сайта: g-ek.com

Чтобы просмотреть все применяемые политики в разделе «Конфигурация компьютера», перейдите в раздел «Конфигурация компьютера \ Административные шаблоны \ Все параметры» 

Чтобы просмотреть все применяемые политики пользовательской настройки, перейдите в раздел «Конфигурация пользователя \ Административные шаблоны \ Все параметры».

Примечание: вы можете использовать поиск на панели задач.

Открыть редактор локальной групповой политики с помощью команды «Выполнить».

1. Нажмите сочетание клавиш Win + X или кликните правой кнопкой мыши на меню «Пуск».

1. В открывшемся меню выберите Выполнить.

1. В строке «Открыть» введите — gpedit.msc и нажмите кнопку «ОК».

Картинка с сайта: g-ek.com

Открыть редактор локальной групповой политики с помощью Проводника Windows.

1. Откройте Проводник с помощью ярлыка на панели задач или просто нажав сочетание клавиш Win + E
2. В адресную строку проводника введите или скопируйте и вставьте:

gpedit.msc

1. Нажмите Enter

Картинка с сайта: g-ek.com

Открыть редактор локальной групповой политики из командной строки или PowerShell

1. Откройте Командную строку или вы можете открыть новый экземпляр PowerShell.

1. Введите: gpedit.msc  и нажмите клавишу Enter.

Открыть редактор локальной групповой политики в качестве оснастки консоли управления.

1. Откройте консоль управления MMC. (Нажмите кнопку «Пуск», введите mmc и нажмите клавишу Enter).

Картинка с сайта: g-ek.com

1. В меню Файл выберите пункт Добавить или удалить оснастку.

Картинка с сайта: g-ek.com

1. В открывшимся диалоговом окне, дважды кликните «Редактор объектов групповой политики» и нажмите кнопку «Готово» и «ОК».

Картинка с сайта: g-ek.com

Открыть редактор локальной групповой политики в Windows 10 Home.

Как вы уже знаете, приложение Редактора локальной групповой политики доступно в Windows 10 Pro, Enterprise или Education. Пользователи Windows 10 Home не имеют доступа к gpedit.msc из-за ограничений ОС. Вот простое и элегантное решение, которое позволяет разблокировать его без установки сторонних приложений.

Существует простой способ включить Редактор локальных групповых политик в Windows 10 Home запустив всего лишь один пакетный файл.

Чтобы включить Gpedit.msc (групповая политика) в Windows 10 Home

1. Загрузите следующий ZIP-архив: Скачать ZIP-архив.
2. Распакуйте его содержимое в любую папку. Он содержит только один файл, gpedit_home.cmd
3. Кликните правой кнопкой мыши по файлу.
4. Выберите в контекстном меню «Запуск от имени администратора».

Все!

Пакетный файл вызовет DISM для активации редактора локальной групповой политики. Подождите, пока командный файл не завершит свою работу.

Помните, что некоторые политики не будут работать в Windows Home. Некоторые политики жестко заданы для версий Windows Pro. Кроме того, если вы активируете gpedit.msc с помощью предоставленного пакетного файла, изменение политик для отдельных пользователей не вступит в силу. Они по-прежнему требуют настройки реестра.

Вы можете самостоятельно создать пакетный файл. Прежде чем начать, рекомендуем создать точку восстановления системы, и вы могли в любой момент отменить произведенные изменения в системе.

1. Откройте текстовый редактор, например «Блокнот».

1. Скопируйте и вставьте следующие строки:

@echo off 
pushd "%~dp0" 

dir /b %SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~3*.mum >List.txt 
dir /b %SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~3*.mum >>List.txt 

for /f %%i in ('findstr /i . List.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i" 
pause

Картинка с сайта: g-ek.com

1. В меню «Файл» текстового редактора выберите «Сохранить как» в диалоговом окне в строке «Имя файла» введите — gpedit.bat и нажмите кнопку «Сохранить».

Картинка с сайта: g-ek.com

1. Запустите от имени Администратора полученный пакетный файл gpedit.bat

1. При запросе фильтра Windows SmartScreen, нажмите «Подробнее», затем нажмите кнопку «Выполнить в любом случае».

Картинка с сайта: g-ek.com

1. В окне Контроля учетных записей, нажмите кнопку «Да».

1. Дождитесь пока утилита DISM внесет изменения и закройте окно.

Все! Редактор локальных групповых политик (gpedit.msc) включен и теперь Вы можете его запустить любым из описанных выше способов.

Policy Plus

Существует хорошая альтернатива встроенному приложению gpedit.msc, которое называется Policy Plus. Это стороннее приложение с открытым исходным кодом: PolicyPlus

Policy Plus предназначен для того, чтобы сделать параметры групповой политики доступными для всех.

• Редактор работает на всех выпусках Windows, не только на Pro и Enterprise
• Полностью соблюдает условия лицензирования

• Просмотр и редактирование политик на основе реестра в локальных объектах групповой политики, объектах групповой политики для отдельных пользователей, отдельных файлах POL, автономных кустах пользователей реестра и действующем реестре

• Переход к политикам по идентификатору, тексту или отдельным записям реестра.
• Просмотр дополнительной технической информации об объектах (политики, категории, продукты)
• Удобные способы изменить и импортировать настройки политики

Рекомендуем: 

• Как Windows 10 вернуть настройки локальной групповой политики по умолчанию.

Не так часто мне удавалось видеть рабочую конфигурацию «Сценария запуска для компьютера» и уж тем более не доводилось реализовать. Но вот возникла необходимость. И казалось-бы у Miscrosoft в редакторе GPO имеются для этого комфортные средства. Бери и делай! Но что-то пошло не так… и мои скрипты не захотели работать. Поэтому здесь я опишу то, с чем мне пришлось столкнуться в процессе решения такой задачи.

Итак, первое, и пожалуй одно из самых важных — это понимание того, что запускаться скрипты будут не от имени пользователя (как авторизованного пользователя в домене), а именно от имени учетной записи компьютера с наивысшими правами, не требующими повышения. А важно это потому, что имеет смысл сразу определиться с местоположением ваших скриптов.

В Microsoft подразумевается, что свои скрипты вы будете размещать в папке, которая соответствует редактируемой политике. Но во-первых, это не всегда так, а во-вторых логично предположить, что права (хотя-бы на чтение) у компьютера, который будет обращаться к скрипту — имеются. Однако это тоже ложное мнение! Итак, первое, с чем мы определимся…

Выбор расположения скриптов и права доступа

Мои скрипты расположены не только в папке политики, которая их и будет выполнять.

Один скрипт у меня находится: \\domen.local\SysVol\domen.local\Policies\{E4A966DE-1FFE-40C8-B3B2-50888E146A4D}\Machine\Scripts\Startup\Main.ps1

Второй скрипт вызывается из первого и у меня он находится: \\domen.local\NETLOGON\zabbix_install.ps1

В случае первого скрипта необходимо: Открыть в редакторе GPO (нужной вам политики): Конфигурация компьютера — Политики — Конфигурация Windows — Сценарий (запуск/завершение) — выбрать Автозагрузка.

В открывшемся окне перейти на вкладку Сценарии PowerShell и нажать внизу кнопку: Показать файлы

Картинка с сайта: blog.shestov.info

Открывшаяся папка — то, что вам нужно. Сюда вы копируете свои скрипты, которые планируете выполнять этой политикой. И сразу проверяете права этой папки.

На вкладке Безопасность  проверяем наличие прав доступа на чтение и выполнение — группе Domain Computers

Права для SYSTEM (Full) — как правило выставляются корректно изначально. Creator Owner — так же являются корректными. 

Если права отсутствуют — добавляем их.

И это касается каждой папки, к которой планируется обращение от имени доменного компьютера!!!

Т.е. в моем случае — мне было необходимо дать такие права еще для папки \\domen.local\NETLOGON а так-же для шары, к которой обращается скрипт и пишет туда логи. \\shara\LOG

Интерфейс добавления скрипта для обработки в GPO неоднозначен, что касается выбора расположения скрипта и предоставляет различные возможности. А именно: прописать скрипт по локальному пути, по сетевой шаре, указать параметры запуска и даже порядок выполнения, относительно скриптов-пакетников.

Я тестировал различные варианты и уже сложно сказать, что работало, а что нет. Потому-что если одно работало — то другое уже отказывалось.  Именно поэтому я сообщаю лишь итоговый рабочий вариант.

Вы скопировали скрипт в папку используемой политики в этом-же окне жмете кнопку добавить и выбираете скрипт. Однако в окне скриптов (это видно на скрине выше)  — пути к файлу нет. И это нормально. Я тестировал варианты: прописать путь до скрипта даже по сети, например: \\shara\PS\Main.ps1 и такое тоже выполнялось, если права на чтение папки компьютерами домена — присутствовало. Поэтому экспериментируйте.

Картинка с сайта: blog.shestov.info

По большому счету все. НО! По умолчанию, ваши PS скрипты не будут запускаться даже из сети, основываясь на безопасности GPO. 

Путей решения несколько. Разрешить запуск любых скриптов. Или использовать политику безопасности, которая позволит запускать скрипты, расположенные локально или в сети, но при этом скрипты должны быть подписаны.

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

Изменение политики безопасности PowerShell — Выполнение сценариев

Находим нужную политику: Конфигурация Компьютера — Административные шаблоны — Компоненты Windows — Windows PowerShell и открываем политику: «Включить выполнение сценариев»

По умолчанию она выключена, а это значит, что выполнение скриптов ЗАПРЕЩЕНО!

Включая — нам становятся доступны опции политики выполнения и если вас не интересует подпись сертификатов — вы выбираете «Разрешить все сценарии«.

Картинка с сайта: blog.shestov.info

Однако хочу сказать, что подпись сценариев оказалось не столь проблематичной, и отладив эту процедуру — вы можете поставить еще одну галочку напротив усиления мер безопасности в вашей сети Как это сделать рассказано во второй части.

Для проверки текущей политики безопасности существует командлет:

Get-ExecutionPolicy 

Restricted — блокируются любые скрипты.

AllSigned — разрешены только те, которые имеют цифровую подпись

RemoteSigned — скрипты, на локальном компьютере, можно запускать без ограничений. Скрипты, загруженные из интернета — только при наличии цифровой подписи.

Unrestricted — разрешены любые скрипты, но запуская неподписанный скрипт из интернета — программа может потребовать подтверждение.

Bypass — ничего не блокируется, никакие предупреждения и запросы не появляются.

Последний вариант часто используют в пакетниках, вызывая доверенные ps1 скрипты, для беспроблемного запуска. Например:

powershell.exe -executionpolicy bypass -File C:\scripts\backup.ps1

Кстати запуск из cmd или bat — Это еще один наиболее простой запуск ps1 скрипта без заморочки на политику безопасности и подписании скриптов  

Запуск скриптов в Windows Server 2012 R2  Windows 8.1 и выше

Это еще один подводный камень. По умолчанию, в версиях 2012 R2 и Windows 8.1 скрипты компьютера на запуск — имеют задержку на выполнение в 5 минут. 

Чтобы это исправить необходимо скорректировать еще один пункт в политике безопасности.

На данный момент уровень моего домена и леса = 2012. Как и все контроллеры домена, под управлением Windows Server 2012. А в этих версиях отсутствует параметр управления этой задержкой. Поэтому первое, что необходимо сделать, это скачать административные шаблоны ADMX отсюда: http://www.microsoft.com/ru-ru/download/details.aspx?id=41193

Скачав файл Windows8.1-Server2012R2ADMX-RTM запустите его установку на одном из контроллеров домена. Путь по умолчанию будет: C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions\ Зайдите в эту папку и удалите лишние языковые директории. Я оставил лишь en-US и ru-RU т.к. имею в распоряжении русскую и английскую версию оснастки.

Теперь необходимо создать Централизованное хранилище политик. На контроллере домена скопировать папку PolicyDefinitions целиком из %systemroot% в папку %systemroot%\sysvol\domain\policies\ 

Затем скопировать содержимое из папки C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions\ в папку %systemroot%\sysvol\domain\policies\PolicyDefinitions\ 
В последствии эти шаблоны будут автоматически распространены и для других контроллеров домена. А вам необходимо только перезапустить оснастку редактора групповых политик.

Переходим к настройке: Конфигурация компьютера — Политики — Административные шаблоны — Групповая политика — Настроить задержку сценария входа 

Включаем этот параметр и выставляем значением «0 мин». Таким образом мы полностью отключаем задержку сценария входа.

Картинка с сайта: blog.shestov.info

Теперь наши скрипты будут также успешно работать и в Windows 2012 R2 и Windows 8.1 при загрузке компьютера!

Продолжение: 

GPO AD: Computer Startup scripts and Powershell (часть 2: Создание своего сертификата. Подпись скриптов)

GPO AD: Computer Startup scripts and Powershell (часть 3: PsExec. Ловим ошибки)

Также вы можете посмотреть мои обращения в Microsoft Technet, где мне успешно помогали решать эти задачи. За что коллегам отдельная благодарность!

Запуск f2.ps1 из f1.ps1 и вывод в лог.

Не срабатывает сценарий Logon в GPO для политики Компьютера