В течение первых двух частей этой серии мы рассмотрели шаги, необходимые для подготовки 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, где обновление было успешным.
Увеличить
Рисунок 15: Рисунок 15: Успешное обновление схемы
Обновление схемы может занять несколько минут. Если вы хотите проверить, что процесс действительно работает, то во время части Расширение схемы (Extending Active Directory schema) процесса перейдите в папку TEMP учетной записи пользователя, которую вы используете для выполнения процесса обновления схемы. По умолчанию пользовательской папкой TEMP будет папка %USERPROFILE%\Local Settings\Temp. Вы можете посмотреть, как она выглядела во время моего процесса обновления схемы на рисунке 16.
Как видно на рисунке 16, в этой папке есть три временных файла. Интересующий нас файл выделен, это файл ldif.log. Этот файл, во время снятия скриншота, имеет содержимое одного из файлов LDIF из файлов источников Exchange 2007, он также был тем файлом, который импортировался в тот момент. Если вы просмотрите содержимое папки TEMP во время процесса обновления, то увидите файл с варьирующимся размером между 0KB и 3KB по мере обработки различных файлов LDIF. На рисунке 17 показано содержимое файла в определенный момент процесса обновления схемы.
Увеличить
Рисунок 17: Содержимое файла LDIF.LOG
Репликация Active Directory
Рекомендуется проверять, что Active Directory копировала все изменения вашей среды, которые вы внесли в любом шаге, описанном в этой серии статей. Чтобы убедиться, что обновление схемы было применено на вашем контроллере домена, нужно проверить значение rangeUpper для атрибута ms-Exch-Schema-Version-Pt, используя ADSIEdit, когда вы подключены к определенному контроллеру домена. Этот атрибут используется для отслеживания версий схемы, которые были установлены, а поскольку rangeUpper значение для Exchange 2007 SP1 - это 11116, то именно его нам нужно искать. Если вы читаете эту статью, а компания Microsoft уже выпустила новую версию пакета обновления для Exchange 2007, это значение будет другим, поэтому обязательно узнайте, каким должно быть это значение. Вот как проверить, что на контроллере домена это значение задано. Здесь предполагается, что вы установили Windows Support Tools, поскольку именно оттуда берется инструмент ADSIEdit.
- Выполните ADSIEdit.msc
- В левой панели главного окна ADSIEdit разверните объект Схема (Schema), а затем выберите следующий объект Схема, который появится под ним.
- В правой панели найдите атрибут CN=ms-Exch-Schema-Version-Pt, правой клавишей нажмите на нем и выберите Свойства из появившегося контекстного меню.
- В появившемся окне свойств пролистайте вниз список атрибутов, пока не найдете атрибут rangeUpper. Убедитесь, что в столбце Значение (Value) стоит 11116, как показано на рисунке 18.
Рисунок 18: Значение rangeUpper
Еще одним инструментом в Windows Support Tools, полезным для проверки репликации Active Directory, является Active Directory Replication Monitor, replmon.exe. Вот как использовать этот инструмент:
- Выполните Replmon.exe и у вас откроется главное окно Replmon, как показано на рисунке 19.
- В левой панели правой клавишей нажмите на Monitored Servers и выберите Add Monitored Server’ из контекстного меню. Откроется окно мастера Add Monitored Server.
- В этом окне выберите соответствующую опцию добавления контроллера домена по имени или поиска определенного домена. Так как у меня всего несколько контроллеров домена в моей среде, я выбрал опцию добавления сервера по имени.
- В окне Добавить сервер для мониторинга доступна опция Ввести имя сервера для мониторинга эксплицитно, поэтому в поле я введу FQDN контроллера домена для мониторинга, как показано на рисунке 20.
Рисунок 20: Добавление определенного сервера
- После того как вы нажмете Готово, вы вернетесь обратно в главное окно Replmon, но на этот раз создано подключение для выбранного контроллера домена. Повторите этот процесс для других контроллеров домена и у вас должно быть окно, похожее на то, что показано на рисунке 21.
Увеличить
Рисунок 21: Replmon с проверяемыми серверами
- Теперь можно проверять репликацию различных каталогов путем их разворачивания и проверки информации, представленной в правой панели. К примеру, посмотрите на рисунок 22, где видно, что репликация была безуспешной, пока не было выполнено успешное обновление.
Увеличить
Рисунок 22: Ошибка и успешная репликация
Вы, вероятно, помните, что в первой части этой статьи мы вкратце рассмотрели тот факт, что Exchange создает журналы регистрации событий установки во время различных подготовительных зданий Active Directory. Если вы снова посмотрите в папку C:\ExchangeSetupLogs во время шагов, перечисленных во второй части, вы заметите, что процесс обновления схемы также создает сценарии PowerShell под названием Install-ExchangeOrganization-{DATE}-{TIME}.ps1. Просмотр содержимого этих программно сгенерированных сценариев PowerShell может помочь вам в понимании процесса установки Exchange, поэтому их стоит просмотреть.
Заключение
В третьей части этой статьи мы охватили очень важную часть процесса подготовки Active Directory, а именно подготовку схемы. Можно сказать, что все части подготовительного процесса очень важны для успешного запуска Exchange, но в обновлении схемы есть дополнительная важность. Очень важно убедиться в том, что схема обновлена корректно, поэтому используйте предоставленную в этой статье информацию.