. Однако, как правило, вину за них нельзя возлагать на AD.

Почему нужно следить за репликацией и поддерживать ее в исправном состоянии? Если репликация отказывает на одном или нескольких DC, то часть пользователей не может получать новейшие данные каталогов. Это приводит к различным неполадкам: не происходит изменение паролей; учетные записи, разблокированные администраторами, недоступны для владельца учетной записи; пользователи лишаются доступа к приложениям (даже если они введены в нужные группы); новые пользователи не могут зарегистрироваться (хотя их учетные записи созданы); и, что очень важно, уволенные сотрудники сохраняют доступ к сети после отключения их учетных записей.

Неполадки репликации также влияют на функционирование групповой политики и изменения сайтов или подсетей. DC, для которого не налажена успешная репликация с партнерскими контроллерами доменов, будет выведен из леса, и его придется перестроить. Проблемы репликации также могут отразиться на обновлениях схемы; известны случаи, когда они приводили к отказам в масштабах всего леса.

Многоуровневый подход

Администраторам AD следует уделить немного больше времени репликации AD ради сохранности каталогов (и своих рабочих мест). Функционирование AD как распределенного приложения зависит от всех уровней инфраструктуры. Большинство проблем, приводящих к нарушениям службы AD (в том числе репликации), объясняется изъянами инфраструктуры или ошибками администратора, например случайным удалением объектов. Поэтому первый шаг при поиске неисправностей в репликации AD — убедиться в правильности работы инфраструктуры. Я называю этот метод диагностикой «от проводов».

В качестве основы для модели диагностики AD я использую семиуровневую сетевую модель OSI (физический, канальный, сетевой, транспортный, сеансовый, представления данных и прикладной уровни). Моя модель имеет следующие уровни:

  • физический (провода);
  • сетевой;
  • разрешения имен;
  • операционной системы;
  • проверки подлинности;
  • собственно приложения AD.

Физический уровень относится к физической инфраструктуре сети: это провода, обеспечивающие функционирование сети. Если сетевой провод был отсоединен или волоконно-оптический кабель задет ковшом экскаватора, репликация будет нарушена.

Сетевой уровень относится к сетевым подключениям над физическим уровнем — функциональности маршрутизатора, коммутатора и особенно брандмауэра. Связь между контроллерами доменов устанавливается через несколько портов (через некоторые — динамически), поэтому важно аккуратно следовать инструкциям, изложенным в статье Microsoft «How to configure a firewall for domains and trusts», опубликованной по адресу support.microsoft.com/kb/179442.

Другая проблема сетей — ошибки удаленного вызова процедур (RPC), например недоступность сервера RPC. В блоге Ask the Directory Services Team содержится очень познавательная публикация о диагностике таких ошибок с использованием утилиты PORTQRY.Дополнительные сведения можно найти в статье «Using PORTQRY for troubleshooting» по адресу bit.ly/g5CTuJ в блоге Microsoft Directory Services Team.

Разрешение имен: главный подозреваемый

Основные усилия при поиске неисправностей AD следует сосредоточить на уровне разрешения имен, так как большинство связанных с AD неполадок вызваны ошибками в настройках разрешения имен. Несколько лет назад служба поддержки продуктов Microsoft пришла к выводу, что 80% неисправностей AD коренится в разрешении имен. Дополнительные сведения можно найти в материале «Troubleshooting networks without NetMon» по адресу blogs.technet.com/b/askds/archive/2007/12/18/troubleshootingnetworks-without-netmon.aspx.

Для работы AD требуется, чтобы служба DNS регистрировала и разрешала многочисленные службы и узлы, а ошибиться при настройке DNS очень просто. Компания Microsoft давно признала это обстоятельство и значительно усовершенствовала мастер DCPROMO для настройки DNS. В нашем журнале было опубликовано множество статей о DNS, в том числе несколько материалов Бойда Гербера, инженера по развитию сетей в компании Microsoft. Дополнительные сведения о диагностике DNS приведены на сайте Microsoft TechNet в статье «Troubleshooting Active Directory–Related DNS Problems» по адресу tinyurl.com/72ca8h.

