Последние 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…
Приведенный LDAP запрос выглядит странно.
Он, конечно, вернет объекты с ObjectCategory NTDS-DSA, но отработает только вторая часть “логического ИЛИ”. Да и в ней зачем то два раза проверяется значение атрибута objectCategory у объекта.
Первая часть “(&(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 и оно одновременно должно удовлетворять двум условиям. Это, насколько я понимаю, вообще никогда не будет истиной, поэтому не понятно зачем оно вообще присутствует в запросе. Можете пояснить?
2ivan
Пояснить почему такой странный запрос не могу. Я его выудил из ldap-трафика. Почему его именно таким сделали без понятия. Вопрос к разработчикам.