Посетителей: 8653 | Просмотров: 14956 (сегодня 0)
Среди новых технологий, появившихся в Windows Server 2008 и Windows Vista, одной из наиболее притягательных является технология настроек групповой политики (GPP), которая намного расширяет границы того, что администратор может сделать с помощью групповой политики. Настройки групповой политики предоставляют более 3000 параметров в 22 различных областях внутри объекта групповой политики (GPO) и включают в себя установку сопоставлений дисков и принтеров, а также контроль над членством в локальной группе. И особенно замечательно то, что для всего этого не нужно устанавливать новой инфраструктуры, поскольку технология работает с существующей инфраструктурой Active Directory и средой групповых политик. Чтобы заставить ее работать, достаточно административного средства и клиента DLL. В этой статье я углублюсь в настройки групповой политики, чтобы продемонстрировать как их полезность, так и простоту их развертывания и администрирования.
Содержание
- Совместимость настроек групповой политики
- Политики и настройки
- Структура и параметры настроек групповой политики
- Более сложные конфигурации
- Администрирование настроек групповой политики
- Настройки групповой политики спешат на помощь
- Подводя итоги
- 1. Учет сетевых принтеров
- 2. Автоматизируем GPP
- 3. Добавление принтеров на сервер печати
- Рекомендуем к прочтению
Совместимость настроек групповой политики
GPP можно администрировать только в среде Active Directory, содержащей минимум один сервер Windows Server 2008 или настольный компьютер Windows Vista, поскольку только они могут поддерживать новую консоль управления групповыми политиками (GPMC). GPMC необходима для поддержки и администрирования параметров GPP, она также запускает новый редактор групповых политик (GPME), отображающий GPP, которые можно администрировать.
Однако ситуация существенно другая, когда дело доходит до применения параметров, связанных с GPP; для этого поддерживаются и операционные системы, предшествовавшие Windows Server 2008 и Windows Vista. Говоря конкретно, GPP поддерживает Windows Server 2003 с пакетом обновления 1 и Windows XP Professional с пакетом обновления 2 (SP2), а также все операционные системы, появившиеся после них. На рис. 1 представлена сводка того, какие операционные системы могут администрировать GPPs и какие могут применять GPP.
| Рис. 1. Поддержка операционных систем |
Политики и настройки
Для осознания новых возможностей групповых политик, важны термины «политики» и «настройки». Определения политик и настроек основаны на некоторых ключевых областях управления групповыми политиками, включая обеспечение выполнения, гибкость, поведение реестра, нацеливание и интерфейс пользователя. Это не исчерпывающий список, но именно эти области обычно наиболее важны для администраторов.
Давайте взглянем на ключевые выгоды, предоставляемые настройками в этих областях. На рис. 2 представлено больше информации по различиям между политиками и настройками.
| Рис. 2. Настройки и политики групповой политики* |
| *Таблица позаимствована из "Group Policy Preferences Overview" («Обзор настроек групповой политики») за авторством Джерри Ханикатта (Jerry Honeycutt) |
Обеспечение выполнения Соблюдение GPP не обязательно; таким образом можно создавать первоначальные конфигурации, но контроль остается в руках конечного пользователя.
Гибкость GPP позволяют легко добавить любое значение реестра, файла или папки в GPO для управления. Кроме того, поскольку GPP основаны на XML, их можно эффективно копировать и вставлять в другие GPO.
Поведение реестра Все записи реестра могут контролироваться, даже когда целевой компьютер или пользователь больше не входит в область управления GPO, где настраивается значение реестра. Значения реестра можно удалять или оставлять на местах после того, как GPO более не влияет на целевой объект.
Нацеливание Каждый параметр GPP предоставляет свыше 25 фильтров нацеливания для управления тем, влияет или нет параметр на целевой объект. Примеры фильтров включают диапазон IP-адресов, членство в группе безопасности и совпадение значения реестра.
Интерфейс пользователя Интерфейс пользователя GPP намного проще и удобнее, чем для других параметров в GPO. В большинстве случаев «реальный интерфейс настройки» дублируется в GPO, делая настройку параметра простой и знакомой.
Структура и параметры настроек групповой политики
Когда GPO открывается GPME, политики и настройки очень четко разделены, как показано на рис. 3, позволяя легко увидеть, какие параметры попадают в новую область GPP. Это важно отметить, поскольку настройки ведут себя иначе, чем политики. При развертывании узлов настроек либо в конфигурации компьютера (см. рис. 4), либо в конфигурации пользователя (см. рис. 5) можно увидеть многочисленные параметры разбитыми на две категории: параметры панели управления и параметры Windows.
.gif)
Рис. 3. GPME отделяет политики от настроек
.gif)
Рис. 4. Настройки конфигурации компьютера
.gif)
Рис. 5. Настройки конфигурации пользователя
Более сложные конфигурации
Над GPPs возможен более детализированный контроль чем над любыми другими параметрами в GPO путем использования вариантов, доступных на вкладке «Общие» для каждой настройки. Эта вкладка содержит выставляемые флажки для пяти различных вариантов, возможность настройки нацеливания и текстовое окно для описания настройки GPO, в целях документации и устранении неполадок.
Остановить обработку элементов в этом расширении при возникновении ошибки Поведение по умолчанию обработки групповой политики состоит в том, что все параметры будут обработаны, даже при наличии нескольких параметров в одними и теми же клиентскими расширениями (CSE) и сбое одного из этих расширений. Если требуется, чтобы обработка параметров внутри одного CSE остановилась после сбоя одного из параметров внутри данного CSE, включите этот вариант. Этот параметр имеет тот же охват, что и текущий GPO.
Работать в контексте безопасности вошедшего в систему пользователя (вариант пользовательской политики) При применении параметров групповой политики (как политик, так и настроек), они применяются с использованием локальной учетной записи системы. Поскольку локальная учетная запись имеет только доступ к переменным среды системы и локальным ресурсам, пользовательский контекст очевидно недоступен. Для получения доступа к переменным среды пользователя и сетевым ресурсам этот параметр можно включить с тем, чтобы он выполнял обработку настроек групповых политик с использованием учетной записи вошедшего в систему пользователя.
Удалить этот элемент, когда он больше не применяется Параметры GPP не удаляются из реестра, когда GPO удаляется с пользователя или компьютера, не удаляются они и когда пользователь или компьютер выпадают из области управления GPO. Чтобы параметры настроек удалялись, когда GPO становится неприменим к объекту пользователя или компьютера, можно включить этот вариант (хотя следует отметить, что этот вариант недоступен в некоторых расширениях, скажем в предназначенных для Internet Explorer).
Применить один раз и не применять повторно У групповой политики существует интервал обновления по умолчанию – примерно каждые 90 минут. Это обновление реализовано так, что новые параметры могут быть применены, а старые применены заново, не требуя от компьютера или пользователя перезапуска или повторного входа в систему. Если настраиваемый параметр GPP должен быть применен к компьютеру лишь однажды, без дальнейших обновлений, можно включить этот вариант. Это отличный механизм для установки первоначального массива конфигураций, на которых может влиять GPP, при сохранении для пользователя возможности создания индивидуализированной среды путем изменения параметров после входа в систему и защиты их от переписывания.
Если параметры входят в конфигурацию пользователя, GPP применит эти параметры один раз на каждом компьютере, на который входит пользователь. Если параметр входит в конфигурацию компьютера, GPP применит этот параметр один раз на каждом компьютере. Отметьте, однако, что это лишь одноразовое применение параметров. Чтобы обновить или заново применить эти параметры, необходимо сперва отменить выбор этого варианта.
Нацеливание на уровень элемента По умолчанию все пользователи и компьютеры, попадающие в область управления GPO, получат параметры внутри GPO. Чтобы эти параметры применялись лишь к части пользователей и компьютеров по умолчанию, можно использовать нацеливание. Доступно свыше 25 различных элементов нацеливания; их можно использовать отдельно или в сочетании с другими элементами. На рис. 6 показан полный список вариантов нацеливания на уровень элементов.
.gif)
Рис. 6. Нацеливание на уровень элемента используется для динамического управления параметрами GPP на объектах компьютера и пользователя
Описание Текстовое окно описание позволяет документировать параметры, варианты и элементы нацеливания для каждого параметра GPP. Это текст, который будет виден при выборе определенного параметра настройки внутри GPME, без необходимости изменять сам параметр GPP, как показано на рис. 7.
Администрирование настроек групповой политики
Администрирование GPP идентично таковому для других параметров GPO. Единственная трудность, как упоминалось ранее, состоит в том, что их необходимо администрировать с компьютера, использующего Windows Server 2008 или Windows Vista с пакетом обновления 1 (SP1).
.gif)
Рис. 8. Диалоговое окно новых свойств диска открывается при создании новых параметров политики для сопоставления дисков
Предположим, что необходимо настроить сопоставление дисков в конфигурации пользователя GPO. Параметр настройки для этого расположен в «Конфигурация пользователя» | «Настройки» | «Параметры Windows» | «Сопоставления дисков». Щелкнув правой кнопкой мыши параметр сопоставлений дисков, можно выбрать «Создать—Подключенный диск», что создаст новую политику, как показано на рис. 8. Здесь вводится информация для сопоставления диска, такая как расположение, локальная метка для диска и буква диска.
На этом этапе можно выбрать применение сопоставления диска к каждому пользователю, попадающему в область управления GPO, или ограничить пользователей, получающих параметр, путем настройки нацеливания на уровне элементов. Следует установить нацеливание на уровне элементов, контролирующее, какие пользователи получаю подключение диска, основываясь на их членстве в группе безопасности и путем выполнения быстрой проверки, удостоверяющейся, находится ли на их компьютере конкретный файл программы (EXE). Эта вторая проверка выполняется потому, что сопоставляемая общая папка содержит файлы, полезные только при доступе с помощью файла этой программы.
Чтобы сделать их параметрами нацеливания на уровень элемента, щелкните вкладку «Общие» в диалоговом окне свойств нового диска. Затем установите флажок рядом с «Нацеливание на уровень элемента» и нажмите кнопку «Нацеливание». Это откроет диалоговое окно редактора нацеливания. Щелкните раскрывающийся список для «Параметры элемента» и выберите «Группа безопасности». Затем щелкните «Просмотр», что позволит настроить соответствующую группу, в данном примере HR Users (см. рис. 9).
Теперь необходимо настроить путь к файлу EXE. Выберите «соответствие файлов» из раскрывающегося списка «тип соответствия» для добавления критериев. Затем введите путь файла, в данном случае C:Program FilesACMEHRBenefits.exe. (Примечание. Как соответствия дисков так и принципов придерживаются обновления политики переднего плана GPO. Дополнительную информацию по обновлениям политики можно извлечь из статьи по GPP, Group Policy Processing («Обработка групповой политики»).)
После этого при следующем выходе пользователя из системы и входе обратно появится сопоставленный диск, при условии, что он является членом группы безопасности HR и на его компьютере имеется файл HRBenefits.exe. Если эти условия не выполнены, буква диска не появится.
Рис. 9. Варианты нацеливания на уровень элемента можно сочетать
Настройки групповой политики спешат на помощь
Вот небольшой список некоторых проблем, которые я решил, используя GPP:
- Правка членства локальной группы администраторов на каждом настольном компьютере, чтобы она включала администраторов домена и локальную учетную запись администратора, но не удаляла бы существующих членов группы.
- Обеспечение того, чтобы учетная запись текущего пользователя настольного компьютера не располагалась бы в локальной группе администраторов.
- Контроль над параметрами питания на каждом настольном компьютере, дающий большую экономию энергии.
- Обновление области конфигурации служб на каждом сервере, использующем конкретную службу, чтобы режимом запуска службы всегда бы был «Автоматический».
- Динамическое подключение принтеров, чтобы при посещении пользователями портативных компьютеров филиала 1 они автоматически получали бы нужные принтеры. Аналогично, при посещении филиала 2 они получали бы нужные принтеры для этого места.
Подводя итоги
Настройки групповой политики просты в администрировании и развертывании. Поскольку эта технологии совместима с Windows Server 2003 с пакетом обновления 1 (SP1) и Windows XP с пакетом обновления 2 (SP2), почти все компании могут воспользоваться новыми настройками и даваемыми ими возможностями. Это уменьшает стоимость реализации и позволяет администраторам контролировать настольные компьютеры, необходимые для эффективного выполнения их работы.
Сочетание хорошей схемы развертывания групповой политики с нацеливанием на уровень элемента дает администраторам возможность создавать динамические конфигурации настольных компьютеров и серверов. При наличии более чем 25 доступных критериев нацеливания на уровень элемента почти любой параметр можно контролировать, чтобы применять его только в подходящей ситуации. Дополнительные сведения по групповой политике можно найти в книге Group Policy Resource Kit («Наборе материалов по групповой политике», а также на веб-узле Windows Server Group Policy («Групповая политика Windows Server».
Если вы имеете разветвлённую инфраструктуру WSUS с центральным сервером и некоторым количеством подчинённых серверов то, возможно, вы используете для централизации управления клиентами WSUS групповые политики. С появлением механизмов Group Policy Preferences (GPP) у нас появилась возможность вместо множества групповых политик настраивающих разные наборы клиентских компьютеров на ближайшие к ним WSUS сервера, — использовать одну групповую политику с рядом соответствующих настроек в зависимости от тех или иных условий.
Рассмотрим пример создания такой единой групповой политики с следующими исходными данными:
- Имеется головной сервер WSUS и несколько подчинённых ему серверов;
- Все сервера расположены в разных физических локациях и обслуживают свой набор клиентских компьютеров, находящихся в разных IP диапазонах;
- Один сервер WSUS может обслуживать несколько разных локаций, по каждой из которых необходимо иметь раздельную статусную информацию;
- Есть необходимость разделения всех клиентов на всех WSUS серверах на логические категории для возможности разграничения процедур одобрения тех или иных наборов обновлений.
Для разграничения всех клиентов мы используем стандартный механизм создания групп компьютеров на сервере WSUS. Для примера создадим отдельные группы для каждой физической локации и дополнительно создадим две вспомогательные группы:
- KOM-All-Test-New-Updates — для тестирования новых обновлений
- KOM-All-Not-Install-IE9 – для настройки запрета установки IE9
Группы создаются на головном сервере и реплицируются с механизмом синхронизации на все подчинённые сервера.
Создание групп WSUS позволяет не только более гибко управлять одобрением/отклонением тех или иных обновлений но и получать сводную статусную информацию о результатах полноты установки обновлений в консоли WSUS
Итак, перейдём к настройке групповой политики. Для этого откроем консоль управления групповыми политиками (gpmc.msc) и создадим новый объект групповой политики, в котором сразу можно выключить настройки конфигурации пользователя, так как мы будем использовать только раздел конфигурации компьютера — Computer Configuration
В стандартных Административных шаблонах этой политики зададим основные параметры настройки клиента WSUS которые могут применяться ко всем без исключения клиентам WSUS. На скриншоте приведён пример настройки таких общих параметров:
Все остальные настройки, которые могут меняться в зависимости от условий, которые выдвигаются клиентами WSUS, мы вносим в GPP в раздел настроек Preferences > Windows Settings > Registry
Создадим в корне дерева этих настроек 2 параметра — 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:
Куст реестра: HKEY_LOCAL_MACHINE
Ключи реестра
для x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
для x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Параметр: TargetGroupEnabled REG_DWORD = 1
Ключи реестра:
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdateAU
Параметр: UseWUServer REG_DWORD = 1
Эти два параметра вынесены на верхний уровень настроек специально для наглядности и будут применяться ко всем компьютерам на которые будет действовать данная политика
Параметры сделаны отдельно для 32-битных (x86) и 64-битных (x64) систем, так как в зависимости от битности ОС используются разные ветки реестра. Для 64-битных клиентов WSUS во всех идущих далее по описанию ключах реестра добавляется дополнительное условие нацеливания Item-level targeting
Это условие построено на проверке наличия ветки реестра SOFTWAREWow6432Node в кусте HKEY_LOCAL_MACHINE, то есть, если эта ветка существует, значит обработка политики происходит на 64-битном клиенте
Помимо указанных двух параметров в корне настроек вы можете видеть группы, которые сделаны для того, чтобы отделить клиентов в зависимости от сервера WSUS к которому они должны принадлежать. Для наглядности эти группы именованы так же как и сами сервера WSUS. Для того чтобы отнести клиентов к той или иной группе настроек мы включаем нацеливание по диапазонам IP адресов клиентов. То есть вложенные в эту группу настройки будут применяться к клиентам только в том случае, если они входят в соответствующие IP диапазоны.
Теперь заглянем внутрь любой из таких серверных групп. Внутри каждой группы сделаны настройки на конкретный сервер для того, чтобы клиенты знали куда им ходить за обновлениями и куда отправлять статусную информацию. Это 2 параметра — 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:
Куст реестра: HKEY_LOCAL_MACHINE
Ключ реестра:
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Параметры:
WUServer REG_SZ = https://KOM-SRV-WSUS:8531
WUStatusServer REG_SZ = https://KOM-SRV-WSUS:8531
Внутри каждой группы уровня настроек серверов создаём подгруппы с помощью которых будут настроены параметры реестра для работы механизма WSUS client-side targeting, то есть для автоматического распределения клиентов по группам WSUS, о которых мы говорили в самом начале. В нашем случае нацеливание GPP выполнено опять-таки на IP адрес клиента, при этом надо понимать что IP диапазон который мы указываем в подгруппе должен входить в логику диапазонов группы верхнего уровня.
Внутри подгруппы создаём параметры для WSUS client-side targeting:
Куст реестра: HKEY_LOCAL_MACHINE
Ключи реестра:
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Варианты указания параметра:
TargetGroup REG_SZ = KOM-AD01
TargetGroup REG_SZ = KOM-AD01;KOM-All-Test-New-Updates
TargetGroup REG_SZ = KOM-AD01;KOM-All-Not-Install-IE9
Если клиент должен входить в несколько групп, то их названия перечисляются в значении через точку с запятой. При этом если группы WSUS имеют вложенную структуру, указывается конечное имя группы (без информации об иерархии). Эту особенность необходимо учитывать в процессе планирования и создания структуры групп WSUS.
Важно так же помнить, что порядок применения GPP (Order) тоже имеет своё определяющее значение. 
На этом уровне в нашем примере мы комбинируем разные варианты значения одного и того же параметра реестра в зависимости от разных условий. Например, за дополнительное условие взято членство учетной записи компьютера в доменной группе безопасности. То есть в данном случае значение ключа TargetGroup будет установлено в “KOM-AD01;KOM-All-Test-New-Updates” при условии, если компьютер имеет 64-битную ОС и входит в соответствующую группу тестовых компьютеров в домене.
Обратите внимание на, то что при указании доменной группы безопасности лучше не вводить её название прямо в поле Group, а пользоваться кнопкой обзора, чтобы Tardeting Editor корректно определил SID этой группы.
На этом настройку GPP можно считать законченной и для того, чтобы параметры реестра для механизма авто-назначения в группы WSUS применившись на клиентских компьютерах начали работать, – необходимо переключить сервер WSUS в режим управления групповыми политиками. Для этого в консоли WSUS — Параметры > Компьютеры (Options > Computers) включим соответствующую настройку:
Обратите внимание, на то что эту настройку нужно изменить на всех серверах WSUS.
Результат в консоли WSUS мы сможем увидеть далеко не сразу, так как для вступления новых параметров реестра на клиентах в силу требуется как минимум перезапуск клиентской службы Windows Update (wuauserv), что например, на рабочих станциях достигается элементарным циклом выключения/включения компьютера пользователями. Возможно также на некоторых “непослушных” клиентах потребуется сбросить авторизацию на сервере WSUS
wuauclt /resetauthorization /detectnow
Не забывайте так же про то, что для того чтобы созданная нами групповая политика успешно работала, – клиенты должны уметь работать с GPP, особенно это касается уже устаревших на сегодня систем типа Windows XP.
Дополнение от 21.10.2011
Может возникнуть ситуация, когда потребуется отдельная настройка параметра групповой политики Allow non-administrators to receive update notifications из состава Административных шаблонов (в разделе Computer Configuration > Administrative Templates > Windows Components > Windows Update). Этот параметр обозначает возможность видеть непривилегированным пользователям оповещения клиента WSUS о доступности новых обновлений и инициировать процесс установки обновлений. Для рабочих станций это нормальная ситуация, а вот на терминальных серверах это может стать настоящей головной болью и поэтому для серверов этот параметр лучше выключать. То есть можно в Административных шаблонах этот параметр оставить ненастроенным, а настраивать его ключом реестра через вышеописанный механизм GPP:
Куст реестра: HKEY_LOCAL_MACHINE
Ключ реестра:
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Параметр: ElevateNonAdmins REG_DWORD 1 или 0
Возможные значения ключа:
- 1 – Включено. Пользователи получают оповещения клиента WSUS о доступности свежих обновлений и могут инициировать процесс установки обновлений
- 0 – Выключено. Пользователи не видят оповещений и только администраторы могут управлять процессом установки обновлений.
Таким образом можно создать соответствующие правила обработки GPP с нацеливанием например на версию ОС (серверная/не серверная) ну или например по имени компьютера если в вашей организации действуют какие-то жёсткие стандарты именования компьютеров. Тут уж всё зависит от вашей фантазии.
В своём случае я решил эту проблему немного иначе – для терминальных серверов у меня настроена отдельная групповая политика с замыканием обработки параметров на себя, то есть её параметры всегда будут перекрывать параметры общей политики WSUS. И уже в этой специальной политике этот параметр у меня выключен и пользователям терминального сервера не досаждают оповещения клиента WSUS.
В качестве эпилога, предвидя реплики типа “Всё гибче делается в SCCM”, отмечу сразу то, что эта заметка рассчитана на тех, кто по каким-то причинам не может использовать подобные решения. Как видите, все настройки сделаны в рамках стандартных функциональных возможностей Windows Server.
Дополнительные источники информации:
Много копий сломано вокруг управления сетевыми принтерами на пользовательских компьютерах. В основном администраторы разбились на два лагеря: подключение логон-скриптами (bat/vbs) и управление через GPP. У обоих подходов есть свои плюсы: скрипты быстрее обрабатываются, а GPP гибче и применяется чаще, чем пользователи перезагружают компьютеры. Но когда принтеров больше сотни и разбросаны они в нескольких десятках офисов и городов, сложности будут в обоих случаях.
Нужно не только подключить правильный набор принтеров каждому пользователю, с учетом его текущего местонахождения, но и ни про один не забыть. А если иногда перемещаются не только пользователи, но и сами принтеры…
В общем, мы с коллегами для себя выбрали GPP, в первую очередь для того, чтобы кто-то кроме ведущих администраторов мог разобраться в действующем конфиге, просто посмотрев отчет GPMC. Однако, кто скажет, что его штатный интерфейс удобен для управления 100+ устройствами — пусть первый бросит в меня камень. Кроме того, при вводе в эксплуатацию очередной партии нужно проделать много рутины по настройке сетевого сканирования и добавлению на сервер печати.
А всё, что делается больше одного раза, можно автоматизировать!
Что мы сегодня будем делать?
- вести учет всех сетевых принтеров;
- автоматизировать добавление принтеров в GPP (PS/XML);
- автоматизировать добавление принтеров на принт-сервер, причем на кластерный (BAT/VBS)!
Итак, начнем.
1. Учет сетевых принтеров
Первая проблема, которая возникает при управлении большим количеством любых объектов — это учет. Без него легко запутаться, что где установлено и кому должно быть подключено.
Самое простое и универсальное решение — CSV. В конце концов, из любой системы инвентаризации, ServiceDesk или Excel-таблицы можно выгрузить в CSV и потом легко импортировать это в PowerShell, что мы и будем делать дальше.
У нас выгрузка выглядит вот так:
Поясню сразу, для чего столько полей:
- Name — сетевое имя принтера, оно прописывается в DNS и на сервере печати
- ByGroup — поле определяет, подключать принтер всем, кто находится в соответствующей подсети или только тем, кто входит в группу AD. Также по группе задаются ACL.
- Subnet — подсеть, в которой должен находиться пользователь для работы с принтером
- Location — строка расположения принтера, по которой ищет виндовый мастер добавления принтеров
Этого набора данных достаточно, чтобы не хардкодить их в Powershell. Можно начинать веселье.
2. Автоматизируем GPP
В общем случае файл Printers.xml в объекте GPP выглядит примерно так:
Практически же, я думаю, вы без труда сопоставите названия полей в этом файле с чекбоксами в интерфейсе GPP, но ключевые моменты я отмечу:
clsid — это фиксированные значения классов Group Policy Preferences, их можно (и нужно) оставить как есть.
Name/Status — это отображаемые имена элементов в консоли GPP
uid — а вот это уникальный идентификатор объекта, который вы видели в таблице выше.
Если он будет меняться при каждом обновлении списка принтеров, принтер будет заново подключаться у всех пользователей, что может вызывать разные побочные эффекты.
Path — UNC-путь к принтеру
FilterGroup, FilterIpRange — элементы нацеливания (Targeting) по членству пользователя в группе AD и по нахождению компьютера в диапазоне IP-адресов.
2.1. Импортируем данные и создадим базовую структуру XML-документа:
Для этого используем системный класс [System.Xml.XmlDocument]:
2.2. Добавим несколько вспомогательных функций для создания необходимых элементов XML и задания их атрибутов
Создание элемента принтера:
Создание элементов фильтрации (нацеливания) по группе и по подсети:
Все три функции работают напрямую с передаваемым объектом PS и ничего не возвращают. Ремарка для перфекционистов: на момент написания скрипта так было проще и быстрее, я не стремился написать идеальный объектно-ориентированный код, мне просто нужно было, чтобы работало. Так что да, в коде есть, что улучшать, но главное — он работает!
2.3. И, наконец, основной цикл, добавление элементов управления принтерами
Для каждого принтера создается два элемента: один на добавление, если пользователь в группе и в подсети, и один на удаление принтера, если пользователь не входит в группу или находится в другой подсети.
Если по какой-то причине в CSV-файле нет UID принтера, он сгенерируется и будет выведен в консоль.
Для перевода подсети из нотации CIDR в диапазон адресов я позаимствовал замечательный командлет PSipcalc.
2.4. И теперь выводим результат в файл
Не вижу ничего плохого в том, чтобы сэкономить немного минут и сразу записать в политику:
3. Добавление принтеров на сервер печати
В Windows есть довольно малоизвестный набор vbs-скриптов для управления принтерами. Причем он есть даже в клиентских версиях. Расположен он в каталоге %SystemRoot%System32Printing_Admin_Scriptsen-US , мурзилку можно почитать здесь.
Нас интересуют три утилиты из набора:
prnport.vbs — для создания порта принтера на сервере печати
prnmngr.vbs — для создания самого принтера
prncnfg.vbs — для задания настроек и включения общего доступа к принтеру
Также нам понадобится утилита SetACL для задания прав доступа на принтеры.
3.1. Создаем принтер на сервере печати
Для этого создадим скрипт CreateRemotePrinter.bat.
В качестве аргументов он будет принимать, по порядку:
%1 — Имя принтера;
%2 — Имя драйвера;
%3 — Расположение (Location);
%4 — Описание принтера.
В общем случае этого достаточно. Но у нас сервер печати размещен на кластере MSCS, а указанный выше набор vbs-скриптов с кластерами работать не умеет. Поэтому придется сделать еще кое-что.
3.2. Переносим принтер с обычного сервера печати на кластеризованный
При обращении к кластеру скрипты из набора выше просто создают порт и принтер на текущей активной ноде, и на кластере они не появляются. Как раз на такой случай у Майкрософт припасен еще один инструмент — PrintBRM (Print queue Backup/Recovery/Migration). Официальной документации на него я не нашел, поэтому делюсь тем, что есть: Справка по параметрам на SS64.
Продолжаем скрипт CreateRemotePrinter.bat.
Утилита PrintBRM умеет корректно копировать конфигурацию принтера вместе с портами на кластер, однако если просто сделать копию (запустить с ключом -b) и восстановить (-r), то никакого чуда не будет.
Поэтому сейчас будет немного магии. Она подробно описана в блоге MS Performance Team Blog.
Сначала мы делаем резервную копию принтера в файл temp.printerexport.
Затем распаковываем в подкаталог printerexport, удаляем каталоги LMONS и PRTPROCS, а также обнуляем содержимое нескольких XML-файлов. Не буду вдаваться в подробности, но эти файлы содержат конфигурацию, специфичную для конкретного сервера и мешают восстановлению принтера на другой сервер, особенно кластерный.
После этого запаковываем отредактированную конфигурацию обратно в файл temp.printerexport и загружаем на кластер:
3.3. Добавляем принтеры одновременно в GPP и на сервер/кластер
Теперь нужно органично вписать этот скрипт в цикл обработки CSV-списка принтеров.
Добавим перед основным циклом запрос списка уже существующих на сервере:
И в теле цикла запустим наш Bat-ничек:
