Создать набор командлет для "регистрации" принтеров и их публикации

[sergey-s-betke]

Описал Get-ADPrintQueue. К сожалению, не смог определить модульные тесты с помощью pester для этой функции, потому как при создании прокси функций для функций с несколькими наборами параметров посредством

[System.Management.Automation.ProxyCommand]::Create($MetaData) 

определения параметров не воспроизводятся вовсе.

Назначение Get-ADPrintQueue - обёртка вокруг Get-ADObject, по аналогии с Get-ADUser.

[sergey-s-betke]

Кратко, что требуется:

• сформировать необходимые атрибуты объекта (описание, displayName)
• возможно - поправить расположение. При этом будет правильно добраться до сервера, опубликовавшего принтер, и поправить атрибуты и на нём, чтобы при обновлении публикации результат сохранить
• создать OU для каждого принтера. Точнее - контейнер, а какой выбрать - следует посмотреть внимательнее схему AD.
• создать группы для каждого принтера (Пользователи печати, Операторы печати). Естественно, наименования групп следует локализовывать, и предоставлять возможность явно задавать в параметрах (возможно?)
• проверять существование очереди печати для каждого созданного OU принтера (очереди печати). Как помечать - подумаем. Есть же теперь корзина! Про это следует почитать.
• создавать GPO для каждой очереди печати, связи к этому GPO, и изменять дескриптор безопасности для GPO. Естественно, и само подключение очереди печати в политику необходимо прописывать. Пожалуй, это и будет самым сложным.
• обязательно поддержать и протестировать -WhatIf и прочие параметры, обязательно!

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

[sergey-s-betke]

Решать задачу будем по частям, с модульными тестами. И первая задача: создание контейнера для каждого принтера. Использовать для этих целей OU нет смысла, это же не подразделение явно. Предлагаю использовать класс container. Объекты этого класса прекрасно видны и в консоле ADUC, но только при включенной опции "Дополнительные компоненты". Хуже будет другое: эти контейнеры не будут видны в консоли "Управление групповой политикой".

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

Итак, функции:

• Test-ADPrintQueueContainer (псевдонимов будет несколько. Test-ADPrinterOU, в часности). - предикат, проверяющий наличие контейнера для нашей очереди печати
• New-ADPrintQueueContainer - создание контейнера. Без групп, только контейнер.
• Get-ADPrintQueueContainer - собственно получение объекта контейнера для объекта очереди печати.
• Set-ADPrintQueueContainer - изменение атрибутов контейнера. Вне зависимости от класса контейнера параметры этой функции позволят изменять только атрибуты контейнера. И только те, которые имеют смысл для контейнера очереди печати.

Практически для всех функций модуля имеет смысл задать один общий параметр - DomainUtilsBase. Общий - для того, чтобы в PoSh 3 его можно было задать через умолчания. И для указанных выше командлет дополнительный параметр - ContainerName. Его значение по умолчанию - через локализацию.

[sergey-s-betke]

Добавить для Get-ADPrinter поддержку для Identity имени принтера.

[sergey-s-betke]

Теперь пора приступать к:

• созданию групп безопасности для очередей печати.
• созданию GPO для каждой очереди печати с ей публикацией в указанном GPO (кстати, публиковать следует как в политику ПК, так и в политику пользователя. Дальше уже пусть безопасностью фильтруют, к кому её применять.

[sergey-s-betke]

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

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

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

В итоге - идём по второму варианту.

[sergey-s-betke]

Долго думал над наименованиями функций.

• для групп: Get-ADPrintQueueGroup, New-ADPrintQueueGroup, Update-ADPrintQueueGroup
• для GPO аналогично.

[sergey-s-betke]

New-ADPrintQueueGroup готова, теперь Get и Update. Для Update есть как раз смысл предусмотреть флаг Force для принудительного создания групп в случае их отсутствия.

[sergey-s-betke]

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

[sergey-s-betke]

Подключение принтера через GPO сценарием - не самое очевидное занятие. Затрагивает и file part, и ad part:

• http://blog.powershell.no/2009/11/08/deploying-printers-using-group-policy/
• http://gallery.technet.microsoft.com/ScriptCenter/df4eae77-c8a9-40f9-b2eb-a7ed9ef7cd2a/

Использовать коммерческий модуль ради этой задачи мы не будем, сценарием поправим сами и AD part, и file part. При этом сначала попробую поправить только AD part, возможно - этого будет достаточно?

[sergey-s-betke]

Подключение очереди печати через ad part и через file part GPO - два альтернативных пути. Первый мне нравится даже больше, но необходимо проверить, будет ли он работать без запуска pushprinterconnections.exe. Если да - будем использовать его, я думаю.

Второй путь так же не сложнее, но придётся создавать / изменять xml файл в file part GPO.

[sergey-s-betke]

GPP (через file part) существенно гибче в настройках, безусловно. Пусть и сложнее, но склоняюсь к варианту публикации через GPP (через file part GPO).

[sergey-s-betke]

Параметры, отвечающие за авторизацию, целесообразно удалить. Иначе вызовы тех же *-GPO сильно усложнены будут. Если необходима явная авторизация - можно использовать сессии PowerShell. Предлагаю оставить только два параметра:

• Server - контроллер домена, на котором будем выполнять изменения
• Domain - собственно домен, в котором будем выполнять необходимые нам действия
• DomainUtilsBase - путь уже должен быть относительным по отношению к домену.

По последнему параметру есть ряд вопросов. Целесообразнее решить вопрос с хранением параметров модуля в AD. Тогда последнего параметра не будет. Так что целесообразно предварительно решить вопрос с хранением параметров, на этом этапе - через инкапсуляцию в командлетах.

[sergey-s-betke]

Есть неочевидные моменты. Например, для Get-ADPrintQueue как "совместить" параметры Domain и SearchBase?

С другой стороны - а зачем совмещать? Никто не говорил, что мы должны "искать" очереди печати в том же домене, в котором будем создавать объекты GPO. Поэтому в указанном командлете параметра Domain быть не должно. А в командлетах, отвечающих за GPO, - не будет SearchBase, что логично.

[sergey-s-betke]

Итак, работу с конфигурацией вынес в отдельный файл и командлеты, модуль заново отладил и сократил параметры благодаря конфигурации. И снова возвращаюсь к отладке создания GPO+GPP.

[sergey-s-betke]

Итак, New-ADPrintQueueGPO в первой редакции работает. Однако, есть проблемы с созданием GPLink. В контейнере (не OU) создать связь невозможно. Да и в консоли Управление групповой политикой видны будут только OU.

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

[sergey-s-betke]

Обеспечил поддержку для New-ADPrinterGPO и класса контейнера OU с созданием ссылок на объекты политик в контейнерах очередей печати (только для OU).

Разумно и необходимо так же создавать ссылки на эти объекты сразу в некий OU, который будет являться "корневым" для размещения учётных записей наших пользователей и учётных записей наших ПК. Расположение этого OU необходимо сохранять в конфигурации. Создание данной ссылки разумно сделать опциональным, по флагу в параметрах командлета.

[sergey-s-betke]

Добавил Get-ADPrintQueueGPO.

[sergey-s-betke]

Необходимо:

• в Initialize-ADPrintQueuesEnvironment добавить -Force (для переопределения аттрибутов существующего контейнера)
• добавить Test-ADPrintQueuesEnvironment

Эти шаги необходимы для Update-ADPrintQueueEnvironment (там же и New-*, и Remove-*). Этими командлетами основной функционал для принтеров завершим.

Дополнительный функционал:

• командлеты для управления очередями печати на принт-серверах (именование, создание локальных групп безопасности и включение в них доменных групп, изменение прав доступа на очереди печати, публикация очередей печати в качестве общих ресурсов, публикация их в AD)
• связывание очередей печати с помещениями (physicalLocation)
• изменение аттрибутов очередей печати на основании аттрибутов physicalLocation

И, естественно, необходимо всё подробно описать в readme.

P.S. Склоняюсь к целесообразности выделения ITG.DomainUtils в качестве самостоятельного модуля. Слишком уж они получаются ёмкими, в том числе и по описанию.

[sergey-s-betke]

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

[sergey-s-betke]

Убрал контейнеры, изменил имена групп.

[sergey-s-betke]

Данный функционал выделен в отдельный модуль - https://github.com/IT-Service/ITG.DomainUtils.Printers