Как ускорить процесс обновления политики групп. Как обновить групповую политику на компьютере Windows? Обновление доменных политик

После изменений GPO необходимо некоторое время (90 минут +/- 30) пока они распространятся на другие системы, но если их нужно применить срочно, админ регистрировался на удаленной системе и выполнял команду “gpupdate ”. При большом количестве ПК процесс занимал некоторое время, да и сам процесс неудобен. Теперь про это можно забыть. В консоли управления групповой политикой (GPMC) в контекстном меню домена и подразделения появился новый пункт “Обновление групповой политики ” (Group Policy Update) позволяющий произвести обновление политик систем начиная с Windows Vista/2008 двумя щелчками мышки. После активации задания будет получен список компьютеров и зарегистрированных пользователей, после чего создается задание “Gpupdate.exe /force ”. Во избежание перегрузки сети, оно будет выполняться со случайной задержкой в интервале 0-10 минут. Результат выполнения задания отображаются в отдельном окне, успешность обновления можно определить с помощью мастера результирующей политики.
Новая функция получила и свой командлет — Invoke-GPUpdate , позволяющий удаленно обновить GP и дающие даже большие возможностей, чем GPMC. Кстати теперь за групповые политики отвечает 27 командлетов т.е. на один больше (получить полный список можно введя «Get-Command -Module GroupPolicy «).
Чтобы немедленно обновить политики на конкретной систем достаточно выполнить:

PS> Invoke- GPUpdate - Computer < имя компьютера>

PS> Invoke-GPUpdate -Computer < имя компьютера>

Дополнительный ключ –RandomDelayInMinutes позволяет задать интервал ожидания, что полезно, если команда будет выполнена на нескольких системах.
Но главное, в консоли GPMC можно выбрать только подразделение, отдельного контейнера компьютеры там нет. Вот здесь и выручает Invoke-GPUpdate, который совместно с командлетом Get-ADComputer, позволяет отобрать системы по любому критерию:

PS> Get- ADComputer –filter * - Searchbase "cn=computers, dc=example,dc=org" | foreach { Invoke- GPUpdate –computer $_ .name –force –- RandomDelayInMinutes 5 }

PS> Get-ADComputer –filter * -Searchbase "cn=computers, dc=example,dc=org" | foreach{ Invoke-GPUpdate –computer $_.name –force –-RandomDelayInMinutes 5}

Еще важный момент, на клиентских системах необходимо открыть несколько портов брандмауэра. Чтобы упростить жизнь админу в MS предложили 2 новые начальные политики (к 8 имеющимся), позволяющие быстро создать и распространить нужные настройки:

— Порты брандмауэра для удаленного обновления групповой политики;
— Порты брандмауэра для отчетов групповой политики.

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

Команда GPUPDATE используется для обновления групповых политик для пользователя и/или компьютера.

Формат командной строки:

GPUpdate

Параметры командной строки:

/Target:{Computer | User} - Обновление параметров политики только пользователя (User) или только компьютера (Computer). Если не указано, обновляются параметры обеих политик.

/Force - Применение всех параметров политики. Если не указано, применяются только изменившиеся параметры политики.

/Wait:значение - Время ожидания (в секундах) завершения обработки политики. По умолчанию - ожидание 600 секунд. Значение "0" - без ожидания. Значение "-1" - ожидание не ограничено. В случае превышения времени ожидания вновь активизируется окно командной строки, но обработка политики продолжается.

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

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

/Sync - Следующее активное применение политики должно выполняться синхронно. Активные применения политики происходят при перезагрузке компьютера или при входе пользователя в систему. Можно использовать этот параметр для пользователя, компьютера или для обоих, задав параметр /Target. При этом параметры /Force и /Wait, если они указаны, пропускаются.

Примеры использования:

gpupdate /? - отобразить подсказку по использования команды.

gpupdate - выполняется обновление политик компьютера и политик пользователя. Применяются только изменившиеся политики.

gpupdate /Target:computer - выполняется обновление политик только для компьютера.

gpupdate /Force - выполняется обновление всех политик.

