Параметры сценария автозагрузки gpo

Обновлено 17.07.2019

Добрый день! Уважаемые читатели и гости одного из крупнейших IT порталов в России Pyatilistnik.org. В прошлый раз вы меня просили рассказать вам, о рабочих методах исправления черного экрана Windows 10 и я с вами ими поделился. Так как направленность моего ресурса больше рассчитана на системных администраторов и продвинутых пользователей, то я сегодня хочу вновь поговорить про групповые политики и автоматизацию получаемую благодаря им. В данной публикации речь пойдет, о запуске скрипта PowerShell средствами GPO (Групповой политики), мы рассмотрим все варианты доступные администраторам.

Постановка задачи

Когда начинающий системный администратор превращается в матерого админа, он хочет везде все автоматизировать и везде экономить свое время, и это логично люди существа любящие комфорт и лень. Рабочая среда Active Directory позволяет, как все знаете через групповые политики настройку почти всех компонентов в системе, а что не может замещается средствами PowerShell, вот такой симбиоз. В нашу задачу входит научиться запускать при загрузке компьютера или при входе пользователя на компьютер или сервер, наш скрипт PowerShell, который реализует ту или иную задачу, это не важно, пусть например монтирует базы 1С.

Методы запуска скрипта PowerShell через GPO

Существует несколько сценариев позволяющих вам применять к вашим объектам нужные скрипты:

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

Запуск PowerShell скрипта в автозагрузке сервера

Открываем оснастку «Управление групповой политикой» и создаем на нужном уровне вашей иерархии организационных подразделений, новую политику, в моем примере, это будет «Добавление баз 1С». Переходим к ее редактированию.

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

Тут вы увидите два возможных варианта «Автозагрузка» и «Завершение работы»

Далее вы открываете пункт «Автозагрузка», переходите на вкладку «Сценарий PowerShell» и нажимаете кнопку «Добавить«. Через окно «добавление сценария» откройте папку «Startup» и скопируйте туда ваш скрипт. Теперь данный файл будет частью папки Sysvol и располагаться в конкретном GPO объекте.

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

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

1. Во первых по умолчанию в Windows есть 5-ти минутная задержка выполнения скриптом, как ее отключать я рассказывал можете почитать вот тут.
2. Если у вас в локальной сети присутствуют операционные системы по типу Windows Server 2008 или ниже, то там есть подводные камни в виде выполнения неподписанных скриптов и во вторых в старой версии PowerShell

Хочу отметить, что начиная с Windows Server 2012 R2, Windows 8.1 и выше, все запускаемые сценарии PowerShell через GPO работают в режиме Bypass, что подразумевает игнорирование политики Set-ExecutionPolicy. Но если у вас есть более старые клиенты, то вы можете пойти вот таким путем:

Вы можете явно указать исполняемый файл PowerShell, для этого в политике откройте вкладку «Сценарии», нажмите добавить. В имя сценария введите путь до файла powerShell, это:

В параметрах сценария введите вот такие ключи и сетевой путь до скрипта PowerShell.

Еще для подстраховки вы можете включить параметр GPO

Активируем настройку «Включить выполнение сценариев (Turn On Script Execution)», выставим значение «Разрешать все сценарии«.

Проверяем применение вашей GPO, если все настроили правильно она отработает если нет, то начинается траблшутинг, проверяете фильтры GPO и общий алгоритм поиска проблем.

Запуск PowerShell скрипта для пользователя

Чтобы применить к пользователю ваш скрипт, вам необходимо в объекте групповой политики открыть вот такую ветку:

Тут будет два варианта «Вход в систему» и «Выход из системы».

Настраиваем аналогично, как я показывал выше для компьютера, все одинаково.

Выполнение сценариев PowerShell по расписанию

Тут все просто, если вы хотите средствами групповой политики запускать скрипты PowerShell по расписанию, то вам нужно создать задание в шедуллере. Для этого есть ветки GPO:

Указываем в задании нужное время, имя и сетевой путь до скрипта.

Как видите все просто. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Опубликовано: 13.06.2017

Инструкция представляет шпаргалку по настройке автозапуска сценария при выполнении входа в систему Windows (login).

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

