☰

Запустить скрипт при присоединении к домену

tag-icon • tag-icon windows group-policy startup-scripts
Запустить скрипт при присоединении к домену

У меня есть домен Microsoft (в основном 2008r2\7).
Я ищу способ запустить скрипт сразу после (перезагрузки после) присоединения к домену (не требуя входа пользователя), и пока что у меня ничего не получилось.

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

Я пробовал GPO со сценарием запуска, но когда компьютер получает GPO, это происходит намного позже запуска.
Я также пробовал GPO с запланированной задачей (с разными триггерами), но они тоже не сработали:
триггер "At startup" не срабатывает так же, как и сценарий запуска.
"At task creation" не срабатывает, я полагаю, потому что он не создается обычным способом.
"At schedule" не имеет значения, потому что мне нужно, чтобы он запускался сразу после присоединения (и установка даты, которая уже прошла, не сработала).
Не удалось найти соответствующие ключи реестра, но я предполагаю, что у них будет та же проблема, что и у сценария запуска GPO.

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

Есть предложения получше?

--Изменить--
К ответам (которые великолепны, но не совсем соответствуют сути) я хочу добавить несколько моментов:
1. Вопрос касается обоих серверов (2008r2\2012\2012r2), хотя я тестировал только на 2012r2.
2. Я ищу решение, более похожее на runonce, то есть я не хочу, чтобы оно работало бесконечно, пока не будет выполнено какое-то условие.
3. Мы используем образы для развертывания серверов и рабочих станций, но я не могу использовать решение, которое подразумевает их редактирование, потому что a) это потребовало бы от меня обновления каждый раз, когда мне нужно что-то изменить в моем скрипте b) BYOD.
4. Мы не используем скрипт присоединения (он нам просто не нужен...), поэтому начинать использовать его, как мне кажется, пустая трата времени. Кроме того, с ним есть несколько проблем (например, где его разместить? в образе? в общем месте? что с BYOD? это нарушит пункт 3).

Спасибо.

решение1

Добавьте пользовательский ключ реестра в ваш образ сборки, просто простое значение '1' где-нибудь.
Добавьте запланированную задачу, которая проверяет значение ключа реестра в образ сборки, добавьте проверки вашего доменного имени в этот ключ реестра

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

Если он обнаружит, что оба запускают ваш скрипт, то измените пользовательский ключ реестра на 0 по завершении. Запустите эту задачу при запуске.

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

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

решение2

Разве вам не нужно перезагружать компьютер после присоединения к домену? Если вы создали сценарий запуска, он будет применяться сразу после этой перезагрузки, когда он загрузит другие объекты групповой политики.

Как вы сейчас присоединяетесь к домену? Вы также можете интегрировать присоединение к домену в свой скрипт. В Powershell это делается с помощью Add-Computer, из командной строки можно использовать netdom.

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

решение3

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

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce https://msdn.microsoft.com/en-us/library/windows/desktop/aa376977%28v=vs.85%29.aspx

---НАЧАТЬ РЕДАКТИРОВАНИЕ---
Вот это да! Точно

Думая о вашем комментарии о задержке применения GPO... Я работаю в основном на серверной ОС, которая выполняет синхронную обработку GPO. Рабочие станции выполняют асинхронную обработку. Попробуйте это, чтобы получить асинхронность:

В процессе сборки/образе попробуйте отключить «Оптимизацию быстрого входа» https://technet.microsoft.com/en-us/magazine/gg486839.aspx
Конфигурация компьютера\Административные шаблоны\Система\Вход в систему
Всегда ждать сети при запуске компьютера и входе в систему = Включено

Создание сценария запуска GPO GPO:
Конфигурация компьютера/Политики/Параметры Windows/Сценарии/Автозагрузка

Внутри определенного вами скрипта используйте этот код:

$built = gwmi Win32_OperatingSystem | foreach {[System.Management.ManagementDateTimeconverter]::ToDateTime($_.InstallDate)}
if ($built -gt (get-date).addHours(-4)) {
    "do something"
}

решение4

Раньше я работала в школах.

И мы автоматизируем процесс присоединения и написания сценариев (наличие идеального образа для развертывания, который прослужит годы, может быть утопией). Поэтому мы использовали WDS/MDT для депо.

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

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

Связанный контент