原文の記事の投稿日: 2011 年 12 月 5 日 (月曜日)
Exchange 2010 Service Pack 2 が今年中にリリースされると以前にお伝えしました (英語)が、ついにリリースされました。Exchange Server 2010 Service Pack 2 をダウンロードできるようになったことをお知らせします。
定期的なリリースの一環として Exchange の価値を継続的に高めることができるのはうれしいことであり、この Service Park での機能強化の多くは皆さんのフィードバックのおかげです。SP2 には、ハイブリッド構成ウィザード、アドレス帳ポリシー、Outlook Web App Mini、Outlook Web App 用のクロスサイト サイレント リダイレクトなどの機能、そしてお客様から要求のあった Service Pack 2 より前にリリースされた修正プログラムとロールアップが含まれています。
SP1 と同様に、Service Pack 2 は Exchange の完全なスリップストリーム版であり、13 のサーバー言語と 66 のクライアント言語 (英語を含みます) を単一のパッケージで利用できます。クライアントおよびサーバーの言語ごとに個別にダウンロードする必要はありません。ユニファイド メッセージングを使用している場合にだけ、個別の言語パックをダウンロードしてインストールする必要があります。
詳細な機能についてご確認 (英語)ください。または、SP2 をダウンロードしてご自分でお試しください。
また、マルチテナント環境での Exchange の内部設置型構成のサポートについてもお知らせしました。サポートの受け方について、いくつかのシナリオの概要と詳細なガイダンスを示したフォローアップ ブログを近いうちに公開する予定です。引き続きご注目ください。
あらためて、TAP に参加していただいた方々およびお客様には、貴重なフィードバックを提供していただいたことに心から感謝します。
Kevin Allisonゼネラル マネージャーExchange カスタマー エクスペリエンス
これはローカライズされたブログ投稿です。原文の記事は、「Released: Exchange Server 2010 SP2」をご覧ください。
原文の記事の投稿日: 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 環境で発生するパブリック フォルダー レプリケーションの問題を調査するために必要な知識は、これで十分なはずです。すべての以前のトラブルシューティング方法は、現在も適用可能です。使用する管理ツールに変更があり、発生する問題の種類が異なるだけです。この投稿がみなさんの参考になれば幸いです。
- Bill Long
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips」をご覧ください。
US ブログへの最初の投稿日: 2006 年 1 月 24 日
この記事は、パブリック フォルダーのレプリケーションの問題のトラブルシューティングに関する 3 番目の投稿です。最初の投稿 (英語)では、新しい変更のレプリケーションのトラブルシューティングについて説明しました。2 番目の投稿 (英語)では、既存のデータのレプリケーションのトラブルシューティングについて説明しました。連載記事の最後となるこの投稿では、レプリカの削除と共通の問題のトラブルシューティングについて説明します。トラブルシューティングの全体像を把握するには、すべての連載記事をお読みください。
レプリカの削除のトラブルシューティング
すべてのフォルダーのレプリカ一覧から古いサーバーを削除したのに、ESM でこの古いストアのパブリック フォルダー インスタンスに移動すると、一連のフォルダーがまだ残っています。この現象は、レプリカを削除するプロセスに問題があるために発生します。Exchange 2003 SP2 バージョンの ESM では、この状態にあるパブリック ストアを削除しようとすると、次のメッセージがダイアログ ボックスに表示されます。
“フォルダー レプリカが含まれているため、このパブリック フォルダー ストアを削除できません。データの損失を避けるには、パブリック フォルダー ストアを右クリックし、[すべてのレプリカを移動] をクリックしてレプリカを別のサーバーに移動してください。コンテンツが新しいサーバーに複製され、ローカル レプリカが削除されるまで、数時間かかることがあります。”
フォルダーのレプリカ一覧からストアを削除しても、そのストアからデータはすぐに削除されません。そうする代わりに、ストアから特別な 0x20 ステータス要求が他のすべてのレプリカに送信されます。この要求は、Replica Delete Pending Status Request (RDPSR) と呼ばれるものであり、アプリケーション ログでは通常のステータス要求と区別できません。RDPSR には、レプリカが削除保留中であることを示すフラグが含まれます。他のストアはこの 0x20 を受信すると、Replica Delete Pending Ack (RDPA) と呼ばれる特別な 0x10 で応答します。RDPA はデータの削除を了解したことを意味しますが、他のストアは削除保留中のレプリカが持つすべての CN がすでにある場合にのみこの 0x10 を送信します。レプリカが実際に削除されるのは、他のストアがデータを持つことを示す 0x10 を元のストアが受信した後のことです。
したがって、パブリック フォルダーが空になる前にストアを削除すると、データの損失を招く可能性があります。この操作に警告が表示されるのは、2003 SP2 ESM だけです。それ以前のバージョンでは、パブリック フォルダーを手動でチェックして、ストアを削除してもかまわないかを確認する必要があります。パブリック ストアを削除する場合は、そうする前に必ずパブリック フォルダー インスタンスをチェックしてください。2003 SP2 ESM の使用時にデータ損失の警告が表示された場合は、それを無視したり迂回しようとはしないで、レプリカ削除プロセスのトラブルシューティングを行う必要があります。
Exchange 2003 SP2 よりも前のバージョンでは、レプリカ一覧から削除されたサーバーは RDPSR を一度だけ送信します。これに応答がなければ、フォルダーはパブリック フォルダー インスタンスに無期限に残留します。これを削除するには、ストアをレプリカ一覧に追加してから再び削除して、新しい RDPSR が送信されるようにする必要があります。2003 SP2 では、この動作が変更され、いずれかのストアから RDPA が応答されるまで、1 時間間隔で再試行するように改められました。
トラブルシューティング
バックフィル プロセスをトラブルシューティングするときと、ほぼ同じ方法を使用します。
1. 削除保留中のレプリカは 0x20 を送信したか ?
レプリカを削除するときにログを有効にしていない限り、この動作は確認できません。幸い、レプリカを再び追加してから改めて削除することができます。そうした後で、アプリケーション ログをチェックして 0x20 を探します。
2. 0x20 は他のレプリカに到達したか ?
これはすでに確認できる状態になっているはずです。他のレプリカのアプリケーション ログをチェックして、0x20 が受信されたかどうかを確認してください。
3. 他のレプリカから 0x10 が応答されたか ?
恐らく、この動作を確認するために集中して取り組むことになるでしょう。レプリカが削除保留中のレプリカから 0x20 を受信したにもかかわらず 0x10 で応答しないのは、他のレプリカが持たないデータが削除保留中のレプリカにあることを意味します。他のレプリカが 0x20 を受信したということは、そのレプリカは欠落しているデータがどれなのかもすでにわかっているということです。したがって、そのフォルダーからのバックフィル要求が 24 ～ 48 時間以内に届くことが予想できます。アプリケーション ログを調べて、前に説明した手順に従って通常のバックフィル プロセスと同じ方法でトラブルシューティングを行います。
4. 削除保留中のレプリカは 0x10 を受信したか ?
他のレプリカにすべてのデータが渡ると、そのレプリカは 0x10 で応答します。削除保留中のレプリカは、この 0x10 を受信すると、最終的にデータを削除しようとします。ただし、データがすぐに削除されるわけではありません。このレプリカを使用するクライアントがある場合は、後でオンライン メンテナンスが行われるときまでデータは削除されません。データをすぐに削除する必要があれば、ストアのマウントの解除とマウントを行ってクライアントを切断することによって、処理を早めることができます。
共通の問題
サーバーがなんらかの種類のレプリケーション メッセージを別のサーバーに送信したにもかかわらず、受信側サーバーがこの受信メッセージをアプリケーション ログに残さないケースがあります。ただし、メッセージ追跡で調べると、メッセージがそのサーバーのストアにローカルに配信されたことがわかります。このような動作は、通常、 レプリケーション 状態 テーブルに問題があるか、SMTP 仮想サーバーにアクセス許可の問題があることを示します。
簡単なケースから先に説明しましょう。受信側サーバーで受信レプリケーション メッセージが無視される原因の 1 つは、 レプリケーション 状態 (ReplState) テーブルの問題です。ReplState テーブルに問題があると、一部のフォルダーに関してバックフィル要求 (0x8) が発行されないという別の問題も発生するため、以下の説明はこの現象の解明にも役立ちます。各パブリック ストアでは、複製されたフォルダーのレプリケーション状態を追跡するために ReplState テーブルが使用されます。このテーブルには、フォルダーごとに複数の行があり、これらの行のそれぞれが 1 つのレプリカを表します。ReplState テーブルの行がレプリカ一覧と同期しておらず、行が多いことや少ないことがあります。レプリカ一覧からサーバーを削除し、この変更を適用した後で、すぐにそのサーバーをレプリカ一覧に戻すことによって同期を回復できることもありますが、常にこの方法で対処できるとは限りません。幸い、ReplState テストの機能が isinteg に追加されました。詳細については、KB889331 (Exchange 2003 の使用時) または KB892485 (Exchange 2000 の使用時) を参照してください。更新された isinteg.exe と store.exe があれば、isinteg を使用して ReplState テーブルの問題を修正できます。ReplState テストのみを実行するのであれば、短時間で操作は完了します。大きなパブリック ストアでも 1 分かかりません。isinteg を実行した後でも、場合によっては手順をさかのぼってフォルダーを変更して、ReplState テーブルをレプリカ一覧に同期させる必要があります。これらが同期すると、サーバーは受信レプリケーション メッセージを処理したりバックフィル要求を通常どおりに発行できるようになります。
受信レプリケーション メッセージが無視されるもう 1 つの共通の問題は、Exchange 2003 の使用時に限り発生します。Exchange 2003 では、送信元サーバーが受信側 SMTP 仮想サーバーの "送信者" 権限を持つことが要求されます。つまり、ServerA が Exchange 2003 であり、ServerB が PF レプリケーション メッセージを ServerA に送信すると仮定した場合、ServerB は ServerA の SMTP 仮想サーバーの "送信者" 権限を持つ必要があります。それ以外の場合、ServerA は受信レプリケーション メッセージを処理しません。このアクセス許可は、通常、Exchange Domain Servers グループを介して付与されます。この "送信者" 権限の問題があると、特定のサーバーからのすべての受信レプリケーション メッセージは無視されます。レプリケーション メッセージがサーバー間で転送される間にネットワーク トレースを実行すると、この問題は簡単に識別できます。このとき、サーバー間で交わされるのは次のようなやり取りです。
ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Hello
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 仮想サーバーで有効になっていないからです。これについては、KB843106 の手順 1. と KB842273 の手順 3. で言及されています。これらの認証の動詞が含まれる限り、以下のように ServerB がそれらを使おうとすることが確認できます。
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI supported
ServerB: <一連の base64 エンコード データ>
ServerA: 334 <その他の base64 エンコード情報>
ServerB: CRLF
ServerA: 235 2.7.0 Authentication successful.
正しく認証されなかった場合は、Kerberos の問題が発生したか、ServerB 用のコンピューター アカウントに問題があると考えられます。次に、サーバーはリンク情報情報をやり取りします。その後で、ようやく電子メールの転送に取りかかることができます。
ServerB: MAIL FROM:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Send binary data
これが XEXCH50 動詞への最後の応答であり、重要なメッセージです。応答が "354 Send binary data" であれば、少なくとも SMTP 仮想サーバーへのアクセス許可に関しては、すべて順調だったとわかります。GSSAPI NTLM ログイン オプションがアドバタイズされなかったか、認証が失敗に終わった場合は、ServerA から "504 Need to authenticate" の応答があります。ここまでの手順が正しく完了したにもかかわらず、ServerA から "354 Send binary data" ではなく "504 Need to authenticate" の応答が返される場合は、ServerB が ServerA の SMTP 仮想サーバーの "送信者" 権限を持ちません。この状況が発生するシナリオは複数あります。たとえば、"Exchange 管理者 (完全)" などの権限を ESM で委任すると、そのユーザーまたはグループは "送信者" 権限の拒否を継承します。したがって、ESM を使用して管理者権限をコンピューター アカウントに委任すると、Exchange Domain Servers グループ、または Exchange Server が含まれるその他のグループは、パブリック フォルダーのレプリケーションを妨げます。別のシナリオとして考えられるのは、コンピューター アカウントが Exchange Domain Servers グループに含まれないことです。通常、コンピューター アカウントはこのグループに含まれることで "送信者" 権限を得ます。SMTP 仮想サーバーでのアクセス許可を評価し、送信元サーバー用のコンピューター アカウントが適切な権限を持たない原因を特定します。"504 Need to authenticate" 問題の詳細については、KB843106 および KB842273 を参照してください。
この記事を読んで気付かれた方もおられるでしょうが、Exchange 2003 SP2 には、レプリケーションの問題が起こることを防止し、それらの問題のトラブルシューティングに役立つ重要な機能強化がいくつか含まれます。複数のパブリック ストアがある環境では、SP2 の導入によって多大なメリットが得られます。特に、サーバー間でレプリカを移動したりパブリック ストアの追加や削除を行うときに効果が顕著です。
この記事が皆様のお役に立てば幸いです。査読に協力していただいた Dave Whitney に感謝します。
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems」をご覧ください。
US ブログへの最初の投稿日: 2006 年 1 月 20 日
このブログ投稿は、パブリック フォルダーのレプリケーション問題のトラブルシューティングに関する 2 番目のブログ投稿です。最初の投稿 (英語)では、新しい変更のレプリケーションのトラブルシューティングについて説明しました。このブログ投稿では既存のデータのレプリケーションのトラブルシューティングについて説明し、このシリーズの最後の投稿 (英語)では、レプリカの削除と共通の問題のトラブルシューティングについて説明します。全容を理解するには、すべての説明をお読みください。
既存のデータのレプリケーションのトラブルシューティング
新しい変更はレプリケートし、元からあって変更されなかったものはレプリケートしないと、バックフィルの問題が起こります。階層のバックフィルが発生する最も一般的な状況は、新しいパブリック ストアが作成される場合です。最も一般的なコンテンツのバックフィルのシナリオは、フォルダーのレプリカ リストにパブリック ストアが追加された場合です。
このようなバックフィルの問題が起きた場合、既に起きているかもしれませんが、簡単な対処法があります。すべてのアイテムを変更するのです。こうすることで、壊れたバックフィル プロセスを回避し、すべてのものを新しい変更としてレプリケートできます。通常、この目的で使用する両ツール (PFDAVAdmin および ModifyItems) を私自身が作成したのは事実ですが、一般には、バックフィル プロセスのトラブルシューティングを行い、根本的な原因を修正するのが最適です。すべてを変更してレプリケートする場合、レプリカが再び同期しなくなったときに、同じバックフィルの問題が繰り返される可能性があります。そこで、バックフィルの説明に移りましょう。バックフィル プロセスについて理解するには、最初に、変更の追跡方法について理解する必要があります。
ストア内のすべてのフォルダーとメッセージには、その作成時と変更のたびに変更番号 (CN) が割り当てられます。レプリケーションが発生すると、各オブジェクトの CN を使用し��、そのオブジェクトをレプリケートする必要があるかどうかが判断されます。CN のグループを、変更番号セット (CNSet) と呼びます。特定のサーバー上の特定のフォルダーの CNSet を、ステータス情報と呼びます。このステータス情報は、すべてのレプリケーション メッセージに含まれます。すべてのメッセージ タイプ 0x2 には、送信側サーバーの階層ステータスが格納されています。同様に、すべてのメッセージ タイプ 0x4 には、送信側サーバーの特定のフォルダーのステータス情報が格納されています。他のすべてのレプリケーション メッセージ タイプにも、対応するフォルダーのステータス情報が格納されています。
新しいパブリック ストアが初めてマウントされると、階層のステータス要求 (タイプ 0x20) が既存のすべてのパブリック ストアに送信されます。同様に、フォルダーのレプリカ リストに新しいストアが追加されると、そのフォルダーの他のすべてのレプリカに 0x20 が送信されます。すべてのレプリケーション メッセージのように、ステータス要求には、元のストアが持つ該当のフォルダー (または階層) の、すべての CN から成る CNSet が含まれており、他のストアに対して、元のストアが持っていない CN を持っている場合は応答するように求めます。Exchange 2003 SP2 より以前は、すべてのレプリカがステータス要求への応答を求められることはなく、元のストアにない変更があっても、ステータス要求を無視するストアもありました。2003 SP2 サーバーはすべてのレプリカから応答を要求し、元のサーバーが具体的に要求していない場合であっても、元のサーバーにない変更がある場合は、応答します。このため、バックフィル プロセス時に行われる判断が大きく向上します。ステータス要求に関して注目すべき点は、これにはレプリケートするデータが含まれていないことです。含まれているのは、変更番号のリストだけです。他のストアはステータス メッセージ (0x10) で応答しますが、これは、同じフォルダー (または階層) の各自の CNSet のリストです。元のサーバーは、0x10 メッセージを受信すると、中に含まれている CNSet を自身の CNSet と比較します。持っていない変更が 0x10 に含まれている場合、バックフィル プロセスが開始します。
バックフィル プロセスの最初の手順では、問題になっているフォルダーのバックフィル配列にエントリを追加します。これらのエントリは、不足している変更を示す CNSet 、および、不足データをストアがいつ要求するかを示すタイムアウト値を持ちます。バックフィル タイムアウトは、状況に応じて異なります。新しいパブリック ストアがオンラインになる場合や、フォルダーの新しいレプリカが追加される場合、初期のタイムアウトは 15 分です。
通常の操作の過程でも、バックフィル エントリがバックフィル配列に追加されることがあります。あるパブリック ストアが、2 つの別々の 0x2 メッセージで 2 つの変更をブロードキャストする場合を考えてみましょう。管理者が最初の 0x2 メッセージをキューから削除しましたが、2 番目のメッセージは通過するものとします。他のサーバーがこの 0x2 を受信し、ステータス情報内の CNSet に、受け取ったことがない CN が含まれていることに気が付きます。そのため、そのデータのバックフィル エントリを作成します。レプリケーションの通常の過程で検出された不足データのバックフィル エントリは、データが同じルーティング グループ (RG) 内にある場合は 6 時間のタイムアウトで開始し、異なる RG 内にのみある場合は 12 時間のタイムアウトで開始します。バックフィル要求が送信されるたびに、次のタイムアウトは、RG 内要求の場合は 12 時間、次は 24 時間になり、RG 間要求の場合は 24 時間と 48 時間になります。
ストアは、5 分ごとに、バックフィル エントリがタイムアウトに達したかどうかを確認します。タイムアウトに達すると、不足している CN についてバックフィル要求 (タイプ 0x8) が送信され、タイムアウトが次の間隔に設定されます。バックフィル要求はブロードキャストではありません。宛先は単一のサーバーです。これは、要求サーバーに送信したステータス情報で不足している CN があることを以前に示した、サーバーの 1 つです。そのサーバーが 0x8 を受信すると、直ちに要求を処理し、1 つまたは複数のバックフィル応答 (階層の場合は 0x80000002、コンテンツの場合は 0x80000004) で応答します。これには、要求された変更番号の実際のデータが含まれています。バックフィル要求と同様、バックフィル応答もブロードキャストではありません。要求サーバーにのみ送信されます。
要求サーバーが、受信したバックフィル応答を正しく処理すると、含まれていた CN はそのストア上のバックフィル配列からクリアされます。実際、受信メッセージに、バックフィル配列内の未処理の CN が含まれていると、その CN は配列からクリアされます。
ご覧のように、バックフィル プロセスをトラブルシューティングするには、多くの問いに答えていく必要があります。
1. ストアはデータが不足していることを理解していますか?
要求する必要がある変更を他のストアが持っていることをサーバーが理解しているかどうかを、最初に判断する必要があります。残念ながら、バックフィル配列を直接表示して、そこに何があるかを確認できるサポート ツールやユーティリティはありません。しかし、これを把握する間接的な方法はいくつかあります。
1 つの方法は、待つことです。データが不足していることをサーバーが理解していれば、少なくとも 24 時間または 48 時間に 1 回は要求が行われます。つまり、ログを調べて、0x8 メッセージが送信されたかどうかを確認するのです。該当のフォルダーの 0x8 が確認できず、しかし、他のフォルダーの 0x8 が確認できた場合は、未処理バックフィル制限に達した可能性があります。これについては、後述します。
もう 1 つの方法は、サーバーに最新のステータス情報を確実に受信させることです。サーバーは、新しいレプリカを追加した後に 1 回のみ、ステータス要求を送信します。その後、受信した唯一のステータス情報が、通常のレプリケーションの過程で使用されます。応答内の 0x20 または 0x10 が失われていたり、削除されたために、ステータスを取得しようとした最初の試みが失敗すると、その状態がいつまでも続き、場合によってはデータが不足していることを理解していない可能性があります。サーバーにフォルダーのステータス情報を確実に受信させるには、さまざまな方法があります。
- すべてのデータを持つサーバーに移動し、メッセージを追加、削除、または変更して、フォルダーを変更します。階層の場合は、フォルダーのプロパティを作成、削除、または変更します。その結果として生じる 0x4 または 0x2 には、該当のフォルダーまたは階層のステータス情報がそれぞれ含まれます。データが不足しているサーバーが、受信したレプリケーション メッセージを正常に処理すると、適切なエントリがバックフィル配列に追加されます。
- Exchange 2003 ESM の [コンテンツの同期] オプションを使用します。これはなかなか見つけにくいのですが、非常に役立つオプションです。このオプションを見つけるには、[パブリック フォルダー] ツリーの下に移動し、目的のフォルダーに移動します。左側のウィンドウでフォルダーを強調表示し、右側のウィンドウで [ステータス] タブをクリックします。すべてのデータを持っているサーバーを右クリックし、[コンテンツの同期] を選択します。これによって、2 つのことが行われます。サーバーはフォルダーのステータス要求 0x20 を送信し、すべてのバックフィル エントリが即時にタイムアウトされます。ここで、既にデータを持っているサーバーから [コンテンツの同期] を実行すると述べたことに注目してください。タイムアウトする必要があるバックフィル エントリを持っているのは別のサーバーなのに、なぜこのような操作を行うのか、疑問に思われるかもしれません。この時点では、データが不足しているサーバーに、バックフィルするものがあることを理解させているに過ぎません。そのために、データを持っているサーバーから [コンテンツの同期] を使用して、データを持っていないサーバーに 0x20 を送信するのです。ここでは、0x20 に対するステータス 0x10 応答の確認は、あまり問題ではありません。コンテンツが不足しているストアが、コンテンツを持つストアからフォルダーのレプリケーション メッセージを受信し、適切なエントリをバックフィル配列に追加できることが重要です。データを持つサーバーからの 0x20 が、この役割を担います。Exchange 2003 SP2 では、[パブリック フォルダー] ノード自体を右クリックすることで、階層について [コンテンツの同期] を使用できます。
- Replication Flags レジストリ値 (KB813629) を使用します。この値と、KB321082 (英語) に記載されている Enable Replication Messages At Startup 値を適切に設定すると、ストアは、スタートアップ時にすべてのフォルダーについてステータス要求 0x20 を送信します。この場合も、コンテンツを持つサーバーでこの操作を行う必要があります。この手順のポイントは、コンテンツを持つサーバーが、そのステータス情報を、コンテンツが不足しているサーバーに送信することです。
- 2003 ESM を使用して、バックフィル応答を送信します。2003 SP1 では、[階層の送信] オプションを使用して階層のバックフィル応答を送信し、[コンテンツの送信] オプションを使用してフォルダー コンテンツのバックフィル応答を送信できました。2003 SP2 では、この 2 つのオプションが、[変更内容の再送信] になりました。このオプションは、指定するデータ範囲のバックフィル応答を送信します。ただし、データ範囲全体を指定すべきではないでしょう。その場合、未処理のバックフィル エントリがすべて該当し、元の問題の対処に終始することになるためです。代わりに、1 日または 2 日のみの範囲を指定します。これによって 0x80000002 または 0x80000004 がターゲット サーバーに送信され、ここでも、データを持つストアのステータス情報を与えるという役割が果たされます。
上記の方法のいずれかを使用してステータス情報を強制的に送信し、データが不足しているストアがメッセージを受信したことをアプリケーション ログで確認できれば、データの不足を理解していることになります。
2. ストアが不足データを要求していますか?
データをバックフィルする必要があることをストアに理解はさせましたが、では、バックフィル要求は送信されているでしょうか。データのバックフィルが何回か行われると、次のバックフィル要求まで、24 時間または 48 時間待機しなければならない可能性があります。この値はそれぞれ、サイト内バックフィルおよびサイト間バックフィルの最長のタイムアウト間隔です。これをスピードアップする方法が 1 つあります。前述の [コンテンツの同期] を使用するのですが、今回は、データが不足しているサーバーからこれを使用します。これにより、そのフォルダーのバックフィル エントリが即時にタイムアウトします。しかし、それでも、目的のフォルダーのバックフィル要求をストアが送信しない場合があります。その場合は、次の 24 ～ 48 時間のアプリケーション ログを調べます。ストアが他のフォルダーのバックフィル要求は送信するのに、目的のフォルダーのバックフィル要求は送信しない場合は、未処理バックフィル制限に達した可能性があります。
多数のフォルダーのレプリカを新しいストアに追加した場合、レプリケーションが最初は順調でも、1 日か 2 日経つと動作しなくなる場合は、未処理バックフィル制限に達している可能性があります。未処理バックフィル制限とは、レプリケーションの調整を目的とするメカニズムです。既定では、ストアが許可する未処理のバックフィル要求は一度に 50 のみです。50 件 の未処理があると、解決されるまで、その 50 件が繰り返し再要求されます。1 つの未処理エントリが解決されると、OBL 内のスロットが解放され、新しいデータ セットが要求されます。つまり、50 件の要求が何らかの理由でその解決に問題がある場合、レプリケーションが処理されません。
このような状態になった場合は、アプリケーション ログを調べて、ストアが何を要求しているかを確認してください。現在の 50 件の未処理のバックフィル要求について 0x8 メッセージが断続的にあり、バックフィル応答は受信していない場合、それが未処理の原因です。その時点で、ストアが現在バックフィルを試みているフォルダーの 1 つをトラブルシューティングすることに、意識を変える必要があります。その問題を解決することで、他のフォルダーに進むことができます。
もう 1 つの方法は、未処理バックフィル制限 (OBL) を増やすことです。これは、該当のストアのレジストリ キーの下に、Replication Oustanding Backfill Limit という名前のレジストリ値を作成することによって行うことができます。最大値は 5000 (10 進) です。ただし、これを行うと、レプリケーションの歯止めが解かれ、問題を引き起こした 50 フォルダーを決定するのが困難になります。状態が再び落ち着くまで、トラブルシューティングを先延ばしにする必要があるでしょう。一般には、制限値を増やして対処するよりも、制限値は 50 のままにして問題を修正することをお勧めします。
OBL が問題とは思えない場合、および、問題となっているフォルダーの送信 0x8 メッセージがやはりない場合は、このシリーズの最後の投稿 (英語)の「共通の問題」を参照してください。
3. 他のストアが要求に応答していますか?
バックフィル要求に注目したら、バックフィルのターゲットが要求を受け取ったかどうかを判断する必要があります。そのサーバーのアプリケーション ログで、受信した 0x8 を確認します。アプリケーション ログで、送信側からの送信イベントに示されているメッセージ ID を検索することもできます。アプリケーション ログに記録がない場合は、メッセージ追跡を使用して、その行方を確認します。0x8 を受け取った場合は、1 つ以上の 0x80000002 メッセージまたは 0x80000004 メッセージでほぼ即時に応答する必要があります (多くの場合、1 つのバックフィル要求に対して複数のバックフィル応答が存在します。これは、変更がすべて 1 つのメッセージで送信されるとは限らないからです)。もちろん、バックフィル応答メッセージを生成するのにかかる時間は、フォルダー内のデータとレプリケーション メッセージのサイズ制限によって異なります。たとえば、レプリケーション メッセージの最大サイズが 1 GB に設定されている場合、応答サーバーは階層全体を 1 つのバックフィル応答にまとめようとするため、まとめるだけで 1 時間以上かかる可能性があります。
4. 要求サーバーが応答を受け取っていますか?
次に、要求サーバーのアプリケーション ログで、バックフィル応答を受信したかどうかを調べます。受信していない場合は、メッセージを追跡して、その行方を確認します。バックフィル応答を受信しており、アプリケーション ログに記録されている場合、バックフィル要求は対処されており、次に進むことができるはずです。
前述のように、メッセージ追跡ではこれらのメッセージの 1 つがストアに送信されたことが示されているのに、アプリケーション ログにはレプリケーション メッセージの受信の記録がない場合は、このシリーズの最後の投稿 (英語)の「共通の問題」を参照してください。
次回のブログ投稿は、「レプリカの削除と共通の問題のトラブルシューティング (英語)」です。
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data」をご覧ください。
US ブログへの最初の投稿日: 2006 年 1 月 17 日
注: このブログ投稿は、パブリック フォルダーに関するトラブルシューティング シリーズの第 1 回です。同シリーズのパート 2 (英語)、パート 3 (英語)、およびパート 4 (英語) もご覧ください。
はじめに
このブログ記事は、パブリック フォルダーのレプリケーションの問題に関するトラブルシューティング ガイドを提供することを目的としています。発生する可能性のあるあらゆるレプリケーション関連問題の解決方法を示すものではありません。ここでは、発生する可能性のあるレプリケーション関連問題の発生源を集中的にトラブルシューティングできるように、問題箇所を特定する方法について説明します。たとえば、「古いサーバーの内容が新しいサーバーにレプリケートされない」という問題の記述を、「新しいサーバーからのステータス要求に古いサーバーが応答しないので、新しいサーバーはデータの欠落を認識せず、バックフィルを試行しない。つまり、問題の原因は古いサーバーにある」という記述にまで絞り込めるようにすることを目的としています。また、特に発生しやすいレプリケーション関連問題の見分け方についても説明します。トラブルシューティングの詳しい説明に進む前に、まず、このような問題への全般的アプローチについて概要を説明します。
パブリック フォルダーのレプリケーションのトラブルシューティングに最も役立つツールはアプリケーション ログです。レプリケーション関連の問題を特定するには、ログでレプリケーション イベントを追跡して、プロセスにおける問題発生場所を正確に知る必要があります。通常、トラブルシューティングはまず、レプリケーション受信 (Replication Incoming) およびレプリケーション送信 (Replication Outgoing) の診断ログを [最大] に設定して開始します。ストアがレプリケーション メッセージを送信または受信するたびに、そのイベントがログに記録されます (ログ記録を設定した場合)。レプリケーション メッセージのさまざまな種類は、イベント記述の "種類" で区別できます。次のような理由から、イベント ID より種類に注目します。
- イベント ID は Exchange のバージョンごとに異なります。たとえば、Exchange 5.5 では送信バックフィル要求のイベント ID は 3014 でした。Exchange 2000 および 2003 では 3016 です。
- 受信と送信のイベント ID は種類ごとに異なります。送信階層メッセージのイベント ID は 3018 ですが、受信階層メッセージのイベント ID は 3028 です。
- ステータス要求とステータス メッセージはそれぞれ別の種類のメッセージですが、どちらにも同じイベント ID が使用されます。つまり、イベント ID だけではこの 2 つを区別できません。
種類に注目すると、少し簡単になります。関連するイベント ID はアプリケーション ログで簡単に調べることができます。種類は 7 つのみであり、送信メッセージと受信メッセージの区別はイベントのカテゴリで確認できます。イベント ID より種類に注目する場合は、次のものを覚えるだけで済みます。
階層 - 0x2 内容 - 0x4 バックフィル要求 - 0x8 バックフィル応答 - 0x80000002 (階層) または 0x80000004 (内容) ステータス - 0x10 ステータス要求 - 0x20
階層 - 0x2
内容 - 0x4
バックフィル要求 - 0x8
バックフィル応答 - 0x80000002 (階層) または 0x80000004 (内容)
ステータス - 0x10
ステータス要求 - 0x20
また、レプリケーション エラー (Replication Errors) のログ記録はあまり有用ではありません。ほとんどのサーバーでは、レプリケーションが正常に動作していても多くのレプリケーション エラー イベントが生成されます。たとえば、プロパティの読み取り時にエラーがあったことを示すイベント ID 3093 などです。ほとんどの場合、プロパティはレプリケーションに影響しないので、このエラーは無視できます。以前のこちらのブログ記事 (英語)で説明しているような特定の問題を調べる場合を除き、レプリケーション エラーのログ記録は [なし] にすることをお勧めします。
新しい変更のレプリケーションのトラブルシューティング
パブリック フォルダーのレプリケーションのトラブルシューティングを行うには、まず、レプリケーションの正常動作時のメッセージ フローをよく把握している必要があります。その知識に基づいて問題の発生場所を特定できます。新しい変更のトラブルシューティングについて説明する前に、まず、正常動作について説明します。
階層のレプリケーション
階層の新しい変更のレプリケーションが実行されるのは、フォルダーの作成または削除、あるいはパブリック フォルダーのプロパティ (レプリカ一覧、クライアントのアクセス許可、説明、管理メモ、格納域の制限など) の変更が行われたときです。電子メールが有効なフォルダーの電子メール アドレスは、これに含まれないので注意してください。電子メール アドレスは Active Directory のディレクトリ オブジェクトに格納されるので、これを変更しても階層のレプリケーションは実行されません。階層のレプリケーションが実行されるのは、パブリック ストア自体に格納されているプロパティが変更されたときのみです。
フォルダー プロパティの変更は、(既定では) 15 分ごとに、ストアから 1 つまたは複数の階層レプリケーション メッセージでブロードキャストされます。レプリケーション送信 (Replication Outgoing) のログを [最大] に設定している場合、階層が変更されたサーバーでは次のようなイベントが記録されます。
イベントの種類: 情報 イベント ソース: MSExchangeIS パブリック ストア イベント カテゴリ: Replication Outgoing Messages イベント ID: 3018 説明: 送信レプリケーション メッセージが発行されました。 種類: 0x2 メッセージ ID: <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
イベントの種類: 情報
イベント ソース: MSExchangeIS パブリック ストア
イベント カテゴリ: Replication Outgoing Messages
イベント ID: 3018
説明:
送信レプリケーション メッセージが発行されました。
種類: 0x2
メッセージ ID: <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 受信イベントのログが記録されます。
トラブルシューティングの手順
レプリケーションの最も基本的なシナリオは 2 種類あります。階層または内容の新しい変更が、あるサーバーから別のサーバーへ反映されない場合、トラブルシューティングは単純です。
1. サーバーは送信レプリケーション メッセージを生成したか
たとえば、フォルダーに変更を加えた場合、または特定のサーバーのフォルダーに内容を追加した場合、その内容が他のサーバーに反映されなかったとします。最初に確認することは、その対象サーバーから変更がブロードキャストされていたかどうかです。トラブルシューティングを行うときは、変更時にどのサーバーで作業していたかを追跡することが重要です。これを調べるにはいくつかの方法があります。ESM では、パブリック フォルダーのノードを右クリックし、[接続先] をクリックして特定のストアを指定します。ほとんどの場合、指定したストアに対して変更が行われますが、クライアントのアクセス許可だけは例外です。Exchange 2003 SP2 より前のバージョンでは、クライアントのアクセス許可を変更した場合、アクセス許可は階層内のフォルダーのプロパティとして格納されてレプリケーションは不要であるにもかかわらず、ESM はフォルダーのレプリカが格納されているストアに変更を行おうとします。ESM 2003 SP2 ではこの動作が変わり、指定した階層に変更が行われます。2003 SP2 以降の ESM を使用しない限り、クライアントのアクセス許可の変更がどのストアに対して行われるか予測できないので、ESM で変更を加えて階層のレプリケーションをテストする場合は、クライアントのアクセス許可を使用しないようにしてください。Outlook を使用している場合にフォルダーのどのレプリカが対象であるか確認するには、MFCMAPI などのツールを使用してフォルダーの PR_REPLICA_SERVER プロパティを調べます。このプロパティは、Outlook がそのフォルダーの内容にアクセスするために使用するサーバーの名前を示します。
問題のフォルダーのレプリケーション スケジュールが [常に] に設定されており (階層の場合は常にこの設定になります)、送信 0x2 または 0x4 が 15 分間発生していない場合は、元のサーバーに問題があることを意味しています。サーバーから送信階層ブロードキャストまたは送信内容ブロードキャストが生成されない場合は、レプリケーション エージェントが開始に失敗している可能性があります。よくあるシナリオの 1 つは、KB272999 で説明されているシナリオです。この場合、次のような 3079 イベントに注意してください。
イベント ID: 3079 ソース: MSExchangeIS パブリック 種類: エラー カテゴリ: Replication Errors 説明: 予期しないレプリケーション スレッド エラー 0x3f0 が発生しました。 EcGetReplMsg EcReplStartup FReplAgent
イベント ID: 3079
ソース: MSExchangeIS パブリック
種類: エラー
カテゴリ: Replication Errors
予期しないレプリケーション スレッド エラー 0x3f0 が発生しました。
EcGetReplMsg
EcReplStartup
FReplAgent
このイベントは、パブリック ストアのマウント時に追加ログ記録を設定していなくても記録されます。3079 に "EcReplStartup" が含まれている場合は、レプリケーション エージェントが開始に失敗しており、問題を解決してストアをマウントし直さないと新しい変更はブロードキャストされないことを示しています。
階層のレプリケーションの場合も、組織に Exchange 5.5 パブリック ストアがあると、アクセス許可の問題が発生する可能性があります。Exchange 2000 または 2003 のサーバーは、Exchange 5.5 サーバーに階層レプリケーション メッセージを送信するとき、ptagNTSD プロパティ (2000 形式の SID ベースのアクセス許可) から ptagACLData プロパティ (5.5 形式の legacyExchangeDN ベースのアクセス許可) を生成する必要があります。つまり、各 SID を legacyExchangeDN に変換する必要があります。SID から legacyExchangeDN へのこの変換は、いくつかの原因によって失敗することがあります。たとえば、1 つの SID が複数のユーザーに該当する場合、次のようなイベントが発生することがあります。
イベント ID: 9528 カテゴリ: General ソース: MSExchangeIS 種類: エラー 説明: DS 内の 2 人のユーザーから SID S-1-5-21-408248388-469072634-37170099-1391 が見つかったため、この SID を一意なユーザーにマップすることができません。 次のユーザーが含まれます: /DC=com/DC=company/CN=Users/CN=User1 /DC=com/DC=company/CN=Users/CN=User2
イベント ID: 9528
カテゴリ: General
ソース: MSExchangeIS
DS 内の 2 人のユーザーから SID S-1-5-21-408248388-469072634-37170099-1391 が見つかったため、この SID を一意なユーザーにマップすることができません。
次のユーザーが含まれます:
/DC=com/DC=company/CN=Users/CN=User1
/DC=com/DC=company/CN=Users/CN=User2
この場合、SID を legacyExchangeDN に変換できず、ストアは送信階層ブロードキャスト メッセージの生成に失敗します。
2. 変更を受信しなかったサーバー宛にメッセージが送信されているか
元のサーバーで送信メッセージが生成されていた場合、次のステップは、データを受信しなかったサーバーにそのメッセージが送信されていることを確認します。これを確認する最も簡単な方法は、メッセージを追跡することです。メッセージ追跡では、送信レプリケーション イベントでレポートされたメッセージ ID を追跡します。[メッセージの履歴] ウィンドウに表示される [宛先] 行を確認します。変更を受信しなかったストアがここに表示されていない場合は、元のサーバーに問題があると考えられます。元のサーバーは組織のそのサーバーを参照していますか。そのサーバーではパブリック ストア オブジェクトに電子メール アドレスを格納していますか。元のサーバーでは、問題のフォルダーのレプリカ一覧でそのストアを指定していますか。
3. メッセージは配信先サーバーに届いたか
メッセージが配信先サーバー宛に送信されていることを確認したら、次に確認することは、メッセージがそのサーバーに届いたかどうかです。これはメッセージ追跡で確認できます。メッセージ追跡ではメッセージがそのストアへ配信されたことが示されているのに、メッセージを確認したという受信レプリケーション イベントが記録されていない場合、このシリーズの最終回の記事 (英語)の「共通の問題」を参照してください。
次回のブログ投稿は「既存のデータのレプリケーションのトラブルシューティング (英語)」です。
これはローカライズされたブログ投稿です。原文の記事は「Public Folder Replication Troubleshooting ? Part 1: Troubleshooting the Replication of New Changes」をご覧ください。
原文の記事の投稿日: 2011 年 10 月 31 日 (月曜日)
Exchange チームにとって、お客様からいただく自分たちの活動のよかった点や改善点についてのフィードバックは、いつでも重要なものです。Exchange 2007 では、Exchange 2003 の OWA 機能に関する最大の要求の 1 つにお応えして、WebReady ドキュメント表示 (英語)を導入しました。これにより、OWA ユーザーは、添付されている Microsoft Office ドキュメントおよび PDF を、ディスクに保存したり、ローカルにインストールされているアプリケーションで開いたりしなくても、Web ブラウザーでプレビューできます。この機能は Exchange 2010 でも引き続き提供されていますが。デスクトップの Office クライアント アプリケーションで表示すると、Office ドキュメントのテキストと書式設定が元のドキュメントと異なる場合があるというフィードバックをたくさんいただきました。
うれしいことに、Exchange Online での OWA に対する更新により、Office Web Apps (英語) が Word、Excel、PowerPoint ファイルの添付ファイル プレビュー エクスペリエンスに統合されるようになりました。引き続きサポートされる PDF と併せて、Exchange Online のユーザーは、作成時とまったく同じ形式で表示された Office ドキュメントの高品質のプレビューを、Web で見ることができます。WebReady ドキュメント表示はドキュメントの簡単なプレビューに最適であり、ドキュメントを編集する必要がある場合は、1 回クリックするだけで Office Web App からファイルを Office のデスクトップ クライアントで簡単に開くことができます。
Office ドキュメントの添付ファイルの横に表示される [ブラウザーで開く] をクリックして、Exchange Online のこの機能を使ってみてください。
David Alexander、Kartik Murthy
これはローカライズされたブログ投稿です。原文の記事は、「Introducing Office Web App Integration with Outlook Web App in Exchange Online」をご覧ください。
原文の記事の投稿日: 2011 年 11 月 9 日 (水曜日)
以前、サポータビリティ プログラム マネージャーの Nino Bilic とチャットしているときに、ちょっと気がかりなことを聞きました。つまり、プレミア カスタマーが Exchange 2010 で重大な状況になる第 1 の理由は、トランザクション ログ LUN でのディスク領域の不足によるメールボックス データベースのマウント解除だというのです。
そのことについてしばらくじっくり考えてみました。当然のことながらびっくりしました。正直に言えば、私は Mailbox Requirements Calculator と TechNet でのガイダンスについて考えたことがあり、この問題は今頃はもう解決していたはずなのです。この情報を共有した後で、(彼ではなく) この私がトランザクション ログの容量計画に関するブログ記事を書くことになりました (ありがとう、Nino!)。
トランザクション ログの LUN のサイズを適切に決定するには、環境についていくつかのことを理解する必要があります。
この説明では、各データベースに 250 のメールボックスが格納されるものとします。各メールボックスは毎日 150 のメッセージを送受信し、メッセージの平均サイズは 100KB であるものとします。「メールボックス データベースおよびログの容量の要因について」の表によると、150 のメッセージ プロファイルと 75 KB の平均メッセージ サイズでは、1 日 (24 時間) あたり 30 のトランザクション ログが生成されることがわかります。ここでのメッセージ サイズは 75 KB より大きいので、メールボックス生成ごとのトランザクション ログではそのことを考慮する必要があります。ガイダンスでは次のように規定されています。
メッセージの平均サイズが 2 倍の 150 KB になった場合、メールボックスごとに生成されるログは 1.9 倍に増えます。この値は、添付ファイルとメッセージ テーブル (メッセージ本文と添付ファイル) を含むデータベースの割合を表します。
したがって、100 KB の平均メッセージ サイズによる影響は、次の式で求めることができます。
150 / 1.9 = [プロファイルの平均メッセージ サイズ] / x
x = (100 * 1.9) / 150
x = 1.266666666666667 ~ 1.27
つまり、メッセージのサイズが基準より 25 KB だけ大きいと、1 つのメールボックスで 1 日に生成されるトランザクション ログの数は、1.27 倍に増加します。したがって、"30 トランザクション ログ * 1.27 = 39 トランザクション ログ/日/メールボックス" となります。これは、250 メールボックスのデータベースの場合は、各データベースで "39 * 250 = 9,750 メールボックス生成トランザクション ログ/日/データベース" となることを意味します。
メールボックスの移動によっても、トランザクション ログが生成されます。移動先のデータベースに移動されるメールボックスごとに、メールボックスのサイズ (回復可能なアイテム フォルダーの内容を含みます) にほぼ匹敵するログが (移動元ではなく移動先に) 生成されます。たとえば、1 日に 1% のメールボックスが移動されると、データベースに移動されるメールボックスは毎日 2.5 個になります。各メールボックスの平均サイズが 5.4 GB とすると (1 つのアイテムの回復が有効な状態で 14 日間の削除済みアイテムの保持を含みます)、"2.5 * 5.4 GB/1024 = 13,888 メールボックス移動トランザクション ログ/日/データベース" となります。
バックアップ/復元の観点からは、使用するバックアップ アーキテクチャの種類を考慮する必要があります。バックアップのシナリオごとに、メールボックス生成トランザクション ログの容量の観点から準備する必要のある、推奨される追加日数があります。余分な領域を用意することで、停止状態に苦しめられずに複数の障害に耐えることができます。トランザクション ログの切り捨ての詳細については、「バックアップ、復元、および障害復旧について」を参照してください。
当然のことながら、他にも考慮する必要のあるシナリオがあります。たとえば、2 つのデータセンターにまたがるデータベース可用性グループ (DAG) を展開している場合は、2 つのデータセンター間のネットワーク リンクが機能していて、データベースのコピーが正常な場合にのみ、ログの切り捨てが行われます。WAN リンク停止の修復に 5 日かかることがわかっている場合は、それを考慮してバックアップ障害保護を調整する必要があります。
このブログのシナリオでは、切り捨ての障害に 3 日だけ耐えられるようにすればよいものとします。つまり、メールボックス生成トランザクション ログのために必要なディスク領域は、9,750 / 1024 * 3 = 28.5 GB です。
さらに、1 週間のメールボックス移動イベントのために必要なディスク領域を考慮する必要があります。このブログのメールボックス移動操作の場合は、13,888 / 1014 * 7 日 = 94.9 GB です。
まとめると、トランザクション ログのために各データベースで必要なディスク領域は 123 GB です。また、説明されてはいなくても発生する可能性のある状況を考慮して、データ オーバーヘッドの要素を含める必要があり、トランザクション ログのディスク領域は 123GB * 1.2 = 148 GB になります。
トランザクション ログに専用の LUN を展開し、LUN に 150 GB 確保しないと、バックアップの障害が発生して多くのメールボックス移動が行われた場合、ディスク領域をすべて使用してしまう可能性があります。通常は、ディスク容量の 80% だけが使用されるように、各 LUN を準備します。その場合の式は次のようになります。
LUN 領域 = [予想されるディスク領域使用量] / (1 – [望ましい空き領域の割合])
LUN 領域 = 148 GB / (1 – 0.2) = 148 GB / 0.8 = 専用トランザクション ログ ボリュームに 185 GB の LUN
データベースと同じ LUN にトランザクション ログを展開する場合は、トランザクション ログに必要なディスク領域とデータベースに必要なディスク領域を単純に加えて、[予想されるディスク領域使用量] の値を求めます。
まず最初に、環境の基準値を求めて、標準的な 1 日あたりのログ生成量を特定する必要があります。さらに、監視機能を設定し、警告が発生した場合にはそれに対処する必要があります。監視機能では次のシナリオを監視する必要があります。
友人の Mike Lagase が、http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (英語) でこのシナリオのトラブルシューティング方法について優れた記事を書いています (この記事は Exchange 2007 について書かれており、一部のツールや推奨事項は Exchange 2010 には該当しないことに注意してください)。Mike が示している手順に加えて、Exchange 2010 では以下の方法を使用して、トランザクション ログの原因不明の拡大を判別できます (この一覧の作成に協力してくれた Todd Luttinen に感謝します)。
[PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name> [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*
Starting from <date/time> service <name> has performed this activity on the server: RPC Operations: 24168. Database Pages Read: 1329 (of which 629 pages preread). Database Pages Updated: 12418 (of which 11555 pages reupdated). Database Log Records Generated: 13906. Database Log Records Bytes Generated: 660331. Time in Server: 19142 ms. Time in User Mode: 6100 ms. Time in Kernel Mode: 63 ms.
データベースの可用性が影響を受けないように十分な領域を用意することの重要性は誰でも理解していると思います。トランザクション ログ容量の計画にこの情報が役立つことを期待します。
Ross Smith IV プリンシパル プログラム マネージャーExchange カスタマー エクスペリエンス
これはローカライズされたブログ投稿です。原文の記事は、「Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted」をご覧ください。
原文の記事の投稿日: 2011 年 11 月 14 日 (月曜日)
何年もの間、一般に Microsoft Scalable Networking Pack (個別の機能は Receive Side Scaling (RSS) や Chimney/TCP 接続オフロード/TOE として知られます) と呼ばれる Windows の機能と、それらをサーバーで有効または無効にした場合の影響に関するさまざまな議論が交わされてきました。
過去を振り返ると、Windows 2003 SP2 でこの機能がリリースされたときに、いくつか解決すべき問題が (ネットワーク ドライバーなど、マイクロソフトとサードパーティのコードの両方に) あったことは確かです。しかし年月を経て状況は劇的に改善しており、今ではこれらの機能を無効にするとサーバーのパフォーマンスに大きな影響が生じる可能性があります。
次に例を示します。
次のスクリーンショットは、CPU の 1 つに過剰な負荷がかかる一方で、他の CPU が負荷を分担していない状況を示しています。ネットワーク接続が大量に発生し、RSS 機能が無効になっているサーバーでは、こうした状況がよく見られます。
次のスクリーンショットは、サーバーで RSS を有効にしたときにどのような現象が起きるかを少しわかりやすく示しています。赤丸で囲んである部分が RSS を有効にした時点です。1 つのプロセッサが大量のネットワーク トラフィックを処理している間、他のプロセッサがほとんど動いていなかったこと、および RSS を有効にした後でどのような変化が起きたかがわかります。
この機能に興味を持っていただいたところで、私の Windows チームの同僚である Tod Edwards が最近書いた記事をご紹介します。この記事では、これらの機能の内容、機能を有効にすべき理由、有効にする方法、さらに有効にするのに適した状況を判断する方法について深く掘り下げています。記事は次の Web サイトでお読みいただけます。
「Give Microsoft’s Scalable Networking Pack Another Look」
http://www.windowsitpro.com/article/networking/give-microsofts-scalable-networking-pack-140350 (英語)
(言うまでもありませんが、お使いのネットワーク カードのドライバーが更新されていることを確認してください。)
ぜひご覧ください!
Nino Bilic
これはローカライズされたブログ投稿です。原文の記事は、「Time to revisit recommendations around Windows networking enhancements usually called Microsoft Scalable Networking Pack」をご覧ください。
原文の記事の投稿日: 2011 年 11 月 17 日 (木曜日)
数か月前、Bruce Langworthy が Windows ディスク タイムアウト値を設定するための新しい推奨事項に関する有益な記事を書きました。http://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx (英語) がその記事です。
彼の投稿をきっかけに、私は Exchange と、I/O の問題に対処する方法について考えるようになりました。Bruce の記事を読んでいない方のために要約すると、既定のディスク タイムアウト値である 60 秒では、Windows はハングした I/O を 60 秒間報告せず、I/O を 8 分間再試行しません。ハングした I/O を再試行するまでに 8 分もかかるのは長すぎるので、マイクロソフトでは新しいガイダンスをリリースし、Windows ディスク タイムアウトの設定をストレージ アーキテクチャに沿った値に変更することを推奨しています。
Exchange に関して私の心に浮かんだ疑問は、「このディスク タイムアウトの動作は Exchange DAG 展開にどのように影響するのか」、より具体的には、「新しい推奨に従って Exchange Server の Windows ディスク タイムアウトを短くするべきか、それともそのままにしておくべきか」という単純なものでした。
この疑問の回答を得るために、私は数人の ESE 開発者に声をかけて意見を求めました。その結果次のようなことがわかりました。
私は、ディスク タイムアウトの設定をどうすべきかを決める前に、Exchange Server 2010 SP1 で導入されたインテリジェンスがどのようなもので、それがディスク タイムアウトにどう作用するかを理解する必要があると考えました。
Exchange Server 2010 SP1 では、ハングした I/O に対処するしくみが大幅に強化されています。強化された機能については、TechNet の記事 http://technet.microsoft.com/ja-jp/library/ff625233.aspx で次のように詳細に解説されています。
"Exchange 2010 SP1 には、特定の状況が発生したとき、具体的にはハングした I/O が発生したときに組み込みの Windows バグチェックの動作を活用する新しい復旧ロジックが備わっています。SP1 では、ハングした I/O を検知し、サーバーを自動的に復旧するための是正措置を講じるように Extensible Storage Engine (ESE) が更新されています。ESE は、特定の時間 I/O が未処理になっていることを検知する I/O ウォッチドッグ スレッドを保持しています。既定では、データベースの I/O が 1 分を超えて未処理になっていると、ESE がイベントをログに記録します。データベースの I/O が 4 分を超えて未処理になっていると、ESE は (可能であれば) 特定の失敗イベントをログに記録します。ハングした I/O の性質に応じて、ESE イベント 507、508、509、または 510 がログに記録される場合とされない場合があります。問題の性質が、OS ボリュームが影響を受けていたり、イベント ログへの書き込みが影響を受けていたりするたぐいのものであれば、イベントはログに記録されません。イベントがログに記録されると、Microsoft Exchange Replication サービス (MSExchangeRepl.exe) がその状況を検知し、wininit.exe プロセスを終了して意図的に Windows のバグチェックが実行されるようにします。"
つまり、これはどういうことでしょうか。多少の議論 (および ESE コードの検索) を経て、この動作をわかりやすくまとめたのが次の表です (参考のために以前のバージョンの Exchange も含めています)。
注意: ここで Exchange チームの ESE 開発者である Alexandre Costa と Brett Shirley の両名に深い感謝の意を表します。2 人がいなければ、この情報をまとめることはできませんでした。
Exchange のバージョン
I/O の種類
I/O 時間
動作
Exchange Server 2003
完了済み
> 60 秒
Exchange Server 2007
Exchange Server 2010 RTM
Exchange Server 2010 SP1
処理中
> 4 分
> 30 秒
注意: 処理中の I/O とは、時間がかかる I/O 処理で、まだ正常に完了していないものを意味します。完了済みの I/O とは、時間がかかる I/O 処理で、完了はしたものの 30 秒を超える時間がかかったものを意味します。Exchange Server 2010 より前のバージョンには、時間がかかる I/O を処理中に検知するという概念がなく、I/O が完了して初めて報告されていたことに注意してください。
多くの事柄と同様に、非常に明確でやむを得ない理由がない限り、この新しい動作を変更することはお勧めできません。それでも、新しい Extensible Storage Engine によるハングした I/O の復旧動作をどうしても変更する必要がある場合は、いくつかのレジストリ キーと Active Directory 属性を操作して変更できます。詳細については、ここを参照してください。
この記事を書き始めたそもそもの理由は、Exchange DAG サーバー ノードの Windows ディスク TimeOutVale を、ここ (英語)で推奨されているように短かくすべきかどうかを判断するためでした。
Exchange チームの Matt Gossage (Matt は Exchange と I/O のことを何でも知っています) に相談したところ、ディスク タイムアウトの働きの 1 つは、バス リセットのストームからホストを保護することだと説明してくれました。I/O が Windows ディスク TimeOutValue に達したときの興味深い副作用の 1 つは、disk.sys ドライバーがバス リセットを発行し、このリセットによって、応答していない LUN だけでなくサーバー上のすべての LUN が影響を受けるということです。
この現象が生じる最も一般的なシナリオが、Exchange 2010 と JBOD ストレージの組み合わせです。RAID ソリューションが展開されている場合、ディスク コントローラーはデータを別のディスクから読み取るか、パリティからデータを再計算することによって不良ブロックの読み取りに対処できます。この場合 I/O は遅延しますが、大幅な遅延ではありません。JBOD では、データ ブロックのコピーが 1 つしかないので、ディスクがデータを読み取ろうとするのを待つ間に、不良ブロックが原因でハングした I/O が発生する可能性があります。要するに、JBOD 展開ではディスク TimeOutValue を短かくすることは望ましくなく、JBOD ディスクのスピンドルの 1 枚で障害が起き始めている場合は、むしろ値を増やしてバス リセットのストームの影響を減らすことが必要になる場合もあるということです。
次の表は、Exchange Server 2010 のメールボックスの役割を実行するサーバーで HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue を設定する場合の推奨ガイダンスです。
Neil Johnson シニア コンサルタント、UK MCS
これはローカライズされたブログ投稿です。原文の記事は、「Windows Disk Timeouts and Exchange Server 2010」をご覧ください。
原文の記事の投稿日: 2011 年 11 月 20 日 (日曜日)
今年の 8 月初旬、Windows SE チームは Windows Server 2008 R2 フェールオーバー クラスターの問題に関する次のサポート技術 (KB) 情報と関連するソフトウェア修正プログラムをリリースしました。
KB2550886 - 動作を停止するのには、Windows Server 2008 R2 のフェールオーバー クラスターの一時的な通信障害の原因します
この修正プログラムは、複数のデータセンターにまたがるすべてのデータベース可用性グループに強く推奨されるものです。複数のデータセンターにまたがらない DAG の場合も、この修正プログラムを適用することが勧められます。この記事では、Windows フェールオーバー クラスターが一時的な通信障害を検出したときに発生する可能性のある、競合状態とクラスター データベースのデッドロックの問題について説明します。クラスター ノードの再接続ロジック内に競合状態が存在し、クラスターで通信障害が発生すると表面化します。この競合状態が起きると、クラスター データベースはハングし、フェールオーバー クラスターでクォーラムの損失が発生します。
TechNet で説明されているように、データベース可用性グループ (DAG) はクラスター データベースなどのクラスターの特定の機能に依存します。DAG が機能して高可用性を提供できるためには、クラスターとクラスター データベー��が正常に動作していることも必要です。
Microsoft は、一時的なネットワーク障害 (約 60 秒間のネットワーク通信の障害) が発生し、その結果、クラスター全体がデッドロックして、DAG 内のすべてのデータベースがマウント解除されるシナリオを発見しました。実際にデッドロックしているクラスター ノードを特定するのは簡単ではないので、再接続ロジックの競合の結果としてフェールオーバー クラスターがデッドロックした場合に実行できる唯一の対処は、クラスター全体のすべてのメンバーを再起動して、デッドロック状態を解決することです。
この問題による典型的な影響は、非対称的な通信障害 (2 つのノードが相互には通信できなくても、他のノードとは通信できる場合) によるクラスター クォーラムの損失です。他のノードでクラスターのグローバル更新マネージャー (GUM) からのクラスター再グループ化メッセージの受信に遅延があると、再グループ化メッセージが予想外の順序で受信される場合があります。このような状況が発生すると、クラスターでは、初期通信障害が発生したノードの 1 つをクラスターから削除するという予期される動作が呼び出される代わりに、クォーラムが失われます。
一般に、このバグは、ペア間の通信の断絶を検出する 2 つのクラスター ノードの待機時間が非対称的である場合 (たとえば、DAG メンバーの半分では待機時間が 1 ミリ秒、他の本文では 30 ミリ秒のような場合) に発生します。第 1 のノードによる接続喪失の検出が第 2 のノードよりかなり早い場合、競合状態が発生する可能性があります。
この問題が発生した場合、DAG には非常に悪い影響があります。したがって、DAG のメンバーであるすべてのメールボックス サーバーにこの修正プログラムを展開することをお勧めします。DAG が複数のデータセンターにまたがっている場合は特に必要です。この修正プログラムは、Exchange 2007 シングル コピー クラスターを実行する環境およびクラスター連続レプリケーション環境に対しても効果があります。
これまでに説明した問題の修正だけでなく、KB2550886 には、DAG にも推奨される Windows Server 2008 R2 の他の重要な修正プログラムも含まれます。
これはローカライズされたブログ投稿です。原文の記事は「Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2」をご覧ください。