И так, запускаем консоль управления групповыми политиками и создаем новый объект GPO.

1. Разрешаем запуск скриптов.

Конфигурация компьютера Административные шаблоны Компоненты Windows Windows Powershell
(Computer Configuration  Administrative Templates  Windows Components  Windows PowerShell)

Находим параметр Включить выполнение сценариев (Turn On Script Execution) и выставляем значение Включить и в выпадающем списке Разрешить все сценарии.

2. Настраиваем время задержки для выполнения скриптов.

Конфигурация компьютера Административные шаблоны Система Групповая политика
(Computer Configuration  Administrative Templates System Group Policy)

Находим параметр Настроить задержку сценария входа в систему (Configure Logon Script Delay) и выставляем значение Включить и время задержки в минутах, например 1.

* как показала практика, лучше ставить хоть какую-то задержку.

3. Настраиваем автозапуск скрипта при входе.

Конфигурация компьютера (или Конфигурация пользователя) Политики Конфигурация Windows Сценарии
(Computer Configuration или User Configuration Policies Windows Settings Scripts)

В данной ветке мы увидим параметры для настройки сценария при входе или выходе из системы (включении или выключении компьютера). Дважды кликаем по нужному параметру и переходим на вкладку Сценарии Powershell (Powershell Scripts).

Нажимаем по Добавить и выбираем заранее написанный скрипт.

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

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

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

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

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

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

Один скрипт у меня находится: \domen.localSysVoldomen.localPolicies{E4A966DE-1FFE-40C8-B3B2-50888E146A4D}MachineScriptsStartupMain.ps1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Get-ExecutionPolicy 

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

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

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

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

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

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

powershell.exe -executionpolicy bypass -File C:scriptsbackup.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 PolicyWindows 8.1-Windows Server 2012 R2PolicyDefinitions Зайдите в эту папку и удалите лишние языковые директории. Я оставил лишь en-US и ru-RU т.к. имею в распоряжении русскую и английскую версию оснастки.

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

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

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

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

Теперь наши скрипты будут также успешно работать и в 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 для политики Компьютера

Логон (логоф) скрипты групповых политик позволяют запустить bat или PowerShell скрипт при загрузке компьютера или входе (выходе) пользователя. В некоторых случаях администратору нужно, чтобы определенный скрипт (команда) запускались для каждого пользователя или компьютера только один раз, и не отрабатывал при следующих входах.

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

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

1. Создайте следующий bat файл (corp_user_init.bat) и поместите его в каталог %SystemRoot%SYSVOLsysvol<domain name>scripts на котроллере домена:
   @echo off
IF EXIST C:Users%UserName%AppDataapp_init.txt GOTO END
:APPFLAG
date /t >> C:Users%UserName%AppDataapp_init.txt
time /t >> C:Users%UserName%AppDataapp_init.txt
REM Здесь добавьте код вашего скрипта, который нужно выполнить один раз
:END

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

2. Откройте консоль редактора доменных GPO (
   gpmc.msc
   );
3. Создайте новую политику и назначьте ее на OU с пользователями (или компьютерами, но для этого нужно включить режим замыкания групповой политики — Loopback Processing mode);
4. Перейдите в раздел User Configuration -> Windows Settings -> Scripts (Logon / Logoff);
5. Выберите Logon;
6. Нажмите кнопку Add и укажите путь к вашему bat файлу в SYSVOL (
   \winitpro.ruSysVolwinitpro.ruscripts
   );
   
7. После обновления групповых политик на клиенте при входе пользователя будет выполнен ваш скрипт. Убедитесь, что он успешно создал файл app_init.txt в профиле пользователя;
8. При следующем входе пользователя на компьютер, основной код скрипта не будет выполняьбся. Т.е. по сути скрипт применится к пользователю только один раз.

Другой вариант разового запуска скрипта через GPO предполагает использование разового задания планировщика Task Scheduler.

1. Поместите ваш файл скрипта (это может быть bat или PowerShell) в каталог Sysvol на контроллере домена (\<ваш_домен>SysVol<ваш_домен>scripts);
2. Создайте новую GPO, назначьте ее на OU с пользователями и откройте ее настройки;
3. Перейдите в раздел Preferences -> Control Panel Settings -> Scheduled Task -> New -> Immediate Task (At least Windows 7);
4. Укажите имя задания;
   
5. Перейдите на вкладку Actions, нажмите New и укажите полный UNC путь к вашему скрипту в SYSVOL;
   
6. Затем перейдите на вкладку Common и включите опцию Apply once and do not reapply;
   
7. Такое задание также отработает на компьютере только один раз при первом входе пользователя.

Если вы хотите запускать PowerShell скрипты через GPO, нужно настроить политику выполнения скриптов PS1, или использовать параметр -ExecutionPolicy Bypass при запуске скрипт (пример есть здесь).

Описание

Групповые политики позволяют запускать сценарии запуска и завершения работы компьютера, входа и выхода из системы пользователя. Возможно связать один или несколько файлов сценариев (scripts) с четырьмя инициируемыми событиями:

• Для машины:
  • Запуск компьютера (Startup)
  • Выключение компьютера/Завершение работы (Shutdown)
• Для пользователя:
  • Вход пользователя (Logon)
  • Выход пользователя (Logoff)

В случае, если указано более одного сценария, они будут выполняться согласно перечню в списке.
Система выполняет сценарии на языках, которые поддерживает клиентский компьютер. В среде Windows эту задачу выполняет Windows Script Host (WSH), который поддерживает языки сценариев, включая bat, cmd, VBScript и Jscript.

Примечание: Если сценарии (scripts) хранятся в SYSVOL, они реплицируются между контроллерами домена. SYSVOL доступен всем членам домена, что гарантирует запуск сценария.

Настройка политики

На машине Windows

Сценарии для входа/выхода пользователя

Для того чтобы назначить сценарий для входа или выхода пользователя (User Logon/Logoff script), необходимо выполнить следующие действия:

Шаг 1. Для удобства можно скопировать нужные сценарии в папку UserScriptsLogon (например, \test.altsysvoltest.altPolicies{20DDB816-421B-4861-8AC5-007E56CB67D0}UserScriptsLogon) или UserScriptsLogoff соответствующей политики.

Шаг 2. На машине с установленным RSAT открыть консоль «Управление групповыми политиками» (gpmc.msc).

Шаг 3. Создать новый объект групповой политики (GPO) и связать его с OU, в который входят учетные записи пользователей.

Шаг 4. В контекстном меню GPO выбрать пункт «Изменить»:

Шаг 5. Откроется редактор GPO. Перейти в «Конфигурация пользователя» -> «Политики» -> «Конфигурация Windows» -> «Сценарий (вход/выход из системы)». Дважды щелкнуть левой кнопкой мыши на политике «Вход в систему» («Logon») или «Выход из системы» («Logoff»):

Шаг 6. В диалоговом окне свойств политики нажать кнопку «Добавить»:

Шаг 7. В диалоговом окне «Добавление сценария» в поле «Имя сценария» ввести путь к сценарию (можно нажать кнопку «Обзор», чтобы найти файл сценария в общей папке на контроллере домена), а в поле «Параметры сценария» ввести необходимые параметры аналогично вводу этих параметров в командной строке.

Пример добавления сценария для ОС ALT:

Примечание: Применение локальных скриптов реализовано в механизме gpupdate версии 0.9.11, в версиях ниже скрипты для ОС ALT должны находиться в GPT настраиваемого объекта групповой политики.

Пример добавления сценария для ОС Windows (можно указать локальный скрипт на компьютере клиента):

При назначении нескольких сценариев они будут применяться в заданном порядке. Чтобы переместить сценарий в списке вверх/вниз, следует выбрать его в списке и нажать кнопку «Вверх»/«Вниз». Для того чтобы изменить сценарий, необходимо нажать кнопку «Изменить». Кнопка «Удалить» предназначена для удаления сценария из списка.

На вкладке «Сценарии PowerShell» можно добавить сценарии с расширением *.ps1.

Сценарии для автозагрузки или завершения работы компьютера

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

