Подробное рассмотрение подготовки Active Directory для Exchange 2007

Прежде чем углубиться в суть вопроса и начать установку Exchange 2007, нужно уделить некоторое время пониманию шагов, которые требуются для подготовки среды Active Directory к получению Exchange 2007. В этом цикле статей, состоящем из четырех частей, мы подробно рассмотрим эти подготовительные шаги, а также, что более важно, мы рассмотрим инструменты и процессы, которые можно использовать для определения успешности или безуспешности выполнения этих шагов.

Прежде чем продолжать наш разговор, есть пара моментов, которые нужно обсудить. Одним из моментов, о котором, я уверен, вы все уже должны были слышать, заключается в том, что Exchange 2007 поддерживается только на 64-разрядном оборудовании. Вы наверняка также слышали о том, что существует 32-разрядная версия Exchange 2007, которая может использоваться в непроизводственных и тестовых средах. Как мы выясним позже, некоторые из команд, необходимых для подготовки Active Directory к установке Exchange 2007, должны выполняться на определенных серверах, которые, как правило, не являются серверами Exchange 2007 и поэтому могут быть запущены на 32-разрядном оборудовании. Если это именно тот случай и если известно, что Exchange 2007 не поддерживается на 32-разрядном оборудовании, как эти команды могут выполняться с полной поддержкой от Microsoft? В этих случаях следует знать о том, что Microsoft поддерживает использование 32-разрядной версии Exchange 2007 для выполнения определенных задач по подготовке Active Directory, таких как расширение схемы. Помня об этом, необходимо убедиться, что под рукой есть копия 32-разрядной версии Exchange 2007, если, скажем, ваша среда оснащена лишь 32-разрядными контроллерами домена.

По мере прочтения этой статьи вы также увидите, что есть возможность выполнять пропущенные ранее процессы с помощью процессов, которые вы выполняете позже. К примеру, если вы сначала забыли подготовить наследственные разрешения, этот шаг будет автоматически выполнен во время обновления схемы. Возникает вполне закономерный вопрос, зачем выполнять все шаги по отдельности, когда их количество можно сократить? Лично я предпочитаю выполнять каждый шаг по отдельности, потому что можно проверять каждый шаг по мере его выполнения, убеждаясь, что каждый процесс завершен корректно, а также исправляя все возможные ошибки. К тому же, поскольку некоторые шаги требуют разрешений различного уровня, можно выполнять каждый шаг с минимальным количеством требуемых разрешений, а это очень удобно в больших и более защищенных средах.

Давайте рассмотрим примерную среду, которую я создал для этой статьи. Среда состоит из пустого корневого домена в лесу, neilhobson.com, и единственного дочернего домена, sales.neilhobson.com. Дочерний домен содержит сервер Exchange 2003 и связанные пользовательские учетные записи, которые имеют почтовые ящики на этом сервере Exchange 2003. Новый сервер Windows 2003 был установлен в этом дочернем домене, и он станет первым сервером Exchange 2007, установленным в этой конкретной организации.

Подготовительные команды

Если вам необходимо подтвердить различные параметры установки в любое время, нужно лишь выполнить следующую команду из файлов источника Exchange:

setup.com /help:PrepareTopology

Результаты команды показаны на рисунке 1; это те команды, которые мы будем рассматривать в рамках статьи. Обратите внимание, что опция для всех переключателей использует определенный контроллер домена при необходимости.

Помня эти команды, давайте рассмотрим их подробно.

Подготовка наследственных разрешений (Legacy Permissions)

Во-первых, нужно определить, устанавливается ли инфраструктура Exchange 2007 в уже существующую организацию Exchange 2000 или Exchange 2003. Если да, то нужно подготовить наследственные разрешения. Причина тому, в основном, заключается в службе обновления получателя (Recipient Update Service - RUS), использующейся в Exchange 2000 и Exchange 2003. Я уверен, что вы знаете, для чего используется служба RUS, и поэтому я не буду вдаваться в подробности, однако если вы не знакомы с этой службой, то можете прочитать статью Марка Фугата или Родни Бьюика по данной теме. Из-за изменений в Exchange 2007 служба RUS не имеет необходимых разрешений для обновления почтовых атрибутов, принадлежащих пользователям, а процесс, описанный в данном разделе, позволяет исправить эту проблему.

Для подготовки наследственных разрешений нужно использовать следующую команду:

setup /PrepareLegacyExchangePermissions

Это довольно длинный набор символов, и есть вероятность допустить опечатку. К счастью, можно получить такой же результат, используя более короткую команду. Не знаю как вы, но если у меня появляется возможность сократить время работы на клавиатуре и, тем самым, исключить возможность опечатки, я ею пользуюсь. Поэтому в данной статье я буду использовать укороченный вариант команды, который выглядит следующим образом:

setup /pl

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

setup /pl:<FQDN домена>

Например, если нужно обновить только домен sales.neilhobson.com, то используется команда:

setup /pl:sales.neilhobson.com

Если вы обновляете один домен, то учетная запись, от имени которой вы запускаете эту команду, должна принадлежать к группе администраторов домена в соответственном домене, при этом ей должна быть делегирована роль Exchange Full Administrator. Для тех, кому придется работать с несколькими доменами, содержащими более ранние версии серверов Exchange, есть дополнительные моменты, которые стоит принять во внимание и которых нужно остерегаться. Если у вас есть несколько доменов, содержащих Exchange 2000 или Exchange 2003 серверы, то вам сначала придется выполнить процесс Exchange 2000 или Exchange 2003 DomainPrep в каждом из этих доменов. Именно в этих доменах процесс наследственных разрешений должен выполнить свою работу, в результате чего сервер, на котором выполнена команда setup /pl, сможет связываться с каждым из этих доменов. Чтобы корректно выполнить команду, используемая для этого учетная запись должна быть членом группы Enterprise Admins.

В моей тестовой среде, я собираюсь выполнить команду setup /pl с только что установленного сервера AD-CHE2K7. Результаты этого показаны на рисунке 2.

Как видно на рисунке 2, проверки организации выполняются до того, как действительные разрешения назначены. Эти проверки позволяют убедиться в том, что разрешения могут быть назначены, а все, что препятствует этому процессу, будет отображено на экране. На рисунке 2 видно, что были выделены три проблемы:

• Рекомендуется установить .NET Framework 2.0 SP1; это лишь рекомендация, поэтому вы можете продолжить процесс без установки этого компонента. Однако лучше все же следовать таким рекомендациям компании Microsoft как эта.
• Наследственная организация Exchange находится не в собственном (native) режиме, что препятствует применению наследственных разрешений Exchange. Это одно из главных требований к наследственной среде перед установкой Exchange 2007, поэтому убедитесь, что переключились на собственный режим, прежде чем пытаться назначить разрешения.
• Наконец, обратите внимание на информацию, говорящую о том, что используемая мною учетная запись не является членом группы Enterprise Admins, что в данном случае является требованием, так как я говорил, что хочу обновить все домены, а не какой-то конкретный домен.

Заключение

На этом закончим первую часть цикла статей. Здесь я рассказал о базовых требованиях для запуска команды, которая подготавливает наследственные разрешения Exchange. Мы также рассмотрели несколько распространенных проблем, с которыми можно столкнуться. Во второй части мы закончим рассмотрение подготовки наследственных разрешений, включая осмотр логов установки, а также другие способы определения успешности процесса, помимо логов.

В первой части этого цикла статей мы начали наше рассмотрение с четырех шагов, необходимых для подготовки Active Directory к получению Exchange 2007. Первым шагом была подготовка наследственных Exchange разрешений в ситуациях, когда в вашей организации новая версия сосуществует с более старыми версиями Exchange, такими как Exchange 2000 или Exchange 2003. В первой части мы лишь запустили команду setup /pl, чтобы познакомится с некоторыми проблемами, нуждающимися в решении до того, как процесс будет продолжен. Эти проблемы были представлены нам в окне командной строки, однако, как вы вскоре увидите, существуют другие способы просмотра того, что произошло во время выполнения этих подготовительных команд.

Установка файлов логов

Как и в случае с прочими подготовительными процессами, которые мы рассмотрим в этой статье, будут создаваться файлы журналов регистрации событий, которые можно просматривать по завершении процесса на предмет возникновения ошибок. Нужный нам файл – это ExchangeSetup.log, созданный в папке C:\ExchangeSetupLogs, как показано на рисунке 3.

Если открыть файл ExchangeSetup.log в блокноте у вас появятся те же ошибки и предупреждения в виде текстового файла, которые вы видели в окне командной строки первой части этой серии статей. Эти ошибки выделены на рисунке 4:

Вы должны заметить, что некоторые ошибки «скрывают» другие ошибки, которые могут наличествовать в вашей наследственной организации Exchange. Например, когда я добавил учетную запись, которую использовал для группы Enterprise Admins и переключил наследственную организацию Exchange в собственный режим, повторный запуск команды setup /pl произвел новую ошибку, показанную на рисунке 5. Здесь говорится, что на один или более серверов Exchange 2003 в наследственной среде не установлен Exchange 2003 Service Pack 2. Мораль сего рассказа заключается в том, что необходимо убедиться, что вы полностью задокументировали свою наследственную среду Exchange и исправили все проблемы, которые могут препятствовать подготовке наследственных разрешений, до выполнения этой команды. Если этого не сделать, то вам придется выполнять эту команду много раз, пока все необходимые моменты не будут выполнены.

В конце концов, процесс выполнения команды setup /pl должен завершиться успешно, как показано на рисунке 6, однако в этом конкретном случае следует обратить внимание, что предупреждение относительно .NET Framework 2.0 SP1 все еще присутствует, что в очередной раз подтверждает тот факт, что предупреждения на самом деле не препятствуют продолжению процесса.

Осмотр списка разрешений

Так как же убедиться в том, что подготовка наследственных разрешений завершилась успешно? Во-первых, нужно помнить, что журналы регистрации событий являются здесь вашими друзьями, как уже отмечалось в первой части. Сначала нужно просмотреть файл ExchangeSetup.log и убедиться, что процесс был завершен без ошибок.

Далее, обратите внимание, что в документации Microsoft приведена подробная информация о записях контроля доступа (Access Control Entries – ACEs), которые генерируются этим процессом. Остается вопрос о том, как определить, были ли добавлены эти ACEs. Давайте более подробно рассмотрим файл ExchangeSetup.log, созданный во время установки наследственных разрешений Exchange. На рисунке 7 приведен отрывок. Обратите внимание, что я установил в блокноте опцию переноса по словам Word Wrap, чтобы все записи журнала были видны полностью.

На рисунке 7 показаны различные ACEs, которые были применены. Если рассматривать первую запись в списке, то видно, что WriteProperty ACE была добавлена к самому домену (DC=neilhobson,DC=com). Также интересным является Globally Unique Identifier (GUID), который показан в конце записи. Этот GUID имеет следующее значение 1f298a89-de98-47b8-b5cd-572ad53d267e. Если вы посмотрите ниже в журнале регистрации, то увидите, что ReadProperty и WriteProperty ACE были применены к объекту AdminSDHolder.

Компания Microsoft подробно описывала в различных статьях способы подтверждения того, что эти ACEs существуют, поэтому для полноты статьи я опишу этот процесс здесь, чтобы продемонстрировать на примере моей тестовой среды, что делать. Вы можете воспользоваться инструментом LDP, который идет как часть Windows Support Tools для проверки ACEs, которые были добавлены процессом подготовки наследственных разрешений. Я не буду рассматривать все ACEs, которые были добавлены, я сконцентрируюсь на двух из них, о которых я упоминал в предыдущем абзаце, а именно WriteProperty в объекте домена и WriteProperty/ReadProperty в объекте AdminSDHolder. Давайте начнем с ACE, добавленной к объекту домена:

1. Выполняем LDP.EXE.
2. В главном окне LDP нажимаем Подключение, а затем ПодключитьпїЅ
3. В окне Подключить вводим имя корневого контроллера домена и нажимаем OK. Это окно показано на рисунке 8.

1. Обратно в главном окне LDP жмем Подключения, а затем Привязать (Bind)
2. В окне Привязать вводим имя пользователя, пароль и учетную запись пользователя домена, которая имеет такие разрешения, как учетная запись администратора корневого домена. Это окно показано на рисунке 9 ниже.

1. Правая панель теперь должна информировать вас о том, что вы аутентифицировались. Нажмите Вид, затем Дерево и в окне Вид дерева просто оставьте поле BaseDN пустым и нажмите OK.
2. В главном окне LDP вы должны увидеть свой корневой домен, записанный сверху в левой панели, как показано на рисунке 10.

1. Прежде чем двигаться далее, очистите содержимое правой панели путем нажатия Подключение, а затем Новое. Это просто значительно облегчает чтение информации в следующем шаге.
2. Правой клавишей нажмите на домене вверху левой панели и выберите Дополнительно, затем Идентификатор безопасности (Security Descriptor) из контекстного меню, показанного на рисунке 11.

1. В появившемся окне Идентификатор безопасности оставьте поле Dn без изменений и выберите OK.
2. Теперь в правой панели появится много информации, подробно описывающей ACEs. В моей тестовой среде в общей сложности было обнаружено 40 ACEs. Ваш экран должен выглядеть подобно тому, что показан на рисунке 12.

1. Если вы пролистаете список ACEs, то найдете запись для набора WriteProperty ACE в объекте домена, как показано на рисунке 13. Здесь вы можете убедиться в том, что это WriteProperty ACE (из строки ACTRL_DS_WRITE_PROP) и что идентификатором безопасности для этой записи будет группа Exchange Enterprise Servers. Также обратите внимание, что GUID упомянутый выше также присутствует.

Теперь давайте проверим, сможем ли мы увидеть ACE в объекте AdminSDHolder. Оставляем LDP открытой там, где она была, и выполняем следующие шаги:

1. Жмем на Подключение, затем Новое, чтобы очистить правую панель.
2. В левой панели разворачиваем объект домена и дважды жмем на объекте Система. Прямо в объекте Система вы увидите объект AdminSDHolder.
3. Нажимаем Подключение, затем Новое, чтобы еще раз очистить правую панель.
4. Теперь правой клавишей нажимаем на объекте AdminSDHolder и выбираем Дополнительно, а затем Идентификатор безопасности, точно так же, как делали это только что для объекта домена.
5. В появившемся окне Идентификатор безопасности оставляем поле Dn без изменений и нажимаем OK.
6. И снова у нас появится много информации ACE в правой панели. Теперь можно пролистать список записей и найти ту, которая задает ReadProperty и WriteProperty для Exchange Enterprise Servers группы, как показано на рисунке 14.

На этом мы завершим рассмотрение установки наследственных разрешений Exchange. Я знаю, что уделил много места подготовке наследственных разрешений, но надеюсь, это дало вам много полезной информации о том, как проверять, были ли ACEs применены или нет.

Как станет ясно из последующих частей, на самом деле лучше дождаться, пока репликация Active Directory начнет работать, прежде чем переходить к следующим компонентам установки, а также будут представлены способы проверки наличия репликации. Я подробно опишу этот процесс после следующего шага, подготовки схемы, поскольку некоторые читатели, возможно, пропустили эту статью и первую часть, если в их организации отсутствует более старая версия Exchange.

Заключение

Здесь во второй части этой серии статей мы завершили рассмотрение процесса подготовки наследственных Exchange разрешений, уделяя внимание тому, как убедиться в успешности этого процесса после его завершения. В третьей части мы рассмотрим шаги, необходимые для подготовки схемы Active Directory, а также проверки успешности завершения этого процесса, наряду с проверкой репликации Active Directory.

В течение первых двух частей этой серии мы рассмотрели шаги, необходимые для подготовки Active Directory к Exchange 2007, а именно подготовку наследственных разрешений Exchange. Для тех из вас, в чьей организации нет сосуществующих Exchange 2000 или Exchange 2003 серверов, данный шаг не потребуется. Однако первые две части этой статьи содержат очень полезную информацию, которая может понадобиться в будущем, например использование таких инструментов, как LDP для определения того, были ли нужные разрешения заданы корректно. Если вы пропустили первые две части, поскольку у вас нет сосуществующих систем Exchange 2000 или Exchange 2003, я все же рекомендовал бы вам прочесть их.

Теперь пришло время двигаться дальше с остальными подготовительными шагами Active Directory, начиная с подготовки схемы Active Directory.

Подготовка схемы

Как и более старые версии Exchange, такие как Exchange 2000 или Exchange 2003, Exchange 2007 требует обновления схемы Active Directory для работы. Поэтому нужно убедиться, что учетная запись, которую вы используете для следующего процесса, является членом группы Schema Admins. К тому же, учетная запись также должна быть членом группы Enterprise Admins, чтобы можно было успешно завершить процесс обновления схемы. Вам понадобиться предварительный план внесения таких изменений, поскольку в безопасной среде очень вероятно, что принадлежность к этим группам не раздается в мгновение ока. Наконец следует обратить внимание на то, что у вас должен быть доступ к контроллеру домена Active Directory, на котором запущена роль мастера схемы, чтобы выполнить этот процесс, так как вы вносите изменения в схему. Если говорить точнее, то процесс подготовки схемы нужно выполнять на сервере, расположенном на том же Active Directory сайте и в том же домене, что и мастер схемы. Если нет, то часть процесса обновления схемы проверки организации будет безуспешной с описанием ошибки:

‘Программе установки необходимо связаться с мастером схемы AD, но этот компьютер находиться не в том же домене Active Directory, в котором расположен мастер схемы (Setup needs to contact the Active Directory schema master but this computer is not in the same Active Directory domain as the schema master (DC=domain,DC=com)).

Программа установки столкнулась с проблемой при подтверждении состояния Active Directory: объекты организационного уровня Exchange не были созданы, и программа установки не может их создать, так как локальный компьютер находиться не в том же домене или сайте, на котором находиться мастер схемы. Запустите установку с параметром /prepareAD на компьютере в домене (домен) и на сайте (имя сайта), и подождите, пока завершится процесс репликации. (Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run setup with the /prepareAD parameter on a computer in the domain {domain} and site {site name}, and wait for replication to complete).’

