Копирование общих папок – основные неисправности

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

Первая область для проверки при устранении неисправностей при дублировании общих папок – это статус иерархии. К примеру, предположим, вы установили новый сервер Exchange на уже существующую структуру и подозреваете, что этому новому серверу не послана копия иерархии. В этом случае, первое, что вам необходимо проверить, правильно ли общее хранилище информации сконфигурировано с почтовыми адресами. И иерархия общих папок и изменения содержимого посылаются между серверами Exchange посредством электронных сообщений, и из этого следует, что если общая информация хранит электронный адрес друг друга, электронный адрес им необходим также, как и рабочий путь между ними. Это работа Recipient Update Service (RUS), чтобы убедиться в том, что объекты содержат правильный электронный адрес, он содержится в общем информационном хранилище. Поэтому, первое, что вам необходимо сделать, это проверить общее информационное хранилище электронных адресов, что может быть сделано при помощи ADSIEdit. ADSIEdit устанавливается как часть средств поддержки Windows 2003 Support Tools.

В запущенном ADSIEdit, щелкните правой кнопкой мыши ADSI Edit и выберите опцию Connect to… В результирующем окне Connection Settings, убедитесь, что контекст наименований установлен в Configuration и затем нажмите OK. После того, как произошло соединение, вы можете переместиться вниз к хранилищу общей информации. Перемещение вниз будет происходить в соответствии с деревом:

CN=Configuration, DC=domain, DC=com
  CN=Services
    CN=Microsoft Exchange
      CN={your Exchange organization name}
        CN=Administrative Groups
          CN={relevant administrative group}
            CN=Servers
              CN={relevant Exchange server}
                CN=InformationStore
                  CN={relevant storage group}.

В примере на рисунке 1, вы можете видеть, что я переместился вниз к First Storage Group на сервере DCEXCH1.

Теперь нажмите правую кнопку на общей папке, показанной на правом окне, и выберите Properties из контекстного меню. В результирующем окне свойств найдите атрибут proxyAddresses и нажмите кнопку Edit. Появится окно, показанное на рисунке 2. Здесь вы можете увидеть пример хранилища общей информации, которое правильно помечено и SMTP и X.400 электронными адресами; если нет значений у атрибута proxyAddresses, мы сразу же понимаем, что для этого хранилища не запущен RUS и поэтому необходимо начать поиск неисправностей в RUS. Заметьте, что за подпись электронными адресами отвечает корпоративный RUS, а не RUS домена, поэтому убедитесь, что вы смотрите на нужный RUS.

В результате моих предыдущих переходов от Exchange 5.5 к Exchange 2000, я помню, что одна из основных причин, по которой RUS не подписывает электронные адреса на новом сервере, заключалась в пропущенном генераторе прокси адресов, который, к примеру, используется шлюзом факса. Другие общие причины заключаются в неправильных контроллерах домена или серверах Exchange, находящихся в списках свойств RUS. Посмотрите раздел ссылок и в конце этого документа и, может быть, вы найдете что-нибудь полезное о поиске неисправностей в RUS. Еще одна ничего не стоящая вещь – это формат адресов SMTP, назначенных для общего хранилища: [email protected]. О значении всего этого мы расскажем далее в этой статье.

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

Cообщения при копировании

Повышение уровня диагностической информации всегда полезно для вашего Exchange при поиске неиправностей. Уровни диагностической информации могут быть установлены для объекта MSExchangeIS Public Folder, находящегося в о свойтсвах сервера Exchange в Exchange System Manager. В случае общих папок, я встречал много профессионалов по Microsoft PSS, рекомендующих устанавливать категории диагностической информации, как показано ниже в таблице 1, как на сервере-отправителе, так и на сервере-получателе копируемых данных. Это позволяет вам увидеть чистую картину того, что случилось в процессе процедуры копирования. В этой статье мы больше сконцентрируемся на копировании входящих и выходящих категорий.

Таблица 1: Рекомендуемые установки диагностической информации

После установки уровня диагностики, журналы событий приложений на отправляющем и принимающем сервере начинают сохранять более подробную информацию о сообщениях, возникающих при копировании. Есть несколько типов сообщений. В таблице 2 отражены тип сообщения, назначение, направление движения и связанный с ним ID события.

Таблица 2: Типы сообщений

Давайте, в качестве примера, рассмотрим сообщение копирования иерархии. Если вы создаете или удаляете общую папку, или, может быть, меняете права доступа, сервером-отправителем серверу-получателю будет сгенерировано сообщение копирования иерархии. Как вы могли предполагать, отправка сообщения копирования иерархии отразится в категории диагностики Replication Outgoing Messages, в то время как, получение сообщения копирования иерархии отразится в категории Replication Incoming Messages. Из этого следует, что для каждого исходящего сообщения от сервера-отправителя должно существовать входящее сообщение на сервере-получателе.

Рассмотрим пример сообщения при копировании, показанного на рисунке 3. Здесь вы можете видеть, что категория события показана, как Replication Outgoing Message. Причина этого станет понятна, когда вы изучите детали. Тип установлен на 0x2 (иерархия), и затронутая папка называется New Test Folder; это была новая общая папка, которую я создал.

Как я только что упомянул, это нормально ожидать соответсвующее входящее сообщение дублирования на принимающем сервер. Хотя, если у вас возникли неполадки, и у клиентов Outlook, присоединенных к серверу-получателю, не отразилась общая папка New Test Folder, слудующий шаг будет заключаться в изучении журнала событий на сервере-получателе, на наличие соответствующего входящего сообщения, чтобы убедиться в том, что оно получено. Это событие должно попасть в категорию Replication Incoming Message и иметь ID сообщения 3028. Тип сообщения будет 0x2, т.к. это будет сообщение иерархии, а также содержать имя папки New Test Folder.

Подобные процессы происходят при копировании с сообщениями других типов. Например, если пользователь отправляет сообщение в общую папку, или каким-то образом изменяет существующее сообщение и сохраняет его обратно в общей папке, все сообщение дублируется, и его можно будет увидеть в окне для просмотра событий в виде сообщения дублирования содержания (тип 0x4) с ID события 3020 или 3030, в зависимости от направления.

Сообщения типа запрос на заполнение и ответ на заполнение – часть процесса заполнения, который определяет по какой причине потеряны некоторые обновления при дублировании и запрашивает эти обновления с других общих хранилищ. Запрос на заполнение посылается как сообщение с типом 0x8, в то время как ответное сообщение будет иметь тип 0x80000002 для сообщений иерархии и тип0x80000004 для сообщений содержимого. На рисунке 4 показан пример сообщения типа запрос на заполнение содержимого. В этом примере сервер DCEXCH1 отвечает на запрос сервера EXCH3 к общей папке Items For Sale.

Последние типы сообщений – это статус копирования, тип 0x10, и статус запроса, тип 0x20. Они используются общим хранилищем информации для синхронизации посылающего и принимающего хранилищ.

Отслеживание сообщений при копировании

Продолжая рассматривать пример выше, может возникнуть ситуация, когда на сервере-получатель не содержится соотствующее событие о входящем сообщении о копировании. Если это произошло, то следующим логическим шагом будет проверить транспорт сообщений. Вероятно, первое что необходимо сделать это использовать Message Tracking Center в Exchange System Manager, чтобы попытаться увидеть в чем дело.

Из рисунка 5, вы можете увидеть, что я отслеживал сообщения, посланные из хранилища общих папок на сервере DCEXCH1. Чтобы сделать это, я просто указал [email protected] в качестве отправителя сообщения. Как говорилось раннее в этой статье, это SMTP адрес посылаемого хранилища общей информации.

Лично я считаю очень полезным убедиться в том, что при отслеживании сообщений включена журнализация. В можете подключить ее в закладке General в свойствах вашего объекта сервера Exchange в Exchange System Manager. На рисунке 5 вы можете увидеть, что подключение журнализации облегчает поиск ваших сообщений, т.к. все сообщения после 22:33 имеют заполненное поле subject, которое стало заполняться после подключения журнализации. К примеру, теперь ясно видно, что сообщение, посланное в 22:45, это сообщение иерархии.

Чтобы углубиться в события, связанные с каждым отслеженным сообщением, необходимо просто дважды щелкнуть соответствующее сообщение. Например, двойной щелчок на сообщении иерархии, посланном в 23:00, откроет окно Message History, как на рисунке 6. Здесь мы также видим, что последняя запись показывает нам, что сообщение было успешно доставлено на сервер-получатель EXCH3. Если бы последние две записи отсутствовали на экране, то мы бы увидели сообщение SMTP: Message Routed and Queued for Remote Delivery. В этом случае, мы бы знали, что сообщение поставлено в очередь на сервере-получателе и, следовательно, не доставлено. Затем необходимо будет проверить очередь сообщений при помощи утилиты Queue Viewer utility в Exchange System Manager on на сервере-получателе.

Стоит заметить, что создается одно сообщение копирования, даже если существует составная модель этой общей папки. К примеру, если общая папка была изменена на сервере DCEXCH1 и модель этой папки существует на серверах EXCH2 и EXCH3, вы увидите, что сгенерировано одно сообщение копирования, и оно направлено одновременно двум хранилищам общих папок. Это показано в окне Message History на рисунке 7.

Резюме

Самая главная вещь в дублировании общих папок заключается в том, что это копирование основано на сообщениях. Зная это, вы будете уверены в том, что общее хранилище имеет правильные электронные адреса, вы можете использовать стандартные средства Exchange System Manager и Event Viewer, чтобы начать поиск неисправностей при копировании. Конечно, всегда могут возникнуть более сложные неисправности, лежащие за пределами этой статьи, но мы надеемся, что эта статья была вам полезна, и вы сможете использовать ее в качестве отправной точки.

Ссылки

Устранение неисправностей Recipient Update Service
http://support.microsoft.com/?id=288807

Устранение неисправностей RUS с использованием журнала событий. Части 1-4
http://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx
http://blogs.technet.com/exchange/archive/2004/07/15/184356.aspx
http://blogs.technet.com/exchange/archive/2004/07/22/191513.aspx
http://blogs.technet.com/exchange/archive/0001/01/01/198662.aspx

Использование Winroute для определения статуса маршрутизации вашей структуры Exchange
http://www.msexchange.org/tutorials/WinRoute-Routing-status-Exchange-organization.html