Шаг 1. Для удобства можно скопировать нужные сценарии в папку MachineScriptsStartup (например, \test.altsysvoltest.altPolicies{20DDB816-421B-4861-8AC5-007E56CB67D0}MachineScriptsStartup) или MachineScriptsShutdown соответствующей политики.

Шаг 2. На машине с установленным RSAT открыть консоль «Управление групповыми политиками» (gpmc.msc).

Шаг 3. Создать новый объект групповой политики (GPO) и связать его с OU, в который входят машины.

Шаг 4. В контекстном меню GPO выбрать пункт «Изменить»:

Шаг 5. Откроется редактор GPO. Перейти в «Конфигурация компьютера» -> «Политики» -> «Конфигурация Windows» -> «Сценарий (запуск/завершение)». Дважды щелкнуть левой кнопкой мыши на политике «Автозагрузка» («Startup») или «Завершение работы» («Shutdown»):

Шаг 6. В диалоговом окне свойств политики нажать кнопку «Добавить»:

Шаг 7. В диалоговом окне «Добавление сценария» в поле «Имя сценария» ввести путь к сценарию (можно нажать кнопку «Обзор» для поиска файла сценария в общей папке контроллера домена), а в поле «Параметры сценария» ввести необходимые параметры аналогично вводу этих параметров в командной строке.

Пример добавления сценария для ОС ALT:

Примечание: Применение локальных скриптов реализовано в механизме gpupdate версии 0.9.11, в версиях ниже скрипты для ОС ALT должны находиться в GPT настраиваемого объекта групповой политики.

Пример добавления сценария для ОС Windows (можно указать локальных скрипт на компьютере клиента):

При назначении нескольких сценариев они будут применяться в заданном порядке. Чтобы переместить сценарий в списке вверх/вниз, следует выбрать его в списке и нажать кнопку «Вверх»/«Вниз». Для того чтобы изменить сценарий, необходимо нажать кнопку «Изменить». Кнопка «Удалить» предназначена для удаления сценария из списка.

На вкладке «Сценарии PowerShell» можно добавить сценарии с расширением *.ps1.

Включение «Экспериментальных групповых политик»

Так как политики управления logon-скриптами относятся к экспериментальным, на машинах Альт где они применяются, должны быть включены «Экспериментальные групповые политики».

Включить «Экспериментальные групповые политики» можно, выбрав в разделе «Конфигурация компьютера» -> «Политики» -> «Административные шаблоны» -> «Система ALT» -> «Групповые политики» пункт «Экспериментальные групповые политики»:

Дважды щелкнуть на политике «Экспериментальные групповые политики», в открывшемся окне установить отметку в поле «Включить»:

Файлы настроек политики

Настройки политики для сценариев входа и выхода пользователя хранятся в каталоге {GUID GPT}UserScriptsscripts.ini. Файлы сценариев (за исключением локальных) хранятся в каталогах: {GUID GPT}UserScriptsLogon и {GUID GPT}UserScriptsLogoff. В файле scripts.ini перечисляются все программы, выполняемые в сценариях входа и выхода пользователя из системы. Сценарии входа начинаются с преамбулы [Logon], сценарии выхода начинаются с преамбулы [Logoff].

Пример файла scripts.ini:

[Logon]
0CmdLine=date.sh
0Parameters=test
1CmdLine=test.sh
1Parameters=new
[Logoff]
0CmdLine=touch.sh
0Parameters=
1CmdLine=Logoff.bat
1Parameters=1.txt
2CmdLine=C:shareLogon.bat
2Parameters=

Настройки политики для сценариев запуска и завершения работы компьютера хранятся в каталоге {GUID GPT}MachineScriptsscripts.ini. Файлы сценариев (за исключением локальных) хранятся в каталогах: {GUID GPT}MachineScriptsShutdown и {GUID GPT}MachineScriptsStartup. В файле scripts.ini перечисляются все скрипты, выполняемые в сценариях запуска и завершения работы компьютера. Сценарии запуска компьютера начинаются с преамбулы [Startup], сценарии завершения работы начинаются с преамбулы [Shutdown].

Пример файла scripts.ini:

[Startup]
0CmdLine=hello.bat
0Parameters=
1CmdLine=notescript.vbs
1Parameters=
2CmdLine=notescript2.vbs
2Parameters=
3CmdLine=touch.bat
3Parameters=
[Shutdown]
0CmdLine=touch.bat
0Parameters=

Файл scripts.ini закодирован в формате UTF-16LE (little-endian).

Права и разрешения

• По умолчанию разрешение на изменение параметров для редактирования GPO имеют члены групп безопасности «Администраторы домена», «Администраторы предприятия», «Владельцы-создатели групповой политики»;
• Сценарии запуска (Startup) и завершения работы выполняются под учетной записью локальной системы, и они имеют полные права, связанные с возможностью запуска под учетной записью локальной системы;
• Сценарии входа (Logon scripts) и выхода (Logoff scripts) запускаются от имени пользователя, а не администратора, и их права соответственно ограничены;
• В Windows Vista сценарии запуска по умолчанию выполняются асинхронно. Это поведение отличается от более ранних операционных систем;
• Настройка синхронного запуска сценариев запуска может привести к замедлению процесса загрузки;
• В Windows Vista сценарии запуска, выполняемые асинхронно, не будут видны. Включение параметра групповой политики Run Startup Scripts Visible не повлияет на асинхронный запуск сценариев запуска.

Диагностика проблем при работе с политикой скриптов

На контроллере домена

• Проверить работоспособность загружаемого скрипта в дистрибутиве ALT;
• Убедиться, что кодировка файла со скриптом — UTF8;
• Убедиться, что скрипт расположен в каталоге (GPT) применяемого объекта групповой политики (GPO);
• Включить групповую политику «Экспериментальные групповые политики» или групповую политику «Управление logon-скриптами»;
• Убедиться, что целевой компьютер входит в подразделение (OU), к которому привязан объект групповой политики GPO.

На компьютере пользователя

• Проверить версию gpupdate. Политики скриптов выполняются с релиза 0.9.11-alt1.
• Убедиться, что механизм применения политик (gpupdate) запущен:

• Убедиться, что служба скриптов запущена:

  # systemctl status gpupdate-scripts-run.service
  

• Проверить содержимое каталога и права для загруженных скриптов:

  # ls -Rl /var/cache/gpupdate_scripts_cache/
  

• Проверить состояние службы запуска скриптов пользователя через вывод команды (от пользователя):

  $ systemctl --user status gpupdate-scripts-run-user.service
  

• Вывести журнал применения политик:

Упрощаем задачу администратора при помощи автозапуска сценариев

Это ограничивает типы задач, которые может выполнять подобный сценарий. Сценарии, запускающиеся с центрального административного сервера или рабочей станции, могут запускаться в контексте служебной учетной записи, имеющей более широкие права. Такие сценарии могут запускаться во всем домене, либо по заданному списку компьютеров. Кроме того, сценарии для запуска с сервера используют только утилиты, допускающие удаленную работу. Так, некоторые встроенные команды, например net.exe недоступны для программ, запускающихся с сервера. При этом, если сценарий запускается для внесения изменений в политику для списка с именами компьютеров, системы, которые в данный момент выключены, часто не получают соответствующих изменений. Необходимо постоянно вести журнал ошибок для повторного запуска сценария на подобных компьютерах.

На компьютерах с Windows 2000 можно добавить систему в группу компьютеров или в организационное подразделение (OU) и использовать групповые политики Active Directory (AD) для запуска сценариев для группы или OU. Если добавить новые узлы в группу или OU, они автоматически становятся объектами воздействия GPO. Основанные на сценариях GPO запускаются каждый раз, когда система обращается к ним. Так, каждый раз, когда пользователь включает компьютер, запускаются примененные к этому компьютеру сценарии. Такая функциональность особенно полезна в тех средах, где используются переносные компьютеры, периодически подключающиеся к сети. Компьютеры не будут терять изменений, вносимых сценариями, поскольку каждый раз во время запуска на них будут запускаться сценарии, созданные для OU или для группы компьютеров, членом которой является система.

Я собрал несколько вопросов, наиболее часто задаваемых пользователями, чтобы показать, как можно использовать GPO для автоматического запуска сценариев на компьютерах. Предполагается, что читатели хорошо знакомы с тем, как использовать Microsoft Management Console (MMC) и оснастку Active Directory Users and Computers для создания GPO и добавления в созданный GPO сценариев для автоматического запуска. Пошаговые объяснения того, как добавить сценарий в GPO, даются во врезке «Добавление в GPO сценариев для автоматического запуска». Приведенные советы по автоматически запускаемым сценариям наиболее актуальны для сетевых сред, в которых пользователи ежедневно выключают и перезагружают компьютеры.

О. Вы можете использовать запускаемые автоматически сценарии для изменения пароля административной учетной записи на системах, которые являются членами компьютерной группы, где нужно поменять пароль. Следующая команда командной строки изменяет пароль учетной записи Administrator после перезагрузки компьютера.

Net user Administrator %1

Во врезке «Добавление в GPO сценариев для автоматического запуска» дается подробное описание добавления этого сценария в GPO. Для начала потребуется создать компьютерную группу, содержащую все компьютеры, являющиеся членами OU, на которые вы должны установить новый пароль. После этого сценарий добавляется в соответствующий GPO. Также потребуется установить разрешение таким образом, чтобы только нужные компьютерные группы имели разрешения Read и Apply Group Policy для созданного GPO. В следующий раз, когда компьютер из означенной группы будет запущен, выполнится сценарий и изменит пароль записи Administrator на данном компьютере. Когда вам понадобится установить другой новый пароль, измените аргумент password, который подставляется в сценарий. Если вы правильно назначите все права и удалите у группы Authenticated Users разрешения Read и Apply Group Policy, как описано во врезке «Добавление в GPO сценариев для автоматического запуска», администраторами GPO останутся только те пользователи, которые имеют доступ к паролям. Запишите и обеспечьте безопасность хранения старых паролей для нескольких циклов изменений для случая, если вам понадобится доступ к тем компьютерам, которые были вне сети на момент изменения пароля.

О. Да, вам понадобится использовать автоматически запускаемый сценарий, связанный с базой данных или файлом, который представляет данные для паролей. Ниже показан пример такого файла с разделителями запятыми (CSV), содержащий имена систем и пароли. На каждой строке должны быть имена систем и пароль.

Pc111777,bambam1
Pc111778,barney12

Установите разрешения так, чтобы выделенная группа компьютеров могла читать эти файлы, а группа Authenticated Users — нет.

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

Set PW=defaultPW
for /f "tokens=1,2 delims=," %%i
in ('find /I "%computername%"
^< Pwlist.txt') do (Set PW=%%j)
Net User Administrator %PW%

О. Вы можете задействовать раздел реестра RunOnce для выполнения этой задачи только один раз. Однако этот способ не позволяет вам отследить изменения, вносимые по вашему требованию. Вместо этого создайте группу компьютеров и сделайте членами этой группы все компьютеры, на которых необходимо произвести изменения реестра. Дайте этой группе компьютеров разрешения Read, Write, Apply Group Policy и Add/Remove self as a member и уберите флажок Allow для группы Authenticated Users для разрешений Read и Apply Group Policy.

Создайте сценарий, выполняющий изменения реестра, и в конце добавьте следующие строки, удаляющие компьютер из группы компьютеров

cusrmgr -dlg Group_Name
-m DC_Name
-u Domain_Name%COMPUTERNAME%$

Cusrmgr- утилита из состава Microsoft Windows 2000 Server Resource Kit. Разместите копию этой утилиты там, где расположены автоматически запускаемые сценарии. Когда компьютер перезагрузится, он запустит сценарий, вносящий изменения в реестр и удаляющий его из группы компьютеров. Чтобы увидеть, на каких компьютерах изменения реестра не выполнились, просто откройте группу. На компьютерах, оставшихся в этой группе, сценарий не отрабатывался и изменения не внесены. Вы можете также добавить программный код, добавляющий компьютер во вторую компьютерную группу, после удаления его из первой группы, после чего одна группа содержит все компьютеры, на которых изменения в реестре произведены. Другая группа содержит компьютеры, на которых изменения не производились.

О. Вы можете добавить пять учетных записей разработчиков в группу Administrators на этих компьютерах, однако членство в этой группе будет теряться каждый раз, когда переустанавливается операционная система компьютеров. Более удачным следует признать следующий метод: разместить компьютеры в OU и использовать автоматически запускаемый сценарий, который добавляет в группу Administrators при каждой перезагрузке индивидуальные пользовательские записи или их группу, которая содержит разработчиков. Используйте следующий код для добавления индивидуальных пользователей в группу Administrators:

Net Localgroup Administrators
"Domain_NameDeveloper1" /Add
Net Localgroup Administrators
"Domain_NameDeveloper2" /Add
Net Localgroup Administrators
"Domain_NameDeveloper3" /Add
Net Localgroup Administrators
"Domain_NameDeveloper4" /Add
Net Localgroup Administrators
"Domain_NameDeveloper5" /Add

Используйте также

Net Localgroup Administrators
"Domain_NameDevelopers_Group"
/Add

для добавления группы разработчиков в группу Administrators. Вы можете также задействовать GPO Restricted Groups для выполнения такой задачи.

О. Пользователям компьютеров в конференц-залах часто предоставляются права в группе локальных администраторов для того, чтобы они могли устанавливать и запускать демонстрируемые программные продукты. Эти пользователи, в свою очередь, могут предоставлять аналогичные права другим пользователям. В результате мы имеем компьютер, на котором множество пользователей имеют административные права. Такие компьютеры также бывают безнадежно перегружены демонстрируемыми программами. Вы можете использовать следующий автоматически запускаемый сценарий компьютеров для очистки группы Administrators и сохранения лишь нескольких авторизованных пользователей.

for /f "tokens=*" %%i in ('Net
Localgroup Administrators
^| find /I /V "Alias"
^| find /I /V "Members"
^| find /I /V "------"
^| find /I /V "successfully"
^| find /V "Administrator"')
Do Net Localgroup
Administrators "%%i" /Delete
Net Localgroup Administrators
"SpecialAdmins" /Add

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

О. Запускаемые автоматически сценарии компьютера могут не выполняться, если компьютер не будет иметь доступа к соответствующим переменным окружения пользователя. Поскольку автоматически запускаемый сценарий запускается перед регистрацией, пользовательские переменные, такие как username, temp и logonserver недоступны. Убедитесь, что переменные, которые вы используете, являются локальными для сценария или представляют собой системные переменные. Также если у вас имеется несколько групповых политик GPO или сценариев, запускающихся для OU, убедитесь, что сценарии не конфликтуют друг с другом. Например, сценарий, который удаляет всех пользователей и группы из группы Power Users, не должен отменить действие сценария, добавляющего группу HelpDeskGroup в ту же самую группу Power Users.

Вы можете установить порядок отработки сценариев GPO. Можно также запускать сценарий в том порядке, который вы зададите. Следующие строки программного кода вы можете добавить в командный файл, применяющий GPO. Он вызывает и запускает четыре других сценария в заданном порядке.

Start /Wait script1.bat
Start /Wait script2.bat
Start /Wait script3.bat
Start /Wait script4.bat

При необходимости сохраните эти сценарии в том же месте, где расположены сценарии на сервере.

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

Для запуска сценариев в режиме трассировки — так, чтобы вы могли отлаживать их, закомментируйте команду @ECHO OFF в начале сценария и установите соответствующие свойства GPO для его запуска. В конце сценария поместите команду pause так, чтобы вы могли видеть результаты в открытом окне, или воспользуйтесь командой sleep для задержки работы сценария на дополнительные 5 — 10 секунд, чтобы можно было просмотреть сообщения об ошибках. После окончания отладки сценария убедитесь, что убраны все команды pause и sleep.

О. Возможно, это связано с задержкой репликации. Во время тестирования сценария запустите его в видимом режиме, дабы убедиться, что он действительно запускается. Нет более бесполезного занятия, чем пытаться объяснить, почему ваш сценарий не работает, когда он не запускается просто из-за того, что не прошла репликация.

О. Чтобы узнать, какие новые GPO и сценарии работают корректно, следует добавить тестовые компьютеры во вновь созданную подчиненную OU, созданную внутри промышленного OU. Не блокируйте наследование политик этой подчиненной OU, иначе не получите точной картины того, как взаимодействуют новые сценарии и политики с уже существующими политиками и сценариями. После того, как политики и сценарии корректно заработают на тестовом компьютере, добавьте в эту тестовую группу другие компьютеры. Делайте это до тех пор, пока не убедитесь, что все работает правильно. Аккуратно документируйте действия, которые выполняет каждый из GPO и связанные с ним сценарии.

После окончания тестирования переместите тестовые компьютеры в другую OU, а тестовую OU оставьте на месте, сохранив примененные политики и сценарии. Такая последовательность действий дает возможность сохранения последней удачной конфигурации «last known good» для GPO и сценариев для выполнения определенной задачи. Если вам понадобится выполнить подобную задачу в будущем, у вас уже будет готовая тестовая среда для проверки новой конфигурации.

Продолжайте работу

Я надеюсь, что подал читателям несколько полезных идей. Запускаемые автоматически сценарии компьютеров действительно представляют собой мощный инструмент для управления компьютерами, которые являются членами локальных групп. Они предоставляют администраторам развитые возможности в области управления системами с Windows XP и Windows 2000.

Добавление в GPO сценариев для автоматического запуска

Для того чтобы добавить сценарий в новый или уже существующий объект групповой политики Group Policy Object (GPO), откройте консоль Microsoft Management Console (MMC) и оснастку Active Directory Users and Computers, как показано на рисунке А. Правой кнопкой мыши щелкните на соответствующей организационной единице (OU), в которой хотите создать новую политику, или получить доступ к уже существующей. Из контекстного меню этой OU выберите Properties, затем выберите закладку Group Policy, как показано на Рисунке B. Нажмите New для добавления новой политики. Дайте новой политике имя и нажмите Edit.

Рисунок А

Рисунок В

Под новой политикой перейдите к Computer Configuration, Windows Settings, Scripts (Startup/Shutdown), как показано на рисунке С. Дважды нажмите Startup на правой панели, чтобы открыть страницу Startup Properties, показанную на Рисунке D, и нажмите Show Files.

Рисунок С

Рисунок D

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

Рисунок Е

NET USER Administrator %1

Закройте окно Startup. Вернитесь в окно Startup Properties и нажмите Add, чтобы открыть окно Add a Script, показанное на рисунке F.

Рисунок F

В этом окне введите имя сценария, который требуется запустить, и нажмите Browse для указания местоположения файла сценария, который вы предварительно скопировали в папку Startup. В поле Script Parameters наберите пароль, под которым будет выполняться сценарий. Сценарий будет подставлять этот пароль на компьютеры в соответствующую OU при следующей перезагрузке. Нажмите OK, чтобы выйти из всех окон. Заключительным шагом добавления автоматически запускаемого сценария в GPO необходимо сделать установку параметров безопасности GPO. В этом примере мне понадобилось установить параметры безопасности так, чтобы передаваемый пароль не был виден. Вернемся к странице свойств GPO, показанной на Рисунке B.

Правой кнопкой мыши нажмите на Group Policy, выберите Properties, затем выберите закладку Security, показанную на Рисунке G. По умолчанию группа Authenticated Users, содержащая пользователей и компьютеры домена, имеет разрешения Read и Apply Group Policy. Такая установка хорошо работает для большинства политик, однако в данном случае присвоение разрешений Read и Apply Group Policy группе Authenticated Users в данном примере приведет к тому, что пароль станет доступен любому пользователю домена, а не только группе, к которой применяется данная политика и пароль. Поэтому очистите пункт Allow для разрешений Read и Apply Group Policy для группы Authenticated Users. Затем предоставьте это разрешение группе компьютеров, содержащей учетные записи систем, на которых предполагается применить заданную GPO, как показано на рисунке Н. Нажмите Apply, а затем OK, чтобы закрыть окно Security.

Рисунок G

Рисунок H

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