次の方法で共有

Exchange パブリック フォルダのトラブルシューティングに関するリソース

  • [アーティクル]

 

ここでは、Microsoft ® Exchange Server のパブリック フォルダに関するトラブルシューティングに役立つドキュメントへのリンクを紹介します。

トラブルシューティングを行う前に、組織の環境で Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを実行することを強くお勧めします。Exchange Server ベスト プラクティス アナライザは、Exchange Server の展開を自動的に調べ、マイクロソフトのベスト プラクティスに応じて構成が行われているかどうかを判断します。Exchange Server ベスト プラクティス アナライザは、Microsoft .NET Framework 1.1 を実行しているクライアント コンピュータにインストールできます。Exchange Server ベスト プラクティス アナライザは適切なネットワーク アクセスを使用して、すべての Microsoft Active Directory® ディレクトリ サービスおよび Exchange サーバーを調べます。

Exchange Server ベスト プラクティス アナライザを使用して Exchange サーバーおよびトポロジの全体的な状態を確認すると、以下のタスクを実行できます。

  • 最適ではない構成設定、サポートされていないオプション、推奨されていないオプションなどの問題の一覧を生成できます。
  • システムの全般的な状態を確認できます。
  • 個々の警告、エラー、および既定以外の構成に関するメッセージについての警告特有のドキュメントを収集し、特定の問題のトラブルシューティングに役立てることができます。

ツールを展開全体、特定のサーバー、またはサーバーのセットに対して実行できます。

以下は、Exchange Server ベスト プラクティス アナライザが報告する特定のパブリック フォルダの構成の例です。

  • Aging Clean Interval レジストリ値
  • Background Cleanup レジストリ値
  • Replication Expiry レジストリ値
  • Minimum Runtime レジストリ値
  • Replication Folder Tombstone Age Limit レジストリ値
  • Replication Folder Conflict Age Limit レジストリ値
  • Preferred Backfill Source レジストリ値
  • パブリック フォルダ ストア データベースのサイズ
  • パブリック フォルダ ストア データベースの場所
  • 電子メール アドレスがないパブリック フォルダ ストア
  • パブリック フォルダ データベース ツリーの割り当て
  • 重複するレジストリ値の追跡
  • コンテンツのインデックス処理に関する構成
  • 最上位階層 (TLH) のアクセス許可
  • 削除済みアイテムの保存期間の構成
  • オフライン アドレス帳の構成
  • パブリック フォルダ階層の構成
  • Active Directory コネクタ (ADC) によって作成されるパブリック フォルダ用接続許可書

Exchange Server パブリック フォルダを削除する

ここでは、パブリック フォルダとパブリック フォルダ データベースを削除する際に役立つ一般的なベスト プラクティスについて説明します。Exchange Server パブリック フォルダとパブリック フォルダ データベースは、慎重に削除する必要があります。

Exchange システム マネージャを使用する

パブリック フォルダを削除するには、[フォルダ] で目的のフォルダを右クリックし、[削除] を選択します。これにより、以下の処理が行われます。

  • パブリック フォルダが削除されます。
  • 送信用の階層レプリケーション メッセージが生成されます。
  • このサーバーから組織内の他のすべてのパブリック フォルダ サーバーに送信用の階層レプリケーション メッセージが送信されます。送信用の階層レプリケーション メッセージは、パブリック フォルダの削除についての情報を提供します。

Exchange Server 5.5 では、管理者は、フォルダまたは削除イベントの記録が取得されないようにパブリック フォルダを削除できました。Exchange 2000 Server および Exchange Server 2003 では、管理者は、パブリック フォルダの General という分類の診断ログを [中] または [高] に調整することによって、パブリック フォルダの監査を有効にすることができます。この調整により、パブリック フォルダが削除されるごとに、イベントがサーバーのアプリケーション ログにログ出力されます。イベントには、削除されたパブリック フォルダの名前とパブリック フォルダを削除するのに使用されたユーザー アカウントが表示されます。

パブリック フォルダ ツリーを削除しようとしても、Exchange Server は、関連付けられたストアが削除されるまでツリーを削除しません。パブリック フォルダ ストアとパブリック フォルダを削除するとき、Exchange システム マネージャが Active Directory を適切に更新します。パブリック ストアを削除する前に、ストアに存在するすべてのフォルダを削除するか、別のサーバーにレプリケートする必要があります。削除するパブリック ストアにのみレプリケートされているすべてのパブリック フォルダの内容は、パブリック フォルダの削除後に完全に失われます。