Вероятно, лучшая команда для поиска неисправностей DNS — DCDIAG/TEST: DNS. Эта команда диагностики выполняет исчерпывающее тестирование службы DNS контроллера домена или сервера, указанного с помощью ключа /S. Использование ключа /V (verbose) обеспечивает подробные результаты тестов. Применение ключа /E (enterprise) запускает команду на всех серверах DNS в лесу. Наконец, для более глубокого анализа больших объемов информации, выдаваемых этой командой, вывод можно направить в файл с использованием ключа /F.

Многие из этих методов описаны на странице DNS диаграммы Active Directory Troubleshooting (deuby.com/adtroubleshooting/ccount/click.php?id=2). Дополнительные советы по диагностике AD можно найти в блоге Active Directory Troubleshooting Tips and Tricks по адресу tinyurl.com/adtroubleshooting.

Один из малоизвестных аспектов AD — связь разрешения имен с репликацией. Некоторые типичные ошибки, нарушающие репликацию, относятся к разрешению имен, например недоступность сервера RPC (RPC server is unavailable) или сбои поиска DNS (DNS lookup failure). Пользователи и большинство служб компьютера отыскивают другие компьютеры в сети с использованием A-записи DNS (например, mycomputer.deuby.net), поэтому естественно предположить, что именно так контроллеры домена обнаруживают друг друга для репликации. В конечном итоге так и происходит, но не напрямую. Для целей репликации служба каталогов DC регистрирует идентификатор GUID в DNS как запись CNAME (псевдоним). Этот GUID уникален в лесу. Имя CNAME известно как идентификатор GUID объекта DSA и преобразуется в запись A контроллера домена. Когда служба каталогов на DC пытается обнаружить партнеров репликации, используется полное имя (FQDN) CNAME (например, 802e2778-27d1-49ca-9d12-5c439f4c4d3b._msdcs.deuby.net).

Чтобы найти DC таким же методом, как его находит другой контроллер домена, нужно найти его GUID. Существует несколько способов обнаружить GUID объекта DSA контроллера домена. Один из них — отыскать его в оснастке DNS Management консоли управления MMC в контейнере _msdcs зоны домена. Но этот метод действует, только если GUID корректно зарегистрирован в DNS. Если уверенности в этом нет, есть способ проверить регистрацию, запустив команду

REPADMIN/SHOWREPL

В этой команде dcname представляет имя DC, на котором замечены неполадки с репликацией. GUID объекта DSA — один из первых элементов, получаемых в ответ. Присоедините _msdcs.domain.com к идентификатору GUID, и это будет целевым объектом для проверки связи.

После того как получен GUID объекта DSA, выполните проверку связи с контроллера домена, который получает сообщения об ошибках. Это можно сделать с собственной системы, но при этом в задачу вводится лишняя переменная величина, так как ваш сервер DNS может быть иным, чем у контроллера домена. Если проверка связи не приносит ответа или возникает ошибка «не удается найти узел», проблема репликации, скорее всего, в некорректной регистрации CNAME или записи A. Повторно зарегистрируйте GUID контроллера домена и его записи SRV, выполнив команду NLTEST/DSREGDNS или перезапустив службу NETLOGON.

Важнейшие уровни: состояние и проверка подлинности

Значение проверки состояния операционной системы DC очевидно. AD — приложение, выполняемое поверх (а в случае Windows Server 2008 R2 и Windows Server 2008 — как роль) Windows Server. У диагностики операционной системы на контроллере домена нет никаких уникальных особенностей по сравнению с любой другой прикладной ролью. Но у выделенного DC есть преимущество перед другими прикладными ролями в случаях, когда возникают проблемы операционной системы. Вместо того чтобы тратить время на попытки исправить испорченную операционную систему, можно просто понизить DC или принудительно удалить роль с использованием команды DCPROMO/FORCEREMOVAL. Затем можно быстро восстановить операционную систему и переустановить AD. Часто это самый быстрый способ вернуть контроллеру домена работоспособность.