gpupdate /Boot - обновление групповых политик с перезагрузкой компьютера.

Резюме : Microsoft Scripting Guy, Ed Wilson показывает, как вызвать обновление групповой политики посредством PowerShell.

Обновление групповой политики в домене

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

Для обновления настроек групповой политики я использую утилиту GPUpdate . Она обладает некоторыми параметрами. По умолчанию, утилита обновляет политику как компьютера, так и пользователя. Но этим можно управлять, используя параметр /target . Например, если мне нудно обновить только политику компьютера, я укажу /target:computer . Для обновления только политики пользователя — /target:user .

PS C:\> gpupdate /target:computer

Updating policy…

По умолчанию GPUpdate применяет только обновленные настройки групповой политики. Для применения всех настроек используется параметр /force . Приведенная ниже команда обновляет все настройки групповой политики (вне зависимости от того, были ли они изменены) для компьютера и пользователя.

PS C:\> gpupdate /force

Updating policy…

Computer Policy update has completed successfully.

User Policy update has completed successfully.

Во-первых, получаем список компьютеров в домене

Первое, что мне необходимо сделать – это получить список всех компьютеров в домене. Для этого я использую командлет Get-ADComputer , входящий в модуль Active Directory.

Заметка: модуль Active Directory входит в состав RSAT.

Я сохраняю полученные объекты компьютеров в переменной $cn.

$cn = Get-ADComputer -filt *

Во-вторых, создаем удаленные сессии

Следующее, что мне нужно сделать – это создать удаленные сессии со всеми компьютерами. Для этого мне нужно предоставить учетные данные для подключения к компьютерам, а также создать сами сессии посредством командлета New-PSSession .

Для начала я воспользуюсь командлетом Get-Credentials и сохраню возвращенный им объект в переменной $cred.

$cred = Get-Credential iammred\administrator

$session = New-PSSession -cn $cn.name -cred $cred

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

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

Теперь запустим команду на всех удаленных машинах

Для запуска команды GPUpdate на всех удаленных машинах я использую командлет Invoke-Command . Он использует сессии, сохраненные нами в переменной $sessions. Алиас для командлета Invoke-Command icm .

icm -Session $session -ScriptBlock {gpupdate /force}

После запуска команды, результаты отображаются в консоли Windows PowerShell.

Проверка обновления групповой политики

Когда на рабочей станции происходит успешное обновление настроек групповой политики, в журнал System записывается событие с кодом 1502. Я могу воспользоваться командлетом Invoke-Command для получения этой информации.

icm -Session $session -ScriptBlock {Get-EventLog -LogName system -InstanceId 1502 -Newest 1}

Команда и ее результаты приведены на рисунке ниже.

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

Иногда мне приходится звонить в техподдержку и они просят обновить групповую политику на моем локальном компьютере. Это не проблема, так как я могу запустить GPUpdate прямо из PowerShell. Сложность возникает тогда, когда они просят меня выполнить обновление групповой политики 5 раз с интервалом в 5 минут. Но и это решается с помощью одной строки кода.

1..5 | % {«refreshing GP $(Get-Date)»; gpupdate /force ; sleep 300}

Ed Wilson, Microsoft Scripting Guy

Оригинал:

· Комментариев нет

Обновление настроек политик групп Microsoft Windows Group Policy на локальной машине не очень сложно сделать с помощью такого инструмента, как Gpupdate, но обновление этих политик на удаленных компьютерах в домене, невозможно сделать ни с помощью консоли управления Microsoft Management Console (MMC), ни с помощью любых, доступных на сегодняшний день, продуктов компании Microsoft. В этой статье я расскажу вам о различных уловках, сценариях и бесплатных инструментах, которые позволяют обновить настройки политики групп на удаленных компьютерах в домене.

Введение

Большинство администраторов знают о проблеме применения политик групп на удаленных компьютерах. После настройки какой-либо важной политики, иногда нам хотелось бы, чтобы эта политика группы GP сразу же появилась на клиентских компьютерах. Но проблема заключается в том, что по умолчанию, так называемая фоновая обработка происходит лишь в интервале от 90 до 120 минут (случайным образом) – если мы хотим ускорить процесс обновления, то здесь мы предоставлены сами себе. Конечно, существует причина, по которой политики просто не обновляются каждые пять минут или даже в режиме реального времени. Загрузка контроллеров доменов и сети в большинстве сред будет слишком большой, чтобы с ней справиться. Но если возникнет необходимость быстрого применения очень важной настройки для безопасности для большого количества клиентов, то было бы неплохо подготовиться к такой ситуации.

Что нам в действительности нужно, это обеспечить возможность для администратора, обновлять политики на компьютерах Computer1, Computer2 и/или Computer3 – а также политики для пользователей A, B и C из централизованной точки – рабочей станции администратора, в том случае если администратор сочтет это необходимым. Посмотрите на рисунок 1.

Рисунок 1: Сценарий

У нас есть замечательный инструмент под названием Gpupdate, который встроен в операционную систему Microsoft Windows XP и более новые операционные системы – а также у нас есть инструмент под названием Secedit для операционной системы Windows 2000 – но к несчастью команда Gpresult для инструментов Gpupdate и Secedit может обрабатываться только на локальных компьютерах. Конечно у нас есть уже настроенная система установки, как сервер управления системами Microsoft Systems Management Server (SMS), мы можем использовать эту систему для передачи небольших сценариев, которые запустят необходимую команду для группы пользователей или компьютеров.

Если в вашей сети нет такой системы, то вы должны попробовать более творческие подходы – т.к. альтернатива заключается в том, чтобы зайти на все необходимые компьютеры с помощью инструмента типа Remote Assistance (Удаленный помощник), или разослать все пользователям электронное письмо с просьбой выполнить команду Gpupdate… Поэтому ищите более творческие подходы.

Проблемы

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

Проблемы с брандмауэром:

Как и в случае с другими соединениями, которые инициированы в сети, пакеты, которые пытаются обновить настройки политик на удаленных компьютерах, не смогут преодолеть локальный брандмауэр на удаленных компьютерах (как, например, брандмауэр, который встроен в операционную систему Windows, начиная с Windows XP с пакетом обновления Service Pack 2 и выше), если это брандмауэр не настроен таким образом, чтобы разрешать такой входящий трафик (из выбранной подсети subnet, IP или что-то в этом роде). Встроенный в операционную систему Windows брандмауэр должен быть настроен, чтобы разрешать входящий трафик, который мы формируем использованием объекта политики группы, поэтому, как не иронично это звучит, такая политика – это единственная, которую мы не можем использовать для удаленных компьютеров с включенным брандмауэром.

Настройки политики, которые должны быть установлены для всех методов, упоминаемых в этой статье, следующие:

Computer Settings | Administrative Templates | Network | Network Connections | Windows Firewall | Domain Profile | “Windows Firewall: Allow remote administration exception”.

Другие устройства, которые выполняют роль брандмауэра, между центральным компьютером и удаленными компьютерами должны также соблюдать вышеупомянутые настройки (смотрите тест помощи Help, для упомянутой политики в GPEDIT.MSC).

Права администратора:

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

После того, как вы обо всем этом позаботились, давайте рассмотрим сами методы.

Написание сценариев

Сценарии бесплатны и широко распространены среди специалистов по информационным технологиям в Интернет – это в действительности “Open Source”. Компания Microsoft предоставила нам несколько встроенных возможностей для расширения возможностей операционной системы и среды – в этой статье мы расскажем о том, как можно использовать эти возможности для удаленного обновления политик групп GP.

Gpupdate & Secedit

Сперва мы должны упомянуть инструменты Gpupdate и Secedit, без этих инструментов ничего, из перечисленного ниже, не было бы возможным. Сценарии и инструменты, которые упоминаются здесь, все подразумевают, что один из этих инструментов установлен на удаленном клиенте, в зависимости от версии операционной системы. Как упоминалось выше, инструмент Secedit входит в состав операционной системы Windows 2000, а инструмент Gpupdate был взят с операционной системы Windows XP и выше, он даже присутствует в операционной системе Longhorn, в том виде, в каком она находится сейчас. В следующих сценариях я сфокусируюсь на Gpupdate – мы можем проверить версию операционной системы перед запуском Gpupdate или Secedit, но эту проверку можно добавить позднее без особых затруднений.

