Сегодня мы рассмотрим на примерах все параметрых встроенной переменной $AdminSessionADSettings. По умолчанию "видение всего леса" отключено, и область видимости всех командлетов в данном процессе ограничена локальным доменом компьютера. Конфигурационный контроллер домена (ККД) тот же, что ККД, используемый службами Exchange на данном компьютере.
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : False
DefaultScope : asia.company.com
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {}
Попробуем найти всех получателей по имени Петр:
[PS] C:\>get-mailbox petr* | fl Identity
Identity : asia.company.com/Users/Petr Petrov
Identity : asia.company.com/Users/Petr Ivanov
Как видите, все они из текущего домена - Asia. Теперь расширим нашу географию и рассмотрим весь лес:
[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $true
[PS] C:\>get-mailbox petr* | fl Identity
Identity : europe.company.com/Users/Petr Pavlov
Identity : asia.company.com/Users/Petr Petrov
Identity : asia.company.com/Users/Petr Ivanov
В список результатов теперь попал еще один Петр из европейского домена. Вот как выглядят наши настройки в данный момент:
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : True
DefaultScope :
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {}
Теперь снова сузим наше поле зрения до одного домена, но в этот раз выберем другой домен.
[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $false
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : False
DefaultScope : asia.company.com
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {}
[PS] C:\>$AdminSessionADSettings.DefaultScope = "europe.company.com"
Проверим, что теперь мы смотрим только на Европу:
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : False
DefaultScope : europe.company.com
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {}
[PS] C:\>get-mailbox petr* | fl Identity
Identity : europe.company.com/Users/Petr Pavlov
Как и ожидалось, нам вернулся только один объект из текущего домена.
Теперь попробуем более тонкие установки: в список предпочитаемых серверов можно внемти по одному контроллеру домена на каждый домен - при этом все командлеты, выполняюшиеся в данном процессе, будут использовать именно их (когда нужен сервер из специфического домена)
[PS] C:\>$AdminSessionADSettings.PreferredDomainControllers = "dc01.asia.company.com"
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : False
DefaultScope : europe.company.com
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {dc01.asia.company.com}
Аналогично можно установить глобальный каталог:
[PS] C:\>$AdminSessionADSettings.PreferredGlobalCatalog = "dc01.asia.company.com"
[PS] C:\>$AdminSessionADSettings.ViewEntireForest = $true
Эту установку можно проверить, посмотрев на поле OriginatingServer в возвращаемых результатах
[PS] C:\>get-mailbox petr* | fl Identity, originatingserver
Identity : europe.company.com/Users/Petr Pavlov
OriginatingServer : dc01.asia.company.com
Identity : asia.company.com/Users/Petr Petrov
OriginatingServer : dc01.asia.company.com
Identity : aisa.company.com/Users/Petra Ivalov
OriginatingServer : dc01.asia.company.com
И наконец, напоминаю, что с этой встроенной переменной нужно обращаться осторожно, а то можно нечаянно ее уничтожить:
[PS] C:\>$AdminSessionADSettings = $false
[PS] C:\>$AdminSessionADSettings
False
К счастью, с настройками при этом ничего не случилось, и переменную можно вернуть обратно:
[PS] C:\>$AdminSessionADSettings = [Microsoft.Exchange.Data.Directory.AdminSessionADSettings]::Instance
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : True
DefaultScope :
PreferredGlobalCatalog :
ConfigurationDomainController : dc16.asia.company.com
PreferredDomainControllers : {}
Вот и все. Если есть вопросы пишите или оставляйте комментарии.
В Exchange 2000 и 2003 управление получателями осуществлялось с помощью оснастки "Active Directory - пользователи и компьютеры" (ADUC). По умолчанию она подключалась к произвольному контроллеру текущего домена, но можно было также переключиться на любой другой домен, или весь лес (путем подключения к глобальному каталогу). Кроме того, для преодоления эффектов репликации можно было указать конкретный контроллер домена или глобальный каталог. В Exchange 2007 управление получателями убрано из оснастки и интегрировано с другими функциями управления Exchange - как в графической оболочке, так и в командной строке. Естественно, мы хотели сохранить все возможности, описанные выше, и даже расширили их. Сейчас я расскажу, каким образом они реализованы в среде Powershell.
По умолчанию новый экземпляр Powershell так же, как и ADUC, "видит" только получателей текущего домена (контроллер домена выбирается произвольно). Это можно видеть в заголовке окна Powershell - там указано имя текущего компьютера и облать действия (локальный домен). Кстати, при этом имеется в виду локальный домен компьютера, а не пользователя (потому что такущий администратор может быть из другого леса, а управлять мы все же хотим получателями Exchange в этом лесу). Другой, более универсальный способ, состоит в использовании встроенной переменной $AdminSessionADSettings. Рассмотрим ее поподробнее:
[PS] C:\>$AdminSessionADSettings
ViewEntireForest : False [Видеть весь лес - значит использовать Глобальный каталог]
DefaultScope : asia.company.com [Текущая область действия - в данной случае локальный домен]
PreferredGlobalCatalog : [Предпочитаемый глобальный каталог]
ConfigurationDomainController : dc16.asia.company.com [Конфигурационный контроллер домена - вся информация, не относящаяся к получателям идет туда/оттуда]
PreferredDomainControllers : {} [Список предпочитаемых контроллеров домена, не более одного на домен]
Именно путем изменения полей этой переменной администратор и может добиться практически неограниченной гибкости в плане использования серверов Active Directory. Как видите, можно переключаться между режимами "весь лес" и "домен", устанавливать текущий домен, задавать предпочитаемые контроллеры домена и глобальный каталог. Все задачи (командлеты) Exchange будут использовать эти установки (если, конечно, в параметрах самой задачи не будет указано иначе). Эти установки действуют в рамках одного процесса Powershell. Все они доступны и в графической оболочке EMC.
Как результат, по умолчанию - даже без настроек специфических контроллеров домена - администратор может практически позабыть о репликации при выполнении последовательности действий - например, он может создать нового получателя и тут же изменить настройки или удалить его. Если действие происходит в том же процессе Powershell или EMC, будет автоматически выбран тот же контроллер домена, что был использован при создании объекта.
В следующем сообщении я поподробнее рассмотрю функциональность всех полей на примерах.
Как известно, любую запись в Active Directory можно найти по ее различающемуся имени (DN) или уникальному GUIDу.Существует немалое количество популярных записей, часто используемых приложениями - например, контейнер CN=Computers,DC=BQSNLF-dom,DC=com. Часто при написании приложений люди "строят" такие адреса путем конкатенации различающегося имени домена и фиксированной строки типа "CN=Computers," + <domain DN>. Этот способ работает почит всегда. Но Active Directory позволяет переименовывать или переносить некоторые из этих контейнеров, и тогда приложение перестает работать.
Для того, чтобы приложение могло по-прежнему находить перенесенный контейнер, в Active Directory существует механизм специальных указателей, так называемых "известных объектов" (well-known objects). Эти указатели "живут" в атрибутах wellKnownObjects и otherWellKnownObjects на фиксированных объектах (типа домена или конфигурационного контейнера), и представляют собой комбинацию из GUID и различающегося имени. Вот, например, как выглядит такой указатель на контейнер Computers:
Dn: DC=BQSNLF-dom,DC=com
1> wellKnownObjects: B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=BQSNLF-dom,DC=com;
Для того, чтобы гарантированно найти этот контейнер, нужно выполнить следующий запрос в Active Directory: <WKGUID=AA312825768811D1ADED00C04FD8D5CD,DC=BQSNLF-dom,DC=com>.
Как видите, это не совсем стандартное различающееся имя. Префикс WKGUID говорит о том, что необходимо заглянуть в специальные атрибуты-указатели; далее идет значение GUID, соответствующее контейнеру Computers (этот GUID был выбран разработчиками этого контейнера), а далее идет различающееся имя объекта, на котором эти атрибуты-указатели хранятся.
При этом если контейнер будет переименован или перемещен, то этот "указатель" автоматически обновится и WKGUID-запрос его легко найдет.
Данный механизм используется в Exchаnge 2007 для нахождения Универсальных групп, существующих в единственном экземпляре. По умолчанию эти группы создаются на этапе подготовки леса в корневом домене. Но поскольку некоторые администраторы Exchange стремятся держать корневой домен "в чистоте" (а некоторые вообще блокируют к нему доступ), то мы поддерживаем перемещение этих групп в другой домен. Указатели на эти группы зранятся в атрибуте otherWellKnownObjects на контейнере Microsoft Exchange:
Dn: CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=BQSNLF-dom,DC=com
5> otherWellKnownObjects:
B:32:9C5B963F67F14A4B936CB8EFB19C4784:CN=ExchangeLegacyInterop,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:DC1301662F547445B9C490A52961F8FC:CN=Exchange View-Only Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:0BD898D939081042B77BF4A555E07FA1:CN=Exchange Recipient Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:354B603D92D95541AAFD8C0AE688EA0F:CN=Exchange Organization Administrators,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
B:32:A7D2016C83F003458132789EEB127B84:CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=BQSNLF-dom,DC=com;
Соответственно, для того, чтобы гарантированно найти, скажем, группу Exchange Organization Administrators, необходимо выполнить такой запрос (GUID этот одинаков для всех инсталляций Exchange):
<WKGUID=354B603D92D95541AAFD8C0AE688EA0F,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=BQSNLF-dom,DC=com>
Так и поступают все компоненты Exchange 2007. Я рекомендую использовать этот способ при написании приложений, которые должны надежно работать с Exchange 2007 (или просто приложений для Active Directory).
Сегодня получил такое письмо и решил заодно опубликовать свой ответ:
Здравствуйте.
Вы как разработчик Exchange надеюсь сможете мне помочь.
У меня возникла следующая проблема.
При добавлении/удалении ролей, а также при запуске setup.exe c любыми из ключей /PrepareAD /PrepareLegacyExchangePermissions /PrepareSchema возникает ошибка:
Setup cannot use domain controller 's-dc1.xxxxxxxx.RU' because an override is set in the registry. Run Setup again, and specify '/DomainController:'.
Ничего не могу сделать с Exchange, ни удалить, ни переустановить.
Где отыскать это переопределение (override in the registry)?
В Exchange можно задать статический список контроллеров домена/глобальных каталогов. Он хранится в регистратуре, но имеется и нормальный "человеческий" доступ к этим данным. Вот как их можно посмотреть:
[PS] D:\>get-exchangeserver -status | fl Name, Static*
Name : 4367R9-A15
StaticDomainControllers : {}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
В данном случае у меня нет никаких статических серверов. Вот как их можно установить:
[PS] D:\>Set-ExchangeServer 4367R9-a15 -StaticDomainControllers hp643453.JXNLDW-dom.com
Посмотрим, что получилось:
[PS] D:\>get-exchangeserver -status | fl Name, Static*
Name : 4367R9-A15
StaticDomainControllers : {hp643453.JXNLDW-dom.com}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
Теперь уберем статическую конфигурацию и разрешим Exchange самому выбирать контроллеры домена и глобальные каталоги:
[PS] D:\>Set-ExchangeServer 4367R9-a15 -StaticDomainControllers $null
Проверим, что все чисто:
[PS] D:\>get-exchangeserver -status | fl Name, Static*
Name : 4367R9-A15
StaticDomainControllers : {}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
Перед запуском программы установки Exchange для удаления или модификации ролей необходимо очистить всю статическую конфигурацию. Это нужно для того, чтобы программа установки могла выбирать контроллеры домена по своему усмотрению (например, schema master если указан ключ /PrepareSchema).
Статические списки серверов имеет смысл использовать только для выяснения причин неполадок или чтобы временно избежать использования перегруженных или неисправных серверов. Я не рекомендую иметь эти списки на постоянной основе, так как они уменьшают живучесть Exchange в случае, если сервера из этого списка вдруг станут недоступны. А если у вас в реестре прописан конфигурационный контроллер домена (StaticConfigDomainController), то если по каким-то причинам пропадет связь с ним, Exchange перестанет функционировать. (В обычных условиях, когда ничего нигде не прописано, будет случайно выбран другой работающий контроллер домена и ничего страшного не произойдет).
Кстати, эти настройки существуют начиная с Exchange 2000.
P.S. Оказалось что установка всех статических серверов в $null проблемы не решила. Дело в том, что при этом ключ в реестре не удаляется (а только очищается его значение). ExBPA этого не понимает и считает, что ститческий сервер по-прежнему там. Это уже исправлено в первом Сервис Паке к Exchange 2007. В краткосрочной перспективе можно просто удалить значение HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Instance0\ConfigDCHostName из реестра (чтобы его вообще не было, даже пустого). То, что значение пустое, видно, кстати, из сообщения об ошибке, упомянутого выше: '/DomainController:'. Если бы в реестре был "настоящий" контроллер домена, то ошибка бы содержала это имя: '/DomainController:dcname.corp.com', и тогда запуск программы установки с таким ключом прошел бы успешно.
Рад сообщить, что Exchange 2007 будет полностью русифицирован. То есть не только OWA, но и административная консоль будет "говорить" по-русски. Но самое главное - документация тоже будет переведена на русский! Её очень много, так что, наверное, переведут не все, но я надеюсь, что самое интересное будет доступно на русском языке уже к Новому году.
Сегодня я расскажу про права доступа, используемые службами Exchange 2000 и 2003, почему они такие и к каким последствиям это приводит (а в следующий раз – про то, чем в этом плане отличается Exchange 2007).
Все службы Exchange 2000 и 2003 используют учетную запись компьютера, на котором они запущены (“local system”). Альтернативой этому мог бы быть какой-нибудь специально созданный пользователь (такую схему использует, например, Live Communication Server), но у пользователя есть существенный минус – ему нужен пароль, который периодически надо обновлять. Если забыть это сделать, все службы перестанут работать. Администраторы не любят этого, поэтому Exchange использует учетную запись local system, которая не требует поддержки.
Дизайн прав доступа был прост: все сервера в лесу Active Directory равноправны, они будут членами одной группы, и программа установки Exchange даст этой группе права на все необходимые ресурсы. Так, в общем, и сделали.
Главной проблемой такого дизайна был тот факт, что Exchange 2000 должен был работать в «смешанном режиме» (mixed mode) в лесу, содержащем Windows NT4. В такой конфигурации Универсальные группы, которые идеально подходили под решение этой задачи, недоступны (нужен «основной режим» (native mode) Windows 2000). В смешанном режиме есть два варианта:
- Локальные группы (domain local): они могут иметь членов из разных доменов, но все эти члены видимы только внутри данного домена
- Глобальные группы (global): они могут иметь членов только из своего домена, зато все они видимы из любого домена.
Естественно, ни одна из этих групп не подходит для решения данной задачи. В результате Exchange 2000/2003 создает две группы в каждом домене (куда устанавливается Exchange):
- глобальная группа Exchange Domain Servers (EDS), членами которой являются все сервера Exchange данного домена.
- локальная группа Exchange Enterprise Servers (EES), членами которой являются все группы EDS из всех доменов.
Все доменные ресурсы в Active Directory (учетные записи пользователей, групп и т.д.) разрешают доступ группе EES – таким образом, это достаточно сделать всего один раз, при установке первого сервера Exchange 2000/2003.
Все конфигурационные ресурсы (все, что находится под CN=Configuration,DC=domain,DC=com) разрешают доступ каждой группе EDS по отдельности - таким образом, это делается один раз на домен. Но это не так и плохо, поскольку копия конфигурационного контекста именования (naming context) имеется на каждом контроллере домена и программа установки делает это легко. Членство групп EES в других доменах поддерживает служба обновления пользователей (Recipient Update Service - RUS).
Когда служба старует, она имеет в своем токене SID обеих групп из своего домена: EDS и EES. Когда сервер попытается считать объект в контексте домена, контроллер домена или глобальный каталог сравнит ACL на этом объекте с токеном службы, найдет ACE для группы EES, а также соответствующий SID в токене, и доступ будет разрешен.
Эта схема работает также и для нескольких доменов. Представим себе, что у нас есть два домена: P (Parent - родительский) и C (child – дочерний). Там будут существовать следующие группы:
Родительский домен (P):
Exchange Domain Servers (EDS-P), включающая сервера Exchange из родительского домена
Exchange Enterprise Servers (EES-P), включающая EDS-P и EDS-C, чтобы сервера Exchange из дочернего домена имели доступ к ресурсам родительского домена
Дочерний домен (С):
Exchange Domain Servers (EDS-C), включающая сервера Exchange из дочернего домена
Exchange Enterprise Servers (EES-C), включающая EDS-P и EDS-C, чтобы сервера Exchange из родительского домена имели доступ к ресурсам дочернего домена
Теперь если сервер Exchange из родительского домена попытается считать объект с глобального каталога в дочернем домене, то он сможет это сделать, поскольку на объекте будет ACE с группой EES-С, и глобальный каталог знает, что эта группа включает в себя EDS-P, которая и есть у нас в токене.
Но есть одно «но». J Представим себе, что служба Exchange 2000 пытается прочитать объект с глобального каталога, находящегося в другом домене. Но объект, который мы хотим прочитать, живет в нашем домене (мы вполне можем это сделать, глобальный каталог имеет копии объектов со всего леса). Посмотрим, что произойдет в этом случае.
Следует заметить, что при «разговоре» с ГК из другого домена из нашего токена исчезнет локальная группа EES-P (в силу своей локальности). В нашем токене останется только SID группы EDS-P. Теперь ГК прочитает ACE, обнаружит там группу EES-P, но, в отличие от предыдущего случая, он не сможет узнать, что она содержит EDS-P, поскольку она живет в другом домене. Результат: все дополнительные права, которые Exchange себе дает, не действуеют при считывании объектов из нашего домена с глобального каталога, живущего в другом домене. На самом деле все не так плохо, это касается всего нескольких атрибутов, которые не являются доступными по умолчанию.
Чтобы обойти это ограничение, группы EDS являются членами пред-Windows2000 группы (pre-windows2000 compatibility group), которой даются права на чтение всех атрибутов.
Поздравляю! Уважаемый читатель блога, вы прошли тест на техническую любопытность и внимательность :)
На самом деле данный пост - это приглашение на Первое собрание участников и читателей blogs.technet.com! И Вы, как один из самых внимательных, приглашены на это мероприятие! (приглашение опубликовано только в блогах, так что должны собраться все свои :))
Собрание состоится 08.09.2006 в 18:00 в московском офисе Microsoft
Подробнее - тут: http://blogs.technet.com/renatmin/archive/2006/08/29/452472.aspx
Ура! Начиная с сегодняшнего дня можно скачать (или заказать DVD) Exchange 2007 Beta 2.
http://www.microsoft.com/technet/prodtechnol/exchange/2007/downloads/beta.mspx?wt.mc_ID=MarTopStory
Русский язык полностью поддерживается в OWA, но русской голосовой поддержки в unified messaging, а также русского интерфейса для админинстрирования пока нет.
Рекомендую всем попробовать эту Бету! Все, чего только может пожелать администратор, доступно из командной строки powershell. Это просто чудо :)
В ближайшее время планирую написать о правах доступа в Exchange 2007 и как они отличаются (в лучшую сторону) от Exchange 2003.
Как известно, Exchange 2000 и 2003 имеют загадочную службу Recipient Update Service (которая выполняет массу функций, не обязательно относящихся к получателям электроной почты), а программа установки имеет опцию"подготовить домен" (DomainPrep).
Какие именно домены нужно "подготавливать". Ну во-первых, естественно, все домены, где будет установлен Exchange. Во-вторых, все домены, где "живут" учетные записи будущих счастливых обладателей почтовых ящиков Exchange. В-третьих (и это не совсем очевидно), если в вашей топологии есть всего один глобальный каталог, то надо "подготовить" и тот домен, в котором этот глобальный каталог находится. При этом надо сконфигурировать Recipient Update Service и "направить" его на этот глобальный каталог.
Причина этого проста - DSAccess будет "иметь дело" только с глобальными каталогами, на которых у него (т.е. у группы Exchange Domain Servers/Exchange Enterprise Servers) есть право читать SACL (что отражено в событии 2080), а это право обеспечивается службой Recipient Update Service (которая, в свою очередь, нуждается в предварительной "подготовке" домена программой установки.
То же самое можно сделать и просто с целью увеличить количество глобальных каталогов, доступных Exchange (если их несколько в топологии), посколько недоступность глобального каталога означает полную остановку Exchange. Например, все есть смысл таким образом "подготовить" все домены, содержащие глобальные каталоги, находящиеся в том же сайте, что Exchange.
Практически все настройки Exchange хранятся в Active Directory. Благодаря этому администрирование сервера можно производить с любого компьютера, где тоже имеется Exchange. Но это удобство имеет и обратную сторону: если Exchange читает данные с одного контроллера домена, а изменения производились на другом, то неизвестно, когда эти изменения реально начнут действовать.
Например, если администратор создает новую базу данных (Mailbox database), он наверняка захочет тут же ее использовать - но как это сделать, если сервер еще не знает об этом?
Вот какие механизмы существуют в Exchange 2000/2003 для смягчения негативных последствий репликации. (В Exchange 2007 по большому счету все работает примерно так же):
1. Общий Конфигурационный контроллер домена. В любой момент времени все без исключения службы Exchange читают и сохраняют свои конфигурационые данные с одного и того же сервера, называемого Конфигурационным контроллером домена (Config DC, или ККД). Под конфигурацией здесь понимается все, что хранится в разделе CN=Configuration,DC=<rootDomain>,DC=com.
Поскольку абсолютно все контроллеры домена имеют реплику (копию) этого раздела, компонент DSAccess всегда выбирает ККД из контроллеров домена, находяшихся поближе к Exchange вне зависимости от домена. Результат выбора сообщается регулярно в событии 2080, о котором я говорил ранее.
Если ККД по какой-то причине становится недоступным, то DSAccess выбирает другой DC, и все службы одновременно переключаются на него.
Наличие одного ККД для всех служб позволяет всем компонентам Exchange иметь целостное видение конфигурации. При необходимости в реестре можно "насильно" установить ККД, но это рекомендуется делать лишь кратковременно, поскольку если этот сервер вдруг станет недоступен, то DSAccess не сможет нарушить "приказ" и найти другой ККД.
2. Администрирование с помощью ККД. Exchange System Manager может удаленно администрировать любой Exchange сервер, так как в большинстве случаев администрирование - это просто работа с данными в Active Directory. Но чтобу изменения моментально начинали действовать, ESM выясняет у удаленного сервера, какой ККД тот использует, и шлет все изменения туда. А поскольку большинство служб Exchange отслеживает изменения конфигурации (именно на ККД), то создается эффект мнговенности данной операции.
3. ККД и установка Exchange. Установка - экстремальный случай администрирования :) Очевидно, когда службы стартуют в первый раз, им очень важно прочитать настройки с правильного DC. Для этого программа установки Exchange "говорит" DSAccess какой ККД нужно использовать сразу после старта службы System Attendant. Это значение сохраняется в течение 8 часов, что более чем достаточно для репликации. Но если остановить службы (или рестартовать сервер) сразу после установки, что это значение будет утеряно и придется ждать, пока репликация завершится.
Кстати, ККД и в обычном режиме меняется каждые 8 часов, чтобы распреедлить нагрузку между контроллерами доменов более равномерно.
4. Конфигурация пользователей и почтовых ящиков. (Тут я не могу подобрать правильные термины, я имею в виду Mail Recipients/Mailboxes. Кто знает - подскажите!) Эти данные не хранятся на ККД, и считываются с глобальных каталогов. Exchange одновременно использует до 10 глобальных каталогов, поэтому точно сказать, откуда будут считаны данные, нельзя. Кроме того, данные о пользователях кэшируются на двух уровнях - Information Store и DSAccess, и уведомлений об изменениях для этих данных тоже нет. Поэтому "мгновенные" изменения пользовательских данных практически невозможны.
Exchange System Manager на вкладке DSAccess содержит полные списки серверов, использующихся в настояще время.
В разделе "полезные советы" я буду давать простые рекомендации, основанные на многолетнем опыте :) Хотя я сам не занимаюсь поддержкой, но в критических ситуациях, или при установке в Майкрософтовской сети, дело доходит и до нас, разработчиков, я мне много чего довелось повидать :)
Итак, совет номер один:
По умолчанию уровень ведения журналов (eventlog) для службы MSExchangeDSAccess установлен в None. При этом в журнал записываются только критические события. Я рекомендую установить уровень ведения журналов для категории Topology в Minimum. Это приведет к тому, что каждые 15 минут в журнале приложений будет появляться событие под номером 2080. (Оно подробно описано в статье, упомянутой в предыдущей заметке). Там вы увидите, какие глобальные каталоги и контроллеры домена (GC и DC) использует Exchange сервер, а какие - нет. А главное, проанализировав это сообщение, будет понятно, почему это так происходит.
Это особенно полезно если вы только что установили Exchange сервер в топологию с несколькими доменами или сайтами - в этом случае не помешает проверить ваши предположения о том, какие контроллеры домена выбрал и использует Exchange.
Да и в стабильной топологии полезно иметь такие события каждые 15 минут - если что-то вдруг перестанет работать или станет работать плохо, можно по истории этих событий попытаться восстановить картину происходящего. Наш Майкрософтовский отдел IT с цифрами в руках доказал, что на этом можно сэкономить массу времени, и в Exchange 2007 по умолчанию категория Topology имеет уровень Minimum. Что и рекомендую сделать в Exchange 2000 и 2003.
Для обеспечения бесперебойной и работы и хорошей производительности Exchange очень полезно понимать куда, как и когда Exchange шлет свои многочисленные LDAP-запросы. На хорошо загруженном сервере можно увидеть 30-60 запросов в секунду. Естественно, если возникают какие-то проблемы в сети или на контроллерах доменов, это не замедлит отразиться на деятельности всех без исключения компонентах Exchange.
Для начала я предлагаю почитать очень хорошую статью, освещающую DSAccess - библиотеку, с помощью которой почти все службы Exchange взаимодействуют со службой каталогов Active Directory. Не уверен насчет правильной терминологии, но по сути дела в ней много полезных вещей.
http://old.osp.ru/win2000/exchange/49exch10.htm
Статья относится к Exchange 2000 Service Pack 2, но вся информация, изложенная в ней,относится и к последующим пакетам обновлений, а также Exchange 2003. Не знаю, сколько будет действовать эта ссылка, я обнаружил, что эта статья уже переехала как минимум один раз. Так что рекомендую скопировать локально на всякий случай :)
По большому счету, главное для нормальной работы - это обеcпечить достаточное количество серверов глобального каталога (GC) в непосредственной близости от Exchange (в том же сайте). Чем больше Exchange-серверов, там больше серверов GC должно быть доступно - как для правильного распределения нагрузки, так и для обеспечения нормального функционирования в случае недоступности одного или нескольких GC.
А вот устанавливать Exchange на контроллер домена или сервер глобального каталога в большой организации не рекомендуется - Exchange и сам способен загрузить память, процессор и диск компьютера, а Active Directory добавит дополнительную нагрузку. Такой совмещенный вариант подходит разве что для Small Business Server, когда загруженность сервера минимальная.
Меня зовут Владимир Гребеник, я работаю в группе Exchange около 7 лет, занимаюсь разработкой всего, что связано с взаимодействием Exchange и Active Directory. Здесь я планирую делиться разными интересными (и, надеюсь, полезными) деталями о неочевидных, недостаточно документированных и просто интересных вещах об Exchange в сфере моей деятельности. И вообще всем, что покажется интересным!