Аналогично разрешению имен, уровень проверки подлинности модели диагностики AD нельзя назвать программным. Это необходимый компонент AD, который, наряду с прочими функциями, определяет действительные удостоверения контроллеров домена, чтобы обеспечить безопасный обмен данными между ними. Kerberos — используемый протокол безопасности, а центр распространения ключей Kerberos (KDC) — компонент каждого DC. Для тех, кто не знаком с этим протоколом (а его должен знать каждый администратор), в блоге Microsoft Directory Services Team есть полезная статья. Дополнительные сведения можно найти в «Kerberos for the Busy Admin» по адресу bit.ly/egoDj9.

Собственно Kerberos — чрезвычайно надежный компонент AD. Многие отказы, связанные с проверкой подлинности в ходе репликации между DC, вызваны внешними неполадками, в частности временным рассогласованием между компьютерами. Утилита W32TM — основной инструмент для устранения такого рассогласования, что достигается путем управления службой Windows Time. Например, можно выполнить следующие действия, запустив соответствующие команды W32TM:

  • выяснить, когда целевой DC успешно синхронизировал время и с каким сервером: w32tm/query/status;
  • принудительно настроить службу на использование другого DC в домене: w32tm/config/syncfromflags: DOMHIER;
  • заставить службу повторно обнаружить сетевые ресурсы, затем повторно синхронизировать ее с источником времени: w32tm/resync/rediscover.

Если некоторые DC виртуализованы, убедитесь, что они синхронизируют время не со своим хост-компьютером, а с партнерскими контроллерами домена. Дополнительные сведения о диагностике Kerberos можно найти в статье Microsoft «Troubleshooting Kerberos Problems» по адресу technet.microsoft.com/en-us/library/cc786325(WS.10).aspx. Дополнительные сведения о диагностике Kerberos с использованием сетевой трассировки, даже если причина проблемы — в преобразовании имен, приведены в статье «Troubleshooting Kerberos Authentication problems — Name resolution issues» в блоге Microsoft Directory Services Team по адресу bit.ly/i287M3. Статьи по Kerberos есть и на сайте Windows Server 2003 R2 Kerberos Technology Center по адресу bit.ly/9 uNVZc.

Принципы репликации

Чтобы эффективно выполнить диагностику репликации, необходимо познакомиться с ее принципами. Репликация представляет собой процесс пересылки обновлений раздела каталога всем контроллерам домена, имеющим копию этого раздела. Например, если вносится изменение в учетную запись пользователя в домене child1.mycompany.com, в результате репликации это изменение будет передано другим контроллерам домена child1, так как они располагают копией этого раздела домена. Если внести изменение в конфигурацию сайта, для mycompany.com, репликация передаст это изменение всем другим DC леса mycompany.com, так как информация сайта хранится в разделе конфигурации, размещенном на каждом DC леса. Репликация работает с разделами, что затрудняет понимание топологии репликации. Для проведения диагностики важно, что отказ репликации обычно происходит для всех разделов на контроллере домена из-за проблем со вспомогательной инфраструктурой.

Чтобы точно настроить способ репликации между контроллерами домена, нужно подготовить топологию сайтов AD, содержащую контроллеры домена леса. Топология сайтов — сеть, узлами которой являются сайты, а соединениями между узлами — связи сайтов. В основе топологии обычно лежит конфигурация локальной сети и распределенной сети компании. Способ формирования связей репликации можно уточнить, изменив относительную стоимость связей сайтов (какова цена цепи WAN).

Внутри сайта каждый DC использует проверку согласованности знаний (KCC) и знания о конфигурации сайта, хранящиеся в разделе конфигурации, для создания объектов соединения между контроллерами домена. Объекты соединения — пути, по которым объекты AD и атрибуты передаются на другие DC (партнеры репликации) через процесс репликации. Эти объекты соединения — однонаправленные, то есть каждый DC должен иметь по крайней мере один объект входящего соединения, чтобы получать обновления с каждого вышестоящего партнера репликации, и по крайней мере один исходящий объект соединения для каждого нижестоящего партнера.

Репликация с одного DC на другой запускается вышестоящим DC, когда он объявляет партнерам репликации о наличии обновления. DC выдает объявление почти немедленно (в течение 15 секунд).

Точно так же, как контроллеры домена соединены внутри сайта, сайты связаны между собой для репликации объектами соединения. Но способ создания объектов соединения зависит от настройки связей сайтов. Большинство администраторов уменьшают интервал репликации для связей сайтов со 180 (по умолчанию) до 15 минут. Если каждому DC в каждом сайте разрешено выполнять репликацию с каждым другим DC, ситуация быстро выйдет из-под контроля. Поэтому один DC назначается сервером-мостом для каждого раздела каталога в каждом сайте. В большинстве случаев один сервер-мост обслуживает межсайтовую репликацию для всех разделов каталога.

Как внутри, так и между сайтами репликация представляет собой операцию извлечения. Другими словами, DC всегда запрашивает обновления у вышестоящих партнеров, а не передает их принудительно нижестоящим. Поэтому в ходе диагностики следует всегда ориентироваться на объекты и рассматривать обновления как входящие запросы к DC, с которым вы работаете. Исчерпывающая документация по репликации опубликована в статье «How Active Directory Replication Topology Works» по адресу bit.ly/hcbXJT в сети Microsoft TechNet.

Верный выбор инструментов

Освоив основные концепции и убедившись, что базовые компоненты AD работают корректно, можно приступать к выбору инструментов для устранения неполадок репликации. В первую очередь следует запустить DCDIAG на целевом DC для проверки общего состояния. DCDIAG — основная диагностическая утилита для контроллеров домена. По умолчанию она выполняет 27 тестов. Например, на экране 1 показаны результаты неудачного теста Replications для DC с именем GODAN.

 

Экран 1. Результаты выполнения теста Replications инструмента DCDIAG на контроллере домена с именем GODAN

Если в ходе тестов DCDIAG получены предупреждения об отказах, причины которых неочевидны, следует повторно выполнить DCDIAG. Уделите особое внимание тесту, завершившемуся неудачей, и укажите режим отображения всей информации. В данном случае DCDIAG/TEST: Replications/V дает мало полезной информации; однако после повторного запуска теста DCDIAG на исходном DC (Kyoshi) обнаруживается, что служба каталогов не функционирует.

Следующая важная утилита — REPADMIN. Это универсальный набор инструментов репликации. В нем собрано 69 различных команд в трех уровнях сложности, от простых проверок до команд, уничтожающих собственный каталог. Кроме того, синтаксис команд в разных версиях часто немного различается. Знание некоторых сложных команд REPADMIN — обязательное условие для успешной работы со службами каталогов. Получить подробную справку об отдельных командах в Server 2008 R2 и Server 2008 можно с помощью REPADMIN/?: command. В таблице показан список команд REPADMIN. Дополнительные сведе­ния об использовании версии REPADMIN для Windows 2003 можно найти в статье Microsoft «Troubleshooting replication with repadmin» по адресу bit.ly/dJapAF.

 

Таблица. Распространенные команды REPADMIN

Как правило, первой из команд REPADMIN выполняют /SHOWREPL применительно к DC, который не получает обновлений. Результат показан на экране 2. Данные легче проанализировать, если разделить его на секции. В первом разделе, предшествующем пунктирной линии, показана общая информация о DC. В частности, данные показывают, что DC является сервером глобального каталога, и отображается GUID объекта DSA. В следующей секции показан каждый раздел, в формате различающегося имени (DN), размещенный на этом контроллере домена. Кроме того, показан партнер репликации DC (и GUID объекта DSA партнера), а также время последней успешной репликации DC.

 

Экран 2. Результаты выполнения команды REPADMIN /SHOWREPL

Знать, где искать

Причины отказов репликации обычно кроются в отдельных DC. Поэтому если репликация из одного раздела не получается, а из другого выполняется успешно, то, скорее всего, разделы реплицируются из разных контроллеров домена. В данном простом примере неисправность устраняется после перезапуска службы NETLOGON на контроллере KYOSHI. Собрав и изучив подробные сведения о репликации, проведите диагностику от уровня проводов, чтобы исключить наиболее вероятные причины. Дополнительные сведения можно найти на странице репликации рабочей диаграммы Active Directory Troubleshooting в блоке Active Directory Troubleshooting Tips and Tricks.

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

REPADMIN/BRIDGEHEADS *

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

REPADMIN/FAILCACHE FSMO_ISTG:<сайт>

Команда направлена на генерацию межузловой топологии, представленной параметром <сайт>. Также выводится список связей неудачной репликации, обнаруженных KCC. Если причина неполадки в неправильной топологии сайта (например, DC был перемещен в новый сайт, и при этом не был создан объект связи сайта для его соединения с другими сайтами) или если просто меняется местоположение контроллеров домена, команда REPADMIN/KCC заставляет KCC заново рассчитать и создать объекты соединения между контроллерами домена, чтобы не тратить время на ожидание планового запуска.

Приняв меры по устранению неисправности, можно запустить общую репликацию для всех партнеров целевого DC с помощью команды

REPADMIN/SYNCALL

или для определенного партнера и раздела каталога, запустив команду

REPADMIN/REPLICATE <целевойDC>
   <исходныйDC> <раздел каталога>

в которой раздел каталога, например, DC=Deuby, DC=net.

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

REPADMIN/REPLSUMMARY

Таким образом удается получить сводку репликации для всех DC в лесу.

Для более глубокого анализа можно задействовать команду

REPADMIN  *

(вместо использования имени DC). При этом команда REPADMIN, такая как /SHOWREPL, выполняется на каждом DC леса. Тим Спрингстон, инженер по поддержке группы Premier Customer Support Group компании Microsoft, рассказал в своем блоге об использовании параметра /CSV для создания упорядоченного вывода /SHOWREPL *, с помощью которого можно увидеть состояние репликации всех DC в Microsoft Excel (см. статью «Get the Lowdown on your Replication» по адресу bit.ly/ek0 Jic).

Еще один, совсем не технический совет: используйте большую доску для изображения процесса диагностики проблем репликации между несколькими DC или сайтами. Иначе голова закружится от сложности связей между контроллерами доменов, разделами каталога и сайтами.

Наконец, нужно упомянуть о старом инструменте репликации, похоже незаслуженно забытом: REPLMON. Эта утилита, входящая в пакет Windows 2003 и Windows 2000 Support Tools, обеспечивает графическое представление топологии репликации. Ее возможности гораздо уже, чем у REPADMIN, и некоторые функции с Server 2008 R2 и Server 2008 не работают. Но это лучший способ узнать, как контроллеры домена устанавливают соединения друг с другом. Я подготовил небольшую презентацию по REPLMON для знакомства с основными шагами применения утилиты. Для просмотра материала посетите youtu.be/GW2F0IzPblk. Получить Windows Support Tools можно, посетив страницу загрузок Windows Server 2003 Service Pack 2 32-it Support Tools по адресу bit.ly/dFUMzm.

Непрерывная бдительность

Репликация AD — процесс, уязвимый к сбоям. Но в большинстве случаев причиной отказов становится вспомогательный компонент. При возникновении неполадок проверьте базовые элементы AD — физический, сеть, разрешение имен, операционную систему и проверку подлинности, прежде чем уделять время исследованию собственно AD или процесса репликации.

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

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP