パブリック フォルダーのレプリケーションのトラブルシューティング - パート 4: Exchange Server 2007/2010 でのヒント
原文の記事の投稿日: 2011 年 11 月 28 日 (月曜日)
US ブログへの最初の投稿日: 2008 年 1 月 11 日
2 年前、パブリック フォルダーのレプリケーションのトラブルシューティングに関する記事を 3 つのパートに分けて投稿しました。パート 1 (英語) では、新しいデータのレプリケーションについて説明し、パート 2 (英語) では、既存のデータのレプリケーションについて説明しました。最後のパート 3 (英語) では、レプリカ削除プロセスと Exchange 2003 で発生するいくつかの共通の問題について説明しました。今回の投稿は、内容を Exchange 2007 向けに更新することを目的とします。
Exchange 2007 でも、パブリック フォルダーのレプリケーションは、基本的に従来と同じ方法で動作します。この連載記事のパート 1 ～ 3 で解説したトラブルシューティングの手順は、Exchange 2007 環境に適用できます。ただし、管理ツールには変更があり、Exchange 2007 で見られる共通の問題はやや異なるので、ここに詳しく説明します。
管理ツールの変更
イベント ログは、レプリケーションの問題を単一障害点に絞り込むうえで、依然として最適なツールです。パート 1 (英語) で、Replication Incoming および Replication Outgoing のログのレベルを "最高" に設定することを推奨しました。これは Exchange 2007 についても当てはまります。ただし、Exchange 2007 では Set-EventLogLevel コマンドレットを使用して "MSExchangeIS\9001 Public\Replication Incoming Messages" と "MSExchangeIS\9001 Public\Replication Outgoing Messages" を "上級" レベルに設定します。
パート 2 (英語) では、ESM で Synchronize Hierarchy オプションと Synchronize Content オプションを使用して、状態メッセージを強制的に発行し、すべての未処理のバックフィル エントリをタイムアウトにする方法を説明しました。この操作は、Exchange 2007 でも Update-PublicFolderHierarchy コマンドレットと Update-PublicFolder コマンドレットを使用して行えます。これらのコマンドは、パブリック フォルダーのルートを選択したときに [階層の更新] として、特定のパブリック フォルダーを選択したときに [コンテンツの更新] としてそれぞれ現れます。これらはコマンド ラインで実行できるので、Exchange 2003 でのオプションよりもずっと柔軟に利用できます。たとえば、Exchange 2007 サーバーにレプリカがあるフォルダーのバックフィル エントリをタイムアウトにする操作は、単純な "Get-PublicFolderStatistics | Update-PublicFolder" コマンドを実行して非常に簡単に行えます。同じ操作を Exchange 2003 で行うには、何度もクリックを繰り返す必要がありました。
パート 3 (英語) では、パブリック フォルダー インスタンスを使用して、レプリカの削除が完了したかどうかを確認する方法について説明しました。Exchange 2007 では、Get-PublicFolderStatistics コマンドを使用してこれと同じ情報を取得できます。
Exchange 2007 での共通の問題
これまでの経験によると、最も共通して発生する現象はストア ドライバーの障害です。たとえば、バックフィル応答を Exchange 2007 サーバーに送信した後で 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 および 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 プロパティが本当の空ではなく空白 (1 文字のスペースなど) に設定されている場合です。この状態を確認するには、Outlook を開いて、アイテムを分類項目別に表示します。"なし" に分類されたアイテムが 2 組あることがわかるはずです。この問題を修正するには、Outlook を使用して、"なし" アイテムの分類項目をクリアします。場合によっては、他の分類項目にいったん設定してから "なし" に再設定する必要があります。Categories プロパティが本当にクリアされたら、表示される "なし" アイテムは 1 組だけになります。この状態にすると、アイテムのレプリケートは正常に行われます。
別の例:
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 を使用すると、これよりも発生頻度の高い共通の問題がもう 1 つ見つかる可能性がありますが、これはコンテンツに問題があって起こるものではありません。InboundFailures フォルダー内の TXT ファイルには、次のような出力が記録されます。
Microsoft.Exchange.Data.Storage.ConversionFailedException: コンテンツの変換の制限を超えました。
at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
at Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
at Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)
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
まず、1 行目の "コンテンツの変換の制限を超えました。" に注目してください。通常、パブリック フォルダー レプリケーション メッセージは長さの制限などに拘束されません。では、このようなエラーが起こる原因は何でしょうか。"isSenderTrusted" が False となっていることに注意してください。これは、認証されていない SMTP 接続を経由してメッセージが到達したことを意味します。送信元サーバーは、認証に失敗したか、認証そのものを試みませんでした。これは、パート 3 (英語) の「共通の問題」で説明した状況とよく似ています。この節では、認証の失敗によって Exchange 2003 で XEXCH50 動詞がエラーになることを説明しました。送信元サーバーが認証されなかったため、Exchange 2007 サーバーは通常の長さの制限をメッセージに適用します。これが 250 個を超える添付ファイルがあるコンテンツ レプリケーション メッセージである場合 (コンテンツ バックフィル応答ではこの長さは珍しくありません)、制限を超えるのでエラーになります。この状況が多く見られるのは、管理者が 2 つ目の受信コネクタを作成するときに、そのコネクタが認証を許可しないにもかかわらず、外部 IP ではなく内部 IP をリッスンするように構成した場合です。これが原因でなければ、パート 3 で説明した方法で Netmon キャプチャを使用して問題を調査する必要があります。
まとめ
Exchange 2007 環境で発生するパブリック フォルダー レプリケーションの問題を調査するために必要な知識は、これで十分なはずです。すべての以前のトラブルシューティング方法は、現在も適用可能です。使用する管理ツールに変更があり、発生する問題の種類が異なるだけです。この投稿がみなさんの参考になれば幸いです。
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips」をご覧ください。