手動によるパブリック データベース ファイル (.edb と .stm ファイル) の削除は、ベスト プラクティスではありません。これらのファイルは、手動で削除された後、Exchange Server ストアの次回マウント時に Exchange Server により再作成されます。このとき、フォルダ階層はバックフィルします。また、削除されたストア上の 1 つ以上のフォルダのレプリカが他のフォルダに存在する場合、内容もバックフィルします。

Caution注意 :
パブリック フォルダは、Exchange システム マネージャの [サーバーの削除] オプションを使用して削除することもできます。Exchange システム マネージャでサーバーを右クリックし、[サーバーの削除] を選択することにより、組織からサーバーを強制的に削除できます。この方法では、他の方法によって行われるすべてのチェックが省略されます。ただし、これはサーバーを削除する最も強力な方法であり、最も多くの問題が発生する可能性があります。この方法は、サーバー自体が失われた場合にのみ使用してください。たとえば、サーバーに致命的なエラーが発生し、バックアップが存在しない場合は、この方法が使用できます。ただし、この場合でも、この方法は慎重に実行する必要があります。

サイト フォルダに関する考慮事項

最初に管理グループにインストールされる Exchange サーバーには、管理グループのサイト フォルダが含まれます。サイト フォルダは、その管理グループのオフライン アドレス一覧と空き時間データのコピーを保持します。また、サイト フォルダは、他の管理グループからの他のサイト フォルダのレプリカも保持します。サイト フォルダを含むストアを削除しようとしても、Exchange システム マネージャは、サイト フォルダが管理グループの別のサーバーにホーム サーバーを変更されるまで、ストアを削除しません。

したがって、管理グループの最初の Exchange サーバーを削除する、またはサイト フォルダを含むパブリック フォルダ ストアを削除するには、まず、パブリック フォルダをその管理グループの他の Exchange サーバーにレプリケートする必要があります。さらに、オフライン アドレス一覧と Schedule+ Free/Busy フォルダを別のサーバーにレプリケートする必要があります。

パブリック フォルダを管理するためのリソース

パブリック フォルダの管理の詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

レプリケーション

レプリケーションに関する問題のトラブルシューティングを効果的に行うには、レプリケーションがどのように動作するのか理解する必要があります。Exchange Server が使用するレプリケーション メッセージの種類を理解し、また変更番号セット (CNset) を理解する必要があります。これらの概念の説明については、「Exchange Server 2003 ストアの操作」の「パブリック フォルダのレプリケーションの制御」を参照してください。また、Exchange 2000 Server と Exchange Server 2003 でパブリック フォルダ レプリケーションを展開および構成するためのベスト プラクティスの情報については、「Exchange パブリック フォルダに関するベスト プラクティス : レプリケーションを実装する」を参照してください。

ここでは、レプリケーションに関する問題のトラブルシューティングに役立つ一般的なベスト プラクティスを紹介します。

バックフィル プロセスに長時間かかる

ストアが停止し、元のレプリケーションの更新内容と、それ以降の状態メッセージを受信していない場合は特に、バックフィル プロセスに長い時間がかかることがあります。バックフィル プロセスが遅い一般的なシナリオがいくつかあります。

  • Exchange Server が、古いサーバーからバックフィルしています。バックフィル要求が、不足しているデータを持たないサーバーに送信される場合、バックフィル要求は満たされません。このシナリオの例として、最近サーバーに古いバックアップを復元し、バックアップ復元後にそのサーバーにバックフィル要求が送信される場合が挙げられます。このシナリオでは、ストアは複数のバックフィル要求を送信する必要があります。このプロセスには、数時間または数日かかる場合があります。
  • Exchange Server が、新しいサーバーに状態要求を送信しています。最初の状態要求を送信するサーバーが新しいストアの場合は、サーバーに階層しかない場合があります。この場合、組織のその他の部分で同期していないのにもかかわらず、ストアは互いに同期しているように見えます。この問題は、組織内の他のストアから更新が到着すれば、最終的に解決されます。ただし、最初の要求が満たされたため、それ以降のバックフィルに数時間または数日かかる場合があります。
  • 新しいルーティング グループが作成されています。組織の他の部分へのトランスポート リンクが作成される前に、Exchange セットアップが Exchange パブリック ストアを開始します。ストアは、状態要求を送信しますが、トランスポートがまだ動作しないので、応答を受け取りません。ストアは追加の状態要求を送信するまで、変更されたスケジュールを使用します。トランスポート リンクの確立後、サーバーは状態要求の送信を試みるか、更新します。また、他のストアからの状態メッセージは、ストアにバックフィルが必要であることを示している可能性があります。しかし、最初の状態要求が失われたため、データ バックフィルには、数時間または数日かかる場合があります。
  • 受信者更新サービスが、ストアのメール属性を更新していません。パブリック フォルダ ストアは、ディレクトリ オブジェクトが必要なメール属性でスタンプされる前に、状態要求の送信を試みる可能性があります。もちろん、この状態要求により、レプリケーション メッセージの配信不能通知 (NDR) が生成されます。ここでもまた、最初の状態要求が失敗したため、ストアが再び同期するまでに数時間または数日かかる場合があります。

これらのシナリオはすべて、最初のレプリケーション メッセージが失われているか、ストアがパブリック フォルダの情報を持たないストアの情報を要求しているかのどちらかです。最終的には、これらの状況は、データが失われていることを他のサーバーが検出すれば、解決します。フォルダが非同期で、何度かバックフィルがタイムアウトした後に再び同期しない場合は、最新のフォルダのレプリカを変更する必要があります。

フォルダが最新であることを確認するには、フォルダのすべてのアイテムが存在することを視覚的に確認する必要があります。たとえば、不完全な階層の問題が発生している場合は、最新のレプリカの階層を変更します。これを行うには、最新のレプリカのアクセス許可エントリを変更します。また、内容の不足の問題が発生している場合は、メッセージを投稿して最新のレプリカの内容を変更します。これにより、レプリケーション メッセージが非同期のストアに強制的に送信され、バックフィル要求が行われます。

診断ログ

特定のサーバーでの受信レプリケーションと送信レプリケーションの診断ログを最大レベルに設定することにより、レプリケーションに関する問題のトラブルシューティングが可能になります。

特定のサーバーでの受信レプリケーションと送信レプリケーションの診断ログを [最大] に設定するには

  1. サーバーの [プロパティ] ページで、[診断ログ] タブをクリックします。

  2. [MSExchangeIS] を展開し、次に [パブリック フォルダ] を展開します。

  3. [パブリック フォルダ] タブで、[Replication Incoming Messages] と [Replication Outgoing Messages] を [最大] に設定します。

この手順によって、パブリック フォルダについて送受信されるレプリケーション メッセージの通知を含んだいくつかのイベント ID が作成されます。受信レプリケーション メッセージのイベント ID の範囲は 3011 から 3020 で、送信レプリケーション メッセージのイベント ID の範囲は 3021 から 3030 です。これらは、レプリケーションに関する問題を絞り込むのに役立つ汎用のレプリケーション イベント メッセージです。

特定のレプリケーション領域の決定後、他のレプリケーション ログ オブジェクトのログ出力を適切に参照することができます。他のレプリケーション オブジェクトとは、Replication Site Folders、Replication Expiry、Replication Conflicts、Replication Backfill、Replication Errors です。[最大] ログ出力レベルは大量にイベント ログを書き込むので、トラブルシューティングの終了時には必ず、ログ出力レベルを [なし] または [最小] に設定し直します。

パブリック フォルダのレプリケーションに関する問題のトラブルシューティングを行う場合は、イベント ログでエラーが表示されない場合があります。ただし、新しく作成されたパブリック フォルダと古いパブリック フォルダの内容は、レプリケーション期間が経過しても、グループ間で正しくレプリケートされない可能性があります。この不一致は、レプリケーション メッセージは送信されたが送信先のサーバーが受信していないためである可能性があります。メッセージ追跡は、この不一致の原因を特定するのに便利なツールです。ストアはアプリケーション間で相互に電子メールを送信しており、これらの電子メール メッセージは、メッセージ追跡ツールを使用して追跡できます。

メッセージ追跡を使用して、パブリック フォルダのレプリケーションに関する問題を診断して解決する方法の詳細については、サポート技術情報の文書「[XADM] PF 階層とコンテントがルーティング グループを越えて複製不可」を参照してください。

レプリケーションのトラブルシューティングに関するリソース

レプリケーションのトラブルシューティングの詳細については、以下のサポート技術情報の文書を参照してください。

アクセス許可

パブリック フォルダのアクセス許可に関する 2 つの一般的な問題が、ユーザーのアクセシビリティと Exchange サーバーのパフォーマンスに悪影響を及ぼす場合があります。これらの問題は、Exchange Server 5.5 から Exchange 2000 Server または Exchange Server 2003 への移行の結果です。

まず、パブリック フォルダに適用されるアクセス許可が保持されないインスタンスがあります。たとえば、パブリック フォルダのプロパティ ページの [アクセス許可] タブで、ユーザーを追加することによりパブリック フォルダにユーザー アクセスを追加する処理を行うとします。ユーザーが追加されたように見えますが、ユーザーはフォルダへのアクセス許可を与えられていません。また、[アクセス許可タブ] を更新すると、そのユーザーは表示されなくなります。

この問題は、パブリック フォルダのアクセス許可を追加しようとしている Active Directory アカウントの問題が原因で発生します。パブリック フォルダ自体の問題である可能性はほとんどありません。おそらく、アクセス権を与えようとしているアカウントは、msExchMasterAccountSID 属性が定義されているメールが有効なアカウントです。インフォメーション ストアは、msExchMasterAccountSID 属性を持つメールが有効なユーザーを有効な構成と見なしません。Exchange サーバーのアプリケーション ログを調べると、msExchMasterAccountSID 属性を持つユーザーを示すイベント 9548 が存在する可能性が高いでしょう。

MSExchMasterAccountSID 属性は、ADC によって作成された無効なメールが有効なユーザー オブジェクトに付与されます。MSExchMasterAccountSID 属性は、Exchange 5.5 Server のメールボックスに関連付けられているユーザー アカウントのセキュリティ識別子 (SID) で設定されます。移行のシナリオでは、このユーザー アカウントは、通常、Microsoft Windows NT® 4.0 のユーザー アカウントです。ただし、シナリオによっては、Exchange 5.5 Server のメールボックスに関連付けられている別のフォレストの Active Directory ユーザー アカウントの場合もあります。

この問題は、Active Directory にアカウントを移行するために、Active Directory 移行ツールなどのツールを使用する代わりに、ADC によって作成された無効なメールが有効なユーザー アカウントを手動で有効にした場合に最も一般的に生じます。無効なアカウントを手動で有効にしないことをお勧めします。この問題の修正の詳細については、この文書の「レプリケーションのトラブルシューティングに関するリソース」を参照してください。

パブリック フォルダのアクセス許可に関する別の一般的な問題も、Exchange 5.5 Server からのアップグレードの結果生じるものです。Exchange 5.5 Server 組織のパブリック フォルダへのアクセス許可を与えられていたメールボックスに、Active Directory のメールボックスに関連付けられているユーザー オブジェクトがない場合があります。この不一致は、Exchange 2000 Server または Exchange Server 2003 のメールボックスを持つユーザーがパブリック フォルダを表示しようとするときにアクセスの問題を引き起こす可能性があります。ユーザーが、アクセスの問題に遭遇する可能性があります。また、Exchange Server で一般的なパフォーマンスの問題が発生する場合もあります。

パブリック フォルダのアクセス許可で発生する可能性が高い最も一般的な現象は、ユーザーが Microsoft Office Outlook® から特定のパブリック フォルダを表示できなくなることです。個々のフォルダが、表示されなくなります。この現象は、Exchange 2000 Server または Exchange Server 2003 に移行したユーザーにのみ影響します。まだ Exchange 5.5 Server を使用しているユーザーは影響を受けません。

Exchange システム マネージャでは、パブリック フォルダが表示されます。次に、Exchange システム マネージャでパブリック フォルダのアクセス許可を調べると、パブリック フォルダを表示できないユーザーがアクセス許可を持っているユーザーとして表示されます。これらのユーザーが所有者アクセス許可を持つようにアクセス許可を変更すると、ユーザーは、Outlook のパブリック フォルダを表示し、アクセスすることができるようになります。ただし、アクセス許可を非所有者に戻すと、パブリック フォルダは、再び表示しようとしても Outlook で表示されません。

この動作は、アクセス制御リスト (ACL) による変換の問題の結果生じます。パブリック・フォルダにアクセス許可があると表示されるメールボックスがある可能性がありますが、実際にはそのようなメールボックスは存在していません。そうしたメールボックスは、おそらく、Exchange 5.5 Server から削除されたにもかかわらず、パブリック フォルダまたはメールボックスの ACL から削除されなかったということです。また、パブリック フォルダに表示され、Active Directory にまだ表示されていないアクセス許可を持つユーザーもいます。Exchange 2000 Server または Exchange Server 2003 のアプリケーション ログを調べると、イベント 9551 と場合によってはイベント 9552 が表示される可能性があります。イベントでは、サーバーで ACL 変換問題が発生しているパブリック フォルダが表示されます。また、問題の原因となっているユーザーまたはグループもイベントに表示されます。この問題の修正の詳細については、以下のリソースを参照してください。

レプリケーションのトラブルシューティングに関するリソース

レプリケーションのトラブルシューティングの詳細については、以下ののマイクロソフト サポート技術情報の文書を参照してください。

詳細情報

Exchange Server のパブリック フォルダの詳細については、以下のリソースを参照してください。