Последние 5 лет с завидной периодичностью встречаю вопросы может ли Exchange использовать RODC (Read-Only Domain Controller) и, в частности, ROGC – RODC, которые содержат глобальный каталог. Ответ на этот вопрос уже давно дан:

  • Нет, Exchange не может использовать RODC/ROGC
  • Нет, Exchange не запустится в том сайте, где находятся только RODC/ROGC
  • Да, нужен полноценный контроллер домена, с правом на запись

Следующий вопрос, который может возникнуть – а почему нельзя использовать RODC/ROGC?

Здесь немного придётся погрузиться в историю. Exchange 2000/2003 использовал специальный компонент DSAccess, который отвечал за доступ к Active Directory (чтение конфигурации, внесение изменений итд). Кроме этого, DSAccess отвечал за составление списка контроллеров домена и серверов глобального каталога, который мог бы в дальнейшем использовать Exchange. Механизм построения списка выглядел следующим образом:

  • DSAccess обращался к DS Locator Service
  • Через него (через ldap-запрос к разделу конфигурации) получал список DC и GC локального сайта AD, в котором находился сервер Exchange
  • Пытался подключиться к каждому из серверов из полученного списка
  • Кешировал 10 доступных DC и 10 доступных GC
  • Перестраивал список таким образом, что в верх списка попадали GC, из того же домена, членом которого являлся сервер Exchange

Отсюда следуют достаточно очевидные выводы:

  • Как минимум один GC должен находиться в сайте, где расположен сервер Exchange
  • GC должен находиться достаточно близко к серверу Exchange. Если имеются две физические локации в одном сайте, то лучше бы сервер GC разместить в той же локации, где находится сервер Exchange
  • Для обеспечения высокой доступности имеет смысл держать 2 или больше GC в сайте, где находится сервер Exchange

В Excahnge 2007 компонент разбили на две части – AD Provider и AD Driver (оба работают в рамках одного сервиса – Active Directory Topology). Функциональность не изменилась. Они так же отвечали за работу с Active Directory. AD Provider отвечал за обращение к AD и поддержку работы кэша (с результатом обращений к AD). AD Driver отвечал за построение топологии DC.

Возвращаясь к нашему вопросу про ROGC. И AD Provider и DSAccess получают список контроллеров домена (включая GC) через специальный ldap-запрос в контейнере с сайтами в разделе конфигурации (CN=Sites,CN=Configuration,DC=domain, DC=local). Запрос для Exchange 2010 выглядит следующим образом:

(|(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=domain,DC=local))
(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)))

Если внимательно посмотреть, то запрос возвращает только объекты, которые являются экземплярами класса NTDS-DSA (который представляет DSA на конкретном контроллере домена). И тут есть небольшая тонкость. RODC представлены другим классом – NTDS-DSA-RO, а следовательно, в процессе запроса списка контроллеров домена в этот список не попадают. То есть, Exchange вообще ничего не знает про контроллеры домена только для чтения. А следовательно, пользоваться RODC/ROGC в качестве контроллеров домена не умеет (что не исключает возможности их использования в качестве серверов DNS, например).

Полезные ссылки:
How DSAccess Builds the List of Cached Servers
Exchange 2000 SP2’s DSAccess Component
The AD Administrator’s Guide to Exchange 2007
AD Integration – from 2003 to 2007….
Windows 2008 Read Only Domain Controllers and Exchange 2007…