Устранение неполадок, возникающих при репликации общедоступной папки. Часть 4. Советы для Exchange Server 2007/2010
Исходная статья опубликована 28 ноября 2011 г.
Исходная публикация в блоге: 11 января 2008 г.
Два года назад я опубликовал серию из трех частей, посвященную устранению неполадок, возникающих при репликации общедоступной папки. В 1-й части описывалась репликация новых данных, во 2-й части обсуждалась репликация существующих данных, а в 3-й части описывался процесс удаления реплик и некоторые распространенные проблемы, наблюдаемые в Exchange 2003. В этой статье я хочу представить сведения для Exchange 2007.
В Exchange 2007 репликация общедоступной папки происходит почти так же, как и всегда. Методы устранения неполадок, описанные в первых трех частях, также применимы. Однако средства администрирования изменились и распространенные проблемы в Exchange 2007 немного отличаются. Об этом я и поговорю в этой статье.
Изменения средств администрирования
Журнал событий — все еще лучшее средство для сужения области проблем с репликацией до определенной ошибки. В 1 части я предложил регистрировать входящие и исходящие сообщения репликации. Это справедливо и для Exchange 2007, только здесь командлет Set-EventLogLevel используется для установки уровня Эксперт для "MSExchangeIS\9001 Public\Replication Incoming Messages" и "MSExchangeIS\9001 Public\Replication Outgoing Messages".
Во 2 части я описал, как использовать параметры Синхронизация иерархии и Синхронизация содержимого в ESM для принудительной установки сообщения о состоянии и завершения всех незавершенных записей обратной засыпки. Это можно сделать и в Exchange 2007 с помощью командлетов Update-PublicFolderHierarchy и Update-PublicFolder. Они также доступны в средстве управления общедоступными папками Sp1: параметр Обновить иерархию появляется при выборе корневого узла "Общедоступные папки", а параметр Обновить содержимое появляется при выборе определенной общедоступной папки. Так как командлеты можно использовать в командной строке, они более гибкие, чем параметры Exchange 2003. Например, теперь можно очень просто завершить записи обратной засыпки для каждой папки с репликой на сервере Exchange 2007 с помощью команды "Get-PublicFolderStatistics | Update-PublicFolder". в Exchange 2003 это было возможно только после выполнения множества операций.
В 3 части я описал, как использовать экземпляры общедоступных папок, чтобы посмотреть, завершилось ли удаление реплики. В Exchange 2007 для этого используется команда Get-PublicFolderStatistics.
Распространенные проблемы в Exchange 2007
Самый распространенный симптом — сбой драйвера хранилища. Например, ответ обратной засыпки отправляется на сервер Exchange 2007, но если посмотреть журнал приложения на сервере, входящего события репликации вы не найдете. При отслеживании сообщений можно узнать, что сообщение репликации дошло до транспортного сервера-концентратора, а затем в драйвере хранилища произошел сбой.
Это может произойти по нескольким причинам, но, к счастью, это не так трудно исправить. Лучший метод в этом случае — использовать конвейерную трассировку и трассировка преобразования содержимого на транспортном сервере-концентраторе. Если выполнить команду "Get-TransportServer | fl", то можно увидеть ряд нужных настроек:
PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com
Чтобы узнать причину сбоя ответа обратной засыпки в драйвере хранилища, присвойте параметру PipelineTracingSenderAddress SMTP-адрес хранилища общедоступных папок, с которого отправляется запрос обратной засыпки. Затем задайте для параметра ContentConversionTracingEnabled значение $true, для параметра PipelineTracingEnabled — значение $true и воспроизведите проблему. После этого посмотри в папке, на которую указывает параметр PipelineTracingPath. Найдите вложенную папку ContentConversionTracing, а затем папку InboundFailures в ней. В папке InboundFailures содержится EML-файл с самим сообщением репликации и TXT-файл с информацией об ошибке. В начале TXT-файле часто указываются полезные сведения о причине ошибки.
Например, несколько раз мы встречали следующую информацию в этом TXT-файле:
Microsoft.Exchange.Data.Storage.PropertyValidationException: ошибка проверки свойства. Свойство = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Ошибка = недопустимый элемент 0 в свойстве с несколькими значениями.
В этом случае система жалуется на свойство Categories. Это происходит, если общедоступная папка содержит элементы, в которых свойство Categories содержит пробел, а не является пустым. Это можно увидеть, открыв Outlook и выбрав просмотр элементов по категории. Вы обнаружите два разных набора элементов со значением "Нет". Чтобы исправить ошибку, просто очистите категорию всех таких элементов с помощью Outlook. Может потребоваться задать другую категорию для элементов и затем опять присвоить им значение "Нет". После очищения свойства Categories у вас будет всего один набор элементов с категорией "Нет" и элементы можно будет успешно реплицировать.
Другой пример:
Microsoft.Exchange.Data.Storage.PropertyValidationException: ошибка проверки свойства. Свойство = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Ошибка = слишком длинный тип Email2AddrType: максимальная длина — 9, текущая длина — 35.
В этом случае свойство Email2AddrType отмечено как проблемное. Мы обнаружили, что оно было каким-то образом заполнено полными адресами электронной почты для определенных контактов, а не просто содержит тип адреса, как должно (например, "SMTP" или "EX"). Если исправить эту ошибку, репликация элементов выполняется без проблем.
Иногда сбой драйвера хранилища происходит без указания на определенное проблемное свойство, как в следующем примере:
Microsoft.Exchange.Data.Storage.ConversionFailedException: содержимое сообщения повреждено. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: ошибка преобразования из-за поврежденного TNEF (состояние нарушения: 0x00000800)
Вот на что похоже ошибка, при возникновении проблемы, описанной в статье базы знаний KB 936000. Если применить исправление на сервере Exchange 2003, создающем сообщение репликации, проблема будет устранена.
Важно отметить, что Exchange 2007 выполняет множество проверок свойств, чтобы поврежденные данные не попали в хранилище. Хотя это хорошо, это может помешать репликации данных общедоступной папки с серверов Exchange 2003, если проблема с содержимым не будет исправлена на сервере Exchange 2003. ContentConversionTracing позволяет идентифицировать такие проблемы и часто указывает на конкретное свойство, вызывающее ошибку.
Существует еще одна распространенная проблема, которую можно выявить с помощью ContentConversionTracing, но она не вызывается реальной ошибкой в содержимом. TXT-файл в папке InboundFailures при этом выглядит следующим образом:
Microsoft.Exchange.Data.Storage.ConversionFailedException: Превышен предел при преобразовании содержимого.
в Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
в параметрах Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
в параметрах Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions)
InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False
ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True
Во-первых, обратите внимание, что верхней строчке указано: "Превышен предел при преобразовании содержимого". Обычно в сообщении о репликации общедоступной папки нет предельных значений размера, так почему возникает эта ошибка? Обратите внимание, что значение "isSenderTrusted" равно False. Это означает, что сообщение поступило через SMTP-подключение, подлинность которого не была проверена. Сервер, отправивший сообщение, не смог пройти проверку подлинности или даже не пытался сделать это. Это очень похоже на то, что я описал в разделе "Распространенные проблемы" в 3 части, где ошибка проверки подлинности вызывает сбой команды XEXCH50 в Exchange 2003. Так как сервер, отправивший сообщение, не прошел проверку подлинности, сервер Exchange 2007 применяет стандартные пределы размера к сообщению. Если это сообщение о репликации содержимого с более чем 250 вложениями (что не так редко для ответа обратной засыпки содержимого), то ошибка возникает из-за превышения предела. Это часто происходит из-за того, что администратор создал второй соединитель получения, который не разрешает проверку подлинности, но он настроен так, что прослушивает внутренние IP-адреса, а не внешние. Если не это причина ошибка, может потребоваться использовать команду Netmon для выявления проблемы, как описано в 3 части.
Заключение
Вот и все, что нужно знать для сужения области поиска проблемы с репликацией общедоступных папок в среде с Exchange 2007. Все старые методы устранения неполадок также применимы. Теперь у нас есть другие средства администрирования и другие проблемы. Надеюсь, это будет вам полезно!
Это локализованная запись блога. Исходная статья доступна по адресу: Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips