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

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

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


Авторизация

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

Подписка

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

Статистика

Hits 2084329
9773
Hosts 1617535
2228
Visitors 166603
2710

10
Мониторинг активности принтеров

Главная / Статьи / Exchange 2007 / Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 4)


Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 4)

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

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

Если вы пропустили предыдущие части этой серии, перейдите по ссылкам:

  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 1)
  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 2)
  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 3)

Если вы хотите получить сообщение о том, что Натан Винтерс выпустил очередную часть этой серии статей, подпишитесь на MSExchange.org Real time article update newsletter.

Настройка коннектора календаря

В системном менеджере Exchange (ESM) нажимаем правой клавишей и выбираем свойства.

Коннектор календаря общий и может использоваться как с Notes, так и с GroupWise. Вкладке Общие, показанной на рисунке 1, необходимо знать, с каким коннектором она работает, поэтому нажимаем Изменить, вводим Коннектор, жмем Проверка имен (Check Names), в результате чего у нас появится список доступных для выбора коннекторов. В данном случае у нас есть только один коннектор.

Рисунок 1: Вкладка «Общие» коннектора календаря Рисунок 1:Вкладка «Общие» коннектора календаря

Далее переходим по вкладке Соединения календаря и жмем Новое. Затем, как показано на рисунке 2 выбираем Novell GroupWise.

Рисунок 2: Выбор системы календаря для подключения Рисунок 2: Выбор системы календаря для подключения

Жмем OK, а затем вписываем имя шлюза GroupWise API:

Все что нам здесь нужно, это имя в формате domain.gateway.

В данном случае, как показано на рисунке 3, это будет DOM1.Exchange.

Рисунок 3: Ввод имени шлюза GroupWise API Рисунок: Ввод имени шлюза GroupWise API

Настройте свой график, нажмите «Применить» и все готово. По окончании настройки мы перейдем к тестированию функциональности, а затем посмотрим на некоторые возможные шаги диагностики.

Наконец, прежде чем двигаться дальше, вспомним, что мы уже говорили в третьей части этой серии о политике GWISE Recipient. По причинам, описанным в следующей статье Microsoft KB, следует активировать прокси адрес GWISE в политике получателей по умолчанию, вместо того, чтобы создавать новую политику.

Event ID 6001 messages are logged when you use Exchange 2000 Calendar Connector

Момент истины – запуск API

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

Я опишу вам эти шаги и надеюсь, они пояснят некоторые моменты о том, как вся эта конфигурация работает в совокупности.

Когда вы устанавливаете API, используя NWCONFIG в GroupWise Post Office, создается структура директорий API в директории wpgate. Помимо наличия файлов, эта директория содержит три подкаталога после того, как API установлен и прежде, чем он запущен.

К этим подкаталогам относятся

  • GWCHARS
  • HELPRQST
  • SAVE

Если структура директории wpgate\API существует и содержит только эти три подкаталога, мы можем вполне уместно предположить, что API еще не используется и никогда не запускался.

С другой стороны, если структура директории wpgate\API содержит пять подкаталогов (три вышеупомянутых плюс два, указанных ниже), можно смело говорить, что API попытался запуститься, но попытка была безуспешной.

  • GWPROB
  • GWHOLD

Установка шлюза API на самом деле является довольно базовой процедурой. Единственным осложненным моментом является путь домена (Domain Path), который должен иметь формат Раздел:Путь

Самой распространенной причиной неудачного запуска является либо то, что объект шлюза не был определен в ConsoleOne, как описано в статье 3, или (наиболее вероятная причина), когда Требуемые параметры для объекта шлюза, рисунок 4, содержат несоответствующую ссылку на корневую директорию (Root Directory), например буква диска вместо /:\

Рисунок 4: Установка правильных путей файла шлюза Рисунок 4: Установка правильных путей файла шлюза

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

Как только объект шлюза был определен как Сетевой администратор и/или ConsoleOne,, вы можете запускать API из консоли Netware System Console, используя команду API. Помните, что сочетание CTRL+ESC перечисляет Текущие экраны.

Первое, на что следует обратить внимание при запуске API, это дополнительные директории, которые создаются в wpgate\API

  • 000.PRC
  • API_IN
  • API_OUT
  • ATT_IN
  • ATT_OUT
  • WPCSIN
  • WPCSOUT

Если эти директории имеются, мы знаем, что API запускался как минимум один раз в прошлом, и возможно работает сейчас.

Останьтесь на некоторое время в консоли Netware System Console. CTRL+ESC выдаст список текущих экранов. Если API работает, выберите его из списка. Если нет, выберите System Console и запустите API, набрав API.

Теперь нажмите F9, чтобы найти файл журнала, и используйте клавиши page up/page down, чтобы просмотреть его. Вы должны заметить строку, которая выглядит примерно следующим образом

02-27-08 19:58:05 **************** Gateway Started ****************

Тремя строками ниже вы должны увидеть домен и шлюз, которыми в моем случае являются = DOM1.Exchange, домен и объект шлюза.

Посмотрите еще на четыре строки ниже и увидите, что расположения корневой директории, рабочей директория и файла журнала также прописаны. Журнал, который вы увидите, должен будет находиться в 000.PRC подкаталоге, который создается при запуске API.

Вы можете также просматривать этот журнал с помощью Windows Explorer и открывать его в блокноте, как показано на рисунке 5.

Рисунок 5: Файл журнала API Рисунок 5: Файл журнала API

В API на сервере Netware нажмите F1, чтобы отменить просмотр файла журнала.

Теперь нажмите F10, чтобы вызвать меню опций.

Дважды нажмите F2, чтобы установить уровень регистрации на Диагностику, это дает гораздо больше информации и может быть очень полезно. На рисунке 6 приведен пример такого типа регистрации.

Нажмите F1, чтобы выйти из опций и на этом работа с сервером NetWare завершена.

Рисунок 6: GroupWise API окно отображает уровень регистрации Рисунок 6: GroupWise API окно отображает уровень регистрации

На данном этапе мы определили объект шлюза, и запустили API. Если вы следовали инструкциям нашей статьи, то должны были создать внешний чужой домен (External Foreign Domain) и подключить его к системе GroupWise.

Почтовый поток

Итак, как же почта все-таки попадает из одной системы в другую? GroupWise ссылается на довольно простой формат. Домен. Почтовая служба. Почтовый ящик. (Domain.Post Office. Mailbox)

Как только мы создали внешний чужой домен, и подключились к нему, GroupWise будет отправлять все, что начинается с Exchange. через API. Все на самом деле так просто. Когда речь идет о GroupWise, Exchange. является именем домена, поэтому если вы начинаете адрес с Exchange., вы должны принадлежать домену.

Вот простой способ тестирования. На клиенте GroupWise запустите Новое сообщение.

В поле To: ведите Exchange.First Administrative Group.Administrator

На данный момент у вас может быть установлен или не установлен коннектор для Novell GroupWise, а DirSync может работать или не работать, это не имеет абсолютно никакого значения. Если внешний чужой домен был создан и правильно подключен, клиент GroupWise примет этот адрес, и вы сможете Отправить сообщение.

Если, с другой стороны, вы получили сообщение об ошибке, рисунок 7, это указывает на то, что внешний чужой домен Exchange еще не был правильно создан.

Рисунок 7: Сообщение ошибки адресации GroupWise Рисунок 7: Сообщение ошибки адресации GroupWise

Если подключаемость Exchange и GroupWise настроена в полной мере и работает, тогда это сообщение будет прислано на почтовый ящик администратора на Exchange Server. Если коннектор Exchange еще не был настроен или запущен, тогда сообщение подготавливается к Exchange, и остается в двух местах в структуре директории wpgate\API.

Заголовок сообщения можно найти в wpgate\API\API_OUT.

Тело (основную часть) письма можно найти в wpgate\API\ATT_OUT.

На странице 125 руководства Microsoft Exchange Server 2003 Interoperability and Migration Guide (Поиск e2k3InterOpMig.doc) дано подробное описание процедуры изменения этих исходящих сообщений и проверки того, что они возвращаются на почтовый ящик отправителя GroupWise. По собственному опыту могу сказать, что если сообщение дошло до API_OUT и ATT_OUT, то API работает.

Итак, что касается системы GroupWise, мы установили, настроили и запустили API, повысили уровень диагностической регистрации, рассмотрели создание структуры директории API, обнаружили директорию файла журнала и немного начали понимать, как эта структура директории используется. Есть много моментов, в которые стоит углубиться, если что-то пошло не по плану. Если у вас все так плохо, и не все работает, пришлите нам письмо.

Запуск коннекторов Exchange

Мне нравится после установки и настройки коннекторов для Novell GroupWise и календаря следовать обычной рутине;

Все службы, связанные с этой подключаемостью, устанавливаются на ручной запуск. В менеджере Exchange System Manager правой клавишей нажмите на сервере, на котором запущен коннектор и выберите Свойства. Во вкладке Общие выберите опцию Активировать отслеживание сообщений, поскольку это очень ценная опция, когда нам нужно знать, входит или исходит сообщение в Exchange. На вкладке Диагностическая регистрация (Diagnostic Logging) обратите внимание на то, какие дополнительные Службы доступны для регистрирования, как показано на рисунке 8. На данном этапе оставляем эту настройку нетронутой.

Рисунок 8: Просмотр дополнительных служб GroupWise, доступных для регистрирования Рисунок 8: Просмотр дополнительных служб GroupWise, доступных для регистрирования

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

На данном этапе можно запустить коннектор GroupWise на сервере Exchange. Для этого входим в инструменты администрирования (Пуск, Выполнить, Services.msc). Правой клавишей жмем Коннектор Microsoft Exchange для Novell GroupWise, и жмем Запустить. Это также должно запустить контроллер подключаемости Microsoft Exchange и маршрутизатор Micorosft Exchange для Novell GroupWise.

Далее,проверяем журнал регистрации событий приложений. В журнале у вас должно быть записано пять событий.

  • Источник MSExchangeGWRtr, событие 6015 означает, что маршрутизатор Exchange для службы Novell GroupWise запущен.
  • Источник MSExchangeCoCo, событие 8229 означает, что служба контроллера подключаемости Microsoft Exchange запущена.
  • Источник MSExchangeGWRtr, событие 5016 означает, что коннектор регистрируется в разделе Novell.
  • Источник MSExchangeGWise, событие 8229 означает, что коннектор Microsoft Exchange для службы Novell GroupWise запущен.
  • Источник MSExchangeGWRtr, событие 5019 означает, что коннектор успешно подключился к разделу Novell, используя настроенную учетную запись пользователя.

Если в журнале вы видите нечто другое вместо пяти событий, значит что-то не так. Особенно если любое из них является отчетом об ошибке. Из собственного опыта перечислю вам несколько событий, которые вы не должны видеть, поскольку они являются самой вероятной причиной проблемы.

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

  • Источник MSExchangeGWRtr, событие 5017, подключение, код системной ошибки 1219

Если вы не установили клиента Novell, что является довольно распространенной ошибкой, вы увидите:

  • Источник MSExchangeGWRtr, событие 5017, подключение, код системной ошибки 1203

При работе с журналом регистрации событий, если вы не ослабите стандартную политику паролей домена, когда пытаетесь выполнить начальную Немедленную полную перезагрузку (Immediate full reload) с GroupWise на Exchange, журнал регистрации событий будет загораться как новогодняя елка, в результате чего вы увидите следующие ошибки:

  • Источник MSExchangeADDXA, событие 8270 LDAP Операции, LDAP ошибка возвращения [35], невозможно выполнить при импортировании трансакции

за ней следует

  • Источник MSExchangeGWISE, событие 8307 GroupWise Directory Syn, Error 4b8: Проблема возникла при импортировании элемента 'Cindy Wright' в Exchange

Параметры, которые вам нужно изменить в стандартной политике домена, расположены в меню «Настройки компьютера, настройки Windows, параметры безопасности, политики учетных записей, политики паролей».

Минимальные параметры, которые я рекомендую для разрешения создания новых объектов пользователя, следующие:

  • Внедрение истории паролей Оставить без изменений
  • Максимальный срок действия пароля Оставить без изменений
  • Минимальный срок действия пароля Оставить без изменений
  • Минимальная длина пароля 0 (Пароль не требуется)
  • Пароль должен соответствовать требованиям сложности Отключено.
  • Хранить пароли, используя обратимое шифрование Оставить без изменений

Теперь, когда все работает, запускаем коннектор календаря Microsoft Exchange. Это должно добавить шестое событие, которое просто означает, что коннектор запущен.

  • Источник MSExchangeCalCon, событие 6015

На данном этапе я бы установил коннектор Microsoft Exchange для Novell GroupWise и коннектор календаря Microsoft Exchange на автоматический режим, чтобы они перезапускались всякий раз, когда перезагружается сервер.

Синхронизация директорий

В менеджере Exchange System Manager, в каталоге Коннекторы правой клавишей жмем Коннекторы для Novell GroupWise и выбираем Свойства. Переходим по вкладке График DirSync.

Когда все коннекторы запущены, а стандартная политика домена ослаблена, нажимаем (если еще на нажимали) Немедленная полная перезагрузка для GroupWise в Exchange и для Exchange в GroupWise.

Открываем ADUC, и смотрим на всплывающее окно объекта пользователя. Если все выполнено правильно, у вас должен появиться новый объект пользователя в OU, который вы определили для импорта в Active Directory, как показано на рисунке 9.

Рисунок 9: Новый объект в GroupWise Sync OU Рисунок 9: Новый объект в GroupWise Sync OU

Вы также обнаружите, что новые пользователи отображены в GAL, как показано на рисунке 10.

Рисунок 10: Новые элементы в GAL Рисунок 10: Новые элементы в GAL

Каждый из них должен иметь почтовую службу GroupWise в списке вкладки Exchange общие в своих свойствах объекта пользователя (рисунок 11).

Рисунок 11: GroupWise адрес синхронизированных объектов Рисунок 11: GroupWise адрес синхронизированных объектов

Наконец, нам нужно проверить, синхронизируются ли учетные записи с Exchange в GroupWise. Для этого перемещаем пользователя только с разрешением существующих ящиков, администратора, в Exchange Users OU (или в OU, которую вы задали для экспортирования), чтобы посмотреть, что он синхронизируется обратно в GroupWise.

Проверьте его синхронизацию с помощью клиента GroupWise.

Рисунок 12: Почтовый ящик администратора Exchange, отображенный в клиенте GroupWise Рисунок 12: Почтовый ящик администратора Exchange, отображенный в клиенте GroupWise

Обратите внимание на то, как на рисунке 12 прокси адрес GWISE отображен в GroupWise.

Хорошим советом для просмотра и диагностики всего, что происходит на стороне Microsoft, является создание журнала регистрации DWROD на сервере Exchange, который будет архивировать все, что проходит через структуру директории program files\exchsrvr\conndata\gwrouter. Эта структура директории на сервере Exchange Server и является коннектором.

Создайте DWROD значение с названием Архив (Archive)  со значением  1  в
HKLM\SYSTEM\CurrentControlSet\Services\LME-GWISE\Parameters,

а затем перезапустите маршрутизатор Exchange для службы Novell GroupWise. Это создаст дополнительную директорию в gwrouter с названием archive, которая будет содержать копию каждого файла, проходящего через структуру директории gwrouter, как показано на рисунке 13. Это очень полезно, поскольку файлы временные и после того, как они обрабатываются, они удаляются, поэтому если вы не активируете архивацию, вам придется отлавливать эти файлы как мух.

Рисунок 13: Директория архива Рисунок 13: Директория архива

Заключение

Если вы до настоящего момента следили за этой серией статей, то вы уже много прошли на пути перехода с GroupWise на Exchange. Мы не рассмотрели один момент, это Free/Busy (свободен/занят) переход между системами. Не будет преувеличением сказать, что это довольно проблематичная область работы! В следующей статье мы осудим это, начнем применять Exchange 2007, а также охватим заявления представителей компании Microsoft о поддержке такого типа перехода.

Если вы пропустили предыдущие части этой серии, перейдите по ссылкам:

  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 1)
  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 2)
  • Переход с GroupWise на Exchange 2007 – функциональная совместимость и миграция (часть 3)




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

Автор: Натан Уинтерс(Nathan Winters)
Натан Уинтерс – консультант по унифицированным коммуникациям для Dimension Data. В первой половине 2006 Натан основал Microsoft Messaging and Mobility User Group UK. В апреле 2007 Натан был награжден MVP (Exchange Server) за свою работу с MMMUG и за пожертвование в Mark Minasi Forum. Вы можете написать Натану на [email protected] или блог.
Эта статья переведена и опубликована с разрешения www.msexchange.org

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





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