Выгрузка контактных координат сотрудников из AD (powershell), или установка и первый опыт ADpowershell на Windows Server 2003
Поставлена задача обеспечить автоматическое формирование “подписи” (disclaimer) для исходящих писем. Для начала необходимо проверить контактные координаты сотрудников в AD (именно эти координаты мы и будем использовать).
Выгрузим их красиво – PowerShell + ADpowershell (+ADWS), для чего обеспечим поддержку ADpowershell для DC на базе Windows Server 2003.
Приступаем. Итак, что нам предлагает Microsoft. А Microsoft нам предлагает модуль Active Directory для Windows PowerShell. Однако, читаем:
Командлеты AD Powershell доступны, начиная с Windows Server 2008 R2. Чтобы использовать командлеты AD Powershell, в домене должен быть хотя бы один контроллер на основе Windows Server 2008 R2.
Беда. А командлеты, безусловно, удобные. Крайний вариант – ADSI. Однако, нашёл упоминание о возможности использования командлет ADPowershell и для управления лесами и доменами более ранних версий — Используем Active Directory PowerShell для управления контроллерами домена на Windows Server 2003/2008:
Многие читатели интересовались возможностью управлять контроллерами на ранних ОС (Windows Server 2003/2008) с помощью ADPowershell. Единственным, чего для этого не хватало, были возможности Active Directory Web Service (описание здесь). Итак, представляем ADWS для контроллеров домена на ранних версиях ОС. С помощью этого продукта, Вы можете управлять существующими лесами Active Directory с помощью ADPowershell.
В настоящее время уже выпущена финальная версия Active Directory Management Gateway Service. Подробнее об установке читайте в документации — здесь.
Хотя ADWS и устанавливается на Windows Server 2003/2008, для установки командлет ADPowerShell потребуется компьютер на Windows 7 или Windows Server 2008 R2.
Итак, не самое приятное ограничение. Но разрабатывать новые скрипты, безусловно, следует с использованием ADpowershell, ADSI далеко не столь удобен в среде powershell.
Принцип взаимодействия командлет ADpowershell с Active Directory неплохо представлен в здесь.
Рецепт установки на windows server 2003 нашёл уже после написания статьи здесь. Для начала потребуется ADWS для Windows Server 2003, ссылку на которую нашёл здесь. Качаем ADWS (KB968934) (в моём случае — Windows5.2-KB968934-x64.exe). Это обновление необходимо установить на контроллер домена Windows Server 2003.
Там же указано, какие дополнительные обновления должны быть установлены заранее. В частности, для Windows Server 2003 – KB969166, KB969429. Последний просто так скачать не получится, его необходимо запросить http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=969429. Ждём письма, скачиваем архив, указываем пароль из письма, устанавливаем… После установки обновлений и до установки KB968934 необходимо перезагрузить сервер. После перезагрузки KB968934 установлено успешно.
Результатом установки ADWS (KB968934) является регистрация и запуск новой службы на нашем контроллере домена – “Веб-службы Active Directory” (процесс C:\WINDOWS\ADWS\Microsoft.ActiveDirectory.WebServices.exe). По сути дела, подготовку контроллера домена к использованию ADpowershell мы уже закончили.
Теперь осталось разобраться с “клиентской” частью, то есть с хостом, на котором будет исполняться powershell скрипт, использующий ADpowershell. Как уже указывал выше, для этих целей может пригодиться только Windows 7 или Windows Server 2008 R2.
Для начала проверим доступность командлет ADpowershell в Windows Server 2008 R2.
import-module servermanager Add-WindowsFeature -Name "RSAT-AD-PowerShell" -IncludeAllSubFeature import-module activedirectory
Вынужден сообщить, что модуль ActiveDirectory доступен только после установки указанного выше компонента ОС. Естественно, в редакциях типа Windows 2008 Web Server указанного компонента нет (собственно, подтверждение этому нашёл и в этом рецепте).
Итак, после всего проделанного выше наконец-то мы можем выполнить первый запрос, используя ADpowershell:
Get-ADUser -filter {SamAccountName -like "sergey*"}
Теперь, по сути, у нас осталось две задачи:
- разобраться, если всё-таки хоть какая-нибудь, пусть и не совсем очевидная, возможность использовать ADpowershell командлеты на windows 2003;
- и, собственно, решить саму исходную задачу – выгрузить контактные координаты наших сотрудников конкретного подразделения.
А теперь решим исходную задачу – выгрузим контактные координаты сотрудников из AD с помощью powershell + ADpowershell.
P.S. Две полезные статьи по фильтрам в LDAP (извиняюсь – ADpowershell) запросах на нашем родном языке: Active Directory PowerShell – Расширенный фильтр, Active Directory PowerShell – Расширенный фильтр (Часть 2).
P.S. Неплохой обзор ADpowershell — http://trycatch.be/blogs/roggenk/archive/2010/01/14/active-directory-web-services-adws-and-active-directory-management-gateway-service-admgs.aspx.
Отзывы » (8)
Связь с комментариями статьи:RSS комментарии
Обратная ссылка
Станицы 
Рубрики 
Облако ключевых слов 
RSS анонсов статей 
Windows 7 
Городские огни 
Characters 
Landscape 
Nature 
Shapes ![[-]](http://sergey-s-betke.blogs.csm.nov.ru/wp-content/themes/inanis-seven/images/st_link.png)
Добрый день. А почему вы не рассматриваете вариант с использованием бестлатных командлетов от Quest software: ActiveRoles Management Shell for Active Directory, которые без проблем можно установить даже на windows xp?
Однако, не успел ещё статью дописать, а уже комментарии :-). QAD командлеты хороши, даже более, чем просто хороши. Однако, моё мнение таково: любой администратор домена на базе Microsoft Windows обязан владеть командлетами ADpowershell, потому как данный модуль является решением разработчика ОС. Поэтому, с точки зрения возможностей сопровождения наёмными инженерами (которые периодически меняются, что неизбежно) лучше строить свои решения на технологиях, которые должны быть знакомы любому системному администратору домена на базе Microsoft Windows Server 2008 R2.
Именно поэтому и отдаю предпочтение ADpowershell от Microsoft, а не QAD от Quest Software.
При этом должен подтвердить: QAD не только не уступает в ряде задача ADpowershell, но и превосходит. Но — это стороннее решение.
В данном случае, как это не пародоксально, решение от Microsoft (по сравнению с решением от Quest) выглядит каким-то инородным телом, которое пытаются хиругическим путем пытаются импланитровать в старые версии ОС .
IMHO, командлеты от Quest, благодаря тому, что
- появились раньше аналога от ms
- поддерживают любые версии ОС
- популярны (огромное количество опубликованных скриптов)
- благодаря особенностям powershell, хорошо и самодокументированы (даже, если предположить, что инженер умудрился ничего не слышать о них, он легко и быстро сможет начать работу с ними)
на текущий момент являются стандартом в гораздо большей степени, чем решение от MS.
Сомневаюсь, что «любой системный администратор» будет напрягаться и, рискуя поставить под угрозу стабильность/работоспособность работы ОС, прикручивть все-таки инородное (для старых версий windows) решение, только из-за того, что оно выпущено тем же производителем.
Сурово Вы оценили ADpowershell. Действительно, решение Quest Software, вероятнее всего, и стало прообразом ADpowershell. Но есть несколько аргументов, которые заставляют меня изучить ADpowershell:
- powershell был создан как средство инкапсуляции конфигурации приложений, их событий. Некое унифицированное средство инкапсуляции.
- с 2007 года Microsoft все вновь выпускаемые серверные решения конфигурирует только посредством powershell. Даже если мы с Вами видим некий интерфейс, он всего лишь генерирует сценарий powershell, который уже и выполняет необходимые действия. Таким образом Microsoft гарантирует полноту возможностей командлет powershell по управлению тем или иным продуктом. Такова генеральная линия, пусть ещё пока и не все продукты выполняют её требования.
- и для Directory Services в Windows 2008 R2 создана консоль, взаимодействующая с AD исключительно посредством ADpowershell.
Из последнего пункта следует вывод: все новые возможности, обеъекты, их реквизиты и так далее будут в обязательном порядке находить свое отражение в ADpowershell в кратчайшие сроки (потому как работа с ними посредством новых консольных решений будет невозможна, пока ADpowershell не поддерживает их). Поэтому есть хоть какая-то гарантия, что поддержка ADpowershell будет постоянной и своевременной. Касательно же бесплатного продукта от Quest Software такой уверенности нет (на то он и бесплатный).
Что касается устройчивости ОС — опасаться нечего. Решение для Windows 2003 повторяет полностью решение для Windows 2008 R2, просто в последнем оно уже «выглядит» как нечто «встроенное», что не так. Такой же web сервис, ничего общего с протоколом ldap не имеющий. И в 2008 R2 это решение — всего лишь обёртка вокруг LDAP интерфейса AD (хотя, вполне возможно, можно было использовать ADSI в качестве прослойки вместо веб сервиса. Но с программированием веб сервиса явно проще :-))
Ни в коем случае никого не призываю забыть QAD, но для решения простейших задач, для которых и ADSI хватило бы, не говоря уже о ADpowershell, считаю более целесообразным использовать то решение, которое «является неотъемлемой частью» контролера домена, начиная с Windows Server 2008 R2 (хотя, как я и говорил уже выше, никто не отменяет LDAP протокола).
Основываясь на одних и тех же фактах мы делаем разные выводы
Никто не спорит (и даже не собирался ;)), что будущее в администрировании win-систем за PoSh , и что MS будет стараться перевести администрирование своих продуктов на этот замечательный скриптовый язык. Речь, по-моему, идет немного о другом: какие командлеты использовать для администрирования ОС, которые заканчивают свой жизненный цикл?
IMHO, в настоящий момент, наиболее простой и удобный способ для этого – использование командлетов о Quest. Ваши предположения о смутном будущем этих командлетов меня ничуть не пугают: не составит большого труда перейти от их использования к использованию родных от командлетов от MS в будущем, т.к. они очень похожи. Да, вполне вероятно, что когда для администрирования AD на любой версии win можно будет установить и использовать командлеты о MS, то QAD-комадлеты отомрут естественным путем, превратившись в неуловимого Гонсалеса. Но сейчас процесс установки «родных» командлетов от MS на старые ОС напоминает процесс «натягивания шарика на кактус» и пугает меня гораздо больше, чем предположения о судьбе QAD-командлетов. Почему для установки требуется запрашивать hotfix, недоступный в открытом доступе? Он недостаточно отлажен? Почему для того, чтобы сделать элементарную вещь (добавить командлеты в работающую систему), я должен навешивать на эту систему ненужные мне сервисы? Почему на технетовских форумах пишут о, возможном возникновении проблем с DC, после установки этих сервисов?
Не-е-е, «такой хоккей нам не нужен»
ЗЫ Бесплатность командлетов от Quest, никак не должна сказаться на желании Quest прекратить их поддержку. IMHO, профит, получаемый Quest от их бесплатности гораздо больше, чем возможная прибыль от их продажи.
Всё зависит от того, как поставить задачу. Если задачу ставить так: «администрирование отмирающих ОС», тогда действительно решение от Quest Software выглядит более предпочтительным. Но задачу то мы ставим иначе: «администрирование Active Directory». При этом крайне желательно для нас при разработке сценариев отвязаться от версии DC, чтобы не пришлось переписывать при переходе на windows server 2008 R2.
По поводу недоступности hotfix в свободном доступе могу предположить следующее: он действительно не прошёл необходимый цикл тестирования (что уж точно — microsoft у себя явно не использует windows 2003 server DC с ADWS), и, кроме того, microsoft хочет иметь возможность некоего мониторинга с контактными координатами, дабы оценить потребность в данном решении для windows server 2003.
Подводя итого, как говорит один мой знакомый: «решений всегда много». И в нашем случае тоже :-).
Обнаружил изумительную по сути статью об использовании командлет ADpowershell (и не только) через powershell remoting неявно!: http://www.oszone.net/13106/Windows-PowerShell. Супер! В таком варианте можно в качестве клиента использовать хоть XP! Буду пробовать.
добрый деньесть ли возможность прислать русские версии KB969166, KB969429.