В первой и второй части этой статьи мы уже подготовили наследственные разрешения с помощью команды setup /pl, так как у нас есть сосуществующий сервер Exchange 2003. Однако если по какой-то причине вы не использовали эту команду и собираетесь сосуществовать с более старыми версиями Exchange, обратите внимание на то, что команда будет выполнена в качестве части процесса обновления схемы, о котором я рассказываю.

В этой статье мы сосуществуем с Exchange 2003, поэтому следует указать на то, что обновление схемы Exchange 2007 также включает обновление схемы, применимое для Exchange 2000 и Exchange 2003.

Для подготовки схемы обновлениями Exchange воспользуйтесь следующей командой:

setup/PrepareSchema

Как и в случае с командой для подготовки наследственных разрешений, здесь есть укороченный вариант команды обновления схемы. Это команда:

setup /ps

В моей тестовой среде я собираюсь выполнить команду setup /ps на корневом контроллере домена под названием AD-ROOT. Результаты выполнения этой команды показаны на рисунке 15, где обновление было успешным.

Обновление схемы может занять несколько минут. Если вы хотите проверить, что процесс действительно работает, то во время части Расширение схемы (Extending Active Directory schema) процесса перейдите в папку TEMP учетной записи пользователя, которую вы используете для выполнения процесса обновления схемы. По умолчанию пользовательской папкой TEMP будет папка %USERPROFILE%\Local Settings\Temp. Вы можете посмотреть, как она выглядела во время моего процесса обновления схемы на рисунке 16.

Как видно на рисунке 16, в этой папке есть три временных файла. Интересующий нас файл выделен, это файл ldif.log. Этот файл, во время снятия скриншота, имеет содержимое одного из файлов LDIF из файлов источников Exchange 2007, он также был тем файлом, который импортировался в тот момент. Если вы просмотрите содержимое папки TEMP во время процесса обновления, то увидите файл с варьирующимся размером между 0KB и 3KB по мере обработки различных файлов LDIF. На рисунке 17 показано содержимое файла в определенный момент процесса обновления схемы.

Репликация Active Directory

Рекомендуется проверять, что Active Directory копировала все изменения вашей среды, которые вы внесли в любом шаге, описанном в этой серии статей. Чтобы убедиться, что обновление схемы было применено на вашем контроллере домена, нужно проверить значение rangeUpper для атрибута ms-Exch-Schema-Version-Pt, используя ADSIEdit, когда вы подключены к определенному контроллеру домена. Этот атрибут используется для отслеживания версий схемы, которые были установлены, а поскольку rangeUpper значение для Exchange 2007 SP1 - это 11116, то именно его нам нужно искать. Если вы читаете эту статью, а компания Microsoft уже выпустила новую версию пакета обновления для Exchange 2007, это значение будет другим, поэтому обязательно узнайте, каким должно быть это значение. Вот как проверить, что на контроллере домена это значение задано. Здесь предполагается, что вы установили Windows Support Tools, поскольку именно оттуда берется инструмент ADSIEdit.

1. Выполните ADSIEdit.msc
2. В левой панели главного окна ADSIEdit разверните объект Схема (Schema), а затем выберите следующий объект Схема, который появится под ним.
3. В правой панели найдите атрибут CN=ms-Exch-Schema-Version-Pt, правой клавишей нажмите на нем и выберите Свойства из появившегося контекстного меню.
4. В появившемся окне свойств пролистайте вниз список атрибутов, пока не найдете атрибут rangeUpper. Убедитесь, что в столбце Значение (Value) стоит 11116, как показано на рисунке 18.

Еще одним инструментом в Windows Support Tools, полезным для проверки репликации Active Directory, является Active Directory Replication Monitor, replmon.exe. Вот как использовать этот инструмент:

1. Выполните Replmon.exe и у вас откроется главное окно Replmon, как показано на рисунке 19.

1. В левой панели правой клавишей нажмите на Monitored Servers и выберите Add Monitored Server’ из контекстного меню. Откроется окно мастера Add Monitored Server.
2. В этом окне выберите соответствующую опцию добавления контроллера домена по имени или поиска определенного домена. Так как у меня всего несколько контроллеров домена в моей среде, я выбрал опцию добавления сервера по имени.
3. В окне Добавить сервер для мониторинга доступна опция Ввести имя сервера для мониторинга эксплицитно, поэтому в поле я введу FQDN контроллера домена для мониторинга, как показано на рисунке 20.

1. После того как вы нажмете Готово, вы вернетесь обратно в главное окно Replmon, но на этот раз создано подключение для выбранного контроллера домена. Повторите этот процесс для других контроллеров домена и у вас должно быть окно, похожее на то, что показано на рисунке 21.

1. Теперь можно проверять репликацию различных каталогов путем их разворачивания и проверки информации, представленной в правой панели. К примеру, посмотрите на рисунок 22, где видно, что репликация была безуспешной, пока не было выполнено успешное обновление.

Вы, вероятно, помните, что в первой части этой статьи мы вкратце рассмотрели тот факт, что Exchange создает журналы регистрации событий установки во время различных подготовительных зданий Active Directory. Если вы снова посмотрите в папку C:\ExchangeSetupLogs во время шагов, перечисленных во второй части, вы заметите, что процесс обновления схемы также создает сценарии PowerShell под названием Install-ExchangeOrganization-{DATE}-{TIME}.ps1. Просмотр содержимого этих программно сгенерированных сценариев PowerShell может помочь вам в понимании процесса установки Exchange, поэтому их стоит просмотреть.

Заключение

В третьей части этой статьи мы охватили очень важную часть процесса подготовки Active Directory, а именно подготовку схемы. Можно сказать, что все части подготовительного процесса очень важны для успешного запуска Exchange, но в обновлении схемы есть дополнительная важность. Очень важно убедиться в том, что схема обновлена корректно, поэтому используйте предоставленную в этой статье информацию.

Это четвертая часть серии статей, охватывающих подготовку Active Directory к Exchange 2007. С первой по третью часть мы рассмотрели подготовку наследственных разрешений и подготовку схемы. В этих трех частях мы также узнали, как убедиться в том, что каждый этап успешно завершен с помощью специальных средств вроде файлов журнала, LDP.EXE и ADSIEdit. Некоторые администраторы считают важной проверку успешного завершения различных процессов и не любят полагаться только на «успешные» сообщения в конце каждого этапа.

Сейчас мы продолжим рассмотрение всего процесса подготовки изучением того, что необходимо для шага под названием подготовка Active Directory.

Подготовка Active Directory

Третий шаг из четырех рассматриваемых здесь – подготовка Active Directory путем создания различных объектов и последующая раздача разрешений. Как мы уже видели в предыдущих статьях, при выполнении определенной команды вызываются шаги из предыдущей команды, если та не была запущена индивидуально, а определенная команда, которую мы будем обсуждать, не изменена. Другими словами, эта команда автоматически подготовит наследственные разрешения и схему, если это еще не было сделано.

Команда, использующаяся для подготовки Active Directory, - setup /PrepareAD или, короче, setup /p. Если у вас сосуществование с другими версиями Exchange, тогда контейнер организации уже должен существовать в Active Directory. Если вы в первый раз устанавливаете Exchange, вам нужно будет добавить ключ /OrganizationName или /on и указать выбранное имя организации Exchange. К примеру:

setup /p /on:Exchange

Эта команда подтвердит готовность Active Directory с именем организации Exchange. Из Рисунка 23 вы можете видеть, на что похож процесс подготовки Active Directory.

Так как эта команда не выполняет никаких изменений схемы, вам нет необходимости быть членом группы Schema Admins для ее запуска, так же как было в случае с setup /ps. Однако вам нужно быть членом группы Enterprise Admins, не забывайте об этом, когда будете решать, от чьего имени будете запускать команду. Так же, как и в случае с процессом setup /ps, нужно выполнять эту команду на сервере, расположенном на том же сайте и домене Active Directory, что и мастер схемы. Хотя вы и не вносите изменений в схему, процесс setup /p вносит изменения конкретно в мастера схемы перед распространением по остальным контроллерам домена.

В предыдущих частях вы видели, что у вас есть возможность использовать такие средства как LDP и ADSIEdit для проверки успешного завершения процессов. В случае с setup /p было сделано несколько изменений, которые вы можете просмотреть с помощью приложений вроде Active Directory Users и Computers and Exchange System Manager. К примеру, в корневом домене инфраструктуры Active Directory вы увидите новую организационную единицу (ОЕ, Organizational Unit) под названием Microsoft Exchange Security Groups, и в этой ОЕ вы увидите следующие шесть групп безопасности:

• Exchange Organization Administrators
• Exchange Public Folder Administrators
• Exchange Recipient Administrators
• Exchange Servers
• Exchange View-Only Administrators
• ExchangeLegacyInterop

Эта ОЕ и группы в ней показаны на Рисунке 24. Помните, что эта ОЕ только что создана в корневом домене инфраструктуры Active Directory. В моем случае это домен neilhobson.com, то есть это означает, что эта ОЕ не будет видна в домене sales.neilhobson.com.

Также после выполнения процесса setup /p администраторам Exchange 2000 или Exchange 2003 может стать очевидным, что что-то изменилось, и предстоящее развертывание Exchange 2007 не за горами. Это происходит из-за того, что новые административная и корневая группы теперь появились в Exchange System Manager (Рисунок 25).

Административная группа Exchange (FYDIBOHF23SPDLT) и корневая группа Exchange (DWBGZMFD01QNBJR) созданы для всех серверов Exchange 2007 так, чтобы наследуемые версии Exchange понимали, как контактировать с новыми серверами Exchange 2007. Вы не увидите объектов этих административной и корневой групп в Exchange 2007 Management Console, так как это противоречит самой концепции этих групп в Exchange 2007. Очевидно, под административной группой Exchange 2007 не будет серверных объектов на данном этапе, поскольку мы еще не установили в действительности ни один сервер Exchange 2007, однако объекты административной и корневой группы в этой время уже есть. Это подтверждается Рисунком 25, где вы не увидите контейнера Servers прямо под объектом Exchange Administrative Group (FYDIBOHF23SPDLT).

И, наконец, еще одна простая проверка, которую вы сейчас можете провести, состоит в проверке содержимого контейнера организации Exchange с помощью ADSIEdit. Посмотрите на Рисунке 26 ниже, каково содержимое контейнера до запуска setup /p. А затем сравните с Рисунком 27, каково содержимое контейнера после запуска процесса setup /p. Обратите внимание на новые элементы на Рисунке 27, а именно контейнеры Client Access, ELC и UM. Они создаются в результате выполнения setup /p.

Процесс setup /p также настраивает много дополнительных разрешений, слишком много для перечисления здесь. Проверки вышеприведенных элементов настройки должно быть достаточно для вас, чтобы убедиться в успешности завершения процесса. Как всегда, не нужно забывать, что вы также можете осуществлять проверку более подробно с помощью файлов журнала.

В последней части процесса, которую я опишу в финальной части этой серии статей, мы посмотрим на подготовку доменов Active Directory. Вам следует обратить внимание на то, что процесс setup /p в действительности подготавливает тот домен, на котором запускается, поэтому в дальнейшем количество доменов, о которых нужно будет позаботиться, уменьшается на единицу.

Одно предупреждение, касающееся процесса setup /p, - по утверждениям Microsoft, этот процесс должен контактировать со всеми доменами в вашем дереве Active Directory, даже с теми, которые не наследуют серверы Exchange, установленные на них; вам будет необходимо учитывать это в большой или сложной инфраструктуре Active Directory.

Итоги

В этой предпоследней части данной серии статей мы рассмотрели этап подготовки Active Directory, а также то, какие проверки можно проводить для того, чтобы убедиться в успешности завершения этого этапа. В данном этапе осуществляются некоторые ключевые изменения, например, создание ОЕ групп безопасности Microsoft Exchange в корневом домене, а также создание наследственных административной и корневой групп. В последней части серии мы рассмотрим последний этап, а именно подготовку доменов Active Directory.

Это пятая и заключительная часть серии статей о подготовке Active Directory к использованию сервера Exchange 2007. На данный момент в этой серии мы рассмотрели подготовку наследственных разрешений, схемы и Active Directory. В результате у нас остался последний шаг подготовки, который представляет собой подготовку доменов Active Directory, которые будут содержать либо серверы Exchange 2007, либо пользователей Exchange 2007.

Подготовка доменов

Итак, мы добрались до самого последнего шага процесса, если говорить точнее, до подготовки доменов Active Directory к получению Exchange 2007. Если вы устанавливали наследственные версии Exchange, вы помните процесс DomainPrep, существовавший в Exchange 2000 и Exchange 2003. Процесс подготовки доменов в Exchange 2007 сходен с этим процессом в том, что его необходимо выполнить в двух местах:

• На каждом домене, куда вы устанавливаете сервер Exchange 2007
• На каждом домене, который будет содержать почтовых пользователей

Для подготовки домена используется команда setup /PrepareDomain или сокращенно setup /pd. Она подготавливает домены с того места, откуда выполняется, хотя, как я уже говорил, процесс setup /p подготавливает домены, на которых был запущен setup /p, поэтому нет необходимости повторять этот процесс на этом домене. Также можно подготовить указанный домен путем добавления полного доменного имени (FQDN) домена в эту команду, например:

setup /pd:sales.neilhobson.com

Чтобы успешно завершить процесс, необходимо выполнять команду от имени учетной записи, имеющей права администратора домена. Вы, возможно, сочтете этот процесс трудоемким, если у вас есть множество доменов в инфраструктуре Active Directory. К счастью, можно подготовить все домены за один раз, используя команду setup /PrepareAllDomains, или сокращенно setup /pad. Само собой разумеется, что в этом случае используемая вами учетная запись должна быть членом группы администраторов предприятия (Enterprise Admins).

