Устранение неполадок, возникающих при репликации общедоступной папки. Часть 1. Устранение неполадок, возникающих при репликации новых изменений
Исходная статья опубликована 28 ноября 2011 г.
Исходная публикация в блоге: 17.01.06
Примечание. Эта запись блога — первая из серии статей, посвященной устранению неполадок, возникающих при работе с общедоступными папками. Также прочитайте 2, 3 и 4 части этой серии.
Введение
Цель этой серии статей — предоставить руководство по устранению неполадок, возникающих при работе с общедоступными папок. Здесь не говорится, как именно можно устранить все возможные проблемы с репликацией. Но здесь показано, как изолировать каждую из них и сконцентрироваться на основной причине ошибки. Другими словами, цель этих статей — перейти от описания, в котором говорится, например, о том, что содержимое старого сервера не реплицируется на новый сервер, к более узкой характеристике проблемы, описывающей, например, следующую ситуацию: "Старый сервер не отвечает на запросы состояния, отправляемые с нового сервера, поэтому новый сервер не знает об отсутствии данных и не пытается выполнить обратную засыпку. Это означает, что проблема фактически связана с работой старого сервера". В этой статье также описывается, как можно определить ряд наиболее распространенных проблем, возникающих при репликации. Перед тем, как перейти к подробным инструкциям по устранению неполадок, я бы хотел представить общий подход, который я использую для решения подобных проблем.
Лучшее средство для устранения неполадок, возникающих при репликации общедоступных папок, — использование журнала приложений. Чтобы изолировать проблему, необходимо изучить события репликации в журнале, чтобы точно узнать, где процесс нарушается. Обычно в начале следует включить ведение журнала диагностики для регистрации входящих и исходящих сообщений репликации. Каждый раз, когда хранилище отправляет или получает сообщение репликации, оно записывает событие в журнал (если ведение журнала включено). Различные виды сообщений можно отличать по параметру "Тип", показанному в описании события. Я предпочитаю сконцентрироваться на типе, а не коде события по следующим причинам.
- Коды события в разных версиях Exchange отличаются. Например, в Exchange 5.5 код исходящего запроса обратной засыпки — 3014. В Exchange 2000 и 2003 — это 3016.
- Коды входящих и исходящих событий отличаются для каждого типа. Код сообщения исходящей иерархии — 3018, а сообщения входящей иерархии — 3028.
- Запросы состояния и сообщения о состоянии используют одинаковые коды событий, хотя это два разных типа сообщений. Таким образом их нельзя отличить только по коду событий.
Если использовать тип, то становится проще. Вы можете легко сопоставить его с кодом события, изучив журнал приложений. Существует всего 7 типов, и вы можете увидеть, является ли сообщение исходящим или входящим, посмотрев на категорию события. Если фокусировать внимание на типах, а не кодах событий, нужно запомнить только следующие сведения:
иерархия — 0x2;
содержимое — 0x4;
запрос обратной засыпки — 0x8;
ответ обратной засыпки — 0x80000002 (для иерархии) или 0x80000004 (для содержимого);
состояние — 0x10;
запрос состояния — 0x20.
Также учтите, что регистрация ошибок репликации редко бывает полезной. Даже если репликация работает нормально, большинство серверов будут создавать много событий ошибок репликации, таких как событие 3093, указывающее на ошибку чтения свойства. В большинстве случаев свойство не влияет на репликацию, поэтому эту ошибку можно игнорировать. Я рекомендуется оставить для регистрации ошибок репликации значение "Нет", если вы не ищите что-то конкретное, например проблему, описанную в предыдущей записи блога.
Устранение неполадок, возникающих при репликации новых изменений
Для устранения проблем, возникающих при репликации общедоступных папок, сначала нужно ознакомиться со стандартным потоком сообщений при успешной репликации. На основе этих знаний вы можете определить точку возникновения ошибки. Перед описанием устранения неполадок с репликацией новых изменений опишем ожидаемое поведение системы.
Репликация иерархии
Репликация новых изменений иерархии происходит при каждом удалении или создании папки, а также изменении свойств общедоступной папки, например списка реплик, клиентских разрешений, описания, административного примечания или ограничений дискового пространства. Учтите, что к ним не относятся адреса электронной почты для папки с поддержкой почты. Адреса электронной почты хранятся в объекте каталога в Active Directory, поэтому их изменение не приводит к репликации иерархии. Только изменение свойств, хранимых в хранилище общих данных, инициирует репликацию иерархии.
Каждые 15 минут (по умолчанию), хранилище отправляет одно или несколько широковещательных сообщений о репликации иерархии с любыми изменения, внесенными в свойства папки. При максимальном уровне ведении журнала для исходящих сообщений репликации вы увидите событие, аналогичное следующему, на сервере, где была изменена иерархия:
Тип события: информация
Источник события: общее хранилище MSExchangeIS
Категория события: исходящие сообщения репликации
Код события: 3018
Описание:
Создано исходящее сообщение репликации.
Тип: 0x2
Код сообщения: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>
База данных "First Storage Group\Public Folder Store (BILONGEXCH1)"
Мин. CN: 1-72CF, макс. CN: 1-72D3
RFI: 1
1) FID: 1-6994, PFID: 1-1, смещение: 28
IPM_SUBTREE\NewFolder
Обратите внимание на строку "Тип: 0x2" в начале описания, указывающую на то, что это сообщение репликации иерархии.
Сообщение репликации иерархии отправлено с исходного сервера непосредственно во все другие хранилища общих данных. Концепции топологии для репликации новых изменений отсутствуют. Все изменения иерархии отправляются непосредственно с сервера, на котором изменения были внесены, на все другие серверы с хранилищем общих данных, связанным с той же иерархией. Каждый другой сервер должен записывать входящее событие в журнал с типом 0x2 при успешной обработке входящего сообщения.
Репликация содержимого
Репликация содержимого происходит, когда сообщение создается или удаляется, а также когда свойства сообщения изменяются. Время, когда хранилище отправляет широковещательные сообщения с изменениями содержимого папки, можно изменить, поменяв расписание репликации для этой папки, но по умолчанию широковещательная рассылка изменений выполняется каждые 15 минут, как и для иерархии. Сообщение репликации содержимого определяется типом 0x4 в описании события. Опять же, концепция топологии для широковещательной рассылки новых изменений отсутствуют. При изменении содержимого папки в определенной реплике она отправляет сообщение с типом 0x4 всем другим репликам папки. И опять же, каждый принимающий сервер должен записать в журнал входящее событие с типом 0x4 при успешной обработке входящего сообщения.
Действия по устранению неполадок
Это два самых простых сценария репликации. Если изменения иерархии или содержимого не доходят от одного сервера до другого, процесс устранения неполадок очень прост.
1. Сервер создал исходящее сообщение репликации?
Итак, вы изменили папку или добавили содержимое в папку на определенном сервере, но это же содержимое не изменилось на другом сервере. Первый вопрос, на который нужно получить ответ, — выполнил ли целевой сервер широковещательную рассылку изменений? При устранении неполадок важно отслеживать, с каким сервером вы работаете при внесении изменений. Для этого есть несколько способов. В ESM можно щелкнуть правой кнопкой узел общедоступной папки и выбрать команду "Подключить к", чтобы указать на определенное хранилище. В большинстве случаев ESM внесет все изменения в указанное хранилище, но помните об одном исключении — клиентские разрешения. До Exchange 2003 с пакетом обновления 2 (SP2) при изменении клиентских разрешений с помощью ESM, система ESM пыталась внести изменение в хранилище, в котором размещалась реплика папки, даже если это не было необходимо, так как разрешения хранятся как свойство папки в иерархии. В версии ESM 2003 с пакетом обновления 2 (SP2) это было изменено. При тестировании репликации иерархии за счет внесения изменений с помощью ESM следует избегать использования разрешений для тестирования, так как предсказать, какое хранилище изменится, будет трудно, если не используется ESM в Exchange 2003 с пакетом обновления 2 (SP2). Если используется Outlook и требуется проверить, какая реплика папки затрагивается, можно использовать MFCMAPI или аналогичное средство для просмотра свойства PR_REPLICA_SERVER папки. Таким образом вы увидите имя сервера, используемого Outlook для доступа к содержимому этой папки.
Если в расписании репликации для указанной папки задан параметр "Всегда" (что всегда справедливо для иерархии) и в течение 15 минут не видно исходящего сообщения с типом 0x2 или 0x4, это свидетельствует о том, что на исходном сервере, возникли какие-то неполадки. Если сервер не создает исходящие широковещательные сообщения репликации иерархии или содержимого, возможно, не удалось запустить агент репликации. Один из распространенных сценариев описан в статье KB272999. Здесь важно обратить внимание на событие 3079:
Код события: 3079
Источник: MSExchangeIS Public
Тип: ошибка
Категория: ошибки репликации
Описание:
Непредвиденная ошибка потока репликации 0x3f0.
EcGetReplMsg
EcReplStartup
FReplAgent
Это событие будет записано в журнал, даже если при подключении хранилища общих данных дополнительные параметры ведения журнала не были включены. Если событие 3079 содержит функцию "EcReplStartup", это значит, что не удалось запустить агент репликации и не будет выполняться широковещательная рассылка новых изменений до исправления проблемы и повторного подключения хранилища.
Репликация иерархии также уязвима к определенным проблемам с разрешениями, если в организации есть хранилища общих данных Exchange 5.5. Если сервер Exchange 2000 или 2003 отправляет сообщение репликации иерархии на сервер Exchange 5.5, он должен создать свойство ptagACLData (разрешения версии 5.5 на основе legacyExchangeDN) из свойства ptagNTSD (разрешения версии 2000 на основе SID). Это значит, что каждый SID необходимо преобразовать в legacyExchangeDN. Преобразование SID в legacyExchangeDN может завершиться ошибкой по несколькими причинам. Например, если SID разрешается до нескольких пользователей, может быть создано следующее событие:
Код события: 9528
Категория: общие
Источник: MSExchangeIS
Тип: ошибка
Описание:
Идентификатор SID S-1-5-21-408248388-469072634-37170099-1391 обнаружен в службе DS у 2 пользователей, поэтому хранилищу не удается сопоставить этот ИД безопасности с уникальным пользователем.
Пользователи:
/DC=com/DC=company/CN=Users/CN=User1
/DC=com/DC=company/CN=Users/CN=User2
Так как идентификатор SID нельзя преобразовать в legacyExchangeDN, хранилищу не удастся создать исходящее широковещательное сообщение репликации иерархии.
2. Сообщение адресовано серверу, который не получил изменение?
Если исходный сервер создал исходящее сообщение, следующий этап — убедиться в том, что оно адресовано серверу, который не получил данные. Самый простой способ проверки — отследить сообщение. При этом можно просто отследить код сообщения, указанный в исходящем событии репликации. В окне "Журнал сообщений" отображается строка "Кому:". Если хранилище, не получившее изменения, не указано здесь, сфокусироваться нужно на исходном сервере. Видит ли он данный сервер в организации? У этого сервера есть адреса электронной почты в объекте хранилища общих данных? Исходный сервер видит это хранилище в списке реплик рассматриваемой папки?
3. Сообщение дошло до конечного сервера?
Убедившись, что сообщение адресовано конечному серверу, нужно ответить на следующий вопрос — дошло ли сообщение до сервера? Это можно определить с помощью отслеживания сообщений. Если сообщение было доставлено в хранилище, но вы не видите входящего события репликации, соответствующего получению сообщения, см. раздел "Распространенные проблемы" в последней статье этой серии.
В следующей записи блога: Устранение неполадок, возникающих при репликации существующих данных.
Это локализованная запись блога. Исходная статья доступна по адресу: Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes