На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2085376
10820
Hosts 1617591
2297
Visitors 166686
2805

9

Главная / Статьи / Exchange 2007 / Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 2)


Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 2)

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

Если вы хотите почитать предыдущую часть этой серии статей, перейдите по ссылке: Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 1).

Введение

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

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

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

Рисунок 3: Лог Exchange Setup Рисунок 3: Лог Exchange Setup

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

Рисунок 4: Открытый лог Exchange Setup Рисунок 4: Открытый лог Exchange Setup

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

Рисунок 5: Ошибка отсутствия Exchange 2003 SP2 Рисунок 5: Ошибка отсутствия Exchange 2003 SP2

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

Рисунок 6: Успешное завершение процесса подготовки наследственных разрешений Рисунок 6: Успешное завершение процесса подготовки наследственных разрешений

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

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

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

Рисунок 7: Записи ACE в ExchangeSetup.log Рисунок 7: Записи ACE в ExchangeSetup.log

На рисунке 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.
Рисунок 8: Окно подключения LDP Рисунок 8: Окно подключения LDP
  1. Обратно в главном окне LDP жмем Подключения, а затем Привязать (Bind)
  2. В окне Привязать вводим имя пользователя, пароль и учетную запись пользователя домена, которая имеет такие разрешения, как учетная запись администратора корневого домена. Это окно показано на рисунке 9 ниже.
Рисунок 9: Окно привязки LDP Bind Рисунок 9: Окно привязки LDP Bind
  1. Правая панель теперь должна информировать вас о том, что вы аутентифицировались. Нажмите Вид, затем Дерево и в окне Вид дерева просто оставьте поле BaseDN пустым и нажмите OK.
  2. В главном окне LDP вы должны увидеть свой корневой домен, записанный сверху в левой панели, как показано на рисунке 10.
Рисунок 10: Вид дерева LDP Рисунок 10: Вид дерева LDP
  1. Прежде чем двигаться далее, очистите содержимое правой панели путем нажатия Подключение, а затем Новое. Это просто значительно облегчает чтение информации в следующем шаге.
  2. Правой клавишей нажмите на домене вверху левой панели и выберите Дополнительно, затем Идентификатор безопасности (Security Descriptor) из контекстного меню, показанного на рисунке 11.
Рисунок 11: Опции меню идентификатора безопасности Рисунок 11: Опции меню идентификатора безопасности
  1. В появившемся окне Идентификатор безопасности оставьте поле Dn без изменений и выберите OK.
  2. Теперь в правой панели появится много информации, подробно описывающей ACEs. В моей тестовой среде в общей сложности было обнаружено 40 ACEs. Ваш экран должен выглядеть подобно тому, что показан на рисунке 12.
Рисунок 12: Отображение ACEs Рисунок 12: Отображение ACEs
  1. Если вы пролистаете список ACEs, то найдете запись для набора WriteProperty ACE в объекте домена, как показано на рисунке 13. Здесь вы можете убедиться в том, что это WriteProperty ACE (из строки ACTRL_DS_WRITE_PROP) и что идентификатором безопасности для этой записи будет группа Exchange Enterprise Servers. Также обратите внимание, что GUID упомянутый выше также присутствует.
Рисунок 13: Доменная ACE для группы Exchange Enterprise Servers Рисунок 13: Доменная ACE для группы Exchange Enterprise Servers

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

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

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

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

Заключение

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

Если вы хотите почитать предыдущую часть этой серии статей, перейдите по ссылке: Подробное рассмотрение подготовки Active Directory к Exchange 2007 (часть 1).





Рейтинг:  
5.0 (голосов 1)  
 1   2   3   4   5    

Автор: Нейл Хобсон (Neil Hobson)

Нейл является основным консультантом в Silverslands (http://www.silversands.co.uk), Золотом партнере Microsoft в Великобритании и отвечает за разработку, применение и поддержку приложений для многих крупных клиентов по всей Европе. В IT отрасли он трудится с 1987 года и специализируется на отправке сообщений с 1995. Он начинал работать еще с Exchange 4.0. Он также обладает званием Exchange MVP и уделяет некоторую часть своего личного времени на помощь различным пользователям Exchange, ведет блоги, посвященные Exchange. Эти блоги вы можете найти по адресу http://www.msexchangeblog.com.

С Нейлом можно связаться по адресу [email protected].

Эта статья переведена и опубликована с разрешения www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010