Выполнение setup /pd процесса для домена sales.neilhobson.com показано на рисунке 28.

Обратите внимание на предупреждение, которое появилось, поскольку я не настроил службу Recipient Update Service в корневом домене.

Что в сущности делает процесс подготовки домена и как проверить его успешность? По сути, процесс назначает различные разрешения и создает дополнительные объекты, которые можно проверить визуально. Например, в подготавливаемом домене можно найти новую группу под названием Exchange Install Domain Servers. Чтобы найти эту группу, вызовите оснастку пользователей и компьютеров Active Directory Users and Computers и убедитесь, что дополнительные параметры отображаются, путем выбора опции Дополнительные параметры (Advanced Features) в меню Вид. Выберите вкладку Microsoft Exchange System Objects в левой панели и в правой панели вы найдете группу Exchange Install Domain Servers, как показано на рисунке 29.

В корневом домене найдите группу Exchange Servers, расположенную в организационном подразделении Microsoft Exchange Security Groups и вызовите ее свойства. Во вкладке Члены убедитесь, что группа Exchange Install Domain Servers с дочернего домена, который только что был подготовлен, является членом этой группы, как показано на рисунке 30.

На рисунке 30 видно, что группа Exchange Install Domain Servers родительского домена является членом группы Exchange Servers. Это потому, что процесс setup /p, который нужно выполнять в корневом домене, автоматически подготовил этот домен. Как видно, наличие группы Exchange Install Domain Servers является хорошим показателем того, что процесс подготовки домена был выполнен успешно.

Однако есть и другие вещи, которые нужно проверять, чтобы быть уверенным. Процесс подготовки домена также обновляет одно из свойств вкладки Microsoft Exchange System Objects, что мы сейчас и рассмотрим. Выполнив ADSIEdit и подключившись к контроллеру домена в дочернем домене можно вызвать свойства вкладки Microsoft Exchange System Objects, как показано на рисунке 31. Я не буду рассказывать подробно обо всех этих шагах, так как использование ADSIEdit было рассмотрено в предыдущих частях этой серии. Я лишь скажу, что нужно подключиться к контексту именования доменов (domain naming context), найти вкладку Microsoft Exchange System Objects, правой клавишей нажать на ней и выбрать Свойства из контекстного меню. В появившемся окне пролистайте вниз, пока не найдете атрибут objectVersion.

На рисунке 31 показано значение 6936, которое представляет собой значение, присвоенное после установки Exchange 2003 RTM. Когда вы выполнили процесс подготовки домена Exchange 2007, эта цифра должна измениться. Для Exchange 2007 RTM она должна быть 10628, а для Exchange 2007 SP1 - 11221.

Наконец, осталась одна последняя проверка, которую можно выполнить и которая отлично описана в документации Microsoft. После процесса подготовки домена для Exchange 2007, группе Exchange Servers Universal Security Group предоставляется разрешение в Manage Auditing and Security Log (Управление аудитом и журналом безопасности), расположенной в политике безопасности контроллера домена.

Чтобы найти ее, выполните следующие шаги:

1. Перейдите в меню Пуск, Администрирование
2. В папке администрирования выберите Политику безопасности контроллера домена.
3. В Настройках безопасности (Security Settings) разверните Локальные политики (Local Policies), а затем выберите Назначение прав пользователей (User Rights Assignment). В левой панели вы должны увидеть политики и список параметров политики, как показано на рисунке 32.

1. Пролистайте список политик вниз до политики под названием Управление аудитом и журналом безопасности. Дважды нажмите на этой политике, в результате чего откроется окно свойств, обратите внимание, что группа Exchange Servers Universal Security Group теперь имеет установленные разрешения, как показано на рисунке 33.

Заключение

Итак, мы рассмотрели все четыре шага подготовки Active Directory; как выполнять эти шаги и чего искать. Должен признать, у меня ушло определенное время, чтобы написать эти четыре шага в рамках пяти статей, которые кажутся небольшими. Однако, я счел полезным объяснить процессы подготовки в некоторых подробностях с обилием фотографий, так как эти процессы являются крайне важными для процесса установки Exchange 2007. Если вы только собираетесь установить Exchange 2007, надеюсь эта статья поможет вам понять, что происходит во время этих процессов. Если вы уже установили Exchange 2007, но еще не сдавали ни один из экзаменов Microsoft, могу лишь сказать, что в них проверяются самые разнообразные навыки, включая подготовку Active Directory.