Файл Gpupdate.exe по умолчанию располагается в папке “%windir%\system32”, поэтому нам не нужно знать абсолютный путь к эго местоположению на удаленной машине. Инструмент можно вызвать с набором различных ключей:

Syntax: Gpupdate

В наших сценариях “сделай сам” для приложений HTML Application (HTA) и Windows Management Instrumentations (WMI) мы сфокусируемся на запуске Gpupdate без ключей – или с ключами “/Taget:Computer” (для обновления политик, относящихся к компьютеру) или “/Target:User” (для обновления политик, относящихся к пользователю). Другие параметры можно включить, немного поработав – но нужны ли нам в действительности “/Logoff” или “/Boot”? Это означает, что пользователи могут выйти в случае необходимости (установка программного обеспечения, изменение папок и т.д.) или даже можно потребовать перезагрузки компьютера во время работы пользователя. В действительности ли это то, что нам надо? В любом случае, мы можем также использовать инструмент типа Shutdown.exe для этих целей – поэтому мое мнение это не будет слишком популярным.

PsExec

Первый метод, о котором я хочу рассказать, очень прост в использовании и практически не требует навыком программирования. Зачем придумывать что-то, что уже было изобретено, верно? Инструмент под названием PsExec был разработан Марком Руссиновичем, бывшим владельцем компании Sysinternals, которая была выкуплена компанией Microsoft в июле 2006. На сегодняшний день доступна версия 1.73, которую можно загрузить с сайта Microsoft Technet .

Инструмент PsExec великолепен, когда речь идет об удаленном выполнении, в основном благодаря тому, что он не требует установки агентов на удаленном компьютере. Вам всего лишь необходимо указать имя компьютера и команду, которую необходимо запустить вместе с ключами в командной строке – и все!

Небольшой трюк заключается в том, чтобы поместить файл PsExec.exe в директорию “%windir%”, т.к. в этом случае нам не нужно указывать полный путь к этому файлу при запуске его из командной строки.

Для того чтобы обновить политики группы на удаленной машине, все, что нам необходимо сделать, это задать ‘Computername’ (имя компьютера) в следующей команде: “PsExec \\Computername Gpupdate”. Пользователь, который работает на удаленной машине, даже не узнает, что случилось, но в фоновом режиме команда Gpupdate обновит политики для пользователя и для компьютера и применит все утерянные настройки. Вы можете подумать, что команду PsExec необходимо запустить с ключом “-i» для обновления для удаленных пользователей специальных политик для пользователей, но тестирование показывает, что это необязательно.

Сценарий FLEX COMMAND

Итак, метод, упомянутый выше, позволяет обновить политики для одного пользователя или компьютера, а как насчет обновления всей организационной единицы (Organizational Unit или OU) благодаря совместному использованию PsExec и Gpupdate? Для этих целей я создал демонстрационный сценарий, чтобы показать некоторые возможности, которые мы можем воспользоваться благодаря написанию сценариев. Сценарий называется FLEX COMMAND и его можно загрузить отсюда . Вы можете легко открыть файл с расширением HTA с помощью текстового редактора типа Notepad и увидеть код, никакой скрытой магии.

Когда стартует FLEX COMMAND, он соединяется с доменом Active Directory AD) domain компьютера, на котором он выполняется. Поэтому он должен быть выполнен на компьютере, который является членом домена, в противном случае не будет найдена организационная единица OU.

Выберите OU, инструмент должен обрабатываться на машинах, которые «живы» (отвечают на запросы WMI requests). Последнее, что нужно сделать, это вставить командную строку, которую мы хотим выполнить на локальном компьютере, для каждого объекта, находящегося в выбранной организационной единице OU. Текстовую строку “{C}” необходимо оставить, т.к. она будет заменена названием компьютера, при работе сценария.

Рисунок 2: FLEX COMMAND в действии

Давайте предположим, что организационная единица OU под названием “MyComputers” содержит всего 3 компьютера: Computer1, Computer2 и Computer3. Команда, которую мы набрали, “psexec \\{C} gpupdate” затем переводится в 3 следующие команды: “psexec \\computer1 gpupdate”, “psexec \\computer2 gpupdate”, “psexec \\computer3 gpupdate” – все команды будут последовательно выполнены (если компьютеры «живы») и удаленные политики будут обновлены.

Инструмент можно модифицировать таким образом, что список компьютеров будет приходить из файла (txt, csv, xls и т.п.), базы данных, особой группы безопасности в AD, с помощью ручного выбора из списка. Способ запуска сценария также можно изменить, он это всего лишь демонстрационный сценарий, основное назначение которого показать имеющиеся у нас возможности.

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

Инструментарий управления Windows Management Instrumentation (WMI)

Хорошо, инструмент PsExec действительно великолепен, но есть ли какие-нибудь ручные методы, с помощью которых я могу лучше настроить решение для своей среды? Да, на самом деле есть! WMI очень мощный и достаточно прост в использовании после нескольких часов изучения. Если вы владеете WMI, и у вас все в порядке с разрешениями на брандмауэре и правами администратора, то вы сможете сделать практически все в среде Windows environment – даже удаленное выключение компьютера, перезагрузка и исполнение удаленных команд.

Я создал другой сценарий для демонстрационных целей под названием OU GPUPDATE. Этот сценарий HTA использует несколько различных техник – в действительности это небольшая модификация сценария FLEX COMMAND. Во-первых, он разбирает структуру организационной единицы OU в AD (верхний выпадающий список), предоставляет пользователям возможность выбрать компьютеры из OU, запустить Gpupdate с параметром “/Target:User” или “/Target:Computer” или вообще без параметров. Только «живые» компьютеры (которые отвечают на запросы WMI requests) будут затронуты по умолчанию.

Рисунок 3: Выберите, что необходимо обновить – настройки пользователя, настройки компьютера или обе

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

Удаленное написание сценариев

Кроме WMI у нас есть возможность использования обычного удаленного написания сценариев (VBScript). Это можно включить установкой всего одного значения в части HKLM реестра компьютеров, также механизм сценария должен поддерживать удаленное написание сценариев “remote scripting”, и с этого момента все остальное становится достаточно очевидным. Процедура заключается в копировании файла сценария на удаленный компьютер (этот сценарий должен использовать Gpupdate), а затем посылается команда VBScript, которая запускает сценарий удаленно.

RGPREFRESH

RGPREFRESH – это инструмент, разработанный Дареном Мар-Элем. Его инструмент использует WMI и запускает либо Secedit либо Gpupdate в зависимости от операционной системы на удаленном компьютере, с ключами, выбранными пользователем. Эти ключи предоставляют вам те же возмжности, что и при локальном использовании этого инструмента.

Этот инструмент обрабатывает одну машина за раз, но совместно с инструментом под названием FLEX COMMAND (в качестве оболочки) этот инструмент можно использовать для целой организационной единицы (OU) всего лишь несколькими нажатиями мыши … Оба инструмента RGPREFRESH и PsExec можно также совместно использовать с утилитами DSQUERY, FOR и другими утилитами, работающими из командной строки, на более, чем один компьютер за раз.

Рисунок 4: Параметры для RGPREFRESH

Этот инструмент можно бесплатно загрузить с этой странички .

Specops Gpupdate

Компания Special Operations Software, Specops, являющаяся международным производителем программного обеспечения, предлагает продукты по управлению Active Directory на основе технологии политик групп. Компания выпустила свое собственное решение для удаленного обновления политик, и что самое замечательное, это то, что оно совершенно бесплатно. Текущая версия Specops Gpupdate — 1.0.2.13 (2006-10-25) а саму утилиту можно загрузить отсюда . Этот инструмент не только обладает функциональностью, которую мы разработали в сценариях, упомянутых выше, но и также добавляет несколько возможностей по управлению. Давайте рассмотрим эту замечательную утилиту …

Установка Specops Gpupdate

Установка MSI приложения очень проста – все, что для нее нужно, это пользователя и компьютеры Active Directory Users & Computers (ADUC) MMC, а также Microsoft .NET Framework version 2.0.

Рисунок 5: Процесс установки также прост, как установка пакетов MSI (нажимаем на next, next, next)

После установки файла MSI в графическом интерфейсе ничего не меняется GUI, и лишь с помощью “Add/Remove Programs” можно узнать, что на нашей машине установлен Specops. Поэтому мы должны выполнить дополнительную работу для магического превращения …

Расширение для Active Directory User & Computers

После установки Specops Gpupdate в лесу AD Forest, необходимо выполнить специальную команду

“%CommonProgramFiles%\Specopssoft\Specops ADUC Extension\SpecopsAducMenuExtensionInstaller.exe” /add

Это не обновление схемы, хотя вы и должны обладать правами корпоративного администратора для запуска этой команды. Это команда абсолютно обратима, просто запустите ее еще раз с ключом “/remove”. Все, что она делает, это регистрирует, так называемые спецификаторы экрана “Display Specifiers” для расширения просмотра с помощью ADUC.

Затем нажмите правой кнопкой мыши на объекте организационной единицы OU или компьютера, и увидите, что появились четыре новые команды: Gpupdate, Restart, Shut down и Start. Есть возможность сделать выбор нескольких компьютеров и OU благодаря удержанию клавиши и нажатию правой кнопки мыши на необходимых объектах.

Рисунок 6: ADUC MMC расширилась

Если у вас, как и меня, возник вопрос, а можно ли изменения применить также для не контроллеров домена DC, то ответ, да! После установки Windows Server 2003 Admin Pack Service Pack 1 Administration Tools Pack на клиенте Windows XP Professional, .NET Framework 2.0 и Specops Gpupdate, консоль управления выглядит также, как на контроллере домена DC, и имеет те же самые возможности.

Параметры Gpupdate

Первый параметр, который у нас есть, позволяет нам запустить команду Gpupdate удаленно на выбранных компьютерах. После выбора Gpupdate мы должны подтвердить выбор, как показано на рисунке 7, и поставить галочку в поле use force option, если мы хотим использовать настройку усиления.

Рисунок 7

После нажатия на кнопку OK появится динамический график, смотри Рисунок 8, а также отчет о состоянии прохождения обновления.

Рисунок 8

Параметры Restart и Shutdown

Следующие два параметра ‘Restart’ и ‘Shutdown’ являются очень важными для управления, поэтому они нужны нам прямо в ADUC. Мы можем запустить команду restart (перезагрузить) или shutdown (выключить), а также задать интервал времени в секундах, который предоставляется пользователю на то, чтобы закрыть все запущенные приложения. Написать сценарий, который делал бы все то же самое, не очень сложно с помощью WMI или благодаря использованию команды Shutdown.exe с правильными ключами, но благодаря Specops Gpupdate мы получаем эту функциональность совершенно бесплатно без затрат времени и сил.

Рисунок 9: Диалоговое окно с сообщением о перезагрузки

Параметр Start Последний из четырех параметров называется ‘Start’, и в действительности представляет собой функциональность Wake on LAN или WOL (разбудить по сети), встроенную в ADUC. После выбора и подтверждения этого параметра, смотри Рисунок 10, так называемые, магические пакеты (Magic packet) будут посланы на MAC адреса клиентских компьютеров, и начнется их загрузка. Для работы WOL соответствующая функциональность должны поддерживаться BIOS компьютеров. Specops Gpupdate взаимодействует с серверами Microsoft DHCP в корпорации, для нахождения информации, необходимой для запуска этого процесса, поэтому есть возможность разбудить клиентов DHCP и только в сети с установленными серверами Microsoft DHCP.

Рисунок 10: Подтвердите запуск удаленного WOL

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

Заключение

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

Компания Specops разработала очень хорошую бесплатную утилиту, которая выполняет основные функции по обновлению политик на сетевых клиентах. Я рекомендую вам попробовать ее!

Источник www.windowsecurity.com