Устранение неполадок, возникающих при репликации общедоступной папки. Часть 3. Устранение неполадок, возникающих при удалении реплик, и распространенные проблемы
Исходная статья опубликована 28 ноября 2011 г.
Исходная публикация в блоге: 24.01.06
Это третья запись блога, посвященная устранению неполадок, возникающих при репликации общедоступных папок. В первой записи мы описали устранение неполадок, возникающих при репликации новых изменений. Во второй записи обсуждалось устранение неполадок, возникающих при репликации существующих данных. В этой записи описывается исправление ошибок, возникающих при удалении реплик, и описываются распространенные проблемы. Чтобы получить общее представление, прочитайте все указанные материалы.
Устранение неполадок, возникающих при удалении реплик
Вы удалили старый сервер из списка реплик для всех папок. Однако если перейти в экземпляр общедоступной папки для старого хранилища в ESM, вы увидите там множество папок. Это связано с проблемой в процессе удаления реплик. Если попытаться удалить хранилище общих данных в таком состоянии в версии ESM для Exchange 2003 с пакетом обновления 2 (Sp2), ESM покажет диалоговое окно со следующим сообщением:
"Нельзя удалить это хранилище общедоступных папок, так как оно содержит реплики папок. Чтобы избежать потери данных, щелкните правой кнопкой хранилище общедоступных папок и используйте команду "Переместить реплики", чтобы переместить реплики на другой сервер. На репликацию содержимого на новый сервер и удаление локальных реплик может уйти несколько часов".
При удалении хранилища из списка реплики папки хранилище не сразу же удаляет данные. Оно отправляет специальный запрос состояния 0x20 всем другим репликам. Этот запрос называется запросом состояния удаления ожидающих реплик (RDPSR) и его нельзя отличить от обычного запроса состояния в журнале приложений. Запрос RDPSR содержит флаг, указывающий на то, что реплика ожидает удаления. Когда другие хранилища получают это сообщение типа 0x20, они отвечают специальным сообщением типа 0x10, которое называется подтверждением ожидания удаления реплики (RDPA). RDPA указывает, что данные можно удалить, но другие хранилища отправляют сообщение типа 0x10, только если у них есть все номера изменений (CN), которые содержит реплика, ожидающая удаления. Эта реплика будет удалено только после того, как хранилище получить сообщение 0x10, означающее, что другое хранилище содержит эти данные.
Это значит, что если удалить хранилище до очищения экземпляров общедоступной папки, данные, вероятно, будут потеряны. Только ESM в Exchange 2003 с пакетом обновления 2 (Sp2) не позволит сделать это, так как в старых версиях необходимо вручную проверить экземпляры общедоступной папки, чтобы узнать, можно ли удалить хранилище. Всегда нужно проверять экземпляры общедоступной папки перед удалением хранилища общих данных, а когда ESM в Exchange 2003 с пакетом обновления 2 (Sp2) отображает это предупреждение, не следует игнорировать его или пытаться его устранить. Вместо этого исправьте процесс удаления реплик.
Учтите, что до Exchange 2003 с пакетом обновления 2 (Sp2) сервер, удаляемый из списка реплик, отправляет запрос RDPSR только один раз. Если никто не отвечает, папка остается среди экземпляров общедоступной папки на неопределенное время, если не добавить хранилище в список реплик и опять его не удалить, что приведет к отправке нового запроса RDPSR. В версии 2003 Sp2 это поведение изменилось и хранилище повторяет попытку каждый час до получения сообщения RDPA от какого-нибудь узла.
Устранение неполадок
Процесс практически аналогичен устранению неполадок с процессом обратной засыпки.
1. Ожидающая удаления реплика отправила сообщение типа 0x20?
Если вы еще не включили ведение журнала при удалении реплики, вы не узнаете этого. К частью, можно просто добавить реплику в список и еще раз ее удалить. Затем найдите в журнале приложений сообщение 0x20.
2. Сообщение типа 0x20 дошло до других реплик?
Вы уже должны знать, что делать. Проверьте журналы приложений на других репликах, чтобы узнать, получили ли они сообщение 0x20.
3. Какая-нибудь другая реплика ответила сообщением типа 0x10?
В этой части вы, наверное, завершите выделение проблемы. Если реплика получила сообщение 0x20 от ожидающей удаления реплики, но не ответила сообщением типа 0x10, то удаляемая реплика содержит данные, которых нет в этой реплике. Так как вы только что получили сообщение 0x20 от этой реплики, вы также знаете, что она в курсе об отсутствующих данных. Поэтому можно ожидать отправки запроса обратной засыпки для этой папки каждые 24-48 часов. Изучите журнал приложений и выполните действия, описанные ранее для устранения неполадок процесса обратной засыпки.
4. Ожидающая удаления реплика получила сообщение типа 0x10?
После того, как другая реплика получит все нужные данные, эта реплика должна ответить сообщением 0x10. Когда удаляемая реплика получает это сообщение, она наконец-то удалить данные. Хотя это не означает, что данные будут удалены сразу же. Если какие-то клиенты используют эту реплику, она не будет удалена до последующего сеанса обслуживания. При необходимости этот процесс можно ускорить, отключив и заново подключив хранилище, чтобы отсоединить клиенты.
Распространенные проблемы
Вы можете обнаружить, что сервер отправил сообщение репликации какого-то типа другому серверу, но тот не записал входящее сообщение в журнал приложений. Однако отслеживание сообщения показывает, что оно было доставлено локально в хранилище на этом сервере. это обычно указывает на проблему с таблицей состояния репликации или проблему с разрешениями на виртуальном SMTP-сервере.
Сначала рассмотрим самый простой вариант. Проблема, из-за которой входящее сообщение репликации игнорируется принимающим сервером — это проблема с таблицей состояния репликации (ReplState). Учтите, что проблема с таблицей ReplState также может не позволять серверу отправлять запросы обратной засыпки (0x8) для некоторых папок, поэтому эта информация также применяется и к этой ситуации. Каждое хранилище общих данных использует собственную таблицу ReplState для отслеживания состояния репликации всех реплицируемых папок. Таблица содержит несколько строк для каждой папки, по одной строке для каждой реплики. Строки в таблице ReplState могут быть не синхронизированы со списком реплик, т. е. в таблице будут лишние строки или какие-то строки будут отсутствовать. Иногда ее можно синхронизировать, внеся изменение, например удалив сервер из списка реплик, применив изменение и сразу же добавить сервер в список, но такой подход не всегда работает. К счастью, тест таблицы ReplState был добавлен в команду isinteg. См. статью KB889331 для Exchange 2003 или статью KB892485 для Exchange 2000. Если у вас есть обновленные файлы isinteg.exe и store.exe, вы можете использовать команду isinteg для устранения проблемы с таблицей ReplState. Если выполнить только тестирование ReplState, процесс происходит очень быстро (меньше минуты даже для очень большого хранилища общих данных). После выполнения команды isinteg может потребоваться вернуться и внести изменение в папку, чтобы синхронизировать таблицу ReplState со списком реплик. После этого сервер должен обрабатывать входящие сообщения репликации или должен начать отправлять запросы обратной засыпки.
Еще одна распространенная проблема, из-за которой входящее сообщение репликации игнорируется, связана с Exchange 2003. Для сервера Exchange 2003 необходимо, чтобы у сервера, отправляющего сообщения, было право "Отправить как" на принимающем виртуальном SMTP-сервере. То есть если ServerA — Exchange 2003, а ServerB отправляет сообщение репликации PF на ServerA, то у ServerB должно быть право "Отправить как" на виртуальном сервере SMTP ServerA. В противном случае ServerA не обработает входящее сообщение репликации. Это разрешение обычно дается с помощью групп серверов домена Exchange. Если проблема заключается в праве "Отправить как", все входящие сообщения репликации от определенного сервера будут вызывать ошибку. Я думаю, что самый простой способ выявить эту проблему — выполнить трассировку сети при передаче сообщения репликации от одного сервера другому. Взаимодействие серверов при этом будет выглядеть следующим образом:
ServerA: 220 ServerA.microsoft.com служба Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Привет
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
Здесь важно, что ServerA должен объявлять о параметрах GSSAPI NTLM LOGIN. Если этих данных нет в ответе ServerA на сообщение EHLO, обычно это вызвано тем, что встроенная проверка подлинности Windows была отключена на виртуальном SMTP-сервере. Это указано на этапе 1 в статье KB843106 и этапе 3 статьи KB842273. Если эти команды проверки подлинности появляются, ServerB должен пытаться их использовать:
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI поддерживается
ServerB: <множество данных в формате base64>
ServerA: 334 <еще данные в формате base64>
ServerB: CRLF
ServerA: 235 2.7.0 Проверка подлинности выполнена успешно.
Если проверка подлинности не была выполнена успешно, возможно наличие проблемы с Kerberos или учетной записью компьютера для ServerB. Затем серверы передают информацию о состоянии связи. Затем они наконец переходят к передаче сообщения электронной почты:
ServerB: СООБЩЕНИЕ ОТ:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Допустимый отправитель
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Отправка двоичных данных
Для нас важен последний ответ в команде XEXCH50. Если ответ — "354 Отправка двоичных данных", то все в порядке (по крайней мере с разрешениями на виртуальном SMTP-сервере). Если параметры входа GSSAPI NTLM не были объявлены, попытка проверки подлинности закончилась неудачно, то ожидается, что ServerA ответит сообщением "504 Требуется проверка подлинности". Если эти действия выполнены успешно, но ServerA все равно передает сообщение "504 Требуется проверка подлинности" вместо "354 Отправка двоичных данных", то у ServerB нет права "Отправить как" на виртуальном SMTP-сервере ServerA. Это может произойти по нескольким причинам. Во-первых, при делегировании прав, таких как полные права администратора Exchange в ESM, этот пользователь или эта группа наследуют отказ в праве "Отправить как". Поэтому при использовании ESM для делегирования прав администратора учетной записи компьютера, группе серверов домена Exchange или другой группе с серверами Exchange репликация общедоступных папок будет нарушена. Еще один возможный вариант заключается в том, что учетная запись компьютера не входит в группу серверов домена Exchange, что необходимо для получения права "Отправить как". Необходимо изучить разрешения на виртуальном SMTP-сервере и определить, почему учетная запись компьютера для отправляющего сообщение сервера не обладает нужными правами. Дополнительные сведения о проблеме с сообщением "504 Требуется проверка подлинности" см. в статьях KB843106 и KB842273.
Заключение
Читая эту статью, вы могли заметить, что пакет обновления 2 (Sp2) для Exchange 2003 содержит несколько важных улучшений, связанных с предотвращением ошибок репликации и их исправлением. Для сред с несколькими хранилищами общих данных пакет обновления 2 (Sp2) будет очень полезен, особенно если дело доходит до перемещения реплик между серверами, а также добавления и удаления хранилищ общих данных.
Надеюсь, что эти сведения будут вам полезны. Спасибо Дейву Уитни (Dave Whitney) за редактирование этих материалов!
Это локализованная запись блога. Исходная статья доступна по адресу: Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems