WMIADRepl.wsf — сценарий для управления репликацией AD
Мониторинг репликации AD является важной задачей управления сетевой инфраструктурой. Особенно это актуально для корпоративных сетей со множеством серверов и сложной топологией репликации. В связи с этим администраторы AD вынуждены применять для управления репликацией AD между серверами множество различных инструментов и пользовательских интерфейсов (Replmon, Repadmin и оснастка Active Directory Sites and Services для Microsoft Management Console). Иногда из-за проблем соединения или отказа могут оказаться недоступными серверы-мосты, контроллер домена или другие важные серверы AD, и эта неисправность существенным образом изменяет топологию репликации. В таком случае может потребоваться выполнить проверку согласованности Knowledge Consistency Checker (KCC) для перерасчета топологии репликации. Для некоторых задач важно автоматизировать запуск KCC или явным образом выполнить принудительную репликацию определенного контекста именования в ответ на возникновение каких-то событий. Для Windows 2000 Server такого рода автоматизация была действительно сложной задачей, требующей непосредственного вызова определенных функций AD через Win32 API. К счастью, Windows Server 2003 содержит специальный провайдер WMI для управления репликацией AD, который обеспечивает API для выполнения некоторых функций KCC и AD, что позволяет значительно упростить и автоматизировать многие задачи управления репликацией AD. В данной статье рассматриваются вопросы использования нового провайдера WMI репликации AD и предлагаемых классов.
Классы WMI репликации AD
Провайдер репликации AD и соответствующие классы, располагающиеся в пространстве имен root
MicrosoftActiveDirectory репозитария CIM (Common Information Model), позволяют вызывать выполнение процедур KCC и получать информацию о репликации AD. Для просмотра и исследования пространства имен rootMicrosoftActiveDirectory и содержащихся там классов можно воспользоваться набором инструментов CIM Studio, который можно загрузить по ссылке http://download.microsoft.com/download/.netstandardserver/ install/v1.1/nt5xp/en-us/wmitools.exe. Можно также воспользоваться языком WQL (WMI Query Language) и создать сценарии для получения из этих классов информации о репликации AD и отслеживания возникновения событий репликации AD.
Например, можно воспользоваться сценарием GenericEventAsyncConsumer.wsf для выполнения приведенного ниже запроса WQL:
Select * From
__InstanceModificationEvent
Within 10 Where
TargetInstance ISA
?MSAD_DomainController?
который будет раз в 10 секунд опрашивать котроллер домена о происшедших на нем изменениях. MSAD_DomainController представляет собой класс репликации AD, обеспечивающий доступ к свойствам контроллера домена. Сценарий GenericEventAsyncConsumer.wsf служит для настройки мониторинга любого типа событий, определяемых запросом WQL.
На экране 1 представлены части возвращаемого результата сценария GenericEventAsyncConsumer.wsf при запуске приведенного выше запроса WQL. Фрагмент А соответствует ситуации, когда контроллер домена не зарегистрирован в DNS; во фрагменте B контроллер домена уже зарегистрирован.
Экран 1. Результат работы сценария при мониторинге событий контроллера домена |
Чтобы использовать этот сценарий для организации запроса WQL, нужно выполнить сценарий на контроллере домена в любом контексте безопасности. Если же вы собираетесь запустить сценарий на удаленном контроллере домена, необходимо работать в контексте администратора, поскольку по умолчанию WMI разрешает удаленный доступ только администраторам. Во время работы сценария следует выполнить изменения регистрации DNS, удалив запись A в своем DNS. WMI обнаружит, что контроллер домена не зарегистрирован в DNS, и направит сценарию соответствующее уведомление. Сценарий, в свою очередь, выдаст сообщение об изменении состояния регистрации DNS.
Сценарий WMIADRepl.wsf
Сценарий GenericEventAsyncConsumer.wsf спроектирован для мониторинга любых типов событий, определяемых запросом событий WQL, но не для того, чтобы перехватывать события провайдера репликации AD. Для управления репликацией AD и поддержки всей функциональности, предоставляемой классами репликации AD, потребуется другой сценарий, который будет представлен ниже, — WMIADRepl.wsf. Данный сценарий можно полностью загрузить на сайте www.windowsitpro.ru.
При запуске сценария WMIADRepl.wsf необходимо в командной строке передать в сценарий свойства репликации AD, которые предполагается обновить, и методы, которые предстоит использовать. WMIADRepl.wsf обращается к имеющемуся в WSH 5.6 модулю разбора XML. После разбора параметров командной строки и установки соединения с WMI сценарий получает экземпляры WMI репликации AD в соответствии с указанными в командной строке параметрами
При указании в командной строке ключа /ReplPendingOp+ происходит выполнение кода, приведенного в листинге 1. Этот код запрашивает информацию о выполняемых и назначенных заданиях репликации на контроллере домена, для чего опрашиваются все экземпляры MSAD_ReplPendingOp. Если имеется хотя бы один экземпляр класса MSAD_ReplPendingOp, сценарий для каждого экземпляра в коллекции перечисляет свойства, получает их значения и вызывает функцию DisplayFormattedProperty(), которая выводит на экран информацию в виде списка значений свойств экземпляра. Функция DisplayFormattedProperty() представлена в файле DisplayFormattedPropertyFunction.vbs, который загружается вместе со сценарием WMIADRepl.wsf.
При указании ключа /NC+ сценарий WMIADRepl.wsf перечисляет экземпляры класса MSAD_NamingContext. Логика исполнения аналогична рассмотренной выше при обработке ключа /ReplPendingOp+. Сценарий получает объекты MSAD_NamingContext и перечисляет все экземпляры. Для каждого из свойств выполняется перечисление свойств класса MSAD_NamingContext и вывод на экран значений свойств. Отличается только форматирование данных при выходе — в этой ветви кода значения выводятся в несколько столбцов, так что обращения к функции DisplayFormattedProperty() не происходит. На экране 2 представлен пример результата сценария при запуске с ключом /NC+.
Экран 2. Результат работы сценария WMIADRepl.wsf |
По ключу /ReplCsr+ сценарий WMIADRepl.wsf выводит сведения о состоянии всех входящих репликаций с учетом всех реплик заданного контекста именования. Здесь применяется техника, приведенная в листинге 1, только используется имя класса MSAD_ReplCursor. При исполнении этой ветви кода сценарий выводит отличительное имя (DN, distinguished name) каждого контекста именования NC, размещенного на контроллере домена, при этом для каждого элемента выводятся дата и время последней успешной синхронизации. Также для каждого контекста именования выводится последовательный номер обновления (USN, update sequence number), который представляет собой 64-разрядное число, начинающееся с 1 и увеличивающееся на 1 с каждым обновлением объекта AD. Следует иметь в виду, что последовательные номера обновлений USN изменяются независимо на различных контроллерах доменов. Таким образом, для одного и того же объекта USN может принимать разные значения на различных контроллерах. Более подробные сведения об используемых в репликации механизмах, и в частности USN, можно найти в статье «Chapter 6 — Active Directory Replication» in Windows 2000 Server Distributed Systems Guide (http://www.microsoft.com/technet/prodtechnol/windows2000serv/ reskit/distsys/part1/dsgch06.asp).
По ключу /DC+ сценарий WMIADRepl.wsf задействует те же принципы программирования, что и в листинге 1, но на этот раз используется класс MSAD_DomainController для получения сведений о контроллере домена (см. пример на экране 1). Булевские значения IsAdvertisingToLocator, IsGC, IsNextRIDPoolAvailable, IsRegisteredInDNS и IsSysVolReady указывают на состояние контроллера домена и полезны для целей мониторинга.
Ключ /ReplNeighbor может использоваться двумя способами. Если не указан контекст именования:
wmiadrepl.wsf /ReplNeighbor
сценарий выводит краткую информацию о каждом из доступных контекстов именования. При указании контекста именования:
wmiadrepl.wsf /ReplNeighbor:
CN=Configuration,DC=LissWare,
DC=Net
сценарий выводит полную информацию об указанном контексте именования. В листинге 2 представлен код, обрабатывающий оба случая. Код выводит значения свойств класса MSAD_ReplNeighbor, соответствующие информации о состоянии входящей репликации для контекста именования AD и его исходного сервера. Например, значения свойств показывают, является ли входящая репликация назначенной по расписанию, имя исходного контроллера домена и результат последней синхронизации. В листинге 2 для обработки ошибок используется вызов функции ErrorHandler(), которая определена в файле TinyErrorHandler.vbs, загружаемом вместе со сценарием WMIADRepl.wsf.
Ключ /ExecuteKCC, как видно из названия, использует метод ExecuteKCC класса MSAD_DomainController для принудительного вызова KCC. Помимо прочего, KCC вычисляет топологию репликации (т. е. определяет, где следует сформировать объекты подключения для создания связей репликации между контроллерами домена). Класс MSAD_DomainController, предоставляющий метод ExecuteKCC, представляет собой оболочку для API DsReplicaConsistencyCheck, так что метод использует те же параметры вызова, что и функция API. В таблице 2 содержатся значения, соответствующие двум параметрам метода, которые определены в качестве констант в начале сценария WMIADRepl.wsf. Для принудительного выполнения KCC используется команда
wmiadrepl.wsf /ExecuteKCC+
В листинге 3 приведено обращение к методу ExecuteKCC.
И наконец, последний из рассматриваемых ключей, /SyncNC, обращается к другому интересному методу класса MSAD_ReplNeighbor — SyncNamingContext, который можно использовать для запуска принудительной репликации определенного контекста именования AD. Класс MSAD_ReplNeighbor представляет собой оболочку для вызова API DsReplicaSync(). Значения параметров вызова для этого класса представлены в виде констант в начале сценария WMIADRepl.wsf, их описание можно найти в таблице 3. Для запуска принудительной репликации контекста именования используется команда вида:
wmiadrepl.wsf /SyncNC:
CN=Configuration,DC=LissWare,
DC=Net
В листинге 4 приведено обращение к методу SyncNamingContext. Чтобы получить контекст именования, для которого будет производиться синхронизация, сценарий выполняет запрос данных WQL с указанием необходимого контекста. Результатом исполнения запроса является соответствующий контексту экземпляр WMI.
Управлять AD стало проще
Управление репликацией каталога — AD или любого другого — никогда не было простой задачей. В AD Windows 2000 из-за ограничений KCC некоторые компании, построившие разветвленную сложную структуру сайтов или доменов, вынуждены использовать сценарии ADSI (Active Directory Service Interfaces) для управления запуском KCC. Более подробные сведения об этом можно найти в статье «How to Optimize Active Directory Replication in a Large Network» базы знаний Microsoft на странице http://support.microsoft.com/?kbid=244368. Специалисты Microsoft утверждают, что в Windows 2003 функция KCC может поддерживать до 5000 сайтов (сравните с 300 для Windows 2000) в лесу AD Windows 2003. Благодаря такому увеличению масштабирования в сочетании с новым провайдером WMI репликации AD функции управления AD значительно расширяются.
Windows 2000 позволяет использовать RepAdmin для принудительного выполнения репликации AD из командной строки, но реализованный в Windows 2003 интерфейс доступа к свойствам и методам репликации AD позволяет администраторам создавать собственные механизмы управления репликацией. При этом могут применяться различные системы программирования — сценарии WSH, Visual Basic, Cи, C++, приложения Windows .NET Framework, а также системы управления инфраструктурой, такие как HP OpenView for Windows. Новый провайдер выводит управление и программирование AD на качественно иной уровень, чем могут воспользоваться системные администраторы и разработчики систем.
Алан Лиссо - член группы Technology Leadership Group, входящей в состав подразделения HP Consulting and Integration. Автор книг Understanding WMI Scripting и Leveraging WMI Scripting (Digital Press). alain.lissoir@lissware.net