Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールは、以下のことを行う診断ツールです。

  • Microsoft Exchange Server 組織から構成情報を収集します。

  • Exchange Server 組織に対し、特定のテストを実行します。

  • テストの結果を報告します。

Exchange Server ベスト プラクティス アナライザを使用して、次のタスクを行うことができます。

  • 推奨されるベスト プラクティスに従って構成が設定されていることを予防的に確認します。

  • 既定の設定と異なるすべての設定を報告します。

  • Exchange Server 組織で最近行われた変更について報告します。この機能は、Exchange Server 組織で行われた変更の結果発生する問題の診断に役立ちます。

  • 正常な状態にない Exchange Server 組織で起きている問題の原因を突き止めやすくします。

  • 一連のサーバーをベースライン構成と比較し、構成のすべての相違点を報告します。

注 :
Exchange Server ベスト プラクティス アナライザが最近の変更内容を報告できるのは、最終更新時刻のプロパティを含む構成オブジェクトに関してのみです。

Exchange Server ベスト プラクティス アナライザは、構成ファイルを使用して、Exchange Server 組織から収集すべき情報を特定します。収集したデータを Exchange Server の設定と構成用に事前定義された一連のルールと比較し、問題を報告します。

Exchange Server ベスト プラクティス アナライザは、すべての問題に関し、次の 3 種類のデータを提供します。

  • Exchange Server 組織でのスキャン結果

  • 推奨される構成

  • 問題および関連トピックに関する詳細情報へのリンク

Exchange Server ベスト プラクティス アナライザに関するご意見、ご提案、およびフィードバックをお待ちしています。フィードバックはさまざまな方法でお寄せいただけます。

  • Microsoft パブリック ニュースグループ Exchange Server ベスト プラクティス アナライザ ツール開発チームのメンバは、news.microsoft.com の microsoft.public.exchange.tools ニュースグループを頻繁にチェックしています。このニュースグループや他の Microsoft ニュースグループへの参加方法の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの Web サイト (http://go.microsoft.com/fwlink/?LinkId=33938) (このサイトは英語の場合があります) と、Microsoft 製品サポート ニュースグループの Web サイト (http://go.microsoft.com/fwlink/?LinkId=50219) を参照してください。

  • Exchange Server ベスト プラクティス アナライザのドキュメントに対するフィードバック Exchange Server ベスト プラクティス アナライザに含まれるドキュメントや文書に対するご意見、ご質問、フィードバックがあれば、exbpadoc@microsoft.com までお送りください。


Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2006-02-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールをインストールするには、ツールを実行するコンピュータで Microsoft インストーラ ファイルの ExBPA.msi を実行します。インストーラは、既定では <システム ドライブ>\Program Files\ に ExBPA という名前のディレクトリを作成し、必要なファイルをこの新しいディレクトリにコピーします。

インストールするコンピュータの選択

Exchange Server ベスト プラクティス アナライザ ツールは、専用の管理ステーションにインストールすることをお勧めします。専用の管理ステーションをインストールして使用する方法の詳細については、『Exchange Server 2003 管理ガイド』(http://go.microsoft.com/fwlink/?linkid=21769) を参照してください。

Exchange 組織の外部にあるコンピュータにツールをインストールするには、Active Directory® ディレクトリ サービスと Exchange サーバーにログオンするためのユーザー名とパスワードを明示的に設定する必要があります。スキャンを実行するユーザー アカウントの資格情報を設定する方法の詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可」を参照してください。

ツールは Exchange サーバーにもインストールできます。このツールは Exchange サーバーでも動作できますが、システム リソース､特に CPU と RAM を大量に消費します。そのため、ツールは別のコンピュータにインストールすることをお勧めします。ツールを Exchange サーバーにインストールする場合は、その Exchange サーバーのみをスキャンすることをお勧めします。

更新ファイルの確認

Exchange Server ベスト プラクティス アナライザ ツールを起動すると、このツールはベスト プラクティス ルールが盛り込まれた新しいファイルが Microsoft の Web サイトにあるかどうかを判断します。新しいバージョンが存在する場合は、その新しいファイルをダウンロードできます。このファイルをダウンロードするには、管理者としてコンピュータにログオンしている必要があります。新しいファイルをダウンロードしないことにした場合、またはツールがインターネットにアクセスできない場合は、ツールを実行しているコンピュータにあるファイルのコピーが使用されます。

注 :
インターネットへのアクセスにプロキシの認証が必要な場合は、ツールが新しいバージョンの構成ファイルにアクセスして、ユーザーがダウンロードできるようにすることはできません。ただし、www.microsoft.com からローカル コンピュータにファイルを手動でコピーできます。
新しいバージョンの構成ファイルを手動でコピーするには

  1. ツールがインストールされているディレクトリで、既存の ExBPA.Config.xml ファイルの名前を変更します。

  2. Web ブラウザで、http://go.microsoft.com/fwlink/?LinkId=34290 に移動します。

  3. 自己抽出型のパッケージをダウンロードし、ツールがインストールされているディレクトリ (通常は C:\Program Files\ExBPA) に新しいファイルを展開します。

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールがパフォーマンスに与える影響
Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールを実行するための前提条件
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを正常に実行するには、Exchange 組織内のコンピュータがいくつかの前提条件を満たしている必要があります。これらの条件が満たされていなくてもほとんどの場合ツールは動作しますが、一部の機能が動作しなかったり、パフォーマンス レベルが低下したりする可能性があります。

ここで説明するトピックには、Exchange Server ベスト プラクティス アナライザ ツールを実行するために必要なアクセス許可や、Exchange 組織およびツールを実行するコンピュータについてのその他のすべての前提条件に関する情報があります。また、その他の前提条件のトピックでも、ツールを実行するためにサポートされている環境を一覧表示しています。

このセクション内

Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのその他の前提条件


Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可

Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールを実行するための前提条件 >

トピックの最終更新日時 : 2005-07-08

必要なすべてのアクセス許可を持つ資格情報を使用して実行しても、Microsoft® Exchange Server ベスト プラクティス アナライザ ツールがアクセスできるのは Active Directory® ディレクトリ サービスと Exchange サーバーのみです。

アクセス許可

Exchange Server ベスト プラクティス アナライザ ツールを正常に実行するには、以下のアクセス許可が必要です。

  • Active Directory サーバー上の Domain Admins グループ、または Builtin\Administrators グループのメンバ。ドメイン コントローラとグローバル カタログ サーバーで Active Directory 情報の列挙、および Microsoft WMI (Windows® Management Instrumentation) プロバイダの呼び出しを行うために必要です。

  • 各 Exchange サーバーの、ローカルの Administrators グループのメンバ。WMI プロバイダの呼び出し、およびレジストリとメタベースへのアクセスを行うために必要です。

  • 少なくとも、Exchange 組織の Exchange 管理者 (参照のみ可) のアクセス許可が委任されている必要があります。

Exchange Server ベスト プラクティス アナライザ ツールを実行するコンピュータに、十分なアクセス許可のないアカウントを使用してログオンする方法として、次の 2 つのオプションがあります。

  1. runas コマンドを使用して、十分なアクセス許可を持つアカウントの下で実行されるコマンド プロンプト ウィンドウを開いた後、このウィンドウからツールを起動します。このときの構文は次のとおりです。

    runas /netonly /user:<ドメイン>\<ユーザー名> exbpa.exe

  2. ツールの [Active Directory に接続] ページで、使用するアカウントの資格情報を設定します。[ログインの詳細オプションを表示する] をクリックして、オプションを展開します。Active Directory に接続するためのアカウントと、Exchange サーバーに接続するためのアカウントの 2 つのアカウントを入力できます。これらのアカウントのどちらかを指定しなかった場合は、ツールが実行されているアカウントが使用されます。

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのその他の前提条件

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールのその他の前提条件

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのその他の前提条件 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールを実行するための前提条件 >

トピックの最終更新日時 : 2007-05-16

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを正常に実行するには、Active Directory® ディレクトリ サービスに必要なアクセス許可を持つアカウントと、Exchange サーバーに必要なアクセス許可を持つアカウントを使用してこのツールを実行し、さらにその他のいくつかの前提条件をチェックする必要があります。

前提条件

Exchange Server ベスト プラクティス アナライザ ツールを正しく実行するには、以下の条件を満たす必要があります。

  • Exchange Server ベスト プラクティス アナライザ ツールを実行するコンピュータに .NET Framework 1.1 がインストールされていること。

  • リモート メタベース アクセスを有効にするため、Exchange Server ベスト プラクティス アナライザ ツールを実行するコンピュータにインターネット インフォメーション サービス (IIS) の共通コンポーネントがインストールされていること。

    注 :
    インターネット インフォメーション サービスの共通コンポーネントは、インターネット インフォメーション サービス、Internet Information Services Admin、または Exchange システム マネージャをインストールすると、自動的にインストールされます。
  • Exchange Server ベスト プラクティス アナライザを実行するコンピュータに、少なくとも 256 MB のランダム アクセス メモリ (RAM) が実装されていること。メモリ量がこれだけあれば、最大 50 台の Exchange サーバーを十分スキャンできます。Exchange 組織に最大 50 台のサーバーを追加するごとに、このツールを実行しているコンピュータに 256 MB の RAM を追加する必要があります。たとえば、組織内に 50 ～ 100 台の Exchange サーバーが存在する場合は、このツールを実行しているコンピュータに少なくとも 512 MB の RAM が必要です。組織内に 100 ～ 150 台の Exchange サーバーが存在する場合は、このツールを実行しているコンピュータに少なくとも 768 MB の RAM が必要です。

  • 組織内にあるスキャン対象の各 Exchange サーバーについて、Exchange Server ベスト プラクティス アナライザ ツールを実行するコンピュータに少なくとも 2 MB のディスク領域があること。

  • トポロジ内の Microsoft Windows® 2000 Server または Windows Server™ 2003 のどちらかに Active Directory がインストールされていること。

  • Active Directory 内に、少なくとも 1 つの Exchange 2003 または Exchange 2000 サーバーがインストールされていること。

  • Active Directory サーバーと Exchange サーバーの両方で、リモート レジストリ (RemoteRegistry) サービスが実行されていること。

  • Active Directory サーバーと Exchange サーバーの両方で、WMI (Windows Management Instrumentation) (winmgmt) サービスが実行されていること。

  • Exchange 2000 Server 以降のバージョンのすべての Exchange サーバーで、Exchange Management (MSExchangeMGMT) サービスが実行されていること。

  • ログオンし、Exchange Server ベスト プラクティス アナライザ ツールを実行しているユーザーが、このツールを実行しているフォルダへの読み取り/書き込みアクセス許可を持っていること。

  • ホスト バス アダプタ (HBA) 情報を収集できるよう、HBA 情報を収集する任意のサーバーに HBA API に準拠したドライバとリモート サービス (Emulex の HBAnywhere サービスなど) がインストールされていること。さらに、Exchange Server ベスト プラクティス アナライザを実行するコンピュータと、HBA がインストールされている対象サーバーの両方で、HBA API MOF (Managed Object Format) インストーラが実行されていること。HBA API に準拠したドライバとリモート サービスがインストールされていないと、Exchange Server ベスト プラクティス アナライザ ツールは動作しますが、HBA 情報は収集されません。

サポートされる環境

Exchange Server ベスト プラクティス アナライザ ツールは、次の環境で実行できます。

  • Windows 2000 Server SP3 以降のバージョン上の Exchange Server 5.5

注 :
Exchange Server 5.5 サーバーは、Active Directory で表現される、混在モードの Exchange 組織に含まれている必要があります。
  • Windows 2000 Server SP3 以降のバージョン上の Exchange 2000 Server (すべての Service Pack)

注 :
Windows 2000 Server と Exchange 2000 Server のどちらも、あまり多くの WMI プロバイダはサポートしていません。データの収集と分析は制限される可能性があります。
  • Windows 2003 Server SP3 以降のバージョン上の Exchange 2000 Server (すべての Service Pack)

注 :
Windows 2000 Server は、あまり多くの WMI プロバイダはサポートしていません。データの収集と分析は制限される可能性があります。
  • Windows Server 2003 上の Exchange Server 2003 (すべての Service Pack)

  • Windows Server 2003 上の Exchange Server 2007

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールは、ユーザーが選択した範囲内にある Exchange 組織内のコンピュータをスキャンします。スキャンした構成設定を推奨されている一連のベスト プラクティスと比較し、その結果を報告します。

スキャンの処理中は、進行状況バーが動的に更新され、スキャン全体の何パーセントまで完了しているのかが表示されます。このパーセンテージは、特定の種類のスキャンで収集すべきデータ量と、スキャンの範囲内にあるサーバーの台数を基にしています。

[推定残り時間] は動的に更新され、60 秒ごとに再計算されます。Exchange Server ベスト プラクティス アナライザには、マルチスレッド テクノロジが採用されているので、一度に複数の Exchange をスキャンすることができます。Exchange Server ベスト プラクティス アナライザは、同時に最大 10 の管理グループにあるコンピュータをスキャンし、また、最大 50 台の Exchange サーバーを同時にスキャンします。追加のサーバーはキューに入れられ、他のサーバーが完了するとスキャンされます。

[サーバー スキャンの詳細] ウィンドウには、スキャン用に選択された各サーバーの状態が表示されます。サーバーは、[保留中]、[処理中]、[完了] の 3 つの状態のいずれかにあります。サーバーが [処理中] の状態にある場合は、何パーセントまで完了しているかが進行状況バーに表示されます。サーバーが [完了] の状態になると、Exchange Server ベスト プラクティス アナライザがそのサーバーにアクセスできたかどうかがアイコンに示されます。緑のチェック マーク アイコンは、Exchange Server ベスト プラクティス アナライザがサーバーにアクセスでき、スキャン中に失敗することも、タイムアウトしきい値を超えることもなかったことを示しています。黄色の警告アイコンは、Exchange Server ベスト プラクティス アナライザがサーバーにアクセスできたものの、スキャン中に失敗したか、またはタイムアウトしきい値を超えたかのいずれかであることを示しています。赤い X のアイコンは、Exchange Server ベスト プラクティス アナライザがサーバーにアクセスすることができず、サーバーがスキャンされなかったことを示しています。

Exchange Server ベスト プラクティス アナライザは、Exchange サーバーの他に Active Directory® ディレクトリ サービスからもデータを収集する必要があります。Active Directory からのデータ収集の進行状況は、ページの一番上にある進行状況バーと [推定残り時間] に表示されますが、[サーバー スキャンの詳細] ウィンドウには表示されません。そのため、すべての Exchange サーバーが [保留中] または [完了] の状態になっても、スキャンの全体的な状態はまだ処理中になっている場合があります。

選択したすべてのサーバーのスキャンが完了したら、[ベスト プラクティス レポートの表示] ページを開くことができます。

このセクション内

Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定

Microsoft Exchange Server ベスト プラクティス アナライザ ツールによるネットワークとアクセス許可のチェック

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成


Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定

Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを起動したら、スキャンのパラメータを設定する必要があります。最初に、ベスト プラクティス ルールの最新の更新ファイルをダウンロードするかどうかを選択する必要があります。更新プログラムの確認と、最新の更新プログラム ファイルのダウンロードの詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール」を参照してください。

次に、操作を 1 つ選択する必要があります。[ようこそ] ページで、[新しいスキャンのオプションを選択する] または [表示するベスト プラクティス レポートを選択する] を選択します。既存のレポートの表示を選択した場合は、ローカルに格納されている出力ファイルの一覧からファイルを選択できます。ローカルに格納されている出力ファイルを選択する代わりに、別の場所から出力ファイルをインポートすることもできます。出力ファイルを選択した後、そのファイルのレポートを表示できます。レポートの詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容」を参照してください。

[新しいスキャンのオプションを選択する] を選択した場合は、Active Directory® ディレクトリ サービスに接続し、新しいスキャンを実行する必要があります。既定では、Exchange Server ベスト プラクティス アナライザは最も近い Active Directory サーバーを検出します。このサーバーに接続するか、サーバーの名前を入力して異なる Active Directory サーバーに接続することができます。

Exchange Server ベスト プラクティス アナライザは、このツールが既定で実行されているアカウントを使用します。Active Directory または Exchange サーバーへのログオンに別のアカウントを使用するには、[ログインの詳細オプションを表示する] をクリックしてオプションを展開します。展開されたウィンドウの上の部分で、Active Directory にログオンするためのアカウント資格情報を入力します。展開されたウィンドウの下の部分で、Exchange サーバーにログオンするためのアカウント資格情報を入力します。

同じアカウントを使用して Active Directory へのログオンと Exchange サーバーへのログオンを行うことも、異なるアカウントを使用して Active Directory と Exchange サーバーにログオンすることもできます。展開したウィンドウの上の部分または下の部分を空のままにした場合、Exchange Server ベスト プラクティス アナライザは、Exchange Server ベスト プラクティス アナライザが実行されているアカウントを使用してログオンします。

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール
Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容
Microsoft Exchange Server ベスト プラクティス アナライザ ツールによるネットワークとアクセス許可のチェック

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールによるネットワークとアクセス許可のチェック

Microsoft Exchange Server ベスト プラクティス アナライザ ツールによるネットワークとアクセス許可のチェック |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールは、スキャンを開始する前にネットワークとアクセス許可のチェックを行い、指定されたアカウント資格情報が有効であること、および Active Directory® ディレクトリ サービスに接続できることを確認します。これらのチェックのいずれかに失敗すると、[Active Directory に接続] ページに戻ります。その場合は、Active Directory を実行しているサーバー名、および Active Directory と Exchange サーバーにログオンするための資格情報の両方を再入力します。

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールに対するアクセス許可
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン >

トピックの最終更新日時 : 2006-10-10

スキャンを実行する前に、最後の手順として以下を実行する必要があります。

  1. スキャンのラベルの設定

  2. 範囲の設定

  3. スキャンの種類の設定

  4. ネットワーク速度の設定

ラベル、範囲、スキャンの種類、およびネットワーク速度を指定すると、Microsoft® Exchange Server ベスト プラクティス アナライザ ツールによってスキャンが開始されます。

スキャンのラベルの設定

スキャンのラベルを設定するには、[新しいベスト プラクティス スキャンの開始] ページで、[このスキャンに名前を付けてください] ボックスに一意のラベルを入力します。既存のレポートを後で参照する場合は、[このスキャンに名前を付けてください] ボックスに入力したラベルによってレポートを識別できます。

既存のレポートは、以下の 2 つの方法で参照できます。

  • [ようこそ] ページで、[表示するベスト プラクティス レポートを選択する] を選択します。

  • Exchange Server ベスト プラクティス アナライザ ウィンドウの左側のナビゲーション ペインで、[表示するスキャンの選択] を選択します。

スキャンの範囲の設定

スキャンの範囲を指定するには、[新しいベスト プラクティス スキャンの開始] ページで、スキャンするサーバーまたは管理グループを選択します。

範囲は、以下の 3 つから選択できます。

  • Exchange Server 組織全体

  • 1 つ以上の管理グループ

  • Exchange Server 組織にある任意の管理グループの 1 つ以上のサーバー

スキャンの種類の選択

次に、スキャンの種類を選択します。スキャンの種類は、以下の 3 つから選択できます。

  • 状態の確認

  • Health/Performance Check

  • 接続のテスト

  • ベースライン

[状態の確認] スキャンを選択すると、完全なスキャンが実行され、エラー、警告、既定以外の構成、最近の変更、その他の構成情報がないかどうかがチェックされます。Exchange Server 組織の状態を確認する場合や、特定の問題のトラブルシューティングを行う場合は、[状態の確認] スキャンを実行してください。

[Health/Performance Check] スキャンを選択すると、[状態の確認] スキャンを実行し、次に Exchange Server パフォーマンス カウンタの範囲を 2 時間以上サンプリングを行います。

[接続のテスト] スキャンを選択すると、範囲で指定された各 Exchange Server について、ネットワーク接続とアクセス許可のテストが実行されます。アクセス許可の問題があると疑われる場合や、トポロジ内にファイアウォールが存在する場合は、[接続のテスト] スキャンを実行してください。[接続のテスト] が正常に完了したら、[状態の確認] スキャンを実行できます。

[接続のテスト] スキャンは、非常に速く実行されます。Exchange Server ベスト プラクティス アナライザは、1 つのレジストリ パラメータと 2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行します。最初の WMI クエリは WMI リポジトリ アクセスを検証し、2 番目の WMI クエリは、Exchange Server で使用されている Active Directory® ディレクトリ サービス サーバーに対してクエリを実行します。範囲で指定されているすべての Exchange Server のスキャンが完了すると、Exchange Server ベスト プラクティス アナライザは、Exchange Server で使用されている Active Directory サーバーについて、ネットワーク接続とアクセス許可の検証を試みます。

[ベースライン] スキャンでは、以下のタスクが実行されます。

  • プロパティの選択

  • 選択したプロパティに対するベースライン値の設定

  • それらのプロパティと比較するサーバーの選択

[ベースライン] スキャンでは、設定したベースライン値との相違点がないかどうかがチェックされます。[ベースライン] スキャンのレポートでは、選択されたサーバーの、選択されたプロパティの比較元の値と異なる値を持つすべてのプロパティが、ベースライン ミスマッチとして識別されます。

ベースライン スキャンを実行するには

  1. [新しいベスト プラクティス スキャンの開始] ページの [実行するスキャンの種類] メニューで、[ベースライン] を選択し、[ベースライン オプション] をクリックします。

  2. [ベースライン オプション] メニューで、既存のスキャンを選択するか、または新しいラベルを入力します。

  3. [比較元の値] 矢印をクリックして、ベースラインのプロパティの一覧を展開します。

    • これらのプロパティは、ExBPA.config.xml ファイルによって収集されたプロパティです。チェックボックスをオンまたはオフにして、ベースライン スキャンで比較するプロパティを選択します。プロパティの値には、ExBPA.config.xml ファイルにある既定値が設定されています。テキスト ボックスにこれらの値を設定します。

  4. [テストするオブジェクト] 矢印をクリックして、スキャンを実行するサーバーの一覧を展開します。

  5. ベースライン ミスマッチをスキャンするサーバーをすべて選択します。

ネットワーク速度の設定

スキャンの種類を選択したら、ネットワーク速度を設定します。ネットワーク速度を設定するには、以下の 4 つのオプションのいずれかを選択します。

  • 高速 LAN

  • LAN

  • 高速 WAN

  • WAN

ネットワーク速度の設定は、スキャンを完了するために必要な時間を見積もるために使用します。また、タイムアウト値の設定にも使用します。

スキャン中、Exchange Server ベスト プラクティス アナライザは、サーバーからの応答を指定された時間だけ待ちます。指定されたタイムアウト時間内に応答がない場合は、それ以上待たずに次の処理に進み、スキャンを完了します。低速なネットワークではネットワーク待ち時間が長いため、この指定されたタイムアウト時間は長くなります。Exchange Server ベスト プラクティス アナライザのタイムアウトが早すぎることがないように、このパラメータにはトポロジ内の最も低速なリンクを選択することをお勧めします。

スキャンの実行

スキャンのオプションをすべて設定したら、[スキャンを開始する] または [スキャンのスケジュール] を選択します。[スキャンを開始する] を選択すると、Exchange Server ベスト プラクティス アナライザによって直ちにスキャンが開始されます。詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン」を参照してください。

[スキャンのスケジュール] を選択すると、[スキャンのスケジュール] ページが表示されます。スキャンのスケジュールを行うには、最初に、必要なセキュリティ資格情報を入力し、[スケジュールに基づいてスキャンを実行する] ボックスを選択する必要があります。必要なセキュリティ資格情報の入力の詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールでのスキャンの設定」を参照してください。

次に、開始時刻を設定します。開始時刻は、スケジュールされた最初のスキャンを実行する日時です。

最後に、間隔を設定する必要があります。間隔とは、スケジュールされたスキャンを実行する頻度です。Exchange Server ベスト プラクティス アナライザを終了するには、[このツールを終了する] をクリックします。スケジュールされたスキャンを実行するために、Exchange Server ベスト プラクティス アナライザを実行する必要はありません。Exchange Server ベスト プラクティス アナライザを終了した場合、スケジュールされたスキャンは指定の日時にバックグラウンドで実行されます。スケジュールされたスキャンのレポートを表示するには、Exchange Server ベスト プラクティス アナライザを一度終了し、再起動する必要があります。

関連項目

概念

出力情報の種類

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン

© 2007 Microsoft Corporation. All rights reserved.


詳細な構成
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン >

トピックの最終更新日時 : 2006-10-26

Microsoft® Exchange Server アナライザ ツールには、次の構成可能なレジストリ パラメータがあります。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | OpenRelayTest
型 | REG_DWORD
説明 | ベスト プラクティス アナライザで各 SMTP サーバーの第三者中継機能をテストしない場合は、0x0 に設定します。このパラメータに値が指定されていない場合は、既定値の 0x1 に設定されます。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | OpenRelayTestSender
型 | REG_SZ
説明 | 第三者中継テストを実行する場合は、メールの送信元アドレスに使用する SMTP アドレスに設定します。このパラメータに値が指定されていない場合は、既定値の ExBPA-OpenRelayTest@Fabrikam.com に設定されます。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | TopoCreateTimeoutSecs
型 | REG_SZ
説明 | 第三者中継テストを実行する場合は、メールの受信先アドレスに使用する SMTP アドレスに設定します。このパラメータに値が指定されていない場合は、既定値の ExBPA-OpenRelayTest@Fabrikam.com に設定されます。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | SMTPTest
型 | REG_DWORD
説明 | ベスト プラクティス アナライザで、スキャンに含まれる各 SMTP サーバーにテスト メッセージを送信しない場合は、0x0 に設定します。このパラメータに値が指定されていない場合は、既定値の 0x1 に設定されます。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | SMTPTestSender
型 | REG_SZ
説明 | SMTP メール受信テストを実行する場合は、メールの送信元アドレスに使用する SMTP アドレスに設定します。このパラメータに値が指定されていない場合は、既定値の ExBPA-MailAcceptTest@Fabrikam.com に設定されます。

場所 | HKEY_CURRENT_USER\Software \Microsoft\Exchange\ExBPA
値 | T SMTPTestRecipient
型 | REG_SZ
説明 | SMTP メール受信テストを実行する場合は、メールの受信先アドレスに使用する SMTP アドレスに設定します。このパラメータに値が設定されていない場合は、既定値である、SMTP サービスで定義されているポストマスタ アカウントに設定されます。


Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2006-02-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールのレポートには、Exchange 組織のスキャンで収集されたデータの分析結果が表示されます。レポートの種類は、[List Reports]、[Tree Reports]、および [Other Reports] の 3 つから選択できます。

  • [List Reports] には、次の内容が含まれます。

    • 重大問題

    • すべての問題

    • 既定以外の設定

    • 最近加えられた変更

    • ベースライン

    • 情報

  • [Tree Reports] には、次の内容が含まれます。

    • 詳細表示

    • 概要表示

  • [Other Reports]

    • 非表示項目

    • ランタイム ログ

[List Reports]

既定のビューは、[重大問題一覧] です。[重大問題一覧] には、発見されたエラーのみが表示されます。エラーは、Exchange Server のパフォーマンスと可用性に直ちに影響する重大な問題です。[問題点の全リスト] には、エラー、警告、およびベスト プラクティスに対する違反が表示されます。[Non-Default Settings lisｔ] には、Exchange Server 製品のインストール後にサーバーに対して行われた構成変更の内容が表示されます。[Recent Changes list] には、過去 5 日間にサーバーに対して行われた構成変更の内容が表示されます。これには、Service Pack およびその他の更新プログラムのインストールも含まれます。[Baseline lisｔ] には、クラスタ内のノード間の構成の不一致が表示されます。

[Tree Reports]

[詳細表示] には、Exchange Server アナライザ ツールによって収集されたすべての構成設定が表示されます。[Summary View] には、Exchange 環境で見つかったすべての問題が階層表示されます。

[Other Reports]

[Hidden Items] レポートには、Exchange 管理者が他の Exchange Server アナライザ レポートで非表示にするよう選択した問題が表示されます。この一覧内の項目は、非表示設定になっていない場合には他のレポートに含めることができます。[Run-Time Log] レポートには、収集マイルストーン情報、および収集プロセスで返されたエラーが表示されます。

[重大問題一覧]、[問題点の全リスト]、および [Non-Default Settings lisｔ] では、エラーまたは警告に関する任意の問題をクリックして説明を表示することができます。次に、[この問題点と解決方法に関する詳しい情報を表示する] をクリックして、さらに詳細な情報を入手することができます。

注 :
スキャンの出力のデータ XML ファイルとログ ファイルは、<システム ドライブ>\Documents and Settings\<ユーザー>\Application Data\Microsoft\ExBPA に格納されています。

このセクション内

出力情報の種類

問題の解決と非表示

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの以前のレポートの表示


出力情報の種類

出力情報の種類 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容 >

トピックの最終更新日時 : 2006-09-29

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールのレポートには、以下の 7 種類の情報が表示されます。

  • エラー

  • 警告

  • 既定以外の構成

  • 最近加えられた変更

  • ベースライン ミスマッチ

  • ベスト プラクティス

  • 情報

エラー

エラーは、解決のための変更を必要とする重大な問題を示しています。たとえば、サーバーのインスタンスが停止している場合や、サーバーに到達できない場合はエラーに相当します。

エラーは以下のレポートに表示されます。

  • 重大問題一覧

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

エラーを無効にした場合、そのエラーは Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

エラーは 赤色の X 印で示されます (図 1)。

図 1 エラー アイコン

エラー状態を表すアイコン

警告

警告は、推奨されているベスト プラクティスではない問題を示しています。その問題を解決するための変更が必要な場合もありますが、変更する必要のない、Exchange Server 組織内の既知の問題である場合もあります。たとえば、サーバー上でサービスが開始されない場合は警告に相当します。

警告は以下のレポートに表示されます。

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

警告を無効にした場合、その警告は Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

警告は、黄色の警告記号で示されます (図 2)。

図 2 警告アイコン

警告アイコン (黒い感嘆符が付いた黄色い三角形)

既定以外の構成

既定以外の構成は、既定値から変更されている設定を示します。Exchange Server ベスト プラクティス アナライザによってエラーまたは警告であると判断された既定以外の構成は、既定以外の構成としてマークされ、レポート内の別の場所では状況に応じてエラーまたは警告の記号付きで表示されます。

既定以外の構成は、以下のレポートに表示されます。

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

既定以外の構成を無効にした場合、その構成は Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

既定以外の構成は、ドキュメントへのポインタの記号によって示されます (図 3)。

図 3 既定以外の構成のアイコン

既定値以外のプロパティを表すアイコン

最近加えられた変更

最近加えられた変更は、過去 5 日以内に変更された設定を示しています。Exchange Server ベスト プラクティス アナライザで、最近加えられた変更として識別できるのは、最終更新時刻のプロパティを持つ設定だけです。Exchange Server ベスト プラクティス アナライザによって、エラー、警告、または既定以外の構成であると判断された最近加えられた変更は、最近加えられた変更としてマークされ、レポート内の別の場所では状況に応じてエラー、警告、または既定以外の構成を示す記号付きで表示されます。

最近加えられた変更は、以下のレポートに表示されます。

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

最近加えられた変更を無効にした場合、その変更は Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

最近加えられた変更は、鉛筆型の変更記号で示されます (図 4)。

図 4 最近加えられた変更のアイコン

最新の変更を示すアイコン

ベースライン ミスマッチ

ベースライン ミスマッチは、ベースライン サーバーでの設定値とは異なる値を持つ設定を示しています。ベースライン ミスマッチを表示するには、ベースライン スキャンを実行する必要があります。Exchange Server ベスト プラクティス アナライザによって、エラー、警告、または既定以外の構成であると判断されたベースライン ミスマッチは、ベースライン ミスマッチとしてマークされ、状況に応じてエラー、警告、または既定以外の構成を示す記号付きで表示されます。

ベースライン ミスマッチは以下のレポートに表示されます。

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

ベースライン ミスマッチを無効にした場合、そのベースライン ミスマッチは Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

ベースライン ミスマッチは、クリップボードとチェック マークの記号で示されます (図 5)。

図 5 ベースライン ミスマッチのアイコン

ExBPA のベースライン レポートを表すアイコン

ベスト プラクティス

ベスト プラクティスのメッセージは、ベスト プラクティスとは見なされない設定を示しています。ベスト プラクティスのメッセージは、Exchange Server 組織の全体的な安定性には影響を与えないため、警告ではありません。ベスト プラクティスのメッセージは、推奨される操作です。Exchange Server ベスト プラクティス アナライザによって、既定以外の構成または最近加えられた変更であると判断されたベスト プラクティスのメッセージは、ベスト プラクティスのメッセージとしてマークされ、レポート内の別の場所では状況に応じて既定以外の構成または最近加えられた変更を示す記号付きで表示されます。

ベスト プラクティスのメッセージは以下のレポートに表示されます。

  • 問題点の全リスト

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

ベスト プラクティスのメッセージを無効にした場合、そのメッセージは Exchange Server ベスト プラクティス アナライザでは [無効な問題点リスト] に表示されます。

ベスト プラクティスのメッセージは、青色の感嘆符記号で示されます (図 6)。

図 6 ベスト プラクティスのアイコン

ベスト プラクティスの警告アイコン

情報

情報のメッセージは、Exchange Server ベスト プラクティス アナライザが他の 6 種類のレポート項目で提示しない情報を示します。情報項目として、たとえば Active Directory® ディレクトリ サービス内の Exchange Server オブジェクトの数を伝えることができます。

情報のメッセージは以下のレポートに表示されます。

  • 詳細表示一覧

  • 詳細表示 - 問題点の全リスト

情報項目は、小文字の "i" の記号で示されます (図 7)。

図 7 情報アイコン

情報を示すアイコン

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの構成

その他のリソース

問題の解決と非表示

© 2007 Microsoft Corporation. All rights reserved.


問題の解決と非表示
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容 >

トピックの最終更新日時 : 2006-02-08

Exchange 組織で Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを実行すると、解決すべき問題がレポートに一覧表示される場合があります。問題をクリックすると、説明と次の 3 つのオプションが表示されます。

  • 問題に関するさらに詳細な情報とその解決方法を検索する場合は、最初のオプションをクリックします。

  • このサーバーについて問題を非表示にする場合は、2 番目のオプションをクリックします。

  • 問題をすべてのサーバーについて非表示にする場合は、3 番目のオプションをクリックします。非表示にした問題は、このレポートの [重大問題一覧] や [問題点の全リスト]、さらには表示するその他のどのレポートにも表示されなくなります。非表示にした問題を表示するには、[Hidden Issues list] に移動します。[Hidden Issues list] で問題を表示して、[重大問題一覧] と [問題点の全リスト] に再度表示させることができます。

Exchange Server ベスト プラクティス アナライザ ツールが、問題を解決するために Exchange 組織に変更を加えることはありません。問題の解決方法に関する情報を表示するだけです。

このセクション内

出力情報の種類


Microsoft Exchange Server ベスト プラクティス アナライザ ツールの以前のレポートの表示

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの以前のレポートの表示 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 > Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容 >

トピックの最終更新日時 : 2005-07-08

新しいスキャンを実行するのではなく、Microsoft® Exchange Server ベスト プラクティス アナライザ ツールを使用して、以前のスキャンのレポートを表示することが必要な場合があります。

以前のレポートを表示するには

  1. ExBPA.exe を実行して、Exchange Server ベスト プラクティス アナライザを起動します。

  2. 最新のルールをダウンロードするかどうかを選択します。

  3. [ようこそ] ページで、[表示するベスト プラクティス レポートを選択する] を選択します。

  4. ローカルに格納されているレポートの一覧から、表示するレポートを選択します。

    ツールによって、<システム ドライブ>\Documents and Settings\<ユーザー>\Application Data\Microsoft\ExBPA に格納されているファイルから一覧が作成されます。レポートをクリックすると、このレポートのサイズと範囲に関する詳細情報が表示されます。レポート全体を表示するには、[このレポートを表示する] をクリックします。

    また、ページの右上にある [インポート レポート] をクリックして、別の場所からレポートをインポートすることもできます。使用している ExBPA.Config.xml ファイルのバージョンが、インポートされたレポート内のデータを収集するために使用されたバージョンと一致しない場合は、インポートの後、インポートされたファイルをツールが再度分析することがあります。

  5. Exchange Server ベスト プラクティス アナライザのレポートを表示します。

関連項目

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールの出力の内容

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server ベスト プラクティス アナライザ ツールがパフォーマンスに与える影響

Microsoft Exchange Server ベスト プラクティス アナライザ ツールがパフォーマンスに与える影響 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールは、Exchange 組織内の次のコンピュータのパフォーマンスに影響を与える場合があります。

  • Exchange Server ベスト プラクティス アナライザを実行しているコンピュータ

  • Active Directory® ディレクトリ サービスを実行しているサーバー

  • ツールがアクセスしている Exchange サーバー

Exchange Server ベスト プラクティス アナライザ ツールを実行しているコンピュータのパフォーマンス

Exchange Server ベスト プラクティス アナライザは、このツールを実行しているコンピュータの以下のリソースを使用します。

  • ツールがスキャンするサーバーごとに 5 ～ 10 MB の RAM

  • Exchange 組織のスキャン中に 50 ～ 75% の CPU

  • 拡張マークアップ言語 (XML) データの処理に 0.5 ～ 2 MB のディスク領域

Exchange Server ベスト プラクティス アナライザ ツールをインストールして実行するコンピュータの選択の詳細については、「Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール」を参照してください。

Active Directory サーバーのパフォーマンス

Exchange Server ベスト プラクティス アナライザ ツールは、Active Directory サーバーの以下のリソースを使用します。

  • ツールから Active Directory サーバーへのアクセス中に 25 ～ 50% の CPU

注 :
このツールは、Active Directory サーバーには不定期にアクセスし、各アクセス時間は平均 10 ～ 15 秒です。この時間は、非常に大きな Exchange 組織では長くなります。

Exchange サーバーのパフォーマンス

Exchange Server ベスト プラクティス アナライザ ツールが組織をスキャンしている間も、Exchange サーバーでは大幅なパフォーマンス低下は見られません。

注 :
ツールが Exchange サーバーからデータを収集するためにかかる時間は、Exchange サーバーの負荷とネットワーク速度に応じて変動します。低速なネットワークでは、データの収集に 1 時間以上かかります。高速なネットワークでは、データの収集に 10 分もかかりません。

関連項目

概念

Microsoft Exchange Server ベスト プラクティス アナライザ ツールのインストール

© 2007 Microsoft Corporation. All rights reserved.


コマンド ライン バージョンの Microsoft Exchange Server ベスト プラクティス アナライザ ツールの使用

コマンド ライン バージョンの Microsoft Exchange Server ベスト プラクティス アナライザ ツールの使用 |
 | 関連項目
Microsoft Exchange Server ベスト プラクティス アナライザ ツールの概要 >

トピックの最終更新日時 : 2005-07-08

Microsoft® Exchange Server ベスト プラクティス アナライザ ツールのコマンド ライン プログラム バージョンが使用できます。コマンド ライン プログラムの実行可能ファイルは ExBPACmd.exe であり、グラフィカル ユーザー インターフェイス (GUI) バージョンのインストール時に <システム ドライブ>\Program Files\ExBPA ディレクトリにインストールされます。場合によっては、GUI バージョンではなく、コマンド ライン プログラムの使用が必要な場合があります。たとえば、コマンド ライン プログラムを使用すると、スケジュールされたスキャンを実行するスクリプトを作成できます。別の例として、Microsoft 製品サポート サービスは、ユーザーの問題解決を支援するためにコマンド ライン プログラムの実行方法を教えることがあります。

ExBPACmd.exe の構文

使用方法 : ExBPACmd.exe [-cfg <構成 XML>] [-dat <データ XML>] [-d <ドキュメント名>] [-n <名前>] [-u <コンテキスト> <[ドメイン\]ユーザー> <パスワード | *> ...][-rs <範囲> <サブ1> ...][-rc <カテゴリ>,...][-rl <レベル>] [-th <最大スレッド数>] [-to <タイムアウト値>] [-a] [-c] [-e] [-?]

-cfg: 取得すべき設定を特定する構成 XML ファイルを指定します。既定値は ExBPA.Config.xml です。

-dat: 使用するデータ XML ファイルを指定します。現在のディレクトリにないデータ XML ファイル名を指定すると、出力ファイル用に指定されたファイル名が使用されます。分析スキャンを実行しているときに既存のデータ XML ファイル名を指定すると、ツールは指定されたファイル内に収集されているデータを読み取り、そのデータを分析した後、指定されたファイルをスキャンの出力で上書きします。収集スキャンを実行しているときに既存のデータ XML ファイル名を指定すると、ツールは指定されたファイルをスキャンの出力で上書きします。

分析スキャンを実行している場合の既定値は output.<ts>.xml です。ここで、<ts> は、現在のディレクトリにある最新のタイム スタンプです。収集スキャンを実行している場合の既定値は output.<ts>.xml です。ここで、<ts> は、新しいタイム スタンプです。

-d: Active® Directory ディレクトリ サービスにアクセスするために使用するドメイン コントローラを指定します。既定では、最も近い Active Directory サーバーが使用されます。

-n: ツールがスキャンしているトポロジの所有者を表す名前を指定します。

-u: コンテキストごとに別の資格情報を指定します。

有効なユーザー コンテキスト : Active Directory にログオンするための資格情報の場合は ADLOGON、Exchange サーバーにログオンするための資格情報の場合は EXLOGON です。

-rs: 指定された範囲内のオブジェクトのみを含むようにスキャンを制限します。<サブ> フィールドは、指定された範囲を表す値です。-rs スイッチを使用しない場合は、スキャンに Exchange 組織全体が含まれます。-rs スイッチを使用する場合は、スキャンを管理グループまたはサーバー別に制限できます。管理グループとサーバーは、どちらかを 1 つ以上指定できます。

有効な範囲 : 管理グループかサーバーです。

-rc: 指定されたカテゴリに一致する設定とオブジェクトのみを含むようにスキャンを制限します。設定とオブジェクトのカテゴリは、構成 XML ファイルで定義されます。-rc スイッチを使用してスキャンを 1 つのカテゴリに制限すると、スキャンには、定義されたそのカテゴリに該当する設定のみが含まれます。このスイッチには、複数のカテゴリを含めることができます。

-rc スイッチで使用できる有効なカテゴリは、構成 XML ファイルのバージョンによって異なる場合があります。使用しているバージョンの構成 XML ファイルで有効なカテゴリを特定するには、ExBPACmd.exe -? を実行します。

-rl: 指定された詳細レベル以下の設定とオブジェクトのみを含むようにスキャンを制限します。設定とオブジェクトの詳細レベルは、構成 XML ファイルで定義されます。既定値は 4 です。

-rl スイッチで使用できる有効なレベルは、構成 XML ファイルのバージョンによって異なる場合があります。使用しているバージョンの構成 XML ファイルで有効なレベルを特定するには、ExBPACmd.exe -? を実行します。

-th: 同時に実行するスレッドの最大数を設定します。既定値は 25 です。

-to: ツールが Exchange 組織内のサーバーからデータを収集している間に待つ既定の時間 (秒単位) を設定します。既定値は 300 秒です。

-a: 構成 XML ファイルのルールを使用して、データ XML ファイルを分析します。このオプションを使用すると、使用するデータ XML ファイルを指定して、収集スキャンの結果である既存の出力ファイルを分析できます。また、現在のディレクトリにはないデータ XML ファイルを指定するか、またはデータ XML ファイルを指定しないで、新しいスキャンのデータの収集と分析を行うこともできます。

-c: 構成 XML ファイルで指定された Exchange 組織からデータを収集します。ツールは、構成 XML ファイルのルールを使用してデータを分析することはせず、データを収集するだけです。分析 (-a) と収集 (-c) のどちらの操作手順も指定されていない場合は、このオプションが既定で有効になります。

-e: 構成 XML ファイルで NotForExport としてマークされた任意の設定値を、ツールが削除する必要があることを示します。

-?: : 構文の情報を表示します。

関連項目

その他のリソース

Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる Exchange 組織のスキャン

© 2007 Microsoft Corporation. All rights reserved.


Microsoft Exchange Server アナライザ - 文書

トピックの最終更新日時 : 2006-10-06

このセクションの文書は、次の Microsoft® Exchange アナライザによって生成されるルールと結果のメッセージに対応しています。

  • Exchange ベスト プラクティス アナライザ

  • Exchange トラブルシューティング アシスタント

Exchange トラブルシューティング アシスタントでは、以下の機能にアクセスできます。

  • Exchange Performance Troubleshooter

  • Exchange Database Troubleshooter

  • Exchange Database Recovery Management

  • Exchange Mail Flow Troubleshooter

各文書で、Exchange Server アナライザによって検出される可能性があるエラー、警告、または既定以外の構成であることを示すメッセージについて説明します。

Microsoft Exchange アナライザ Web ページ (http://go.microsoft.com/fwlink/?linkid=34707) には、最新バージョンの Exchange ベスト プラクティス アナライザと Exchange トラブルシューティング アシスタントのダウンロードが含まれます。さらに、このページにはシステム要件や、アナライザに関するディスカッションを目的としたニュースグループへのリンクもあります。

Exchange ベスト プラクティスの自動更新機能を利用できない環境で実行している場合は、Microsoft Exchange ベスト プラクティス アナライザの Web 更新パックの Web ページ (http://go.microsoft.com/fwlink/?linkid=34290) にアクセスしてください。最新の構成ファイルとヘルプ ファイルをダウンロードできます。

注 :
更新が自動的に適用される場合は、このダウンロードを使用する必要はありません。


Active Directory
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-17

このセクションの文書では、Microsoft® Exchange Server アナライザ ツールで、Active Directory® ディレクトリ サービスに関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出された Active Directory 関連のエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


Active Directory コネクタ サーバーが停止しているか、Active Directory コネクタ サーバーに到達できない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、リモート プロシージャ コール (RPC) を使用して、Active Directory コネクタ (ADC) サーバーの次のレジストリ キーから CurrentVersion 文字列の値を読み取ります。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

Microsoft Windows® 2000 Server が実行されているコンピュータでは、CurrentVersion 文字列の予想される値は 5.0 です。Microsoft Windows Server™ 2003 が実行されているコンピュータでは、予想される値は 5.2 です。

Exchange Server アナライザが何らかの理由でこのレジストリの値を読み取れない場合は、エラーが表示されます。

このエラーを修正するには

  1. ADC サーバーが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、ADC サーバーが到達可能かどうかを確認します。

  3. ファイアウォールが設置されている場合は、RPC ポートがブロックされているかどうかを調べます。

  4. ADC サーバーで、リモート レジストリ サービスが開始されていることを確認します。

  5. Exchange Server アナライザが実行されているアカウントのアクセス許可を調べ、そのアカウントに、ADC サーバーのレジストリを読み取るための十分なアクセス許可が与えられていることを確認します。

ネットワーク接続に関する問題のトラブルシューティングの詳細については、以下を参照してください。

  • Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • 『Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems』(http://go.microsoft.com/fwlink/?LinkId=56285) (このサイトは英語の場合があります)


Active Directory コネクタ サーバーが接続許可書を実行していないため、削除の対象になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchChildSyncAgreements 属性の値を判断します。この値は、Active Directory コネクタ (ADC) サーバーで実行されている接続許可書を表します。この属性は複数値の文字列で、Active Directory オブジェクトである CN=Active Directory Connector (サーバー名),CN=Exchange Settings,CN=サーバー名,CN=Servers,CN=サイト名,CN=Sites,CN=Configuration,DC=ドメイン名,DC=com に設定されます。

Exchange Server アナライザは、この属性に含まれるエントリ数 (カウント) を取得します。カウントが 0 の場合、接続許可書が実行されていないことを示し、警告が表示されます。

必要な接続許可書がすべて他の ADC サーバーで実行されていることが検出された場合は、このサーバーの ADC サービスを削除または無効化する必要があります。接続許可書なしで ADC サービスを実行しても、問題が発生することはありません。ただし、ベスト プラクティスとしては、不要なサービスを実行しないことをお勧めします。したがって、ADC サーバー上の ADC サービスを無効にするか、ADC サーバーから ADC サービスをアンインストールする必要があります。

この警告を修正するには

  1. ADC サービスを実行しているサーバーで ADC サービスを無効にするには、デスクトップの [マイ コンピュータ] を右クリックし、[管理] をクリックします。

  2. [サービスとアプリケーション] ノードを展開し、[サービス] ノードをクリックします。

  3. 右側のペインで [Microsoft Active Directory Connector] を右クリックし、[プロパティ] をクリックします。

  4. [スタートアップの種類] を [無効] に変更します。これにより、次回コンピュータを起動する際に、ADC サービスが開始されなくなります。

  5. [適用] をクリックし、[OK] をクリックします。

ADC サービスをアンインストールする場合は、Microsoft Exchange 2000 Server または Exchange Server 2003 の CD を使用します。\ADC\I386 フォルダに移動し、Setup.exe プログラムをダブルクリックします。表示されるメッセージに従って、ADC サービスをアンインストールします。

Active Directory コネクタの詳細については、以下の Microsoft Support WebCast を参照してください。

  • 「サポート : Active Directory コネクタの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325300)

  • 「サポート : Active Directory コネクタを詳細 Microsoft」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325221)

  • Active Directory コネクタのインストールおよび構成の詳細については、Microsoft サポート技術情報の文書番号 312632「[HOW TO] Exchange 2000 Server で Active Directory コネクタをインストールおよび構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=312632) を参照してください。


Active Directory コネクタ サーバーで Windows 2000 Server の最新の Service Pack が実行されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory コネクタ (ADC) サーバーの ServicePackMajorVersion キーの値を判断します。また、Exchange Server アナライザは次のレジストリ エントリを調べて、ADC サーバーで実行されている Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

ADC サーバーで Microsoft Windows 2000 Server オペレーティング システムが実行されていても、Windows 2000 Server の Service Pack 4 が実行されていないと判断されると、警告が表示されます。

ベスト プラクティスとして、Exchange の展開内に存在する、ADC サーバーを含むすべてのソフトウェアで最新の Service Pack を実行することをお勧めします。

このエラーを修正するには

  1. Windows 2000 Server オペレーティング システムを実行している ADC サーバーおよびその他のサーバーを SP4 に更新し、さらに Windows Update から最新の修正プログラムと更新を適用します。

  2. Windows 2000 Server オペレーティング システムを実行している他の Exchange Server コンピュータをすべて、最新の Service Pack および更新プログラムのロールアップに更新します。

Windows 2000 Server オペレーティング システムの Service Pack の入手とインストールの詳細については、http://go.microsoft.com/fwlink/?LinkId=18353 を参照してください (このサイトは英語の場合があります)。

Exchange Server の Service Pack や更新プラグラムのロールアップの入手、およびインストールの詳細については、http://go.microsoft.com/fwlink/?LinkId=21573 を参照してください (このサイトは英語の場合があります)。


Active Directory コネクタ サーバーが過負荷になっている可能性がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchChildSyncAgreements 属性の値を判断します。この値は、Active Directory コネクタ (ADC) サーバーで実行されている接続許可書を表します。この属性は複数値の文字列で、Active Directory オブジェクトである CN=Active Directory Connector (サーバー名),CN=Exchange Settings,CN=サーバー名,CN=Servers,CN=サイト名,CN=Sites,CN=Configuration,DC=ドメイン名,DC=com に設定されます。

Exchange Server アナライザは、この属性に含まれるエントリ数 (カウント) を取得します。カウントが 80 を超えている場合は、警告が表示されます。

実行時の接続許可書の数は、ADC サーバーあたり 80 未満とすることをお勧めします。推奨される最大数より少ない接続許可書数をホストしている ADC サーバーが他にある場合は、カウントが 80 を超えているサーバーからそれらの ADC サーバーに、一部の接続許可書を移動します。ADC サーバーが他にない場合は、Microsoft Exchange 2000 Server または Exchange Server 2003 に含まれている ADC プログラムを、Microsoft Windows® 2000 Server または Microsoft Windows Server™ 2003 コンピュータが実行されている別のコンピュータにインストールします。

接続許可書を別の ADC サーバーに移動しても、特定の接続許可書のコア属性は変更されません。たとえば、レプリケーションに使用されるレプリケーション元コンテナとレプリケーション先コンテナ、およびレプリケートするように構成されているデータは変更されません。接続許可書を移動すると、その接続許可書を実行していた ADC サーバーのみが変更されます。

この警告を修正するには

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をクリックします。次に、[管理ツール] をポイントし、[Active Directory コネクタの管理] をクリックして ADC 管理コンソールを開始します。

  2. MMC コンソールの左側のペインに、ADC サービスを実行しているサーバーの一覧が表示されます。移動する接続許可書が置かれているサーバーの ADC を選択します。

  3. MMC コンソールの詳細ペインに、選択した ADC サーバーにホストされている接続許可書が表示されます。

  4. 移動する接続許可書を右クリックし、[プロパティ] をクリックします。

  5. [全般] タブの [接続許可書を実行するサーバーの選択] の一覧で、この接続許可書を実行するサーバーを選択し、[OK] をクリックします。

  6. [接続するユーザー (Windows サーバー)] ダイアログ ボックスで、ADC サービス用のアカウント名とパスワードを入力し、[OK] をクリックします。

  7. [接続するユーザー (Exchange サーバー)] ダイアログ ボックスで、Exchange サービス用のアカウント名とパスワードを入力し、[OK] をクリックします。

接続許可書の移動の詳細については、Microsoft サポート技術情報の文書番号 326060「XADM: 別のサーバーに接続許可書を移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=326060) を参照してください。

Exchange 2000 Server の ADC プログラムを別のサーバーにインストールする方法の詳細については、Microsoft サポート技術情報の文書番号 312632「[HOT TO] Exchange 2000 Server で Active Directory コネクタをインストールおよび構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=312632) を参照してください。

Exchange Server 2003 の ADC プログラムを別のサーバーにインストールする方法の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。


Active Directory コネクタ ソフトウェアを更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-10-10

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory コネクタ (ADC) ファイルである Adc.exe の Version キーの値を判断します。Version WMI キーは、このファイルのビルド番号を示しています。

Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してもクエリを実行し、Active Directory のフォレスト オブジェクトである NTDS Settings の msDS-Behavior-Version 属性値を判断します。この値は、Active Directory フォレストの機能レベルを示しています。以下の表に、msDS-Behavior-Version 属性の有効な値を示します。

値 | フォレストの機能レベル
0 | Microsoft Windows 2000 Server 混在
1 | Windows Server™ 2003 中間
2 | Windows Server 2003 ネイティブ

Exchange Server アナライザによって、Windows Server 2003 中間またはネイティブ モードにある Active Directory フォレスト内で Exchange Server を実行しているコンピュータ上の Adc.exe のビルド番号が 6.0.6615.0 より小さいことが検出されると、エラーが表示されます。このエラーは、Exchange 2000 Server バージョンの ADC プログラムが、互換性のない Windows Server 2003 Active Directory フォレスト レベルで実行されていることを示しています。この問題を解決するには、Exchange ADC (Active Directory Connection) プログラムの更新を行う必要があります。

混在またはネイティブのフォレスト機能レベルで古いバージョンの ADC を実行すると、不完全なディレクトリの更新やデータの損失が発生する可能性があります。組織内のすべてのコンピュータで、ADC を最新の Exchange Server 2003 バージョンにアップグレードすることをお勧めします。

最新バージョンの ADC、および最新の Exchange Server 2003 Service Pack は、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) からダウンロードできます。また、ADC の Exchange Server 2003 最終バージョンは、Exchange Server CD からインストールすることもできます。

最新バージョンの ADC にアップグレードするには

  1. 古いバージョンの ADC を実行しているサーバーで、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「E:\setup\adc\i386\setup.exe」と入力します。E は、ダウンロードした Exchange Server Service Pack の場所です。

  2. [Active Directory コネクタ インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  3. [検出された以前のインストール] ページで、[再インストール] をクリックして ADC をアップグレードします。

  4. [Active Directory コネクタ インストール ウィザードの完了] ページで、[完了] をクリックします。

フォレストの機能レベルがどのように ADC に影響するかの詳細については、Microsoft サポート技術情報の文書番号 825916 の Exchange 2000 Active Directory コネクタで、フォレストの機能レベルが 1 または 2 の Windows Server 2003 Active Directory のグループ メンバシップに対する変更が正常にレプリケートされない現象についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=825916) を参照してください。

ドメインとフォレストの機能レベルの詳細については、Microsoft サポート技術情報の文書番号 322692 の、[HOWTO] Windows Server 2003 でドメインの機能レベルおよびフォレストの機能レベルを上げる方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322692) を参照してください。


Active Directory フォレストが Hosted Exchange 用に構成されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Microsoft Active Directory® ディレクトリ サービスに対してクエリを実行し、Global-Address-List スキーマ属性オブジェクトの LinkID 属性の値を判断します。Global-Address-List オブジェクトは、新しく作成されたグローバル アドレス一覧 (GAL) の識別名を格納するために Exchange コンテナ上で使用されます。

Exchange Server アナライザによって、Global-Address-List オブジェクトの LinkID 属性の値が 4,048 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。4,048 の値は、Active Directory フォレストが Hosted Exchange 環境用に構成されていることを示しています。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Hosted Exchange 環境の詳細については、以下の資料を参照してください。

  • 「Information for Hosters」(http://go.microsoft.com/fwlink/?LinkId=46307) (このサイトは英語の場合があります)

  • 『Exchange Server 2000 Resource Kit』の「Chapter 23 - Hosted Service Environments」(http://go.microsoft.com/fwlink/?LinkId=46326) (このサイトは英語の場合があります)


Active Directory サーバーが停止しているか、Active Directory サーバーに到達できない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、リモート プロシージャ コール (RPC) を使用して、Active Directory® ディレクトリ サーバーの次のレジストリ キーから CurrentVersion 文字列の値を読み取ります。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

Microsoft Windows® 2000 Server が実行されているコンピュータでは、CurrentVersion 文字列の予想される値は 5.0 です。Windows Server™ 2003 が実行されているコンピュータでは、予想される値は 5.2 です。

Exchange Server アナライザが何らかの理由でこのレジストリの値を読み取れない場合は、エラーが表示されます。

このエラーを修正するには

  1. ディレクトリ サーバーが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、ディレクトリ サーバーが到達可能かどうかを判断します。

  3. ファイアウォールが設置されている場合は、RPC ポートがブロックされているかどうかを調べます。

  4. ディレクトリ サーバーの Remote Registry サービスが開始されていることを確認します。

  5. Exchange Server アナライザが実行されているアカウントのアクセス許可を調べ、Active Directory サーバーのレジストリを読み取るための十分なアクセス許可がアカウントに与えられていることを確認します。

ネットワーク接続に関する問題のトラブルシューティングの詳細については、以下を参照してください。

  • Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • 『Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems』(http://go.microsoft.com/fwlink/?LinkId=56285) (このサイトは英語の場合があります)


Active Directory サーバーに実装されているメモリは 1 GB 未満だが、Boot.ini ファイルに /3GB スイッチおよび /USERVA=3030 スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory® ディレクトリ サーバーに実装されている物理メモリの量と、ユーザー モード プロセスに割り当てられている仮想アドレス スペースの量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クラス | キー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_OperatingSystem | OSProductSuite | オペレーティング システムにインストールされ、ライセンスされている追加のシステム製品
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されているランダム アクセス メモリ (RAM) の量

ディレクトリ サーバーに実装されている RAM が 950 MB 未満であり、かつ MaxProcessMemorySize の値が 2097024 より大きく 3104640 未満であることが検出されると、警告が表示されます。

この警告は、このディレクトリ サーバーが、次の 2 つの点でメモリ使用が最適になるように正しく構成されていないことを示しています。

  • /USERVA=3030 起動スイッチが設定されている。このスイッチが必要なのは、1 GB 以上のメモリが実装され、Microsoft Windows Server™ 2003 オペレーティング システムが実行されている Exchange Server コンピュータのみです。

  • /3GB 起動スイッチが設定されている。このスイッチは、1 GB 以上のメモリが実装され、以下のいずれかのオペレーティング システムが実行されている Exchange サーバーでのみ使用してください。

    • Microsoft Windows Server 2003 Standard Edition

    • Microsoft Windows Server 2003 Enterprise Edition

    • Microsoft Windows Server 2003 Datacenter Edition

    • Microsoft Windows 2000 Advanced Server

    • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。さらに、/3GB スイッチは、1 GB 以上の物理メモリが実装されている場合に、上記のオペレーティング システムでのみサポートされています。

1 GB の物理メモリが実装されているシステムでこの警告が表示される場合は、この物理メモリの一部にハードウェア レベルで別のコンポーネント (ビデオ カードなど) がすでに割り当てられているために、割り当てられた物理メモリがオペレーティング システムから使用できなくなっていることを示している可能性があります。このような場合は、Windows に従って物理的に実装されているメモリの量は、コンピュータに実装されている実際の物理メモリの量よりも少なくなります。この状況が発生した場合は、BIOS によって報告される実装済みメモリの量と、Windows によって報告される実装済みメモリの量を比較する必要があります。

Windows Server 2003 でこの警告を修正するには

  1. [マイコンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] をクリックします。

  3. [起動と回復] で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] で、[編集] をクリックします。Windows の Boot.ini ファイルがメモ帳に表示されます。

  5. [Operating Systems] セクションで、すべての起動行から /3GB /USERVA=3030 スイッチを削除します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

Windows 2000 Server でこの警告を修正するには

  1. Windows エクスプローラで、システム パーティションを見つけます。

  2. Boot.ini ファイルが表示されない場合は、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合は、エクスプローラで [ツール] をクリックし、[フォルダ オプション] をクリックします。次に、[表示] をクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. エクスプローラに Boot.ini ファイルが表示されたら、すぐにそのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から /3GB /USERVA=3030 スイッチを削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

/3GB および /USERVA 起動スイッチの使用方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 308356「Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 文書番号 297812「4GT RAM チューニング機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory サーバーに実装されているメモリは 1 GB 未満だが、Boot.ini ファイルに /3GB スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory® ディレクトリ サーバーに実装されている物理メモリの量と、ユーザー モード プロセスに割り当てられている仮想アドレス スペースの量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クラス | キー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_OperatingSystem | OSProductSuite | オペレーティング システムにインストールされ、ライセンスされている追加のシステム製品
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されているランダム アクセス メモリ (RAM) のバイト数

ディレクトリ サーバーに実装されている RAM が 950 MB 未満であり、かつ MaxProcessMemorySize の値が 2097024 より大きく 3104640 未満であることが検出されると、警告が表示されます。

この警告は、このディレクトリ サーバーが、メモリ使用が最適になるように正しく構成されていないことを示しています。このコンピュータには /3GB 起動スイッチが設定されており、このスイッチを削除する必要があります。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Active Directory サーバーでのみ使用してください。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server™ 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では /3GB スイッチを使用しないでください。サポート対象外であり、アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があります。/3GB スイッチがサポートされるのは、物理メモリが 1 GB 以上搭載されている上記のオペレーティング システムだけです。

1 GB の物理メモリが実装されているシステムでこの警告が表示される場合は、この物理メモリの一部にハードウェア レベルで別のコンポーネント (ビデオ カードなど) が既に割り当てられているために、割り当てられた物理メモリがオペレーティング システムから使用できなくなっていることを示している可能性があります。このような場合、Windows に従って物理的に実装されているメモリの量は、コンピュータに実装されている実際の物理メモリの量よりも少なくなります。この状況が発生した場合は、BIOS によって報告される実装済みメモリの量と、Windows によって報告される実装済みメモリの量を比較する必要があります。

Windows Server 2003 でこの警告を修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] をクリックします。

  3. [起動と回復] で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  5. [Operating Systems] セクションで、すべての起動行から次のスイッチを削除します。/3GB

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

Windows 2000 Server でこの警告を修正するには

  1. Windows エクスプローラで、システム パーティションに移動します。

  2. boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、エクスプローラで [ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。-[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から次のスイッチを削除します。/3GB

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

/3GB 起動スイッチの使用方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 308356「Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 文書番号 297812「4GT RAM チューニング機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOW TO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory サーバーで Windows 2000 Server が実行され、/3GB スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ユーザー モード プロセスに割り当てられた仮想アドレス スペースの容量 (MaxProcessMemorySize) と、Active Directory® ディレクトリ サービス サーバーで実行されている Windows のバージョン (OSProductSuite) を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

Exchange Server アナライザによって、MaxProcessMemorySize の値が 3104640 であり、OSProductSuite の値が Windows 2000 Server に解決されていると判断されると、エラーが表示されます。

このエラーは、Microsoft Windows 2000 Server が実行されているディレクトリ サーバー上の Boot.ini ファイルで、/3GB 起動スイッチが設定されていることを示します。このスイッチは、Windows 2000 Server ではサポートされていません。以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ コンピュータでのみ使用可能です。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

Boot.ini ファイルから /3GB スイッチを削除するには

  1. エクスプローラから、システム パーティションに移動します。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、エクスプローラで [ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. エクスプローラに Boot.ini ファイルが表示されたら、ファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から /3GB /USERVA=3030 スイッチを削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. ディレクトリ サーバーを再起動して、変更を有効にします。

/3GB 起動スイッチの使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 297812「4GT RAM チューニング機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Active Directory Server レジストリにアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、各ドメイン コントローラ上で次のレジストリ エントリを読み取ります。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion\CurrentVersion

Exchange Server アナライザが何らかの理由でこのレジストリ値を読み取ることができない場合は、エラーが表示されます。

このエラーを修正するには

  1. ドメイン コントローラが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、ドメイン コントローラにアクセスできるかどうかを確認します。

  3. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを調べます。

  4. ドメイン コントローラ上で、リモート レジストリ サービスが開始されていることを確認します。

  5. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザを実行しているアカウントは、スキャン対象の各ドメイン コントローラ上で管理者アクセス許可を持っている必要があります。

ネットワーク接続に関する問題のトラブルシューティングの詳細については、以下を参照してください。

  • Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • 『Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems』(http://go.microsoft.com/fwlink/?LinkId=56285) (このサイトは英語の場合があります)

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


利用可能な Active Directory サーバー ソフトウェアの更新プログラム
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-02-20

Microsoft Exchange アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Name プロパティの値を判断します。Name プロパティは、Exchange サーバーが Active Directory ディレクトリ サービス参照に使用するドメイン コントローラのコンピュータ名を指定します。

次に、Active Directory に対してクエリを実行し、そのドメイン コントローラの特定の属性値を問い合わせ、次の状態について判断します。

  • Active Directory ドメイン コントローラで Windows Server 2003 オペレーティング システムが稼働しているかどうか

  • Active Directory ドメイン コントローラで英語以外のバージョンの Microsoft Windows Server 2003 オペレーティング システムが稼働しているかどうか

  • Exchange 組織に Microsoft Exchange Server 2007 サーバーが存在するかどうか

  • サーバー上の ntdsa.dll ファイルの Version キーの値が 2700 未満であるかどうか

これらのすべての条件が当てはまることが検出されると、警告が表示されます。

この警告は、Exchange Outlook Web Access クライアントで、Exchange アドレス帳のインデックス処理に関する問題が発生している可能性があることを示します。

Outlook Web Access では、ユーザー インターフェイス (UI) で使用する言語を選択できます。選択した言語によってロケール設定が決まります。また、Outlook Web Access ではこの言語を使用してアドレス帳などの Active Directory の結果が並べ替えられます。Exchange が仮想一覧表示 (VLV) クエリを実行し、ドメイン コントローラで利用できない言語を指定した場合は、エラーが発生します。この問題は、VLV クエリで指定された言語がドメイン コントローラの言語に一致しない場合に、Exchange で別の言語を使用できるようにする既定のインデックス処理機構が現在存在していないために起こります。

この警告に対処するには、マイクロソフト サポート技術情報の文書番号 919166「アドレス帳関数同じロケールが設定していることが Exchange OWA クライアントと Windows Server 2003-based ドメイン コントローラにないとき、Exchange 2007 が切断されます。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=919166) で説明されている更新プログラムを入手してインストールしてください。


Active Directory サーバーの WMI にアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ドメイン コントローラの Name キーに値が設定されているかどうかを判断します。WMI クエリが失敗すると、エラーが表示されます。

このエラーには、次の 2 つの原因が考えられます。

  • Exchange Server アナライザを実行するアカウントが、WMI 情報に対してクエリを実行するための十分なアクセス許可を持っていない。

  • ネットワークの問題により、Exchange Server アナライザからコンピュータにアクセスできない。

このエラーを修正するには

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを調べます。

  4. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

    または、Exchange Server アナライザの実行に使用するアカウントに、特定の WMI アクセス許可を与えることもできます。

    1. Exchange コンピュータで、[コンピュータの管理] MMC のコンソール ツリーを開きます。

    2. [サービスとアプリケーション] で、[WMI コントロール] を右クリックし、[プロパティ] をクリックします。

    3. [WMI コントロールのプロパティ] ページで、[セキュリティ] タブをクリックし、[Root] を展開します。

    4. [CIMV2] フォルダを選択し、[セキュリティ] をクリックします。

    5. [セキュリティ ROOT\CIMV2] ページで、Exchange Server アナライザの実行に使用するアカウントを追加します。

    6. 手順 e. で追加したアカウントを選択し、[<選択したアカウント> のアクセス許可] の [許可] 列で、[リモートの有効化] チェック ボックスと [セキュリティの読み取り] チェック ボックスをオンにします。次に、[OK] をクリックします。

ネットワーク接続に関する問題のトラブルシューティングの詳細については、以下を参照してください。

  • Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487)

  • 『Microsoft Exchange Server Best Practices Analyzer Tool Troubleshooting Connectivity Problems』(http://go.microsoft.com/fwlink/?LinkId=56285) (このサイトは英語の場合があります)

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


ADCDisabledMail 属性が検出された
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange 組織が混在モードまたはネイティブ モードのどちらにあるのかを判断します。Exchange 組織がネイティブ モードにあることが検出されると、Exchange Server アナライザは Active Directory に対してクエリを実行し、組織のドメイン内に legacyExchangeDN 属性の値が ADCDisabledMail に設定されたメールが有効なオブジェクトが存在するかどうかを判断します。legacyExchangeDN 属性の値が ADCDisabledMail に設定されたメールが有効なオブジェクトが検出されると、それらのオブジェクトと所属するドメインが列挙された警告が表示されます。

この問題は、メールボックスが削除された場合に、Exchange 2000 Server 環境と Exchange Server 2003 環境の両方で発生する可能性があります。メールボックスが削除されると、アカウントの legacyExchangeDN 属性の値に ADCDisabledMail のスタンプが付けられます。この値は、Active Directory コネクタ (ADC) に対して、Active Directory 内で関連付けられたオブジェクトのメールが無効になったらそのオブジェクトを Exchange Server 5.5 ディレクトリ サービスから削除するよう指示するために使用されます。大規模な配布グループ内に削除されたメールボックスが複数存在する場合、このメッセージは、ADCDisabledMail の一意の legacyExchangeDN 属性値が Active Directory 内で検索されている間に表示されます。この同じ legacyExchangeDN 属性値 を持つメールボックスが複数存在する可能性があるため、この検索には長い時間がかかります。これにより、メッセージの配信に遅延が発生します。メッセージ配信の遅延は、Microsoft Office Outlook® 2003 クライアントからのメッセージの [宛先]/[CC]/[BCC] 行で配布グループが展開されている場合にも発生します。

この警告を解決するには、これらのオブジェクトを削除するか、または Active Directory サービス インターフェイス (ADSI) Edit ツール、ldp.exe ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用してlegacyExchangeDn 属性の内容を削除します。legacyExchangeDN 属性値が NULL に設定されている場合は、Active Directory に対する検索が "/O=NT5/ou=<ドメインの objectGUID>/cn=<ユーザーの objectGUID>" に設定され、配信不能レポート (NDR) がはるかに早く送信されます。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
legacyExchangeDN 属性の ADCDisabledMail 値を削除するには

  1. Windows 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • ドメイン コンテナ

    • DC=ドメイン名

    • [Users] コンテナ

  3. [<ユーザー名>] を右クリックし、[プロパティ] をクリックします。

  4. [Attributes] の一覧で [legacyExchangeDN] をクリックし、[Edit] をクリックします。

  5. 元の値を選択し、[Clear] をクリックして、ADCDisabledMail を含む元の legacyExchangeDN 値を削除します。

  6. [OK] を 2 回クリックして変更を適用します。

ADSI Edit の操作方法の詳細については、Windows Server オンライン ヘルプのトピック「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。


アドレス一覧のフィルタ設定が原因で新しい受信者がアドレス一覧に表示されない可能性がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各アドレス一覧オブジェクトの purportedSearch 属性に設定されている属性を判断します。purportedSearch 属性に "proxyAddresses=*" という文字列が含まれていることが検出されると、エラーが表示されます。

新しいユーザー オブジェクトを作成すると、受信者更新サービスによってその受信者オブジェクトに、プロキシ アドレスなどの固有の属性が割り当てられます。ただし、受信者更新サービスが ShowInAddressBook 属性の割り当てに失敗する可能性もあります。受信者オブジェクトの ShowInAddressBook 属性は、その受信者が含まれているアドレス一覧を示しています。この属性が割り当てられていない受信者オブジェクトは、そのオブジェクトがアドレス一覧フィルタの条件を満たしていても、グローバル アドレス一覧またはその他のどのアドレス一覧にも表示されません。

この状況は、1 つ以上のアドレス一覧フィルタに proxyAddresses 属性が含まれている場合に発生することがあります。この状況に当てはまるかどうかは、各アドレス一覧のプロパティを確認し、[フィルタのルール] ボックスに "proxyAddresses=*" という文字列が含まれているかどうかを調べることによって判断できます。

受信者更新サービスが受信者オブジェクトに属性を正しく割り当てられるようにして、受信者オブジェクトがグローバル アドレス一覧やその他のアドレス一覧に表示されるようにするには、次の手順を実行します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[すべてのグローバル アドレス一覧] を展開します。次に、[受信者ポリシー] を選択します。

  3. 右側のペインで、編集するアドレス一覧を右クリックし、[プロパティ] をクリックします。

  4. [プロパティ] ページの [全般] タブで、[フィルタのルール] の [変更] をクリックします。

  5. [Exchange 受信者を検索します] ボックスの一覧の [カスタムの検索条件] をクリックします。アドレス一覧が最初にカスタム検索によって作成されている場合は、手順 3. で [変更] をクリックすると [カスタムの検索条件を検索します] ページが表示されます。

  6. 条件一覧の [プロキシ アドレスが *] エントリをクリックし、[削除] をクリックします。

  7. [OK] をクリックしてダイアログ ボックスを閉じます。

  8. 受信者ポリシーを右クリックし、[今すぐこのポリシーを適用] をクリックします。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328738)

  • 文書番号 319065「[HOWTO] Exchange 2000 での受信者更新サービスの使用方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319065)


管理グループのモードが不明である
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory 内の [管理グループ] コンテナにある管理グループ オブジェクトの msExchAdminGroupMode 属性をチェックすることにより、その管理グループのモードを確認します。msExchAdminGroupMode 属性の値が 0、1、2 のいずれでもないことが検出されると、エラーが表示されます。

Exchange は管理グループのモードを使用して、その管理グループに Exchange 5.5 サーバーか、Exchange Server 2003 サーバー (または EXchange 2000 Server サーバー) のどちらを含めることができるかを示しています。この属性の値が 0、1、2 のいずれでもない場合は、管理者がこの値を手動で変更した可能性があります。Exchange セットアップ プログラムや Exchange システム マネージャが、この値を誤って設定することはありません。

この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントといったツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

MSExchAdminGroupMode 属性を変更するには

  1. ADSI Edit などの Active Directory エディタを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    MSExchAdminGroupMode 属性は次の場所にあります。

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN=管理グループ

  2. 次のいずれかの整数を入力します。

    0= ネイティブ モード (この管理グループは、Exchange 2000 Server または Exchange Server 2003 を使用して作成されています)

    1= Exchange Server 5.5 モード (この管理グループは Exchange Server 5.5 を使用して作成され、Exchange Server 5.5 サーバーのみが含まれています)

    2= 混在モード (この管理グループには、Exchange Server 5.5 サーバーと、Exchange 2000 Server サーバーまたは Exchange Server 2003 サーバーの両方を含めることができます)

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server オンライン ヘルプのトピッ ク「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。


Hosted Exchange の Authenticated Users が正しく構成されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server 環境が Hosted Exchange 環境として構成されているかどうかを判断します。Exchange Server 環境が Hosted Exchange 環境の場合、Exchange Server アナライザは Active Directory に対してクエリを実行し、ドメイン内の Pre-Windows® 2000 Compatible Access グループに Authenticated Users グループが含まれているかどうかを判断します。

Authenticated Users グループが Pre-Windows 2000 Compatible Access グループのメンバである場合は、警告が表示されます。この構成は、Hosted Exchange ソリューションにはお勧めできません。

この警告を修正するには、Pre-Windows 2000 Compatible Access セキュリティ グループから Authenticated Users グループを削除します。

  1. [Active Directory ユーザーとコンピュータ] を起動します。

  2. ドメイン ノードを展開し、[Builtin] コンテナをクリックします。

  3. [Pre-Windows 2000 Compatible Access] セキュリティ グループを右クリックし、[プロパティ] をクリックします。

  4. [メンバ] タブをクリックします。

  5. [Authenticated Users] を選択します。

  6. [削除] をクリックします。

  7. [OK] をクリックします。

Hosted Exchange 環境の詳細については、以下の資料を参照してください。

  • "「Information for Hosters」(http://go.microsoft.com/fwlink/?LinkId=46307) (このサイトは英語の場合があります)

  • 『Exchange 2000 Server Resource Kit』(http://go.microsoft.com/fwlink/?LinkId=46326) の「Chapter 23 - Hosted Service Environments」(このサイトは英語の場合があります)


証明書のプリンシパルが一致しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバー システム内の Server Certificate オブジェクトに対してクエリを発行し、X509 証明書に関するさまざまなプロパティを取得します。Exchange Server アナライザは、見つかった各 SSL (Secure Sockets Layer) 証明書の Principal 属性を評価し、その証明書に割り当てられていた www.microsoft.com などの完全修飾ドメイン名 (FQDN) を識別します。

Microsoft Exchange Server アナライザは、Principal FQDN がホスト アドレスまたは URL と一致しない場合、警告を発行します。証明書の Principal が一致しないという警告が発生したということは、ユーザーが Microsoft Office Outlook® Web Access for Exchange Server 2003、Outlook Anywhere for Exchange Server 2007、Exchange Server ActiveSync、および RPC over HTTP を使用してメールボックスに接続できない可能性があることを意味しています。

注 :
サーバーは、SSL プロトコルを実行するときにサーバー証明書を持っている必要があります。オプションとして、サーバーはクライアントの証明書を要求できます。サーバー証明書には、Web サイトの名前が格納されています。ブラウザは、Web サイトの名前が、入力した名前と一致することを確認します。たとえば、https://www.example.com のような Web サイトがある場合、証明書の名前は www.example.com である必要があります。

以下のいずれかの条件に当てはまる場合、不一致になる可能性があります。

  • 証明書を誤って正しくないサーバーに適用する。

  • サーバーが複数のホスト名を持っている場合に、クライアントがホストの正しくない URL を使用してサーバーのデータにアクセスする。

証明書の名前の不一致に関する問題を解決するには、次の操作を行います。

  • SSL 証明書が付与され、正しいホストに適用されていることを確認します。

詳細情報

  • Exchange Server 2003 の仮想サーバーで証明書を使用する方法については、Microsoft サポート技術情報の文書番号 823024「Exchange Server 2003 の仮想サーバーで証明書を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823024) を参照してください。

  • SSL を使用する方法およびサーバー証明書を取得してインストールする方法については、Exchange Server 2003 のクライアント アクセス ガイド (http://go.microsoft.com/fwlink/?LinkId=47568) で、Exchange Server 2003 にクライアント アクセスを構成する方法についての章を参照してください (このサイトは英語の場合があります)。

  • SSL の使用方法および Exchange Server 2007 用にサーバー証明書を入手してインストールする方法の詳細については、Outlook Anywhere 用に SSL を構成する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80875) を参照してください (このサイトは英語の場合があります)。


接続許可書のアクティブ化スケジュールが [しない] に設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各接続許可書オブジェクトの activationStyle 属性の値を判断します。activationStyle 属性は、接続許可書のスケジュール設定を表します。このスケジュールが [しない] に設定されていると、警告が表示されます。

この接続許可書が必要なくなったと判断した場合は、削除する必要があります。この接続許可書が必要な場合は、適切なスケジュールで実行されるように構成する必要があります。

この警告を修正するには

  1. [スタート] ボタンをクリックし、[プログラム] をクリックします。次に、[管理ツール] をクリックし、[Active Directory コネクタ] をクリックします。

  2. 左側のペインで、変更する接続許可書をホストしている Active Directory コネクタ (ADC) サーバーをクリックします。

  3. 右側のペインで、変更する接続許可書を右クリックし、[プロパティ] をクリックします。

  4. [スケジュール] タブをクリックします。

  5. スケジュールを [常に] または [選択時間] に設定します。[選択時間] を選択する場合は、グリッド内の適切な場所をクリックして、接続許可書がその時刻に実行されるようにします。

双方向の受信者用接続許可書の構成の詳細については、Microsoft サポート技術情報の文書番号 296260「[XGEN] Exchange Server 5.5 ユーザーに対する双方向のユーザー接続許可書を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=296260) を参照してください。


接続許可書が切り離されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各接続許可書の msExchHomeSyncService に有効な値が設定されているかどうかを判断します。接続許可書のこの属性に有効な値が設定されていないことが検出されると、警告が表示されます。

msExchHomeSyncService 属性には、その接続許可書が配置されている Active Directory コネクタ (ADC) サーバーが含まれます。

ADC を最初に削除せずに ADC サーバーを削除した場合、または ADC サーバーの接続許可書を削除した場合、この警告が表示されることがあります。ADC サーバーを削除すると、接続許可書と ADC サーバーとの接続が切断されます。その結果、これらの接続許可書の対象となっているオブジェクトがレプリケートされなくなります。別の ADC サーバーで ADC マネージャ スナップインを使用した場合、その ADC サーバーに配置されている、削除済みの接続許可書は表示されません。ただし、これらの接続許可書は依然として Active Directory に存在します。

この問題を解決するには、古い接続許可書と新しい ADC サーバーを再び関連付けます。この方法の 1 つは、新しい ADC サーバーで新しい接続許可書を作成し、古い接続許可書から msExchHomeSyncService 属性をコピーして新しい接続許可書に貼り付けることです。

接続許可書と ADC サーバーを再び関連付けるには

  1. ADC マネージャ スナップインを開始します。

  2. 新しい接続許可書を作成します。

  3. Active Directory サービス インターフェイス (ADSI) Edit を起動します。

  4. [構成]、[サービス]、[Microsoft Exchange] の順に展開し、[Active Directory Connections] をクリックします。

  5. 右側のペインで、作成した接続許可書のプロパティを開きます。

  6. [Select a property to vie] ボックスの一覧で [msExchHomeSyncService] をクリックします。

  7. [Value(s)] ボックスから属性全体をコピーし、[OK] をクリックします。

  8. 再び関連付ける接続許可書のプロパティを開きます。

  9. [Select a property to view] ボックスの一覧で [msExchHomeSyncService] 属性をクリックします。

  10. コピーした値を [属性の編集] ボックスに貼り付けます。

  11. [設定] をクリックし、[適用] をクリックします。次に、[OK] をクリックします。

切り離された接続許可書の詳細については、Microsoft サポート技術情報の文書番号 319486「[XADM] Active Directory コネクタを削除した後に接続許可書が非表示になる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319486) を参照してください。


既定の表示名が変更されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、displaySpecifier クラスがあるオブジェクトの createDialog 属性の値を判断します。displaySpecifier クラスがあるオブジェクトは、Active Directory のオブジェクトと共に使用されるショートカット メニューとプロパティ ページを記述します。Exchange Server アナライザによって、createDialog 属性が設定されていると判断されると、既定以外の構成であることを示すメッセージが表示されます。

Active Directory で新しいユーザーや連絡先オブジェクトを作成する場合、[フル ネーム] ボックスは常に、"姓名" の形式で作成されます。次にこのボックスによって、グローバル アドレス一覧の作成時に [表示名] ボックスが設定されます。したがって、"姓名" 形式のグローバル アドレス一覧になります。

必要な場合には、Active Directory サービス インターフェース (ADSI) Edit などの Active Directory エディタを使用して、[表示名] ボックスの構築方法を変更することができます。ADSI Edit で変更を行うと、このボックスの構築方法が変更されるだけでなく [表示名] ボックスも変更されます。したがって、ユーザーが Active Directory ユーザーとコンピュータ内で表示されるときには、選択した形式で表示されます。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

これらの変更は、悪影響を与える可能性があることに注意して行ってください。この変更によって発生する可能性がある結果の詳細については、Micrososft サポート技術情報の文書番号 276266「LDAP-restricted 文字でのユーザーのグループ変更は、動作しない可能性があります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=276266) を参照してください。

ユーザーおよび連絡先オブジェクトの既定の表示形式を変更するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. 最上位のノードを右クリックし、[Connect to] をクリックします。

  3. [Naming Context] を "Configuration Container" に変更し、[OK] をクリックしてバインドおよび認証を行います。

  4. [Configuration Container] ノードを展開し、[Configuration] ノードを展開します。

  5. [cn=DisplaySpecifiers] ノードを展開し、[CN=409] をダブルクリックします。注 : 409 は英語 (米国) のロケール ID です。複数言語環境では、他のコードに変更する必要が生じる場合があります。

  6. 右側のペインで、[CN=user-Display] のプロパティを開きます。

  7. オプションの属性の [createDialog] までスクロールします。

  8. 属性を "%<sn>.%<givenName>" に設定し、[Set] をクリックします。注 : 形式を設定できるトークンは、%<sn>、%<givenName>、および %<initials> のみです。

  9. [OK] をクリックしてダイアログ ボックスを閉じます。

  10. Acitve Directory 内に新しいユーザーを作成し、[フル ネーム] と [表示名] が意図したとおりに構築されることを確認します。注 : 複数ドメイン環境では、レプリケーションが完了して Active Directory ユーザーとコンピュータ ツールに変更が反映されるまで待つことが必要な場合があります。

上の手順の結果、表示名は "姓名" の形式で表示されます。上に示したのは、ユーザー オブジェクトに対する手順です。連絡先オブジェクトについては、手順 6. を "contact-Display" で読み替えてください。

ADSI スクリプトを使用してこのタスクを実行する方法の詳細については、Microsoft サポート技術情報の文書番号 277717「ADSI スクリプトでの Active Directory ユーザー表示名の変更」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277717) を参照してください。

コード ページは、国際電気通信連合 (ITU) および 国際標準化機構 (ISO) によって定義されています。詳細については、以下の ITU および ISO の Web ページにアクセスしてください。

  • http://www.itu.int

  • http://www.iso.ch/iso/en/ISOOnline.openerpage

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

ローカライズした Exchange クライアントのサポートの詳細については、Microsoft サポート技術情報の文書番号 150977「XADM: ローカライズ Exchange クライアントをサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=150977) を参照してください。


メールボックス ストアの削除済みアイテムの保存期間が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストアの garbageCollPeriod 属性値を判断します。いずれかのメールボックス ストアで garbageCollPeriod 属性が 0 に設定されていることが検出されると、ベスト プラクティスのメッセージが表示されます。

ガーベジ コレクションは、メールボックス ストア データベース内でディスク領域を開放する、Exchange の内部的な整理処理です。既定では、削除済みアイテムは Exchange によって完全に削除されるまで、メールボックス ストア データベースに一定の日数の間格納されます。削除済みアイテムの保存期間の長さは、メールボックス ストアの既定値を使用するか、完全に削除するまで削除済みアイテムを保管する日数を選択することによって設定できます。

削除済みアイテムを保存する日数は、0 ～ 24,855 の間で選択できます。この設定は、7 日に構成することをお勧めします。削除済みアイテムの保存期間が 0 に設定されている場合、削除済みアイテムは直ちにサーバーから完全に削除されます。ディスクの空き領域に問題がなければ、削除済みアイテムの保存機能を無効にしないようにすることをお勧めします。以下の手順に従って、完全に削除するまで削除済みアイテムを保存する日数を指定します。

Exchange システム マネージャで削除済みアイテムの保存期間を構成するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] または [サーバー] を展開し、[<サーバー名>] をクリックします。次に、[<メールボックス ストア名>] をクリックします。

  3. メールボックス ストアを右クリックし、[プロパティ] をクリックします。

  4. [制限] タブで、以下の手順を実行して削除済みアイテムの保存期間を設定します。

    • 削除済みアイテムの保存期間を設定するには、[削除済みアイテムの保存期間 (日)] をクリックし、値を入力します。

    • バックアップするまでアイテムを保存するには、[ストアのバックアップが完了するまで、メールボックスとアイテムを削除しない] チェック ボックスをオンにします。

Active Directory ユーザーとコンピュータで、削除済みアイテムの保存期間を構成するには

  1. Active Directory ユーザーとコンピュータ スナップインを起動します。

  2. コンソール ツリーで、ドメインを展開します。

  3. [Users] をダブルクリックするか、変更する受信者情報が格納されているノードをダブルクリックします。

  4. 詳細ペインで、変更する受信者をダブルクリックします。

  5. [Exchange 全般] タブで、[格納域の制限] をクリックします。

  6. [格納域の制限] ダイアログ ボックスで、[削除済みアイテムの保存期間] の [メールボックス ストアの既定値を使用する] チェック ボックスをオフにし、[削除済みアイテムの保存期間 (日)] ボックスに値を入力します。

    バックアップが行われるまで削除済みアイテムの完全な削除が行われないようにするには、[ストアのバックアップが完了するまで、アイテムを削除しない] チェック ボックスをオンにします。

メールボックスの記憶域の制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 319583「[HOWTO] Exchange 2000 のメールボックスで格納域の制限を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319583) を参照してください。


パブリック フォルダ ストアの削除済みアイテムの保存期間が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストアの garbageCollPeriod 属性の値を判断します。パブリック フォルダ ストアの garbageCollPeriod 属性が 0 に設定されていることが検出されると、ベスト プラクティスのメッセージが表示されます。

ガーベジ コレクションは、パブリック フォルダ ストア データベース内の領域を解放する Exchange 内部の整理プロセスです。既定では、削除済みアイテムは、Exchange によって完全に削除される前にパブリック フォルダ ストア データベースに一定の日数格納されます。パブリック フォルダ ストアの既定値を使用するか、または削除済みアイテムが完全に削除される前に保持される日数を指定して、削除済みアイテムの保存期間の長さを設定することができます。

削除済みアイテムを保存する日数は、0 ～ 24,855 の間で選択できます。この設定は、7 日に構成することをお勧めします。削除済みアイテムの保存期間が 0 に設定されている場合、削除済みアイテムは直ちにサーバーから完全に削除されます。ディスクの空き領域に問題がなければ、削除済みアイテムの保存機能を無効にしないようにすることをお勧めします。

Exchange システム マネージャで削除済みアイテムの保存期間を構成するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] または [サーバー] を展開し、[<サーバー名>] をクリックします。次に、[パブリック フォルダ ストア] をクリックします。

  3. パブリック フォルダ ストアを右クリックし、[プロパティ] をクリックします。

  4. [制限] タブで、以下の手順を実行して削除済みアイテムの保存期間を設定します。

    • 削除済みアイテムの保存期間を設定するには、[削除済みアイテムの保存期間 (日)] をクリックし、値を入力します。

    • バックアップが完了するまでアイテムを保存するには、[ストアのバックアップが完了するまで、アイテムを削除しない] をクリックします。

パブリック フォルダの記憶域の制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 319439「[HOWTO] Exchange 2000 のパブリック フォルダで格納域の制限を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319439) を参照してください。


削除済みメールボックスの保存機能が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストアの msExchMailboxRetentionPeriod 属性値を判断します。いずれかのメールボックス ストアの msExchMailboxRetentionPeriod 属性値が 0 に設定されていることが検出されると、ベスト プラクティスのメッセージが表示されます。

msExchMailboxRetentionPeriod 属性は、削除済みメールボックスが実際に削除されるまでの保存日数を示しています。削除済みメールボックスの保存日数を指定する場合は、0 ～ 24,855 の数値を選択できます。削除済みメールボックスの保存期間の既定値は 30 日です。メールボックスの保存期間が 0 に設定されていると、削除されたメールボックスは直ちにサーバーから完全に削除されます。ディスク領域が問題になっている場合以外は、削除済みメールボックスの保存期間機能を無効にしないようにすることをお勧めします。

削除済みメールボックスの保存期間を構成するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、使用している管理グループを展開します。次に、[サーバー] を展開し、使用しているストレージ グループを展開します。Exchange システム マネージャに [管理グループ] ノードが表示されない場合は、[サーバー] を展開し、使用しているストレージ グループを展開します。

  3. 構成するメールボックス ストアを右クリックし、[プロパティ] を選択します。

  4. [制限] タブで、[削除済みメールボックスの保存期間 (日)] ボックスに、メールボックスの保存期間を入力します。

  5. [OK] をクリックし、変更を保存します。
注 :
メールボックスの保存期間がまだ経過しておらず、関連付けられたユーザー オブジェクトが削除されていなければ、メールボックスを回復できる可能性があります。

削除済みメールボックスの回復の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 274343「[XADM] Exchange 2000 で削除されたメールボックスを回復する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=274343)

  • 文書番号 813337「[HOWTO] Exchange 2000 Server の単一のメールボックスを回復または復元する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=813337)

  • 文書番号 823176「[HOWTO] Exchange Server 2003 で単一のメールボックスを回復または復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823176)


ドメインに不明な Exchange の署名が存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、指定されたドメイン内で最後に実行された DomainPrep のバージョンを判断します。DomainPrep のバージョン番号は、該当するドメイン用の Exchange の署名として機能します。Exchange Server アナライザは、指定されたドメインの Exchange System Objects オブジェクトの objectVersion 属性を調べます。この値の有効な整数には、次の 2 つがあります。

  • Exchange 2000 Server の場合、objectVersion 値は 4406 です。

  • Exchange Server 2003 の場合、objectVersion 値は 6936 です。

  • Exchange Server 2007 の場合、objectVersion 値は 10628 です。

objectVersion 属性が上記の値のいずれでもないことが検出されると、エラーが表示されます。

指定されたドメインにプレリリース版の Exchange 2000 Server または Exchange Server 2003 をインストールしたが、製品版の DomainPrep を実行していない場合、この値は正しくない可能性があります。

注 :
Microsoft Exchange 2000 Server と Exchange Server 2003 では、setup /forestprep と setup /domainprep を実行することで Active Directory 準備手順を実行しました。Exchange 2007 には /forestprep オプションと /domainprep オプションはありません。Exchange Server 2007 では、Active Directory とドメインの準備に必要なアクセス許可を持つアカウントを使用して、setup /PrepareDomain プロセス、またはセットアップ ウィザードを実行してください。

Exchange 2000 Server または Exchange Server 2003 について、このエラーを修正するには、最終バージョンの Exchange 2000 Server DomainPrep、Exchange Server 2003 DomainPrep、または Exchange Server 2007 の最終バージョンの PrepareDomain プロセスまたはセットアップ ウィザードを実行します。DomainPrep、PrepareDomain、またはセットアップ ウィザードを実行するために使用するアカウントは、ローカル ドメインの Domain Admins セキュリティ グループのメンバであり、かつローカル コンピュータの管理者である必要があります。

  • ルート ドメイン。

  • Exchange 2000 Server または Exchange Server 2003 コンピュータを含むすべてのドメイン。

  • Exchange 2000 Server または Exchange Server 2003 メールボックスが有効なオブジェクト (たとえば、ユーザーとグループ) を含むすべてのドメイン。ドメインに Exchange サーバーがインストールされていない場合も含みます。

  • Exchange ディレクトリ アクセス コンポーネントが使用する可能性があるグローバル カタログ サーバーを含むすべてのドメイン。

  • Exchange 組織の管理に使用される Exchange 2000 Server または Exchange Server 2003 ユーザーとグループを含むすべてのドメイン。

Exchange 2000 Server または Exchange Server 2003 の DomainPrep を実行するには

  1. CD-ROM ドライブに Exchange の CD-ROM を挿入します。DomainPrep は、ドメイン内の任意のコンピュータで実行できます。

  2. コマンド プロンプトで、「<ドライブ>:\setup\i386\setup /DomainPrep」と入力します。<ドライブ> は CD-ROM ドライブを示します。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] が [DomainPrep] に設定されていることを確認します。設定されていない場合は、ドロップダウン メニューの矢印をクリックし、[DomainPrep] をクリックします。[次へ] をクリックします。

  7. [Microsoft Exchange ウィザードを終了します。] ページで、[完了] をクリックします。

Exchange Server 2007 の PrepareDomain を実行するには

  1. Active Directory とドメインを準備する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=78453) の詳細な手順の指示に従ってください。

Exchange Server 2003 DomainPrep の実行の詳細については、Exchange Server 展開ガイド のページ (http://go.microsoft.com/fwlink/?LinkId=47569) (英語) を参照してください。

Exchange 2000 Server DomainPrep の実行の詳細については、Microsoft Exchange 2000 のインストールとセットアップについての説明 (http://go.microsoft.com/fwlink/?LinkId=5906) (英語) を参照してください。

Exchange Server 2007 の Active Directory とドメインの準備に関する詳細については、Active Directory とドメインを準備する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください。


Exchange Server がゲストとしてインストールされた Virtual Server 2005 がドメイン コントローラで実行されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が Virtual Machine に設定されているかどうかを判断します。

さらに、次のレジストリ値の有無も確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

さらに Exchange Server アナライザは、Microsoft Virtual Server 2005 を実行している物理的なコンピュータで、Win32_ComputerSystem の Domain Role キーを読み取ります。キーの値が 3 より大きい場合、この物理的なコンピュータはドメイン コントローラです。

Model キーに文字列 Virtual Machine が含まれていること、上記のレジストリ ブランチが存在していること、および Domain Role の値が 3 より大きいことが検出されると、エラーが表示されます。

Model キーの値が Virtual Machine の場合、Virtual Server 2005 または Microsoft Virtual PC 2004 いずれかの仮想コンピュータ上で、Exchange Server コンピュータがゲストとして実行されていることを示します。上記のレジストリ ブランチを作成するのは Virtual Server 2005 だけなので、このブランチが存在すれば、Exchange Server コンピュータは Virtual Server 2005 のゲスト仮想コンピュータとして実行されていることになります。

Microsoft では、バージョンに関係なく、仮想マシンまたはエミュレータでの Exchange Server の実行をサポートしていません。この点は、Virtual Server 2005、Virtual PC 2004、またはその他のどのサードパーティー製仮想マシン プログラム上で実行される Exchange Server にも当てはまります。Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Calatog」(http://go.microsoft.com/fwlink/?linkid=17219) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています (このサイトは英語の場合があります)。

さらに、ドメイン コントローラで Virtual Server のゲストとして Exchange を実行することは、サービス全体で適切な冗長性を確保できないという点で、ベスト プラクティスであるとは言えません。

このエラーを修正するには

  1. メールボックスを、Virtual Server 2005 の下で実行されている Exchange サーバーから、仮想化されていない Exchange Server コンピュータに移動します。

  2. 必要に応じて、パブリック フォルダを再格納し、仮想 Exchange サーバーが保持していた役割を転送します。

  3. Exchange を仮想コンピュータからアンインストールして、その Exchange の使用を停止し Exchange インフラストラクチャおよび Active Directory® ディレクトリ サービスから削除します。

メールボックスの移動の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

仮想環境で実行される Exchange Server コンピュータに対するサポートの詳細については、Microsoft サポート技術情報の文書 320220「Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual Server 2005 の詳細については、http://go.microsoft.com/fwlink/?linkid=34938 を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual PC 2004 の詳細については、http://go.microsoft.com/fwlink/?linkid=34663 を参照してください。


ドメイン名前付け FSMO 役割からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、構成名前付けコンテキスト内にあるドメイン名前付け操作マスタの fSMORoleOwner 属性の値を判断します。たとえば、contoso.com というドメインの場合、ドメイン名前付け操作マスタの fSMORoleOwner は CN=Partitions,CN=Configuration,DC=contoso,DC=com という属性になります。次に、Exchange Server アナライザは、現在その役割を保持しているドメイン コントローラの TCP ポート 389 に対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。このドメイン コントローラに接続できないと、エラーが表示されます。

ドメイン名前付けマスタは、フォレスト階層に存在するすべてのディレクトリ パーティションの追加と削除をドメインに関係なく管理する、フォレスト全体にわたる操作マスタの役割です。ドメイン名前付けマスタの役割を持つドメイン コントローラは、以下の操作を実行できる唯一のドメイン コントローラです。

  • フォレストへの新規ドメインの追加

  • フォレストからの既存ドメインの削除

  • 外部ディレクトリへの相互参照オブジェクトの追加または削除

ドメイン名前付けマスタは、フォレスト全体で 1 つだけ置くことができます。

このエラーを修正するには

  1. エラーに示されたディレクトリ サーバーがオンラインになっており、組織内の Exchange サーバーからアクセスできることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、ドメイン名前付けマスタの役割を別のドメイン コントローラに割り当てる必要があります。

ドメイン名前付け操作マスタの役割をあるドメイン コントローラから別のドメイン コントローラに転送することに関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Server™ 2003 については、Microsoft サポート技術情報の文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows® 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


ドメイン名前付け FSMO 役割が見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、構成名前付けコンテキストのドメイン名前付け操作マスタについて fSMORoleOwner 属性を判断します。たとえば、contoso.com というドメインでは、ドメイン名前付けマスタの fSMORoleOwner は CN=Partitions, CN=Configuration, DC=contoso, DC=com の属性です。次に、Exchange Server アナライザはドメイン コントローラとのライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。fSMORoleOwner 属性で指定されているドメイン コントローラが応答しないことが検出されると、エラーが表示されます。

ドメイン名前付けマスタ ドメイン コントローラは、フォレストへのドメインの追加または削除を制御します。ドメイン名前付けマスタは、フォレスト全体で 1 つだけ置くことができます。

Active Directory フォレストには、必ずドメイン名前付けマスタを定義する必要があります。Exchange セットアップと Exchange Service Pack セットアップは、セットアップの最中にドメイン名前付けマスタ ドメイン コントローラがオンラインになっていないと失敗します。ドメイン名前付けマスタとして指定されているドメイン コントローラがオフラインの場合は、オンラインに戻す必要があります。

このエラーを修正するには

  1. 指定されている Active Directory サーバーが物理的に存在していることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、ドメイン名前付けマスタの役割を別のドメイン コントローラに割り当てます。

ドメイン名前付けマスタの役割を別のドメイン コントローラに割り当てる方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Serve™ 2003 については、文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows® 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


ディレクトリ サーバー DNS の名前解決エラー
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、各 Active Directory® ディレクトリ サービス サーバーに対して構成されている DNS サーバーに対し、ドメイン ネーム システム (DNS) クエリの実行を試みます。この接続は、名前解決要求を実行し、その結果を分析するカスタム オブジェクト プロセッサを使用して行われます。クエリ結果の一部に IP アドレスが含まれていなかった場合、エラーが表示されます。

このエラーは、DNS 内にディレクトリ サーバーが見つからなかったことを示します。Exchange Server および Active Directory の両方にとって、正しく構成されて正常な状態にある DNS が正しく機能する必要があります。DNS の登録および解決に関する問題によって、メッセージを送信、受信、および配信する機能が広範囲にわたって影響を受ける場合があります。

Active Directory と Exchange Server を正常に機能させるには、DNS を正しく構成する必要があります。Active Directory のための DNS 構成の詳細な扱い方については、Microsoft サポート技術情報の文書番号 237675「Active Directory 用に DNS をセットアップする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=237675) を参照してください。

このエラーを修正するには

  1. DNS が正しく動作していること、および Active Directory の DNS エントリが正常に登録されることを保証するため、以下の構成項目を確認します。

    • DNS の IP の構成

    • 動的なゾーンの更新

    • DNS フォワーダ

  2. ルート ゾーンのエントリが存在するかどうかを確認します。DNS 管理コンソールで前方参照ゾーンを表示します。そこには、ドメインのエントリが存在します。その他のゾーン エントリも存在することがあります。ドット (".") ゾーンは存在しません。ドット (".") ゾーンが存在する場合は削除します。ドット (".") ゾーンは DNS サーバーをルート サーバーと認識します。一般に、外部 (インターネット) アクセスを必要とする Active Directory ドメインはルート DNS サーバーとしては構成しません。ドット (".") を削除した後、ディレクトリ サーバーの Ipconfig /registerdns を使用して、ディレクトリ サーバーの IP アドレスを手動で再登録します。Netlogon サービスも再開する必要がある場合があります。

  3. ディレクトリ サーバーの netdiag /fix を使用して、Active Directory DNS エントリを手動で再登録します。

Active Directory DNS の併用に関する詳細については、Microsoft サポート技術情報の文書番号 323418「[HOWTO] Active Directory が有効な Windows Server 2003 で、既存の DNS インフラストラクチャに DNS を統合する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418) を参照してください。

DNS と Active Directory の問題のトラブルシューティングに関する詳細については、Microsoft サポート技術情報の文書番号 260371「Windows 2000 における一般的な Active Directory セットアップの問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260371) を参照してください。


dSHeuristics が Hosted Exchange 用に正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、その展開が Hosted Exchange 環境かどうかを判断します。Exchange 展開が Hosted Exchange で実行されている場合、Exchange Server アナライザは Active Directory に対してクエリを実行し、Directory Service コンテナの dSHeuristics 属性が Hosted Exchange の展開用に正しく設定されているかどうかを判断します。

dSHeuristics の値が 1 ではないことが検出されると、警告が表示されます。Hosted Exchange 環境では、dSHeuristics 属性は 1 に設定されている必要があります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
この警告を修正するには

  1. ADSI Edit などの Active Directory エディタを使用して、Active Directory のディレクトリ サービス オブジェクトを見つけます。

    dSHeuristics 属性は次の場所にあります。

    CN=Configuration, CN=Services, CN=Windows NT, CN=Directory Service

  2. dSHeuristics の値に「1」と入力します。

Hosted Exchange 環境の詳細については、以下の資料を参照してください。

  • "「Information for Hosters」(http://go.microsoft.com/fwlink/?LinkId=46307) (このサイトは英語の場合があります)

  • 『Exchange Server 2000 Resource Kit』の「Hosted Service Environments」(http://go.microsoft.com/fwlink/?LinkId=46326) (このサイトは英語の場合があります)


重複した Microsoft Exchange System Objects コンテナが Active Directory に存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン名前付けコンテキスト内に Microsoft Exchange System Objects コンテナが存在するかどうかを判断します。

重複した Microsoft Exchange System Objects コンテナが Active Directory に存在することが検出されると、"Active Directory domain appears to be prepared for Exchange but there are multiple 'Microsoft Exchange System Objects' containers in existence. Clean up may be necessary." というエラーが表示されます。

この問題は、次の状況にある Exchange Server 環境で発生することがあります。

  • Active Directory から Exchange Server 5.5 への双方向の Active Directory コネクタ (ADC) サーバー接続許可書が削除され、置き換えられた。

  • Exchange Server 5.5 から Active Directory への新しい一方向の ADC サーバー接続許可書が準備されている。

  • Exchange Server 5.5 が動作している混在モードの環境が Exchange Server 2003 環境に移行された。

  • 外部のメール サーバーから Exchange Server 2003 への移行が実行された。

Exchange Server アナライザによってこのエラーが表示された場合は、不適切な重複した Microsoft Exchange System Objects コンテナまたは組織単位 (OU) を削除する必要があります。重複した Microsoft Exchange System Objects コンテナが存在する場合は、再び DomainPrep を実行しても問題を解決できません。不適切な重複した Microsoft Exchange System Objects コンテナを識別して削除する必要があります。

重複した Microsoft Exchange System Object コンテナを削除するには

  1. 管理者の資格情報を使用してドメイン コントローラにログオンします。

  2. [スタート] ボタンをクリックし、[プログラム] をクリックします。次に、[管理ツール] をクリックし、[Active Directory ユーザーとコンピュータ] をクリックします。

  3. [Active Directory ユーザーとコンピュータ] 管理コンソール ペインで、ツールバーのメニューから [表示] をクリックし、[Advanced Features] を選択します。

  4. [Active Directory ユーザーとコンピュータ] 管理コンソール ペインで、不適切な重複した Microsoft Exchange System Objects コンテナまたは組織単位 (OU) に移動します。

  5. 不適切な重複した Microsoft Exchange System Objects コンテナまたは OU に有効な Active Directory オブジェクトが含まれないことを確認します。

  6. 不適切な重複した Microsoft Exchange System Objects コンテナまたは OU を右クリックし、[削除] をクリックします。

  7. Active Directory ダイアログ ボックスで [はい] をクリックして削除を確認します。

    注 :
    変更をすぐにレプリケートするには、ドメイン コントローラ間のレプリケーションを手動で開始する必要があります。

Exchange Server でのこの問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 316280「XADM:「ADC」グローバル名属性の説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=316280)

  • 文書番号 252228「[XADM] ADC が重複したオブジェクトを作成するように見える」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=252228)

  • 文書番号 253800「[XADM] ADC が Active Directory 内に重複したオブジェクトを作成する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=253800)

  • 文書番号 274480「XADM: Exchange Server 5.5 から Windows 2000 Active Directory へオブジェクトをレプリケートすると、作成された重複オブジェクト」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=274480)

  • 文書番号 288578「[XADM] ADC が Exchange Server 5.5 と Active Directory にアカウントを重複して作成する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=288578)


Active Directory へのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスのドメイン コントローラが使用できなくなっている可能性があると判断しました。Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

このエラーを修正するには

  • Exhcange Server アナライザで Active Directory ドメイン コントローラを指定した場合は、ドメイン コントローラを指定せずに接続を試みます。

  • ドメイン コントローラを指定していなかった場合は、利用可能な実行中のドメイン コントローラを指定します。


Exchange Server 管理グループへのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービス フォレストに Exchange 組織がインストールされ、Active Directory の Exchange 組織の構成情報に正常にアクセスできると判断しました。しかし、Exchange サーバーを含む管理グループが見つかりませんでした。

このエラーを修正するには

  • Active Directory に適切なアクセス権があり、Exchange 管理グループのコンテナにアクセスできることを確認します。

  • Exchange Server アナライザを実行しているワークステーションが別の Active Directory フォレストに属している場合、またはドメイン アカウントでログオンしていない場合は、Exchange サーバーをホストしているフォレストの Active Directory ドメイン コントローラに接続する必要があります。


Exchange の Configuration コンテナに対するアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Exchange の Configuration コンテナがアクセスできない状態になっていると判断しました。Exchange の組織、管理グループ、およびサーバーの構成情報は、Active Directory® ディレクトリ サービスの構成名前付けコンテキストに格納されます。Exchange のいずれかの構成情報にアクセスするには、Active Directory Configuration コンテナの Microsoft Exchange ブランチを読み取れる必要があります。

このエラーを修正するには

  • Active Directory Configuration コンテナの読み取りに必要なアクセス許可があることを確認します。

  • Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。


Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利を拒否されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Everyone セキュリティ グループのセキュリティ識別子 (SID) が Exchange 組織オブジェクトの ntSecurityDescriptor に列挙されているかどうかを判断します。Everyone グループ用の SID が組織オブジェクトの ntSecurityDescriptor に存在することが検出されると、警告が表示されます。この警告は、Everyone グループが最上位のパブリック フォルダを作成する権利を拒否されていないことを示しています。

Exchange 2000 Server では、最上位のパブリック フォルダを作成する権利は既定で許可されます。ただし、Exchange Server 2003 バージョンの ForestPrep または Exchange Server 2007 の PrepareAD が実行されていると、Everyone セキュリティ グループは最上位のパブリック フォルダへのアクセスを拒否されます。この拒否機能は、セキュリティ対策として実装されています。Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利を許可すると、組織がサービス拒否攻撃を受けやすい状態に置かれたままになる可能性があります。

そのため、ベスト プラクティスとして、Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利を拒否することをお勧めします。Exchange Server 2003 または Exchange Server 2007 を保有している場合は、Exchange Server 2003 バージョンの ForestPrep と Exchange Server 2007 バージョンの PrepareAD をそれぞれ実行する必要があります。Exchange Server 2003 バージョンの ForestPrep は、Exchange 2000 Server 環境で実行できます。ただし、その後 Exchange 2000 Server をインストールすると、アクセス許可がリセットされ、Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利が許可されます。

Exchange Server 2003 または Exchange Server 2007 を保有していない場合は、このアクセス許可を手動で設定できます。その後 Exchange 2000 をインストールすると、このアクセス許可がリセットされることに注意してください。そのため、Exchange 2000 Server をインストールするたびに、このアクセス許可を手動で構成する必要があります。アクセス許可を設定するには、Exchange システム マネージャに [セキュリティ] タブが表示されるようにしておく必要があります。それには、Exchange Server コンピュータ上で、レジストリに ShowSecurityPage エントリを追加します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
レジストリに ShowSecurityPage エントリを追加するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin

  3. [編集] をクリックし、[新規] をクリックします。次に、[DWORD 値] をクリックします。

  4. 新しい値の名前として「ShowSecurityaPage」と入力し、Enter キーを押します。

  5. [ShowSecurityPage] をダブルクリックし、[値のデータ] フィールドに「1」と入力します。次に、[OK] をクリックします。

Exchange 2000 Server 環境で Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利を手動で拒否するには

  1. Exchange システム マネージャを起動します。

  2. [組織名] を右クリックし、[プロパティ] をクリックします。

  3. [組織名のプロパティ] ページで、[セキュリティ] タブをクリックします。

  4. [セキュリティ] タブの [グループ名またはユーザー名] で [Everyone] を選択します。[Everyone のアクセス許可] ボックスで、[Create top-level public folder] アクセス許可まで下にスクロールし、[許可] 列のチェック ボックスをオフにします。次に、[適用] をクリックします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986 の、Microsoft Windows レジストリの説明についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 ForestPrep の実行の詳細については、Exchange Server デプロイメント ガイド の Web ページ (http://go.microsoft.com/fwlink/?LinkId=47569) (英語) を参照してください。

Exchange Server 2007 の PrepareAD の実行方法の詳細については、Active Directory とドメインを準備する方法についての説明 (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください。

Exchange 2000 Server で Everyone セキュリティ グループが最上位のパブリック フォルダを作成する権利を拒否する方法の詳細については、Microsoft サポート技術情報の文書番号 328808 の、最上位パブリック フォルダを 2000 Exchange で作成するユーザー権限を削除する方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328808) を参照してください。


Exchange ドメイン コンテナに問題がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン名前付けコンテキスト内に Microsoft Exchange System Objects コンテナが存在するかどうかを判断します。Microsoft Exchange System Objects コンテナが存在しないか、存在していても無効であるか形式が正しくないことが検出されると、エラーが表示されます。

Microsoft Exchange System Objects コンテナは、Exchange DomainPrep が実行されたときに各ドメインに作成されます。

このエラーが検出されたドメインでは、DomainPrep を実行する必要があります。Microsoft Exchange System Objects コンテナが見つからないドメインの名前が、Exchange Server アナライザの出力に一覧表示されます。

DomainPrep を実行するために使用するアカウントは、ローカル ドメインの Domain Admins セキュリティ グループのメンバであり、かつローカル コンピュータの管理者であることが必要です。

一般的に、DomainPrep は以下のドメインで実行する必要があります。

  • ルート ドメイン。

  • Exchange 2000 Server コンピュータまたは Exchange Server 2003 コンピュータが含まれる予定のすべてのドメイン。

  • Exchange 2000 Server または Exchange Server 2003 のメールボックスが有効なオブジェクト (ユーザーやグループなど) が含まれる予定のすべてのドメイン。Exchange サーバーがインストールされないドメインも含まれます。

  • Exchange ディレクトリ アクセス コンポーネントが使用する可能性があるグローバル カタログ サーバーを含むすべてのドメイン。

  • Exchange 組織の管理に使用される Exchange 2000 Server または Exchange Server 2003 ユーザーとグループを含むすべてのドメイン。

DomainPrep を実行するには

  1. CD-ROM ドライブに Exchange CD-ROM を挿入します。DomainPrep は、ドメイン内の任意のコンピュータで実行できます。

  2. コマンド プロンプトで「<ドライブ>:\setup\i386\setup /DomainPrep」と入力します。<ドライブ> は CD-ROM ドライブを示します。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] が [DomainPrep] に設定されていることを確認します。設定されていない場合は、ドロップダウン メニューの矢印をクリックし、[DomainPrep] をクリックします。[次へ] をクリックします。

  7. [Microsoft Exchange ウィザードを終了します。] ページで、[完了] をクリックします。

Exchange Server 2003 DomainPrep の実行の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange 2000 Server DomainPrep の実行の詳細については、技術文書「Microsoft Exchange 2000 Installation and Setup」(http://go.microsoft.com/fwlink/?LinkId=5906) を参照してください (このサイトは英語の場合があります)。


Exchange ドメイン サーバー グループが見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Microsoft Exchange System Objects オブジェクトの ntSecurityDescriptor 属性の値を判断して、ドメイン内で実行されている DomainPrep のバージョンを判断します。

有効な整数は以下の 2 つです。

  • Exchange 2000 Server の場合、ntSecurityDescriptor 値は 4406 です。

  • Exchange Server 2003 の場合、ntSecurityDescriptor 値は 6936 です。

上記のいずれかのバージョンの DomainPrep が使用されていることが検出されると、Exchange Server アナライザは Active Directory に対してクエリを実行し、Microsoft Exchange System Objects オブジェクトの objectGuid 属性の値を判断して、Exchange Domain Servers グループが存在するかどうかを判断します。このグループが存在しないことが検出されると、エラーが表示されます。

このエラーを解決するには、製品版の Exchange 2000 Server DomainPrep または Exchange Server 2003 DomainPrep を実行します。DomainPrep を実行するときに使用するアカウントは、ローカル ドメイン内の Domain Admins セキュリティ グループのメンバであり、かつローカル コンピュータの管理者である必要があります。

DomainPrep は、以下のドメイン内で実行する必要があります。

  • ルート ドメイン。

  • Exchange 2000 Server または Exchange Server 2003 コンピュータを含むすべてのドメイン。

  • Exchange 2000 Server または Exchange Server 2003 メールボックスが有効なオブジェクト (たとえば、ユーザーとグループ) を含むすべてのドメイン。ドメインに Exchange サーバーがインストールされていない場合も含みます。

  • Exchange ディレクトリ アクセス コンポーネントが使用する可能性があるグローバル カタログ サーバーを含むすべてのドメイン。

  • Exchange 組織の管理に使用される Exchange 2000 Server または Exchange Server 2003 ユーザーとグループを含むすべてのドメイン。

DomainPrep を実行するには

  1. CD-ROM ドライブに Exchange CD-ROM を挿入します。DomainPrep は、ドメイン内の任意のコンピュータで実行できます。

  2. コマンド プロンプトで、「<ドライブ>:\setup\i386\setup /DomainPrep」と入力します。この <ドライブ> は使用する CD ドライブです。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] が [DomainPrep] に設定されていることを確認します。設定されていない場合は、ドロップダウン メニューの矢印をクリックし、[DomainPrep] をクリックします。[次へ] をクリックします。

  7. [Microsoft Exchange ウィザードを終了します。] ページで、[完了] をクリックします。

Exchange Server 2003 DomainPrep の実行の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange 2000 Server DomainPrep の実行の詳細については、『Microsoft Exchange 2000 Server Installation and Setup』(http://go.microsoft.com/fwlink/?LinkId=5906) を参照してください (このサイトは英語の場合があります)。


Exchange Enterprise Servers グループが見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Microsoft Exchange System Objects オブジェクトの ntSecurityDescriptor 属性の値を判断して、ドメイン内で実行されている DomainPrep のバージョンを判断します。

以下の 2 つの整数が有効です。

  • Exchange 2000 Server の場合、ntSecurityDescriptor 値は 4406 です。

  • Exchange Server 2003 の場合、ntSecurityDescriptor 値は 6936 です。

上記のいずれかのバージョンの DomainPrep が使用されていることが検出されると、Exchange Server アナライザは Active Directory に対してクエリを実行し、Microsoft Exchange System Objects オブジェクトの objectGuid 属性の値を判断して、Exchange Enterprise Servers グループが存在するかどうかを判断します。このグループが存在しないことが検出されると、エラーが表示されます。

このエラーを解決するには、製品版の Exchange 2000 Server DomainPrep または Exchange Server 2003 DomainPrep を実行します。DomainPrep を実行するために使用するアカウントは、ローカル ドメインの Domain Admins セキュリティ グループのメンバであり、かつローカル コンピュータの管理者であることが必要です。

DomainPrep は、以下のドメイン内で実行する必要があります。

  • ルート ドメイン。

  • Exchange 2000 Server または Exchange Server 2003 コンピュータを含むすべてのドメイン。

  • Exchange 2000 Server または Exchange Server 2003 メールボックスが有効なオブジェクト (たとえば、ユーザーとグループ) を含むすべてのドメイン。ドメインに Exchange サーバーがインストールされていない場合も含みます。

  • Exchange ディレクトリ アクセス コンポーネントが使用する可能性があるグローバル カタログ サーバーを含むすべてのドメイン。

  • Exchange 組織の管理に使用される Exchange 2000 Server または Exchange Server 2003 ユーザーとグループを含むすべてのドメイン。

DomainPrep を実行するには

  1. CD-ROM ドライブに Exchange CD-ROM を挿入します。DomainPrep は、ドメイン内の任意のコンピュータで実行できます。

  2. コマンド プロンプトで「<ドライブ>:\setup\i386\setup /DomainPrep」と入力します。<ドライブ> は CD-ROM ドライブを示します。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] が [DomainPrep] に設定されていることを確認します。設定されていない場合は、ドロップダウン メニューの矢印をクリックし、[DomainPrep] をクリックします。[次へ] をクリックします。

  7. [Microsoft Exchange ウィザードを終了します。] ページで、[完了] をクリックします。

Exchange Server 2003 DomainPrep の実行の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange 2000 Server DomainPrep の実行の詳細については、『Microsoft Exchange 2000 Installation and Setup』(http://go.microsoft.com/fwlink/?LinkId=5906) を参照してください (このサイトは英語の場合があります)。


Lost and Found コンテナに Exchange オブジェクトがある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Configuration コンテナの下の LostAndFoundConfig コンテナ内にオブジェクトが存在するかどうかを判断します。LostAndFoundConfig コンテナにオブジェクトが存在することが検出されると、そのオブジェクトと、オブジェクトの派生元になったオブジェクト クラスと共にエラーが表示されます。

LostAndFoundConfig コンテナは、Active Directory によって整合性をとることができないオブジェクトを保持します。LostAndFoundConfig コンテナ内にあるオブジェクトは、すべて削除したことを確認してください。これは、Exchange がそれらのオブジェクトを使おうとするためです。たとえば、Exchange が Active Directory に対しオブジェクト クラス (Servers) 別のクエリを実行すると、LostAndFoundConfig コンテナ内に存在する可能性があるかどうかとは無関係に、すべてのオブジェクトが有効なオブジェクトとして返されます。この結果、Exchange は実在するオブジェクトの代わりに、the LostAndFoundConfig コンテナにあるサーバーに接続しようとする可能性があります。この動作によって、Exchange の予期しない動作が発生し、場合によってはサーバーのエラーが発生する可能性があります。これらのオブジェクトが存在するために、同じクラスのオブジェクトの作成が妨げられることもあります。

この問題を解決するには、Active Directory サービス インターフェイス (ADSI) Edit を使用して、LostAndFoundConfig コンテナ内のエントリを Active Directory から削除する必要があります。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
注 :
ADSI Edit は、Windows 2000 Server および Windows Server 2003 のサポート ツールに含まれるツールです。

このエラーを修正するには

  1. [ADSI Edit] MMC スナップインを開きます。

  2. [操作] メニューの [Connect to] をクリックします。

  3. [Connection Settings] ダイアログ ボックスで、[Name] ボックスに ADSI 接続の名前を入力します。[Connection Point] で [Select a well-known Naming Context] をクリックし、ドロップダウン メニューで [Configuration] を選択します。[OK] をクリックします。

  4. 左側のペインで [Configuration] オブジェクトをダブルクリックし、[LostAndFoundConfig] をダブルクリックします。

  5. 右側のペインで、すべてのオブジェクトとコンテナを削除します。オブジェクトまたはコンテナを右クリックし、[削除] をクリックします。次に、[はい] をクリックします。

  6. ADSI Edit を終了します。


Exchange 組織に受信者ポリシーが存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 組織の受信者ポリシー オブジェクトの Name 属性値を判断します。受信者ポリシー オブジェクトが存在しないか、または受信者ポリシー オブジェクトに受信者ポリシーが含まれていないことが検出されると、エラーが表示されます。

Exchange Server がインストールされると、SMTP (Simple Mail Transfer Protocol) アドレスと X.400 アドレスを Exchange 組織内のすべての受信者に適用する既定の受信者ポリシーが作成されます。既定のポリシーを変更するか、または新しいポリシーを作成することができます。ただし、既定のポリシーを削除することはできません。Exchange 組織内のすべての受信者が、SMTP アドレスと X.400 アドレスの両方を持っている必要があります。Exchange 組織に受信者ポリシーが存在しないと、信頼性の問題が発生します。

受信者ポリシーを作成するには

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. Exchange システム マネージャの左側のペインで、組織を展開し、[受信者] を展開します。次に、[受信者ポリシー] を右クリックし、[新規] をポイントして [受信者ポリシー] をクリックします。

  3. [新しいポリシー] ダイアログ ボックスで、作成するポリシーの種類を [電子メール アドレス] チェック ボックスまたは [メールボックス マネージャの設定] チェック ボックス、あるいはその両方をオンにして選択し、[OK] をクリックします。

  4. [プロパティ] ダイアログ ボックスで、新しい受信者ポリシーの名前を入力し、[変更] をクリックして受信者ポリシーのフィルタを作成します。

    注 :
    フィルタを作成しないと、ポリシーはどの受信者にも適用されません。

  5. 受信者ポリシーをカスタマイズするには、[プロパティ] ダイアログ ボックスの [電子メール アドレス (ポリシー)] タブまたは [メールボックス マネージャの設定 (ポリシー)] タブに切り替えます。これらのタブの設定を使用して受信者ポリシーを構成し、[OK] をクリックしてポリシーを作成します。

  6. Exchange システム マネージャで受信者ポリシーを右クリックし、[今すぐこのポリシーを適用] をクリックします。

受信者と受信者ポリシーの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Recipients and Recipient Policies」を参照してください (このサイトは英語の場合があります)。

受信者ポリシーを作成して構成する方法の詳細については、Microsoft サポート技術情報の文書番号 249299「[HOWTO] Exchange で受信者ポリシーを構成する方法」（http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249299) を参照してください。


Exchange 組織にシステム ポリシーが存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 組織のシステム ポリシー オブジェクトの名前を判断します。システム ポリシー オブジェクトが存在しないか、またはシステム ポリシー オブジェクトにシステム ポリシーが含まれていないことが検出されると、エラーが表示されます。

システム ポリシー オブジェクトを使用すると、複数の Exchange サーバーのパラメータを、メールボックス ストア、パブリック フォルダ ストア、サーバーの設定などの単一の構成オブジェクトを通して構成することによって、システム管理作業を簡略化できます。組織で ForestPrep を実行すると、既定では、以下のシステム ポリシーが作成されます。

  • Hidden DL Membership

  • Mail Enable Recipient

  • Mailbox Enable Recipient

Exchange 組織にこれらの既定のシステム ポリシーが存在しないと、信頼性に関する問題が発生します。既定のシステム ポリシーを再作成するには、ForestPrep を実行する必要があります。

Exchange Server 2003 ForestPrep を実行するには

  1. CD-ROM ドライブに Exchange CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「ドライブ:\setup\i386\setup /ForestPrep」と入力します。ここで、ドライブ は CD-ROM のドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] が [ForestPrep] に設定されていることを確認します。設定されていない場合は、ドロップダウン メニューの矢印をクリックし、[ForestPrep] をクリックします。[次へ] をクリックします。

    重要 :
    [アクション] に [ForestPrep] が表示されていない場合は、手順 2. で ForestPrep コマンドのスペルを間違っている可能性があります。ForestPrep コマンドのスペルを間違っていた場合は、手順 2. に戻り、コマンドを再入力します。

  7. [Microsoft Exchange Server 管理者アカウント] ページで、[アカウント] ボックスに、Exchange をインストールする役割を持つアカウントまたはグループの名前を入力します。

    注 :
    指定したアカウントには、Exchange 管理委任ウィザードを使用して他の Exchange 管理者アカウントを作成するためのアクセス許可も与えられます。Exchange 管理委任ウィザードの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47617) を参照してください (このサイトは英語の場合があります)。

  8. [次へ] をクリックして ForestPrep を起動します。いったん起動したら、ForestPrep プロセスはキャンセルできません。

    注 :
    ネットワーク トポロジや、Microsoft Windows® 2000 Server または Microsoft Windows Server™ 2003 ドメイン コントローラの速度によっては、ForestPrep の完了に長い時間がかかる場合があります。

  9. [Microsoft Exchange ウィザードを終了します。] ページで、[完了] をクリックします。

Exchange でシステム ポリシーが使用されるしくみの詳細については、Microsoft サポート技術情報の文書番号 253838「[XADM] 受信者更新サービスでシステム ポリシーが適用されるしくみ」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=253838) を参照してください。

システム ポリシーの詳細については、『Technical Reference Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47891) の「Exchange System Manager Architecture」を参照してください (このサイトは英語の場合があります)。

Exchange で既定以外のシステム ポリシーを作成する方法の詳細については、Microsoft サポート技術情報の文書番号 256141「[XADM] Exchange 2000 でシステム ポリシーを作成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256141) を参照してください。


グローバル カタログ NSPI ポートが無効になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-01-15

Microsoft® Exchange Server アナライザ ツールは、グローバル カタログ サーバーで次のレジストリ エントリを読み取り、TCP/IP Port レジストリ値が設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port

TCP/IP Port レジストリ キーが作成および設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

グローバル カタログ サーバーが MAPI クライアントの要求の処理に特定のポートを使用する必要がある場合は、TCP/IP Port レジストリ キーが必要です。Exchange 環境にこのような要件がない場合は、このキーを削除することができます。

.

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

グローバル カタログ サーバーで TCP/IP ポートを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

  3. TCP/IP Port キーを右クリックし、[削除] をクリックします。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)

  • 文書番号 298369「[XADM] MAPI クライアントの要求の処理時に特定のポートを使用するようにグローバル カタログ サーバーを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298369)

  • 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=24823) (このサイトは英語の場合があります)


グローバル カタログのポート 3268 からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、このサーバーの isGlobalCatalogReady 属性の値を判断します。この属性値は、True の場合はディレクトリ サーバーが機能しているグローバル カタログ サーバーでもあることを示し、False の場合はディレクトリ サーバーはグローバル カタログ サーバーではないことを示しま。

次に、Exchange Server アナライザは、Exchange サーバーのポート 3268 に接続して、このポートから応答があることを確認します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • サーバーがグローバル カタログ サーバーである。

  • ポート 3268 からの応答がない。

注 :
Exchange Server アナライザを実行しているコンピュータとグローバル カタログ サーバーとの間にファイアウォールが存在する場合、このメッセージが誤って表示されることがあります。

この問題は通常、グローバル カタログ サーバーのチェック ボックスがオンにした後でサーバーを再起動していない場合に発生します。

この問題を修正するには

  • サーバーを再起動します。

ドメイン コントローラの昇格の詳細については、Microsoft サポート技術情報の文書番号 304403「XADM: Exchange Considerations for Promoting a Domain Controller to a Global Catalog Server」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=304403) を参照してください (このサイトは英語の場合があります)。


グループ クラス スキーマのエラー
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchBaseClass クラスが Active Directory スキーマ内のグループ オブジェクトの auxiliaryClass 属性に含まれているかどうかを判断します。

Active Directory には、ディレクトリが正しく機能するために必要な、異なるすべてのオブジェクトの種類を定義する定義済みのクラスがあります。オブジェクトの定義は、それぞれのクラスを入れ子にすることで作成します。クラスを入れ子にすることで、クラス間の親子関係が作成されます。

Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 をインストールすると、msExchBaseClass クラスが Active Directory に追加されます。msExchBaseClass クラスは、CDO for Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 (CDOEX) によって拡張されるすべてのクラスに適用される、基本補助クラスです。CDOEX は、Exchange ストア内のほとんどの種類の情報を管理できる、基本的なコンポーネント オブジェクト モデル (COM) クラスおよびインターフェイスを提供します。

Active Directory スキーマを誤って変更すると、グループ オブジェクトの msExchBaseClass クラスと auxiliaryClass 属性の関係が壊される場合があります。この関係が壊れたことにより、受信者更新サービスでエラーが発生したり、組織内に新しく Exchange Server 200x サーバーをインストールできなくなったりなど、Exchange サーバーが不安定になる場合があります。

Exchange Server アナライザが、Active Directory スキーマ内のグループ オブジェクトの auxiliaryClass 属性に msExchBaseClass クラスが含まれないことを検出した場合は、この関係が壊されていることを示します。msExchBaseClass クラスが、Active Directory スキーマ内のグループ オブジェクトの auxiliaryClass 属性に含まれない場合は、エラーが表示されます。

このエラーを修正するには、Microsoft 製品サポート サービス (http://go.microsoft.com/fwlink/?LinkId=41364) にお問い合わせください。


Hosted Exchange 環境にはネイティブ モードの Exchange 組織が必要
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server 環境が Hosted Exchange 環境として構成されているかどうかを判断します。Exchange Server 環境が Hosted Exchange 環境である場合は、Active Directory に対してクエリを実行し、Exchange 組織が混在モードで実行されているかどうかを判断します。

Exchange 組織が混在モードで実行されている場合、警告が表示されます。Hosted Exchange ソリューションにはネイティブ モードの組織が必要です。

ネイティブ モードに切り替えた後で混在モードに戻すことはできません。

ネイティブ モードに切り替えるには

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、ネイティブ モードに切り替える組織を右クリックし、[プロパティ] をクリックします。

  3. [<組織名> のプロパティ] ダイアログ ボックスで、[処理モードの変更] の [モードの変更] をクリックします。

  4. ネイティブ モードに完全に切り替える場合は、警告ダイアログ ボックスで [はい] をクリックします。[適用] をクリックして、新しい Exchange モードに切り替えます。

Exchange のネイティブ モードを最大限に活用するには、組織内のすべての Exchange サーバーで、Microsoft Exchange Information Store サービスを再開する必要があります。すべての Microsoft Exchange Information Store サービスを同時に再開する必要はありませんが、サーバーで Exchange ネイティブ モードの機能をすべて利用するには、それぞれのサーバーでサービスを再開する必要があります。ネイティブ モードへの変更がローカルの Microsoft Windows® ドメイン コントローラにレプリケートされた後で、サーバーのサービスを再開します。

Microsoft Exchange Information Store サービスを再開するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「services.msc」と入力し、[OK] をクリックします。

  2. [サービス (ローカル)] ペインで、[Microsoft Exchange Information Store] サービスを見つけます。

  3. このサービスを右クリックし、[再開] をクリックします。

Hosted Exchange 環境の詳細については、以下の資料を参照してください。

  • "「Information for Hosters」(http://go.microsoft.com/fwlink/?LinkId=46307) (このサイトは英語の場合があります)

  • 『Exchange 2000 Server Resource Kit』(http://go.microsoft.com/fwlink/?LinkId=46326) の「Chapter 23 - Hosted Service Environments」(このサイトは英語の場合があります)

混在モードからネイティブ モードへの変更の詳細については、Microsoft サポート技術情報の文書番号 327779「[HOWTO] Exchange で混在モードからネイティブ モードに変換する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779) を参照してください。


インフラストラクチャ FSMO サーバー役割からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン名前付けコンテキストのインフラストラクチャ マスタについて fSMORoleOwner 属性の値を判断します。たとえば、contoso.com というドメインでは、インフラストラクチャ マスタの fSMORoleOwner は CN=Infrastructure,DC=contoso,DC=com の属性です。次に、Exchange Server アナライザは、現在その役割を保持しているドメイン コントローラの TCP ポート 389 に対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。このドメイン コントローラに接続できないと、エラーが表示されます。

インフラストラクチャ マスタは、ドメイン内でグループのメンバの名前が変更されるたび、またはメンバが変更されるたびにグループからユーザーへの参照を更新します。そのグループのドメインについてインフラストラクチャ マスタの役割を持つドメイン コントローラは、ドメイン間のグループからユーザーへの参照を更新し、ユーザーの新しい名前を反映します。インフラストラクチャ マスタは定期的にドメイン アカウントをスキャンし、グループのメンバシップを確認します。ユーザー アカウントが新しいドメインに移動されている場合、インフラストラクチャ マスタはユーザー アカウントの新しいドメインを識別し、それに応じてグループを更新します。インフラストラクチャ マスタは、これらの参照をローカルで更新してから、レプリケーションを使用してドメインの他のレプリカをすべて更新します。インフラストラクチャ マスタが使用不可能な場合、これらの更新は遅延されます。各ドメインに、インフラストラクチャ マスタとして動作するドメイン コントローラは常に 1 つだけ置くことができます。

このエラーを修正するには

  1. エラーに示されたディレクトリ サーバーがオンラインになっており、組織内の Exchange サーバーからアクセスできることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、インフラストラクチャ マスタの役割を別のドメイン コントローラに割り当てる必要があります。

インフラストラクチャ マスタの役割をあるドメイン コントローラから別のドメイン コントローラに転送することに関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Server™ 2003 については、文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


Exchange 組織オブジェクトのバージョン属性が正しくない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-02-28

Microsoft Exchange Server アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、Exchange のスキーマ バージョン情報を判断します。具体的には次の Active Directory オブジェクトを調べ、rangeUpper 属性の現在の値を判断します。

CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=<フォレスト ルート ドメインの DN>

rangeUpper の値が 4397 であれば、Exchange 2000 Server がインストールされています。

rangeUpper の値が 6870 であれば、Exchange Server 2003 がインストールされています。

rangeUpper の値が 10637 であれば、Exchange Server 2007 がインストールされています。

Exchange Server アナライザによって rangeUpper の値がこれら以外であることが検出されると、エラーが表示されます。

rangeUpper の値は、ForestPrep プロセスの間に Exchange 2000 Server または Exchange Server 2003 によって入力されます。この値が 4397、6870、または 10637 以外の場合は通常、Exchange のベータ版またはプレリリース版を使用して ForestPrep (Exchange Server 2007 の場合は PrepareDomain) が実行されされたことを示します。

Exchange 2000 Server または Exchange Server 2003 の場合にこの問題を解決するには、環境にインストールされている製品版の Exchange を使用して、ForestPrep プロセスを再度実行します。Exchange Server 2007 の場合は、環境にインストールされている製品版の Exchange を使用して、PrepareSchema を再度実行します。ForestPrep または PrepareSchema は、少なくとも次の権限を持つアカウントでログオンして実行する必要があります。

  • Enterprise Admins グループのメンバ

  • Schema Admins グループのメンバ

  • Domain Admins グループのメンバ

  • ローカル コンピュータの Administrator グループのメンバ (メンバ サーバーのみで実行されている場合)

Exchange 2000 Server または Exchange Server 2003 の場合にこのエラーを修正するには

  1. setup.exe /forestprep を実行します。

  2. ForestPrep プロセスが正常に完了したことを確認します。

Exchange Server 2007 の場合にこのエラーを修正するには

  1. setup.exe /PrepareSchema を実行します。

  2. PrepareSchema プロセスが正常に完了しことを確認します。

Exchange をインストールして PrepareSchema プロセスを実行する方法の詳細については、次の製品ドキュメントを参照してください。

  • Active Directory とドメインを準備する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=78453)

Exchange をインストールして ForestPrep プロセスを実行する方法の詳細については、マイクロソフト サポート技術情報の次の文書を参照してください。

  • 文書番号 312371「[HOW TO]Exchange 2000 Server または Exchange Server 2003 で ForestPrep を使用してフォレストを準備する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=312371)。この文書は、Exchange 2000 Server と Exchange Server 2003 の両方に適用されます。

  • 274737 の、Exchange 2000 Server または Exchange Server 2003 で ForestPrep および DomainPrep が正常に完了したことを確認する方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=274737)

  • 828765 の、Exchange Server 2003 でコンポーネントをインストールするために必要なアクセス許可に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828765)


ネイティブ モードの管理グループに古いアカウント情報が存在している
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 管理グループ オブジェクトの msExchLegacyAccount 属性にデータが含まれているかどうかを判断します。

また、Active Directory に対してクエリを実行し、各管理グループの msExchAdminGroupMode 属性の値も判断します。msExchAdminGroupMode 属性の値が 0 の場合、その管理グループは Exchange ネイティブ モードです。値が 1 の場合は Exchange Server 5.5 のみの環境であり、値が 2 の場合は Exchange 混在モードです。

Exchange Server アナライザによって、msExchLegacyAccount 属性にデータが含まれ、msExchAdminGroupMode 属性の値が 0 であることが検出されると、エラーが表示されます。

Exchange ネイティブ モードに切り替えると、msExchLegacyAccount 属性は削除されます。この属性は、Exchange Server 5.5 が依然として存在する、混在モードの Exchange 組織でのみ使用されます。実際の属性データが Exchange Server 5.5 サービス アカウントで、ネイティブ モードの Exchange 組織に msExchLegacyAccount 属性が存在している場合、アップグレード時と Service Pack のインストール時に誤動作が発生します。実際には、この属性が存在するだけで、データが存在しなくても誤動作が発生します。これは、Exchange セットアップがこの属性を使用して、Exchange 組織が混在モードかネイティブ モードかを検出するためです。この属性が存在すると、Exchange セットアップ プログラムはインストール用に混在モード構成で動作しますが、インストールは実際にはネイティブ モードで行われます。

Active Directory サービス インターフェイス (ADSI) Edit スナップインを使用して Active Directory からデータを手動で削除した場合、msExchLegacyAccount 属性が残っている可能性が高くなります。

LDP (ldp.exe) ツールで属性を手動で編集し、このデータを msExchLegacyAccount から削除する必要があります。LDP ツールまたはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用して、データと属性の両方をディレクトリから完全に削除する必要があります。ADSI Edit スナップインはデータのみを削除して属性はそのまま残すため、この場合には適していません。LDP.exe は Windows® サポート ツール パッケージに含まれています。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる可能性があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchLegacyAccount 属性を削除するには

  1. LDP.exe を起動します。

  2. [Connection] メニューの [Connect] をクリックし、[Connect] ダイアログ ボックスで、Exchange 組織と同じ Active Directory フォレストのドメイン コントローラの名前を入力します。次に、[OK] をクリックします。

  3. [Connection] メニューの [Bind] をクリックし、[Bind] ダイアログ ボックスで、少なくとも管理グループ レベルの Exchange 管理者 (完全) 権限を持つ資格情報を入力し、[OK] をクリックします。

  4. [View] メニューの [Tree] をクリックし、[Tree View] ダイアログ ボックスで、ルート ドメインから接続する場合はボックスを空のままにし、それ以外の場合は「CN=Configuration,DC=ドメイン名, DC=ドメイン サフィックス」と入力します。ここで、ドメイン名 は Active Directory フォレストのルート ドメイン、ドメイン サフィックス は com、net、org などのドメイン サフィックスです。[OK] をクリックします。

  5. 左側のペインにある LDP の階層ビューを、使用している管理グループが開くまで展開します。このためには、次の順序でノードをダブルクリックします (LDP の各ノードに完全な識別名 (DN) が付いていることに注意してください。ここでは簡略化のため、左端の CN のみを表記します)。

    1. DC=ドメイン名

    2. CN=Configuration

    3. CN=Services

    4. CN=Microsoft Exchange

    5. CN=組織名

    6. CN=Administrative Groups

    7. CN=管理グループ名

    LDP の詳細ペイン (右側) で下にスクロールし、使用している管理グループの属性を表示します。msExchLegacyAccount 属性が存在している場合は、削除する必要があります。msExchLegacyAccount 属性が存在している場合、msExchLegacyDomain 属性と msExchEncryptedPassword 属性も存在していると考えられます。これらの属性も削除する必要があります。

  6. LDP の階層ペイン (左側) で、管理グループ名 を右クリックし、[Modify] をクリックします。

  7. [Modify] ダイアログ ボックスで、[Dn] ボックスの一覧に表示されている完全な DN が、変更の必要がある管理グループを正しく識別していることを確認します。次のように表示される必要があります。CN=管理グループ名,CN=Administrative Groups,CN=組織名,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ドメイン名。

  8. [Modify] ダイアログ ボックスの [Operations] の下で、[Delete] を選択し、[Edit entry] の下の [Attribute] ボックスに「msExchLegacyAccount」と入力します。次に、[Enter] をクリックします。これにより、msExchLegacyAccount が [Entry List] に追加されます。[Entry List] に定義された属性は、[Run] をクリックすると削除されます。

  9. msExchLegacyDomain と msExchEncryptedPassword 属性のいずれかが管理グループに存在している場合、手順 8. に従ってそれらを [Entry List] に追加します。

  10. 削除する必要がある属性が [Entry List] に表示されたら、[Run] をクリックします。LDP の詳細ペインに、状態メッセージが表示されます。

  11. [Connection] メニューの [New] をクリックして LDP 詳細ペインをクリアします。

  12. CN=管理グループ名 に移動し、オブジェクトをダブルクリックします。右側のペインの内容を確認し、属性が削除されていることを確認します。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。


Exchange 組織の legacyExchangeDN 属性が正しくない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-02-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange 組織オブジェクトの legacyExchangeDN 属性の形式を判断します。legacyExchangeDN 属性が正しくないこと、または形式が誤っていることが検出されると、エラーが表示されます。

この属性値は /o=組織という形式です。ここで組織は、Exchange 組織の名前です。この値の最初が /o= または /O= 以外の場合、形式が誤っていると見なされます。この問題はできるだけ早く修正する必要があります。

Exchange 2000 Server または Exchange Server 2003 の場合にこのエラーを修正するには

  1. Exchange Server ForestPrep プロセスを実行します。このプロセス実行時に、セットアップ プログラムによって legacyExchangeDN の形式が正しくないと判断されると、この問題が自動的に修正されます。

Exchange Server 2007 の場合にこのエラーを修正するには

  1. Exchange Server PrepareAD プロセスを実行します。このプロセス実行時に、セットアップ プログラムによって legacyExchangeDN の形式が正しくないと判断されると、この問題が自動的に修正されます。

ForestPrep プロセスの詳細については、Microsoft サポート技術情報の記事 312371 の、[HOWTO] Exchange 2000 Server または Exchange Server 2003 で ForestPrep を使用してフォレストを準備する方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=312371) を参照してください。

PrepareAD プロセスの詳細については、Active Directory とドメインを準備する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください。

legacyExchangeDN 属性とその変更方法の詳細については、マイクロソフト サポート技術情報の次の記事を参照してください。

  • 324606 の、Legacydn.exe を使用して Exchange 組織または管理グループ名を修正する方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=324606)

  • 286783 の、[XADM] Exchange 2000 Server で空き時間データを更新時にエラー メッセージが発生することに関するページ ?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=286783)

  • 301585 の、[XADM] Mbconn.exe ユーティリティに関する問題の回避方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=301585)


ネイティブ モードの管理グループ内に古いドメイン情報が存在している
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 管理グループ オブジェクトの msExchLegacyDomain 属性にデータが含まれているかどうかを判断します。

また、Active Directory に対してクエリを実行し、各管理グループの msExchAdminGroupMode 属性の値も判断します。msExchAdminGroupMode 属性の値が 0 の場合は、この管理グループが Exchange のネイティブ モードにあることを示します。この値が 1 の場合は純粋な Exchange Server 5.5 環境にあることを、また、この値が 2 の場合は Exchange の混在モードにあることを示します。

Exchange Server アナライザによって、msExchLegacyDomain 属性にデータが含まれ、msExchAdminGroupMode 属性の値が 0 であることが検出されると、エラーが表示されます。

Exchange をネイティブ モードに切り替えた場合は、msExchLegacyDomain 属性が削除されます。この属性は、Exchange Server 5.5 が依然として存在する、混在モードの Exchange 組織でのみ使用されます。実際の属性データは Exchange Server 5.5 サービス アカウントのドメインであり、ネイティブ モードの Exchange 組織内の msExchLegacyDomain 属性にこのデータが存在すると、アップグレードや Service Pack のインストール中に誤動作が発生する原因になります。実際、データが含まれていなくても、この属性が存在するだけで誤動作の原因になります。それは、Exchange 組織が混在モードまたはネイティブ モードのどちらにあるのかを検出する方法として、Exchange セットアップ プログラムがこの属性を使用しているためです。この属性が存在すると、Exchange セットアップ プログラムはインストール用に混在モード構成で動作しますが、インストールは実際にはネイティブ モードで行われます。

Active Directory サービス インターフェイス (ADSI) Edit スナップインを使用して Active Directory からデータを手動で削除したために、msExchLegacyDomain 属性が引き続き存在している場合があります。

このデータは、LDP (ldp.exe) ツールを使用して属性を手動で編集することによって msExchLegacyDomain から削除する必要があります。LDP ツールまたはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用して、データと属性の両方をディレクトリから完全に削除する必要があります。ADSI Edit スナップインはデータのみを削除して属性はそのまま残すため、この場合には適していません。LDP.exe は Windows® サポート ツール パッケージに含まれています。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchLegacyDomain 属性を削除するには

  1. LDP.exe を起動します。

  2. [Connection] メニューの [Connect] をクリックし、[Connect] ダイアログ ボックスで、Exchange 組織と同じ Active Directory フォレストのドメイン コントローラの名前を入力します。次に、[OK] をクリックします。

  3. [Connection] メニューの [Bind] をクリックし、[Bind] ダイアログ ボックスで、少なくとも管理グループ レベルの Exchange 管理者 (完全) 権限を持つ資格情報を入力し、[OK] をクリックします。

  4. [View] メニューの [Tree] をクリックし、[Tree View] ダイアログ ボックスで、ルート ドメインから接続する場合はボックスを空のままにし、それ以外の場合は「CN=Configuration,DC=ドメイン名, DC=ドメイン サフィックス」と入力します。ここで、ドメイン名 は Active Directory フォレストのルート ドメイン、ドメイン サフィックス は com、net、org などのドメイン サフィックスです。[OK] をクリックします。

  5. LDP の左側のペインで、対象の管理グループが表示されるまで階層の表示を展開します。それには、ノードを以下の順にダブルクリックします (LDP 内の各ノードの後には完全な識別名 (DN) が続きますが、わかりやすくするために、ここでは一番左の CN だけが示されています)。

    • DC=ドメイン名

    • CN=Configuration

    • CN=Services

    • CN=Microsoft Exchange

    • CN=組織名

    • CN=Administrative Groups

    • CN=管理グループ名

    LDP の詳細 (右側) ペインで、下にスクロールして、対象の管理グループの属性を表示します。msExchLegacyDomain 属性が存在する場合は、削除する必要があります。msExchLegacyDomain 属性が存在する場合は、msExchLegacyDomain および msExchEncryptedPassword 属性も存在する可能性があります。これらの属性が存在する場合は、同様に削除する必要があります。

  6. LDP の階層ペイン (左側) で、管理グループ名 を右クリックし、[Modify] をクリックします。

  7. [Modify] ダイアログ ボックスで、[Dn] ボックスの一覧に表示されている完全な DN が、変更の必要がある管理グループを正しく識別していることを確認します。次のように表示される必要があります。CN=管理グループ名,CN=Administrative Groups,CN=組織名,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ドメイン名。

  8. [Modify] ダイアログ ボックスの [Operations] の下で、[Delete] を選択し、[Edit entry] の下の [Attribute] ボックスに「msExchLegacyAccount」と入力します。次に、[Enter] をクリックします。これにより、msExchLegacyAccount が [Entry List] に追加されます。[Entry List] に定義された属性は、[Run] をクリックすると削除されます。

  9. msExchLegacyAccount または msExchEncryptedPassword 属性のどちらかが管理グループに存在する場合は、手順 8. に従って [Entry List] に追加します。

  10. 削除する必要がある属性が [Entry List] に表示されたら、[Run] をクリックします。LDP の詳細ペインに、状態メッセージが表示されます。

  11. [Connection] メニューの [New] をクリックして LDP 詳細ペインをクリアします。

  12. CN=管理グループ名 に移動し、オブジェクトをダブルクリックします。右側のペインの内容を調べ、属性が削除されたことを確認します。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。


管理グループの LegacyExchangeDN が親組織と一致しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-11-30

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、管理グループ コンテナ オブジェクトの legacyExchangeDN 属性の形式を判断します。管理グループの legacyExchangeDN 属性が Exchange 組織の legacyExchangeDN と一致していないことが検出されると、エラーが表示されます。

Exchange は legacyExchangeDN 値を使用して、Active Directory 内の Exchange オブジェクトを識別します。legacyExchangeDN 値は、Exchange 組織内のオブジェクトの場所を示す識別名であり、次のような形式をしています。

/o= 組織 /ou= 管理グループ

サーバーやフォルダ階層などのオブジェクトは、その legacyExchangeDN 値の一部を管理グループから継承します。つまり、管理グループの値に問題があると、その他の多くのオブジェクトに同じ問題が継承される可能性があります。

通常、legacyExchangeDN に関する問題は、管理者がこの値を直接変更しようとした場合に発生します。この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、その他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    legacyExchangeDN 属性は次の場所にあります。

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN= 管理グループ

  2. 次の形式で、新しい文字列値を入力します。

    /o= 組織 /ou= 管理グループ

LDP ツールの使用に関する詳細については、Microsoft サポート技術情報の文書番号 260745 の LDP ユーティリテイを使用した AD オブジェクト属性の変更についての説明(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server ヘルプで、ADSI Edit (Adsiedit.msc) についてのトピック (英語) を参照してください。


管理グループの legacyExchangeDN が無効である
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、管理グループの legacyExchangeDN の値を判断します。このエラーは、legacyExchangeDN 値で指定されている組織または管理グループが、その組織または管理グループの実際の名前と一致しない場合や、その値の一部が完全になくなっている場合に表示されます。

Exchange は legacyExchangeDN 値を使用して、Active Directory 内の Exchange オブジェクトを識別します。legacyExchangeDN 値は、Exchange 組織内のオブジェクトの場所を示す識別名であり、次のような形式をしています。

/o=組織/ou=管理グループ

サーバーやフォルダ階層などのオブジェクトは、その legacyExchangeDN 値の一部を管理グループから継承します。つまり、管理グループの値に問題があると、その他の多くのオブジェクトに同じ問題が継承される可能性があります。

一般に、legacyExchangeDN に関する問題は、管理者がこの値を直接変更しようとした場合に発生します。この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントといったツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。これらの Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    legacyExchangeDN 属性は次の場所にあります。

    CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=Organization, CN=Administrative Groups, CN=管理グループ

  2. 次の形式で、新しい文字列値を入力します。

    /o=組織/ou=管理グループ

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server オンライン ヘルプのトピッ ク「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。


メールが有効なユニバーサル グループ以外のグループが存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、環境内に存在するドメインの数を判断します。フォレストに複数の分離した Active Directory ドメインが存在することが検出されると、次に、各ドメインに対してクエリを実行し、これらのドメイン内に 1 つ以上のメールが有効なユニバーサル グループ以外のグループが存在するかどうかを判断します。

複数ドメイン フォレスト内にメールが有効なユニバーサル グループ以外のグループが存在することが検出されると、警告が表示されます。

複数ドメインのフォレストで、ドメインのローカルまたはグローバル配布グループを使用した場合、以下の理由から電子メール配信の問題が発生することがあります。

  • 配布グループを個別の受信者に展開するために、Exchange はグローバル カタログ サーバーと通信を行います。

  • グローバル カタログ サーバーには、各ドメイン内のすべての種類のグループを含む一覧がありますが、リモート ドメインで作成されるドメイン ローカルおよびグローバル グループのメンバシップ一覧は含まれていません。

  • メッセージがグローバル配布グループに送信され、ホーム以外のドメインで展開される場合、Exchange はメッセージをグループのメンバに正しく配信できません。

  • カテゴライザは配布リストを展開できないため、ユーザーが複数ドメイン フォレスト内のグローバル配布グループまたはメールが有効なセキュリティ グループにメッセージを送信する場合、グローバル配布グループ内のユーザーはメッセージを受信しないことがあります。

  • 追跡ログの最後のエントリは、カテゴライザへの送信です。メッセージの送信者は、配信不能レポート (NDR) を受信しません。

この問題を解決し、電子メールが確実に配信されるようにするには、複数ドメイン環境でユニバーサル配布グループを使用します。ユニバーサル配布グループのメンバシップは、各ドメイン内の各グローバル カタログ サーバーにレプリケートされます。

この問題点、およびユニバーサル配布グループ全般の詳細については、次のトピックを参照してください。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Using Mail-Enabled Groups in Multi-Domain Environments」(このサイトは英語の場合があります)。

  • 『Active Directory』 (http://go.microsoft.com/fwlink/?LinkId=51276) の「Understanding Groups」の「Group scope」(このサイトは英語の場合があります)。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Guidelines for Creating Query-Based Distribution Groups」 (このサイトは英語の場合があります)。

また、以下の Microsoft サポート技術情報の文書も参照してください。

  • 文書番号 271930「[XADM] 配布グループへのメッセージ配信が機能しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=271930)

  • 文書番号 283051「[XADM] メールが有効なグローバル グループに送信された電子メールが消える」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=283051)

  • 文書番号 231273「Windows におけるグループの種類とスコープの用途」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231273)


Mailbox Enable User システム ポリシーを変更する必要がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange システム ポリシー オブジェクトの purportedSearch 属性値を判断します。purportedSearch 属性は、ポリシーが適用されるときに使用される検索引数を示しています。

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Active Directory 内のフォレスト オブジェクトである NTDS Settings の msDS-Behavior-Version 属性値も判断します。この値は、Active Directory フォレストの機能レベルを示しています。以下の表に、msDS-Behavior-Version 属性の有効な値を示します。

値 | フォレストの機能レベル
0 | Microsoft Windows® 2000 Server 混在
1 | Microsoft Windows Server™ 2003 中間
2 | Microsoft Windows Server 2003 ネイティブ

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Windows2003Update コンテナの revision 属性値も判断します。この属性値は、Active Directory の準備ユーティリティ (ADPrep.exe) が実行されているかどうかを示しています。

最後に、Exchange Server アナライザは Win32_OperatingSystem Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、OSProductSuite キーの値を判断します。OSProductSuite キーの値は、コンピュータ上で実行されている Windows のバージョンを示しています。

Exchange Server アナライザによって、以下の条件に当てはまることが検出されると、警告が表示されます。

  • Mailbox Enable User システム ポリシーの purportedSearch 属性の値が (&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*)) ではない。

  • Active Directory フォレストの機能レベルが、Windows Server 2003 中間または Windows Server 2003 ネイティブ モードである。

  • Exchange Server コンピュータで Windows Small Business Server 2003 が実行されていない。

メールボックスの再配置の問題が発生しないようにするために、受信者ポリシーへの変更が必要になります。この更新は、Active Directory サービス インターフェイス (ADSI) Edit (ADSIEdit.msc)、LDP (ldp.exe) ツール、または他の Active Directory エディタ ツールを使用して行うことができます。

Windows Server 2003 がドメイン コントローラとして使用されており、Mailbox Enable User ポリシーが更新されていない場合は、Windows Server 2003 で発生するリンクされた値のレプリケーションによって、受信者更新サービスが新しいユーザーの homeMDB 属性値を上書きするため、その受信者のメールボックスはサーバーの最初のストアに再配置されます。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Windows Server 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=<Exchange 組織名>] の順に展開します。

  3. [CN=System Policies] を選択します。

  4. 右側のペインで、[CN=Mailbox Enable User] を右クリックし、[プロパティ] を選択します。

  5. 下にスクロールして purportedSearch 属性を選択し、[Edit] をクリックします。

  6. 属性をクリアし、次のフィルタを使用して構成します。

    (&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))

    注 :
    手順 6. に示されているフィルタは、読みやすくするために折り返されています。フィルタを入力する際は、スペースや改行を含めないようにしてください。

  7. 再度 [OK] をクリックして変更を保存し、ADSI Edit を終了します。

LDP ツールの使用方法の詳細については、マイクロソフト サポート技術情報の記事 260745 の、[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更することに関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

この問題およびその影響の詳細については、マイクロソフト サポート技術情報の文書番号 903291 の、受信者更新サービスによって新しい Exchange Server 2003 ユーザーの homeMDB 属性の値が上書きされる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=903291) を参照してください。


グローバル カタログで MAPI インターフェイスが無効になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、そのレジストリ キーが存在しているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\Initialize MAPI interface

Initialize MAPI interface キーが存在し、何らかの数値で構成されていることが検出されると、エラーが表示されます。

Initialize MAPI interface レジストリ キーが存在している場合、Microsoft Office Outlook® クライアントはこのサーバー上のアドレス帳に接続できません。この問題を修正するには、Initialize MAPI interface レジストリ キーを削除する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Initialize MAPI interface

  3. [Initialize MAPI interface] キーを右クリックし、[削除] を選択します。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Initialize MAPI interface レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 275127「[XADM] ドメイン コントローラ又はグローバル カタログ上で 5.5 が動作する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=275127) を参照してください。


MaxActiveQueries が変更されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、一度に処理できるライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリの最大数を判断します。この値は、現在の LDAP 管理ポリシーを調査することによって取得されます。具体的には、Exchange Server アナライザは MaxActiveQueries の存在を確認します。MaxActiveQueries が存在しており、20 以外の任意の値で構成されていると判断されると、既定以外の構成であることを示すメッセージが表示されます。

LDAP の管理制限によって、Active Directory の運用上の機能とパフォーマンスのバランスがとられます。これらの制限によって、特定の操作がサーバーのパフォーマンスに悪影響を与えないようにします。既定値を超えて MaxActiveQueries の設定を増やすと、Active Directory インフラストラクチャに悪影響を与える可能性があります。

LDAPAdminLimits 属性の MaxActiveQueries 値は、既定のクエリ ポリシーに関して、同時 LDAP クエリの最大数を制御します。既定では、アクティブなクエリ数は 20 に制限されています。この制限に達すると、Active Directory から LDAP_ADMIN_LIMIT_EXCEEDED が返され、以降の LDAP クエリは処理されません。

Ntdsutil.exe を起動するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。

  2. [名前] ボックスに「ntdsutil」と入力し、Enter キーを押します。ヘルプを表示するにはいつでも、コマンド プロンプトで「?」と入力します。

ポリシー設定を表示するには

  1. Ntdsutil.exe のコマンド プロンプトで、「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで、「connections」と入力し、Enter キーを押します。

  3. サーバー接続のコマンド プロンプトで、「connect to server サーバーの DNS 名」と入力し、Enter キーを押します。現在作業を行っているサーバーに接続します。

  4. サーバー接続のコマンド プロンプトで、「q」と入力して Enter キーを押すと、前のメニューに戻ります。

  5. LDAP ポリシーのコマンド プロンプトで、「Show Values」と入力し、Enter キーを押します。

    ポリシーがあれば、表示されます。
注 :
この手順では、既定のドメイン ポリシーの設定のみが表示されます。独自にポリシー設定を適用した場合、そのポリシーは表示されません。

ポリシー設定を変更するには

  1. Ntdsutil.exe のコマンド プロンプトで、「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで、「Set MaxActiveQueries to 20」と入力し、Enter キーを押します。

    Show Values コマンドを使用すると変更内容を確認できます。

  3. 変更を保存するには、Commit Changes を使用します。

  4. 作業が終了したら、「q」と入力して Enter キーを押します。

  5. Ntdsutil.exe を終了するには、コマンド プロンプトで、「q」と入力して Enter キーを押します。

LDAP ポリシーの構成の詳細については、Microsoft サポート技術情報の文書番号 315071「表示する方法と Active Directory の Ntdsutil.exe を使って、設定された LDAP ポリシー」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071) を参照してください。


MaxPageSize バラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービス内の Query-Policies コンテナにある Default Query Policy オブジェクトの属性をチェックして、ドメイン コントローラのライトウェイト ディレクトリ アクセス プロトコル (LDAP) 構成を確認します。LDAPAdminLimits 属性の MaxPageSize 値が既定の 1000 から変更されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

LDAP の管理制限によって、Active Directory の運用上の機能とパフォーマンスのバランスがとられます。これらの制限によって、特定の操作がサーバーのパフォーマンスに悪影響を与えることが避けられると同時に、サービス拒否攻撃に対するサーバーの抵抗力も向上します。この設定を既定値以上に増やすと、Active Directory インフラストラクチャに悪影響を与える場合があります。

LDAP ポリシーは、queryPolicy クラスのオブジェクトを使用して実装されます。Query Policy オブジェクトは、構成名前付けコンテキスト内にある Directory Service コンテナの子である、Query-Policies コンテナの中に作成できます。

LDAPAdminLimits 属性の MaxPageSize 値は、LDAP クエリに対して返すことのできるレコード数を制御します。既定値は 1000 レコードです。返されたアイテム数が 1000 を超えていると、Active Directory はこの最大値を参照して、何も返さないようにします。

この制限は、いくつかの種類の Active Directory オブジェクトのサポート可能な個数を制御します。たとえば、各組織には最大 1000 のサーバー、最大 1000 の管理グループ、および最大 1000 のアドレス一覧を、各管理グループには最大 1000 のルーティング グループを、さらに各ルーティング グループには最大 1000 のコンテナを収容することができます。

Microsoft 製品サポート サービスからの指示により別の値を使用している場合以外は、この値を 1,000 に戻す必要があります。

Ntdsutil.exe を起動するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。

  2. [名前] ボックスに「ntdsutil」と入力し、Enter キーを押します。ヘルプを表示するにはいつでも、コマンド プロンプトで「?」と入力します。

ポリシー設定を表示するには

  1. Ntdsutil.exe のコマンド プロンプトで「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで「connections」と入力し、Enter キーを押します。

  3. サーバー接続のコマンド プロンプトで「connect to server サーバーの DNS 名」と入力し、Enter キーを押します。現在操作しているサーバーに接続する必要があります。

  4. サーバー接続のコマンド プロンプトで「q」と入力し、Enter キーを押して前のメニューに戻ります。

  5. LDAP ポリシーのコマンド プロンプトで「Show Values」と入力し、Enter キーを押します。

    ポリシーがあれば、表示されます。

    注 :
    この手順では、既定のドメイン ポリシーの設定のみが表示されます。独自のポリシー設定が適用されている場合、その設定は表示されません。

ポリシー設定を変更するには

  1. Ntdsutil.exe のコマンド プロンプトで「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで「Set MaxPageSize to 1000」と入力し、Enter キーを押します。

    Show Values コマンドを使用すると変更内容を確認できます。

  3. 変更内容を保存するには、Commit Changes を使用します。

  4. 完了したら、「q」と入力し、Enter キーを押します。

  5. Ntdsutil.exe を終了するには、コマンド プロンプトで「q」と入力し、Enter キーを押します。

LDAP ポリシーの構成の詳細については、Microsoft サポート技術情報の文書番号 315071「表示する方法と Active Directory の Ntdsutil.exe を使って、設定された LDAP ポリシー」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071) を参照してください。


MaxPageSize の設定値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Query-Policies コンテナにある既定のクエリ ポリシー オブジェクトの、LDAPAdminLimits 属性の MaxPageSize 値の設定を判断します。MaxPageSize の値が 2,500 より大きいことが検出されると、エラーが表示されます。

ライトウェイト ディレクトリ アクセス プロトコル (LDAP) の管理制限によって、Active Directory の運用上の機能とパフォーマンスのバランスがとられます。これらの制限によって、特定の操作がサーバーのパフォーマンスに悪影響を与えないようにします。この制限によって、サービス拒否攻撃に対するサーバーの抵抗力も向上します。この設定を既定値以上に増やすと、Active Directory インフラストラクチャに悪影響を与える場合があります。

LDAP ポリシーは、queryPolicy クラスのオブジェクトを使用して実装されます。Query Policy オブジェクトは、構成名前付けコンテキスト内にある Directory Service コンテナの子である、Query-Policies コンテナの中に作成できます。

LDAPAdminLimits 属性の MaxPageSize 値は、LDAP クエリに対して返すことのできるレコード数を制御します。既定値は 1,000 レコードです。返されたアイテム数が 1,000 を超えていると、Active Directory はこの最大値を参照して、何も返さないようにします。

この制限は、いくつかの種類の Active Directory オブジェクトのサポート可能な個数を制御します。たとえば、各組織は最大 1,000 のサーバー、最大 1,000 の管理グループ、および最大 1,000 のアドレス一覧を設定することができます。各管理グループには最大 1,000 のルーティング グループを、また各ルーティング グループには最大 1,000 のコネクタを設定できます。

Microsoft 製品サポート サービスからの指示により別の値を使用している場合以外は、この値を 1,000 に戻す必要があります。

Ntdsutil.exe を起動するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。

  2. [名前] ボックスに「ntdsutil」と入力し、Enter キーを押します。ヘルプを表示するにはいつでも、コマンド プロンプトで「?」と入力します。
ポリシー設定を表示するには

  1. Ntdsutil.exe のコマンド プロンプトで、「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで、「connections」と入力し、Enter キーを押します。

  3. サーバー接続のコマンド プロンプトで、「connect to server<サーバーの DNS 名>」と入力し、Enter キーを押します。現在操作しているサーバーに接続します。

  4. サーバー接続のコマンド プロンプトで、「q」と入力して Enter キーを押すと、前のメニューに戻ります。

  5. LDAP ポリシーのコマンド プロンプトで、「Show Values」と入力し、Enter キーを押します。

    ポリシーがあれば、表示されます。

    注 :
    この手順では、既定のドメイン ポリシーの設定のみが表示されます。独自にポリシー設定を適用した場合、そのポリシーは表示されません。
ポリシー設定を変更するには

  1. Ntdsutil.exe のコマンド プロンプトで、「LDAP policies」と入力し、Enter キーを押します。

  2. LDAP ポリシーのコマンド プロンプトで「Set MaxPageSize to 1000」と入力し、Enter キーを押します。

    Show Values コマンドを使用すると変更内容を確認できます。

  3. 変更を保存するには、Commit Changes を使用します。

  4. 作業が終了したら、「q」と入力して Enter キーを押します。

  5. Ntdsutil.exe を終了するには、コマンド プロンプトで、「q」と入力して Enter キーを押します。

LDAP ポリシーの構成の詳細については、Microsoft サポート技術情報の文書番号 315071「表示する方法と Active Directory の Ntdsutil.exe を使って、設定された LDAP ポリシー」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=315071) を参照してください。


800 を超えるアドレス一覧が存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory のすべてのアドレス一覧グループにあるアドレス一覧の数が 800 を超えているかどうかを判断します。Exchange Server 組織に 800 を超えるアドレス一覧が存在していることが検出されると、警告が表示されます。

受信者更新サービスの操作中に大きな待ち時間が発生しないように、すべてのアドレス一覧グループに含まれるアドレス一覧の数は 800 未満にすることをお勧めします。Exchange Server 組織に含まれるアドレス一覧が 800 を超えていると、メールが有効なオブジェクトに受信者更新サービスによってスタンプが適用されるときに大きな待ち時間が発生します。

あるいは、受信者更新サービスを無効にして、受信者更新サービスによって実行されるタスクをスクリプトで処理することもできます。

受信者更新サービスの無効化の詳細については、Microsoft サポート技術情報の文書番号 296479「[XADM] 受信者更新サービスを無効にするための要件」(http://go.microsoft.com/fwlink/?Linkid=3052&kbid=296479) を参照してください。

アドレス一覧と受信者更新サービスの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Recipients and Recipient Policies in Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。


800 を超えるグローバル アドレス一覧が存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory のすべてのグローバル アドレス一覧グループにあるアドレス一覧の数が 800 を超えているかどうかを判断します。Exchange Server 組織に 800 を超えるグローバル アドレス一覧が存在することが検出されると、警告が表示されます。

受信者更新サービスの操作中に大きな待ち時間が発生しないように、すべてのグローバル アドレス一覧グループに含まれるアドレス一覧の数は 800 未満にすることをお勧めします。Exchange Server 組織に含まれるグローバル アドレス一覧が 800 を超えていると、メールが有効なオブジェクトに受信者更新サービスによってスタンプが適用されるときに大きな待ち時間が発生します。

あるいは、受信者更新サービスを無効にして、受信者更新サービスによって実行されるタスクをスクリプトで処理することもできます。

受信者更新サービスの無効化の詳細については、Microsoft サポート技術情報の文書番号 296479「[XADM] 受信者更新サービスを無効にするための要件」(http://go.microsoft.com/fwlink/?Linkid=3052&kbid=296479) を参照してください。

アドレス一覧と受信者更新サービスの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Recipients and Recipient Policies in Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。


msExchHomeMDB 属性にインデックスが付けられている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory で Routing Group Back-Link 属性にインデックス付けが構成されているかどうかを判断します。具体的には、Active Directory に対してクエリを実行し、msExchHomeMDB 属性について現在のインデックス付けの値を判断します。msExchHomeMDB は、Active Directory にあるメールボックスが有効なオブジェクトの属性です。既定では、この属性にインデックスは付けられていません。この属性がインデックス用に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchHomeMDB 属性にインデックス付けを行うことによる影響は最小のものです。インデックスをメモリに保持するため、グローバル カタログ サーバーによって使用されるメモリの量がわずかに増加します。

組織が次の条件のいずれかに当てはまる場合、この属性をインデックス付けすることで利点が得られます。

  • メールが有効なオブジェクトが多数存在している。メールが有効なオブジェクトが 100,000 以上存在する非常に大規模な環境では、この属性をインデックス付けすることで、Exchange システム マネージャ、および Active Directory ユーザーとコンピュータで実行可能な Exchange 固有のタスクのパフォーマンスを向上させることができます。

  • Exchange メールボックス マージ プログラム (ExMerge) を頻繁に使用する中規模から大規模の環境では、msExchHomeMDB 属性のインデックス付けが必要な場合があることが判明しています。msExchHomeMDB 属性にインデックスを付けると、ExMerge の速度とパフォーマンスが向上することがわかっています。

これらの条件のどれにも当てはまらない場合は、既定値である、インデックス付けを行わない設定に戻すことをお勧めします。

このエラーを修正するには

  • Exchange Server アナライザによって生成されたメッセージは情報提供のみを目的としており、操作は必要ありません。


msExchRoutingGroupMembersBL 属性にインデックスが付けられている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Routing Group Back-Link 属性が Active Directory でのインデックス処理用に構成されているかどうかを判断します。具体的には、次の Active Directory オブジェクトを調べ、msExchRoutingGroupMembersBL 属性の現在のインデックス値を判断します。

CN=Configuration,DC=ドメイン名,DC=ドメイン サフィックス, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Administrative Groups, CN=管理グループ名, CN=Routing Groups, CN=ルーティング グループ名

既定では、この属性はインデックス処理されていません。この属性がインデックス用に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

多数のルーティング グループが含まれている Exchange の分散展開または支社展開では、この属性をインデックス処理しない設定のままにしておくと、パフォーマンスが低下する場合があります。たとえば、Exchange 組織に数百のルーティング グループが存在すると、1 つ以上のグローバル カタログ サーバー上で 15 分ごとに操作が増加することに気付く場合があります。この操作の増加は、Exchange 内の DSAccess コンポーネントがルーティング グループ構成を再度読み取るために発生します。極端な場合は、グローバル カタログがこの操作でいっぱいになることがあります。

グローバル カタログへのこうした負荷を最小限に抑えるには、Routing Group Back-Link 属性をインデックス処理します。それにより、DSAccess がルーティング グループ情報を読み取るためにかかる時間が短縮されると共に、この操作によるグローバル カタログへの負荷が軽減されます。

このエラーを修正するには

  • Exchange Server アナライザによって生成されたメッセージは情報提供のみを目的としており、操作は必要ありません。

Exchange をチューニングして最適なパフォーマンスを得る方法の詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47576) を参照してください (このサイトは英語の場合があります)。


複数のパブリック フォルダ階層が見つかった
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPFTreeType 属性値が 1 であるパブリック フォルダ階層の数を判断します。msExchPFTreeType 属性の値が 1 の場合は、そのパブリック フォルダ階層が MAPI クライアント用に指定されているパブリック フォルダ階層であることを示します。Exchange 組織内の複数のパブリック フォルダ階層で msExchPFTreeType 属性の値が 1 に設定されていることが検出されると、エラーが表示されます。

このエラーは、その Exchange 組織内で、MAPI クライアント用のパブリック フォルダ階層が複数見つかったことを示しています。MAPI クライアント用のパブリック フォルダ階層が複数存在すると、問題が発生する可能性があります。

この問題を解決するには、Active Directory の編集ツールを使用して、MAPI パブリック フォルダ階層を除くすべてのパブリック フォルダ階層の msExchPFTreeType 属性の値を 0 に設定します。必要に応じて、その MAPI パブリック フォルダ階層を MAPI クライアントの既定のパブリック フォルダ ストアとして参照するように、Exchange サーバー上のメールボックス ストアを再構成します。

Active Directory 編集ツールを次に示します。

  • Active Directory サービス インターフェイス (ADSI) Edit (AdsiEdit.msc)

  • LDP (ldp.exe) ツール

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. Active Directory の編集ツールを使用して、Active Directory のパブリック フォルダ オブジェクトを見つけます。パブリック フォルダ オブジェクトは次の場所にあります。 CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Folder Hierarchies

  2. MAPI パブリック フォルダ階層を除くすべてのパブリック フォルダ階層オブジェクトについて、新しい値として「0」と入力し、msExchPFTreeType 属性を変更します。

  3. Active Directoyr エディタを終了します。

  4. Exchange システム マネージャを起動します。

  5. 各メールボックス ストアのプロパティにアクセスするには、[管理グループ] をクリックし、目的の管理グループを展開します。次に、[サーバー] を展開し、操作するサーバーを展開して、目的のストレージ グループを展開します。次に、プロパティを変更するメールボックス ストアを右クリックし、[プロパティ] をクリックします。

  6. [全般] タブで、[既定のパブリック ストア] の [参照] をクリックします。

  7. MAPI パブリック フォルダ階層を選択し、[OK] を 2 回クリックして変更を保存します。

  8. 各メールボックス ストアに対して、手順 5. ～ 7. を繰り返します。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

MAPI およびアプリケーション用のパブリック フォルダ階層の詳細については、以下の文書を参照してください。

  • Microsoft サポート技術情報の文書番号 258509「[XADM] Exchange 2000 のパブリック フォルダ ツリーの種類」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258509)

  • Exchange Team Blog のエントリ「How mail-enabled Public Folders work」(http://go.microsoft.com/fwlink/?LinkId=41913) (このサイトは英語の場合があります)


'NeverPing' パラメータで推奨メッセージが表示される
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ドメインに対して確立されている信頼の数を判断します。各ドメインで少なくとも 1 つのドメイン コントローラに NeverPing 値が設定されている場合、このツールはベスト プラクティスを推奨するメッセージを表示します。

Exchange Server アナライザは、Exchange Server 2003 環境内の各ドメインが、以下の条件に当てはまる場合に警告を表示します。

  • ドメインが、50 を超える確立済みの信頼を持っている。

  • ドメイン内のドメイン コントローラの NeverPing レジストリ サブキーの値が Null (0) に設定されている。

この警告は、LSASS.exe の処理またはドメインに対するユーザー認証の処理に遅延が発生する可能性があることを示します。ローカル セキュリティ機関サブシステム サービス (LSASS) は、Windows ベースのコンピュータまたはサーバーに対するユーザー ログオンを検証する、Microsoft Windows オペレーティング システムの処理です。

この問題を解決するには、次の手順に従って、ドメイン コントローラの NeverPing レジストリ サブキーの値を 1 に設定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Exchange 2003 環境内のドメイン コントローラの NeverPing パラメータを設定するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「regedit」と入力し、[OK] をクリックします。

  2. 次のレジストリ サブキーを見つけます。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. このサブキーを右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックし、「NeverPing」と入力して Enter キーを押します。

  4. [NeverPing] を右クリックし、[変更] をクリックします。次に、[値のデータ] ボックスに 1 と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この問題と、ドメイン コントローラの NeverPing パラメータ値を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 825107「Lsass.exe プロセスは、Windows 2000 Server ベースのドメイン コントローラで外部の多くの信頼を持っていること応答を停止することがあります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=825107) を参照してください。

注 :
この文書は Microsoft Windows 2000 Server について説明していますが、これは Windows Server™ 2003 にも適用されます。この文書で説明している更新プログラムは、Windows Server 2003 には必要ありません。


新しいバージョンの Active Directory コネクタが提供されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各接続許可書オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Active Directory コネクタ (ADC) のバージョンを表します。

また、Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory コネクタ (ADC) ファイルである Adc.exe の Version キーの値を判断します。Version WMI キーは、このファイルのビルド番号を示しています。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • 接続許可書オブジェクトの versionNumber 属性が 16973842 に設定されている。

  • 接続許可書オブジェクトの versionNumber 属性が 16973843 に設定され、Adc.exe の Version キーが 7250.0 より小さい。

値が 16973842 の場合は、コンピュータで実行されている ADC のバージョンが Exchange Server 2003 CD からインストールされた元の製品版であることを示しています。Adc.exe の Version キーの値が 7250.0 より小さい場合は、コンピュータで Exchange Server 2003 Service Pack 1 (SP1) バージョンの ADC が実行されていることを示しています。

新しいバージョンの ADC は、Exchange Server 2003 の Service Pack 2 と共に提供されています。ベスト プラクティスとしては、最新バージョンの ADC を使用することをお勧めします。

この警告を修正するには

  1. 「Service Pack 2 for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=54751) に移動して、最新バージョンの ADC をダウンロードします。

  2. 既存の ADC をアンインストールし、更新されたバージョンの ADC をインストールします。

ADC 接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 303180「[XADM] 管理グループが混在する場合の Active Directory コネクタ接続許可書の要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 文書番号 317721「[XADM] ADC 接続許可書を一方向の接続許可書から双方向の接続許可書に変更すると Exchange Server 5.5 メールボックス所有者権限が削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


接続許可書用に指定された Exchange サーバーが組織内に存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各接続許可書オブジェクトの msExchServer2NetworkAddress 属性の値を判断します。msExchServer2NetworkAddress 属性は、この接続許可書の実行にかかわるサーバーのネットワーク アドレスを表します。Exchange Server アナライザは、Active Directory 内の管理グループを列挙して、このサーバー名が管理グループの接続許可書メンバの一覧にあるかどうかを確認します。このサーバー名が管理グループの一覧にない場合は、エラーが表示されます。

このエラーは、接続許可書が切り離されていることを示しています。この状態は、Exchange Server コンピュータが使用を停止されている場合に発生することがあります。Exchange Server コンピュータが組織から削除されている場合は、Active Directory コネクタ (ADC) 管理ツールで、接続許可書のプロパティの [接続] タブにある Exchange サーバー名を変更する必要があります。問題の Exchange サーバーが、保守またはその他の明らかな理由でオフラインになっている場合、このエラーは無視してかまいません。

このエラーを修正するには

  1. [スタート] ボタンをクリックし、[プログラム] をクリックします。次に、[管理ツール] をクリックし、[Active Directory コネクタ] をクリックします。

  2. 左側のペインで、変更する接続許可書をホストしている ADC サーバーをクリックします。

  3. 右側のペインで、変更する接続許可書を右クリックし、[プロパティ] をクリックします。

  4. [接続] タブをクリックします。

  5. 接続に使用するサーバーの名前を、存在するサーバー名に変更します。

ADC 接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 303180「[XADM] 管理グループが混在する場合の Active Directory コネクタ接続許可書の要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)


指定されたオフライン アドレス帳サーバーが組織内に存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オフライン アドレス帳構成オブジェクトの offLineABServer 属性の値を判断します。offLineABServer 属性は、オフライン アドレス帳を作成する Exchange Server コンピュータの識別名が格納されている、単一値の識別名属性です。

また、Exchange Server アナライザは、Active Directory 内の Exchange Server オブジェクトの distinguishedName 属性の値も調べます。

offLineABServer 属性に列挙されているサーバーが、Exchange Server オブジェクトの見つかった distinguishedName 属性と一致せず、さらに offLineABServer 属性に DEL: という文字列が含まれていないことが検出されると、エラーが表示されます。

Exchange は、各オフライン アドレス帳のオフライン アドレス帳ファイルを、指定されたサーバーの一連のパブリック フォルダ内に生成および格納します。このメッセージが表示される場合は、オフライン アドレス帳オブジェクトで指定されているサーバーが存在しないことを示しています。この状況は、古いオフライン アドレス帳サーバーが使用を停止されている場合や、トポロジから誤って削除されている場合に発生することがあります。新しいサーバーが指定されるまで、Exchange はオフライン アドレス帳を作成しません。

Exchange Server 2000 または Exchange Server 2003 でこのエラーを修正するには

  1. Exchange システム マネージャの [受信者] で、[オフライン アドレス一覧] をクリックします。右側のペインで、[既定のオフライン アドレス一覧] (またはこのメッセージを作成する他のオフライン アドレス一覧) をクリックし、[プロパティ] をクリックします。

  2. [全般] タブの [オフライン アドレス帳サーバー] で、[参照] をクリックし、使用するサーバーをクリックします。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。アクション ペインの [移動] タブをクリックして、オフライン アドレス帳の移動ウィザードを起動します。このウィザードを使用すると、オフライン アドレス帳の生成を別のサーバーに移動できます。既存のオフライン アドレス帳ファイルを指定のサーバーにコピーすることもできます。

Exchange Management Shell を使用して、オフライン アドレス帳の生成をホストするサーバーを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Server> には、選択した処理を実行する Exchange サーバーを指定します。

    たとえば、オフライン アドレス帳の生成を SERVER01 に移動するには、次のように入力します。
コードのコピー
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink/?LinkId=79247) (英語) を参照してください。


指定された受信者更新サービス Exchange サーバーが組織内に存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-03-29

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内のすべての Exchange Server オブジェクトの distinguishedName 属性の値を判断します。また、Active Directory ディレクトリ サービスに対してもクエリを実行し、ディレクトリ内の各受信者更新サービスオブジェクトの msExchAddressListServiceLink 属性の値も判断します。msExchAddressListServiceLink 属性は、アドレス一覧サービスから、そのサービスが実行されている Exchange Server コンピュータへのリンクです。msExchAddressListServiceLink 属性の値に "DEL" という文字列が含まれておらず、その属性がディレクトリ内のどの Exchange Server オブジェクトの distinguishedName 属性とも一致しないことが検出されると、エラーが表示されます。

受信者更新サービスの各インスタンスは、受信者更新サービスを実行している Exchange Server コンピュータの 1 台と関連付けられています。このメッセージが表示される場合は、その受信者更新サービス インスタンスが、Exchange 組織内には存在しない Exchange Server コンピュータに関連付けられています。そのサーバーは、使用を停止されているか、別の理由でトポロジから外されている可能性があります。

受信者更新サービスのこのインスタンスを実行するには、そのインスタンスを既存の Exchange Server に関連付ける必要があります。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] で、[受信者更新サービス] をクリックします。右側のペインで、受信者更新サービスの該当するインスタンスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[Exchange サーバー] の横の [参照] をクリックし、このインスタンスを実行する新しいサーバーを指定します。

  4. [OK] をクリックし、[OK] をもう 1 回クリックして変更を有効にします。

  5. Exchange システム マネージャを終了します。

受信者更新サービスの詳細については、以下のトピックおよび Microsoft サポート技術情報の文書を参照してください。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47617) の「Managing Recipients and Recipient Policies in Exchange Server 2003」(このサイトは英語の場合があります)

  • 文書番号 328738「受信者更新サービスで受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 246127「Exchange 受信者更新サービスの進行状況を確認する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 文書番号 253770「Exchange 受信者更新サービスで実行されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


指定されたルーティング グループ マスタ サーバーが管理グループ内に存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ルーティング グループ コンテナの msExchRoutingMasterDN 属性の値を判断します。msExchRoutingMasterDN 属性の値に有効なサーバー名が含まれておらず、さらにその属性に "DEL:" という文字列が含まれていないことが検出されると、警告が表示されます。

この問題は、以前のルーティング グループ マスタが使用を停止されている場合や、トポロジから誤って削除されている場合に発生することがあります。ルーティング グループ マスタがないと、Exchange はルーティング トポロジの正常な更新または管理を行うことができません。

ルーティング グループを作成する場合、そのルーティング グループの最初のサーバーに、"ルーティング グループ マスタ" の役割が割り当てられます。ルーティング グループ マスタは、ルーティング グループに対して現在のリンク状態情報を保持し、この情報をルーティング グループを持つ他のサーバーに適用します。ルーティング グループ マスタは、そのルーティング グループのみについて、Active Directory に書き込まれるルーティング構成を監視します。メンバ サーバーは、他のコネクタ状態またはサーバーの可用性情報をルーティング グループ マスタに通信します。たとえば、メンバ サーバーが、あるコネクタを介して、別のルーティング グループ内の別のサーバーとの通信を試み、そのリンクが使用できない場合、メンバ サーバーは直ちにルーティング グループ マスタに通知します。同様に、マスタ以外のサーバーは、新しいリンク状態情報を受信すると直ちにコネクタ状態情報をルーティング グループ マスタに転送します。このため、他のサーバーはルーティングの変更に関する情報を受信することができます。

この警告を修正するには

  1. Exchange システム マネージャで、[管理グループ] の [管理グループ名] を展開し、[ルーティング グループ]を展開します。

  2. 対象のルーティング グループを展開し、[メンバ] をクリックします。

  3. 右側のペインで、ルーティング グループ マスタとして構成する Exchange コンピュータを右クリックし、[マスタに設定] をクリックします。

ルーティング グループ マスタの詳細については、『Exchange Server Transport and Routing Guide』の「Configuring a Routing Topology」(http://go.microsoft.com/fwlink/?linkid=47579) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ用接続許可書の数が構成接続許可書の数より少ない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory と 各 Exchange Server 5.5 サイトの間にパブリック フォルダ用接続許可書があるかどうかを判断します。これを行うには、パブリック フォルダ用接続許可書の数と構成接続許可書の数の両方についてクエリを実行します。パブリック フォルダ用接続許可書の数が構成接続許可書の数よりも少ないことが検出されると、警告が表示されます。

この警告は、少なくとも 1 つの Exchange Server 5.5 サイトが Active Directory との間にパブリック フォルダ用接続許可書を持っていないため、パブリック フォルダのディレクトリ オブジェクトを Active Directory にレプリケートできないことを示します。したがって、Exchange 2000 Server のメールボックスまたは Exchange Server 2003 のメールボックスから Exchange Server 5.5 のパブリック フォルダへメールを流すことも、Exchange Server 5.5 のメールボックスからメールが有効な Exchange 2000 Server または Exchange Server 2003 のパブリック フォルダへメールを流すこともできません。

構成接続許可書は、Exchange Server 5.5 のみが存在するサイトで Exhcange 2000 Server コンピュータまたは Exchange Server 2003 コンピュータをインストールすると、自動的に生成されます。パブリック フォルダ用接続許可書は、ユーザー定義の接続許可書です。各 Exchange Server 5.5 サイトと Active Directory の間にパブリック フォルダ用接続許可書が存在する場合は、少なくとも構成接続許可書と同数のパブリック フォルダ用接続許可書が存在します。

パブリック フォルダ用接続許可書を作成するには

  1. Active Directory コネクタ (ADC) サーバーで、Active Directory コネクタ マネージャを起動します ([スタート] ボタンをクリックし、[プログラム] または [すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[Active Directory コネクタ] をクリックします)。

  2. コンソール ツリーで、[Active Directory コネクタ] をクリックします。右側のウィンドウに接続許可書の一覧が表示されます。この一覧を使用して、パブリック フォルダ接続許可書を持っていないサイトを判断します。

  3. [操作] メニューで [新規作成] をポイントし、[パブリック フォルダ用接続許可書] をクリックしてプロパティを設定するダイアログ ボックスを表示します。

  4. [全般] タブの [名前] に、接続許可書の名前を入力します。

  5. [Active Directory コネクタ サービス] で、接続許可書を実行するサーバーを選択します。

  6. [接続] タブで、パブリック フォルダ オブジェクトをレプリケートする Active Directory サーバーおよび Exchange Server 5.5 サーバーを選択し、それぞれについて適切なアカウントおよび資格情報を指定します。

  7. [スケジュール] タブで、レプリケーション スケジュールを選択します。

  8. [OK] をクリックします。

パブリック フォルダと構成接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 264889「[XADM] パブリック フォルダの接続許可書について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=264889)

  • 文書番号 281223「Exchange の接続許可書について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=281223).


オフライン アドレス帳の生成が継続的に更新するよう設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchOAB クラスの offLineABSchedule 属性値がオフライン アドレス帳の生成用に構成されているかどうかを判断します。offLineABSchedule 属性によって、オフライン アドレス一覧のスケジュールが決定されます。Exchange Server アナライザによって、オフライン アドレス一覧のためのオフライン アドレス帳の生成スケジュールが継続的に更新するよう設定されていることが検出されると、エラーが表示されます。

オフライン アドレス帳は、オフライン アドレス一覧のコレクションを格納するコンテナです。管理者は、使用可能なオフライン アドレス帳を構成します。Microsoft Office Outlook® 2003 および Outlook 2007 ユーザーは、ダウンロードするオフライン アドレス一覧を選択できます。Outlook 2003 や Outlook 2007 などの MAPI クライアントは、オフライン アドレス一覧をダウンロードできます。そのため、ユーザーは、Exchange サーバーに接続していない場合でも電子メール メッセージを作成できます。

オフライン アドレス一覧を更新する時間は、スケジュールすることができます。ただし、次回の更新が開始される前に、オフライン アドレス一覧の生成が完了するだけの十分な時間が確保されるような更新スケジュールを構成するようにしてください。たとえば、以下の条件に当てはまる場合は、各更新の間隔を少なくとも 4 時間は空ける必要があります。

  • 24 時間以内に 3 つの更新が指定されている。

  • オフライン アドレス一覧の更新に 4 時間かかる。

頻繁に更新を行うと、次に示すような形でクライアントやサーバーのパフォーマンスに影響する可能性があるため、一般には、頻繁に更新しないようにすることをお勧めします。

  • サーバーは、オフライン アドレス帳をより頻繁に生成する必要があります。Active Directory のサイズによっては、完了に数時間かかる可能性があります。

  • 更新のたびに、Outlook はオフライン アドレス帳のコピーをローカル コンピュータ上に作成し、サーバーから取得される増分変更を適用する必要があります。ローカル コンピュータ上のオフライン アドレス帳が 150 MB であれば、Outlook は更新のたびに、これだけの容量のデータのコピーを作成する必要があります。

  • Outlook には、ユーザー操作を検出するとオフライン アドレス帳の更新速度を低下させる "スロットリング" メカニズムがあります。ユーザー操作が継続的に発生した場合、オフライン アドレス帳のサイズに応じて、更新には短くて 1 時間、長ければ 8 時間かかります。

更新の頻度を増やす場合は、オフライン アドレス帳がそれほど大きくないことを確認してください。圧縮されていない状態での適度なサイズは 1 ～ 25 MB です。

Exchange 2000 Server と Exchange Server 2003 でオフライン アドレス一覧を更新する時間をスケジュールするには

  1. [システム マネージャ] で、[受信者] をダブルクリックし、[オフライン アドレス一覧] をクリックします。

  2. 詳細ペインで、更新スケジュールを設定するオフライン アドレス一覧をダブルクリックします。

    1. あらかじめ構成された更新間隔を選択するには、[全般] タブで、[更新の間隔] ボックスの一覧から間隔のうちの 1 つを選択します。

      重要 :
      ボックスの一覧から [実行しない] を選択すると、オフライン アドレス一覧は更新されません。
    2. 特定の更新スケジュールを設定するには、[カスタマイズ] をクリックします。[スケジュール] ダイアログ ボックスで、表示されている日付と時刻のグリッドで更新スケジュールを設定し、[OK] をクリックします。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。アクション ペインで、[プロパティ] をクリックします。

  5. [全般] タブで、[更新スケジュール] ボックスの一覧から実行時間を選択するか、[カスタマイズ] をクリックしてカスタム スケジュールを設定します。

  6. [OK] をクリックして変更を保存します。
Exchange Management Shell を使用してオフライン アドレス帳の生成スケジュールを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Set-OfflineAddressBook -Identity <OAB Name> -Schedule <Schedule>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Schedule> には、オフライン アドレス帳の生成を開始するスケジュール時間を指定します。形式は開始曜日.時:分 [AM/PM] です。曜日には次の値を使用できます。

    • 曜日の完全な名前。

    • 曜日の省略名。

    • 0 ～ 6 の整数。0 は日曜日です。

    24 時間制を使用する場合、AM/PM は省略します。

    たとえば、既定のオフライン アドレス帳の生成スケジュールを毎日午前 1 時と 3 時に設定するには、次のように入力します。
コードのコピー
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -Schedule 0.01:00-0.03:00,1.01:00-1.03:00,2.01:00-2.03:00,3.01:00-3.03:00,4.01:00-4.03:00,5.01:00-5.03:00,6.01:00-6.03:00

詳細については、オフライン アドレス帳のベスト プラクティスに関するガイド (http://go.microsoft.com/fwlink/?LinkId=47583) (英語) を参照してください。

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink/?LinkId=79247) (英語) を参照してください。


オフライン アドレス帳の生成スケジュールが [実行しない] に設定されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オフライン アドレス帳構成オブジェクトの offLineABSchedule 属性値を判断します。offLineABSchedule 属性は、Active Directory の [アドレス一覧] コンテナに含まれる [既定のオフライン アドレス一覧] オブジェクトのオフライン アドレス帳の生成スケジュールを表します。Exchange Server アナライザによって、offLineABSchedule 属性が [実行しない] を示す値に設定されていることが検出されると、警告が表示されます。

既定では、Exchange はオフライン アドレス帳を 1 つだけ保持します。Exchange は、メンテナンス サイクル中、毎晩このオフライン アドレス帳を更新するか、または新しいバージョンのオフライン アドレス帳を生成します。追加のオフライン アドレス帳を作成する場合は、以下の手順に従うと、オフライン アドレス帳の生成スケジュールを確認できます。

この警告は、スケジュールが [実行しない] に変更されていることを示します。Exchange は、新しいスケジュールが設定されるまで既存のオフライン アドレス帳を更新しません。これは、ユーザーは既存のオフライン アドレス帳をダウンロードできるものの、更新は受け取らないことを意味します。

Exchange 2000 Server および Exchange Server 2003 の場合にこの警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] の下にある [オフライン アドレス一覧] をクリックします。

  3. 右側のペインで、[既定のオフライン アドレス一覧] を右クリックし、[プロパティ] をクリックします。オフライン アドレス帳を使用しない場合は、[既定のオフライン アドレス一覧] を右クリックし、[削除] をクリックします。それ以外の場合は、残りの手順を実行してスケジュールを設定します。

  4. [全般] タブで、[更新の間隔] ボックスの一覧から実行時間を選択するか、[カスタマイズ] をクリックしてカスタム スケジュールを設定します。

  5. [OK] をクリックし、変更を保存します。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。アクション ペインで、[プロパティ] をクリックします。

  5. [全般] タブで、[更新スケジュール] ボックスの一覧から実行時間を選択するか、[カスタマイズ] をクリックしてカスタム スケジュールを設定します。

  6. [OK] をクリックして変更を保存します。

Exchange Management Shell を使用してオフライン アドレス帳の生成スケジュールを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Set-OfflineAddressBook -Identity <OAB Name> -Schedule <Schedule>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Schedule> には、オフライン アドレス帳の生成を開始するスケジュール時間を指定します。形式は開始曜日.時:分 [AM/PM] です。曜日には次の値を使用できます。

    • 曜日の完全な名前。

    • 曜日の省略名。

    • 0 ～ 6 の整数。0 は日曜日です。

    24 時間制を使用する場合、AM/PM は省略します。

    たとえば、既定のオフライン アドレス帳の生成スケジュールを毎日午前 1 時と 3 時に設定するには、次のように入力します。
コードのコピー
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -Schedule 0.01:00-0.03:00,1.01:00-1.03:00,2.01:00-2.03:00,3.01:00-3.03:00,4.01:00-4.03:00,5.01:00-5.03:00,6.01:00-6.03:00

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink?LinkId=79247) (英語) を参照してください。


古い接続許可書が検出される
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Active Directory コネクタ (ADC) 接続許可書の versionNumber 属性の値を判断します。

1 つ以上の Exchange Server 2003 コンピュータを含む Exchange 組織で、いずれかの接続許可書の versionNumber 属性の値が 16973842 未満であることが検出されると、警告が表示されます。

値が 16973842 未満の場合、その接続許可書は Exchange 2000 Server ADC により作成され、管理されています。Exchange 2000 Server または Exchange Server 5.5 のいずれかが実行されている組織で Exchange Server 2003 のインスタンスを実行している場合は、ADC のすべてのインスタンスを、Exchange Server 2003 に含まれているバージョンにアップグレードする必要があります。Exchange Server 2003 または Exchange Server 2003 Service Pack 1 (SP1) バージョンの ADC にアップグレードすると、そのバージョンの ADC が所有する接続許可書も更新されます。それぞれの接続許可書の versionNumber 属性は、最新の値に更新されます。

この警告を修正するには

  1. Exchange Server 2003 Server SP1 を、http://go.microsoft.com/fwlink/?LinkId=29090 からダウンロードします。

  2. Exchange Server コンピュータの完全なバックアップを実行します。

  3. Exchange 2000 Server の ADC を実行しているサーバーで、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<パス>\adc\i386\setup.exe」と入力します。この <パス> は、Exchange 2003 Server SP1 をダウンロードした場所です。

  4. [Active Directory コネクタ インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  5. [検出された以前のインストール] ページで [再インストール] をクリックして、Exchange 2000 Server の ADC を Exchange Server 2003 の ADC にアップグレードします。

  6. [Active Directory コネクタ インストール ウィザードの完了] ページで、[完了] をクリックします。

ADC のインストールとアップグレードの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 822942「Exchange Server 2003 にアップグレードする際の注意事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822942)


PDC エミュレータ FSMO 役割からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン名前付けコンテキストのドメイン ディレクトリ パーティションのルートについて、fSMORoleOwner 属性の値を判断します。たとえば、contoso.com というドメインでは、プライマリ ドメイン コントローラ (PDC) エミュレータの fSMORoleOwner は DC=contoso,DC=com の属性です。次に、Exchange Server アナライザは、現在その役割を保持しているドメイン コントローラの TCP ポート 389 に対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。このドメイン コントローラに接続できないと、エラーが表示されます。

PDC エミュレータは、以前の Microsoft Windows® オペレーティング システムとの互換性のために、プライマリ ドメイン コントローラとして機能します。Microsoft Windows 2000 Server および Microsoft Windows Server™ 2003 は、Microsoft Windows NT® ワークステーション、メンバ サーバー、およびバックアップ ドメイン コントローラとの相互運用を行います。Microsoft Windows NT 3.51 または Microsoft Windows NT 4.0 ドメインの PDC には、以下の役割があります。

  • ユーザーとコンピュータの両方からのパスワード変更処理

  • バックアップ ドメイン コントローラへの更新のレプリケート

  • ドメイン マスタ ブラウザの実行

PDC エミュレータのマスタの役割が割り当てられるドメイン コントローラは、各ドメインで 1 つだけです。

このエラーを修正するには

  1. エラーに示されたディレクトリ サーバーがオンラインになっており、組織内の Exchange サーバーからアクセスできることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、PDC エミュレータの役割を別のドメイン コントローラに割り当てる必要があります。

PDC エミュレータの役割をあるドメイン コントローラから別のドメイン コントローラに転送することに関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Windows Server 2003 については、文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


構成オブジェクトのアクセス許可の継承がブロックされる
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-04-13

Microsoft® Exchange Server アナライザ ツールは、Active Directory® データベース内のすべての Exchange 構成オブジェクトに対してクエリを発行し、アクセス許可の継承がブロックされているオブジェクトがあるかどうかを判断します。Exchange 構成オブジェクトのアクセス許可の継承がブロックされている場合、エラーが表示されます。

Exchange Server アナライザは、アクセス許可の継承がブロックされている構成オブジェクトを識別します。

Exchange Server アナライザは、Active Directory から Exchange 構成オブジェクト用の随意アクセス制御リスト (DACL) を取得します。既定では、Exchange をインストールするときに、Exchange サーバーや Exchange Server プロトコルなどの構成オブジェクトはアクセス許可を継承するように設定されます。アクセス許可を誤って無効にするかまたは変更すると、構成オブジェクトのアクセス許可の継承がブロックされます。この状態では、キュー内にメッセージが残されるなどのメールの流れに関する問題や、ストアのマウントに関する問題が発生し、Exchange Server の応答速度が低下する可能性があります。

注 :
アクセス制御リスト (ACL) は、すべてのオブジェクト、オブジェクトの一連のプロパティ、またはオブジェクトの個別のプロパティに適用される、セキュリティ保護のリストです。アクセス制御リストには、随意とシステムの 2 種類があります。

オブジェクトのアクセス許可の継承を再度有効にすると、この問題を解決できます。

Exchange 構成オブジェクトのアクセス許可の継承を再度有効にするには、次の操作を行います。

  1. レジストリ パラメータを設定することにより、Exchange システム マネージャのオブジェクトのプロパティ ボックスにある [セキュリティ] タブを有効にします。詳細な手順については、Microsoft サポート技術情報の文書番号 264733「[XADM] 組織オブジェクトの [セキュリティ] タブを有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264733) を参照してください。

    注 :
    既定では、構成オブジェクトのプロパティ ボックスの [セキュリティ] タブは無効になっています。

  2. Exchange システム マネージャを開き、対象のオブジェクトを見つけて、アクセス許可の継承を再度有効にします。

  3. Exchange Server を再起動します。

Windows Server 2003 Active Directory の随意アクセス制御リストの詳細については、セキュリティ記述子とアクセス制御リストの動作についてのページ

(http://go.microsoft.com/fwlink/?LinkId=64193) を参照してください (このサイトは英語の場合があります)。

アクセス許可の継承の詳細については、アクセス許可の動作についてのページ (http://go.microsoft.com/fwlink/?LinkId=64195) を参照してください (このサイトは英語の場合があります)。


ドメイン オブジェクトのアクセス許可の継承がブロックされる
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-04-13

Microsoft® Exchange Server アナライザ ツールは、コンテナや組織単位などの Active Directory® ドメイン オブジェクトを確認します。コンテナまたは組織単位のアクセス許可の継承がブロックされている場合、Exchange Server アナライザはエラーを表示します。

Exchange Server アナライザは特定のオブジェクトを識別します。

Active Directory ドメイン オブジェクトを変更すると、アクセス制御リスト (ACL) に対する変更が上書きされます。'親からの継承' を手動で有効にしている場合でも、変更が ACL に適用されると、適用済みの継承が無効になります。受信者更新サービス (RUS) は、アカウントが存在している Active Directory 組織単位へのアクセスに必要なアクセス許可を持っていないため、継承が無効になると RUS に問題が発生します。

この状況は、アカウントが存在している Active Directory 組織単位の [Allow inheritable permissions from parent to propagate to this object] チェック ボックスをオフにすると発生する場合があります。

この問題を解決するには、Active Directory ユーザーとコンピュータ スナップインまたは Active Directory サービス インターフェイス (ADSI) Edit を使用して、組織単位へのアクセス用の継承可能なアクセス許可を再構成します。Microsoft サポート技術情報の文書番号 254030「不足する権限では、受信者更新サービスが in Exchange 2000 のサーバーと Exchange Server 2003 のアカウントを処理しないのが発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=254030) のシナリオ 2 で詳細に説明されている手順に従います。

Microsoft Windows Server 2003™ Active Directory のアクセス制御リスト (ACL) の詳細については、セキュリティ記述子とアクセス制御リストの動作についてのページ (http://go.microsoft.com/fwlink/?LinkId=64193) を参照してください (このサイトは英語の場合があります)。

アクセス許可の継承の詳細については、アクセス許可の動作についてのページ (http://go.microsoft.com/fwlink/?LinkId=64195) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ階層が見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPFTreeType 属性値が 1 であるパブリック フォルダ階層の数を判断します。msExchPFTreeType 属性値が 1 の場合は、特定のパブリック フォルダ階層が MAPI クライアント用に指定されたパブリック フォルダ階層であることを示しています。Exchange Server アナライザによって、Exchange 組織内に msExchPFTreeType 属性値が 1 であるパブリック フォルダ階層が存在しないことが検出されると、エラーが表示されます。

このエラーは、組織内に MAPI クライアント用のパブリック フォルダ階層が存在しないことを示しています。MAPI クライアント用のパブリック フォルダ階層が存在しないと、問題が発生することがあります。たとえば、MAPI クライアント用のパブリック フォルダ階層が存在しない場合、Microsoft Windows® サーバー クラスタで実行されている Exchange 仮想サーバーをアップグレードしようとすると失敗する可能性があります。

この問題を解決するには、Active Directory 編集ツールを使用して、MAPI クライアント用のパブリック フォルダ階層の msExchPFTreeType 属性値を 1 に設定します。Active Directory 編集ツールを次に示します。

  • Active Directory サービス インターフェイス (ADSI) Edit (AdsiEdit.msc)

  • LDP (ldp.exe) ツール

MAPI パブリック フォルダ階層のみを変更するようにしてください。Exchange 組織にアプリケーション パブリック フォルダ階層が含まれている場合は、MAPI パブリック フォルダ階層のみの属性を変更するようにしてください。

MAPI パブリック フォルダ階層の msExchPFTreeType 属性値を 1 に設定した後、Exchange サーバーのメールボックス ストアを、既定のパブリック フォルダ ストアとして MAPI パブリック フォルダ階層を指すように構成します。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. Active Directory 編集ツールを使用して、Active Directory 内のパブリック フォルダ階層オブジェクトを見つけます。パブリック フォルダ オブジェクトは、CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<OrganizationName>, CN=Administrative Groups, CN=<AdminGroupName>, CN=Folder Hierarchies にあります。

  2. msExchPFTreeType 属性を、新しい値として「1」と入力して変更します。

  3. Active Directoyr エディタを終了します。

  4. Exchange システム マネージャを起動します。

  5. 各メールボックス ストアのプロパティにアクセスするには、[管理グループ] を展開し、使用している管理グループを展開します。次に、[サーバー] を展開し、使用しているサーバーを展開して、使用しているストレージ グループを展開します。次に、プロパティを変更するメールボックス ストアを右クリックし、[プロパティ] をクリックします。

  6. [全般] タブで、[既定のパブリック ストア] の [参照] をクリックします。

  7. MAPI パブリック フォルダ階層を選択し、[OK] を 2 回クリックして変更を保存します。

  8. 各メールボックス ストアに対して、手順 5. ～ 7. を繰り返します。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

MAPI およびアプリケーション用のパブリック フォルダ階層の詳細については、以下の文書を参照してください。

  • Microsoft サポート技術情報の文書番号 258509「[XADM] Exchange 2000 のパブリック フォルダ ツリーの種類」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258509)

  • Exchange Team Blog のエントリ「How mail-enabled Public Folders work」(http://go.microsoft.com/fwlink/?LinkId=41913) (このサイトは英語の場合があります)


受信者用接続許可書のレプリケーション スケジュールが [常に] に設定されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Active Directory コネクタ (ADC) 接続許可書の activationStyle 属性がどのように設定されているかを判断します。activationStyle 属性は、ADC 接続許可書が実行される頻度に対応します。値が 0 の場合、レプリケーション スケジュールは [しない] に設定されています。値が 1 の場合、レプリケーション スケジュールは [選択時間] に設定されています。値が 2 の場合、レプリケーション スケジュールは [常に] に設定されています。

また、Exchange Server アナライザは、Active Directory に対してもクエリを実行し、各 ADC 接続許可書オブジェクトの msExchServer2SearchFilter 属性の値を判断します。msExchServer2SearchFilter 属性は、ディレクトリの検索時に使用される検索フィルタを表わします。

activationStyle 属性が [常に] に設定されていないこと、および msExchServer2SearchFilter 属性が受信者情報をレプリケートしていることが検出されると、警告が表示されます。

一般に、受信者用接続許可書のレプリケーション スケジュールは、常にレプリケートするように設定することがベスト プラクティスです。場合によっては、接続許可書をそれ以外のスケジュールに設定すると、Exchange 5.5 サイトのメールボックスを Exchange Server 2003 組織に移動した後に配信不能レポート (NDR) が生成されることがあります。

この警告を修正するには

  1. Active Directory コネクタ サービス MMC スナップインを開きます。

  2. [接続許可書] を開きます。

  3. 接続許可署名のプロパティ ページで、[スケジュール] タブをクリックし、[常に] をクリックします。次に、[OK] をクリックします。

ADC の展開と接続許可書の構成の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。


受信者ポリシーに変数が含まれている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各受信者ポリシー オブジェクトの gatewayProxy 属性の値を判断します。受信者ポリシー オブジェクトの gatewayProxy 属性に文字列 SMTP:% が含まれていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

置換文字列を使用して SMTP (Simple Mail Transfer Protocol) アドレスを生成するように受信者ポリシーを変更している場合、受信者ポリシーには変数が含まれます。Exchange 2000 Server Service Pack 2 (SP2) より前のバージョンでは、既定の受信者ポリシーに変数を使用すると、レプリケーションに関する問題が発生する可能性があります。したがって、受信者ポリシーに変数を使用しないようにするか、Exchange 2000 Server を最新の Service Pack にアップグレードすることをお勧めします。Exchange 2000 Server SP2 以降では、既定の受信者ポリシーで変数がサポートされます。

受信者ポリシーを変更するには

  1. Exchange システム マネージャを起動します。

  2. [組織] をクリックし、[受信者] をクリックします。次に、[受信者ポリシー] をクリックします。

  3. 変更するポリシーをダブルクリックします。

  4. [電子メール アドレス] タブをクリックし、適切な SMTP アドレスまたは生成ルールを編集します。

受信者ポリシーの構成方法の詳細については、Microsoft サポート技術情報の文書番号 249299「[HOWTO] Exchange で受信者ポリシーを構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249299) を参照してください。

生成ルールを使用した SMTP アドレスのカスタマイズの詳細については、Microsoft サポート技術情報の文書番号 822447「受信者ポリシーを使用して SMTP 電子メール アドレスを変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822447) を参照してください。

既定の受信者ポリシーに変数が含まれている場合に Exchange 2000 Server で発生する可能性がある問題の詳細については、Microsoft サポート技術情報の文書番号 271339「[XADM] データベースをマウントできずイベント ID 9546 が発生する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=271339) を参照してください。

最新の Exchange 2000 Server Service Pack の入手については、Exchange 2000 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


受信者更新サービスが停止しているように見える
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory の受信者更新サービス オブジェクトのそれぞれについて msExchServer1HighestUSN 属性値を判断します。また、Active Directory ディレクトリ サービスに対してクエリを実行し、Active Directory 内の各受信者更新サービス オブジェクトの activationStyle 属性値も判断します。activationStyle 属性は、受信者更新サービスの更新間隔を示しています。

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、受信者更新サービスで使用されているドメイン コントローラの RootDSE 属性の highestCommittedUSN 属性値も判断します。highestCommittedUSN 属性は、このドメイン コントローラ上のデータベースにコミットされたサーバー上のすべてのオブジェクトのうちで最も高い更新シーケンス番号 (USN) です。

また、Active Directory ディレクトリ サービスに対してクエリを実行し、各受信者更新サービス オブジェクトの msExchServer1LastUpdateTime 属性値も判断します。msExchServer1LastUpdateTime 属性は、最後に成功したこのディレクトリからの同期のうち最新の更新の日付と時刻を示しています。

Exchange Server アナライザによって、次の 3 つの条件に当てはまることが検出されると、警告が表示されます。

  • activationStyle 属性が 2 に設定されている。これは、この受信者更新サービスのスケジュールが [常に] に設定されていることを示しています。

  • msExchServer1HighestUSN 値に列挙されているシーケンス番号が、highestCommittedUSN に列挙されているシーケンス番号よりも 5,000 以上小さい。

  • msExchServer1LastUpdateTime 属性に記録されているタイムスタンプから 6 時間以上経過している。

この警告は、指定された受信者更新サービスが数時間実行されておらず、停止している可能性があることを示しています。

この警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[受信者更新サービス] を選択します。

  3. 指定された受信者更新サービスを右クリックし、[今すぐ更新] を選択します。

  4. 30 分待ってから Exchange Server アナライザを再実行して、この警告が依然として表示されるかどうかを確認します。警告が表示される場合は、手順 5. に進みます。警告が表示されなくなったら、これ以上の操作は必要ありません。

  5. Microsoft Exchange System Attendant サービスを再開します。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 253838「[XADM] 受信者更新サービスでシステム ポリシーが適用されるしくみ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328728)


受信者更新サービスがすべての変更を処理していない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory 内のいずれかの受信者更新サービス オブジェクトの gatewayProxy 属性に値が設定されているかどうかを判断します。いずれかの受信者更新サービス オブジェクトの gatewayProxy 属性に値が設定されていることが検出されると、警告が表示されます。

この警告は、受信者更新サービス オブジェクトの gatewayProxy 属性に、完全には処理されていない古いデータが含まれていることを示しています。このデータは手動で削除する必要があります。

gatewayProxy 属性から古いデータを削除する必要があります。削除しないと、これらのアドレスが '適用済み' の状態になります。管理者が [再構築] オプションまたは [今すぐ更新] オプションを使用してポリシーの変更を選択すると、ユーザーの有効なアドレスが誤って上書きされ、それぞれのユーザーの SMTP アドレスが変更されます。詳細については、Exchange ブログの記事の受信者ポリシーおよび Exchange 2000 と 2003 のみが存在するサイトについての情報を参照してください (このサイトは英語の場合があります)。

注 :
このブログへのリンクは、情報の提供を目的として用意されています。内容は通知なしに変更される場合があります。

以下のいずれかの条件に当てはまる場合は、受信者更新サービス オブジェクトの gatewayProxy 属性に、完全には処理されていない古いデータが含まれている可能性があります。

  • Active Directory レプリケーション関連の問題が存在する。Exchange システム マネージャが、受信者更新サービスを実行している Exchange サーバーで使用されているものとは異なるドメイン コントローラを使用している場合は、Active Directory レプリケーションに関連する待ち時間やその他の問題が発生する可能性があります。

  • トランザクション関連以外のタイミング的な問題が存在し、変更が失われる原因になっている。この状況は、Exchange システム マネージャとシステム アテンダントが gatewayProxy 属性に同時にアクセスした場合に発生します。Exchange システム マネージャとシステム アテンダントはどちらも、この属性を読み取り、変更を行ってから、この属性を書き戻します。

古いデータは、Active Directory サービス インターフェイス (ADSI) Edit (AdsiEdit.msc)、LDP (ldp.exe) ツール、または他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用して削除する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
この警告を修正するには

  1. 次の操作を行い、受信者更新サービスに対する更新の間隔を [実行しない] に設定します。

    1. Exchange システム マネージャを起動します。

    2. [受信者] を展開し、[受信者更新サービス] を展開します。

    3. 変更する受信者更新サービスを右クリックし、[プロパティ] を選択します。

    4. [全般] タブで、[更新の間隔] 一覧を使用してスケジュールを [実行しない] に設定します。

  2. 約 1 ～ 2 分待ちます。

  3. 次に、ADSI Edit または同様のツールを使用して、gatewayProxy 属性に古いデータが含まれている受信者更新サービス オブジェクトを見つけます。受信者更新サービス オブジェクトは次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Address Lists Container,CN=Recipient Update Services

    1. 古いデータを含んでいる受信者更新サービス オブジェクトを右クリックし、[プロパティ] を選択します。

    2. [Attribute Editor] タブで、下にスクロールして gatewayProxy 属性を選択します。

    3. [Edit] をクリックして、この属性を編集します。

    4. [Values] ボックスで、削除する古いアドレスの種類をクリックし、[Remove] をクリックします。次に、[OK] をクリックします。すべてのアドレスの種類を削除するまで、この手順を繰り返します。

    5. [OK] をクリックして変更を保存し、ADSI Edit を終了します。

  4. gatewayProxy 属性をクリアした後、ディレクトリのレプリケーションを実行します。ドメインの受信者更新サービスを再度実行する前に、レプリケーションが行われていることを確認してください。

  5. 受信者更新サービスを元のスケジュールに再構成します。

  6. 必要に応じて、特定の受信者ポリシーを再適用します。Active Directory サイトとサービス スナップインを使用して、手動で Active Directory レプリケーションを実行します。

この問題の詳細については、Microsoft サポート技術情報の文書番号 821743「受信者更新サービス オブジェクトの gatewayProxy 属性は、解除されていません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821743) を参照してください。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ディレクトリ レプリケーションの実行の詳細については、Microsoft サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

ADSI Edit の操作の詳細については、Windows Server 2003 ヘルプのトピック「Adsiedit.msc: ADSI Edit」(英語) を参照してください。


受信者更新サービスの完全な再構築
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server によって使用されている構成ドメイン コントローラの受信者更新サービス オブジェクトの msDS-ReplAttributeMetaData 属性値を判断します。msDS-ReplAttributeMetaData 属性には、この属性に対して最後に変更が行われた日時やその他の情報が含まれています。Exchange Server アナライザによって、msDS-ReplAttributeMetaData 属性に設定されている日時からの経過日が 5 日未満であることが検出されると、警告が表示されます。

この警告は、この受信者更新サービスの完全な再構築が最近スケジュールされたことを示しています。完全な再構築が構成されていると、次回受信者更新サービスがスケジュールまたは [今すぐ更新] コマンドによって開始されたとき、受信者更新サービスは新しいオブジェクトに対してのみクエリを実行するのではなく、すべてのオブジェクトを調べます。このプロセスは長時間を要する場合があり、システム遅延を引き起こす可能性があります。

完全な再構築を意図している場合は、この警告を無視してかまいません。完全な再構築を意図していない場合は、Active Directory サービス インターフェース (ADSI) Edit (AdsiEdit.msc) を使用し、以下の手順を実行して、Active Directory 内の msExchDoFullReplication 属性値を True から False に変更することにより、この問題を解決できます。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
この警告を修正するには

  1. ADSI Edit または同様のツールを使用して、指定された受信者更新サービス オブジェクトの msExchDoFullReplication 属性を見つけます。受信者更新サービス オブジェクトは、CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Address Lists Container,CN=Receipient Update Services にあります。

  2. 指定された受信者更新サービスを右クリックし、[プロパティ] を選択します。

  3. [Attribute Editor] タブで、下にスクロールして msExchDoFullReplication 属性を選択します。

  4. [Edit] をクリックして、この属性を編集します。

  5. [Boolean Attribute Editor] ダイアログ ボックスで、選択内容を [True] から [False] に変更し、[OK] をクリックします。

  6. [OK] をもう 1 度クリックして変更を保存し、ADSI Edit を終了します。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 253838「[XADM] 受信者更新サービスでシステム ポリシーが適用されるしくみ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328728)


受信者更新サービスが完全再構築用に構成されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory の受信者更新サービス オブジェクトのそれぞれについて msExchDoFullReplication 属性値を判断します。いずれかの受信者更新サービス オブジェクトの msExchDoFullReplication 属性値が True に設定されていることが検出されると、警告が表示されます。

この警告は、受信者更新サービスが、次回の処理サイクルに完全再構築を実行するように構成されていることを示しています。msExchDoFullReplication 属性が True に設定されていると、次回受信者更新サービスがスケジュールまたは [今すぐ更新] コマンドによって開始されたとき、受信者更新サービスは新しいオブジェクトに対してのみクエリを実行するのではなく、すべてのオブジェクトを調べます。このプロセスは長時間を要する場合があり、システム遅延を引き起こす可能性があります。

完全な再構築を意図している場合は、この警告を無視してかまいません。完全な再構築を意図していない場合は、Active Directory サービス インターフェース (ADSI) Edit (AdsiEdit.msc) を使用し、以下の手順を実行して、Active Directory 内の msExchDoFullReplication 属性値を True から False に変更することにより、この問題を解決できます。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
この警告を修正するには

  1. ADSI Edit または同様のツールを使用して、指定された受信者更新サービス オブジェクトの msExchDoFullReplication 属性を見つけます。受信者更新サービス オブジェクトは、CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Address Lists Container,CN=Receipient Update Services にあります。

  2. 指定された受信者更新サービスを右クリックし、[プロパティ] を選択します。

  3. [Attribute Editor] タブで、下にスクロールして msExchDoFullReplication 属性を選択します。

  4. [Edit] をクリックして、この属性を編集します。

  5. [Boolean Attribute Editor] ダイアログ ボックスで、選択内容を [True] から [False] に変更し、[OK] をクリックします。

  6. [OK] をもう 1 度クリックして変更を保存し、ADSI Edit を終了します。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 253838「[XADM] 受信者更新サービスでシステム ポリシーが適用されるしくみ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328728)


受信者更新サービスがアクティブになっていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory の受信者更新サービス オブジェクトのそれぞれについて activationStyle 属性値を判断します。受信者更新サービス オブジェクトの activationStyle 属性の値が 0 に設定されていることが検出されると、警告が表示されます。

この警告は、該当する受信者更新サービス オブジェクトのスケジュールが [実行しない] に設定されていることを示します。受信者更新サービスのスケジュールが [実行しない] に設定されている場合、新しいオブジェクトは処理されません。

この受信者更新サービス オブジェクトは、必要なければ削除し、必要であればスケジュールを構成することをお勧めします。

スケジュールの構成によってこの警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[受信者更新サービス] を選択します。

  3. スケジュールが [実行しない] に設定されている受信者更新サービスを右クリックし、[プロパティ] を選択します。

  4. [更新の間隔] ボックスの一覧から定義済みのスケジュールを選択するか、または [カスタマイズ] をクリックしてカスタム スケジュールを作成します。

  5. [OK] をクリックし、変更を保存します。

  6. この受信者更新サービスを右クリックし、[今すぐ更新] を選択します。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 253838「[XADM] 受信者更新サービスでシステム ポリシーが適用されるしくみ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253838)

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)


受信者更新サービス ソフトウェアを更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、受信者更新サービスとも呼ばれる、アドレス帳のビューおよび動的グループ サービス (abv_dg.dll) の Version キーの値を判断します。Version WMI キーは、このファイルのビルド番号を示しています。

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、NTDS Settings オブジェクトの msDS-Behavior-Version 属性値を判断します。この値は、Active Directory フォレストの機能レベルを示しています。以下の表に、msDS-Behavior-Version 属性の有効な値を示します。

値 | フォレストの機能レベル
0 | Microsoft Windows 2000 Server 混在
1 | Microsoft Windows Server™ 2003 中間
2 | Microsoft Windows Server 2003 ネイティブ

Exchange Server アナライザによって、Windows Server 2003 中間またはネイティブ モードの Active Directory フォレストにある Exchange サーバーの abv_dg.dll のビルド番号が 6.0.6615.0 より小さいことが検出されると、エラーが表示されます。このエラーは、Exchange 2000 Server バージョンの受信者更新サービスが、互換性のない Windows Server 2003 Active Directory フォレスト レベルで実行されていることを示しています。この問題を解決するには、受信者更新サービスの更新が必要です。

Exchange 2000 Server 内の受信者更新サービスを使用して Windows Server 2003 フォレスト内の受信者オブジェクトを更新しても、これらのオブジェクトは正しく更新されません。たとえば、この受信者更新サービスは、グループ メンバシップに加えられた変更を認識できません。また、Exchange 2000 Server Active Directory コネクタ (ADC) を使用している場合は、ADC がグループ メンバシップの変更を Active Directory から Exchange Server 5.5 ディレクトリにレプリケートできない可能性があります。

最新バージョンの受信者更新サービスにアップグレードするには

  1. Microsoft サポート技術情報の文書番号 873059「Windows Server 2003 フォレストで Exchange 2000 Server が実行すると、オブジェクトを正しく受信者更新サービスは更新しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=873059) の指示に従い、必要な更新を入手します。

  2. 更新を適用します。更新を適用した後にコンピュータを再起動する必要はありません。ただし、この更新を適用すると、Exchange 関連のサービスが自動的に再開されます。


RUS インスタンスがドメインに存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、フォレスト内のドメイン一覧を返します。また、既存のドメイン受信者更新サービス (RUS) インスタンスの一覧について、msExchangeDomainLink 属性に対してクエリを実行します。次に、返されたドメインの一覧と、返された RUS インスタンスの一覧を比較し、一致があるかどうかを判断します。以下の条件に当てはまる場合は、エラーが表示されます。

  • ドメインが存在する。

  • そのドメインに対する RUS インスタンスが存在しない。

ドメインが DomainPrep を使用して準備されているが、そのドメインに対する RUS インスタンスが存在しない場合、Exchange Server アナライザによってこのエラーが表示されます。管理者がフォレストに新しい Active Directory ドメインを追加し、DomainPrep を使用して Exchange 用にドメインの準備を行った後、そのドメインに対する RUS インスタンスの追加を忘れた場合、不一致が発生することがあります。この状況が発生した場合、ドメインで作成される新しいユーザー オブジェクトは、そのオブジェクト宛てに発行された電子メール アドレスを受信しません。このエラー メッセージが表示された場合は、そのドメインに対する新しい受信者更新サービスを作成します。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開します。

  3. [受信者更新サービス] ノードを右クリックし、[New] をクリックし、[受信者更新サービス] をクリックします。

  4. [新しいオブジェクト] ウィンドウで、[参照] をクリックして、ドメインの名前を見つけます。

  5. ドメイン名を選択し、[OK] をクリックします。

  6. [新しいオブジェクト] ウィンドウで、[次へ] をクリックし、[Finish] をクリックします。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 246127「[XADM] Exchange 2000 のアドレス一覧サービスのトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


レプリケーション エポックが変更されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン コントローラの NTDS Settings オブジェクトの ms-DS-ReplicationEpoch 属性が設定されているかどうかを判断します。

エポックは、ドメインが特定の名前を持つ期間です。新しいエポックは、ドメインが最初に作成されたとき、およびドメインの名前が変更されたときに始まります。

ms-DS-ReplicationEpoch 属性は、すべてのドメイン コントローラがレプリケートを行っているエポックに適用されます。Exchange Server アナライザ によって、この属性に値が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

一般に、ms-DS-ReplicationEpoch 属性に値が設定されている場合は、問題が発生したサーバーが存在するドメインの名前が変更されています。Microsoft Windows Server™ 2003 Standard Edition、Windows Server 2003 Enterprise Edition、および Windows Server 2003 Datacenter Edition では、管理者は Active Directory フォレスト構造を決定した後、フォレスト内のドメインの名前を変更できます。Windows® 2000 Server オペレーティング システムでは、フォレスト構造を決定した後に管理者が Active Directory フォレスト内のドメイン名を変更することはできません。

Active Directory フォレスト構造は、ドメインを作成する順序と、それらのドメインの階層名で決まります。最初にフォレストのルート ドメインを決定します。フォレストのルート ドメインの名前から、すべての子ドメインの識別名と既定の DNS 名が決まります。フォレストの他のツリーでも同様に名前を決定します。

ドメインの名前を変更すると、既存のドメイン ツリーの階層構造が変化します。たとえば、別の親を持つように子ドメインの名前を変更したり、新しいツリーのルート ドメインとなるように子ドメインの名前を変更することができます。どちらの場合も、既存のドメインの位置を変更して、新しいドメイン ツリー構造を作成します。

また、構造に影響を与えずに、ドメインの名前を変更することもできます。たとえば、ルート ドメインの名前を変更する場合は、このルート ドメイン以下のすべての子ドメインの名前を変更します。この場合は、新しいドメイン ツリー構造を作成していません。

Exchange 2000 Server または Exchange Server 5.5 を含むフォレストでは、ドメイン名の変更はサポートされません。Windows Server 2003 ドメイン名変更ツールは、Exchange 2000 Server サーバーまたは Exchange Server 5.5 サーバーを含まない Active Directory フォレストで、ドメイン名を変更するように設計されています。Windows Server 2003 ドメイン名変更ツールの制限は、次の理由によるものです。

  • ドメイン名の変更により、一部の Exchange 属性が影響を受ける。

  • Windows Server 2003 ドメイン名変更ツールには、これらの属性を修復する機能がない。

Exchange Server 2003 を含むフォレストでは、ドメイン名の変更がサポートされます。Exchange ドメイン名変更/属性修正ユーティリティ (XDR-fixup.exe) は、Exchange Server 2003 Server サーバーを含むドメインの名前を変更した後に、Exchange Server の属性を修復します。Exchange ドメイン名変更/属性修正ユーティリティは、Windows Server 2003 ドメイン名変更ツール (Rendom.exe) と併用できます。

Windows Server 2003 Active Directory ドメイン名変更ツールの詳細について、および Windows Server 2003 Active Directory ドメイン名変更ツールのダウンロードについては、「Windows Server 2003 Active Directory Domain Rename Tools」(http://go.microsoft.com/fwlink/?LinkId=40992) を参照してください (このサイトは英語の場合があります)。

ドメイン名を変更するには、Exchange ドメイン名変更/属性修正ユーティリティを実行する必要があります。Exchange ドメイン名変更/属性修正ユーティリティは、新しいドメイン名を反映するように、Exchange Server の Active Directory 属性を変更します。Exchange ドメイン名変更/属性修正ユーティリティは、Windows Server 2003 ドメイン名変更ツールを置き換えるものではありません。また、Windows Server 2003 ドメイン名変更ツールの機能を拡張するものでもありません。Windows Server 2003 ドメイン名変更ツールを実行するたびに、Exchange ドメイン名変更/属性修正ユーティリティを実行する必要があります。

ドメイン名を変更する処理の詳細、およびドメイン名の変更処理が Exchange Server に与える影響の詳細については、次のツールとドキュメントを参照してください。

  • 「Windows Server 2003 Active Directory Domain Rename Tools」(http://go.microsoft.com/fwlink/?LinkId=40992) (このサイトは英語の場合があります)

  • 『Understanding How Domain Rename Works』(http://go.microsoft.com/fwlink/?LinkId=41906) (このサイトは英語の場合があります)

  • 『Step-by-Step Guide to Implementing Domain Rename』(http://go.microsoft.com/fwlink/?LinkId=41359) (このサイトは英語の場合があります)

  • 『Microsoft Exchange Server 2003 Domain Rename Fixup (XDR-Fixup)』(http://go.microsoft.com/fwlink/?LinkId=34171) (このサイトは英語の場合があります)

  • 「Exchange and Domain Rename Operations」(http://go.microsoft.com/fwlink/?LinkId=41908) (このサイトは英語の場合があります)


OAB Version 2 のレプリカが見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-01-29

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Exchange_Public_Folder に対してクエリを実行し、HasLocalReplica の現在の値を判断します。オフライン アドレス一覧の OAB Version 2 インスタンスを表す HasLocalReplica の値が False に設定されていることが検出されると、エラーが表示されます。

オフライン アドレス一覧の OAB Version 2 インスタンスを表す HasLocalReplica が False に設定されている場合、オフライン アドレス一覧は正しく生成されません。その結果、Microsoft Outlook® 2002 以前のユーザーは、オフライン アドレス一覧をダウンロードできません。

この問題は、OAB Version 2 のレプリカを含むようにパブリック フォルダ ストアを構成していない場合に発生することがあります。既定では、オフライン アドレス帳は、そのアドレス帳がインストールされているサーバーのパブリック フォルダ ストアにコンテンツをレプリケートします。パブリック フォルダ ストアがオフライン アドレス帳のレプリケーション構成から削除されていると、上で説明した問題が発生します。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、[フォルダ] をクリックします。

  3. [パブリック フォルダ] を右クリックし、[システム フォルダの表示] をクリックします。

  4. [OFFLINE ADDRESS BOOK] オブジェクトをクリックして展開します。

  5. [OFFLINE ADDRESS BOOK] の下で、[o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] を右クリックし、[プロパティ] をクリックします。

  6. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳の適切なパブリック フォルダ ストアを入力します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] をクリックして展開します。

  9. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] の下にある [OAB Version 2] を右クリックし、[プロパティ] をクリックします。

  10. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳のための適切なパブリック ストアを入力します。

  11. [適用] をクリックし、[OK] をクリックします。

この問題の詳細については、Microsoft サポート技術情報の文書番号 286328「[XADM] オフライン アドレス帳が見つからず、Exchange 2000 で生成されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328) を参照してください。

オフライン アドレス帳一覧の生成に関する詳細については、オフライン アドレス帳一覧の生成の概要に関するページ (http://go.microsoft.com/fwlink/?LinkId=82242) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 を実行している最初のコンピュータを管理グループから正しく削除する方法の詳細については、Microsoft サポート技術情報の文書番号 822931「最初の Exchange 2003 Server コンピュータをサイトから削除する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931) を参照してください。


OAB Version 3a のレプリカが見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Exchange_Public_Folder に対してクエリを実行し、HasLocalReplica の現在の値を判断します。オフライン アドレス一覧の OAB Version 3a インスタンスで、HasLocalReplica の値が False に設定されていることが検出されると、エラーが表示されます。

オフライン アドレス一覧の OAB Version 3a インスタンスで HasLocalReplica が False に設定されていると、オフライン アドレス一覧が正しく生成されません。この結果 Microsoft Office Outlook® 2003 ユーザーは、オフライン アドレス一覧をダウンロードすることができません。

この問題は、OAB Version 3a のレプリカを含むようにパブリック フォルダ ストアを構成していない場合に発生することがあります。既定では、オフライン アドレス帳のコンテンツは、オフライン アドレス帳がインストールされているサーバーのパブリック フォルダ ストアにレプリケートされます。パブリック フォルダ ストアがオフライン アドレス帳のレプリケーション構成から削除されていると、上で説明した問題が発生します。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、[フォルダ] をクリックします。

  3. [パブリック フォルダ] を右クリックし、[システム フォルダの表示] をクリックします。

  4. [OFFLINE ADDRESS BOOK] オブジェクトをクリックして展開します。

  5. [OFFLINE ADDRESS BOOK] の下で、[o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] を右クリックし、[プロパティ] をクリックします。

  6. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳のための適切なパブリック ストアを入力します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] をクリックして展開します。

  9. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] の下にある [OAB Version 3a] を右クリックし、[プロパティ] をクリックします。

  10. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳のための適切なパブリック ストアを入力します。

  11. [適用] をクリックし、[OK] をクリックします。

この問題の詳細については、Microsoft サポート技術情報の文書番号 286328「[XADM] オフライン アドレス帳が見つからず、Exchange 2000 で生成されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328) を参照してください。

Exchange Server 2003 を実行している最初のコンピュータを管理グループから正しく削除する方法の詳細については、Microsoft サポート技術情報の文書番号 822931「最初の Exchange 2003 Server コンピュータをサイトから削除する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931) を参照してください。


ディレクトリ レプリケーション コネクタのスケジュール
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Active Directory コネクタ (ADC) 接続許可書オブジェクトの activationSchedule 属性にどのような値が設定されているかを判断します。activationSchedule 属性は、ADC 接続許可書が実行される頻度に対応します。値が 0 の場合、レプリケーション スケジュールは [しない] に設定されています。値が 1 の場合、レプリケーション スケジュールは [選択時間] に設定されています。値が 2 の場合、レプリケーション スケジュールは [常に] に設定されています。

また、Exchange Server アナライザは、Active Directory に対してもクエリを実行し、各 ADC 接続許可書オブジェクトの msExchServer2SearchFilter 属性の値を判断します。msExchServer2SearchFilter 属性は、ディレクトリの検索時に使用される検索フィルタを表わします。

Exchange Server アナライザによって、activationSchedule 属性が [選択時間] に設定されていること、レプリケーションの間隔が 6 時間より長く指定されていること、および msExchServer2SearchFilter 属性が受信者情報をレプリケートしていることが検出されると、警告が表示されます。

一般に、受信者用接続許可書のレプリケーション スケジュールは、常にレプリケートする ([常に]) ように設定することがベスト プラクティスです。場合によっては、接続許可書をそれ以外のスケジュールに設定すると、Exchange Server 5.5 サイトのメールボックスを Exchange 2000 Server または Exchange Server 2003 に移動した後に配信不能レポート (NDR) が生成されることがあります。

この警告を修正するには

  1. Active Directory コネクタ サービス MMC スナップインを開きます。

  2. [接続許可書] を開きます。

  3. 接続許可書のプロパティ ページで、[スケジュール] タブをクリックし、[常に] をクリックします。次に、[OK] をクリックします。

ADC の展開と接続許可書の構成の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。


RID FSMO サーバーの役割からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ドメイン名前付けコンテキストのインフラストラクチャ マスタについて fSMORoleOwner 属性の値を判断します。たとえば、contoso.com という名前のドメインでは、RID 操作マスタの fSMORoleOwner の属性は CN=RID Manager$, CN=System, DC=contoso, DC=com です。次に、Exchange Server アナライザは、現在その役割を保持しているドメイン コントローラの TCP ポート 389 に対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。このドメイン コントローラに接続できないと、エラーが表示されます。

RID マスタは、すべてのドメイン コントローラに相対 ID を割り当て、すべてのセキュリティ プリンシパルが一意の識別子を持つようにします。任意のドメイン コントローラで、新しいセキュリティ プリンシパル オブジェクト (ユーザー、グループ、またはコンピュータ) を作成できます。セキュリティ プリンシパル オブジェクトを作成すると、ドメイン コントローラによって、そのオブジェクトに一意のセキュリティ識別子 (SID) が関連付けられます。ドメインの SID には 4 つの要素があり、その 1 つがドメインの RID です。RID 操作マスタは、特定のドメイン内のすべてのドメイン コントローラからの RID プール要求を処理する役割を果たします。ドメイン内で RID マスタとして動作するドメイン コントローラは、任意の時点で 1 つだけ存在できます。

このエラーを修正するには

  1. エラーに示されたディレクトリ サーバーがオンラインになっており、組織内の Exchange サーバーからアクセスできることを確認します。

  2. このディレクトリ サーバーの使用が停止されている場合は、RID マスタの役割を別のドメイン コントローラに割り当てる必要があります。

RID 操作マスタの役割を、あるドメイン コントローラから別のドメイン コントローラに移す方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Server™ 2003 については、Microsoft サポート技術情報の文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows® 2000 Server については、Microsoft サポート技術情報の文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


スキーマ FSMO 役割が見つからない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、スキーマの FSMO (スキーマ名前付けコンテキストにおける fSMORoleOwner ) として指定されたドメイン コントローラを判断します。fSMORoleOwner 属性で指定されたドメイン コントローラがフォレストに存在しないことが検出されると、エラーが表示されます。

スキーマ名前付けコンテキスト (CN=Schema,CN=Configuration,DC=ドメイン名,DC=com) における fSMORoleOwner 属性は、フォレストのスキーマ マスタとなるドメイン コントローラを定義しています。スキーマ マスタ ドメイン コントローラは、スキーマに加えられるすべての更新および変更を制御します。フォレストのスキーマを更新するには、スキーマ マスタにアクセスできる必要があります。スキーマ マスタは、フォレスト全体で 1 つだけ置くことができます。

Active Directory フォレストには、必ずスキーマ マスタを定義する必要があります。スキーマ マスタ ドメイン コントローラがセットアップ時にオンラインになっていないと、スキーマの更新を行わない場合でも、Exchange 2000 Server セットアップと Exchange 2000 Server Service Pack セットアップを実行できません。スキーマ マスタとして指定されているドメイン コントローラがオフラインの場合は、オンラインに戻す必要があります。これは Exchange Server 2003 には当てはまりません。Exchange Server 2003 セットアップは、スキーマが拡張されていないと判断した場合のみスキーマ マスタにアクセスします。

このエラーを修正するには

  1. 指定されている Active Directory サーバーが物理的に存在していることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、スキーマ マスタの役割を別のドメイン コントローラに割り当てます。

スキーマ マスタの役割を別のドメイン コントローラに割り当てる方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 280178「[XADM] Exchange 2000 のインストール時にスキーマ マスタへのアクセスが必要となる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=280178)

  • Microsoft Windows Server™ 2003 については、Microsoft サポート技術情報の文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows® 2000 Server については、Microsoft サポート技術情報の文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


スキーマ FSMO 役割からの応答がない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、スキーマ名前付けコンテキストのスキーマ操作マスタについて、fSMORoleOwner 属性の値を判断します。たとえば、contoso.com という名前のドメインでは、スキーマ操作マスタの fSMORoleOwner の属性は CN=Schema,CN=System,DC=contoso,DC=com です。次に、Exchange Server アナライザは、現在その役割を保持しているドメイン コントローラの TCP ポート 389 に対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 接続を開こうと試みます。このドメイン コントローラに接続できないと、エラーが表示されます。

ディレクトリ スキーマへの書き込み操作を実行できるドメイン コントローラは、スキーマ マスタの役割を保持しているドメイン コントローラだけです。このスキーマの更新は、スキーマ マスタから、フォレストに含まれるその他すべてのドメイン コントローラにレプリケートされます。ドメインの数にかかわらずフォレストに存在するスキーマは 1 つだけなので、スキーマ マスタは、フォレスト単位での操作マスタの役割です。フォレストのスキーマを更新するには、スキーマ マスタにアクセスできる必要があります。スキーマ マスタは、フォレスト全体で 1 つだけ置くことができます。

このエラーを修正するには

  1. エラーに示されたディレクトリ サーバーがオンラインになっており、組織内の Exchange サーバーからアクセスできることを確認します。

  2. このディレクトリ サーバーが使用停止の状態にある場合は、スキーマ マスタの役割を別のドメイン コントローラに割り当てる必要があります。

スキーマ操作マスタの役割をあるドメイン コントローラから別のドメイン コントローラに転送することに関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Server™ 2003 については、文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows® 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


Secure Sockets Layer 証明書の有効期限切れが近づく
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバー システム内の Server Certificate オブジェクトに対してクエリを発行し、X509 証明書に関するさまざまなプロパティを取得します。Exchange Server アナライザは、見つかった各 SSL (Secure Sockets Layer) 証明書の ExpirationDate 属性を評価し、その証明書の有効期限を識別します。

注 :
サーバーは、SSL プロトコルを実行するときにサーバー証明書を持っている必要があります。サーバー証明書には、Web サイトの名前が格納されています。ブラウザは、Web サイトの名前が、入力した名前と一致することを確認します。たとえば、https://www.example.com のような Web サイトがある場合、証明書の名前は www.example.com である必要があります。

ExpirationDate の値が 3 ～ 20 日後の日付の場合、Exchange Server アナライザが警告を表示します。ExpirationDate の値が 3 日後より前の日付の場合、Exchange Server アナライザはエラーを表示します。

証明書の有効期限が切れると、このメッセージに示されている URL への SSL 接続に失敗します。同様に、その URL を使用する RPC over HTTP 接続および Exchange Server ActiveSync 接続も失敗します。

証明書の有効期限に関するこの警告またはエラーの問題を解決するには、このメッセージに示された証明書を更新します。証明書を更新するために実行する必要のある手順は、使用している証明機関に応じて異なります。

詳細情報

SSL および Exchange Server の仮想サーバーで証明書を使用する方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server 2003 の仮想サーバーで証明書を使用する方法については、Microsoft サポート技術情報の文書番号 823024「Exchange Server 2003 の仮想サーバーで証明書を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823024) を参照してください。

  • SSL を使用する方法およびサーバー証明書を取得してインストールする方法については、Exchange Server 2003 のクライアント アクセス ガイド (http://go.microsoft.com/fwlink/?LinkId=47568) で、Exchange Server 2003 にクライアント アクセスを構成する方法についての章を参照してください (このサイトは英語の場合があります)。

  • SSL の使用方法および Exchange Server 2007 用にサーバー証明書を入手してインストールする方法の詳細については、Outlook Anywhere 用に SSL を構成する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80875) を参照してください (このサイトは英語の場合があります)。


サーバー コンテナが存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対して、現在の管理グループ内で検出された各 Routing Group オブジェクトの distingushedName 属性値に対してクエリを実行します。

次に、Exchange Server アナライザは Active Directory に対してクエリを実行し、現在の管理グループに [サーバー] コンテナが存在するかどうかを判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • 現在の管理グループに 1 つ以上のルーティング グループが含まれている。

  • [サーバー] コンテナが存在しない。

このエラーは、管理グループにサーバーがインストールされていないため、Exchange 組織内のサーバー間でルーティング情報が動的に伝達されない可能性があることを示します。

このエラーを修正するには、Exchange 組織がネイティブ モードになっていることを確認し、次の手順に従います。

解決手順

  1. 新しい管理グループを作成します。

  2. 新しい管理グループ内に、新しい [ルーティング グループ] コンテナを作成します。

  3. 既存のルーティング グループを、古い [ルーティング グループ] コンテナから新しいコンテナにドラッグします。

  4. すべての Exchange サービスを再開します。

このエラーの詳細については、マイクロソフト サポート技術情報の文書番号 318491 の、XADM: Exchange 2000 組織でルーティング情報が伝達されない現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=318491) を参照してください。


グローバル カタログ サーバーに存在しないサービス プリンシパル名
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-05-12

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスのグローバル カタログ サーバーに対してクエリを実行し、exchangeAB と HOST リソースにおける servicePrincipalName 属性の完全修飾ドメイン名 (FQDN) と NetBIOS 名に対して返される値を検出します。

以下の条件のいずれかに当てはまる場合は、エラーが表示されます。

  • exchangeAB リソースの servicePrincipalName 属性 に、予期される FQDN 名または NetBIOS 名の値のいずれかが不足している場合。

  • HOST Exchange リソースの servicePrincipalName 属性に、予期される FQDN 名または NetBIOS 名の値のいずれかが不足している場合。

サービス プリンシパル名 (SPN) はサービスのインスタンスを識別するための一意の名前で、サービス インスタンスが動作しているログオン アカウントに関連付けられます。Kerberos 認証は、SPN が適切に設定されていない Exchange サービスでは利用できません。

  • Microsoft Outlook® 2003 以降のクライアントに Active Directory 認証問題が発生する場合は、exchangeAB リソースに有効な SPN が設定されていないことが原因になっている場合があります。

  • サーバー間で認証問題が発生する場合は、HOST リソースに有効な SPN が設定されていないことが原因になっている場合があります。

この問題を解決するには、以下の手順に従い、servicePrincipalName 属性に対して不足している値を追加します。

SETSPN.exe ツールを使用して、不足している値を SPN に追加する

  1. Setspn.exe ツールをインストールします。Setspn.exe ツールを取得するには、"Windows 2000 リソース キット ツール :Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103) を参照してください (このサイトは英語の場合があります)。

    Windows Server 2003 バージョンの Setspn.exe コマンドライン ツールは、Windows Server 2003 CD に格納されている Windows Server 2003 のサポート ツールに含まれています。Server 2003 サポート ツールをインストールする場合は、Support/Tools フォルダの Suptools.msi ファイルをダブルクリックしてください。

  2. SETSPN.EXE Setspn_d.txt ファイルのガイダンスに従って、不足している値を Exchange サーバーの Active Directory オブジェクトに追加します。以下の例は、仮想 SMTP サーバーの SPN に対する FQDN 値の追加を示しています。

    • コマンド プロンプトを開始し、Setspn.exe をインストールしたディレクトリに移動します。

    • コマンド プロンプトで、以下のコマンドを入力します。

      setspn.exe-a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      注 :
      mail.yourdomain.com を SMTP 仮想サーバーの FQDN に置き換え、YOURSERVERNAME を Exchange サーバー名に置き換えます。
      Enter キーを押します。


管理グループ用のサイト フォルダ サーバー パブリック フォルダ ストアが管理グループ内に存在しない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストアの distinguishedName の値を判断します。さらに、Active Directory に対してもクエリを実行し、各管理グループの siteFolderServer 属性および msExchAdminGroupMode 属性の値を判断します。siteFolderServer 属性は、サイト フォルダをホストする役割を持つサーバーの名前を表します (通常は、サイトまたは管理グループ内の最初のサーバー)。msExchAdminGroupMode 属性は、以下に示す管理グループのモードを表します。

  • Exchange Server 5.5 のみ

  • Exchange Server 5.5、Exchange 2000 Server、および Exchange Server 2003 Server の混在モード

  • Exchange 2000 Server または Exchange Server 2003 のネイティブ モード

管理グループがネイティブ モードになく、siteFolderServer の値がパブリック フォルダ ストアの distinguishedName の値と一致せず、さらに siteFolderServer 属性の値に "DEL:" の文字列が含まれていないことが検出されると、警告が表示されます。

既定では、サイト フォルダ サーバーは管理グループ内にインストールされている最初のサーバーです。このサーバーのパブリック フォルダ ストアは、その管理グループ用の Free/Busy フォルダとオフライン アドレス帳フォルダの既定の場所になります。これらのフォルダを別のサーバーにレプリケートしないでサイト フォルダ サーバーを削除するか使用を停止し、そのサーバーをオフライン アドレス帳サーバーとして指定すると、Outlook でオフライン アドレス帳データや空き時間情報データに関する問題が発生します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

この警告を修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. 以下を順に展開し、サイト フォルダ サーバーとして指定するパブリック フォルダ インフォメーション ストアを見つけます。[CN=<パブリック フォルダ ストア名>]、[CN=<ストレージ グループ名>]、[CN=InformationStore]、[CN=<サーバー名>]、[CN=Servers]、[CN=<管理グループ名>]、[CN=Administrative Groups]、[CN=<組織名>]、[CN=Microsoft Exchange]、[CN=Services]、[CN=Configuration,DC=<ドメイン名>,DC=com]

  3. 右側のペインで、[CN=<パブリック フォルダ ストア名>] を右クリックし、[プロパティ] を選択します。

  4. [Attributes] 一覧で、下にスクロールして distinguishedName 属性をクリックします。

  5. [Edit] をクリックし、属性全体をクリップボードにコピーします。

  6. [Configuration] コンテナを展開し、[CN=Administrative Groups]、[CN=<組織名>]、[CN=Microsoft Exchange]、[CN=Services]、[CN=Configuration,DC=<ドメイン名>,DC=com] の順に展開します。

  7. 変更する管理グループを右クリックし、[プロパティ] を選択します。

  8. [Attributes] 一覧で、下にスクロールして siteFolderServer 属性をクリックします。

  9. [Edit] をクリックし、distinguishedName 属性の値を [Value] ボックスに貼り付けます。

  10. [Value] ボックスの内容をダブルクリックして貼り付けが正しく実行されたことを確認し、[OK] をクリックして変更を保存します。

  11. [OK] をクリックして、管理グループのプロパティ ダイアログボックスを閉じます。

  12. ADSI Edit を終了し、サイト内のすべての Exchange Server 上にある Microsoft Exchange Server Information Store サービスを再開して、変更を有効にします。

システム フォルダの再作成とサイト フォルダ サーバーの再設定の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 275171「[XADM] Exchange 2000 Server でシステム フォルダをリセットする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=275171)

  • 文書番号 284200「[XADM] Schedule+ Free/Busy システム フォルダが削除される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=284200)

LDP ツールの使用方法の詳細については、マイクロソフト サポート技術情報の記事 260745 の、[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更することに関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server 2003 ヘルプの「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。


オフライン アドレス帳が使用するサイト フォルダ サーバーのパブリック フォルダ ストアが検出されなかった
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2007-02-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、すべての Exchange パブリック フォルダ ストア (objectClass が objectClass=msExchPublicMDB であるストア) について、siteFolderServer 属性の値を判断します。siteFolderServer 属性は、オフライン アドレス帳サーバーのために使用されるパブリック フォルダ ストアを表します。

Exchange Server アナライザによって、属性に 1 つのサーバーも示されていない、示されたサーバーが停止している、または示されたサーバーが存在しないと判断されると、警告が表示されます。siteFolderServer 属性に文字列 "DEL" が含まれていると、Exchange Server アナライザはエラー メッセージを表示します。

既定では、Exchange Server 2003 は、オフライン アドレス帳ファイルをサイト フォルダ サーバー (管理グループにインストールされている最初のサーバー) に作成します。異なるサーバーをオフライン アドレス帳サーバーとして動作するように指定した場合、この属性には、管理グループの実際のサイト フォルダ サーバー上にあるパブリック フォルダ ストアではなく、新しいオフライン アドレス帳サーバー上にあるパブリック フォルダ ストアが示されます。

Exchange Server 2003 がオフライン アドレス帳ファイルを作成する場合は、ファイルをメール メッセージに添付し、そのメッセージを特殊なパブリック フォルダに格納します。Microsoft Office Outlook® 2003 がそのパブリック フォルダからメッセージを取得し、添付ファイルをダウンロードします。

Exchange Server 2003 では、オフライン アドレス帳のメッセージは、OFFLINE ADDRESS BOOK フォルダのサブフォルダに格納されます。このフォルダは、既定の [パブリック フォルダ] ツリーにあるシステム フォルダの 1 つです。このフォルダには、トポロジ内にあるそれぞれの管理グループまたはサイトに対応するサブフォルダが含まれています。既定では、特定の管理グループ フォルダの内容のレプリカは、管理グループにインストールされた最初のサーバー (サイト フォルダ サーバー) にあります。

Exchange 組織が Exchange Server 2007 で、下位レベル (Outlook 2003 またはそれ以前) のクライアントがない場合は、この警告またはエラーを無視できます。Exchange Server 2007 組織で、Outlook 2003 またはそれ以前を実行するクライアントをホストしている場合は、次の手順に従って、オフライン アドレス帳ファイルのパブリック フォルダ配布を有効にします。パブリック フォルダの配布は、Outlook 2003 またはそれ以前を実行する、オフラインまたはダイヤルアップ接続で動作するクライアントから OAB へのアクセスに使用する配布方法です。

Exchange Server 2003 の場合にこの警告を修正するには

  1. サーバーが存在しないことがわかっている場合は、Exchange システム マネージャで、[サーバー] の下のサーバーを展開し、ストレージ グループを展開します。次に、[パブリック フォルダ ストア] をクリックします。右側のペインをクリックしてストアが実行されていることを確認します。

  2. 新しいオフライン アドレス帳サーバーを指定するにには、[受信者] の [オフライン アドレス一覧] をクリックします。次に、右側のペインで [既定のオフライン アドレス一覧] (または、このメッセージを発生させた別のオフライン アドレス一覧) をクリックします。

    オフライン アドレス帳を使用しない場合は、[既定のオフライン アドレス帳] を右クリックし、[削除] をクリックします。削除しない場合は、残りの手順に従ってスケジュールを設定します。

  3. [既定のオフライン アドレス帳] を右クリックし、[プロパティ] をクリックします。

  4. [全般] タブで、[オフライン アドレス帳サーバー] の [参照] をクリックしてサーバーを選択します。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。

    1. オフライン アドレス帳のパブリック フォルダの配布を有効にするには、[配布] タブの [パブリック フォルダの配布を有効にする] をクリックします。

    2. [OK] をクリックし、変更を保存します。

  5. 新しいオフライン アドレス帳サーバーを指定するには、アクション ペインの [移動] をクリックして、オフライン アドレス帳の移動ウィザードを起動します。このウィザードを使用すると、オフライン アドレス帳の生成を別のサーバーに移動できます。既存のオフライン アドレス帳ファイルを指定のサーバーにコピーすることもできます。

Exchange Management Shell を使用して、オフライン アドレス帳ファイルのパブリック フォルダ配布を有効にするには

  • 次のコマンドを実行します。

    コードのコピー
    Set-OfflineAddressBook -Identity <OAB> -PublicFolderDistributionEnabled $true

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。

    たとえば、既定のオフライン アドレス帳のパブリック フォルダ配布を有効にするには、次のように入力します。
コードのコピー
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -PublicFolderDistributionEnabled $true

Exchange Management Shell を使用して、オフライン アドレス帳の生成をホストするサーバーを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Server> には、選択した処理を実行する Exchange サーバーを指定します。

    たとえば、オフライン アドレス帳の生成を SERVER01 に移動するには、次のように入力します。
コードのコピー
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink/?LinkId =79247) (英語) を参照してください。


SiteName がハードコードされている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange サーバー上に SiteName レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\SiteName

SiteName レジストリ値が存在することが検出されると、警告が表示されます。

この警告は、Active Directory® ディレクトリ サービスのサイト メンバシップが、Microsoft Windows® オペレーティング システムを実行しているこのコンピュータ上でハードコードされていることを示しています。この構成は、Exchange Server にはお勧めできません。

Windows サイトをハードコードすると、Microsoft Exchange System Attendant サービスのエラーや、一般的な Exchange Server の障害が発生することがあります。SiteName レジストリ値の削除を検討する必要があります。SiteName レジストリ値を削除すると、Windows は適切な Active Directory サイトに自動的に参加します。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
SiteName レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

  3. 右側のペインで、SiteName レジストリ値を見つけて削除します。

  4. レジストリ エディタを終了し、サーバーを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

SiteName レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 322834「XADM: イベント 1005 をは、System Attendant は起動しません。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322834) を参照してください。


Exchange 組織内に 900 を超える管理グループが存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange 組織内に存在する管理グループの数を判断します。900 を超える管理グループが検出されると、警告メッセージが表示されます。

1 つの Exchange オブジェクトの種類について、インスタンスの数は最大でも 900 にすることをお勧めします。これは、Active Directory では、特定の要求に対して返す最大ページ サイズの既定値が 1,000 に設定されているためです。つまり、あるオブジェクトに対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求が実行され、Active Directory 内でそのオブジェクトのインスタンスの数が 1,000 を超えている場合、最大ページ サイズを超過するために結果が返されなくなります。

Exchange では、さまざまなプロセスが特定のオブジェクトの種類のインスタンス化を要求します。たとえば、Exchange システム マネージャは Active Directory に LDAP 要求を発行して、Exchange 組織内にあるすべての管理グループのリスト ビューを作成します。1,000 を超える管理グループが存在すると、Active Directory は結果を何も返しません。その結果、Exchange システム マネージャにエラーが表示され、管理グループは表示されません。

Active Directory の最大ページ サイズの値を増やすことはできますが、Exchange では推奨されていないか、またはサポートされていません。最大ページ サイズの値を増やすと、Exchange 環境で異常な動作が発生したり、処理が失敗したりする場合がありました。

Exchange の 1 つのオブジェクトの種類について、オブジェクトの種類を 900 以下に維持することが推奨されますが、最大 1,000 まではサポートされています。

この問題を修正するには、管理グループの統合を検討します。

Exchange のサイトや管理グループの統合の詳細については、次のサイトを参照してください。

  • マイクロソフトにおける Exchange Server 2003 統合ソリューションの全世界サイトへの展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=33531) (このサイトは英語の場合があります)


Exchange 組織内に 900 を超える Exchange サーバーが存在する
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-03-30

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer の objectCategory を保持しているディレクトリ内のオブジェクトの数を取得します。この数は、Active Directory 内に存在する Exchange Server コンピュータの数を表します。900 を超える Exchange Server コンピュータが検出されると、警告が表示されます。

1 つの Exchange オブジェクトの種類について、使用するインスタンスの数は最大でも 900 にすることをお勧めします。これは、Active Directory では、特定の要求に対して返す最大ページ サイズの既定値が 1,000 に設定されているためです。つまり、あるオブジェクトに対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求が実行され、Active Directory 内でそのオブジェクトのインスタンスの数が 1,000 を超えている場合、最大ページ サイズを超過するために結果が返されなくなります。

Exchange Server では、さまざまなプロセスが特定のオブジェクトの種類のインスタンス化を要求します。たとえば、Exchange システム マネージャは Active Directory に LDAP 要求を発行して、Exchange 組織内にあるすべての Exchange サーバーのリスト ビューを作成します。1,000 を超える Exchange サーバーが存在すると、Active Directory は結果を何も返しません。その結果、Exchange システム マネージャにエラーが表示され、Exchange Server コンピュータは表示されません。

Active Directory の最大ページ サイズの値を増やすことはできますが、Exchange では推奨されていないか、またはサポートされていません。最大ページ サイズの値を増やすと、Exchange 環境で異常な動作が発生したり、処理が失敗したりする場合がありました。

Exchange Server の 1 つのオブジェクトの種類について、オブジェクトの種類を 900 以下に維持することが推奨されますが、最大 1,000 まではサポートされています。

この警告を修正するには

  1. 組織内にある Exchange サーバーの統合を検討します。

  2. Active Directory 内に、切り離された Exchange Server コンピュータがないかどうかを調べ、あった場合は Active Directory から削除します。

Exchange サーバーの統合の詳細については、Exchange Server 2003 を使用したサーバーの統合についてのページ (http://go.microsoft.com/fwlink/?linkid=47586) を参照してください (このサイトは英語の場合があります)。


組織レベルで委任されている管理者が 10 人を超えている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange 管理者または Exchange 管理者 (完全) のどちらかとしてのアクセス許可を持つユーザーの数を判断します。Exchange Server アナライザは、msExchAdmins 属性に列挙されているエントリの数を数えます。この属性は、組織内のすべての Exchange 管理者へのリンクを、対応するアクセス許可と共に表します。Exchange Server アナライザによって、Exchange 管理者または Exchange 管理者 (完全) のアクセス許可を持つユーザーが 10 人を超えていることが検出されると、警告が表示されます。

msExchAdmins は、Exchange ルート組織コンテナの、複数の値を持つ属性です。この属性には、委任された Exchange アクセス許可を持つユーザー アカウントを表すセキュリティ識別子 (SID) の一覧が含まれています。

Exchange 組織に対する書き込みアクセス権を持つユーザーの数を制限するのがベスト プラクティスです。組織レベルの Exchange 管理者および Exchange 管理者 (完全) の数を減らすことを検討してください。メッセージング インフラストラクチャの要件に対応した管理の役割を再検討することにより、これらのユーザーの多くを組織レベルでは Exchange 管理者 (参照のみ可) に変更する一方で、管理グループ レベルで Exchange 管理者の役割を委任することができる可能性があります。

この警告を修正するには

  1. Exchange 管理者 または Exchange 管理者 (完全) のアクセス許可を持つユーザーの数を減らすことを検討します。

  2. 組織内の Exchange Server アクセス許可の監査を実施し、それらのアクセス許可が適切かどうかを確認することを検討します。

Exchange におけるアクセス許可の計画および構成の詳細については、以下を参照してください。

  • Exchange Server 2003 での Active Directory アクセス許可の操作についてのドキュメント (http://go.microsoft.com/fwlink/?LinkId=47592) (英語)

  • Microsoft Exchange Server 2007 の操作の、アクセス許可の構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=78432)

  • Microsoft Exchange Server 2007 の計画とアーキテクチャの、Active Directory の計画の、アクセス許可に関する考慮事項についてのページ (http://go.microsoft.com/fwlink/?LinkId=78433)

Exchange Server 2003 における管理の役割の詳細については、Microsoft サポート技術情報の文書番号 823018「管理ロールの Exchange 2003 での Exchange 権限の概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823018) を参照してください。

Exchange 2000 Server における管理の役割の詳細については、マイクロソフト サポート技術情報の記事 289811 の、[XGEN] Exchange 2000 の役割のアクセス許可に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=289811) を参照してください。


接続許可書の設定で、照合が実行されなかった場合に無効なアカウントが作成されるように設定されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行して、各接続許可書オブジェクトの msExchServer1AlwaysCreateAs 属性の値を判断します。msExchServer1AlwaysCreateAs 属性が 1 に設定されていないと判断されると、警告が表示されます。

msExchServer1AlwaysCreateAs 属性は、X.500 オブジェクトが Active Directory と同期する方法を決定します。この属性値が 0 の場合は、Microsoft Windows® の連絡先を作成するように接続許可書が構成されています。この属性値が 1 の場合は、Active Directory 内に無効な Windows ユーザー アカウントを作成するように接続許可書が構成されています。この属性値が 2 の場合は、Windows ユーザー アカウントを新たに作成するように接続許可書が構成されています。

Exchange Server 5.5 と Active Directory を共存させる必要があり、さらに Exchange Server 2003 への完全移行が予定されている状況においては、Active Directory コネクタ (ADC) による無効な Windows ユーザー アカウントの作成が重要であるという理由から、Exchange Server アナライザは警告を発行します。この無効な Windows ユーザー アカウントは、"メールボックスが有効" です。つまり、Exchange Server 5.5 コンピュータ上に存在するメールボックスに論理的に接続されています。この無効な Windows アカウントとなるユーザー オブジェクトが、最終的にパブリック フォルダ、および Active Directory 内のその他のセキュリティで保護されたオブジェクトにアクセスできるようにするには、無効な Windows ユーザー アカウントを作成しておくことが必要です。

ADC ユーザー インターフェイスには、Exchange Server 5.5 のメールボックスに対して一致するオブジェクトが Active Directory 内に見つからなかった場合に新しいオブジェクトを作成するための 3 つのオプションが用意されています。これらのオプションは、接続許可書のプロパティの [詳細設定] タブにあります。各オプションの内容は以下のとおりです。

  • [Windows の連絡先を作成] - Contact オブジェクトはセキュリティ コンテキストを持たないため、このオプションはお勧めできません。

  • [新しい Windows ユーザー アカウントを作成] - 作成される新しいアカウントは新規の SID を持つことになり、したがって移行時に Microsoft Windows NT® Server 4.0 ユーザー アカウントの SID 履歴がこの新しいアカウントに持ち越されない (SID が異なってしまう) ため、このオプションはお勧めできません。

  • [無効な Windows ユーザー アカウントを作成] - 完全移行が完了するまで、リソースへのアクセスを維持したまま Windows NT Server 4.0 ユーザーの共存が可能なため、このオプションを使用することをお勧めします。

この警告を修正するには

  1. Active Directory 受信者用接続許可書を構成して、メールボックスが有効になっている、無効な Windows ユーザー アカウントを作成します。

  2. Active Directory 移行ツールを使用します。このツールは、Windows NT Server 4.0 ユーザー アカウントを Active Directory に移し、有効な Windows アカウントを作成します。作成した有効な Windows アカウントの SID は、ADC で作成した無効な Windows アカウントの SID と同じです。

  3. Active Directory クリーンアップ ウィザード (ADClean) を使用します。このウィザードは、Active Directory 移行ツールで作成したアカウントの情報を ADC で作成したアカウントに結合します。

Active Directory コネクタの受信者用接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 303180「[XADM] 管理グループが混在する場合の Active Directory コネクタ接続許可書の要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 文書番号 296260「[XGEN] Exchange Server 5.5 ユーザーに対する双方向のユーザー接続許可書を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052kbid=303180&kbid=296260)

  • Active Directory クリーンアップ ウィザードの詳細については、Microsoft サポート技術情報の次の文書を参照してください。

  • 文書番号 270652「Active Directory アカウント クリーンアップ ウィザードの使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270652)

  • Active Directory 移行ツールの詳細については、Microsoft サポート技術情報の次の文書を参照してください。

  • 文書番号 260871「Windows NT 4.0 から Windows 2000 へ移行するために ADMT をセットアップする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260871)


接続許可書が Exchange からの一方向の接続許可書になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行して、各接続許可書オブジェクトの msExchSynchronizationDirection 属性の値を判断します。msExchSynchronizationDirection 属性は、ディレクトリを同期させる方向を表します。この属性が 2 に設定されていると、警告が表示されます。

msExchSynchronizationDirection 属性の値は、0 または 2 になります。この属性が 0 に設定されている場合は、双方向の接続許可書であることを示します。この属性が 2 に設定されている場合は、Exchange Server コンピュータからの一方向の接続許可書であることを示します。

ベスト プラクティスとしては、双方向の接続許可書を使用することをお勧めします。混在モードの Exchange 環境 (Exchange Server 5.5 が Exchange 2000 Server または Exchange Server 2003 と共存する環境) では、双方向の接続許可書が必要です。

この警告を修正するには

  1. 既存の一方向の接続許可書を削除します。

  2. 置き換え用の双方向の接続許可書を作成します。

Active Directory コネクタ (ADC) の接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 303180「[XADM] 管理グループが混在する場合の Active Directory コネクタ接続許可書の要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 文書番号 317721「[XADM] ADC 接続許可書を一方向の接続許可書から双方向の接続許可書に変更すると Exchange Server 5.5 メールボックス所有者権限が削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


接続許可書が Windows からの一方向の接続許可書になっている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行して、各接続許可書オブジェクトの msExchSynchronizationDirection 属性の値を判断します。msExchSynchronizationDirection 属性は、ディレクトリを同期させる方向を表します。この属性が 1 に設定されていると、警告が表示されます。

msExchSynchronizationDirection 属性の値は、0、1、2 のいずれかです。この値が 0 の場合は双方向の接続許可書を示し、1 の場合は Active Directory からの一方向の接続許可書を示し、2 の場合は Exchange Server コンピュータからの一方向の接続許可書を示します。

ベスト プラクティスとしては、双方向の接続許可書を使用することをお勧めします。混在モードの Exchange 環境 (Exchange Server 5.5 が Exchange 2000 Server または Exchange Server 2003 と共存する環境) では、双方向の接続許可書が必要です。

この警告を修正するには

  1. 既存の一方向の接続許可書を削除します。

  2. 置き換え用の双方向の接続許可書を作成します。

Active Directory コネクタ (ADC) の接続許可書の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823601「Active Directory コネクタの組織全体への要件と影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823601)

  • 文書番号 303180「[XADM] 管理グループが混在する場合の Active Directory コネクタ接続許可書の要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=303180)

  • 文書番号 317721「[XADM] ADC 接続許可書を一方向の接続許可書から双方向の接続許可書に変更すると Exchange Server 5.5 メールボックス所有者権限が削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317721)


Exchange と Active Directory のタイムスタンプの差が 5 分を超えている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_UTCTime Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Exchange サーバーの日付と時刻を判断します。また、Exchange Server アナライザは既定のドメイン コントローラ上の現在の日付と時刻も取得します。Exchange Server アナライザによって、2 つのサーバー間に 5 分を超える差があることが検出されると、エラーが表示されます。

Microsoft Windows 2000 Server と Windows Server™ 2003 は、Windows Time サービスを使用して、Windows ベースのネットワーク上で動作しているコンピュータの日付と時刻を同期させます。Windows 2000 Server および Windows Server 2003 では、既定の認証プロトコルの認証チケット生成プロセスの一部としてワークステーションの時刻が使用されるため、時刻の同期がきわめて重要になります。既定の認証プロトコルは、MIT Kerberos Version 5 です。

Active Directory® ディレクトリ サービス ドメイン内の Windows ベースのサーバーはすべて、その Windows Time サービスが、ドメイン コントローラで使用可能な Windows Time サービスを使用して自動的に構成されます。Windows Time サービスは、そのドメイン内のドメイン コントローラを信頼できるタイム ソースとして構成し、定期的に自身の時刻をこのソースと同期させます。

このエラーを修正するには、Exchange サーバーのクロックをディレクトリ サーバーと同期させます。

Active Directory ドメイン内のサーバーでクロックを同期させるには

  1. コマンド プロンプトを開きます。

  2. 「w32tm /resync」と入力し、Enter キーを押します。

このエラーが引き続き発生する場合や、組織内の多数のコンピュータでこのエラーが発生する場合は、Windows Time サービスが Active Directory フォレスト内でどのように展開および構成されているかを確認してください。Windows タイム サービスの詳細については、「Windows Time Service Technical Reference」(http://go.microsoft.com/fwlink/?LinkId=40648) を参照してください (このサイトは英語の場合があります)。

Exchange フロントエンド サーバーが Active Directory の時刻と同期していない場合は、クライアントが Microsoft Office Outlook® Web Access に接続しようとすると "HTTP 500 内部サーバー" エラーが表示されることがあります。この状況の詳細については、Microsoft サポート技術情報の文書番号 841546「"HTTP 500 サーバー内部 error" エラーが Exchange 2000 Outlook Web Access で発生する既知の問題により」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841546) を参照してください。


Active Directory コネクタ サーバーと Active Directory のタイムスタンプの差が 5 分を超えている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_UTCTime Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Active Directory コネクタ (ADC) サーバーの日付と時刻を判断します。また、Exchange Server アナライザは既定のドメイン コントローラ上の現在の日付と時刻も取得します。Exchange Server アナライザによって、2 つのサーバー間に 5 分を超える差があることが検出されると、エラーが表示されます。

Microsoft Windows 2000 Server と Windows Server™ 2003 は、Windows Time サービスを使用して、Windows ベースのネットワーク上で動作しているコンピュータの日付と時刻を同期させます。Windows 2000 Server および Windows Server 2003 では、既定の認証プロトコルで認証チケットを生成するプロセスの一部としてワークステーションの時刻が使用されるため、時刻の同期がきわめて重要になります。既定の認証プロトコルは、MIT Kerberos Version 5 です。

Windows タイム サービスは、Active Directory® ディレクトリ サービス ドメインのすべての Windows サーバーに対し、ドメイン コントローラで利用可能な Windows タイム サービスを使用して自動的に自身を構成します。Windows Time サービスは、そのドメイン内のドメイン コントローラを信頼できるタイム ソースとして構成し、定期的に自身の時刻をこのソースと同期させます。

このエラーを修正するには、ADC サーバーのクロックをディレクトリ サーバーと同期させます。

Windows 2000 Server または Windows Server 2003 ドメインでサーバーの時刻を同期するには

  1. コマンド プロンプトを開きます。

  2. 「w32tm /resync」と入力し、Enter キーを押します。

このエラーが引き続き発生する場合や、組織内の多数のコンピュータでこのエラーが発生する場合は、Windows Time サービスが Active Directory フォレスト内でどのように展開および構成されているかを確認してください。Windows タイム サービスの詳細については、『Windows Time Service Technical Reference』(http://go.microsoft.com/fwlink/?LinkId=40648) を参照してください (このサイトは英語の場合があります)。


実行されている Windows Server 2003 が製品版 (最終ビルド) ではない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange 組織の Active Directory コネクタ (ADC) サーバーにある Version キーの値を判断します。また、Exchange Server アナライザは次のレジストリ エントリを調べて、ADC サーバーで実行されている Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

Exchange Server アナライザにより、CurrentVersion の 2 番目のインスタンスについて値が 5.2 であり、かつ Version 値が 5.2.3790 ではないことが検出されると、エラーが表示されます。

CurrentVersion 値が 5.2 の場合は、そのコンピュータが Windows Server 2003 オペレーティング システムを実行していることを示します。製品版の Windows Server 2003 オペレーティング システムは、すべて Version 値が 5.2.3790 です。Version キーの値がこれ以外である場合は、プレリリース版の Windows Server 2003 が使用されています。

TAP (Technology Adoption Program)、または Microsoft が提供する同様のプログラムに参加しているお客様以外が、プレリリース版のソフトウェアを運用環境で使用することはお勧めしません。また、Microsoft ではこのような使用のサポートを提供していません。

このエラーを修正するには

  1. ドメイン コントローラ、グローバル カタログ サーバー、ADC サーバー、および Exchange Server コンピュータを含むすべての Exchange インフラストラクチャ サーバーを、最新の製品版ソフトウェアにアップグレードします。

  2. アップグレード オプションが利用可能であるかサポートされている場合、オペレーティング システムを再構築し、Exchange Server の設定とデータを復元します。

ドメイン コントローラ、グローバル カタログ サーバー、ADC サーバー、および Exchange Server コンピュータを含むすべての Exchange インフラストラクチャ サーバーを、最新の製品版ソフトウェアにアップグレードします。

Windows Server 2003 ソフトウェア更新プログラムの詳細については、「Windows Server 2003 Software Updates」(http://go.microsoft.com/fwlink/?LinkId=33760) を参照してください (このサイトは英語の場合があります)。


Windows Server 2003 のプレリリース版ソフトウェアが実行されている
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスを調べて、ServicePackMajorVersion キーの値を判断します。また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Windows のバージョンを確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の 2 番目のインスタンスの値が 5.2 であり、かつ ServicePackMajorVersion の値が 1 より大きいことが検出されると、警告メッセージが表示されます。

CurrentVersion の値が 5.2 の場合は、そのコンピュータが Microsoft Windows Server™ 2003 オペレーティング システムを実行していることを示します。ServicePackMajorVersion の値が 1 より大きい場合は、Service Pack 1 (SP1) より後の Service Pack がインストールされていることを示します。Windows Server 2003 用にリリースされた Service Pack は SP 1 だけであるため、インストールされている Windows Server 2003 Service Pack 2 以降はすべて、プレリリース版ソフトウェアです。

TAP (Technology Adoption Program) または Microsoft が支援する類似のプログラムに参加している場合を除き、運用環境ではプレリリース版ソフトウェアを実行しないようにすることをお勧めします。

この警告を修正するには

  1. インストールされているすべてのプレリリース版ソフトウェアをアンインストールします。

  2. アンインストール オプションが使用できる場合は、オペレーティング システムを再構築して、Exchange Server の設定とデータを復元します。

Windows Server 2003 ソフトウェア更新プログラムの詳細については、「Windows Server 2003 Software Updates」(http://go.microsoft.com/fwlink/?LinkId=33760) を参照してください (このサイトは英語の場合があります)。


Windows 2000 Server で Service Pack 4 が実行されていない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスを調べて、ServicePackMajorVersion キーの値を判断します。また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

対象のシステムで Windows 2000 Server オペレーティング システムは実行されているが、Windows 2000 Server の Service Pack 4 が実行されていないと判断されると、警告が表示されます。

ベスト プラクティスとして、Exchange を展開した環境内に存在するすべてのソフトウェアに最新の Service Pack をインストールすることをお勧めします。

この警告を修正するには

  1. Windows 2000 Server オペレーティング システムを実行しているすべてのドメイン コントローラとグローバル カタログ サーバーを Service Pack 4 に更新し、Windows Update から最新の修正プログラムと更新を適用します。

  2. すべての Exchange Server コンピュータを、最新の Service Pack と更新プログラムのロールアップに更新します。

Windows 2000 Server オペレーティング システムの Service Pack の入手とインストールの詳細については、Windows 2000 Service Pack Web サイト (http://go.microsoft.com/fwlink/?linkid=18353) を参照してください (このサイトは英語の場合があります)。

Exchange Server の Service Pack や更新プラグラムのロールアップの入手、およびインストールの詳細については、Microsoft Exchange Server Web サイト (http://go.microsoft.com/fwlink/?LinkId=21573) を参照してください (このサイトは英語の場合があります)。


実行されている Windows 2000 Server が製品版 (最終ビルド) ではない
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2005-11-17

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Version キーの値を判断します。

また、Exchange Server アナライザは次のレジストリ エントリも調べて、コンピュータ上で実行されている Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 5.0 の場合は、そのコンピュータが Microsoft Windows 2000 Server オペレーティング システムを実行していることを示します。製品版の Windows 2000 Server オペレーティング システムは、すべて Version 値が 5.0.2195 です。Version キーの値がこれ以外である場合は、プレリリース版の Windows 2000 Server が使用されています。

CurrentVersion の 2 番目のインスタンスの値が 5.0 であり、かつ Version の値が 5.0.2195 に等しくないことが検出されると、エラーが表示されます。

TAP (Technology Adoption Program) または Microsoft が支援する類似のプログラムに参加しているお客様以外が、運用環境でプレリリース版のソフトウェアを使用することはお勧めしません。また、Microsoft ではこのような使用のサポートを提供していません。

このエラーを修正するには

  1. ドメイン コントローラ、グローバル カタログ サーバー、Active Directory コネクタ (ADC) サーバー、および Exchange Server コンピュータを含むすべての Exchange インフラストラクチャ サーバーを、最新の製品版ソフトウェアにアップグレードします。

  2. アップグレード オプションが使用可能か、またはサポートされている場合は、オペレーティング システムを再構築して、Exchange Server の設定とデータを復元します。

Windows 2000 Service Pack 4 の入手とインストールについては、Windows 2000 Service Pack 4 Web サイト(http://go.microsoft.com/fwlink/?LinkId=33241) を参照してください (このサイトは英語の場合があります)。


X.400 アドレスに無効な終了文字がある
Microsoft Exchange Server アナライザ - 文書 > Active Directory >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、受信者ポリシーの gatewayProxy の値を判断し、X.400 アドレスがセミコロンで終了していることを確認します。

受信者ポリシーでの X.400 アドレスの正しい形式は、アドレスがセミコロンで終了する必要があります。セミコロンがない場合、X.400 アドレスへのメッセージ ルーティングが壊れます。

この問題を修正するには、Active Directory サービス インターフェイス (ADSI) Edit または LDP ツールを使用して、アドレスの終わりにセミコロンを追加する必要があります。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration [ドメイン名]] を展開し、[CN=Configuration, DC=ドメイン名, DC=ドメイン サフィックス] を展開します。

  3. [CN=Services] を展開し、[CN=Microsoft Exchange] を展開します。

  4. [CN=組織名] を展開し、[CN=Administrative Groups] を展開します。次に、[CN=Recipient Policies] を展開します。

  5. [CN=ポリシー名] を右クリックし、[プロパティ] をクリックします。

  6. 下にスクロールして [gatewayProxy] を選択し、[Edit] をクリックします。

  7. [Value] ボックスに、正しい gatewayProxy を入力します。

  8. Active Directory エディタを終了し、Exchange Server コンピュータを再起動して、変更を有効にします。


データベースの回復
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2007-01-22

このセクション内の文書には、Microsoft® Exchange Database Troubleshooter Tool によってアプリケーション ログ内で検出されたデータベースのエラーおよび警告イベントに関する詳細が記載されています。Database Troubleshooter は、Microsoft Exchange トラブルシューティング アシスタントと同じエンジンを使用して、プログラムによってトラブルシューティングの一連の手順を実行し、データベースのマウントに関する問題の根本的な原因を判別します。さらにこれらの文書では、データベースに関連する問題の兆候を判別し、それを解決するための手順も記載されています。

ツールの詳細、およびダウンロードについては、Microsoft Exchange トラブルシューティング アシスタント Version 1.0 に関するページを参照してください (このサイトは英語の場合があります)。


ESE 428 (0xfffff8f0): トランザクション ログ ドライブの空き領域が不足している
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-04-02

Microsoft® Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の ESE 428 イベントが検出されました。このイベントは、トランザクション ログのドライブに空き領域が不足していることを示しています。このエラーが発生すると、Exchange Server は新しいトランザクション ログ ファイルを作成できなくなります。データベースに対する更新をトランザクション ログに記録する必要があるため、このエラーによって、影響を受けるストレージ グループ内のすべてのデータベースがオフラインになります。

説明

Exchange Server では、次の 2 つのメカニズムを提供して、トランザクション ログ ドライブがいっぱいにならないようにしています。

  • 循環ログ。トランザクション ログは、データベース チェックポイントがそれより先に進むと自動的に完全削除されます。トランザクション ログ ファイルに使用するディスク領域は、ほとんどの状況において 50 MB 未満の空きが残ります。バックアップ中は、バックアップが完了するまでトランザクション ログの削除が中断される場合があります。

    注 :
    既定では、循環ログは、Microsoft Exchange 2000 Server 以降のバージョンでは有効になっていません。
  • ストレージ グループのバックアップ。Exchange Server は、Exchange Server 用のボリューム シャドウ コピー サービス (VSS) またはストリーミング オンライン バックアップ API を実装するバックアップ方法を使用して、ストレージ グループ内のすべてのデータベースの完全または増分のオンライン バックアップを実行してから、超過分のログを削除します。

循環ログが有効になっておらず、以下のいずれかの条件に該当する場合は、トランザクション ログ ファイルの数は、ハード ディスク ドライブの領域がなくなるまで増加していきます。

  • バックアップ プログラムでトランザクション ログ ファイルが削除されない。

  • バックアップ プログラムの動作が停止している。

  • トランザクション ログ ファイルが、その他の方法によって削除されない。

ハード ディスクの空き領域が不足すると、トランザクション ログ ファイルの手動による削除が必要になる場合があります。特定のストレージ グループ内のすべてのデータベースの完全または増分のオンライン バックアップを実行する前に、ハード ディスクの空き領域が不足することが予想される場合にも、トランザクション ログ ファイルの手動による削除が必要になることがあります。データベース チェックポイントより先にあるログを削除してデータベースが異常停止した場合は、必要なログを復元するまでデータベースをマウントできません。このため、手動で Exchange Server トランザクション ログ ファイルを削除する前に、削除しても安全なログかどうかを確かめる必要があります。

このエラーは、JET_errDiskFull またはエラー コード 0xfffff8f0 としてレポートされる場合もあります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

このエラーを解決するには、次のいずれかの解決策を選択します。

  • Database Recovery Management ツールを実行します。Microsoft Exchange Server 2007 では、このツールは Exchange 管理コンソールの [ツールボックス] の、データベース回復ツールの一覧に表示されます。Exchange Server アナライザは、安全に削除できるログ ファイルを自動的に判別し、それらをバックアップ場所にコピーします。ログ ファイルの移動には、Exchange Server アナライザを使用することを強くお勧めします。

    注 :
    クラスタ連続レプリケーション (CCR) に対して、データベースを含むストレージ グループが有効になっている場合は、Exchange Server アナライザは Exchange 2007 では動作しません。
  • 各データベース ヘッダーの State および Log Required の値を確認し、手動で削除しても安全なトランザクション ログ ファイルかどうかを判別します。

    注 :
    この文書では、トランザクション ログ ファイルの削除とは、トランザクション ログ ファイルをバックアップ、格納、または完全削除できる別の場所にそのトランザクション ログ ファイルを移動することを意味します。この操作は必要に応じて異なります。この文書では、トランザクション ログ ファイルの完全削除とは、そのトランザクション ログ ファイルをバックアップまたは復元できない種類の削除を意味します。

手動で削除しても安全なトランザクション ログ ファイルを判別するには、次の手順に従います。

データベースのヘッダーを確認して不要なログ ファイルを削除するには

  1. ヘッダーを確認するデータベースのマウントを解除します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力してコマンド プロンプト ウィンドウを開きます。

  3. コマンド プロンプトで、データベース ファイルを配置するディレクトリ パスに移動します。

    注 :
    Exchange 2000 Server および Exchange Server 2003 でデータベースの .edb ファイルと .stm ファイルのパスとファイル名を調べるには、Exchange システム マネージャを使用して、各データベース オブジェクトのプロパティ ダイアログ ボックスの [データベース] タブを表示します。Exchange Server 2007 でデータベース ファイルの名前とパスを調べるには、[サーバーの構成] で [Exchange 管理コンソール] を展開し、[メールボックス] をクリックして、[データベースの管理] タブを表示します。

  4. コマンド プロンプトで、以下の Eseutil コマンドを /MH スイッチと共に入力します。

    コードのコピー
    "eseutil /MH databasefilename.edb"
    注 :
    この構文の databasefilename には調べるデータベースの名前が入ります。

  5. 表示されるヘッダー情報の State および Log Required の値を確認します。

    State の値は、データベースが正常に切断されたかどうかを示す以下の情報を表します。

    • データベースが正しく切断された場合、State の値は Clean Shutdown または Consistent のいずれかになります。この値は、実行している Exchange Server のバージョンによって異なります。現在のトランザクション ログ ファイル以外のすべてのトランザクション ログ ファイルを削除できます。

      注 :
      すべてのデータベースがクリーン シャットダウン状態のときに現在のログ ファイルを削除する場合は、ログ ファイルの順序をリセットすることになります。これによりデータベースを起動できなくなることはありません。ただし、この状況が発生すると、ログ ファイルの順序がリセットされることにより、データベースを以前のバックアップからロールフォワードする機能に影響を及ぼします。
    • データベースが正しく切断されなかった場合は、State の値は Dirty Shutdown または Inconsistent のいずれかになります。データベース ヘッダーの Log Required フィールドを確認すると、削除可能なトランザクション ログ ファイルがわかります。

      注 :
      データベースの状態がダーティ シャットダウンまたは不整合の場合は、既存のトランザクション ログ ファイルの中に、データベースによって要求された未解決のトランザクションが含まれるものがあることを示しています。この状況でトランザクション ログ ファイルを削除すると、バックアップからデータベースを復元しない限り、データベースを再起動することはできません。または、Eseutil コマンドと Isinteg コマンドを使用してデータベースを修復することもできます。
      ストレージ グループのログを削除するには、そのストレージ グループの各データベースの Log Required の値を確認する必要があります。

      Log Required フィールドには、このデータベースの起動に必要な、連番の付いたログ ファイルの範囲が表示されます。この範囲が 0 - 0 の場合は、このデータベースの起動に必要なログ ファイルはありません。これは、データベースの状態がクリーン シャットダウンまたは整合であることを示しています。チェックポイント ログよりも古いログ ファイルがある場合は、そのチェックポイント ログ以外の古いログ ファイルを削除できます。

      Exchange Server 2003 Service Pack 1 (SP1) より前のバージョンの Exchange Server を実行している場合は、Log Required フィールドに表示される範囲の値を 10 進数から 16 進数に変換する必要があります。たとえば、Log Required の値が 28217 - 28221 の場合は、このデータベースには 06E39 から 06E3D までのログ ファイルが必要です。Exchange 2003 SP1 では、Log Required フィールドは、10 進数と 16 進数の両方の値を報告するように拡張されています。

      注 :
      Windows の電卓の関数電卓モードを使用すると、10 進数から 16 進数に変換できます。電卓を起動して、[表示] メニューの [関数電卓] をクリックします。10 進数の数値を入力し、[16 進] をクリックします。
      Exchange 2000 および Exchange 2003 では最大 4 つのストレージ グループを指定でき、各ストレージ グループにはログ ファイルの固有のセットを指定できるため、トランザクション ログ ファイル名に Edb というプレフィックスは表示されません。Exchange 2000 および Exchange 2003 では、Edb というプレフィックスは、E00、E01、E02、または E03 に置き換えられます。回復用ストレージ グループの場合は、Edb というプレフィックスは、R00 に置き換えられます。ストレージ グループのログ ファイル名のプレフィックスは、Exchange システム マネージャで、個々のストレージ グループ オブジェクトのプロパティ ダイアログ ボックスの [全般] タブに表示されます。このため、ストレージ グループのプレフィックスが E01 で、Log Required のエントリが 28217 - 28221 (0x06E39 - 0x06E3D) の場合は、実際に必要なログは、E0106E39.log から E0106E3D.log までとなります。

  6. ストレージ グループ内のデータベースの Log Required フィールドの最小値のエントリよりも小さい番号が付いているログ ファイルは、すべて安全に削除できます。

    注 :
    ログ ファイルは完全に削除するのではなく移動するということを覚えておいてください。
    注 :
    ベスト プラクティスとして、最新のトランザクション ログ ファイルは削除しないことをお勧めします。これは最新のタイムスタンプを持ち、ファイル名にまだ連番が付いていないログ ファイルです。このファイルを削除しても安全だと判断した場合であっても、ログ ファイルの順序が 0 にリセットされるのを避けるために、このファイルは残しておいてください。ログ ファイルの順序をリセットすると、バックアップ サイクルに影響を及ぼします。リセット前に実行したバックアップからデータベースをロール フォワードできなくなる可能性があります。


ESE 454 -515: 必要なトランザクション ログ ファイルが見つからない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールによって、エラー コード -515 を含む ESE イベント 454 が検出されました。このエラーは、必要なトランザクション ログ ファイルが見つからないため、Exchange データベースがマウントできなかったことを示しています。

説明

-515 エラーを含む ESE 454 イベントは、復元処理中に ESE (Extensible Storage Engine) がストレージ グループ内のすべてのデータベースを整合状態にしようとした際に発生する可能性があります。必要なトランザクション ログ ファイルが見つからない場合、復元処理は失敗し、-515 エラーとなってデータベースをマウントできません。

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • ここに記載された手順に従い、見つからないトランザクション ログ ファイルの名前と場所を特定します。その後、それらのファイルをこのストレージ グループのトランザクション ログ ディレクトリに戻します。

  • 対象のデータベースをバックアップから復元します。

注意 :
見つからないトランザクション ログ ファイルを探して元の場所に戻すソリューションがあくまでも優先されます。データベースの復元は、それができない場合に限って実行するようにしてください。データベースの復元を行うと、前回のバックアップ以降のすべてのデータが上書きされてしまいます。
注 :
データベースを復元する場合、その前に対象のストレージ グループに関連付けられているすべてのトランザクション ログ ファイルを、保存先のパスから移動するか、または削除してください。
Exchange Server 2003 および Exchange Server 2007 で、Microsoft Exchange トラブルシューティング アシスタントを使用して見つからないトランザクション ログ ファイルを特定するには、次の操作を行います。

  1. Microsoft Exchange トラブルシューティング アシスタントの [イベント ログの調査結果の表示] ウィンドウで、[Use related Database Recovery Management task to verify and resolve this issue (関連するデータベース回復管理タスクを使用して、この問題を確認および解決する)] リンクをクリックし、見つからないトランザクション ログ ファイルを特定します。

  2. 手順 1. で報告されたログ ファイル名をメモします。

  3. これらのログ ファイルが現在置かれている場所を特定し、ファイルを正しい場所に戻します。
注 :
見つからないトランザクション ログ ファイルが現在置かれている場所を探す場合は、ごみ箱やウイルス対策の検疫フォルダも探してください。
  1. 対象の Exchange データベースのマウントを試行します。

 Exchange 2000 Server または Exchange Server 2003 で、見つからないトランザクション ログを手動で探して元の場所に戻すには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. [全般] タブの [トランザクション ログの場所] に表示されるトランザクション ログ ファイルの場所のパスをメモします。

  4. コマンド プロンプトで、Eseutil.exe のあるディレクトリを開きます。Exchange 2000 Server および Exchange Server 2003 では、Eseutil.exe の既定のパスは、C:\program files\exchsrvr\bin です。

  5. コマンド プロンプトで、以下のコマンドを入力します。

    コードのコピー
    eseutil /ml "logpath\logprefix"

    logpath には、手順 3. でメモしたトランザクション ログ ファイルのパスを指定します。logprefix には、トランザクション ログ ファイルのプレフィックスを指定します。通常 e00 です。

    既定値を使用したこのコマンドの例は次のようになります。

    eseutil /ml "c:\program files\exchsrvr\mdbdata\e00".

  6. 見つからないトランザクション ログ ファイルの種類に応じて、以下の 2 つの形式のいずれかで報告されます。

    • <見つからないログ ファイル>: c:\program files\exchsrvr\mdbdata\E0002BE2.log

    • エラー: <見つからないログ ファイル>。ログ ファイルの世代は 11,235 (0x2BE3) ですが、予期された世代は 11,234 (0x2BE2) です。

    0x2BE2 は見つからないログ ファイル E0002BE2.log を指します。

  7. 手順 6. で報告されたログ ファイル名をメモします。

  8. これらのログ ファイルが現在置かれている場所を特定し、ファイルを手順 3. で得られた正しい場所に戻します。
注 :
見つからないトランザクション ログ ファイルが現在置かれている場所を探す場合は、ごみ箱やウイルス対策の検疫フォルダも探してください。
  1. 対象の Exchange データベースのマウントを試行します。

 Exchange Server 2007 で、見つからないトランザクション ログを手動で探して元の場所に戻すには、次の操作を行います。

  1. ストレージ グループが格納されているサーバー上で Exchange 管理コンソールを起動します。

  2. コンソール ツリーで、[サーバーの構成] を展開し、[メールボックス] をクリックします。

  3. 結果ウィンドウで、該当のストレージ グループ (見つからないトランザクション ログ ファイルを元の場所に戻そうとしている) が格納されているメールボックス サーバーをクリックします。

  4. ストレージ グループを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブの [ログのパス] に表示されたトランザクション ログ ファイルの場所のパスをメモします。

  6. コマンド プロンプトで、Eseutil.exe のあるディレクトリを開きます。Exchange Server 2007 では、Eseutil は Exchange の既定のインストール フォルダにあります。そのフォルダは、<システム ドライブ>:\Program Files\Microsoft\Exchange Server\Bin です。

  7. コマンド プロンプトで、以下のコマンドを入力します。

    コードのコピー
    eseutil /ml "logpath\logprefix"

    logpath には、手順 5. でメモしたトランザクション ログ ファイルのパスを指定します。logprefix には、トランザクション ログ ファイルのプレフィックスを指定します。通常 e00 です。

    既定値を使用したこのコマンドの例は次のようになります。

    eseutil /ml "c:\Program Files\Microsoft\Exchange Server\Bin\e00".

  8. 見つからないトランザクション ログ ファイルの種類に応じて、以下の 2 つの形式のいずれかで報告されます。

    • <見つからないログ ファイル>: c:\Program Files\Microsoft\Exchange Server\Bin\E000000049A.log

    • エラー: <見つからないログ ファイル>。ログ ファイルの世代は 11,235 (0x2BE3) ですが、予期された世代は 11,234 (0x2BE2) です。

    0x2BE2 は見つからないログ ファイル E0002BE2.log を指します。

  9. 手順 8. で報告されたログ ファイル名をメモします。

  10. これらのログ ファイルが現在置かれている場所を特定し、ファイルを手順 5. で得られた正しい場所に戻します。
注 :
見つからないトランザクション ログ ファイルが現在置かれている場所を探す場合は、ごみ箱やウイルス対策の検疫フォルダも探してください。
  1. 対象の Exchange データベースのマウントを試行します。

ESE イベント 454 の詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=81883) を参照してください (このサイトは英語の場合があります)。


ESE 455 -1811 (0xfffff8ed):現在のトランザクション ログ ファイル (Exx.log) が見つからない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-05-31

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内にエラーコード -1811 (0xfffff8ed) を含む ESE 455 イベントが 1 つ以上検出されました。このイベントは、現在のトランザクション ログ (exx.log) が見つからない、アクセスできない、または署名が一致しないことを示しています。

説明

このエラーには、以下の原因が考えられます。

  • JET_errFileNotFound に対応するエラー 1811。この問題は、Exchange ログ ファイルの署名およびログ内部の世代番号 (LGeneration) が一致しない場合に発生する可能性があります。通常、Exchange ログ ファイルは E00.log ファイルです。E00.log ファイルの署名が一致しない場合、データベースの整合性が保持されていてもインフォメーション ストアはマウントされません。

  • ウイルス対策プログラムによって、現在の Exchange ログ ファイルが検疫または削除された。

  • 対象のデータベースに eseutil /p 修復コマンドが実行されたが、ログ ファイルが削除されなかった。

  • eseutil /r Exx.log などのように、正しくないログ ファイル ベース名で eseutil /r 回復コマンドが実行された。この例の場合、Exx.log ではなく、3 文字のログ ファイル ベース名を指定する必要があります。

このエラーは、エラー -1811, JET_errFileNotFound として識別されることもあります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

このエラーを解決するには、次のいずれかの操作を行います。

  • ログ ファイルの署名および世代番号が一致しない場合は、Microsoft Customer Support Services にお問い合わせください。詳細については、Microsoft ヘルプとサポート Web サイトのお問い合わせについてのページを参照してください (このサイトは英語の場合があります)。

  • ウイルス対策プログラムによって現在の Exchange ログ ファイルが検疫または削除された場合は、以下の手順に従います。

    • ウイルス対策プログラムの構成を確認します。

    • Exchange Server ディレクトリをスキャンしないようにウイルス対策プログラムが構成されていることを確認します。

    • ウイルス対策プログラムの中には、ドライブおよびディレクトリを手動モードまたは自動モードで毎週スキャンするように既定で設定されています。この設定は見逃しやすいので注意が必要です。Exchange Server ディレクトリは、ウイルス対策プログラムが適用されない場所に追加してください。Exchange と共に動作するようにウイルス対策プログラムを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」を参照してください。

    • ウイルス対策プログラムのログ ファイルを調べ、Exchange ログ ファイルが検疫または削除されていることを確認します。

    Exchange ログ ファイルを回復するには、以下のいずれかの方法を使用します。

方法 1: Exchange ログ ファイルが検疫された場合

  1. 運用ログ ファイルを格納しているフォルダに Exchange ログを回復します。

  2. Microsoft Exchange Information Store サービスを開始します。他に足りないログ ファイルがない場合は、データベースがマウントされます。他に足りないログ ファイルがある場合は、ウイルス対策プログラムの検疫フォルダにそのログ ファイルがあるかどうかを確認します。検疫フォルダにログ ファイルがない場合は、方法 2 を参照してください。

Exchange ログ ファイルが削除された場合は、バックアップからストレージ グループ データベースを復元する必要があります。その後、ログ ファイルを再生する必要があります。利用可能なデータベースを復元するには、次の手順に従います。

方法 2: Exchange ログ ファイルが削除された場合

  1. 不整合なデータベースをすべてバックアップ フォルダに移動します。

  2. 新しい E00.log ファイルが作成された場合は、このファイルもバックアップ フォルダに移動します。さらに、E00.chk ファイルをバックアップ フォルダに移動します。

  3. 既存のログ ファイルをすべてバックアップ フォルダにコピーします。注 ログ ファイルはコピーする必要があります。移動しないでください。

  4. 最後の E00*.log ファイルの名前を E00.log に変更します。

  5. バックアップからデータベースを復元します。次に、ログ ファイルを再生します。これにより、データベースが整合状態になります。ただし、バックアップ フォルダにコピーした E00.log ファイルはデータベースに含まれません。一部のデータは失われますが、データベースはマウント可能になります。

    注 :
    バックアップからデータベースを復元できない場合は、データベースに対して修復ユーティリティを実行し、データベースを整合状態にします。

  6. Microsoft Exchange Information Store サービスを開始します。

対象のデータベースに eseutil /p 修復コマンドを実行してもログ ファイルが削除されなかった場合は、以下の手順に従います。

eseutil /p コマンドが実行されたかどうかを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. コマンド プロンプトで次のように入力します。

    コードのコピー
    c:\program files\exchsrvr\bin\eseutil /mh "c:\program files\exchsrvr\mdbdata\<name of Exchange database.edb>"

    この構文では次の設定を前提としています。

    • Exchange Server のプログラム ファイルは c:\program files\exchsrvr フォルダにインストールされている。

    • データベースは c:\program files\exchsrvr\mdbdata フォルダにある。

  3. 修復カウント属性を読み取ります。修復カウント属性が 0 (ゼロ) の場合、eseutil /p コマンドは実行されなかったことを示します。修復カウント属性が 0 以外の数値の場合は、eseutil /p コマンドがデータベースで実行されたことを示します。

パブリックおよびプライベート データベースが整合状態またはクリーン シャットダウン状態である場合、トランザクション ログ ファイルを別のフォルダに移動できます。データベースが整合状態またはクリーン シャットダウン状態であるかどうかを判断するには、次の手順に従います。

データベースが整合状態またはクリーン シャットダウン状態であるかどうかを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. プライベート インフォメーション ストアを確認するには、次のように入力します。

    コードのコピー
    c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\priv1.edb"

  3. パブリック インフォメーション ストアを確認するには、次のように入力します。

    コードのコピー
    c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\pub1.edb"

    手順 2. および 3. の構文では、次の設定を前提としています。

    • Exchange Server のプログラム ファイルは c:\program files\exchsrvr フォルダにインストールされている。

    • データベースは c:\program files\exchsrvr\mdbdata フォルダにある。

  4. 整合性チェックの結果を確認します。データベースが整合している場合 (状態 = クリーン シャットダウン) は、すべてのログ ファイルがインフォメーション ストアにコミットされています。データベースが整合していない場合 (状態 = ダーティ シャットダウン)、データベースは破損していない可能性があります。ログ ファイルはまだデータベースにコミットされていなかった可能性があります。

  5. 状態がクリーン シャットダウンになったら、すべての mdbdata ディレクトリからすべてのログ ファイルをバックアップ フォルダに移動します。

  6. データベースをマウントします。
  • 正しくないログ ファイル ベース名で eseutil /r 回復コマンドが実行された場合は、正しいスイッチを使用してコマンドを適切に実行します。共通のログ ファイル ベース名は、e00、e01、e02 および e03 です。たとえば、次のコマンドでは正しいログ ファイルベース名が使用されています。

    コードのコピー
    eseutil /r e00
  • 引き続き問題が発生する場合は、Microsoft Customer Support Services にお問い合わせください。詳細については、Microsoft ヘルプとサポート Web サイトのお問い合わせについてのページを参照してください (このサイトは英語の場合があります)。


ESE 474 -1018: データベースに回復不能なエラーが検出された
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-03-28

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の ESE 474 イベント (エラー コード -1018) が検出されました。このエラーは、Microsoft Exchange の整合性検証用コンポーネントによって、Exchange Server がハード ディスク サブシステムに Exchange データベース ファイルのデータを正しく格納できなかった、またはデータを取得できなかったと判断された場合に生成されます。

説明

ESE 474 イベント (エラー コード -1018) は、ハード ディスク サブシステムのハードウェア コンポーネントに障害が発生している場合、あるいはハード ディスク サブシステムのドライバやファームウェアが古い、または互換性がない場合に発生することがあります。

-1018 エラーが発生した後で、サーバーに対して診断ハードウェア テストを実行しても、ディスク サブシステムにハードウェアの問題はないと報告される場合があります。この場合、問題の原因は Exchange Server にあると推定することができます。

Microsoft とハードウェア ベンダによって行われた大規模な調査の結果、ほとんどの -1018 エラーは、ディスク サブシステムのハードウェア コンポーネント、またはそれをサポートするドライバやファームウェアの些細な問題に起因することが判明しています。

Exchange によって -1018 エラーが報告されるのは、データベース ファイルの初期化されたページが、以下のいずれかの状況であることが検出された場合です。

  • ページに格納されているチェックサムが、ページが読み取られるときに実行されたチェックサム再計算の結果と一致しない。

  • ページに格納されているページ番号が、データベース ファイル内でのそのページの物理的な場所から推定されるページ番号と一致しない。

以下の状況が発生した場合、Exchange 自体の原因によって -1018 エラーが生成されることがあります。

  • Exchange が誤ったチェックサムを持つページを作成した。

  • Exchange がページを正しく作成したが、オペレーティング システムに対してページを誤った場所に書き込むように指定した。

Exchange では、ページにすべてのデータが書き込まれた後で、ディスクに書き込まれるページのチェックサムを生成します。これには、ページ番号自体も含まれます。ページにチェックサムを追加した後で、Exchange は Windows オペレーティング システムに対して、標準の公開されている Windows ベースの API を使用してページをディスクに書き込むように指示します。

このとき、一時的なメモリ エラーによって、ハード ディスク上の誤った場所にページが書き込まれる可能性があります。

ページのチェックサムが正しくても、論理的なページ番号が物理的なページ番号と一致しない場合、Exchange は -1018 エラーを報告します。

Exchange データベースで -1018 エラーが単独で報告された場合、通常は Exchange データベースが停止したり、-1018 エラー以外の症状が発生したりすることはありません。この場合、問題のページは、送信済みアイテム フォルダや削除済みアイテム フォルダなど、あまり頻繁にアクセスされないフォルダのものである場合や、ほとんど開かれない添付ファイルのものである可能性があります。または、空である可能性もあります。

-1018 エラーの単独の発生では、広範なデータの消失を引き起こす可能性は低いのですが、ストレージ システムが少なくとも 1 回は安全にデータの格納または取得を行うことができなかったことを意味するため、その点で問題となります。-1018 エラーは、これから徐々に悪化する可能性のある問題の初期警告です。-1018 エラーが最初に報告されたのがデータベースの空のページであっても、次に破損するのはどのページかは予測できません。重要なグローバル テーブルが破損した場合、Exchange データベースが開始されない、データベースの修復が成功しない、または部分的にしか修復が成功しない可能性があります。

-1018 エラーが記録された場合、エラーの根本的な原因が判明するまで、データベースの障害や別のランダムなダメージがすぐにも発生する可能性があることを考慮し、対処を計画してください。

ユーザーの操作

アプリケーション ログに記録された ESE 474 - 1018 エラーの修正を試みる前に、サーバーのディスク サブシステムが安定しているかどうかを確認してください。

ディスク サブシステムのトラブルシューティングを行うには、次の操作を行います。

  1. アプリケーション ログを開き、ESE 474 イベントを検索します。各イベントについて、問題となっているデータベースの完全なパスを書き留めます。問題となっているデータベースの一覧をまとめた後で、データベースのパスで参照されているドライブ文字に注目します。この情報によって、それらの物理ディスクに対象を絞ってトラブルシューティングを行うことができます。

  2. システム ログを参照し、ディスクの読み取り、書き込み、またはタイムアウトのエラーが記録されていないかどうか確認します。

  3. 製造元の提供するディスク サブシステム診断ユーティリティを使用します。また、ディスク サブシステムの整合性を確認するための方法について、ディスク サブシステム ハードウェアのベンダに問い合わせます。

ディスク サブシステムの問題点を解決したら、またはディスク サブシステムの安定性を確認したら、次の方法で -1018 エラーから回復します。これらの方法は、優先順位の高い (先に実行する) 順に掲載しています。

方法 1: メールボックスを、アプリケーション ログの ESE 474 イベントで参照されているデータベースから移動します。既存の、正常であることが確認されているストアにメールボックスを移動するか、またはこの目的で使用する新しいメールボックス ストアを作成します。すべてのメールボックスを移動したら、破損したメールボックス ストアを削除します。

メールボックスを移動するには (Exchange 2000 Server または Exchange Server 2003)

  1. Active Directory ユーザーとコンピュータで、メールボックスを移動するユーザーを選択します。

  2. 前の手順で選択したユーザーの一覧を右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。
メールボックスを移動するには (Exchange Server 2003 のみ)

  1. Exchange システム マネージャで、[サーバー] を展開し、メールボックスを移動するサーバーを展開します。次に、メールボックスの移動元のストレージ グループを展開して移動するメールボックスが含まれるメールボックス ストアを展開し、[メールボックス] をクリックします。

  2. 詳細ウィンドウで、メールボックスを移動するユーザーを右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。
Exchange 管理コンソールを使用してメールボックスを移動するには (Exchange Server 2007 のみ)

  1. Exchange 管理コンソールを起動します。

  2. コンソール ツリーで、[受信者の構成] を展開し、[メールボックス] をクリックします。

  3. 結果ウィンドウで、移動するメールボックスをクリックします。

  4. 操作ウィンドウで、[メールボックスの移動] をクリックします。

  5. メールボックスの移動ウィザードの [概要] ページで、メールボックスの移動先となるサーバー、ストレージ グループ、およびメールボックス データベースを選択し、[次へ] をクリックします。

  6. [移動オプション] ページで、メールボックス内の破損したメッセージを処理するためのオプションを選択し、[次へ] をクリックします。

  7. [移動スケジュール] ページで、移動を行うスケジュールを指定し、[次へ] をクリックします。

  8. [メールボックスの移動] ページで、メールボックスの移動の概要を確認し、[移動] をクリックします。

  9. [完了] ページで、[終了] をクリックします。

メールボックスの移動ウィザードと Move-Mailbox コマンドレットの使用に関してサポートされるシナリオの詳細については、Exchange Server 2007 製品ドキュメントの、メールボックスの移動に関するページ (http://go.microsoft.com/fwlink/?LinkId=85754) を参照してください (このサイトは英語の場合があります)。

方法 2: 良好な状態であることがわかっているバックアップから、データベースを復元します。Exchange Server データベースを復元する方法の詳細については、以下の文書を参照してください。

  • Exchange Server 2007 の障害回復についてのページ (http://go.microsoft.com/fwlink/?LinkId=85802) (このサイトは英語の場合があります)

  • 『Exchange Server 2003 障害回復ガイド』(http://go.microsoft.com/fwlink/?LinkId=30250) (このサイトは英語の場合があります)

方法 3: Eseutil を使用して、問題のデータベースのハード修復操作を実行します。この方法は、前の 2 つの方法が失敗した場合にのみ行ってください。ハード修復操作を実行した後で、修復されたデータベースに対してオフラインでのディスク最適化を実行し、Isinteg ツールを実行して論理的な破損を修復する必要があります。これらの手順は、Exchange Database Troubleshooter ツールの修復タスクを使用して実行できます。このタスクによって、Eseutil /P、Eseutil /D、および Isinteg の処理が自動的に実行されます。

詳細情報

この問題の詳細については、以下の Microsoft サポート技術情報の文書と Exchange のリソースを参照してください。

  • 文書番号 314917「-1018、-1019、および -1022 Exchange データベース エラーの理解と解析」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=314917)

  • 文書番号 867626「コードを修正している新しいエラーは、Exchange Server 2003 SP1 に付属します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=867626)

  • 文書番号 259851「[XADM] ESEUTIL /P コマンドまたは EDBUTIL /D /R コマンドの実行が及ぼす影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=259851)

  • Exchange Server エラー -1018 についてのページ (http://go.microsoft.com/fwlink/?LinkId=85807) (このサイトは英語の場合があります)


MSExchangeIS 1003: Exchange データベース ドライブの空き領域が不足している
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-22

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 1003 イベントが検出されました。このエラーは、マウントしようとしているデータベースが格納されているドライブの空きディスク領域が不足している場合に発生する可能性があります。

説明

Exchange データベースが格納されているディスクの空き領域が不足している場合、Microsoft Exchange Information Store サービスにより MSExchangeIS 1003 イベントがログ出力され、対象のデータベースはマウント解除されます。これが発生すると、対象のストレージ グループのデータベースをマウントできなくなる可能性があります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、そのデータベース ドライブに空きディスク領域を確保してから、データベースのマウントを再試行します。それには、次のいずれかの操作を行います。

  • ハード ディスク上のファイルが Exchange データベース ファイルのみの場合は、ディスクの空き領域を確保するため、オフラインでのデータベース最適化を実行する必要がある可能性があります。

    注 :
    データベースで確保される空き容量によっては、この手順を実行しても問題が解決しない場合があります。
    この手順の実行方法の詳細については、マイクロソフト サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」を参照してください。

    また、Eseutil /D (最適化) の実行方法についてのページも参照してください (このサイトは英語の場合があります)。

  • このドライブに Exchange トランザクション ログ ファイルも保存されている場合は、不要なログ ファイルを削除することでディスク領域を解放できる可能性があります。

    この手順の実行方法の詳細については、マイクロソフト サポート技術情報の文書番号 240145「Exchange Server のトランザクション ログ ファイルを移動する方法」を参照してください。


MSExchangeIS 1088: legacyExchangeDN が無効なため、データベースをマウントできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、MSExchangeIS 1088 イベントが検出されました。このイベントは、Exchange データベースの legacyExchangeDN 属性値が Active Directory に格納されたものと異なるため、データベースをマウントできなかったことを示しています。

説明

MSExchangeIS 1088 イベントは、Exchange データベースが元の管理グループの legacyExchangeDN 属性値と異なる legacyExchangeDN 属性値を持つ管理グループに復元された場合に発生する可能性があります。この動作は仕様です。ストアを Exchange Server にマウントするには、Exchange データベースの組織および管理グループの legacyExchangeDN 属性値が、Active Directory 内の組織および管理グループの legacyExchangeDN 属性値と一致する必要があります。

ユーザーの操作

この問題を解決するには、次の操作を行います。

  • Exchange データベースを元の管理グループに復元します。

  • Exchange データベースを元の管理グループに復元できない場合は、復元先の Active Directory オブジェクトの名前を変更し、この Active Directory オブジェクトの legacyExchangeDN 属性値が Exchange データベースと同じものになるようにします。この値は、Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、その他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用して修正できます。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには、次の操作を行います。

  1. ADSI Edit または同様のツールを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    legacyExchangeDN 属性は次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Administrative Groups,CN=管理グループ名

  2. 次の形式で、新しい文字列値を入力します。

    /o= 組織 /ou= 管理グループ

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server 2003 ヘルプのトピック「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。

MSExchangeIS イベント 1088 の詳細については、以下のリソースを参照してください。

  • イベントとエラーのメッセージについてのページ (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 280652「ストアが XADM:「イベント ID 1088 が」記録され、ストアのマウントに失敗します。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=280652)


MSExchangeIS 5000 (0x3f5): Information Store サービスに無効なサービス アカウントが構成されている
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-02-27

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 5000 イベント (エラー コード 0x3f5) が検出されました。このエラーは、Microsoft Exchange Information Store サービスが、ローカル システム以外のアカウントを使用して開始するように構成されている場合に発生します。

説明

この問題は、Microsoft Exchange Information Store サービス (Store.exe) がローカル システム アカウント以外のアカウントを使用している場合、あるいはドメイン コントローラ、ドメイン、またはローカル マシンのセキュリティ ポリシーで、セキュリティ監査の生成ポリシーにローカル サービス アカウントが含まれていない場合に発生することがあります。この問題が発生すると、Exchange Information Store サービスが初期化に失敗します。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • 既定では、Exchange Information Store サービスはローカル システム アカウント (MACHINENAME$) を使用して、Information Store サービスを開始します。Services.msc スナップインを使用して、Information Store サービスの開始にどのアカウントが使用されているかを調べてください。アカウントがローカル システム アカウントである場合は、セキュリティ監査の生成の権限をローカル システム アカウントに与える必要があります。これを行うには、以下のいずれかの方法を使用します。

    • このコンピュータで、Exchange の Setup /domainprep コマンドを再実行します。

    • 以下のいずれかのポリシーで、ローカル システム アカウントにセキュリティ監査の生成の権限を手動で与えます。

    1. ドメイン コントローラのポリシー

    2. ドメインのポリシー

    3. ローカル マシンのセキュリティ ポリシー

      メンバ サーバーのローカル マシンのセキュリティ ポリシーにこの権限を再付与するには、以下の手順に従います。

      注 :
      この問題が 1 台のサーバーのみで発生している場合は、このソリューションをお勧めします。
      メンバ サーバーのローカル マシン セキュリティ ポリシーに監査権を再付与するには、以下の操作を行います。

      1. [スタート] ボタンをクリックし、[管理ツール] をクリックします。次に、[ローカル セキュリティ ポリシー] をクリックします。

      2. [セキュリティの設定] を展開して、[ローカル ポリシー] をクリックし、[ユーザー権利の割り当て] をクリックします。

      3. 右側のウィンドウで、[セキュリティ監査の生成] をダブルクリックし、[追加] をクリックします。「MACHINENAME$」と入力し、[OK] を 2 回クリックします。

      4. グループ ポリシー スナップインを終了します。
  • ローカル システム アカウント以外のアカウントを使用して Information Store サービスを開始している場合は、そのアカウントをローカル システム アカウント (MACHINENAME$) に戻す必要があります。その後、Information Store サービスを開始します。Exchange 2000 Server および Exchange Server 2003 がローカル システム アカウントを使用して Exchange サービスを開始する理由の詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」を参照してください。

詳細情報

詳細については、Microsoft サポート技術情報の文書番号 281850「インフォメーション ストアは、ID 9530 イベントと 5000 の Exchange 2000 Server と Exchange メッセージでサーバー 2003 を起動しません。」を参照してください。


MSExchangeIS 5000 (0x80004005): サービス アカウントの誤り、SeSecurityPrivilege アクセス許可の欠如、またはグループ メンバシップの誤りのため、データベースをマウントできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-02-19

Microsoft Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 5000 イベント (エラー コード 0x80004005) が検出されました。このイベントは、サービス アカウントの誤り、SeSecurityPrivilege アクセス許可の欠如、またはグループ メンバシップの誤りのために、Exchange Server でデータベースがマウントできないことを示しています。

説明

以下の条件のいずれかに当てはまる場合、このイベントが発生することがあります。

  • 1 つ以上のドメイン コントローラ上の Exchange Enterprise Servers グループから、監査とセキュリティ ログの管理のアクセス許可 (SeSecurityPrivilege) が削除されています。Exchange Enterprise Servers グループには、ドメイン内のすべてのドメイン コントローラに対して、監査とセキュリティ ログの管理のアクセス許可が必要です。この条件が当てはまる場合、Exchange Server に関連する 1 つ以上のサービスが開始しません。

  • Microsoft Exchange Information Store サービスが Local System 以外のアカウントで開始されているか、またはドメイン コントローラ、ドメイン、ローカル コンピュータのいずれかのセキュリティ ポリシーにおいて、セキュリティ監査の生成ポリシーに Local Service アカウントが含まれていません。この条件が当てはまる場合、Exchange Information Store サービスは開始しません。

  • 親ドメインの Exchange Enterprise Servers グループに、子ドメインの Exchange Domain Servers グループが含まれていません。

このイベントは、MAPI_E_CALL_FAILED として識別されることもあります。このイベントは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • 1 つ以上のドメイン コントローラ上の Exchange Enterprise Servers グループから、監査とセキュリティ ログの管理のアクセス許可 (SeSecurityPrivilege) が削除されている場合は、次の手順に従います。

    1 つ以上のドメイン コントローラにアクセス許可を追加するには、次の操作を行います。

    1. Policytest.exe を使用して、アクセス許可の問題のトラブルシューティングを実行します。Policytest.exe は、Exchange 2000 Server CD の Support\Utils\I386 フォルダ、または Exchange Server 2003 CD の Support\ExDeploy フォルダにあります。Policytest.exe を使用して、Exchange Enterprise Servers グループの "監査とセキュリティ ログの管理" アクセス許可がドメイン コントローラから削除されているかどうかを判断します。正しく実行されると、次のような情報が返されます。

      Local domain is "<contoso.com>" (contoso) Account is "CONTOSO\Exchange Enterprise Servers" DC = "<コンピュータ名>" In site = "<既定の最初のサイト名>" Right found: "SeSecurityPrivilege"

      注 正しい結果では、"監査とセキュリティ ログの管理" アクセス許可が存在することを示します。Policytest.exe を実行するには、ドメイン管理者権限が必要です。Policytest.exe ユーティリティの詳細については、マイクロソフト サポート技術情報の文書番号 281537「[XADM] Policytest.exe ユーティリティについて」を参照してください。

    2. Exchange Enterprise Server の既定のアクセス許可をドメイン レベルでリセットします。それには、次の手順に従います。

      1. Exchange Server CD またはネットワーク インストール ポイントから setup /domainprep コマンドを実行します。setup /domainprep コマンドを実行すると、Exchange Enterprise Servers グループが、既定のアクセス許可を持つドメインに追加されます。setup /domainprep コマンドを実行すると、1 つのドメイン コントローラに直ちにアクセス許可が追加されます。その後、変更が他のドメイン コントローラにレプリケートされます。

      2. 他の組織単位にアクセス許可の継承を復元します。ドメイン コントローラによって変更がドメイン全体にレプリケートされるまで待ちます。

      3. Policytest.exe を実行します。次のような正しい結果を返すドメイン コントローラを確認します。

        Right found: "SeSecurityPrivilege"

        すべてのドメイン コントローラが正しいアクセス許可を持っている場合は、Exchange Server サービスを再開します。正しいアクセス許可を持つドメイン コントローラがない場合は、手順 3 を参照してください。

    3. 既定のドメイン コントローラのポリシーを確認します。それには、次の手順に従います。

      1. [Active Directory ユーザーとコンピュータ] スナップインを起動します。

      2. [ドメイン コントローラ] コンテナを右クリックし、[プロパティ] をクリックします。

      3. [グループ ポリシー] タブをクリックし、[既定のドメイン コントローラ ポリシー] が [グループ ポリシー オブジェクトのリンク] ボックスの一覧に表示されていることを確認します。注 [既定のドメイン コントローラ ポリシー] が表示されていない場合は、[追加]、[既定のドメイン コントローラ ポリシー]、[OK] の順にクリックします。この変更が他のすべてのドメイン コントローラにレプリケートされるまで待ちます。

      4. Exchange Server CD またはネットワーク インストール ポイントから setup /domainprep コマンドを実行します。setup /domainprep コマンドを実行すると、Exchange Enterprise Servers グループが、既定のアクセス許可を持つドメインに追加されます。

      5. Policytest.exe を実行します。次のような正しい結果を返すドメイン コントローラを確認します。

      Right found: "SeSecurityPrivilege"

      すべてのドメイン コントローラが正しいアクセス許可を持っている場合は、Exchange Server サービスを再開します。正しいアクセス許可を持たないドメイン コントローラが存在する場合は、手順 4 を参照してください。

    4. ドメイン コントローラに手動でアクセス許可を追加します。setup /domainprep コマンドを実行しても、1 つ以上のドメイン コントローラに更新されたセキュリティ ポリシーがファイル複製サービス (FRS) によってレプリケートされない場合があります。この問題が発生した場合は、Exchange Enterprise Servers グループに正しいアクセス許可を手動で割り当てる必要があります。一部またはすべてのドメイン コントローラが正しいアクセス許可を持っていない場合は、Exchange Enterprise Servers グループに "監査とセキュリティ ログの管理" アクセス許可を割り当てます。この設定が他のドメイン コントローラにレプリケートされるまで待ちます。それには、次の手順に従います。

      1. [Active Directory ユーザーとコンピュータ] スナップインを起動します。

      2. [ドメイン コントローラ] コンテナを右クリックし、[プロパティ] をクリックします。

      3. [グループ ポリシー] タブをクリックし、[グループ ポリシー オブジェクトのリンク] ボックスの [既定のドメイン コントローラ ポリシー] をクリックして、[編集] をクリックします。

      4. [コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ローカル ポリシー] の順に展開して、[ユーザー権利の割り当て] をクリックします。

      5. 右側のウィンドウで、[監査とセキュリティ ログの管理] をダブルクリックし、[追加] をクリックします。次に、[参照] をクリックして、Exchange Enterprise Servers グループを追加します。

      6. [ユーザーまたはグループの追加] ダイアログ ボックスで、[OK] をクリックします。もう一度 [OK] をクリックします。

      7. グループ ポリシー スナップインを終了して、[ドメイン コントローラ] の [プロパティ] ダイアログ ボックスで [OK] をクリックします。注 [ユーザーまたはグループの追加] ダイアログ ボックスで [参照] をクリックしても、Exchange Enterprise Servers グループが表示されない場合があります。表示されない場合は、Exchange Domain Servers グループを追加します。次に、setup /domainprep コマンドを再実行します。この処理によって、Exchange Enterprise Servers グループの追加がすべてのドメイン コントローラに反映されます。
  • Exchange Information Store サービスが Local System 以外のアカウントで開始されているか、またはドメイン コントローラ、ドメイン、ローカル コンピュータのいずれかのセキュリティ ポリシーにおいて、セキュリティ監査の生成ポリシーに Local Service アカウントが含まれていない場合は、次の解決策に従います。

    既定では、Exchange Information Store サービスはローカル システム アカウント (MACHINENAME$) を使用して、Information Store サービスを開始します。Services.msc スナップインを使用して、Information Store サービスの開始にどのアカウントが使用されているかを調べてください。アカウントがローカル システム アカウントである場合は、セキュリティ監査の生成の権限をローカル システム アカウントに再付与する必要があります。これを行うには、以下のいずれかの方法を使用します。

    セキュリティ監査の生成の権限をローカル システム アカウントに再付与するには、次の操作を行います。

    1. このコンピュータで、Exchange の Setup /domainprep コマンドを再実行します。

    2. 以下のいずれかのポリシーで、ローカル システム アカウントにセキュリティ監査の生成の権限を手動で与えます。

      • ドメイン コントローラのポリシー

      • ドメインのポリシー

      • ローカル マシンのセキュリティ ポリシー

    メンバ サーバーのローカル マシンのセキュリティ ポリシーにセキュリティ監査の生成の権限を再付与するには、次の操作を行います。

    1. [スタート] ボタンをクリックし、[管理ツール] をクリックします。次に、[ローカル セキュリティ ポリシー] をクリックします。

    2. [セキュリティの設定] を展開して、[ローカル ポリシー] をクリックし、[ユーザー権利の割り当て] をクリックします。

    3. 右側のウィンドウで、[セキュリティ監査の生成] をダブルクリックし、[追加] をクリックします。「MACHINENAME$」と入力し、[OK] を 2 回クリックします。

    4. グループ ポリシー スナップインを終了します。

    ローカル システム アカウント以外のアカウントを使用して Information Store サービスを開始している場合は、そのアカウントをローカル システム アカウント (MACHINENAME$) に戻す必要があります。その後、Information Store サービスを開始します。Exchange 2000 Server および Exchange Server 2003 がローカル システム アカウントを使用して Exchange サービスを開始する理由の詳細については、マイクロソフト サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」を参照してください。

  • 親ドメインの Exchange Enterprise Servers グループに子ドメインの Exchange Domain Servers グループが含まれていない場合は、子ドメインの Exchange Enterprise Servers グループを親ドメインの Exchange Domain Servers グループに追加します。また、ルート ドメイン内で受信者更新サービスを作成することにより、この問題を解決することもできます。

    この問題を解決するには、リモートの Windows ドメインにあるサーバーの /domainprep スイッチを使用して、Exchange のセットアップを実行します。次に、Exchange Server で Exchange システム マネージャを使用して、リモート ドメインの受信者更新サービスを作成します。それには、次の手順に従います。

    リモート ドメインの受信者更新サービスを作成するには、次の操作を行います。

    1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

    2. 組織オブジェクトを展開して、[受信者] コンテナを展開します。

    3. [受信者更新サービス] をクリックします。

    4. 右側のウィンドウで、[新規] を右クリックし、[受信者更新サービス] をクリックします。

    5. 受信者更新サービスのインスタンスがなく、Exchange で更新する必要があるユーザーが存在するドメインをクリックします。

    6. [次へ] をクリックします。

    7. 受信者更新サービスを実行し、すべての必要なユーザーを Exchange 属性で処理するサーバーを選択します。

    8. [次へ] をクリックします。

    9. [完了] をクリックします。

    10. ドメイン内の受信者の更新を手動で開始するには、[受信者更新サービス] を右クリックし、[今すぐ更新] をクリックして更新を行います。
    詳細については、マイクロソフト サポート技術情報の文書番号 253770「Exchange 受信者更新サービスで実行されるタスク」を参照してください。


MSExchangeIS 5000 (0x80040154): SMTP サービス拡張が存在しないか、または破損している
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-02-19

Microsoft Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 5000 イベント (エラー コード 0x80040154) が検出されました。このエラーは、Exchange Server の SMTP (Simple Mail Transfer Protocol) サービス拡張が存在しないか、または破損している場合に発生することがあります。

説明

この問題は、Exchange SMTP サービス拡張が存在しないか、または破損している場合に発生します。この問題によって、Exchange と SMTP サービスとの間の機能が損なわれます。SMTP サービスは、インターネット インフォメーション サービス (IIS) のサブコンポーネントとしてインストールされる、必要なサービスです。

このエラーの発生には、以下の原因が考えられます。

  • IIS が削除された。

  • IIS から SMTP サービスのサブコンポーネントが削除された。

  • IIS が削除され、その後 Windows のコンポーネントとして再インストールされたが、必要な SMTP サービスのサブコンポーネントがインストールされなかった。

  • IIS が削除され、その後適切なサブコンポーネントの一覧を持つ Windows コンポーネントとして再インストールされたが、Exchange SMTP サービス拡張が再インストールされなかった。

このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

このエラーを解決するには、マイクロソフト サポート技術情報の文書番号 326305「Small Business Server 2000 で MSExchangeIS のイベント ID 5000、9538 および 9098 が発生する」を参照してください。

SMTP サービス拡張を復元するには、次の操作を行います。

  1. Exchange SMTP サービス拡張がないことを確認します。それには、次の手順に従います。

    1. 管理者の資格情報を持つアカウントを使用して、Microsoft Exchange を実行しているコンピュータにログオンします。

    2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

    3. コマンド プロンプトに「telnet 127.0.0.1 25」と入力して、"220 server.domain.com Microsoft ESMTP Mail Service" エントリを表示します。

    4. 「EHLO」と入力して Enter キーを押し、250 コマンドの一覧を表示します。名前が "X" で始まるコマンドがない場合は、SMTP サービス拡張がないことになります。

  2. システム パーティションを完全にバックアップします。システム状態と Exchange データベース ファイルを含めます。この方法の詳細については、マイクロソフト サポート技術情報の文章番号 258243「Windows バックアップ プログラムを使用した Exchange コンピュータのバックアップおよび復元の方法」を参照してください。

  3. 必要な Exchange 依存のサブコンポーネントを含め、IIS が正しく再インストールされていることを確認します。

    IIS 6.0

    1. [スタート] ボタンをクリックし、[設定] をポイントします。次に、[コントロール パネル] をクリックします。

    2. [プログラムの追加と削除] をダブルクリックします。

    3. 左側のウィンドウで、[Windows コンポーネントの追加と削除] をクリックします。

    4. Windows コンポーネント ウィザードで、コンポーネント一覧からアプリケーション サーバーを特定し、[詳細] をクリックします。

    5. 次のコンポーネントでインストールされていないものがある場合は、そのコンポーネントをインストールします。

      ASP.NET

      Enable network COM+ access

      インターネット インフォメーション サービス (IIS)

    6. [インターネット インフォメーション サービス (IIS)] をクリックし、[詳細] をクリックします。

    7. 次のコンポーネントでインストールされていないものがある場合は、そのコンポーネントをインストールします。

      共通コンポーネント

      インターネット インフォメーション サービス マネージャ

      NNTP サービス

      SMTP サービス

      World Wide Web サービス

    8. [OK] を 2 回クリックします。メインの [Windows コンポーネント] ページで [次へ] をクリックし、[完了] をクリックします。

    IIS 5.0

    1. [スタート] ボタンをクリックし、[設定] をポイントします。次に、[コントロール パネル] をクリックします。

    2. [プログラムの追加と削除] をダブルクリックします。

    3. 左側のウィンドウで、[Windows コンポーネントの追加と削除] をクリックします。

    4. [Windows コンポーネント ウィザード] ダイアログ ボックスのコンポーネント一覧で、インターネット インフォメーション サービス (IIS) を見つけます。[インターネット インフォメーション サービス (IIS)] チェック ボックスがオンになっている場合、IIS はインストールされています。インストールされている IIS サブコンポーネントを表示するには、[インターネット インフォメーション サービス (IIS)] をクリックし、[詳細] をクリックします。

    5. IIS がインストールされていない場合は、[インターネット インフォメーション サービス (IIS)] チェック ボックスをオンにして、[詳細] をクリックします。IIS 5.0 サブコンポーネントをインストールし、[OK] をクリックします。Exchange 2000 をインストールする前に最小限必要な IIS 5.0 サブコンポーネントは、次のとおりです。

      共通コンポーネント

      インターネット インフォメーション サービス スナップイン

      SMTP サービス

      ネットワーク ニュース トランスポート プロトコル (NNTP) サービス (ニュースグループ用)

      World Wide Web サービス

    6. [次へ] をクリックし、[完了] をクリックします。

  4. Exchange SMTP サービス拡張を復元します。

    Exchange Server 2003

    既存の Exchange 2003 に Exchange 2003 を再インストールする場合、データベース ファイルとアクセス許可は失われません。それには、次の手順に従います。

    1. Exchange 2003 CD を挿入します。

    2. \SETUP\I386 フォルダで、Setup.exe ファイルをダブルクリックします。

    3. [ようこそ] ページで、[コンポーネントの選択] ページが表示されるまで [次へ] をクリックします。

    4. [コンポーネントの選択] ページで、[アクション] 列の [再インストール] をクリックし、[次へ] をクリックします。

    5. [インストールの概要] ページで選択内容を確認し、[次へ] をクリックして Exchange 2003 のインストールを続行します。

    Exchange 2000 Server

    Exchange 2000 SMTP サービス拡張の復元に使用できる方法は、削除された IIS サブコンポーネントの数によって異なります。削除された IIS サブコンポーネントが SMTP サービスだけで、Exchange 2000 Server Service Pack 2 (SP2) 以降の Service Pack がインストールされている場合は、Smtpreinstall.exe コマンド ライン ユーティリティを使用します。Smtpreinstall.exe コマンド ライン ユーティリティは、Server\Support\Utils\I386 フォルダにあります。

    Smtpreinstall.exe ユーティリティを使用するには、次の操作を行います。

    1. Smtpreinstall.exe ファイルを Exchsrvr\Bin フォルダにコピーします。

    2. コマンド プロンプトで Exchsrvr\Bin フォルダに変更し、次のコマンドを入力します。

      smtpreinstall.exe

    3. プロンプトが表示されたら、コンピュータを再起動します。

    IIS 5.0 がコンポーネントとして削除されている場合、または IIS 5.0 から SMTP サービスのサブコンポーネント以外のコンポーネントが削除されている場合は、Microsoft Small Business Server 2000 の統合セットアップの一環として、既存のインストールに Exchange 2000 を再インストールします。

    Exchange 2000 Server を再インストールするには、次の操作を行います。

    注 :
    既存の Exchange 2000 に Exchange 2000 を再インストールする場合、データベース ファイルとアクセス許可は失われません。
    1. Exchange 2000 Server CD を挿入します。

    2. \SETUP\I386 フォルダで、Setup.exe ファイルをダブルクリックします。

    3. [ようこそ] ページで、[次へ] をクリックします。

    4. プロンプトが表示されたら CD キーを入力し、[次へ] をクリックします。

    5. [コンポーネントの選択] ページで、[アクション] 列の [再インストール] をクリックし、[次へ] をクリックします。

    6. [インストールの概要] ページで選択内容を確認し、[次へ] をクリックして Exchange 2000 のインストールを続行します。

  5. Exchange Service Pack と修正プログラムを再インストールします。

    詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

    文書番号 836993「Exchange Server 2003 用の最新の更新プログラムと Service Pack の入手方法」

    文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」


MSExchangeIS 5000 (0xc004038a): アクセス許可が正しくないか、またはルーティング グループが削除されたためにデータベースをマウントできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-05-31

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 5000 イベント (エラー コード 0xc004038a) が検出されました。このエラーが発生すると、Microsoft Exchange Information Store サービスは初期化されず、データベースはマウントされません。

説明

エラーコード 0xc004038a を含むイベント MSExchangeIS 5000 は、アクセス許可が正しくないため、またはルーティング グループが削除されたために発生します。このイベントは、次のいずれかの原因で発生する可能性があります。

  • Exchange Server がルーティング グループのメンバでなくなったか、またはそのルーティング グループが Active Directory から削除された。

  • Exchange Domain Servers グループが Active Directory で適切なアクセス許可を持っていない。

このイベントは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

このエラーを解決するには、次のいずれかの操作を行います。

  • Exchange Domain Servers グループが適切なアクセス許可を持っていない場合は、Active Directory サービス インターフェイス (ADSI) Edit ユーティリティを使用して、Exchange Domain Servers グループが Active Directory で必要なアクセス許可を持つようにします。Administrators グループ、Exchange Domain Servers グループ、およびその他構成に関係するグループの [セキュリティ] タブで [親からの継承可能なアクセス許可をこのオブジェクトとすべての子オブジェクトに伝達できるようにします] チェック ボックスがオンになっていることを確認します。

    注 :
    必要に応じてドメイン コントローラ間でレプリケーションを強制し、変更がドメイン全体に伝達されるようにします。
    注 :
    ADSI Edit ツールは、Windows 2000 および Windows 2003 のインストール CD の Microsoft Windows 2000 サポート ツールおよび Microsoft Windows Server 2003 サポート ツールに収められています。
  • Exchange サーバーがルーティング グループのメンバでなくなっている場合、またはそのルーティング グループが Active Directory から削除された場合は、ルーティング グループを追加するか、ルーティング グループを復元します。以下の解決策のうち、シナリオに最も当てはまる解決策に従ってください。

解決策 1: サーバーをルーティング グループに追加します。次の手順に従って、サーバーがルーティング グループのメンバになっていないことを確認します。

  1. Exchange システム マネージャを起動します。

  2. [組織]、[管理グループ]、[AdministrativeGroupName]、[ルーティング グループ] の順に展開します。

    注 :
    この手順で、AdministrativeGroupName は管理グループの名前を意味します。
  3. 使用可能なすべてのルーティング グループを参照して、このサーバーが含まれていないことを確認します。

    注 :
    ルーティング グループが 1 つも表示されない場合は、解決策 2 を参照してください。
  4. このサーバーがルーティング グループのメンバでないことを確認したら、サーバーを既存のルーティング グループに戻します。それには、次の手順に従います。

    重要 :
    ADSI Edit スナップイン、LDAP ユーティリティ、またはその他の LDAP Version 3 クライアントを使用して Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows 2000 Server、Microsoft Windows Server 2003、Microsoft Exchange 2000 Server、Microsoft Exchange Server 2003 のいずれか、または Windows と Exchange の両方の再インストールが必要になる場合があります。Microsoft は、Active Directory オブジェクトの属性を誤って変更したために発生する問題について、その解決を保証いたしません。これらの属性の変更は、ご自身の責任で行ってください。
サーバーをルーティング グループに戻すには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「adsiedit.msc」と入力し、[OK] をクリックします。

    注 :
    ADSI Edit ツールは、Microsoft Windows 2000 サポート ツールおよび Microsoft Windows Server 2003 サポート ツールに含まれています。これらのサポート ツールをインストールするには、次の手順に従います。
    • Windows 2000 Server ベースのコンピュータの場合は、Windows 2000 CD の Support\Tools フォルダにある Setup.exe をダブルクリックし、Windows サポート ツール セットアップ ウィザードの手順に従って Windows 2000 サポート ツールをインストールします。

    • Windows Server 2003 ベースのコンピュータの場合は、Windows Server 2003 CD の Support\Tools フォルダにある Suptools.msi を右クリックし、[インストール] をクリックして、Windows サポート ツール セットアップ ウィザードの手順に従って Windows Server 2003 サポート ツールをインストールします。

  2. [Configuration [servername.domain_name.com]]、[CN=Configuration]、[DC= domain_name]、[DC= com]、[CN=Services]、[CN=Microsoft Exchange]、[CN= OrganizationName]、[CN=Administrative Groups]、[CN= AdministrativeGroupName] の順に展開して、[CN=Routing Groups] をクリックします。

    注 :
    この手順で、servername はサーバー名、domain_name.com はドメイン名、OrganizationName は Exchange Server 組織の名前、AdministrativeGroupName は管理グループの名前を意味します。

  3. このサーバーをメンバにするルーティング グループを右クリックし、[プロパティ] をクリックします。

  4. [distinguishedName] 属性をクリックして、[編集] をクリックします。

  5. distinguishedName 属性の値をメモ帳にコピーします。

  6. [キャンセル] を 2 回クリックしてプロパティを閉じます。

  7. ADSIEdit ツールで、[Configuration [servername.domain_name.com]]、[CN=Configuration,DC= domain_name]、[DC= com]、[CN=Services]、[CN=Microsoft Exchange]、[CN= OrganizationName]、[CN=Administrative Groups]、[CN= AdministrativeGroupName]、[CN=Servers] の順に展開します。

  8. サーバー名を右クリックし、[プロパティ] をクリックします。

  9. [msExchHomeRoutingGroup] 属性をクリックし、[編集] をクリックします。

  10. 手順 5. でメモ帳にコピーした値を貼り付け、[OK] を 2 回クリックして新しい値を保存します。

  11. Exchange システム マネージャで、このサーバーを追加したルーティング グループを見つけます。

  12. Exchange システム マネージャを更新すると、このサーバーが表示されます。

    注 :
    Exchange サーバーがすぐに表示されない場合は、Active Directory のレプリケーションが実行されるまで待ちます。

  13. このルーティング グループ内に、[サーバーの種類] が [マスタ] に設定されている Exchange サーバーが他にない場合は、この Exchange サーバーを右クリックし、[マスタに設定] をクリックします。

  14. Information Store サービスと MTA Stacks サービスを開始します。

解決策 2: ルーティング グループを復元します。ルーティング グループを誤って削除した場合は、システム状態データの最新のバックアップを使用してルーティング グループを復元します。システム状態データの最近のバックアップがなく、ドメイン コントローラが複数ある場合は、削除したルーティング グループについて、権限のある復元操作を実行します。

ルーティング グループを復元するには、次の操作を行います。

  1. Exchange システム マネージャを起動し、削除したルーティング グループと同じ名前で新しいルーティング グループを作成します。それには、次の手順に従います。

    1. [管理グループ]、[AdministrativeGroupName]、[ルーティング グループ] の順に展開します。

      この手順で、AdministrativeGroupName は管理グループの名前を意味します。

    2. [ルーティング グループ] を右クリックし、[新規] をポイントします。次に、[ルーティング グループ] をクリックします。

    3. [名前] ボックスにルーティング グループの名前を入力し、[OK] をクリックします。

      誤って削除したルーティング グループと同じ名前を使用します。

    4. Exchange システム マネージャを終了します。

  2. ADSI Edit を起動します。それには、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスに「adsiedit.msc」と入力し、[OK] をクリックします。

    注 :
    ADSI Edit ツールは、Microsoft Windows 2000 サポート ツールおよび Microsoft Windows Server 2003 サポート ツールに含まれています。これらのサポート ツールをインストールするには、次の操作を行います。
    • Windows 2000 Server ベースのコンピュータの場合は、Windows 2000 CD の Support\Tools フォルダにある Setup.exe をダブルクリックし、Windows サポート ツール セットアップ ウィザードの手順に従って Windows 2000 サポート ツールをインストールします。

    • Windows Server 2003 ベースのコンピュータの場合は、Windows Server 2003 CD の Support\Tools フォルダにある Suptools.msi を右クリックし、[インストール] をクリックして、Windows サポート ツール セットアップ ウィザードの手順に従って Windows Server 2003 サポート ツールをインストールします。

  3. [Configuration [servername.domain_name.com]]、[CN=Configuration]、[DC=domain_name]、[DC=com]、[CN=Services]、[CN=Microsoft Exchange]、[CN=OrganizationName]、[CN=Administrative Groups]、[CN=AdministrativeGroupName] の順に展開して、[CN=Routing Groups] をクリックします。

    この手順で、servername はサーバー名、domain_name.com はドメイン名、OrganizationName は Exchange Server 組織の名前、AdministrativeGroupName は管理グループの名前を意味します。

  4. 右側のウィンドウで、新しく作成したルーティング グループを右クリックして、[プロパティ] をクリックします。

  5. [必須属性を表示する] チェック ボックスと [オプション属性を表示する] チェック ボックスをオンにします。

  6. [属性] 一覧で、[msExchRoutingGroupMembersBL] をクリックし、[編集] をクリックします。

    [値] 一覧は空白になっています。

  7. [キャンセル] をクリックします。

  8. [属性] 一覧で、[distinguishedName] をダブルクリックします。

  9. [値] ボックスの識別名を右クリックし、[コピー] をクリックします。

  10. メモ帳などのテキスト エディタを開き、[編集] メニューの [貼り付け] をクリックして、識別名を貼り付けます。

  11. [文字列の属性エディタ] ダイアログ ボックスで、[キャンセル] をクリックします。次に、[キャンセル] をクリックして [CN=RoutingGroupName] ダイアログ ボックスを閉じます。

    この手順で、RoutingGroupName はルーティング グループの名前を意味します。

  12. ADSI Edit の [CN=AdministrativeGroupName] で [CN=Servers] をクリックします。

  13. 右側のウィンドウで [CN=ServerName] を右クリックし、[プロパティ] をクリックします。

    この手順で、ServerName はこのルーティング グループ内の Exchange コンピュータの 1 つを意味します。

  14. [属性] の一覧で、[msExchHomeRoutingGroup] をクリックし、[編集] をクリックします。

  15. [値] ボックスで、手順 9. および 10. でコピーした識別名を貼り付けて、[OK] をクリックします。

  16. [適用] をクリックし、[OK] をクリックします。

  17. 誤って削除したルーティング グループのメンバだった各サーバーに対して、手順 13. から 15. を実行します。

  18. [CN=AdministrativeGroupName] で、[CN=Routing Groups] をクリックします。

  19. 右側のウィンドウで、新しく作成したルーティング グループを右クリックして、[プロパティ] をクリックします。

  20. [属性] 一覧で、[msExchRoutingGroupMembersBL] をクリックし、[編集] をクリックします。

    [値] の一覧に値が表示されるようになります。

  21. [キャンセル] を 2 回クリックします。

  22. ADSI Edit を終了します。

  23. Exchange システム マネージャを使用して、ルーティング グループ マスタを設定します。それには、次の手順に従います。

    1. Exchange システム マネージャを起動します。

    2. [管理グループ]、[AdministrativeGroupName]、[ルーティング グループ] の順に展開します。

    3. 新しく作成したルーティング グループを展開し、[メンバ] をクリックします。

    4. 右側のウィンドウで、ルーティング グループ マスタとして構成する Exchange コンピュータを右クリックし、[マスタに設定] をクリックします。

    5. Exchange システム マネージャを終了します。

  24. ドメイン全体に変更が伝達されるまで待ちます。

  25. 停止していた Microsoft Exchange サービスを再開します。


MSExchangeIS 5000 (0x8004010f): アクセス許可が間違っているか、または組織名の文字が無効なため、データベースをマウントできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 5000 イベント (エラー コード 0x8004010f) が検出されました。このイベントは、アクセス許可の誤り、または Exchange 組織名に無効な文字が含まれていることが原因で、Exchange サーバーでデータベースがマウントできないことを示しています。

説明

エラー コード 0x8004010f が含まれる MSExchangeIS 5000 イベントは、以下の条件のいずれかに当てはまる場合に発生する可能性があります。

  • 認証されたユーザーに、Active Directory のドメイン コンテナまたは構成コンテナに対する読み取りアクセス権がありません。この条件が当てはまる場合、既に Exchange サーバーが存在する管理グループ内に 2 番目の Exchange サーバーをインストールしようとしても、インストールできない可能性があります。また、Microsoft Exchange Information Store サービスを開始できない可能性があります。

  • Everyone アカウントに、Active Directory の構成コンテナ内の既知のセキュリティ プリンシパル コンテナに対する読み取りアクセス許可がありません。この条件が当てはまる場合、メンバ サーバー上で Exchange Information Store サービスが開始されません。

  • Exchange 組織名にサポートされていない文字が含まれています。この条件が当てはまる場合、Exchange 2000 Server または Exchange Server 2003 をインストールした後に、Exchange Information Store サービスが開始されない可能性があります。また、アプリケーション ログにイベント MSExchangeIS 5000 および MSExchangeIS 1121 が出力されている可能性があります。

このイベントは、MAPI_E_NOT_FOUND として識別されることもあります。このイベントは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

重要 :
Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP ユーティリティ、またはその他の任意の LDAP Version 3 クライアントを使用する際に、Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows® 2000 Server、Microsoft Windows Server™ 2003、Microsoft Exchange 2000 Server、Microsoft Exchange Server 2003 のいずれか、または Windows と Exchange 両方の再インストールが必要になる場合があります。Microsoft は、Active Directory オブジェクトの属性を誤って変更したために発生する問題について、その解決を保証いたしません。これらの属性の変更は、ご自身の責任で行ってください。
  • 認証されたユーザーに Active Directory のドメイン コンテナまたは構成コンテナに対する読み取りアクセス権がない場合は、Exchange Server 2003 および Exchange 2000 Server で ADSI Edit ツールを使用して、ユーザーに Active Directory のドメイン コンテナおよび構成コンテナに対する読み取りアクセス権を与えます。次の手順に従います。

    注 :
    ADSI Edit ツールは Microsoft Windows 2000 サポート ツールおよび Microsoft Windows Server 2003 サポート ツールに含まれています。Windows サポート ツールをインストールするには、Windows CD-ROM 内の Support\Tools フォルダにあるセットアップ プログラムを実行します。Windows サポート ツールの詳細については、Windows CD-ROM 内の Support\Tools フォルダにある Sreadme.doc ファイルを参照してください。
認証されたユーザーに Active Directory のドメイン コンテナまたは構成コンテナに対する読み取りアクセス権を与えるには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「adsiedit.msc」と入力し、[OK] をクリックします。

  2. [Domain NC] コンテナを展開し、ドメインのフォルダ (DC=domain、DC=com) を右クリックします。次に、[プロパティ] をクリックして、フォルダのプロパティを開きます。

  3. [セキュリティ] タブをクリックし、[Authenticated Users] グループに [許可] 列で [読み取り] アクセス権が選択されていることを確認します。[読み取り] が選択されていない場合、[読み取り] をクリックして選択し、[OK] をクリックします。

  4. [Configuration Container] を展開し、構成のフォルダ (CN=Configuration、DC=domain、DC=com) を右クリックします。次に、[プロパティ] をクリックして、フォルダのプロパティを開きます。

  5. [セキュリティ] タブをクリックし、[Authenticated Users] グループに [許可] 列で [読み取り] アクセス権が選択されていることを確認します。[読み取り] が選択されていない場合、[読み取り] をクリックして選択し、[OK] をクリックします。

  6. ADSI Edit を終了します。

  7. ドメイン コントローラ間で変更がレプリケートされるまで待ちます。

  8. Information Store サービスを開始します。
  • Everyone アカウントに Active Directory の構成コンテナ内の既知のセキュリティ プリンシパル コンテナに対する読み取りアクセス許可がない場合、以下の手順に従って問題を解決してください。

Active Directory の既知のセキュリティ プリンシパル コンテナの Everyone アカウントに対する読み取りアクセス権を与えるには、次の操作を行います。

  1. ドメイン管理者としてログオンし、ADSI Edit を起動します。

  2. [構成] コンテナを展開し、[CN=WellKnown Security Principals] コンテナをクリックします。

  3. [プロパティ] を右クリックし、[セキュリティ] タブをクリックします。

  4. [追加] をクリックし、「everyone」と入力します。次に、[OK] をクリックします。

  5. [許可] 列で、[読み取り] チェック ボックスをオンにします。
  • Exchange 組織名に無効な文字が含まれている場合は、組織名から無効な文字を削除してください。無効な文字の詳細については、マイクロソフト サポート技術情報の文書番号 329599「Exchange Information Store サービスが開始されず、イベント 1121 および 5000 がログ出力される」を参照してください。


MSExchangeIS 9518 (0xfffffddc): このストレージ グループで使用可能なトランザクション ログの最大数を超えた
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-22

Microsoft® Exchange Server Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffddc) が検出されました。これは、このストレージ グループで使用可能なトランザクション ログの最大数を超えたことを示しています。

説明

ストレージ グループのデータベースのマウントを試みたときに次の両方の条件が当てはまる場合、MSExchangeIS 9518 イベント (エラー コード 0xfffffddc) がログに記録されます。

  • このストレージ グループで使用可能なトランザクション ログの最大数を超えた。

  • このストレージ グループ内のすべてのデータベースがクリーン シャットダウン状態である。

この場合、対象のデータベースがシャットダウンする前に、アプリケーション ログに MSExchangeIS 1159 イベント (エラー コード 0xfffffdf9) も記録されます。このイベントは、Exchange Server が、このストレージ グループで使用可能なトランザクション ログ ファイルをすべて使い尽くしたことを示しています。最後のトランザクション ログがいっぱいになると、このストレージ グループ内のすべてのデータベースがマウント解除され、再起動できなくなります。

Exchange が使用するトランザクション ログ ファイルには、連続した番号が付加されます。Exchange 2000 Server および Exchange Server 2003 では、トランザクション ログ ファイルは Exx00001.log から開始し、ExxFFFF0.log まで順に増分します。よって、1 回のシーケンスで生成できるトランザクション ログ ファイルの最大数は、1,048,560 個 (0xFFFF0) です。一般的に、これだけ多数のログ ファイルが生成されるには、数年間の運用期間が必要です。

Exchange Server 2007 では、トランザクション ログ ファイルにはさらに余裕があります。ログ ストリームには、最大 2,147,483,647 個のログ ファイルが使用できます (16 進数の 0x7FFFFFFF、ログ ファイル名は 16 進数で表されるため)。各トランザクション ログ ファイルは 1 MB です。よって、Exchange Server 2007 でこのエラーが発生する可能性はほとんどありません。

ユーザーの操作

このエラーを解決するには、すべてのトランザクション ログ ファイルを削除し、トランザクション ログ ファイルのシーケンスをリセットして 1 に戻します。ログ ファイルのシーケンスをリセットすると、ログ ファイルの名前は、Exchange Server 2003 またはそれ以前のバージョンでは Exx00001.log、Exchange Server 2007 では Exx00000001.log になります。

この操作を実行するには、Microsoft Exchange トラブルシューティング アシスタントの Database Recovery Management ツールに含まれている、ログの世代番号のリセット処理を使用します。このツールは、すべてのデータベースが正しくシャットダウンされたことを確認してから、すべてのトランザクション ログ ファイルをバックアップ場所に安全に移動します。

注 :
トランザクション ログ ファイルは手動で削除することもできますが、手動による削除では、ストレージ グループ内のデータベースが正しくシャットダウンせず、データベースを再マウントできなくなる場合があります。このような障害の発生を防ぐために、Database Recovery Management ツールを使用することをお勧めします。

ツールの詳細、およびダウンロードについては、Microsoft Exchange トラブルシューティング アシスタント Version 1.0 に関するページを参照してください (このサイトは英語の場合があります)。


MSExchangeIS 9518 (0xfffff745): TMP ファイルの作成またはアクセスができない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffff745) が検出されました。このエラーは、Exchange が TMP システム環境変数または TEMP システム環境変数で指定されたフォルダ内にファイルを作成できないか、またはそこにあるファイルにアクセスできない場合に発生します。

説明

以下の条件のいずれかに当てはまる場合、この問題が発生することがあります。

  • TMP 環境変数または TEMP 環境変数が指し示しているパスが使用できないか、または読み取り専用です。たとえば、TMP 環境変数がリモート ドライブやストレージ エリア ネットワーク (SAN) にマッピングされており、そのマッピングされたドライブや SAN が使用できなくなったときにこの問題が発生します。

  • TMP 環境変数または TEMP 環境変数のレジストリ設定が正しくありません。

  • Exchange に、ドライブのルートからトランザクションログおよびデータベースに至るまでのフルコントロール アクセス許可がありません。

ユーザーの操作

この問題を解決するには、以下のいずれかの操作を行います。

注 Microsoft Windows には複数のバージョンが存在し、以下の手順はコンピュータによって異なる場合があります。その場合は、製品ドキュメントを参照して手順を実行してください。

  • TMP 環境変数および TEMP 環境変数の両方が Windows 内の有効な場所を指し示していることを確認します。それには、次の手順に従います。

    TEMP 変数および TMP 変数に有効なパスを設定するには、次の操作を行います。

    1. [スタート] ボタンをクリックし、[設定] をポイントします。次に、[コントロール パネル] をクリックします。

    2. [システム] をダブルクリックし、[詳細設定] タブをクリックします。次に [環境変数] をクリックします。

    3. [システム環境変数] で、[TEMP] をクリックし、[編集] をクリックします。

    4. [変数値] ボックスに表示されているパスが有効なものでない場合は、TEMP 変数の有効なパスを入力し、[OK] をクリックします。たとえば、「%systemroot%\Temp」と入力し、[OK] をクリックします。

    5. [システム環境変数] で、[TMP] をクリックし、[編集] をクリックします。

    6. [変数値] ボックスに表示されているパスが有効なものでない場合は、TMP 変数の有効なパスを入力し、[OK] をクリックします。たとえば、「%systemroot%\Temp」と入力し、[OK] をクリックします。

    7. [OK] を 2 回クリックし、[システムのプロパティ] ダイアログ ボックスを閉じます。

    8. コンピュータを再起動します。
  • ローカルの Administrators グループまたは SYSTEM アカウントに、Temp フォルダに対するフル コントロール アクセス許可が割り当てられているか確認します。Domain Admins グループにフル コントロール アクセス許可を割り当てるだけでは不十分です。既定では、システム環境変数 TMP および TEMP のいずれにも、次のパスが指定されています。

    %SYSTEMROOT%\Temp

    Exchange は、SYSTEM アカウントを使用してこのフォルダの場所にアクセスする必要があります。このアクセス許可を確認するには、次の手順に従います。

    Temp フォルダのアクセス許可を確認するには、次の操作を行います。

    1. [スタート] を右クリックし、[エクスプローラ] をクリックします。

    2. システム環境変数で指定されている Temp フォルダを右クリックし、[プロパティ] をクリックします。通常、このフォルダは %systemroot%\Temp です。

    3. [セキュリティ] タブをクリックします。

    4. [名前] の一覧で [SYSTEM] をクリックすると、割り当てられているアクセス許可が [アクセス許可] の一覧に表示されます。
    Temp フォルダのアクセス許可が正しい場合は、Exchange データベース ファイルまたは Exchange ログ ファイルが格納されている各ドライブのアクセス許可を確認します。SYSTEM アカウントには、Exchange データベース ファイルまたは Exchange トランザクション ログ ファイルが格納されているドライブのルートおよび各フォルダに対して、フル コントロール アクセス許可が割り当てられている必要があります。たとえば、C:\Exchsrvr\Mdbdata フォルダにトランザクション ログがある場合、SYSTEM アカウントには、ドライブ C のルート ディレクトリ、Exchsrvr フォルダ、および Mdbdata フォルダに対するフル コントロール アクセス許可が必要になります。

  • 問題がレジストリ設定の誤りであるかどうかをチェックします。次の手順に従います。

    レジストリ設定を確認するには、次の操作を行います。

    1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedt32.exe」と入力し、[OK] をクリックします。

    2. 次のレジストリ キーを見つけます。

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

    3. TMP (または TEMP) の名前を見つけます。このキーの種類は、REG_EXPAND_SZ になっている必要があります。

    4. いずれかのキーが正しくない場合は、Environment サブキーをバックアップしてから、右側の TMP 値または TEMP 値を削除します。

    5. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Sysdm.cpl」と入力し、[OK] をクリックします。

    6. [詳細設定] タブで、[環境変数] をクリックします。

    7. [システム環境変数] の一覧に、手順 4. で削除した値がないことを確認します。

      注 :
      TEMP 変数または TMP 変数を確認するために、下にスクロールすることが必要な場合もあります。

    8. [新規] をクリックします。[変数名] ボックスに、手順 4. で削除した名前を入力します。たとえば、「C:\Winnt\TEMP」と入力します。

    9. [OK] を 3 回クリックし、その後コンピュータを再起動します。


MSExchangeIS 9518 0xfffffbc4: ログ ファイルのパスが既に使用されている
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-05-14

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffbc4) が検出されました。このエラー コードは、1 つ以上のストレージ グループが、同じログ ファイルのパスまたはシステム ファイルのパスを使用するように構成されていることを示しています。

説明

このエラーは、複数のストレージ グループが同じログ ファイルのパス、またはシステム ファイルのパスを使用するように構成されている場合に発生することがあります。Exchange では、各ストレージ グループがログおよびシステム ファイルについて固有のパスを使用する必要があります。

ユーザーの操作

この問題を解決するには、各ストレージ グループに固有のログ ファイルのパスと、システム ファイルのパスが構成されていることを確認します。

注 :
個別のストレージ グループは同じログ ファイルのパスおよびシステム ファイルのパスを共有できます。ただし、その同じパスを別のストレージ グループのログ ファイルのパスや、システム ファイルのパスとして使用することはできません。
Exchange 2000 Server または Exchange Server 2003 で、ログ ファイルのパスおよびシステム ファイルのパスを確認または設定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. [全般] タブの [トランザクション ログの場所] で、[参照] をクリックします。

  4. [ログ ファイルのパス] と [システム ファイルのパス] が、ストレージ グループに固有であることを確認します。

  5. ストレージ グループの [ログ ファイルのパス] および [システム ファイルのパス] がそのストレージ グループに固有でない場合は、ログ ファイル、システム ファイル、またはその両方の新しい場所のパスを入力し、[OK] をクリックします。

  6. [OK] をクリックします。
Exchange Server 2007 で、ストレージ グループのログ ファイルのパスおよびシステム ファイルのパスを確認または設定するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、[メールボックス] を選択します。

  3. [メールボックス] ウィンドウで、操作するサーバーを選択します。

  4. [データベースの管理] ウィンドウで、操作するストレージ グループを右クリックし、[プロパティ] をクリックします。

  5. [ログ ファイルのパス] と [システム ファイルのパス] が、ストレージ グループに固有であることを確認します。

  6. ストレージ グループの [ログ ファイルのパス] および [システム ファイルのパス] が、そのストレージ グループに固有でない場合、Exchange Server 2007 ドキュメントの、ストレージ グループのログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80702) に記載されている手順に従って、各ストレージ グループで固有の場所となるファイルのパスを設定します (このサイトは英語の場合があります)。

Exchange Server 2003 上でのログ ファイルの移動の詳細については、Microsoft サポート技術情報の文書番号 821915「Exchange Server 2003 で Exchange のデータベースおよびログを移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915) を参照してください。

Exchange 2000 Server 上でのログ ファイルの移動の詳細については、Microsoft サポート技術情報の文書番号 239944「[XADM] トランザクションまたはシステム ログを別の場所に移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239944) を参照してください。


MSExchangeIS 9518 (0xfffffd9a): チェックポイント ファイルが存在せず、1,008 個を超えるトランザクション ログ ファイルが存在する
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffd9a) が検出されました。このエラーは、このストレージ グループにチェックポイント ファイル (Exx.chk) が存在しないかまたは削除されており、かつデータベースに対して再生されるトランザクション ログ ファイルが 1,008 個を超えていることを示しています。

説明

以下の条件のいずれかに当てはまる場合、この問題が発生することがあります。

  • ログ ファイルとデータベースが正常にシャットダウンされており、回復しなければならない障害は発生していない。

  • Exx.chk チェックポイント ファイルの名前が変更されたか、または削除されている。

  • サーバー上に、チェックポイント間で再生されるログ ファイルが 1,008 個以上ある。

  • "ロール フォワード" 回復の際に、ストレージ グループ内の 1 つまたは複数のデータベースが失われているが、回復の時点でサーバー上のログ ファイルは損なわれていない。"ロール フォワード" 回復操作が正常に完了していない。

この状況では、Microsoft Exchange Information Store サービスはソフト リカバリを実行して、起動時にすべてのログ ファイルを再生します。ログ ファイルとデータベースは正常にシャットダウンされているため、実行する必要のある回復はありません。チェックポイントがないため、Exchange はクリーン シャットダウンのレコードに到達するまですべてのログを処理します。ログ ファイルの数が 1,008 個を超えているため、Exchange はクリーン シャットダウン状態のレコードを見つける前にログ ファイル数の制限である 1,008 に到達します。

注 :
上記の条件に当てはまる場合、eseutil /r コマンドを使用してログ ファイルを再生する際にもここで説明した兆候が発生することがあります。eseutil /r コマンドは、メールボックス ストアのソフト リカバリも実行します。

このエラーは、エラー JET_errCheckpointDepthTooDeep, -614 として識別されることもあります。このエラーは、Microsoft Exchange Server 2003 のみに当てはまります。

ユーザーの操作

Exchange Server 2003 でこの問題を解決するには、Microsoft サポート技術情報の文書番号 836611「Exchange Server 2003 コンピュータの起動時にインフォメーション ストア データベースがマウントされず、"Operation terminated with error -614" というエラー メッセージが表示される」で説明されている修正プログラムを適用してください。


MSExchangeIS 9518 0xfffffb40: データベース ファイルが見つからない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-05-23

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffb40) が検出されました。これは、ストレージ グループの 1 つ以上のデータベース ファイルが見つからないことを示しています。

説明

このエラーは、ESE (Extensible Storage Engine) が、回復時にストレージ グループ内のすべてのデータベースを整合状態にしようとした際、データベース ファイルが見つからないか、または異なるバージョンに置き換えられていることを検出したときに発生する可能性があります。

ストレージ グループのいずれかのデータベース ファイルが見つからない、または異なるバージョンに置き換えられている場合、ESE はエラー -1216 を返し、回復を中断し、ストレージ グループを開始しません。

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • 方法 1: データベース ファイルが移動されている、または名前が変更されていることによって見つからない場合は、アプリケーション ログで、データベースのマウントの試行後に発生した ESE 494 イベントを探します。それぞれのイベントで見つからないと報告されているデータベース ファイルをメモして、そのファイルの現在の場所を見つけて、正しい場所に移動します。

注 :
このサーバーにファイルレベルのウイルス対策ソフトウェアがインストールされており、除外対象が正しく構成されていない場合、ウイルス対策ソフトウェアによってデータベースが削除または検疫された可能性があります。ウイルス対策ソフトウェアの検疫および削除に関するログを調べ、このような操作が行われていないかどうかを確認します。
  • 方法 2:

    • 方法 2-A: データベース ファイルを削除または消失したことによって見つからない場合は、そのファイルをバックアップから運用ストレージ グループに復元します。Exchange Database Recovery Management ツールの [データベースおよびトランザクション ログ ファイルの検証] タスクを使用して、復元対象のデータベース ファイルを使用して復元を実行可能かどうかを確認できます。

      このデータベース ファイルの復元中に、次の手順を実行して、ストレージ グループ内のその他の問題のないデータベースをマウントし、アクセスすることもできます。

問題のないデータベースに対するメールボックス アクセスをユーザーに許可するには、次の操作を行います。

  1. eseutil /R /L <Path to Log Files> /S <Path to System Files> Log Base Name /I を実行します ("Log Base Name" は、このストレージ グループのログ ファイルの最初の 3 文字、たとえば E00 や E01 などです)。これによって、ESE は存在するデータベース ファイルを整合状態にし、存在しないデータベース ファイルは無視します。このコマンドの実行後に、存在しないデータベース ファイルをバックアップから復元する必要があります。
注 :
/L および /S スイッチは省略可能で、ログ ファイルおよびシステム ファイルが置かれている場所から eseutil を実行する場合には指定する必要はありません。
  1. ストレージ グループ内に存在し、整合状態になったデータベース ファイルをマウントします。

  2. これによってマウントされたデータベースにホストされているメールボックスのユーザーは、メールにアクセスできるようになります。
  • 方法 2-B: バックアップからデータベース ファイルを回復用ストレージ グループに復元します。新しいデータベースで開始することによって、送受信の機能をすばやく提供することもできます (これをダイヤル トーン回復と呼びます)。この場合、クライアントには空のメールボックスが表示されますが、復元や修復が完了するのを待つよりも早く送受信を行うことができます。

注 :
ダイヤル トーン オプションを使用する場合、新しい (ダイヤル トーン後の) データと、復元されたデータを後で結合する必要があります。

ダイヤル トーン回復の詳細については、Exchange 2007 製品ドキュメントの障害回復のトピックにある、ダイヤル トーンのポータビリティについてのページを参照してください。

回復用ストレージ グループの詳細については、Exchange 2007 製品ドキュメントの障害回復のトピックにある、回復用ストレージ グループについてのページを参照してください。
  • 方法 3: ストレージ グループ内の 1 つ以上のデータベースに対してハード修復操作 (手動、または Exchange トラブルシューティング アシスタントの [データベースの修復] タスクのいずれか) を実行し、データベースが整合状態になっている場合に、ストレージ グループのログ ファイルが削除されていなかったことが考えられます。ストレージグループのすべてのデータベースが正しい場所にある場合、次のコマンドを実行し、すべてのデータベースが整合状態にあることを確認します。

データベース ファイルの整合状態を手動で確認するには、次の操作を行います。

  1. eseutil /mh <path to database .edb file> を実行します。

  2. このコマンドの出力から、"状態 :" フィールドを探し、値が "クリーン シャットダウン" であることを確認します。

  3. ストレージ グループのすべてのデータベースがクリーン シャットダウン状態の場合、そのストレージ グループのすべてのトランザクション ログとシステム ログをバックアップの場所へ移動してから、ストアのマウントを試みます。すべてのデータベースを正常にマウントできた場合、ストレージ グループのバックアップを直ちに作成することをお勧めします。

詳細情報

MSExchangeIS 9518 イベント (エラー コード 0xfffffb40) の詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=91705) を参照してください (このサイトは英語の場合があります)。

このエラーから回復する方法の詳細については、Microsoft サポート技術情報の文書番号 296843「エラー -1216 の後に Exchange 2000 Server データベースを回復する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=296843) を参照してください。

Exchange 障害回復計画の詳細については、Exchange 障害回復計画ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=91706) を参照してください (このサイトは英語の場合があります)。

データベース回復管理およびデータベース トラブルシューティング ウィザードの詳細については、Database Recovery Management ツールおよび Database Troubleshooter ツールについてのページ (http://go.microsoft.com/fwlink/?LinkId=91707) を参照してください (このサイトは英語の場合があります)。

ダイヤル トーン回復の詳細については、Exchange 2007 製品ドキュメントの障害回復のトピックにある、ダイヤル トーンのポータビリティについてのページ (http://go.microsoft.com/fwlink/?LinkId=91703) を参照してください (このサイトは英語の場合があります)。

回復用ストレージ グループの詳細については、Exchange 2007 製品ドキュメントの障害回復のトピックにある、回復用ストレージ グループについてのページ (http://go.microsoft.com/fwlink/?LinkID=80784) を参照してください (このサイトは英語の場合があります)。


MSExchangeIS 9518 (0xfffffea8): データベース ファイルのデータベース タイム スタンプが一致しない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffea8) が検出されました。このエラーは、対象のデータベースの現在のページの dbtime が、そのデータベースのグローバル データベース dbtime よりも大きい場合に発生します。

説明

このエラーが発生すると、対象のメールボックスまたはパブリック フォルダ データベースがマウントされなくなります。このエラーは、JET_errDbTimeCorrupted としても識別されます。

このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

データベース タイム スタンプの不一致を解決するには、eseutil /d コマンドを実行してこの問題が発生しているデータベースを最適化し、その後データベースをマウントします。eseutil /d の実行方法の詳細については、Eseutil /D (最適化) の実行方法についてのページ (このサイトは英語の場合があります)、および Microsoft サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」を参照してください。


MSExchangeIS 9518 (0xfffff764): ストリーミング ファイルが存在しないか、アクセスできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffff764) が検出されました。このエラーは、Exchange が、データベースに関連付けられたストリーミング ファイル (.stm) にアクセスできない場合に発生することがあります。

説明

このエラーは、データベースに関連付けられたストリーミング ファイル (.stm) が削除または移動された場合、あるいはアクセス許可が変更されたために Exchange がストリーミング ファイルにアクセスできない場合に発生することがあります。

注 :
状況によっては、ウイルス対策プログラムによって .stm ファイルなどの Exchange ファイルが削除されたり、アクセス許可が変更されることがあります。Microsoft Exchange のベスト プラクティスとして、Exchange ディレクトリはウイルス スキャンから除外することが推奨されますが、これが行われていない場合にこの状況が発生します。この件に関する詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」を参照してください。

このエラーは、-2204 として識別されることもあります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • データベースのバックアップ コピーからストリーミング ファイルを復元します。

  • ウイルス対策ソフトウェアによってストリーミング ファイルが検疫フォルダに移動されていないか調べます。ストリーミング ファイルが検疫フォルダに見つかった場合は、元の場所に移動して、ウイルス対策プログラムが Exchange Server 2003 フォルダをスキャンしないように構成します。

    注 :
    ウイルス対策プログラムによっては、ファイルが検疫フォルダに移動されるとファイルのプロパティを読み取り専用に変更するものがあります。ストリーミング ファイルが検疫フォルダに入れられていた場合は、そのファイルを右クリックし、[プロパティ] をクリックします。データベースをマウントする前に [読み取り専用] チェック ボックスをクリックしてオフにします。
  • Microsoft Exchange トラブルシューティング アシスタントに含まれる Microsoft Exchange Database Recovery Management Tool を実行する方法もあります。Database Recovery Management Tool は、対象のストレージ グループのデータベースとトランザクション ログを分析し、この問題についてのさらに詳しい情報を提供します。ツールの詳細、およびダウンロードについては、Microsoft Exchange トラブルシューティング アシスタント Version 1.0 に関するページを参照してください (このサイトは英語の場合があります)。


MSExchangeIS 9518 (0xfffffbf8): Exchange データベース フォルダまたはドライブに必要なアクセス許可がない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-03-15

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffbf8) が検出されました。これは、Exchange データベースが格納されているフォルダまたはドライブに、適切なアクセス許可が割り当てられていないことを示しています。

説明

このエラーは、Exchange データベース ファイルをホストしているフォルダまたはドライブに、最低限の機能を実行するため必要なアクセス許可が割り当てられていないことを示しています。メールボックス ストアやパブリック フォルダ ストアへのアクセスやマウントで問題が発生する可能性があります。

ユーザーの操作

この問題を解決するには、Exchange データベースが格納されているフォルダと、そのフォルダが存在するドライブに対して、既定のアクセス許可を与えます。

Exchange 2007 の Exchange データベースが格納されているフォルダに対して既定のアクセス許可を与えるには、次の操作を行います。

  1. Windows エクスプローラを起動し、Exchange データベースが格納されているフォルダに移動します。既定では、このフォルダは C:\Program Files\Microsoft\Exchange\Mailbox\<ストレージ グループ名>\ です。

  2. このフォルダを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、以下の既定のアクセス許可を与えます。

アカウント | アクセス許可
Administrators | フル コントロール
System | フル コントロール
 Exchange 2007 の Exchange データベースが格納されているドライブに対して既定のアクセス許可を与えるには、次の操作を行います。

  1. Windows エクスプローラを起動します。

  2. Exchange データベース フォルダが格納されているローカル ディスク オブジェクトを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、インストールされているオペレーティング システムに応じて、以下に示す既定のアクセス許可を与えます。

Windows 2000 Server の場合

アカウント | アクセス許可
Everyone | フル コントロール

Windows Server 2003 の場合

アカウント | アクセス許可
Administrators | フル コントロール
Creator Owner | なし
Everyone | なし
System | フル コントロール
Users | 読み取りと実行、フォルダの内容の一覧表示、読み取り
 Exchange 2000 Server および Exchange Server 2003 で、Mdbdata フォルダに対して既定のアクセス許可を与えるには、次の操作を行います。

  1. Windows エクスプローラを起動し、Exchsvr フォルダに移動して、このフォルダを展開します。

  2. Mdbdata フォルダを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、以下の既定のアクセス許可を与えます。

アカウント | アクセス許可
Administrators | フル コントロール
Authenticated Users | 読み取りと実行、フォルダの内容の一覧表示、読み取り
Creator Owner | なし
Server Operators | 変更、読み取りと実行、フォルダの内容の一覧表示、読み取り、書き込み
System | フル コントロール
 Exchange 2000 Server および Exchange Server 2003 で、Mdbdata フォルダが存在するドライブに対して既定のアクセス許可を与えるには、次の操作を行います。

  1. Windows エクスプローラを起動します。

  2. Mdbdata フォルダが格納されているローカル ディスク オブジェクトを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、インストールされているオペレーティング システムに応じて、以下に示す既定のアクセス許可を与えます。

Windows 2000 Server の場合

アカウント | アクセス許可
Everyone | フル コントロール

Windows Server 2003 の場合

アカウント | アクセス許可
Administrators | フル コントロール
Creator Owner | なし
Everyone | なし
System | フル コントロール
Users | 読み取りと実行、フォルダの内容の一覧表示、読み取り

詳細情報

この問題の詳細については、Microsoft サポート技術情報の文書番号 823022「メールボックスまたはパブリック ストアをマウントすると "ID 番号 : c1041724" エラー メッセージとイベント ID 491 が表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823022) を参照してください。


MSExchangeIS 9518 (0xfffff743): 一時ファイルが多すぎる
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-03-14

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffff743) が検出されました。これは、サーバーの一時ファイルの名前空間がすべて使用されたか、Temp フォルダへの書き込みに使用できる領域がないことを示しています。

説明

Exchange 2000 Server および Exchange Server 2003 は、メッセージやファイルなどの大きなオブジェクトをストア内にストリームするときに、オブジェクト全体を内部に書き込むには .stm ファイルが断片化されすぎていると、Temp フォルダに一時ファイルを作成します。

通常の操作中、Exchange サービスが停止すると、これらのファイルは Temp フォルダから削除されます。Exchange サーバーが予期せずにシャットダウンしたり、Exchange サービスが予期せずに停止した場合、これらのファイルは削除されません。Exchange サービスが後で再開されると、新しい一時ファイルが作成されます。この結果、パフォーマンスが低下します。64,000 の一時ファイルの名前空間がすべて使用されると、Exchange サービスが開始できなくなり、イベント ビューアのアプリケーション ログに 9518 イベント (エラー コード 0xfffff743) が記録されます。

ユーザーの操作

この問題を解決するには、次の操作を行います。

  • Windows Temp フォルダに lb*.tmp ファイルが存在するかどうかを確認します。これらのファイルが存在する場合は、次に説明する手順に従って削除します。

  • Temp フォルダをホストするドライブの空きディスク領域を調べます。ディスクに空き領域がない場合は、次の手順を使用して、Temp フォルダと Tmp フォルダを別のドライブに移動します。

Windows Temp フォルダから lb*.tmp ファイルを削除するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] を選択します。次に、[管理ツール] を選択して [サービス] をクリックします。

  2. [Microsoft Exchange Information Store] まで下にスクロールします。

  3. サービスの状態が Started の場合は、サービスを右クリックし、[停止] をクリックします。
注 :
この操作により、すべてのユーザーがメールボックスから切断されます。
  1. %windir%\temp フォルダに移動します。ここで、%windir% は Windows システム ルート フォルダです。既定では、これは C:\Windows\Temp です。

  2. lb*.tmp ファイルをすべて削除します。

  3. [サービス] 管理コンソールで [Microsoft Exchange Information Store] サービスを右クリックし、[開始] をクリックします。

 Temp フォルダと Tmp フォルダを別のドライブに移動するには、次の操作を行います。

  1. Exchange Server コンピュータで、[スタート] ボタンをクリックし、[コントロール パネル] をクリックします。次に、[システム] をダブルクリックします。

  2. [詳細設定] タブをクリックし、[環境変数] をクリックします。

  3. [システム環境変数] で、TEMP 変数とドライブが含まれる行をクリックし、[編集] をクリックします。次に、新しいドライブの場所を入力します。

  4. [システム環境変数] で、TMP 変数とドライブが含まれる行をクリックし、[編集] をクリックします。次に、新しいドライブの場所を入力します。
注 :
この変更が、ユーザー環境変数ではなく、システム環境変数に適用されたことを確認します。
注 :
ここで説明した手順によって問題が解決されない場合は、Microsoft サポート技術情報の文書番号 307242「0xfffff745 エラーおよび -2235 エラーが発生し、インフォメーション ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307242) を参照してください。

詳細情報

この問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 294462「[XADM] Temp フォルダに Lb*.tmp ファイルが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=294462)

  • 文書番号 307242「0xfffff745 エラーおよび -2235 エラーが発生し、インフォメーション ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307242)


MSExchangeIS 9519 (0xfffffb3a): 複数のデータベースで同一の署名が使用されていることが検出された
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0xfffffb3a) が検出されました。このエラーは、同一のデータベースの別のコピーが既に実行中であることを示しています。

説明

それぞれの Exchange データベースは、固有の署名を持っています。Microsoft Exchange Information Store サービスが同一の署名を持つデータベースを複数検出した場合は、データベースが重複してマウントされることを防止します。

このイベントは、エラー -1222, JET_errDatabaseSignInUse として識別されることもあります。

ユーザーの操作

1 つのストレージ グループの中に同一のデータベースの 2 つのコピーが存在しているかについて、以下の手順を実行することによって確認できます。

  1. ストレージ グループ内の他のデータベースのマウントをすべて解除して、このエラー メッセージの原因となったデータベースをマウントします。

  2. このデータベースのマウントが可能な場合は、ストレージ グループ内の他のデータベースをすべてマウントしてみます。

  3. ストレージ グループ内の別のデータベースでアプリケーション ログに同じエラーが記録される場合は、これら 2 つのデータベースは同一の署名を持っているため、同一のデータベースのコピーであることになります。

この問題を解決するには、1 つのストレージ グループの中にはデータベースのコピーは必ず 1 つしか存在しないようにします。


MSExchangeIS 9519 (0xfffffe07): バックアップ プロセスが実行中のため、データベースをマウントできない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-02-27

Microsoft Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0xfffffe07) が検出されました。このエラーは、バックアップ プロセスが実行中のため、指定されたデータベースがマウントできなかったことを示しています。

説明

このエラーは、このデータベースが属するストレージ グループに複数のデータベース (メールボックス データベースまたはパブリック フォルダ データベース) があり、そのうちのいずれか 1 つがバックアップ中であった場合に、データベースをマウントしようとすると発生する可能性があります。この動作は仕様です。ストレージ グループ内のあるデータベースをバックアップしているときに、同じストレージ グループ内の別のデータベースをマウントすることはできません。

このエラーは、エラー -505, JET_errBackupInProgress として識別されることもあります。

ユーザーの操作

ストレージ グループ内の他のデータベースがバックアップ中でないことを確認してからデータベースをマウントするようにしてください。また、データベースをマウントする場合は、同じストレージ グループの他のデータベースのバックアップが終わるまで待ってください。


MSExchangeIS 9519 (0x3f3): 復元後に [復元時はこのデータベースを上書きする] チェック ボックスがオフになっている
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0x3f3) が検出されました。このエラーは、[復元時はこのデータベースを上書きする] チェック ボックスがオフになっている状態でデータベースの復元が実行されたことを示しています。

説明

このイベントは、データベースの復元操作が実行され、ストアのプロパティの [復元時はこのデータベースを上書きする] チェック ボックスがオフになっていることが Exchange によって検出された場合に発生します。

ユーザーの操作

この問題を解決するには、データベースを上書きできるようにします。それには、次の操作を実行します。

Exchange Server 2003 および Exchange 2000 Server でこのオプションを有効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. 必要に応じて、[管理グループ] を展開します。

  3. [サーバー]、[<サーバー名>]、[<ストレージ グループ>] の順に展開し、復元されたデータベースをクリックします。

  4. データベースを右クリックし、[プロパティ] をクリックします。

  5. [データベース] タブをクリックします。

  6. [復元時はこのデータベースを上書きする] チェック ボックスをクリックしてオンにします。

  7. [OK] をクリックします。

  8. データベースをマウントするには、データベースを右クリックし、[ストアのマウント] をクリックします。
Exchange Server 2007 でこのオプションを有効にするには、次の操作を行います。

  1. Exchange 管理コンソールを起動します。

  2. [サーバーの構成] で、[メールボックス] を選択します。

  3. [データベースの管理] ウィンドウで、復元されたデータベースを右クリックします。

  4. [プロパティ] をクリックします。

  5. [制限] タブをクリックします。

  6. [復元時はこのデータベースを上書きする] チェック ボックスをクリックしてオンにします。

  7. [OK] をクリックします。

  8. データベースをマウントするには、データベースを右クリックし、[データベースのマウント] をクリックします。


MSExchangeIS 9518 (0xfffffc01): データベースまたはトランザクション ログのドライブまたはディレクトリが正しくない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9518 イベント (エラー コード 0xfffffc01) が検出されました。これは、Exchange のデータベースまたはログ ファイルのドライブ文字またはパスが誤って設定されていることを示しています。

説明

このエラーは、対象のストレージ グループ内のデータベースまたはログ ファイルのパスが無効なドライブ文字を参照しているか、ファイルのパスが誤っていることを示しています。このエラーが発生すると、対象のストレージ グループ内のすべてのデータベースがマウントされなくなります。

また、この問題は、ウイルス対策ソフトウェアによって Exchange データベースまたはトランザクション ログ ファイルが格納されているドライブへの書き込みアクセスがブロックされた場合にも発生することがあります。

このイベントは、エラー -1023, JET_errInvalidPath として識別されることもあります。

ユーザーの操作

この問題を解決するには、次のいずれかの操作を行います。

  • この問題の原因がウイルス対策ソフトウェアであるかどうかを確認するために、サービス コンソールでウイルス対策ソフトウェアを一時的に無効にします。次に、対象のデータベースのマウントを試みます。これによってデータベースが正常にマウントされた場合は、ウイルス対策ソフトウェアの製造元にソフトウェアの最新ビルドについてお問い合わせください。

  • このエラーの対象となっている各ストレージ グループおよびデータベースのシステム パス、データベースのパス、およびトランザクション ログ ファイルのパスが正しいかどうかを確認し、必要に応じて設定を変更します。次の手順に従います。

Exchange Server 2003 または Exchange 2000 Server でファイル パスが正しいかどうかを確認し、設定を変更するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. Exchange システム マネージャで管理グループが表示されたら、[管理グループ] を展開し、問題が発生した管理グループを展開します。

  3. [サーバー] を展開し、問題が発生したサーバーを展開します。

  4. マウントできないストアが含まれているストレージ グループを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[トランザクション ログの場所] ボックスに表示されるパスを確認します。次に、[システム パスの場所] ボックスのパスを確認します。

    これらのパスに誤りがある場合は、問題解決のサポートについて Microsoft 製品サポート サービスにお問い合わせください。

  6. 存在する各ストレージ グループについて手順 3. ～ 5. に従い、データベースのパスおよびトランザクション ログ ファイルのパスを確認します。

  7. 各ストレージ グループのシステム パスおよびトランザクション ログ ファイルのパスを確認したら、次に各ストレージ グループ内のそれぞれのストアのデータベースのパスを確認します。それには、次の手順に従います。

    1. ストレージ グループを展開します。たとえば、[最初のストレージ グループ] を展開します。

    2. [<ストア名> (サーバー名)] を右クリックし、[プロパティ] をクリックします。

    3. [データベース] タブをクリックし、[Exchange データベース] ボックスに表示されるパスを確認します。次に、[Exchange ストリーミング データベース] ボックスに表示されるパスを確認します。

      特定のパスに誤りがある場合は、問題解決のサポートについて Microsoft 製品サポート サービスにお問い合わせください。

    4. 手順 7b. および 7c. を繰り返し、各ストレージ グループ内のそれぞれのメールボックス ストアまたはパブリック フォルダ ストアのパスを確認します。

  8. メールボックス ストアまたはパブリック フォルダ ストアをマウントします。

Exchange Server 2007 でファイル パスが正しいかどうかを確認し、設定を変更するには、次の操作を行います。

  1. Exchange 管理コンソールを起動します。[スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[Exchange 管理コンソール] をクリックします。

  2. [サーバーの構成] を展開し、[メールボックス] を選択します。

  3. [データベースの管理] ウィンドウで、マウントできないデータベースが含まれているストレージ グループを選択します。

  4. ストレージ グループを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[ログのパス] および [システム パス] に表示されているパスを確認します。

    これらのパスに誤りがある場合は、ストレージ グループを右クリックし、[ストレージ グループ パスの移動] をクリックします。[ログ ファイルのパス] および [システム ファイルのパス] の下にある [参照] をクリックし、トランザクション ログ ファイルまたはデータベース ファイルが格納されているフォルダを指定します。既定では、トランザクション ログ ファイルおよびデータベース ファイルは次のフォルダにあります。

    %PROGRAMFILES%\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>

  6. [OK] をクリックします。

  7. 存在する各ストレージ グループについて手順 3. ～ 5. に従い、システム パスおよびトランザクション ログ ファイルのパスを確認します。

  8. 各ストレージ グループのシステム パスおよびトランザクション ログ ファイルのパスを確認したら、次に各ストレージ グループ内のそれぞれのデータベースのパスを確認します。それには、次の手順に従います。

    1. ストレージ グループを展開します。たとえば、[最初のストレージ グループ] を展開します。

    2. [データベースの管理] ウィンドウで、[データベース ファイルのパス] に表示されるパスを確認します。

    3. 特定のパスに誤りがある場合は、データベースを右クリックし、[データベース パスの移動] をクリックします。

    4. [参照] をクリックし、データベース ファイルが置かれているフォルダの正しい場所を指定します。既定では、Exchange データベース ファイル (.edb) は次のフォルダにあります。

      %PROGRAMFILES%\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>\<データベース名.edb>

    5. [OK] をクリックします。

    6. 手順 8b. ～ 8e. に従い、各ストレージ グループ内のそれぞれのメールボックス データベースまたはパブリック フォルダ データベースのパスを確認します。

  9. メールボックス データベースまたはパブリック フォルダ データベースをマウントします。


MSExchangeIS 9519 (0xfffffbda): 既定のシステム ロケールとして構成されている 2 バイト文字セットのロケールが存在しない
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0xfffffbda) が検出されました。このイベントは、英語以外のシステム ロケールが既定としてインストールされていましたが、Exchange Server のインストール後に、この既定のシステム ロケールがアンインストールされたことを示しています。

説明

Exchange サーバーの再起動時に、エラーコード 0xfffffbda を含むイベント MSExchangeIS 9519 が発生すると、Exchange データベースはマウントされません。さらに、アプリケーション イベント ログに ESE 604 および MSExchangeIS 9519 が出力されます。

この動作は、既定のシステム ロケールとして英語以外のロケールが設定されていた場合に発生します。既定のシステム ロケールに英語以外のロケールが選択されており、このロケールが削除されると、Exchange 2000 Server または Exchange Server 2003 の再起動時にこのイベントが発生します。

このエラーは、エラー -1062, JET_errInvalidLanguageId として識別されることもあります。このイベントは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、該当する英語以外のロケールを再インストールするか、または新しいデータベースを作成します。この英語以外のロケールを再インストールする場合は、それを既定のシステム ロケールとして設定する必要はありません。


MSExchangeIS 9519 (0xfffff05b): Exchange Server 2000 SP3 以降を実行するサーバーでデータベースまたはログが圧縮されている
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-02-19

Microsoft Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0xfffff05b) が検出されました。このエラーは、Exchange データベースまたはトランザクション ログ ファイルが、ファイル システムの圧縮が有効になっているドライブ上に存在していることを示しています。

説明

Exchange 2000 Server に格納されているインフォメーション ストア データベースが NTFS ファイル システム圧縮を使用して圧縮されている場合に、Exchange 2000 Server Service Pack 3 (SP3) を適用するとこのイベントが発生することがあります。この問題は、Exchange 2000 Server コンピュータを Exchange Server 2003 にアップグレードしたときにも発生することがあります。Exchange 2000 Server SP3、Exchange Server 2003、および Exchange Server 2007 では、圧縮されたインフォメーション ストア データベースはマウントできません。

このエラーは、-4005, JET_errFileCompressed として識別されることもあります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server SP3

ユーザーの操作

この問題を解決するには、インフォメーション ストア データベースおよびログが格納されているフォルダの圧縮を解除し、データベースを最適化してから、データベースおよびログが格納されているインフォメーション ストア ストレージ グループの Exchange 対応バックアップをオンラインで実行する必要があります。これを行うには、マイクロソフト サポート技術情報の文書番号 327772「[XADM] SP3 を適用後にデータベースがマウントせずエラー 0xfffff05b が発生する」を参照してください。


MSExchangeIS 9519 (0xfffffa84): データベースのインデックスが存在しないか、または破損している
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-01-22

Microsoft® Exchange Database Troubleshooter Tool によって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0xfffffa84) が検出されました。このイベントは、このデータベースのインデックスが破損しているか、または存在しないことを示しています。

説明

データベースのインデックスの破損、または存在しない原因には、次のような場合があります。

  • この現象は、Microsoft Windows の新しい Service Pack の適用後、Exchange データベースのインデックスをクリーンアップしているときに発生する可能性があります。この Service Pack を適用すると、Exchange サーバーでメールボックスまたはパブリック フォルダ データベースをマウントできなくなります。また、アプリケーション イベント ログにイベント ESE 609 および ESE 611 が出力されます。

  • この現象は、データベースの修復操作 (eseutil /p) を実行した後に発生する可能性があります。この操作によって、データベースの最初の作成時に生成されたインデックスが削除されている可能性があります。Eseutil 修復コマンドを実行すると、インデックスが削除されます。

このエラーは、-1404, JET_errIndexNotFound として識別されることもあります。このエラーは、次のバージョンの Exchange Server に適用されます。

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2003

  • Microsoft Exchange 2000 Server

ユーザーの操作

この問題を解決するには、上記に述べた問題のシナリオに合った解決策に従ってください。

  • Windows の新しい Service Pack を適用した後で Exchange データベースのインデックスをクリーンアップしているときにインデックスが破損した場合は、以下の手順に従います。

    1. 対象のメールボックスまたはパブリック フォルダ データベースを、良好な状態であることがわかっているバックアップから復元します。

    2. eseutil /d を実行して、対象のデータベースに対してオフラインでの最適化を実行します。対象のデータベースに対してオフラインでの最適化を実行する方法については、以下のトピックを参照してください。

      Exchange 2000 Server および Exchange Server 2003 のデータベースの場合 : Eseutil /D (最適化) の実行方法についてのページ (このサイトは英語の場合があります)

      Exchange Server 2007 のデータベースの場合 : Eseutil /D (最適化) の実行方法についてのページ (このサイトは英語の場合があります)

  • データベースの修復操作 (eseutil /p) を実行した後でインデックスが失われた場合は、Microsoft サポート技術情報の文書番号 924627「Exchange 2003 でのデータベースを復旧するために、Eseutil と Isinteg ユーティリティを使用した後に、データベースをマウントしようとすると、エラー 0xfffffa84 を含むイベント ID 9519 が記録されます。」に記載されている修正プログラムを適用してください。


MSExchangeIS 9519 0x972 : パブリック フォルダ コンテナが削除されたか、必要な属性が欠けている
Microsoft Exchange Server アナライザ - 文書 > データベースの回復 >

トピックの最終更新日時 : 2007-08-30

Microsoft Exchange Database Troubleshooter ツールによって、アプリケーション ログ内に 1 つ以上の MSExchangeIS 9519 イベント (エラー コード 0x972) が検出されました。これは、パブリック フォルダ コンテナが削除されているか、またはパブリック フォルダ コンテナに必要な属性が欠けているために、パブリック フォルダ データベースのマウントに失敗したことを示しています。

説明

このエラーは、パブリック フォルダ コンテナが Active Directory から削除されているか、または影響を受けるパブリック ストアが、パブリック フォルダ コンテナを使用するよう構成されていない場合に発生することがあります。構成されていないとは、パブリック フォルダ コンテナの msExchOwningPFTreeBL 属性の値が、パブリック ストアを指していない、ということです。このエラーの原因として最も可能性の高いものは、パブリック フォルダ コンテナを新しい管理グループに移動する前に、パブリック フォルダ コンテナを保有していた管理グループを削除したことです。

ユーザーの操作

この問題を解決するには、ADSI Edit または同様のツールを使用して、パブリック フォルダ コンテナが存在しているのかどうか、および msExchOwningPFTreeBL 属性が該当するパブリック ストアを指すように適切に構成されているのかどうかを判断することです。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
エラーの原因を判断するには

  1. ADSI Edit または同様のツールを使用して、Active Directory の各管理グループ オブジェクトを見つけます。

    管理グループ オブジェクトは次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group

  2. 各管理グループ オブジェクトを展開し、CN=Folder Hierarchies コンテナがあるかどうかをチェックします。CN=Folder Hierarchies コンテナがある場合、そのコンテナを強調表示し、CN=Public Folders オブジェクトが右側のウィンドウにあることを確認します。どの管理グループにも CN=Public Folders オブジェクトがない場合、「ソリューション 1 : フォルダ階層コンテナとパブリック フォルダ コンテナを再作成する」に進みます。CN=Public Folders コンテナがある場合、手順 3 に進みます。

  3. CN=Public Folders オブジェクトを右クリックし、[プロパティ] をクリックします。

  4. [属性] の一覧で、[msExchOwningPFTreeBL] 属性をクリックし、[編集] をクリックします。

  5. 影響を受けるパブリック フォルダ ストアが、[値] の一覧に表示されていることを確認します。一覧に表示されていない場合には、「ソリューション 2」に進みます。
ソリューション 1 : フォルダ階層コンテナとパブリック フォルダ コンテナを再作成する

  1. ADSI Edit または同様のツールを使用して、[Exchange Administrative Group (FYDIBOHF23SPDLT)] を見つけ、展開します。

    [Exchange Administrative Group (FYDIBOHF23SPDLT)] オブジェクトは、次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups

  2. [Exchange Administrative Group (FYDIBOHF23SPDLT)] オブジェクトを右クリックし、[新規作成] をクリックして、[オブジェクト] をクリックします。

  3. [クラスを選択] の一覧で、[msExchPublicFolderTreeContainer] をクリックし、[次へ] をクリックします。

  4. [値] ボックスに「フォルダ階層」と入力し、[次へ] をクリックして [完了] をクリックします。

  5. 新規作成した [フォルダ階層] オブジェクトを右クリックして、[新規作成] をクリックし、[オブジェクト] をクリックします。

  6. [クラスを選択] の一覧で、[msExchPFTree] をクリックし、[次へ] をクリックします。

  7. [値] ボックスに「パブリック フォルダ」と入力し、[次へ] をクリックします。

  8. [その他の属性] をクリックします。

  9. [表示するプロパティを選択] ボックスの一覧で、[msExchPFTree] をクリックします。

  10. [属性の編集] ボックスに「1」と入力し、[設定] をクリックして [OK] をクリックし、[完了] をクリックします。

  11. パブリック フォルダ コンテナを各パブリック ストアに割り当てるには、[パブリック フォルダ] コンテナを右クリックして、[プロパティ] をクリックします。

  12. [属性] 一覧で、[distinguishedName] をクリックし、[編集] をクリックします。

  13. [値] ボックスの内容をクリップボードにコピーし、[キャンセル] をクリックします。

  14. MSExchangeIS 9519 イベント (エラー コード 0x972) が発生している各サーバーについて、[パブリック フォルダ ストア] オブジェクトに移動します。このオブジェクトの既定の場所は、次のとおりです。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Servers, CN= ServerName , CN= InformationStore , CN=Second Storage Group.

  15. [パブリック フォルダ ストア] オブジェクトを右クリックし、[プロパティ] をクリックします。

  16. [属性] 一覧で、[msExchOwningPFTree] をクリックし、[編集] をクリックします。

  17. 手順 13. でクリップボードにコピーした値を [値] ボックスに貼り付け、[OK] を 2 回クリックして終了します。

  18. MSExchangeIS 9519 イベント (エラー コード 0x972) が発生している各サーバーについて、手順 15. ～ 17. を繰り返します。

  19. 影響を受ける各サーバーで、Microsoft Exchange Information Store サービスを再開します。

ソリューション 2 : パブリック フォルダ コンテナ オブジェクトの msExchOwningPFTreeBL 属性の値を再入力する

  1. ADSI Edit または同様のツールを使用して、Active Directory 内の [パブリック フォルダ] オブジェクトを見つけます。

    [パブリック フォルダ] オブジェクトは次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Folder Hierarchies,CN=Public Folders

  2. [パブリック フォルダ] コンテナを右クリックし、[プロパティ] をクリックします。

  3. [属性] 一覧で、[distinguishedName] をクリックし、[編集] をクリックします。

  4. [値] ボックスの内容をクリップボードにコピーし、[キャンセル] をクリックします。

  5. MSExchangeIS 9519 イベント (エラー コード 0x972) が発生している各サーバーについて、[パブリック フォルダ ストア] オブジェクトに移動します。このオブジェクトの既定の場所は、次のとおりです。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Servers, CN= ServerName , CN= InformationStore , CN=Second Storage Group.

  6. [パブリック フォルダ ストア] オブジェクトを右クリックし、[プロパティ] をクリックします。

  7. [属性] 一覧で、[msExchOwningPFTree] をクリックし、[編集] をクリックします。

  8. 手順 4. でクリップボードにコピーした値を [値] ボックスに貼り付け、[OK] を 2 回クリックして終了します。

  9. MSExchangeIS 9519 イベント (エラー コード 0x972) が発生している各サーバーについて、手順 6. ～ 8. を繰り返します。

  10. 影響を受ける各サーバーで、Microsoft Exchange Information Store サービスを再開します。


Exchange クラスタ
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクションの文書では、Microsoft® Exchange Server アナライザ ツールで、Exchange クラスタに関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出された Exchange クラスタに関連するエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


クラスタのデバッグが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、サーバー上でクラスタのデバッグが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Cluster\Debug

Debug 値が 1 に等しいことが検出されると、警告が表示されます。

このレジストリ値によるクラスタ デバッグでは、クラスタ リソースがノード間でフェール オーバーされなくなります。このレジストリ値の使用は、リソースのフェール オーバーを禁止して行う必要がある問題のデバッグのみに制限する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
クラスタ デバッグのレジストリ キーを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. HKLM\Software\Microsoft\Exchange\Cluster に移動します。

  3. Debug 値を 0 に変更します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

Exchange クラスタの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Exchange Clusters in Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。


クラスタの専用ハートビート ネットワークの優先度が正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Exchange サーバー クラスタ内の各ネットワーク インターフェイス リソースの優先順位を判断します。

HKEY_LOCAL_MACHINE\Cluster\Networks\<ネットワーク インターフェイスの GUID>\Priority

Priority の値は、ネットワーク インターフェイス リソース用に構成されたネットワークの優先度を示します。優先度の最も高いネットワーク インターフェイス リソースが 1 の値になり、次に優先度の高いものが 2、以下も同様です。

Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Exchange サーバー クラスタ内の各ネットワーク用に定義された役割を判断します。

HKLM\Cluster\Networks\<NetworkInterfaceGUID>\Role

この値が 1 の場合は、このネットワーク リソースが専用のプライベート ネットワークとして構成されていることを示します。この値が 2 の場合は、専用のパブリック ネットワーク (クライアント アクセス) として構成されていることを示します。この値が 3 の場合は、ハートビート トラフィックとクライアント アクセス トラフィックの両方が可能な、混在ネットワークとして構成されていることを示します。

Exchange Server アナライザによって、Role の値が 1 であるネットワーク インターフェイス リソースの Priority が 1 より大きい値に設定されていることが検出されると、警告が表示されます。この警告は、専用のハートビートネットワークが検出されたが、そのネットワーク優先度が正しく設定されていないことを示しています。

クラスタ ハートビートに使用する専用のプライベート ネットワークを構成することは、すべての Exchange Server クラスタに推奨されるベスト プラクティスです。ノード間の通信は、円滑なクラスタ操作にとってきわめて重要です。次の手順に従い、専用ハートビート ネットワークのネットワーク優先度を正しく構成します。

この警告を修正するには

  1. クラスタ アドミニストレータを起動し、Exchange サーバー クラスタに接続します。

  2. 左側のペインで、階層の最上位にある [クラスタ] オブジェクトを右クリックし、[プロパティ] をクリックします。

  3. [ネットワークの優先順位] をクリックします。

  4. 専用のハートビート ネットワーク リソースを選択します。

  5. 専用のハートビート ネットワーク リソースがネットワーク リソース一覧の一番上になるまで、[上へ移動] をクリックします。

  6. [OK] をクリックします。

クラスタ ハートビート ネットワークの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750)

  • 文書番号 307962「クラスタ ハートビートにおけるマルチキャスト サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307962)

詳細については、「Exchange Server 2003 Cluster Configuration Checklist」(http://go.microsoft.com/fwlink/?linkid=36083) を参照してください (このサイトは英語の場合があります)。


クラスタ ノードの Windows のビルド番号が最初のノードと一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、クラスタ内の各ノードで実行されている Microsoft Windows® オペレーティング システムのコア バージョンを判断します。

HKEY_LOCAL_MACHINE\Cluster\Nodes\<ノード番号>\BuildNumber

Exchange クラスタ内の 2 番目以降のノードの BuildNumber の値が、その Exchange クラスタ内の最初のノードの BuildNumber の値と異なることが検出されると、エラーが表示されます。

Exchange クラスタ内で異なるバージョンの Windows が実行されていると、フェールオーバーが予期したように、つまり構成したように実行されないことがあります。Windows のバージョンが混在している環境では、フェールオーバーは古いオペレーティング システムから新しいオペレーティング システムへ (たとえば、Windows 2000 Advanced Server から Windows Server™ 2003 Enterprise Edition へ) のみ実行されます。新しいオペレーティング システムから古いオペレーティング システムへ (たとえば、Windows Server 2003 から Windows 2000 Server へ) は実行されません。

この問題を解決するには、すべてのノードを同じオペレーティング システムと Service Pack にアップグレードする必要があります。ダウンタイムを最小限に抑えるために、クラスタのローリング アップグレードを実行することができます。

このエラーを修正するには

  1. クラスタのローリング アップグレードを実行する手順については、Microsoft サポート技術情報の文書番号 811272「Windows Server 2003 サーバー クラスタのローリング アップグレードの実行方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=811272) を参照してください。

  2. 文書「Windows 2000 Clustering: Performing a Rolling Upgrade」(http://go.microsoft.com/fwlink/?linkid=1718) を参照してください (このサイトは英語の場合があります)。

  3. BuildNumber 値がクラスタ内の最初のノードと異なる各ノードのローリング アップグレードを実行します。

これに代わる別の手順については、「Alternatives to rolling upgrades」(http://go.microsoft.com/fwlink/?LinkId=41363) を参照してください (このサイトは英語の場合があります)。


クラスタ ノードの Windows Service Pack のバージョンが最初のノードと一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、クラスタ内の各ノードにインストールされている Microsoft Windows® Service Pack のバージョンを判断します。

HKEY_LOCAL_MACHINE\Cluster\Nodes\<ノード番号>\CSDVersion

Exchange クラスタ内の 2 番目以降のノードの CSDVersion の値が、その Exchange クラスタ内の最初のノードの CSDVersion の値と異なることが検出されると、エラーが表示されます。

このエラーは、この Exchange クラスタ内の各ノードで、同じレベルの Windows Service Pack が実行されていないことを示しています。ベスト プラクティスとして、Exchange クラスタ内のすべてのノードで、同じレベルのオペレーティング システムと Service Pack を実行することをお勧めします。

この問題を解決するには、すべてのノードを同じオペレーティング システムと Service Pack にアップグレードする必要があります。ダウンタイムを最小限に抑えるために、クラスタのローリング アップグレードを実行することができます。

この警告を修正するには

  1. クラスタのローリング アップグレードを実行する手順については、Microsoft サポート技術情報の文書番号 811272「Windows Server 2003 サーバー クラスタのローリング アップグレードの実行方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=811272) を参照してください。

  2. 文書「Windows 2000 Clustering: Performing a Rolling Upgrade」(http://go.microsoft.com/fwlink/?linkid=34288) を参照してください (このサイトは英語の場合があります)。

  3. CSDVersion 値がクラスタ内の最初のノードと異なる各ノードのローリング アップグレードを実行します。

これに代わる別の手順については、「Alternatives to rolling upgrades」(http://go.microsoft.com/fwlink/?linkid=34289) を参照してください (このサイトは英語の場合があります)。


クラスタの TEMP/TMP パスがシステム パーティションと同じドライブ上に存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

クラスタ化されていない Exchange Server コンピュータ上では、Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、TEMP 環境変数と TMP 環境変数の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP

Exchange Server アナライザは、Microsoft Windows® サーバー クラスタ内の Exchange 仮想サーバー (EVS) に対して実行された場合、HKLM レジストリ ハイブの読み取りは行いません。代わりに、以下のレジストリ エントリを読み取ります。

HKEY_USERS\<クラスタ サービスのアカウント SID>\Environment\TEMP

HKEY_USERS\<クラスタ サービスのアカウント SID>\Environment\TMP

Exchange Server アナライザによって、TEMP 環境変数と TMP 環境変数、またはそのいずれかが %SYSTEMROOT で始まっていることが検出されると、警告が表示されます。

Microsoft Exchange Information Store サービス プロセスは、メッセージの変換やメールボックスの移動などのさまざまな操作の間、TEMP フォルダと TMP フォルダを一時的な記憶域として使用します。クラスタ化されていない Exchange サーバーでは、Microsoft Exchange Information Store サービスは TEMP と TMP の両方について、既定の環境変数の設定である %Systemroot%\Temp が使用される SYSTEM (たとえばローカル システム) を使用します。

Windows サーバー クラスタ環境で実行される EVS は、特定のユーザー セキュリティ プリンシパルのコンテキストで実行されるクラスタ サービス アカウントの環境変数の設定を使用します。ユーザー アカウントの場合、TEMP と TMP の既定の環境変数は %Userprofile%\temp に設定されます。

TEMP 環境変数と TMP 環境変数は、一時的なワークスペースを必要とするアプリケーションが使用するファイル システム内のフォルダを 、(たとえばパスで) 指定するために使用されます。TEMP は通常、Exchange などのアプリケーションによって使用され、TMP は通常、Microsoft Visual C++® などの開発ツールによって使用されます。各変数のパスは、通常、アプリケーションまたはツールのセキュリティ コンテキストを基準にしています。

最大のパフォーマンスを得るためには、オペレーティング システムを格納しているディスクを、Exchange が使用する TEMP フォルダと TMP フォルダのために使用しないことをお勧めします。また、これらの環境変数が、RAID 0+1 スピンドル セットなどの高速なディスクまたはディスク システム上のパスに設定されるようにしてください。さらに、オペレーティング システムを格納しているディスクを、Exchange または EVS が使用する TEMP フォルダと TMP フォルダのために使用しないことをお勧めします。

この警告を修正するには

  1. クラスタ サービスのアカウントとしてクラスタ内のノードにログオンします。

  2. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。

  3. [詳細設定] をクリックします。

  4. [環境変数] をクリックします。

  5. [<アカウント名> のユーザー環境変数] グループで、[TEMP] を選択し、[編集] をクリックします。

  6. [変数値] ボックスに TEMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  7. [<アカウント名> のユーザー環境変数] グループで、[TMP] を選択し、[編集] をクリックします。

  8. [変数値] ボックスに TMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  9. [OK] をクリックして [環境変数] ダイアログ ボックスを閉じ、もう一度 [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じます。

  10. ノードを再起動して変更を適用します。

  11. クラスタ内の各ノードについて、手順 1. ～ 10. を繰り返します。

クラスタ化されていない Exchange Server コンピュータにおける TEMP 環境変数や TMP 環境変数の変更に関する詳細については、「TEMP/TMP 変数が無効なフォルダまたは不適切なフォルダを指していると思われる」を参照してください。


専用のクラスタ ハートビートが見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange サーバー クラスタ内にある各ネットワーク インターフェイス リソースの定義された役割を判断します。

HKEY_LOCAL_MACHINE\Cluster\Networks\<NetworkInterfaceGUID>\Role

値が 1 の場合、ネットワーク リソースは専用のプライベート (ハートビート) ネットワークとして構成されています。値が 2 の場合、ネットワーク リソースは専用のパブリック ネットワーク (クライアント アクセス) として構成されています。この値が 3 の場合は、ハートビート トラフィックとクライアント アクセス トラフィックの両方が可能な、混在ネットワークとして構成されていることを示します。

Exchange Server アナライザは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。値が True の場合はクラスタ サービスが開始されており、値が False の場合はクラスタ サービスは実行されていません。

Exchange クラスタ内のネットワーク リソースが専用のプライベート ネットワークとして構成されていることが検出されなかった場合、警告が表示されます。

すべての Exchange Server クラスタに該当するベスト プラクティスとして、クラスタ ハートビート用に使用する専用のプライベート ネットワークを構成することをお勧めします。クラスタ操作を円滑に行うためには、ノード間の通信が不可欠です。ネットワークは、クラスタ通信に最適で、すべてのハードウェア互換性一覧の要件に準拠するように構成する必要があります。ネットワーク構成の場合は、2 つ以上の独立したネットワークをクラスタのノードに接続して、単一障害点の発生を回避する必要があります。通常は、2 つのローカル エリア ネットワークを使用します。Microsoft 製品サポート サービスでは、1 つのネットワークにしか接続されていないノードを持つクラスタの構成をサポートしていません。

この警告を修正するには

  1. ネットワーク インターフェイス カードがない場合は、それを Exchange クラスタ内の各ノードに取り付け、そのネットワーク インターフェイス カードをクラスタ アドミニストレータでプライベート ネットワークとして構成します。

  2. ネットワーク カードが他に存在するものの、混合ネットワーク用として使用されている場合は、専用のプライベート ネットワークとして機能するように適切なネットワークを再構成して、構成を変更する必要があります。

クラスタ ハートビート ネットワークの詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 258750「クラスタサーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750)

  • 文書番号 307962「クラスタ ハートビートにおけるマルチキャスト サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307962)

詳細については、「Exchange Server 2003 Cluster Configuration Checklist」(http://go.microsoft.com/fwlink/?linkid=36083) を参照してください (このサイトは英語の場合があります)。


cluster.log の既定のファイル サイズを 32 に上げる必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ClusterLogSize パラメータが設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\

ClusterLogSize の値が存在しないこと、または ClusterLogSize の値が 8 以下であることが検出されると、警告が表示されます。ビジー状態のクラスタでは cluster.log ファイルのサイクルがすぐに回ってきてしまうため、以下の状況でフェールオーバー状態のトラブルシューティングを行うとエントリが失われる可能性があります。

  • トラブルシューティングで、クラスタ ログ ファイルを詳しく調査する必要がある。

  • クラスタが多くのリソースを管理している。

そのため、トラブルシューティングに cluster.log ファイルが必要な場合は、ClusterLogSize パラメータがまだ作成されていない場合は作成し、既定のサイズを 32、64、または 96 に上げる必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
ClusterLogSize パラメータを作成してその値を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

  3. 左側のペインで、[環境] をクリックします。

  4. [編集] メニューの [新規] をクリックし、[DWORD 値] をクリックします。

  5. 「ClusterLogSize」と入力し、Enter キーを押して、新しいレジストリ エントリに名前を付けます。

  6. [ClusterLogSize] を右クリックし、[変更] をクリックします。

  7. ClusterLogSize の [値データ] を新しいログ ファイル サイズに変更します。たとえば、ClusterLogSize の値を、32、64、または 96 に変更して、Enter キーを押します。

  8. レジストリ エディタを終了します。
cluster.log ファイルの既定のサイズを変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

  3. [ClusterLogSize] を右クリックし、[変更] をクリックします。

  4. ClusterLogSize の [値データ] を新しいログ ファイル サイズに変更します。たとえば、ClusterLogSize の値を、32、64、または 96 に変更して、Enter キーを押します。

  5. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Cluster Server のクラスタ ログ機能の詳細については、Microsoft サポート技術情報の文書番号 168801「Microsoft Cluster Server のクラスタ ログ機能を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=168801) を参照してください。


SMTP に対して Kerberos 認証を有効にする
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-05-12

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Windows™ Server 2003 クラスタ サービスに導入されている Microsoft Exchange Server 2003 サーバーが、servicePrincipalName 属性における SMTPSVC リソース値として、サーバーの完全修飾ドメイン名 (FQDN) を保持しているかどうかを判断します。

Exchange Server アナライザが、クラスタ サービスの SMTPSVC Exchange リソースに対する servicePrincipalName 属性に、サーバーの FQDN 値が含まれていないことを検出すると、ベスト プラクティス メッセージが表示されます。

ここでのベスト プラクティスは、Exchange Server 2003 を実行している Windows Server 2003 クラスタ サーバーで、SMTP (Simple Mail Transfer Protocol) に対して Kerberos 認証に有効にすることです。Kerberos 認証を有効にするには、SMTPSVC Exchange リソースに対して新しいサービス プリンシパル名 (SPN) を手動で設定します。

既定では、Windows Server 2003 は NTLM 認証を使用します。Kerberos プロトコルは、NTLM と比べて柔軟性と効率性に優れ、より安全です。Kerberos 認証を使用する利点は、以下のとおりです。

  • 接続が早くなる。NTLM 認証では、各クライアントを認証するために、アプリケーション サーバーがドメイン コントローラに接続する必要があります。Kerberos 認証では、サーバーはドメイン コントローラを検出する必要はありません。サーバーは、クライアントが提示する資格情報を検証して、クライアントを認証できます。クライアントは、特定のサーバーの資格情報を 1 度取得すると、ネットワーク ログオン セッションでその資格情報を再利用できます。

  • 相互認証。NTLM を使用すると、サーバーはクライアントの ID を確認できます。NTLM を使用しても、クライアントはサーバーの ID を確認できません。あるいは、あるサーバーが別のサーバーの ID を確認できません。NTLM 認証は、サーバーが正規であると仮定されているネットワーク環境向けに設計されました。Kerberos プロトコルでは、そのような条件はありません。ネットワーク接続の両端の接続先は、他方の接続先が主張どおりの接続先であることを認識できます。

  • 委任された認証。Windows サービスは、クライアントに代わってリソースにアクセスする際、クライアントを偽装します。多くの場合、サービスは、ローカル コンピュータのリソースにアクセスすることによって、クライアントの作業を完了できます。NTLM と Kerberos は、サービスがローカルでクライアントを偽装するために必要な情報を提供します。ただし一部の分散アプリケーションでは、フロントエンド サービスは、他のコンピュータのバックエンド サービスに接続する際にクライアントを偽装する必要があります。Kerberos プロトコルは、サービスが他のサービスに接続する際にクライアントを偽装できるようにするプロキシ メカニズムです。NTLM には同様の機能はありません。

この問題を解決するには、以下の手順に従い、関連する属性に対して不足している値を追加します。

SETSPN.exe ツールを使用して、不足している値を SPN に追加する

  1. Setspn.exe ツールをインストールします。Setspn.exe ツールを取得するには、"Windows 2000 リソース キット ツール :Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103) を参照してください (このサイトは英語の場合があります)。

    Windows Server 2003 バージョンの Setspn.exe コマンドライン ツールは、Windows Server 2003 CD に格納されている Windows Server 2003 のサポート ツールに含まれています。Server 2003 サポート ツールをインストールする場合は、Support/Tools フォルダの Suptools.msi ファイルをダブルクリックしてください。

  2. SETSPN.EXE Setspn_d.txt ファイルのガイダンスに従って、不足している値を Exchange サーバーの Active Directory オブジェクトに追加します。以下の例は、仮想 SMTP サーバーの SPN に対する FQDN 値の追加を示しています。

    • コマンド プロンプトを開始し、Setspn.exe をインストールしたディレクトリに移動します。

    • コマンド プロンプトで、以下のコマンドを入力します。

      setspn.exe-a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      注 :
      mail.yourdomain.com を SMTP 仮想サーバーの FQDN に置き換え、YOURSERVERNAME を Exchange サーバー名に置き換えます。
    • Enter キーを押します。


Exchange クラスタ ノードに接続できない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。この値が True の場合はクラスタ サービスが開始されていることを示し、False の場合はクラスタ サービスが実行されていないことを示します。

Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合は、そのコンピュータが Microsoft Windows NT® Server 4.0 を実行していることを示します。この値が 5.0 の場合は Windows 2000 Server を実行していることを示し、5.2 の場合は Windows Server™ 2003 を実行していることを示します。

クラスタで実行されている Windows のバージョンを判断できない場合、またはクラスタ サービスが実行されているかどうか判断できない場合は、エラーが表示されます。このエラーは、Exchange Server アナライザが Exchange Server クラスタのノードに接続できなかったことを表しています。

このエラーを修正するには

  1. Exchange Server コンピュータが起動し、ネットワークに接続されていることを確認します。

  2. ping コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. ファイアウォールが設置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを調べます。

  4. Exchange Server コンピュータで Remote Registry サービスが開始されていることを確認します。

  5. Exchange Server アナライザを実行しているアカウントのアクセス許可をチェックし、そのアカウントが Exchange Server コンピュータのレジストリを読み取るために必要とされる十分なアクセス許可を持っていることを確認します。

ネットワーク接続の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


Active Directory の Exchange データ パスがクラスタ レジストリと一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-04-28

Microsoft® Exchange Server アナライザ ツールは、クラスタ レジストリ (HKEY_LOCAL_MACHINE\Cluster) と Active Directory® ディレクトリ サービスの両方に対してクエリを実行し、それら両方の場所で、メッセージ追跡ログ ファイルなどの Exchange データ ファイルのパスが同じになっているかどうかを確認します。Exchange セットアップ プログラムを使用して Microsoft Windows® サーバー クラスタのノードに Exchange をインストールする際は、レジストリと Active Directory でパスの値が構成されます。

Exchange セットアップ プログラムによって作成され、Exchange Server アナライザによって読み込まれるのは、次のレジストリ値です。

HKLM\Cluster\Resources\<Information Store リソースのリソース GUID>\Parameters\DestPath

Exchange セットアップ プログラムによって作成され、Exchange Server アナライザによって読み込まれる Active Directory の値は、msExchDataPath です。この値は、Active Directory 内の Exchange Server コンピュータ オブジェクトの属性で、次の場所にあります。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= <組織名> =Administrative Groups, CN= <管理グループ名> , CN=Servers, CN= <サーバー名>

Exchange Server アナライザで、DestPath の値と msExchDataPath の値が一致しないことが検出されると、エラーが表示されます。

これらの値が異なるものになる一般的な理由は、Exchange の運用開始後に一部またはすべての Exchange データ ファイルの場所が変更されたことです。たとえば、ハードウェアのアップグレード、メッセージ追跡ログ ファイルの移動、およびドライブ文字の変更が行われると、変更はクラスタ レジストリには反映されますが、Active Directory には反映されません。そのような変更が行われた後は、サービスの開始エラーやデータベースのマウントの問題を始めとした問題が生じる可能性があります。特に、Exchange Service Pack を適用した場合や、ロールアップ パッケージをインストールした場合に問題が発生する可能性があります。

注 :
この不一致はできるだけ早期に解決する必要があります。この問題が解決されるまでは、Exchange Server に Service Pack や更新プログラムをインストールしないでください。

次の手順を実行するには、Active Directory サービス インターフェイス (ADSI) Edit などの Active Directory エディタや LDP (ldp.exe) ツールを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. クラスタ レジストリの DestPath の値と一致するように、変更の影響を受けた Exchange 仮想サーバー (EVS) の msExchDataPath の値を変更します。msExchDataPath 属性は、CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名=Administrative Groups, CN=管理グループ名, CN=Servers, CN=サーバー名 にあります。

  2. 仮想サーバーの Exchange System Attendant リソースを再起動して変更を有効にします。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745) を参照してください。

ADSI Edit を使用して msExchDataPath 属性を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 288362「XADM:「イベント ID 5007 メッセージがログが Microsoft Exchange System Attendant によって出力されるシステムできる見付かるパス指定」」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=288362) を参照してください。


イベント ログのレプリケーションが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、クラスタのノードである各サーバーの次のレジストリ エントリを読み取ります。

HKEY_LOCAL_MACHINE\Cluster\Nodes\X\EnableEventLogReplication

注 :
X はノードの番号であり、1 から始まります。

Exchange Server アナライザによって EnableEventLogReplication の値が 1 であることが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

EnableEventLogReplication レジストリ エントリが 1 に設定されている場合、クラスタ ノードは、イベント ログ内のイベントをクラスタ内の他のすべてのノードにレプリケートします。イベント ログのレプリケーションが有効になっていると、Microsoft Operations Manager (MOM) などの複数のサーバーを監視するツールは、1 つのイベントを複数回、つまりノードごとに 1 回ずつ報告します。自動監視機能を使用している場合は、クラスタ ノードのイベント ログのレプリケーションを無効にすることをお勧めします。

クラスタのすべてのノードのイベント ログのレプリケーションを無効にするには

  1. ドメイン ユーザー アカウントまたはグローバル グループのメンバであるアカウントを使用して、クラスタの任意のノードにログオンします。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、以下のコマンドを入力します。

    cluster /prop EnableEventLogReplication=0
単一のクラスタ ノードのイベント ログのレプリケーションを無効にするには

  1. ドメイン ユーザー アカウントまたはグローバル グループのメンバであるアカウントを使用して、クラスタの任意のノードにログオンします。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、以下のコマンドを入力します。

    Cluster <無効にするノードの名前> /prop EnableEventLogReplication=0

イベント ログのレプリケーションを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 224969「Windows 2000 クラスタ サーバーにおけるイベント ログ複製の構成方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224969) を参照してください。

サーバー クラスタの管理の詳細については、「Administering Server Clusters」(http://go.microsoft.com/fwlink/?LinkId=45971) を参照してください (このサイトは英語の場合があります)。


ネットワーク名リソースで Kerberos が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、サーバー上で実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合は、そのコンピュータが Windows NT® Server 4.0 を実行していることを示します。この値が 5.0 の場合は Windows 2000 Server オペレーティング システムを実行していることを示し、5.2 の場合は Windows Server™ 2003 オペレーティング システムを実行していることを示します。

Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスのすべてのオブジェクトの serialNumber 属性の値も判断します。この文字列値に "Version 5.5" が含まれている場合は、コンピュータで Exchange Server 5.5 が実行されています。この文字列値に "Version 6.0" が含まれている場合は、コンピュータで Exchange 2000 Server が実行されています。この文字列値に "Version 6.5" が含まれている場合は、コンピュータで Exchange Server 2003 が実行されています。

最後に、Exchange Server アナライザは次のレジストリ エントリを読み取り、Exchange Server が Kerberos の有効なネットワーク名クラスタ リソースを持つクラスタで実行されているかどうかを判断します。

HKLM\Cluster\Resources\<ネットワーク名リソースのリソース GUID>\Parameters\RequireKerberos

RequireKerberos の値が 0 の場合はネットワーク名リソースが Kerberos 用に有効になっていないことを、この値が 1 の場合はネットワーク名リソースが Kerberos 用に有効になっていることを示します。

Exchange Server アナライザによって、Windows Server 2003 サーバーベースのクラスタで実行されている Exchange Server 2003 仮想サーバー上で RequireKerberos の値が 0 に設定されていることが検出されると、警告が表示されます。

この警告は、Exchange Server 2003 仮想サーバーで、Kerberos が有効なネットワーク名クラスタ リソースが使用されていないことを表しています。この構成はサポートされていないため、できるだけ早く修正する必要があります。

この警告を修正するには

  1. クラスタ アドミニストレータ プログラムを起動します。

  2. ネットワーク名リソースをオフラインにします。これによって、Microsoft Exchange System Attendant リソースを含む、ネットワーク名リソースに依存するリソースもすべてオフラインになります。

  3. ネットワーク名リソースを右クリックし、[プロパティ] をクリックします。

  4. [パラメータ] タブで、[Kerberos 認証を有効にする] オプションをクリックし、[OK] をクリックします。

  5. ネットワーク名リソースをオンラインに戻してから、他のオフライン リソースもオンラインにします。

Windows Server 2003 クラスタで Kerberos が有効なネットワーク名リソースを使用する方法の詳細については、Microsoft サポート技術情報の文書番号 302389「Windows Server 2003 のクラスタ ネットワーク名リソースのプロパティの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=302389) を参照してください。

クラスタ化の詳細については、以下のトピックを参照してください。

  • 『Exchange Server Deployment Guide』?(http://go.microsoft.com/fwlink/?linkid=47569) の「Deploying Exchange Server 2003 in a Cluster」(このサイトは英語の場合があります)

  • 『Exchange 2003 High Availability Guide』?(http://go.microsoft.com/fwlink/?linkid=47571) の「Planning for Exchange Clustering」(このサイトは英語の場合があります)


ネットワーク名リソースで Kerberos が有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、サーバー上で実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合は、そのコンピュータが Windows NT® Server 4.0 を実行していることを示します。この値が 5.0 の場合は Windows 2000 Server オペレーティング システムを実行していることを示し、5.2 の場合は Windows Server™ 2003 オペレーティング システムを実行していることを示します。

Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスのすべてのオブジェクトの serialNumber 属性の値も判断します。この文字列値に "Version 5.5" が含まれている場合は、コンピュータで Exchange Server 5.5 が実行されています。この文字列値に "Version 6.0" が含まれている場合は、コンピュータで Exchange 2000 Server が実行されています。この文字列値に "Version 6.5" が含まれている場合は、コンピュータで Exchange Server 2003 が実行されています。

最後に、Exchange Server アナライザは次のレジストリ値を読み取り、Exchange が、Kerberos の有効なネットワーク名クラスタ リソースを含むクラスタ内で実行されているかどうかを判断します。

HKLM\Cluster\Resources\<Resource GUID for Network Name resource>\RequireKerberos

RequireKerberos の値が 0 の場合はネットワーク名リソースが Kerberos 用に有効になっていないことを、この値が 1 の場合はネットワーク名リソースが Kerberos 用に有効になっていることを示します。

Exchange Server アナライザによって、Windows 2000 Server サーバー ベースのクラスタ内で実行されている Exchange 2000 Server 仮想サーバーで RequireKerberos の値が 1 に設定されていることが検出されると、警告が表示されます。

この警告は、Exchange 2000 Server 仮想サーバーで、Kerberos の有効なネットワーク名クラスタ リソースが使用されていることを示していますこの構成はサポートされていないため、可能な限り速やかに変更する必要があります。Microsoft サポート技術情報の文書番号 235529「Windows 2000 ベースのサーバー クラスタでの Kerberos サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=235529) で説明されているように、Exchange 2000 Server ネットワーク名リソース用の Kerberos 認証はサポートされていません。Exchange 2000 Server では、クラスタ化された Exchange 2000 Server 仮想サーバーが Kerberos 認証をサポートしていることを確認するテストは行われていません。

この警告を修正するには

  1. クラスタ内の任意のノードでコマンド プロンプトを開きます。

  2. 次のコマンドを実行します。cluster res "ネットワーク名リソースの名前" /priv requiredkerberos=0:dword

    注 :
    リソース名は、引用符で囲む必要があります。

  3. ネットワーク名リソースをオフラインにしてから、削除します。

  4. Active Directory ユーザーとコンピュータ スナップインを起動します。

  5. 削除したネットワーク名リソース用のコンピュータ アカウント オブジェクトを見つけ、Active Directory から削除します。

  6. この Exchange 仮想サーバー (EVS) 用の新しいネットワーク名リソースを作成し、Kerberos は無効にします。手順 3. で削除したネットワーク名リソースと同じ名前と構成を使用することができます。

  7. 新しいネットワーク名リソースをオンラインにしてから、EVS 内の残りのリソースをオンラインにします。

Windows 2000 Server クラスタで Kerberos の有効なネットワーク名リソースを使用する方法の詳細については、Microsoft サポート技術情報の文書番号 235529「Windows 2000 ベースのサーバー クラスタでの Kerberos サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=235529) を参照してください。


MSDTC がクラスタに存在しないように見える
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、クラスタ内に Microsoft 分散トランザクション コーディネータ (MSDTC) リソースが存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\Cluster\Resources\

ClusterMSDTCInstance の値が 0 の場合、Exchange Server アナライザは警告を表示します。

初期インストールおよび Service Pack のアップグレードをサポートするには、MSDTC リソースが Exchange Server クラスタ内に存在している必要があります。ただし、このリソースは重要なコンポーネントではないため、Exchange を実行しているときには不要です。

Exchange を実行しているときに MSDTC リソースは不要であることがわかっているため、組織の管理者がこのリソースを削除する場合があります。

ただし、Exchange Server 2003 の初期セットアップが完了しても MSDTC リソースを削除しないことをお勧めします。クラスタ内に MSDTC リソースを残しておくと、Service Pack のセットアップやその他の更新を実行できます。

この警告の問題を解決するには、新しい MSDTC リソースを作成します。MSDTC リソースを作成する方法の具体的な手順については、Exchange Server 2003 の展開ガイド (http://go.microsoft.com/fwlink/?LinkId=47569) で、クラスタ内での Exchange Server 2003 の展開に関する章の Windows Server 2003 サーバー クラスタに Microsoft 分散トランザクション コーディネータをインストールする方法についてのセクションを参照してください (このサイトは英語の場合があります)。

詳細情報

MSDTC および Exchange の詳細については、Exchange Server 2003 の高可用性についてのガイド (http://go.microsoft.com/fwlink/?LinkId=47571) で、Exchange Server 2003 クラスタリングの章にあるクラスタ グループのセクションを参照してください (このサイトは英語の場合があります)。

Microsoft Windows Server™ 2003 に MSDTC リソースを追加する方法の詳細については、Microsoft サポート技術情報の文書番号 301600「Windows Server 2003 クラスタで Microsoft 分散トランザクション コーディネータを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301600) を参照してください。

注 :
サポート技術情報の文書番号 301600 には、文書番号 817064「Windows Server 2003 でネットワーク DTC アクセスを有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=817064) への参照が含まれています。Exchange クラスタへのネットワーク DTC アクセスを無効にすることが、Exchange Server セキュリティに対するベスト プラクティスです。Exchange クラスタに分散トランザクション コーディネータ リソースを構成する場合は、ネットワーク DTC アクセスを有効にしないでください。


MSDTC が停止するとクラスタ グループに影響を与える
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取って、Microsoft 分散トランザクション コーディネータ (MSDTC) リソースに障害が発生したときにグループが影響を受ける設定方法で、リソースが構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\Cluster\Resources\

ClusterMSDTCInstance の値が 2 の場合、Exchange Server アナライザは警告を表示します。

初期インストールおよび Service Pack のアップグレードをサポートするには、MSDTC リソースが Exchange クラスタ内に存在している必要があります。ただし、Exchange を実行しているときにこのリソースは必要ありません。

既定では、MSDTC リソースに障害が発生すると、グループに影響を与えます。リソースの障害の例には、次の 2 つがあります。

  • ログ ファイルのサイズがディスクの容量を超える。

  • MSDTC リソースの物理ディスクに障害が発生する。

特に、MSDTC リソースに障害が発生すると、そのクラスタ ノード上で実行されているすべての Exchange サービスが、クラスタ内の別のノードにフェールオーバーされます。ただし、MSDTC リソースは必須リソースではないため、グループに影響を与えるような構成にする必要はありません。

この警告の問題を解決するには、MSDTC リソースの障害によってグループが影響を受けないように Exchange クラスタを構成します。

MSDTC リソースの障害によってグループが影響を受けないように Exchange を構成するには、次の操作を行います。

  1. クラスタの任意のノードにログオンします。

  2. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[管理ツール] をポイントし、[クラスタ アドミニストレータ] をクリックします。

  3. [グループ] で、MSDTC リソースが存在するクラスタ グループを右クリックします。

  4. MSDTC リソースを右クリックし、[プロパティ] をクリックします。

  5. [詳細設定] タブで、[グループに適用する] チェック ボックスをオフにして、[OK] をクリックします。

詳細情報

MSDTC リソースを作成する方法の具体的な手順については、Exchange Server 2003 の展開ガイド (http://go.microsoft.com/fwlink/?LinkId=47569) で、クラスタ内での Exchange Server 2003 の展開に関する章の Windows Server 2003 サーバー クラスタに Microsoft 分散トランザクション コーディネータをインストールする方法についてのセクションを参照してください (このサイトは英語の場合があります)。

MSDTC および Exchange の詳細については、Exchange Server 2003 の高可用性についてのガイド (http://go.microsoft.com/fwlink/?LinkId=47571) で、Exchange Server 2003 クラスタリングの概要の章にあるクラスタ グループのセクションを参照してください (このサイトは英語の場合があります)。

Microsoft Windows Server™ 2003 に MSDTC リソースを追加する方法の詳細については、Microsoft サポート技術情報の文書番号 301600「Windows Server 2003 クラスタで Microsoft 分散トランザクション コーディネータを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301600) を参照してください。

注 :
サポート技術情報の文書番号 301600 には、文書番号 817064「Windows Server 2003 でネットワーク DTC アクセスを有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=817064) への参照が含まれています。Exchange クラスタへのネットワーク DTC アクセスを無効にすることが、Exchange Server セキュリティに対するベスト プラクティスです。Exchange クラスタに分散トランザクション コーディネータ リソースを構成する場合は、ネットワーク DTC アクセスを有効にしないでください。


MTA が停止するとクラスタ グループに影響を与える
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバー システムの Cluster\Resources レジストリ設定を調べます。

HKEY_LOCAL_MACHINE\Cluster\Resources

Exchange Server アナライザによって、ネイティブ モードの組織の Exchange Server 2003 クラスタ上でメッセージ転送エージェント (MTA) Stacks サービス リソースが実行されていることが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

ベスト プラクティスとして、MTA が停止するか障害が発生したときに Exchange 仮想サーバーのフェールオーバーが発生しないように、Exchange 管理者が MTA リソースを構成することをお勧めします。

注 :
Microsoft Exchange 2000 Server および Microsoft Exchange Server 2003 の MTA Stacks サービスは、混在モードの環境で、Exchange 2000 Server サーバーまたは Exchange Server 2003 サーバーと Microsoft Exchange Server 5.5 サーバーとの間に下位互換性のあるメッセージ転送サービスを提供する場合によく使用されます。Exchange 2000 Server または Exchange Server 2003 のみのネイティブ モード環境に移行すると、MTA は Exchange サービスを実行するときの不可欠なリソースではなくなります。

MTA Stacks サービスの実行が停止するかサービスに障害が発生すると、Exchange 仮想サーバーのフェールオーバーが開始される可能性があります。Exchange 仮想サーバー (EVS) のフェールオーバーの実行を防止するには、ベスト プラクティスとしての次の手順に従って、フェールオーバーが実行されないように MTA Stacks サービスを構成することをお勧めします。

Exchange サーバー クラスタに影響を与えない状態に MTA Stacks サービスを構成するには、次の操作を行います。

  1. Cluster Administrator を開きます。

  2. MTA Stack サービス リソースの Affect this Group オプションをクリアします。

詳細情報

Exchange Server 2003 における MTA Stacks サービス サポートのガイドラインについては、Microsoft サポート技術情報の文書番号 810489「Exchange 2000 Server および Exchange Server 2003 の MTA Stacks サービス サポートのガイドライン」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810489) を参照してください。

Exchange Server 2003 アーキテクチャの MTA の詳細については、Exchange Server 2003 アーキテクチャにおける Exchange MTA についてのページ (http://go.microsoft.com/fwlink/?LinkId=63496) を参照してください (このサイトは英語の場合があります)。

クラスタ内に Exchange Server 2003 を展開する方法の詳細については、クラスタ内での Exchange Server 2003 の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=63495) を参照してください (このサイトは英語の場合があります)。

クラスタ アドミニストレータの使用方法については、クラスタ アドミニストレータを使用した Exchange クラスタの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63493) を参照してください (このサイトは英語の場合があります)。


クラスタが 2 ノードのアクティブ/アクティブ クラスタである
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2006-04-28

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ClusSvc (クラスタ サービス) の Started キーの値を判断します。この値が True の場合は、クラスタ サービスが実行されています。この値が False の場合は、クラスタ サービスは実行されていません。

Exchange Server アナライザは次のレジストリ エントリを読み取り、クラスタ内のノードの数も判断します。

HKEY_LOCAL_MACHINE\Cluster\Nodes\ <ノード番号> \NodeName

NodeName のインスタンスの数は、クラスタ内に存在するノードの数を表します。さらに、Exchange Server アナライザは次のレジストリ エントリを読み取り、クラスタ内の Exchange Server リソースの数を判断します。

HKLM\Cluster\Resources\ <クラスタ リソース GUID> \Parameters\DestPath

Exchange Server クラスタ上の以下のリソースには、DestPath 値があります。

  • Microsoft Exchange メッセージ転送エージェント

  • Microsoft Exchange Information Store

DestPath のインスタンスの数は、クラスタ内で Exchange 仮想サーバー (EVS) が実行されているサーバーの数を示します。

Exchange Server アナライザによって、NodeName のインスタンスが 2 つあるクラスタ内に DestPath のインスタンスが 3 つ存在していると判断されると、警告が表示されます。この警告は、クラスタがアクティブ/アクティブ クラスタと呼ばれる、EVS が実行されているサーバーを 2 つ含む 2 ノードのクラスタであることを示しています。

  • アクティブ/アクティブ クラスタ モデルでは、クラスタ内の Exchange 仮想サーバーの数は、クラスタ内の物理ノードの数と等しいか、またはそれ以上です。

注 :
アクティブ/アクティブ Exchange クラスタは、2 つのノードによって構成されるクラスタでのみ作成できます。3 つ以上のノードがクラスタ内にある場合は、アクティブ/パッシブ モデルを使用する必要があります。
  • アクティブ/パッシブ クラスタ モデルでは、クラスタ内の Exchange 仮想サーバーの数は、クラスタ内の物理ノードの数より少なくなります。

Microsoft は、Exchange Server のアクティブ/アクティブ クラスタをサポートしていますが、Exchange クラスタではアクティブ/パッシブの実装を使用することを強くお勧めします。Microsoft でサポートしているのは、スケーラビリティに関する以下の制限を満たすアクティブ/アクティブ Exchange クラスタのみです。

  • 各物理ノードの Exchange 仮想サーバーあたりの同時ユーザー接続数は、どのような状況でも 1,900 を超えてはいけません。クラスタのいずれかのノードが使用できず、1 つのノードですべての Exchange 仮想サーバーがオンラインになっている場合、Exchange 仮想サーバー 2 台でのスケーラビリティの制限は、3,800 接続のままになります。各ユーザーは複数の接続を作成できるため、メールボックスの数から接続の数を正確に予測することはできません。

  • 各 Exchange ストア プロセスの平均 CPU 使用率は、40% を超えてはいけません。1 つのノード上で、STORE.EXE プロセスによる合計 CPU 使用率が 10 分間以上にわたって 40% を超えている場合、ユーザーを別の Exchange 仮想サーバーまたは Exchange サーバーに移動する必要があります。この負荷には、管理タスクのために消費される CPU 使用率は含まれないことに注意してください。

アクティブ/アクティブ クラスタ構成をアクティブ/パッシブ構成に移行する場合は、2 番目の EVS のリソースを移動し、次にこのサーバーの使用を停止する作業を行う必要があります。

アクティブ/アクティブ クラスタをアクティブ/パッシブ クラスタに移行するには

  1. クラスタ内の 2 番目の EVS でホストされているメールボックスを最初の EVS に移動します。クラスタ内の最初の EVS には常に、クラスタ内の Microsoft Exchange メッセージ転送エージェント (MTA) リソースのみが格納されています。

  2. すべてのメールボックスを最初の EVS に移動した後で、2 番目の EVS をオフラインにします。

  3. 以下のいずれかの操作を実行して、2 番目の EVS を削除します。

    • Exchange Server 2003 クラスタの場合は、[Microsoft Exchange System Attendant] リソースを右クリックし、[Exchange 仮想サーバーの削除] をクリックます。

    • Exchange Server 2000 クラスタの場合は、[Microsoft Exchange System Attendant] リソースを右クリックし、[削除] をクリックます。

  4. Active Directory® ディレクトリ サービスから EVS オブジェクトが削除されていることを確認します。Exchange Server 2003 では、クラスタ サービス アカウントのアクセス許可に変更が加えられているため、使用しているアカウントに Active Directory オブジェクトを削除するためのアクセス許可が必要です。

  5. 2 番目の EVS 内の残りのリソース (論理ディスク、ネットワーク名、IP アドレスなど) をオフラインにして、それらを削除します。

  6. 2 番目の EVS を含んでいたリソース グループを削除します。

EVS を削除する方法の詳細については、『Deploying Microsoft Exchange 2000 Server Clusters』(http://go.microsoft.com/fwlink/?LinkId=9393) の「Removing an Exchange virtual server from a Cluster」を参照してください (このサイトは英語の場合があります)。

Exchange クラスタに関するベスト プラクティスと推奨事項の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Windows サーバー クラスタ内での Exchange の展開に関する詳細については、Microsoft サポート技術情報の文書番号 815180「[XADM] Exchange 2000 をアクティブ/アクティブ クラスタで展開する際の考慮点」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815180) を参照してください。


クォーラム ログが小さすぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange クラスタ >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、クラスタに構成されているクォーラム ログのサイズを判断します。

HKEY_LOCAL_MACHINE\Cluster\Quorum\MaxQuorumLogSize

MaxQuorumLogSize の値が 4,194,304 (10 進数、16 進数では 0x400000) 未満であることが検出されると、警告が表示されます。

MaxQuorumLogSize レジストリの値は、Reset quorum log at クラスタ クォーラム パラメータについて現在構成されている値を表します。この警告は、MaxQuorumLogSize が 4,096 KB より小さい場合に生成されます。

クラスタ データベースへの変更はすべて、クラスタによってクォーラム ログ ファイルに記録されます。クォーラム ログが指定のサイズに達すると、クラスタによりデータベースが保存され、ログ ファイルがリセットされます。Microsoft Windows® 2000 Server ベースのクラスタでは、クォーラムの既定のサイズ制限は 64 KB です。Windows Server™ 2003 ベースのクラスタでは、クォーラムの既定のサイズ制限は 4,096 KB です。Exchange Server クラスタでは、Reset quorum logs at プロパティを 4,096 KB に構成することをお勧めします。これによって、クラスタ構成情報 (どのサーバーがクラスタの一部であるか、どのリソースがクラスタにインストールされているか、それらのリソースがオンライン、オフラインなどのどのような状態にあるか、など) を保持するための十分な容量が確保されます。

この警告を修正するには

  1. クラスタ アドミニストレータを起動します。

  2. 左側のペインで、クラスタを表すオブジェクトを右クリックし、[プロパティ] をクリックします。

  3. [クォーラム] タブで、[クォーラム ログを更新するサイズ] の値を 4,096 に構成します。

  4. [OK] をクリックして変更を保存します。

既定のクォーラム ログ サイズ制限の詳細については、Microsoft サポート技術情報の文書番号 225081「クラスタのリソースであるクォーラム ログのサイズはデフォルトで 64 KB に設定されている」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=225081) を参照してください。


Exchange Server
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクションの文書では、Microsoft® Exchange Server アナライザ ツールで、Exchange Server コンピュータに関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出された Exchange に関連するエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


アカウント ロックアウトがインストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-08-28

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバー上の System32 フォルダに ALockout.dll という名前のファイルが存在するかどうかを判断します。ALockout.dll は、Account Lockout and Management Tools (ALTools.exe) に含まれています。これらのツールは、アカウントの管理や、アカウント ロックアウトの問題のトラブルシューティングを行う管理者を支援します。

Exchange サーバーに ALockout.dll が存在することが検出されると、エラーが表示されます。

Account Lockout and Management Tools は、ネットワーク アプリケーションまたはサービスをホストしているサーバー (Exchange サーバーを含む) 上では使用しないでください。Account Lockout and Management Tools を Exchange サーバー上にインストールすると、Exchange サービスを開始できなくなる場合があります。したがって、Exchange サーバーに Account Lockout and Management Tools がインストールされている場合は、アンインストールすることを強くお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
このエラーを修正するには

  1. コマンド プロンプトで、「regsvr32 /u alockout.dll」と入力します。

  2. 次のレジストリ キーにある ALockout.dll 値を削除します。HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
注 :
ALockout.dll 値を削除すると、AppInit_DLLs レジストリ エントリは空になります。コンピュータを再起動します。
  1. System32 フォルダから ALockout.dll ファイルを削除します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Account Lockout and Management Tools の詳細については、「Account Passwords and Policies 」(http://go.microsoft.com/fwlink/?LinkId=52465) の「Account Lockout Tools」を参照してください (このサイトは英語の場合があります)。


Active Directory サイトが一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、実装されている Win32 API DsGetSiteName 関数を使用して、ドメイン コントローラの Active Directory® ディレクトリ サービスのサイト名およびローカルの Exchange Server の Active Directory サイト名についてのクエリを実行します。

Exchange Server アナライザは、ドメイン コントローラの Active Directory サイト名とローカルの Exchange Server の Active Directory サイト名が一致しないことを確認すると、警告を表示します。

この警告は、DSAccess (Directory Service Access) 処理によるライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求が、ローカルの Active Directory サイトの外部に送信されることを示します。このため、Exchange Server のパフォーマンスが大幅に低下する可能性があります。

この状況は、オフサイトのドメイン コントローラの静的構成、ネットワークまたはドメイン コントローラ コンピュータの停止によるサイト内のドメイン コントローラへの到達不能、または Exchange Server と同じサイト内に Active Directory ドメイン コントローラが配置されていない、正しくない Active Directory トポロジの設計によって発生する場合があります。

DSAccess は、ディレクトリ情報にアクセスしてそれをキャッシュに格納する共有 Exchange Server コンポーネントです。DSAccess は、Active Directory サイトの構成や Active Directory サーバーの可用性などの条件に基づいて、他の Exchange コンポーネントが参照の対象とする必要のあるディレクトリ サーバーを動的に検出します。Exchange フロントエンド サーバーは DSAccess を使用して、特定のユーザーのメールボックスが存在するサーバー、ユーザー オブジェクト用の SMTP (Simple Mail Transfer Protocol) アドレス、およびパブリック フォルダ ストアが存在するサーバーを判断します。

初期化時に、一連の静的に構成されたドメイン コントローラまたはグローバル カタログがレジストリ内に見つからない場合、DSAccess は、検索処理を使用してネットワーク トポロジを識別し、ディレクトリ サーバーの可用性と適合性を評価します。ドメイン コントローラの適合性を判断する処理には、そのドメイン コントローラが Exchange Server と同じ Active Directory サイト内に存在するかどうかを確認する作業が含まれています。

サイト間で LDAP 要求を送受信することにより発生する待機時間を短縮するには、ドメイン コントローラが存在する Active Directory サイト内に Exchange Server を配置する必要があります。

この問題を修正するには、次のことを確認します。

  • Active Directory トポロジのサイト定義を評価し、それぞれの Exchange Server が同じ Active Directory サイト内にあるドメイン コントローラにアクセスすることを確認します。

  • 静的に構成されているすべてのドメイン コントローラが、Exchange Server と同じ Active Directory サイト内に存在していることを確認します。

詳細情報

DSAccess を構成およびトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • ディレクトリの統合と Exchange Server についてのページ (http://go.microsoft.com/fwlink/?LinkId=63447) (このサイトは英語の場合があります)

  • ディレクトリ アクセスの概要とトラブルシューティングについてのオンライン ブック (http://go.microsoft.com/fwlink/?LinkId=39012) (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570)


管理用のファイル共有が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の管理用共有が無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareServer

AutoShareServer の値が 0 に設定されていることが検出されると、エラーが表示されます。

このエラーは、このサーバーで、サーバーが作成した既定の管理用共有が無効になっていることを示します。既定の管理用共有が無効になっていると、Exchange Server のオンライン バックアップや復元が機能しない可能性があります。バックアップ プログラムによっては、データを復元しようとしたときにエラー メッセージが表示されることがあります。テープ バックアップのログでエラー メッセージが見つかる場合もあります。

また、管理用共有が削除されていると、Exchange Server のオンライン バックアップ中に、"予期しないエラーが発生しました 0xc0040000 Microsoft Exchange Server コンピュータは使用できません。" というメッセージが表示される場合があります。この問題を解決するために、レジストリを編集してこのサーバー サービスを再開することによって、既定の管理用共有を再度有効にすることをお勧めします。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

  3. 右側のペインで、[AutoShareServer] を見つけてダブルクリックします。

  4. 値を 0 から 1 に変更します。

  5. レジストリ エディタを終了し、このサーバー サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows Server™ 2003 の既定の管理用共有を復元する方法の詳細については、Microsoft サポート技術情報の文書番号 816113「[HOWTO] Windows Server 2003 でレジストリ エディタを使用して管理用共有を復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816113) を参照してください。


AFD.SYS ドライバと X.400 コネクタの相互運用性
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Microsoft Windows NT® Server 4.0 上で Exchange Server コンピュータが実行されていることを示します。値が 5.0 の場合、Exchange Server コンピュータは Windows 2000 Server 上で実行されており、値が 5.2 の場合、Windows Server™ 2003 上で実行されています。

また、Exchange Server アナライザは Win32_ComputerSystem Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、NumberOfProcessors キーの値を判断します。この値は、コンピュータに搭載されているプロセッサの数を表します。これらのプロセッサには、物理プロセッサと論理プロセッサの両方が含まれます。Intel のハイパー スレッディング テクノロジを使用すると、物理プロセッサを 2 つの論理プロセッサに分割できます。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange Server が X.400 コネクタのブリッジヘッドかどうかを判断します。

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMTA

Exchange Server アナライザは、CIM_Datafile WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Afd.sys というファイルの Version キーの値を判断します。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • Exchange Server コンピュータが Windows Server 2000 上で実行されている。

  • NumberOfProcessors の値が 1 より大きい。

  • Exchange Server が X.400 コネクタのブリッジヘッドである。

  • WINDOWSPATH%\\system32\\drivers\\afd.sys の Version キーの値が 5.0.2195.7036 から 5.0.2195.7060 の範囲にある。

この警告は、サーバーにインストールされている Afd.sys のバージョンによって、このサーバー上の X.400 コネクタとのメール フローの問題を引き起こす可能性があることを示します。

この問題を解決するには、Microsoft サポート技術情報の文書番号 904712「メール配信が予想より低下、またはメール配信が Exchange Server 5.5 のリモート サイトの X.400 コネクタを停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=904712) で参照されている更新プログラムを入手してください。


データベースの Aging Keep Time が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchAgingKeepTime 属性が設定されているかどうかを判断します。この属性は、インデックス、ビュー、および分類を削除する時期を判断するために使用される時間値を表します。この属性が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange クライアントが Exchange データベース テーブル内に作成したビューで使用されているインデックスが一定の時間使用されない場合、それらのインデックスはこの時間でクリーン アップされます。msExchAgingKeepTime 属性は、インデックスが削除されるまでの最短期間を指定します。Exchange 2000 Server の最初のリリースでの既定値は 8 日でした。Exchange 2000 Server の Service Pack 1 (SP1) 以降のすべてのバージョン (Exchange Server 2003 および Exchange Server 2007 を含む) の Exchange Server では、既定値は 40 日です。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
Aging Keep Time 値を表示または変更するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=<Exchange 組織名>] の順に展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を展開します。次に、[CN=<ストレージ グループ名>] を選択します。

  5. 詳細ウィンドウで、[CN=<メールボックス ストア名>] を右クリックし、[プロパティ] を選択します。

  6. [Attribute Editor] で、[msExchAgingKeepTime] 属性をクリックし、[Edit] をクリックします。

  7. [Edit Attribute] ボックスで、[Clear] をクリックして値をクリアします。

  8. [適用] をクリックし、[OK] をクリックします。

  9. ADSI Edit を終了します。変更を行った場合は、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

Exchange Server のインフォメーション ストア フォルダへのアクセスで発生する可能性のある問題の詳細については、Microsoft サポート技術情報の文書番号 216076「[XADM] インフォメーション ストア フォルダにアクセスすると、処理速度が低下する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=216076) を参照してください。


Antigen の更新プログラムが利用可能である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-06-20

Microsoft Exchange Server アナライザ ツールは、CIM_Datafile WMI (Microsoft® Windows® Management Instrumentation) クラスに対してクエリを実行し、MimeNavigator.dll の Version キーの値を判断します。このモジュールは、Microsoft Antigen Version 8 および 9 に含まれています。

MimeNavigator.dll の Version キーの値が、Version 8 の場合は 8.00.1517.0、Version 9 の場合は 9.00.1055.0 より小さいことが検出されると、警告が表示されます。

この警告は、Exchange サーバーに Microsoft Antigen Version 8 または 9 がインストールされており、ソフトウェア更新プログラムが存在することを示しています。この更新プログラムの使用は強く推奨されており、サーバーの全体的なパフォーマンスと信頼性を向上させることができます。

この問題に対処するには、Microsoft サポート技術情報の文書番号 928082「SMTP メッセージのサイズは、Antigen のスキャン処理中に、増加します。」に記載されている推奨事項を確認し、更新プログラムを適用します。


アプリケーション ログのサイズ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-11-09

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、アプリケーション ログ ファイルの最大サイズを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\MaxSize

MaxSize の値が 41,943,040 バイト (40 MB) より小さいことが検出されると、ベスト プラクティスのメッセージが表示されます。

既定では、アプリケーション ログ ファイルの最大ログ サイズは、Windows Server 2003 の場合は 16,777,216 バイト (16384 KB)、Windows 2000 Server の場合は 524,288 バイト (512 KB) です。Exchange Server を実行しているコンュータでのベスト プラクティスとして、アプリケーション ログ ファイルの最大サイズを 40MB (40,960KB として入力) 以上に設定することをお勧めします。アプリケーション ログ ファイルのサイズを大きくすると、保持されるアプリケーション イベントの数が増加します。追加されたイベント情報は、トラブルシューティング時に役立ちます。

アプリケーション ログの最大サイズを大きくするには

  1. [イベント ビューア] Microsoft 管理コンソール (MMC) スナップインを開きます。

  2. [アプリケーション] を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[ログ サイズ] の [最大ログ サイズ] ボックスに「40960」以上の値を入力し、[OK] をクリックします。


ASP.NET Rootver が壊れている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ASP.NET の Rootver キーに設定されている値を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET

以下の条件に当てはまる場合は、エラーが表示されます。

  • Exchange Server アナライザによって、Rootver 値が 0.0.0.0 に設定されていることが検出された。

  • クラスタ サービスが実行されている。

場合によっては、ASP.NET セットアップがエラーを通知せずに失敗することがあります。この場合は、Rootver キーが 0.0.0.0 に設定されています。Rootver 値を 0.0.0.0 に設定すると、Microsoft Exchange System Attendant サービスやその他の Exchange Server サービスが Exchange Server 2003 および Exchange Server 2007 のクラスタ上で開始できなくなります。このエラーを修正するには、Rootver 値を以下のいずれかに設定する必要があります。

  • Exchange Server 2003 の場合、Rootver キー = 1.1.4322.0

  • Exchange Server 2007 の場合、Rootver キー = 2.0.50727.0

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Rootver を 1.1.4322.0 に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\Software\Microsoft\ASP.NET\

  3. 詳細ウィンドウで、RootVer キーをダブルクリックします。

  4. [文字列の編集] ダイアログ ボックスで、[値のデータ] を上記に示した適切な値に設定し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


オペレーティング システムの自動デバッグが無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、オペレーティング システムのデバッグが無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto

Auto の値が 0 に設定されていることが検出されると、警告が表示されます。

既定では、Microsoft Windows® 2000 Server および Windows Server™ 2003 オペレーティング システムと共に、ワトソン博士という名前のアプリケーション デバッガがインストールされます。デバッガは、他のプログラムに含まれているエラーの検出、特定、および修正に役立つプログラムです。プログラマはデバッガを使用して、プログラムのステップ実行、データの調査、変数の値などの状況の監視といった操作を行うことができます。

既定のオプションは、ワトソン博士が最初に実行されるときに設定されます。これは、プログラム エラーが発生したとき、またはユーザーがワトソン博士を起動したときのどちらかです。

アプリケーション エラーが発生すると、Windows は、プログラムのエラー ハンドラを検索します。プログラムのエラー ハンドラは、プログラムの実行中にエラーが発生した場合に、エラーの処理を行います。Windows でプログラムのエラー ハンドラが見つからない場合、プログラムが現在デバッグ中ではないことが確認され、そのエラーは未処理であると見なされます。次に Windows は、レジストリ内でプログラム エラー デバッガを探すことによって未処理のエラーを処理します。

Windows の動作は、HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug の下にある 2 つのレジストリ値の設定によって決まります。

これらのレジストリ エントリの名前は、Debugger と Auto です。Debugger エントリの値は、プログラム エラーを分析するために使用されるデバッガのコマンドを指定します。Debugger エントリの値が見つからない場合、Windows は Auto エントリの値が 0 または 1 のどちらに設定されているかを確認します。

  • Auto エントリの値が 0 に設定されている場合、プログラム エラーが発生したことを通知するメッセージ ボックスが生成されます。Debugger エントリの値によって有効なデバッガのコマンドが指定されている場合、メッセージ ボックスに [OK] と [キャンセル] という 2 つのボタンが表示されます。[OK] をクリックすると、プログラムが停止されます。[キャンセル] をクリックすると、指定されているデバッガが起動されます。Debugger エントリの値が空の場合、メッセージ ボックスには [OK] だけが表示され、デバッガは起動されません。

  • Auto エントリの値が 1 に設定されており、Debugger エントリの値によって有効なデバッガのコマンドが指定されている場合、デバッガが自動的に起動され、メッセージ ボックスは生成されません。

Windows がインストールされるときに、Auto エントリの値は既定で 1 に設定され、Debugger エントリの値には、ワトソン博士を起動するコマンド (drwtsn32 -p %ld -e %ld -g) が指定されます。つまり、プログラム エラーが発生すると、ワトソン博士によって自動的にエラーが診断され、適切な診断情報がログに出力されます。

Exchange Server コンピュータでのベスト プラクティスとして、プログラム エラー デバッガを使用することをお勧めします。既定のデバッガとしてワトソン博士以外のプログラムを使用していた場合、代わりにワトソン博士を使用するには、コマンド プロンプトを開き、コマンドとして「drwtsn32 -i」と入力してワトソン博士を起動します。「-i」と入力することで、必要な変更がレジストリに加えられます。

コマンド プロンプトからワトソン博士を既定のデバッガとして登録するには

  1. コマンド プロンプト ウィンドウを開きます。

  2. 次のコマンドを実行します。drwtsn32 -i

  3. ワトソン博士が既定のアプリケーション デバッガとしてインストールされたことを知らせるメッセージが表示されます。[OK] をクリックしてこのメッセージを確認します。

ユーザー インターフェイスからワトソン博士を既定のデバッガとして登録するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「drwtsn32」と入力し、Enter キーを押します。Windows ワトソン博士のユーザー インターフェイスが表示されます。

  2. [クラッシュ ダンプ ファイルの作成] チェック ボックスをオンにします。

  3. [OK] をクリックして変更を保存し、Windows ワトソン博士のユーザー インターフェイスを閉じます。

Windows ワトソン博士の詳細については、ワトソン博士のユーザー インターフェイスで F1 キーを押し、ワトソン博士のヘルプを参照してください。

ワトソン博士以外のプログラム エラー デバッガを使用する予定がある場合は、Microsoft サポート技術情報の文書番号 188296「[NT] Windows NT でワトソン博士を無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=188296) に記載されている手順に従って、ワトソン博士を無効にすることができます。


LDAP 読み取りの平均待ち時間が 50 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-14

Microsoft Exchange アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Process パフォーマンス オブジェクトの LDAP Read Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

LDAP Read Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 読み取り要求の実行にかかった時間をミリ秒単位で示します。Exchange アナライザは、サンプルを 5 秒ごとに 5 分間取得します。次に、Exchange アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。平均値が 50 ミリ秒を超えていることが検出されると、警告が表示されます。

LDAP 読み取りの待ち時間が長くなる原因として、リモート プロシージャ コール (RPC) の待ち時間の増加、およびキューの増大が考えられます。LDAP 読み取りの待ち時間の増加は、一般的に次のいずれかの問題を示しています。

  • ドメイン コントローラへのネットワーク接続に関するパフォーマンスの問題

  • ドメイン コントローラ自体に関するパフォーマンスの問題

注 :
ユーザーが別の物理サイトにあるドメイン コントローラに接続する場合、LDAP の待ち時間は一般的に長くなります。ただし、通常はここで示されている推奨の最大待ち時間を適用する必要があります。

この警告を記録したドメイン コントローラが別の物理サイトに配置されている場合、この警告を報告するドメイン コントローラが Exchange サーバーで使用されていなければ、このエラーを無視してかまいません。ドメイン コントローラが Exchange に使用されているかどうかを判断する手段として、MSExchangeDSAccess サービスのトポロジ コンポーネントに対する診断ログのレベルを [最小] にするという方法があります。MSExchangeDSAccess のイベント ID 2080 が表示されない場合、この警告は無視してかまいません。

この警告を解決するには、次の操作を行います。

  • ドメイン コントローラに至るすべてのネットワーク接続が機能しており、それらの接続がインターネット制御メッセージ プロトコル (ICMP) トラフィックをサポートしていることを確認します。

  • 次の文書で紹介されているベスト プラクティスを検討します。

    • LDAP Read Time パフォーマンス カウンタ、および Active Directory に関する問題のトラブルシューティングに利用できるその他のカウンタの詳細については、Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) で、Active Directory に関連する問題を排除する方法についてのトピックを参照してください (このサイトは英語の場合があります)。この文書には、Active Directory のパフォーマンスを向上させる方法に関する情報も含まれています。

    • Active Directory のパフォーマンスを最大化する方法の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) の、Active Directory 統合のチューニングに関するセクションを参照してください (このサイトは英語の場合があります)。

    • Active Directory サーバーの高可用性を実現する方法の詳細については、Exchange Server 2003 可用性向上ガイドのページ (http://go.microsoft.com/fwlink/?LinkId=47571) にある、システムレベルのフォールト トレラント対策に関するトピックで、Active Directory およびドメイン ネーム システムへの安全なアクセス方法に関するセクションを参照してください (このサイトは英語の場合があります)。

    • ネットワーク帯域幅に関する考慮事項の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) にある Exchange パフォーマンスについての項目のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。


LDAP 読み取りの最大待ち時間が 100 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-14

Microsoft Exchange アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Process パフォーマンス オブジェクトの LDAP Read Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

LDAP Read Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 読み取り要求の実行にかかった時間をミリ秒単位で示します。Exchange アナライザは、サンプルを 5 秒ごとに 5 分間取得します。次に、Exchange アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。最大値が 100 ミリ秒を超えていることが検出されると、エラーが表示されます。

LDAP 読み取りの待ち時間が長くなる原因として、リモート プロシージャ コール (RPC) の待ち時間の増加、およびキューの増大が考えられます。LDAP 読み取りの待ち時間の増加は、一般的に次のいずれかの問題を示しています。

  • ドメイン コントローラへのネットワーク接続に関するパフォーマンスの問題

  • ドメイン コントローラ自体に関するパフォーマンスの問題

注 :
ユーザーが別の物理サイトにあるドメイン コントローラに接続する場合、LDAP の待ち時間は一般的に長くなります。ただし、通常はここで示されている推奨の最大待ち時間を適用する必要があります。

Exchange サーバーは、グローバル カタログ サーバーとドメイン コントローラの最新のリストを維持するために、ドメイン外部のグローバル カタログ サーバーに対して 15 分ごとにクエリを実行します。これらのディレクトリ サーバーの中にはリモートに存在するものもあるため、これらのキューの待ち時間は長くなることがあります。要求が、たとえば 1 秒あたり 0.5 件未満のように低い頻度の場合は、特に問題はありません。

このエラーを記録したドメイン コントローラが別の物理サイトに配置されている場合には、このエラーを報告するドメイン コントローラが Exchange サーバーで使用されているかどうかを判断できれば、このエラーを無視してかまわないこともあります。ドメイン コントローラが Exchange に使用されているかどうかを判断する手段として、MSExchangeDSAccess サービスのトポロジ コンポーネントに対する診断ログのレベルを [最小] にするという方法があります。MSExchangeDSAccess のイベント ID 2080 が表示されない場合、このエラーは無視してかまいません。

重要 :
混在モードの環境の場合にのみ、Exchange 2000 SP2 の時期の前後に tokenGroups や tokengroupsGlobalandUniversal などのセキュリティ関連の特定のユーザー属性についてこの動作が導入されました。これらの属性は、ユーザーが属するセキュリティ グループを指定し、それによって、そのユーザーのホーム ドメインに対して権限を持つドメイン コントローラに Exchange サーバーがクエリを実行する必要のあるパブリック フォルダなどのリソースをセキュリティで保護するために、ユーザーに与えるアクセス許可を指定するのに使用します。権限を持つドメイン コントローラがリモート サイトに存在し、ローカルのパブリック フォルダにアクセスする多数のリモート ドメイン ユーザーからこのドメイン コントローラに対してクエリが実行されると、RPC 待ち時間が増加する可能性があります。

この動作の詳細については、以下の Exchange Server ブログのトピックを参照してください。

  • Exchange でローカルのグローバル カタログが使用されない件についてのページ (このサイトは英語の場合があります)

    注 :
    ブログへのリンクは、必要な技術情報の検索に利用することを目的として用意されています。それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

このエラーを解決するには、次の操作を行います。

  • ドメイン コントローラに至るすべてのネットワーク接続が機能しており、それらの接続がインターネット制御メッセージ プロトコル (ICMP) トラフィックをサポートしていることを確認します。

  • 次の文書で紹介されているベスト プラクティスを検討します。

    • LDAP Read Time パフォーマンス カウンタ、および Active Directory に関する問題のトラブルシューティングに利用できるその他のカウンタの詳細については、Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) で、Active Directory に関連する問題を排除する方法についてのトピックを参照してください (このサイトは英語の場合があります)。この文書には、Active Directory のパフォーマンスを向上させる方法に関する情報も含まれています。

    • Active Directory のパフォーマンスを最大化する方法の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) の、Active Directory 統合のチューニングに関するセクションを参照してください (このサイトは英語の場合があります)。

    • Active Directory サーバーの高可用性を実現する方法の詳細については、Exchange Server 2003 可用性向上ガイドのページ (http://go.microsoft.com/fwlink/?LinkId=47571) にある、システムレベルのフォールト トレラント対策に関するトピックで、Active Directory およびドメイン ネーム システムへの安全なアクセス方法に関するセクションを参照してください (このサイトは英語の場合があります)。

    • ネットワーク帯域幅に関する考慮事項の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) にある Exchange パフォーマンスについての項目のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。


LDAP 検索の平均待ち時間が 50 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-14

Microsoft Exchange アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Process パフォーマンス オブジェクトの LDAP Search Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

LDAP Search Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 検索要求の実行にかかった時間をミリ秒単位で示します。Exchange アナライザは、サンプルを 5 秒ごとに 5 分間取得します。次に、Exchange アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。平均値が 50 ミリ秒を超えていることが検出されると、警告が表示されます。

LDAP 検索の待ち時間が長くなる原因として、リモート プロシージャ コール (RPC) の待ち時間の増加、およびキューの増大が考えられます。LDAP 検索の待ち時間の増加は、一般的に次のいずれかの問題を示しています。

  • ドメイン コントローラへのネットワーク接続に関するパフォーマンスの問題

  • ドメイン コントローラ自体に関するパフォーマンスの問題

注 :
ユーザーが別の物理サイトにあるドメイン コントローラに接続する場合、LDAP の待ち時間は一般的に長くなります。ただし、通常はここで示されている推奨の最大待ち時間を適用する必要があります。

この警告を記録したドメイン コントローラが別の物理サイトに配置されている場合には、この警告を報告するドメイン コントローラが Exchange サーバーで使用されているかどうかを判断できれば、このエラーを無視してかまわないこともあります。ドメイン コントローラが Exchange に使用されているかどうかを判断する手段として、MSExchangeDSAccess サービスのトポロジ コンポーネントに対する診断ログのレベルを [最小] にするという方法があります。MSExchangeDSAccess のイベント ID 2080 が表示されない場合、この警告は無視してかまいません。

この警告を解決するには、次の操作を行います。

  • ドメイン コントローラに至るすべてのネットワーク接続が機能しており、それらの接続がインターネット制御メッセージ プロトコル (ICMP) トラフィックをサポートしていることを確認します。

  • 次の文書で紹介されているベスト プラクティスを検討します。

    • LDAP Read Time パフォーマンス カウンタ、および Active Directory に関する問題のトラブルシューティングに利用できるその他のカウンタの詳細については、Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) で、Active Directory に関連する問題を排除する方法についてのトピックを参照してください (このサイトは英語の場合があります)。この文書には、Active Directory のパフォーマンスを向上させる方法に関する情報も含まれています。

    • Active Directory のパフォーマンスを最大化する方法の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) の、Active Directory 統合のチューニングに関するセクションを参照してください (このサイトは英語の場合があります)。

    • Active Directory サーバーの高可用性を実現する方法の詳細については、Exchange Server 2003 可用性向上ガイドのページ (http://go.microsoft.com/fwlink/?LinkId=47571) にある、システムレベルのフォールト トレラント対策に関するトピックで、Active Directory およびドメイン ネーム システムへの安全なアクセス方法に関するセクションを参照してください (このサイトは英語の場合があります)。

    • ネットワーク帯域幅に関する考慮事項の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) にある Exchange パフォーマンスについての項目のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。


LDAP 検索の最大待ち時間が 100 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-14

Microsoft Exchange アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Process パフォーマンス オブジェクトの LDAP Search Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

LDAP Search Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 検索要求の実行にかかった時間をミリ秒単位で示します。Exchange アナライザは、サンプルを 5 秒ごとに 5 分間取得します。次に、Exchange アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。最大値が 100 ミリ秒を超えていることが検出されると、エラーが表示されます。

LDAP 検索の待ち時間が長くなる原因として、リモート プロシージャ コール (RPC) の待ち時間の増加、およびキューの増大が考えられます。LDAP 検索の待ち時間の増加は、一般的に次のいずれかの問題を示しています。

  • ドメイン コントローラへのネットワーク接続に関するパフォーマンスの問題

  • ドメイン コントローラ自体に関するパフォーマンスの問題

注 :
ユーザーが別の物理サイトにあるドメイン コントローラに接続する場合、LDAP の待ち時間は一般的に長くなります。ただし、通常はここで示されている推奨の最大待ち時間を適用する必要があります。

Exchange サーバーは、グローバル カタログ サーバーとドメイン コントローラの最新の一覧を保持するため、15 分ごとにドメイン外のグローバル カタログ サーバーにクエリを発行します。これらのディレクトリ サーバーの一部はリモートである場合があり、そのためクエリの待ち時間が長くなることがあります。要求がそれほど頻繁に行われない場合、具体的には 1 秒あたりの要求数が 0.5 未満であれば許容範囲です。

このエラーを記録したドメイン コントローラが別の物理サイトに配置されている場合、このエラーを報告するドメイン コントローラが Exchange サーバーで使用されていなければ、このエラーを無視してかまいません。ドメイン コントローラが Exchange に使用されているかどうかを判断する手段として、MSExchangeDSAccess サービスのトポロジ コンポーネントに対する診断ログのレベルを [最小] にするという方法があります。MSExchangeDSAccess のイベント ID 2080 が表示されない場合、このエラーは無視してかまいません。

重要 :
混在モードの環境の場合にのみ、Exchange 2000 SP2 の時期の前後に tokenGroups や tokengroupsGlobalandUniversal などのセキュリティ関連の特定のユーザー属性についてこの動作が導入されました。これらの属性は、ユーザーが属するセキュリティ グループを判断し、Exchange サーバーがユーザーのホーム ドメインに権限を持つドメイン コントローラにクエリを実行する必要のあるリソース (パブリック フォルダなど) をセキュリティ保護するために付与するアクセス許可を指定する際に使用します。権限を持つドメイン コントローラがリモート サイトに存在し、ローカルのパブリック フォルダにアクセスする多数のリモート ドメイン ユーザーからこのドメイン コントローラに対してクエリが実行されると、RPC 待ち時間が増加する可能性があります。

この動作の詳細については、以下の Exchange Server ブログの記事を参照してください。

  • Exchange でローカルのグローバル カタログが使用されない件についてのページ (このサイトは英語の場合があります)

    注 :
    ブログへのリンクは、必要な技術情報の検索に利用することを目的として用意されています。それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

このエラーを解決するには、次の操作を行います。

  • ドメイン コントローラに至るすべてのネットワーク接続が機能しており、それらの接続がインターネット制御メッセージ プロトコル (ICMP) トラフィックをサポートしていることを確認します。

  • 次の文書で紹介されているベスト プラクティスを検討します。

    • LDAP Read Time パフォーマンス カウンタ、および Active Directory に関する問題のトラブルシューティングに利用できるその他のカウンタの詳細については、Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) で、Active Directory に関連する問題を排除する方法についてのトピックを参照してください (このサイトは英語の場合があります)。この文書には、Active Directory のパフォーマンスを向上させる方法に関する情報も含まれています。

    • Active Directory のパフォーマンスを最大化する方法の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) の、Active Directory 統合のチューニングに関するセクションを参照してください (このサイトは英語の場合があります)。

    • Active Directory サーバーの高可用性を実現する方法の詳細については、Exchange Server 2003 可用性向上ガイドのページ (http://go.microsoft.com/fwlink/?LinkId=47571) にある、システムレベルのフォールト トレラント対策に関するトピックで、Active Directory およびドメイン ネーム システムへの安全なアクセス方法に関するセクションを参照してください (このサイトは英語の場合があります)。

    • ネットワーク帯域幅に関する考慮事項の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) にある Exchange パフォーマンスについての項目のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。


指定された Exchange ゲートウェイを識別できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの msExchExchangeServer のオブジェクト クラスを持つ各ディレクトリの名前 (cn) に対してクエリを実行し、ユーザー指定の Exchange ゲートウェイ サーバーに一致するものがあるかどうかを判断します。

cn 値は、Exchange Server コンピュータの短縮名が含まれている文字列です。

Exchange Server アナライザがユーザー指定の Exchange ゲートウェイ サーバーに一致する cn 値を見つけることができない場合、Exchange Server アナライザはエラーを表示します。

このエラーは、以下の条件のいずれかに当てはまることを示します。

  • ユーザー指定の Exchange ゲートウェイ サーバーがローカルの Exchange Server 組織に存在しない。

  • ユーザー指定の Exchange ゲートウェイ サーバーが誤って入力された。

このエラーを修正するには、指定した Exchange ゲートウェイ サーバーが正しく入力されていることを確認し、操作を再試行します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
サーバー名 (cn) の値を確認するには

  1. ADSI Edit または同様のツールを使用して、Active Directory 内のサーバー オブジェクトを見つけます。

    CN 属性は次の場所にあります。

    コードのコピー
    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Servers,CN=Server.


Categorizer Queue Length がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Categorizer Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Categorizer Queue Length カウンタがピーク値の 10 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

SMTP Server\Categorizer Queue Length カウンタは、SMTP (Simple Mail Transfer Protocol) カテゴライザ キューで、グローバル カタログ サーバーを使用するディレクトリ サービスの属性検索のために待機しているメッセージ数を示します。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

このエラーは、サーバーまたはネットワークのパフォーマンスの問題、DSAccess (Directory Service Access) の問題、Active Directory® ディレクトリ サービスの問題、または Exchange Server 組織内の重要なサーバーの停止が発生する可能性があることを示します。Categorizer Queue Length カウンタの増加は、Active Directory への問い合わせ、またはローカル配信あるいは SMTP へのメッセージ引渡しに時間がかかったり、応答がないことを示します。これにより、メール配信に遅延が生じる場合があります。

このエラーを修正するには、次の操作を行います。

  • 十分な Active Directory のリソースを Exchange サーバーが利用できることを確認します。これには、ドメイン コントローラとグローバル カタログ サーバーの両方が含まれます。この場合は、同程度の速度の Exchange サーバーのプロセッサとグローバル カタログ サーバーのプロセッサ間で、4:1 の比率を維持することをお勧めします。

  • Exchange システム マネージャで、Exchange サーバーの [DSAccess] タブに列挙されているすべてのドメイン コントローラが正しく機能していることを確認します。これには、ConfigDC、ドメイン コントローラ、およびグローバル カタログ サーバーのロールに列挙されているサーバーが含まれます。

  • Exchange サーバーと、選択したドメイン コントローラおよびグローバル カタログ サーバー間のネットワークのパフォーマンスを監視して、ネットワーク パフォーマンスのボトルネックがないかどうか判断します。

  • Exchange サーバーのプロセッサ使用率と Inetinfo.exe プロセスのプロセッサ使用率を監視します。これにはカテゴライザ コンポーネントが含まれます。

  • 『Microsoft Exchange Server デプロイメント ツール』(http://go.microsoft.com/fwlink/?LinkId=21231) の ConfigDSInteg ツールで、e2kdsinteg 構成オブジェクトを使用して、Exchange 関連のユーザー オブジェクトおよびグループ オブジェクトの状態を確認します。アドレスの形式が正しくない場合や、情報が不完全である場合のオブジェクトは、受信者の判断および遅延の分類に時間がかかる原因になります。

詳細情報

Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


CDO.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


CimWin32.dll の更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-19

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Microsoft Windows NT® Server 4.0 上で Exchange Server コンピュータが実行されていることを示します。値が 5.0 の場合、Exchange Server コンピュータは Windows 2000 Server 上で、5.2 の場合は Windows Server™ 2003 上で実行されています。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Cimwin32.dll ファイルの Version キーに設定されている値を判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • Exchange Server コンピュータが Windows 2000 Server 上で実行されている。

  • Version キーの値が特定のバージョンの Cimwin32.dll ファイルに対応する。

Exchange Server アナライザの動作をより効率的にする、Cimwin32.dll ファイルの更新プログラムが存在する。

この問題を修正するには、マイクロソフト サポート技術情報の文書番号 820608 の、CIM_DataFile クラスは 2 GB 以上の Windows 2000 でより大きいファイルの間違った値または NULL 値を返す現象に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=820608) に記載されている推奨事項を確認し、適用してください。


クライアント アプリケーションがサーバーのパフォーマンスに影響を与える
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange 組織内に、サーバーの負荷を増大させる特定の種類のクライアント コンピュータまたはクライアント サイド アプリケーションがあるかどうかを判断します。

多くのアプリケーションは、サーバーの負荷を増大させる可能性があります。負荷が増大した場合、ユーザーが実行しているアプリケーションを調査し、ユーザーに対して特定のアプリケーションの実行を制限するかどうかを判断します。電子メールにアクセスする一部のアプリケーション (サードパーティ製のアプリケーションのプラグイン、または Microsoft Office Outlook® のプラグイン) は、サーバーの負荷を増大させる可能性があります。サーバーでリモート プロシージャ コール (RPC) の待ち時間や負荷が増加している場合は、呼び出し元を調査することをお勧めします。

Exchange Server User Monitor (ExMon) を使用すると、大きな遅延を感じているユーザーや、サーバーの負荷を増大させているユーザーを識別することができます。ExMon をダウンロードするには、Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=54983) を参照してください (このサイトは英語の場合があります)。

手順

この警告を修正するには

  • ExMon を使用して、サーバーの負荷を増大させているユーザーを識別します。識別したユーザーに問い合わせて、以下のアプリケーションが負荷を増大させているかどうかを判断します。

    • サードパーティ製のクライアント コンピュータ プラグイン

    • デスクトップの同期デバイス (Exchange ActiveSync®、Blackberry など)

    • デスクトップ検索エンジンなどのその他の MAPI アプリケーション

    これらのアプリケーションがビジネスに必要ない場合、またはアプリケーションに修正プログラムが公開されている場合は、アプリケーションの使用を中止するか更新し、負荷を適切なレベルに低下させます。

  • 操作的に最もコストのかかるクライアント コンピュータ (特に、Restrict、SetColumns、または FindRow 操作で長い待ち時間が生じるコンピュータ) は、Exchange キャッシュ モードを使用するように構成してください。Exchange キャッシュ モードは、ほとんどの超過 RPC トラフィックからサーバーを分離します。

    さらに、フォルダ内に多くのアイテムを保存しているユーザーには、古いデータを .pst ファイルにアーカイブするように指示します。また、これらのユーザーがデータをサーバーに保存することを希望する場合は、古いアイテムを新しく作成したフォルダに移動するように指定します。

    最後に、受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5.000 未満にすることをお勧めします。
注 :
一部のアプリケーションは、多くの MAPI 操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、これらのユーザーは、必ずしも多数の MAPI操作を発行することなく、CPU に比較的高い影響を与えているユーザーとして報告されます。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Outlook クライアントのパフォーマンスに関する問題のトラブルシューティングの詳細については、「Exchange Server 2003 または Exchange 2000 Server を実行しているサーバーに多くの項目を含むフォルダを使用する場合、 Outlook ユーザーで不完全なパフォーマンスが発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803) を参照してください。

  • デスクトップ検索ソフトウェアの詳細については、Microsoft サポート技術情報の文書番号 905184「Exchange 2000 Server と Exchange Server 2003 パフォーマンスが Outlook または他の MAPI クライアント コンピュータでデスクトップ検索エンジン ソフトウェアが実行されている場合、影響される可能性があります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184) を参照してください。


クラスタの TEMP パスが無効または既定値以外である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

クラスタ化されていない Exchange Server コンピュータ上では、Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、TEMP 環境変数の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

Exchange Server アナライザが Microsoft Windows® サーバー クラスタ内の Exchange 仮想サーバー (EVS) に対して実行された場合は、HKLM レジストリ ハイブの読み取りは行われません。代わりに、Exchange Server アナライザは次のレジストリ値を読み取ります。

HKEY_USERS\<クラスタ サービスのアカウント SID>\Environment\TEMP

TEMP 環境変数が現在のシステムで使用可能なパスに設定されていないことが検出されると、警告が表示されます。このパスが無効な場合は、組織でメール配信エラーが発生する可能性があります。既定の構成にある Exchange Server アナライザは、既定では、このパスが %USERPROFILE%\Local Settings\Temp に設定されていると想定しています。このパスは他の場所を指すようにも変更できますが、修正プログラムや更新プログラムを適用してクラスタ ノードを再起動した後は、このパスが既定値に設定されていると想定されます。

TEMP 環境変数は、一時的なワークスペースを必要とするアプリケーションが使用するファイル システム内のフォルダを指定するために使用されます。TEMP は通常、Exchange Server などのアプリケーションによって使用されます。各変数のパスは、通常、アプリケーションのコンテキストを基準にしています。Microsoft Exchange Information Store サービス プロセスは、メッセージの変換やメールボックスの移動などのさまざまな操作中に、TEMP フォルダを一時的な記憶域として使用します。

この警告を修正するには

  1. クラスタ サービスのアカウントとしてクラスタ内のノードにログオンします。

  2. [マイコンピュータ] を右クリックし、[プロパティ] をクリックします。

  3. [詳細設定] をクリックします。

  4. [環境変数] をクリックします。

  5. [<アカウント名> のユーザー環境変数] グループで、[TEMP] を選択し、[編集] をクリックします。

  6. [変数値] ボックスに TMP 環境変数の既定のパスを入力し、[OK] をクリックします。

  7. [OK] をクリックして [環境変数] ダイアログ ボックスを閉じ、もう一度 [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じます。

  8. ノードを再起動して変更を適用します。

  9. 既定値以外に設定されているクラスタ内の各ノードに対して、手順 1. ～ 8. を繰り返します。


複数のオフライン アドレス帳のレプリカを検討する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-08-14

Microsoft® Exchange Server アナライザ ツールは、root\MicrosoftExchangeV2 名前空間内の Exchange_PublicFolder Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ReplicaList キーのエントリの数を判断します。エントリの数は、各管理グループに存在するオフライン アドレス帳のレプリカの数を表します。

また、Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、legacyExchangeDN 属性が設定されたパブリック フォルダ データベース オブジェクトの数を判断します。この属性が設定されたオブジェクトの数は、組織内に存在するパブリック フォルダ ストアの数を表します。

Exchange Server アナライザによって、複数のパブリック フォルダ ストアがある Exchange 組織にオフライン アドレス帳のレプリカが 1 つしか存在しないことが検出されると、ベスト プラクティスのメッセージが表示されます。

可用性とパフォーマンスのために、オフライン アドレス帳ごとに複数のレプリカを展開することを検討することをお勧めします。複数のオフライン アドレス帳のレプリカを使用することにより、パフォーマンスや復元性が向上する場合があります。大規模な Exchange 組織の場合、1 つのオフライン アドレス帳のレプリカでは過負荷になる可能性があります。すべての Exchange 組織において、オフライン アドレス帳のレプリカが 1 つであることは単一障害点となります。

複数のレプリカによりネットワークに追加のレプリケーション トラフィックが発生することになりますが、複数のレプリカを使用することをお勧めします。少なくとも、オフライン アドレス帳ごとに 2 つのレプリカを使用する必要があります。

Exchange 組織にオフライン アドレス帳のレプリカを追加するには

  1. Exchange システム マネージャを起動します。

  2. [フォルダ] を展開し、[パブリック フォルダ] を右クリックして、[システム フォルダの表示] をクリックします。注 [フォルダ] ノードが表示されない場合は、[管理グループ] を展開し、表示するシステム フォルダが含まれている管理グループを展開します。次に、[パブリック フォルダ] を右クリックし、[システム フォルダの表示] をクリックします。

  3. [OFFLINE ADDRESS BOOK] コンテナを展開します。レプリカを追加するオフライン アドレス帳を右クリックして、[プロパティ] をクリックします。

  4. [レプリケーション] タブをクリックし、[追加] をクリックします。次に、レプリカを追加するパブリック ストアを選択します。[OK] をクリックして完了します。

  5. レプリカを追加するオフライン アドレス帳コンテナ以下のすべての子オブジェクトに対して、手順 3. と 4. を繰り返します。この繰り返しにより、サポートされるすべての形式をレプリカに含めます。特に、子オブジェクトの OAB Version 2、OAB Version 3a などを追加します。

オフライン アドレス帳の管理および構成方法の詳細については、次の Microsoft Exchange Server TechCenter の文書を参照してください。

  • 「Offline Address Book - Things to Consider」(http://go.microsoft.com/fwlink/?LinkId=57581) (このサイトは英語の場合があります)

  • 「Working with Exchange Server 2003 Stores」(http://go.microsoft.com/fwlink/?LinkId=47595) (このサイトは英語の場合があります)

  • 「Offline Address Book Best Practices Guide」(http://go.microsoft.com/fwlink/?LinkId=47583) (このサイトは英語の場合があります)

  • 「OAB Version 4 in Exchange Server 2003 Service Pack 2」(http://go.microsoft.com/fwlink/?linkid=53097) (このサイトは英語の場合があります)

  • 「How Outlook 2003 SP2 and Exchange Server 2003 SP2 OAB Version 4 Work Together」(http://go.microsoft.com/fwlink/?linkid=53099) (このサイトは英語の場合があります)


受信者更新サービス ドメイン コントローラへの接続
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-05-18

Microsoft® Exchange Server アナライザ ツールは、各ドメイン コントローラでポート 389 への TCP ソケット接続を開きます。この接続は、接続に成功した場合に特定の文字列を返すカスタム オブジェクト プロセッサを使用することにより、確立します。

返された文字列の一部に 389 Available が含まれていない場合は、警告が表示されます。

この警告は、TCP ポート 389 での接続の試行にドメイン コントローラが応答しなかったことを示します。TCP ポート 389 は、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 通信用の既定のポートです。この警告が表示される場合、以下のいずれかの状況が存在している可能性があります。

  • Exchange Server アナライザとドメイン コントローラの間で接続の問題が発生している。

  • サーバーが停止している。

  • サーバーが使用を停止されている。

Exchange Server アナライザがドメイン コントローラに対してクエリを実行したときに、ドメイン コントローラが LDAP 要求を適切に処理できない理由は多数あります。

この警告を修正するには

  1. Exchange Server アナライザを実行するアカウントにドメイン コントローラに対するクエリの実行が許可されていることを確認します。ドメイン コントローラが動作しているドメインには、ユーザー レベルのアクセス許可が必要になります。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ファイルを参照してください。Exchange Server アナライザのヘルプ ファイルを開くには、Exchange Server アナライザで [ヘルプ] メニューの [Microsoft Exchange Server Analyzer Tool ヘルプ] をクリックします。

  2. Exchange Server アナライザが実行されているコンピュータと、応答に失敗したドメイン コントローラの間に、ファイアウォールおよびポートの制限がないことを確認します。

  3. ドメイン コントローラがネットワークに接続され、正常に機能していることを確認します。

  4. サーバーが使用を停止されておらず、Exchange Server が使用可能なドメイン コントローラの一覧に含まれていることを確認します。

詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 319065「[HOWTO] Exchange 2000 での受信者更新サービスの使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319065)

  • 文書番号 816103「[HOWTO] Portqry を使用して Active Directory の接続の問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103)


コンテンツの更新が可能である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-06-21

詳細については、Exchange Server 2007 ドキュメントのダウンロード ページを参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアでコンテンツのインデックス処理が有効になっているが、更新がスケジュールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストアの msExchCIAvailable 属性の値を判断します。この属性の値は、コンテンツのインデックス処理がパブリック フォルダ ストアで有効になっているかどうかを表しています。この値が True の場合は、パブリック フォルダ ストアのコンテンツのインデックスが存在し、Exchange システム マネージャの [クライアントはこのインデックスを検索に使用する] がオンになっていることを示します。この値が False の場合は、パブリック フォルダ ストアのコンテンツのインデックスは存在しますが、Exchange システム マネージャの [クライアントはこのインデックスを検索に使用する] がオフになっていることを示します。この値が <Not Set> の場合、パブリック フォルダ ストアのコンテンツのインデックスは存在しません。

Exchange Server アナライザはまた、Active Directory に対してクエリを実行し、各パブリック フォルダ ストアの msExchCIRebuildSchedule 属性の値も判断します。この属性の値は、コンテンツのインデックスの再構築スケジュール設定を表しています。この属性は、82 組の 16 進数値を持つオクテット文字列として格納されます。

Exchange Server アナライザによって、msExchCIAvailable 属性の値が True に設定されているが、msExchCIRebuildSchedule 属性のオクテット文字列の値が [実行しない] という内容であることが検出されると、警告が表示されます。

更新の間隔を設定するための推奨のベスト プラクティスは、最低でも 1 日 1 回は増分を更新するようにスケジュールすることです。インデックスは最後に作成された時点までのデータしか保持していないため、更新頻度を上げてスケジュールすることをお勧めします。インデックスを定期的に更新しないと、結果が不正確で古いものになることがあります。

また、増分の作成を完了するために必要な時間についても考慮する必要があります。たとえば、一般的なスケジュールでは、毎正時に増分の更新を設定します。ただし、更新処理にかかった時間が 1 時間を超える場合、次回の増分作成は、次の正時に開始されます。

通常、パブリック フォルダ ストアが 6 GB 以下の場合は、増分の更新を 1 時間ごとに実行できます。ストアが 6 GB より大きい場合、またはサーバーのメモリ使用率が高い場合は、インデックスの更新頻度を下げてください。

特定のパブリック フォルダ ストアについて、フルテキスト インデックス処理の更新間隔を設定するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に [サーバー] を展開し、操作するサーバーとストレージ グループを順に展開します。パブリック フォルダ ストアを右クリックして [プロパティ] をクリックします。Exchange システム マネージャに [管理グループ] ノードが表示されていない場合、[サーバー] を展開し、操作するサーバーを右クリックします。次に、[プロパティ] をクリックします。

  3. [フルテキスト インデックス処理] タブで、[実行しない] 以外のオプションを選択します。

  4. [カスタム スケジュールを使用する] を選択した場合、[カスタマイズ] をクリックし、カスタムのスケジュールを設定します。次に、[OK] をクリックします。

  5. [適用] をクリックします。

Exchange Server のフルテキスト インデックス処理の詳細については、『Best Practices for Deploying Full-Text Indexing』(http://go.microsoft.com/fwlink/?linkid=5223) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアでコンテンツのインデックス処理が有効になっているが、更新がスケジュールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストアの msExchCIAvailable 属性値を判断します。この属性の値は、メールボックス ストアでコンテンツのインデックス処理が有効になっているかどうかを示します。この値が TRUE の場合は、メールボックス ストアにコンテンツのインデックスが存在し、Exchange システム マネージャの設定 [クライアントはこのインデックスを検索に使用する] がオンになっています。この値が FALSE の場合は、メールボックス ストアにコンテンツのインデックスが存在しますが、Exchange システム マネージャの設定 [クライアントはこのインデックスを検索に使用する] はオフになっています。この値が <Not Set> の場合は、メールボックス ストアにコンテンツのインデックスは存在しません。

Exchange Server アナライザはまた、Active Directory に対してもクエリを実行し、各メールボックス ストアのmsExchCIRebuildSchedule 属性の値を判断します。この属性の値は、コンテンツのインデックスに対する再構築スケジュールの設定を示します。この属性は、16 進数値の 82 個のペアが含まれたオクテット文字列として格納されます。

Exchange Server アナライザによって、msExchCIAvailable 属性の値が TRUE に設定されているが、msExchCIRebuildSchedule 属性のオクテット文字列の値が [実行しない] という内容であることが検出されると、警告が表示されます。

更新の間隔を設定する場合の推奨されるベスト プラクティスは、増分更新を少なくとも 1 日に 1 回スケジュールすることです。インデックスは、最後にそのインデックスのカタログが作成された時点での最新版にすぎないため、更新をより頻繁にスケジュールすることをお勧めします。インデックスが定期的に更新されていないと、結果が不正確になったり、最新でなくなったりする場合があります。

また、カタログの増分作成を完了するまでにかかる時間も考慮する必要があります。たとえば、一般的なスケジュールでは、毎正時に増分の更新を設定します。ただし、更新処理にかかった時間が 1 時間を超える場合、次回のカタログ増分作成は、次の正時に開始されます。

一般に、メールボックス ストアが 6 GB 以下の場合は、増分の更新を毎時に実行できます。ストアが 6 GB より大きい場合、またはサーバーのメモリ使用率が高い場合は、インデックスの更新頻度を下げてください。

特定のメールボックス ストアでフルテキスト インデックス処理の更新間隔を設定するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、対象の管理グループ、[サーバー]、対象のサーバー、ストレージ グループの順に展開します。[メールボックス ストア] を右クリックし、[プロパティ] をクリックします。Exchange システム マネージャに管理グループノードが表示されない場合は、[サーバー] を展開し、対象のサーバーを右クリックします。次に、[プロパティ] をクリックします。

  3. [フルテキスト インデックス処理] タブで、[実行しない] 以外のオプションを選択します。

  4. [カスタム スケジュールを使用する] を選択する場合は、[カスタマイズ] をクリックし、独自のカスタム スケジュールを設定して、[OK] をクリックします。

  5. [適用] をクリックします。

Exchange でのフルテキスト インデックス処理の構成とトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 822932「HOW TO: 2003 にメールボックス ストアでの Exchange でのフルテキスト インデックス処理を構成します。」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=822932) および文書番号 319436「[HOWTO] Exchange 2000 のメールボックス ストアにフルテキスト インデックス処理を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319436) を参照してください。

Exchange Server のフルテキスト インデックス処理の詳細については、『Best Practices for Deploying Full-Text Indexing』(http://go.microsoft.com/fwlink/?LinkId=5223) を参照してください (このサイトは英語の場合があります)。


CQPCIDRV.SYS ドライバの更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-14

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server を実行しているサーバー上で実行されている Microsoft Windows® のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Exchange サーバーでは Microsoft Windows NT® Server 4.0 が実行されていることを示します。値が 5.0 の場合、Exchange サーバーでは Windows 2000 Server が実行されていることを示します。値が 5.2 の場合、Exchange Server コンピュータでは Windows Server™ 2003 が実行されていることを示します。

また、Exchange Server アナライザは、Win32_Processor Microsoft WMI (Windows® Management Instrumentation) クラスを調べて、DataWidth キーの値を判断します。

DataWidth キーの値が 32 の場合、サーバーは 32 ビット版の Windows オペレーティング システムが実行されていることを示し、DataWidth キーの値が 64 の場合は、64 ビット版の Windows オペレーティング システムが実行されていることを示します。

さらに、Exchange Server アナライザは、CIM_Datafile WMI クラスに対してクエリを実行し、CpqCiDrv.sys ファイルの Version キーの値を判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • Exchange サーバーで Exchange Server 2003 が実行されている。

  • Exchange サーバーで 64 ビット版の Windows オペレーティング システムが実行されている。

  • HP Integrated Lights-Out 管理インターフェイス ドライバ (CPQCIDRV.sys) のバージョンが 1.8 より前である。

このエラーは、サーバーにインストールされている CpqCiDrv.sys のバージョンが古いため、カーネル メモリの割り当てエラーが発生する可能性があることを示します。

この問題を解決するには、ベンダの指示に従います。HP のサポート文書 Document ID: c00688313 (英語ページの可能性があります) (http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00688313) を参照してください。

注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


CrashOnAuditFail が有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、CrashOnAuditFail パラメータが設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\CrashOnAuditFail

CrashOnAuditFail の値が 2 に等しいことが検出されると、エラーが表示されます。

CrashonAuditFail レジストリ キーの目的は、セキュリティ ログが構成済みのサイズ制限に達したら、エンド ユーザーにコンピュータへのアクセスを許可しなくなるようにサーバーを構成することにあります。コンピュータへのアクセスを許可しないようにすれば、通常はログに記録される監査情報が消失することはなくなります。

CrashonAuditFail レジストリ キーを有効にする場合は、その値を 1 に設定します。ただし、セキュリティ ログの制限に到達すると、サーバーがこのレジストリ キーの値を 2 に設定します。これにより、サーバー上の処理は停止します。場合によっては、この処理のために、完全な障害または STOP 0xC0000244 (停止エラーとも呼ばれます) が発生することがあります。少なくとも、ユーザーはサーバー リソースにアクセスできなくなり、パフォーマンスは大幅に低下します。さらに、サーバーがこの状態にある場合は、管理者アクセス許可を持つユーザーのみがコンピュータにアクセスできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Control\LSA

  3. CrashOnAuditFail という名前の値を削除します (値のデータだけでなく、値全体を削除する必要があります)。

  4. セキュリティ イベント ログを別の場所にコピーします。既定では、セキュリティ イベント ログ (SecEvent.Evt) は %SystemRoot%\System32\Config に格納されています。ここで、%SystemRoot% は、Microsoft Windows® オペレーティング システムがインストールされている場所へのパスです。

  5. イベント ビューアを起動し、[セキュリティ] を右クリックします。次に、[プロパティ] をクリックします。

  6. [セキュリティのプロパティ] ページで、[ログの消去] をクリックします。ログを保存するかどうかを確認するメッセージが表示されたら、[はい] をクリックし、ログ ファイルを保存する場所を指定します。

    注 [セキュリティのプロパティ] ページでは、[最大ログ サイズ] ボックスを編集して [適用] をクリックすることにより、ログ サイズを増やすこともできます。

  7. サーバーを再起動します。

  8. Exchange メールボックスにログオンして、ユーザーがサーバー リソースにアクセスできることを確認します。

  9. CrashonAuditFail レジストリ キーを再作成し、値のデータを 1 に設定します。

  10. サーバーを再起動して、CrashonAuditFail 設定を有効にします。

  11. 最大ログ サイズを超えないように、サーバーのセキュリティ ログを定期的に削除および保存してください。詳細については、Microsoft サポート技術情報の文書番号 312571「イベント ログが最大ログ サイズに達する前に、イベントの出力が停止する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=312571) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

CrashOnAuditFail の障害から回復する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 232564「セキュリティ ログがいっぱいになると STOP 0xC0000244 が表示される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232564)

  • 文書番号 829082「Windows Server 2003 ベースのコンピュータでレジストリ キー crashonauditfail を 1 に設定するとエラー メッセージ "Stop error 0xC0000244 {Audit Failed}" が表示される。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=829082)


カスタム パブリック フォルダの参照一覧
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchFolderAffinityCustom 属性に Exchange サーバー名が含まれているかどうかを判断します。msExchFolderAffinityCustom 属性にサーバー名の一覧が含まれていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 では、既定ではルーティング グループを使用してパブリック フォルダの参照を判断します。

Exchange Server 2007 では、既定では Active Directory ディレクトリ サービスのサイト間コストを使用してパブリック フォルダの参照のルーティングを判断します。

msExchFolderAffinityCustom 属性にサーバー名の一覧が含まれている場合は、その Exchange サーバー上でカスタム参照が構成されています。msExchFolderAffinityCustom 属性は、サーバーごとの属性です。

一般的なベスト プラクティスとして、パブリック フォルダの参照には既定の動作を使用することをお勧めします。ただし、カスタム参照一覧の作成が必要になることもあります。既定以外の構成であることを示すメッセージは、情報を提供するためのメッセージです。このメッセージへの対処は必要ありません。

Exchange Server 2003 で既定の構成に戻すには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. カスタム パブリック フォルダの参照が構成されているサーバー オブジェクトを見つけます。カスタム パブリック フォルダの参照が構成されている Exchange サーバーの名前は、Exchange Server アナライザのメッセージに指定されています。

  3. [<サーバー名>] を右クリックし、[プロパティ] をクリックします。

  4. [パブリック フォルダの参照] タブの [パブリック フォルダの参照オプション] ボックスの一覧で、[ルーティング グループの使用] を選択します。

  5. [適用] をクリックし、[OK] をクリックします。
Exchange Server 2007 で既定の構成に戻すには、次の操作を行います。

  1. 次のコードは、パブリック フォルダ データベース 'MyServer\First Storage Group\Public Folder Database' において PublicFolderRefferalServerList の使用を無効にする、Exchange 管理シェルの Set-PublicFolderDatabase コマンドの例を示しています。
コードのコピー
Set-PublicFolderDatabase -Identity "MyServer\First Storage Group\Public Folder Database" -UseCustomReferralServerList $false

UseCustomReferralServerList パラメータは、PublicFolderReferralServerList パラメータで指定されたサーバー コストを使用するかどうかを指定します。これを $true に設定すると、サーバーは PublicFolderReferralServerList パラメータのコストを使用してパブリック フォルダの参照を行います。これを $false に設定すると、サーバーは Active Directory のサイト間コストを使用してパブリック フォルダの参照を行います。

注 :
このパラメータを $false に設定すると、PublicFolderReferralServerList パラメータは消去されます。

Exchange 管理シェルの Set-PublicFolderDatabase コマンドの詳細については、Exchange Server 2007 製品ドキュメントのテクニカル リファレンスにある、Set-PublicFolderDatabase についてのページ (http://go.microsoft.com/fwlink/?LinkId=80813) を参照してください (このサイトは英語の場合があります)。

パブリック フォルダのレプリケーションの詳細については、「Best Practices for Exchange Server Public Folders」(http://go.microsoft.com/fwlink/?LinkId=46437) を参照してください (このサイトは英語の場合があります)。


Database パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Database パフォーマンス オブジェクトの Log Record Stalls/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合、次の状況のいくつかが当てはまります。

  • Database パフォーマンス オブジェクトが無効になっている。

  • Database パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張カウンタによってレジストリが壊れた場合、または Microsoft WMI (Windows® Management Instrumentation) に基づくプログラムによってレジストリが変更された場合に発生する可能性があります。

以下の手順は、最初の 2 つの状況を修復する方法について説明しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. Database パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードし、インストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. 足りないパフォーマンス カウンタまたは壊れたパフォーマンス カウンタを再構築します。パフォーマンス カウンタを再構築する方法については、Microsoft サポート技術情報の文書番号 300965「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) を参照してください。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Exchange Server を修復モードで再インストールしてから、最新の Exchange Server Service Pack を適用する必要があります。


DAVEX.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


DHCP クライアント サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DHCP (動的ホスト構成プロトコル) クライアント サービスの Started キーの値を判断します。Exchange サーバー上で DHCP クライアント サービスの Started キーの値が False に設定されていることが検出されると、警告が表示されます。

この警告は、DHCP クライアント サービスが実行されていないことを示しています。DHCP クライアント サービスは、動的 DNS (ドメイン ネーム システム) 更新を実行します。DHCP クライアント サービスが実行されていないと、動的更新は失敗します。Exchange サーバーでこのサービスが実行されていない場合の最も一般的な問題は、メール フローの問題です。

この問題を修正するには、DHCP クライアント サービスが自動的に開始されるように設定してから、そのサービスを開始します。

注 :
サーバーが DHCP ではなく静的 IP アドレスを使用するように構成されている場合でも、DHCP クライアント サービスが実行されている必要があります。
DHCP クライアント サービスを有効にするには

  1. [サービス] スナップインを起動します。

  2. 詳細ペインで、[DHCP クライアント サービス] を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[スタートアップの種類] をクリックし、[自動] を選択します。

  4. [スタート] ボタンをクリックし、[OK] をクリックします。

DHCP クライアント サービスの詳細については、Microsoft サーポート技術情報の文書番号 264539「DHCP クライアント サービスが停止していると動的 DNS 更新が動作しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264539) を参照してください。

DNS 動的更新プロトコルの詳細については、Microsoft サポート技術情報の文書番号 816592「Windows Server 2003 で DNS 動的更新を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592) を参照してください。


ワトソン博士が有効になっていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーの値を読み取り、ワトソン博士が Microsoft Windows® オペレーティング システムの既定のアプリケーション デバッガとして構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

Debugger の値が drwtsn32 で始まっていないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

このメッセージは、ワトソン博士が有効になっていないことを示しています。Windows NT® 以降の Windows には、ワトソン博士と呼ばれるアプリケーション モードのデバッガが組み込まれています。アプリケーションがクラッシュすると、その障害がワトソン博士によってトラップされ、さまざまな情報 (プラットフォームの情報、実行されているプロセスの一覧、障害が発生したプロセスの ID、障害が発生したプロセスのメモリ ダンプ、1 つ以上のコール スタック、障害自体へのポインタなど) がログに記録されます。収集される情報のほとんどは低レベルのデバッグ情報で、障害が発生したプロセスの開発者向けのものです。

推奨されているベスト プラクティスは、アプリケーション モードのデバッガを有効にして Windows を実行することです。ワトソン博士が有効になっておらず、その他のアプリケーション デバッガも使用していない場合は、次の手順でワトソン博士を有効にすることをお勧めします。

ワトソン博士を有効にするには

  1. コマンド プロンプト ウィンドウを開きます。

  2. コマンド プロンプトで、「drwtsn32 -i」と入力します。

ワトソン博士の有効/無効を切り替える方法の詳細については、Microsoft サポート技術情報の文書番号 188296「[NT] Windows NT でワトソン博士を無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=188296) を参照してください。


DSA コンピュータ名が一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSA Computer 値の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange サーバー オブジェクトの name 属性値を判断します。

最後に、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。値が True の場合はクラスタ サービスが開始されており、値が False の場合はクラスタ サービスは実行されていません。

Exchange Server アナライザによって、Windows Server クラスタ内で実行されていない任意の Exchange Server コンピュータについて、DSA Computer キーの値が、Active Directory 内にあるサーバー オブジェクトの name 属性値と一致していないことが検出されると、エラーが表示されます。

このエラーを修正するには、Active Directory 内にある name 属性値と一致するように、DSA Computer レジストリ キーを編集する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、[DSA Computer] をダブルクリックし、このコンピュータの正しい名前を入力します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


DSACCESS.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


DSAccess 構成キャッシュがいっぱいになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-05-24

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_MSExchangeDSAccess_MSExchangeDSAccessCaches Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、TotalEntriesMemoryConfigurationData の現在の値を判断します。TotalEntriesMemoryConfigurationData の値が DSAccess (Directory Service Access) 構成キャッシュの合計サイズ (MaxMemoryConfig) に等しいことが検出されると、警告が表示されます。

DSAccess は、すべての Exchange コンポーネントが Active Directory® ディレクトリ サービスにアクセスする方法を制御する、Exchange 2000 Server および Exchange Server 2003 の内部コンポーネントです。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。さらに、Microsoft Exchange ストアなどの内部 Exchange コンポーネントによって実行される、受信者の解決や構成設定の検索などのディレクトリ クエリは、すべて DSAccess を経由してルーティングされます。この作業の一環として、DSAccess はこれらのクエリの一部の結果をメモリ内キャッシュに保持し、同じ情報が再度要求されたら、Active Directory に対して再度ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを実行しなくても DSAccess キャッシュからその情報を取得できるようにしています。

DSAccess 構成キャッシュに対する既定の設定の最大サイズは、Exchange 2000 Server での 25 MB から Exchange Server 2003 での 5 MB に削減されました。そのため、この警告メッセージは、どちらのバージョンの Exchange でも生成される可能性があります。この警告がどのバージョンの Exchange で生成されたかには関係なく、可能な限り速やかにこの問題を修正する必要があります。

MaxMemoryConfig 値は通常、DSAccess キャッシュ内のユーザー データ オブジェクトが消費できるメモリの最大量を制御する、MaxMemoryUser 値と組み合わせて使用されます。以下の手順に説明されている方法で MaxMemoryConfig 値を編集または削除する場合は、「DSAccess ユーザー キャッシュの値が既定値ではない」の説明に従って、MaxMemoryUser 値も同様に編集または削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. MaxMemoryConfig の値を増やします。Instance0 キーまたは MaxMemoryConfig の DWORD 値が存在しない場合は、その値を手動で作成できます。MaxMemoryConfig レジストリ エントリの値のデータは KB 単位のため、10 進数の 15,000 が 15 MB に等しくなります。この値が存在する場合は、値を 10% 増やします。この値が存在しない場合は、10 MB から始めることをお勧めします。

  4. レジストリ エディタを終了し、Microsoft Exchange System Attendant サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


DSAccsss 構成キャッシュが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) 構成オブジェクト キャッシュのサイズが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0\MaxMemoryConfig

MaxMemoryConfig が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MaxMemoryConfig は、Exchange 2000 Server のレジストリ パラメータで、通常は Exchange Server 2003 では必要ありません。MaxMemoryConfig は、DSAccess 構成キャッシュ内の構成データ オブジェクトが消費できるメモリの最大容量を制御します。DSAccess は Exchange 2000 Server と Exchange Server 2003 の内部コンポーネントで、すべての Exchange コンポーネントが Active Directory® ディレクトリ サービスにどのようにアクセスするかを制御します。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。さらに、Microsoft Exchange ストアなどの内部 Exchange コンポーネントによって実行される、受信者の解決や構成設定の検索などのディレクトリ クエリは、すべて DSAccess を経由してルーティングされます。この作業の一環として、DSAccess はこれらのクエリの一部の結果をメモリ内キャッシュに保持し、同じ情報が再度要求されたら、Active Directory に対して再度ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを実行しなくても DSAccess キャッシュからその情報を取得できるようにしています。

Exchange 2000 Server では、構成キャッシュのサイズは最初は 25 MB に設定されていました。ほとんどの Exchange サーバーでは、この設定は必要量をはるかに上回っていました。MaxMemoryConfig 設定は、DSAccess 構成キャッシュにより使用されていたメモリの一部を取り戻して再割り当てするために使用されていました。この値は一般に、5 MB に構成されていました。社内でのテストと顧客からのフィードバックに基づいて、Microsoft は 3 MB が最適のサイズと判断し、Exchange Server 2003 ではこの値を初期設定にしました。Exchange 2000 Server から Exchange Server 2003 にアップグレードするときは、手動の設定はすべて保持されます。この Exchange サーバーが Exchange 2000 Server から Exchange Server 2003 にアップグレードされている場合は、MaxMamoryConfig の値が 5 MB を超えていないことを確認する必要があります。

MaxMemoryConfig 値は通常、DSAccess キャッシュ内のユーザー データ オブジェクトが消費できるメモリの最大量を制御する、MaxMemoryUser 値と組み合わせて使用されます。以下の手順に説明されている方法で MaxMemoryConfig 値を編集または削除する場合は、「DSAccess ユーザー キャッシュの値が既定値ではない」の説明に従って、MaxMemoryUser 値も同様に編集または削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxMemoryConfig レジストリの値を使用するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. MaxMemoryConfig の値を調べるか編集します。
注 :
このレジストリ エントリの値は KB 単位です。この値が 3,000 以下に設定されている場合は、MaxMemoryConfig を削除し、Microsoft Exchange System Attendant サービスを再開して、Exchange Server 2003 の設定を既定値にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「[XCON] ディレクトリサービスサーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。


DSAceess の DisableNetLogonCheck レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) が既定以外の ping プロトコルを使用するよう構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\DisableNetLogonCheck

Exchange Server アナライザによって、DisableNetLogonCheck が存在し、さらにそれが 0 より大きい値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

DSAccess が Active Directory® ディレクトリ サービス トポロジを検出すると、検出されたドメイン コントローラとグローバル カタログ サーバーが使用に適しているかどうかを判断します。最初の検出、および継続した再検出の間、DSAccess は一連のテストを実行してサーバーの適性を確認します。あるテストでは、全般的な適性をテストするために、ディレクトリ サーバーにリモート プロシージャ コール (RPC) が送信されます。RPC トラフィックが通常許可されていない境界領域のネットワークでは、DSAccess RPC 要求は失敗します。ただし、DSAccess は失敗するまで RPC の送信を継続するため、長い時間がかかる場合があります。このような反復チェックは、Exchange Server を実行するコンピュータのパフォーマンスに悪影響を与える可能性があります。このため、管理者が DisableNetLogonCheck レジストリ キーを追加し、境界領域のネットワークに配置された Exchange Server でその値を 1 に構成することがよくあります。

既定以外の構成であることを示すメッセージを生成した Exchange サーバー が、RPC が無効になっている境界領域のネットワークにある場合、または DSAccess にこの適性テストを実行させない場合は、DisableNetLogonCheck キーを 1 に設定する必要があります。それ以外の場合は、DisableNetLogonCheck キーを削除する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

DisableNetLogonCheck キーを使用するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. DisableNetLogonCheck キーをダブルクリックし、DWORD 値を 1. に設定します。

  4. レジストリ エディタを終了します。変更を有効にするためにサービスを再開する必要はありません。

DisableNetLogonCheck キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. DisableNetLogonCheck という名前の値を削除します。

  4. レジストリ エディタを終了します。変更を有効にするためにサービスを再開する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

DisableNetLogonCheck レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 320228「[XGEN] "DisableNetLogonCheck" レジストリ値の作成と使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320228) を参照してください。


DSAccess がハードコードされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ConfigurationType キーの値を判断します。このキーの値が 0 の場合、既定以外の構成であることを示すメッセージが表示されます。

ConfigurationType プロパティは、インスタンスに記述されているドメイン コントローラが、自動的に検出されたものなのかそれとも手動で指定されたものなのかを示します。Exchange Server の DSAccess (Directory Service Access) コンポーネントは、特別な設定をしなくても、Active Directory® ディレクトリ サービス トポロジを動的に検出し、ドメイン コントローラとグローバル カタログ サーバーの位置を自動的に特定します。Exchange Server 2000 Service Pack 2 以上のバージョンまたは Exchange Server 2003 が動作しているコンピュータの場合、Exchange システム マネージャには DSAccess で使用するために Active Directory サーバーのハードコードされた一覧を入力する機能が搭載されています。

何らかの理由で DSAccess 用のディレクトリ サーバーをハードコードしない限り、サーバーの一覧を削除し、既定の設定 (自動検出) に戻す必要があります。自動トポロジ検出機能を使用して、グローバル カタログのフェールオーバーを活用することをお勧めします。

既定の設定に戻すには

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. [管理グループ] を展開し、<管理グループ名> を展開します。次に、[サーバー] を展開して <サーバー名> を展開します (この場合の管理グループ名は、Exchange サーバーを含む管理グループの名前です。またサーバー名は、構成する Exchange サーバーの名前です)。

  3. Exchange サーバーを右クリックし、[プロパティ] をクリックします。

  4. [ディレクトリ アクセス] タブをクリックします。

  5. [表示] ボックスの一覧の [構成ドメイン コントローラ] をクリックします。

  6. [サーバーを自動検出する] チェック ボックスをオンにします。

  7. Exchange システム マネージャ プロンプトに、"手動で選択したサーバーの指定は解除されます。続行しますか?" というメッセージが表示されたら、[はい] をクリックします。

  8. [表示] ボックスの一覧の [ドメイン コントローラ] をクリックします。

  9. [サーバーを自動検出する] チェック ボックスをオンにします。

  10. Exchange システム マネージャ プロンプトに、"手動で選択したサーバーの指定は解除されます。続行しますか?" というメッセージが表示されたら、[はい] をクリックします。

  11. [表示] ボックスの一覧の [グローバル カタログ サーバー] をクリックします。

  12. [サーバーを自動検出する] チェック ボックスをオンにします。

  13. Exchange システム マネージャ プロンプトに、"手動で選択したサーバーの指定は解除されます。続行しますか?" というメッセージが表示されたら、[はい] をクリックします。

  14. [OK] をクリックし、変更を保存します。

DSAccess およびディレクトリ サービスの検出の詳細については、Microsoft サポート技術情報の文書番号 250570「[XCON] ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。


DSAccess が LDAP ドメイン コントローラ要求にポート 389 を使用していない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、LDAPPort キーの値を判断します。LDAPPort キーの値が 389 に設定されていない場合は、既定以外の構成であることを示すメッセージが表示されます。

LDAPPort キーは、そのドメイン コントローラがライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求を待つ TCP ポート番号を表します。管理者は、セキュリティの手段として、SSL (Secure Sockets Layer) 経由の LDAP を TCP ポート 636 (ドメイン コントローラ) または TCP ポート 3269 (グローバル カタログ) 上で使用します。

既定では、グローバル カタログ サーバーはポート 3268 上で LDAP 通信を待ちます。ただし、エンタープライズ証明機関がインストールされている場合は、すべてのドメイン コントローラが証明書を自動的に要求すると共に、SSL 通信経由の LDAP を TCP ポート 636 上でサポートすることができます。ドメイン コントローラがグローバル カタログとしても構成されている場合は、SSL 通信経由の LDAP を TCP ポート 3269 上でもサポートできます。

このエラーを修正するには

  • 操作は必要ありません。Exchange Server アナライザは既定以外の構成を識別しています。

DSAccess と LDAP ポートの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 247078「[HOWTO] Windows 2000 ドメイン コントローラに対して SSL (Secure Socket Layer) 通信を LDAP で有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=247078)

  • 文書番号 246228「[XGEN] DSAccess プロファイル」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246228)


DSAccess が LDAP グローバル カタログ要求にポート 3268 を使用していない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、LDAPPort キーの値を判断します。LDAPPort キーの値が 3268 に設定されていない場合は、既定以外の構成であることを示すメッセージが表示されます。

LDAPPort キーは、そのドメイン コントローラがライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求を待つ TCP ポート番号を表します。管理者は、セキュリティの手段として、SSL (Secure Sockets Layer) 経由の LDAP を TCP ポート 636 (ドメイン コントローラ) または TCP ポート 3269 (グローバル カタログ) 上で使用します。

既定では、グローバル カタログ サーバーはポート 3268 上で LDAP 通信を待ちます。ただし、エンタープライズ証明機関がインストールされている場合は、すべてのドメイン コントローラが証明書を自動的に要求すると共に、SSL 通信経由の LDAP を TCP ポート 636 上でサポートすることができます。ドメイン コントローラがグローバル カタログとしても構成されている場合は、SSL 通信経由の LDAP を TCP ポート 3269 上でもサポートできます。

DSAccess と LDAP ポートの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 247078「[HOWTO] Windows 2000 ドメイン コントローラに対して SSL (Secure Socket Layer) 通信を LDAP で有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=247078)

  • 文書番号 246228「[XGEN] DSAccess プロファイル」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246228)


DSAceess の LdapKeepAliveSecs レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) がライトウェイト ディレクトリ アクセス プロトコル (LDAP) Microsoft Windows® オペレーティング システム実装 (wLDAP) プロトコルを使用するように構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\ LdapKeepAliveSecs

LdapKeepAliveSecs が存在し、値が 0 に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

DSAccess は、Active Directory® ディレクトリ サービス トポロジを検出した後で、検出された動作中のドメイン コントローラとグローバル カタログ サーバーの一覧が使用に適しているかどうかを判断します。最初の検出および継続的な再検出時に、DSAccess は一連のテストを実行して、サーバーが適切であるかどうかを判断します。既定では、このテストの 1 つで ICMP (Internet Control Message Protocol) を使用してドメイン コントローラに対して ping を実行し、サーバーが利用可能であることを確認します。

ネットワークのすべての接続が ICMP をサポートしているとは限りません。このような状況の例としては、境界ネットワークで Exchange サーバーとドメイン コントローラとの間の ICMP 接続が許可されていない場合が挙げられます。このような場合、LdapKeepAliveSecs レジストリ パラメータを 0 に設定すると、DSAccess が適合性テストに Windows 実装の LDAP (wLDAP) を使用するようにすることができます。

既定以外の構成を示すメッセージが生成された Exchange サーバーが、リモート プロシージャ コール (RPC) が無効になっている境界ネットワーク内にある、または ICMP が許可されていないネットワーク内にある場合、LdapKeepAliveSecs キーの構成はそのままにしておく必要があります。それ以外の場合は、キーを削除する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

LdapKeepAliveSecs キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. LdapKeepAliveSecs という値を削除します。

  4. レジストリ エディタを終了します。変更を有効にするために、サービスを再開する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

LdapKeepAliveSecs レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 320529「[XADM] 境界領域のネットワーク ファイアウォールで DSAccess を使用するにはレジストリ キー設定が必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320529) を参照してください。


DSAccess LdapKeepAliveSecs レジストリ パラメータが、サポートされていない値に設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) がライトウェイト ディレクトリ アクセス プロトコル (LDAP) Microsoft Windows® オペレーティング システム実装 (wLDAP) プロトコルを使用するように構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAccess\ LdapKeepAliveSecs

LdapKeepAliveSecs が存在し、0 以外の値で構成されていることが検出されると、警告が表示されます。

DSAccess が Active Directory® ディレクトリ サービス トポロジを検出すると、検出された稼動中のドメイン コントローラとグローバル カタログ サーバーの一覧が使用に適しているかどうかを判断します。最初の検出、および継続した再検出の間、DSAccess は一連のテストを実行してサーバーの適性を確認します。既定では、適性テストの 1 つでは ICMP (Internet Control Message Protocol) を使用してドメイン コントローラへの ping を実行し、サーバーが利用可能であることを確認します。

ネットワークの接続の中には、ICMP がサポートされていない接続がある場合があります。この状況を示す具体的な例は、Exchange サーバーとドメイン コントローラ間の ICMP 接続が許可されていない境界領域のネットワークです。このような場合、LdapKeepAliveSecs レジストリ パラメータを 0 に設定すると、DSAccess は適性テストのために wLDAP を使用するよう強制されます。

この警告を生成した Exchange サーバーが、リモート プロシージャ コール (RPC) が無効になっている境界領域のネットワークにあるか、ICMP が許可されていないネットワークにある場合、LdapKeepAliveSecs キーを 0 に設定します。それ以外の場合は、キーを削除する必要があります。このレジストリ キーでは、0 以外の値はサポートされません。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

LdapKeepAliveSecs キーを変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. [LdapKeepAliveSecs] キーをダブルクリックし、DWORD 値を 0 に設定します。

  4. レジストリ エディタを終了します。変更を有効にするためにサービスを再開する必要はありません。

LdapKeepAliveSecs キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess

  3. LdapKeepAliveSecs という名前の値を削除します。

  4. レジストリ エディタを終了します。変更を有効にするためにサービスを再開する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

LdapKeepAliveSecs レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 320529「[XADM] 境界領域のネットワーク ファイアウォールで DSAccess を使用するにはレジストリ キー設定が必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320529) を参照してください。


DSAccess PreloadBaseDNs レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) の検索のプリロード機能の値が既定の構成から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadBaseDNs

PreloadBaseDNs の値のデータは、既定では次のとおりです。

'"'

'"'

'"'

'"'

'"'

Exchange Server アナライザによって、PreloadBaseDNs の値がこれらの既定値から変更されていることが検出されると、警告メッセージが表示されます。Exchange Server アナライザがこの構成を報告するのは、この構成が、Microsoft 製品サポート サービスと相談してから変更すべき設定であるためです。

DSAccess キャッシュは Exchange サーバーに常駐し、Active Directory® ディレクトリ サービスから取得した構成およびユーザー レコードを収集します。DSAccess キャッシュ内のレコードへのアクセスは、オブジェクトの識別名、グローバル一意識別子 (GUID)、またはキー (Active Directory でこのオブジェクトを検索する場合に使用されるスコープ、BaseDN、および検索フィルタから作成されるもの) を使用して行われます。同じ識別名、GUID、またはキーを使用するそれ以降のアクセスでは、キャッシュ内のレコードが検索されます。したがって、同一の検索では、Active Directory に対する不要な負荷が発生しなくなります。ただし、検索フィルタがキャッシュに含まれている検索フィルタと異なる場合は、DSAccess がユーザー オブジェクトの同じ属性セットを要求したとしても DSAccess で Active Directory 上の負荷の発生を防ぐことはできません。

検索のプリロードは、同じユーザー オブジェクトに対してさまざまな検索フィルタが発行されたときに発生する可能性のある、Active Directory の複数検索に関する問題を回避するための手段です。検索のプリロードは、スコープ、BaseDN、および検索フィルタによって検索エントリを作成する、前述のキーの作成によって機能します。

DSAccess の検索のプリロードを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 250572「[XCON] プリロードと DSAccess キャッシュ」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250572) を参照してください。


DSAceess の PreloadFilters レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) の検索のプリロード機能の値が既定の構成から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\PreloadFilters

PreloadFilters の値のデータは、既定では次のとおりです。

(&(|(msExchMasterAccountSID=%)(objectSid=%))(!(objectClass=foreignSecurityPrincipal)))(|(msExchMailboxGUID=%)(objectGUID=%))(legacyExchangeDN=%)(msExchMailboxGUID=%)(&(proxyAddresses=%)(|(objectClass=user)(objectClass=contact)))

Exchange Server アナライザによって、PreloadFilters の値がこれらの既定値から変更されていることが検出されると、警告が表示されます。この構成が報告されるのは、PreloadFilters レジストリ設定が Microsoft 製品サポート サービスに相談してからでないと変更できないためです。

DSAccess キャッシュは Exchange サーバーに常駐し、Active Directory® ディレクトリ サービスから取得した構成およびユーザー レコードを収集します。キャッシュ内のレコードへのアクセスは、オブジェクトの識別名、グローバル一意識別子 (GUID)、またはキー (Active Directory でこのオブジェクトを検索する場合に使用されるスコープ、BaseDN、および検索フィルタから作成されるもの) を使用して行われます。同じ識別名、GUID、またはキーを使用するそれ以降のアクセスでは、キャッシュ内のレコードが検索されます。したがって、同一の検索では、Active Directory に対する不要な負荷が発生しなくなります。ただし、検索フィルタがキャッシュに含まれている検索フィルタと異なる場合は、DSAccess がユーザー オブジェクトの同じ属性セットを要求したとしても DSAccess で Active Directory 上の負荷の発生を防ぐことはできません。

検索のプリロードは、同じユーザー オブジェクトに対してさまざまな検索フィルタが発行されたときに発生する可能性のある、Active Directory の複数検索に関する問題を回避するための手段です。検索のプリロードは、スコープ、BaseDN、および検索フィルタによって検索エントリを作成する、前述のキーの作成によって機能します。

DSAccess の検索のプリロードを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 250572「[XCON] プリロードと DSAccess キャッシュ」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250572) を参照してください。


DSAccess により、この Active Directory サーバーが機能していないことが報告される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、IsUp キーの値を判断します。IsUp キーが False に設定されていることが検出されると、エラーが表示されます。

IsUp キーが True に設定されている場合、これは Exchange サーバーが最後に接続を確立しようとしたときにドメイン コントローラが応答したことを示します。IsUp が False に設定されている場合は、接続の試みに対してドメイン コントローラが応答しなかったことを示します。

応答がないことは、必ずしも、ドメイン コントローラやグローバル カタログ サーバーの停止または誤動作を示すものではありません。場合によっては、Exchange サーバーとドメイン コントローラの間にネットワーク接続の問題があり、それによりこの失敗が発生していることがあります。あるいは、Exchange サーバーとドメイン コントローラの間にファイアウォールがあり、そこで適切なポートが開かれていないために発生している場合もあります。

このエラーを修正するには

  1. PING を送信することによって、ドメイン コントローラが機能していることを確認します。

  2. ファイアウォールがある場合は、ファイアウォールで正しいポートが開かれていることを確認します。また、ファイアウォールが PING パケットを破棄するように構成されている場合があることにも注意してください。特定のポートを開いたり閉じたりする方法の詳細については、ファイアウォールのマニュアルを確認してください。

  3. その他のネットワーク関連の問題、たとえば、スイッチ、ルーター、ケーブルなどの誤動作がないことを確認します。

DSAccess およびディレクトリ サービスの検出の詳細については、Microsoft サポート技術情報の文書番号 250570「[XCON] ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。

ネットワーク接続性の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


DSAccess によって、Active Directory サーバーが残りのトポロジと同期されていないことが報告される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間内の Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、IsInSync キーの値を判断します。IsInSync の値が False の場合、エラーが表示されます。

IsInSync キーは、ドメイン コントローラがグローバル カタログ サーバーおよび構成ドメイン コントローラと同期されているかどうかを示します。ドメイン コントローラは、値が True の場合は同期されており、値が False の場合は同期されていません。

このエラーを修正するには

  1. ドメイン コントローラまたはグローバル コントローラでの時刻を調査します。タイム サービスが開始されていることを確認するか、Exchange サーバーでの時刻と、グローバル カタログ サーバーまたは構成ドメイン コントローラでの時刻を手動で同期します。

  2. レプリケーション モニタ ツール (Replmon) を使用して、ドメイン コントローラのレプリケーションの問題についての調査、確認、および必要に応じた修正を行います。Replmon は、Microsoft Windows 2000 Server および Microsoft Windows Server™ 2003 のサポート ツールの一部で、Windows Server CD の Support\Tools フォルダに収録されています。

DSAccess およびディレクトリ サービスの検出の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 316300「MSExchangeDSAccess に起因するイベント ID 2080」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316300)

  • 文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570)


DSAccess により、Active Directory サーバーが LDAP 要求への応答に 2 秒を超える時間を要していることが報告される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ROOT\MicrosoftExchangeV2 名前空間にある Exchange_DSAccessDC Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、IsFast キーと IsUp キーの値を判断します。IsUp キーの値が True の場合、Exchange Server の DSAccess (Directory Service Access) コンポーネントで使用されているディレクトリ サーバーがネットワークに接続され、応答していることを示しています。値が False の場合、ディレクトリ サーバーは応答していません。IsFast の値が True の場合、このディレクトリ サーバーの応答時間は 2 秒未満です。値が False の場合、応答時間は 2 秒を超えています。IsUp の値が True であるのに、IsFast の値が False である場合、エラーが表示されます。

このエラーを修正するには

  1. ドメイン コントローラとグローバル カタログの負荷を調べます。ドメイン コントローラとグローバル カタログが過負荷になっていると、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 呼び出しへの応答時間が長くなることがあります。

  2. 最良のパフォーマンスを得るには、ローカル Active Directory® ディレクトリ サービス サイトに最低 1 つのグローバル カタログを必ず設置してください。

DSAccess およびディレクトリ サービスの検出の詳細については、Microsoft サポート技術情報の文書番号 250570「[XCON] ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。


DSAceess の TopoCreateTimeoutSecs レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) の初期化タイムアウトの既定値が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\TopoCreateTimeoutSecs

TopoCreateTimeoutSecs キーが存在し、値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

DSAccess は、起動時に検索処理を使用して Active Directory® ディレクトリ サービスのトポロジを識別し、ドメイン コントローラとグローバル カタログ サーバーの可用性を評価します。起動が完了したら、以後は 15 分ごとにほぼ同じ処理によってトポロジを再検索し、サーバーの可用性に変化があるかどうかを確認します。既定では、起動時の DSAccess の初期化は 1 分以内に完了する必要があります。完了しないと、DSAccess は停止します。通常は、DSAccess の初期化には 1 分あれば十分です。

注 :
DSAccess で使用するディレクトリ サーバーをハードコードしている場合、DSAccess は検索処理を省略し、サーバーの適合性のみを確認します。
重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess

  3. TopoCreateTimeoutSecs という値を削除します。

  4. レジストリ エディタを終了します。

このレジストリ キーが存在する場合は、ネットワーク トポロジの評価を行うことを検討する必要があります。組織で DSAccess の初期化時間を増やす必要がある場合、設計またはネットワークの問題を示している可能性があります。Exchange を最適に運用するためには、ドメイン コントローラ、特にグローバル カタログ サーバーに対して、信頼性が高いアクセスをすばやく行える必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ディレクトリ アクセスの詳細については、『Understanding and Troubleshooting Directory Access』(http://go.microsoft.com/fwlink/?LinkId=39012) を参照してください (このサイトは英語の場合があります)。


DSAccess ユーザー キャッシュがいっぱいになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_MSExchangeDSAccess_MSExchangeDSAccessCaches Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、TotalEntriesMemoryUserData の現在の値を判断します。TotalEntriesMemoryUserData の値が DSAccess (Directory Service Access) ユーザー キャッシュの合計サイズ (MaxMemoryUser) に等しいことが検出されると、警告が表示されます。

DSAccess は、すべての Exchange コンポーネントが Active Directory® ディレクトリ サービスにアクセスする方法を制御する、Exchange 2000 Server および Exchange Server 2003 の内部コンポーネントです。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。さらに、Exchange ストアなどの Exchange 内部のコンポーネントによって作成された、受信者の解決や構成設定の参照を始めとするディレクトリ クエリは、すべて DSAccess を通してルーティングされます。この作業の一環として、DSAccess はこれらのクエリの一部の結果をメモリ内キャッシュに保持し、同じ情報が再度要求されたら、Active Directory に対して別のライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを実行しなくても DSAccess キャッシュからその情報を取得できるようにしています。

Exchange 2000 Server では、ユーザー キャッシュは 25 MB に初期設定されていました。多数の Microsoft Office Outlook® 2003 クライアントにサービスを提供する Exchange 2000 Server コンピュータでは、DSAccess ユーザー キャッシュの既定のサイズでは不十分でした。Exchange Server 2003 では、パフォーマンスを改善するためにユーザー キャッシュの既定値が最適化され、140 MB に設定されています。

DSAccess ユーザー キャッシュの最大サイズは、既定の設定値が Exchange 2000 Server での 25 MB から Exchange Server 2003 での 140 MB に引き上げられたため、この警告メッセージはおそらく、Exchange 2000 Server コンピュータで生成されます。どの Exchange のバージョンでこの警告メッセージが生成されたかにかかわらず、この問題はできるだけ早期に解決する必要があります。DSAccess キャッシュが小さいシステムでは、ローカルのメッセージ配信やアドレス帳の名前解決の速度が、必要なレベルより遅くなる可能性があります。

ユーザー キャッシュの最大サイズは、Exchange サーバーのレジストリ エントリを使用して手動で構成できます。MaxMemoryUser は Exchange 2000 Server のレジストリ パラメータで、Exchange 管理者はこのパラメータによって、DSAccess キャッシュ内のユーザー データ オブジェクトが消費することができる最大メモリ量を制御できます。

MaxMemoryUser 値は多くの場合、DSAccess キャッシュ内の構成データ オブジェクトが消費することができる最大メモリ量を制御する、MaxMemoryConfig 値と共に使用されます。次の手順で説明するように MaxMemoryUser 値の編集または削除を行う場合は、「DSAccsss 構成キャッシュが既定値ではない」での説明と同様の手順で、MaxMemoryConfig 値の編集や削除も行う必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange 2000 Server コンピュータでこの問題を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. MaxMemoryUser の値を増やします。この DWORD 値が存在しない場合は、手動で値を作成できます。このレジストリ エントリの値データは KB 単位です。したがって、10 進数の 140000 というエントリは 140 MB と同じです。

  4. MaxMemoryConfig の値を減らします。この DWORD 値が存在しない場合は、手動で値を作成できます。このレジストリ エントリの値データは KB 単位です。5 MB に等しい 10 進数の 5000 が、推奨されている値です。

  5. レジストリ エディタを終了し、Microsoft Exchange System Attendant サービスを再開して、変更を有効にします。

Exchange 2003 Server コンピュータでこの問題を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. MaxMemoryUser が存在しており、140 MB より小さく構成されている場合は、MaxMemoryUser 値を削除します。MaxMemoryUser が存在しており、140 MB より大きい場合は、値を 10% 増やします。

  4. MaxMemoryConfig が存在する場合は削除します。

  5. レジストリ エディタを終了し、Exchange System Attendant を再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570) を参照してください。


DSAccess ユーザー キャッシュの値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、DSAccess (Directory Service Access) ユーザー オブジェクト キャッシュのサイズが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0\MaxMemoryUser

MaxMemoryUser が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MaxMemoryUser は Exchange サーバーのレジストリ パラメータであり、Exchange 管理者はこれを使用して、DSAccess キャッシュ内のユーザー データ オブジェクトが消費できるメモリの最大量を制御することができます。

DSAccess は、すべての Exchange コンポーネントが Active Directory® ディレクトリ サービスにアクセスする方法を制御する、Exchange 2000 Server および Exchange Server 2003 の内部コンポーネントです。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。さらに、Exchange ストアなどの内部 Exchange コンポーネントによって実行される、受信者の解決や構成設定の検索などのディレクトリ クエリは、すべて DSAccess を経由してルーティングされます。この作業の一環として、DSAccess はこれらのクエリの一部の結果をメモリ内キャッシュに保持し、同じ情報が再度要求されたら、Active Directory に対して再度ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを実行しなくても DSAccess キャッシュからその情報を取得できるようにしています。

Exchange 2000 Server では、ユーザー キャッシュのサイズは最初は 25 MB に設定されていました。多数の Microsoft Office Outlook® 2003 クライアントにサービスを提供する Exchange 2000 Server コンピュータでは、DSAccess ユーザー キャッシュの既定のサイズでは不十分でした。DSAccess キャッシュのサイズが不足しているシステムでは、ローカルのメッセージ配信やアドレス帳の名前解決の速度が期待値を下回る可能性があります。

パフォーマンスを向上させるには、ユーザー キャッシュの既定値を最適化し、Exchange Server 2003 では 140 MB に設定します。Exchange 2000 Server から Exchange Server 2003 へのアップグレードでは、手動による設定がすべて保持されます。この Exchange サーバーが Exchange 2000 Server から Exchange Server 2003 にアップグレードされている場合は、MaxMemoryUser の値が少なくとも 140 MB になっていることを確認する必要があります。

MaxMemoryUser 値は通常、DSAccess キャッシュ内の構成データ オブジェクトが消費できるメモリの最大量を制御する、MaxMemoryConfig 値と組み合わせて使用されていました。以下の手順に説明されている方法で MaxMemoryUser 値を編集または削除する場合は、「DSAccess user cache value is non-default」の説明に従って、MaxMemoryConfig 値も同様に編集または削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxMemoryUser レジストリ キーを使用するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

  3. MaxMemoryUser の値を調べる、または編集します。

    このレジストリ エントリの値は KB 単位です。この値が 140,000 以下に設定されている場合は、MaxMemoryUser を削除し、Microsoft Exchange System Attendant サービスを再開して、Exchange Server 2003 の設定を既定値にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「[XCON] ディレクトリサービスサーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。


DSProxy RFR サービスが無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ディクレクトリ サービス プロキシ参照 (DSProxy RFR) サービスが無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\MSExchangeSA\Parameters\ No RFR Service

Exchange Server アナライザによって、No RFR Service の存在が確認され、さらにその値が 1 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange 2000 Server および Exchnage Server 2003 の DSProxy コンポーネントは、ドメイン コントローラまたは Microsoft Outlook® 98 クライアントおよび Outlook 97 クライアントのグローバル カタログへのディレクトリ アクセスを提供します。Outlook 2000 Service Release 2 (SR-2) 以降のバージョンでは、グローバル カタログ サーバーに直接クエリを発行できます。

Outlook 2000 SR-2 以降のバージョンのクライアントは、Exchange 2000 サーバー以降のバージョンのコンピュータへの初回接続時に、ホーム Exchange サーバーでディレクトリ サービスを検索します。Outlook はまず、最初のセッションのために DSProxy プロセスを処理します。クライアントが DSProxy サービスに接続すると (使用可能なすべてのトランスポート プロトコルを試行します)、クライアントに参照が返されます。この参照には、今後ディレクトリ要求が発生する場合は、すべてのディレクトリ要求をグローバル カタログ サーバーに送信する必要があることが示されています。Outlook はその参照をレジストリ内の MAPI プロファイルに設定します。DSProxy 参照メカニズムを導入することにより、Exchange Server の負荷が軽減され、アドレス帳検索の待ち時間が短縮されます。明示的なサーバー名をプロファイルに入力した場合、その Active Directory® ディレクトリ サービス サーバーに障害が発生したときは、Outlook を再起動する必要があります。この場合、Exchange Server は Outlook に新しい参照を送信します。

一部のシナリオでは、最新バージョンであっても、参照を伴わない DSProxy プロセスの処理が常に Outlook クライアントによって強制実行される場合があります。たとえば、Outlook と Exchange サーバーの間にファイアウォールが存在する場合は、この強制実行が必要となることがあります。

No RFR Service レジストリ エントリを追加して、値を 1 に設定すると、Exchange サーバーは、クライアントに適切なグローバル カタログ サーバーを参照させて直接通信を行う代わりに、Outlook クライアントに対してプロキシのように動作します。No RFR Service レジストリ パラメータを 1 に設定すると、Exchange サーバーのパフォーマンスが低下します。これは、Exchange サーバーがすべての Outlook クライアント (Active Directory と直接通信できる Outlook 2000 SR-2 以降のクライアントを含む) に対してプロキシとして機能するためです。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

DSProxy RFR サービスを有効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. No RFR Service という DWORD 値を新たに作成します。

  4. No RFR Service 値を、設定を 1 にして構成します。

DSProxy RFR サービスを無効にするには、No RFR Service レジストリ値を削除するか、レジストリ値を 0 に設定します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook 2000 SR-2 以降のクライアントと Active Directory との通信方法の詳細については、Microsoft サポート技術情報の文書番号 302914「[XCCC] Outlook 2000 から Active Directory へのアクセス方式」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914) を参照してください。

MAPI クライアントから Active Directory にアクセスする方法の詳細については、Microsoft サポート技術情報の文書番号 256976「MAPI クライアントから Active Directory へアクセスする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976) を参照してください。


EMSMTA.EXE ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EnableAuthEpResolution レジストリ キーが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、リモート プロシージャ コール (RPC) インターフェイス制限のレジストリ キーが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows NT\RPC

EnableAuthEpResolution レジストリ値が存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

RPC インターフェイス制限は、システムがネットワーク経由の攻撃を受けにくくなるようにネットワークの保護を強化するための機能です。

リモートから匿名で使用可能であり、Microsoft Windows® XP で既定で登録される RPC インタフェースによって、攻撃にさらされる危険性が大幅に増加します。動的エンドポイントを使用した呼び出しに対してエンドポイントの解決を提供するには、RPC 自体がそのようなインターフェイスを登録する必要があります。RestrictRemoteClients レジストリ キーにより、システム上のすべての RPC インターフェイスの動作が変更されます。一部の例外を除き、RestrictRemoteClients レジストリ キーによって、システム上の RPC インターフェイスへのリモート匿名アクセスが既定で防止されます。そのため、RPC エンドポイント マッパー インターフェイスは、匿名では使用できなくなります。

動的エンドポイントを使用して呼び出しを試みる RPC クライアントは、まずサーバー上の RPC エンドポイント マッパーに対してクエリを実行し、RPC クライアントがどの動的エンドポイントに接続する必要があるかを判断します。RPC クライアントの呼び出し自体が RPC セキュリティを使用して実行される場合でも、このクエリは匿名で実行されます。Microsoft Windows XP Service Pack 2 の場合、既定の RestrictRemoteClients 機能によってシステム上の RPC インターフェイスへのリモート匿名アクセスが防止されるため、既定では RPC エンドポイント マッパー インターフェイスへの匿名呼び出しは失敗します。この RPC インターフェイス制限のために、RPC クライアント ランタイムは、エンドポイント マッパーに対して認証されたクエリを実行するように変更されます。この RPC インターフェイス制限は、Windows XP Service Pack 2 での既定の動作です。これにより、RPC クライアント ランタイムは、統合 Windows 認証 (以前の NTLM) を使用してエンドポイント マッパーを認証します。統合 Windows 認証は、実際の RPC クライアント呼び出しがこの種の認証を使用した場合に実行されます。以下の条件に当てはまる場合は、既定以外の構成が存在します。

  • 上で説明した RPC レジストリ キーと EnableAuthEpResolution 値が作成されている。

  • EnableAuthEpResolution レジストリ値が 0 に設定されている。

Windows XP Service Pack 2 での RPC サービスの変更の詳細については、「RPC Interface Restrictions」(http://go.microsoft.com/fwlink/?LinkId=47371) を参照してください (このサイトは英語の場合があります)。


Epoxy Client Out Queue Length (IMAP) がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Client Out Queue Length (IMAP) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Client Out Queue Length (IMAP) パフォーマンス カウンタは、Inetinfo.exe プロセスによって Store.exe プロセスに送信された IMAP4 メッセージを含むキュー内のメッセージの数を示します。このキューは、常に 50 未満になっている必要があります。サンプル期間中に Client Out Queue Length (IMAP) カウンタがピーク値の 50 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

Epoxy (ExIPC) は、Microsoft インターネット インフォメーション サービス (IIS) (Inetinfo.exe) および Microsoft Exchange Information Store サービス (Store.exe) のプロセスが、データを高速にやり取りできるようにする共有メモリのメカニズムです。これにより、Inetinfo.exe プロセスと Store.exe プロセスの間で双方向のプロセス間通信を行えます。

注 :
Inetinfo.exe は、WebDAV、IMAP4、NNTP、POP3、SMTP などのインターネット プロトコルからの要求を受け付けます。

このメモリは、Active Directory® 情報をキャッシュする Exchange コンポーネントの DSAccess でも使用されます。

このエラーは、Store.exe プロセスか、Store.exe プロセスが依存するリソースに、このキューを増大させているパフォーマンスの問題があることを示しています。これにより、サーバーの応答時間が長くなります。

この問題を解決するには、「詳細情報」のリソースを使用して、Store.exe プロセスまたは関連リソースのパフォーマンスのボトルネックを特定します。このボトルネックは、ディスクのパフォーマンスの低下や高い CPU 使用率に関連する可能性があります。

詳細情報

  • Epoxy のキューの増大を識別する方法の詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Rising Queues in Epoxy」を参照してください (このサイトは英語の場合があります)。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ストアのパフォーマンスに関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 257725「XADM: How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Client Out Queue Length (POP) がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Client Out Queue Length (POP) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Client Out Queue Length (POP) パフォーマンス カウンタは、Inetinfo.exe プロセスによって Store.exe プロセスに送信された POP3 メッセージを含むキュー内のメッセージの数を示します。このキューは、常に 50 未満になっている必要があります。Exchange Server アナライザは、このカウンタから 5 秒ごとに 5 分間のサンプルを取得します。サンプル期間中に Client Out Queue Length (POP) カウンタがピーク値の 50 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

Epoxy (ExIPC) は、Microsoft インターネット インフォメーション サービス (IIS) (Inetinfo.exe) および Microsoft Exchange Information Store サービス (Store.exe) のプロセスが、データを高速にやり取りできるようにする共有メモリのメカニズムです。これにより、Inetinfo.exe プロセスと Store.exe プロセスの間で双方向のプロセス間通信を行えます。

注 :
Inetinfo.exe は、WebDAV、IMAP4、NNTP、POP3、SMTP などのインターネット プロトコルからの要求を受け付けます。

このメモリは、Active Directory® 情報をキャッシュする Exchange コンポーネントの DSAccess でも使用されます。

このエラーは、Store.exe プロセスか、Store.exe プロセスが依存するリソースに、このキューを増大させているパフォーマンスの問題があることを示しています。これにより、サーバーの応答時間が長くなります。

この問題を解決するには、「詳細情報」のリソースを使用して、Store.exe プロセスまたは関連リソースのパフォーマンスのボトルネックを特定します。このボトルネックは、ディスクのパフォーマンスの低下や高い CPU 使用率に関連する可能性があります。

詳細情報

  • Epoxy のキューの増大を識別する方法の詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Rising Queues in Epoxy」を参照してください (このサイトは英語の場合があります)。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ストアのパフォーマンスに関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 257725「XADM: How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


EPOXY.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


Epoxy パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Client Out Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、以下の状況のいずれかまたは複数が発生しています。

  • Epoxy パフォーマンス モニタ オブジェクトが無効になっている。

  • Epoxy パフォーマンス モニタ オブジェクトが存在しないか、破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能なカウンタによりレジストリが破壊されている場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによりレジストリが変更されている場合に発生する可能性があります。以下の手順は、最初の 2 つの状況を修正する方法を示しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. Epoxy パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List tool (Exctrlst.exe) をダウンロードしてインストールします。Exctrist.exe は、Exctrlst.exe: Extensible Performance Counter List Web サイト (http://go.microsoft.com/fwlink/?LinkId=34436) でダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) に記載されている手順に従って、存在しないまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Exchange Server を修復モードで再インストールしてから、最新の Exchange Server Service Pack を適用する必要があります。


Epoxy Store Out Queue Length (IMAP) がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Store Out Queue Length (IMAP) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Store Out Queue Length (IMAP) パフォーマンス カウンタは、Store.exe プロセスによって Inetinfo.exe プロセスに送信された IMAP4 メッセージを含むキュー内のメッセージの数を示します。このキューは、常に 50 未満になっている必要があります。Exchange Server アナライザは、このカウンタから 5 秒ごとに 5 分間のサンプルを取得します。サンプル期間中に Store Out Queue Length (IMAP) カウンタがピーク値の 50 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

Epoxy (ExIPC) は、Microsoft インターネット インフォメーション サービス (IIS) (Inetinfo.exe) および Microsoft Exchange Information Store サービス (Store.exe) のプロセスが、データを高速にやり取りできるようにする共有メモリのメカニズムです。これにより、Inetinfo.exe プロセスと Store.exe プロセスの間で双方向のプロセス間通信を行えます。

注 :
Inetinfo.exe は、WebDAV、IMAP4、NNTP、POP3、SMTP などのインターネット プロトコルからの要求を受け付けます。

このメモリは、Active Directory® 情報をキャッシュする Exchange コンポーネントの DSAccess でも使用されます。

このエラーは、Inetinfo.exe プロセスか、Inetinfo.exe プロセスが依存するリソースに、このキューを増大させているパフォーマンスの問題があることを示しています。これにより、サーバーの応答時間が長くなる場合があります。したがって、ユーザーはサーバーからの応答を待つ時間が長くなります。

この問題を解決するには、「詳細情報」のリソースを使用して、Inetinfo.exe または関連リソースのパフォーマンスのボトルネックを識別します。このボトルネックは、ディスクのパフォーマンスの低下や高い CPU 使用率に関連する可能性があります。

詳細情報

  • Epoxy のキューの増大を識別する方法の詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Rising Queues in Epoxy」を参照してください (このサイトは英語の場合があります)。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ストアのパフォーマンスに関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 257725「XADM: How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Store Out Queue Length (POP) がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Store Out Queue Length (POP) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Store Out Queue Length (POP) パフォーマンス カウンタは、Store.exe プロセスによって Inetinfo.exe プロセスに送信された POP3 メッセージを含むキュー内のメッセージの数を示します。このキューは、常に 50 未満になっている必要があります。Exchange Server アナライザは、このカウンタから 5 秒ごとに 5 分間のサンプルを取得します。サンプル期間中に Store Out Queue Length (POP) カウンタがピーク値の 50 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

Epoxy (ExIPC) は、Microsoft インターネット インフォメーション サービス (IIS) (Inetinfo.exe) および Microsoft Exchange Information Store サービス (Store.exe) のプロセスが、データを高速にやり取りできるようにする共有メモリのメカニズムです。これにより、Inetinfo.exe プロセスと Store.exe プロセスの間で双方向のプロセス間通信を行えます。

注 :
Inetinfo.exe は、WebDAV、IMAP4、NNTP、POP3、SMTP などのインターネット プロトコルからの要求を受け付けます。

このメモリは、Active Directory® 情報をキャッシュする Exchange コンポーネントの DSAccess でも使用されます。

このエラーは、Inetinfo.exe プロセスか、Inetinfo.exe プロセスが依存するリソースに、このキューを増大させているパフォーマンスの問題があることを示しています。これにより、サーバーの応答時間が長くなる場合があります。したがって、ユーザーはサーバーからの応答を待つ時間が長くなります。

この問題を解決するには、「詳細情報」のリソースを使用して、Inetinfo.exe または関連リソースのパフォーマンスのボトルネックを識別します。このボトルネックは、ディスクのパフォーマンスの低下や高い CPU 使用率に関連する可能性があります。

詳細情報

  • Epoxy のキューの増大を識別する方法の詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Rising Queues in Epoxy」を参照してください (このサイトは英語の場合があります)。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ストアのパフォーマンスに関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 257725「XADM: How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Exchange Server へのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールが Exchange サーバーにアクセスできません。このエラーは、指定した Exchange サーバーの構成情報が、Active Directory® ディレクトリ サービスに見つからなかったことを示しています。

このエラーを修正するには

  • サーバー名を正しく入力したことを確認します。

  • 完全修飾ドメイン名 (Server1.example.com など) ではなく、サーバーのホストまたは NetBIOS 名 (Server1 など) のみを入力します。

  • このサーバーの Active Directory 構成情報にアクセスするために必要なアクセス許可があることを確認します。


Exchange サーバーの情報に対するアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange サーバーの Active Directory® ディレクトリ サービス構成情報へのアクセスに関する問題があります。

このエラーを修正するには

  • 現在ログオンしているアカウントに Active Directory の Exchange サーバー構成情報を読み取るための適切なアクセス許可があるかどうかを確認します。

  • Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

  • Active Directory にアクセスするための明示的なアカウント資格情報を Exchange Server アナライザ ツールに入力します。

  • Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  • 指定した Exchange サーバーが存在し、サーバー名を正しく入力したことを確認します。


メッセージ追跡ログへのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの各インスタンスの MessageID プロパティに対してクエリを実行します。

クエリから結果が返らなかった場合、エラーが表示されます。

このエラーはほとんどの場合、メッセージ追跡センターが無効になっていることが原因で発生します。

メッセージ追跡センターが有効になっていれば、送信者、メール メッセージ、およびメッセージ受信者に関する情報がログに収集されます。特に、メッセージの送受信時刻、メッセージのサイズ、メッセージの優先度、メッセージ受信者の一覧などの統計情報を参照できます。また、電子メール メッセージの件名行をログに収集することもできます。メッセージ追跡センターでは、システム メッセージ、パブリック フォルダ メッセージ、電子メール メッセージなどのメッセージが検索されます。

メッセージを追跡する各サーバーでメッセージ追跡センターを有効にする必要があります。有効にすると、サーバーを介してルーティングされたすべてのメッセージがメッセージ追跡ログに追加されます。

Exchange Server アナライザでスキャンを開始するには、メッセージ追跡が有効になっている必要があります。

注 :
この手順を実行するには、ローカルの Administrators グループのメンバ、および管理グループ レベルで Exchange 管理者のロールが適用されているグループのメンバのアクセス許可が必要です。
サーバーでメッセージ追跡センターを有効にするには

  1. Exchange システム マネージャで、[サーバー] を展開し、メッセージ追跡を有効にするサーバーを右クリックして、[プロパティ] をクリックします。

  2. [全般] タブで、[メッセージの追跡を有効にする] チェック ボックスをオンにします。

  3. サーバーから送信されたメッセージ、サーバーに送信されたメッセージ、またはサーバーを介して送信されたメッセージの件名を記録するには、[件名のログ収集と表示を有効にする] チェック ボックスをオンにします。

    注 :
    件名のログ収集を有効にすると、パフォーマンスが低下することがあります。

  4. [Log file maintenance] で、ログ ファイルを削除できないようにしたり、ログ ファイルの保存期間を変更したりすることができます。追跡ログの既定の保存期間は 7 日間です。

    注 :
    大量のメールを処理するサーバーでは、追跡ログが短期間に大きくなります。ログ ファイル、およびそのディスクを使用する他のサービスやアプリケーションに十分なディスク領域があることを確認してください。

  5. [OK] または [適用] をクリックします。この変更を有効にするためにサービスを再開する必要はありません。

メッセージ追跡センターの使用方法の詳細については、Microsoft サポート技術情報の文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162) を参照してください。

Exchange Server のトランスポートに関する問題をトラブルシューティングする方法の詳細については、Microsoft サポート技術情報の文書番号 821910「Exchange Server 2003 トランスポート問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821910) を参照してください。


ACL のアップグレード中のエラー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-15

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、MSExchangeIS のイベント 9551 エラーが過去 1 時間以内にログに記録されていないかどうかを判断します。

イベント 9551 エラーが過去 1 時間以内にログに記録されていることが検出されると、その時間にログに記録されたイベント 9551 エラーの合計数がカウントされます。

最後に、イベント 9551 エラーが過去 1 時間に 20 回以上ログに記録されていることが検出されると、警告が表示されます。

このエラーは、メールボックス リソースまたはパブリック フォルダのアクセス制御リスト (ACL) に現れているが、有効な Active Directory ディレクトリ サービス オブジェクトには関連していないユーザー アカウントが存在している可能性があることを示します。

Microsoft Exchange Server 2003 または Exchange 2000 Server を実行しているサーバー上にあるメールボックスにアクセスするには、Active Directory において、そのメールボックスの有効な Active Directory ディレクトリ サービス ユーザー アカウントが存在する必要があります。

メールボックスが Exchange Server 5.5 ベースのコンピュータ上で削除された後に、Exchange 2000 Server または Exchange Server 2003 のメールボックス リソースまたはパブリック フォルダが更新されない場合、Active Directory において有効でないアカウントが作成されることになります。

削除したメールボックス アカウントがメールボックス リソースまたはパブリック フォルダの ACL に残っている場合、メールボックス リソースまたはパブリック フォルダがアクセスされ、一覧のアカウントを Exchange が解決しようとするたびに、Active Directory で有効ではない削除されたアカウントは解決されないことになります。この処理によってパフォーマンス上の問題が発生する可能性があります。

この問題を解決するには、次の操作を行います。

  • Exchange 2000 Server Service Pack 3 (SP3) 以降のバージョンがインストールされていることを確認します。最新の Exchange 2000 Server Service Pack を入手するには、マイクロソフト サポート技術情報の文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378) を参照してください。

  • Exchange システム マネージャを使用して、ACL から無効なメールボックス アカウントを手動で削除します。

  • Exchange 環境が Exchange 混在モードになっている場合は、インフォメーション ストアに対して DS/IS 整合性チェッカーを実行します。

  • Exchange が Exchange ネイティブ モードになっている場合は、マイクロソフト サポート技術情報の文書番号 324323「[XADM] アクセス制御リストの変換中に Active Directory に表示されないユーザー アカウントをスキップする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323) の説明に従ってください。

Exchange システム マネージャを使用して ACL から無効なアカウントを手動で削除するには、次の操作を行います。

  1. Exchange システム マネージャを起動し、9551 エラーで特定されたフォルダを見つけます。

  2. フォルダを右クリックし、[プロパティ] を選択します。

  3. [アクセス許可] タブを選択し、[クライアントのアクセス許可] をクリックします。

  4. [名前] ウィンドウで、9551 エラーで特定されたユーザー アカウントを選択し、[削除] ボタンをクリックして ACL からそのアカウントを削除します。
Exchange 混在モードでインフォメーション ストアに対して DS/IS 整合性チェッカーを実行するには、次の操作を行います。

  1. Exchange Server 5.5 管理ツールで、インフォメーション ストアを含んだ Exchange 5.5 Server コンピュータをクリックします。

  2. [ファイル] メニューの [プロパティ] をクリックし、[詳細設定] タブをクリックします。

  3. [整合性調整機能] をクリックします。

  4. [パブリック フォルダのアクセス許可から不明なユーザー アカウントを削除] および [メールボックスのアクセス許可から不明なユーザー アカウントを削除] チェック ボックスをオンにして、[すべての不整合] をクリックします。

  5. その他のチェック ボックスはすべてオフにして、[OK] をクリックします。

詳細情報

この問題の詳細については、以下のマイクロソフト サポート技術情報の文書と Exchange Server リソースを参照してください。

  • イベントおよびエラー メッセージ センターの MSExchangeIS メールボックス ストア イベント 9551 の詳細についてのページ (http://go.microsoft.com/fwlink/?LinkId=83189) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378)

  • マイクロソフト サポート技術情報の文書番号 324323「[XADM] アクセス制御リストの変換中に Active Directory に表示されないユーザー アカウントをスキップする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323)


ESE.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?linkid=33457) を参照してください (このサイトは英語の場合があります)。


ESEUTIL.EXE ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXCDO.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXCHMEM.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXMIME.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXOLEDB.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXPOP3.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXPROX.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXRES.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXSMTP.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


EXSMTP.DLL ファイルのバージョンが古い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、EXSMTP.DLL の Version キーの値を判断します。EXSMTP.DLL の Version キーが 6556.0 に等しくないことが検出されると、警告が表示されます。

この警告は、この Exchange Server コンピュータの EXSMTP.DLL のバージョンが、2004 年 5 月に公開された Exchange 2000 Server Service Pack 3 以降の更新プログラムのロールアップ Version 1 のものであることを示しています。これより新しい更新プログラムのロールアップは、ダウンロードにより入手できます。

この警告を修正するには

  1. 最新の更新 (2004 年 8 月) を、Exchange 2000 Server のダウンロードページ (http://go.microsoft.com/fwlink/?LinkId=33457) からダウンロードします (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 870540「2004 年 8 月公開の Exchange 2000 Server Service Pack 3 以降の更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540) を参照して、最新の更新プログラムについて確認します。

  3. Exchange Server コンピュータ全体をバックアップします。

  4. 2004 年 8 月の更新プログラムを適用します。

この更新プログラムのロールアップやその他の Exchange Server の更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange ActiveSync のトレースが現在有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ActiveSync® に対してトレースが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Tracing\Microsoft Server ActiveSync\MasSync\Enabled

Enabled の値が存在し、 0 より大きい値で構成されていることが検出されると、警告が表示されます。

Exchange ActiveSync は、ISAPI (Internet Server Application Programming Interface) 拡張機能としてインターネット インフォメーション サービス (IIS) に実装されています。IIS、Exchange ActiveSync、および Exchange ActiveSync を使用するクライアント デバイスの多くはネイティブのトレース機能を備えているため、Microsoft Windows Server™ 2003 のネイティブのトレース機能を使用する必要はありません。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Windows NT\CurrentVersion\Tracing\Microsoft Server ActiveSync\MasSync

  3. Enabled の値を削除します。

  4. レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange ActiveSync と Exchange ActiveSync クライアントのトレースおよびログ収集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 330463「[XCCC] Server ActiveSync HTTP エラー コードのトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=330463)

  • 文書番号 330461「サーバー ActiveSync のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=330461)

  • 文書番号 822176「Exchange Server 2003 の Up-to-date の通知のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822176)


Exchange バイナリ ファイルのバージョンが Exchange Server のインストール済みバージョンより新しい
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

これらのいずれかのファイルの Version 値が Exchange Server の Version 値より大きいことが検出されると、警告が表示されます。大きいバージョン番号は、ファイルが予期されたものより新しいことを示しています。この警告は、修正プログラムがインストールされている場合に発生します。

この警告を修正するには

  1. 必要な操作はありません。この警告は、一般に、修正プログラムやその他の更新プログラムがインストールされた結果として新しいファイルが存在することを示しているだけです。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


Exchange クラスタ ノードがドメイン コントローラの役割も果たしている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Microsoft WMI (Windows® Management Instrumentation) オブジェクト (Win32_ComputerSystem クラス) に対してクエリを実行し、サーバーの DomainRole 値を判断します。DomainRole 値は、ドメインにおけるコンピュータの役割を表します。以下の表は、DomainRole の有効な値の一覧です。

値 | 意味
0 | スタンドアロン ワークステーション
1 | メンバ ワークステーション
2 | スタンドアロン サーバー
3 | メンバ サーバー
4 | バックアップ ドメイン コントローラ
5 | プライマリ ドメイン コントローラ

さらに、Exchange Server アナライザは、ClusSvc WMI オブジェクト (Windows クラスタ サービス オブジェクト、Win32_Service クラス) に対してクエリを実行して、Started 値を判断します。値が True の場合はクラスタ サービスが開始されており、値が False の場合はサービスは開始されていません。

クラスタ サービスが実行されている Exchange Server コンピュータの DomainRole 値が 3 よりも大きいと判断されると、エラーが表示されます。このエラーは、ドメイン コントローラとして機能するノードを持つ Windows サーバー クラスタで、Exchange サーバーが実行されていることを示します。

Exchange Server クラスタ ノードをドメイン コントローラとして実行することは、サポート対象外の構成です。

このエラーを修正するには

  1. ドメイン コントローラとして機能させる、クラスタ以外のサーバーを選択し、Active Directory インストール ウィザード (dcpromo) を実行してそのサーバーを昇格させます。

  2. 新しいドメイン コントローラで Active Directory® ディレクトリ サービスを構成したら、既存の Active Directory の内容が新しいサーバーにレプリケートされるのを待ちます。

    Active Directory のサイズによっては、この処理に数時間かかる場合があります。

  3. クラスタ サーバーで Active Directory インストール ウィザード (dcpromo) を実行し、サーバーを降格して Active Directory を削除します。

ドメイン コントローラの昇格および降格の詳細については、Microsoft サポート技術情報の文書番号 238369「ドメイン コントローラとメンバー サーバー間の昇格と降格」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=238369) を参照してください。


Exchange エラー報告が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange エラー報告が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\DisableErrorReporting

DisableErrorReporting の値が 1 に設定されていることが検出されると、警告が表示されます。値が 1 の場合は、Exchange エラー報告が無効になっていることを示します。

Microsoft エラー報告 (Windows エラー報告、Microsoft イベント報告、エラーの自動報告とも呼ばれます) のサポートは、Exchange 2000 Server Service Pack 2 で初めて追加されました。Exchange Server 2003 には、Exchange エラー報告という名前の拡張されたバージョンの Microsoft エラー報告が含まれています。このエラー報告は、管理者へのエラー報告を合理化して企業エラー報告と統合したもので、Exchange Server 2003 の受信者更新サービス用の拡張された報告機能を提供します。

Exchange エラー報告を使用すると、Exchange Server 管理者は HTTPS を使用して、クラッシュやその他の致命的なエラーをインターネット経由で Microsoft エラー報告サーバーに転送することができます。Microsoft オンライン クラッシュ ダンプ解析サービスにエラー報告を送信することをお勧めします。Exchange サーバーから致命的なエラーのデータを収集することは、お使いのソフトウェアのエラーを、Exchange 製品チームが特定して修正することに役立ちます。

Exchange システム マネージャの使用中や、Exchange システム マネージャがインストールされたコンピュータ上で Active Directory ユーザーとコンピュータを使用して Exchange 関連のタスクを実行しているときに致命的なエラーが発生した場合、Exchange エラー報告はエラーについて管理者に通知し、エラーを Microsoft に報告するかどうかを管理者に確認します。Exchange エラー報告は、Microsoft Exchange System Attendant サービス、Microsoft Exchange Information Store サービス、およびその他の Exchange サービスで発生したエラーのトラップと報告も行います。さらに、受信者更新サービスで発生したエラーが原因となってシステム アテンダント コンポーネントが正しくない状態のままになる可能性があるため、Exchange エラー報告では、受信者更新サービスで発生したアクセス違反やその他の内部エラーも報告されます。

Exchange システム マネージャのサーバーのプロパティ ページでチェック ボックスをオンにすると、致命的なエラーの情報を送信するように各 Exchange サーバーを構成できます。

致命的なエラーのデータを Microsoft に送信するように Exchange 2000 Server または Exchange Server 2003 を構成するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開して、操作する管理グループを展開します｡次に、[サーバー] を展開して、操作するサーバーを右クリックし、[プロパティ] をクリックします。Exchange システム マネージャに [管理グループ] ノードが表示されない場合は、[サーバー] を展開し、操作するサーバーの名前を右クリックします。次に、[プロパティ] をクリックします。

  3. [<サーバー名>のプロパティ] ページの [全般] タブで、[サービスの致命的なエラー情報を自動的に Microsoft に送信する] チェック ボックスをオンにし、[適用] をクリックします。

  4. [はい] をクリックして Exchange エラー報告を有効にすることを確認します。

  5. [OK] をクリックします。

致命的なエラーが発生した場合、圧縮されたエラー報告ファイルが作成されます (通常は 10 ～ 50 KB)。このレポートには、ダンプ ファイルとその他のデータが含まれています。ダンプ ファイルは、エラーが発生したプロセスに関する情報を格納しているファイルです。エラーはさまざまなプログラム レベル (たとえば、スレッド レベル、インターフェイス レベル、メソッドや関数のレベル) で発生する可能性がありますが、どのエラーも単一のプロセスのコンテキスト内で発生します。ダンプ ファイルには、通常、各スレッドで実行されていた処理内容の詳細、そのプロセスで使用されていたさまざまなメモリ領域、システム情報、その他の関連するデバッグ情報など、エラーが発生したプロセスに関する情報が含まれています。Exchange Server の場合、エラー レポートにはさらに、Exchange Server の状態に関する情報、オペレーティング システムのバージョン情報、コンピュータのハードウェアの詳細、コンピュータの IP アドレス、および製品ライセンスの識別に使用されるデジタル プロダクト ID が含まれます。

Microsoft では、収集した情報の一部に、システムを一意に識別するために使用できる情報が含まれている可能性があることを認識していますが、個人情報を意図的に収集することはありません。Microsoft は収集したデータをクラッシュの報告とバグの修正にのみ使用し、システムを一意に識別する目的には使用しません。詳細については、エラー報告ポリシーである「Data Collection Policy」(http://go.microsoft.com/fwlink/?LinkId=33818) を参照してください (このサイトは英語の場合があります)。


Exchange フロントエンド サーバーの Boot.ini ファイルに /3GB 起動スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータでユーザー モード プロセスに割り当てられている仮想アドレス スペースの量 (MaxProcessMemorySize) を判断します。また、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI クラスも調べ、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。

MaxProcessMemorySize キーの値が 2097024 に等しくなく、かつ IsFrontEndServer キーが True に設定されていることが検出されると、警告が表示されます。

この警告は、Boot.ini ファイルに /3GB 起動スイッチが設定されているために、Exchange Server コンピュータが最適なメモリ量を使用するように正しく構成されていないことを示します。このスイッチは、以下のオペレーティング システムのいずれかが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。さらに、/3GB スイッチは、1 GB 以上の物理メモリが実装されている場合に、前に示したオペレーティング システムでのみサポートされています。

Microsoft Windows 2000 Server または Microsoft Windows Server 2003 を実行しているサーバーの Boot.ini ファイルに /3GB パラメータが含まれている場合、最大 4 GB の仮想アドレス スペースから、3 GB がユーザー プロセスに割り当てられ、1 GB がカーネルに割り当てられます。通常 (/3GB パラメータが使用されていない場合)、Windows は 2 GB をユーザー プロセスに割り当て、2 GB をカーネルに割り当てます。このため、/3GB スイッチを使用すると、メモリを集中的に使用するアプリケーションが動作する仮想メモリ アドレス スペースがより大きくなり、パフォーマンスが向上します。

/3GB スイッチの使用は、主に、ユーザーのメールボックスをホストする Exchange サーバー上の Store.exe プロセスなどの、メモリを集中的に使用するアプリケーションに役立ちます。フロントエンド サーバーはユーザーのメールボックスをホストしないため、フロントエンド サーバーで /3GB スイッチを使用するメリットはありません。

この警告を修正するには

  1. Windows エクスプローラで、システム パーティションに移動します。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、Windows エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から /3GB スイッチを削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

/3GB 起動スイッチの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 297812「4GT RAM チューニング 機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange IFS ドライブが Windows バックアップから明示的に除外されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、バックアップを使用したバックアップから除外されているファイルとフォルダを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

具体的には、"Exchange IFS" という文字列値を検索します。

また、次のレジストリ エントリも読み取り、Exchange IFS (Installable File System) ドライブを表すドライブ文字を取得します。

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

Exchange 2000 Server では、既定のドライブ文字は M です。Exchange Server 2003 では、IFS ドライブは既定でオフになっています。

FilesNotToBackup キーに "Exchange IFS" という文字列値が含まれていないか、または "Exchange IFS" が含まれていても "Exchange IFS" の値データが "M:\* /s" ("M" は IFS を表すドライブ文字) に等しくないことが検出されると、警告が表示されます。

既定では、IFS ドライブ文字の割り当てが有効にされると、FilesNotToBackup レジストリ キーに "Exchange IFS" が追加されます。M:\ ドライブは Exchange ストアの論理的なビューであり、実際のドライブではありません。このため、このドライブをバックアップすると、添付ファイルの消失などの重大な問題が発生する場合があります。さらに、バックアップ ソフトウェアによってログ ファイルが適切に切り捨てられない可能性があるため、サーバーのディスク空き領域が予期せず不足する場合があります。

バックアップを使用していない場合、この警告は無視してかまいません。バックアップを使用している場合は、すべてのバックアップ ジョブから IFS ドライブを除外することをお勧めします。バックアップやその他のバックアップ プログラムを使用して IFS ドライブをバックアップすると、インフォメーション ストアのデータベースが破損したり、データが消失したりして、IFS ドライブのバックアップからデータを復元できなくなる可能性があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

  3. [FilesNotToBackup] を右クリックし、[新規] をクリックします。次に、[複数行文字列値] をクリックします。名前に「Exchange IFS」と入力し、Enter キーを押します。

  4. 右側のペインで、[Exchange IFS] をダブルクリックし、[値のデータ] に「M:\* /s」と入力します。システムで既定のドライブ文字 M を使用していない場合は、正しいドライブ文字を使用していることを確認してください。

  5. レジストリ エディタを終了します。

Microsoft Windows® レジストリの詳細については、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

Exchange のバックアップと復元の詳細については、『Exchange 2003 Disaster Recovery Operations Guide』(http://go.microsoft.com/fwlink/?LinkId=47570) を参照してください (このサイトは英語の場合があります)。その他の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 258243「[XADM] Exchange 2000 Server のバックアップおよび復元方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=258243)

  • 文書番号 233427「Ntbackup.exe ツールを Windows Server 2003、Windows XP、および、Windows 2000 で使用するときにバックアップされないファイルおよびフォルダの一覧。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=233427)

ウイルス対策ソフトウェアで IFS ドライブをスキャンする場合に発生する可能性のある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


Exchange メールボックス サーバーに 1 GB 以上のメモリが搭載されているのに Boot.ini ファイルで /3GB が設定されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーの物理メモリの容量と、ユーザー モード プロセスに割り当てられている仮想アドレス スペースの容量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クエリ対象のクラス | クエリ対象のキー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_OperatingSystem | OSProductSuite | オペレーティング システムにインストールされ、ライセンスされている追加のシステム製品
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されているランダム アクセス メモリ (RAM) のバイト数

Exchange Server アナライザによって、Exchange Server コンピュータで Windows 2000 Server が実行されておらず、1 GB 以上の物理メモリが搭載されており、MaxProcessMemorySize の値が 2097024 より大きく 3104640 より小さいと判断されると、警告が表示されます。

この警告は、Exchange サーバーが、Microsoft サポート技術情報の文書番号 266096「[XGEN] 1 GB 以上の RAM がある場合、/3GB スイッチが必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096) に記載された要件に準拠していないことを示します。これは、お勧めできる製品構成ではありません。

Microsoft Windows Server™ 2003 では、起動スイッチとして /3GB と /USERVA の 2 種類がサポートされています。これらのスイッチを使用すると、メモリの使用量およびメモリのアドレス スペースの割り当てを調整できます。Windows は、システムに搭載されている物理メモリの容量にかかわらず 4 GB の仮想アドレス スペースを使用し、アプリケーションなどのユーザー モード プロセスに 2 GB を割り当て、オペレーティング システムやカーネル モードのドライバなどのカーネル モード プロセスに 2 GB を割り当てます。1 GB 以上の物理メモリを搭載したシステムでは、これら 2 つの起動スイッチを使用して、アプリケーションにはより多くのメモリ (3 GB) を割り当て、オペレーティング システムにはより少ないメモリ (1 GB) を割り当てることができます。この追加の仮想アドレス スペースは、Exchange インフォメーション ストア プロセスの仮想アドレス スペースにおけるメモリの断片化を減らすために役立ちます。

/3GB スイッチは、この割り当て変更を生じさせるために使用されます。このスイッチは、システムの Boot.ini ファイルに入力されて、再起動後に有効になります。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。さらに、/3GB スイッチは、1 GB 以上の物理メモリが実装されている場合に、前に示したオペレーティング システムでのみサポートされています。

/USERVA スイッチは Windows Server 2003 で新しく導入されました。このスイッチは、ユーザー モード プロセスとカーネル モード プロセスの間で仮想アドレス スペースを分割する方法を、より細かく制御できるようにすることを目的としています。このスイッチは、Exchange 2000 Server や Exchange Server 2003 など、このスイッチをサポートするアプリケーションに対してのみ、各アプリケーションでサポートされている特定の値を指定して使用する必要があります。

注 :
Microsoft 製品サポート サービスは、独自に行われる /USERVA の設定をサポートしていません。ユーザーがこの設定を Boot.ini ファイルに追加するのは、製造元に推奨された場合のみにしてください。

/USERVA スイッチを Exchange Server 2003 システムで使用する場合、サポートされる値は 3030 のみです (たとえば、/USERVA=3030 と指定します)。この値を指定すると、オペレーティング システムに追加の 40 MB が割り当てられ、利用可能なシステム リソースをすべて消費しないでより多くのユーザーを追加できます。

この警告を修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] タブをクリックします。

  3. [起動と回復] 領域で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] 領域で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  5. [Operating Systems] セクションで、/fastdetect スイッチを含む起動用の行の最後に、/3GB /USERVA=3030 スイッチを追加します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開かれているダイアログ ボックスを閉じてから、Exchange Server コンピュータを再起動し、変更を有効にします。

Exchange Server でのメモリの使用方法とパフォーマンスの最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266096「[XGEN] 1 GB 以上の RAM がある場合、/3GB スイッチが必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 810371「[XADM] Windows 2003 Server ベースの Exchange Server で /Userva スイッチを使用する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371)

  • 文書番号 823440「Windows Server 2003 ベースのシステムに Exchange Server 2003 をインストールするとき、/3GB スイッチを使用する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

  • 文書番号 822178「Exchange Server 2003 の機能の依存関係および要件の概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822178)


Exchange プロバイダのトレースが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-06-20

Microsoft Exchange Server アナライザ ツールは Active Directory ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて、serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Microsoft Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 2003 を実行しています。文字列値に "Version 8.0" が含まれている場合、コンピュータでは Microsoft Exchange Server 2007 を実行しています。

また、Exchange Server アナライザは CIM_Datafile Microsoft® WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange トランスポート プロバイダである Emsmdb32.dll の Version キーの値を判断します。Version WMI キーは、このファイルのビルド番号を示しています。

最後に、Exchange アナライザは次のレジストリ エントリに対してクエリを実行し、Exchange プロバイダのトレースが構成され、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Enable Tracing

以下の条件に当てはまる場合は、エラー メッセージが表示されます。

  • サーバーが Exchange Server 2007 を実行していない。

  • Emsmdb32.dll の Version キーが 6.5.7233.47 以降のバージョンである。

  • HKML\Software\Microsoft\Exchange\Exchange Provider\Enable Tracing エントリが存在し、0 以外の値に設定されている。

このエラーは、コンピュータで Exchange トランスポート プロバイダのトレースが有効になっていることを示します。

Exchange トランスポート プロバイダの 6.5.7233.47 以降のバージョンには、トレース機能が組み込まれています。.ttd ファイルにより、次のプログラムのトレースが有効になります。

  • Exchange Server 2003 を実行しているサーバーで MAPI を使用するすべてのプログラム

  • Microsoft Exchange システム管理ツールを使用してインストールされたすべてのプログラム

Exchange トランスポート プロバイダのトレースは、積極的にトラブルシューティングを行う場合にのみ有効にしてください。それ以外の場合、通常のサーバーのパフォーマンスに悪影響を与える可能性があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Exchange Server 2003 で Exchange プロバイダのトレースを無効にするには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. HKML\Software\Microsoft\Exchange\Exchange Provider\ に移動します。

  3. 右側のナビゲーション ウィンドウで、次の操作を行います。

    1. [Enable Tracing] サブキーを右クリックして削除します。または、

    2. [Enable Tracing] をダブルクリックします。

  4. 値を 0 にして Enable Tracing サブキーを構成します。

  5. レジストリ エディタを終了します。

  6. Exchange Information Store サービスを再起動して、これらの変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986 の Microsoft Windows レジストリの説明に関するページを参照してください。


Exchange Management サービスが LocalSystem アカウントで実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Management (MSExchangeMGMT) サービスの StartName プロパティの値を判断します。Exchange Management サービスが LocalSystem (SYSTEM) アカウント以外のアカウントで実行されていることが検出されると、エラーが表示されます。

このエラーは、Exchange Management サービスが、サポートされている構成で実行されていないことを示しています。Exchange Management サービスが他の任意のアカウントで実行されていると、アクセス許可やアクセスのエラーが発生します。

このエラーを解決するには、LocalSystem (SYSTEM) アカウントで開始されるように Exchange Management サービスを構成する必要があります。

Exchange Management サービス アカウントを構成するには

  1. [サービス] Microsoft 管理コンソール (MMC) スナップインを開きます。

  2. Microsoft Exchange Management サービスを見つけて停止します。

  3. [Microsoft Exchange Management] サービスをダブルクリックします。

  4. [Microsoft Exchange Management のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択し、[適用] をクリックします。

  5. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  6. [サービス] スナップインを終了します。

LocalSystem アカウントでの Exchange サービスの実行に関する詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


Exchange Management サービスが停止している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Process Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Management サービスを表す MSExchangeMGMT インスタンスの Started キーの値を判断します。MSExchangeMGMT インスタンスの Started キーの値が True ではないことが検出されると、警告が表示されます。

Exchange Management サービスは、Exchange 2000 Server Service Pack 2 で導入されました。特に Exchange Server メッセージ追跡センター機能と一部の Exchange システム マネージャの機能は、このサービスに依存して機能します。

Exchange Management サービスを使用すると、ユーザー インターフェイスを使用して、Exchange Server 2003 または Exchange 2000 Server が Active Directory® ディレクトリ サービスにアクセスするために使用するドメイン コントローラまたはグローバル カタログ サーバーを指定することができます。このサービスは、メッセージ追跡にも必要となります。このサービスを無効にしても、Exchange のコア機能への影響はありません。ただし、Exchange の機能を監査する場合は、メールをルーティングするすべての Exchange Server コンピュータにメッセージ追跡機能が必要となる場合があります。

注 :
フロントエンド サーバーの最も一般的な用途は、メールのルーティングではなくメールにアクセスすることなので、フロントエンド サーバーでは Exchange Management サービスを実行する必要がない場合もあります。

自動的に開始されるように Exchange Management サービスを構成するには

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. [Microsoft Exchange Management] サービスをダブルクリックします。

  3. [Microsoft Exchange Management のプロパティ] ページの [全般] タブで、[スタートアップの種類] ボックスの一覧の [自動] をクリックし、[適用] をクリックします。

  4. [サービスの状態] の [開始] をクリックし、[OK] をクリックします。

Exchange Management サービスの詳細については、Microsoft サポート技術情報の文書番号 307413「[XGEN] Exchange Management サービスの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307413) を参照してください。

Exchange の管理に関するより一般的な情報については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) を参照してください (このサイトは英語の場合があります)。


Exchange 2000 Server で最新の Service Pack が実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータで実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が 4416 より大きく、6249 以下であると判断されると、警告が表示されます。

この警告は、Exchange Server コンピュータで実行されているコードが、そのコンピュータで実行されているバージョンの Exchange 向けに提供されている最新のコードではないことを示します。

この警告を修正するには

  1. Exchange 2000 Server Service Pack 3 (http://go.microsoft.com/fwlink/?LinkId=17058) をダウンロードします。

  2. 『Exchange 2000 Server Service Pack 3 Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=12337) を参照します (このサイトは英語の場合があります)。

  3. 最新の更新 (2004 年 8 月) を、http://go.microsoft.com/fwlink/?LinkId=33457 からダウンロードします。

  4. Microsoft サポート技術情報の文書番号 870540「2004 年 8 月公開の Exchange 2000 Server Service Pack 3 以降の更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540) を参照して、最新の更新プログラムについて確認します。

  5. Exchange Server コンピュータの完全なバックアップを作成します。

  6. Exchange 2000 Server Service Pack 3 を適用します。

  7. 2004 年 8 月の更新プログラムを適用します。

Exchange 2000 Server の最新 Service Pack の入手に関する詳細については、Microsoft サポート技術情報の文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378) を参照してください。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Windows Server 2003 で Exchange 2000 Server がサポートされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。この値が 5.0 の場合は Windows 2000 Server を実行していることを示し、5.2 の場合は Windows Server™ 2003 を実行していることを示します。

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。この文字列値に "Version 5.5" が含まれている場合は、そのコンピュータで Microsoft Exchange Server Version 5.5 が実行されています。この文字列値に "Version 6.0" が含まれている場合は、Exchange 2000 Server が実行されています。この文字列値に "Version 6.5" が含まれている場合は、Exchange Server 2003 が実行されています。

Exchange Server アナライザにより、CurrentVersion の値が 5.2 であり、serialNumber の値に "Version 6.0" が含まれていることが検出された場合は、エラーが表示されます。この構成はサポートされていません。このエラーはできるだけ早く修正する必要があります。

このエラーを修正するには

  1. 以下のいずれかを実行します。

    • サポート対象のオペレーティング システムを実行しているサーバー上に Exchange 2000 Server をインストールし、メールボックスをそのサーバーに移動します。

    • Exchange 2000 Server を Exchange Server 2003 にアップグレードします。

サポートされている構成の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange Server と Windows Server 2003 の詳細については、Microsoft サポート技術情報の文書番号 810591「[XGEN] Exchange 2000 Server および Exchange Server 5.5 の Windows Server 2003 との互換性」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810591) を参照してください。


Exchange 2007 プレリリース版がインストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-20

Microsoft Exchange Server アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、ディレクトリ内にあるすべての Exchange Server オブジェクトについて serialNumber 属性を判断します。serialNumber 属性は、Exchange Server のバージョンと、Service Pack のバージョン (インストールされている場合) を含む文字列値です。たとえば、Service Pack がインストールされていない Exchange Server 2007 コンピュータでは、serialNumber 属性が Version 8.0 (Build 0685) になります。

serialNumber 属性の文字列値に 8.0 が含まれていても、0685 未満のビルド番号が含まれていないことが検出されると、エラーが表示されます。

このエラーは、Exchange Server 2007 コンピュータがプレリリース版の Exchange Server 2007 を実行していることを示します。

プレリリース版の Exchange Server 2007 は運用環境ではサポートされません。

このエラーに対処するには、製品版の Exchange Server 2007 をインストールします。


Exchange 2007 サーバー オブジェクトが別の管理グループに移動されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-11

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内のすべての Exchange Server オブジェクトについて、serialNumber 属性の値を判断します。

また、Exchange Server アナライザは、Exchange Server を実行しているサーバーが置かれている管理グループの cn 属性値に対してクエリを実行し、Exchange 2007 専用の管理グループである [Exchange 管理グループ (FYDIBOHF23SPDLT)] かどうかを判断することもできます。

Microsoft Exchange Server 2007 を実行しているサーバーが [Exchange 管理グループ (FYDIBOHF23SPDLT)] 以外の管理グループに置かれていると判断した場合、Exchange Server アナライザはエラーを表示します。

このエラーは、Exchange 2007 専用の管理グループからサーバーが手動で移動されたことが原因でメール フローの問題が発生している可能性があることを示します。

serialNumber 属性は、Exchange Server のバージョンと、インストールされている Service Pack のバージョン (インストールされている場合) を含む文字列値です。serialNumber 属性の値が Version 8.0 の場合、サーバーは Exchange 2007 を実行していることを示します。

Microsoft Exchange Server 2003 および Microsoft Exchange 2000 Server では、Exchange オブジェクトの管理に必要なアクセス許可を委任するために、管理グループを使用して Exchange オブジェクトがグループ化されます。Exchange 2007 では、論理管理ユニットに管理グループは使用されません。Exchange Server 2003 または Exchange 2000 Server と Exchange 2007 の共存をサポートするために、Exchange 2007 のインストール時に、すべての Exchange 2007 サーバーは自動的に 1 つの管理グループに追加されます。Exchange Server 2003 の Exchange システム マネージャでは、この管理グループは [Exchange 管理グループ (FYDIBOHF23SPDLT)] として認識されます。

この問題を解決するには、サーバーを削除して再インストールします。


Exchange がグローバル カタログ サーバーではないドメイン コントローラ上に常駐している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DomainRole キーの値を判断します。以下の表に、このキーの有効な値を示します。

値 | 意味
0 | スタンドアロン ワークステーション
1 | メンバ ワークステーション
2 | スタンドアロン サーバー
3 | メンバ サーバー
4 | バックアップ ドメイン コントローラ
5 | プライマリ ドメイン コントローラ

Exchange Server アナライザはまた、Win32_Service WMI (Windows Management Instrumentation) クラスに対してもクエリを実行し、ClusSvc (クラスタ サービス) の Started キーの値を判断します。さらに、Win32_OperatingSystem WMI クラスに対してクエリを実行し、OSProductSuite キーの値を判断します。OSProductSuite キーの値は、コンピュータ上で実行されている Windows のバージョンを示しています。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト カテゴリが msExchExchangeServer であるすべてのディレクトリ オブジェクトの serialNumber 属性値を判断します。serialNumber 属性値は、使用されている Exchange Server のバージョンを示しています。

最後に、Exchange Server アナライザは Active Directory に対してクエリを実行し、このサーバーの isGlobalCatalogReady 属性値を判断します。この属性値が True の場合は、このディレクトリ サーバーが、機能しているグローバル カタログ サーバーでもあることを示し、False の場合はグローバル カタログ サーバーではないことを示します。

Exchange Server アナライザによって、Exchange Server コンピュータの DomainRole キーの値が 3 より大きく、その Exchange Server コンピュータが Windows Small Business Server または Exchange Server Version 5.5 を実行していないか、あるいは Windows クラスタ内で実行されておらず、さらに isGlobalCatalogReady 属性が False に設定されていることが検出されると、警告が表示されます。

この警告は、Exchange Server が、機能しているグローバル カタログ サーバーではないディレクトリ サーバー上で実行されていることを示しています。この構成はサポートされておらず、Exchange サービスの失敗を引き起こす可能性があります。

Small Business Server がインストールされていないドメイン コントローラで Exchange Server を実行している場合は、以下の問題を考慮に入れてください。

  • Exchange Server と Active Directory はどちらもリソースを集中的に使用するアプリケーションです。両方のアプリケーションを同じコンピュータで実行する場合は、パフォーマンス面の影響を考慮する必要があります。

  • Exchange Server をドメイン コントローラで実行する場合は、そのドメイン コントローラをグローバル カタログ サーバーにすることも必要です。

  • DSAccess (Directory Service Access)、ディレクトリ サービス プロキシ (DSProxy)、メッセージ カテゴライザなどのいくつかの Exchange Server ディレクトリ コンポーネントは、その他のドメイン コントローラやグローバル カタログ サーバーにはフェールオーバーされません。

  • Windows の /3GB 起動スイッチを使用すると Exchange Server がすべてのメモリを消費し、Active Directory で使用できるメモリが減少するため、このスイッチは利用しないでください。

  • サーバーをシャットダウンまたは再起動する前に Exchange Server のサービスが停止されていないと、システムのシャットダウンにかかる時間が大幅に長くなります。

  • この構成では、Exchange 管理者が Active Directory に対してローカルの管理アクセス許可を持つことになるため、セキュリティのレベルが低下します。これは、管理者が自分の特権を昇格させることができるからです。さらに、Exchange Server または Active Directory のいずれかでセキュリティの脆弱性が見つかると、もう一方も危険にさらされます。

  • Exchange Server 2003 または Exchange Server 2007 をドメイン コントローラ上で実行している場合、ドメイン コントローラの昇格ツール (DCPromo) を使用してコンピュータの役割を変更することはサポートされません。また、この操作によって Microsoft Outlook® Mobile Access などのコンポーネントが破損することがわかっています。

  • Active Directory ドメイン コントローラでもあるクラスタ化されたノードでの Exchange Server 2003 または Exchange Server 2007 の実行はサポートされていないため、実行しないでください。つまり、ドメイン コントローラでもあるクラスタ内のノードで Exchange 2000 Server を実行する場合は、Exchange 2000 Server から Exchange Server 2003 にアップグレードする前に、サーバーをメンバ サーバーに降格する必要があります。

このコンピュータで Exchange 2000 Server を実行している場合は、できるだけ早い機会に DCPromo を使用してサーバーをメンバ サーバーに降格することをお勧めします。コンピュータで Exchange Server 2003 または Exchange Server 2007 を実行している場合は、次のいずれかの手順を使用して、この警告を修正してください。

Exchange を別のコンピュータへ移動してこの警告を修正するには

  1. Exchange Server を別のコンピュータにインストールします。

  2. Exchange タスク ウィザードの [メールボックスの移動] を使用して、既存のメールボックスをすべてドメイン コントローラから新しい Exchange サーバーに移動します。

  3. 古い Exchange Server コンピュータによって保持されているすべてのパブリック フォルダと役割を、新しい Exchange Server コンピュータに再配置します。

  4. Exchange Server をドメイン コントローラからアンインストールします。
Exchange サーバーをグローバル カタログ サーバーにしてこの警告を修正するには

  1. Active Directory サイトとサービス スナップインを起動します。

  2. [サイト] を展開し、サイトを展開します。次に、[サーバー] を展開します。

  3. グローバル カタログ サーバーとして指定するドメイン コントローラを選択します。

  4. 右側のウィンドウで、[NTDS Settings] を右クリックし、[プロパティ] を選択します。

  5. [全般] タブで、[グローバル カタログ] チェック ボックスをオンにします。ディレクトリ サーバーが Windows 2000 Server Service Pack 2 以前を実行している場合は、サーバーを再起動して変更を有効にします。Windows 2000 Server Service Pack 3 以降または Windows Server™ 2003 を実行している場合は、サーバーを再起動しなくても動的に変更が適用されます。

ドメイン コントローラへの Exchange Server のインストールの詳細については、Microsoft サポート技術情報の文書番号 250989「XADM: ADC をまた Exchange Server を実行する Windows 2000 ドメイン コントローラでインストールします。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250989) を参照してください。


Exchange Server 5.5 の検出
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server Version 5.5 を実行しています。この文字列値に "Version 6.0" が含まれている場合は、Exchange 2000 Server が実行されています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Exchange Server 2003 を実行しています。

serialNumber の値に "Version 5.5" が含まれていることが検出されると、エラーが表示されます。

このエラーは、検出されたバージョンの Exchange Server を、このバージョンの Exchange Server アナライザではこれ以上分析できないことを示しています。

Exchange Server アナライザは、検出されたバージョンの Exchange Server では使用できないさまざまな特定のプログラムのインターフェイスに依存しています。

このエラーに対処するには、Exchange 2000 以降のバージョンを実行する Exchange Server を指定します。

このルールが誤って引き起こされたと考えられる場合は、Active Directory の Exchange Server オブジェクトの serialNumber 属性の値が正しく設定されていることを確認します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、または別のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
serialNumber 属性の値を表示するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=<Exchange 組織名>] の順に展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. サーバー オブジェクトを右クリックし、[プロパティ] をクリックします。

  5. [serialNumber] 属性をダブルクリックし、その現在の値を表示します。

Exchange Server 2003 の展開方法の詳細については、Exchange Server デプロイメント ガイドのページ (http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください。

Exchange Server 5.5 から Exchange Server 2003 への移行方法の詳細については、マイクロソフト サポート技術情報の記事 259912 の、Exchange Server 5.5 を Exchange 2000 Server または Exchange Server 2003 にアップグレードする際の必要条件に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=259912) を参照してください。

Exchange Server 2003 への移行とアップグレードの方法の詳細については、Exchange Server 2003 へのアップグレードに関するページ (http://go.microsoft.com/fwlink/?LinkId=34186) を参照してください。


Exchange Server 5.5 に最新の Service Pack が適用されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が 1959 より大きく、2653 より小さいことが検出されると、警告が表示されます。これは、このコンピュータで Service Pack 4 適用前の Exchange Server 5.5 が実行されていることを示します。

この警告は、Exchange Server コンピュータが、そのコンピュータで実行中の Exchange のバージョンに対応する最新のコードを実行していないことを示します。

この警告を修正するには

  1. Exchange Server 5.5 Service Pack 4 をダウンロードします (http://go.microsoft.com/fwlink/?LinkId=33456) (このサイトは英語の場合があります)。

  2. Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=33456) から、Exchange Server 5.5 の最新の更新プログラム (2004 年 11 月) をダウンロードします (このサイトは英語の場合があります)。

  3. この更新プログラムについては、Microsoft サポート技術情報の文書番号 841765「2004 年 11 月公開の Exchange Server 5.5 用更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=841765) を参照してください。

  4. Exchange Server コンピュータの完全なバックアップを実行します。

  5. Exchange Server 5.5 Service Pack 4 を適用します。

  6. 2004 年 11 月公開の更新プログラムを適用します。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Windows 2003 で Exchange Server 5.5 がサポートされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合は Windows 2000 Server を、値が 5.2 の場合は Windows Server™ 2003 を実行しています。

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server Version 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータは Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Exchange Server 2003 を実行しています。

Exchange Server アナライザにより、CurrentVersion の値が 5.2 であり、serialNumber の値に "Version 5.5" が含まれていることが検出された場合は、エラーが表示されます。この構成はサポートされていません。このエラーはできるだけ早く修正する必要があります。

このエラーを修正するには

  • 以下のいずれかを実行します。

    • サポート対象のオペレーティング システムを実行しているサーバー上に Exchange Server 5.5 をインストールし、メールボックスをそのサーバーに移動します。

    • Exchange Server 5.5 を Exchange Server 2003 に移行します。

Exchange Server 2003 の展開の詳細については、『Exchange Server 2003 Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange Server と Windows Server 2003 の詳細については、Microsoft サポート技術情報の文書番号 810591「[XGEN] Exchange 2000 Server および Exchange Server 5.5 の Windows Server 2003 との互換性」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810591) を参照してください。

Exchange Server 5.5 から Exchange Server 2003 への移行の詳細については、Microsoft サポート技術情報の文書番号 259912「Exchange Server 5.5 を Exchange Server 2000 または Exchange Server 2003 にアップグレードする際の必要条件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=259912) を参照してください。

Exchange Server 2003 への移行とアップグレードの詳細については、移行とアップグレードに関するページ「Upgrade to Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=34186) を参照してください (このサイトは英語の場合があります)。


Exchange Server 5.0 の最新の Service Pack または更新プログラムのロールアップが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が 1456 より大きく、1460 未満であることが検出されると、警告が表示されます。

この警告は、この Exchange Server コンピュータ上で、実行されているバージョンの Exchange に対応する入手可能な最新のコードが実行されていないことを示しています。

この警告を修正するには

  1. Exchange Server 5.0 Service Pack 2 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168858) をダウンロードします。

  2. Service Pack 2 README.TXT ファイル (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168735) に目を通します。

  3. Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=41361) にアクセスし、Exchange Server 5.0 の最新の更新プログラム (2004 年 4 月リリース) をダウンロードします (このサイトは英語の場合があります)。

  4. この更新プログラムについては、Microsoft サポート技術情報の文書番号 834130「Microsoft Exchange Server 5.0 更新ロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834130) を参照してください。

  5. Exchange Server コンピュータ全体をバックアップします。

  6. Exchange Server 5.0 Service Pack 2 を適用します。

  7. 2004 年 4 月公開の更新プログラムを適用します。

この更新プログラムやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange Server 5.5 が Active Directory ドメイン コントローラ上に常駐している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DomainRole キーの値を判断します。以下の表に、このキーの有効な値を示します。

値 | 意味
0 | スタンドアロン ワークステーション
1 | メンバ ワークステーション
2 | スタンドアロン サーバー
3 | メンバ サーバー
4 | バックアップ ドメイン コントローラ
5 | プライマリ ドメイン コントローラ

Exchange Server アナライザはまた、Win32_Service WMI (Windows Management Instrumentation) クラスに対してもクエリを実行し、ClusSvc (クラスタ サービス) の Started キーの値を判断します。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト カテゴリが msExchExchangeServer であるすべてのディレクトリ オブジェクトの serialNumber 属性値を判断します。serialNumber 属性値は、使用されている Exchange Server のバージョンを示しています。

Exchange Server アナライザによって、Exchange Server コンピュータの DomainRole キーの値が 3 より大きく、その Exchange Server コンピュータが Windows クラスタ内で実行されておらず、さらに実行されている Exchange のバージョンが Exchange Server Version 5.5 であることが検出されると、警告が表示されます。

この警告は、Exchange Server 5.5 が Active Directory サーバー上で実行されていることを示しています。この状況では、ポートが競合する可能性があるため、Active Directory コネクタ (ADC) で問題が発生する場合があります。ADC でこのサーバーがターゲットとして使用される場合は、正しい Exchange ライトウェイト ディレクトリ アクセス プロトコル (LDAP) ポート番号が使用されていることを確認する必要があります。既定では、ディレクトリ サーバーは TCP ポート 389 で LDAP 要求を待機します。Exchange のポートが変更され、ADC がその Exchange ポートを使用するように構成されない限り、ADC は Exchange と通信できません。

Active Directory は、LDAP アクセス用に標準の LDAP ポート 389 を使用します。ただし、標準のポート番号の使用は、同様に LDAP ポート 389 で接続要求を待機しようとしている同じサーバーに常駐する Exchange サーバーより優先されます。ディレクトリへの Exchange サーバーの LDAP アクセスを許可するには、Exchange の LDAP ポートを再割り当てする必要があります。

この警告を修正するには

  1. Exchange 管理ツールを起動します。

  2. [サイト名] を展開し、[構成] を展開します。次に、[プロトコル] を展開し、[LDAP (ディレクトリ) サイトの既定値] を展開します。

  3. ポートの割り当てを 389 から、現在使用されていないポートに変更します。

  4. [OK] をクリックして変更を保存します。

  5. Microsoft Exchange Directory サービスを再開して、変更を有効にします。

  6. 必要に応じて、このサーバーをターゲットとして使用している ADC を、新しいポートを使用するように再構成します。

Exchange Server 5.5 で LDAP ポートの割り当てを変更する方法の詳細については、Microsoft サポート技術情報の文書番号 224447「[XADM] Exchange Server で LDAP のポート割り当てを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=224447) を参照してください。


Exchange Server DNS の名前解決エラー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、各 Exchange Server コンピュータに対して構成されているドメイン ネーム システム (DNS) サーバーに対し、DNS クエリの実行を試みます。この接続は、名前解決の要求を実行して結果を分析するカスタム オブジェクト プロセッサを使用することによって作成されます。Exchange Server アナライザでクエリ結果の一部としてインターネット プロトコル (IP) アドレスを受信しなかった場合、エラーが表示されます。

このエラーは、Exchange Server コンピュータが DNS で見つからなかったことを示します。Exchange Server および Active Directory® ディレクトリ サービスの両方が正しく動作するためには、正しく構成されて正常に動作している DNS が必要です。DNS の登録と解決の問題は、メッセージを送信、受信、および配信する機能に、広範囲に及ぶ影響を与える可能性があります。

Active Directory と Exchange Server が正しく動作することを保証するためには、DNS を正しく構成する必要があります。Active Directory のための DNS 構成の詳細な扱い方については、Microsoft サポート技術情報の文書番号 237675「Active Directory 用に DNS をセットアップする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=237675) を参照してください。

このエラーを修正するには

  1. DNS が正しく動作していること、および Exchange Server の DNS エントリが正常に登録されることを保証するため、以下の構成項目を確認します。

    • DNS の IP の構成

    • 動的なゾーンの更新

    • DNS フォワーダ

  2. ルート ゾーンのエントリが存在するかどうかを確認します。DNS 管理コンソールで前方参照ゾーンを表示します。そこには、ドメインのエントリが存在します。その他のゾーン エントリも存在することがあります。ドット (".") ゾーンは存在しません。ドット (".") ゾーンが存在する場合は削除します。ドット (".") ゾーンは DNS サーバーをルート サーバーと認識します。一般に、外部 (インターネット) アクセスを必要とする Active Directory ドメインはルート DNS サーバーとしては構成しません。ドット (".") を削除した後、ディレクトリ サーバーの Ipconfig /registerdns を使用して、Exchange Server の IP アドレスを手動で再登録します。Netlogon サービスも再開する必要がある場合があります。

  3. Exchange Server コンピュータの netdiag /fix を使用して、Exchange Server DNS エントリを手動で再登録します。

Active Directory での DNS 使用の詳細については、Microsoft サポート技術情報の文書番号 323418「[HOWTO] Active Directory が有効な Windows Server 2003 で、既存の DNS インフラストラクチャに DNS を統合する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418) を参照してください。

DNS と Active Directory の問題のトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 260371「Windows 2000 における一般的な Active Directory セットアップの問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260371) を参照してください。


Exchange サーバーがフロントエンドとして指定されており、メールボックスをホストしているように見える
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Exchange Server Microsoft WMI (Windows® Management Instrumentation) オブジェクト (Exchange_Server クラス) に対してクエリを実行し、サーバーの IsFrontEndServer の値を判断します。この値が True の場合、Exchange サーバーはフロントエンド サーバーとして動作しています。サーバーにメールボックス ストアが存在する場合、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバー上にメールボックスがいくつ存在するかを判断します。それぞれのメールボックス ストア オブジェクト (msExchPrivateMDB クラス) には、複数の値を持つ homeMDBBL 属性があり、ストア内に存在するすべてのメールボックスが値として列挙されます。これらの値をカウントすることで、Exhcange Server アナライザはサーバー上にあるメールボックスの合計数を取得します。

Exchange サーバーがフロントエンド サーバーとして指定されており、同時に 20 を超えるメールボックスが構成されている場合、警告が表示されます。

構成によっては、フロントエンド サーバーにサービス メールボックスを配置することが必要な場合があります。たとえば、フロントエンド サーバーが SMTP (Simple Mail Transfer Protocol) メールをインターネットから受信する場合、そのサーバー上に Exchange SMTP サービス専用のメールボックスが必要な場合があります。Exchange Server アナライザでは、Exchange サーバー上に 20 を超えるメールボックスが構成されている場合に警告を表示することだけが、これらのサービス メールボックスについての説明となっています。

フロントエンド サーバーには、ユーザーのメールボックスを配置しないでください。そのような構成はサポートされていません。

ユーザーのメールボックスがフロントエンド サーバーに置かれている場合、Exchange システム マネージャ (Exchange Server 2003 のみ) または Active Directory ユーザーとコンピュータを使用して、それらのメールボックスを適切なバックエンド サーバーに移動します。

メールボックスを移動するには (Exchange 2000 Server または Exchange Server 2003)

  1. Active Directory ユーザーとコンピュータで、メールボックスを移動するユーザーを選択します。

  2. 前の手順で選択したユーザーの一覧を右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

メールボックスを移動するには (Exchange Server 2003 のみ)

  1. Exchange システム マネージャで、[サーバー] を展開し、メールボックスを移動するサーバーを展開します。次に、メールボックスの移動元の ストレージ グループを展開して移動するメールボックスが含まれる メールボックス ストアを展開し、[メールボックス] をクリックします。

  2. 詳細ペインで、メールボックスを移動するユーザーを右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

Exchange フロントエンド サーバーの正しい構成の詳細については、Microsoft サポート技術情報の文書番号 822443「Exchange Server 2003 におけるフロントエンド サーバーの考慮事項。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822443) を参照してください。

Exchange フロントエンド サーバーの展開と構成に関する一般的な推奨事項については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) を参照してください (このサイトは英語の場合があります)。

Exchange フロントエンド サーバーでユーザーのメールボックスを運用したために発生する可能性があるエラーの詳細については、Microsoft サポート技術情報の文書番号 273296「[XCON] フロントエンド サーバー上でユーザーがメールを取得できない」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=273296) を参照してください。

Exchange Server 2003 におけるメールボックスの移動の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829)

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)


Exchange サーバーが、推奨される構成ではないドメイン コントローラになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-28

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DomainRole キーの値を判断します。以下の表に、このキーの有効な値を示します。

値 | 意味
0 | スタンドアロン ワークステーション
1 | メンバ ワークステーション
2 | スタンドアロン サーバー
3 | メンバ サーバー
4 | バックアップ ドメイン コントローラ
5 | プライマリ ドメイン コントローラ

さらに、Exchange Server アナライザは Win32_Service WMI クラスに対してもクエリを実行し、ClusSvc (クラスタ サービス) の Started キーの値を判断します。

Exchange Server アナライザは、Active Directory® ディレクトリに対してもクエリを実行し、オブジェクト カテゴリが msExchExchangeServer であるすべてのディレクトリ オブジェクトについて、serialNumber 属性の値を判断します。serialNumber 属性の値は、使用されている Exchange Server のバージョンを示します。

Exchange Server コンピュータの DomainRole キーの値が 3 より大きく、その Exchange Server コンピュータが Exchange Server Version 5.5 を実行していないか、または Windows クラスタ内で実行されていると判断されると、警告が表示されます。

Exchange Server を Microsoft Small Business Server 2000 または Windows Small Business Server 2003 の一部として実行している場合は、ドメイン コントローラ上に Exchange Server をインストールできます。ただし、Exchange Server を Small Business Server の一部として実行していない場合は、ドメイン コントローラ上で Exchange Server を実行しないようにすることをお勧めします。

Small Business Server がインストールされていないドメイン コントローラで Exchange Server を実行している場合は、以下の問題に注意してください。

  • Exchange Server と Active Directory はどちらもリソースを集中的に使用するアプリケーションです。両方のアプリケーションを同じコンピュータで実行する場合は、パフォーマンス面の影響を考慮する必要があります。

  • Exchange Server をドメイン コントローラで実行する場合は、そのドメイン コントローラをグローバル カタログ サーバーにすることも必要です。グローバル カタログ サーバーの作成の詳細については、Microsoft サポート技術情報の文書番号 313994「[HOWTO] Windows 2000 でグローバル カタログの作成または移動を行う方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313994) を参照してください。

  • DSAccess (Directory Service Access)、ディレクトリ サービス プロキシ (DSProxy)、メッセージ カテゴライザなどのいくつかの Exchange Server ディレクトリ コンポーネントは、その他のドメイン コントローラやグローバル カタログ サーバーにフェールオーバーされません。

  • Windows の /3GB 起動スイッチを使用すると Exchange Server がすべてのメモリを消費し、Active Directory で使用できるメモリが減少するため、このスイッチは利用しないでください。

  • サーバーをシャットダウンまたは再起動する前に Exchange Server のサービスが停止されていないと、システムのシャットダウンダウンにかかる時間が大幅に長くなります。

  • この構成では、Exchange 管理者が Active Directory に対してローカルの管理アクセス許可を持ち、自分の特権を昇格させることができるため、セキュリティのレベルが低下します。また、Exchange Server または Active Directory のいずれかでセキュリティの脆弱性が見つかると、もう一方も危険にさらされます。

  • Exchange Server 2003 または Exchange Server 2007 をドメイン コントローラ上で実行している場合、ドメイン コントローラの昇格ツール (DCPromo) を使用してコンピュータの役割を変更することはサポートされません。また、この操作によって Microsoft Outlook® Mobile Access などのコンポーネントが破損することがわかっています。

  • Active Directory ドメイン コントローラでもあるクラスタ化されたノードでの Exchange Server 2003 または Exchange Server 2007 の実行はサポートされていないため、実行しないでください。これは、ドメイン コントローラでもあるクラスタ内のノードで Exchange 2000 Server を実行する場合は、Exchange 2000 Server から Exchange Server 2003 にアップグレードする前に、サーバーをメンバ サーバーに降格する必要があることを意味します。

このコンピュータで Exchange 2000 Server を実行している場合は、できるだけ早い機会に DCPromo を使用してサーバーをメンバ サーバーに降格することをお勧めします。コンピュータで Exchange Server 2003 を実行している場合は、次の手順を使用して、この警告を修正してください。

この警告を修正するには、次の操作を行います。

  1. Exchange Server を別のコンピュータにインストールします。

  2. Exchange タスク ウィザードの [メールボックスの移動] を使用して、既存のメールボックスをすべてドメイン コントローラから新しい Exchange サーバーに移動します。

  3. 古い Exchange Server コンピュータによって保持されているすべてのパブリック フォルダと役割を、新しい Exchange Server コンピュータに再配置します。

  4. Exchange Server をドメイン コントローラからアンインストールします。

ドメイン コントローラへの Exchange Server のインストールの詳細については、Microsoft サポート技術情報の文書番号 250989「XADM: ADC をまた Exchange Server を実行する Windows 2000 ドメイン コントローラでインストールします。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250989) を参照してください。


Exchange サーバーが停止しているか、Exchange サーバーに到達できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、リモート プロシージャ コール (RPC) を使用して、次に示す Exchange Server コンピュータのレジストリ キーの CurrentVersion 文字列値を読み取ります。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

Exchange Server アナライザが何らかの理由でこのレジストリの値を読み取れない場合は、エラーが表示されます。

このエラーを修正するには

  1. Exchange Server コンピュータが起動し、ネットワークに接続されていることを確認します。

  2. Ping コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. ファイアウォールが設置されている場合は、RPC ポートがブロックされているかどうかを調べます。

  4. Exchange Server コンピュータで Remote Registry サービスが開始されていることを確認します。

  5. Exchange Server アナライザ ツールが実行されているアカウントのアクセス許可を調べ、Exchange Server コンピュータのレジストリを読み取るための十分なアクセス許可がアカウントに与えられていることを確認します。

ネットワーク接続の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングの詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題をトラブルシューティングする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=56285) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーが Windows NT4.0 上で実行されているため、使用できる診断情報が限定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合は Windows 2000 Server を、値が 5.2 の場合は Windows Server™ 2003 を実行しています。

CurrentVersion の値が 4.0 に等しいことが Exchange Server アナライザによって検出された場合、警告が表示されます。

この警告は、この Exchange Server コンピュータで Windows NT Server 4.0 が実行されていることを示します。Windows NT Server 4.0 では、それより後のバージョンの Windows Server ほど多くの診断情報が提供されません。したがって、Exchange Server アナライザで収集し分析することができる情報は、限られた量のみになります。

この警告を修正するには

  1. 直ちに行う必要がある操作はありません。この警告は、情報提供のみを目的としています。

  2. Windows NT Server 4.0 と Exchange Server Version 5.5 はプロダクト ライフサイクルの終わりに近づいているため、Windows Server 2003 と Exchange Server 2003 にアップグレードすることを検討してください。

Windows NT Server 4.0 と Exchange Server 5.5 のプロダクト ライフサイクルの詳細については、Microsoft Support Lifecycle Web サイト (http://go.microsoft.com/fwlink/?LinkId=21759) を参照してください (このサイトは英語の場合があります)。

Windows Server 2003 の詳細については、製品のホーム ページである「Microsoft Windows Server 2003」(http://go.microsoft.com/fwlink/?LinkId=26095) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 の詳細については、製品のホームページである「Microsoft Exchange Server」(http://go.microsoft.com/fwlink/?LinkId=21573) を参照してください (このサイトは英語の場合があります)。


Exchange 2003 サーバーで Service Pack 2 の最終ビルドが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内のすべての Exchange Server オブジェクトについて、serialNumber 属性の値を判断します。serialNumber 属性は、Exchange Server のバージョンと、インストールされている Service Pack のバージョン (インストールされている場合) を含む文字列値です。たとえば、Service Pack 1 がインストールされている Exchange Server 2003 コンピュータでは、serialNumber 属性が Version 6.5 (Build 7638: Service Pack 2) になります。

serialNumber 属性の文字列値に 6.5 と Service Pack 2 は含まれているが 7638 は含まれないことが検出されると、警告が表示されます。

この警告は、Exchange Server 2003 コンピュータで、プレリリース版の Exchange Server 2003 Service Pack 2 が実行されていることを示します。

注 :
Exchange Server の Service Pack はアンインストールできないため、Exchange Server を実行しているコンピュータの完全バックアップを実行してから Service Pack を適用することを強くお勧めします。
この警告を修正するには

  1. Exchange Server 2003 Service Pack 2 の最終バージョンは、Exchange Server 2003 Service Pack 2 Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) から入手できます (このサイトは英語の場合があります)。

  2. Exchange Server 2003 Service Pack 2 のリリース ノート (http://go.microsoft.com/fwlink/?LinkId=52072) の内容を確認します (このサイトは英語の場合があります)。

  3. Exchange Server コンピュータを完全にバックアップします。

  4. Exchange Server 2003 Service Pack 2 を適用します。

  5. Exchange Server を実行しているコンピュータを再度完全にバックアップします。

Exchange Server の Service Pack のインストール方法の詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange Server で SharePoint Portal Server が実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、Microsoft Windows SharePoint® Portal Server (MSDMSERV) の Started キーの値を判断します。この値が True の場合は、この Exchange サーバー上で SharePoint Portal Server が実行されていることを示しています。

Exchange Server アナライザによって、Exchange Server コンピュータ上で SharePoint Portal Server が実行されていることが検出されると、警告が表示されます。

SharePoint Portal Server は Exchange Server とは互換性がないため、削除する必要があります。ShrePoint Portal Server と Exchange Server は連携して動作することによって、組織の共同作業環境内で 1 つの役割を果たすように設計されています。ただし、SharePoint Portal Server と Exchange Server は互いに並行して動作するように設計されており、同じハードウェア上で共存するようには設計されていません。

この警告を修正するには

  • Exchange Server または SharePoinit Portal Server のどちらかを別のコンピュータに移動します。どちらかのプログラムをコンピュータから削除することをお勧めします。

Exchange Server のメールボックスを移動する方法の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange Server と SharePoint Portal Server の互換性の詳細については、Microsoft サポート技術情報の文書番号 277567「[SPS] SharePoint Portal Server と Exchange 2000 Server の共存」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277567) を参照してください。


Exchange Server がゲストとしてインストールされた Virtual Server 2005 が別の Exchange Server で実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ キーの値を読み取り、そのサーバーが仮想サーバーかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Classes\Installer\Products\354F2D7F395B57846953B997DF778AC1

次のレジストリ値も確認します。

HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters

さらに、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、Microsoft Virtual Server 2005 を実行している物理コンピュータ上で Microsoft Exchange Information Store サービス (MSExchangeIS) が実行されているかどうかを判断します。

そのサーバーが仮想サーバーであり、上記のレジストリ ブランチが存在して、さらに物理コンピュータ上で MSExchangeIS が実行されていることが検出されると、エラーが表示されます。

HKLM\Software\Classes\Installer\Products\354F2D7F395B57846953B997DF778AC1 キーが存在する場合は、Exchange Server コンピュータに Virtual Machine Additions がインストールされています。このキーが存在し、かつ HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters キーが存在する場合は、Exchange Server コンピュータが Virtual Server 2005 でゲスト仮想コンピュータとして実行されています。

Microsoft では、バージョンに関係なく、仮想コンピュータまたはエミュレータでの Exchange Server の実行をサポートしていません。この点は、Microsoft Virtual Server 2005、Microsoft Virtual PC 2004、またはその他の任意のサードパーティー製仮想コンピュータ プログラム上で実行される Exchange Server にも当てはまります。Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Calatog」(http://go.microsoft.com/fwlink/?linkid=17219) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています (このサイトは英語の場合があります)。

さらに、Exchange Server が実行されているコンピュータ上で仮想サーバーのゲストとして Exchange を実行すると、サービス全体にわたる適切な冗長性を確保できないため、この方法はベスト プラクティスとは言えません。

このエラーを修正するには

  1. メールボックスを、Vitual Server 2005 環境下で実行している Exchange Server から、仮想 Exchange Server コンピュータ以外のコンピュータに移動します。

  2. 必要に応じて、パブリック フォルダを再格納し、仮想 Exchange サーバーが保持していた役割を転送します。

  3. Exchange を仮想コンピュータからアンインストールすることにより、その Exchange の使用を停止し Exchange インフラストラクチャおよび Active Directory ディレクトリ サービスから削除します。

メールボックスの移動の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

仮想環境で実行される Exchange Server コンピュータに対するサポートの詳細については、Microsoft サポート技術情報の文書 320220「Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください (このサイトは英語の場合があります)。

Virtual Server 2005 の詳細については、「Microsoft Virtual Server 2005」(http://go.microsoft.com/fwlink/?linkid=34938) を参照してください (このサイトは英語の場合があります)。

Virtual PC 2004 の詳細については、「Microsof Virtual PC 2004」(http://go.microsoft.com/fwlink/?linkid=34663) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーで DNS サービスが実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DNS サーバー サービス (DNS) の Started キー の値を判断します。この値が True のときは、この Exchange サーバー上で DNS サーバー サービスが実行されていることを示しています。

Exchange Server アナライザはまた、Win32_OperatingSystem WMI クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーに対して返される値は、その Exchange Server コンピュータ上で実行されている Windows オペレーティング システムのバージョンを示しています。

さらに、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。

DNS サーバー サービスが、以下の基準を満たす Exchange Server コンピュータ上で開始されていることが検出されると、警告が表示されます。

  • Exchange Server コンピュータが 100 を超えるメールボックスをホストしている。

  • Exchange Server コンピュータが Windows Small Business Server 2003 または Small Business Server 2000 上で実行されていない。

DNS サーバー サービスを、運用環境の Exchange メールボックス サーバーと同じコンピュータ上で実行することはお勧めできません。DNS サーバー サービスと Exchange Server を運用環境内の同じコンピュータ上で同時にホストすると、その一方または両方によってパフォーマンスが低下する可能性があります。

この警告を修正するには

  1. この警告を修正するには、以下のいずれかのオプションを検討する必要があります。

    • コンピュータから Exchange Server か DNS Server のどちらかを移動して取り除きます。どちらかのサーバー アプリケーションをコンピュータから完全に削除することをお勧めします。

    • Exchange メールボックスをサーバーから移動して取り除きます。少なくともメールボックスを削除して、Exchange サーバーをプロトコル サーバーまたはインフラストラクチャ サーバーにする必要があります。これにより、ディスク I/O の負荷がかなり低減され、CPU の負荷もわずかに低減されます (後者は Exchange のインフラストラクチャ役割に依存します)。

    • 代わりに、Small Business Server をインストールすることを検討してください。複数の Exchange サーバーを必要としない、ユーザー数が 75 未満の小規模な環境で Exchange を実行している場合は、Small Business Server をインストールすると利点が得られる可能性があります。Small Business Server には、Microsoft SQL Server™ と Exchange Server の両方、および Microsoft のその他のコア サーバー アプリケーションが含まれており、単一コンピュータでの運用のために開発、テスト、および最適化されています。

メールボックスおよび Exchange サーバーの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

  • 文書番号 297289「[XADM] Exchange Server 2000 を同じサーバー名のまま新規のハードウェアに移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=297289)

Small Business Server の詳細については、「Windows Small Business Server 2003 Service Pack 1 の提供開始」(http://go.microsoft.com/fwlink/?linkid=23456) を参照してください。


SQL Server を実行している Exchange サーバー
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft SQL Server™ サービス (MSSQLSERVER) の Started キーの値を判断します。この値が True のときは、この Exchange サーバー上で SQL Server サービスが実行されていることを示しています。

Exchange Server アナライザはまた、Win32_OperatingSystem WMI クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーに対して返される値は、その Exchange Server コンピュータ上で実行されている Windows オペレーティング システムのバージョンを示しています。

さらに、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。

SQL Server サービスが、以下のすべての基準を満たす Exchange Server コンピュータ上で開始されていることが検出されると、警告が表示されます。

  • Exchange Server コンピュータが 100 を超えるメールボックスをホストしている。

  • Exchange Server コンピュータが Windows Small Business Server 2003 または Small Business Server 2000 上で実行されていない。

SQL Server を 運用環境の Exchange メールボックス サーバーと同じコンピュータ上で実行することはお勧めできません。SQL Server と Exchange メールボックス サーバーのどちらも、最適な運用のために大量のメモリとディスク リソースを消費します。SQL Server と Exchange Server を運用環境内の同じコンピュータ上で同時にホストすると、その一方または両方によってパフォーマンスが低下する可能性があります。さらに、そのようなインストールをトラブルシューティングしたり、セキュリティで保護したりすることも困難になります。

最後に、SQL Servr と Exchange Server を同じコンピュータ上で実行した場合に発生する可能性のある相互運用性の問題もいくつか知られています。これらの問題のほとんどは、Microsoft 分散トランザクション コーディネータ (MS DTC)、Microsoft ADO (ActiveX® Data Objects)、OLE データベース (OLE DB) など、この 2 つのサーバーに共通したファイルやプログラムのバージョンが一致していないために発生します。

この警告を修正するには

  • この警告を修正するには、以下のいずれかのオプションを検討する必要があります。

    • コンピュータから Exchange Server か SQL Server のどちらかを移動して取り除きます。どちらかのプログラムをコンピュータから完全に削除することをお勧めします。

    • Exchange メールボックスをサーバーから移動して取り除きます。少なくともメールボックスを削除して、Exchange サーバーをプロトコル サーバーまたはインフラストラクチャ サーバーにする必要があります。これにより、ディスク I/O の負荷がかなり低減され、CPU の負荷もわずかに低減されます (後者は Exchange のインフラストラクチャ役割に依存します)。

    • 代わりに、Small Business Server をインストールすることを検討してください。複数の Exchange サーバーを必要としない小規模な環境で Exchange を実行している場合は、Small Business Server をインストールすると利点が得られる可能性があります。Small Business Server には、DNS Server と Exchange Server の両方、および Microsoft のその他のコア サーバー アプリケーションが含まれており、単一コンピュータでの運用のために開発、テスト、および最適化されています。

メールボックスおよび Exchange サーバーの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

  • 文書番号 297289「[XADM] Exchange Server 2000 を同じサーバー名のまま新規のハードウェアに移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=297289)

Small Business Server の詳細については、「Windows Small Business Server 2003 Service Pack 1 の提供開始」(http://go.microsoft.com/fwlink/?linkid=23456) を参照してください。


Exchange サーバーが VMware 環境で実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-26

仮想環境で実行される Exchange Server コンピュータに対するサポートの詳細については、Microsoft サポート技術情報の文書番号 897615 の、マイクロソフト以外のハードウェア仮想化ソフトウェアでマイクロソフトのソフトウェアを実行する場合のサポート ポリシーについての説明 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=897615) を参照してください。


Exchange サーバーのメモリが 1 GB 未満であるにもかかわらず、boot.ini ファイルに /3GB および /USERVA=3030 スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、2 つのMicrosoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータ内の物理メモリの容量、およびユーザー モード プロセスに割り当てられた仮想アドレス スペースの容量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クラス | キー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_OperatingSystem | OSProductSuite | オペレーティング システムにインストールされ、ライセンスされている追加のシステム製品
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されているランダム アクセス メモリ (RAM) のバイト数

Exchange Server アナライザによって、Exchange Server コンピュータの RAM が 950 MB 未満であり、かつ MaxProcessMemorySize の値が 2,097,024 より大きく、3,104,640 より小さいことが検出されると、警告が表示されます。

この警告は、Exchange Server コンピュータが次の 2 つの点でメモリを最適に使用するように正しく構成されていないことを表しています。

  • /USERVA=3030 起動スイッチが設定されています。このスイッチが必要なのは、Microsoft Windows Server™ 2003 オペレーティング システム上で実行されている、1 GB 以上のメモリを搭載している Exchange Server コンピュータのみです。

  • /3GB 起動スイッチが設定されています。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

    • Microsoft Windows Server 2003 Standard Edition

    • Microsoft Windows Server 2003 Enterprise Edition

    • Microsoft Windows Server 2003 Datacenter Edition

    • Microsoft Windows 2000 Advanced Server

    • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。/3GB スイッチは、1 GB 以上の物理メモリが実装されている場合の、上記のオペレーティング システムでのみサポートされています。

1 GB の物理メモリが実装されているシステムでこの警告が表示される場合は、この物理メモリの一部にハードウェア レベルで別のコンポーネント (ビデオ カードなど) がすでに割り当てられているために、割り当てられた物理メモリがオペレーティング システムから使用できなくなっていることを示している可能性があります。この場合は、Windows によって物理的に実装されるメモリの容量が、コンピュータに実装されている物理メモリの実容量より小さくなります。この状況が発生した場合は、BIOS によって報告される実装済みメモリの量と、Windows によって報告される実装済みメモリの量を比較する必要があります。

Windows Server 2003 でこの警告を修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] をクリックします。

  3. [起動と回復] で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] の [編集] をクリックします。Windows の Boot.ini ファイルがメモ帳に表示されます。

  5. [Operating Systems] セクションで、すべての起動行から /3GB /USERVA=3030 スイッチを削除します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

Windows 2000 Server でこの警告を修正するには

  1. エクスプローラで、システム パーティションに移動します。

  2. boot.ini ファイルが表示されない場合は、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合は、Windows エクスプローラ ウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. Windows エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. 「/3GB」 を削除します。「/USERVA=3030」 があればそれも削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

/3GB および /USERVA 起動スイッチの使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 308356「Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356)

  • 文書番号 297812「4GT RAM チューニング機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOW TO]Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange サーバーのメモリが 1 GB 未満であるにもかかわらず、Boot.ini ファイルに /3GB スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータ内の物理メモリの容量、および Exchange Server コンピュータ上で実行されているユーザー モード プロセスに割り当てられた仮想アドレス スペースの容量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クエリが実行されるクラス | クエリが実行されるキー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されたランダム アクセス メモリ (RAM) のバイト数

TotalPhysicalMemory の値が 1073741824 未満であり、かつ MaxProcessMemorySize の値が 3145600 と等しいことが検出されると、警告が表示されます。

この警告は、システムの物理メモリが 950 MB 未満であるにもかかわらず、Boot.ini ファイルに /3GB 起動スイッチが構成されていることを示します。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。/3GB スイッチがサポートされるのは、物理メモリが 1 GB 以上搭載されている上記のオペレーティング システムだけです。

1 GB の物理メモリが実装されているシステムでこの警告が表示される場合は、この物理メモリの一部にハードウェア レベルで別のコンポーネント (ビデオ カードなど) がすでに割り当てられているために、割り当てられた物理メモリがオペレーティング システムから使用できなくなっていることを示している可能性があります。この場合は、Windows によって物理的に実装されるメモリの容量が、コンピュータに実装されている物理メモリの実容量より小さくなります。この状況が発生した場合は、BIOS によって報告される実装済みメモリの量と、Windows によって報告される実装済みメモリの量を比較する必要があります。

Windows Server 2003 でこの警告を修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] をクリックします。

  3. [起動と回復] で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  5. [Operating Systems] セクションで、すべての起動行から /3GB スイッチを削除します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

Windows 2000 Server でこの警告を修正するには

  1. エクスプローラから、システム パーティションに移動します。このパーティションには、Boot.ini や NTLDR など、ハードウェア固有のファイルが保持されています。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、Windows エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。確認を求めるメッセージが表示されたら、[はい] をクリックします。

  3. Boot.ini ファイルが Windows エクスプローラに表示されたら、このファイルを右クリックし、[プログラムから開く] をクリックします。次に、[メモ帳] をクリックしてファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から /3GB スイッチを削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

Exchange Server のためのメモリ使用量の最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」?(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange サーバーの Boot.ini ファイルに /3GB 起動スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータでユーザー モード プロセスに割り当てられている仮想アドレス スペースの量 (MaxProcessMemorySize) を判断します。

また、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI クラスも調べ、IsFrontEndServer キーの値を判断します。値が False のときは、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True のときは、Exchange Server コンピュータはフロントエンド サーバーです。

Exchange Server アナライザはさらに、Win32_Service WMI クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) が存在し、開始されているかどうかを判断します。

最後に、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、メールボックス ストア オブジェクト (msExchPrivateMDB) の homeMDBBL 属性のカウントを判断します。判明したカウントは、Exchange Server コンピュータで見つかったメールボックスの数です。

MaxProcessMemorySize キーの値が 2097024 ではないこと、IsFrontEndServer キーが False に設定されていること、クラスタ サービスが実行されていないこと、Exchange Server のメールボックス ストアに含まれるメールボックスの数が 20 未満であること、および Exchange が Microsoft Windows Small Business Server 2003 上で実行されていないことが検出されると、警告が表示されます。

この警告は、Boot.ini ファイル内で /3GB 起動スイッチが設定されているため、メモリ使用が最適になるようにディレクトリ サーバーが正しく構成されていないことを示します。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。さらに、/3GB スイッチは、1 GB 以上の物理メモリが実装されている場合に、前に示したオペレーティング システムでのみサポートされています。

サポートされているオペレーティング システムの Boot.ini ファイルに /3GB パラメータが含まれている場合、最大 4 GB の仮想アドレス スペースから、3 GB がユーザー プロセスに割り当てられ、1 GB がカーネルに割り当てられます。通常 (/3GB パラメータが使用されていない場合)、Windows は 2 GB をユーザー プロセスに割り当て、2 GB をカーネルに割り当てます。このため、/3GB スイッチを使用すると、メモリを集中的に使用するアプリケーションが動作する仮想メモリ アドレス スペースがより大きくなり、パフォーマンスが向上します。

/3GB スイッチを使用することが主に役立つのは、ユーザーのメールボックスをホストする Exchange サーバー上の Store.exe プロセスのように、メモリを集中的に使用するアプリケーションです。フロントエンド サーバーはユーザーのメールボックスをホストしないため、フロントエンド サーバーで /3GB スイッチを使用することによる利点はありません。

この警告を修正するには

  1. Windows エクスプローラで、システム パーティションに移動します。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、Windows エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. Windows エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、すべての起動行から /3GB スイッチを削除します。

  5. 変更を保存して、メモ帳を閉じます。

  6. コンピュータを再起動して、変更を有効にします。

/3GB スイッチの使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)


Exchange 2003 サーバーで Service Pack 1 の最終ビルド (7226.6) が実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内にあるすべての Exchange Server オブジェクトについて serialNumber 属性を判断します。serialNumber 属性は、Exchange Server のバージョンと、インストールされている Service Pack のバージョン (インストールされている場合) を含む文字列値です。たとえば、Service Pack 1 がインストールされている Exchange Server 2003 コンピュータでは、serialNumber 属性が Version 6.5 (Build 7226.6:Service Pack 1) になります。

serialNumber 属性の文字列値に 6.5 と Service Pack 1 は含まれていても、7226.6 は含まれないことが検出されると、警告が表示されます。

この警告は、Exchange Server 2003 コンピュータで、プレリリース版の Exchange Server 2003 Service Pack 1 が実行されていることを示します。

注 :
Exchange の各種 Service Pack はアンインストールできないため、Exchange Server コンピュータの完全バックアップを実行してから、Service Pack を適用することを強くお勧めします。

この警告を修正するには

  1. Exchange Server 2003 Service Pack 1 (http://go.microsoft.com/fwlink/?linkid=29090) の最新バージョンを入手します。

  2. Exchange Server 2003 のリリース ノート (http://go.microsoft.com/fwlink/?linkid=23235) の内容を確認します (このサイトは英語の場合があります)。

  3. ヘルプとサポートの Web サイト (http://go.microsoft.com/fwlink/?linkid=34272) で、Service Pack 1 に含まれる更新プログラムを確認します (このサイトは英語の場合があります)。

  4. Exchange Server コンピュータを完全にバックアップします。

  5. Exchange Server 2003 の Service Pack 1 を適用します。

  6. Exchange Server コンピュータを再度完全にバックアップします。

Exchange Server の Service Pack のインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange サーバーが Windows 2000 Server を実行しているにもかかわらず、boot.ini ファイルに /3GB スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータ内の物理メモリの容量、およびユーザー モード プロセスに割り当てられた仮想アドレス スペースの容量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クラス | キー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_OperatingSystem | OSProductSuite | オペレーティング システムにインストールされ、ライセンスされている追加のシステム製品
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されているランダム アクセス メモリ (RAM) のバイト数

MaxProcessMemorySize キーの値が 2097024 以外であり、かつ OSProductSuite キーの値が Windows 2000 Server に解決されていることが検出されると、エラーが表示されます。

この警告は、Boot.ini ファイル内で /3GB 起動スイッチが設定されているため、メモリ使用が最適になるようにディレクトリ サーバーが正しく構成されていないことを示します。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server™ 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。/3GB スイッチがサポートされるのは、物理メモリが 1 GB 以上搭載されている上記のオペレーティング システムだけです。

Windows Server 2003 でこのエラーを修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] タブをクリックします。

  3. [起動/回復] で、[設定] ボタンをクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] で、[編集] ボタンをクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  5. [Operating Systems] セクションで、すべての起動行から /3GB スイッチを削除します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、ディレクトリ サーバーを再起動してこの変更を有効にします。

Windows 2000 Server でこのエラーを修正するには

  1. エクスプローラで、システム パーティションに移動します。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、Windows エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. Windows エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. /3GB を削除し、ファイルを保存します。

  5. ディレクトリ サーバーを再起動して、変更を有効にします。

/3GB 起動スイッチおよび /USERVA 起動スイッチの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 297812「4GT RAM チューニング機能の使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 316739「Boot.ini ファイルで /USERVA スイッチを使用して /3GB 構成をチューニングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」?(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


Exchange Server WMI にアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-24

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Name キーに値が設定されているかどうかを判断します。WMI に対するクエリが失敗し、かつ Exchange Server が Microsoft Windows NT® Server°4.0 上で実行されていない場合は、エラーが表示されます。

このエラーには、次の 2 つの原因が考えられます。

  • Exchange Server アナライザを実行するアカウントが、WMI クラスに対してクエリを実行するための十分なアクセス許可を持っていない。

  • ネットワークの問題により、Exchange Server アナライザからコンピュータにアクセスできない。

このエラーを修正するには

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. ファイアウォールが設置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを調べます。

  4. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange サーバーで、ローカルの Administrator アクセス許可を持っている必要があります。

    または、次の手順に従って、Exchange Server アナライザの実行に使用するアカウントに、特定の WMI アクセス許可を与えることもできます。

    1. Exchange コンピュータで、[コンピュータの管理] Microsoft 管理コンソール (MMC) のツリーを開きます。

    2. [サービスとアプリケーション] で、[WMI コントロール] を右クリックし、[プロパティ] をクリックします。

    3. [WMI コントロールのプロパティ] ページで、[セキュリティ] タブをクリックし、[Root] を展開します。

    4. [CIMV2] フォルダを選択し、[セキュリティ] をクリックします。

    5. [セキュリティ ROOT\CIMV2] ページで、Exchange Server アナライザの実行に使用するアカウントを追加します。

  5. 前の手順 5 で追加したアカウントを選択します。[<選択したアカウント> のアクセス許可] の [許可] 列で、[リモートの有効化] チェック ボックスと [セキュリティの読み取り] チェック ボックスをオンにし、[OK] をクリックします。

ネットワーク接続の問題に関するトラブルシューティングの詳細については、マイクロソフト サポート技術情報の記事 325487 の、ネットワーク接続の問題のトラブルシューティング方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングの詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題をトラブルシューティングする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、マイクロソフト サポート技術情報の記事 832017 の、Windows サーバー システムのサービス概要およびネットワーク ポート要件に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


フロントエンド サーバーで Exchange System Attendant サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange System Attendant サービスの Started キーの値を判断します。値が False の場合、Exchange System Attendant サービスは実行されていません。値が True の場合、Exchange System Attendant サービスは実行されています。

Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間の Exchange_Server WMI クラスに対してもクエリを実行し、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。

Exchange Server アナライザによって、Exchange フロントエンド サーバーの Started キーの値が False に設定されていることが検出されると、警告が表示されます。

通常、ほとんどの Exchange サーバーでは常にシステム アテンダント サービスが実行されます。しかし、システム アテンダント サービスを実行する必要がない場合もあります。たとえば、フロントエンド サーバーでシステム アテンダント サービスが必要なのは、サーバーに構成の変更を加える場合のみです。

Exchange Server は、受信者ポリシー、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの構成、RPC over HTTP の設定、およびユーザーのメールボックスに関する情報を含めて、すべての構成情報を Active Directory® ディレクトリ サービスに格納します。ただし SMTP は、インターネット インフォメーション サービス (IIS) メタベースから設定を読み取ります。Exchange が SMTP および RPC over HTTP 機能で必要とする情報を IIS メタベースに書き込むために、システム アテンダントのディレクトリ サービスからメタベースへのレプリケーション (DS2MB) コンポーネントは、構成情報を Active Directory から IIS メタベースにレプリケートします。システム アテンダントが実行されていない場合、Active Directory に格納されている Exchange Server 構成設定に加えられた変更は、Exchange Server の IIS メタベースにコピーされません。構成変更が行われておらず、SMTP メッセージの処理が行われていない場合は、システム アテンダント サービスを停止状態のままにしておくことができます。

構成に変更を加える場合は、システム アテンダント サービスを開始し、構成に変更を加えてから、それらの変更が IIS メタベースにレプリケートされるまで待ちます。変更が Active Directory から IIS メタベースにレプリケートされたかどうかを判断するには、Exchange Server のアプリケーション イベント ログに、イベント ソースが MSExchangeMU でイベント ID が 1005 である 3 つのエントリが存在するかどうかを確認します。DS2MB が正常にレプリケートされると、これらのイベントがログに記録されます。これらのイベントがログ出力されたら、直ちにシステム アテンダント サービスを停止できます。

SMTP をフロントエンド サーバー上で使用している場合以外は、システム アテンダント サービスを停止して無効に設定する構成をお勧めします。SMTP を使用するフロントエンド サーバー上、および他のすべての Exchange Server コンピュータ上では、メッセージを配信し、SMTP とメールボックス ストアのトランザクションにサービスを提供し、DS2MB のレプリケーションを実行するために、Exchange System Attendant サービスが実行されている必要があります。

バックエンド サーバー、およびメールボックスまたはパブリック フォルダを格納している他のすべての Exchange サーバーでは、Exchange System Attendant サービスを常に実行しておく必要があります。

この警告を修正するには

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. 右側のペインで、[Microsoft Exchange System Attendant] サービスまでスクロールし、このサービスをダブルクリックします。この操作によって [システム アテンダント サービスのプロパティ] ダイアログ ボックスが表示されます。

  3. [スタートアップの種類] ボックスの一覧で、値を [自動] に設定します。

  4. [開始] をクリックしてシステム アテンダント サービスを開始します。

  5. [OK] をクリックして変更を保存し、[Microsoft Exchange System Attendant のプロパティ] ダイアログ ボックスを閉じます。

  6. [サービス] スナップインを終了します。

システム アテンダント サービスの無効化、および Exchange サーバーのセキュリティ保護の詳細については、Exchange Server に関する以下のトピックを参照してください。

  • 「Securing Exchange 2000 Servers Based on Role」(http://go.microsoft.com/fwlink/?LinkId=35585) (このサイトは英語の場合があります)

  • 『Exchange Server Security Hardening Guide』(http://go.microsoft.com/fwlink/?LinkId=47578) (このサイトは英語の場合があります)


Exchange System Attendant サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange System Attendant サービスの Started キーの値を判断します。値が False の場合、Exchange System Attendant サービスは実行されていません。値が True の場合、Exchange System Attendant サービスは実行されています。

また、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI クラスも調べ、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True のときは、Exchange Server コンピュータはフロントエンド サーバーです。

フロントエンド サーバーではない Exchange Server コンピュータで Started キーの値が False に設定されていることが検出されると、警告が表示されます。

一般に、ほとんどの Exchange サーバーではシステム アテンダント サービスが常時実行されています。ただし、システム アテンダント サービスの実行が不要な場合もあります。たとえば、Exchange 2000 Server または Exchange Server 2003 のフロントエンド サーバーでシステム アテンダント サービスが必要になるのは、サーバーの構成に変更を加える場合のみです。

Exchange Server は、受信者ポリシー、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの構成、RPC (リモート プロシージャ コール) over HTTP (Hypertext Transfer Protocol) の設定、ユーザーのメールボックスなどに関する情報を含む、すべての構成情報を Active Directory® ディレクトリ サービスに格納します。ただし、SMTP は、設定をインターネット インフォメーション サービス (IIS) メタベースから読み取ります。Exchange が SMTP および RPC over HTTP 機能で必要とする情報を IIS メタベースに書き込むために、システム アテンダントのディレクトリ サービスからメタベースへのレプリケーション (DS2MB) コンポーネントは、構成情報を Active Directory から IIS メタベースにレプリケートします。システム アテンダントが実行されていない場合、Active Directory に格納されている Exchange Server の構成設定に加えられた変更は、Exchange Server の IIS メタベースにコピーされません。構成に変更が加えられず、SMTP メッセージが処理中ではない場合、システム アテンダント サービスは停止状態のままです。

構成に変更を加える場合は、システム アテンダント サービスを開始し、構成に変更を加えてから、それらの変更が IIS メタベースにレプリケートされるまで待ちます。変更が Active Directory から IIS メタベースにレプリケートされたかどうかを判断するには、Exchange サーバーのアプリケーション イベント ログに、イベント ソースが MSExchangeMU でイベント ID が 1005 である 3 つのエントリが存在するかどうかを確認します。DS2MB が正常にレプリケートされると、これらのイベントがログに記録されます。これらのイベントがログに記録された後であれば、システム アテンダント サービスをすぐに停止できます。

SMTP を Exchange 2000 Server または Exchange Server 2003 のフロントエンド サーバー上で使用している場合以外は、システム アテンダント サービスを停止して無効に設定する構成をお勧めします。SMTP を使用する Exchange 2000 Server または Exchange Server 2003 のフロントエンド サーバー、および他のすべての Exchange Server コンピュータでは、メッセージの配信、SMTP とメールボックス ストア トランザクションへのサービス提供、および DS2MB レプリケーションの実行のため、Exchange System Attendant サービスを実行しておく必要があります。

バックエンド サーバー、およびメールボックスやパブリック フォルダを格納している他のすべての Exchange サーバーでは、Exchange System Attendant サービスを常に実行しておく必要があります。

この警告を修正するには

  1. [サービス] Microsoft 管理コンソール (MMC) スナップインを開きます。

  2. 右側のウィンドウで、下にスクロールして [Microsoft Exchange System Attendant] をダブルクリックします。[Microsoft Exchange System Attendant のプロパティ] ダイアログ ボックスが表示されます。

  3. [スタートアップの種類] ボックスの一覧から [自動] をクリックします。

  4. [開始] をクリックしてシステム アテンダント サービスを開始します。

  5. [OK] をクリックして変更を保存し、[Microsoft Exchange System Attendant のプロパティ] ダイアログ ボックスを閉じます。

  6. サービス スナップインを閉じます。

システム アテンダント サービスの無効化と Exchange Server のセキュリティ保護の詳細については、「Securing Exchange 2000 Servers Based on Role」(http://go.microsoft.com/fwlink/?linkid=35585) を参照してください (このサイトは英語の場合があります)。


Exchmem ヒープがパフォーマンスの問題を示している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、MSExchangeIS パフォーマンス オブジェクトの下にある Exchmem Heap パフォーマンス カウンタを分析し、Exchange サーバーのパフォーマンスが低下しているかどうかを判断します。Exchange Server アナライザ ツールは Exchmem カウンタについて次のような報告を行います。

  • Exchmem: Number of heaps with memory errors の値が 0 より大きい場合は警告を報告します。この値が 5 を超えている場合はエラーを報告します。

  • Exchmem: Number of memory errors の値が 500 より大きい場合はエラーを報告します。

  • Exchmem: Number Additional Heaps の値が 3 より大きい場合はエラーを報告します。

Store.exe プロセスは、独自のヒープ割り当て機構および構造を使用します。これらは、Exchmem と呼ばれます。起動時に、Store.exe プロセスはいくつかの Exchmem ヒープを作成します。Store.exe は、現在存在しているヒープがすべて使用されているか、割り当てのために十分な連続メモリを使用できないほど断片化されている場合のみ、ヒープの数を増やします。

メモリの使用に関する問題、または内部の断片化 (Exchange ストアの仮想メモリ領域内に存在する Exchmem ヒープの断片化) が存在する場合、Store.exe プロセスは新しい Exchmem ヒープを作成します。

一般に、Store.exe プロセスが追加ヒープを繰り返し作成する必要がある場合は、Exchange ストアの仮想メモリ全体が断片化しているか、または使い果たされています。上記のカウンタを追跡すると、Exchmem ヒープが問題の原因なのか、あるいはヒープの断片化によってパフォーマンスが低下しているのかを判断できます。

この警告またはエラーを修正するには

  • 最新の Exchange ストア更新プログラムをダウンロードしてインストールします。

    • 最新の Exchange Server 2003 のダウンロードについては、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

    • 最新の Exchange 2000 Server のダウンロードについては、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。

  • Store.exe プロセスで実行されているすべてのアプリケーションについて、最新の更新プログラムをダウンロードしてインストールします。Store.exe プロセスで実行されているサードパーティ製のアプリケーションが、ヒープの断片化を引き起こす場合もあります。

  • 問題が発生しているサーバーからユーザー メールボックスを別のサーバーに移動し、サーバーの負荷を低減することを検討します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

  • 問題の原因を特定できるまで、必要に応じて再起動を行い、メモリをリセットします。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Windows の System32 フォルダに EXCHMEM.DLL が存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、\Windows\System32\Exchmem.dll の Version キーを読み取れるかどうかを判断します。この Version キーを読み取れる場合は、Exchmem.dll が System32 フォルダにあります。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6" が含まれている場合、コンピュータでは Exchange 2000 Server または Exchange Server 2003 が実行されています。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • System32 フォルダに Exchmem.dll が存在する。

  • コンピュータが Exchange 2000 Server または Exchange Server 2003 を実行している。

通常、1 つの Exchange サーバー上に Exchmem.dll のコピーが 2 つ存在することはありません。ただし、インプレース アップグレードを使用して製品の前のリリースからアップグレードすると、2 つ目の Exchmem.dll ファイルが追加されることがあります。このファイルのバージョンが 2 つ存在すると、Service Pack のインストール時にセットアップに失敗する可能性があります。この問題を防止するには、\Windows\System32 フォルダにある Exchmem.dll ファイルの名前を変更するか、削除することをお勧めします。

2 番目のバージョンの Exchmem.dll の名前を変更するか削除するには、次の操作を行います。

  1. すべての Exchange サービスを停止します。

  2. \Windows\System32 フォルダにある Exchmem.dll ファイルの名前を変更するか、削除します。

  3. すべての Exchange サービスを再開します。


致命的なエラーの検出
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールでは、分析を実行するために、次に示すようなさまざまな特定のリソースへのアクセスが試行されます。

  • Microsoft Active Directory® ディレクトリ サービス

  • Exchange Server メッセージ追跡センター

  • Microsoft Windows® レジストリ

  • Microsoft Windows® Management Instrumentation (WMI)

  • インターネット インフォメーション サービス (IIS) メタベース

Exchange Server アナライザから、必要な 1 つまたは複数のリソースにアクセスできない場合、Exchange Server アナライザはエラーを表示します。

このエラーは、1 つまたは複数の基本的なこれらのリソースにアクセスできないため、追加の分析は不可能であることを示します。

このエラーに対処するには、Exchange Server アナライザから提供される、リソース固有のエラーに対する指示およびリンクを確認します。


サーバーで FCL ログが有効になっていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-20

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて、serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server Version 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータは Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Exchange Server 2003 を実行しています。

また Exchange Server アナライザは、次のレジストリ エントリに Disable Call Tracing サブキーが存在するかどうかを問い合わせるクエリを実行し、Exchange サーバーで Microsoft Exchange 関数呼び出しログ (FCL) 機能が有効になっているかどうか判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Exchange Server では、Microsoft Exchange Information Store サービス (Store.exe) が実行する内部呼び出しのパフォーマンスをトレースできます。FCL を使用することで、パフォーマンス上の問題の根本原因となっている可能性のあるコンポーネントおよび関数呼び出しを切り離すことができます。

Microsoft Exchange Information Store サービスの FCL 機能は、次のコンポーネントの関連する呼び出しを記録します。

  • ローカル セキュリティ認証サーバー (Lsass.exe)

  • DSAccess

  • Extensible Storage Engine (ESE)

  • IMAIL

  • Virusscan

FCL は、Exchange Server でのシャットダウンの問題や、Exchange Information Store サービス (Store.exe) のパフォーマンスの低下や応答なしの状況などの問題シナリオに関するデータを収集する、オーバーヘッドの低いログです。

FCL を有効に設定すると、関数呼び出しのデータが自動的にログに記録されます。運用サーバーのユーザー ダンプ ファイルの取得やデバッガの使用などの特別な構成やユーザーの介入は不要です。

FCL は、Exchange Server 2003 では既定で有効に設定されていますが、Exchange Server 2000 では明確に有効に設定する必要があります。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • サーバーで Exchange 2000 Server が実行されており、Disable Call Tracing サブキーが存在しないか、または Disable Call Tracing サブキーが存在し、このキーに 0 以外の値が設定されている。

  • サーバーで Exchange Server 2003 が実行されており、Disable Call Tracing サブキーが存在し、このキーに 0 以外の値が設定されている。

このベスト プラクティス メッセージが表示された場合、FCL が無効になっていることを表します。

推奨されるベスト プラクティスは、すべての Exchange サーバーで FCL を有効に設定することです。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Exchange 2000 Server で関数呼び出しログを有効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Disable Call Tracing

  3. 右側のペインで、Disable Call Tracing をダブルクリックします。Disable Call Tracing サブキーが存在しない場合は、新しい DWORD 値としてこれを作成します。

  4. Disable Call Tracing サブキーの値を 0 に設定します。
注 :
Exchange 2000 Server では FCL は既定でオフに設定され、この値が 1 に設定されています。
  1. レジストリ エディタを終了します。

  2. Exchange Information Store サービスを再起動して、これらの変更を有効にします。ｓ

 Exchange Server 2003 で関数呼び出しログを有効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Disable Call Tracing.

  3. 右側のペインで、Disable Call Tracing をダブルクリックします。

  4. Disable Call Tracing サブキーの値を 0 に設定します。
注 :
Exchange Server 2003 では FCL は既定でオンに設定されますが、この場合、Disable Call Tracing サブキーが作成され、0 以外の値に設定されています。
  1. レジストリ エディタを終了します。

  2. Exchange Information Store サービスを再起動して、これらの変更を有効にします。

レジストリを編集する場合、およびレジストリの編集方法の詳細が必要な場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ページ テーブル エントリの空き容量が "致命的" のしきい値に達した
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_PerfOS_Memory Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、FreeSystemPageTableEntries オブジェクトの現在の値を判断します。FreeSystemPageTableEntries の値が 5000 以下であることが検出されると、エラーが表示されます。

Microsoft Windows Server™ 2003 と Windows 2000 Server は、搭載されている物理 RAM の量とは無関係に、4 GB までのメモリ アドレス スペースのアドレスを直接指定することができます。プロセスの観点からは、仮想アドレスのどの要素も物理メモリの特定のバイトを参照することになります。各仮想アドレスを対応する物理アドレスに変換またはマッピングする処理は、仮想メモリ マネージャ (VMM) とプロセッサ メモリ管理ユニット (MMU) によって行われます。VMM は、RAM を固定サイズのページ フレームに分割し、これらのページ フレームに関する情報を格納するシステム ページ テーブル エントリ (PTE) を作成してマッピングを実行します。システム PTE は小容量のカーネル モードのメモリ バッファで、ディスク I/O サブシステムとネットワークとの通信を行うために使用されます。それぞれの PTE はページ フレームを表し、VMM がページを見つけるための必要な情報を含んでいます。

4 KB のページ サイズを使用する x86 ベースのシステムでは、2 GB のアドレス スペースをマッピングするために必要な PTE の最大数は 524,288 (2 GB ÷ 4 KB) です。/3GB スイッチを使用する同様のシステムでは、3 GB のアドレス スペースをマッピングするために必要な PTE の数は 786,432 (3 GB ÷ 4 KB) です。一般的なシステムでは、この領域は以下のように使用されます。

  • 一般的な用途のために、最大で 50,000 の PTE (約 195 MB のアドレス スペース) が予約されます。

  • 他の PTE は、システム キャッシュ、ハイパースペース、ページ プール、非ページ プール、クラッシュ ダンプ領域、その他のマッピングに使用されます。

この PTE プールのサイズは、システム内の物理メモリの容量に基づいて、システムの起動時に自動的に決定されます。このプールは、ページ プールと非ページ プール (非ページ プールもシステム内の物理メモリの容量と共に増加します) の間に割り当てられます。

システム PTE プールは、頻繁に使用され、断片化が激しくなることがあります。これにより、ドライバが読み込めなくなる事態が生じることがあります。また、システム PTE プールがすべて使い果たされると、システムの他の部分のパフォーマンスが低下し、スレッドが作成されなくなる、システムが停止する、さらにはシステムがクラッシュするなどの問題が発生する可能性があります。

Exchange Server コンピュータが正しく動作するためには、使用可能なシステム PTE が常に少なくとも 8,000 必要です。空いているシステム PTE の数が 8,000 未満であるが、5,000 より多い場合は、「ページ テーブル エントリの空き容量が "警告" のしきい値に達した」の説明にある警告が表示されます。空いているシステム PTE の数が 5,000 未満に低下すると、このエラーが表示されます。

この問題を解決するには、次の手順を使用して、Exchange Server コンピュータのオペレーティング システムに対して適切な SystemPages レジストリ値を設定します。1 GB 以上の RAM を備えた Windows Server 2003 上で Exchange Server 2003 Service Pack 1 (SP1) を実行している場合は、SystemPages レジストリ キーを 0 に設定することをお勧めします。この推奨事項は、Windows 2000 Server の場合とは異なります。Windows 2000 Server では、SystemPages の値を 10 進数の 31000 に設定するよう推奨されています。

次に説明する手順を実行した後で、空いているシステム PTE の数を監視する必要があります。Windows システム モニタ (パフォーマンス モニタとも呼ばれます) で Memory オブジェクトの Free System Page Table Entries カウンタを監視すると、システム PTE の数を監視できます。レジストリの変更を行ってもまだ、空いているシステム PTE の数が少ない場合は、Exchange Server コンピュータが最適に構成されていることを確認するために次の点を調べます。

  • ドライバ システム PTE の数が不足する最も一般的な原因の 1 つは、ドライバの誤動作です。ハードウェアの製造元に確認し、すべてのハードウェアで最新のドライバを使用していることを確認してください。より基本的なドライバにダウングレードできる場合もあります。たとえば、Exchange Server などのサーバー ベースのアプリケーションを実行しているコンピュータには、通常はすべての機能を備えた高機能のビデオ ドライバは必要ありません。多くの場合、より基本的なドライバで十分です。高機能のビデオ ドライバから基本的なビデオ ドライバに切り替えると、空いているシステム PTE の数が増加するはずです。

  • システム構成 Windows Server 2003 システムに 1 GB 以上の物理メモリが搭載されている場合は、Microsoft サポート技術情報の文書番号 823440「Windows Server 2003 ベースのシステムに Exchange Server 2003 をインストールするとき、/3GB スイッチを使用する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) と文書番号 810371「[XADM] Windows 2003 Server ベースの Exchange Server で /Userva スイッチを使用する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371) で説明されているように、/3GB スイッチと /USERVA=3030 スイッチを使用して Boot.ini ファイルが適切に構成されていることを確認する必要があります。

  • イベント ログ Exchange Server のアプリケーション イベント ログを調べ、エラーと警告、特に MSExchangeIS イベント 9582 (エラーと警告)、9665 (警告)、および 12880 (エラー) があるかどうかを調べます。イベント 9665 も、SystemPages が最適なパフォーマンスが得られるように構成されていないことを示す場合があります。これらのイベントの詳細については、サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Windows 2000 Server を実行しているコンピュータでこのエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに、値 として10進数の 31000 (31000 は 16 進数の7918 の 10 進数表記です。Regedit.exe は既定では 16進数の値に設定されます) を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

最初のリリースの Windows Server 2003 を実行しているコンピュータでこのエラーを修正するには

  • Microsoft サポート技術情報の文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な 空き システム ページ テーブル エントリを正確に示しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067) を参照して、実際の Free System Page Table Entries の数を判断します。

Windows Server 2003 SP1 を実行しているコンピュータでこのエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

  6. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  7. [詳細設定] をクリックします。

  8. [起動と回復] 領域で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  9. [起動システム] 領域で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  10. [オペレーティング システム] セクションを確認します。

    1. /3GB スイッチはあるが /USERVA=3030 スイッチがない場合は、起動行に /USERVA=3030 スイッチを追加して、これが /3GB /USERVA=3030 として構成されるようにします。

    2. /3GB /USERVA=3030 スイッチが既に構成されている場合は、/USERVA スイッチの値を /USERVA=2970 に変更します。

  11. 変更を保存して、メモ帳を閉じます。

  12. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のためのメモリ最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な 空き システム ページ テーブル エントリを正確に示しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067)

  • 文書番号 325044「[HOW TO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 文書番号 823150「How to gather data to troubleshoot Exchange Server 2003 virtual memory issues」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823150) (このサイトは英語の場合があります)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


ページ テーブル エントリの空き容量が "警告" のしきい値に達した
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_PerfOS_Memory Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、FreeSystemPageTableEntries オブジェクトの現在の値を判断します。FreeSystemPageTableEntries の値が 5000 より大きく 8000 以下である場合は、警告が表示されます。

Microsoft Windows Server™ 2003 と Windows 2000 Server は、搭載されている物理 RAM の量とは無関係に、4 GB までのメモリ アドレス スペースのアドレスを直接指定することができます。プロセスの観点からは、仮想アドレスのどの要素も物理メモリの特定のバイトを参照することになります。各仮想アドレスを対応する物理アドレスに変換またはマッピングする処理は、仮想メモリ マネージャ (VMM) とプロセッサ メモリ管理ユニット (MMU) によって行われます。VMM は、RAM を固定サイズのページ フレームに分割し、これらのページ フレームに関する情報を格納するシステム ページ テーブル エントリ (PTE) を作成してマッピングを実行します。システム PTE は小容量のカーネル モードのメモリ バッファで、ディスク I/O サブシステムとネットワークとの通信を行うために使用されます。それぞれの PTE はページ フレームを表し、VMM がページを見つけるための必要な情報を含んでいます。

4 KB のページ サイズを使用する x86 ベースのシステムでは、2 GB のアドレス スペースをマッピングするために必要な PTE の最大数は 524,288 (2 GB ÷ 4 KB) です。/3GB スイッチを使用する同様のシステムでは、3 GB のアドレス スペースをマッピングするために必要な PTE の数は 786,432 (3 GB ÷ 4 KB) です。一般的なシステムでは、この領域は以下のように使用されます。

  • 一般的な用途のために、最大で 50,000 の PTE (約 195 MB のアドレス スペース) が予約されます。

  • 他の PTE は、システム キャッシュ、ハイパースペース、ページ プール、非ページ プール、クラッシュ ダンプ領域、その他のマッピングに使用されます。

この PTE プールのサイズは、システム内の物理メモリの容量に基づいて、システムの起動時に自動的に決定されます。このプールは、ページ プールと非ページ プール (非ページ プールもシステム内の物理メモリの容量と共に増加します) の間に割り当てられます。

システム PTE プールは、頻繁に使用され、断片化が激しくなることがあります。これにより、ドライバが読み込めなくなる事態が生じることがあります。また、システム PTE プールがすべて使い果たされると、システムの他の部分のパフォーマンスが低下し、スレッドが作成されなくなる、システムが停止する、さらにはシステムがクラッシュするなどの問題が発生する可能性があります。

Exchange Server コンピュータが正しく動作するためには、使用可能なシステム PTE が常に少なくとも 8,000 必要です。空いているシステム PTE の数が 5,000 より少なくなると、「ページ テーブル エントリの空き容量が "致命的" のしきい値に達した」で説明されているエラーが表示されます。空いているシステム PTE の数が 8,000 未満になっても、5,000 より多く残っている場合は、この警告が表示されます。

この問題を解決するには、次の手順を使用して、Exchange Server コンピュータのオペレーティング システムに対して適切な SystemPages レジストリ値を設定します。1 GB 以上の RAM を備えた Windows Server 2003 上で Exchange Server 2003 Service Pack 1 (SP1) を実行している場合は、SystemPages レジストリ キーを 0 に設定することをお勧めします。この推奨事項は、Windows 2000 Server の場合とは異なります。Windows 2000 Server では、SystemPages の値を 10 進数の 31,000 に設定するよう推奨されています。

次に説明する手順を実行した後で、空いているシステム PTE の数を監視します。Windows システム モニタ (パフォーマンス モニタとも呼ばれます) で Memory オブジェクトの Free System Page Table Entries カウンタを監視すると、システム PTE の数を監視できます。次に説明するレジストリの変更を行った後でも依然として空いているシステム PTE の数が少ない場合は、Exchange Server コンピュータが最適に構成されていることを確認するために次の点を調べます。

  • ドライバ システム PTE の数が不足する最も一般的な原因の 1 つは、ドライバの誤動作です。ハードウェアの製造元に連絡し、すべてのハードウェアで最新のドライバを使用していることを確認してください。より基本的なドライバにダウングレードできる場合もあります。たとえば、Exchange Server などのサーバー ベースのアプリケーションを実行しているコンピュータには、通常はすべての機能を備えた高機能のビデオ ドライバは必要ありません。多くの場合、より基本的なドライバで十分です。高機能のビデオ ドライバから基本的なビデオ ドライバに切り替えると、空いているシステム PTE の数が増加するはずです。

  • システム構成 Windows Server 2003 システムに 1 GB 以上の物理メモリが搭載されている場合は、Microsoft サポート技術情報の文書番号 823440「Windows Server 2003 ベースのシステムに Exchange Server 2003 をインストールするとき、/3GB スイッチを使用する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) と文書番号 810371「[XADM] Windows 2003 Server ベースの Exchange Server で /Userva スイッチを使用する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371) で説明されているように、/3GB スイッチと /USERVA=3030 スイッチを使用して Boot.ini ファイルが適切に構成されていることを確認する必要があります。

  • イベント ログ Exchange Server のアプリケーション イベント ログを調べ、エラーと警告、特に MSExchangeIS イベント 9582 (エラーと警告)、9665 (警告)、および 12880 (エラー) があるかどうかを調べます。イベント 9665 も、SystemPages が最適なパフォーマンスが得られるように構成されていないことを示す場合があります。これらのイベントの詳細については、サポート技術情報の文書番号 324044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Windows 2000 Server を実行しているコンピュータでこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに、値 として10進数の 31000 (31000 は 16 進数の7918 の 10 進数表記です。Regedit.exe は既定では 16進数の値に設定されます) を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

最初のリリースの Windows Server 2003 を実行しているコンピュータでこの警告を修正するには

  • Microsoft サポート技術情報の文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な 空き システム ページ テーブル エントリを正確に示しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067) を参照して、実際の Free System Page Table Entries の数を判断します。

Windows Server 2003 SP1 を実行しているコンピュータでこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

  6. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  7. [詳細設定] をクリックします。

  8. [起動と回復] 領域で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  9. [起動システム] 領域で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  10. [オペレーティング システム] セクションを確認します。

    1. /3GB スイッチはあるが /USERVA=3030 スイッチがない場合は、起動行に /USERVA=3030 スイッチを追加して、これが /3GB /USERVA=3030 として構成されるようにします。

    2. /3GB /USERVA=3030 スイッチが既に構成されている場合は、/USERVA スイッチの値を /USERVA=2970 に変更します。

  11. 変更を保存して、メモ帳を閉じます。

  12. [OK] を 2 回クリックして、開いているダイアログ ボックスを閉じ、コンピュータを再起動してこの変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のためのメモリ最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な 空き システム ページ テーブル エントリを正確に示しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067)

  • 文書番号 325044「[HOW TO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 文書番号 823150「How to gather data to troubleshoot Exchange Server 2003 virtual memory issues」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823150) (このサイトは英語の場合があります)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


フロントエンド サーバーでサイト レプリケーション サービスを実行している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Exchange Server Microsoft WMI (Windows® Management Instrumentation) オブジェクト (Exchange_Server クラス) に対してクエリを実行し、サーバーの IsFrontEndServer の値を判断します。この値が True の場合は、Exchange サーバーがフロントエンド サーバーとして機能しています。また、Exchange Server アナライザは MSExchangeSRS WMI オブジェクト (Win32_Service クラス) に対してもクエリを実行し、そのオブジェクトの Started プロパティの値を判断します。この値が True の場合は、このサーバー上でサイト レプリケーション サービスが実行されています。

Exchange サーバーがフロントエンド サーバーとして指定され、同時にサイト レプリケーション サービスの実行中のインスタンスも存在する場合は、警告が表示されます。

トポロジ内に Exchange Server Version 5.5 と、Exchange 2000 Server または Exchange Server 2003 が含まれていると、Exchange ではサイト レプリケーション サービスが使用されます。このサービスを使用すると、新しいバージョンの Exchange は、サーバー構成情報を Exchange Server 5.5 ディレクトリと互換性のある形式で Exchange Server 5.5 サーバーにレプリケートできます。また、Exchange Server 5.5 ディレクトリからレプリケートされた構成情報を、Active Directory® ディレクトリ サービスに格納できるように正しく処理することもできます。トポロジがフロントエンド サーバーとバックエンド サーバーを使用するように構成されている場合は、サイト レプリケーション サービスをバックエンド サーバーでのみ実行するようにする必要があります。Exchange 2000 Server Service Pack 2 の時点では、サイト レプリケーション サービスはフロントエンド サーバーでは正常に機能せず、問題が発生する可能性があります。

この問題を修正するには、フロントエンド サーバーをバックエンド サーバーに変換し、新しいフロントエンド サーバーを構成します。サーバーからサイト レプリケーション サービスを削除することはお勧めできません。

このエラーを修正するには

  1. 新しいフロントエンド サーバーを構成します。

  2. 問題のあるフロントエンド サーバーで、Exchange システム マネージャの [サーバー] にある問題のサーバーを右クリックし、[プロパティ] をクリックします。

  3. [このサーバーをフロントエンド サーバーにする] チェックボックスをオフにします。

フロントエンド サーバーとサイト レプリケーション サービスの詳細については、Microsoft サポート技術情報の文書番号 313646「[XADM] Exchange 2000 Server SP2 へのアップグレード後にフロントエンド サーバー上でサービスが無効になる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313646) を参照してください。


bin フォルダに GAPI32.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


system32 フォルダに GAPI32.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


GlobalFlag が設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、GlobalFlag エントリの値を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MAD.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\INETINFO.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\EMSMTA.EXE

GlobalFlag の値が存在しており、0 または NULL 以外の値で構成されていることが検出されると、警告が表示されます。

GlobalFlag レジストリ値の設定は、特定のプロセスに対して有効にされていたデバッグ オプションを判断するビットマスクです。この場合、Exchange Server アナライザは特に、さまざまな Exchange コンポーネントに対していずれかのデバッグ オプションが有効にされていたかどうかを調査しています。

  • STORE.EXE (インフォメーション ストア プロセス)

  • MAD.EXE (システム アテンダント プロセス)

  • INETINFO.EXE (IIS Admin および親プロセス)

  • EMSMTA.EXE (メッセージ転送エージェント プロセス)

Microsoft 製品サポート サービスの支援を受けて積極的に問題のデバッグやトレースに参加する場合を除き、常に GlobalFlag の値を 0 に設定するか、完全に削除することをお勧めします。どちらの方法を使用しても結果は同じです。

既定では、GlobalFlag レジストリ値は存在しておらず、STORE.EXE プロセス (または任意の他のプロセス) をデバッグする必要がある場合に、手動で追加する必要があります。そのために、Microsoft Windows Server™ 2003 サポート ツールに含まれている Gflags ツールを使用することができます。このツールは、Windows CD の \Support フォルダに収録されています。または、値を手動で 0 に設定するか、レジストリ エディタを使用して GlobalFlag 値を完全に削除することもできます。どちらの手順についても、この文書で説明します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Gflags を使用してこのエラーを修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスで「GFlags」を実行します。Global Flags のユーザー インターフェイスが表示されます。

  2. [Image File Name] ボックスに、「STORE.EXE」と入力します。

  3. [Image File Options] を選択します。

  4. すべてのチェック ボックスをオフにし、[Apply] をクリックします。

  5. ここで挙げた各 Exchange プロセスに対して、手順 2. ～ 4. を繰り返します。

  6. [OK] をクリックして GFlags ツールを終了し、影響を受けるサービスを再開して変更を有効にします。

レジストリ エディタを使用してこのエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

  3. GlobalFlag という名前の値を削除します。

  4. ここで挙げた各 Exchange プロセスに対して、手順 2. と 3. を繰り返します。

  5. レジストリ エディタを終了し、影響を受けるサービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ACL アップグレードの失敗が大量に発生している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ACLUpgradefailures キーの現在の値を判断します。ACLUpgradefailures キーは、MSExchangeIS パフォーマンス オブジェクトのACL Upgrade: failures パフォーマンス カウンタを表します。

Exchange Server アナライザによって ACLUpgradefailures キーの値が 500 より大きいことが検出されると、警告が表示されます。

この警告は、Exchange サーバーでアクセス制御リスト (ACL) のアップグレードの失敗が多数報告されていることを示します。ACL アップグレードの失敗が過度に発生すると、インフォメーション ストア プロセス (store.exe) がランダムに停止するなど、深刻なパフォーマンスの問題が発生する可能性があります。

ACL アップグレードの失敗はさまざまな理由で発生する可能性があり、次の条件を満たすときに発生することがわかっています。

  • 混在モードの Exchange 組織で、Active Directory コネクタ (ADC) サーバーを実装する前に、Exchange Server Version 5.5 の整合性調整機能が実行されなかった。Exchange Server 5.5 の整合性調整機能を実行すると、切り離された ACL が削除されます。

  • Active Directory レプリケーションが正常に機能していない。

  • Active Directory コネクタのレプリケーションが、Exchange Server 5.5 から Active Directory にアカウントを正しくレプリケートしていない。

  • ユーザー アカウントの移行が正しく行われなかった。

この警告を修正するには

  1. Microsoft サポート技術情報の文書番号 812963「Ignore Zombie Users レジストリ キーの使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812963) を参照してください。

  2. Ignore Zombie Users レジストリ キーを使用することによる影響を理解した後、ご自身の判断でキーを追加してください。

  3. Exchange Server アナライザを実行するか、ACL Upgrade: failures パフォーマンス カウンタを監視して、ACL アップグレードの失敗が過度に発生するかどうかを確認します。


Exmon ユーザーのアクティビティが高い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、Exchange Server User Monitor (ExMon) ツールを使用して、ユーザーまたはプロセス (あるいは、ユーザーまたはプロセスのグループ) が現在のサーバー負荷のうちの過度に大きな割合を占めているかどうかを判断します。

ExMon は、以下のようないくつかのシナリオを評価します。

  • クライアントの制限

  • 大量のリモート プロシージャ コール (RPC) 操作

  • 大量の RPC 同期操作

  • 多数のクライアントのオンライン操作

  • ユーザー ビューの操作

以下のセクションでは、各シナリオについて説明し、それぞれに推奨される処理を示します。

クライアントの制限

このシナリオでは、ExMon の RPC データは、クライアント コンピュータの制限がこのサーバーに高い負荷を引き起こしていることを示しています。MAPI に関して言えば、制限とは Restrict と呼ばれる MAPI 操作を指します。この操作は、特定の条件に一致するアイテムを選択するために使用されます。Restrict 操作は、Exchange に対してフォルダまたはフォルダのセットに対するビュー (事実上、条件が関連付けられているデータベース テーブル) の作成を要求するプロセスの一部です。フォルダまたはフォルダのセットのビューが一致する制限を既に有している場合、Exchange はユーザーの要求を満たすために既存のビューを使用します。ビューが一致する制限を持っていない場合、Exchange は新しいビューを作成します。ビューの作成には、既存のビューを使用するよりコストがかかります。

多数のメールボックスの移動後は、少しの間クライアントの制限にかかるコストが高くなります。move-mailbox 操作によって、サーバーはフォルダのインデックスを再構築します。したがって、クライアントが新しいサーバーで最初にフォルダを参照するときにはすべての制限を新たに作成する必要があるため、パフォーマンスが低下することがあります。メールボックスを最近移動していない場合は、以下のことを調べてください。

  • クライアント コンピュータに別の MAPI アプリケーションがインストールされていない。Microsoft Office Outlook® アドインや他の MAPI アプリケーションが原因で、多数の制限が作成されることがよくあります。

  • 組織全体でメールボックスのサイズが設定され、制限が適切に設定されている。

メールボックスのサイズとアイテム数の詳細については、Microsoft Exchange Team Blog の推奨されるメールボックス サイズの制限値についての情報 (http://go.microsoft.com/fwlink/?linkid=55097) を参照してください (このサイトは英語の場合があります)。

大量の RPC 操作

大量の RPC 操作の例には、1 つの操作で数百や数千のアイテムに対してプロパティ (つまり、読み取りフラグ) の移動、削除、または設定を行う操作などがあります。このような種類の操作によって、少しの間サーバーのパフォーマンスが低下することがあります。大量の RPC 操作を頻繁に行い、サーバーのディスクまたはプロセッサがボトルネックとなっている場合は、同じサーバーを使用する他のユーザーの Outlook のパフォーマンスが低下します。

このエラーを修正するには

  1. メールボックスの制限が設定されていることを確認します。

  2. ユーザーに対して、アイテムを .pst ファイルにアーカイブすることを推奨します。

    注 :
    一般的なベスト プラクティスとして、使用頻度の高いフォルダ内のアイテム数は 5,000 未満にすることをお勧めします。

大量の RPC 同期操作

大量の RPC 同期操作は、多くのユーザーが現在アイテムの同期を行っていることを示します。その結果、サーバーの負荷が増加しています。

このエラーを修正するには

  • Exchange サーバーが、Exchange キャッシュ モードで Outlook を実行しているクライアント コンピュータの数に応じて拡張されていることを確認します。詳細については、「Introduction to Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  • Exchange キャッシュ モードのクライアント要求を遅くすると、大量の RPC 同期操作がパフォーマンスの問題になるのを防止できる可能性があります。詳細については、Microsoft サポート技術情報の文書番号 818484「レジストリが値で、Outlook クライアント同期を設定し、そして監視するのに使用できることをカウンタする。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=818484) を参照してください。

多数のクライアントのオンライン操作

Exchange では、ユーザー間に分散される高い負荷によって、パフォーマンスの問題が急増することがあります。この状況は、組織の成長に対して十分な計画が立てられていないために発生したものである可能性があります。組織の拡大や縮小を行う際に Microsoft のベスト プラクティスに従っていても、多数のクライアントのオンライン操作によってパフォーマンスが低下する場合、ユーザーがサードパーティ製の MAPI アプリケーションや Outlook プラグインを実行していることが原因になっている場合があります。

ユーザー ビューの操作

ExMon の RPC データは、ユーザーが新しいビューを構築しているために、サーバーに高い負荷が発生していることを示しています。このシナリオでは、単一のユーザー アカウントが RPC の CPU 使用の大きな割合を占めています。

この問題を調査するには、以下のシナリオを考慮します。

  • ユーザーが、多くのアイテムが含まれるフォルダに対して操作を実行している可能性があります。この問題を修正するには、ユーザーに対して、1 つのフォルダに置くアイテムの数を減らすように勧めます。一般的なベスト プラクティスとして、フォルダ内のアイテムの数は 2,000 未満にすることをお勧めします。

  • ユーザーが実行しているアプリケーションが適切に作成されていないために、過剰な負荷が発生している可能性があります。この問題を修正するには、そのアプリケーションを削除します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • メールボックスのサイズとアイテム数の詳細については、Microsoft Exchange Team Blog の推奨されるメールボックス サイズの制限値についての情報 (http://go.microsoft.com/fwlink/?linkid=55097) を参照してください (このサイトは英語の場合があります)。

  • メールボックスの制限の詳細については、Microsoft Exchange Team blog のエントリ「Putting the Restrictions on Restrictions」(http://go.microsoft.com/fwlink/?LinkId=55098) を参照してください (このサイトは英語の場合があります)。

  • ExMon の詳細については、ExMon のダウンロード Web サイト (http://go.microsoft.com/fwlink/?LinkId=54983) を参照してください (このサイトは英語の場合があります)。


IIS が 64 ビットのコンピュータに 32 ビットのプロセスを作成しようとしている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-05-03

Microsoft Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースに対してクエリを実行し、Exchange Server 2007 を実行しているすべての 64 ビット Windows Server 2003 Service Pack 1 (SP1) サーバーに関する w3svc/AppPools/Enable32BitAppOnWin64 メタベース プロパティの値を確認して、IIS が 32 ビット ワーカー プロセスを作成するように構成されているかどうかを判断します。

値が 1 (True) の場合、IIS は 32 ビット ワーカー プロセスを作成するように構成されています。値が 0 (False) の場合、IIS は 64 ビット ワーカー プロセスを作成するように構成されています。

w3svc/AppPools/Enable32BitAppOnWin64 メタベース プロパティの値が 1 (True) に設定されていることが検出されると、エラーが表示されます。このエラーは、Exchange 2007 を実行している 64 ビット Windows サーバー上で、IIS が 32 ビット ワーカー プロセスを作成するように構成されていることを示しています。この構成では、Exchange 2007 の仮想ディレクトリが正常に機能しなくなります。

このエラーに対処するには、Exchange 2007 を実行している 64 ビット Windows Server 2003 (SP1) サーバー上で、IIS が 64 ビット ワーカー プロセスを作成するように構成します。

IIS を 64 ビット モードに切り替えるには

  1. コマンド プロンプトを開きます。

  2. 次のように入力します。

    cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

  3. Enter キーを押します。

64 ビット Windows Server 2003 SP1 サーバー上で IIS 6.0 の 32 ビット ワーカー プロセスを実行する場合の詳細については、Microsoft サポート技術情報の文書番号 895976「Windows Server 2003 SP1 は、32 ビット IIS 6.0 での Web アプリケーションの WOW64 互換性を有効にします。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=895976) を参照してください。


カーネル メモリの向上
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、システム メモリ レベルにテストを実行して、許容範囲内であることを確認します。Exchange Server アナライザによってパフォーマンス モニタ (Perfmon) のカーネル メモリ カウンタが適切なレベルを下回っていることが検出されると、トラブルシューティングのメッセージが表示されます。

Microsoft Windows® カーネル メモリは、ページ プール メモリ、非ページ プール メモリ、およびシステム ページ テーブル エントリを含む複数のメモリ構造から構成されています。これらのメモリ構造は、カーネル メモリとも呼ばれ、Exchange などのアプリケーションの環境を提供するためにオペレーティング システムによって使用されます。正常な Exchange の展開を保持するには、カーネル メモリの監視を確実に行ってください。

カーネル メモリの最適化は、複雑な作業になる場合があります。トラブルシューティング情報を含むカーネル メモリの使用の詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。サーバー リソースを解放するための考慮事項 1 つは、サーバー上のユーザーのメールボックスの負荷を確認することです。ユーザーのメールボックスを別のサーバーに移動してサーバーの負荷を減らすことを検討し、問題が解決されるかどうかを確認します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

Exchange Server パフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47576) を参照してください (このサイトは英語の場合があります)。

ユーザーのメールボックスを移動してサーバーの負荷を減らすための詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


ユーザー メモリの強化
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-28

Microsoft® Exchange Server アナライザ ツールは、ユーザー メモリのパフォーマンス カウンタが Exchange サーバーの正常な状態と見なされるしきい値を超えていると判断しました。Exchange Server アナライザは、Memory パフォーマンス オブジェクトの下にある Available Mbytes パフォーマンス カウンタと Memory Pages/sec カウンタに対してクエリを実行します。サーバーのメモリが不足しているか、ページングが大量に発生している場合、メモリがボトルネックになっています。

Available MBytes パフォーマンス カウンタは、プロセスへの割り当てやシステムで使用するためにすぐに利用可能な物理メモリの容量 (MB) を示します。利用可能なメモリの容量は、スタンバイ (キャッシュ)、空き、およびゼロページのリストに割り当てられているメモリの合計と等しくなります。

Memory Pages/sec パフォーマンス カウンタは、ハードウェアによるページ フォールトを解決するため、ディスクから読み取られる、またはディスクに書き込まれるページの速度を示します。サーバーがメモリを使用し、空きメモリが少なくなると、オペレーティング システムはプロセスのワーキング セットを小さくし、ページ ファイルを多用するようになります。ディスクの処理にはメモリの処理よりも時間がかかるため、ページ ファイルの使用は全体のパフォーマンスに影響を及ぼします。このカウンタは、システム規模の遅延の原因となるエラーの種類に関する主要なインジケータです。カウンタには、ファイル システム キャッシュでページ フォールトと見なされるために取得されたページも含まれます。通常、これらのページはアプリケーションによって要求されます。このカウンタは、常に 1,000 未満になっている必要があります。

Exchange Server アナライザによって、Available Mbytes パフォーマンス カウンタが利用可能なメモリが 50 MB 未満であることを示しているか、メモリ ページのディスクへの書き込みまたはディスクからの読み取りが毎秒 1,000 ページを超えていることが検出されると、エラーが表示されます。

ユーザー領域のメモリのパフォーマンスを強化する方法については、次の一覧を参照してください。

この問題を修正するには

  1. Microsoft Exchange Server ベスト プラクティス アナライザ ツール (http://go.microsoft.com/fwlink/?LinkId=34705) を使用して、サーバーのメモリ設定が適切に構成されていることを確認します (このサイトは英語の場合があります)。

  2. 不要なソフトウェアを削除します。Exchange で利用可能なメモリ リソースを増やすため、監視機能や、重要でないサービスを実行するサードパーティ製のソフトウェア ツールを削除します。パフォーマンス スナップイン (Perfmon.msc) を使用すると、各アプリケーションが消費しているメモリの量を知ることができます。

  3. サーバーの保守作業は、ピーク時以外の時間帯に行います。保守ツール (Eseutil など) やタスク (メールボックスの管理など) をピーク時に実行すると、Exchange で使用できるメモリが消費されます。ベスト プラクティスとして、これらのツールやタスクはピーク時以外の時間帯または負荷の少ない時間帯に実行することをお勧めします。

  4. 問題が発生しているサーバーからユーザー メールボックスを別のサーバーに移動し、サーバーの負荷を低減することを検討します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

詳細については、以下の Microsoft リソースを参照してください。

  • ユーザーのメールボックスを別のサーバーに移動する

  • 『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)

  • Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) の Exchange Server 2003 におけるメモリ使用の最適化に関するセクション (このサイトは英語の場合があります)

  • 「Microsoft Exchange Server Best Practices Analyzer Tool」(http://go.microsoft.com/fwlink/?LinkId=34705) (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 「Exchange 2003 Memory Configuration change for Windows 2003 (PAE Support)」(http://go.microsoft.com/fwlink/?LinkId=54979) (このサイトは英語の場合があります)

    注 :
    それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。


仮想メモリの向上
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、そのサーバーで仮想メモリの断片化の問題が発生していると判断しました。

32 ビット版の Microsoft Windows® システムには、2 種類のメモリがあります。

  • 物理メモリ システムにインストールされている実際のメモリの容量

  • 仮想メモリ アドレス スペース 仮想化された 4 GB のメモリ スペース

システムに取り付けられている物理メモリの量とは無関係に、仮想アドレス スペースの合計サイズは常に同じ 4 GB です。すべての 32 ビット アプリケーションに当てはまるわけではありませんが、Exchange Server の場合、仮想アドレス スペースは仮想メモリに一致します。これらの用語は同義で使用されます。

通常の動作中、Exchange ストアは繰り返し仮想メモリの割り当て、使用、および割り当ての解除を行います。仮想メモリの割り当て、使用、および割り当て解除が頻繁に行われると、仮想メモリの断片化が発生することがあります。仮想メモリの断片化は、時間が経過すると発生することがあるファイル システムの断片化に似ています。しばらくすると、割り当てられた仮想メモリのセグメントが連続的ではなくなって、パフォーマンスが低下し始めます。ファイル システムの場合、ファイル システムを最適化するアプリケーションを実行できます。ほとんどの場合、最適化はシステムがオンラインでアクセスされている間に実行することが可能です。仮想メモリの断片化の場合、最適化ツールはありません。代わりに、この問題を解決するために、Microsoft Exchange Information Store サービスを停止してから開始するか、システムを再起動する必要があります。

仮想メモリの断片化は、store/inetinfo プロセスを実行しているサードパーティ製のソフトウェアによって引き起こされることがあります。サードパーティ製のアプリケーションに対して最新のドライバが適用されていることを確認してください。再起動後も問題が再発する場合は、サードパーティ製のソフトウェアを無効にするか、ユーザー メールボックスを別のサーバーに移動してサーバー負荷を減らすことを検討し、問題が解消されるかどうかを確認します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Microsoft Exchange Server 2003 および Exchange 2000 Server での仮想メモリの断片化のトラブルシューティングに関する詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。

  • 仮想メモリの使用量を最適化する方法の詳細については、Microsoft サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


Exchange Server 2003 を実行している 1 つ以上のサーバーにインテリジェント メッセージ フィルタがインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、組織内の各 Exchange Server オブジェクトの msExchExchangeServer 属性の値を判断します。Exchange Server アナライザはこのクエリの結果を使用して、組織内にある Exchange Server 2003 を実行しているサーバーの総数を判断します。また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、組織内のすべての Exchange Server 2003 サーバーに Microsoft Exchange インテリジェント メッセージ フィルタがインストールされているかどうかを判断します。Exchange Server 2003 を実行している 1 つ以上のサーバーにインテリジェント メッセージ フィルタがインストールされていないことが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

インテリジェント メッセージ フィルタは、迷惑な商用電子メール (UCE) である可能性が高いメッセージを識別します。標準的な Exchange Server 2003 トポロジでは、インテリジェント メッセージ フィルタは、受信インターネット電子メール メッセージをフィルタするためにゲートウェイ サーバーにインストールされます。インターネット ゲートウェイ サーバーとして Microsoft 以外の電子メール システムを使用する場合は、そのゲートウェイ サーバーから受信インターネット電子メール メッセージを受け付ける Exchange ブリッジヘッド サーバーにインテリジェント メッセージ フィルタをインストールする必要があります。

インテリジェント メッセージ フィルタをインストールするには、ローカルの管理者権限を持ち、かつ Exchange 管理者の役割が割り当てられているグループのメンバであるアカウントを使用します。

詳細については、「Exchange Intelligent Message Filter」(http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください。


最新の ISA Server 2000 更新プログラムが提供されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft ISA (Internet Security and Acceleration) Server 2000 SMTP (Simple Mail Transfer Protocol) Message Screener 機能によって使用される、smtpfltr.dll ファイルのバージョンを判断します。バージョン番号の値が 2004 より小さいことが検出されると、警告が表示されます。

この警告は、最新バージョンの ISA Server 2000 が提供されていることを示します。ISA Server 2000 Service Pack 2 をインストールすることをお勧めします。SMTP Message Screener 機能を実行している場合は、特に Service Pack 2 にアップグレードすることが重要です。以前のバージョンの SMTP Message Screener はボトルネックの原因となり、メッセージの全体的なスループット パフォーマンスが低下します。

この警告を修正するには

  1. ISA Server 2000 Service Pack 2 を、Microsoft ダウンロードセンター (http://go.microsoft.com/fwlink/?linkid=37592) からダウンロードします (このサイトは英語の場合があります)。

  2. Service Pack 2 のリリース ノート (http://go.microsoft.com/fwlink/?linkid=37584) を確認します (このサイトは英語の場合があります)。

  3. リリース ノートの指示に従って、Service Pack 2 をインストールします。

ISA Server 2000 Service Pack 2 など、ISA Server のダウンロードの詳細については、ISA Server 2000 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=18919) を参照してください (このサイトは英語の場合があります)。


ジャーナリング受信者が有効ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-27

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ジャーナリング受信者オブジェクトに対する mailNickname 属性の値が有効であるかどうかを判断します。mailNickname 属性を有効にするには、ニックネームを設定する必要があります。指定されたジャーナリング受信者オブジェクトの mailNickname 属性が有効でない場合、ジャーナリング メッセージはキューに入れられます。また、無効な mailNickname は、ジャーナリング メッセージをメールボックスが無効な受信者オブジェクトにコピーするようにジャーナリングが構成されていることを示す場合があります。Exchange Server アナライザによってジャーナリング受信者オブジェクトの mailNickname 属性の値が有効ではないことが検出されると、エラーが表示されます。

Exchange Server 2003 でこのエラーを修正するには、Active Directory ユーザーとコンピュータおよび Exchange システム マネージャを使用し、必要に応じて以下の操作を実行します。

  • ジャーナリング受信者オブジェクトのメールボックスを有効にする。

  • 新しいユーザーのメールボックスを履歴保持用の受信者として指定する。

Exchange Server 2003 でこのエラーを修正するには、Active Directory ユーザーとコンピュータおよび Exchange システム マネージャを使用し、必要に応じて以下の操作を実行します。

Exchange Server 2003 で履歴保持用の受信者オブジェクトのメールボックスを有効にするには、次の操作を行います。

  1. Active Directory ユーザーとコンピュータ スナップインを起動します。

  2. コンソール ツリーで、ドメインを展開します。

  3. 変更する受信者の親のコンテナに移動します。

  4. 詳細ウィンドウで、変更する受信者を右クリックし、[Exchange タスク] をクリックします。

  5. Exchange タスク ウィザードの [実行可能なタスク] ダイアログ ボックスで、[メールボックスの作成] をクリックし、[次へ] をクリックします。

  6. [メールボックスの作成] ダイアログ ボックスで、[エイリアス]、[ストア]、および [メールボックス サーバー] のフィールドの情報を確認し、[次へ] をクリックします。

  7. [完了] をクリックして Exchange タスク ウィザードを閉じます。
Exchange Server 2003 で新しいユーザーのメールボックスを履歴保持用の受信者として指定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス ストアを右クリックして [プロパティ] を選択します。

  3. [このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] の右にある [参照] をクリックして、メールボックスを履歴保持用のメールボックスとして指定します。

    注 :
    このメールボックス ストア上の送信者の履歴保持対象のメッセージはすべて、指定したメールボックスに送信されます。

Exchange Server 2007 でこのエラーを修正するには、Exchange 管理コンソールまたは Exchange 管理シェルを使用して、必要に応じて以下の操作を実行します。

  • ジャーナル受信者オブジェクトのメールボックスを作成する。

  • 新しいユーザーのメールボックスをジャーナリング受信者として指定する。

Exchange Server 2007 で Exchange 管理コンソールを使用して、ジャーナル受信者オブジェクトのメールボックスを有効にするには、次の操作を行います。

  1. Exchange 管理コンソールで、[受信者の構成] を展開し、メールボックス オブジェクトを右クリックします。次に、[メールボックスの新規作成] をクリックして、メールボックスの新規作成ウィザードを開始します。

  2. [概要] ウィンドウで [ユーザー メールボックス] を選択し、[次へ] をクリックします。

  3. [ユーザーの種類] ウィンドウで [既存のユーザー] を選択し、[参照] ボタンをクリックして、メールボックスを作成するジャーナル受信者オブジェクトを選択します。

  4. [メールボックスの設定] ウィンドウで、[エイリアス]、[サーバー]、[ストレージ グループ]、[メールボックス データベース] の各フィールドの情報を確認し、[次へ] をクリックします。

  5. [メールボックスの新規作成] ウィンドウで、[新規] をクリックし、ジャーナル受信者オブジェクトのメールボックスを作成します。

  6. [終了] をクリックして、メールボックスの新規作成ウィザードを閉じます。
Exchange Server 2007 で Exchange 管理シェルを使用して、ジャーナル受信者オブジェクトのメールボックスを有効にするには、次の操作を行います。

  1. Exchange Server 2007 の製品ドキュメントの "Enable-Mailbox" (http://go.microsoft.com/fwlink/?LinkID=80827) の指示に従います (このサイトは英語の場合があります)。

Exchange Server 2007 で新しいユーザーのメールボックスをジャーナリング受信者として指定するには、次の操作を行います。

  1. Exchange 管理コンソールで、[サーバーの構成]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス データベースを右クリックして、[プロパティ] を選択します。

  2. [全般] タブの [ジャーナルの受信者] で [参照] をクリックし、ジャーナリング メールボックス用のメールボックスを指定します。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkId=80820) を参照してください (このサイトは英語の場合があります)。


履歴保持用の受信者が削除済みのオブジェクトを示す
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchMessageJournalRecipient 属性の値に文字列 DEL: が含まれているかどうかを判断します。この属性は、削除済みのメールボックスにメッセージをコピーするようにジャーナリングが構成されていることを示します。ジャーナリングが正しく動作するためには、コピーされるメッセージの送信先となる有効なジャーナリング受信者メールボックスが存在する必要があります。msExchMessageJournalRecipient 属性は、メールボックス データベースでジャーナリングを有効にするときに設定されます。この属性はメールボックス データベース属性で、ジャーナリング メールボックスの識別名を保持しています。

ジャーナリング受信者メールボックスが削除されている場合、ジャーナリング メッセージはキューに格納され始めます。Exchange Server アナライザによって msExchMessageJournalRecipient 属性の値に文字列 DEL: が含まれていることが検出されると、エラーが表示されます。

このエラーを修正するには、Exchange システム マネージャまたは Exchange 管理コンソールを使用して新しいメールボックスをジャーナリング受信者として指定します。

Exchange Server 2003 で新しいユーザーのメールボックスを履歴保持用の受信者として指定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス ストアを右クリックして [プロパティ] を選択します。

  3. [このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] の右にある [参照] をクリックして、メールボックスを履歴保持用のメールボックスとして指定します。

    注 :
    このメールボックス ストア上の送信者の履歴保持対象のメッセージはすべて、指定したメールボックスに送信されます。
Exchange Server 2007 で新しいユーザーのメールボックスをジャーナリング受信者として指定するには、次の操作を行います。

  1. Exchange 管理コンソールで、[サーバーの構成]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス データベースを右クリックして、[プロパティ] を選択します。

  2. [全般] タブの [ジャーナルの受信者] で [参照] をクリックし、ジャーナリング メールボックス用のメールボックスを指定します。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkId=80820) を参照してください (このサイトは英語の場合があります)。


履歴保持用の受信者が無効なアカウントを示す
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ジャーナリング受信者オブジェクトの msExchUserAccountControl 属性の値が無効なユーザー アカウントを示すように設定されていないかどうかを判断します。ジャーナリング受信者オブジェクトの msExchUserAccountControl 属性の値が 2 の場合、ジャーナリングはジャーナリング メッセージを無効なユーザー アカウントにコピーするように構成されていることを示します。この構成により、ジャーナリング メッセージがキューに置かれたり、不正メール フォルダに送信されたりする可能性があります。Exchange Server アナライザによって、ジャーナリング受信者の msExchUserAccountControl 属性の値が無効なジャーナリング受信者のユーザー アカウントを示すよう設定されていることが検出されると、エラーが表示されます。

Exchange Server 2003 でこのエラーを修正するには、Active Directory ユーザーとコンピュータおよび Exchange システム マネージャを使用し、必要に応じて以下の操作を実行します。

  • 現在のジャーナリング受信者のユーザー アカウントを有効にする。

  • 新しいユーザーのメールボックスをジャーナリング受信者として指定する。

Exchange Server 2003 で履歴保持用の受信者のアカウントを有効にするには、次の操作を行います。

  1. Active Directory ユーザーとコンピュータ スナップインを起動します。

  2. コンソール ツリーで、ドメインを展開します。

  3. 変更する履歴保持用の受信者の親コンテナに移動します。

  4. 詳細ウィンドウで、変更する受信者を右クリックし、[アカウントの有効化] を選択します。
Exchange Server 2003 で新しいユーザーのメールボックスを履歴保持用の受信者として指定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス ストアを右クリックして [プロパティ] を選択します。

  3. [このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] の右にある [参照] をクリックして、メールボックスを履歴保持用のメールボックスとして指定します。

    注 :
    このメールボックス ストア上の送信者の履歴保持対象のメッセージはすべて、指定したメールボックスに送信されます。

Exchange Server 2007 でこのエラーを修正するには、Exchange 管理コンソールまたは Exchange 管理シェルを使用して、必要に応じて以下の操作を実行します。

  • ジャーナル受信者オブジェクトのメールボックスを作成する。

  • 新しいユーザーのメールボックスをジャーナリング受信者として指定する。

Exchange Server 2007 で Exchange 管理コンソールを使用して、ジャーナル受信者オブジェクトのメールボックスを有効にするには、次の操作を行います。

  1. Exchange 管理コンソールで、[受信者の構成] を展開し、メールボックス オブジェクトを右クリックします。次に、[メールボックスの新規作成] をクリックして、メールボックスの新規作成ウィザードを開始します。

  2. [概要] ウィンドウで [ユーザー メールボックス] を選択し、[次へ] をクリックします。

  3. [ユーザーの種類] ウィンドウで [既存のユーザー] を選択し、[参照] ボタンをクリックして、メールボックスを作成するジャーナル受信者オブジェクトを選択します。

  4. [メールボックスの設定] ウィンドウで、[エイリアス]、[サーバー]、[ストレージ グループ]、[メールボックス データベース] の各フィールドの情報を確認し、[次へ] をクリックします。

  5. [メールボックスの新規作成] ウィンドウで、[新規] をクリックし、ジャーナル受信者オブジェクトのメールボックスを作成します。

  6. [終了] をクリックして、メールボックスの新規作成ウィザードを閉じます。
Exchange Server 2007 で Exchange 管理シェルを使用して、ジャーナル受信者オブジェクトのメールボックスを有効にするには、次の操作を行います。

  1. Exchange Server 2007 の製品ドキュメントの "Enable-Mailbox" (http://go.microsoft.com/fwlink/?LinkId=80827) の指示に従います (このサイトは英語の場合があります)。

Exchange Server 2007 で新しいユーザーのメールボックスをジャーナリング受信者として指定するには、次の操作を行います。

  1. Exchange 管理コンソールで、[サーバーの構成]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス データベースを右クリックして、[プロパティ] を選択します。

  2. [全般] タブの [ジャーナルの受信者] で [参照] をクリックし、ジャーナリング メールボックス用のメールボックスを指定します。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkID=80820) を参照してください (このサイトは英語の場合があります)。


履歴保持用の受信者がローカル サーバーを示す
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、メールボックス ストアのジャーナリング受信者オブジェクトの msExchHomeServerName 属性の値が、ローカル サーバーの legacyExchangeDN 属性の値と一致しているかどうかを判断します。これらの属性の値が一致している場合、ジャーナリング メッセージは、アクティブなジャーナリングの実行対象となっているサーバー上のメールボックスにコピーされます。ジャーナリングでは大量のトラフィックが生成されるため、ジャーナル受信者メールボックスは専用のジャーナリング サーバーに置くことをお勧めします。

Exchange Server アナライザによって、ジャーナリング受信者オブジェクトの msExchHomeServerName 属性の値が、ローカル サーバーの legacyExchangeDN の値と一致していることが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkId=80820) を参照してください (このサイトは英語の場合があります)。


履歴保持用の受信者は非表示にする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ジャーナリング受信者オブジェクトの msExchHideFromAddressLists 属性の値が True に設定されているかどうかを判断します。この属性が True 以外の値に設定されている場合、メールボックス ストアのジャーナリング受信者は Exchange Server のアドレス一覧で非表示になっていないため、ジャーナリングに関連していないメッセージの受信者となる可能性があります。Exchange Server アナライザによって、ジャーナリング受信者オブジェクトの msExchHideFromAddressLists 属性の値が True に設定されていないことが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

Exchange Server 2003 でこの問題を修正するには、Active Directory ユーザーとコンピュータ ツールを使用して、Exchange Server のアドレス一覧で履歴保持用の受信者メールボックスを非表示にします。

Exchange Server 2007 でこの問題を修正するには、Exchange 管理コンソールを使用して、Exchange Server のアドレス一覧でジャーナリング受信者のメールボックスを非表示にします。

Exchange Server 2003 で、指定した履歴保持用の受信者メールボックスを Exchange Server のアドレス一覧で非表示にするには、次の操作を行います。

  1. Active Directory ユーザーとコンピュータ スナップインを起動します。

  2. コンソール ツリーで、ドメインを展開します。

  3. 変更する受信者の親コンテナに移動します。

  4. 詳細ウィンドウで、変更する受信者をダブルクリックします。

  5. [Exchange の詳細設定] タブで、[Exchange アドレス一覧に表示しない] チェック ボックスをオンにします。

  6. [OK] をクリックします。
Exchange Server 2007 で、指定したジャーナル受信者のメールボックスを Exchange Server のアドレス一覧で非表示にするには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. コンソール ツリーで、変更する受信者の親コンテナに移動します。

  3. 詳細ウィンドウで、目的のジャーナリング受信者のメールボックス オブジェクトをダブルクリックして、プロパティを表示します。

  4. [全般] タブで、[Exchange アドレス一覧に表示しない] チェック ボックスをオンにします。

  5. [OK] をクリックします。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkId=80820) を参照してください (このサイトは英語の場合があります)。


Junk store threshold not configured
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange Server アナライザ ツールは、Exchange Server 2007 のハブ トランスポート サーバーの役割またはメールボックス サーバーの役割があるかどうかを、Exchange 環境に照会します。

Exchange Server 2007 のハブ トランスポート サーバーの役割またはメールボックス サーバーの役割のいずれかが見つかった場合、Exchange アナライザは、次の Exchange 管理シェル コマンドレットを使用して、Exchange 組織の SCLJunkThreshold パラメータの値を照会します。

Get-OrganizationConfig

組織の SCLJunkThreshold パラメータの値は、メッセージが迷惑メール フォルダに移動される SCL (Spam Confidence Level) を指定します。

Exchange アナライザが、組織の SCLJunkThreshold パラメータが既定値の 8 に設定されていると判断すると、警告が表示されます。

この警告は、メッセージが迷惑メール フォルダに移動される Spam Confidence Level のしきい値が、正当なユーザーからのメールであってもフィルタ処理され、迷惑メールとして迷惑メール フォルダに移動されるような値に設定されていることを示します。SCLJunkThreshold パラメータの推奨値は、4 です。

この警告に対処するには、Exchange 管理シェルで Set-OrganizationConfig コマンドレットを使用して、SCLJunkThreshold パラメータの値を 4 に設定します。

Set-OrganizationConfig コマンドレットを使用して、SCLJunkThreshold パラメータの値を 4 に設定するには

  1. 次のコードは、SCLJunkThreshold パラメータの値を 4 に設定する Set-OrganizationConfig コマンドの一例です。

  2. Set-OrganizationConfig -SCLJunkThreshold 4


カーネル メモリの不足
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-15

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、SRV (サーバー) または NCP Server ソースのイベント 2000、イベント 2019、またはイベント 2020 エラーが過去 24 時間以内にログに記録されていないかどうかを判断します。

  • SRV (サーバー) イベント ID 2000 は、一般システム カーネル メモリが不足したために、サーバーによるシステム サービスの呼び出しが失敗したことを示します。

  • SRV イベント ID 2019 は、システムの非ページ プール メモリが不足していることを示します。

  • SRV イベント ID 2020 は、システムのページ プール メモリが不足していることを示します。

これらのイベントの 1 つ以上が過去 24 時間以内にログに記録されていることが検出されると、エラーが表示されます。

この警告は、サーバーのカーネル メモリが使い果たされており、サーバーにパフォーマンスの問題が生じている可能性があることを示します。

Microsoft Windows カーネル メモリは、ページ プール メモリ、非ページ プール メモリ、およびシステム ページ テーブル エントリを含む複数のメモリ構造から構成されています。これらのメモリ構造は、カーネル メモリとも呼ばれ、Exchange などのアプリケーションの環境を提供するためにオペレーティング システムによって使用されます。

この問題に対処するには、Exchange アナライザの特定の問題について説明している以下の文書の指示に従ってください。

  • カーネル メモリの向上

  • ページ プールが警告しきい値を超えている

  • 非ページ プールが "警告" のしきい値を超えている

  • ページ プールがエラーのしきい値を超えている

一般に、正常な Exchange の展開を保持するには、Exchange Server のカーネル メモリの定期的な監視を確実に行う必要があります。

詳細情報

SRV イベント 2000、2019、または 2020 の詳細については、イベントおよびエラー メッセージ センターのイベント詳細についてのページを参照してください。

  • SRV イベント ID 2000 http://go.microsoft.com/fwlink/?LinkId=83250 (このサイトは英語の場合があります)

  • SRV イベント ID 2019 http://go.microsoft.com/fwlink/?LinkId=83251 (このサイトは英語の場合があります)

  • SRV イベント ID 2020 http://go.microsoft.com/fwlink/?LinkId=83252 (このサイトは英語の場合があります)

Exchange Server のためのメモリ最適化に関する詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 912376「2003 または Exchange 2000 Exchange Server サーバーのページ プール メモリ使用の監視とトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=912376)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な 空き システム ページ テーブル エントリを正確に示しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=894067)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)

  • 文書番号 912376「2003 または Exchange 2000 Exchange Server サーバーのページ プール メモリ使用の監視とトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=912376)


カーネル リソースの不足 : ボリューム シャドウ コピー サービスの更新
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの CIM_Datafile に対してクエリを実行し、Vssvc.exe ファイルが存在することを確認します。

Exchange Server アナライザは、レジストリでクエリを実行し、ボリューム シャドウ コピー サービス (VSS) または仮想ディスク サービス (VDS) が Windows Server で実行されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS

さらに、Exchange Server アナライザは、次のレジストリ値を読み取り、Exchange サーバーで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 5.0 の場合、Exchange サーバーは Microsoft Windows 2000 Server 上で実行されています。CurrentVersion の値が 5.2 の場合、Exchange サーバーは Microsoft Windows Server™ 2003 上で実行されています。

最後に、Exchange Server アナライザ ツールは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、ServicePackMajorVersion キーの値を判断します。ServicePackMajorVersion キーの値は、コンピュータにインストールされている Windows Service Pack を示します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Exchange Server が Windows Server 2003 Service Pack 1 (SP1) にインストールされている。

  • ボリューム シャドウ コピー サービスまたは仮想ディスク サービスが Windows Server 2003 SP 1 で実行されている。

  • VSS の更新プログラムがこの Exchange Server の構成にインストールされていない。

VSS の更新プログラムを適用すると、カーネル リソースの不足などの問題が解決されます。

このエラーを修正するには、次の操作を行います。

  • VSS の更新プログラムを適用するには、Microsoft サポート技術情報の文書番号 891957「Windows Server 2003 のボリューム シャドウ コピー サービスのさまざまな問題を修正する更新プログラム」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=891957) から VSS の更新プログラムをダウンロードします。

Exchange Server 2003 で VSS を使用するためのベスト プラクティスの詳細については、「Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=56571) を参照してください (このサイトは英語の場合があります)。


LeakDiag がインストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、LeakDiag.exe がコンピュータにインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\LeakDiag

このレジストリ ブランチが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

LeakDiag は、開発者、サポート担当者、および情報技術 (IT) スタッフが、Microsoft Windows NT® Server 4.0、Windows® 2000 Server、Windows XP、および Windows Server™ 2003 を実行しているコンピュータ上のアプリケーションやサービスのメモリ リーク、断片化、およびメモリに関連するその他の問題を診断するために使用する一連のツールです。

LeakDiag ツールは、コード行のメモリ リークの場所を特定するために使用できます。LeakDiag は Microsoft Detours テクノロジを使用して、指定されたメモリ割り当てへの呼び出しを傍受し、各種コール スタックを追跡します。そして、割り当てられたが解放されていないメモリについての報告を行います。この情報により、メモリ リークの問題のトラブルシューティングを行い、割り当てを行っているコンポーネントを特定できます。適切なデバッグ シンボルを使用すれば、その割り当てを要求したコード行を参照することも可能です。

運用環境の Exchange サーバーで LeakDiag を実行することはお勧めしません。LeakDiag を有効にすると、Exchange サーバーが起動されるたびに、すべてのプロセスについてすべてのメモリ割り当てが追跡されます。それに伴い膨大なプロセッサとメモリ リソースが消費されるため、これはメモリに関連する問題の積極的なトラブルシューティングを行っているとき以外は推奨されません。メモリに関連する問題の積極的なトラブルシューティングを行っているとき以外は、LeakDiag を無効にしてください。運用 Exchange Server 環境で LeakDiag を実行することはメモリの断片化と不足を引き起こし、最終的に Exchange の障害の原因となる可能性があります。

注 :
LeakDiag による問題のトラブルシューティングは、必ず使用のピーク時間を避けて行ってください。負荷の大きな時間、またはピークの時間に LeakDiag を使用すると、Exchange Server コンピュータのパフォーマンスが大幅に低下することがあります。

このメッセージに関する情報

  1. このメッセージは、情報提供のみを目的としています。LeakDiag は、有効化され実行されていない限り、インストールしただけでは Exchange Server のパフォーマンスに影響しません。LeakDiag は約 4 MB のハード ディスク領域を必要とします (ログを除く)。

  2. このハードディスク領域を解放するには、[コントロール パネル] で [プログラムの追加と削除] をクリックし、[LeakDiag] をクリックします。次に、[削除] をクリックして LeakDiag.exe を削除します。

LeakDiag の最新バージョンについては、Microsoft の公開 FTP サイト (http://go.microsoft.com/fwlink/?LinkId=41401) を参照してください。


LeakDiag が有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、このコンピュータ上で LeakDiag.exe が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\LeakDiag\EnableAutoStart

EnableAutoStart の値が 1 に設定されていることが検出されると、警告が表示されます。EnableAutoStart は、LeakDiag のユーザー インターフェイスを使用して構成されます。既定の値は 0 です。値が 1 の場合は、LeakDiag が有効かつアクティブになっています。

LeakDiag は、開発者、サポート担当者、情報技術 (IT) 担当者が、Microsoft Windows NT® Server 4.0、Windows® 2000 Server、Windows XP、および Windows Server™ 2003 が実行されているコンピュータ上のアプリケーションやサービスのメモリ リーク、断片化、およびメモリに関連するその他の問題を診断するために使用する一連のツールです。

LeakDiag ツールは、コード行のメモリ リークの場所を特定するために使用できます。LeakDiag は Microsoft Detours テクノロジを使用して、指定されたメモリ割り当てへの呼び出しを傍受し、各種コール スタックを追跡します。そして、割り当てられたが解放されていないメモリについての報告を行います。この情報を使用すると、メモリ リークの問題のトラブルシューティングを行っている担当者は、どのコンポーネントがその割り当てを行ったのかを正確に把握できます。適切なデバッグ シンボルを使用すれば、その割り当てを要求したコード行を参照することも可能です。

運用環境の Exchange サーバーで LeakDiag を実行することはお勧めしません。LeakDiag を有効にすると、Exchange サーバーが起動されるたびに、すべてのプロセスについてすべてのメモリ割り当てが追跡されます。それに伴い膨大なプロセッサとメモリ リソースが消費されるため、これはメモリに関連する問題の積極的なトラブルシューティングを行っているとき以外は推奨されません。メモリに関連する問題の積極的なトラブルシューティングを行っているとき以外は、LeakDiag を無効にしてください。運用 Exchange Server 環境で LeakDiag を実行することはメモリの断片化と不足を引き起こし、最終的に Exchange の障害の原因となる可能性があります。

注 :
LeakDiag による問題のトラブルシューティングは、必ず使用のピーク時間を避けて行ってください。負荷の大きな時間、またはピークの時間に LeakDiag を使用すると、Exchange Server コンピュータのパフォーマンスが大幅に低下することがあります。

LeakDiag.exe で自動起動を無効にするには

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[LeakDiag] をポイントして [LeakDiag] をクリックします。

  2. [Tools] メニューの [Options] をクリックします。

  3. [Options] ページで、[Allow AutoStart] チェック ボックスをオフにし、[OK] をクリックします。

LeakDiag の最新バージョンについては、Microsoft の公開 FTP サイト (http://go.microsoft.com/fwlink/?LinkId=41401) を参照してください。


ログの空き領域が残り 7 日分未満になる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-13

Microsoft Exchange Server アナライザ ツールは、Exchange Server ストレージ グループのトランザクション ログ ドライブの空き領域がいっぱいになるまでの残り時間を予測します。Exchange Server アナライザは、ログ ドライブ上のトランザクション ログ ファイルのタイムスタンプを調べることにより、このファイルがログ ドライブの容量に到達する時間を予測します。ログ ドライブがいっぱいになるまでの残り時間が 7 日未満であることが検出されると、エラーが表示されます。

Exchange Server データベースのログ ファイルを格納するドライブのディスク領域が不足します。

ログ ドライブのディスク領域が不足すると、以下の問題が発生する可能性があります。

  • データベースが起動しないか、またはシャットダウンされる。

  • データベースがダーティ シャットダウンされ、整合性が失われる。

  • ユーザーがメール フォルダやパブリック フォルダにアクセスできなくなる。

循環ログが無効になっていることが原因で、ログ ドライブの領域がいっぱいになる場合があります。無効になっていると、Exchange Server 対応のバックアップ ソフトウェアを使用する完全オンライン バックアップまたは増分オンライン バックアップを実行するまで、トランザクション ログ ファイルがドライブ上に残されます。

Exchange 2003 以前のバージョンの Exchange Server では、データベースが動作している間はデータベースをクリーン シャットダウンの状態にできません。ディスク領域が不足するような緊急事態が発生すると、Res1.log と Res2.log の 2 つの予備のトランザクション ログ ファイルが、通常のトランザクション ログに変換されます。

Exchange Server 2003 には最適化機能が実装されたため、予備のログ ファイルがすべて変換されるまで、データベースをクリーンにシャットダウンできます。データベースがクリーンにシャットダウンされなかった場合、そのデータベースに関連付けられている最後のいくつかのトランザクション ログが削除されません。これらのトランザクション ログには、データベースの整合性を回復するために適用する必要のある情報が残されています。これらのログ ファイルを削除すると、データベースを修復または復元するまで、データベースを再び起動することはできません。

ストレージ グループ内のすべてのデータベースがクリーン シャットダウンの状態にある場合、すべてのトランザクション ログを削除しても、データベースを起動できます。ただし、トランザクション ログを削除すると、以前のバックアップは無効になります。トランザクション ログの削除は、バックアップの復元ができないことを意味するわけではありません。これは、復元されたデータベースを、ログ ファイルを削除した時点以降にロール フォワードできないことを意味します。

Exchange Server アナライザのログ領域ウィザードは既存のトランザクション ログ ファイルを分析するため、データベースに不要になったトランザクション ログを移動する場合に役立ちます。また、ログ領域ウィザードは、すべてのデータベースがクリーン シャットダウンの状態にある場合でも、現在のログ ファイルが削除されないようにします。現在のログ ファイルが削除されていない場合、以前のバックアップが有効のままになります。

ログ ドライブの空き領域を増やすには、不要なログ ファイルを削除する必要があります。以下の操作を行うことをお勧めします。

ログ ドライブの領域が容量いっぱいまで使用されるかまたはいっぱいに近づいたときに、ログ ドライブの空き領域を増やすには、次の操作を行います。

  • Exchange に対応するオンライン ストリーミング バックアップまたはボリューム シャドウ コピー サービス (VSS) バックアップを使用してデータベースのバックアップを作成します。VSS バックアップの詳細については、Exchange Server 2003 でボリューム シャドウ コピー サービスを使用する場合のベスト プラクティスのページ (http://go.microsoft.com/fwlink/?LinkId=56571) を参照してください (このサイトは英語の場合があります)。

    注 :
    不要なログ ファイルを削除する場合は、オンライン ストリーミング バックアップまたは VSS バックアップを作成することをお勧めします。

  • ログ ドライブの空き領域不足が原因でデータベースがシャットダウンされる場合は、Exchange Server アナライザのログ領域管理ウィザードを使用できます。このウィザードを使用すると、超過するログ ファイルを移動できます。代わりに、データベースを再度マウントする前に、超過するログ ファイルを手動で移動することもできます。

    ログ ファイルを手動で削除するには、Microsoft サポート技術情報の文書番号 240145「Exchange Server トランザクション ログ ファイルを移動する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240145) に記載されている手順および推奨事項に従ってください。


Exchange サーバーの LegacyExchangeDN が親管理グループと一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory の [Servers] コンテナ内にあるサーバー オブジェクトの属性を、そのサーバーが存在する組織または管理グループの実際の名前と比較してチェックすることにより、サーバーの legacyExchangeDN 値を確認します。そのサーバーの legacyExchangeDN 値が組織または管理グループと異なることが検出されると、エラーが表示されます。

Exchange は legacyExchangeDN 値を使用して、Active Directory 内の Exchange オブジェクトを識別します。legacyExchangeDN 値は、Exchange 組織内のオブジェクトの場所を示す識別名であり、次のような形式をしています。

/o= 組織 /ou= 管理グループ /ou= サーバー

メールボックス ストアやパブリック フォルダ ストアなどのオブジェクトは、legacyExchangeDN 値の一部をサーバーから継承します。つまり、サーバーの値に問題があると、その他のオブジェクトにも同じ問題が継承される可能性があります。

一般に、legacyExchangeDN に関する問題は、管理者がこの値を直接変更しようとした場合に発生します。この値は、Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、その他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit または同様のツールを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    legacyExchangeDN 属性は次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Administrative Groups,CN=管理グループ名,CN=Servers,CN=サーバー名

  2. 次の形式で、新しい文字列値を入力します。

    /o= 組織 /ou= 管理グループ /ou= サーバー

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server 2003 ヘルプのトピック「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。


使用中の Exchange サーバーの LegacyExchangeDN が正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange サーバーの legacyExchangeDN 値を判断します。このエラーは、legacyExchangeDN 値に名前が記載されている組織または管理グループが、組織や管理グループの実際の名前と一致しない場合、または値の一部が完全に欠けている場合に表示されます。

Exchange は legacyExchangeDN 値を使用して、Active Directory 内の Exchange オブジェクトを識別します。legacyExchangeDN 値は、Exchange 組織内のオブジェクトの場所を示す識別名であり、次のような形式をしています。

/o= 組織 /ou= 管理グループ

サーバーやフォルダ階層などのオブジェクトは、legacyExchangeDN 値の一部を管理グループから継承します。つまり、管理グループの値に問題がある場合、他の多くのオブジェクトが同じ問題を継承することになります。

legacyExchangeDN に関する問題は一般に、管理者がその値を直接変更しようとしたときに発生します。この値は、Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、その他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit または同様のツールを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    legacyExchangeDN 属性は次の場所にあります。

    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=組織名,CN=Administrative Groups,CN=管理グループ名

  2. 次の形式で、新しい文字列値を入力します。

    /o= 組織 /ou= 管理グループ

LDP ツールの使用に関する詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM]: LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server 2003 ヘルプのトピック「Adsiedit.msc: ADSI Edit」を参照してください (このページは英語の場合があります)。


License Logging サービスが [自動] に設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、License Logging サービス (LicenseService) の Started キーの値を判断します。値が False の場合は、この Exchange サーバー上で License Logging サービスが実行されていません。値が True の場合は、License Logging サービスが実行されています。

Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間の Exchange_Server WMI クラスに対してもクエリを実行し、IsFrontEndServer キーの値を判断します。値が False のときは、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True のときは、Exchange Server コンピュータはフロントエンド サーバーです。

Exchange Server アナライザはまた、Win32_OperatingSystem WMI クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーの値として返された値は、Exchange Server コンピュータで実行されている Windows オペレーティング システムのバージョンを示します。

さらに、Exchange Server アナライザは Active DirectoryR ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性のエントリ数は、メールボックス ストア上のメールボックスの数を表します。

以下のすべての条件を満たす Exchange Server コンピュータで、License Logging サービスが開始されていると判断されると、警告が表示されます。

  • Exchange Server コンピュータがフロントエンド サーバーではない。

  • Exchange Server コンピュータで、20 を超えるメールボックスがホストされている。

  • Exchange Server コンピュータが Microsoft Windows Small Business Server 2003 または Microsoft Windows Small Business Server 2000 上で実行されていない。

License Logging サービスはもともと、顧客が、サーバー クライアント アクセス ライセンス (CAL) モデルでライセンスされた Microsoft サーバー製品のライセンスを管理するのに役立つように設計されたツールです。

既定では、Microsoft Windows Server™ 2003 では License Logging サービスが無効になっています。License Logging サービスでは、元々の設計面での制約やラインセンス条項の改定のために、単一のサーバーまたは企業全体で使用されている CAL の総数と比較して、購入済みの CAL の総数を正確に表示できません。License Logging サービスによって報告される CAL は、エンド ユーザー使用許諾契約書 (EULA) および製品使用権説明書 (PUR) の解釈と矛盾する場合があります。License Logging サービスは、Windows オペレーティング システムの将来のバージョンには含まれません。

Microsoft は、Exchange Server コンピュータでの License Logging サービスの使用について、以下のような特定の要件と推奨事項を設けています。

  • SSL (Secure Sockets Layer) を使用するフロントエンドの Exchange サーバーでは、License Logging サービスを有効にして開始する必要があります。License Logging サービスが実行されていない場合は、インターネット インフォメーション サービス (IIS) によって、SSL 認証を使用した同時接続数が 10 までに制限されます。

  • バックエンドの Exchange サーバーでは License Logging サービスを停止し、[無効] に設定することをお勧めします。

  • クラスタ化された Exchange サーバーでは License Logging サービスを停止し、[無効] に設定することをお勧めします。

  • Microsoft Windows Small Business Server 2003 または Microsoft Windows Small Business Server 2000 上で実行されている Exchange サーバーでは、認証される SSL 接続が 10 より多く必要な場合のみ、License Logging サービスが必要になります。

License Logging サービスの状態を設定するには

  1. [管理ツール] メニューから [サービス] スナップインを開きます。

  2. [License Logging Service] を見つけてダブルクリックします。

  3. [スタートアップの種類] ボックスの一覧で、適切なオプションを選択します。

    • SSL を使用するフロントエンド Exchange サーバーで、サービスを [自動] に設定します。

    • バックエンド Exchange サーバーおよびクラスタ化された Exchange サーバーでは、サービスを [無効] に設定します。

  4. License Logging サービスを無効にする場合は、さらに [停止] をクリックしてサービスを停止します。

  5. [OK] をクリックして変更を保存し、サービス スナップインを終了します。

License Logging サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 824196「Windows サーバー オペレーティング システムのライセンス ログ サービスについて」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=824196)

  • 文書番号 316631「ライセンス ログ サービスを無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=316631)


ログ ファイル名がログ生成番号と一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、トランザクション ログ ファイルのヘッダーにある lGeneration 内部生成番号の値とトランザクション ログ ファイルのファイル名とを比較して、それらが一致しているかどうかを判断します。

トランザクション ログ ファイルの内部生成番号がトランザクション ログ ファイル名の内部生成番号の表記と一致していない場合、エラーが表示されます。

ログ ファイルが現在のログでない場合は、使用可能な最新のログ ファイルのファイル名がその生成番号と一致している必要があります。ログ ファイルが現在のログである場合は、生成番号はファイル名には含まれず、ストレージ グループのログのプレフィックスのみがファイル名に含まれています。たとえば、以前の一連のトランザクション ログの名前は E0154321.LOG、E0154322.LOG、E0154323.LOG のようになり、現在のログの名前は E01.LOG のようになります。

Eseutil /ML LOGFILE コマンドを使用すると、ログ ファイルの内部の lGeneration 値を表示できます。

Exchange Server のトランザクション ログの詳細については、『Using Recovery Storage Groups in Exchange Server 2003』の「Exchange Transaction Logging in Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。


ログ シーケンスの署名の不一致
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、ログ ファイルの Signature を後続のログ ファイルの Signature 値と比較し、2 つの値が一致するかどうかを確認します。

ログ ファイルの Signature 値と後続のログ ファイルの Signature 値が一致しないと、エラーが表示されます。

Exchange は、1 つの大きなファイルにすべてのログ情報を書き込むのではなく、一連のログ ファイルを使用します。個々のファイル サイズは 5 MB ちょうどです。1 つのログ ファイルがいっぱいになると、Exchange はそのファイルを閉じ、シーケンス番号を付けてファイル名を変更します。

Exchange ストレージ グループのトランザクション ログ ファイルの新しいシーケンスが初期化されると、最初のログ ファイルに Signature が書き込まれ、その Signature が後続の各ログ ファイルにコピーされます。Signature により、特定のログ ファイルが特定のログ シーケンスのメンバとして一意に識別されます。

通常、同じフォルダ内に格納されているログ ファイルに異なる署名が割り当てられていることはありません。そのような状況が検出された場合、それは異種のログ ファイルがストレージ グループにコピーされたか、または以前のすべてのログ ファイルを先に削除することなしにログ ファイルがリセットされたことを表します。

Eseutil /ML LOGFILE コマンドを使用すると、ログ ファイルの Signature 値を表示できます。

Exchange Server のトランザクション ログの詳細については、『Using Recovery Storage Groups in Exchange Server 2003』の「Exchange Transaction Logging in Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。


ログの署名の問題
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、サーバー上の現在の Exchange トランザクション ログ ファイルのヘッダーにある署名とストレージ グループのデータベース ファイル内のログ署名とを比較します。

トランザクション ログ ファイルの署名といずれかのデータベース ファイルのログ署名が一致しない場合、Exchange Server アナライザはエラーを表示します。

このエラーは、以下の状況のいずれかに該当することを示します。

  • 現在のトランザクション ログ ファイルが存在しない。

  • 現在のトランザクション ログ ファイルが、ストレージ グループ内のデータベースのいずれかと一致しない。

この状況の発生には、以下の原因が考えられます。

  • ストレージ グループのトランザクション ログが手動で削除されている。

  • 別のストレージ グループのデータベースが、このストレージ グループに復元またはコピーされている。

  • 別のシーケンスまたはストレージ グループのトランザクション ログがこのストレージ グループにコピーされている。

この条件によって、データベースのマウントができなくなるかどうかは、データベース ファイルがクリーン シャットダウン状態と、ダーティ シャットダウン状態のいずれであるかによって異なります。

注 :
ストレージ グループ内の他のデータベースがマウント可能でない場合は、特定のデータベースがクリーン シャットダウン状態でも、マウントできません。Exchange Server 障害回復アナライザを使用して診断を実行すると、このような状況でデータベースのマウントを可能にする方法が表示されます。

Exchange データベースが正しくシャットダウンされた場合は、保留中のすべてのデータがデータベース ファイルに書き込まれます。通常のシャットダウン後は、データベース ファイル セット (拡張子 .edb および .stm) の整合性が保持されていると見なされます。その後、Exchange によってデータベース ファイル セットがログ ストリームから切断されます。これによって、データベース ファイルは自己完結し、完全に最新の状態になります。データベース ファイルの起動に過去のトランザクション ログは必要ありません。

クリーン シャットダウン状態のデータベースは、ログ ファイルから切断されており、別のログ ストリームに接続できます。このため、ログ ファイルとデータベースの不一致が必ずしも問題になるとは限りません。

ダーティ シャットダウン状態のデータベースは、ログ ファイルから正しく切断されていません。これらのデータベースは、接続されたログ ファイルを使用して回復する必要があります。接続されたログ ファイルの位置を確認できないと、データベースをマウントできません。データベースをマウント可能にするには、バックアップから復元を実行するか、修復する必要があります。

Eseutil /mh コマンドを入力してファイルのヘッダーを調べると、データベースがクリーン シャットダウンされているかどうかを確認できます。Microsoft Exchange 2000 Service Pack 1 以降では、ヘッダーに「State:Clean Shutdown」または「State:Dirty Shutdown」と表示される行があります。これより前のバージョンの Exchange では、これと同じ状態が「State:Consistent」または「State:Inconsistent」としてレポートされます。

Exchange Server のトランザクション ログの詳細については、『Using Recovery Storage Groups in Exchange Server 2003』の「Exchange Transaction Logging in Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。


1 秒あたりのログ レコードのバイト数がエラーのしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期されるとおりに実行されているかどうかを判断します。

この分析の一環として、Exchange Server アナライザはトランザクション ログの使用状況を確認し、ユーザーの MAPI 操作によって 1 分間に 5 MB を超えるデータが Exchange トランザクション ログに書き込まれていないかを判断します。

MAPI 操作によってログ ファイルが過度に増大すると、チェックポイントの深さ制限の超過、ディスク I/O のボトルネック、ディスク容量の不足など、サーバー リソースのボトルネックやエラーの原因になる可能性があります。

ユーザーの MAPI 操作によって 1 分間に 5 MB を超えるデータが Exchange トランザクション ログに書き込まれていることが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI 操作で Exchange トランザクション ログに 1 分間に 5 MB を超えるデータが書き込まれたとしても、これは必ずしも問題となるわけではありません。メールボックスの移動や多数のメッセージに対する一括操作など、大量のトランザクション ログ データを生成する一部の動作については、書き込み率が高くなることが予想されます。この場合、高い書き込み率が続くのは最大でも数分間です。

RPC の待ち時間が長くなるなどサーバーで他の問題が発生する場合は、そのトランザクション ログ データを生成しているユーザーと協力して、ログの高い書き込み率を発生させているのはどのユーザー操作であるかを特定します。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server 2003 のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


LogicalDisk パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、LogicalDisk パフォーマンス オブジェクトの Avg. Disk sec/Read パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合、次の状況のいくつかが発生しています。

  • LogicalDisk パフォーマンス オブジェクトが無効になっている。既定では、Microsoft Windows Server™ 2003 では LogicalDisk パフォーマンス オブジェクトは有効です。ただし、Microsoft Windows® 2000 Server では、既定で LogicalDisk は有効ではありません。

  • LogicalDisk パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張カウンタによってレジストリが壊れた場合、または Microsoft WMI (Windows Management Instrumentation) に基づくプログラムによってレジストリが変更された場合に発生する可能性があります。

以下の手順は、最初の 2 つの状況を修復する方法について説明しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. LogicalDisk パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードし、インストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. 足りないパフォーマンス カウンタまたは壊れたパフォーマンス カウンタを再構築します。パフォーマンス カウンタを再構築する方法については、Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) を参照してください。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Windows オペレーティング システムを修復モードで再インストールしてから、最新の Windows Service Pack を適用する必要があります。


待ち時間の長い MAPI 操作が検出される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-11-22

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、5 分間のサンプリングでデータを収集し、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

データ収集の時間枠において、ユーザーの MAPI 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示され、エラーを引き起こしたユーザーの操作についてさらに詳細な分析が行われます。

MAPI 操作が 30 秒を超えても、必ずしも問題となるわけではありません。メッセージ データや添付ファイルを大量に保存していると、MAPI 操作に通常より長く時間がかかることがあります。

ユーザーが頻繁に遅延に遭遇したり、メッセージング操作に悪影響を及ぼす遅延が発生する場合は、これらの MAPI 操作の遅延を詳しく調査し、これらの待ち時間の問題が、リソースのボトルネックや入れ子になった依存関係など、さらに重大な問題を示すものでないことを確認します。

このエラーを修正するには、次の操作を行います。

  • ExMon ツールを使用してさらに多くのデータ サンプルを取得し、Exchange Server アナライザで調査することを検討します。ExMon では大量のデータが生成されるため、データ収集のサンプリングの時間は 30 分以下にすることをお勧めします。

  • すべての待ち時間に関するエラー、および特定の操作やこれらのエラーを解決する手順が記載された文書を確認します。Exchange Server アナライザによって待ち時間に関連するエラーが報告されていない場合は、ユーザー アクションに関する詳細な分析で特に問題がなかったことを意味します。


MAPI 一括操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI 一括操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

MAPI 一括操作は複数のオブジェクトを処理する操作で、通常コストが高くなります (多くの I/O を必要とするため)。

ユーザーの MAPI 一括操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI 一括操作が 30 秒を超えても、必ずしも問題となるわけではありません。ユーザーが 1000 以上のメッセージを一度に処理 (コピー、削除、属性フラグの設定など) する場合、MAPI 一括操作にかかる時間は通常より長くなることがあります。

ユーザーが頻繁に遅延に遭遇したり、メッセージング操作に悪影響を及ぼす遅延が発生する場合は、これらの MAPI 一括操作の遅延を詳しく調査し、これらの待ち時間の問題が、リソースのボトルネックや入れ子になった依存関係など、さらに重大な問題を示すものでないことを確認します。

このエラーを修正するには、次の操作を行います。

  • ExMon ツールを使用してさらに多くのデータ サンプルを取得し、Exchange Server アナライザで調査することを検討します。Exchange では大量のデータが生成されるため、データ収集のサンプリングの時間は 30 分以下にすることをお勧めします。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server 2003 のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI 'FindRow' 操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-11-22

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI FindRow 操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

各フォルダのビュー数が増加することによって、多くの MAPI 操作でより多くのオーバーヘッドが発生する可能性があります。クライアント アプリケーションは、MAPI 操作 SeekRow または FindRow を使用して、ビューの行間でポインタを移動します。SeekRow はポインタを移動する行数を指定し、CPU 時間に関しては非常に低コストです。FindRow のコストが非常に高いのは、実体が存在しない (キャッシュされない) ビュー 内で、制限条件に一致する最初の項目にポインタを移動し、クライアント アプリケーションが処理を完了した後でこのビューを削除するためです。FindRow の最終的な CPU コストは、制限の複雑さ、および条件と一致する最初の項目を検索するまでにストアが確認する必要がある行数によって異なるため、フォルダ内のアイテム数との相互関係が少しあります。

FindRow によって高コストの処理が発生する場合は、サーバーのコストを減らすためにキャッシュ モードの実行を検討します。CPU の利用率が高くなるのは共有予定表による処理だけの場合があります。この場合は、キャッシュ モードによる効果はないことに注意してください。FindRow 操作によって CPU の利用率が高くなる場合、多数のビュー作成、高コストのビュー、またはフォルダ内のアイテム数が多いことを示している可能性があります。

ユーザーが発行した MAPI FindRow 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI FindRow 操作が 30 秒を超えても、必ずしも問題となるわけではありません。特定のユーザーで頻繁に遅延が発生したり、メッセージング操作に悪影響を与える遅延が発生する場合は、原因を調べる必要があります。待ち時間が長くなっているユーザーと協力して、次のことを確認します。

  • フォルダ内のアイテム数が多いかどうか。

  • ユーザーはどのようなアプリケーションを実行しているか。

この問題を解決するには

  • フォルダ内のアイテム数が多い場合は、ユーザーに各フォルダのアイテム数を減らすように指示します。受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5,000 未満にすることをお勧めします。

  • 操作的に最もコストのかかるクライアント コンピュータ (特に、Restrict、SetColumns、または FindRow 操作で長い待ち時間が生じるコンピュータ) は、Exchange キャッシュ モードを使用するように構成してください。Exchange キャッシュ モードは、ほとんどの超過 RPC トラフィックからサーバーを分離します。

  • すべてのアプリケーションを終了させ、その後これらのアプリケーションを 1 つずつ起動し、問題の原因となっているアプリケーションを特定します。これらのアプリケーションが業務に必要ない場合、またはアプリケーションに修正プログラムが公開されている場合は、そのアプリケーションの使用を完全に中止するか、あるいはアプリケーションを更新して、負荷を適切なレベルに低下させます。

注 :
一部のアプリケーションは、多くの MAPI 操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、多くの MAPI 操作を発行したわけではないにもかかわらず、CPU に高い影響を与えているユーザーを報告します。

また、リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在する場合も、FindRow 操作の待ち時間が長くなることに注意してください。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI オンライン操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI オンライン操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

MAPI オンライン操作の例として、QueryRows 操作があります。

QueryRows 操作は、現在のビュー内の行を返すために使用します。QueryRows は、テーブル内のデータを使用してユーザーの要求に応答します。QueryRows で利用できるデータは、SetColumns 操作によって決定されます。QueryRows のコストは、要求されたプロパティのサイズ、要求されたプロパティの数、および要求されたデータの行数に伴い増加します。また、多くの列や行が要求される場合にも、QueryRows のコストは高くなります。

Exchange Server 2003 のコアのフォルダ内のアイテム数が増えるに従い、Outlook ユーザー向けの操作を実行する際の物理的なディスク コストも増加します。受信トレイをサイズ順に並べ替える処理の初回のコストは非常に高くなります (ディスク I/O を多く必要とするため)。それ以降の受信トレイをサイズ順に並べ替えるコストは非常に低くなります。

データ収集の時間枠において、ユーザーの MAPI オンライン操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI オンライン操作の待ち時間が長い場合、サーバー リソースのボトルネックを示している可能性があります。QueryRows 操作では、フォルダ内のアイテム数が多いこと、または内部テーブルに設定されたプロパティが多いことを示している可能性もあります。

同時に多数のデータを処理する際にオンライン操作の待ち時間が長くなる場合がありますが、これは特にサーバー パフォーマンスの問題を示しているのではない可能性があります。このような例としては、ユーザーがフォルダ内のすべてのアイテムを選択し、一度の操作でそれらを開封済みにする場合などです。待ち時間が長くなっているユーザーと協力して、次のことを確認します。

  • フォルダ内のアイテム数が多いかどうか。

  • ユーザーはどのようなアプリケーションを実行しているか。

この問題を解決するには

  • フォルダ内のアイテム数が多い場合は、ユーザーに各フォルダのアイテム数を減らすように指示します。受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5,000 未満にすることをお勧めします。

  • すべてのアプリケーションを終了させ、その後これらのアプリケーションを 1 つずつ起動し、問題の原因となっているアプリケーションを特定します。これらのアプリケーションが業務に必要ない場合、またはアプリケーションに修正プログラムが公開されている場合は、そのアプリケーションの使用を完全に中止するか、あるいはアプリケーションを更新して、負荷を適切なレベルに低下させます。

注 :
一部のアプリケーションは、多くの MAPI オンライン操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、多くの MAPI 操作を発行したわけではないにもかかわらず、CPU に比較的高い影響を与えているユーザーを報告します。

また、リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在する場合も、MAPI オンライン操作の待ち時間が長くなることに注意してください。サーバー リソースのボトルネックを確認し、サーバー リソースの処理能力を増やすか、ユーザーをより負荷の低いサーバーに移動します。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server 2003 のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI 操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-11-22

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

ユーザーの MAPI 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

各フォルダのビュー数が増加することによって、多くの MAPI 操作でより多くのオーバーヘッドが発生する可能性があります。このトピックでは、最も多く発生する SeekRow および FindRow の 2 つの例について説明します。Exchange Server アナライザで「操作時間が長い」と判断された他の MAPI 操作も、通常は、SeekRow および FindRow の MAPI 操作の場合と同じ手法で解決できます。

クライアント アプリケーションは、MAPI 操作 SeekRow または FindRow を使用して、ビューの行間でポインタを移動します。SeekRow はポインタを移動する行数を指定し、CPU 時間に関しては非常に低コストです。FindRow のコストが非常に高いのは、実体が存在しない (キャッシュされない) ビュー 内で、制限条件に一致する最初の項目にポインタを移動し、クライアント アプリケーションが処理を完了した後でこのビューを削除するためです。FindRow の最終的な CPU コストは、制限の複雑さ、アクセスされる各メッセージのメッセージ プロパティ数、および条件と一致する最初の項目を検索するまでにストアが確認する必要がある行数によって異なるため、フォルダ内のアイテム数との相互関係が少しあります。

MAPI 操作が 30 秒を超えても、必ずしも問題となるわけではありません。特定のユーザーで頻繁に遅延が発生したり、メッセージング操作に悪影響を与える遅延が発生する場合は、原因を調べる必要があります。待ち時間が長くなっているユーザーと協力して、次のことを確認します。

  • フォルダ内のアイテム数が多いかどうか。

  • ユーザーはどのようなアプリケーションを実行しているか。

この問題を解決するには

  • フォルダ内のアイテム数が多い場合は、ユーザーに各フォルダのアイテム数を減らすように指示します。受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5,000 未満にすることをお勧めします。

  • 操作的に最もコストのかかるクライアント コンピュータ (特に、Restrict、SetColumns、または FindRow 操作で長い待ち時間が生じるコンピュータ) は、Exchange キャッシュ モードを使用するように構成してください。Exchange キャッシュ モードは、ほとんどの超過 RPC トラフィックからサーバーを分離します。

  • すべてのアプリケーションを終了させ、その後これらのアプリケーションを 1 つずつ起動し、問題の原因となっているアプリケーションを特定します。これらのアプリケーションが業務に必要ない場合、またはアプリケーションに修正プログラムが公開されている場合は、そのアプリケーションの使用を完全に中止するか、あるいはアプリケーションを更新して、負荷を適切なレベルに低下させます。

注 :
一部のアプリケーションは、多くの MAPI 操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、多くの MAPI 操作を発行したわけではないにもかかわらず、CPU に高い影響を与えているユーザーを報告します。

また、リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在する場合も、MAPI 操作の待ち時間が長くなることに注意してください。サーバー リソースのボトルネックを確認し、サーバー リソースの処理能力を増やすか、ユーザーをより負荷の低いサーバーに移動します。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI 'SaveChangesMessage' 操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-11-22

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI SaveChangesMessage 操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

MAPI SaveChangesMessage 操作は、アプリケーションがサーバーにメッセージのコンテンツやプロパティを保存するときに呼び出されます。操作を完了するのに必要な時間は、書き込まれるデータ、書き込み先のデータベースおよびトランザクション ログのディスクの速度、およびリソースにボトルネックがあるかどうかによって変わってきます。

ユーザーが発行した MAPI SaveChangesMessage 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI SaveChangesMessage 操作が 30 秒を超えても、必ずしも問題となるわけではありません。メッセージ データや添付ファイルを大量に保存していると、MAPI SaveChangesMessage 操作に通常より長く時間がかかることがあります。遅延が頻繁に発生したり、メッセージング操作に悪影響を与える遅延が発生する場合、最も可能性が高いと思われる原因はディスクのボトルネックです。

詳細情報

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Exchange Server 2003 Performance and Scalability Guide』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server 2003 パフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (http://go.microsoft.com/fwlink/?linkid=72988) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

  • ディスクのサイズの変更、待ち時間、および入出力速度の詳細については、Microsoft Exchange Team Blog の Web サイトにある以下のページを参照してください。

    • ディスク サイズの基本概念についてのページ (http://go.microsoft.com/fwlink/?linkid=39538) (このサイトは英語の場合があります)

    • ディスク IO と計算に関する詳細な考慮事項についてのページ (http://go.microsoft.com/fwlink/?linkid=39539) (このサイトは英語の場合があります)

    • ディスク I/O 要件の計算方法についてのページ (http://go.microsoft.com/fwlink/?linkid=69747) (このサイトは英語の場合があります)


MAPI 'SetColumns' 操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が Exchange Server を実行している正常なサーバーで通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI SetColumns 操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

基本的なビューは、MAPI の SetColumns 呼び出しを使用して作成されます。SetColumns を呼び出すことによって、新規ビュー テーブルの列になるプロパティが定義されます。

ビューで最初にプロパティを要求するときに、サーバーはビューを生成するための追加動作を実行する必要があります。プロパティがビューに一度要求されたら、そのプロパティはその後ずっとビューに格納されたままになります。つまり、新しいプロパティが最初に要求される場合、SetColumns 呼び出しにはより多くの時間がかかることになります。これにかかる時間は、新しいプロパティの数およびフォルダ内のアイテム数に比例します。たとえば、メールボックスの移動後に、最初にユーザーが受信トレイを表示させた場合、サーバーではビューの生成により多くの時間がかかります。これはメールボックスの移動と共にビューは移動されないためです。ビューは作り直されます。

ビューへのプロパティの追加は、通常、非常にコストが高くなります。プロパティの追加コストは、フォルダ内のアイテム数および追加されるプロパティ数に比例します。Microsoft Office® Outlook® の通常の使用では Message Folder Table に多数のプロパティが追加されることはありませんが、手動でさらに多くのプロパティを追加することができます。通常これが問題となることはありません。ただし、アプリケーションによって列が頻繁に追加されたり、多数の列が追加される場合、またはクライアントによって複数の列が追加され、そこに多くのアイテムが関連する場合、遅延が発生する可能性があります。Message Folder Table 内の列が多くなればなるほど、フォルダ内のアイテムに対するすべての処理でより多くのオーバーヘッドがかかります。一度追加された列は削除できません。フォルダ内にアイテムを挿入する場合、Message Folder Table 内のすべてのプロパティがオーバーヘッドを発生させることになります。

ユーザーが発行した MAPI SetColumns 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

メールボックスが新しいデータベースまたは新しいサーバーに移動された後、ユーザーがメールボックスに最初にアクセスするときに、サーバーは新しいビューを作成する必要があります。この場合、SetColumns および Restrict 呼び出しに時間がかかることが予測されます。メールボックスを移動した後、数日間はこれらのエラーを無視してかまいません。

アプリケーションの中には、新しいビューを作成し、プロパティをストア データの内部構造に昇格させるものがあります。これは、サーバーがこのユーザーのデータにアクセスする際のパフォーマンスに長期にわたり影響を及ぼす可能性があります。特定のユーザーで頻繁に遅延が発生したり、メッセージング操作に悪影響を与える遅延が発生する場合は、原因を調べる必要があります。待ち時間が長くなっているユーザーと協力して、次のことを確認します。

  • フォルダ内のアイテム数が多いかどうか。

  • ユーザーはどのようなアプリケーションを実行しているか。

この問題を解決するには、次の手順に従います。

  • フォルダ内のアイテム数が多い場合は、ユーザーに各フォルダのアイテム数を減らすように指示します。受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5,000 未満にすることをお勧めします。

  • 最もコストの高い操作を行うクライアント コンピュータでは Exchange キャッシュ モードが使用されるように構成します。Restrict、SetColumns、または FindRow 操作で長い待ち時間が生じるクライアント コンピュータに特に注意します。Exchange キャッシュ モードは、ほとんどの超過 RPC トラフィックからサーバーを分離します。

  • すべてのアプリケーションを終了します。次に、これらのアプリケーションを 1 つずつ起動し、問題の原因となっているアプリケーションを特定します。次のいずれかの条件に当てはまる場合は、そのアプリケーションの使用を完全に中止するか、あるいはアプリケーションを更新して、負荷を適切なレベルに低下させます。

    • アプリケーションが業務に必要ではない。

    • アプリケーションの修正プログラムが公開されている。

注 :
一部のアプリケーションは、多くの MAPI 操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、多くの MAPI 操作を発行したわけではないにもかかわらず、CPU に高い影響を与えているユーザーを報告します。

また、リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在する場合も、SetColumns 操作の待ち時間が長くなることに注意してください。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI 同期操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI 同期操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

MAPI 同期操作は、Microsoft Office® Outlook® オフライン フォルダ ファイル (.ost) またはユーザーのメールボックスのローカル コピーをサーバー上のユーザーのメールボックス データと同期させるために実行します。

MAPI 同期操作が 30 秒を超えても、必ずしも問題となるわけではありません。既定では、Outlook 2003 で初めて Exchange キャッシュ モードを有効にしたときに、Exchange Server に格納されたすべての電子メール メッセージ、およびグローバル アドレス一覧の完全コピーがユーザーのコンピュータにダウンロードされます。

Exchange Server との最初の同期中に、Outlook 2003 ユーザーに応答の遅延が発生することがあります。

キャッシュ モードの最初の同期の後にも、ユーザーが頻繁に遅延に遭遇したり、メッセージング操作に悪影響を及ぼす遅延が発生する場合は、これらの MAPI 同期操作の遅延を詳しく調査し、待ち時間の問題が、リソースのボトルネックなどさらに重大な問題を示すものでないことを確認します。

リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在すると、MAPI 同期操作の待ち時間は常に長くなります。サーバー リソースのボトルネックを確認し、サーバー リソースの処理能力を増やすか、ユーザーをより負荷の低いサーバーに移動します。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server 2003 のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAPI 'TaskQ' 操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-20

Microsoft Exchange アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が正常な Exchange サーバー上で通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange アナライザは ExMon データを確認し、ユーザーが発行した MAPI TaskQ 操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

TaskQ 操作は、RPC コールのコンテキスト外で実行される非同期タスクです。TaskQ および TaskQ User Unknown 操作は、Exchange の要求によって実行されるタスクで、ストアの保守が含まれます。TaskQ User Known 操作は、ユーザーによる直接の要求によって実行される非同期タスクです。検索フォルダの作成、並べ替え、さらに移動、コピー、削除、および複数メッセージを既読としてマークするなどの一括操作を行います。

ユーザーが発行した MAPI TaskQ 操作のうち、完了までに 30 秒を超えるものがあると判断されると、Exchange アナライザによって警告が表示されます。

一般的に TaskQ 操作は完了までに時間がかかるため、必ずしもパフォーマンス上の問題を示しているとは限りません。

この問題に対処するには、次の操作を行います。

  • ExMon ツールを使用してさらに多くのデータ サンプルを取得し、Exchange Server アナライザで調査することを検討します。Exchange では大量のデータが生成されるため、データ収集のサンプリングの時間は 30 分以下にすることをお勧めします。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)

  • Microsoft Exchange Server パフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)

  • Exchange Server 2003 パフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)


MAPI 'Restrict' 操作によって操作に時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-23

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ユーザー モニタ (ExMon) ツールを使用して、ユーザーの MAPI 操作が Exchange Server を実行している正常なサーバーで通常予期される時間より長くかかっているかどうかを判断します。

この分析の一環として、Exchange Server アナライザは ExMon データを確認し、ユーザーが発行した MAPI Restrict 操作のうち、完了までに 30 秒を超えるものがあるかどうかを調べます。

MAPI Restrict 操作は、クライアント アプリケーションが特定の条件を満たす項目を選択するために使用します。この操作によってサーバーはビューを作成しますが、実際作成されるのは、"制限" という条件が付加されたテーブルになります。一致する制限を持つビューが既にある場合は、サーバーは既存のビューを使用してユーザー要求を満たします。サーバーがこの既存のビューを使用する場合は、ビューを新たに作成するよりもコストが低くなります。既定では、ストアはフォルダごとに 11 のビューのみをキャッシュします。サーバーは 12 番目のビューの作成を要求されると、キャッシュされたビューのうち最も古いものを削除して新しいビューを作成します。ビューが存在すると、アイテムに対するすべての処理でオーバーヘッドが増加します。

ユーザーが発行した MAPI Restrict 操作のうち 30 秒を超えるものが検出されると、Exchange Server アナライザによってエラーが表示されます。

MAPI Restrict 操作が 30 秒を超えても、必ずしも問題となるわけではありません。ただし、ユーザーが頻繁に遅延に遭遇したり、メッセージング操作に悪影響を及ぼす遅延が発生する場合は、ユーザーのアプリケーションが原因で新規ビューが作成されていることを示している可能性があります。

このエラーを解決するには、待ち時間が長くなっているユーザーと協力して、次のことを確認します。

  • フォルダ内のアイテム数が多いかどうか。

  • ユーザーはどのようなアプリケーションを実行しているか。

この問題を解決するには、次の手順に従います。

  • フォルダ内のアイテム数が多い場合は、ユーザーに各フォルダのアイテム数を減らすように指示します。受信トレイ、予定表、送信済みアイテム、連絡先、および削除済みアイテムのフォルダに保存するアイテムは、5,000 未満にすることをお勧めします。

  • 最もコストの高い操作を行うクライアント コンピュータでは Exchange キャッシュ モードが使用されるように構成します。Restrict、SetColumns、または FindRow 操作で長い待ち時間が生じるクライアント コンピュータに特に注意します。Exchange キャッシュ モードは、ほとんどの超過 RPC トラフィックからサーバーを分離します。

  • 下記の Exchange Team Blog に記述されている指示に従って、イベント ログで制限のトレースを有効にします。その後、ユーザーのアプリケーションを 1 つずつ起動し、どのアプリケーションが原因で制限の実行時間が長くなっているかを追跡します。

  • すべてのアプリケーションを終了します。次に、これらのアプリケーションを 1 つずつ起動し、問題の原因となっているアプリケーションを特定します。次のいずれかの条件に当てはまる場合は、そのアプリケーションの使用を完全に中止するか、あるいはアプリケーションを更新して、負荷を適切なレベルに低下させます。

    • アプリケーションが業務に必要ではない。

    • アプリケーションの修正プログラムが公開されている。

注 :
一部のアプリケーションは、多くの MAPI 操作を発行することなく、サーバーの負荷を大幅に増大させる場合があります。これは、特定の操作で他の操作よりも多くのコストがかかるためです。コストの高い操作の数がわずかに増えるだけで、サーバーのパフォーマンスに大きな影響を与える可能性があります。ExMon では、多くの MAPI 操作を発行したわけではないにもかかわらず、CPU に高い影響を与えているユーザーを報告します。

また、リソースのボトルネック (一般的にはディスクや CPU のボトルネック) が存在する場合も、Restrict 操作の待ち時間が長くなることに注意してください。

詳細情報

MAPI Restrict 操作の詳細については、Microsoft Exchange Team Blog の "制限" に制限をかけることについてのページ (http://go.microsoft.com/fwlink/?linkid=55098) を参照してください (このサイトは英語の場合があります)。

注 :
それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

詳細については、以下の Exchange Server リソースを参照してください。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の可能性があります)

  • Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の可能性があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 905803「Exchange Server を実行しているサーバーの多くの項目を含むフォルダを操作するとき、不十分のパフォーマンスが Outlook ユーザーに発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)


MAD.EXE ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


MAD NSPI ポートの値が 5,000 未満である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange System Attendant サービスの TCP/IP NSPI Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

TCP/IP NSPI Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

TCP/IP NSPI Port を静的な値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。5,000 未満の静的なポート番号を割り当てると、ポートが別のプロセスと競合して、Exchange System Attendant サービス プロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP NSPI Port のレジストリ キーを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP NSPI Port キーをダブルクリックし、[値のデータ] ボックスを 5,000 (10 進数) を超える整数に設定します。

  4. レジストリ エディタを終了します。

  5. Microsoft Exchange System Attendant サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ポートの制限の詳細については、Microsoft サポート技術情報の文書番号 194952「[XADM] Exchange Server の静的に割り当てられるポートの制限」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952) を参照してください。


MAD RFR ポートが手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange System Attendant のディレクトリ参照ポートの値が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

TCP/IP Port が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook® 2003 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。この構成はサポートされています。MAPI クライアントがファイアウォール経由で Exchange に接続できるように構成する方法の詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。このシナリオを使用しない場合、レジストリ キーを削除する必要があります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、および Windows® XP Professional にある RPC over HTTP (Remote Procedure Call over Hypertext Transfer Protocol) 機能を使用することをお勧めします。MAPI モードは、以前は企業またはワークグループ モードと呼ばれていました。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP ポートのレジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP Port というレジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange System Attendant サービスを再開します。

RPC over HTTPS を展開するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  3. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  4. Microsoft Support Web Cast「[OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MAD RFR ポートが 5,000 未満である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange System Attendant サービスの TCP/IP Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

TCP/IP Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

TCP/IP Port を静的な値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。静的ポート番号に 5,000 未満の値を割り当てると、別のプロセスとの間でポートが競合し、Microsoft Exchange System Attendant サービスのプロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP Port レジストリ キーを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP Port キーをダブルクリックし、[値のデータ] ボックスの値を 5,000 (10 進数) より大きい整数に設定します。

  4. レジストリ エディタを終了します。

  5. Microsoft Exchange System Attendant サービスを再開して、この変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ポート設定の詳細については、マイクロソフト サポート技術情報の文書番号 194952「[XADM] Exchange Server の静的に割り当てられるポートの制限」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952) を参照してください。


bin フォルダに MAPI32.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


system32 フォルダに MAPI32.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


MAPISTUB.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


MAPISP32.EXE ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


ESE の最大キャッシュ サイズが 1.2 GB より大きい
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、DataBase パフォーマンス オブジェクトの DataBase Cache Size (DBCacheSize) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

DataBase Cache Size (DBCacheSize) パフォーマンス カウンタは、ストアによって使用されている現在のキャッシュ サイズを表します。DataBase Cache Size (DBCacheSize) パフォーマンス カウンタの値が 307200 (1.2 GB) より大きいことが検出されると、Exchange Server アナライザによってエラーが表示されます。

このエラーは、Microsoft Exchange Information Store (MSExchangeIS) オブジェクトの msExchESEParamCacheSizeMax 属性の値が、推奨される最大値の 307200 (1.2 GB) を超えたことを示しています。

ストア データベース キャッシュは、ESE (Extensible Storage Engine) バッファとも呼ばれます。これは、データベースにコミットされる前にデータベース トランザクションをキャッシュします。

Exchange 2000 Server では、Store.exe によって使用される大きな仮想メモリ領域が、ESE バッファに割り当てられます。Exchange 2000 Server は、このバッファのためにハード コードされた既定値の 858 MB を使用します。Exchange Server 2003 では、ESE バッファの割り当ては、Boot.ini ファイル内に /3GB スイッチが記述されているかどうかに基づいて行われます。/3GB スイッチがある場合、ESE バッファは 896 MB に調整されます。/3GB スイッチがない場合、ESE バッファは 576 MB に調整されます。自動調整は常に有効ですが、自動調整を無効にして、実際の環境により適した値を手動で設定したい場合があります。

この値は、割り当てられる実際のメモリが 8,192 バイトの倍数になるような任意の数値に調整できますが、次の表に示した値のみを使用することをお勧めします。

推奨値 | メモリ割り当て量 | コメント
147456 | 576 MB | 最小推奨値です。これよりも小さい値は設定しないでください。この値は、仮想メモリに制約があるサーバー、および Microsoft Windows® 2000 Server 上で実行されている Exchange Server 2003 コンピュータで有効です。Windows 2000 Server は、/3GB スイッチをサポートしていません。この値は、/3GB スイッチを使用していないシステムに対する既定値でもあります。
196608 | 768 MB | これは、大容量の仮想メモリを持ち、イベント 9582 が頻繁にログに記録されるサーバーで推奨される値です。
219726 | 858 MB | これは Exchange 2000 Server の既定値です。これは、大量の仮想メモリを使用しており、インプレース アップグレードを実施中のシステムで使用するのに適した値です。
229376 | 896 MB | これは Exchange Server 2003 の既定値です。アプリケーション イベント ログにイベント 9582 が存在するために他の値が適切だとわかる場合を除き、新しいシステムで使用するのに適した値です。
307200 | 1.2 GB | 設定可能な最大値です。この値は、物理メモリを 2 GB 以上搭載したシステムでのみ使用してください。

この値を構成し直す前に、Store.exe プロセスによって消費される仮想メモリの量を監視する必要があります。このためには、Microsoft Windows の Process パフォーマンス オブジェクトを監視します。/3GB スイッチを使用するシステムでは、Process オブジェクトの Store.exe インスタンスの Virtual Bytes カウンタが 2.8 GB 未満であることが必要です。/3GB スイッチを使用しないシステムでは、Process オブジェクトの Store.exe インスタンスの Virtual Bytes カウンタが 1.8 GB 未満であることが必要です。値がこれらの量より大きい場合は、msExchESEParamCacheSizeMax の値を減らすことが必要な場合があります。値がこれらの量より小さい場合は、msExchESEParamCacheSizeMax の値を増やすことができます。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory® オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
msExchESEParamCacheSizeMax 属性を調整するには、次の操作を行います。

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックします。

  3. [CN=Services] を展開します。

  4. [CN=Microsoft Exchange] を展開します。

  5. [CN=<Exchange 組織名>] を展開します。

  6. [CN=Administrative Groups] を展開します。

  7. [CN=<管理グループ名>] を展開します。

  8. [CN=Servers] を展開します。

  9. [CN=<Exchange サーバー名>] を展開します。

  10. [CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  11. [属性] ボックスで、[msExchESEParamCacheSizeMax] までスクロールしてダブルクリックします。

  12. [値] ボックスに、設定する値を入力します。上の表を使用して、システムに最適な値を判断します。

  13. [OK] をクリックし、再度 [OK] をクリックします。

  14. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

メモリ使用量の最適化の詳細については、『Planning a Microsoft Exchange Server 2003 Messaging System』(http://go.microsoft.com/fwlink/?LinkId=47584) の「Optimizing Memory Usage for Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。

msExchESEParamCacheSizeMax 属性の詳細については、Microsoft サポート技術情報の文書番号 266768「Exchange 2000 Server でストア データベースの最大キャッシュ サイズを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768) を参照してください。


最大受信者数の制限が変更されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchRecipLimit 属性が既定値から変更されているかどうかを判断します。msExchRecipLimit 属性は、各電子メール メッセージに対するグローバルな受信者の最大数の値を格納します。既定では、msExchRecipLimit 属性の値は 5000 です。Exchange Server アナライザによって、msExchRecipLimit 属性値が 5000 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

グローバルな最大受信者数の制限は、Exchange 組織全体に適用されます。msExchRecipLimit 属性値は、1 通の電子メール メッセージに対する受信者の数を制限します。グローバルな最大受信者数の制限は、システム メッセージとシステム メッセージ以外のメッセージに影響します。システム メッセージには、パブリック フォルダのレプリケーション メッセージが含まれます。

注 :
受信者数の制限は、Active Directory ユーザーとコンピュータを使用して、ユーザー単位で設定することもできます。ユーザー単位の設定はグローバル設定よりも優先され、グローバル設定を上書きします。既定では、ユーザー単位の受信者数の制限は、グローバルな最大受信者数の制限を使用するように設定されています。
注 :
SMTP (Simple Mail Transfer Protocol) 仮想サーバーでは、インターネット ユーザーから受信したメッセージに対し、受信者数の制限をメッセージ単位で設定できます。この制限は、グローバルな最大受信者数の制限やユーザー単位の受信者数の制限とは異なります。グローバルな最大受信者数の制限とユーザー単位の受信者数の制限は、どちらも Exchange ユーザーがメッセージを送信できる相手の数を制限します。
グローバルな最大受信者数の制限を既定値に変更するには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインで、[グローバル設定] を展開します。

  3. [メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  4. [既定] タブで、[受信者の制限] の [最大受信者数] をクリックします。次に、「5000」と入力します。

  5. Microsoft Exchange Information Store サービスを再開します。

受信者の制限の設定と Microsoft Office Outlook® Web Access クライアントの構成の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?LinkId=47574) の「Outlook Web Access S/MIME Control-Related Settings」を参照してください (このサイトは英語の場合があります)。

最大受信者数の制限に関する過去のできごとについては、Exchange Weblog の「Me Too!」(http://go.microsoft.com/fwlink/?LinkId=41848) を参照してください (このサイトは英語の場合があります)。


最大受信者数の制限値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、メッセージのmsExchRecipLimit 値が 7500 を超えているかどうかを判断します。msExchRecipLimit 属性の値が 7500 より大きいことが検出されると、警告が表示されます。

msExchRecipLimit 属性は、各電子メール メッセージに対するグローバルな受信者の最大数の値を格納します。この値は、1 通の電子メール メッセージの受信者の数を制限します。システム メッセージもそれ以外のメッセージも、この値の影響を受けます。システム メッセージには、パブリック フォルダのレプリケーション メッセージが含まれます。既定では、msExchRecipLimit 属性の値は 5000 です。

msExchRecipLimit 属性値が 7,500 を超えている場合は、受信者数の多いメッセージが原因となる問題が生じる危険性が高まります。

注 :
受信者数の制限は、Active Directory ユーザーとコンピュータを使用して、ユーザー単位で設定することもできます。ユーザー単位の設定はグローバル設定よりも優先され、グローバル設定を上書きします。既定では、ユーザー単位の受信者数の制限は、グローバルな最大受信者数の制限を使用するように設定されています。
注 :
SMTP (Simple Mail Transfer Protocol) 仮想サーバーでは、インターネット ユーザーから受信したメッセージに対し、受信者数の制限をメッセージ単位で設定できます。この制限は、グローバルな最大受信者数の制限やユーザー単位の受信者数の制限とは異なります。グローバルな最大受信者数の制限とユーザー単位の受信者数の制限は、どちらも Exchange ユーザーがメッセージを送信できる相手の数を制限します。
グローバルな最大受信者数の制限を既定値に変更するには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインで、[グローバル設定] を展開します。

  3. [メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  4. [既定] タブで、[受信者の制限] の [最大受信者数] をクリックします。次に、「5000」と入力します。

  5. Microsoft Exchange Information Store サービスを再開します。

受信者の制限の設定と Microsoft Office Outlook® Web Access クライアントの構成の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?LinkId=47574) の「Outlook Web Access S/MIME Control-Related Settings」を参照してください (このサイトは英語の場合があります)。

グローバルな最大受信者数の制限に関する過去のできごとについては、「Me Too!」(http://go.microsoft.com/fwlink/?LinkId=41848) を参照してください (このサイトは英語の場合があります)。


最大受信者数の制限が厳しすぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、メッセージに対する msExchRecipLimit 値が、Exchange 組織のパブリック フォルダ ストア数より小さいかどうかを判断します。msExchRecipLimit 属性値がパブリック フォルダ ストアの数より小さいことが検出されると、エラーが表示されます。

msExchRecipLimit 属性は、各電子メール メッセージに対するグローバルな受信者の最大数の値を格納します。この値は、1 通の電子メール メッセージの受信者の数を制限します。システム メッセージもそれ以外のメッセージも、この値の影響を受けます。システム メッセージには、パブリック フォルダのレプリケーション メッセージが含まれます。既定では、msExchRecipLimit 属性の値は 5,000 です。msExchRecipLimit 属性の値が Exchange 組織のパブリック フォルダ ストアの数よりも小さいと、パブリック フォルダ階層のレプリケーションに問題が発生します。

注 :
受信者数の制限は、Active Directory ユーザーとコンピュータを使用して、ユーザー単位で設定することもできます。ユーザー単位の設定はグローバル設定よりも優先され、グローバル設定を上書きします。既定では、ユーザー単位の受信者数の制限は、グローバルな最大受信者数の制限を使用するように設定されています。
注 :
SMTP (Simple Mail Transfer Protocol) 仮想サーバーでは、インターネット ユーザーから受信したメッセージに対し、受信者数の制限をメッセージ単位で設定できます。この制限は、グローバルな最大受信者数の制限やユーザー単位の受信者数の制限とは異なります。グローバルな最大受信者数の制限とユーザー単位の受信者数の制限は、どちらも Exchange ユーザーがメッセージを送信できる相手の数を制限します。
グローバルな最大受信者数の制限を既定値に変更するには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインで、[グローバル設定] を展開します。

  3. [メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  4. [既定] タブで、[受信者の制限] の [最大 (受信者数)] をクリックし、値が Exchange 組織のパブリック フォルダ ストアの数より小さくないことを確認します。

  5. Microsoft Exchange Information Store サービスを再開します。

受信者の制限の設定と Microsoft Office Outlook® Web Access クライアントの構成の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?LinkId=47574) の「Outlook Web Access S/MIME Control-Related Settings」を参照してください (このサイトは英語の場合があります)。

グローバルな最大受信者数の制限に関する過去のできごとについては、「Me Too!」(http://go.microsoft.com/fwlink/?LinkId=41848) を参照してください (このサイトは英語の場合があります)。


MaxUserPort キーがないか、既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-23

Microsoft Exchange アナライザ ツールは Active Directory ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて、serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータでは Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 を実行しています。文字列値に "Version 8.0" が含まれている場合、コンピュータでは Exchange Server 2007 を実行しています。

次に、Exchange アナライザ ツールは、見つかった各 Exchange Server 2007 サーバーの次のレジストリを読み取り、MaxUserPort キーの値が既定値の 60000 に設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

MaxUserPort キーは、アプリケーションがシステムに使用可能なユーザー ポートを要求したときに TCP が割り当てることのできる最大のポート番号を決定します。

既定では、Microsoft Windows Server 2003 は MaxUserPort 値を 5000 に設定します。Microsoft Windows 2000 は、レジストリに MaxUserPort 値を追加しません。ただし、この値を手動で追加できます。Windows Server 2003 上および Windows 2000 Server 上では、Exchange Server 2003 と Exchange Server 2007 はこの既定値を 60000 に設定します。Exchange 2000 Server はこの値を設定しません。

MaxUserPort 値を 60000 に設定することをお勧めします。MaxUserPort 値を 60000 未満に設定すると、イベント 9040 などの NSPI (Name Service Provider Interface) のプロキシ警告が発生する場合があります。次の表にイベント 9040 を示します。

イベント ID | 9040
イベント分類 | NSPI プロキシ
イベント ソース | MSExchangeSA
イベントの種類 | 警告
イベントの説明 | パケットの受信中に、NSPI プロキシによってエラーが検出されました。対象のドメイン コントローラ、ネットワーク、またはクライアントが停止している可能性があります。Winsock サブシステムからエラー [0x2746] が返されました。このエラーを受信した回線は閉じられています。
重要 :
このトピックには、レジストリの編集に関する説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. [MaxUserPort] をダブルクリックし、[値のデータ] ボックスに 60000 (10 進数) を設定します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、コンピュータを再起動してこの設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この問題は、「TcpTimedWaitDelay キーがないか、既定値ではない」というアナライザの問題に関連しています。

MaxUserPort および TcpTimedWaitDelay レジストリ キーが及ぼす影響の詳細については、Windows 2000 リソース キットの伝送制御プロトコルについてのトピック (http://go.microsoft.com/fwlink/?LinkId=85654) を参照してください (このサイトは英語の場合があります)。


MaxUserPort 値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、TCP ephemeral ポートの最大値を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort

ephemeral ポートは、短期間だけ使用されるポートです。

Exchange Server アナライザによって、MaxUserPort レジストリ キーの値が 50,000 未満であることが検出されると、警告が表示されます。

MaxUserPort の値は、アプリケーションがシステムに使用可能なユーザー ポートを要求したときに TCP が割り当てることのできる最大のポート番号を示します。通常、ephemeral ポートには、ポート番号 1024 ～ 5000 が割り当てられます。

既定では、Microsoft Windows Server™ 2003 は MaxUserPort 値を 5000 に設定します。Microsoft Windows® 2000 は、レジストリに MaxUserPort 値を追加しません。MaxUserPort 値は、レジストリに手動で追加できます。ただし、Windows Server 2003 および Windows 2000 Server では、Exchange Server 2003 はこの既定値を 60000 に設定します。Exchange 2000 Server はこの値を設定しません。

MaxUserPort 値を 60000 に設定することをお勧めします。MaxUserPort 値を 60000 未満に設定すると、イベント 9040 などの NSPI (Name Service Provider Interface) のプロキシ警告が発生する場合があります。次の表にイベント 9040 を示します。

イベント ID | 9040
イベント分類 | NSPI プロキシ
イベント ソース | MSExchangeSA
イベントの種類: | 警告
イベントの説明 | パケットの受信中に、NSPI プロキシによってエラーが検出されました。対象のドメイン コントローラ、ネットワーク、またはクライアントが停止している可能性があります。Winsock サブシステムからエラー [0x2746] が返されました。このエラーを受信した回線は閉じられています。

この警告を修正するには、MaxUserPort レジストリ キーの値を 60000 に設定します。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. [MaxUserPort] をダブルクリックし、[値のデータ] フィールドに ea60 (16 進数) を設定します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、コンピュータを再起動してこの設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MDBSZ.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


Memory パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Memory パフォーマンス オブジェクトの Available Mbytes パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、次の状況のいずれかの組み合わせが当てはまります。

  • Memory パフォーマンス オブジェクトが無効になっている。

  • Memory パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能カウンタによってレジストリが破壊された場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによってレジストリが変更された場合に発生する可能性があります。

この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. Memory パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) の説明に従って、存在しないパフォーマンス カウンタまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書に従っても問題を解決できない場合は、Windows オペレーティング システムを修復モードで再インストールし、最新の Windows Service Pack を適用する必要があります。


MSExchangeDSAccess Processes パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess パフォーマンス オブジェクトの LDAP Read Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、次の状況のいずれかの組み合わせが当てはまります。

  • MSExchangeDSAccess パフォーマンス オブジェクトが無効になっている。

  • MSExchangeDSAccess パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能カウンタによってレジストリが破壊された場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによってレジストリが変更された場合に発生する可能性があります。以下の手順は、最初の 2 つの状況を修正する方法を説明しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。

Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. MSExchangeDSAccess パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードしてインストールします。 You can download Exctrlst.exe at Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) でダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) の説明に従って、存在しないパフォーマンス カウンタまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書に従っても問題を解決できない場合は、Exchange Server を修復モードで再インストールし、最新の Exchange Server Service Pack を適用する必要があります。


MSExchangeIS Mailbox パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS Mailbox パフォーマンス オブジェクトの Send Queue Size パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、次の状況のいずれかの組み合わせが当てはまります。

  • MSExchangeIS Mailbox パフォーマンス オブジェクトが無効になっている。

  • MSExchangeIS Mailbox パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能カウンタによってレジストリが破壊された場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによってレジストリが変更された場合に発生する可能性があります。

この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. MSExchangeIS Mailbox パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) の説明に従って、存在しないパフォーマンス カウンタまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書に従っても問題を解決できない場合は、Exchange Server を修復モードで再インストールし、最新の Exchange Server Service Pack を適用する必要があります。


MSExchangeIS パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-03

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの RPC Operations/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、次の状況のいずれかの組み合わせが当てはまります。

  • MSExchangeIS パフォーマンス オブジェクトが無効になっている。

  • MSExchangeIS パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能カウンタによってレジストリが破壊された場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによってレジストリが変更された場合に発生する可能性があります。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. MSExchangeIS パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、Exctrlst.exe (Extensible Performance Counter List) についてのページ (http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) の説明に従って、存在しないパフォーマンス カウンタまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書に従っても問題を解決できない場合は、Exchange Server を修復モードで再インストールし、最新の Exchange Server Service Pack を適用する必要があります。

Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングの詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題をトラブルシューティングする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。


MSExchangeIS Public パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS Public パフォーマンス オブジェクトの Send Queue Size パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、以下の状況のいずれかまたは複数が発生しています。

  • MSExchangeIS Public パフォーマンス オブジェクトが無効になっている。

  • MSExchangeIS Public パフォーマンス モニタ オブジェクトが存在しないか、破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能なカウンタによりレジストリが破壊されている場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによりレジストリが変更されている場合に発生する可能性があります。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. MSExchangeIS Public パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List tool (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) に記載されている手順に従って、存在しないまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Exchange Server を修復モードで再インストールしてから、最新の Exchange Server Service Pack を適用する必要があります。


MSGINA.DLL ドライバの更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server を実行しているサーバー上で実行されている Microsoft Windows® のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Exchange サーバーでは Microsoft Windows NT® Server 4.0 が実行されていることを示します。値が 5.0 の場合、Exchange サーバーでは Windows 2000 Server が実行されていることを示します。値が 5.2 の場合、Exchange サーバーでは Windows Server 2003™ が実行されていることを示します。

また、Exchange Server アナライザは、Win32_OperatingSystem Microsoft WMI （Windows® Management Instrumentation) クラスを調べて、ServicePackMajorVersion キーの値を判断します。

ServicePackMajorVersion キーの値が 1 の場合、サーバーには Service Pack 1 (SP1) がインストールされていることを示します。

さらに、Exchange Server アナライザは、CIM_Datafile WMI クラスを照会して、Msgina.dll ファイルの Version キーの値を判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • サーバーで Windows Server™ 2003 SP1 が実行されている。

  • Msgina.dll ファイルのビルド番号が 5.2.3790.2525 より小さい。

このエラーは、サーバーにインストールされている Msgina.dll のバージョンが古いために過剰なページ ファイル操作が発生し、パフォーマンスが低下する可能性があることを示します。

この問題を解決するには、マイクロソフト サポート技術情報の文書番号 905865 の、Windows Server 2003 を実行しているコンピュータでターミナル サービスを使用してログオンまたはログオフするときにコンソール セッションのすべてのプロセスのワーキング セットのサイズが小さくなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905865) に示されている更新プログラムを入手します。


MTA の APDU logging required パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\APDU logging required

APDU logging required の値が存在し、0 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

アプリケーション プロトコル データ ユニット (APDU) テキスト ログは、異なるサイトの Exchange メッセージ転送エージェント (MTA) 間や、サイト内の MTA とクライアント アプリケーション間の通信をバイナリで表現したものです。APDU ログは、MTA での問題を診断する手段になります。ただし、APDU ログを活用するには、X.400 プロトコルの ASCII 変換に精通している必要があります。

APDU logging required レジストリ パラメータが存在し、0 に構成されていると、MTA が送受信するすべての APDU は MTADATA\BF*.LOG にバイナリ データとして記録されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の MTA APDU ログ構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、APDU logging required 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

APDU ログの詳細については、Microsoft サポート技術情報の文書番号 163324「[XCON] Application Protocol Data Unit(APDU) のログ (BF0.LOG)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=163324) を参照してください。


MTA の Call-stack diagnostics required パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Call-stack diagnostics required

Call-stack diagnostics required の値が存在し、1 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Call-stack diagnostics required レジストリ値は、詳細なデバッグ目的にのみ使用され、この値の読み取りを行うのはデバッグ バージョンのメッセージ転送エージェント (MTA) のみです。値データは常に 1 であることが必要です。デバッグ バージョンの MTA が使用されるときには、この値によって、終了時に各 MTA スレッドに対してコール スタックが提供されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Call-stack diagnostics required] 値を見つけてダブルクリックします。

  4. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA コンピュータ名が一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、メッセージ転送エージェント (MTA) の Computer 値の設定を判断します。HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange サーバー オブジェクトの name 属性値を判断します。

最後に、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。値が True の場合、クラスタ サービスが開始されていることを示し、値が False の場合、クラスタ サービスが実行されていないことを示します。

Exchange Server アナライザによって、Windows サーバー クラスタ内では実行されていない任意の Exchange Server コンピュータについて、MTA Computer キーの値が、Active Directory 内にあるサーバー オブジェクトの name 属性の値と一致していないことが検出されると、エラーが表示されます。

このエラーを修正するには、Active Directory 内にある name 属性値と一致するように、MTA Computer レジストリ キーを編集する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、[MTA Computer] をダブルクリックし、このコンピュータの正しい名前を入力します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の Concurrent connections to LAN-MTAs パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent connections to LAN-MTAs

Concurrent connections to LAN-MTAs の値が存在し、0x28 (16 進数) または 40 (10 進数) 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Concurrent connections to LAN-MTAs レジストリ値は、ローカル エリア ネットワーク (LAN) を経由したメッセージ転送エージェント (MTA) への同時接続の最大数を決定するものです。LAN 経由で通信を行う MTA を LAN-MTAs と呼びます。ローカル MTA の構成とシステムの負荷によっては、1 つのリモート MTA に対して複数の接続が存在することがあります。LAN ベースの MTA 同時接続の最大数は 240 です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の MTA Concurrent 接続構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Concurrent connections to LAN-MTAs] 値を見つけ、ダブルクリックします。

  4. [表記] が 16 進に設定されていることを確認し、[値のデータ] ボックスに「28」と入力します。次に、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

LAN ベースの MTA 同時接続の最大数の詳細については、Microsoft サポート技術情報の文書番号 243402「XCON: Exchange Server イベント MTA ID 9280」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=243402) を参照してください。


MTA の Concurrent connections to X.400 gateways パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent connections to X.400 gateways

Concurrent connections to X.400 gateways の値が存在し、6 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Concurrent connections to X.400 gateways レジストリ値は、リモートの X.400 メッセージ転送エージェント (MTA) に接続できる最大同時接続数です。大半の組織では、既定値の 6 で十分です。Concurrent connections to X.400 gateways の値を 0x12 (16 進数) または 18 (10 進数) に変更する必要がある Exchange Server Version 5.5 が実行されているサーバーで、EDK コネクタを 5 つ以上使用する場合には、問題が起きることがわかっています。この問題の詳細については、Microsoft サポート技術情報の文書番号 282115「4 つ以上の Exchange EDK コネクタがインストールされる場合、メール フローが停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=282115) を参照してください。上記の文書に説明されている問題が発生していない限り、Concurrent connections to X.400 gateways レジストリ値は 6 のままにしておいてください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Concurrent connections to X.400 gateways] 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「6」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の Concurrent MDB/delivery queue clients パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Concurrent MDB/delivery queue clients

Concurrent MDB/delivery queue clients の値が存在し、3 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Concurrent MDB/delivery queue clients 値は、MTA (メッセージ転送エージェント) がサポートできるメッセージング データベース (MDB) クライアントおよび Exchange API メッセージ アクセス配信キュー クライアントの最大数です。各クライアントが複数のセッションを持つことができます。プライベートおよびパブリック MDB エンティティをサポートするには、この値を少なくとも 2 に設定する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、Concurrent MDB/delivery queue clients 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「3」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA データ ファイルが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、メッセージ転送エージェント (MTA) データ パスの Compressed キーの値を判断します。Compressed キーの値が True であると判断されると、エラーが表示されます。

Microsoft は、NTFS ファイルシステムの圧縮ボリュームに Exchange データ ファイルを格納することをサポートしていません。圧縮されたボリュームに Exchange のデータ ファイルを格納すると、追加されるオーバーヘッドによって Exchange のパフォーマンスに大きな影響があります。さらに、Exchange ストア データベースの大きさが特定のサイズ (約 4 GB) に達すると、マウントされない場合が生じたり、破損したりする可能性があります。

Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

ESE (Extensible Storage Engine) で管理されているファイルは、圧縮ドライブに格納するようには設計されていません。ESE は、ログ ベースの回復をセクタの独立性に依存しており、ファイルを圧縮することによりセクタの独立性は無効になります。ESE データベースをホストしているボリュームや、先行書き込みログを使用しているデータベースでは、圧縮を有効にしないでください。

Exchange 2000 Server Service Pack 3 のリリース以前は、圧縮された Exchange ストア データベースをマウントすることは不可能でした。ただし、NTFS 圧縮を使用して圧縮されていた任意の Exchange 2000 の Exchange ストア データベースやログで破損が生じる可能性がありました。

Exchange 2000 Server Service Pack 3 の使用時には、128 MB 以下の圧縮されたインフォメーション ストア データベース ファイルで、自動的に圧縮が解除されます。データベース ファイルが大きくなり 128 MB を超えると、データベースはマウントされず、アプリケーション ログにエラー メッセージが生成されます。Exchange 2000 Server Service Pack 3 では、128 MB を超える圧縮ファイルはマウントできません。

指定されたフォルダに対するファイル圧縮を無効にするには

  1. ファイルの圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

MTA データベース ファイルを移動するには

  1. Exchange Server Version 5.5 では、パフォーマンス オプティマイザ ツールを使用して MTA データベース ファイルを移動できます。Exchange 2000 Server または Exchange Server 2003 でこの操作を行う方法の詳細については、Microsoft サポート技術情報の文書番号 259896「[XCON] MTA Database および MTA Run Directory の場所を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=259896) を参照してください。

Exchange データ ファイルと NTFS 圧縮の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 170009「XADM: NTFS は、エラーの ボリューム原因格納を圧縮しました。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=170009)

  • 文書番号 327772「[XADM] SP3 を適用後にデータベースがマウントせずエラー 0xfffff05b が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327772)


MTA データ ファイルが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、メッセージ転送エージェント (MTA) データ パスの Encrypted キーの値を判断します。このキーの値が True であることが検出されると、エラーが表示されます。

Exchange 2000 Server または Exchange Server 2003 コンピュータでは、MTA ファイルは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\MTAdata

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームに Exchange データ ファイルを格納することをサポートしていません。Exchange データ ファイルを暗号化ボリュームに格納するとオーバーヘッドが増え、Exchange のパフォーマンスに大きく影響します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティ保護に役立てるため、Exchange コンピュータに対する権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

指定されたフォルダでのファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange Server のデータ ファイルと EFS の詳細については、Microsoft サポート技術情報の文書番号 834638「ストレージに関するデータの情報は、暗号化されたボリュームに Exchange でサーバーを提出します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Microsoft Exchange Server 2003 でメッセージをセキュリティ保護する方法の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?linkid=47574) を参照してください (このサイトは英語の場合があります)。


MTA データ ファイルが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange メッセージ転送エージェント (MTA) データ フォルダの FSName キーの値を判断します。FSName キーの値が NTFS ではないことが検出されると、エラーが表示されます。

Microsoft では、NTFS ではないボリュームへの Exchange データ ファイルの格納をサポートしていません。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

このエラーが表示された場合は、MTA データ フォルダを NTFS ドライブに移動する必要があります。MTA データ フォルダが置かれているドライブが FAT (ファイル アロケーション テーブル) ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

Exchange mtadata フォルダを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. ストレージ グループのプロパティ ページで、[システム パスの場所] ボックスの横にある [参照] をクリックします。

  4. mtadata フォルダの新しいパスを入力し、[OK] をクリックします。

  5. [OK] をクリックします。

この手順の代わりに、ファイルが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、コマンド ライン ツールの convert.exe を使用してそのドライブを NTFS に変換することもできます。コマンド ライン ツールの convert.exe を使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579) を参照してください。


MTA の DB data buffers per object パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\DB data buffers per object

Exchange Server アナライザによって、DB data buffers per object の値が存在し、ゼロよりも大きい 3 と 6 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

DB data buffers per object の値は、各データベース オブジェクトに対して構成される、4 KB のデータベース サーバー バッファの数を示します。バッファ数が増えると多くのメモリが必要になりますが、バッファ領域の不足が原因でデータベース オブジェクトがディスクにロールアウトされる可能性は低くなります。この値の変更が推奨される理由の 1 つとして、メッセージ転送エージェント (MTA) がサイト内またはサイト間で複数の Exchange Server Version 5.5 コンピュータと通信を行う場合が挙げられます。このような場合は、値を 6 に変更することをお勧めします。調査された MTA がこの基準に合致していない場合は、値を既定の設定である 3 に戻す必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[DB data buffers per object] を探して値をダブル クリックします。

  4. [値のデータ] ボックスに「3」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の DB file handles パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\DB file handles

DB file handles 値が存在し、192 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

DB file handles 値は、構成されるデータベース サーバー ファイル ハンドルの数を示しています。これにより、同時に開くことができるデータベース ファイルの最大数が決定されます。構成された値よりも多くのファイルを開く必要がある場合、データベース オブジェクトがディスクにコピーされます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[DB file handles] を探して値をダブルクリックします。

  4. [値のデータ] ボックスに「192」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の診断ログ レベルが 5 を超えている (MTA がデバッグ モードになっている)
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、一連のレジストリ キーを読み取り、Exchange サーバーで設定されているメッセージ転送エージェント (MTA) 診断ログのレベルを判断します。これらのレジストリ キーは、次の場所にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Diagnostics

これらのキーの既定値は 0 です。Exchange Server アナライザによって、これらのいずれかのキーの値が 5 より大きいことが検出されると、エラーが表示されます。

これらのレジストリ キーは、特定のサーバーのプロパティ ページにある [診断ログ] タブでログ出力レベルを変更すると、Exchange システム マネージャによって設定されます。管理者は Exchange システム マネージャを使用して、特定のログ出力レベルを [なし]、[最小]、[中]、または [最大] に設定できます。これに対応するレジストリ キーの値は、それぞれ 0、1、3、または 5 です。

したがって、5 より大きい値を設定できるのはレジストリを手動で編集した場合のみであり、このようなレベルは、ピーク時以外の時間帯にきわめて短時間にデバッグやトラブルシューティングを行うときのみに限る必要があります。これらのキーを 5 より大きい整数に設定すると、ログ出力のレベルが、リソースを極端に集中して使用するデバッグ レベルにまで上がります。ログ出力がデバッグ レベルに上がるだけでなく、サイズが約 40 MB ある "call.out" デバッグ トレース ファイルが数秒ごとに出力されるようになります。これにより、コンピュータのイベント ログは 1 分以内にいっぱいになります。

以下の表に、MTA のログ カテゴリを Exchange システムマネージャの [診断ログ] タブに列挙されているとおりに記載し、それに対応するレジストリ内のキー名を示します。

Exchange システム マネージャに表示されるカテゴリ | 対応するレジストリ キー名
X.400 Service | 1 X.400 Service
Resource | 2 Resource
Security | 3 Security
Interface | 4 Interface
Field Engineering | 5 Field Engineering
MTA Administration | 6 MTA Administration
Configuration | 7 Configuration
Directory Access | 8 Directory Access
Operating System | 9 Operating System
Internal Processing | 10 Internal Processing
Interoperability | 11 Interoperability
APDU (Application Protocol Data Unit) | 12 APDU

この文書の最後にあるリファレンスでは、各 MTA カテゴリでログ出力される内容に関する詳細情報が提供されています。

実際にトラブルシューティングを行っている場合以外は、各 MTA カテゴリのログ出力を [なし] (0) に設定することをお勧めします。これが推奨される理由は、ログ出力されるイベントの数を管理可能な範囲に維持するためです。レベルを [最小] (1) にした場合でも、レベルが設定されているカテゴリによっては、数日間に数百のイベントログが生成される可能性があります。

現在トラブルシューティングを行っていない場合は、トラブルシューティングの実行中に高く設定された値が、誤ってそのままの設定で残されている可能性があります。これらの値は、少なくとも [最大] (5) に設定する必要がありますが、実際にトラブルシューティングを行っている場合以外は、各 MTA 診断ログ カテゴリについてログ出力レベルを [なし] (0) に設定することを検討してください。

MTA の診断ログ カテゴリを [なし] に設定するには

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、[サーバー] を展開し、対象のサーバーを展開します。次に、[プロパティ] をクリックします。

  3. [<サーバー名> のプロパティ]で、[診断ログ] タブをクリックします。

  4. [サービス] の [MSExchangeMTA] をクリックします。

  5. [分類] の各エントリについて、[ログ出力のレベル] のカテゴリから [なし] を選択して、ログ出力のレベルを [なし] に設定します。

  6. すべてのカテゴリを [なし] に設定したら、[適用] をクリックし、[OK] をクリックします。

Exchange 2000 Server および Exchange Server 2003 での MTA 診断ログ出力の詳細については、Microsoft サポート技術情報の文書番号 163033「[XCON] MTA の診断カテゴリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163033) を参照してください。

Exchange Server Version 5.5 での MTA 診断ログ出力の詳細については、Microsoft サポート技術情報の文書番号 163032「[XCON] MTA の診断ログ出力の解説」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163032) を参照してください。


MTA 診断ログのレベルが 0 以外になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、一連のレジストリ キーを読み取り、Exchange サーバーで設定されているメッセージ転送エージェント (MTA) 診断ログのレベルを判断します。これらのレジストリ キーは次の場所にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Diagnostics

これらのキーの既定値は 0 です。Exchange Server アナライザによって、これらのキーのいずれかの値が 1 より大きく 6 より小さいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

これらのレジストリ キーは、指定されたサーバーのプロパティ ページにある [診断ログ] タブでログ出力レベルを変更すると、Exchange システム マネージャによって設定されます。管理者は Exchange システム マネージャを使用すると、指定されたログの出力レベルを [なし]、[最小]、[中]、または [最大] に設定できます。これらに対応するレジストリ キーの値は、それぞれ 0、1、3、または 5 です。

以下の表に、MTA のログ カテゴリを Exchange システムマネージャの [診断ログ] タブに列挙されているとおりに記載し、それに対応するレジストリ内のキー名を示します。

Exchange システム マネージャに表示される分類 | 対応するレジストリ キーの名前
X.400 Service | 1 X.400 Service
Resource | 2 Resource
Security | 3 Security
Interface | 4 Interface
Field Engineering | 5 Field Engineering
MTA Administration | 6 MTA Administration
Configuration | 7 Configuration
Directory Access | 8 Directory Access
Operating System | 9 Operating System
Internal Processing | 10 Internal Processing
Interoperability | 11 Interoperability
APDU (Application Protocol Data Unit) | 12 APDU

この文書の最後に示した参考情報では、MTA の各分類によってログ出力される内容の詳細が紹介されています。

診断ログの一般的なベスト プラクティスは、トラブルシューティングを積極的に実施する場合以外は、MTA の各分類のログを [なし] (0) に設定する方法です。この設定が推奨されるのは、ログに出力されるイベントの数を管理可能な数に維持することが理由です。[最小] (1) のレベルであっても、このレベルを設定した分類によっては、数日間経過する間におそらく数百のイベント ログ エントリが生成されます。

現在トラブルシューティングを実行している場合、トラブルシューティングの実施中にこれらの値をより高く設定した後、誤って設定されたままになることがあります。MTA の診断ログの分類それぞれについて、ログのレベルを [なし] (0) に設定することを検討してください。

Exchange Server 2003 または Exchange 2000 Server でこのエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを右クリックします。次に [プロパティ] をクリックします。

  3. [<サーバー名> のプロパティ] で、[診断ログ] タブをクリックします。

  4. [サービス] ボックスの一覧の [MSExchangeMTA] をクリックします。

  5. [分類] ボックスの一覧にあるエントリごとに、分類を選択して [ログ出力のレベル] の [なし] を選択することによって、ログのレベルを "なし" に設定します。

  6. すべての分類を [なし] に設定したら、[適用] をクリックし、[OK] をクリックします。

Exchange Server Version 5.5 でこのエラーを修正するには

  1. Microsoft Exchange 管理ツールを起動します。

  2. MTA で問題が発生しているサーバーを表すオブジェクトを開きます。

  3. 右側のペインで [メッセージ転送エージェント] をダブルクリックします。

  4. [診断ログ] タブで、[X.400 Service] を選択し、[最大] をクリックします。

  5. [Resource] を選択します。

  6. Ctrl キーを押したまま、デバッグする各リソースをクリックします。

  7. ログ出力のレベルとして [なし] オプションをクリックします。

  8. [OK] をクリックします。

Exchange 2000 Server での MTA 診断ログの詳細については、Microsoft サポート技術情報の文書番号 163033「[XCON] MTA の診断カテゴリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163033) を参照してください。

Exchange Server 5.5 での詳細ログのロールバックに関する詳細については、Microsoft サポート技術情報の文書番号 「[XCON] Exchange 5.0 および 5.5 の MTA で詳細ログ出力を設定する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168906) を参照してください。

Exchange Server 5.5 での MTA 診断ログの詳細については、Microsoft サポート技術情報の文書番号 163032「[XCON] MTA の診断ログ出力の解説」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=163032) を参照してください。


MTA の Dispatcher threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Dispatcher threads

Dispatcher threads の値が存在し、1 と 2 を除く 0 より大きい値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Dispatcher threads の値は、メッセージ転送エージェント (MTA) ディスパッチャ スレッドの数です。ディスパッチャ スレッドには 3 つのサブタイプ (Router、Fanout、Result) があるため、この値は 3 倍されます。この値を変更することが推奨されるのは、1 つの MTA がサイト内またはサイト間のいずれかで、5 台より多い Exchange Server Version 5.5 コンピュータと通信する場合、または配布リストが高い頻度で使用される場合です。これらの場合は、値を 3 に変更することをお勧めします。調査された MTA がこの基準に合致していない場合は、値を既定の設定である 1 に戻す必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Dispatcher threads] 値を見つけてダブルクリックします。

  4. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA が LocalSystem アカウントで実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange MTA Stacks サービスの StartName キーに設定されている値を判断します。Exchange Server アナライザは、Active DirectoryR ディレクトリ サービスに対してもクエリを実行して、ディレクトリ内にある Exchange Server オブジェクトの serialNumber 属性値を判断します。Exchange Server オブジェクトの serialNumber 属性は、そのオブジェクトによって表されるコンピュータで実行中の Exchange Server のバージョンを識別する属性です。StartName キーの値が、Exchange 2000 Server または Exchange Server 2003 を実行している Exchange サーバーの LocalSystem の値と等しくない場合は、エラーが表示されます。

LocalSystem 以外のアカウントで Exchange MTA Stacks サービスを実行していると、アクセス許可およびアクセス エラーの原因となります。また、そのような構成はサポートされていません。

このエラーを解決するには、LocalSystem (SYSTEM) アカウントで開始されるように Exchange MTA Stacks サービスを構成する必要があります。

注 :
このエラーは、Exchange Server 5.5 には当てはまりません。Exchange 2000 Server および Exchange Server 2003 の場合のみ、Exchange MTA Stacks サービスが LocalSystem アカウントで実行されている必要があります。

Exchange MTA Stacks サービス アカウントを構成するには、以下の操作を行います。

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. Microsoft Exchange MTA Stacks サービスを見つけて停止します。

  3. [Microsoft Exchange MTA Stacks] サービスをダブルクリックします。

  4. [Microsoft Exchange MTA Stacks のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択し、[適用] をクリックします。

  5. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  6. [サービス] スナップインを閉じます。

LocalSystem アカウントでの Exchange サービスの実行に関する詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


MTA の Kernel threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Kernel threads

Kernel threads の値が存在し、この値が 0 より大きく、1 または 3 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Kernel threads 値は、OSI (Open Systems Interconnection) スタックのプレゼンテーションおよびセッション レベルを処理するプラットフォーム スレッドの数です。これらのスレッドは、メッセージ転送エージェント (MTA) メッセージ処理の中心となります。この MTA が低速な、または待ち時間の長いネットワーク接続経由でリモート プロシージャ コール (RPC) を使用して他の多くの Exchange Server Version 5.5 サーバーと通信する場合は、次の表に示した値を使用することをお勧めします。

値 | 説明
0x3 (16 進数) | 標準の推奨値。低速な、または待ち時間の長いネットワーク接続経由で RPC を使用して他の Exchange Server 5.5 サーバーと通信する MTA については、この値を使用します。
0x8 (16 進数) | この値は、15 台を超える Exchange Server 5.5 コンピュータが含まれているサイトに属する Exchange 2000 Server または Exchange Server 2003 MTA に対して使用します。
0xC (16 進数) | この値は、30 台を超える Exchange Server 5.5 コンピュータが含まれているサイトに属する Exchange 2000 Server または Exchange Server 2003 MTA に対して使用します。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Kernel threads 値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、Kernel threads 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスで、組織に適した値を入力して、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の LAN-MTAs パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\LAN-MTAs

LAN-MTAs の値が存在し、20 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

LAN-MTAs 値は、MTA がサポートするネットワーク メッセージ転送エージェント (MTA) の数を表します。このレジストリの値として 20 を使用することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、LAN-MTAs 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「20」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の MDB users パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\MDB users

MDB users の値が存在し、500 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MDB users 値は、メッセージ転送エージェント (MTA) でサポートされるメッセージ データベース (MDB) ユーザーの最大数です。Exchange Server ユーザーは、そうでないことが明示的に設定されていない限り、既定ではすべて MDB ユーザーです。

MDB users レジストリ値により、ディレクトリからキャッシュする識別名の数が定義されます。組織に 1,500 を超えるユーザーが含まれている場合は、この値をグローバル アドレス一覧のサイズの 1/3 (ただし、最大 5,000 まで) に変更する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、MDB users 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「500」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の Max RPC Calls Outstanding パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Max RPC Calls Outstanding

Max RPC Calls Outstanding の値が存在し、50 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Max RPC Calls Outstanding 値は、リモート プロシージャ コール (RPC) スレッドの最大数です。この最大数により、同時処理が保証される RPC の最大数が制限されます。この値は、RpcServerUseAllProtSeqs() および RpcServerListen() で使用されています。

Exchange 2000 Server または Exchange Server 2003 が Exchange Server Version 5.5 コンピュータと共存しており、Store.exe プロセスの Gateway In/Out スレッドの数が増やされている混在モードでは、値のデータを 0x80 (16進) または 128 (10 進) に増やすことをお勧めします。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、Max RPC Calls Outstanding 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「50」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA 用の Min RPC Threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Min RPC Threads

Min RPC Threads 値が存在し、さらにその値が 4 以外に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Min RPC Threads 値は、リモート プロシージャ コール (RPC) スレッドの最小数です。これにより、呼び出しスレッドの最小数が指定されます。この値は、RpcServerListen() によって使用されます。通常は、このレジストリ値を既定の設定から変更しないでください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Min RPC Threads] 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに「4」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の RTS threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\RTS threads

RTS threads の値が存在し、この値が 0 より大きく、1 または 3 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

RTS threads 値は、OSI (Open Systems Interconnection) スタックの RTSE (Reliable Transfer Service Element) レベルを処理するプラットフォーム スレッドの数を表します。RTS スレッドは、データをキューに格納する役割を果たします。このメッセージ転送エージェント (MTA) が、サイト内またはサイト間で複数の Exchange Server Version 5.5 コンピュータと通信する場合は、RTS Threads レジストリ値を既定値の 1 から 3 に調整する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

RTS threads レジストリ値を最適化するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、RTS threads 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに適切な値 (1 または 3) を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-19

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下に示すサービスの Started キーの設定値が、True と False のどちらに設定されているかを判断します。

  • Microsoft Exchange MTA Stacks サービス

  • クラスタ サービス

値が False の場合、この Exchange Server コンピュータでサービスは実行されていません。値が True の場合は、サービスが実行されています。

また、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI クラスも調べ、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。

評価された 3 つのキーの値がすべて False の場合は、警告が表示されます。

メールのルーティングを行うすべての Exchange Server コンピュータで、Exchange MTA Stacks サービスを開始しておくことをお勧めします。これは、Exchange Server Version 5.5 と、Exchange Server 2003 や Exchange 2000 Server との間でメッセージが転送される混在モード環境において特に重要です。また、どの X.400 コネクタも Exchange MTA Stacks サービスを必要とするため、このサービスを無効にするとエラーが生成され、機能が動作しなくなることがあります。メールボックスを移動する場合も、Exchange MTA Stacks サービスが開始されている必要があります。

この警告を解決するには、Exchange MTA Stacks サービスを開始します。

Exchange MTA Stacks サービスを開始するには

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[管理ツール] をポイントし、[サービス] MMC (Microsoft 管理コンソール) スナップインをクリックします。

  2. [Microsoft Exchange MTA Stacks] サービスを右クリックし、[プロパティ] をクリックします。

  3. Microsoft Exchange MTA Stacks のプロパティ ページの [全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。そのようになっていない場合は、[適用] をクリックし、[OK] をクリックします。

  4. [Microsoft Exchange MTA Stacks] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。

混在モードの Exchange 環境で Exchange MTA Stacks サービスを実行し続けることの詳細については、マイクロソフト サポート技術情報の文書番号 810489「Exchange 2000 Server および Exchange Server 2003 の MTA Stacks サービス サポートのガイドライン」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810489) を参照してください。


MTA サービスが無効に設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange MTA Stacks サービスの StartMode キーの値を判断します。値が Disabled の場合、Exchange MTA Stacks サービスは無効になっており、StartMode の値が Manual または Automatic に変更されるまでは開始できません。

また、Exchange Server アナライザは、Win32_Service WMI クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合は、サービスが実行されています。

最後に、Win32_OperatingSystem WMI クラスに対してクエリを実行し、OSProductSuite キーの値を判断します。このキーの値は、Microsoft Windows Server™ 2003 オペレーティング システムの特定のバージョンに対応しています。

Exchange Server アナライザによって、SMTP サービスが開始されている Exchange Server コンピュータで StartMode キーがDisabled に設定されており、その Exchage Server コンピュータが Microsoft Windows Small Business Server 2003 インストールの一部ではないことが検出されると、警告が表示されます。

サーバーが Microsoft Windows Small Business Server 2003 インストールの一部であるか、または Exchange Server 2003 の完全なネイティブ モード環境にある場合を除き、メールのルーティングを行うすべての Exchange Server コンピュータで Exchange MTA Stacks サービスが Automatic に設定されている必要があります。Exchange MTA Stacks サービスが無効になっているサーバーでメールのルーティングを行うと、各種エラー メッセージが生成される可能性があります。場合によっては、Exchange ServerVersion 5.5 がまだ実行されている Exchange 2000 Server または Exchange Server 2003 環境を実行していると、エラーがログに記録されることがあります。また、どの X.400 コネクタも Exchange MTA Stacks サービスを必要とするため、このサービスを無効にするとエラーが生成され、機能が動作しなくなることがあります。

注 :
Exchange Server 2003 では、外部 X.400 メール システムとの直接接続する場合、または Novell GroupWise コネクタ、Lotus Notes コネクタ、サードパーティーの Fax コネクタなどの Exchange Development Kit (EDK) を実行する場合を除き、MTA スタック サービスへの依存は解消されています。したがって、Microsoft は現在、MTA スタック サービスが無効になっている完全なネイティブ モードの Exchange Server 2003 の展開をサポートしています。

このエラーを解決するには、メールのルーティングを行うサーバーで Exchange MTA Stacks サービスが自動的に開始されるように構成する必要があります。

Exchange MTA Stacks サービスが自動的に開始されるように構成するには

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. [Microsoft Exchange MTA Stacks] サービスをダブルクリックします。

  3. [Microsoft Exchange MTA Stacks のプロパティ] ページの [全般] タブで、[スタートアップの種類] ボックスの一覧から [自動] をクリックし、[適用] をクリックします。

  4. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  5. [サービス] スナップインを終了します。

Exchange で Exchange MTA Stacks サービスを実行し続けることについては、Microsoft サポート技術情報の文書番号 810489「[XCON] Exchange 2000 Server では MTA Stacks サービスを有効にしておく必要がある」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810489) を参照してください。


MTA の Submit/deliver threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\ Submit/deliver threads

Submit/deliver threads の値が存在し、2 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Submit/deliver threads 値は、メッセージ転送エージェント (MTA) の発信/配信スレッドの数を表します。MTA はこれらのスレッドを使用して、インフォメーション ストアにメッセージを渡します。一部の Exchange Server Version 5.5 コンピュータでは、Exchange パフォーマンス オプティマイザによって、この値が既定値の 2 からその Exchange サーバーにより適した値に自動的に変更されている場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、Submit/deliver threads 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに 2 が入力されていることを確認し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

Exchange 2000 Server および Exchange Server 2003 コンピュータの場合、このエントリには 3 以下の値を設定する必要があります。Exchange Server 5.5 コンピュータの場合は、前の手順を実行する代わりに、Exchange パフォーマンス オプティマイザを詳細モードで実行し (perfwiz.exe -v)、このツールを使用して値を設定できます。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MTA の Submit/deliver threads レジストリ値を既定値から変更する必要がある状況の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 234280「XCON:低速のネットワーク接続を介してメールを渡す MTA の機能を増やす方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=234280)

  • 文書番号 265186「MTA Fanout がマルチプロセッサ サーバーで遅くてで、インフォメーション ストアでメッセージがバックアップします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=265186)

  • 文書番号 234702「XGEN: ゆっくりインフォメーション ストア処理することに MTA キュー」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=234702)

  • 文書番号 327260「下がる MTA が緩める Exchange で サーバー 5.5 を個室、またはプライベート インフォメーション ストアのメッセージがバックアップします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327260)

  • Exchange パフォーマンス オプティマイザを詳細モードで使用する方法の詳細については、Microsoft サポート技術情報の文書番号 246125「XADM: 詳細モードの Exchange Server 5.5 パフォーマンス オプティマイザ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246125) を参照してください。


MTA TCP/IP の control blocks パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\TCP/IP control blocks

TCP/IP control blocks の値が存在し、20 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

TCP/IP control blocks の値は、同時にサポートされる RFC1006 (TCP/IP) 接続の最大数を示します。この設定により、X.400 接続に使用可能なバッファ数が制御されます。このメッセージ転送エージェント (MTA) が複数の X.400 コネクタをホストする場合、TCP/IP control blocks の値を調整する必要があります。ホストされる X.400 コネクタごとに 10 の制御ブロックと、受信接続へのサービスを行うための 1 つの制御ブロックが必要です。したがって、3 つの X.400 接続を持つシステムでは、適切な値は 33 です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP control blocks の値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[TCP/IP control blocks] を探して値をダブルクリックします。

  4. [値のデータ] ボックスに、この MTA に適した値を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA TCP/IP threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\TCP/IP threads

Exchange Server アナライザにより、TCP/IP threads の値が存在し、2 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

TCP/IP threads の値は、RFC1006 接続を処理するメッセージ転送エージェント (MTA) の動的アドレス モジュール (DMOD) スレッドの最大数です。RFC1006 スレッドには 2 つのサブタイプ (Driver と Async Notify) があるため、この値は 2 倍されます。多数の接続を処理する X.400 ディレクトリ レプリケーション ブリッジヘッド サーバーと専用のパブリック フォルダ サーバーでは、この値を既定の 2 から 10 に変更することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの編集方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP threads 値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[TCP/IP threads] 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに適切な値を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


MTA の Transfer threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Transfer threads

Transfer threads の値が存在し、この値が 0 より大きく、1 または 2 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Transfer threads の値は、メッセージ転送エージェント (MTA) 転送スレッドの数です。各 Transfer スレッドには 2 つのサブタイプ (Transfer In および Transfer Out) があるため、この値は 2 倍されます。ゲートウェイと MTA の場合を除き、この値は Submit/deliver threads 値 (MTA とインフォメーション ストアのメッセージ転送に関連している) と等しくなります。Submit/deliver threads 値の詳細については、「MTA の Submit/deliver threads パラメータが既定値ではない」を参照してください。

サイト内またはサイト間で複数の Exchange Server Version 5.5 コンピュータと通信している Exchange 2000 Server または Exchange Server 2003 MTA の場合は、Transfer threads の値を 3 に調整することをお勧めします。

一部の Exchange Server 5.5 コンピュータでは、Exchange パフォーマンス オプティマイザによって、この値が既定値の 2 からその Exchange Server コンピュータにより適した値に自動的に変更されている場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Transfer threads 値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、Transfer threads 値を見つけ、ダブルクリックします。

  4. [値のデータ] ボックスに適切な値を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して、変更を有効にします。

Exchange 2000 Server および Exchange Server 2003 コンピュータの場合、このエントリには 3 以下の値を設定する必要があります。前の手順を実行する代わりに、Exchange パフォーマンス オプティマイザを詳細モードで実行し (perfwiz.exe -v)、このツールを使用して値を設定できます。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MTA の Transfer threads レジストリ値を既定値から変更する必要がある状況の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 234280「XCON:低速のネットワーク接続を介してメールを渡す MTA の機能を増やす方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=234280)

  • 文書番号 265186「MTA Fanout がマルチプロセッサ サーバーで遅くてで、インフォメーション ストアでメッセージがバックアップします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=265186)

  • 文書番号 327260「下がる MTA が緩める Exchange で サーバー 5.5 を個室、またはプライベート インフォメーション ストアのメッセージがバックアップします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327260)


MTA の Transport threads パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、その現在の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMTA\Parameters\Transport threads

Transport threads の値が存在し、1 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Transport threads の値は、メッセージ転送エージェント (MTA) トランスポート スレッドの数です。どのような組織でも、通常は既定値の 1 で十分です。Microsoft 製品サポート サービスから指示がない限り、この値は 1 に設定されたままにしてください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Transport threads 値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeMTA\Parameters

  3. 右側のペインで、[Transport threads] 値を見つけてダブルクリックします。

  4. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange MTA Stacks サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


メッセージ追跡が無効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバー オブジェクトの messageTrackingEnabled プロパティが TRUE (有効) と FALSE (無効) のどちらに設定されているかを判断します。

サーバー オブジェクトの messageTrackingEnabled プロパティが False に設定されていることが検出されると、エラーが表示されます。

サーバー オブジェクトの messageTrackingEnabled プロパティによって、サーバーのメッセージ追跡センターの状態が決定されます。

メッセージ追跡センターが有効になっていれば、送信者、メール メッセージ、およびメッセージ受信者に関する情報がログに収集されます。特に、メッセージの送受信時刻、メッセージのサイズ、メッセージの優先度、メッセージ受信者の一覧などの統計情報を参照できます。また、電子メール メッセージの件名行をログに収集することもできます。メッセージ追跡センターでは、システム メッセージ、パブリック フォルダ メッセージ、電子メール メッセージなどのメッセージが検索されます。

メッセージを追跡する各サーバーでメッセージ追跡センターを有効にする必要があります。有効にすると、サーバーを介してルーティングされたすべてのメッセージがメッセージ追跡ログに追加されます。

Exchange Server アナライザでスキャンを開始するには、メッセージ追跡が有効になっている必要があります。

注 :
この手順を実行するには、ローカルの Administrators グループのメンバ、および管理グループ レベルで Exchange 管理者のロールが適用されているグループのメンバのアクセス許可が必要です。
サーバーでメッセージ追跡センターを有効にするには

  1. Exchange システム マネージャで、[サーバー] を展開し、メッセージ追跡を有効にするサーバーを右クリックして、[プロパティ] をクリックします。

  2. [全般] タブで、[メッセージの追跡を有効にする] チェック ボックスをオンにします。

  3. サーバーから送信されたメッセージ、サーバーに送信されたメッセージ、またはサーバーを介して送信されたメッセージの件名を記録するには、[件名のログ収集と表示を有効にする] チェック ボックスをオンにします。

    注 :
    件名のログ収集を有効にすると、パフォーマンスが低下することがあります。

  4. [Log file maintenance] で、ログ ファイルを削除できないようにしたり、ログ ファイルの保存期間を変更したりすることができます。追跡ログの既定の保存期間は 7 日間です。

    注 :
    大量のメールを処理するサーバーでは、追跡ログが短期間に大きくなります。ログ ファイル、およびそのディスクを使用する他のサービスやアプリケーションに十分なディスク領域があることを確認してください。

  5. [OK] または [適用] をクリックします。この変更を有効にするためにサービスを再開する必要はありません。

メッセージ追跡センターの使用方法の詳細については、Microsoft サポート技術情報の文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162) を参照してください。

Exchange Server のトランスポートに関する問題をトラブルシューティングする方法の詳細については、Microsoft サポート技術情報の文書番号 821910「Exchange Server 2003 トランスポート問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821910) を参照してください。


メッセージ追跡ログが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、メッセージ追跡ログ ファイル パスの Compressed キーの値を判断します。Compressed キーの値が True であると判断されると、エラーが表示されます。

Exchange 2000 Server または Exchange Server 2003 コンピュータでメッセージ追跡が有効になっている場合、追跡ログは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\ <サーバー名> .log

ここで、<ドライブ> は \Program Files\Exchsrvr パスが含まれているドライブ、サーバー名は Exchange Server コンピュータのホスト名です。

Microsoft では、NTFS 圧縮ボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。さらに、インフォメーション ストア データベースが特定のサイズ (約 4 GB) に達すると、マウントに失敗したり破損したりすることがあります。

Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

ESE (Extensible Storage Engine) で管理されているファイルは、圧縮ドライブに格納するようには設計されていません。ESE は、ログ ベースの回復をセクタの独立性に依存しており、ファイルを圧縮することによりセクタの独立性は無効になります。ESE データベースや、先行書き込みログを使用している任意のデータベースをホストしているボリュームについては、圧縮を有効にしないでください。

Exchange 2000 Server Service Pack 3 より前のバージョンでは、圧縮されたインフォメーション ストア データベースのマウントが許可されていました。しかし、NTFS 圧縮を使用して圧縮された Exchange 2000 Server インフォメーション ストア データベースやインフォメーション ストア ログは、いずれも破損する可能性があります。

Exchange 2000 Server Service Pack 3 を使用している場合、128 MB 以下の圧縮されたインフォメーション ストア データベース ファイルは自動的に圧縮が解除されます。データベース ファイルが大きくなり 128 MB を超えると、データベースはマウントされず、アプリケーション ログにエラー メッセージが生成されます。Exchange 2000 Server Service Pack 3 では、128 MB を超える圧縮ファイルはマウントされません。

指定されたフォルダでファイルの圧縮を無効にするには

  1. ファイルの圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

上記の手順の代わりに、メッセージ追跡ログ ファイルを別の、圧縮されていないフォルダに移動することもできます。メッセージ追跡ログ ファイルの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 841089「メッセージ追跡の場所を変更する方法が Exchange でサーバー 2003 を記録します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=841089)

  • 文書番号 317700「[XADM] メッセージ追跡ログの場所を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700)

Exchange データ ファイルと NTFS 圧縮の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 170009「XADM: ストアが圧縮 NTFS ボリュームにより、失敗します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=170009)

  • 文書番号 327772「[XADM] SP3 を適用後にデータベースがマウントせずエラー 0xfffff05b が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327772)


メッセージ追跡ログが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行して、Exchange メッセージ追跡ログ ファイル パスの FSName の値を判断します。FSName キーの値が NTFS ではないことが検出されると、エラーが表示されます。

Microsoft では、NTFS ではないボリュームへの Exchange データ ファイルの格納をサポートしていません。Exchange データ ファイルには、次のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

このエラーが表示された場合は、メッセージ追跡ログを NTFS ドライブ上のフォルダに移動する必要があります。メッセージ追跡ログが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

Exchange Server 2003 でメッセージ追跡ログを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開して、操作する管理グループを展開します。次に、[サーバー] を展開して、操作するサーバーを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブの [変更] をクリックします。

  4. メッセージ追跡ログの新しいパスを入力し、[OK] をクリックします。

  5. [OK] をクリックします。
注 :
既定では、世界協定時刻 (UTC) の午前 0 時に、追跡ログ ファイルの場所の変更が行われます。この変更が有効になると、Exchange メッセージ追跡コンポーネントにより、指定した新しい場所に新しいログ ファイルが作成されます。ただし、以前のログ ファイルは新しい場所に移動されません。このため、ログ ファイルの場所の変更が有効になるのを待ってから、以前のログ ファイルを元の場所から新しい場所へ手動で移動してください。Microsoft Exchange System Attendant サービスを再開すると、直ちにログ ファイル パスが新しい場所に変更されます。このシナリオの場合、Exchange メッセージ追跡コンポーネントにより新しいログ ファイルが新しい場所に作成されるタイミングは、ユーザーがメッセージを送信したときです。このシナリオでは、同じ名前の 2 つのログ ファイル (元の場所に格納されているログ ファイルと指定した新しい場所に格納されているログ ファイル) が存在する状況を想定しています。この状況が発生した場合は、元の場所に格納されているログ ファイルの名前を変更してから、そのファイルを新しい場所に移動します。名前付けには、Exchange メッセージ追跡と同じ名前付け規則 (yyyymmdd) を使用します。ただし、この場合、この名前変更後のログ ファイルが今後作成されるログ ファイルと重複しないように、既存のログ ファイルより古い日付を使用してください。

Exchange 2000 Server が実行されているコンピュータでメッセージ追跡ログ ファイルを移動する方法の詳細については、Microsoft サポート技術情報の文書番号 317700「[XADM] メッセージ追跡ログの場所を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700) を参照してください。

または、ファイルが格納されているドライブが FAT ドライブとしてフォーマットされている場合、前の手順を実行する代わりに、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。コマンド ライン ツールの convert.exe を使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579) を参照してください。


メッセージ追跡ログが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、メッセージ追跡ログ ファイルの Encrypted キーの値を判断します。このキーの値が True の場合、エラーが表示されます。

Exchange 2000 Server または Exchange Server 2003 コンピュータでメッセージ追跡が有効になっている場合、追跡ログは次の既定の場所に書き込まれます。

<ドライブ>:\Program Files\Exchsrvr\ <サーバー名> .log

ここで、<ドライブ> は \Program Files\Exchsrvr のパスが通っているドライブ、サーバー名は Exchange Server コンピュータのホスト名です。

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームに Exchange データ ファイルを格納することをサポートしていません。暗号化されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティ保護に役立てるため、Exchange コンピュータに対する権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

指定されたフォルダに対するファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

上記の手順の代わりに、メッセージ追跡ログ ファイルを別の、暗号化されていないフォルダに移動することもできます。メッセージ追跡ログ ファイルの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 841089「メッセージ追跡の場所を変更する方法が Exchange でサーバー 2003 を記録します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=841089)

  • 文書番号 317700「[XADM] メッセージ追跡ログの場所を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317700)


メタベースにアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-13

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの以下のパスから SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスのさまざまなプロパティを読み取ろうとします。

/LM/SmtpSvc/<SMTP 仮想サーバー インスタンス>

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • メタベースに対するクエリが失敗した。

  • Exchange Server が Microsoft Windows NT® Server 4.0 上で実行されていない。

このエラーは、Exchange Server アナライザが IIS メタベースに接続できないことを示しています。

IIS メタベースには、HTTP のプロトコル設定、メールボックスおよびモバイル デバイス アクセス用の仮想ディレクトリ、HTTP セキュリティ設定などの、Exchange Server に影響を与える情報が含まれています。

この問題を解決するには、メタベースの整合性、およびその IIS が正しくインストールされているかどうかを確認します。

メタベースが破損していないこと、および IIS が正しくインストールされていることを確認するには、以下の文書を参照してください。

  • マイクロソフト サポート技術情報の文書番号 240225「メタベースを修正する Adsutil と MetaEdit ユーティリティ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240225)

  • マイクロソフト サポート技術情報の文書番号 317678「[HOWTO] Exchange 2000 Server で Internet Information Services (IIS) を再起動する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317678)

これらの文書の指示に従っても問題が解決されない場合は、IIS をアンインストールしてから再インストールすることが必要になる場合があります。

コントロール パネルの [Windows コンポーネントの追加と削除] を使用して IIS をアンインストールするには

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] をクリックします。

  7. [次へ] をクリックします。

  8. IIS がアンインストールされたら、[完了] をクリックします。
コントロール パネルを使用して IIS をインストールするには

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] チェック ボックスをオンにします。

  7. Windows コンポーネント ウィザードに戻るまで、[OK] をクリックします。

  8. [次へ] をクリックし、Windows コンポーネント ウィザードを完了します。


MinUserDC の値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、プライマリ ドメイン コントローラ (PDC) エミュレータとして動作している Active Directory® ディレクトリ サービス ドメイン コントローラが、Exchange で利用可能なドメイン コントローラの一覧から手動で除外されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

MinUserDC が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

PDC エミュレータは Active Directory 操作のマスタの役割を担うコンピュータで、Microsoft Windows NT® Server 4.0 バックアップ ドメイン コントローラからのレプリケーション要求を処理し、Active Directory が有効なクライアント ソフトウェアを実行していないクライアントのすべてのパスワード更新を処理します。PDC エミュレータはドメイン コントローラでもあるため、Exchange などのアプリケーションで利用できます。

DSAccess (Directory Service Access) は Exchange 2000 Server と Exchange Server 2003 の内部コンポーネントであり、すべての Exchange コンポーネントが Active Directory にどのようにアクセスするかを制御します。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。

DSAccess の保持する利用可能なドメイン コントローラの一覧には、既定で PDC エミュレータ コンピュータが含まれています。Exchange 以外のプログラムが PDC エミュレータを頻繁に使用している場合、DSAccess で PDC エミュレータを使用すると、PDC エミュレータ コンピュータ、Exchange サーバー、および Exchange 以外のプログラムを実行しているコンピュータでパフォーマンス上の問題が発生する可能性があります。

このようなパフォーマンスの問題を回避するため、Exchange サーバーで MinUserDC レジストリの値を追加します。これにより、DSAccess に対し、PDC エミュレータ操作のマスタの役割を保持しているドメイン コントローラに対してクエリを実行する前に、他のすべての利用可能なドメイン コントローラに対してクエリを実行することを強制できます。

注 :
MiniUserDC レジストリ値が構成されている Exchange サーバーは、最初に同じドメイン内の他のサーバーの使用を試みます。そのため、この構成は、Exchange サーバーを含むドメインのドメイン コントローラがサイトに少なくとも 2 つ存在する場合にのみ設定することをお勧めします。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MinUserDC レジストリの値を確認および編集するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

  3. MinUserDC の値を見つけて、必要な変更を加えます。この DWORD 値は、存在しない場合は手動で作成できます。

  4. MinUserDC レジストリ エントリについて構成した値のデータは、PDC エミュレータと通信する前に通信するドメイン コントローラの最大数を表します。たとえば、MinUserDC を 4 に設定すると、DSAccess は、合計 4 つのドメイン コントローラが利用可能な場合に限り PDC エミュレータを除外するように構成されます。この条件が満たされ場合、PDC エミュレータは使用されず、DSAccess は残りの 3 つのドメイン コントローラとのみ通信を行います。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MinUserDC レジストリ エントリの使用の詳細については、Microsoft サポート技術情報の文書番号 298879「[XADM] Exchange 2000 で、DSAccess に PDC エミュレータが使用されると、パフォーマンスの問題が発生する場合がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298879) を参照してください。


1,000 を超えるメールボックス ストアが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-13

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchPrivateMDB の Microsoft Exchange インフォメーション ストア オブジェクトの数を判断します。1 つの組織内に 1,000 を超えるメールボックス ストアがあることが検出されると、警告が表示されます。

この警告が表示されるのは、Microsoft Office Outlook® Web Access 2003 から、メールボックス ストアが 1,000 を超える組織内のフロントエンド サーバーを通してメールボックスにアクセスしているユーザーがメールボックスにアクセスできないという既知の問題があるためです。この問題は、フロントエンド Exchange サーバーがバックエンド Exchange サーバーにどのように認証要求を代理送信するかによって発生します。

ユーザーがフロントエンド Exchange サーバーからメールボックス ストアにアクセスしていて、この警告が表示される場合は、次のいずれかの操作を行う必要があります。

  • Microsoft サポート技術情報の文書番号 899902「ユーザーが Exchange Server 2003 フロントエンド サーバー内に Outlook Web Access を使用すると、あるメールボックスへのアクセスをしようとすると、401 エラー メッセージが表示されます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=899902) で説明されている Exchange Server 修正プログラムを入手してインストールする。

  • 可能な場合は、メールボックスを少数のメールボックス ストアに統合する。

  • バックエンド サーバーに対する認証に基本認証を使用するようにフロントエンド サーバーを設定する。この文書の残りでは、この方法について説明します。

既定では、Exchange Server 2003 フロントエンド サーバーは Kerberos 認証を使用して、フロントエンド サーバーとバックエンド サーバーの間でユーザー資格情報を保護します。Kerberos 認証に失敗すると、警告イベントがログに記録され、フロントエンド サーバーは代わりに NTLM 認証を試みます。NTLM に失敗すると、エラーがログに記録されます。30 分後には、Kerberos 認証が再試行されます。Exchange 2000 Server または Exchange Server 2003 フロントエンド コンピュータが Exchange 2000 Server バックエンド コンピュータを認証する場合は、NTLM が使用されます。インターネット インフォメーション サービス (IIS) と Exchange システム マネージャのどちらにも、認証機構を選択するためのユーザー インターフェイスはありません。

基本認証を使用するようにフロントエンド Exchange サーバーを構成するには、組織内にあるすべてのフロントエンド サーバーのレジストリ キーを設定する必要があります。以下の手順は、このキーを手動で設定する方法を説明しています。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange バックエンド サーバーに対して基本認証を使用するように Exchange フロントエンド サーバーを構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\MSExchangeWeb に移動します。

  2. [MSExchangeWeb] を右クリックし、[新規] をポイントします。次に、[キー] をクリックします。新しいキーに Dav という名前を付けます。

  3. 新しい Dav キーを右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  4. 新しい値に UseBasicAuthToBE という名前を付け、値を 1 に設定します。

  5. [サービス] Microsoft 管理コンソール (MMC) スナップインを開き、[IIS Admin サービス] を右クリックして、[再起動] をクリックします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


進行中のほとんどの store.exe 呼び出しが ESE からの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から Exchange Extensible Storage Engine (ESE) への進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Microsoft Exchange Information Store は、ESE データベースに基づきます。ESE は、トランザクション ベースの高度なデータベース エンジンです。トランザクションとは、アトミック (それ以上分割できない) 単位として扱われる一連の操作です。トランザクション内のすべての操作が実行されて完全に保存されるか、いずれの操作も実行されないかのどちらかです。

Exchange Server は、データベースの構造を決定し、メモリを管理する埋め込みデータベース エンジンとして ESE を使用します。このデータベース エンジンでは、4 キロバイト (KB) のデータのチャンク (ページ) をメモリに転送したり、メモリから転送したりすることによって、データベースをメモリにキャッシュします。メモリ内のページが更新され、新しいページまたは更新されたページがディスクに再度書き込まれます。要求がシステムに送信された際、データベース エンジンはデータをメモリにバッファリングできます。そのため、ディスクに繰り返しアクセスする必要はありません。

メモリへのデータのキャッシュは、データを処理する最も迅速で効率的な方法ですが、Exchange の実行中は、ディスク上の情報が完全に最新ではないことを意味します。最新版のデータベースはメモリ内にあります。ただし、メモリ内の多くの変更がまだディスクに保存されていないため、データベースとメモリは同期されていません。トランザクション ログ ディスクは常に、各トランザクションに関する情報で最新の状態に維持されます。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Exchange Information Store サービス (Store.exe) から ESE データベースへの多数の呼び出しを表していることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから ESE への進行中の呼び出しは、以下の状況で生じることがあります。

  • Exchange のオンライン最適化

  • データ バックアップ

    注 :
    Exchange Call Trace logging の収集時にデータ バックアップまたはオンライン最適化が処理されていた場合は、Exchange Server のパフォーマンス問題を示すエラー メッセージを無視しても問題ありません。
  • サーバー上のユーザー数に対する必要な領域の不足など、データベース ドライブのボトルネック

  • TEMP および TMP ドライブのボトルネック

このエラーを解決するには、次の操作を行います。

  • ベスト プラクティスとして、バックアップ ウィンドウやオンライン保守が、ユーザーの需要が最高の期間と重ならないようにすることをお勧めします。

  • データベース ディスク ドライブが正常で、I/O 負荷に十分なスループットがあることを確認します。

  • Exchange Server アナライザを実行して、サーバーをさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

オンライン最適化の時間ウィンドウを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 244524 の [XADM] Exchange Server のオンライン最適化の時間ウィンドウの構成方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=244524) を参照してください。

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

ESE の詳細については、「Extensible Storage Engine アーキテクチャ」(http://go.microsoft.com/fwlink/?linkid=67009) を参照してください。


進行中のほとんどの store.exe 呼び出しが IMAIL からの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange Server 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から MAPI クライアントの IMAIL コンポーネントへの多数の進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Exchange Server の IMAIL コンポーネントは柔軟性に富んだ変換サービスで、インターネット メッセージと MAPI メッセージ間で Microsoft Exchange Information Store サービスによって使用されます。これによって、RFC-822 またはインターネット形式を使用するクライアントと、MAPI クライアントや内部ストア タスクなど、Exchange Server の内部ストレージ形式を使用するクライアント間の相互運用性が実現します。

Exchange では IMAIL メカニズムを使用して、Exchange システム マネージャでインターネット ドメインに定義されたメッセージ形式または Microsoft Office Outlook® で各受信者にユーザーが指定したメッセージ形式を内容に適用します。形式パラメータが IMAIL に渡されなかった場合、IMAIL は MAPI メッセージを Summary TNEF (S/TNEF) 形式に変換してサーバー間で転送します。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から MAPI クライアントの IMAIL コンポーネントへの多数の進行中の呼び出しを表していることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

以下の条件の 1 つ以上に該当する場合、Microsoft Exchange Information Store サービスから MAPI クライアントの IMAIL コンポーネントへの進行中の呼び出しが発生する可能性があります。

  • IMAIL がメッセージまたは添付ファイル内の大量のデータを処理しようとする。

  • 多数のクライアントがデータ変換を要求する。

  • DSAccess 要求に対する応答が遅い。

  • TEMP および TMP ドライブにボトルネックがある。

  • メールボックスの移動が進行中である。

このエラーを解決するには、次の操作を行います。

  • オフピーク時にメールボックスの移動をスケジュールします。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

Exchange Server のメッセージ サイズの制限に関するベスト プラクティスの詳細については、「送信メッセージの最大サイズが設定されていない」を参照してください。

DSAccess と Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) の「DSAccess ユーザー キャッシュを構成する方法」を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


進行中のほとんどの store.exe 呼び出しが LSASS からの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-11

Microsoft® Exchange Server アナライザ ツールは、Exchange Server 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) からローカル セキュリティ認証サーバー (Lsass.exe) プロセスへの多数の進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

ローカル セキュリティ認証サーバー プロセス (Lsass.exe) は、アカウント情報の確認とログオンの検証のために他のプロセスによって起動されるセキュリティ サブシステムです。

Exchange のクライアント ログオンが行われるたびに、Exchange Server を実行するサーバーはクライアントのアカウント セキュリティ識別子 (SID) を参照する要求を送信し、ローカル セキュリティ認証サーバー (Lsass.exe) プロセス内で呼び出しを生成します。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが、Microsoft Exchange Information Store サービス (Store.exe) からローカル セキュリティ認証サーバー (Lsass.exe) プロセスへの多数の進行中の呼び出しを表していることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから LSASS プロセスへの進行中の呼び出しは、以下の状況で生じることがあります。

  • 同時に認証を実行するユーザー数に関するサーバー リソースの問題

  • Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間

  • サーバー リソースのボトルネックの問題

このエラーを解決するには、次の操作を行います。

  • 「'NeverPing' パラメータで推奨メッセージが表示される」の説明に従った NeverPing パラメータの実装を検討します。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Lsass.exe プロセスおよびメモリ使用量の詳細については、Microsoft サポート技術情報の文書番号 308356「Windows Server 2003 または Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356) を参照してください。

Exchange のクライアント ログオン、および LSASS の問題の詳細については、Microsoft サポート技術情報の文書番号 161938「リソースデッドロックで Exchange クライアントのログオンが遅い」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938) を参照してください。

Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間の詳細については、Exchange Server チームのブログ記事「Exchange Does Not Always Use Local GCs」(http://go.microsoft.com/fwlink/?LinkId=69166) を参照してください (このサイトは英語の場合があります)。

注 :
それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

サーバー リソースのボトルネックの問題の詳細については、「プロセッサのボトルネック」を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


進行中の store.exe の呼び出しの大部分がディレクトリからの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-14

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から Active Directory® ディレクトリ サービスへのコンポーネント間の多数の進行中の呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Active Directory は、メールボックス情報、アドレス一覧サービス、およびその他の受信関連情報のすべてを提供します。Exchange Server 2003 の構成情報の大部分も Active Directory に格納されます。

Exchange Server サービスは、Active Directory に格納された情報にアクセスし、Active Directory に情報を書き込みます。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から Active Directory への多数の呼び出しを表していることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから Active Directory への進行中の呼び出しは、次の状況で生じることがあります。

  • Exchange サーバーとドメイン コントローラ間のネットワーク待ち時間。

  • DSAccess が静的または不適切に構成されている。

  • ドメイン コントローラおよびグローバル カタログの負荷が高すぎる。

  • Active Directory トポロジが不適切に設計されている。

このエラーを解決するには、次の操作を行います。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • Active Directory ドメイン コントローラ サーバーのパフォーマンスを確認します。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange のパフォーマンスおよび DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

ドメイン コントローラのパフォーマンスの詳細については、以下の Windows Server リソースを参照してください。

  • 「Planning Domain Controller Capacity」(http://go.microsoft.com/fwlink/?LinkId=70191) (このサイトは英語の場合があります)

  • Windows 2000 Server の Active Directory の計画および展開に関するガイドの Active Directory のドメイン コントローラの監視に関する記事 (http://go.microsoft.com/fwlink/?LinkId=70193)


進行中のほとんどの store.exe 呼び出しが、ウイルス スキャン ソフトウェアからの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Exchange Information Store サービス (Store.exe) から Virusscan Virus API (VAPI) コンポーネントへの多数の進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から Virusscan VAPI コンポーネントへの多数の進行中の呼び出しを表していることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから Virusscan VAPI コンポーネントへの進行中の呼び出しは、以下の状況で生じることがあります。

  • ウイルス スキャン ソフトウェアに対する更新によって、インフォメーション ストアの項目が再スキャンされる

  • ウイルス スキャン ソフトウェアが不適切に構成されている

  • ウイルス スキャン ソフトウェアが処理するメッセージまたは添付ファイルのサイズが大きい

このエラーを解決するには、次の操作を行います。

  • リソースの消費が少ないとき、つまり需要がピークでない時間帯にウイルス エンジンの更新をスケジュールします。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。ただし、再インストールは需要がピークでない時間帯に実行します。

  • ウイルス スキャン エンジンの構成を調べ、スレッドの構成、ファイル レベルの除外などが適正であることを確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


進行中のほとんどの store.exe 呼び出しが VSS スナップショットからの応答を待機している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Exchange Information Store サービス (Store.exe) からボリューム シャドウ コピー サービス (VSS) スナップショット コンポーネントへの進行中のコンポーネント間呼び出しを示すイベントがないかを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

VSS は、システム上のアプリケーションがボリュームへの書き込みを続けているときに、ボリューム バックアップを実行するためのフレームワークを実装する COM API のセットです。

Microsoft Exchange Server 2003 では、Microsoft Windows Server™ 2003 オペレーティング システムに組み込まれている VSS を使用して、Exchange Server 2003 データベースおよびトランザクション ログ ファイルのボリューム シャドウ コピーを取得します。

VSS スナップショットは、元のデータから完全に独立しているわけではありません。通常、スナップショットは、特定の時点にデータをロールバックできるように、その時点にあらかじめマーカーを定義した場合に作成されます。

Exchange Server アナライザによって Store.fcl ログ ファイル内のイベントが、Microsoft Exchange Information Store サービス (Store.exe) から VSS スナップショット コンポーネントへの進行中の呼び出しを示していることが検出されると、ベスト プラクティス メッセージが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

注 :
Exchange Call Trace logging の収集の 20 秒以内に VSS スナップショットが意図的に開始された場合は、Exchange Server のパフォーマンスの問題を示すこのメッセージを無視しても問題ありません。

ベスト プラクティスとして、バックアップ ウィンドウがオンライン保守やユーザーの需要が最高の期間と重ならないようにすることをお勧めします。

詳細情報

VSS の詳細については、Exchange Server 2003 でボリューム シャドウ コピー サービスを使用する際のベスト プラクティスについてのページ (http://go.microsoft.com/fwlink/?LinkId=56571) を参照してください (このサイトは英語の場合があります)。


MOUNTMGR.SYS ファイルのバージョンが正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、Microsoft Windows® Server 2003 がインストールされているかどうかを判断します。HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\

Exchange Server アナライザでは、次のクエリも実行されます。

  • Windows Server 2003 Service Pack 1 がインストールされているかどうかを判断する Win32_OperatingSystem Microsoft WMI (Windows Management Instrumentation) クラス

  • クラスタ サービスが実行されているかどうかを判断する Win32_Service WMI クラス

  • ボリューム マウント ポイントが存在するかどうかを判断する Win32_Volume WMI クラス

  • Mountmgr.sys の Version キーの値が 2443 未満であるかどうかを判断する CIM_Datafile WMI クラス

以下の条件に当てはまる場合は、エラーが表示されます。

  • Mountmgr.sys の Version キーが 2443 未満である。

  • サーバーが Windows Server 2003 Service Pack 1 を実行しているクラスタのノードになっている。

  • サーバーにボリューム マウント ポイントがある。

クラスタ ノードにインストールされている Mountmgr.sys のバージョンが、ボリューム マウント ポイントのエラーの原因になる場合があります。この問題は Mountmgr.sys ドライバの問題によって発生します。これは、マウント ポイントにマウントされるボリュームを受け取る場合に発生する断続的なタイミングの問題です。

注 :
通常、この問題はクラスタ化されていない環境では発生しません。クラスタ化されていない環境では、ボリュームのマウント プロセスのタイミングが異なります。

この問題の詳細については、Microsoft サポート技術情報の文書番号 898790「Windows Server 2003 Service Pack 1 をインストールした後に、サーバー クラスタ内のディスクのボリューム マウント ポイントは断続的に利用できません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790) を参照してください。


Temp ディレクトリおよび TMP ディレクトリの移動
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-01

Microsoft® Exchange Server アナライザ ツールは、サーバーの TEMP フォルダおよび TMP フォルダが、ディスク パフォーマンスを最適化する場所に配置されていないと判断しました。ベスト プラクティスとして、TEMP フォルダおよび TMP フォルダは、システム フォルダや Exchange データ ファイルと共有されていないディスク サブシステムに格納することをお勧めします。

Microsoft Exchange Information Store サービスは、メッセージ変換、サイズの大きな添付ファイルの処理、メールボックスの移動などのさまざまな操作の間、TEMP フォルダと TMP フォルダを一時的な記憶域として使用します。TEMP 環境変数と TMP 環境変数は、一時的なワークスペースを必要とするアプリケーションが使用するファイル システム内のフォルダを 、(たとえばパスで) 指定するために使用されます。TEMP は通常、Microsoft Exchange などのアプリケーションによって使用され、TMP は通常、Microsoft Visual C++® などの開発ツールによって使用されます。各変数のパスは、通常、アプリケーションまたはツールのセキュリティ コンテキストを基準にしています。

クラスタ化されていない Exchange サーバーでは、Exchange ストアは TEMP と TMP の両方について、既定の環境変数の設定である %Systemroot%\Temp が使用される SYSTEM (たとえばローカル システム) フォルダを使用します。Microsoft Windows® サーバー クラスタ環境で実行される Exchange 仮想サーバーは、特定のユーザー セキュリティ プリンシパルのコンテキストで実行されるクラスタ サービス アカウントの環境変数の設定を使用します。ユーザー アカウントの場合、TEMP と TMP の既定の環境変数は %Userprofile%\Temp に設定されます。

この文書では、クラスタ化された環境およびクラスタ化されていない環境で、TEMP ディレクトリおよび TMP ディレクトリを移動する方法を説明します。ここに示す手順を実行する前に、次の推奨事項を検討してください。

  • 最大のパフォーマンスを得るためには、オペレーティング システムを格納しているディスクを、Exchange が使用する TEMP フォルダと TMP フォルダのために使用しないことをお勧めします。また、これらの環境変数が、RAID-0+1 スピンドル セットなどの高速なディスクまたはディスク システム上のパスに設定されるようにしてください。

  • Exchange トランザクション ログが記録されるディスクを、TEMP フォルダおよび TMP フォルダ用に使用することはお勧めしません。

クラスタ化されていない環境で TEMP フォルダまたは TMP フォルダを移動するには

  1. 管理者権限を持つアカウントを使用して、Exchange Server を実行しているコンピュータにログオンします。

  2. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。

  3. [詳細設定] タブをクリックします。

  4. [環境変数] をクリックします。

  5. [システム環境変数] 領域で、[TEMP] を選択し、[編集] をクリックします。

  6. [変数値] ボックスに TEMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  7. [システム環境変数] 領域で、[TMP] を選択し、[編集] をクリックします。

  8. [変数値] ボックスに TMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  9. [OK] をクリックして [環境変数] ダイアログ ボックスを閉じます。次に、[OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じます。

  10. サーバーを再起動してすべての変更を適用します。
クラスタ化された環境で TEMP フォルダまたは TMP フォルダを移動するには

  1. クラスタ サービスのアカウントとしてクラスタ内のノードにログオンします。

  2. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。

  3. [詳細設定] をクリックします。

  4. [環境変数] をクリックします。

  5. [<アカウント名> のユーザー環境変数] グループで、[TEMP] を選択し、[編集] をクリックします。

  6. [変数値] ボックスに TEMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  7. [<アカウント名> のユーザー環境変数] グループで、[TMP] を選択し、[編集] をクリックします。

  8. [変数値] ボックスに TMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  9. [OK] をクリックして [環境変数] ダイアログ ボックスを閉じます。次に、[OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じます。

  10. ノードを再起動して変更を適用します。

  11. クラスタ内の各ノードについて、手順 1. ～ 10. を繰り返します。
重要 :
Authenticated Users アカウントに、TMP フォルダおよび TEMP フォルダの新しいパスに対する適切なアクセス許可を与える必要があります。
Authenticated Users グループに TMP フォルダと TEMP フォルダに対するアクセス許可を与えるには

  1. Windows エクスプローラを起動し、TEMP 変数または TMP 変数が指すフォルダを右クリックし、[プロパティ] をクリックします。

  2. Temp のプロパティ ダイアログ ボックスで、[セキュリティ] タブ、[追加] の順にクリックします。

  3. [ユーザー、コンピュータ、またはグループの選択] ダイアログ ボックスで、オブジェクト名の一覧に Authenticated Users グループを追加し、[OK] をクリックします。

  4. [詳細設定] をクリックして、セキュリティの詳細設定を表示します。

  5. [名前] の一覧で [Authenticated Users] を選択し、[編集] をクリックして [アクセス許可エントリ] ダイアログ ボックスを表示します。

  6. [アクセス許可] の一覧のチェック ボックスを使用して、次の特別なアクセス許可を与えます。

    フォルダのスキャン/ファイルの実行

    ファイルの作成/データの書き込み

    フォルダの作成/データの追加

  7. [OK] を 3 回クリックして、アクセス許可を適用し、終了します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


ユーザーのメールボックスを別のサーバーに移動する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールによって、現在、サーバーのユーザー負荷が効率的にサポートできる上限よりも高くなっていることが判断されました。現在のユーザー負荷により、パフォーマンスの問題が発生しています。パフォーマンスの問題が解決されるまで毎晩少数のユーザー (通常はユーザー総数の 5%) を移動して、ユーザーを別の場所へ移動することをお勧めします。

以下のいずれかの問題が発生したため、この方法をお勧めします。

  • 一部の Exchange データベース ファイルが、スループット処理能力の上限に達している、または上限を超えているディスク上にある。

  • その他のサーバー リソース (メモリ、CPU など) が処理能力を超えている。

  • ディスクが処理能力を超えています。つまり、現在 1 つ以上の Exchange ストアをサポートしているディスク サブシステムの平均ディスク I/O 待ち時間が現在の推奨レベルを超えています。問題が解決されるまで、ユーザーの 5% を異なるディスク サブシステム上のデータベースへ移動する必要があります。データベース ドライブがボトルネックの場合は、異なるドライブ上にあるデータベースへユーザーを移動します。ストレージ グループ ドライブがボトルネックの場合は、別のデータベース上にある別のストレージ グループ内のデータベースへユーザーを移動します。ドライブが別のリソースによって共有されている場合、考えられる別の解決策は、これらのドライブ上でその他のアプリケーションの負荷を減らすことです。

  • 物理サーバーは処理能力を超えています。現在のプロセッサまたはメモリでは、ユーザーが生成しているサーバー負荷を十分にサポートできません。パフォーマンスの問題が解決されるまで、ユーザーの 5% を別のサーバーへ移動する必要があります。

注 :
Exchange クライアントは、メールボックスの移動処理中にメールボックスから切断する必要はありませんが、サービスの中断の可能性を回避するために、ピーク時間外などの Exchange クライアントの活動が低下しているときに移動処理を行うことをお勧めします。
Exchange Server 2003 でメールボックスを移動するには

  1. 処理を実行する Exchange Server 2003 コンピュータで Exchange システム マネージャを起動します。

  2. [サーバー] をダブルクリックし、ユーザーのメールボックスが置かれているサーバー コンテナを見つけます。

    たとえば、既定のストレージ グループおよびメールボックス ストアからメールボックスを移動する場合は、[最初のストレージ グループ] をダブルクリックし、[メールボックス ストア] をダブルクリックし、[メールボックス] をクリックします。

  3. 詳細ペインで、移動するメールボックスをクリックします。

  4. 選択したユーザーを右クリックし、[Exchange タスク] をクリックします。

  5. Exchange タスク ウィザードで、[次へ] をクリックします。

  6. [実行可能なタスク] ページの [実行するタスクを選択してください] で、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  7. [メールボックスの移動] ページの [サーバー] ボックスの一覧で、目的のサーバーをクリックし、[メールボックス ストア] ボックスの一覧で、目的のメールボックス ストアをクリックします。

  8. [次へ] をクリックします。

  9. 移動中に見つかった壊れたメッセージの処理方法を構成し、[次へ] をクリックします。

  10. [次へ] をクリックします。

詳細情報

  • Exchange Server パフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

  • Exchange 2000 Server と Exchange 5.5 Server との間でメールボックスを移動する方法の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。


NAS 構成に問題がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループ オブジェクトの msExchESEParamLogFilePath 属性値を判断します。この属性は、ストレージ グループ内のデータベースで使用されるトランザクション ログ ファイルの場所を指定します。

Exchange Server アナライザは Active Directory に対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。

さらに、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、Microsoft Windows Storage Server 2003 Feature Pack サービス (wssexchmap) の Started キーの値を判断します。この値が False の場合は、この Exchange サーバー上で Windows Storage Server 2003 Feature Pack サービスは実行されていません。この値が True の場合は、Windows Storage Server 2003 Feature Pack サービスが実行されています。

いずれかの msExchESEParamLogFilePath 属性の値が "S:\{" で始まり、かつ 1,500 を超えるメールボックスが含まれている Exchange Server コンピュータ上で Windows Storage Server 2003 Feature Pack サービスが開始されていることが検出されると、警告が表示されます。

Windows Storage Server 2003 は、NAS デバイスのための Microsoft プラットフォームです。Exchange Server 2003 でも Windows Storage Server 2003 の記憶域レイアウトを使用することが推奨されますが、このレイアウトは標準の Exchange Server のレイアウトとは多少異なります。推奨される構成では、Exchange Server データベースを Windows Storage Server 2003 に配置し、トランザクション ログ ファイルを Exchange Server コンピュータ内のローカル ディスクに配置します。

Microsoft は、Windows Storage Server 2003 Feature Pack を、次の 3 種類の負荷に対応するように開発しました。

  • 低負荷。1 台の Windows Storage Server コンピュータに接続された 1 台の Exchange Server により、最大 250 のメールボックスがホストされます。このシナリオでは、Windows Storage Server の構成として、1 GHz 以上のプロセッサ、512 MB の RAM、RAID-5 ボリュームとして構成された 4 個の SCSI または IDE/SATA ディスク、および LAN 接続用に 1 枚と Exchange サーバーに直接接続するためのプライベート ギガビット イーサネット アダプタに 1 枚の合計 2 枚のネットワーク インターフェイス カード (NIC) が推奨されます。Exchange データベースは RAID-5 ボリュームに格納され、トランザクション ログは Exchange サーバーのローカルの RAID-1 に残ります。

  • 中程度の負荷。1 台の Exchange Server と 1 台の Windows Storage Server コンピュータにより、1 つのストレージ グループ内の最大 750 のメールボックスがホストされます。この構成では、Windows Storage Server コンピュータに、1 組の 1 GHz 以上のプロセッサ、1 GB の RAM、6個の SCSI ディスク、および 1 枚の NIC を実装する必要があります。これらのディスクは、データベース用の 4 ディスク RAID-5 アレイと、トランザクション ログ用の別の 2 ディスク ミラー セットとして構成する必要があります。

  • 高負荷。1 または 2 台の Exchange Server 2003 サーバーにより、2 つのストレージ グループ内の最大 1,500 のメールボックスがホストされます。この構成では、Windows Storage Server に、2 つの 1 GHz 以上のプロセッサ、2 GB の RAM、およびデータベースを格納するための RAID 0+1 アレイ用に 10 個と、トランザクション ログ用に 2 セットのミラー化されたディスクの、合計 14 個のディスクを実装する必要があります。

この警告は、Exchange Server コンピュータが Windows Storage Server 2003 を記憶域として使用するように構成されていることを示しています。Windows Storage Server を Exchange Server のデータ記憶域として使用する場合は、Exchange Server に同時にアクセスするユーザー数を 1,500 未満にすることをお勧めします。

この警告を修正するには

  • 以下のいずれかを実行します。

    • トランザクション ログを Exchange Server コンピュータ内のローカル ディスクに移動します。

    • この Exchange Server コンピュータ上のメールボックスの一部を別の Exchange Server コンピュータに移動して、Windows Storage Server を使用している Exchange Server コンピュータ上のメールボックスの数が 1,500 以下になるようにします。

Exchange Server 2003 で Windows Storage Server 2003 Feature Pack を使用する方法の詳細については、「Managing Exchange Storage with the Windows Storage Server 2003 Feature Pack」(http://go.microsoft.com/fwlink/?linkid=34942) を参照してください (このサイトは英語の場合があります)。

詳細については、以下の追加リソースを参照してください。

  • 「Introduction to Windows Storage Server 2003 Architecture and Deployment」(http://go.microsoft.com/fwlink/?linkid=34943) (このサイトは英語の場合があります)

  • 「Building Better Protected Storage using Windows Storage Server 2003」(http://go.microsoft.com/fwlink/?linkid=34944) (このサイトは英語の場合があります)

  • 「Exchange Server 2003 Server Consolidation」(http://go.microsoft.com/fwlink/?linkid=47586) (このサイトは英語の場合があります)


networkAddress 属性が正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、networkAddress 属性に ncacn_ip_tcp 文字列が含まれているかどうかを判断します。以下のいずれかの条件に当てはまる場合は、エラーが表示されます。

  • ncacn_ip_tcp 文字列が存在しない。

  • ncacn_ip_tcp 文字列が壊れている。

Exchange Server 2003 用の Microsoft Office Outlook® Web Access では、フロントエンド サーバーが Exchange バックエンド サーバーへの接続を試みるときに、networkaddress 属性値が調査されます。

注 :
Exchange 2000 Server は Outlook Web Access との間ではこの調査を実行しません。

フロントエンド サーバーは、完全修飾ドメイン名 (FQDN) の値を必要とします。フロントエンド サーバーはある期間、networkaddress ncacn_ip_tcp に対して返される値を確認します。以下の条件に当てはまる場合、特定のバックエンド サーバー上にあるメールボックスへの接続要求が失敗し、フロントエンド サーバーからユーザーに、"HTTP 500 内部サーバー エラー" というエラー メッセージが返されます。

  • networkaddress ncacn_ip_tcp の値が、ホスト名または NetBIOS 名だけになっている。

  • networkaddress ncacn_ip_tcp の値が、FQDN ではない。

Outlook Web Access 2003 が正しく機能するように、Active Directory のサーバー オブジェクトで networkaddress ncacn_ip_tcp の値を更新する必要があります。影響を受けているサーバーの名前は、Exchange Server アナライザのエラー メッセージに示されています。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
注 :
ncacn_ip_tcp の値を更新する前に、この文書を終わりまで読んでください。Exchange Server サービスを再開するときのダウンタイムを最小限にするには、Exchange Server サービスを再開する前に追加の手順を実行する必要があります。
networkAddress 属性の ncacn_ip_tcp 値を更新するには

  1. Windows 2000 Server サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

  3. [<Exchange サーバー名>] を右クリックし、[プロパティ] をクリックします。

  4. [Attributes] の一覧で [networkAddress]] をクリックし、[Edit] をクリックします。

  5. ncacn_ip_tcp の新しい値を追加します。サーバーの NetBIOS 名やホスト名ではなく、FQDN を使用します。

    この値のために使用する構文は、ncacn_ip_tcp:FQDN です。たとえば、使用している Exchange バックエンド サーバーのホスト名が EXCHANGE1 であり、FQDN が EXCHANGE1.contoso.com である場合は、ncacn_ip_tcp に ncacn_ip_tcp:EXCHANGE1.contoso.com という値を使用します。

  6. [OK] を 2 回クリックして変更を適用します。

  7. サーバー上のすべての Exchange Server サービスを再開します。

  8. ドメイン コントローラが複数ある場合は、レプリケーションが行われるまで待機してから、フロントエンド サーバーからログオンします。レプリケーションの完了後に問題が解決されていない場合は、フロントエンド サーバーで IIS Admin サービスを再開します。

短い形式のホスト名を持つサーバーの IP アドレスを関連付けるためにバックエンド サーバーで Hosts ファイルを管理する場合は、UpdateProtocols registry 値も更新する必要があります。Hosts ファイルが使用されている場合は、Microsoft System Attendant サービスが再開されるときに、Exchange Server によって ncacn_ip_tcp 値が元に戻されることがあります。バックエンド サーバーがクラスタ化されている場合は、フェールオーバー後に Exchange Server によって、ncacn_ip_tcp 値が元に戻されることがあります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Hosts ファイルを使用するバックエンド サーバーの UpdateProtocols レジストリ値を変更するには

  1. レジストリ エディタを使用して、バックエンド サーバーで次のレジストリ値を構成します。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\UpdateProtocols

    注 :
    UpdateProtocols 値が存在しない場合は、この値を作成する必要があります。それには、次の手順に従います。

  2. レジストリ エディタを起動して、次のレジストリ サブキーを見つけます。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\

    1. [Parameters] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

    2. 「UpdateProtocols」と入力し、Enter キーを押します。

  3. [UpdateProtocols] を右クリックし、[変更] をクリックします。次に、[値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  4. ネットワークのバックエンド クラスタ ノードで Hosts ファイルを使用する場合は、 UpdateProtocols のエントリの順序を以下のように変更します。

    IPAddress to FQDN

    IPAddress to NetBIOS

    変更前は以下のようになっていたはずです。

    IPAddress to NetBIOS

    IPAddress to FQDN

  5. サーバー上のすべての Exchange Server サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


Network Interface パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Network Interface パフォーマンス オブジェクトの Bytes Total/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、次の状況のいずれかの組み合わせが当てはまります。

  • Network Interface パフォーマンス オブジェクトが無効になっている。

  • Network Interface パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能カウンタによってレジストリが破壊された場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによってレジストリが変更された場合に発生する可能性があります。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. Network Interface パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) でダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) の説明に従って、存在しないパフォーマンス カウンタまたは破損しているパフォーマンス カウンタを再構築します。

  3. この Microsoft サポート技術情報の文書に従っても問題を解決できない場合は、Windows オペレーティング システムを修復モードで再インストールし、最新の Windows Server Service Pack を適用する必要があります。


最新の MSGTRACK.dll が利用可能
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-05

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの複数のパフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Msgtrak.dll ファイルの Version キーに設定されている値を判断します。

次の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • サーバーで高い CPU 使用率が生じている。

  • Msgtrak.dll ファイルの Version キーの値が、バージョン 6.0.6373.0 より前のバージョンを示している。

この警告は、検出された Msgtrack.dll のバージョンが高い CPU 使用率の原因となっている可能性があることを示しています。また、検出された Msgtrack.dll のバージョンが原因で Inetinfo.exe プロセスが極めて高いメモリ使用率を示している可能性も示しています。

この問題を修正するには、Microsoft サポート技術情報の文書番号 811409 の、[XADM] メッセージ追跡が原因で Inetinfo.exe プロセスのメモリ使用量が高くなる問題についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=811409) から更新プログラムを入手してください。


最新の WLDAP32.DLL が利用可能
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの複数のパフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows® のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Exchange Server コンピュータで Microsoft Windows NT® 4.0 が実行されていることを示します。値が 5.0 の場合は、Exchange Server コンピュータで Windows 2000 Server が実行されていることを示し、値が 5.2 の場合は、Exchange Server コンピュータで Windows Server™ 2003 が実行されていることを示します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Wldap32.dll ファイルの Version キーに設定されている値を判断します。

次の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • Exchange Server アナライザで、分析対象のサーバの CPU 使用率が高いことが検出された。

  • Exchange Server コンピュータで Windows 2000 Server が実行されている。

  • Wldap32.dll ファイルの Version キーの値が、バージョン 5.0.2195.7044 より前のバージョンを示している。

この警告は、検出された Wldap32.dll のバージョンでは、Windows 2000 Server システム上の Inetinfo.exe プロセスで CPU の使用率が 100% になる可能性があることを示しています。

この問題を解決するには、マイクロソフト サポート技術情報の記事 899019 の、Exchange 2000 Server を実行する Windows 2000 Server コンピュータの Inetinfo.exe プロセスで CPU 使用率が 100% になる場合がある問題についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=899019) から更新プログラムを入手してください。


NNTP サービスが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NNTP (Network News Transfer Protocol) サービス (NntpSvc) の Started キーの値を判断します。値が True の場合は、NNTP (Network News Transfer Protocol) サービスが Exchange サーバー上で実行されています。

また、Exchange Server アナライザは、インターネット インフォメーション サービス (IIS) メタベースの次のプロパティを読み取り、Exchange サーバーのために NNTP フィードが構成されているかどうかも判断します。

/LM/NNTPSVC/1/Feeds

NNTP サービスが開始されていても、サーバーのために構成されているフィードがないことが検出されると、警告が表示されます。

リソースを節約するため、および一般的なセキュリティの予防措置として、使用されていないコンポーネントのためのサービスは実行しないようにする必要があります。実行されるサービスはそれぞれ、悪意のあるユーザーに利用されるおそれのある機能を公開しています。使用されていないサービスは、すべて無効にすることをお勧めします。

NNTP サービスを無効にするには

  1. [スタート] ボタンをクリックし、[プログラム] をクリックします。次に、[管理ツール] をクリックして [サービス] をクリックします。

  2. [Network News Transfer Protocol (NNTP)] サービスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[停止] をクリックします。

  4. [スタートアップの種類] で、[無効] をクリックし、[OK] をクリックします。

Exchange Server 2003 のセキュリティ保護の詳細については、『Exchange Server Security Hardening Guide』(http://go.microsoft.com/fwlink/?linkid=47578) を参照してください (このサイトは英語の場合があります)。


テストに使用可能な DNS サーバーがない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-05

Microsoft® Exchange Server アナライザ ツールは、Microsoft WMI (Windows® Management Instrumentation) の Win32_NetworkAdapterConfiguration クラスに対してクエリを実行し、Exchange Server を実行しているサーバーが送信しようとしているメッセージの送信先のリモート サーバーの DNSServerSearchOrder 属性を取得します。この属性は、DNS (ドメイン ネーム システム) サーバーに対するクエリで使用されるサーバー IP アドレスの配列です。

Exchange Server アナライザは、Microsoft Active Directory® ディレクトリ サービスに対してもクエリを実行し、Exchange 2000 Server および Exchange Server 2003 サーバー オブジェクトの protocolCfgSMTPServer クラスの msExchSMTPExternalDNSServers 属性の値を判断します。protocolCfgSMTPServer クラスには、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの設定が含まれています。msExchSMTPExternalDNSServers 属性が設定されている場合、SMTP 仮想サーバーは外部 DNS サーバーを使用します。

また、Exchange Server アナライザは、以下の Exchange Management Shell コマンドレットを使用して、対象の Exchange 2007 トランスポート サーバーの役割の ExternalDNSServers プロパティおよび InternalDNSServers プロパティの値を取得するためにクエリを実行します。ExternalDNSServers プロパティは、サーバーがリモート ドメインを解決する際に実行するクエリの対象の、外部 DNS サーバーの一覧を指定します。InternalDNSServers プロパティは、対象サーバーのローカル ドメイン名の解決に使用する必要のある DNS サーバーの一覧を指定します。

コードのコピー
get-TransportServer -Identity %ExchangeServerName% -DomainController %DomainControllerName%

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • Exchange Server アナライザによって DNSServerSearchOrder 属性の値を正常に取得できない。または、その属性にデータが含まれていない。

  • Exchange 2000 Server および Exchange Server 2003 サーバー オブジェクトの msExchSMTPExternalDNSServers 属性が設定されていない。

  • 対象の Exchange 2007 トランスポート サーバーの役割の ExternalDNSServers プロパティおよび InternalDNSServers プロパティの値にデータがない。

このエラーは、Exchange Server アナライザが、対象の Exchange サーバーによって使用される DNS サーバーを識別できないことを示しています。さらに、この状態によってメール フローが悪影響を受ける可能性があります。

この状態には次のような原因が考えられます。

  • 対象サーバーにおいて、DNS が正しく構成されていない。

  • WMI でエラーが発生しているか、WMI にアクセスできない。

この問題を解決するには

  • 対象サーバーの DNS 構成を確認します。

  • Exchange WMI にアクセスできることを確認します。

Exchange WMI にアクセスできることを確認するには

  1. Exchange サーバーが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、Exchange サーバーにアクセスできるかどうかを確認します。

  3. ファイアウォールが配置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを確認します。

  4. Exchange Server アナライザの実行に使用するアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange サーバーで、ローカルの管理者アクセス許可を持っている必要があります。

    または、次の手順に従って、Exchange Server アナライザの実行に使用するアカウントに、特定の WMI アクセス許可を与えることもできます。

    1. Exchange サーバーで、Microsoft 管理コンソール (MMC) の [コンピュータの管理] ツリーを開きます。

    2. [サービスとアプリケーション] で、[WMI コントロール] を右クリックし、[プロパティ] をクリックします。

    3. [WMI コントロールのプロパティ] ページで、[セキュリティ] タブをクリックし、[Root] を展開します。

    4. [CIMV2] フォルダを選択し、[セキュリティ] をクリックします。

    5. [セキュリティ ROOT\CIMV2] ページで、Exchange Server アナライザの実行に使用するアカウントを追加します。

  5. 手順 4 で追加したアカウントを選択します。[<選択したアカウント> のアクセス許可] の [許可] 列で、[リモートの有効化] チェック ボックスと [セキュリティの読み取り] チェック ボックスをオンにし、[OK] をクリックします。

Exchange Server と共に動作する DNS の構成方法の詳細については、マイクロソフト サポート技術情報の記事 322856 の、Exchange Server と一緒に使用する際の DNS の構成方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322856) を参照してください。

ネットワーク接続の問題に関する詳細については、マイクロソフト サポート技術情報の記事 325487 の、ネットワーク接続の問題のトラブルシューティング方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) (英語) を参照してください。

ポート要件の詳細については、マイクロソフト サポート技術情報の記事 832017 の、Windows サーバー システムのサービス概要およびネットワーク ポート要件についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


マスタ アカウント SID がない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-14

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、MSExchangeIS のイベント 9548 警告が過去 1 時間以内にログに記録されていないかどうかを判断します。

イベント 9548 警告が過去 1 時間以内にログに記録されていることが検出されると、その時間にログ記録されたイベント 9548 警告の合計数がカウントされます。

最後に、イベント 9548 警告が過去 1 時間に 20 回以上ログに記録されていることが検出されると、警告が表示されます。

この警告は、Exchange Server メールボックスに関連付けられ、有効な msExchMasterAccountSID 属性を持たない無効な Active Directory ディレクトリ サービス ユーザー アカウントが存在する可能性があることを示します。

Microsoft Exchange Server 2003 または Exchange 2000 Server を実行しているサーバー上にあるメールボックスを利用するには、このメールボックスを Active Directory ディレクトリ サービス ユーザー アカウントにリンクする必要があります。このリンクは、メールボックスに msExchMasterAccountSid Active Directory 属性を設定することにより確立されます。Exchange メールボックスのリンク先の Active Directory アカウントの状態は、有効または無効のどちらでもかまいません。無効なアカウントだけが、msExchMasterAccountSid 属性を持つユーザーを必要とします。

無効なユーザー アカウントで msExchMasterAccountSid 属性の値が空になっているか破損されており、そのユーザー アカウントを含むアクセス制御リスト (ACL) が構築されている場合、メールボックスまたはパブリック フォルダ リソースへのアクセスにその ACL が使用されると、パフォーマンスの問題が発生する可能性があります。

この警告に対処するには、次の操作を行います。

  • マイクロソフト サポート技術情報の文書番号 916783「ホットフィックスは、ホットフィックスは、Exchange Server 2003 SP2 が Exchange Server 2003 メールボックスに関連付けられる無効な Active Directory ユーザー アカウントを処理する方法を変更するのに使用できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=916783) で説明されている修正プログラムが、Exchange Server 2003 Service Pack 2 (SP2) に適用されていることを確認します。

  • イベント 9548 警告で説明されている ACL およびユーザー アカウントを調べて、msExchMasterAccountSid 属性値が空になっているか、または破損しているかどうかを判断します。必要に応じて、マイクロソフト サポート技術情報の文書番号 328880「Exchange 2000 または Exchange 2003 での ACL の変換に関連して発生するパブリック フォルダのパフォーマンス問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328880) の説明に従って、アカウントに対して有効な msExchMasterAccountSID 属性値を生成します。

  • マイクロソフト サポート技術情報の文書番号 278966「Exchange リソース メールボックスの移動やログオンができない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=278966) の説明に従って、ACL から無効なユーザー アカウントを削除します。

詳細情報

この問題の詳細については、以下のマイクロソフト サポート技術情報の文書と Exchange Server リソースを参照してください。

  • イベントおよびエラー メッセージ センターの MSExchangeIS メールボックス ストア イベント 9548 の詳細についてのページ (http://go.microsoft.com/fwlink/?LinkId=83135) (このサイトは英語の場合があります)

  • マイクロソフト サポート技術情報の文書番号 916783「ホットフィックスは、Exchange Server 2003 SP2 が Exchange Server 2003 メールボックスに関連付けられる無効な Active Directory ユーザー アカウントを処理する方法を変更するのに使用できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=916783)

  • マイクロソフト サポート技術情報の文書番号 328880「Exchange 2000 または Exchange 2003 での ACL の変換に関連して発生するパブリック フォルダのパフォーマンス問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328880)

  • マイクロソフト サポート技術情報の文書番号 278966「Exchange リソース メールボックスの移動やログオンができない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=278966)


SMTP インスタンスが見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの protocolCfgSMTPServer オブジェクト クラスの distingushedName 属性に対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスがユーザー指定の Exchange ゲートウェイ サーバー名で実行されているかどうかを判断します。

Exchange Server アナライザがユーザー指定の Exchange ゲートウェイ サーバーの SMTP 仮想サーバー インスタンスを検出できない場合、Exchange Server アナライザはエラーを表示します。

このエラーは一時的なネットワークの問題が原因で発生する場合がありますが、Active Directory の誤った情報を示す場合もあります。

この問題を解決するには、ユーザー指定の Exchange ゲートウェイ サーバーの SMTP 仮想サーバーの構成を確認します。

SMTP 仮想サーバー インスタンスの構成を表示するには

  1. Exchange システム マネージャを起動します。

    [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. 以下のコンテナに移動します。

    \Administrative Groups\GroupName\Servers\ServerName\Protocols\SMTP\SMTP Virtual Server Instance\

  3. 目的の SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. SMTP 仮想サーバー インスタンスの構成が正しいことを確認します。

SMTP 仮想サーバーの設定の詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 266686 の [XADM] SMTP サービスの構成方法 (第 1 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)。

  • 文書番号 268163 の [XADM] SMTP サービスの構成方法 (第 2 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)。

SMTP Service Design の詳細については、Exchange Server 2003 テクニカル リファレンス ガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=58876) の、SMTP Service Design に関するセクションを参照してください。

ネットワーク接続の問題に関する詳細については、マイクロソフト サポート技術情報の文書番号 325487 の、ネットワーク接続の問題のトラブルシューティング方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


NSPI ターゲット サーバーが手動で無効にされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Name Service Provider Interface ターゲット サーバー (NSPI target server) サービスが手動で無効にされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\NSPI Target Server

NSPI Target Server が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

クライアントの種類が異なれば、ドメイン コントローラとグローバル カタログ サーバーを使用してグローバル アドレス一覧 (GAL) を取得する方法も異なります。Microsoft Outlook® 2000 Service Release 2 (SR-2) より前の Exchange クライアントは、Exchange サーバー上でディレクトリ サービスを参照します。Exchange 2000 Server および Exchange Server 2003 は、Directory サービス プロキシ (DSProxy) と呼ばれるメカニズムを使用することにより、最も近いグローバル カタログ サーバーへの接続をクライアントに代わって確立し、さらに Outlook と グローバル カタログ サーバーの間のプロキシ接続を確立します。展開に関する要件によっては、DSProxy 要求の処理に使用する特定のグローバル カタログ サーバーを明示的に指定する必要がある場合があります。このためには、Exchange サーバーのレジストリ内にある NSPI Target Server エントリをハードコードします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

NSPI サーバーを手動で指定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. NSPI Target Server という名前の新しい REG_MULTISZ 値を作成します。

  4. 指定するサーバーの完全修飾ドメイン名を使用して、NSPI Target Server 値を構成します。

NSPI サーバーの固定設定を無効にするには、削除するサーバーの完全修飾ドメイン名を削除します。入力されているサーバーが NSPI ターゲット サーバーのみの場合は、NSPI Target Server レジストリ値を削除します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook 2000 SR-2 以降のクライアントが Active Directory® ディレクトリ サービスと通信する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 302914「[XCCC] Outlook 2000 から Active Directory へのアクセス方式」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914)

  • 文書番号 256976「MAPI クライアントから Active Directory へアクセスする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976)


Exchange Server 以外の MAPI サブシステムがインストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次の 2 つのフォルダにある MAPI32.dll のバージョンを判断します。

<ドライブ>:\Program Files\Exchsrvr\Bin

%Systemroot%\System32

両方のフォルダに MAPI32.dll の同じバージョンとコピーが見つからない場合は、エラーが表示されます。

MAPI の単一のバージョンが使用されるようにするために、Exchange Server セットアップ プログラムは、<ドライブ>:\Program Files\Exchsrvr\Bin ディレクトリと %Systemroot%\system32 ディレクトリの両方に MAPI32.dll をコピーします。Exchange Server コンピュータに、Microsoft Office Outlook® 2003 やサード パーティ製プログラムなどの別の MAPI アプリケーションがインストールされている場合は、このアプリケーションによって System32 フォルダに別のバージョンの MAPI32.dll がコピーされ、それにより Exchange の機能が阻害される可能性があります。こうした問題は、これらの 2 つの製品によって MAPI サブシステムの競合が発生し、この競合が Exchange Server か他の MAPI アプリケーションのどちらかを中断させなければ完全には調整できなくなるために発生します。

Outlook 2000 以降のバージョンの Outlook と、Exchange Server 2003、Exchange 2000 Server、または Exchange Server 5.5 の両方を同じコンピュータ上にインストールしないようにすることを強くお勧めします。

Outlook を Exchange Server と同じコンピュータ上にインストールする一般的な理由は、サーバー側のプログラムで特定の Outlook コンポーネントを利用することにあります。ほとんどのプログラム開発要件では、Exchange コンピュータに Outlook は必要ありません。Exchange Server には、Outlook オブジェクト モデルと同様の機能を提供できる、CDO (Collaboration Data Objects) が含まれています。CDO は、サーバー側で使用することを目的に設計されており、後のバージョンの Outlook に見られる影響も回避されています。詳細については、Microsoft サポート技術情報の文書番号 290500「[OL2002] Outlook 2002 電子メールのセキュリティ機能に関する開発者向け情報」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=290500) を参照してください。

別の一般的な理由として、MAPI プロファイルを作成するという要件があります。Exchange Server には MAPI プロファイルの作成に必要なすべての機能が含まれており、Outlook を必要とする理由はありません。Outlook をインストールしないで MAPI プロファイルを作成する方法の詳細については、Microsoft サポート技術情報の文書番号 306962「Outlook をインストールせずに MAPI プロファイルを作成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306962) を参照してください。

デモンストレーションの目的で Outlook と Exchange Server を同じコンピュータにインストールする必要がある場合は、デモンストレーションの目的用にテストされている、次のいずれかの構成を使用することをお勧めします。

  • Exchange 2000 Server を Outlook 2000 と共に使用

  • Exchange 2000 Server を Outlook 2002 と共に使用

このエラーを修正するには

  1. Exchange サーバーから Microsoft Outlook またはサード パーティ製 MAPI アプリケーションをアンインストールします。

  2. Exchange Server セットアップを再度実行し、[再インストール] をクリックします。

Microsoft Office Outlook 2003 と Microsoft Exchange Server の同じコンピュータ上での使用に関する詳細については、Microsoft サポート技術情報の文書番号 266418「Exchange Server コンポーネントと Outlook を同じコンピュータにインストールすることはマイクロソフトのサポート対象外」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266418) を参照してください。

MAPI 競合の解決の詳細については、Microsoft サポート技術情報の文書番号 229700「Microsoft Outlook で Mapisvc.inf ファイルの正しいパスを見つける方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=229700) を参照してください。

MAPI32 スタブ ライブラリの詳細については、「Messaging API (MAPI)」(http://go.microsoft.com/fwlink/?linkid=34395) を参照してください (このサイトは英語の場合があります)。


Microsoft 製以外の ESE エンジンが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Ese.dll の Version キーの値を判断します。Ese.dll は Exchange データベース ストレージ エンジンで、ESE (Extensible Storage Engine) とも呼ばれます。

また、Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータは Microsoft Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Microsoft Exchange Server 2003 を実行しています。

Exchange Server アナライザによって、Version の値にバージョン情報の一部として "6" という文字列が含まれず、しかも serialNumber の値により Exchange 2000 Server または Exchange Server 2003 がインストールされていることが検出されると、警告が表示されます。この警告は、この Exchange Server コンピュータに Microsoft 以外のバージョンの Ese.dll がインストールされ使用されていることを示します。この問題はできるだけ早く修正する必要があります。

考えられる原因の 1 つは、ESE ベースのウイルス対策ソフトウェアを使用していることです。ESE ベースのウイルス対策プログラムの一部は、Exchange インフォメーション ストアと ESE の間でサポートされていないインターフェイスを使用しています。この種のソフトウェアを使用すると、ソフトウェアの実装にエラーがあった場合にデータベースの破損やデータの消失の危険があります。

ESE ベースのスキャナは、インストール中に、ESE ベースのウイルス対策プログラムのサービスに依存するように Microsoft Exchange Information Store サービスを変更します。これにより、ESE ベースのウイルス対策プログラムのサービスが開始されてから、Microsoft Exchange Information Store サービスが開始されます。ESE ベースのウイルス対策プログラムが開始されると、Exchange Server に組み込まれているバージョンの Ese.dll は一時的に Xese.dll という名前に変更され、ESE ベースのウイルス対策プログラムに組み込まれているバージョンの Ese.dll が元のファイルに置き換わります。ESE ベースのウイルス対策プログラムに組み込まれているバージョンの Ese.dll がロードされたら、Exchange Server に組み込まれているバージョンの方は Ese.dll という名前に戻され、Microsoft Exchange Information Store サービスの開始処理が完了します。

Exchange Server コンピュータでは、Microsoft 以外の実装による ESE は使用しないことを強くお勧めします。Microsoft 製品サポート サービスでは、問題点を特定するために ESE ベースのウイルス対策プログラムを無効にすることをお願いする場合があります。ただし、問題点の根本原因が正しく突き止められた後であれば、そのソフトウェアを再度有効にしてもかまいません。

最も広く使用されている ESE ベースのウイルス対策プログラムは、Sybari Software 製の Antigen for Microsoft Exchange です。Microsoft と Sybari は、Sybari Antigen を無効にすることが、問題点の原因を判断するための有効なトラブルシューティング手順であることに合意しています。Sybari Software に連絡する方法については、同社の Web サイト (http://www.sybari.com/) を参照してください (このサイトは英語の場合があります)。

注 :
サードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供しているものです。この URL は予告なしに変更されることがあります。

Antivirus API (AVAPI) とも呼ばれる、VSAPI (Virus Scanning Application Programming Interface) をサポートしているウイルス対策プログラムを使用することもお勧めします。

この警告を修正するには

  1. Exchange Server コンピュータの完全なバックアップを実行します。

  2. Exchange Server をコンピュータからアンインストールします。

  3. Exchange Server をコンピュータに再インストールします。

  4. 最新の Service Pack と更新プログラムを Exchange Server に適用します。

Exchange Server でのウイルス対策ソフトウェアの実行に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 328841「[XADM] Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841)


Microsoft 以外の ESE (Extensible Storage Engine) が検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ESE (Extensible Storage Engine) とも呼ばれる Exchange データベース ストレージ エンジン、Ese.dll の Version キーの値を判断します。

また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトの serialNumber 属性値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータは Microsoft Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Microsoft Exchange Server 2003 を実行しています。

Version 値のバージョン情報の一部に "5.5" という部分文字列は含まれていないが、serialNumber の値から判断して Exchange Server 5.5 がインストールされていることが検出されると、警告が表示されます。この警告は、この Exchange Server コンピュータに Microsoft 以外のバージョンの Ese.dll がインストールされ使用されていることを示します。この問題は、可能な限り速やかに修正する必要があります。

この問題の原因の 1 つとして、ESE ベースのウイルス対策ソフトウェアを使用していることが考えられます。一部の ESE ベースのウイルス対策プログラムは、Exchange インフォメーション ストアと ESE の間でサポートされていないインターフェイスを使用します。この種のソフトウェアを使用すると、ソフトウェアの実装にエラーが発生した場合にデータベースが損傷したり、データが消失したりするという危険を冒すことになります。

ESE ベースのスキャナは、インストール中に、ESE ベースのウイルス対策プログラムのサービスに依存するように Microsoft Exchange Information Store サービスを変更します。これにより、ESE ベースのウイルス対策プログラムのサービスが開始されてから、Microsoft Exchange Information Store サービスが開始されます。ESE ベースのウイルス対策プログラムが起動すると、Exchange Server に含まれているバージョンの Ese.dll の名前が一時的に Xese.dll に変更され、元のファイルは ESE ベースのウイルス対策プログラムのバージョンの Ese.dll に置き換えられます。ESE ベースのウイルス対策プログラムのバージョンの Ese.dll が読み込まれた後、Exchange Server に含まれているバージョンの名前が Ese.dll に戻され、Microsoft Exchange Information Store サービスはスタートアップ プロセスを完了します。

Exchange Server コンピュータでは、Microsoft 以外の ESE 実装は使用しないようにすることを強くお勧めします。Microsoft 製品サポート サービスに連絡すると、問題を特定しやすくするために ESE ベースのウイルス対策プログラムを無効にするよう依頼されることがありますが、問題の根本的な原因が正しく診断された後は、再びそのプログラムを有効にしてもかまいません。

この警告を修正するには

  1. Exchange Server コンピュータの完全バックアップを実行します。

  2. そのコンピュータに Exchange Server を再インストールします。

  3. Exchange Server 用の最新の Service Pack と更新プログラムを適用します。これらは、Microsoft Exchange Server Web サイト (http://go.microsoft.com/fwlink/?LinkId=21573) から入手できます (このサイトは英語の場合があります)。
  • Exchange Server でウイルス対策ソフトウェアを実行する方法の詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

  • 同じコンピュータ名を使用して Exchange Server 5.5 コンピュータを再構築する方法の詳細については、Microsoft サポート技術情報の文書番号 155216「[XADM] 同じ名前の新しいコンピュータに Exchange Server を移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=155216) を参照してください。


非ページ プールが "警告" のしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_PerfOS_Memory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、PoolNonpagedBytes キーの現在の値を判断します。Exchange Server アナライザによって行われる操作は、基になるオペレーティング システム、Windows の Boot.ini ファイル内に /3GB のスイッチが存在するかどうか、および検出されたこのキーの値によって決定されます。

次の表は、このキーの値が、指定された Exchange サーバーについて範囲外にあるかどうかを判断するために Exchange Server アナライザによって使用される評価のマトリックスを示しています。次の表の条件を満たすと、警告が表示されます。

オペレーティング システム | Boot.ini の設定 | 現在の非ページ プールのサイズ
Microsoft Windows 2000 Server または Microsoft Windows 2000 Advanced Server | /3GB | 100 MB 以上
Microsoft Windows 2000 Server または Microsoft Windows 2000 Advanced Server | なし | 200 MB 以上
Microsoft Windows Server™ 2003 | /3GB | 100 MB 以上
Microsoft Windows Server 2003 | なし | 200 MB 以上

PoolNonpagedBytes キー値は、カーネル メモリ非ページ プールのバイト単位のサイズです。非ページ プールは、使用していないときでもディスクに書き込むことができないオブジェクトのための、物理的なシステム メモリの領域です。このキーのページ プール値は、最後に観察された値です。正常な Exchange サーバーでは、バックアップまたは復元が実行されていない限り、使用される非ページ プール メモリが 85 MB を超えることはありません。

Windows 2000 Server および Windows 2000 Advanced Server では、非ページ プール メモリの最大値は 256 MB です。非ページ プール メモリの制限を上記の値よりも大きくすることはできないため、この状態はできるだけ早く修正する必要があります。使用しているオペレーティング システムと /3GB スイッチの有無に関係なく、Windows からアクセスできる非ページ プール メモリはこれだけです。Windows のカーネル メモリがなくなると、エラー メッセージが表示され、クラッシュする場合があります。カーネル メモリは、システムの正常な動作にとってきわめて重要であるため、注意深く監視する必要があります。

Exchange Server の再起動後、この状態が再発した場合は、次の手順として、システムが正しく調整されているかどうか、およびシステムのソフトウェアとハードウェアがすべて最新のものであるかどうかを確認します。これには、以下に示す最新版のインストールも伴います。

  • Windows オペレーティング システムの Service Pack

  • Exchange Server の Service Pack

  • ハードウェアのファームウェアおよびドライバ

  • システム BIOS の更新ファイル

  • インストールされ、実行されているすべてのサード パーティ製アプリケーションの更新プログラム

ソフトウェアおよびハードウェアを更新してもこの問題を解決できない場合は、サード パーティ製ソフトウェアをすべて無効にし、Exchange Server コンピュータを再起動して、カーネル メモリを監視する必要があります。

このエラーを修正するには

  1. 早急に Exchange Server コンピュータを再起動します。

  2. [Memory] パフォーマンス オブジェクトの [Pool Nonpaged Bytes] パフォーマンス カウンタを監視して、その値が、使用しているシステムについて上に一覧されたしきい値を超えていないことを確認します。

Exchange Server を正しく調整する方法の詳細については、以下の Microsoft サポート技術情報の文書とホワイト ペーパーを参照してください。

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 266096「1 GB 以上の RAM がある場合、/3GB スイッチが必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • 『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)

  • 『Troubleshooting Exchange 2000 Performance』(http://go.microsoft.com/fwlink/?LinkId=18177) (このサイトは英語の場合があります)

  • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)

非ページ プール メモリおよび関連するトピックの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 294418「Windows XP および Windows Server 2003 における 32 ビット版と 64 ビット版のメモリ構造の比較」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=294418)

  • 文書番号 177415「Memory Pool Monitor (Poolmon.exe) を使用してカーネル モードのメモリ リークのトラブルシューティングを行う方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=177415)

  • 文書番号 268343「[Umdhtools.exe] Umdh.exe を使用してメモリ リークを検出する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268343)


ページ テーブル エントリの空き容量が少なく、システムが不安定になる可能性がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SystemPages レジストリの値の設定を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

SystemPages の値が 0 に設定されており、システムで空いているページ テーブル エントリ (PTE) の数が 3,001 よりも小さいことが検出されると、警告が表示されます。

Microsoft Windows Server™ 2003 と Windows® 2000 Server は、搭載されている物理 RAM の量とは無関係に、4 GB までのメモリ アドレス スペースのアドレスを直接指定することができます。プロセスの観点からは、仮想アドレスのどの要素も物理メモリの特定のバイトを参照することになります。各仮想アドレスを対応する物理アドレスに変換またはマッピングする処理は、仮想メモリ マネージャ (VMM) とプロセッサ メモリ管理ユニット (MMU) によって行われます。VMM は、RAM を固定サイズのページ フレームに分割し、これらのページ フレームに関する情報を格納するシステム PTE を作成してマッピングを実行します。システム PTE は小容量のカーネル モードのメモリ バッファであり、ディスク I/O サブシステムとネットワークとの通信を行うために使用されます。それぞれの PTE はページ フレームを表し、VMM がページを見つけるための必要な情報を含んでいます。

4 KB のページ サイズを使用する x86 ベースのシステムでは、2 GB のアドレス スペースをマッピングするために必要な PTE の最大数は 524,288 (2 GB ÷ 4 KB) です。/3GB スイッチを使用する同様のシステムでは、3 GB のアドレス スペースをマッピングするために必要な PTE の数は 786,432 (3 GB ÷ 4 KB) です。一般的なシステムでは、この領域は以下のように使用されます。

  • 一般的な用途のために、最大で 50,000 の PTE (約 195 MB のアドレス スペース) が予約されます。

  • 他の PTE は、システム キャッシュ、ハイパースペース、ページ プール、非ページ プール、クラッシュ ダンプ領域、その他のマッピングに使用されます。

この PTE プールのサイズは、システム内の物理メモリの容量に基づいて、システムの起動時に自動的に決定されます。このプールは、ページ プールと非ページ プール (非ページ プールもシステム内の物理メモリの容量と共に増加します) の間に割り当てられます。

システム PTE プールは、頻繁に使用され、断片化が激しくなることがあります。これにより、ドライバが読み込めなくなる事態が生じることがあります。また、システム PTE プールがすべて使い果たされると、システムの他の部分のパフォーマンスも低下します。それにより、スレッドが作成されなくなったり、システムが停止したり、さらにはシステムがクラッシュしたりする場合があります。

Exchange Server コンピュータが正しく動作するためには、使用可能なシステム PTE が常に少なくとも 5,000 必要です。空いているシステム PTE の数が 5,000 未満であるが、3,001 より多い場合は、「ページ テーブル エントリの空き容量が "警告" のしきい値に達した」の説明にある警告が表示されます。空いているシステム PTE の数が 3,001 未満に低下すると、このエラーが表示されます。この問題を解決するには、次の手順を使用して、Exchange Server コンピュータのオペレーティング システムに対して適切な SystemPages レジストリの値を設定します。1 GB 以上の RAM が実装されている Windows Server 2003 上で Exchange Server 2003 Service Pack 1 (SP1) を実行する場合、SystemPages レジストリ キーを 0 に設定することをお勧めします。この推奨事項は、Windows 2000 Server の場合とは対照的です。Windows 2000 Server では、SystemPages を 24,000 ～ 31,000 の間の値に設定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

次に説明する手順を実行した後で、空いているシステム PTE の数を監視します。Windows システム モニタ (パフォーマンス モニタとも呼ばれます) で Memory オブジェクトの Free System Page Table Entries カウンタを監視すると、システム PTE の数を監視できます。次に説明するレジストリの変更を行った後でも依然として空いているシステム PTE の数が少ない場合は、Exchange Server コンピュータが最適に構成されていることを確認するために次の点を調べます。

  • ドライバ システム PTE の数が不足する最も一般的な原因の 1 つは、ドライバの誤動作です。ハードウェアの製造元に確認し、すべてのハードウェアで最新のドライバを使用していることを確認してください。より基本的なドライバにダウングレードできる場合もあります。たとえば、Exchange Server などサーバー ベースのアプリケーションを実行するコンピュータでは、すべての機能を持つ高機能のビデオ ドライバは通常は必要ありません。多くの場合、より基本的なドライバで十分です。高機能のビデオ ドライバから基本的なビデオ ドライバに切り替えると、空いているシステム PTE の数が増加するはずです。

  • システム構成 使用しているシステムに 1 GB 以上の物理メモリが搭載されている場合は、以下の Microsoft サポート技術情報の文書で説明されているよに、/3GB スイッチと /USERVA=3030 スイッチを使用して Boot.ini ファイルが適切に構成されていることを確認する必要があります。

    • 文書番号 823440「Windows Server 2003 ベースのシステムに Exchange Server 2003 をインストールするとき、/3GB スイッチを使用する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

    • 文書番号 810371「[XADM] Windows 2003 Server ベースの Exchange Server で /Userva スイッチを使用する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371)

  • イベント ログ Exchange Server のアプリケーション イベント ログを調べ、エラーと警告、特に MSExchangeIS イベント 9582 (エラーと警告)、9665 (警告)、および 12880 (エラー) があるかどうかを調べます。イベント 9665 も、SystemPages が最適なパフォーマンスが得られるように構成されていないことを示す場合があります。これらのイベントの詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

Windows 2000 Server でこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに 24,000 ～ 31,000 (10 進数) の値を入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

Windows Server 2003 でこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のためのメモリ最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


現在ウイルス検索を待機している進行中の呼び出しの数が制限値に近い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルを調べ、Microsoft Exchange Information Store サービス (Store.exe) から Virus API (VAPI) コンポーネントへの進行中のコンポーネント間の呼び出しの数を判定します。

また、Exchange Server アナライザは次のレジストリ エントリから ScanningThreads キーのクエリを実行し、VAPI コンポーネントの呼び出しに使用可能なスレッドの最大数も判定します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Exchange Server アナライザが、Exchange Information Store サービス (Store.exe) から VAPI コンポーネントへの進行中の呼び出しの数が許可されるスレッドの最大数に近づいていることを検出すると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから VAPI コンポーネントへの進行中の呼び出しは、次の状況で生じることがあります。

  • ウイルス スキャン ソフトウェアに対する更新によって、インフォメーション ストアの項目が再スキャンされる

  • ウイルス スキャン ソフトウェアが不適切に構成されている

  • ウイルス スキャン ソフトウェアが処理するメッセージまたは添付ファイルのサイズが大きい

このエラーを解決するには、次の操作を行います。

  • リソースの消費が少ないとき、つまり需要がピークでない時間帯にウイルス エンジンの更新をスケジュールします。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。ただし、再インストールは需要がピークでない時間帯に実行します。

  • ウイルス スキャン エンジンの構成を調べ、スレッドの構成、ファイル レベルの除外などが適正であることを確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • ウイルス検索 API のスレッド数を増やします。

    ScanningThreads に最適な値は、(2 * NumberOfProcessors) + 1 です。たとえば、プロセッサを 2 つ搭載したサーバーで Exchange Server を実行している場合、ScanningThreads の最適値は 5 になります。

    注 :
    ハイパー スレッディングが有効な場合、NumberOfProcessors の値は物理プロセッサの数の 2 倍になります。ウイルス対策ソフトウェアの製造元に問い合わせて、物理プロセッサと論理プロセッサのどちらがこの式での使用に適しているかを判定するようにお勧めします。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
スレッド数を増やすには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. 右側のペインで、[ScanningThreads] をダブルクリックします。

  4. 上の式から得られた値を入力します。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリの編集方法の詳細が必要な場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

ハイパー スレッディング テクノロジの詳細については、Intel の Web サイト (http://www.intel.com/technology/hyperthread) を参照してください (このサイトは英語の場合があります)。

注 :
このトピックにあるサード パーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


OABGEN.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

Exchange Server アナライザによって、上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


Exchange Server 5.0 の最新の Service Pack、または更新プログラムのロールアップを入手する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が 1460 以上、1462 未満であることが検出されると、警告が表示されます。

この警告は、この Exchange Server コンピュータ上で、実行されているバージョンの Exchange に対応する入手可能な最新のコードが実行されていないことを示しています。

この警告を修正するには

  1. Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=41361) (このサイトは英語の場合があります) にアクセスし、Exchange Server 5.0 の最新の更新プログラム (2004 年 4 月リリース) をダウンロードします。

  2. この更新プログラムについては、Microsoft サポート技術情報の文書番号 834130「Microsoft Exchange Server 5.0 更新ロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834130) を参照してください。

  3. Exchange Server コンピュータ全体をバックアップします。

  4. 2004 年 4 月公開の更新プログラムを適用します。

Exchange Server 5.0 Service Pack 2 用の最新の更新プログラムのロールアップを入手するには、Microsoft サポート技術情報の文書番号 168858「[XGEN] Exchange Server 5.0 U.S 版 Service Pack 2 の入手方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=168858) を参照してください。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange Server 5.5 の最新の Service Pack、または更新プログラムのロールアップを入手する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が 26532653 以上、2658 未満であることが検出されると、警告が表示されます。この範囲の値は、このコンピュータで Exchange Server 5.5 Service Pack 4 または修正プログラムが適用された Exchange Server 5.5 Service Pack 4 が実行されていることを示しています。

この警告は、この Exchange Server コンピュータで、実行されているバージョンの Exchange に対する入手可能な最新のコードが実行されていないことを示しています。

この警告を修正するには

  1. Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=33456) にアクセスし、Exchange Server 5.5 の最新の更新プログラム (2004 年 5 月リリース) をダウンロードします (このサイトは英語の場合があります)。

  2. この更新プログラムについては、Microsoft サポート技術情報の文書番号 841765「2004 年 11 月公開の Exchange Server 5.5 用更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=841765) を参照してください。

  3. Exchange Server コンピュータ全体をバックアップします。

  4. 2004 年 5 月の更新プログラムを適用します。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange Server 2003 の最新の Service Pack、または更新プログラムのロールアップを入手する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。

  • Version キーの値 7638 は、Exchange Server 2003 Service Pack 2 を示す

  • Version キーの値 7226 は、Exchange Server 2003 Service Pack 1 を示す

  • Version キーの値 6944 は、最初のリリースの Exchange Server 2003 を示す

  • 上記のバージョンの間の値は、サーバーが Store.exe プロセスの修正プログラム更新バージョンを実行していることを示します。

Exchange Server アナライザによって Store.exe の Version キーの値が 7638 未満であることが検出されると、警告が表示されます。

この警告は、Exchange Server コンピュータが、そのコンピュータで実行中の Exchange Server のバージョンに対応する最新のコードを実行していないことを示します。

この警告を修正するには

  1. Exchange Server 2003 Service Pack 2 Web サイト (http://go.microsoft.com/fwlink/?LinkId=54751) で、Exchange Server 2003 用の Service Pack 2 をダウンロードするか、SP 1 の CD-ROM を注文します。

  2. Exchange Server 2003 Service Pack 2 (SP1) Release Notes Web サイト (http://go.microsoft.com/fwlink/?LinkId=52072) で、Service Pack 2 のリリース ノートの内容を確認します (このサイトは英語の場合があります)。

  3. Exchange Server コンピュータ全体をバックアップします。

  4. Exchange Server 2003 の Service Pack 2 を適用します。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法 」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


Exchange 2000 Server の最新の Service Pack、または更新プログラムのロールアップを入手する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータ上で実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.EXE プロセスの Version キーの値を判断します。STORE.EXE の Version キーの値が、以下に示す範囲のいずれかに含まれると判断されると、警告が表示されます。

  • 6249 より大きく 6396 以下である

  • 6396 より大きく 6487 以下である

  • 6487 より大きく 6556 以下である

  • 6556 より大きく 6603 以下である

  • 6603 より大きく 6700 未満である

この警告は、Exchange Server コンピュータが、そのコンピュータで実行中の Exchange のバージョンに対応する最新のコードを実行していないことを示します。

この警告を修正するには

  1. 「Downloads for Exchange 2000」Web サイト (http://go.microsoft.com/fwlink/?LinkId=33457) から、最新の更新プログラム (2004 年 8 月) をダウンロードします (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 870540「2004 年 8 月公開の Exchange 2000 Server Service Pack 3 以降の更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540) を参照して、最新の更新プログラムについて確認します。

  3. Exchange Server コンピュータの完全なバックアップを実行します。

  4. 2004 年 7 月の更新プログラムを適用します。

この更新プログラムのロールアップやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


オフライン アドレス帳サーパーが削除されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オフライン アドレス帳構成オブジェクトの offLineABServer 属性値を判断します。offLineABServer 属性に "DEL:" という文字列が含まれていないことが検出されると、エラーが表示されます。

offLineABServer 属性は、オフライン アドレス帳を作成する Exchange Server コンピュータの識別名が格納されている、単一値の識別名属性です。Exchange は、各オフライン アドレス帳のオフライン アドレス帳ファイルを、指定されたサーバーの一連のパブリック フォルダ内に生成および格納します。このエラーは、オフライン アドレス帳構成オブジェクトの offLineABServer 属性で指定されているサーバーが存在しないことを示しています。この状況は、古いオフラインのアドレス帳サーバーが使用を停止されているか、トポロジから誤って削除されている場合に発生することがあります。新しいサーバーが指定されるまで、Exchange はオフライン アドレス帳を作成しません。

Exchange Server 2000 または Exchange Server 2003 でこのエラーを修正するには

  1. Exchange システム マネージャの [受信者] で、[オフライン アドレス一覧] をクリックします。右側のペインで、[既定のオフライン アドレス一覧] (またはこのメッセージを作成する他のオフライン アドレス一覧) をクリックし、[プロパティ] をクリックします。

  2. [全般] タブの [オフライン アドレス帳サーバー] で、[参照] をクリックし、使用するサーバーをクリックします。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。アクション ペインの [移動] タブをクリックして、オフライン アドレス帳の移動ウィザードを起動します。このウィザードを使用すると、オフライン アドレス帳の生成を別のサーバーに移動できます。既存のオフライン アドレス帳ファイルを指定のサーバーにコピーすることもできます。

Exchange Management Shell を使用して、オフライン アドレス帳の生成をホストするサーバーを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Server> には、選択した処理を実行する Exchange サーバーを指定します。

    たとえば、オフライン アドレス帳の生成を SERVER01 に移動するには、次のように入力します。
コードのコピー
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink/?LinkId=79247) (英語) を参照してください。


オフライン アドレス帳サーバーがフロントエンド サーバーで実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オフライン アドレス帳構成オブジェクトの offLineABServer 属性の値を判断します。offLineABServer 属性は、オフライン アドレス帳を作成する Exchange Server コンピュータの識別名が格納されている、単一値の識別名属性です。

また、Exchange Server アナライザは Exchange_Server Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーの IsFrontEndServer キーの値を判断します。IsFrontEndServer キーの値が True の場合、Exchange サーバーはフロントエンド サーバーとして機能しています。

Exchange Server アナライザによって、指定されたオフライン アドレス帳サーバーがフロントエンド サーバーでもあることが検出されると、エラー メッセージが表示されます。

このエラーは、オフライン アドレス帳の生成用に指定されている Exchange サーバーがフロントエンド サーバーであることを示しています。指定されたオフライン アドレス帳サーバーがフロントエンド サーバーでもある場合、オフライン アドレス帳の生成は失敗します。このタスク用の新しいサーバーを指定する必要があります。Microsoft Exchange 2000 Server Service Pack 2 またはそれ以降を実行しているサーバーがフロントエンド サーバーとして指定されている場合、以下のサービスは実行されなくなります。

  • DSProxy

  • オフライン アドレス一覧の生成

  • 受信者更新サービス

  • 空き時間タスク

  • メールボックス クリーンアップ エージェント

  • Exchange Event サービス

  • サイト レプリケーション サービス (SRS)

フロントエンド サーバーは、Microsoft Office Outlook® Web Access、POP3、IMAP4、Exchange ActiveSync、Outlook Mobile Access、および RPC over HTTP を使用するように構成されている Outlook クライアントからの受信クライアント要求を処理するように設計されています。フロントエンド サーバーは、内部の Exchange サーバーに SMTP メッセージを中継するために使用されることもあります。

この問題を解決するには、バックエンド Exchange サーバーをオフライン アドレス帳サーバーとして指定することをお勧めします。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] で、[オフライン アドレス一覧] をクリックします。

  3. 右側のペインで、[既定のオフライン アドレス一覧] を右クリックし、[プロパティ] をクリックします。

    注 :
    このメッセージを生成するその他すべてのオフライン アドレス一覧について、同じ手順を実行します。

  4. [全般] タブの [オフライン アドレス一覧サーバー] で、[参照] をクリックし、使用するバックエンド Exchange サーバーをクリックします。

オフライン アドレス帳の操作の詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Configuring Exchange Server 2003 Offline Address Books」を参照してください (このサイトは英語の場合があります)。


オフライン アドレス帳サイトのパブリック フォルダが削除されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストア オブジェクトの siteFolderServer 属性の値を判断します。siteFolderServer 属性に "DEL:" という文字列が含まれていないことが検出されると、エラーが表示されます。

siteFolderServer 属性は、オフライン アドレス帳サーバー用に使用されているパブリック フォルダ ストアを表します。既定では、Exchange サーバーは、オフライン アドレス帳ファイルをサイト フォルダ サーバー (管理グループにインストールされている最初のサーバー) に作成します。別のサーバーをオフライン アドレス帳サーバーとして機能するように指定した場合は、管理グループの実際のサイト フォルダ サーバーではなく、この属性に列挙されているパブリック フォルダ ストアが新しいオフライン アドレス帳サーバー上のストアになります。

Exchange Server 2003 がオフライン アドレス帳ファイルを作成する場合は、ファイルをメール メッセージに添付し、そのメッセージを特殊なパブリック フォルダに格納します。Microsoft Office Outlook® 2003 がそのパブリック フォルダからメッセージを取得し、添付ファイルをダウンロードします。

オフライン アドレス帳のメッセージは、Offline Address Book フォルダのサブフォルダに格納されます。このフォルダは、既定の [パブリック フォルダ] ツリーにあるシステム フォルダの 1 つです。このフォルダには、トポロジ内の各管理グループまたはサイト に対応するサブフォルダが含まれています。既定では、特定の管理グループ フォルダの内容のレプリカは、管理グループにインストールされた最初のサーバー (サイト フォルダ サーバー) にあります。

Exchange 組織が Exchange Server 2007 で、下位レベル (Outlook 2003 またはそれ以前) のクライアントがない場合は、この警告またはエラーを無視できます。Exchange Server 2007 組織で、Outlook 2003 またはそれ以前を実行するクライアントをホストしている場合は、次の手順に従って、オフライン アドレス帳ファイルのパブリック フォルダ配布を有効にします。パブリック フォルダの配布は、Outlook 2003 またはそれ以前を実行する、オフラインまたはダイヤルアップ接続で動作するクライアントから OAB へのアクセスに使用する配布方法です。

このエラーを修正するには

  1. サーバーが存在することがわかっている場合は、Exchange システム マネージャで、[サーバー] の下のサーバーを展開し、ストレージ グループを展開します。次に、[パブリック フォルダ ストア] をクリックします。右側のペインで、Exchange ストアが実行されていることを確認します。

  2. 新しいオフラインアドレス帳サーバーを指定するには、[受信者] で [オフライン アドレス一覧] をクリックします。右側のペインで、[既定のオフライン アドレス一覧] (または、このメッセージを作成する他のオフライン アドレス一覧) をクリックします。

    オフライン アドレス帳を使用しない場合は、[既定のオフライン アドレス帳] を右クリックし、[削除] をクリックします。それ以外の場合は、残りの手順でスケジュールを設定します。

  3. [既定のオフライン アドレス一覧] を右クリックし、[プロパティ] をクリックします。

  4. [全般] タブの [オフライン アドレス帳サーバー] で、[参照] をクリックしてサーバーを選択します。

Exchange Server 2007 の場合にこの警告を修正するには

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[組織の構成] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、[既定のオフライン アドレス帳] を選択します。

    1. オフライン アドレス帳のパブリック フォルダの配布を有効にするには、[配布] タブの [パブリック フォルダの配布を有効にする] をクリックします。

    2. [OK] をクリックし、変更を保存します。

  5. 新しいオフライン アドレス帳サーバーを指定するには、アクション ペインの [移動] をクリックして、オフライン アドレス帳の移動ウィザードを起動します。このウィザードを使用すると、オフライン アドレス帳の生成を別のサーバーに移動できます。既存のオフライン アドレス帳ファイルを指定のサーバーにコピーすることもできます。

Exchange Management Shell を使用して、オフライン アドレス帳ファイルのパブリック フォルダ配布を有効にするには

  • 次のコマンドを実行します。

    コードのコピー
    Set-OfflineAddressBook -Identity <OAB> -PublicFolderDistributionEnabled $true

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。

    たとえば、既定のオフライン アドレス帳のパブリック フォルダ配布を有効にするには、次のように入力します。
コードのコピー
Set-OfflineAddressBook -Identity "\Default Offline Address Book" -PublicFolderDistributionEnabled $true

Exchange Management Shell を使用して、オフライン アドレス帳の生成をホストするサーバーを設定するには

  • 次のコマンドを実行します。

    コードのコピー
    Move-OfflineAddressBook -Identity <OAB> -Server <Server>

    ここで、<OAB> は、オフライン アドレス帳の識別名 (DN)、ドメイン\アカウント名、または GUID です。<Server> には、選択した処理を実行する Exchange サーバーを指定します。

    たとえば、オフライン アドレス帳の生成を SERVER01 に移動するには、次のように入力します。
コードのコピー
Move-OfflineAddressBook -Identity "My OAB" -Server "Server1"

オフライン アドレス帳の操作の詳細については、Exchange Server 2003 ストアの操作に関するページの Exchange Server 2003 オフライン アドレス帳の構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47595) (英語) を参照してください。

Exchange Server 2007 でのオフライン アドレス帳の操作の詳細については、[組織の構成] > [メールボックス] > [オフライン アドレス帳] に関するページ (http:// go.microsoft.com/fwlink/?LinkId=79247) (英語) を参照してください。


古い CDO.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い DAVEX.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い DRVIIS.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる複数のコア Exchange Server バイナリ ファイルの Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • DrvIis.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用してる Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や更新プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで、<ドライブ> は CD-ROM のドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) (英語) を参照してください。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) (英語) を参照してください。


古い DSACCESS.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EMSMTA.EXE ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EPOXY.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い ESE.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-06-20

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロードについてのページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い ESEUTIL.EXE ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXCDO.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを解決するには、使用しているバージョンの Exchange 用の最新の Service Pack または更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXCHMEM.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXCHMEM.DLL が存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、複数のコア Exchange Server バイナリ ファイルの Version キーの値を判断します。これらのファイルには Exchmem.dll が含まれています。Exchange Server アナライザによって \%systemroot%\system32 フォルダ内の Exchmem.dll ファイルが \%exchangeroot%\bin フォルダ内の Exchmem.dll ファイルより古いことが検出されると、警告が表示されます。

通常、1 つのサーバー上に Exchmem.dll のコピーが 2 つ存在することはありません。ただし、インプレース アップグレードで製品の前のリリースからアップグレードすると、2 つ目の Exchmem.dll ファイルが追加されることがあります。このファイルのバージョンが 2 つ存在すると、サービス リリースのインストール時にセットアップに失敗する可能性があります。この問題を防止するには、\%systemroot%\system32 フォルダにある Exchmem.dll ファイルの名前を変更することをお勧めします。

この警告を修正するには

  1. すべての Exchange サービスを停止します。

  2. \%systemroot%\system32 フォルダにある Exchmem.dll ファイルの名前を Exchmem.dll.old に変更します。

  3. すべての Exchange サービスを再開します。


古い EXMIME.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXOLEDB.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXPOP3.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXPROX.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXRES.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い EXSMTP.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い MAD.EXE ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い MAPI32.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


system32 フォルダで古い MAPI32.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い MDBSZ.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い OABGEN.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い PHATCAT.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い PHATQ.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い REAPI.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い RESVC.DLL ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルについて Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダの両方で確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


古い STORE.EXE ファイルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる複数のコア Exchange Server バイナリ ファイルの Version キーの値を判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Gapi32.dll (System32 フォルダと \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上に示したいずれかのファイルについて、Version の値が Exchange Server の Version の値より小さいことが検出されると、警告が表示されます。バージョン番号が小さい場合、古いファイルが使用されている可能性があります。

このエラーを修正するには、最新の Service Pack、または使用してる Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や更新プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで、<ドライブ> は CD-ROM のドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) (英語) を参照してください。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) (英語) を参照してください。


Active Directory への進行中の呼び出しが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-14

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から Active Directory® ディレクトリ サービスへの進行中のコンポーネント間の呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Active Directory は、メールボックス情報、アドレス一覧サービス、およびその他の受信関連情報のすべてを提供します。Exchange Server 2003 の構成情報の大部分も Active Directory に格納されます。

Exchange Server サービスは、Active Directory に格納された情報にアクセスし、Active Directory に情報を書き込みます。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から Active Directory への呼び出しが進行中であることを示していることが検出されると、警告が表示されます。

この警告は、サーバーのパフォーマンスに問題が発生する可能性があることを示します。進行中の呼び出しが頻繁でなければ、問題の兆候であるとは限りませんが、同じ領域への進行中の呼び出しが繰り返し検出される場合は問題になる可能性があります。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから Active Directory への進行中の呼び出しは、次の状況で生じることがあります。

  • Exchange サーバーとドメイン コントローラ間のネットワーク待ち時間。

  • DSAccess が静的または不適切に構成されている。

  • ドメイン コントローラおよびグローバル カタログの負荷が高すぎる。

  • Active Directory トポロジが不適切に設計されている。

この警告に対処するには、次の操作を行います。

  • Exchange Server アナライザでサーバーの問題の詳細分析を実行します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます。

  • Active Directory ドメイン コントローラ サーバーのパフォーマンスを確認します。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange のパフォーマンスおよび DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

ドメイン コントローラのパフォーマンスの詳細については、以下の Windows Server リソースを参照してください。

  • 「Planning Domain Controller Capacity」(http://go.microsoft.com/fwlink/?LinkId=70191) (このサイトは英語の場合があります)

  • Windows 2000 Server の Active Directory の計画および展開に関するガイドの Active Directory のドメイン コントローラの監視に関する記事 (http://go.microsoft.com/fwlink/?LinkId=70193)


ESE への進行中の呼び出しが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から Exchange Extensible Storage Engine (ESE) への進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Microsoft Exchange Information Store は、Extensible Storage Engine (ESE) データベースに基づきます。ESE は、トランザクション ベースの高度なデータベース エンジンです。トランザクションとは、アトミック (それ以上分割できない) 単位として扱われる一連の操作です。トランザクション内のすべての操作が実行されて完全に保存されるか、いずれの操作も実行されないかのどちらかです。

Exchange Server は、データベースの構造を決定し、メモリを管理する埋め込みデータベース エンジンとして ESE を使用します。このデータベース エンジンでは、データのチャンク (ページ) をメモリに転送したり、メモリから転送したりすることによって、データベースをメモリにキャッシュします。メモリ内のページが更新され、新しいページまたは更新されたページがディスクに再度書き込まれます。要求がシステムに送信された際、データベース エンジンはデータをメモリにバッファリングできます。そのため、ディスクに繰り返しアクセスする必要はありません。

メモリへのデータのキャッシュは、データを処理する最も迅速で効率的な方法ですが、Exchange の実行中は、ディスク上の情報が完全に最新ではないことを意味します。最新版のデータベースはメモリ内にあります。ただし、メモリ内の多くの変更がまだディスクに保存されていないため、データベースとメモリは同期されていません。トランザクション ログ ディスクは常に、各トランザクションに関する情報で最新の状態に維持されます。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から Extensible Storage Engine (ESE) データベースへの進行中の呼び出しを表していることが検出されると、警告が表示されます。

この警告は、このサーバーでパフォーマンスが問題になる可能性があることを示しています。進行中の呼び出しが頻繁でなければ、問題の兆候であるとは限りませんが、同じ領域への進行中の呼び出しが繰り返し検出される場合は問題になる可能性があります。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Microsoft Exchange Information Store サービスから Extensible Storage Engine (ESE) への進行中の呼び出しは、以下の状況で生じることがあります。

  • Exchange のオンライン最適化

  • データ バックアップ

    注 :
    Exchange Call Trace logging の収集時にデータ バックアップまたはオンライン最適化が処理されていた場合は、Exchange Server のパフォーマンス問題を示すこの警告を無視しても問題ありません。
  • サーバー上のユーザー数に対する必要な領域の不足など、データベース ドライブのボトルネック

  • TEMP および TMP ドライブのボトルネック

このエラーを解決するには、次の操作を行います。

  • ベスト プラクティスとして、バックアップ ウィンドウやオンライン保守が、ユーザーの需要が最高の期間と重ならないようにすることをお勧めします。

  • データベース ディスク ドライブが正常で、I/O 負荷に十分なスループットがあることを確認します。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

オンライン最適化の時間ウィンドウを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 244524 の [XADM] Exchange Server のオンライン最適化の時間ウィンドウの構成方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=244524) を参照してください。

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

ESE の詳細については、「Extensible Storage Engine アーキテクチャ」(http://go.microsoft.com/fwlink/?linkid=67009) を参照してください。


IMAIL への進行中の呼び出しが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から MAPI クライアントの IMAIL コンポーネントへの進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Exchange Server の IMAIL コンポーネントは柔軟性に富んだ変換サービスで、インターネット メッセージと MAPI メッセージ間で Microsoft Exchange Information Store サービスによって使用されます。これによって、RFC-822 またはインターネット形式を使用するクライアントと、MAPI クライアントや内部ストア タスクなど、Exchange Server の内部ストレージ形式を使用するクライアント間の相互運用性が実現します。

Exchange では IMAIL メカニズムを使用して、Exchange システム マネージャでインターネット ドメインに定義されたメッセージ形式または Microsoft Office Outlook® で各受信者にユーザーが指定したメッセージ形式を内容に適用します。形式パラメータが IMAIL に渡されなかった場合、IMAIL は MAPI メッセージを Summary TNEF (S/TNEF) 形式に変換してサーバー間で転送します。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが Microsoft Exchange Information Store サービス (Store.exe) から MAPI クライアントの IMAIL コンポーネントへの進行中の呼び出しを表していることが検出されると、警告が表示されます。

この警告は、このサーバーでパフォーマンスが問題になる可能性があることを示しています。進行中の呼び出しが頻繁でなければ、問題の兆候であるとは限りませんが、同じ領域への進行中の呼び出しが繰り返し検出される場合は問題になる可能性があります。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

以下の条件の 1 つ以上に該当する場合、Exchange Information Store サービスから MAPI クライアントの IMAIL コンポーネントへの進行中の呼び出しが発生する可能性があります。

  • IMAIL がメッセージまたは添付ファイル内の大量のデータを処理しようとする。

  • 多数のクライアントがデータ変換を要求する。

  • DSAccess 要求に対する応答が遅い。

  • TEMP および TMP ドライブにボトルネックがある。

  • メールボックスの移動が進行中である。

この警告に対処するには、次の操作を行います。

  • 需要がピークでない時間帯にメールボックスの移動をスケジュールします。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

Exchange Server のメッセージ サイズの制限に関するベスト プラクティスの詳細については、「送信メッセージの最大サイズが設定されていない」を参照してください。

DSAccess と Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) の「DSAccess ユーザー キャッシュを構成する方法」を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


LSASS への進行中の呼び出しが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Exchange Information Store サービス (Store.exe) からローカル セキュリティ認証サーバー (Lsass.exe) プロセスへの進行中のコンポーネント間の呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

ローカル セキュリティ認証サーバー プロセス (Lsass.exe) は、アカウント情報の確認とログオンの検証のために他のプロセスによって起動されるセキュリティ サブシステムです。

Exchange のクライアント ログオンが行われるたびに、Exchange Server を実行するサーバーはクライアントのアカウント セキュリティ識別子 (SID) を参照する要求を送信し、ローカル セキュリティ認証サーバー (Lsass.exe) プロセス内で呼び出しを生成します。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントが、Microsoft Exchange Information Store サービス (Store.exe) からローカル セキュリティ認証サーバー (Lsass.exe) プロセスへの呼び出しが進行中であることが検出されると、警告が表示されます。

この警告は、このサーバーでパフォーマンスが問題になる可能性があることを示しています。進行中の呼び出しが頻繁でなければ、問題の兆候であるとは限りませんが、同じ領域への進行中の呼び出しが繰り返し検出される場合は問題になる可能性があります。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Exchange Information Store サービスから LSASS プロセスへの進行中の呼び出しは、以下の状況で生じることがあります。

  • 同時に認証を実行するユーザー数に関するサーバー リソースの問題

  • Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間

  • サーバー リソースのボトルネックの問題

この警告に対処するには、次の操作を行います。

  • 「'NeverPing' パラメータで推奨メッセージが表示される」の説明に従った NeverPing パラメータの実装を検討します。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Lsass.exe プロセスおよびメモリ使用量の詳細については、Microsoft サポート技術情報の文書番号 308356「Windows Server 2003 または Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356) を参照してください。

Exchange のクライアント ログオン、および LSASS の問題の詳細については、Microsoft サポート技術情報の文書番号 161938「リソースデッドロックで Exchange クライアントのログオンが遅い」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938) を参照してください。

Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間の詳細については、Exchange Server チームのブログ記事「Exchange Does Not Always Use Local GCs」(http://go.microsoft.com/fwlink/?LinkId=69166) を参照してください (このサイトは英語の場合があります)。

注 :
それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

サーバー リソースのボトルネックの問題の詳細については、「プロセッサのボトルネック」を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


ウイルス スキャン ソフトウェアに対する進行中の呼び出しが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、Microsoft Exchange Information Store サービス (Store.exe) から Virusscan Virus API (VAPI) コンポーネントへの進行中のコンポーネント間呼び出しを示すイベントを調べます。

進行中の呼び出しとは、Exchange FCL データが Store.fcl ファイルに書き込まれるときに応答がなかった、Microsoft Exchange Information Store サービス (Store.exe) から他のコンポーネントへの要求です。

Exchange Server アナライザによって Store.fcl ログ ファイル内のイベントが、Microsoft Exchange Information Store サービス (Store.exe) から VAPI コンポーネントへの呼び出しが進行中であることを示していることが検出されると、警告が表示されます。

この警告は、このサーバーでパフォーマンスが問題になる可能性があることを示しています。進行中の呼び出しが頻繁でなければ、問題の兆候であるとは限りませんが、同じ領域への進行中の呼び出しが繰り返し検出される場合は問題になる可能性があります。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Exchange Information Store サービスから VAPI コンポーネントへの進行中の呼び出しは、以下の状況で生じることがあります。

  • ウイルス スキャン ソフトウェアに対する更新によって、インフォメーション ストアの項目が再スキャンされる

  • ウイルス スキャン ソフトウェアが不適切に構成されている

  • ウイルス スキャン ソフトウェアが処理するメッセージまたは添付ファイルのサイズが大きい

この警告に対処するには、次の操作を行います。

  • リソースの消費が少ないとき、つまり需要がピークでない時間帯にウイルス エンジンの更新をスケジュールします。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。ただし、再インストールは需要がピークでない時間帯に実行します。

  • ウイルス スキャン エンジンの構成を調べ、スレッドの構成、ファイル レベルの除外などが適正であることを確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


オペレーティング システムの GlobalFlag が設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、GlobalFlag エントリの値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager

GlobalFlag の値が存在しており、0 または NULL 以外の値で構成されていることが検出されると、警告が表示されます。

  • GlobalFlag レジストリ値の設定は、オペレーティング システムでどのデバッグ オプションが有効になっているかを決定するビットマスクです。Microsoft 製品サポート サービスの支援を受けて問題のデバッグや追跡を実際に行っている場合以外は、GlobalFlag 値を常に 0 に設定することをお勧めします。

GlobalFlag レジストリ値は、既定で 0 に設定されています。この値が既定の 0 から変更されている場合は、Microsoft Windows Server™ 2003 のサポート ツールに含まれている Gflags ツール (Windows Server 2003 の CD-ROM の \Support フォルダに格納されている) を使用することができます。あるいは、レジストリ エディタを使用して、この値を手動で 0 に設定することもできます。以下では、この両方の手順について説明します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

GFlags を使用してこのエラーを修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスに「GFlags」と入力します。Global Flag のユーザー インターフェイスが表示されます。

  2. すべてのチェック ボックスをオフにし、[適用] をクリックします。

  3. [OK] をクリックして GFlags ツールを終了し、コンピュータを再起動して、変更を有効にします。

レジストリ エディタを使用してこのエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\ System\CurrentControlSet\Control\Session Manager

  3. GlobalFlag という名前の値をダブルクリックし、その値のデータを 0 に設定します。

  4. レジストリ エディタを終了し、コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


オペレーティング システムがデバッグ モードになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_OperatingSystem Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、Debug プロパティに値が設定されているかどうかを判断します。Exchange Server コンピュータで、このキーの値が True に設定されている場合は、エラーが表示されます。

Windows デバッグ モードには、Boot.ini ファイルに /debug パラメータを追加して切り替えます。Windows Server コンピュータの Boot.ini ファイルに /debug が指定されていると、起動時にカーネル デバッガが読み込まれ、メモリ内に常に保持されます。これにより、システムがカーネルの停止画面で中断された場合でなくても、サポートの専門家がデバッグ中のシステムにダイヤルインし、デバッガに入ることができます。/crashdebug スイッチとは異なり、/debug スイッチの使用時には、デバッグ中かどうかにかかわらず COM ポートが使用されます。このスイッチは、何度でも再現できる問題のデバッグを行う場合に使用されます。この /debug パラメータは、問題のトラブルシューティングを行うための手段として設定され、誤って設定されたままになった可能性があります。

追加のプロセスが実行されるため、パフォーマンスが大幅に低下します。このため、Windows がデバッグ モードで実行されているコンピュータで Exchange Server を実行することはお勧めできません。

このエラーをなくすには、Boot.ini ファイルを編集し、/debug パラメータを削除します。

このエラーを修正するには

  1. Windows エクスプローラで、システム パーティションに移動します。これは、Boot.ini や NTLDR のようなハードウェア固有のファイルが格納されているパーティションです。

  2. Boot.ini ファイルが表示されない場合は、原因として、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合、Windows エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。確認を求めるメッセージが表示されたら、[はい] をクリックします。

  3. Boot.ini ファイルが Windows エクスプローラに表示されたら、このファイルを右クリックし、[プログラムから開く] をクリックします。次に、[メモ帳] をクリックしてファイルを開きます。

  4. [Operating Systems] セクションで、/debug パラメータを削除します。

  5. ファイルを保存して閉じてから、Exchange Server コンピュータを再起動して変更を有効にします。

Boot.ini ファイルで使用できるパラメータの詳細については、Microsoft サポート技術情報の文書番号 833721「Windows XP および Windows Server 2003 の Boot.ini ファイルで使用可能なスイッチ オプション」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833721) を参照してください。


Outlook Web Access には Windows Server 2003 SP1 用の修正プログラムが必要である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-08-28

Microsoft® Exchange Server アナライザ ツールは、さまざまな Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下の情報を収集します。

  • Exchange Server がインストールされている Microsoft Windows Server オペレーティング システムのバージョン

  • クラスタ上で Exchange サーバーが実行されているかどうか

Exchange Server アナライザ ツールによって以下の条件に当てはまると判断されると、警告が表示されます。

  • Exchange Server 2003 Service Pack 1 (SP1) がインストールされている。

  • Microsoft Windows Server™ 2003 SP1 がインストールされていない。

  • クラスタ サービスが実行されている。

  • Davex.dll の Version の値が 6.5.7232 より小さい。

この構成を実行している場合、Windows Server 2003 SP1 をインストールする前に、Exchange Server の修正プログラムをダウンロードしてインストールする必要があります。Exchange Server の修正プログラムをインストールしないと、Microsoft Office Outlook® Web Access for Exchange Server 2003 ユーザーはメールボックスにログオンすることができません。クラスタ上でホストされているメールボックスを持つユーザーが Outlook Web Access を使用してメールボックスに接続しようとすると、次のエラー メッセージが表示されます。

  • "500 - 内部サーバー エラー"

このエラーは、Windows Server 2003 SP1 に含まれている一部のセキュリティ強化機能が原因で発生します。

ユーザーが Outlook Web Access を使用してメールボックスにログオンしようとすると、HTTP はログオン ユーザーに偽装して、クラスタ API に要求を送信します。しかし、Windows Server 2003 SP1 ではセキュリティに関する変更があり、リモート レジストリへのアクセスを行う API に対するセキュリティ制限が変更されました。このため、ログインは成功しません。

このエラーを修正するには、Microsoft サポート技術情報の文書番号 841561 の、クラスタ化された Exchange Server 2003 のバックエンド サーバーにユーザーが Outlook Web Access を使用してアクセスするとき、"500 - 内部サーバー エラー" というエラー メッセージが表示される現象についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841561) で説明されている Exchange Server 修正プログラムをダウンロードしてインストールする必要があります。


Outlook Web Access テンプレート ファイルが一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Wmtemplates.dll ファイルのバージョン番号を判断します。次に、管理グループ内のすべてのサーバーの Wmtemplates.dll のバージョン番号を比較します。フロントエンドとバックエンドの Exchange サーバーの間で Wmtemplates.dll のバージョン番号が一致しないことが検出されると、ベスト プラクティスのメッセージが表示されます。

Wmtemplates.dll ファイルは、Microsoft Office Outlook® Web Access コントロールによって使用されます。フロントエンドとバックエンドの Exchange サーバーで Wmtemplates.dll のバージョンが一致していないと、ユーザーがフロントエンドの Exchange サーバーにアクセスして Outlook Web Access にログオンしようとしたときに 400 レベルのエラーが発生する可能性があります。

Wmtemplates.dll を更新する次の 2 つの更新プログラムが最近 Microsoft からリリースされています。

  • 「Exchange Server 2003 SP1 を定期的にインストールした後に、Microsoft Exchange Information Store サービスがクラッシュ。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=872963)

  • 「Exchange Server 2003 OWA クライアントを Windows XP Service Pack 2 ベースのコンピュータで実行しているときに、S/MIME コントロールが OWA に読み込まれない」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=883543)

最近、このどちらかの更新プログラムをインストールしている場合は、次の状況に当てはまる可能性があります。

  • 更新プログラムが正しい順序でインストールされていない。

  • 更新プログラムがフロントエンド サーバーとバックエンド サーバーの両方にはインストールされていない。

Outlook Web Access の更新プログラムをインストールする場合は、更新プログラムをフロントエンド サーバーにインストールし、サーバーを再起動してから、更新プログラムをバックエンド サーバーにインストールする必要があります。

このどちらかの更新プログラムをインストールしていない場合は、すべてのサーバーで最新の Exchange Server Service Pack と更新プログラムが実行されていることを確認してください。

最新の Exchange Server Service Pack と更新プログラムについては、次の Web サイトを参照してください。

  • Exchange Server 2003 のダウンロード ページ(http://go.microsoft.com/fwlink/?LinkId=21236) (このサイトは英語の場合があります)

  • Exchange Server 2000 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) (このサイトは英語の場合があります)


未解決の RPC 要求が最大しきい値に達した
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの RPC Requests パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル時間中に、RPC 要求の数がピーク値の 100 に達したことが検出されると、Exchange Server アナライザによってエラーが表示されます。

RPC Requests パフォーマンス カウンタは、Microsoft Exchange Information Store サービスによって現在処理されている要求である、MAPI リモート プロシージャ コール (RPC) またはクライアントの数を示します。RPC Requests パフォーマンス カウンタの平均値は、常に 30 未満にする必要があります。既定では、RPC 要求の最大値は 100 です。したがって、別の方法で構成しない限り、Microsoft Exchange Information Store サービスが同時に処理できる RPC 要求数は 100 のみで、それ以上の新しいすべての RPC 操作は拒否されます。ユーザーは RPC 要求数が 100 未満に低下するまでサーバーに接続できません。このサーバーは応答しなくなり、メール フローが停止する可能性があります。さらに、Outlook ユーザーに [要求の取り消し] ダイアログ ボックスが表示される場合があります。

このエラーは、サーバーにパフォーマンスのボトルネックが発生したか、プロセスの応答が停止したことを示します。

パフォーマンスのボトルネックは、CPU、ディスク、ネットワーク、またはメモリに関連する場合があり、サーバーに対する負荷の増大、またはサーバーのリソース不足が原因で発生します。パフォーマンス モニタ (Perfmon.msc) ツールを使用して、ボトルネックがサーバーに対する負荷の増大によって発生しているのか、サーバーのサイズが小さいために発生しているのかを判断します。サーバーの負荷が増大している場合は、原因を突き止めて負荷を減らします。サーバーのリソースが不十分な場合は、必要なリソースを増やすか、ユーザーをサーバーから移動します。

返されることのないリソースをストアが待っているため、プロセスが応答を停止する場合があります。例としては、メッセージ追跡をホストするドライブとクラスタとの接続が切断された場合、またはウイルス スキャン ソフトウェアの問題が発生した場合などがあります。プロセスの応答が停止すると、RPC 要求に対する応答が行われなくなるため、ストアを再起動する必要があります。

詳細情報

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する計画方法の詳細については、「Exchange Server 2003 Performance:10 Things to Think About」(http://go.microsoft.com/fwlink/?LinkID=56460) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


PHATCAT.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

Exchange Server アナライザによって、上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」Web サイト (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


PHATQ.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応した更新プログラムのロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


ページ ファイルのパフォーマンスの問題
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、LogicalDisk パフォーマンス オブジェクトの PAGEDISK インスタンスの Avg Disk sec/Read カウンタと Avg Disk sec/Write カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Avg Disk sec/Read カウンタおよび Avg Disk sec/Write カウンタが 10 ミリ秒 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

LogicalDisk パフォーマンス オブジェクトは、ハード ディスクの論理パーティションを監視する Avg Disk sec/Read カウンタおよび Avg Disk sec/Write カウンタなどのカウンタで構成されています。Avg Disk sec/Read パフォーマンス カウンタは、ディスクからのデータ読み取りの平均時間 (秒) を示しています。Avg Disk sec/Write パフォーマンス カウンタは、ディスクへのデータの書き込みの平均時間 (秒) を示しています。Avg Disk sec/Read パフォーマンス カウンタと Avg Disk sec/Write パフォーマンス カウンタの平均値は、10 ミリ秒未満である必要があります。

サーバー上の LogicalDisk パフォーマンス オブジェクトの PAGEDISK インスタンスは、ページ ファイル (Pagefile.sys) を表します。Pagefile.sys は、ハード ディスク上の隠しシステム ファイルであり、システムの RAM が不足したときに Microsoft Windows® が一時データを格納するために使用します。ページ ファイルは、ページング ファイルまたはスワップ ファイルとも呼ばれます。

このエラーは、ページ ファイルをホストしているディスクに待ち時間の問題があることを示します。

このエラーを解決するには、次の操作を行います。

  • 待ち時間の原因を突き止めます。この問題が過剰なページングが原因により発生する場合は、サーバーのメモリの問題が原因である可能性があります。

  • ページ ファイルを専用のパーティションまたは高速なディスクに配置することを検討します。

  • 代わりのドライブ上に 2 次ページ ファイルを作成することを検討します。詳細については、Microsoft サポート技術情報の文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379) を参照してください。

  • サーバーの保守作業は、ピーク時以外の時間帯に行います。Exchange Server データベース ユーティリティ (Eseutil.exe) などの保守ツール、またはメールボックスの管理などのタスクをピーク時に実行すると、Exchange で使用できるメモリが消費されます。ベスト プラクティスとして、これらのツールやタスクはピーク時以外の時間帯または負荷の少ない時間帯に実行することをお勧めします。

詳細情報

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ページ ファイルのパフォーマンスを最適化する方法の詳細については、Microsoft サポート技術情報の文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379) を参照してください。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=72988) を参照してください。

  • ディスクのサイズの変更、待ち時間、および入出力速度の詳細については、Microsoft Exchange Team Blog の Web サイトにある以下のページを参照してください。

    • 「A few basic concepts in disk sizing」(http://go.microsoft.com/fwlink/?linkid=39538) (このサイトは英語の場合があります)

    • ディスク IO と計算に関する詳細な考慮事項についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=39539)

    • ディスク I/O 要件の計算方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=69747)


ページ ファイル使用量カウンタの値が 50% を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、Paging File パフォーマンス オブジェクトの % Usage カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル時間中に % Usage カウンタが 50% を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

ページ ファイル (Pagefile.sys) は、ハード ディスク上の隠しシステム ファイルであり、システムの RAM が不足したときに Windows が一時データを格納するために使用します。ページ ファイルは、ページング ファイルまたはスワップ ファイルとも呼ばれます。ディスクの処理にはメモリの処理よりも時間がかかるため、ページ ファイルの使用は全体のパフォーマンスに影響を及ぼします。また、ディスクとの間のページングが過大になると、最終的にディスクのボトルネックが発生し、パフォーマンスが低下します。この場合、実際に問題があるのはメモリであり、ディスクのボトルネックは兆候にすぎません。

実際の作業に必要な時間を基準にして、限られたメモリの管理にシステムが大幅な時間がかかるようになるまでは、メモリの競合は許容されます。平均応答時間に対するメモリの競合をグラフ化すると、競合がないポイントから応答時間が大幅に増大するポイントまで、滑らかな線が引かれます。これはスラッシング ポイントと呼びます。メモリの競合がこのポイントを超えて増大すると、応答時間が急に増大します。一時的なスラッシングが許容される環境もありますが、できる限り回避する必要があります。

このエラーは、ページ ファイルをホストしているディスクにパフォーマンスの問題があることを示します。この問題は、最終的にサーバー上のメモリの問題に関連する場合があります。

このエラーを解決するには、次の操作を行います。

  • 代わりのドライブ上に 2 次ページ ファイルを作成することを検討します。詳細については、Microsoft サポート技術情報の文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379) を参照してください。

  • ページ ファイルを専用のパーティションまたは高速なディスクに配置することを検討します。

  • 不要なソフトウェアを削除します。Exchange で利用可能なメモリ リソースを増やすため、監視機能や、重要でないサービスを実行するサードパーティ製のソフトウェア ツールを削除します。パフォーマンス スナップイン (http://go.microsoft.com/fwlink/?LinkId=56118) を使用すると、各アプリケーションによって使用されているメモリの量を知ることができます (このサイトは英語の場合があります)。

  • サーバーの保守作業は、ピーク時以外の時間帯に行います。Exchange Server データベース ユーティリティ (Eseutil.exe) などの保守ツール、またはメールボックスの管理などのタスクをピーク時に実行すると、Exchange で使用できるメモリが消費されます。ベスト プラクティスとして、これらのツールやタスクはピーク時以外の時間帯または負荷の少ない時間帯に実行することをお勧めします。

  • 問題が発生しているサーバーからユーザー メールボックスを別のサーバーに移動し、サーバーの負荷を低減することを検討します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • ページ ファイルのパフォーマンスを最適化する方法の詳細については、Microsoft サポート技術情報の文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379) を参照してください。

  • メモリのパフォーマンス向上の詳細については、「ユーザー メモリの強化」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=72988) を参照してください。

  • ディスクのサイズの変更、待ち時間、および入出力速度の詳細については、Microsoft Exchange Team Blog の Web サイトにある以下のページを参照してください。

    • ディスクのサイズ変更に関するいくつかの基本概念についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=39538)。

    • ディスク IO と計算に関する詳細な考慮事項についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=39539)。

    • ディスク I/O 要件の計算方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=69747)。


PageHeapFlags が設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、PageHeapFlags エントリの値を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MAD.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\INETINFO.EXE

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\EMSMTA.EXE

PageHeapFlags の値が存在し、0 または NULL 以外の値で構成されていることが検出されると、警告が表示されます。

PageHeapFlags オプションは、「GlobalFlag が設定されている」で説明されている GlobalFlag レジストリ値と組み合わせて使用されます。PageHeapFlags オプションを使用すると、標準のヒープ検証またはページ全体のヒープ検証を選択できます。標準のヒープ検証では、各ヒープ割り当ての末尾にフィル パターンを書き込み、割り当てが開放されるときにこのパターンを検証します。このオプションにより、各割り当ての末尾にアクセス不可能なページが配置されるため、プログラムが割り当てを超えたメモリにアクセスすると、そのプログラムは即座に停止します。ページ全体のヒープ検証は各割り当てに対してメモリのページ全体を使用するため、この検証を多く使用するとシステム メモリが不足する可能性があります。

この場合、Exchange Server アナライザは特に、次の各種 Exchange コンポーネントに対して PageHeapFlags 値が有効になっているかどうかを調べます。

  • STORE.EXE - インフォメーション ストア プロセス

  • MAD.EXE - システム アテンダント プロセス

  • INETINFO.EXE - IIS Admin および親プロセス

  • EMSMTA.EXE - メッセージ転送エージェント プロセス

Microsoft 製品サポート サービスの支援を受けて積極的に問題のデバッグやトレースに参加する場合を除き、常に PageHeapFlags の値を 0 に設定するか、完全に削除することをお勧めします。どちらの方法を使用しても結果は同じです。

PageHeapFlags レジストリ値は既定では存在しないため、STORE.EXE プロセス (またはその他のプロセス) のデバッグが必要な場合は、手動で追加する必要があります。それには、Windows Server 2003 CD-ROM の \Support フォルダにある Microsoft Windows Server™ 2003 サポート ツールに含まれている、Gflags ツールを使用します。あるいは、レジストリ エディタを使用して、値を手動で 0 に設定するか、または PageHeapFlags 値を完全に削除できます。この文書では、この両方の手順について説明します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

GFlags を使用してこのエラーを修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスに「GFlags」と入力して実行します。Global Flags ユーザー インターフェイスが表示されます。

  2. [Image File Name] ボックスに、「STORE.EXE」と入力します。

  3. [Image File Options] をクリックします。

  4. すべてのチェック ボックスをオフにし、[Apply] をクリックします。

  5. 上記の各 Exchange プロセスに対して、手順 2. ～ 4. を繰り返します。

  6. [OK] をクリックして GFlags ツールを終了し、影響のあるサービスを再開して、変更を有効にします。

  7. GFlags ツールを使用してこの値を消去する場合、PageHeapFlags の値は削除または変更されません。代わりに、GlobalFlag 値が 0 に設定され、この値が優先されることにより PageHeapFlags エントリで構成されている動作が無効になります。

レジストリ エディタを使用してこのエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\STORE.EXE

  3. PageHeapFlags という名前の値を削除します。

  4. 上記の各 Exchange プロセスに対して、手順 2. ～ 3. を繰り返します。

  5. レジストリ エディタを終了し、影響のあるサービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ページ プールがエラーのしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_PerfOS_Memory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、PoolNonpagedBytes キーの現在の値を判断します。Exchange Server アナライザが実行する操作は、基盤となるオペレーティング システム、Windows Boot.ini ファイル内の /3GB スイッチの有無、および検出されたこのキーの値に応じて異なります。

次に、特定の Exchange サーバーでこの値が範囲外であるかどうかを判断するため、Exchange Server アナライザによって使用される評価の表を示します。表の条件が満たされるとエラーが表示されます。

オペレーティング システム | Boot.ini の設定 | 現在の非ページ プールのサイズ
Windows 2000 Server または Advanced Server | /3GB | 110 MB 以上
Windows 2000 Server または Advanced Server | なし | 220 MB 以上
Windows Server™ 2003 | /3GB | 110 MB 以上
Windows Server 2003 | なし | 220 MB 以上

PoolNonpagedBytes キーの値は、カーネル メモリの非ページ プールのサイズ (バイト単位) です。非ページ プールは、ディスクに書き込むことはできなくても、割り当てられている間は物理メモリ内に保持する必要があるオブジェクトのための、物理的なシステム メモリの領域です。このキーの値は、最新の監視値です。正常な Exchange サーバーでは、この値は一定であるはずです。このカウンタの値が絶えず増加している場合、メモリー リークが発生している可能性があります。

上記の値を超えて非ページ プール メモリの制限値を増やす方法はないため、この状況はできるだけ早期に修正する必要があります。使用しているオペレーティング システムや、/3GB スイッチが指定されているかどうかにかかわらず、Windows オペレーティング システムがアクセスすることができる非ページ プール メモリには限りがあります。Windows は、カーネル メモリが不足すると、エラー メッセージを表示してクラッシュする可能性があります。カーネル メモリはシステムの正常な動作にとって必要であるため、カーネル メモリを注意して監視する必要があります。

Exchange サーバーの再起動後にこの状況が繰り返される場合、次の手順として、システムが正しくチューニングされるようにして、このシステム上に存在するすべてのソフトウェアとハードウェアが最新のものであるようにします。これには、以下のものの最新版をインストールする作業が含まれます。

  • Windows オペレーティング システムの Service Pack

  • Exchange Server の Service Pack

  • ハードウェアのファームウェアとドライバ

  • システム BIOS の更新

  • インストールして実行しているすべてのサード パーティ製アプリケーション用の更新

ソフトウェアとハードウェアの更新によってこの問題が解決されない場合、サード パーティ製ソフトウェアをすべて無効にし、Exchange Server コンピュータを再起動してカーネル メモリを監視します。

このエラーを修正するには

  1. 都合がつきしだい、Exchange Server コンピュータを再起動します。

  2. 上の一覧で使用中のシステムに当てはまるしきい値を超えていないことを確認するため、Memory オブジェクトの Pool Nonpaged Bytes パフォーマンス カウンタを監視します。

Exchange Server の正しいチューニングの詳細については、以下の Microsoft サポート技術情報の文書とトピックを参照してください。

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 文書番号 266096「1 GB 以上の RAM がある場合、/3GB スイッチが必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • 『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)

  • 「Troubleshooting Exchange 2000 Performance」(http://go.microsoft.com/fwlink/?LinkId=18177) (このサイトは英語の場合があります)

  • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)


ページ プールが警告しきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_PerfOS_Memory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、PoolPagedBytes キーの現在の値を判断します。Exchange Server アナライザによって行われる操作は、基になるオペレーティング システム、Windows の Boot.ini ファイル内に /3GB のスイッチが存在するかどうか、および検出されたこのキーの値によって決定されます。

次に、特定の Exchange サーバーでこの値が範囲外であるかどうかを判断するため、Exchange Server アナライザによって使用される評価の表を示します。表中の状態と一致する場合は、警告が表示されます。

オペレーティング システム | Boot.ini の設定 | 現在のページ プール
Windows 2000 Server または Advanced Server | /3GB | 180 MB 以上
Windows 2000 Server または Advanced Server | なし | 180 MB 以上
Windows Server™ 2003 | /3GB | 200 MB 以上
Windows Server 2003 | なし | 300 MB 以上

PoolPagedBytes キー値は、カーネル メモリのページ プールのサイズ (バイト単位) です。ページ プールは、使用されていないときはディスクに書き込めるオブジェクトが占める、システムの物理メモリの領域です。このキーのページ プール値は、最後に観察された値です。正常な Exchange サーバーでは、バックアップまたは復元を実行しない限り、使用するページ プール メモリが 180 MB を超えることはありません。

Windows 2000 Server および Windows 2000 Advanced Server では、ページ プール メモリの最大値は 470 MB です。/3GB スイッチが、Windows 2000 Advanced Server を実行しているコンピュータに追加されている場合、ページ プール メモリの最大値は 192 MB です。/3GB スイッチを指定せずに Windows Server 2003 を実行しているコンピュータの場合、ページ プール メモリの最大値は 491 MB です。/3GB スイッチを指定して Windows Server 2003 を実行しているコンピュータの場合、ページ プール メモリの最大値は 256 MB です。

ページ プール メモリの制限値を上記の値よりも大きくすることはできないため、この状態はできるだけ早く修正する必要があります。使用しているオペレーティング システムと /3GB スイッチの有無に関係なく、Windows からアクセスできるページ プール メモリはこれだけです。Windows のカーネル メモリがなくなると、エラー メッセージが表示され、クラッシュする場合があります。カーネル メモリは、システムが正しく動作するために不可欠です。そのため、カーメル メモリを注意深く監視する必要があります。

Exchange サーバーの再起動後、この状態が再発した場合は、次の手順として、システムが正しく調整されているかどうか、およびシステムのソフトウェアとハードウェアがすべて最新のものであるかどうかを確認します。これには、以下に示す最新版のインストールも伴います。

  • Windows オペレーティング システムの Service Pack

  • Exchange Server の Service Pack

  • ハードウェアのファームウェアおよびドライバ

  • システム BIOS の更新ファイル

  • インストールされ、実行されているサード パーティ製アプリケーションの更新プログラム

ソフトウェアおよびハードウェアを更新してもこの問題を解決できない場合は、サード パーティ製ソフトウェアをすべて無効にし、Exchange Server コンピュータを再起動して、カーネル メモリを監視する必要があります。

この警告を修正するには

  1. 早急に Exchange Server コンピュータを再起動します。

  2. [Memory] パフォーマンス オブジェクトの [Paged Pool Bytes] パフォーマンス カウンタを監視して、システムの上記のしきい値を超えていないことを確認します。

Exchange Server を適切に調整する方法の詳細については、以下の Microsoft サポート技術情報の文書と Exchange に関するトピックを参照してください。

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 266096「1 GB 以上の RAM がある場合、/3GB スイッチが必要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266096)

  • 『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)

  • 『Troubleshooting Exchange 2000 Performance』(http://go.microsoft.com/fwlink/?LinkId=18177) (このサイトは英語の場合があります)

  • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)

詳細については、以下の Exchange ブログの記事を参照してください。

  • Microsoft Windows カーネル メモリの管理および Microsoft Exchange Server についての情報 (http://go.microsoft.com/fwlink/?LinkId=63477) (このサイトは英語の場合があります)

  • Exchange 2003 におけるホット アド メモリおよび大容量メモリの構成についての情報 (http://go.microsoft.com/fwlink/?LinkId=63478) (このサイトは英語の場合があります)

  • 大きなセキュリティ トークンとカーネル メモリの消費についての情報 (http://go.microsoft.com/fwlink/?LinkId=63479) (このサイトは英語の場合があります)

    注 :
    これらのブログへのリンクは、情報の提供を目的として用意されています。内容は通知なしに変更される場合があります。


RPC プロキシ サーバー拡張のパスが正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベース内の次のプロパティを読み取り、その値が正しく構成されているかどうかを判断します。

LM/W3SVC/Filters/RpcProxy

このメタベース プロパティは、IIS の Web サービス拡張にあるリモート プロシージャ コール (RPC) プロキシ サーバー拡張プロパティです。このプロパティの正しい値は次のとおりです。

<Windows ディレクトリ>\system32\rpcproxy\rpcproxy.dll

Exchange Server アナライザによって、このプロパティに正しい値が設定されていないことが検出されると、警告メッセージが表示されます。

RPC プロキシ サーバー拡張プロパティは、ネットワーク サービス Microsoft Windows® コンポーネントの RPC over HTTP プロキシ サブコンポーネントをインストールしたときに設定されます。このプロパティが正しく設定されていない場合や、手動で値を変更している場合は、次の操作を行う必要があります。

  1. 正しくない RPC プロキシ サーバー拡張プロパティを削除します。

  2. RPC over HTTP プロキシ サブコンポーネントを削除します。

  3. RPC over HTTP プロキシ サブコンポーネントを再インストールします。

正しくない RPC プロキシ サーバー拡張プロパティを削除するには

  1. インターネット インフォメーション サービス (IIS) マネージャを起動します。

  2. [インターネット インフォメーション サービス (IIS) マネージャ] ウィンドウの左側のペインで、サーバー名を展開し、[Web サービス拡張] をクリックします。

  3. [インターネット インフォメーション サービス (IIS) マネージャ] ウィンドウの右側のペインで、[RPC プロキシ サーバー拡張] を右クリックし、[プロパティ] をクリックします。

  4. [必要なファイル] タブで、ファイル一覧内の正しくないファイルを選択し、[削除] をクリックします。次に、[OK] をクリックします。

    注 :
    完全なパスを表示するには、ファイル一覧の [ファイル名] 列の幅を調整します。
RPC over HTTP プロキシ サブコンポーネントを削除するには

  1. [スタート] ボタンをクリックし、[コントロール パネル] をポイントします。次に、[プログラムの追加と削除] をクリックします。

  2. 左側のペインで、[Windows コンポーネントの追加と削除] をクリックします。

  3. [ネットワーク サービス] を選択し、[詳細] をクリックします。

  4. [HTTP プロキシを経由した RPC] チェック ボックスをオフにし、[OK] をクリックします。次に、[次へ] をクリックします。

  5. Windows コンポーネント ウィザードが完了したら、[完了] をクリックしてウィザードを終了します。
RPC over HTTP プロキシ サブコンポーネントを再インストールするには

  1. [スタート] ボタンをクリックし、[コントロール パネル] をポイントします。次に、[プログラムの追加と削除] をクリックします。

  2. 左側のペインで、[Windows コンポーネントの追加と削除] をクリックします。

  3. [ネットワーク サービス] を選択し、[詳細] をクリックします。

  4. [HTTP プロキシを経由した RPC] チェック ボックスをオンにし、[OK] をクリックします。次に、[次へ] をクリックします。

  5. Windows コンポーネント ウィザードが完了したら、[完了] をクリックしてウィザードを終了します。

RPC プロキシ サーバー拡張が正しく読み込まれない問題の詳細については、Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=833401) の「トラブルシューティング」を参照してください。

Exchange Server 2003 に RPC over HTTP を展開する方法の詳細については、『Exchange Server 2003 RPC over HTTP Deployment Scenarios』(http://go.microsoft.com/fwlink/?LinkId=24823) を参照してください (このサイトは英語の場合があります)。


PDC エミュレータが DSAccess トポロジから除外されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、プライマリ ドメイン コントローラ (PDC) エミュレータとして動作している Active Directory® ドメイン コントローラが、Exchange Server で利用可能なドメイン コントローラの一覧から手動で除外されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\MinUserDC

PDC エミュレータとして動作しているドメイン コントローラが Exchange Server で利用可能なドメイン コントローラの一覧から手動で除外されていないことが検出されると、ベスト プラクティスのメッセージが表示されます。

PDC エミュレータは、Active Directory 操作のマスタの役割を担うコンピュータで、Microsoft Windows NT® Server 4.0 バックアップ ドメイン コントローラからのレプリケーション要求を処理し、Active Directory が有効なクライアント ソフトウェアを実行していないクライアントのすべてのパスワード更新を処理します。PDC エミュレータはドメイン コントローラでもあるため、Exchange Server などのアプリケーションで利用できます。

DSAccess (Directory Service Access) はExchange 2000 Server と Exchange Server 2003 の内部コンポーネントであり、すべての Exchange Server コンポーネントが Active Directory にどのようにアクセスするかを制御します。DSAccess の最も重要な機能は、ディレクトリに関連するさまざまなイベントや操作に関する情報を保持することです。たとえば、DSAccess は Active Directory トポロジを検索し、ドメイン コントローラとグローバル カタログ サーバーが利用可能な状態にあり、クエリに応答しているかどうかを確認します。

DSAccess の保持する利用可能なドメイン コントローラの一覧には、既定で PDC エミュレータ コンピュータが含まれています。Exchange Server 以外のプログラムが PDC エミュレータを頻繁に使用している場合、DSAccess で PDC エミュレータを使用すると、PDC エミュレータ コンピュータ、Exchange サーバー、および Exchange Sever 以外のプログラムを実行しているコンピュータでパフォーマンス上の問題が発生する可能性があります。

このようなパフォーマンスの問題を回避するため、Exchange サーバーで MinUserDC レジストリの値を追加します。これにより、DSAccess に対し、PDC エミュレータ操作のマスタの役割を保持しているドメイン コントローラに対してクエリを実行する前に、他のすべての利用可能なドメイン コントローラに対してクエリを実行することを強制できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
MinUserDC レジストリの値を確認し変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

  3. MinUserDC の値を見つけて、必要な変更を行います。この DWORD 値が存在しない場合は、手動で値を作成できます。

    注 :
    MinUserDC レジストリ エントリについて構成した値のデータは、PDC エミュレータと通信する前に通信するドメイン コントローラの最大数を表します。たとえば、MinUserDC を 4 に設定すると、DSAccess は、合計 4 つのドメイン コントローラが利用可能な場合に限り PDC エミュレータを除外するように構成されます。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MinUserDC レジストリ エントリの使用の詳細については、Microsoft サポート技術情報の文書番号 298879「[XADM] Exchange 2000 で、DSAccess に PDC エミュレータが使用されると、パフォーマンスの問題が発生する場合がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298879) を参照してください。


Available MBytes カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Memory パフォーマンス オブジェクトの Memory パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Available MBytes パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Available MBytes パフォーマンス カウンタは、プロセスへの割り当てやシステムで使用するためにすぐに利用可能な物理メモリの容量 (MB) を示します。利用可能なメモリの容量は、スタンバイ (キャッシュ)、空き、およびゼロページのリストに割り当てられているメモリの合計と等しくなります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


LogicalDisk パフォーマンス オブジェクトの Average Disk sec/Read カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、LogicalDisk パフォーマンス オブジェクトの Avg. Disk sec/Read パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Avg. Disk sec/Read パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Logical Disk パフォーマンス オブジェクトは、ハード ディスクの論理パーティションを監視する Avg. Disk sec/Read などのカウンタで構成されています。Avg. Disk sec/Read パフォーマンス カウンタは、ディスクからのデータ読み取りの平均時間 (秒) を示しています。Avg. Disk sec/Read パフォーマンス カウンタの平均値は 10 ミリ秒未満である必要があります。Avg. Disk sec/Read パフォーマンス カウンタの最大値は 50 ミリ秒以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

Exchange Server 2003 用にストレージ システムを最適化する方法の詳細については、『Optimizing Storage for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=49324) を参照してください (このサイトは英語の場合があります)。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


PhysicalDisk パフォーマンス オブジェクトの Average Disk sec/Read カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、PhysicalDisk パフォーマンス オブジェクトの Avg. Disk sec/Read パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Avg. Disk sec/Read パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Avg. Disk sec/Read パフォーマンス カウンタは、ディスクからのデータ読み取りの平均時間 (秒) を示しています。Avg. Disk sec/Read パフォーマンス カウンタの平均値は 10 ミリ秒未満である必要があります。Avg. Disk sec/Read パフォーマンス カウンタの最大値は 50 ミリ秒以下である必要があります。

Disk Reads/sec カウンタと Disk Writes/sec カウンタから結果を収集すると、Exchange Server により生成される I/O が時間と共に増加しているか、または減少しているかを判断することができます。Avg. Disk sec/Read カウンタと Avg. Disk sec/Write カウンタから結果を収集すると、ストレージの待ち時間が時間と共に変更したかどうかを判断できます。たとえば、次の手順を実行すると、ストレージのスループットがボトルネックとなっているか、またはその可能性があるかどうかを予測することができます。

  1. 毎月測定を行います。できれば、毎月同じ日の同じ時間帯に測定を行います。

  2. 収集したデータを分析します。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


LogicalDisk オブジェクトの Average Disk sec/Write カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、LogicalDisk パフォーマンス オブジェクトの Avg. Disk sec/Write パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Avg. Disk sec/Write パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Logical Disk パフォーマンス オブジェクトは、ハード ディスクの論理パーティションを監視する Avg. Disk sec/Write などのカウンタで構成されています。Avg. Disk sec/Write パフォーマンス カウンタは、ディスクへのデータの書き込みにかかる平均時間 (秒) を示しています。Avg. Disk sec/Write パフォーマンス カウンタの平均値は 10 ミリ秒未満である必要があります。Avg. Disk sec/Write パフォーマンス カウンタの最大値は 50 ミリ秒以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

Exchange Server 2003 のストレージ システムを最適化する方法の詳細については、Microsoft TechNet Web サイトの『Optimizing Storage for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=34649) を参照してください (このサイトは英語の場合があります)。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Average Disk sec/Write カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Physical Disk パフォーマンス オブジェクトの Avg. Disk sec/Write パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Avg. Disk sec/Write パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Avg. Disk sec/Write パフォーマンス カウンタは、ディスクへのデータ書き込みの平均時間 (秒) を示しています。Avg. Disk sec/Write パフォーマンス カウンタの平均値は 10 ミリ秒未満である必要があります。Avg. Disk sec/Write パフォーマンス カウンタの最大値は 50 ミリ秒以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Client Out Queue Length (DSAccess) カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Client Out Queue Length (DSAccess) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Client Out Queue Length (DSAccess) パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Client Out Queue Length (DSAccess) パフォーマンス カウンタは、キューにあるメッセージのうち、Inetinfo.exe プロセスによって送信された DSAccess (Directory Service Access) メッセージを含むメッセージの数を示しています。キューの数は常に 10 未満である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Client Out Queue Length (SMTP) カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Client Out Queue Length (SMTP) パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Client Out Queue Length (SMTP) パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Client Out Queue Length (SMTP) パフォーマンス カウンタは、Inetinfo.exe プロセスによって送信された SMTP (Simple Mail Transfer Protocol) メッセージを含むキュー内のメッセージの数を示します。メール キューがある場合を除き、これらのキューは常に 50 未満になっている必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタの推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Store Out Queue Length (DSAccess) カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Store Out Queue Length (DSAccess) パフォーマンス カウンタからデータを収集して、そのパフォーマンス データを分析します。Exchange Server アナライザによって Store Out Queue Length (DSAccess) パフォーマンス カウンタから何らかのデータが収集されると、収集されたデータに関する情報がベースライン情報として表示されます。

Store Out Queue Length (DSAccess) パフォーマンス カウンタは、Store.exe プロセスによって送信された DSAccess (Directory Service Access) メッセージが含まれているキュー内のメッセージの数を示します。このキューは、常に 10 未満になっている必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタの推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Epoxy Store Out Queue Length (SMTP) カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、Epoxy パフォーマンス オブジェクトの Store Out Queue Length (SMTP) パフォーマンス カウンタからデータを収集して、そのパフォーマンス データを分析します。Exchange Server アナライザによって Store Out Queue Length (SMTP) パフォーマンス カウンタから何らかのデータが収集されると、収集されたデータに関する情報がベースライン情報として表示されます。

Store Out Queue Length (SMTP) パフォーマンス カウンタは、Store.exe プロセスによって送信された SMTP (Simple Mail Transfer Protocol) メッセージを含むキュー内のメッセージの数を示します。メール キューがある場合を除き、これらのキューは常に 50 未満になっている必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタの推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


RPC Averaged Latency カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの RPC Averaged Latency パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが RPC Averaged Latency パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

RPC Averaged Latency パフォーマンス カウンタは、過去 1,024 パケットでの、リモート プロシージャ コール (RPC) の平均待ち時間 (ミリ秒単位) を示します。RPC Averaged Latency パフォーマンス カウンタの最大値を、常に 50 ミリ秒未満にする必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


RPC Operations/sec カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの RPC Operations/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが RPC Operations/sec パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

RPC Operations/sec パフォーマンス カウンタは、リモート プロシージャ コール (RPC) 操作の発生頻度を示します。MAPI ベースの操作はすべて RPC プロトコルを使用するため、RPC Operations/sec パフォーマンス カウンタは Exchange Server の負荷を計測するための優れた頻度カウンタになります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


RPC Requests カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの RPC Requests パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが RPC Requests パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

RPC Requests パフォーマンス カウンタは、Microsoft Exchange Information Store サービスによって現在処理されている要求である、MAPI リモート プロシージャ コール (RPC) またはクライアントの数を示します。RPC Requests パフォーマンス カウンタの平均値は、常に 30 未満にする必要があります。既定では、RPC 要求の最大値は 100 です。このため、他の方法で構成されていない限り、Microsoft Exchange Information Store サービスは同時に 100 の RPC 要求しか処理できず、それを超えるとクライアント要求を拒否します。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


SMTP Categorizer Queue Length カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Categorizer Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザは、カテゴライザ キューで見つかったメッセージの総数を報告します。

SMTP Server\Categorizer Queue Length カウンタは、SMTP (Simple Mail Transfer Protocol) カテゴライザ キューで、グローバル カタログ サーバーを使用するディレクトリ サービスの属性検索のために待機しているメッセージ数を示します。一般的なガイドラインとして、最大値を 10 未満にする必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

Categorizer Queue Length カウンタは、メッセージのカテゴライザ キューにあるメッセージ数を示します。カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認します。

  • すべての受信者に対する制限を決定します。

  • 必要に応じて配布リストを拡張します。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断します。

Categorizer Queue Length カウンタの増加は、サーバーのパフォーマンス問題、DSAccess (Directory Service Access)、Active Directory® ディレクトリ サービス、または Exchange Server 組織内の重要なサーバーの停止による潜在的な問題が存在する可能性があることを示します。Categorizer Queue Length カウンタの増加は、Active Directory への問い合わせ、またはローカル配信または SMTP へのメッセージの引渡しに時間がかかったり、応答がないことを示します。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


SMTP Local Queue Length カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Local Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザは、SMTP (Simple Mail Transfer Protocol) ローカル キューに見つかったメッセージの合計数を報告します。

SMTP Server\Local Queue Length カウンタは、ローカル配信のために SMTP キューに置かれているメッセージの数を示します。一般的なガイドラインとして、最大値は 1,000 未満である必要があります。キューは、平均値の近くで安定を保ち、差異は少しである必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

サーバーが受信メールを適切な時間内に配信できなくなっているため、ローカル配信キューでのメッセージの蓄積はパフォーマンスの問題やサーバー上での停止を示しています。以下の状況によってこの遅延が発生する可能性があります。

  • Active Directory® ディレクトリ サービスが直ちに参照されていない。

  • メッセージがローカル配信または SMTP に直ちに渡されていない。

  • データベースのマウントが解除されている。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


SMTP Remote Queue Length カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Remote Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザによって、SMTP (Simple Mail Transfer Protocol) リモート キュー内に見つかったメッセージの総数が報告されます。

SMTP Server\Remote Queue Length カウンタは、リモート配信用の SMTP キュー内のメッセージの総数を示します。一般的なガイドラインとして、最大値は 1,000 未満である必要があります。このキューは、ほぼ平均値に安定して保たれ、変動も少なくなるようにする必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

リモート キューの長さの増加は、メールが他のサーバーに送信されていないことを示しています。このメール送信エラーは、ネットワーク サーバーやリモート サーバーの停止またはパフォーマンスの問題によって説明することができます。こうした停止またはパフォーマンスの問題によって、ネットワーク サーバーやリモート サーバーはメールを効率的に受信できなくなります。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Virus Scan Queue Length カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの Virus Scan Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Virus Scan Queue Length パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Virus Scan Queue Length パフォーマンス カウンタは、ウイルス スキャン用のキューに入れられている、現在未解決の要求の数を示します。このカウンタの推奨値は、組織ごとに異なります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタの推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Log Record Stalls/sec カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Database パフォーマンス オブジェクトの Log Record Stalls/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Log Record Stalls/sec パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Log Record Stalls/sec パフォーマンス カウンタは、ログ バッファがいっぱいになっているためにこのバッファに追加できないログ レコードの 1 秒あたりの数を示しています。Log Record Stalls/sec パフォーマンス カウンタの平均値は 1 秒あたり 10 未満である必要があります。最大値は 1 秒あたり 100 以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Log Threads Waiting カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Database パフォーマンス オブジェクトの Log Threads Waiting パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Log Threads Waiting パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Log Threads Waiting パフォーマンス カウンタは、データをログに書き込むことによりデータベースの更新を完了させるのを待機しているスレッドの数を示します。Log Threads Waiting パフォーマンス カウンタの値が大きすぎると、ログが他のトランザクションのボトルネックになる可能性があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク ポイントの値になることがあります。したがって、最大値は期間全体を表すものではありません。また、中間値には収集期間中のアイドル時間が含まれるため、中間値も負荷を常に正確に示すとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタの推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Pages/sec カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Memory パフォーマンス オブジェクトの Pages/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが LDAP Search Time パフォーマンス カウンタのデータを収集している場合、収集されたデータに関する情報がベースライン情報として表示されます。

Pages/sec パフォーマンス カウンタは、ハードウェアによるページ フォールトを解決するため、ディスクから読み取られる、またはディスクに書き込まれるページの速度を示します。このカウンタは、システム規模の遅延の原因となるエラーの種類に関する主要なインジケータです。カウンタには、ファイル システム キャッシュでページ フォールトと見なされるために取得されたページも含まれます。通常、これらのページはアプリケーションによって要求されます。このカウンタは、常に 1,000 以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


% Processor Time カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの % Processor Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが % Processor Time パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

% Processor Time パフォーマンス カウンタは、プロセッサがアイドルではないスレッドを実行している時間の割合を示します。このカウンタを使用して、プロセッサの全体的な使用率またはプロセッサごとの使用率を監視できます。平均 CPU 使用率は、常に 90% 未満にする必要があります。

注 :
Exchange Server アナライザによって表示される % Processor Time は、検出された CPU (論理プロセッサおよび物理プロセッサの両方) の合計数に基づく集計値であり、これを CPU 数の合計で割ります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


Bytes Total/sec カウンタのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Network Interface パフォーマンス オブジェクトの Bytes Total/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが Bytes Total/sec パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

Bytes Total/sec パフォーマンス カウンタは、ネットワーク アダプタが 1 秒あたりに処理するデータ バイトの数を示しています。このカウンタには、パケット ヘッダーなどのプロトコル情報に加えて、すべてのアプリケーションとファイルのデータが含まれています。100 Mbps (メガビット/秒) のネットワーク アダプタの場合、Bytes Total/sec パフォーマンス カウンタの値は 7 MB/秒以下である必要があります。1000 Mbps のネットワーク アダプタの場合、Bytes Total/sec パフォーマンス カウンタの値は 70 MB/秒 以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


LDAP Read Time カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Process パフォーマンス オブジェクトの LDAP Read Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが LDAP Read Time パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

LDAP Read Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 読み取り要求の実行にかかった時間をミリ秒単位で示します。平均値は 50 ミリ秒未満である必要があります。最大値は 100 ミリ秒以下である必要があります。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

場合によっては、最大値が期間内のピーク点の値であることがあります。したがって、最大値は期間全体を表してはいません。中間値は、収集期間中のアイドル時間を含むため、負荷を正確に示しているとは限りません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージの情報は、情報の提供のみを目的として表示されます。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


LDAP Search Time カウンタからのパフォーマンス データ
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeDSAccess Processes パフォーマンス オブジェクトの LDAP Search Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。Exchange Server アナライザが LDAP Search Time パフォーマンス カウンタからデータを収集した場合、収集されたデータに関する情報はベースライン情報として表示されます。

LDAP Search Time パフォーマンス カウンタは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 検索要求が実行されるのにかかる時間 (ミリ秒) を示します。平均値は 50 ミリ秒以下です。最大値は 100 ミリ秒を超えないようにします。

既定では、Exchange Server アナライザは 2 時間の間に 30 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。また、収集されたすべての値のうちの 90 パーセンタイルに当たる値も報告されます。

注 :
Exchange Server アナライザが収集したすべての値を昇順に一覧表示すると、90 パーセンタイルはその一覧の 90% にある値です。90 パーセンタイル値は、収集期間中のこのカウンタの高い値を示しています。

状況によっては、最大値は期間中のピーク時の値になります。このため、最大値は期間全体を表わしていません。中間値には収集期間中のアイドル時間が含まれるため、必ずしも正確な負荷を示しません。そのため、Exchange Server アナライザ ツールでは、最大値と 90 パーセンタイル値が報告されます。

このベースライン メッセージは、情報の提供のみを目的としています。操作は必要ありません。

パフォーマンス カウンタに推奨されるしきい値の詳細については、「Troubleshooting Microsoft Exchange Server Performance」(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


PhysicalDisk パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、PhysicalDisk パフォーマンス オブジェクトの Avg. Disk sec/Read パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合は、以下の状況のいずれかまたは複数が発生しています。

  • PhysicalDisk パフォーマンス オブジェクトが無効になっている。

  • PhysicalDisk パフォーマンス モニタ オブジェクトが存在しないか、破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張可能なカウンタによりレジストリが破壊されている場合、または Microsoft WMI (Windows® Management Instrumentation) ベースのプログラムによりレジストリが変更されている場合に発生する可能性があります。以下の手順は、最初の 2 つの状況を修正する方法を示しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. PhysicalDisk パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List tool (Exctrlst.exe) をダウンロードしてインストールします。Exctrlst.exe は、Microsoft の Web サイト「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) でダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) に記載されている手順に従って、存在しないまたは破損しているパフォーマンス カウンタを再構築します。

  3. Microsoft サポート技術情報のこの文書の手順に従っても問題が解決しない場合は、Windows オペレーティング システムを [修復] モードでインストールしてから、最新の Windows Service Pack を適用する必要があります。


ポートの競合 :サイト レプリケーション サービス
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP と競合しているポートについてもエラーが表示されます。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP レジストリ パラメータを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. TCP/IP キーをダブルクリックし、[値のデータ] ボックスの値を 5,000 (10 進数) より大きい一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、この設定を有効にします。

RPC over HTTP を展開するには

  1. 「Introduction to Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  3. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  4. Microsoft サポート技術情報の文書番号 829134「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange によって使用されるポートの静的割り当ての詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 194952「[XADM] Exchange Server の静的に割り当てられるポートの制限」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952)

  • 文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836)


ポートの競合 : ストア HTTP
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

レジストリの Rpc/HTTP Port キーは、Exchange が Microsoft Office Outlook® 2003 の RPC/HTTP 機能および Exchange Server 2007 の Outlook Anywhere 機能をサポートするために使用されます。Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\Rpc/HTTP Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters\Rpc/HTTP Port と競合しているポートについてもエラーが表示されます。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

RPC/HTTP Outlook 2003 または Outlook 2007 クライアントをサポートする場合、Rpc/HTTP Port キーを 10 進数の 6001 に設定する必要があります。さらに、使用している環境での RPC/HTTP 構成を確認する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP Port レジストリ値を設定するには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters

  3. Rpc/HTTP Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP 構成を確認するには、次のドキュメントを参照してください。

  1. Exchange Server 2003 における RPC over HTTP の展開シナリオについてのページ (http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=80831) を参照してください (このサイトは英語の場合があります)。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft Support WebCast「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ポートの競合 :Store TCP
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port と競合しているポートについてもエラーが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook 2003® または Outlook 2007 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、Exchange Server 2007、Outlook 2007、および Microsoft Windows® XP Professional にある RPC over HTTP 機能を使用することをお勧めします。MAPI モードは、以前は "企業" または "ワークグループ" モードと呼ばれていました。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP Port レジストリ値を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. TCP/IP Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP を展開するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=80831) を参照してください (このサイトは英語の場合があります)。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft サポート技術情報の文書番号 829134「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange によって使用される静的に割り当てられるポートの詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange Server の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。


ポートの競合 : システム アテンダント HTTP
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

HTTP Port キーは、Exchange が Microsoft Office Outlook® 2003 の RPC/HTTP 機能および Exchange Server 2007 の Outlook Anywhere 機能をサポートするために使用されます。Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port と競合しているポートについてもエラーが表示されます。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

RPC/HTTP Outlook 2003 または Outlook 2007 クライアントをサポートする場合、HTTP Port キーを 10 進数の 6002 に設定する必要があります。さらに、使用している環境での RPC/HTTP 構成を確認する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

HTTP Port レジストリ値を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. HTTP Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP 構成を確認するには、次のドキュメントを参照してください。

  1. Exchange Server 2003 における RPC over HTTP の展開シナリオについてのページ (http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/7b2d1ce2-b6df-4604-80fd-2f6cafc47e82.mspx) (このサイトは英語の場合があります) を参照してください。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft Support WebCast「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ポートの競合 : システム アテンダント HTTP NSPI
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

レジストリの Rpc/HTTP NSPI Port キーは、Exchange が Microsoft Office Outlook® 2003 の RPC/HTTP 機能および Exchange Server 2007 の Outlook Anywhere 機能をサポートするために使用されます。Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\ Rpc/HTTP NSPI Port と競合しているポートについてもエラーが表示されます。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

RPC/HTTP Outlook 2003 クライアントまたは Outlook 2007 をサポートする場合、Rpc/HTTP NSPI Port キーを 10 進数の 6004 に設定する必要があります。さらに、使用している環境での RPC/HTTP 構成を確認する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP NSPI Port レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Rpc/HTTP NSPI Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP 構成を確認するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=80831) を参照してください (このサイトは英語の場合があります)。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft Support Web Cast「[OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ポートの競合 : システム アテンダント NSPI
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port と競合しているポートについてもエラーが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook 2003® および Outlook 2007 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、Exchange Server 2007、Outlook 2007、および Microsoft Windows® XP Professional にある RPC over HTTP 機能を使用することをお勧めします。MAPI モードは、以前は "企業" または "ワークグループ" モードと呼ばれていました。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP NSPI Port レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP NSPI Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP を展開するには

  1. Exchange Server 2003 における RPC over HTTP の展開シナリオについてのページ (http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=80831) を参照してください (このサイトは英語の場合があります)。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft Support WebCast「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange によって使用されるポートの静的割り当ての詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836)


ポートの競合 :システム アテンダント RFR
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ポートの競合が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port

HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

Exchange Server アナライザによって HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port の値が、この文書に記載されている他の 6 つのポートのレジストリ値のいずれかと一致していることが検出されると、エラーが表示されます。また、HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP Port と競合しているポートについてもエラーが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook 2003® または Outlook 2007 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、Exchange Server 2007、Outlook 2007、および Microsoft Windows® XP Professional にある RPC over HTTP 機能を使用することをお勧めします。MAPI モードは、以前は "企業" または "ワークグループ" モードと呼ばれていました。

このエラーを修正するには、このキーまたは Exchange Server アナライザの出力に記載されている競合しているキーを一意の値に変更する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP Port レジストリ値を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP Port キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える一意の値に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

RPC over HTTP を展開するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Outlook Anywhere の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=80831) を参照してください (このサイトは英語の場合があります)。

  3. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  4. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  5. Microsoft Support Web Cast「[OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange によって使用される静的に割り当てられるポートの詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange Server の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。


プレリリース版 Service Pack の更新プログラムのロールアップが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータで実行されている Exchange Server のバージョンを表します。

また、Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、ExCDO (Exchange Collaboration Data Object) ライブラリ ファイルである ExCDO.dll の Version キーの値を判断します。ExCDO.dll の Version キーが 6603.0 に等しいことが検出されると、警告が表示されます。

バージョンが 6603.0 の ExCDO.dll を実行している Exchange 2000 Server コンピュータは、2004 年 8 月公開の Exchange 2000 Server Service Pack 3 (SP3) 以降の更新プログラム ロールアップ (Version 1) を実行しています。この更新プログラムのロールアップは、現在は Version 2 が提供されています。2004 年 8 月公開の更新プログラムのロールアップをインストールすることをお勧めします。

この警告を修正するには

  1. 最新の更新プログラムの詳細については、Microsoft サポート技術情報の文書番号 870540「2004 年 8 月公開の Exchange 2000 Server Service Pack 3 以降の更新プログラムのロールアップ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=870540) を参照してください。

  2. 最新の更新 (2004 年 8 月) を、Exchange 2000 Server のダウンロードページ (http://go.microsoft.com/fwlink/?LinkId=33457) からダウンロードします (このサイトは英語の場合があります)。

  3. Exchange Server コンピュータをバックアップします

  4. 2004 年 7 月の更新プログラムのロールアップを適用します。

Exchange 2000 Server の最新 Service Pack の入手方法の詳細については、Microsoft サポート技術情報の文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378) を参照してください。

この更新プログラムやその他の Exchange Server 更新プログラムのインストールの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


ページ ファイルの場所に関する問題
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ページ ファイルがサーバーのパフォーマンスに悪影響を及ぼす場所に配置されていると判断しました。ページ ファイルは、Exchange データベース ファイルまたは Exchange ログ ファイルと同じディスクに配置しないでください。また、ページ ファイルとシステム ファイルを分離することもお勧めします。

ページ ファイルは、専用のパーティションまたは高速なディスクに配置することをお勧めします。

この警告を修正するには

  • ページ ファイルを、Exchange データベース ファイルまたはログ ファイルが格納されていない場所に移動します。可能であれば、システム パーティションを含んでいない場所にしてください。

詳細情報

  • ページ ファイルの構成方法の詳細については、Microsoft サポート技術情報の文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=197379) を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


プロセッサのボトルネック
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-24

Microsoft® Exchange Server アナライザ ツールによって、サーバーで CPU のボトルネックが発生していることが検出されました。サーバーの CPU 使用率が推奨しきい値を超えています。プロセッサのボトルネックまたはプロセッサ使用率の問題を識別するために使用されるカウンタには、次のものが含まれます。

  • System パフォーマンス オブジェクトの下にある Context Switches/sec パフォーマンス カウンタ。

  • Processor パフォーマンス オブジェクトの下にある % Processor Time (_Total) パフォーマンス カウンタ。

  • System パフォーマンス オブジェクトの下にある Processor Queue Length パフォーマンス カウンタ。

プロセッサのボトルネックの検出

次の条件のいずれかに当てはまると、Exchange Server アナライザによってボトルネックが検出されます。

  • Process パフォーマンス オブジェクトの下にある % Processor Time (_Total) パフォーマンス カウンタの平均が 70% より大きい。

  • Process パフォーマンス オブジェクトの下にある % Processor Time (_Total) パフォーマンス カウンタの最大が 90% より大きい。

  • System パフォーマンス オブジェクトの下にある Context Switches/second パフォーマンス カウンタの平均が 20,000 より大きい。

  • System パフォーマンス オブジェクトの下にある Processor Queue Length パフォーマンス カウンタが 2 より大きい。

  • Process パフォーマンス オブジェクトの下にあるこの % Processor Time (_Total) パフォーマンス カウンタは、プロセッサの全体的な使用率を示します。平均 CPU 使用率は、常に 80% 未満にする必要があります。これより高い平均はプロセッサのボトルネックを示します。平均プロセッサ使用率が 70% を超えている場合は、警告が表示されます。90% を超えるプロセッサ時間の頻繁な急上昇もプロセッサのボトルネックを示しています。

  • System パフォーマンス オブジェクトの下にある Processor Queue Length パフォーマンス カウンタは、プロセッサ キュー内のスレッドの数を示します。複数のプロセッサが搭載されたコンピュータであっても、プロセッサ時間用のキューは 1 つです。2 よりも大きい数値は、スレッドがプロセッサ時間を待機していて、プロセッサのボトルネックが発生していることを示しています。

プロセッサ負荷のソースの判断

プロセッサのボトルネックが見つかった場合は、CPU 使用率の大半がどこで発生しているかを判断する必要があります。Exchange バックエンド サーバーでは、CPU 使用率の大半は Store.exe プロセスで発生しています。20% を超える CPU 使用率が Store.exe 以外のプロセスで発生している場合は、CPU 使用率を消費している他のプロセスを見つけることが重要です。

次の表に示されているプロセスの CPU 使用率がしきい値を超えている場合は、Exchange Server アナライザによってエラーが表示されます。

プロセス | Process パフォーマンス オブジェクトの下にある %Processor Time パフォーマンス カウンタのしきい値
Store | 90%
Inetinfo | 20%
Emsmts | 40%
Lsass | 40%
System | 40%
Mad | 40%
ExMGMT | 20%
W3WP | 40%

また、Exchange Server アナライザは、Process パフォーマンス オブジェクトの下にある %Processor Time パフォーマンス カウンタ (Idle インスタンス) および %Processor Time パフォーマンス カウンタ (_Total インスタンス) によって測定されるアイドル プロセッサ時間の差異を測定します。正常な Exchange バックエンド サーバーでは、使用中のプロセッサ時間の少なくとも 70% は Store.exe プロセスが使用している必要があります。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Exchange サーバーに関連するプロセス (Store.exe、inetinfo.exe、emsmta.exe、lsass.exe、w3wp.exe、exmgmt.exe、または mad.exe のプロセス) に費やされないプロセッサ時間が 35% を超える場合。

  • Exchange に関連しないプロセッサ時間が 20% を超える場合。

  • プロセッサのボトルネックが発生していて、Store.exe プロセスが使用するプロセッサ時間が 70% 未満の場合。

これらすべての場合は、サーバーの CPU 時間を消費している他のプロセスを見つけ出すことをお勧めします。

バックエンド サーバーでのプロセッサのボトルネックの一般的な原因

パフォーマンスのボトルネックには、次のように多くの原因が考えられます。

  • CPU 使用率を消費している、サーバー上のその他のアプリケーション

  • 高い RPC の比率

  • 配布リストの展開

  • 運用時間のピーク時に実行されるバックアップおよび保守

  • 以下が原因になるメッセージ内のメッセージ コンテンツの変換 :

    • 実行している複数のプロトコル (HTTP、POP3、IMAP4、Microsoft Office Outlook® など)

    • オフライン フォルダ (.ost ファイル) を使用する Outlook 2000 またはそれ以前のバージョン

プロセッサのボトルネックの解消

Exchange サーバーのプロセッサのボトルネックを解消する多くの方法があります。

プロセッサのボトルネックを解消するには

  • 可能な場合は、サーバーにより多くの、またはより速いプロセッサを追加します。また、プロセッサによってサポートされている場合は、ハイパー スレッディングを有効にします。ハイパー スレッディングはシステム BIOS を構成して有効にすることができます。詳細については、コンピュータの製造元のヘルプ ドキュメントを参照してください。

  • プロセッサの処理能力を高めることができない場合は、プロセッサの負荷を減らす必要があります。サーバーに対する全体的な影響を減らすには、I/O を集中的に使用すること、CPU を集中的に使用すること、またはメモリを消費するタスクを通常の運用時間外に実行することを確実に行うことが重要です。

    最初に、サーバーで負荷を引き起こしているアプリケーションまたはタスクを識別します。Exchange 以外のアプリケーションがそのサーバーに対して重要でない場合は、そのアプリケーションを別のサーバーで実行します。可能な場合は、サーバーの役割も他のコンピュータへ移動します。たとえば、Inetinfo プロセスが大量の CPU 使用率を消費している場合は、Inetinfo が実行するプロトコル作業をフロントエンド サーバーに追加することを検討します。パブリック フォルダ アクセスを専用のパブリック フォルダ サーバーに移動することもできます。最後に、サーバーが多くの配布リストの展開を実行する場合は、配布リストの展開を専用の配布リスト展開サーバーに移動して、CPU の使用率を減らすことができます。

  • バックアップ タスク、保守タスクなどの CPU を集中的に使用するタスクがピーク以外の時間帯に実行されるようにします。また、これらのタスクが段階的に実行されるようにします。段階的なタスクの実行とは、各タスクに対して、異なる開始時刻、さらに可能であれば異なる終了時刻を設定することを意味します。また、データベースまたはストレージ グループの保守およびバックアップを段階的に実行すると、これらのリソースを集中的に使用するタスクの影響が少なくなります。

  • オプションの負荷ソースをすべて取り除いても、CPU 使用率が高いままの場合は、ユーザーを別のサーバーへ移動して負荷を減らす必要があります。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ユーザーのメールボックスを移動してサーバーの負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


Processor パフォーマンス モニタ オブジェクトが使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの % Processor Time パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合、次の状況のいくつかが当てはまります。

  • Processor パフォーマンス オブジェクトが無効になっている。

  • Processor パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張カウンタによってレジストリが壊れた場合、または Microsoft WMI (Windows® Management Instrumentation) に基づくプログラムによってレジストリが変更された場合に発生する可能性があります。以下の手順は、最初の 2 つの状況を修復する方法について説明しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. Processor パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードし、インストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?LinkId=34436) でダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. 足りないパフォーマンス カウンタまたは壊れたパフォーマンス カウンタを再構築します。パフォーマンス カウンタを再構築する方法については、Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) を参照してください。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Windows オペレーティング システムを修復モードで再インストールしてから、最新の Windows Service Pack を適用する必要があります。


パブリック フォルダのコンテンツのレプリケーションが一時停止されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server 組織に heuristics 属性が設定されているかどうかを判断します。heuristics のビット 1024 がセットされていることが検出されると、警告が表示されます。

Exchange Server 2003 SP2 では、管理者が組織内のすべてのパブリック フォルダ コンテンツのレプリケーションを停止できる機能が導入されました。Exchange システム管理ツールで組織名を右クリックし、[パブリック フォルダのコンテンツのレプリケーションを停止する] をクリックすることにより、すべてのパブリック フォルダのレプリケーションを停止できます。[パブリック フォルダのコンテンツのレプリケーションを停止する] をクリックすると、heuristics 属性のビット 1024 がセットされます。すべてのパブリック フォルダのレプリケーションを停止するのは、組織全体にわたるパブリック フォルダやメール フローに関する問題のトラブルシューティングなど、極端な場合だけにしてください。

次の条件に当てはまる場合は、パブリック フォルダ コンテンツのレプリケーションを再開する必要があります。

  • トラブルシューティングを行っていない。

  • 特に、すべてのパブリック フォルダ コンテンツのレプリケーションを停止する必要はない。

組織レベルでパブリック フォルダ コンテンツのレプリケーションを再開するには

  1. Exchange システム マネージャを起動します。

  2. [<組織名>] を右クリックし、[パブリック フォルダのコンテンツのレプリケーションを再開する] をクリックします。

パブリック フォルダのレプリケーションの詳細については、「Best Practices for Exchange Server Public Folders」(http://go.microsoft.com/fwlink/?LinkId=46437) を参照してください (このサイトは英語の場合があります)。


フロントエンド サーバーにパブリック フォルダ ストアが存在している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-07

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange サーバーにパブリック フォルダ ストアが存在しているかどうかを判断します。InformationStore オブジェクトがオブジェクト クラス msExchPublicMDB であることが検出された場合、サーバーはパブリック フォルダ ストアをホストしています。

また、Exchange Server アナライザは MicrosoftExchangeV2 Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、IsFrontEndServer キーに値が設定されているかどうかを判断します。値が True の場合は Exchange サーバーはフロントエンド サーバーとして構成されており、値が False の場合は Exchange サーバーはフロントエンド サーバーとして構成されていません。フロントエンド サーバーとして構成されている Exchange サーバーがパブリック インフォメーション ストアをホストしていることが検出されると、警告が表示されます。

フロントエンド サーバーではパブリック フォルダ ストアを実行しないことをお勧めします。フロントエンド サーバーはメールボックスをホストしないため、パブリック フォルダ ストアは必要ありません。さらに、パブリック フォルダのレプリケーション、パブリック フォルダの参照、およびパブリック フォルダ ストアが Exchange 2000 Server を実行するフロントエンド サーバーに配置されている場合のメモリ リークに関して、既知の問題点があります。したがって、すべてのフロントエンド サーバーでパブリック フォルダ ストアをすべてマウント解除します。

Microsoft Exchange Information Store サービスは、パブリック フォルダ ストアをマウント解除した後はフロントエンド サーバーで何の機能も実行しないため、無効にすることができます。不必要なサービスを削除すると、読み込みを削減し、セキュリティとパフォーマンスを強化することができます。

注 :
フロントエンド サーバーがインターネットからの SMTP (Simple Mail Transfer Protocol) メッセージも受信している場合は、Microsoft Exchange Information Store サービスを実行したままにし、メールボックス ストアをマウント状態にしておく必要があります。ただし、フロントエンド サーバーには一切パブリック フォルダ ストアを置かないでください。

メールボックスとパブリック フォルダ データベースを停止し無効にするには

  1. Exchange システム マネージャで [サーバー] を展開し、使用しているサーバーを展開します。次に[最初のストレージ グループ] を展開します。

    [メールボックス ストア (サーバー名)] を右クリックし、[ストアのマウントを解除] をクリックします。次に、[はい] をクリックしてストアのマウントを解除します。

    重要 :
    フロントエンド サーバーを SMTP ブリッジヘッド サーバーとして使用する場合、サーバーにメールボックス ストアをマウントする必要があります。この場合、ストアのマウント解除や削除は行いませんが、サーバーにメールボックスが格納されていないことを確認します。

  2. [メールボックス ストア (サーバー名)] を右クリックし、[プロパティ] をクリックします。

  3. [データベース] タブをクリックし、[起動時にこのストアをマウントしない] チェック ボックスをオンにします。次に、[OK] をクリックします。

    [パブリック フォルダ ストア (サーバー名)] を右クリックし、[ストアのマウントを解除] をクリックします。

    注意 :
    パブリック フォルダ ストアのマウントを解除する前に、そのパブリック フォルダのレプリカが別のパブリック フォルダ ストアに存在することを確認してください。この操作を行わないと、情報が失われるおそれがあります。

  4. [はい] をクリックして、パブリック フォルダ ストアのマウントを解除します。

Microsoft Exchange Information Store サービスを無効にするには

  1. サービス MMC (Microsoft 管理コンソール) スナップインで、[名前] 一覧にある [Microsoft Exchange Information Store] を右クリックし、[プロパティ] をクリックします。

  2. [スタートアップの種類] 一覧の [無効] を選択し、[停止] をクリックします。

メールボックスとパブリック フォルダ データベースを完全に削除するには

  • Exchange Server セキュリティ強化ガイドのメールボックス ストアおよびパブリック フォルダ ストアをマウント解除して削除する方法 に関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=25210) の指示に従います。

フロントエンド サーバーでのストア サービスの実行に関する問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 286822 の [XCCC] フロントエンド サーバーがフロントエンド サーバー自体に対して多数の接続を確立する現象に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=286822)

  • 文書番号 320298「[XCCC] フロントエンド サーバーで多数の接続が確立される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320298)

フロントエンド サーバーとバックエンド サーバーの詳細については、『Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology』(http://go.microsoft.com/fwlink/?linkid=34216) を参照してください (このサイトは英語の場合があります)。


REAPI.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

Exchange Server アナライザによって、上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


Recipient Update Service is missing or is not configured
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-07-11

Microsoft Exchange Server アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、ディレクトリ内にある各受信者更新サービス オブジェクトの msExchAddressListServiceLink 属性の値を判断します。msExchAddressListServiceLink 属性は、アドレス一覧サービスからサービスが実行されている必要のある Exchange Server コンピュータへのリンクです。受信者更新サービス オブジェクトの msExchAddressListServiceLink 属性が見つからない、またはオブジェクトの msExchAddressListServiceLink 属性に値が設定されていないことが検出されると、エラーが表示されます。

各受信者更新サービス インスタンスは、通常、その受信者更新サービスを実行している 1 つの Exchange Server コンピュータに関連付けられています。このメッセージが表示される場合、受信者更新サービス インスタンスは Exchange Server コンピュータと関連付けられていません。これにより、Exchange アドレス一覧および受信者が更新されない可能性があります。

受信者更新サービスのこのインスタンスを実行するには、インスタンスを既存の Exchange サーバーに関連付ける必要があります。

このエラーを修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [受信者] で、[受信者更新サービス] をクリックします。右側のペインで、受信者更新サービスの該当するインスタンスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[Exchange サーバー] で、[参照] をクリックし、このインスタンスを実行するサーバーを指定します。

  4. [OK] をクリックし、[OK] を再度クリックして、変更を有効にします。

  5. Exchange システム マネージャを終了します。

受信者更新サービスの詳細については、以下のトピックおよび Microsoft サポート技術情報の文書を参照してください。

  • 『Exchange Server 2003 管理ガイド』の「Exchange Server 2003 での受信者と受信者ポリシーの管理」(http://go.microsoft.com/fwlink/?linkid=47617) (このサイトは英語の場合があります)

  • 文書番号 328738「受信者更新サービスで受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253828「受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 246127「Exchange 受信者更新サービスの進行状況を確認する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 文書番号 253770「Exchange 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


クラスタ環境での Windows 2000 Server SP4 の推奨アップデート
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange サーバー上で実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

注 :
CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合、そのコンピュータは Microsoft Windows 2000 Server を実行しています。値が 5.2 の場合は、そのコンピュータは Microsoft Windows Server™ 2003 を実行しています。

また、Exchange Server アナライザは Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、ServicePackMajorVersion キーの値を判断します。

最後に、Win32_Service WMI クラスに対してクエリを実行し、ClusSvc サービスが開始されているかどうかを判断します。

以下の条件に当てはまる場合は、ベスト プラクティスの構成を推奨するメッセージが表示されます。

  • Exchange サーバーが、Service Pack 4 でアップグレードされた Windows 2000 Server を実行しているコンピュータ上にある。

  • CluSvc サービスが開始されている。

利用可能な更新プログラムと修正プログラムを確認し、現在の環境で発生している問題を解決できるかどうかを判断することをお勧めします。

Windows 2000 Server を実行しているサーバーで利用可能な更新プログラムの詳細と一覧については、Microsoft サポート技術情報の文書番号 895090「Windows 2000 Service Pack 4-based サーバー クラスタの推奨ホットフィックス」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895090) を参照してください。


リモート キューの長さがしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-04-09

Microsoft Exchange アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Remote Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Remote Queue Length カウンタがピーク値の 1000 を超えたことが検出されると、Exchange アナライザによってエラーが表示されます。

SMTP Server\Remote Queue Length カウンタは、リモート配信を待機している SMTP (Simple Mail Transfer Protocol) キュー内のメッセージの数を示します。Remote Queue Length の増加は、メールが他のサーバーに送信されていないことを示しています。

このメール送信エラーは、ネットワーク サーバーやリモート サーバーの停止またはパフォーマンスの問題によって説明することができます。こうした停止またはパフォーマンスの問題によって、ネットワーク サーバーやリモート サーバーはメールを効率的に受信できなくなります。

このエラーを解決するには、次のリンクにあるリソースを使用して問題のあるサーバーまたはネットワーク コンポーネントを識別し、パフォーマンスの問題に対処します。

詳細情報

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Symptoms of Poor Performance」のメール キューの増加に関するセクションを参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスに関して考慮する必要がある 10 項目についてのページ (http://go.microsoft.com/fwlink/?LinkID=56460) を参照してください (このサイトは英語の場合があります)。


Remote Retry Queue Length がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Remote Retry Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

SMTP Server\Remote Retry Queue Length カウンタは、SMTP (Simple Mail Transfer Protocol) リモート再試行キューにある目的のサーバーに送信できなかったメッセージ数を示します。サンプル期間中に Remote Retry Queue Length カウンタがピーク値の 1000 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

このメール送信エラーは、ネットワーク サーバーやリモート サーバーの停止またはパフォーマンスの問題によって説明することができます。こうした停止またはパフォーマンスの問題によって、ネットワーク サーバーやリモート サーバーはメールを効率的に受信できなくなります。

このエラーを解決するには、次のリンクにあるリソースを使用して問題のあるサーバーまたはネットワーク コンポーネントを識別し、パフォーマンスの問題に対処します。

詳細情報

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Identifying Symptoms of Poor Performance」のメール キューの増加に関するセクションを参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 Performance:10 Things to Think About」(http://go.microsoft.com/fwlink/?LinkID=56460) を参照してください (このサイトは英語の場合があります)。


OAB Version 4 のレプリカが見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Exchange_Public_Folder に対してクエリを実行し、HasLocalReplica の現在の値を判断します。オフライン アドレス一覧の OAB Version 4 インスタンスで、HasLocalReplica の値が False に設定されていることが検出されると、Exchange Server アナライザによってエラーが表示されます。

オフライン アドレス一覧の OAB Version 4 インスタンスを表す HasLocalReplica が False に設定されている場合、オフライン アドレス一覧は正しく生成されません。この結果 Microsoft Office Outlook® 2003 ユーザーは、オフライン アドレス一覧をダウンロードすることができません。

この問題は、OAB Version 4 のレプリカを含むようにパブリック フォルダ ストアを構成していない場合に発生することがあります。既定では、オフライン アドレス帳は、そのアドレス帳がインストールされているサーバーのパブリック フォルダ ストアにコンテンツをレプリケートします。パブリック フォルダ ストアがオフライン アドレス帳のレプリケーション構成から削除されていると、上で説明した問題が発生します。

このエラーを修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、[フォルダ] をクリックします。

  3. [パブリック フォルダ] を右クリックし、[システム フォルダの表示] をクリックします。

  4. [OFFLINE ADDRESS BOOK] オブジェクトをクリックして展開します。

  5. [OFFLINE ADDRESS BOOK] の下で、[o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] を右クリックし、[プロパティ] をクリックします。

  6. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳のための適切なパブリック ストアを入力します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] をクリックして展開します。

  9. [o=<組織名>/cn=addrlists/cn=oabs/cn=<既定のオフライン アドレス一覧>] の下にある [OAB Version 4] を右クリックし、[プロパティ] をクリックします。

  10. [レプリケーション] タブで、[コンテンツを以下のパブリック ストアにレプリケートする] ボックスにパブリック フォルダ ストアが入力されていることを確認します。パブリック フォルダ ストアが入力されていない場合は、[追加] をクリックし、オフライン アドレス帳のための適切なパブリック ストアを入力します。

  11. [適用] をクリックし、[OK] をクリックします。

この問題の詳細については、Microsoft サポート技術情報の文書番号 286328「[XADM] オフライン アドレス帳が見つからず、Exchange 2000 で生成されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=286328) を参照してください。

Exchange Server 2003 を実行している最初のコンピュータを管理グループから正しく削除する方法の詳細については、Microsoft サポート技術情報の文書番号 822931「最初の Exchange 2003 Server コンピュータをサイトから削除する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822931) を参照してください。

オフライン アドレス帳に関する問題の詳細については、次の Exchange Server リソースを参照してください。

  • 「Offline Address Book - Things to Consider」(http://go.microsoft.com/fwlink/?LinkId=57581) (このサイトは英語の場合があります)

  • 「How Outlook 2003 SP2 and Exchange Server 2003 SP2 OAB Version 4 Work Together」(http://go.microsoft.com/fwlink/?linkid=53099) (このサイトは英語の場合があります)

  • 「OAB Version 4 in Exchange Server 2003 Service Pack 2」(http://go.microsoft.com/fwlink/?linkid=53097) (このサイトは英語の場合があります)


レプリケーション受信キューのキューの長さがしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS Public パフォーマンス オブジェクトの Replication Receive Queue Size パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Replication Receive Queue Size カウンタがピーク値の 1000 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

パブリック フォルダのレプリケーション メッセージは SMTP によって受信され、分類されてローカルの SMTP キューに渡されます。次に、メッセージはパブリック フォルダ ストアに送信されます。パブリック フォルダ ストアに送信されると、メッセージはレプリケーション受信キューに入ります。レプリケーション受信キュー内のメッセージは処理され、適切なパブリック フォルダで変更が行われます。Replication Receive Queue Size パフォーマンス カウンタは、処理を待機しているパブリック フォルダ内のレプリケーション メッセージ数を示します。

レプリケーション キューが大きくなるほど、フォルダ内の内容が同期されなくなります。レプリケーション キューが増加すると、レプリケーション キューのメッセージの処理時にリソース上の負荷が増大します。また、レプリケーション キューが増加することは、サーバー上のパブリック フォルダの内容が古くなることを示します。

次のような場合は、レプリケーション受信キューの増加が事前に予期されるため、対策を施す必要がない可能性があります。

  • 新しく導入されたパブリック フォルダ サーバーで、予期される初回のバックフィル レプリケーションによってレプリケーション受信キューの増大が発生する。

  • Exchange のトポロジ内で、サイトの統合や、その他大規模な変更が生じる場合に、コンテンツの移動時に大量のレプリケーションが発生する。

パブリック フォルダのレプリカが大幅に変更されていない、安定した状態にある既存のサーバーである場合、このエラーは次のことを示す可能性があります。

  • ディスク、CPU、ネットワーク、メモリなどのサーバー リソースでのパフォーマンスのボトルネック。サーバー上にリソースのボトルネックが存在する場合、Store.exe プロセスはレプリケーション メッセージを十分な速度で処理することができず、キューが増加する。

  • レプリケーションの間隔が短すぎるため、次のレプリケーション サイクルの開始前にパブリック フォルダのレプリケーションを完了できない。

このエラーを解決するには、次の操作を行います。

  • レプリケーションの間隔を長くしてこれが確認できるまで MSExchangeIS Public\Replication Receive Queue Size を監視し、次のレプリケーション サイクルが始まる前にレプリケーションが完了するようにします。

  • 次のリンクにあるリソースを使用し、パフォーマンスのボトルネックがキューの増加の原因になっているかどうかを判断して、ボトルネックに対処します。

  • Exchange 組織内のレプリカの合計数を減らして、必要なレプリケーション トラフィックの量を小さくすることを検討します。

詳細情報

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Handling Special Exchange Roles and Performance」を参照してください (このサイトは英語の場合があります)。

  • Exchange Server パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。

  • Exchange パブリック フォルダのベスト プラクティスの詳細については、『Exchange Public Folder Best Practices:Implementing Replication』(http://go.microsoft.com/fwlink/?LinkId=46440) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 Service Pack 2 で導入されたパブリック フォルダ管理の強化機能の詳細については、『Microsoft Exchange Server 2003 Service Pack 2 リリース ノート』(http://go.microsoft.com/fwlink/?linkid=52072) を参照してください。


RESVC.DLL ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

Exchange Server アナライザによって、上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、最新の Service Pack、または使用している Exchange のバージョンに対応したロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールするときは、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


RestrictRemoteClients レジストリ キーが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、リモート プロシージャ コール (RPC) インターフェイス制限が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows NT\RPC

RestrictRemoteClients レジストリ キーが構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

RPC インターフェイス制限は、システムがネットワーク経由の攻撃を受けにくくなるようにネットワークの保護を強化するための機能です。RestrictRemoteClients レジストリ値により、システム上のすべての RPC インターフェイスの動作が変更されます。一部の例外を除き、RestrictRemoteClients レジストリ値によって、システム上の RPC インターフェイスへのリモート匿名アクセスが既定で防止されます。

RpcServerRegisterIf を使用してインターフェイスを登録する場合は、RPC により、サーバー アプリケーションがインターフェイスへのアクセスを (通常はセキュリティ コールバックを通して) 制限できるようになります。RestrictRemoteClients レジストリ値を使用すると、インターフェイスにセキュリティ コールバックが登録されていない場合でも、RPC はすべてのインターフェイスに対して追加のセキュリティ チェックを実行できます。

注 :
名前付きパイプ プロトコル シーケンスを使用する RPC クライアントは、すべての制限から除外されます。下位互換性に関する重大な問題があるために、パイプ プロトコル シーケンスは制限できません。
注 :
また、グループ ポリシー オブジェクト エディタを使用して the RestrictRemoteClients レジストリ キーを構成することもできます。

RestrictRemoteClients レジストリ キーは、DWORD 値を使用して構成されます。このレジストリ値が存在しない場合、その値は RPC_Restrict_Remote_Client_Default 値と同等です。

以下の表に、RestrictRemoteClients の構成設定に関する情報を示します。

レジストリ キー値 (DWORD) 説明

0 (既定値)

RPC_RESTRICT_REMOTE_CLIENT_NONE (0) は、Microsoft Windows Server™ 2003 Service Pack 1 での既定値を表します。この既定値が設定されていると、RPC インターフェイス制限は使用されません。

既定値の設定は、RPC_RESTRICT_REMOTE_CLIENT_NONE の値に対応します。サーバー アプリケーションは、適切な RPC 制限を課す役割を果たします。この既定の設定は、以前のバージョンの Windows での RestrictRemoteClients の値と同等です。

1

RestrictRemoteClients レジストリ キーの値が 1 の場合は、Microsoft Windows® XP Service Pack 2 での既定値を表します。この値を 1 に設定すると、すべての RPC インターフェイスへのアクセスが制限されます。すべてのリモート匿名呼び出しが、RPC ランタイムによって拒否されます。

この値の設定は、RPC_RESTRICT_REMOTE_CLIENT_DEFAULT の値に対応します。あるインターフェイスでセキュリティ コールバックが登録され、RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH フラグが設定されていると、そのインターフェイスにこの制限は適用されません。

2

RestrictRemoteClients レジストリ キーの値が 2 の場合は、すべてのリモート匿名呼び出しが、例外なく RPC ランタイムによって拒否されることを表します。

この値の設定は、RPC_RESTRICT_REMOTE_CLIENT_HIGH の値に対応します。RestrictRemoteClients 値が 2 に構成されていると、システムは RPC を使用してリモート匿名呼び出しを受信することができません。

Windows XP Service Pack 2 での RPC サービスの変更の詳細については、MSDN® の文書「RPC Interface Restrictions」(http://go.microsoft.com/fwlink/?LinkId=47371) を参照してください (このサイトは英語の場合があります)。


RFR ターゲット サーバーが手動で無効にされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ディレクトリ サービス プロキシ参照 (DSProxy 参照) サービスが手動で無効にされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\RFR Target Server

RFR Target Server が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Microsoft Outlook® 2000 Service Release 2 (SR-2) 以降のクライアントが初めて Exchange 2000 Server コンピュータまたは Exchange Server 2003 コンピュータに接続するときは、ホーム Exchange サーバーのディレクトリ サービスを探します。Outlook はまず、最初のセッションのために DSProxy プロセスを処理します。クライアントが DSProxy サービスに接続すると、クライアントに DSProxy 参照が返されます。この参照には、今後ディレクトリ要求が発生する場合は、すべてのディレクトリ要求をグローバル カタログ サーバーに送信する必要があることが示されています。Outlook は、DSProxy 参照情報をレジストリ内の MAPI プロファイルに設定します。

DSProxy 参照メカニズムを導入することにより、Exchange Server の負荷が軽減され、アドレス帳検索の待ち時間が短縮されます。明示的なサーバー名をプロファイルに入力した場合、グローバル カタログ サーバーに障害が発生したときは、Outlook を再起動する必要があります。この場合、Exchange Server は Outlook に新しい参照を送信します。

状況によっては、RFR Target Server エントリをハードコードし、MAPI クライアント参照サービスで使用するサーバーを指定した方がよい場合があります。たとえば、グローバル カタログ サーバーをメンバ サーバーに降格する 1 週間前には、RFR Target Server エントリをグローバル カタログ サーバーの定義済みグループにハードコードする必要があります。これによって、降格されるグローバル カタログ サーバーは Outlook クライアントの MAPI プロファイルで参照されなくなります。RFR Target Server レジストリ エントリのこの使用方法の詳細については、Microsoft サポート技術情報の文書番号 305065「[XADM] グローバル カタログ サーバーをドメイン コントローラに降格する際の Exchange Server 関連の考慮点」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=305065) を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

RFR Target Server レジストリ値を使用するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. RFR Target Server という名前の新しい REG_MULTISZ 値を作成します。

  4. 指定するサーバーの完全修飾ドメイン名を使用して、RFR Target Server 値を構成します。

  5. レジストリ エディタを終了し、Microsoft Exchange System Attendant サービスを再開して、変更を有効にします。

RFR サーバーの固定設定を無効にするには、削除するサーバーの完全修飾ドメイン名を削除します。入力されているサーバーが RFR ターゲット サーバーのみの場合は、RFR Target Server レジストリ値を削除します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook 2000 SR-2 以降のクライアントが Active Directory® ディレクトリ サービスと通信する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 302914「[XCCC] Outlook 2000 から Active Directory へのアクセス方式」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914)

  • 文書番号 256976「MAPI クライアントから Active Directory へアクセスする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976)


RegTrace が現在有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで高度な診断トレースが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\MosTrace\CurrentVersion\DebugAsyncTrace\EnabledTraces

EnabledTraces レジストリ エントリが存在し、0 以外の値で構成されていることが検出されると、エラーが表示されます。

Exchange Server のトランスポートおよびルーティング コンポーネントの高度な診断トレースは、Regtrace ユーティリティ (Regtrace.exe) を使用することにより実現されます。Regtrace は、特に、配信不能レポート (NDR) の診断やトラブルシューティングに有効なツールです。Regtrace ユーティリティは、Exchange Server の CD の \Support\Utils\I386 フォルダに格納されています。

トレース ファイルは Regtrace ユーティリティの [Output] タブで指定した場所にあります。このファイルの既定の場所は、C:\Trace.atf です。トレース ファイルはバイナリ エンコード ファイルであり、トレース対象のトランスポートおよびルーティング コンポーネントに関するデバッグ レベルの情報を含んでいます。このため、Microsoft 製品サポート サービスでは、内部分析を行うために顧客にトレース ファイルを送付するよう依頼します。

Regtrace を有効にするとサーバーのパフォーマンスが大幅に低下するため、問題のトラブルシューティングを行うことが多い場合を除き、Regtrace は Microsoft 製品サポート サービスの厳格な指示に基づいて短期間のみ使用するように十分注意してください。パフォーマンスの問題に加えて、トレース ファイル用のディスク領域も、1 分あたり 10 MB 以上のペースで消費されます。問題のトラブルシューティングを行っていない場合は、このエラーを解決するために、Regtrace を使用してトレースを無効にすることができます。

Regtrace を使用して高度な診断トレースを無効にするには

  1. Regtrace.exe を Exchange Server の CD から Exchange Server コンピュータにコピーします。

  2. Exchange Server コンピュータで Regtrace.exe を実行します。Regtrace のユーザー インターフェイスが表示されます。

  3. [Traces] タブで、チェック ボックスをすべてオフにします。

  4. [Output] タブを選択し、[No Tracing] を選択します。

  5. [OK] をクリックして変更を保存し、Regtrace ユーティリティを終了します。
  • Regtrace ツールの詳細については、Microsoft サポート技術情報の文書番号 238614「[XCON] Exchange 2000 用に Regtrace をセットアップする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=238614) を参照してください。

  • メッセージングに関する一般的なトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 281800「[XCON] Exchange 2000でのメッセージ障害のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281800) を参照してください。


Rejection threshold not configured
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、ContentFilterConfig のクラスを含むすべてのオブジェクトについて、次の属性の値を判断します。

msExchAgentsFlags msExchAgentsFlag 属性の値は、Microsoft Exchange Server 2007 のコンテンツ フィルタ エージェント、および SCL (Spam Confidence Level) 拒否処理の状態を示します。コンテンツ フィルタ エージェントが任意のコンピュータで有効になっていると、そのコンピュータのどの受信コネクタを経由したメッセージであっても、すべてフィルタ処理されます。SCL 拒否処理の機能が有効になっていると、SMTP トランザクション時に SCL 拒否のしきい値を超えるすべてのメッセージに関して、拒否応答が送信されます。

msExchMessageHygieneSCLRejectThreshold msExchMessageHygieneSCLRejectThreshold 属性の値は、SCL 拒否処理の設定レベルを示します。この値は、コンテンツ フィルタ エージェントがメッセージを拒否し、送信者に配信不能レポート (NDR) を送信することになる SCL レベルです。

また、Exchange アナライザは、次の Exchange 管理シェル コマンドレットを実行し、スパム対策エージェントがインストールされたすべてのハブ トランスポート サーバーの役割を照会します。

Get-TransportServer | where { $_.AntispamAgentsEnabled -eq $True}

Exchange アナライザによって、次に示すような状況にあるサーバーが検出されると、警告が表示されます。

  • コンテンツ フィルタが有効である。

  • SCL 拒否処理が有効である。

  • SCL 拒否のしきい値が 9 に設定されている。

  • サーバーでスパム対策エージェントが有効である。

この警告は、コンテンツ フィルタと SCL 拒否処理が有効であるのに、SCL 拒否処理のしきい値が既定値の 9 に設定されていることを示しています。この場合、正当なユーザーからのメッセージであっても拒否されることがあります。SCL 拒否処理のしきい値の推奨設定値は、7 です。

この警告に対処するには、SCL 拒否処理のしきい値を 7 に設定します。そのためには、Exchange 管理コンソールの [スパム対策] タブ、または Exchange 管理シェルの Set-ContentFilterConfig コマンドレットを使用します。

SCL 拒否処理のしきい値を設定するには、Exchange Server 2007 製品ドキュメントの「Spam Confidence Level のしきい値を有効化および構成する方法」(http://go.microsoft.com/fwlink/?LinkId=96099) トピックにあるガイダンスに従ってください。

詳細情報

Exchange Server 2007 のスパム対策機能とウイルス対策機能を管理する方法の詳細については、Exchange Server 2007 製品ドキュメントの「スパム対策およびウイルス対策の機能の管理」(http://go.microsoft.com/fwlink/?LinkId=96103) を参照してください。


受信者更新サービスが削除されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内の各受信者更新サービス オブジェクトの msExchAddressListServiceLink 属性の値を判断します。msExchAddressListServiceLink 属性は、アドレス一覧サービスから、そのサービスが実行されている Exchange Server コンピュータへのリンクです。Exchange Server アナライザによって、msExchAddressListServiceLink 属性の値が "DEL:" に設定されていることが検出されると、エラーが表示されます。

受信者更新サービスの各インスタンスは、受信者更新サービスを実行している Exchange Server コンピュータの 1 台と関連付けられています。このメッセージが表示される場合は、その受信者更新サービス インスタンスが、Exchange 組織内には存在しない Exchange Server コンピュータに関連付けられています。そのサーバーは、使用を停止されているか、別の理由でトポロジから外されている可能性があります。

受信者更新サービスのこのインスタンスを実行するには、そのインスタンスを既存の Exchange Server に関連付ける必要があります。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] の下の [受信者更新サービス] をクリックします。右側のペインで、受信者更新サービスの該当するインスタンスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[Exchange サーバー] の横の [参照] をクリックし、このインスタンスを実行する新しいサーバーを指定します。

  4. [OK] をクリックし、[OK] を再度クリックして変更を有効にします。

  5. Exchange システム マネージャを終了します。

受信者更新サービスの詳細については、以下の Exchange のトピックおよび Microsoft サポート技術情報の文書を参照してください。

  • 『Administration Guide for Exchange Server 2003』の「Managing Recipients and Recipient Policies」(http://go.microsoft.com/fwlink/?linkid=47617) (このサイトは英語の場合があります)

  • 文書番号 328738「受信者更新サービスで受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号 246127「Exchange 受信者更新サービスの進行状況を確認する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 文書番号 253770「Exchange 受信者更新サービスで実行されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


RPC のバインドに FQDN が含まれていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、networkAddress 属性の ncacn_ip_tcp 値に完全修飾ドメイン名 (FQDN) が含まれているかどうかを判断します。ncacn_ip_tcp 値にピリオド (.) が含まれていないことが検出されると、エラーが表示されます。

Exchange Server 2003 用の Microsoft Office Outlook® Web Access では、フロントエンド サーバーが Exchange バックエンド サーバーへの接続を試みるときに、networkaddress 属性値が調査されます。

注 :
Exchange 2000 Server 用の Outlook Web Access では、この確認は行われません。フロントエンド サーバーは、FQDN の値を必要とします。

フロントエンド サーバーはある期間、networkaddress ncacn_ip_tcp に対して返される値を確認します。以下の条件に当てはまる場合、特定のバックエンド サーバー上にあるメールボックスへの接続要求が失敗し、フロントエンド サーバーからユーザーに、"HTTP 500 内部サーバー エラー" というエラー メッセージが返されます。

  • ncacn_ip_tcp の値が、ホスト名または NetBIOS 名だけになっている。

  • ncacn_ip_tcp の値が、FQDN ではない。

Active Directory のサーバー オブジェクトで ncacn_ip_tcp 値を更新し、Exchange Server 2003 用の Outlook Web Access が正しく機能することを確認する必要があります。影響を受けているサーバーの名前は、Exchange Server アナライザの出力に示されます。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
注 :
ncacn_ip_tcp の値を更新する前に、この文書を終わりまで読んでください。Exchange Server サービスを再開する前に、追加の手順を実行することもできます。
networkAddress 属性の ncacn_ip_tcp 値を更新するには

  1. Windows 2000 Server サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

  3. [<Exchange サーバー名>] を右クリックし、[プロパティ] をクリックします。

  4. [Attributes] の一覧で [networkaddress] をクリックし、[Edit] をクリックします。

  5. ncacn_ip_tcp の新しい値を追加します。サーバーの NetBIOS 名やホスト名ではなく、FQDN を使用します。

    この値のために使用する構文は、ncacn_ip_tcp:FQDN です。たとえば、使用している Exchange バックエンド サーバーのホスト名が EXCHANGE1 であり、FQDN が EXCHANGE1.contoso.com である場合は、ncacn_ip_tcp に ncacn_ip_tcp:EXCHANGE1.contoso.com という値を使用します。

  6. 元の ncacn_ip_tcp 値を選択し、[削除] をクリックして、バックエンド サーバーの NetBIOS 名またはホスト名を含む元の値を削除します。[OK] を 2 回クリックして変更を適用します。

  7. サーバー上のすべての Exchange Server サービスを再開します。

  8. ドメイン コントローラが複数ある場合は、レプリケーションが行われるまで待機してから、フロントエンド サーバーからログオンします。レプリケーションの完了後に問題が解決されていない場合は、フロントエンド サーバーで IIS Admin サービスを再開します。

短い形式のホスト名を持つサーバーの IP アドレスを関連付けるためにバックエンド サーバーで Hosts ファイルを管理する場合は、UpdateProtocols レジストリ値も更新する必要があります。Hosts ファイルが使用されている場合は、Microsoft System Attendant サービスが再開されるときに、Exchange Server によって ncacn_ip_tcp 値が元に戻されることがあります。バックエンド サーバーがクラスタ化されている場合は、フェールオーバー後に Exchange Server によって ncacn_ip_tcp 値が元に戻されることがあります。

Exchange Server サービスの再開によって発生する可能性があるダウンタイムを最小限にするには、以下の手順を実行してから、前の手順で説明したように networkaddress 属性の ncacn_ip_tcp 値を更新し、Exchange Server サービスを再開します。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Hosts ファイルを使用するバックエンド サーバーの UpdateProtocols レジストリ値を変更するには

  1. レジストリ エディタを使用して、バックエンド サーバーで次のレジストリ値を構成します。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\UpdateProtocols

    注 :
    UpdateProtocols 値が存在しない場合は、この値を作成する必要があります。それには、次の手順に従います。
    1. レジストリ エディタを起動して、次のレジストリ サブキーを見つけます。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\

    2. [Parameters] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

    3. 「UpdateProtocols」と入力し、Enter キーを押します。

  2. [UpdateProtocols] を右クリックし、[変更] をクリックします。次に、[値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  3. ネットワークのバックエンド クラスタ ノードで Hosts ファイルを使用する場合は、 UpdateProtocols のエントリの順序を以下のように変更します。

    IPAddress to FQDN

    IPAddress to NetBIOS

    変更前は以下のようになっていたはずです。

    IPAddress to NetBIOS

    IPAddress to FQDN

  4. サーバー上のすべての Exchange Server サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


RPC のバインドが DNS で解決された名前と一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、各 Exchange Server コンピュータ用に構成されているドメイン ネーム システム (DNS) サーバーに対し、DNS クエリの実行を試みます。この接続は、名前解決要求を実行し、その結果を分析するカスタム オブジェクト プロセッサを使用して行われます。また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバーの networkAddress 属性の ncacn_ip_tcp 値、および DNS 解決後に返される完全修飾ドメイン名 (FQDN) が異なるかどうかを判断します。networkAddress 属性は、Active Directory の各 Exchange Server オブジェクトの属性です。Active Directory 内のサーバーの ncacn_ip_tcp 値が DNS 解決後の FQDN と一致しないことが検出されると、警告が表示されます。

この状況は、Exchange がインストールされた後でサーバーの FQDN が変更された場合に発生します。Exchange Server および Active Directory の両方にとって、正しく構成されて正常な状態にある DNS が正しく機能する必要があります。ドメイン ネーム サービスの登録と解決の問題は、Exchange Server コンピュータのメッセージ送信、受信、および配信機能に大きな影響を与える可能性があります。Active Directory の Exchange Server オブジェクトの networkAddress 属性を手動で編集することにより 2 つのアドレスを一致させると、この問題を防止できます。

Active Directory のサーバー オブジェクトの ncacn_ip_tcp 値を更新して、ncacn_ip_tcp 値をサーバーの DNS FQDN と一致させる必要があります。影響を受けているサーバーの名前は、Exchange Server アナライザの出力に示されます。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
networkAddress 属性の ncacn_ip_tcp 値を更新するには

  1. Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

  3. [<Exchange サーバー名>] を右クリックし、[プロパティ] をクリックします。

  4. [Attributes] の一覧で [networkAddress] をクリックし、[Edit] をクリックします。

  5. ncacn_ip_tcp の新しい値を追加します。現在の値ではなく、サーバーの FQDN を使用します。

    この値のために使用する構文は、ncacn_ip_tcp:FQDN です。たとえば、使用している Exchange サーバーのホスト名が EXCHANGE1 で、FQDN が EXCHANGE1.contoso.com である場合、ncacn_ip_tcp には、ncacn_ip_tcp:EXCHANGE1.contoso.com という値を使用します。

  6. 誤ったサーバー名が含まれる元の ncacn_ip_tcp 値を削除するには、元の値を選択し、[削除] をクリックします。[OK] を 2 回クリックして変更を適用します。

  7. サーバー上のすべての Exchange Server サービスを再開します。

Active Directory での DNS 使用の詳細については、Microsoft サポート技術情報の文書番号 323418「[HOWTO] Active Directory が有効な Windows Server 2003 で、既存の DNS インフラストラクチャに DNS を統合する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=323418) を参照してください。


RPC のバインド順序が正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで使用されているリモート プロシージャ コール (RPC) のバインド順序を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Svr_Binding_Order

Rpc_Svr_Binding_Order の値が ncacn_ip_tcp で始まっていないことが検出されると、エラーが表示されます。

Rpc_Svr_Binding_Order レジストリ エントリは、コンピュータに Exchange Server をインストールすると作成されます。このエントリにより、サーバー間の RPC 通信に使用するプロトコル シーケンスが決定されます。

既定では、Rpc_Svr_Binding_Order エントリには、次の値のデータが含まれています。

ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp

注 :
Exchange Server コンピュータに他のプロトコルもインストールされている場合は、この文字列に他の値が追加されていることがあります。

このエントリは、Exchange Server が他のサーバーとの RPC 通信のために試みるネットワーク通信プロトコルの順序を指定しています。たとえば、最初に TCP/IP が指定されているため、Exchange Server は最初に TCP/IP 経由の RPC を使用して別のサーバーとの通信を試み、その後で他のプロトコル経由の RPC を試みます。

RPC のバインド順序は、既定値から変更しないようにすることをお勧めします。既定値を変更すると、サーバーまたはサービスの起動中や、サーバー間通信で問題が発生する可能性があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. 右側のペインで、[Rpc_Svr_Binding_Order] をダブルクリックします。

  4. [値のデータ] ダイアログ ボックスに、「ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp」と入力します。

  5. [OK] をクリックし、レジストリ エディタを終了します。

  6. すべての Exchange Server サービスを再開するか Exchange Server コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC のバインド順序の詳細については、Microsoft サポート技術情報の文書番号 325930「[XCCC] RPC クライアント プロトコルのレジストリ エントリが原因で発生する接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930) を参照してください。


Rpc_Binding_Order レジストリ エントリが存在している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、クライアント指向のリモート プロシージャ コール (RPC) のバインド順序に関するレジストリ エントリが Exchange Server コンピュータ上に存在するかどうかを確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Binding_Order

Rpc_Binding_Order が存在することが検出されると、警告が表示されます。

Rpc_Binding_Order 値が存在している場合、以下のうち 1 つ以上がコンピュータにインストールされていることを示しています。

  • Exchange Server Version 5.5

  • Microsoft Office Outlook® 2003

  • Windows クラスタ

  • RPC_Binding_Order エントリによって、Outlook RPC の通信が開始されるときに使用されるプロトコル シーケンスが決定されます。このエントリは、Exchange Server 2003 や Exchange 2000 Server には作成されません。このエントリが作成されるのは、Exchange Server 5.5 以前のバージョンの Exchange のみです。このコンピュータに以前 Exchange Server 5.5 または Microsoft Outlook がインストールされ、その後で削除されている場合は、このレジストリ エントリを手動で削除する必要があります。さらに、サポートされていない構成であるため、Exchange Server を実行するコンピュータからは Outlook を削除する必要があります。Exchange と Outlook を同じコンピュータで使用することの詳細については、Microsoft サポート技術情報の文書番号 266418「[XCCC] マイクロソフトでは Exchange 2000 Server と Outlook 2000 以降を同じコンピュータにインストールしないことを推奨します」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266418) を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc_Binding_Order レジストリ エントリを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. Rpc_Binding_Order 値を削除します。

  4. レジストリ エディタを終了し、すべての Exchange Server サービスを再開するか Exchange Server コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC_Binding_Order レジストリ エントリの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325930「[XCCC] RPC クライアント プロトコルのレジストリ エントリが原因で発生する接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930)

  • 文書番号 326036「[XADM] 正しい資格情報を使用して Exchange 2000 Server コンピュータにログオンできない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326036)


Rpc_Svr_Binding_Order レジストリ値が既定値から変更されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで使用されているリモート プロシージャ コール (RPC) のバインド順序を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Provider\Rpc_Svr_Binding_Order

Rpc_Svr_Binding_Order の値が ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp に設定されていないことが検出されると、警告が表示されます。

Rpc_Svr_Binding_Order レジストリ エントリは、コンピュータに Exchange Server をインストールすると作成されます。このエントリにより、サーバー間の RPC 通信に使用するプロトコル シーケンスが決定されます。

既定では、Rpc_Svr_Binding_Order エントリには、次の値のデータが含まれています。

ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp

注 :
Exchange Server コンピュータに他のプロトコルもインストールされている場合は、上記の文字列に他の値が追加されていることがあります。

このエントリは、Exchange Server が他のサーバーとの RPC 通信のために試みるネットワーク通信プロトコルの順序を指定しています。たとえば、最初に TCP/IP が指定されているため、Exchange Server は最初に TCP/IP 経由の RPC を使用して別のサーバーとの通信を試み、その後で他のプロトコル経由の RPC を試みます。

RPC のバインド順序は、既定値から変更しないようにすることをお勧めします。既定値を変更すると、サーバーの起動中やサービスの開始時、またはサーバー間通信で問題が発生する可能性があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Exchange\Exchange Provider

  3. 右側のペインで、[Rpc_Svr_Binding_Order] をダブルクリックします。

  4. [値のデータ] ダイアログ ボックスに、「ncacn_ip_tcp,ncacn_spx,ncacn_vns_spp」と入力します。

  5. [OK] をクリックし、レジストリ エディタを終了します。

  6. すべての Exchange Server サービスを再開するか Exchange Server コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC のバインド順序の詳細については、Microsoft サポート技術情報の文書番号 325930「[XCCC] RPC クライアント プロトコルのレジストリ エントリが原因で発生する接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325930) を参照してください。


Active Directory サーバーへのラウンドトリップ時間が 100 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、root\cimv2 名前空間内の WIN32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ResponseTime キーの値を判断します。ResponseTime キーの値が 100 ミリ秒を超えていることが検出されると、エラーが表示されます。

ResponseTime キーは、インターネット制御メッセージ プロトコル (ICMP) エコー要求 (ping) に対する応答の経過時間 (ミリ秒単位) を表します。Exchange Server コンピュータで使用されるドメイン コントローラの応答時間は、常に 10 ミリ秒以下である必要があります。応答時間が 100 ミリ秒を超えている場合は、パフォーマンスや接続の問題が発生している可能性があります。

このエラーを修正するには

  1. 問題のドメイン コントローラが過負荷になっていないことを確認します。ADTest.exe ツールを使用してドメイン コントローラに対するテストを実行し、このサーバーが予測された負荷を処理できるかどうかを確認します。

  2. Exchange サーバーとドメイン コントローラ上のイベント ログを調べ、1 つ以上の問題が発生していることを示すネットワーク関連のイベントが記録されていないかどうかを確認します。

  3. ドメイン コントローラで DCDiag.exe コマンドと NetDiag.exe コマンドを使用して、構成とシステムが正しい状態であることを確認します。

  4. 最後に、Active Directory® ディレクトリ サービスのサイト設計を調べます。Active Directory サイトは、帯域幅が広く、待ち時間が短いネットワーク セクションと見なされています。ネットワークがこの仕様に従って分割されていない場合は、ネットワークをさらに多くの Active Directory サイトに分割することを検討してください。
注 :
ping テストを行うためにアナライザ ツールで WMI に対してクエリを実行すると、既定のパケット サイズとタイムアウト値は無効になります。代わりに、アナライザは、ICMP パケットのサイズとして 4,096 バイト (既定値は 32 バイト)、タイムアウト値として 2,000 ミリ秒 (既定値は 1,000 ミリ秒) を使用します。

以下の手順に従って、アナライザの ping の動作を手動でエミュレートします。

手動で ping テストを実行するには

  • Exchange サーバーのコマンド ライン ウィンドウで次のコマンドを実行します。ping -L 4096 -N 6 <Active Server server name>注 このコマンドで、それぞれが 4,096 バイトの 6 つの ping 要求の送信が開始されます。

ADTest.exe ツールの詳細については、「Active Directory Performance Testing Tool (ADTest.exe)」(http://go.microsoft.com/fwlink/?LinkId=33758) を参照してください (このサイトは英語の場合があります)。

Win32_PingStatus WMI クラスの詳細については、MSDN® の文書「Win32_PingStatus」(http://go.microsoft.com/fwlink/?LinkId=33549) を参照してください (このサイトは英語の場合があります)。

Active Directory サイト設計の詳細については、「Designing the Site Topology」(http://go.microsoft.com/fwlink/?linkid=33551) を参照してください (このサイトは英語の場合があります)。


Active Directory サーバーへのラウンドトリップ時間が 10 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、root\cimv2 名前空間内の WIN32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ResponseTime キーの値を判断します。ResponseTime キーの値が 10 ミリ秒より大きく、100 ミリ秒未満であることが検出されると、警告が表示されます。

ResponseTime キーは、Exchange サーバーからドメイン コントローラに送信されたインターネット制御メッセージ プロトコル (ICMP) エコー要求 (ping) パケットに対する応答の経過時間 (ミリ秒単位) を表します。Exchange Server コンピュータで使用されるドメイン コントローラの応答時間は、常に 10 ミリ秒以下である必要があります。応答時間が 10 ミリ秒を超えている場合は、パフォーマンスや接続の問題が発生している可能性があります。

この警告を修正するには

  1. 問題のドメイン コントローラが過負荷になっていないことを確認します。ADTest.exe ツールを使用してドメイン コントローラに対するテストを実行し、このサーバーが予測された負荷を処理できるかどうかを確認します。

  2. Exchange サーバーとドメイン コントローラ上のイベント ログを調べ、1 つ以上の問題が発生していることを示すネットワーク関連のイベントが記録されていないかどうかを確認します。

  3. ドメイン コントローラで DCDiag.exe コマンドと NetDiag.exe コマンドを使用して、構成とシステムが正しい状態であることを確認します。

  4. 最後に、Active Directory® ディレクトリ サービスのサイト設計を調べます。Active Directory サイトは、帯域幅が広く、待ち時間が短いネットワーク セクションと見なされています。ネットワークがこの仕様に従って分割されていない場合は、ネットワークをさらに多くの Active Directory サイトに分割することを検討してください。
注 :
ping テストを行うためにアナライザ ツールで WMI に対してクエリを実行すると、既定のパケット サイズとタイムアウト値は無効になります。代わりに、アナライザは、ICMP パケットのサイズとして 4,096 バイト (既定値は 32 バイト)、タイムアウト値として 2,000 ミリ秒 (既定値は 1,000 ミリ秒) を使用します。

以下の手順に従って、アナライザの ping の動作を手動でエミュレートします。

手動で ping テストを実行するには

  • Exchange サーバーのコマンド ライン ウィンドウで次のコマンドを実行します。ping -L 4096 -N 6 <Active Server server name>注 このコマンドで、それぞれが 4,096 バイトの 6 つの ping 要求の送信が開始されます。

ADTest.exe ツールの詳細については、「Active Directory Performance Testing Tool (ADTest.exe)」(http://go.microsoft.com/fwlink/?LinkId=33758) を参照してください (このサイトは英語の場合があります)。

Win32_PingStatus WMI クラスの詳細については、MSDN® の文書「Win32_PingStatus」(http://go.microsoft.com/fwlink/?LinkId=33549) を参照してください (このサイトは英語の場合があります)。

Active Directory サイト設計の詳細については、「Designing the Site Topology」(http://go.microsoft.com/fwlink/?linkid=33551) を参照してください (このサイトは英語の場合があります)。


グローバル カタログ サーバーへのラウンドトリップ時間が 100 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、root\cimv2 名前空間内の WIN32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ResponseTime キーの値を判断します。ResponseTime キーの値が 100 ミリ秒を超えていることが検出されると、エラーが表示されます。

ResponseTime キーは、Exchange サーバーからグローバル カタログ サーバーに送信された ICMP (Internet Control Message Protocol) エコー要求 (ping) パケットに対する応答の経過時間 (ミリ秒単位) を表します。Exchange Server コンピュータで使用されるグローバル カタログ サーバーの応答時間は、常に 10 ミリ秒以下である必要があります。応答時間が 10 ミリ秒を超えている場合は、パフォーマンスや接続の問題が発生している可能性があります。

このエラーを修正するには

  1. 問題のグローバル カタログ サーバーが過負荷になっていないことを確認します。ADTest.exe ツールを使用してグローバル カタログ サーバーに対するテストを実行し、このサーバーが予測された負荷を処理できるかどうかを確認します。

  2. Exchange サーバーとグローバル カタログ サーバーのイベント ログを調べ、1 つ以上の問題が発生していることを示すネットワーク関連のイベントが記録されていないかどうかを確認します。

  3. グローバル カタログ サーバーで DCDiag.exe コマンドと NetDiag.exe コマンドを使用して、構成とシステムが正しい状態であることを確認します。

  4. 最後に、Active Directory® ディレクトリ サービスのサイト設計を調べます。Active Directory サイトは、帯域幅が広く、待ち時間が短いネットワーク セクションと見なされています。ネットワークがこの仕様に従って分割されていない場合は、ネットワークをさらに多くの Active Directory サイトに分割することを検討してください。
注 :
ping テストを行うためにアナライザ ツールで WMI に対してクエリを実行すると、既定のパケット サイズとタイムアウト値は無効になります。代わりに、アナライザは、ICMP パケットのサイズとして 4,096 バイト (既定値は 32 バイト)、タイムアウト値として 2,000 ミリ秒 (既定値は 1,000 ミリ秒) を使用します。

以下の手順に従って、アナライザの ping の動作を手動でエミュレートします。

手動で ping テストを実行するには

  • Exchange サーバーのコマンド ライン ウィンドウで次のコマンドを実行します。ping -L 4096 -N 6 <Active Server server name>注 このコマンドで、それぞれが 4,096 バイトの 6 つの ping 要求の送信が開始されます。

ADTest.exe ツールの詳細については、「Active Directory Performance Testing Tool (ADTest.exe)」Web サイト (http://go.microsoft.com/fwlink/?linkid=33758) を参照してください (このサイトは英語の場合があります)。

Win32_PingStatus WMI クラスの詳細については、MSDN® の文書「Win32_PingStatus」(http://go.microsoft.com/fwlink/?LinkId=33549) を参照してください (このサイトは英語の場合があります)。

Active Directory サイト設計の詳細については、「Designing the Site Topology」(http://go.microsoft.com/fwlink/?linkid=33551) を参照してください (このサイトは英語の場合があります)。

Windows 2000 Server サポート ツールのインストールについては、Microsoft サポート技術情報の文書番号 301423「Windows 2000 サポート ツールを Windows 2000 Server ベースのコンピュータにインストールする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301423) を参照してください。

Windows Server 2003 サポート ツールのインストールについては、「Install Windows Support Tools」(http://go.microsoft.com/fwlink/?LinkId=41362) を参照してください (このサイトは英語の場合があります)。


グローバル カタログ サーバーへのラウンドトリップ時間が 10 ミリ秒を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-16

Microsoft® Exchange Server アナライザ ツールは、root\cimv2 名前空間内の WIN32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ResponseTime キーの値を判断します。ResponseTime キーの値が 10 ミリ秒より大きく 100 ミリ秒より小さいことが検出されると、警告が表示されます。

ResponseTime キーは、Exchange サーバーからグローバル カタログ サーバーに送信された ICMP (Internet Control Message Protocol) エコー要求 (ping) パケットに対する応答の経過時間 (ミリ秒単位) を表します。Exchange Server コンピュータで使用されるグローバル カタログ サーバーの応答時間は、常に 10 ミリ秒以下である必要があります。応答時間が 10 ミリ秒を超えると、パフォーマンスや接続の問題が発生する可能性があります。

この警告を修正するには

  1. 問題のグローバル カタログ サーバーが過負荷になっていないことを確認します。ADTest.exe ツールを使用してグローバル カタログ サーバーに対するテストを実行し、このサーバーが予測された負荷を処理できるかどうかを確認します。

  2. Exchange サーバーとグローバル カタログ サーバーのイベント ログを調べ、1 つ以上の問題が発生していることを示すネットワーク関連のイベントが記録されていないかどうかを確認します。

  3. グローバル カタログ サーバーで DCDiag.exe コマンドおよび NetDiag.exe コマンドを使用して、正しく構成され、正常な状態にあることを確認します。

  4. 最後に、Active Directory® ディレクトリ サービスのサイト設計を調べます。Active Directory サイトは、帯域幅が広く、待ち時間が短いネットワーク セクションと見なされています。ネットワークがこの仕様に従って分割されていない場合は、ネットワークをさらに多くの Active Directory サイトに分割することを検討してください。
注 :
ping テストを行うためにアナライザ ツールで WMI に対してクエリを実行すると、既定のパケット サイズとタイムアウト値は無効になります。代わりに、アナライザは、ICMP パケットのサイズとして 4,096 バイト (既定値は 32 バイト)、タイムアウト値として 2,000 ミリ秒 (既定値は 1,000 ミリ秒) を使用します。

以下の手順に従って、アナライザの ping の動作を手動でエミュレートします。

手動で ping テストを実行するには

  • Exchange サーバーのコマンド ライン ウィンドウで次のコマンドを実行します。

    ping -L 4096 -N 6 <Active Server server name>

    注 :
    このコマンドで、それぞれが 4,096 バイトの 6 つの ping 要求の送信が開始されます。

ADTest.exe ツールの詳細については、「Active Directory Performance Testing Tool (ADTest.exe)」Web サイト (http://go.microsoft.com/fwlink/?linkid=33758) を参照してください (このサイトは英語の場合があります)。

Win32_PingStatus WMI クラスの詳細については、MSDN® の文書「Win32_PingStatus」(http://go.microsoft.com/fwlink/?linkid=33549) を参照してください (このサイトは英語の場合があります)。

Active Directory サイト設計の詳細については、「Designing the Site Topology」(http://go.microsoft.com/fwlink/?linkid=33551) を参照してください (このサイトは英語の場合があります)。


受信者ポリシーのために検索フィルタを変更する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 受信者ポリシー オブジェクトの purportedSearch 属性値を判断します。purportedSearch 属性は、ポリシーが適用されるときに使用される検索引数を示しています。

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Active Directory 内のフォレスト オブジェクトである NTDS Settings の msDS-Behavior-Version 属性値も判断します。この値は、Active Directory フォレストの機能レベルを示しています。以下の表に、msDS-Behavior-Version 属性の有効な値を示します。

値 | フォレストの機能レベル
0 | Microsoft Windows® 2000 Server 混在
1 | Microsoft Windows Server™ 2003 中間
2 | Windows Server 2003 ネイティブ

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Windows2003Update コンテナの revision 属性値も判断します。この属性値は、Active Directory の準備ツール (ADPrep.exe) が実行されているかどうかを示しています。

Exchange Server アナライザ ツールは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、OSProductSuite キーの値を判断します。OSProductSuite キーの値は、そのコンピュータで実行されている Windows のバージョンを示します。

Exchange Server アナライザによって、以下の条件に当てはまることが検出されると、警告が表示されます。

  • 受信者ポリシーの purportedSearch 属性値に homeMdb が含まれている。

  • Active Directory フォレストの機能レベルが、Windows Server 2003 中間または Windows Server 2003 ネイティブ モードである。

  • Exchange Server コンピュータで Windows Small Business Server 2003 が実行されていない。

この警告は、Active Directory フォレストが Windows Server 2003 用に準備されていることを示しています。フォレストが Windows Server 2003 の完全な機能レベルにアップグレードされるときに電子メール アドレスのスタンプの問題が発生しないようにするために、受信者ポリシーの変更が必要になります。影響を受ける受信者ポリシーは、Exchange Server アナライザの出力に示されます。

Windows Server 2003 がドメイン コントローラとして使用されていて、受信者ポリシーが更新されていない場合、Windows Server 2003 でリンクされた値がレプリケートされると、受信者更新サービスは新しいユーザーの電子メール アドレスを正しく書き込みません。受信者更新サービスによる最初のユーザーの参照は、リンクされた値のレプリケーションにより、mailnickname がレプリケートされる時刻と homeMDB がレプリケートされる時刻の間である可能性があります。このため、この時点でユーザーには homeMDB ベースのポリシーではなく、既定のポリシーが適用されます。数分後、homeMDB がレプリケートされるときに、ユーザーには自身の homeMDB ポリシーが適用されます。ただし、ユーザーは既に既定のポリシーに一致するアドレスを持っています。

この警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[受信者ポリシー] を選択します。次に、受信者ポリシー名を右クリックし、[プロパティ] をクリックします。

  3. [<受信者ポリシー名> のプロパティ] ページの [全般] タブで、[フィルタのルール] の [変更] をクリックします。

  4. [Exchange 受信者を検索します] メニューの [カスタムの検索条件] を選択します。受信者ポリシーが最初にカスタム検索によって作成されている場合は、手順 3. で [変更] をクリックすると [カスタムの検索条件を検索します] ページが表示されます。

  5. ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを変更し、homeMdb 属性がフィルタ条件の一部として使用されないようにします。extensionAttribute、msExchHomeServerName、UPN などの属性は、同じ検索結果を得るのに役立つ可能性のある有効な引数です。

  6. [OK] をクリックして変更を保存し、Exchange システム マネージャを終了します。


受信者ポリシーの検索フィルタを変更する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange 受信者ポリシー オブジェクトの purportedSearch 属性値を判断します。purportedSearch 属性は、ポリシーが適用されるときに使用される検索引数を示しています。

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Active Directory 内のフォレスト オブジェクトである NTDS Settings の msDS-Behavior-Version 属性値も判断します。この値は、Active Directory フォレストの機能レベルを示しています。以下の表に、msDS-Behavior-Version 属性の有効な値を示します。

値 | フォレストの機能レベル
0 | Windows® 2000 Server 混在
1 | Windows Server™ 2003 中間
2 | Windows Server 2003 ネイティブ

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、Windows2003Update コンテナの revision 属性値も判断します。この属性値は、Active Directory の準備ツール (ADPrep.exe) が実行されているかどうかを示しています。

Exchange Server アナライザ ツールは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、OSProductSuite キーの値を判断します。OSProductSuite キーの値は、コンピュータ上で実行されている Windows のバージョンを示しています。

Exchange Server アナライザによって、以下の条件に当てはまることが検出されると、警告が表示されます。

  • 受信者ポリシーの purportedSearch 属性値に (homeMdb=) が含まれている。

  • Active Directory フォレストの機能レベルが Windows 2000 Server 混在である。

  • Active Directory フォレストが Windows Server 2003 ドメイン コントローラ用に準備されている。

  • Exchange Server コンピュータで Microsoft Windows Small Business Server 2003 が実行されていない。

この警告は、Active Directory フォレストが Windows Server 2003 用に準備されていることを示しています。Active Directory フォレストが Windows Server 2003 の完全な機能レベルにアップグレードされるときに電子メール アドレスのスタンプの問題が発生しないようにするには、受信者ポリシーを変更する必要があります。影響を受ける受信者ポリシーは、Exchange Server アナライザの出力に示されます。

ドメイン コントローラとして Windows Server 2003 を使用しており、受信者ポリシーを更新しない場合、Windows Server 2003 でのリンクされた値のレプリケーションによって、受信者更新サービスが新しいユーザーの電子メール アドレスを誤って書き込みます。

リンクされた値のレプリケーションにより、受信者更新サービスは、mailnickname のレプリケート時と homeMdb のレプリケート時の間で初めて新しいユーザーを検出する場合があります。このため、ユーザーはその時点で homeMdb ベースのポリシーではなく、既定のポリシーを使用します。数分後に homeMdb がレプリケートされると、ユーザーは homeMdb ポリシーを使用します。ただし、ユーザーは既に既定のポリシーと一致するアドレスを持っていることになります。

この警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[受信者ポリシー] を選択します。次に、受信者ポリシー名を右クリックし、[プロパティ] をクリックします。

  3. [<受信者ポリシー名> のプロパティ] ページの [全般] タブで、[フィルタのルール] の [変更] をクリックします。

  4. [Exchange 受信者を検索します] メニューの [カスタムの検索条件] を選択します。受信者ポリシーが最初にカスタム検索によって作成されている場合は、手順 3. で [変更] をクリックすると [カスタムの検索条件を検索します] ページが表示されます。

  5. ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを変更し、homeMdb 属性がフィルタ条件の一部として使用されないようにします。extensionAttribute、msExchHomeServerName、UPN などの属性は、同じ検索結果を得るのに役立つ可能性のある有効な引数です。

  6. [OK] をクリックして変更を保存し、Exchange システム マネージャを終了します。


Sender ID が構成されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-05-10

Microsoft Exchange ベスト プラクティス アナライザ ツールは、次の Exchange 管理シェル コマンドレットを使用して、対象となる Exchange Server 2007 エッジ トランスポート サーバーの役割またはハブ トランスポート サーバーの役割に対してクエリを実行し、SenderIdConfig オブジェクトの Enabled プロパティと ExternalMailEnabled プロパティの値を調べます。

コードのコピー
- get-SenderIdConfig

Enabled プロパティの値は、Sender ID エージェントが有効かどうかを指定します。Enabled パラメータの有効な入力は $true または $false です。既定の設定は $true です。Enabled パラメータが $true に設定されると、Sender ID エージェントが有効になります。

ExternalMailEnabled プロパティの値は、認証されていない接続からのすべてのメッセージを、Sender ID エージェントを経由して処理に渡すかどうかを指定します。ExternalMailEnabled パラメータの有効な入力は $true または $false です。既定の設定は $true です。ExternalMailEnabled パラメータが $true に設定されていると、認証されていない接続からのすべてのメッセージが Sender ID エージェントを経由して処理に渡されます。

Exchange ベスト プラクティス アナライザによって、SenderIdConfig オブジェクトの Enabled プロパティまたは ExternalMailEnabled プロパティの値が $true に設定されていないと判断されると、ベスト プラクティス メッセージが表示されます。

このメッセージは、対象となる Exchange Server 2007 エッジ トランスポート サーバーの役割またはハブ トランスポート サーバーの役割で、Sender ID が有効になっていないことを示します。

Sender ID は、すべての電子メール メッセージが、送信元であるはずのインターネット ドメインから送信されたことを確認しようとします。

Sender ID があるコンピュータで有効になっていると、そのコンピュータのどの受信コネクタを経由したメッセージであってもすべてフィルタ処理されます。外部ソースから届いたメッセージだけがフィルタ処理されます。外部ソースとは、認証されていないソースのことです。外部ソースは匿名のインターネット ソースだと見なされます。

この問題に対処するには、対象となる Exchange Server 2007 エッジ トランスポート サーバーの役割またはハブ トランスポート サーバーの役割で Sender ID を有効にします。

Exchange 管理シェルを使用して Sender ID 機能を有効にするには、次の操作を行います。

  • 送信者フィルタを有効にするには、次のコマンドを実行します。

    コードのコピー
    Set-SenderIdConfig -Enabled $true -ExternalMailEnabled $true

Sender ID の詳細については、以下のトピックを参照してください。

  • Sender ID ホーム ページ (http://go.microsoft.com/fwlink/?linkid=50977)

  • Exchange 2007 の Sender ID についてのページ (http://go.microsoft.com/fwlink/?LinkId=89719) (このサイトは英語の場合があります)

  • Sender ID の構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=89720) (このサイトは英語の場合があります)


サーバー名の大文字と小文字が一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory に格納されている Exchange サーバーの名前の値 (CN=<ExchangeServerName>) を判断します。Exchange Server アナライザは、この名前を取得した後、名前の文字数をカウントします。

また、Exchange Server アナライザは次のレジストリ エントリを読み取り、Exchange Server コンピュータのレジストリに格納されている Exchange サーバーのホスト名の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

また、Exchange Server アナライザは Win32_Service Microsoft WMI （Windows® Management Instrumentation) クラスに対してクエリを実行し、Windows® クラスタ サービス (ClusSvc) の Started キーの値を判断します。

以下の条件にすべて当てはまる場合は、Exchange Server アナライザによって既定以外の構成であることを示すメッセージが表示されます。

  • CN=<ExchangeServerName> の値が Hostname の値の大文字と小文字と一致しない。たとえば、CN=ComputerName に対し、Hostname は COMPUTERNAME と設定されています。

    注 :
    レジストリ内のサーバー名の大文字と小文字の変更はサポートされていますが、これはお勧めできません。
  • Exchange サーバー名が 15 文字以下になっている。

  • Exchange サーバーが Windows クラスタ内で実行されていない。

このエラーの最も一般的な原因は、Exchange サーバーの名前がレジストリにおいて手動で変更されたことです。


サーバー名が一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、This Server 値の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange サーバー オブジェクトの name 属性値を判断します。

最後に、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。値が True の場合はクラスタ サービスが開始されており、値が False の場合はクラスタ サービスは実行されていません。

Exchange Server アナライザによって、サーバー クラスタ内では実行されていない任意の Exchange Server コンピュータについて、This Server キーの値が、Active Directory 内にあるサーバー オブジェクトの name 属性値と一致していないことが検出されると、エラーが表示されます。

このエラーを修正するには、Active Directory 内にある name 属性の値と一致するように、This Server レジストリ キーを編集する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem.

  3. 右側のペインで、[This Server] をダブルクリックし、このコンピュータの正しい名前を入力します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


サーバー名が長すぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-22

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchExchangeServer の各ディレクトリ オブジェクトの名前 (cn) を判断します。cn 値は、Exchange Server コンピュータの短縮名が含まれている文字列です。Exchange Server アナライザは cn を取得して、その文字列の長さを確認します。この文字列の長さは、Exchange サーバー名の文字数です。Exchange サーバー名が 15 文字を超えていることが検出されると、エラーが表示されます。

Exchange Server 2007、Exchange Server 2003、および Exchange 2000 Server は NetBIOS とのいくつかの依存関係があり、ネットワーク トポロジによっては、すべての Exchange コンポーネントが正常に動作するように異なるサブネット間で NetBIOS 名前解決を使用する必要がある場合があります。NetBIOS の名前付け規則では、NetBIOS 名に 16 文字を使用できます。ただし、Microsoft では NetBIOS 名を 15 文字に制限し、16 文字目を NetBIOS サフィックスとして使用しています。

Exchange Server は NetBIOS との依存関係があり、NetBIOS 名が 15 文字を超えることができないため、Exchange 組織では 15 文字を超えるサーバー名はサポートされていません。さらに、Exchange Server コンピュータの名前を変更すると Active Directory および Exchange 組織全体に広範囲の影響を与える場合があるため、Exchange Server コンピュータの名前の変更はサポートされていません。

このエラーを修正するには

  1. 名前が正しく付けられていない Exchange Server コンピュータを、Remove オプションを使用して削除します。

  2. そのコンピュータの名前を 15 文字以下の名前に変更します。

  3. そのコンピュータに Exchange Server を再インストールします。

Exchange Server 2007 の削除の詳細については、Microsoft Exchange Server 2007 の展開に関するドキュメントの、Exchange 2007 をサーバーから完全に削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=79246) を参照してください。

Exchange Server 2003 の削除の詳細については、『Exchange Server Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) の「How to Uninstall Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。

詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 833396「Exchange Server 2003 をコンピュータから削除する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=833396)

  • 文書番号 260378「Exchange 2000 インストールを手動で削除する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260378)

  • 文書番号 328810「サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810)

  • 文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829)


サーバーの RPC ネットワーク アドレスが Exchange サーバー名と一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Miceosoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内にある各 Exchange Server オブジェクトの networkAddress 属性の値を判断します。この複数行文字列属性については、通常、以下の例に示すように複数のエントリが示されます。

ncacn_ip_tcp:<Exchange Server の完全修飾ドメイン名>

ncacn_np:<Exchange Server のホスト名>

ncacn_spx:<Exchange Server のホスト名>

ncacn_vns_spp:<Exchange Server のホスト名>

ncalrpc:<Exchange Server のホスト名>

netbios:<Exchange Server のホスト名>

また、Exchange Server アナライザは、Active Directory に対してもクエリを実行し、各 Exchange サーバー オブジェクトの name 属性の値を判断します。

name 属性の値が networkAddress 属性に含まれる文字列の名前部分と一致しないことが検出されると、エラーが表示されます。

このエラーは、管理者がサーバー オブジェクトの cn 値を手動で変更した場合に発生する可能性があります。networkAddress 属性は、Exchange Server によって作成および保守されます。この属性には、Exchange Server がサポートするさまざまなネットワーク通信プロトコルに対応するための文字列値が複数含まれます。各値は、それぞれのプロトコルの仕様に応じて、プロトコルに適切な形式のサーバー名を関連付けます。

このエラーを修正するには、サーバー名が変更されているかどうか、または値が無効になっているかどうかを確認し、適切な措置を講じます。

  • サーバー名が変更されている場合は、この文書の後の方で説明する手順に従って、適切な値に修正します。

  • 何らかの理由で値が無効になっている場合は、サーバー上で Exchange のセットアップを再実行します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit または同様のツールを使用して、Active Directory の管理グループ オブジェクトを見つけます。

    networkAddress 属性は、次の場所にあります。

    [CN=Configuration]、[CN=Services]、[CN=Microsoft Exchange]、[CN=組織名]、[CN=Administrative Groups]、[CN=管理グループ名]、[CN=Servers]、[CN=サーバー名]

  2. 一覧に表示される各値の形式に注意してください。必要に応じて値を更新しますが、各値のサーバー名以外は変更しないでください。

    注 :
    ncacn_ip_tcp 値の場合、サーバー名は NetBIOS 名やインターネット プロトコル アドレスではなく、完全修飾ドメイン名の形式にしてください。

  3. Active Directory エディタを終了し、Exchange Routing Engine サービスを再開します。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

Exchage のルーティングに関する問題の詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Troubleshooting Routing」を参照してください (このサイトは英語の場合があります)。


サービス プリンシパル名が存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-08-14

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、以下のテーブルに一覧表示されている Exchange リソースの Exchange サーバー コンピュータ アカウントにおける servicePrincipalName 属性に対して返される値を検出します。

Exchange リソース servicePrincipalName の値 | 返される値
exchangeMDB | 完全修飾ドメイン名 (FQDN)
exchangeMDB | NetBIOS 名
exchangeRFR | 完全修飾ドメイン名 (FQDN)
exchangeRFR | NetBIOS 名
SMTP | 完全修飾ドメイン名 (FQDN)
SMTP | NetBIOS 名
SMTPSVC | 完全修飾ドメイン名 (FQDN)
SMTPSVC | NetBIOS 名
HOST | 完全修飾ドメイン名 (FQDN)
HOST | NetBIOS 名

Exchange Server アナライザは、Exchange リソースのコンピュータ アカウントにおける servicePrincipalName 属性に、一覧内の予期される値のいずれかが存在しないことを検出すると、エラーを表示します。

サービス プリンシパル名 (SPN) はサービスのインスタンスを識別するための一意の名前で、サービス インスタンスが動作しているログオン アカウントに関連付けられます。Kerberos 認証は、SPN が適切に設定されていない Exchange サービスでは利用できません。

  • Microsoft Office Outlook® 2003 以降を実行しているクライアントと Exchange Information Store (メールボックス データ) の間で発生する認証問題は、exchangeMDB リソースに有効な SPN が設定されていないことが原因になっている場合があります。

  • Outlook 2003 以降のクライアントで発生する Active Directory 認証問題は、exchangeRFR リソースに有効な SPN が設定されていないことが原因になっている場合があります。

  • SMTP (Simple Mail Transport Protocol) 仮想サーバー間の認証問題は、SMTPSVC または HOST リソースに有効な SPN が設定されていないことが原因になっている場合があります。

この問題を解決するには、以下の手順に従い、関連する属性に対して不足している値を追加します。

SETSPN.exe ツールを使用して、不足している値を SPN に追加する

  1. Setspn.exe ツールをインストールします。Setspn.exe ツールを取得するには、"Windows 2000 リソース キット ツール :Setspn.exe" (http://go.microsoft.com/fwlink/?LinkId=28103) を参照してください (このサイトは英語の場合があります)。

    Windows Server 2003 バージョンの Setspn.exe コマンド ライン ツールは、Windows Server 2003 CD に格納されている Windows Server 2003 サポート ツールに含まれています。Server 2003 サポート ツールをインストールする場合は、Support/Tools フォルダの Suptools.msi ファイルをダブルクリックしてください。

  2. SETSPN.EXE Setspn_d.txt ファイルの指示に従って、不足している値を Exchange サーバーの Active Directory オブジェクトに追加します。以下の例は、仮想 SMTP サーバーの SPN に対する FQDN 値の追加を示しています。

    • コマンド プロンプトを開始し、Setspn.exe をインストールしたディレクトリに移動します。

    • コマンド プロンプトで、以下のコマンドを入力します。

      setspn.exe-a SMTPSVC/ mail.yourdomain.com YOURSERVERNAME

      注 :
      mail.yourdomain.com を SMTP 仮想サーバーの FQDN に置き換え、YOURSERVERNAME を Exchange サーバー名に置き換えます。
      Enter キーを押します。


過去 24 時間以内にサービスが予期せず終了した
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-14

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、サービス コントロール マネージャのソースについてイベント 7031 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

イベント 7031 警告は、指定したサービスが続行できなかったことを意味します。サービスはエラー数を報告するように構成されており、特定数のエラーが報告されると、サービス コントロール マネージャは指定されたサービスに構成されている回復操作を実行します。

これらのイベントの 1 つ以上が過去 24 時間以内にログに記録されていることが検出されると、情報メッセージが表示されます。

この問題はさまざまな原因によって発生しますが、一般的な原因としては次のことが考えられます。

  • 破損メッセージが処理されている。

  • ウイルス対策アプリケーションの構成上の問題。

この問題を解決するには、次の操作を行います。

  • マイクロソフト サポート技術情報の文書番号 286350「ADPlus を使用した "ハング" および "クラッシュ" のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=286350) で説明されている手順に従って、プロセスが応答しない (ハングする) または予期せず停止する (クラッシュする) 原因を特定します。

  • Microsoft Windows 2000 の最新の Service Pack を入手します。

  • Microsoft Exchange Server の最新の Service Pack を入手します。

  • ウイルス対策アプリケーションのベンダに問い合わせ、最新の更新プログラムと構成情報を入手します。

詳細情報

イベント 7031 警告の詳細については、イベントおよびエラー メッセージ センターのイベント詳細についてのページ (http://go.microsoft.com/fwlink/?LinkId=83114) を参照してください (このサイトは英語の場合があります)。

Windows 2000 Server の最新の Service Pack を入手する方法については、マイクロソフト サポート技術情報の文書番号 260910「最新の Windows 2000 Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260910) を参照してください。

Exchange 2000 Server の最新の Service Pack を入手する方法については、マイクロソフト サポート技術情報の文書番号 301378「[XGEN] 最新の Exchange 2000 Server Service Pack の入手方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=301378) を参照してください。

Exchange Server 2003 の最新の Service Pack を入手する方法については、Exchange Server 2003 に Service Pack 2 を適用する理由についてのページ (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange Server コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server パートナーのウイルスおよびスパム対策ソフトウェアについてのページ (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Services Value is Missing or Inaccessible
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-07-24

Microsoft Exchange アナライザ ツールは、次のレジストリ エントリを読み取り、Services 文字列型の値が存在することを確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup

Exchange アナライザによって Services 文字列型の値が存在しないか、アクセスできないことが検出されると、エラーが表示されます。

このエラーは、Exchange インストール ルートのパスを保持するために使用される Services 文字列型の値が存在しないか、アクセスできないことを示しています。Exchange インストール ルートのパスが存在しないと、重要なドライバとプロトコルを初期化できず、Exchange インフォメーション ストアや依存サービスの起動時に失敗する可能性があります。

このエラーに対処するには、Microsoft サポート技術情報の文書番号 285116「Exchange ストアが起動しない : エラー 7024、1026、9542、5000」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=285116) の手順に従ってください。


単一の Free/Busy のレプリカを見つけた
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、root\MicrosoftExchangeV2 名前空間の Exchange_PublicFolder Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各管理グループに存在する Free/Busy のレプリカの数を判断します。

管理グループ内に Free/Busy のレプリカが 1 つしかないことが検出されると、ベスト プラクティスのメッセージが表示されます。

通常は、各管理グループに複数の Free/Busy フォルダを用意することをお勧めします。複数の Free/Busy のレプリカにより、パフォーマンスや復元性が向上する場合があります。大規模な Exchange 組織の場合、単一の Free/Busy データのレプリカでは過負荷になる可能性があります。すべての Exchange 組織において、単一の Free/Busy データのレプリカは単一障害点となります。

以下の考慮事項がありますが、複数のレプリカを使用することをお勧めします。

  • 複数のレプリカにより、ネットワーク上のレプリケーション トラフィックが増加する。

  • 複数のレプリカにより、スケジュールが競合する危険が増大する。

少なくとも、10,000 メールボックスごとに 1 つのレプリカを使用する必要があります。

Free/Busy フォルダと空き時間情報の発行の詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) を参照してください (このサイトは英語の場合があります)。


大量のメールボックスで単一の Free/Busy のレプリカを見つけた
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、root\MicrosoftExchangeV2 名前空間内の Exchange_PublicFolder Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ReplicaList キーのエントリの数を判断します。エントリの数は、各管理グループに存在する Free/Busy レプリカの数を表します。

また、Exchange Server アナライザは Activie Diredctory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されているエントリの数は、メールボックス ストア上のメールボックスの数を表します。

管理グループ内に、10,000 以上のメールボックスを含む Free/Busy のレプリカが 1 つしかないことが検出されると、ベスト プラクティスのメッセージが表示されます。

通常は、各管理グループに複数の Free/Busy フォルダを用意することをお勧めします。複数の Free/Busy のレプリカにより、パフォーマンスや復元性が向上する場合があります。大規模な Exchange 組織の場合、単一の Free/Busy データのレプリカでは過負荷になる可能性があります。すべての Exchange 組織において、単一の Free/Busy データのレプリカは単一障害点となります。

以下の考慮事項がありますが、複数のレプリカを使用することをお勧めします。

  • 複数のレプリカにより、ネットワーク上のレプリケーション トラフィックが増加する。

  • 複数のレプリカにより、スケジュールが競合する危険が増大する。

少なくとも、10,000 メールボックスごとに 1 つのレプリカを使用する必要があります。

Free/Busy フォルダと空き時間情報の発行の詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) を参照してください (このサイトは英語の場合があります)。


トポロジ内にグローバル カタログが 1 つしか存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、root\MicrosoftExchangeV2 名前空間内の Exchange_DSAccess Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、そのトポロジ内に存在するグローバル カタログ サーバーの数を判断します。グローバル カタログ サーバーの数は、DSAccessNameGC WMI キーのエントリの数をカウントして決定されます。Exchange Server アナライザによって、そのトポロジ内にグローバル カタログ サーバーが 1 つしか存在しないことが検出されると、ベスト プラクティスのメッセージが表示されます。

フォールト トレランスを実現するためのベスト プラクティスとして、Exchange Server とユーザーへのサービスに少なくとも 2 台のグローバル カタログ サーバーを使用可能にすることをお勧めします。グローバル カタログ サーバーが 1 台しか存在しないと、単一障害点が発生します。Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 は、さまざまな機能をグローバル カタログ サーバーに依存しています。グローバル カタログ サーバーが使用できないと、メールの配信が遅延したり、完全に停止したりする場合があります。また、Exchange Server サービスが開始できない場合もあります。Exchange Server サービスが開始しないと、ユーザーはメールボックスにアクセスできません。

スケーラビリティとフォールト トレランスを実現するために、各 Active Directory® ディレクトリ サービス サイトに少なくとも 2 台のグローバル カタログ サーバーを構成することをお勧めします。サイトが複数のドメインにまたがる場合は、Exchange 2000 Server コンピュータ、Exchange Server 2003 コンピュータ、または Exchange Server 2007 コンピュータ、およびクライアントが存在するドメインごとにグローバル カタログを構成することをお勧めします。また、Exchange Server コンピュータのプロセッサ 4 個ごとに 1 台のグローバル カタログ サーバーを展開することをお勧めします。

追加のグローバル カタログ サーバーを作成する方法の詳細については、Microsoft サポート技術情報の文書番号 313994「[HOWTO] Windows 2000 でグローバル カタログの作成または移動を行う方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313994) を参照してください。

Exchange Server に関連したグローバル カタログ サーバーの配置と可用性の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 875427「グローバル カタログ サーバー位置と Exchange 2000 Server 組織または Exchange Server 2003 組織に率」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=875427)

  • 文書番号 322801「[XADM] Exchange System Attendant が開始されず、"グローバル カタログ サーバーから応答がありません" というエラー メッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322801)

  • 文書番号 829361「シャットダウンに下に長い Exchange Server 2003 コンピュータ取るが必要であることを超える Exchange Server 2003 コンピュータ取る」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829361)

  • 文書番号 304403「XADM: Exchange Considerations for Promoting a Domain Controller to a Global Catalog Server」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=304403) (このサイトは英語の場合があります)

  • 文書番号 305065「[XADM] グローバル カタログ サーバーをドメイン コントローラに降格する際の Exchange Server 関連の考慮点」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=305065)


サイト フォルダ サーバーが削除されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各管理グループ オブジェクトの siteFolderServer 属性の値を判断します。siteFolderServer 属性の値に "DEL:" という文字列が含まれていることが検出されると、エラーが表示されます。

siteFolderServer 属性は、サイト フォルダをホストする役割を持つパブリック フォルダ ストアの識別名 (DN) を表します (通常は、サイトまたは管理グループ内の最初のサーバー)。

既定では、サイト フォルダ サーバーは管理グループ内にインストールされている最初のサーバーです。このサーバーのパブリック フォルダ ストアは、その管理グループ用の Free/Busy フォルダとオフライン アドレス帳フォルダの既定の場所になります。これらのフォルダを別のサーバーにレプリケートしないでこのサーバーを削除するか使用を停止し、そのサーバーをオフライン アドレス帳サーバーとして指定すると、Microsoft Office Outlook® 2003 のユーザーにオフライン アドレス帳や空き時間情報データに関する問題が発生します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. Configuration コンテナで以下のノードを順に展開し、サイト フォルダ サーバーとして指定するパブリック フォルダ インフォメーション ストアを見つけます。

    [CN=Configuration,DC=<ドメイン名>,DC=com]、[CN=Services]、[CN=Microsoft Exchange]、[CN=<組織名>]、[CN=Administrative Groups]、[CN=<管理グループ名>]、[CN=Servers]、[CN=<サーバー名>]、[CN=InformationStore]、CN=<ストレージ グループ名>]

  3. 右側のペインで、[CN=<パブリック フォルダ ストア名>] を右クリックし、[プロパティ] を選択します。

  4. [Attributes] 一覧で、下にスクロールして distinguishedName 属性をクリックします。

  5. [Edit] をクリックし、属性全体をクリップボードにコピーします。

  6. [Configuration] コンテナを展開し、[CN=Configuration,CN=<ドメイン名>,CN=com]、[CN=Services]、[CN=Microsoft Exchange]、[CN=<組織名>]、[CN=Administrative Groups] の順に展開します。

  7. 変更する管理グループを右クリックし、[プロパティ] をクリックします。

  8. [Attributes] 一覧で、下にスクロールして siteFolderServer 属性をクリックします。

  9. [Edit] をクリックし、distinguishedName 属性の値を [Value] ボックスに貼り付けます。

  10. [Value] ボックスの内容をダブルクリックして貼り付けが正しく実行されたことを確認し、[OK] をクリックして変更を保存します。

  11. [OK] をクリックして、管理グループのプロパティを閉じます。

  12. Active Directory エディタを終了し、サイト内のすべての Exchange Server 上にある Microsoft Exchange Server Information Store サービスを再開して、変更を有効にします。

システム フォルダの再作成とサイト フォルダ サーバーの再設定の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822444「[HOWTO] Exchange Server 2003 でサイト フォルダをリセットする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822444)

  • 文書番号 275171「[XADM] Exchange 2000 Server でシステム フォルダをリセットする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=275171)

  • 文書番号 284200「[XADM] Schedule+ Free/Busy システム フォルダが削除される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=284200)

LDP ツールの使用に関する詳細については、サポート技術情報の文書番号 260745「[XADM]: LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の使用に関する詳細については、Windows Server ヘルプのトピック「Adsiedit.msc: ADSI Edit」(英語) を参照してください。


Active Directory ディレクトリ サービスの呼び出しが遅い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-14

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルを調べて、応答時間が 2.5 秒を超える Active Directory® ディレクトリ サービス コンポーネントのイベントはないか調べます。

Exchange FCL Active Directory コンポーネント イベントは、Active Directory コンポーネントへの Microsoft Exchange Information Store サービス (Store.exe) 関数呼び出しです。

Active Directory は、メールボックス情報、アドレス一覧サービス、およびその他の受信関連情報のすべてを提供します。Exchange Server 2003 の構成情報の大部分も Active Directory に格納されます。

Exchange Server サービスは、Active Directory に格納された情報にアクセスし、Active Directory に情報を書き込みます。

Exchange Server アナライザによって、FCL ファイル内のイベントの応答時間が、Microsoft Exchange Information Store サービス (Store.exe) からの Active Directory の関数呼び出しで 2.5 秒を超えていることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

Active Directory に対する Microsoft Exchange Information Store サービスからの 2.5 秒を超える呼び出しは、以下の状況で生じることがあります。

  • Exchange サーバーとドメイン コントローラ間のネットワーク待ち時間。

  • DSAccess が静的または不適切に構成されている。

  • ドメイン コントローラおよびグローバル カタログの負荷が高すぎる。

  • Active Directory トポロジが不適切に設計されている。

このエラーを解決するには、次の操作を行います。

  • Exchange Server アナライザを実行して、サーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • Active Directory ドメイン コントローラ サーバーのパフォーマンスを確認します。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange のパフォーマンスおよび DSAccess の詳細については、Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=250570) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。

ドメイン コントローラのパフォーマンスの詳細については、以下の Windows Server リソースを参照してください。

  • 「Planning Domain Controller Capacity」(http://go.microsoft.com/fwlink/?LinkId=70191) (このサイトは英語の場合があります)

  • Windows 2000 Server の Active Directory の計画および展開に関するガイドの Active Directory のドメイン コントローラの監視に関する記事 (http://go.microsoft.com/fwlink/?LinkId=70193)


ESE の呼び出しが遅い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルを調べて、応答時間が 2.5 秒を超える Exchange Extensible Storage Engine (ESE) コンポーネントのイベントがないか調べます。

Exchange FCL ESE コンポーネント イベントは、ESE コンポーネントへの Microsoft Exchange Information Store サービス (Store.exe) 関数呼び出しです。

Exchange Information Store は ESE データベースに基づきます。ESE は、トランザクション ベースの高度なデータベース エンジンです。トランザクションとは、アトミック (それ以上分割できない) 単位として扱われる一連の操作です。トランザクション内のすべての操作が実行されて完全に保存されるか、いずれの操作も実行されないかのどちらかです。

Exchange Server は、データベースの構造を決定し、メモリを管理する埋め込みデータベース エンジンとして ESE を使用します。このデータベース エンジンでは、4 キロバイト (KB) のデータのチャンク (ページ) をメモリに転送したり、メモリから転送したりすることによって、データベースをメモリにキャッシュします。メモリ内のページが更新され、新しいページまたは更新されたページがディスクに再度書き込まれます。要求がシステムに送信された際、データベース エンジンはデータをメモリにバッファリングできます。そのため、ディスクに繰り返しアクセスする必要はありません。

メモリへのデータのキャッシュは、最もすばやく効率的にデータを処理する方法ですが、これは Exchange が実行されている間、ディスクの情報が完全には最新のものでないことを意味します。しかし、トランザクション ログ ディスクには、各トランザクションに関する最新の情報が常に維持されます。ただし、メモリ内の多くの変更がまだディスクに保存されていないため、データベースとメモリは同期されていません。

Exchange Server アナライザによって、Store.fcl ファイル内のイベントの応答時間が、Microsoft Exchange Information Store サービス (Store.exe) からの ESE コンポーネントの関数呼び出しで 2.5 秒を超えていることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

ESE からの進行中の呼び出しは、以下の状況で生じることがあります。

  • Exchange のオンライン最適化

  • データ バックアップ

    注 :
    Exchange Call Trace logging の収集時にデータ バックアップまたはオンライン最適化が意図的に処理されていた場合は、Exchange Server のパフォーマンス問題を示すこのメッセージを無視しても問題ありません。
  • データベース ドライブのボトルネック

このエラーを解決するには、次の操作を行います。

  • ベスト プラクティスとして、バックアップ ウィンドウやオンライン保守が、ユーザーの需要が最高の期間と重ならないようにすることをお勧めします。

  • Exchange Server アナライザを実行して、サーバーをさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

オンライン最適化の時間ウィンドウを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 244524 の [XADM] Exchange Server のオンライン最適化の時間ウィンドウの構成方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=244524) を参照してください。

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

ESE の詳細については、「Extensible Storage Engine アーキテクチャ」(http://go.microsoft.com/fwlink/?linkid=67009) を参照してください。


IMAIL 呼び出しに時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-12

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、応答時間が 2.5 秒を超える MAPI クライアントの IMAIL コンポーネントのイベントを調べます。

Exchange FCL IMAIL MAPI コンポーネントのイベントは、インターネット形式にメッセージを変換する、またはインターネット形式から MAPI 形式にメッセージを変換する Microsoft Exchange Information Store サービス (Store.exe) 関数呼び出しを表します。

Exchange Server の IMAIL コンポーネントは柔軟性に富んだ変換サービスで、インターネット メッセージと MAPI メッセージ間で Microsoft Exchange Information Store サービスによって使用されます。これによって、RFC-822 またはインターネット形式を使用するクライアントと、MAPI クライアントや内部ストア タスクなど、Exchange Server の内部ストレージ形式を使用するクライアント間の相互運用性が実現します。

Exchange では IMAIL メカニズムを使用して、Exchange システム マネージャでインターネット ドメインに定義されたメッセージ形式または Microsoft Office Outlook® で各受信者にユーザーが指定したメッセージ形式を内容に適用します。形式パラメータが IMAIL に渡されなかった場合、IMAIL は MAPI メッセージを Summary TNEF (S/TNEF) 形式に変換してサーバー間で転送します。

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントの応答時間が、Microsoft Exchange Information Store サービス (Store.exe) からの MAPI クライアントの IMAIL コンポーネント関数呼び出しで 2.5 秒を超えていることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

IMAIL への Exchange Information Store サービス (Store.exe) 関数呼び出しの応答時間が長い場合は、以下の状況が原因となっている可能性があります。

  • IMAIL がメッセージまたは添付ファイル内の大量のデータを処理しようとする。

  • 多数のクライアントがデータ変換を要求する。

  • DSAccess 要求に対する応答が遅い。

  • TEMP および TMP ドライブにボトルネックがある。

  • メールボックスの移動が進行中である。

  • このエラーを解決するには、次の操作を行います。

  • 需要がピークでない時間帯にメールボックスの移動をスケジュールします。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) でダウンロードできます (このサイトは英語の場合があります)。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Exchange Server のディスクのボトルネックに関する問題の詳細については、「ディスクのボトルネックが検出された」を参照してください。

Exchange Server のディスクのサイジングと最適化の方法の詳細については、『Exchange Server 2003 の記憶域の最適化』(http://go.microsoft.com/fwlink/?linkid=49324) の「ディスク I/O の要件を計算する方法」と「複数のアーキテクチャに共通のベスト プラクティス」を参照してください。

Exchange Server のメッセージ サイズの制限に関するベスト プラクティスの詳細については、「送信メッセージの最大サイズが設定されていない」を参照してください。


LSASS の呼び出しが遅い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL)、Store.fcl ファイルで、応答時間が 25 ミリ秒を超えるローカル セキュリティ認証サーバー (Lsass.exe) プロセスのコンポーネント イベントを調べます。

Exchange FCL LSASS プロセスのコンポーネント イベントは、ローカル セキュリティ認証サーバー (Lsass.exe) プロセス コンポーネントに対する Microsoft Exchange Information Store サービス (Store.exe) の関数呼び出しを表します。

ローカル セキュリティ認証サーバー プロセス (Lsass.exe) は、アカウント情報の確認とログオンの検証のために他のプロセスによって起動されるセキュリティ サブシステムです。

Exchange のクライアント ログオンが行われるたびに、Exchange Server を実行するサーバーはクライアントのアカウント セキュリティ識別子 (SID) を参照する要求を送信し、ローカル セキュリティ認証サーバー (Lsass.exe) プロセス内で呼び出しを生成します。

Exchange Server アナライザが Store.fcl ログ ファイルで、Microsoft Exchange Information Store サービス (Store.exe) からのローカル セキュリティ認証サーバー (Lsass.exe) コンポーネントの関数呼び出しに対する応答時間が 25 ミリ秒を超えることを示すイベントを検出すると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

LSASS に対する Microsoft Exchange Information Store サービス (Store.exe) の関数呼び出しの応答時間の遅延原因として、以下の状況が考えられます。

  • 同時に認証を実行するユーザー数に関するサーバー リソースの問題

  • Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間

  • サーバー リソースのボトルネックの問題

このエラーを解決するには、次の操作を行います。

  • 「'NeverPing' パラメータで推奨メッセージが表示される」の説明に従った NeverPing パラメータの実装を検討します。

  • Exchange Server アナライザを実行して、メッセージや添付ファイルのサイズ制限などのサーバーの問題をさらに分析します。Exchange Server アナライザは、Microsoft Exchange Server ベスト プラクティス アナライザ ツール Version 2.7 のページ (http://go.microsoft.com/fwlink/?LinkId=34705) (英語) でダウンロードできます。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Lsass.exe プロセスおよびメモリ使用量の詳細については、Microsoft サポート技術情報の文書番号 308356 の、Windows Server 2003 または Windows 2000 Server ベースのドメイン コントローラ上の Lsass.exe プロセスによるメモリの使用量についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=308356) を参照してください。

Exchange のクライアント ログオン、および LSASS の問題の詳細については、Microsoft サポート技術情報の文書番号 161938 の、リソースデッドロックで Exchange クライアントのログオンが遅い現象についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=161938) を参照してください。

Exchange サーバーとドメイン コントローラまたはグローバル カタログ サーバー間のネットワーク待ち時間の詳細については、Exchange でローカルのグローバル カタログが使用されない件についての Exchange Server チームのブログ記事 (http://go.microsoft.com/fwlink/?LinkId=69166) (英語) を参照してください。

注 :
それぞれのブログの内容およびその URL は、通知なしに変更される場合があります。

サーバー リソースのボトルネックの問題の詳細については、「プロセッサのボトルネック」を参照してください。

Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 パフォーマンスとスケーラビリティ ガイドに関するページ (http://go.microsoft.com/fwlink/?LinkId=47576) (英語) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) (英語) を参照してください。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725 の、Information Store のトラブルシューティングを行うために診断データを収集する方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) (英語) を参照してください。


ウイルス スキャン ソフトウェアの呼び出しが遅い
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-11

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルを調べて、応答時間が 2.5 秒を超える Virusscan Virus API (VAPI) コンポーネントのイベントはないか調べます。

Exchange FCL Virusscan VAPI コンポーネント イベントは、外部のウイルス スキャン ソフトウェアへの Microsoft Exchange Information Store サービス (Store.exe) 関数呼び出しを表します。

VAPI のトラブルシューティングを強化するために、Exchange Server にはウイルス スキャン API のパフォーマンスの追跡に使用できるイベント ログを実装しています。

次のイベントがログに記録されます。

  • ベンダの DLL のロードおよびアンロード

  • 正常に実行されたアイテムのスキャン

  • インフォメーション ストアで検出したウイルス

  • VAPI での予測外の動作

Exchange Server アナライザによって、Store.fcl ログ ファイル内のイベントの応答時間が、Microsoft Exchange Information Store サービス (Store.exe) からの外部ウイルス スキャン ソフトウェアの関数呼び出しで 2.5 秒を超えていることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

ウイルス スキャン ソフトウェアに対する Microsoft Exchange Information Store サービス (Store.exe) の外部関数呼び出しの応答時間の遅延原因として、以下の状況が考えられます。

  • ウイルス スキャン ソフトウェアに対する更新によって、インフォメーション ストアの項目が再スキャンされる

  • ウイルス スキャン ソフトウェアが不適切に構成されている

  • ウイルス スキャン ソフトウェアが処理するメッセージまたは添付ファイルのサイズが大きい

このエラーを解決するには、次の操作を行います。

  • リソースの消費が少ないとき、つまり需要がピークでない時間帯にウイルス エンジンの更新をスケジュールします。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。ただし、再インストールは需要がピークでない時間帯に実行します。

  • ウイルス スキャン エンジンの構成を調べ、スレッドの構成、ファイル レベルの除外などが適正であることを確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • このドキュメントの「詳細情報」セクションに記載されている文書を確認します。

詳細情報

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

Exchange Server のパフォーマンスの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

インフォメーション ストアのパフォーマンスのトラブルシューティング方法の詳細については、Microsoft サポート技術情報の文書番号 257725「XADM:How to Collect Diagnostic Data for Information Store Troubleshooting」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725) を参照してください (このサイトは英語の場合があります)。


VSS スナップショット呼び出しに時間がかかる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-13

Microsoft® Exchange Server アナライザ ツールは、Exchange 関数呼び出しログ (FCL) である Store.fcl ファイルで、応答時間が 20 秒を超えるボリューム シャドウ コピー サービス (VSS) スナップショット コンポーネントのイベントを調べます。

Exchange FCL VSS コンポーネントのイベントは、VSS スナップショット コンポーネントへの Microsoft Exchange Information Store サービス (Store.exe) 関数呼び出しを表します。

VSS は、システム上のアプリケーションがボリュームへの書き込みを続けているときに、ボリューム バックアップを実行するためのフレームワークを実装する COM API のセットです。

Microsoft Exchange Server 2003 では、Microsoft Windows Server™ 2003 オペレーティング システムに組み込まれている VSS を使用して、Exchange Server 2003 データベースおよびトランザクション ログ ファイルのボリューム シャドウ コピーを取得します。

VSS スナップショットは、元のデータから完全に独立しているわけではありません。通常、スナップショットは、特定の時点にデータをロールバックできるように、その時点にあらかじめマーカーを定義した場合に作成されます。

Exchange Server アナライザによって、Store.fcl ファイル内のイベントの応答時間が、Microsoft Exchange Information Store サービス (Store.exe) からの VSS スナップショット コンポーネント関数呼び出しで 20 秒を超えていることが検出されると、エラーが表示されます。

Microsoft Exchange Information Store サービス (Store.exe) からのコンポーネント間呼び出しが応答を待機している際には、これらの要求の背後でリモート プロシージャ コール (RPC) スレッドが停滞し、クライアントへのサーバーの応答が遅延するなど、Exchange Server でパフォーマンスの問題が生じることがあります。

注 :
Exchange Call Trace logging の収集の 20 秒以内に VSS スナップショットが意図的に開始された場合は、Exchange Server のパフォーマンス問題を示すこのエラー メッセージを無視しても問題ありません。

ベスト プラクティスとして、バックアップ ウィンドウがオンライン保守やユーザーの需要が最高の期間と重ならないようにすることをお勧めします。

詳細情報

VSS の詳細については、Exchange Server 2003 でボリューム シャドウ コピー サービスを使用する際のベスト プラクティスについてのページ (http://go.microsoft.com/fwlink/?LinkId=56571) を参照してください (このサイトは英語の場合があります)。


'SMTPSVC' エラー イベント (ID: 429) が過去 24 時間以内にログに記録されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange Server アナライザ ツールは、IIS メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの各インスタンスの LM/SmtpSvc/%SMTPInstance%/ServerState プロパティの値を判断します。

ServerState プロパティは、サーバー インスタンスの現在の状態を示します。この状態とそれに対応する状態コードは次のとおりです。1 (開始中)、2 (開始)、3 (停止中)、4 (停止)、5 (一時停止中)、6 (一時停止)、または 7 (続行中)。

SMTP 仮想サーバー インスタンスの ServerState プロパティの値が 2 (開始) ではないことが検出された場合、Exchange アナライザは Win32_NTLogEvent WMI (Microsoft Windows Management Instrumentation) クラスに対してクエリを実行し、過去 24 時間以内に SMTP サービス (SMTPSVC) についてイベント 429 エラーがログに記録されているかどうかを調べます。

SMTP 仮想サーバー インスタンス (VSI) が開始されておらず、過去 24 時間以内に少なくとも 1 つのイベント 429 エラーがログに記録されていることが検出されると、警告が表示されます。

この警告は、SMTP 仮想サーバー インスタンスに指定されているディレクトリに問題が発生している可能性があることを示しています。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。

この問題は、以下のいずれかの原因で発生することがあります。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パス、またはそのディレクトリ パスの下にあるフォルダが移動された、存在しない、または破損している。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パス、またはそのディレクトリ パスの下にあるフォルダへのアクセス許可が適切に設定されていない。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パス、またはそのディレクトリ パスの下にあるフォルダを、ウイルス対策ソフトウェアがスキャンしている。

この警告に対処するには、次のいずれかの操作を行います。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パス、およびそのディレクトリ パスの下にあるフォルダの場所と整合性を確認します。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パス、およびそのディレクトリ パスの下にあるフォルダへのアクセス許可を確認します。

  • <ドライブ>:\Program Files\Exchsrvr\Mailroot ディレクトリ パスを、ウイルス対策ソフトウェアがスキャンしていないことを確認します。

Exchange Server 2003 の Mailroot ディレクトリ パスを確認するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、目的の Exchange サーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[停止] をクリックします。

  4. SMTP 仮想サーバーをもう一度右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブをクリックします。

  6. [キュー ディレクトリ] ボックスで、Mailroot フォルダの完全なパスが適切であるかどうかを確認します。[参照] をクリックするとローカル コンピュータのパスを参照できます。

  7. [OK] をクリックして変更を保存します。

  8. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。
Exchange 2000 Server の Mailroot ディレクトリ パスを確認するには、次の操作を行います。

  1. 確認する SMTP 仮想サーバーの Mailroot フォルダがある Exchange 2000 Server で、Exchange Server および IIS のサービスをすべて停止します。

  2. 対象の SMTP 仮想サーバーの msExchSmtpQueueDirectory の値が、適切なパスで構成されているかどうかを確認します。

  3. この Exchange サーバーが使用するグローバル カタログ サーバーに、Active Directory によってこの変更がレプリケートされるまで待機します。

  4. Microsoft Exchange System Attendant サービスを開始します。

  5. Exchange Server コンピュータのアプリケーション イベント ログで、イベント ソースが MSExchangeMU でカテゴリが General であるイベント ID 1005 のインスタンスが 3 つ存在するかどうかを確認します。

  6. Exchange Server コンピュータを再起動して変更を有効にします。
Exchange 2000 Server および Exchange Server 2003 で、Mailroot ディレクトリ パスの既定のアクセス許可を確認するには、次の操作を行います。

  1. Windows エクスプローラを起動し、Exchsvr フォルダに移動して、このフォルダを展開します。

  2. Mailroot フォルダを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、以下の既定のアクセス許可を確認します。

アカウント | アクセス許可
Administrators | フル コントロール
Authenticated Users | 読み取りと実行、フォルダの内容の一覧表示、読み取り
Creator Owner | なし
Server Operators | 変更、読み取りと実行、フォルダの内容の一覧表示、読み取り、書き込み
System | フル コントロール
  1. 各仮想サーバー インスタンスのすべてのフォルダで、これらの既定のアクセス許可が設定されていることを確認します。

ここで説明した手順の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822933)

  • 文書番号 318230「[XCON] Exchange 2000 SMTP Mailroot ディレクトリの場所を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=318230)

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

ウイルス対策ソフトウェアを Exchange での使用に合わせて構成する方法の詳細については、「ウイルス対策のフォルダの除外が構成されていない」を参照してください。

Symantec AntiVirus Corporate Edition のリアルタイム スキャンで除外を構成する方法の詳細については、Symantec のウイルス対策 Web サイト (http://www.symantec.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange Server 環境を強化する方法の詳細については、Exchange 環境を電子メールによるウイルス感染から守るための指針についてのページ (http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサード パーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server 2007 パートナーのウイルスおよびスパム対策ソフトウェアについてのページ (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


SMTP インスタンスの完全修飾ドメイン名がサーバー名と一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバー オブジェクトの networkAddress 属性の文字列 ncacn_ip_tcp: の値が、簡易メール転送プロトコル (SMTP) 仮想サーバー オブジェクトの msExchSmtpFullyQualifiedDomainName 属性にある完全修飾ドメイン名 (FQDN) と一致するかどうかを判別します。

Exchange Server アナライザが、これらの属性の値が一致していないと判定すると、警告が表示されます。

この警告は、これらの属性の値が手動で変更されている可能性があること、およびこのサーバー上でのメール フローの問題の原因になる可能性があることを示します。

msExchSmtpFullyQualifiedDomainName 属性の値は、SMTP 仮想サーバーの FQDN を指定し、ドメイン ネーム システム (DNS) ネットワーク プロトコルで解決可能である必要があります。

SMTP 仮想サーバーの FQDN の解決を試行するメッセージング サーバーで正しい IP アドレスを取得してメールを正しく転送するには、この属性の値には有効な DNS HOST (A) レコードの存在が必要です。

Exchange の DNS 逆引き参照機能の詳細については、「ゾーンにリソース レコードを追加する」(http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の記事を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

SMTP サービスの設計の詳細については、『Exchange Server 2003 テクニカル リファレンス ガイド』の「SMTP サービスの設計」(http://go.microsoft.com/fwlink/?LinkId=58876) を参照してください。


SMTP Local Queue Length がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Local Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Local Queue Length カウンタがピーク値の 1000 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

SMTP Server\Local Queue Length カウンタは、Microsoft Exchange Information Store サービスへのローカル配信のために SMTP (Simple Mail Transfer Protocol) キュー内のメッセージ数を示します。SMTP ローカル キュー データ (Mailroot ディレクトリ) は、Exchange Server によって処理されている間は一時的に記憶装置に保持されます。この設計によって、サーバーに障害が発生した場合のデータの損失を防ぎます。たとえば、目的のサーバーに到達できない場合、そのサーバーにルーティングされる必要のあるメッセージは、配信可能になるまでローカル サーバーのキュー ディレクトリに格納されます。

このエラーは、サーバーが受信メールを適切な時間内に配信できないために起こるパフォーマンスの問題やサーバー上での停止を示します。以下の状況によってこの遅延が発生する可能性があります。

  • Active Directory® ディレクトリ サービスが直ちに参照されていない。

  • メッセージがローカル配信または SMTP に直ちに渡されていない。

  • データベース (メールボックス ストアおよびパブリック フォルダ ストア) のマウントが解除されている。

  • この問題を解決するには、次の操作を行います。

  • すべてのデータベース (メールボックス ストアおよびパブリック フォルダ ストア) がマウントされていることを確認します。

  • パフォーマンスのボトルネックの原因を突き止めます。パフォーマンスのボトルネックは、CPU、ディスク、ネットワーク、またはメモリに関連する場合があり、サーバーに対する負荷の増大、またはサーバーのリソース不足が原因で発生します。パフォーマンス モニタ (Perfmon.msc) ツールを使用して、ボトルネックがサーバーの負荷の増大によって発生しているのか、サーバーのサイズが小さいために発生しているのかを判断します。サーバーの負荷が増大している場合は、原因を突き止めて負荷を減らします。サーバーのリソースが不十分な場合は、必要なリソースを増やすか、ユーザーをサーバーから移動します。

  • パフォーマンスの問題に対して Active Directory ディレクトリ サービスなどの外部の依存関係を監視し、必要に応じてトラブルシューティングおよび修正を行います。

詳細情報

  • SMTP トランスポートのチューニングの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) の SMTP トランスポートのチューニングに関するセクションを参照してください (このサイトは英語の場合があります)。

  • メール フローの問題をトラブルシューティングする方法の詳細については、Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489) を参照してください。

  • トランスポート問題のトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265) を参照してください。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • ディスクのボトルネックの詳細については、「ディスクのボトルネックが検出された」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


SMTP Server パフォーマンス モニタ オブジェクトを使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Local Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。このカウンタから有効なデータが返されない場合、Exchange Server アナライザはベースライン メッセージを表示します。

パフォーマンス データ収集エンジンによって有効なデータが返されない場合、次の状況のいくつかが当てはまります。

  • SMTP Server パフォーマンス オブジェクトが無効になっている。

  • SMTP Server パフォーマンス モニタ オブジェクトが存在しないか、または破損している。

  • Exchange Server アナライザに、パフォーマンス オブジェクトにアクセスするための適切なアクセス許可が与えられていない。

最初の 2 つの状況は、特定の拡張カウンタによってレジストリが壊れた場合、または Microsoft WMI (Windows® Management Instrumentation) に基づくプログラムによってレジストリが変更された場合に発生する可能性があります。以下の手順は、最初の 2 つの状況を修復する方法について説明しています。この手順を実行する前に、Exchange Server アナライザに適切なアクセス許可が与えられていることを確認してください。Exchange Server アナライザの実行に必要なアクセス許可の詳細については、Exchange Server アナライザに含まれているヘルプ ドキュメントを参照してください。ヘルプを参照するには、Exchange Server アナライザを開き、F1 キーを押します。

このエラーを修正するには

  1. SMTP Server パフォーマンス オブジェクトが有効になっていることを確認します。

    1. Extensible Performance Counter List ツール (Exctrlst.exe) をダウンロードし、インストールします。Exctrlst.exe は、「Exctrlst.exe: Extensible Performance Counter List」Web サイト (http://go.microsoft.com/fwlink/?LinkId=34436) からダウンロードできます (このサイトは英語の場合があります)。

    2. Exctrlst.exe を開き、[Sort Order] をクリックします。次に、[Service] をクリックします。

    3. パフォーマンス オブジェクトが報告するサービスに移動し、[Performance Counters Enabled] チェック ボックスがオンになっていることを確認します。

      [Performance Counters Enabled] チェック ボックスがオフになっている場合はオンにし、パフォーマンス カウンタと関連付けられているサービスを再開して、パフォーマンス カウンタが機能していることを確認します。パフォーマンス カウンタが機能していない場合、または [Performance Counters Enabled] チェック ボックスが既にオンの場合は、手順 2. に進みます。

  2. 足りないパフォーマンス カウンタまたは壊れたパフォーマンス カウンタを再構築します。パフォーマンス カウンタを再構築する方法については、Microsoft サポート技術情報の文書番号 300956「パフォーマンス カウンタ ライブラリの値を手動で修正する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=300956) を参照してください。

  3. この Microsoft サポート技術情報の文書によって問題が解決されない場合は、Windows オペレーティング システムを修復モードで再インストールしてから、最新の Windows Service Pack を適用する必要があります。


Exchange Server がゲストとしてインストールされた Virtual Server 2005 が SQL Server で実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が Virtual Machine に設定されているかどうかを判断します。

さらに、次のレジストリ値の有無も確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

また、Win32_Services WMI クラスに対してもクエリを実行し、Microsoft Virtual Server 2005 を実行している物理コンピュータ上で Microsoft SQL Server™ サービス (MSSQLSERVER) が実行されているかどうかを判断します。

Model キーに文字列 "Virtual Machine" が含まれていること、上記のレジストリ ブランチが存在すること、および MSSQLSERVER が実行されていることが検出されると、エラーが表示されます。

Model キーの値が Virtual Machine の場合、Virtual Server 2005 または Microsoft Virtual PC 2004 いずれかの仮想コンピュータ上で、Exchange Server コンピュータがゲストとして実行されていることを示します。上記のレジストリ ブランチを作成するのは Virtual Server 2005 だけなので、このブランチが存在すれば、Exchange Server コンピュータは Virtual Server 2005 のゲスト仮想コンピュータとして実行されていることになります。

Microsoft では、バージョンに関係なく、仮想マシンまたはエミュレータでの Microsoft Exchange の実行をサポートしていません。この点は、Microsoft Virtual Server 2005、Microsoft Virtual PC 2004、またはその他の任意のサードパーティー製仮想マシン プログラム上で実行される Exchange Server にも当てはまります。Microsoft Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Calatog」(http://go.microsoft.com/fwlink/?linkid=17219) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています (このサイトは英語の場合があります)。

さらに、SQL Server が実行されているコンピュータ上で仮想サーバーのゲストとして Exchange を実行すると、サービス全体にわたる適切な冗長性を確保できないため、この方法はベスト プラクティスとは言えません。

このエラーを修正するには

  1. メールボックスを、Vitual Server 2005 環境下で実行している Exchange Server から、仮想 Exchange Server コンピュータ以外のコンピュータに移動します。

  2. 必要に応じて、パブリック フォルダを再格納し、仮想 Exchange サーバーが保持していた役割を転送します。

  3. Exchange を仮想コンピュータからアンインストールして、その Exchange の使用を停止し、Exchange インフラストラクチャおよび Active Directory® ディレクトリ サービスから削除します。

メールボックスの移動の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

仮想環境で実行される Exchange Server コンピュータに対するサポートの詳細については、Microsoft サポート技術情報の文書 320220「Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual Server 2005 の詳細については、Microsoft Virtual Server 2005 Web サイト (http://go.microsoft.com/fwlink/?linkid=34938) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual PC 2004 の詳細については、Microsoft Virtual PC 2004 Web サイト (http://go.microsoft.com/fwlink/?linkid=34663) を参照してください (このサイトは英語の場合があります)。


SRS port is below 5000
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Site Replication サービスの TCP/IP の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

TCP/IP が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

TCP/IP を静的な値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。5,000 未満の静的なポート番号を割り当てると、ポートが別のプロセスと競合して、Microsoft Exchange Site Replication サービス プロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP レジストリ キーを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. [TCP/IP] キーをダブルクリックし、[値のデータ] を 5,000 (10 進数) を超える整数に設定します。

  4. レジストリ エディタを終了します。

  5. Microsoft Exchange Site Replication サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ポートの制限の詳細については、Microsoft サポート技術情報の文書番号 194952「[XADM] Exchange Server の静的に割り当てられるポートの制限」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=194952) を参照してください。


SRS ポートが手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Site Replication サービスのポートの値が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS\Parameters\TCP/IP

TCP/IP が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook® 2003 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。これはサポートされている構成です。MAPI クライアントがファイアウォール経由で Exchange に接続できるように構成する方法の詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。このシナリオを使用しない場合、レジストリ キーを削除する必要があります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、および Microsoft Windows® XP Professional にある RPC over HTTP 機能を使用することをお勧めします。MAPI モードは、以前は "企業" または "ワークグループ" モードと呼ばれていました。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP レジストリ エントリを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSRS\Parameters

  3. TCP/IP というレジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Site Replication サービスを再起動します。

RPC over HTTP を展開するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  3. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  4. Microsoft Support Web Cast「[OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


システム アテンダント用に構成された開始アカウントがサポートされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Services Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange System Attendant サービス (MSExchangeSA) の StartName プロパティで指定されている開始アカウントが LocalSystem アカウントを使用しているかどうかを判断します。Exchange 2000 Server または Exchange Server 2003 コンピュータで StartName プロパティの値が LocalSystem 以外のアカウントであることが検出されると、エラーが表示されます。LocalSystem アカウントは、SYSTEM アカウントとも呼ばれます。

Exchange 2000 Server および Exchange Server 2003 では、MSExchangeSA を LocalSystem セキュリティ コンテキストで開始する必要があります。MSExchangeSA を特定のユーザー アカウントに関連付けて開始することはできません。LocalSystem として実行されている Exchange サービスがリモート サーバーにアクセスすると、その Exchange サービスはコンピュータ アカウントの資格情報を使用して認証されます。

標準のパスワード変更機構では、コンピュータ アカウントのパスワードは 7 日ごとに変更されます。パスワードを 7 日ごとに変更することにより、コンピュータ アカウントのセキュリティが強化されます。コンピュータ アカウントは、次の理由で一般のユーザー アカウントよりセキュリティが強化されています。

  • 一般のユーザー アカウントのパスワードは、コンピュータ アカウントほど頻繁に変更されません。

  • 一般のユーザー アカウントのパスワードは、ランダムに生成されるコンピュータ アカウントのパスワードほどにランダムではありません。

Exchange Server 5.5 では、サービスにユーザー アカウントが使用されます。Exchange Server 5.5 の使用経験がある一部の管理者は、Exchange 2000 Server サービスや Exchange Server 2003 サービスの開始アカウントを、既定の LocalSystem アカウントからユーザー アカウントに変更しています。

Exchange 2000 Server および Exchange Server 2003 では、MSExchangeSA を既定の LocalSystem アカウント以外のアカウントで実行することはサポートされていません。

このエラーを修正するには

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[管理ツール] をポイントし、[サービス] をクリックします。

  2. サービスの一覧の [Microsoft Exchange System Attendant] を右クリックし、[プロパティ] をクリックします。

  3. [ログオン] タブで、[ログオン] の下の [ローカル システム アカウント] をクリックし、[OK] をクリックします。

  4. [Microsoft Exchange System Attendant] を右クリックし、[再起動] をクリックします。

Exchange サービスの詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」( http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


STORE.EXE ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次に挙げる Exchange のコア バイナリ ファイルが存在するかどうかを判断します。

  • Exres.dll

  • Gapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapi32.dll (System32 フォルダおよび \Exchsrvr\bin フォルダで確認)

  • Mapisp32.dll

  • Mapistub.dll

  • Cdo.dll

  • DavEx.dll

  • DSAccess.dll

  • EmsMta.exe

  • Epoxy.dll

  • Ese.dll

  • Eseutil.exe

  • ExCdo.dll

  • ExchMem.dll

  • ExMime.dll

  • ExOleDb.dll

  • ExPop3.dll

  • ExSmtp.dll

  • Mad.exe

  • Mbdsz.dll

  • OabGen.dll

  • PhatCat.dll

  • Phatq.dll

  • Reapi.dll

  • ReSvc.dll

  • Store.exe

Exchange Server アナライザによって、上記のファイルが 1 つ以上足りないことが検出されると、エラーが表示されます。このエラーを修正するには、使用している Exchange のバージョンに対応した最新の Service Pack またはロールアップをインストールします。この操作を行っても依然としてエラーが発生する場合は、Exchange 2000 Server または Exchange Server 2003 のセットアップ プログラムを実行し、[再インストール] を選択します。再インストール モードでセットアップ プログラムを実行すると、バイナリ ファイルのみがインストールされます。この場合、ユーザー データや構成データの削除やリセットは行われません。Exchange Server を再インストールする際は、既にインストールされている Exchange Service Pack や修正プログラムも再インストールする必要があります。

Exchange 2000 Server または Exchange Server 2003 を再インストールするには

  1. Exchange を再インストールするサーバーにログオンします。CD-ROM ドライブに Exchange 2000 Server または Exchange Server 2003 の CD-ROM を挿入します。

  2. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「<ドライブ>:\setup\i386\setup」と入力します。ここで <ドライブ> は CD-ROM ドライブ文字です。

  3. [Microsoft Exchange インストール ウィザードへようこそ] ページで、[次へ] をクリックします。

  4. [使用許諾契約書] ページで、使用許諾契約書を読みます。条件に同意する場合は、[同意します] をクリックし、[次へ] をクリックします。

  5. [プロダクト ID] ページで 25 桁のプロダクト キーを入力し、[次へ] をクリックします。

  6. [コンポーネントの選択] ページで、[アクション] 列の [Microsoft Exchange] ノードの横にあるドロップダウン メニューの矢印をクリックし、メニューの [再インストール] をクリックします。次に、[次へ] をクリックします。

最新の Exchange Server 2003 Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=25097) を参照してください (このサイトは英語の場合があります)。

最新の Exchange 2000 Server Service Pack、更新プログラムのロールアップ、およびアドインの詳細については、「Downloads for Exchange 2000 Server」Web サイト(http://go.microsoft.com/fwlink/?LinkId=33457) を参照してください (このサイトは英語の場合があります)。


ストアの HTTP ポートの値が 5,000 未満である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Information Store サービスの Rpc/HTTP Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

Rpc/HTTP Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

Rpc/HTTP Port レジストリ キーは、Exchange Server 2003 および Exchange Server 2007 のセットアップ プログラムによって 6001 に設定されます。Rpc/HTTP Port レジストリ キーは、Microsoft Office Outlook® 2003 および Microsoft Office Outlook 2007 用の RPC over HTTP 機能をサポートするために使用されます。

Microsoft コンサルティング サービスの支援を受けて、または Microsoft 製品サポート サービスからの指示によって RPC over HTTP 展開をカスタマイズしている場合を除き、RPC over HTTP は既定のポートの値で展開することをお勧めします。

Rpc/HTTP Port を 6,001 以外の値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。5,000 未満の静的なポート番号を割り当てると、ポートが別のプロセスと競合して、Microsoft Exchange Information Store サービス プロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP Port レジストリを既定値に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

  3. Rpc/HTTP Port キーをダブルクリックし、[値のデータ] ボックスを 6,001 (10 進数)、または 5,000 (10 進数) を超える整数に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


ストア : HTTP ポートが既定値でない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、HTTP Port が既定値に設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc/HTTP Port

Rpc/HTTP Port の値が 6001 (10 進数) ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Rpc/HTTP Port レジストリ キーは、Exchange Server 2003 および Exchange Server 2007 のセットアップ プログラムによって 6001 に設定されます。Rpc/HTTP Port レジストリ キーは、Microsoft Office Outlook® 2003 および Microsoft Office Outlook 2007 用の RPC over HTTP 機能をサポートするために使用されます。

Microsoft コンサルティング サービスの支援を受けて、または Microsoft 製品サポート サービスからの指示によって RPC over HTTP 展開をカスタマイズしている場合を除き、RPC over HTTP は既定のポートの値で展開することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP Port レジストリ キーを既定値に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [Rpc/HTTP Port] キーをダブルクリックし、[値のデータ] ボックスを 6001 (10 進数) に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


メモリ設定が最適でない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-15

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、MSExchangeIS のイベント 9665 エラーが過去 24 時間以内にログに記録されていないかどうかを判断します。

Microsoft Exchange Server 2003 は、ストア プロセスが開始されるとメモリ構成が最適かどうかをチェックします。メモリ設定が最適でない場合、イベント ビューアにイベント 9665 が表示されます。

イベント 9665 が過去 24 時間以内にログに記録されていることが検出されると、イベントのデータ フィールドが読み取られ、次の表に示すフラグのうちどのフラグがイベントに存在しているかが判断されます。

イベント データ フィールド フラグ | 表示される Exchange Server アナライザ警告 | Exchange Server 2003 の問題
0x00000001 | /3GB スイッチが設定されていません | サーバーでは、Microsoft Windows 2000 Advanced Server または Microsoft Windows 2000 Datacenter Server が稼働しており、1 GB 以上の物理メモリが実装されていますが、boot.ini ファイルに /3GB スイッチが設定されていません。
0x00000002 | /Userva スイッチが正しく設定されていません | サーバーでは、Microsoft Windows Server 2003 Standard Edition、Microsoft Windows Server 2003 Enterprise Edition、または Microsoft Windows Server 2003 Datacenter Edition が稼働しており、1 GB 以上の物理メモリが実装され /3GB スイッチが設定されていますが、boot.ini ファイルに /USERVA 設定が存在しません。
0x00000004 | 'SystemPages' を設定する必要があります。 | サーバーでは、Microsoft Windows 2000 Server のいずれかのエディションが稼働しており、レジストリの SystemPages 値が 24000 から 31000 の範囲外に設定されています。
0x00000008 | 'SystemPages' を再設定する必要があります | サーバーでは、Microsoft Windows Server 2003 Standard、Microsoft Windows Server 2003 Enterprise、または Microsoft Windows Server 2003 Datacenter Edition が稼働しており、レジストリの SystemPages 値が 0 以外の値に設定されています。
0x00000010 | HeapDecommitFreeBlockThreshold が正しく設定されていません | サーバーでは、Microsoft Windows 2000 Server または Microsoft Windows Server 2003 のいずれかのエディションが稼働しており、レジストリの HeapDeCommitFreeBlockThreshold 値が 0x00040000 以外の値に設定されています。

イベント 9665 データ フィールドに存在するフラグに応じて、上の表で対応している警告が表示されます。

これらの警告は、Exchange Server メモリが最適な状態に設定されていないことを示しています。

この警告に対処するには、Exchange アナライザの特定の問題について説明している以下の文書の指示に従ってください。

  • Exchange メールボックス サーバーに 1 GB 以上のメモリが搭載されているのに Boot.ini ファイルで /3GB が設定されていない

  • USERVA の設定が正しくない

  • SystemPages の設定値が大きすぎる

  • サーバーで Windows Server 2003 が実行されており、SystemPages の値が 0 になっていない

  • サーバーに 1 GB 以上の物理メモリが実装されているが、HeapDeCommitFreeBlockThreshold が 262,144 に設定されていない

詳細情報

これらの問題の詳細については、マイクロソフト サポート技術情報の文書番号 325044「Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

MSExchangeIS イベント 9665 の詳細については、イベントおよびエラー メッセージ センターのイベント詳細についてのページを参照してください。

  • メールボックス ストア イベント 9665 については、http://go.microsoft.com/fwlink/?LinkId=83210 を参照してください (このサイトは英語の場合があります)。

  • パブリック ストア イベント 9665 については、http://go.microsoft.com/fwlink/?LinkId=83213 を参照してください (このサイトは英語の場合があります)。


クライアントにインストールされているデスクトップ検索が疑わしい
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-05

Microsoft® Exchange Server アナライザ ツールによって、デスクトップ検索エンジンを使用している多くのユーザーがいると判断されました。デスクトップ検索エンジンによって、これらの検索エンジンがパブリック フォルダ ストアのファイル構造をクロールする際のパブリック フォルダに対する大量のトラフィックだけでなく、ユーザーのマウントされたメールボックスに対する多くのリモート プロシージャ コール (RPC) が生成される可能性があります。多くの検索エンジンは、パブリック フォルダがユーザーのパブリック フォルダのお気に入りリストにある場合はそのパブリック フォルダのみをクロールします。そのため、デスクトップ検索でパブリック フォルダ サーバー上の読み込みが参照される場合とされない場合があります。

この問題を回避するための処理には、以下のものが含まれます。

  • スキャナの Microsoft Office Outlook® 機能をユーザーに無効にしてもらうか、スキャンを個人用メールボックスのみに制限する。

  • スキャンがサーバーではなくローカル ワークステーションのみに影響するように、Exchange キャッシュ モードで Outlook を実行する。

  • マイクロソフト サポート技術情報の文書番号 889086 の、Exchange 2000 Server でのパブリック フォルダにアクセスするとき、Windows XP ベースのコンピュータでの予期しない現象が発生する場合がある現象に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=889086) の指示に従って、修正プログラムを取得し、デスクトップ検索のユーザーがアクセスする Exchange Server を実行しているコンピュータの MaxObjsPerMapiSession レジストリ キーを設定します。

デスクトップ検索アプリケーションが特定のユーザーに対する高い負荷の原因かどうかを確認するには、Microsoft Exchange Server User Monitor (ExMon) を使用して検索エンジンが操作する RPC 処理を監視し、十分な時間 (最低 5 分間) のデータを収集します。次に、検索エンジンを削除し、ExMon ツールを再度実行します。RPC の比率が大幅に減る場合は、デスクトップ検索エンジンが負荷上昇の原因であることが確認されたことになります。RPC の平均待ち時間の減少が検出された場合は、高い負荷が RPC の待ち時間の増加する原因であることが確認されたことになります。

注 :
RPC の待ち時間の比率は 1 日を通して大幅に変化します。5 分のテストでは不十分な可能性があるため、時間を増やして測定する必要がある場合があります。

ExMon をダウンロードするには、Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?linkid=54983) を参照してください (このサイトは英語の場合があります)。

詳細情報

  • デスクトップ検索ソフトウェアの詳細については、以下を参照してください。

    • マイクロソフト サポート技術情報の記事 905184 の、Outlook またはその他の MAPI クライアント コンピュータでデスクトップ検索エンジン ソフトウェアが実行されている場合に Exchange 2000 Server および Exchange Server 2003 のパフォーマンスが影響される可能性があることに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184)

    • Microsoft Exchange Team Blog の、クライアントが Exchange メールボックスまたはパブリック フォルダにインデックスを付けるデスクトップ検索エンジンを使用している場合についてのページ (http://go.microsoft.com/fwlink/?LinkId=54475) (英語)

  • Exchange Server のパフォーマンスの詳細については、『Exchange Server 2003 Performance and Scalability Guide』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


SystemPages の設定値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-03-13

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SystemPages の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

SystemPages の値が 50,000 より大きいことが検出されると、警告が表示されます。

Microsoft Windows Server™ 2003 および Microsoft Windows® 2000 Server は、搭載されている物理 RAM の量とは無関係に、4 GB までのメモリ アドレス スペースのアドレスを直接指定することができます。プロセスの観点からは、仮想アドレスのどの要素も物理メモリの特定のバイトを参照することになります。各仮想アドレスを対応する物理アドレスに変換またはマッピングする処理は、仮想メモリ マネージャ (VMM) とプロセッサ メモリ管理ユニット (MMU) によって行われます。VMM は、RAM を固定サイズのページ フレームに分割し、これらのページ フレームに関する情報を格納するシステム ページ テーブル エントリ (PTE) を作成してマッピングを実行します。システム PTE は小容量のカーネル モードのメモリ バッファであり、ディスク I/O サブシステムとネットワークとの通信を行うために使用されます。それぞれの PTE はページ フレームを表し、VMM がページを見つけるための必要な情報を含んでいます。

4 KB のページ サイズを使用する x86 ベースのシステムでは、2 GB のアドレス スペースをマッピングするために必要な PTE の最大数は 524,288 (2 GB ÷ 4 KB) です。/3GB スイッチを使用する同様のシステムでは、3 GB のアドレス スペースをマッピングするために必要な PTE の数は 786,432 (3 GB ÷ 4 KB) です。一般的なシステムでは、この領域は以下のように使用されます。

  • 一般的な用途のために、最大で 50,000 の PTE (約 195 MB のアドレス スペース) が予約されます。

  • 他の PTE は、システム キャッシュ、ハイパースペース、ページ プール、非ページ プール、クラッシュ ダンプ領域、その他のマッピングに使用されます。

この PTE プールのサイズは、システム内の物理メモリの容量に基づいて、システムの起動時に自動的に決定されます。このプールは、ページ プールと非ページ プール (非ページ プールもシステム内の物理メモリの容量と共に増加します) の間に割り当てられます。

システム PTE プールは、頻繁に使用され、断片化が激しくなることがあります。これにより、ドライバが読み込めなくなるなどの事態が生じることがあります。また、システム PTE プールがすべて使い果たされると、システムの他の部分のパフォーマンスも低下します。それにより、スレッドが作成されなくなったり、システムが停止したり、さらにはシステムがクラッシュしたりする場合があります。

システム PTE プールが極端に断片化することを防止するには、SystemPages レジストリ値を常に Exchange Server コンピュータのオペレーティング システムに適した値に構成する必要があります。Windows Server 2003 上で Exchange Server を実行する場合は、SystemPages レジストリ キーを 0 に設定することをお勧めします。この推奨事項は、Windows 2000 Server の場合とは対照的です。Windows 2000 Server では、SystemPages を 24,000 ～ 31,000 の間の値に設定します。

次に説明する手順を実行した後で、空いているシステム PTE の数を監視します。Windows パフォーマンス モニタ (システム モニタとも呼ばれます) で Memory オブジェクトの Free System Page Table Entries カウンタを監視すると、システム PTE の数を監視できます。次に説明するレジストリの変更を行った後でも依然として空いているシステム PTE の数が少ない場合は、Exchange Server コンピュータが最適に構成されていることを確認するために次の点を調べます。

  • ドライバ システム PTE の数が不足する最も一般的な原因の 1 つは、ドライバの誤動作です。さらに、特定バージョンの S3 Savage 4 ビデオ カード ドライバは、SystemPages を 208,896 に設定することがわかっています。このドライバは、IBM E-Series サーバーでよく使用されます。ハードウェアの製造元に確認し、すべてのハードウェアで最新のドライバを使用していることを確認してください。より基本的なドライバにダウングレードできる場合もあります。たとえば、Exchange Server などサーバー ベースのアプリケーションを実行するコンピュータでは、すべての機能を持つ高機能のビデオ ドライバは通常は必要ありません。多くの場合、より基本的なドライバで十分です。高機能のビデオ ドライバから基本的なビデオ ドライバに切り替えると、空いているシステム PTE の数が増加するはずです。

  • システム構成 Windows Server 2003 システムに 1 GB 以上の物理メモリが搭載されている場合は、以下の Microsoft サポート技術情報の文書で説明されているように、/3GB スイッチと /USERVA=3030 スイッチを使用して Boot.ini ファイルが適切に構成されていることを確認する必要があります。

    • 文書番号 823440「Windows Server 2003 ベースのシステムに Exchange Server 2003 をインストールするとき、/3GB スイッチを使用する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

    • 文書番号 810371「[XADM] Windows 2003 Server ベースの Exchange Server で /Userva スイッチを使用する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810371)

  • イベント ログ Exchange Server のアプリケーション イベント ログを調べ、エラーと警告、特に MSExchangeIS イベント 9582 (エラーと警告)、9665 (警告)、および 12880 (エラー) があるかどうかを調べます。イベント 9665 も、SystemPages が最適なパフォーマンスが得られるように構成されていないことを示す場合があります。これらのイベントの詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Windows 2000 Server で、SystemPages の値を変更してこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに、24,000 ～ 31,000 (10 進数) の値を入力し、[OK] をクリックします。使用する値が不明の場合は、31,000 (10 進数) を使用することをお勧めします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

Windows Server 2003 で、SystemPages の値を変更してこの警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

ビデオ ドライバの更新またはダウングレードによってこの警告を修正するには

  • 以下のいずれかを実行します。

    • ハードウェアの製造元に連絡し、SystemPages の設定を構成しない、更新されたビデオ ドライバを入手します。

    • ビデオ ドライバを標準 VGA ドライバにダウングレードし、上で説明したように SystemPages 値を修正します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のためのメモリ最適化に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


システム アテンダントの HTTP ポートの値が 5,000 未満である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange System Attendant の HTTP Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HTTP Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

HTTP Port レジストリ キーは、Exchange Server 2003 および Exchange Server 2007 のセットアップ プログラムによって 6002 に設定されます。HTTP Port レジストリ キーは、Microsoft Office Outlook® 2003 および Microsoft Office Outlook 2007 用の RPC over HTTP 機能をサポートするために使用されます。

Microsoft コンサルティング サービスの支援を受けて、または Microsoft 製品サポート サービスからの指示によって RPC over HTTP 展開をカスタマイズしている場合を除き、RPC over HTTP は既定のポートの値で展開することをお勧めします。

HTTP Port を 6,002 以外の値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。5,000 未満の静的なポート番号を割り当てると、ポートが別のプロセスと競合して、Microsoft Exchange System Attendant プロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

HTTP Port レジストリ キーを既定値に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. HTTP Port キーをダブルクリックし、[値のデータ] ボックスを 6,002 (10 進数)、または 5,000 (10 進数) を超える整数に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


システム アテンダントの HTTP NSPI ポートの値が 5,000 未満である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange System Attendant の Rpc/HTTP NSPI Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

Rpc/HTTP NSPI Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

Rpc/HTTP NSPI Port レジストリ キーは、Exchange Server 2003 および Exchange Server 2007 のセットアップ プログラムによって 6004 に設定されます。Rpc/HTTP NSPI Port レジストリ キーは、Microsoft Office Outlook® 2003 および Microsoft Office Outlook 2007 用の RPC over HTTP 機能をサポートするために使用されます。

Microsoft コンサルティング サービスの支援を受けて、または Microsoft 製品サポート サービスからの指示によって RPC over HTTP 展開をカスタマイズしている場合を除き、RPC over HTTP は既定のポートの値で展開することをお勧めします。

Rpc/HTTP NSPI Port を 6,004 以外の値に設定する必要がある場合は、5,000 を超える値に設定することをお勧めします。5,000 未満の静的なポート番号を割り当てると、ポートが別のプロセスと競合して、Microsoft Exchange System Attendant プロセスでエラーが発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP NSPI Port レジストリ キーを既定値に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Rpc/HTTP NSPI Port キーをダブルクリックし、[値のデータ] ボックスを 6,004 (10 進数)、または 5,000 (10 進数) を超える整数に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


システム アテンダント : HTTP NSPI ポートが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、HTTP Port が既定値に設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\Rpc/HTTP NSPI Port

Rpc/HTTP NSPI Port が 6004 (10 進数) ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Rpc/HTTP NSPI Port レジストリ キーは、Exchange Server 2003 セットアップ プログラムによって 6004 に設定されます。Rpc/HTTP NSPI Port レジストリ キーは、Microsoft Office Outlook® 2003 の RPC over HTTP 機能をサポートするために使用されます。

Microsoft Consulting Services の支援を受けて、あるいは Microsoft 製品サポート サービスの推奨に従って RPC over HTTP の展開をカスタマイズしている場合を除き、RPC over HTTP は既定値のポートを使用して展開することをお勧めします。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Rpc/HTTP NSPI Port レジストリ値を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. Rpc/HTTP NSPI Port キーをダブルクリックし、[値のデータ] フィールドを 6,004 (10 進数) に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、この設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


システム アテンダント : HTTP ポートが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、HTTP Port が既定値に設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\HTTP Port

HTTP Port が 6002 (10 進数) ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

HTTP Port レジストリ キーは、Exchange Server 2003 および Exchange Server 2007 のセットアップ プログラムによって 6002 に設定されます。HTTP Port レジストリ キーは、Microsoft Office Outlook® 2003 および Microsoft Office Outlook 2007 用の RPC over HTTP 機能をサポートするために使用されます。

Microsoft コンサルティング サービスの支援を受けて、または Microsoft 製品サポート サービスからの指示によって RPC over HTTP 展開をカスタマイズしている場合を除き、RPC over HTTP は既定のポートの値で展開することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

HTTP Port レジストリ キーを既定値に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. HTTP Port キーをダブルクリックし、[値のデータ] フィールドを 6002 (10 進数) に設定します。

  4. レジストリ エディタを終了します。

  5. コンピュータを再起動して、設定を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の構成の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401)

  • 文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330)


システム アテンダントの legacyExchangeDN 値が存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server コンピュータの System Attendant オブジェクトの legacyExchangeDN 属性値を判断します。システム アテンダント オブジェクトの legacyExchangeDN 属性の値が検出されない場合、エラー メッセージが表示されます。

legacyExchangeDN 属性が存在しない理由として、管理者が障害回復時にデータベースを回復しようとして Active Directory を変更したことが考えられます。このエラーを解決するには、LDP (ldp.exe) ツールや Active Directory サービス インターフェイス (ADSI) Edit などの Active Directory エディタを使用して、legacyExchangeDN 属性を変更する必要があります。

legacyExchangeDN 属性が正しいことを確認するには、エラーが発生していないこのサーバーまたは他の Exchange サーバーの他のシステム アテンダント オブジェクトを調べる必要があります。これは、それらも同じ legacyExchangeDN 属性値を持っているためです。

データベース上に legacyExchangeDN 属性が存在しない状況を考慮すると、その他のいくつかのシステム オブジェクトにもこの属性が存在しない可能性があります。そのため、LDP や ADSI Edit を使用して新しい legacyExchangeDN 値を追加する場合は、他のすべてのシステム オブジェクトに対しても新しい legacyExchangeDN 値を追加する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration [ドメイン名]] を展開し、[CN=Configuration, DC=ドメイン名, DC=ドメイン サフィックス] を展開します。

  3. [CN=Services] を展開し、[CN=Microsoft Exchange] を展開します。

  4. [CN=組織名] を展開し、[CN=Administrative Groups] を展開します。次に、[CN=管理グループ名] を展開します。

  5. [CN=Servers] を展開し、[CN=サーバー名] を展開します。

  6. [CN=Microsoft System Attendant] を右クリックし、[プロパティ] をクリックします。

  7. 下にスクロールして legacyExchangeDN を選択し、[Edit] をクリックします。

  8. [Value] ボックスに、正しい legacyExchangeDN を入力します。

  9. Active Directory エディタを終了し、Exchange Server コンピュータを再起動して、変更を有効にします。

ADSI Edit を使用した legacyExchangeDN 属性の新規作成の詳細については、Microsoft サポート技術情報の文書番号 273863「[XADM] ADSIEdit を使用して legacyExchangeDN 属性を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863) を参照してください。


システム アテンダント NSPI ポートが手動で無効にされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Name Service Provider Interface ターゲット サーバー (NSPI target server) サービスが手動で無効にされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\TCP/IP NSPI Port

TCP/IP NSPI Port が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook® 2003 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。

Outlook を企業またはワークグループ モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、および Windows® XP Professional にある RPC (リモート プロシージャ コール) over HTTP 機能を使用することをお勧めします。

RPC over HTTP では、Outlook 2003 から Exchange Server 2003 への MAPI アクセスを可能にするために、仮想プライベート ネットワーク (VPN) を使用したり、ファイアウォールで複数のポートを開いたりする必要はありません。Outlook 2003 を実行しているユーザーは、インターネット経由で Exchange サーバーに接続できます。RPC クライアントは、HTTP プロトコルを経由した RPC トラフィックをトンネリングすることによってインターネット接続を確立します。RPC クライアントが、インターネット インフォメーション サービス (IIS) を実行中のリモート コンピュータに対して HTTP/HTTPS 接続を確立できた場合、その RPC クライアントはリモート ネットワーク上の任意のサーバーに接続できます。リモート ネットワーク上のサーバーは、RPC over HTTP を使用してインターネット経由でアクセス可能なように構成する必要があります。さらに、その RPC クライアントはインターネット経由で RPC サーバー プログラムに接続できます。これは両方のプログラムが異なるネットワーク上でファイアウォールの内側にある場合でも同様です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP NSPI Port レジストリ エントリを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

  3. TCP/IP NSPI Port という名前のレジストリ値を削除します。

  4. レジストリ エディタを終了し、Exchange System Attendant サービスを再開します。

RPC over HTTP を展開するには

  1. 「Exchange Server 2003 RPC over HTTP Deployment Scenarios」(http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  3. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  4. Microsoft サポート技術情報の文書番号 829134「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ファイアウォール環境で TCP/IP NSPI Port レジストリ値を使用する方法の詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。


システム アテンダント サービスがデスクトップと対話するように構成されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange System Attendant (MSExchangeSA) サービスの DesktopInteract プロパティの値を判断します。Exchange System Attendant サービスがデスクトップと対話するように構成されていることが検出されると、エラーが表示されます。

この構成は、Microsoft 製品サポート サービスからの指示に基づいてのみ使用するようにしてください。Microsoft 製品サポート サービスから、システム アテンダント サービスをこの構成で実行するように指示されている場合以外は、システム アテンダント サービスのプロパティを、デスクトップと対話しないように再構成することをお勧めします。

Exchange System Attendant サービス アカウントを構成するには

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. Microsoft Exchange System Attendant サービスを見つけて停止します。システム アテンダント サービスを停止すると、システム アテンダント サービスに依存するサービスもすべて停止されることに注意してください。このようなサービスには、Microsoft Exchange Information Store サービスがあります。

  3. [Microsoft Exchange System Attendant] サービスをダブルクリックします。

  4. [Microsoft Exchange System Attendant のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] をクリックします。

  5. [デスクトップとの対話をサービスに許可] チェック ボックスをオフにし、[適用] をクリックします。

  6. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  7. [サービス] スナップインを終了します。

正しい Exchange サービス構成の詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


システム アテンダント サービスが LocalSystem アカウントで実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-01-09

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange System Attendant (MSExchangeSA) サービスの StartName プロパティの値を判断します。また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、ディレクトリ内にある Exchange Server オブジェクトの serialNumber 属性の値も判断します。Exchange Server オブジェクトの serialNumber 属性は、そのオブジェクトによって表される、コンピュータで実行中の Exchange Server のバージョンを識別する属性です。Exchange Server アナライザによって、Exchange 2000 Server、Exchange Server 2003 または Exchange Server 2007 が実行されている Exchange サーバー上で、Exchange System Attendant サービスが LocalSystem (SYSTEM) アカウント以外のアカウントで実行されていることが検出されると、エラーが表示されます。

このエラーは、システム アテンダント サービスが、サポートされている構成で実行されていないことを示しています。システム アテンダント サービスが他の任意のアカウントで実行されていると、アクセス許可やアクセスのエラーが発生します。

このエラーを解決するには、LocalSystem (SYSTEM) アカウントで開始されるように Exchange System Attendant サービスを構成する必要があります。

注 :
このエラーは、Exchange Server Version 5.5 には当てはまりません。Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 の場合のみ、Exchange System Attendant サービスが LocalSystem アカウントで実行されている必要があります。
Exchange System Attendant サービス アカウントを構成するには

  1. [サービス] Microsoft 管理コンソール (MMC) スナップインを開きます。

  2. Microsoft Exchange System Attendant サービスを見つけて停止します。システム アテンダント サービスを停止すると、システム アテンダント サービスに依存するサービスもすべて停止されることに注意してください。このようなサービスには、Microsoft Exchange Information Store サービスがあります。

  3. [Microsoft Exchange System Attendant] サービスをダブルクリックします。

  4. [Microsoft Exchange System Attendant のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択し、[適用] をクリックします。

  5. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  6. サービス スナップインを終了します。

LocalSystem アカウントでの Exchange サービスの実行に関する詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


TcpTimedWaitDelay キーがないか、既定値ではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-03-13

Microsoft Exchange アナライザ ツールは Active Directory ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて、serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータでは Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 を実行しています。文字列値に "Version 8.0" が含まれている場合、コンピュータでは Exchange Server 2007 を実行しています。

次に、Exchange アナライザ ツールは、見つかった各 Exchange Server 2007 サーバーの次のレジストリを読み取り、TcpTimedWaitDelay キーの値が既定値の 60 に設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TcpTimedWaitDelay キーは、TCP が閉じられた接続を解放してそのリソースを再利用するまで待機する必要がある時間を決定します。閉じられてから解放するまでの間隔は、TIME_WAIT 状態または 2MSL 状態と呼ばれます。この間、クライアントとサーバーにとっては、新しい接続を確立する場合より大幅に少ないコストで接続を再度開くことができます。

このエントリの値を小さくすると、TCP は閉じられた接続をより短時間に解放し、新しい接続のためにより多くのリソースを提供できます。ただし、値が小さすぎる場合、接続が完了する前に TCP が接続リソースを解放し、サーバーが追加のリソースを使用して接続を再確立する必要が生じる可能性があります。

Exchange アナライザが TcpTimedWaitDelay キーの値がないか、既定値の 60 とは異なると判断すると、警告が表示されます。

最適なパフォーマンスを得るには、Exchange Server 2007 サーバーで、TcpTimedWaitDelay キーを既定値の 60 に設定することをお勧めします。

重要 :
このトピックには、レジストリの編集に関する説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
TcpTimedWaitDelay レジストリ キーを既定値に設定するには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. [TcpTimedWaitDelay] をダブルクリックし、[値のデータ] ボックスを 60 (10 進数) に設定します。

  4. レジストリ エディタを終了し、コンピュータを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この問題は、「MaxUserPort キーがないか、既定値ではない」というアナライザの問題に関連しています。

MaxUserPort および TcpTimedWaitDelay レジストリ キーが及ぼす影響の詳細については、Windows 2000 リソース キットの伝送制御プロトコルについてのトピック (http://go.microsoft.com/fwlink/?LinkId=85654) を参照してください (このサイトは英語の場合があります)。


TEMP/TMP 変数が無効なフォルダまたは不適切なフォルダを指していると思われる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

クラスタ化されていない Exchange Server コンピュータ上では、Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、TEMP 環境変数と TMP 環境変数の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\TEMP

HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP

Microsoft Exchange Information Store サービスは、メッセージの変換やメールボックスの移動などのさまざまな操作の間、TEMP フォルダと TMP フォルダを一時的な記憶域として使用します。クラスタ化されていない Exchange サーバーでは、Microsoft Exchange Information Store サービスは TEMP と TMP の両方について、既定の環境変数の設定である %Systemroot%\Temp が使用される SYSTEM (ローカル システムなど) を使用します。Exchange Server の TEMP 環境変数と TMP 環境変数のいずれか、または両が %SYSTEMROOT で始まっていると、警告が表示されます。

TEMP 環境変数と TMP 環境変数は、一時的なワークスペースを必要とするアプリケーションが使用するファイル システム内のフォルダを (パスで) 指定するために使用されます。TEMP は通常、Microsoft Exchange などのアプリケーションによって使用され、TMP は通常、Microsoft Visual C++® などの開発ツールによって使用されます。各変数のパスは、通常、アプリケーションまたはツールのセキュリティ コンテキストを基準にしています。

Exchange Server アナライザは、Windows Server™ 2003 クラスタ内の Exchange 仮想サーバーに対して実行された場合、HKLM レジストリ ツリーの読み取りは行いません。代わりに、以下のレジストリ エントリを読み取ります。

HKEY_USERS\<クラスタ サービスのアカウント SID>\Environment\TEMP

HKEY_USERS\<クラスタ サービスのアカウント SID>\Environment\TMP

Windows Server 2003 クラスタで実行される Exchange 仮想サーバーは、特定のユーザー セキュリティ プリンシパルのコンテキストで実行されるクラスタ サービス アカウントの環境変数の設定を使用します。ユーザー アカウントの場合、TEMP と TMP の既定の環境変数は %Userprofile%\temp に設定されます。Exchange 仮想サーバーの TEMP 環境変数と TMP 環境変数のいずれか、または両方が %SYSTEMROOT で始まっていると、警告が表示されます。

最大のパフォーマンスを得るためには、オペレーティング システムを格納しているディスクを、Exchange が使用する TEMP フォルダと TMP フォルダのために使用しないことをお勧めします。また、これらの環境変数が、RAID 0+1 スピンドル セットなどの高速なディスクまたはディスク システム上のパスに設定されるようにしてください。さらに、オペレーティング システムを格納しているディスクを、Exchange Server または Exchange 仮想サーバーが使用する TEMP フォルダと TMP フォルダのために使用しないことをお勧めします。

この警告を修正するには

  1. 管理者権限を持つアカウントを使用して、Exchange サーバー コンピュータにログオンします。

  2. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。

  3. [詳細設定] タブをクリックします。

  4. [環境変数] をクリックします。

  5. [システム環境変数] 領域で、[TEMP] を選択し、[編集] ボタンをクリックします。

  6. [変数値] ボックスに TEMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  7. [システム環境変数] 領域で、[TMP] を選択し、[編集] ボタンをクリックします。

  8. [変数値] ボックスに TMP 環境変数の新しいパスを入力し、[OK] をクリックします。

  9. [OK] をクリックして [環境変数] ダイアログ ボックスを閉じ、もう一度 [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じます。

  10. ノードを再起動して変更を適用します。

クラスタ化された Exchange サーバーにおける TEMP 環境変数や TMP 環境変数の変更に関する詳細については、「クラスタの TEMP/TMP パスがシステム パーティションと同じドライブ上に存在する」を参照してください。


サーバーに 1 GB 以上の物理メモリが実装されているが、HeapDeCommitFreeBlockThreshold が 262,144 に設定されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-08-14

エラー メッセージ

はじめに

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、システム内の物理メモリ容量に基づいて Exchange が最適に調整されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\HeapDeCommitFreeBlockThreshold

1 ギガバイト (GB) 以上の物理メモリが実装されている Exchange Server コンピュータで、HeapDeCommitFreeBlockThreshold の値が設定されていないことが検出されると、警告が表示されます。

メモリがあるアドレスで解放されると、オペレーティング システムのヒープ マネージャは、そのアドレス周辺の空き連続バイト数をチェックします。チェックが完了すると、ヒープ マネージャは以下のいずれかを実行します。

  • 連続しているメモリ ブロックをコミットされたままにします。

  • 連続しているメモリ ブロックをデコミットし、予約専用としてマークします。

HeapDeCommitFreeBlockThreshold レジストリ キーは、メモリがデコミットされる場合の最低連続バイト数を指定します。既定では、ヒープ マネージャが必ずしもすべての空きブロックの結合や新規割り当てを行うとは限りません。そのため、ブロックがデコミットされても仮想アドレス スペースに無用な空きができるにすぎない場合があります。このことが仮想メモリの断片化やパフォーマンスの低下の原因となり、最終的にはシステムが不安定になる可能性があります。

1 GB 以上の物理メモリを実装しているシステムでは、デコミットされたメモリのチャンクのサイズを制御することによって、パフォーマンスを最適化します。HeapDeCommitFreeBlockThreshold レジストリ キーを使用すると、メモリが解放されたときの処理方法を制御できます。この値をレジストリに追加する場合は、16 進数値 0x00040000 (10 進数値では 262144) で構成する必要があります。

Microsoft では、HeapDeCommitFreeBlockThreshold レジストリ キーの値として、16 進数値 0x00040000 (10 進数値では 262144) 以外の値をサポートしていません。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Control\Session Manager

  3. HeapDeCommitFreeBlockThreshold という名前の DWORD 値を作成します。

  4. HeapDeCommitFreeBlockThreshold 値をダブルクリックし、16 進数で「0x00040000」(10 進数なら 262144) と入力します。

  5. レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

HeapDeCommitFreeBlockThreshold レジストリ キーの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 315407, "XADM:文書番号 315407「[XADM] "HeapDecommitFreeBlockThreshold" レジストリ キーについて」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=315407)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)


サーバーで Windows Server 2003 が実行されており、SystemPages の値が 0 になっていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SystemPages レジストリの値の設定を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

Exchange Server アナライザは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーの値は、Microsoft Windows オペレーティング システムの特定のバージョンに対応します。

Exchange Server アナライザによって、Microsoft Windows Small Business Server 2003 の一部ではない Microsoft Windows Server™ 2003 を実行している Exchange Server コンピュータで、SystemPages の値が 0 に設定されていないことが検出されると、警告が表示されます。

1 GB 以上の RAM が実装されている Microsoft Windows Server 2003 上で Exchange Server 2003 Service Pack 1 (SP1) を実行する場合、SystemPages レジストリ キーを 0 に設定することをお勧めします。この推奨事項は、Microsoft Windows 2000 Server の場合とは対照的です。Windows 2000 Server では、SystemPages を 24,000 ～ 31,000 の間の値に設定します。

Microsoft Windows Small Business Server 2003 の一部ではない Windows Server 2003 コンピュータでは、SystemPages レジストリ値を 0 以外の値に設定しないでください。この値を変更すると、システムの変更が生じたときに、システムに最適な値を計算して値を調整することができなくなります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
注意 :
Windows Server 2003 が実行されているコンピュータで SystemPages レジストリ値を設定すると、ページ プールの最大サイズが小さくなるという影響が発生します。これにより、ページ プールが使い果たされたり、サーバーが不安定になったりすることがあります。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

  3. 右側のペインで、[SystemPages] をダブルクリックします。

  4. [値のデータ] ボックスに「0」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のためのメモリ最適化の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)

  • 文書番号 311901「システム ページ テーブル エントリでの 4GT チューニングの影響」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)


Exchange サーバーの Boot.ini ファイルに /PAE 起動スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SystemStartupOptions プロパティでどのオプションが設定されているかを判断します。また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、メールボックス ストア オブジェクト (msExchPrivateMDB) の homeMDBBL 属性のカウントを判断します。ここで得られる値は、Exchange Server コンピュータ上に見つかったメールボックスの数を表します。

メールボックス数が 500 未満であり、Windows 2000 Server が実行されている Exchange サーバーの Boot.ini ファイルに /PAE 起動スイッチが設定されていることが検出されると、警告メッセージが表示されます。

物理アドレス拡張 (PAE) を使用すると、コンピュータは 4 GB を超える物理メモリ (RAM) にアクセスできるようになります。Exchange Server は PAE をサポートしていません。PAE を使用すると、Windows が 4 GB を超える物理メモリにアクセスできるようになります。Exchange Server は 4 GB を超える物理メモリを使用できないので、Exchange Server の実行のみを担当するコンピュータに 4 GB を超える RAM を搭載する利点はありません。PAE は、Boot.ini ファイル内に /PAE 起動スイッチが存在する場合に有効になります。

この警告を Windows 2000 についてのみ修正するには、Boot.ini ファイルから /PAE スイッチを削除することをお勧めします。

この警告を修正するには

  1. Windows エクスプローラで、システム パーティションに移動します。これは、Boot.ini や NTLDR のようなハードウェア固有のファイルが格納されているパーティションです。

  2. Boot.ini ファイルが表示されない場合は、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合は、エクスプローラのウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[すべてのファイルとフォルダを表示する] をクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。確認を求められたら、[はい] をクリックします。

  3. Windows エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、/PAE スイッチを削除します。

  5. ファイルを保存して閉じ、Exchange Server コンピュータを再起動して、変更を有効にします。

Boot.ini の /PAE スイッチの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 268363「Windows 2000 における Intel PAE (物理アドレス拡張。」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 文書番号 328882「[XGEN] Exchange 2000 Server のメモリ使用と /3GB スイッチ」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


物理アドレス拡張 (PAE) が有効な状態で Exchange サーバーが実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-05-08

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次のキーの値を判断します。

  • PAEEnabled このキーの値は、物理アドレス拡張 (PAE) が有効になっているかどうかを示しています。この値が True の場合は PAE が有効になっていることを示し、False の場合は PAE が有効になっていないことを示します。

  • Version このキーの値は、そのコンピュータ上で実行されている Microsoft Windows オペレーティング システムのバージョンを示します。この値が 5.0.2195 の場合は Microsoft Windows 2000 Server オペレーティング システムが実行されていることを、5.2.3790 の場合は Microsoft Windows Server™ 2003 オペレーティング システムが実行されていることを示しています。

  • ServicePackMajorVersion このキーの値は、インストールされている Windows Service Pack のメジャー バージョン番号を示します。

Exchange Server アナライザはまた、そのシステムで実行されている ntoskrnl.exe のマイナ バージョンの CIM_Datafile WMI クラスに対してもクエリを実行し、セキュリティ更新プログラム MS04-032 がコンピュータにインストールされているかどうかを判断します。ntoskrnl.exe のマイナ バージョンが 174 以下である場合、MS04-032 はインストールされていません。ntoskrnl.exe のマイナ バージョンが 174 より大きい場合は、MS04-032 がインストールされています。

Exchange Server アナライザによって、セキュリティ更新プログラム MS04-032 がインストールされていない Windows Server 2003 で実行されている Exchange Server に対して PAEEnabled の値が True に設定されていることが検出されると、エラーが表示されます。このエラーは、このコンピュータが、Microsoft Exchange Information Store サービス (Store.exe) のクラッシュを引き起こす可能性のある既知の問題の影響を受けやすい状態にあることを示しています。

Exchange Server は PAE を使用しません。PAE を使用すると、Windows が 4 GB を超える物理メモリにアクセスできるようになります。Exchange Server が 4 GB を超える物理メモリを使用できないため、Exchange Server を実行するための専用のコンピュータに 4 GB を超える RAM を実装してもメリットはありません。PAE は、起動時に Boot.ini ファイル内に /PAE 起動スイッチが存在する場合、または新しく追加されたメモリ デバイスが Windows Server 2003 オペレーティング システムによって検出された場合に有効になります。Windows Server 2003, Enterprise Edition および Windows Server 2003, Datacenter Edition で PAE が自動的に有効になるのは、サーバーが、新しく追加されたメモリ デバイスを使用している場合のみです。

MS04-032 更新プログラムをインストールしてこのエラーを修正するには

  1. MS04-032 更新プログラムを入手するには、Microsoft サポート技術情報の文書番号 840987「[MS04-032] Microsoft Windows のセキュリティ更新プログラム」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=840987) を参照してください。

  2. システムを完全にバックアップします。

  3. 更新プログラムを適用した後、コンピュータを再起動して更新プログラムを有効にします。

PAE の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 268363「Windows 2000 における Intel PAE (物理アドレス拡張。」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 文書番号 328882「[XGEN] Exchange 2000 Server のメモリ使用と /3GB スイッチ」

    (http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)

Boot.ini の /NOPAE スイッチの詳細については、MSDN の文書「/nopae」(http://go.microsoft.com/fwlink/?LinkId=51490) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーが物理アドレス拡張が有効な状態で実行され、かつ /3GB 起動スイッチが設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、PAEEnabled キーの値を判断します。このキーの値は、物理アドレス拡張 (PAE) が有効になっているかどうかを示しています。この値が True の場合は PAE が有効になっていることを示し、False の場合は PAE が有効になっていないことを示します。また、Exchange Server アナライザは Win32_OperatingSystem WMI クラスに対してクエリを実行し、MaxProcessMemorySize キーの値も判断します。

PAEEnabled の値が True で、MaxProcessMemorySize の値が 2097024 より大きいことが検出されると、警告が表示されます。この警告は、これらの値が既定値ではないことを示しています。Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

PAE の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 268363: 文書番号 268363「Windows 2000 における Intel PAE (物理アドレス拡張。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 文書番号 328882「Exchange のメモリ使用と /3GB スイッチ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


/PAE 起動スイッチと /3GB 起動スイッチが設定された状態で Exchange サーバーが実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SystemStartupOptions キーでどのオプションが設定されているかを判断します。また、Exchange Server アナライザは Win32_OperatingSystem WMI クラスに対してクエリを実行し、MaxProcessMemorySize キーの値も判断します。

SystemStartupOptions キーの値に /PAE が含まれ、Win32_OperatingSystem 値によって Microsoft Windows 2000 Server であることが示され、さらに MaxProcessMemorySize の値が 2,097,024 より大きいことが検出されると、エラーが表示されます。

このエラーは、Boot.ini ファイルに /PAE と /3GB の両方の起動スイッチが設定されていることを示しています。物理アドレス拡張 (PAE) を使用すると、コンピュータは 4 GB を超える物理メモリ (RAM) にアクセスできるようになります。Exchange Server は PAE をサポートしていません。Exchange Server は 4 GB を超える物理メモリを使用できないため、Exchange Server を実行するための専用のコンピュータに 4 GB を超える RAM を実装してもメリットはありません。PAE は、起動時に、Boot.ini ファイル内に /PAE 起動スイッチが存在する場合に有効になります。

このエラーを Windows 2000 Server についてのみ修正するには、Boot.ini ファイルから /PAE スイッチを削除することをお勧めします。

このエラーを修正するには

  1. エクスプローラから、システム パーティションに移動します。このパーティションには、Boot.ini や NTLDR などのハードウェア固有のファイルが保持されています。

  2. Boot.ini ファイルが表示されない場合は、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合は、Windows エクスプローラ ウィンドウで、[ツール] メニューの [フォルダ オプション] をクリックし、[表示] タブをクリックします。[すべてのファイルとフォルダを表示する] をクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。確認を求められたら、[はい] をクリックします。

  3. Windows エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] をクリックして、ファイルを開きます。

  4. [Operating Systems] セクションで、/PAE スイッチを削除します。

  5. ファイルを保存して閉じてから、Exchange Server コンピュータを再起動して変更を有効にします。

Boot.ini の /PAE スイッチの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 268363「Windows 2000 における Intel PAE (物理アドレス拡張。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268363)

  • 文書番号 328882「[XGEN] Exchange 2000 Server のメモリ使用と /3GB スイッチ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328882)


このフロントエンド サーバーは受信者更新サービスで構成される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内の各 Recipient Update Service オブジェクトについて、msExchAddressListServiceLink 属性の値を判断します。msExchAddressListServiceLink 属性は、アドレス一覧サービスから、受信者更新サービス (RUS) が実行されている Exchange Server コンピュータへのリンクです。以下の条件に当てはまる場合は、エラーが表示されます。

  • Exchange Server がフロントエンド サーバーとして構成されている。

  • Exchange Server コンピュータで受信者更新サービスが実行されている。

受信者更新サービスは、Exchange System Attendant サービスのコンポーネントです。受信者更新サービスにより、Active Directory に Exchange 固有の属性値が作成および保持されます。ユーザー用のメールボックスを作成すると、SMTP (Simple Mail Transfer Protocol) アドレス、および受信者ポリシーで定義しているその他のプロキシ アドレスが受信者更新サービスによって自動生成されます。

受信者更新サービスを使用するように構成された Exchange Server がフロントエンド サーバーとしても構成されている場合、新しく作成されたユーザー オブジェクトは受信者構成サービスによって処理されません。その結果、ユーザー オブジェクトが電子メール アドレスを受信せず、受信者がアドレス一覧に表示されない場合があります。また、オフライン アドレス帳への更新が処理されません。

このメッセージが表示される場合、受信者更新サービスはフロントエンド サーバーとして構成された Exchange Server で実行されています。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] の下の [受信者更新サービス] をクリックします。右側のペインで、受信者更新サービスの該当するインスタンスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[Exchange サーバー] の横の [参照] をクリックし、この RUS インスタンスを実行する新しいサーバーを指定します。

  4. [OK] をクリックし、[OK] を再度クリックして変更を有効にします。

受信者更新サービスの詳細については、以下のトピックと Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328738「[XADM] 受信者更新サービスによって受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253828「[XADM] 受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 文書番号246127「[XADM] Exchange 2000 のアドレス一覧サービスのトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 文書番号 253770「[XADM] 受信者更新サービスで行われるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


レジストリと Active Directory の Exchange サーバー名が一致しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory に格納されている Exchange サーバーの名前の値 (CN=<Exchange サーバー名>) を判断します。Exchange Server アナライザは、この名前を取得した後、名前の文字数をカウントします。

また、Exchange Server アナライザは次のレジストリ エントリを読み取り、Exchange Server コンピュータのレジストリに格納されている Exchange サーバーのホスト名の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Hostname

さらに、Exchange Server アナライザは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、ClusSvc (クラスタ サービス) の Started キーの値を判断します。

以下の条件にすべて該当すると判断されると、エラーが表示されます。

  • CN=<Exchange サーバー名> の値が Hostname の値と一致しない。

  • Exchange サーバー名が 15 文字以下になっている。

  • Exchange サーバーが Windows クラスタ内で実行されていない。

このエラーの最も一般的な原因は、Exchange サーバーの名前が変更されたことです。Exchange サーバーの名前を変更すると、コンピュータのレジストリ内の名前が変更され、Active Directory 内のコンピュータ アカウントの名前が変更されますが、Active Directory 内にある Exchange の属性やオブジェクトの全体にわたって数多く存在する、Exchange サーバー名への参照は変更されません。

注 :
サードパーティのソフトウェアには、クラスタ化機能を提供するためにコンピュータ名も変更するものがあります。そのようなソフトウェアを使用している場合は、この問題を無視する必要が生じることがあります。

Exchange Server コンピュータの名前を変更する操作はサポートされていません。コンピュータ名の変更後に、Microsoft Exchange System Attendant サービスを開始できないなどの問題が発生することがわかっています。名前を変更した Exchange Server コンピュータが正常に機能していないと思われる点がある場合、この文書で概要を示す手動での削除手順に従って、コンピュータから Exchange Server を手動で削除することができます。名前を変更した Exchange Server コンピュータがすべての点で正常に機能しているように見える場合でも、この構成はサポートされておらず、将来問題の原因になる可能性があるため、下の再構築手順に従って Exchange サーバーを再構築する必要があります。

Exchange Server を手動で削除してこのエラーを修正するには

  1. すべての Exchange Server サービスを停止し、コンピュータを完全にバックアップします。

  2. 実行している Exchange Server のバージョンに応じて、以下の Microsoft サポート技術情報の文書を参照してください。

    • Exchange Server 2007 を実行している場合は、Exchange Server 2007 ドキュメントの、Exchange 2007 をサーバーから完全に削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=79246) に記載されている手順に従います。

    • Exchange Server 2003 を実行している場合は、Microsoft サポート技術情報の文書番号 833396「Exchange Server 2003 をコンピュータから削除する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833396) に記載されている手順に従います。

    • Exchange 2000 Server を実行している場合は、Microsoft サポート技術情報の文書番号 260378「[XADM] Exchange 2000 インストールを手動で削除する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260378) に記載されている手順に従います。

  3. Exchange 2000 Server または Exchange Server 2003 を実行しており、このサーバーが組織内に存在する唯一の Exchange サーバーである場合は、マイクロソフト サポート技術情報の記事 273478 の、Active Directory から Exchange 2000 または Exchange 2003 を完全に削除する方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=273478) に記載されている手順に従います。

Exchange Server コンピュータを再構築してこのエラーを修正するには

  1. メールボックス、パブリック フォルダ、コネクタ、および役割を、組織内にある別の Exchange Server コンピュータに移動します。

  2. Exchange Server をコンピュータからアンインストールします。

  3. Exchange Server 2003 または Exchange Server 2000 を実行しているコンピュータのレジストリをクリーンアップするには、以下のマイクロソフト サポート技術情報の記事に記載されている、レジストリの削除に関する手順に従います。

    • 文書番号 833396「Exchange Server 2003 をコンピュータから削除する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=833396)

    • 文書番号 260378「[XADM] Exchange 2000 インストールを手動で削除する方法」(http://go.microsoft.com/fwlink/?linkId=3052&kbid=260378)

    または、オペレーティング システムを再構築することができます。

  4. Exchange Server をコンピュータにインストールします。

  5. 新しく構築した Exchange Server コンピュータにメールボックス、パブリック フォルダ、コネクタ、および役割を移動します。

Exchange Server 2003 をクラスタ上に展開する方法の詳細については、Microsoft サポート技術情報の文書番号 810986「[XADM] クラスタ ノードへの Exchange Server のインストールに関するマイクロソフトのサポート ポリシー」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810986) を参照してください。


Active Directory 内の Exchange サーバー名に不一致がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバーの Name 属性と cn 属性 (mxExchExchangeServer クラスのオブジェクト) が一致するかどうかを判断します。これらの属性が異なることが検出されると、エラー メッセージが表示されます。

Exchange は、サーバー オブジェクトの cn 値を使用して、サーバーを内部で識別します。また、Name 値を使用して、Microsoft Exchange システム マネージャのユーザー インターフェイスでサーバーを識別します。

このエラーは、管理者が Active Directory サービス インターフェイス (ADSI) Edit や LDP (ldp.exe) ツールなどのツールを使用して Name 値を変更した場合に発生することがあります。この操作を行うと、ユーザー インターフェイスのサーバー名は変更されますが、ストアおよびシステム アテンダント イベントを生成する不一致が発生します。この値は、ADSI Edit スナップイン、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントといったツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit または同様のツールを使用して、Active Directory 内のサーバー オブジェクトを見つけます。

    CN 属性と Name 属性は、次の場所にあります。

    コードのコピー
    CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=Organization,CN=Administrative Groups,CN=Administrative group,CN=Servers,CN=Server

  2. Name 属性に、CN 属性の値と一致する新しい文字列値を入力します。

LDP ツールの使用に関する詳細については、Microsoft サポート技術情報の文書番号 260745 の LDP ユーティリテイを使用した AD オブジェクト属性の変更についての説明(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の使用に関する詳細については、Windows Server ヘルプで ADSI Edit (Adsiedit.msc) についてのトピック (英語) を参照してください。


Active Directory サーバーと Exchange サーバーの間に複数のネットワークが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、root\cimv2 名前空間の WIN32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、RouteRecord キーの値を判断します。RouteRecord キーには、Exchange サーバーとドメイン コントローラ間の中間ホップのレコード (たとえば、ルーターの数) が格納されています。Exchange Server アナライザは、RouteRecord キーで示されているルーターの数を数えます。複数のルーターが示されていることが検出されると、エラーが表示されます。

Active Directory® ディレクトリ サービスは、Exchange Server コンピュータがサブネット上でドメイン コントローラまたはグローバル カタログ サーバーと通信できることが保証される設計であると最適です。このエラーは、Exchange Server コンピュータが、2 ホップ以上離れたネットワーク上にあるドメイン コントローラと通信していることを示します。

このエラーを修正するには

  1. ネットワーク トポロジを確認し、Active Directory サーバーの配置を再検討します。

  2. Exchange Server とドメイン コントローラのイベント ログを監視し、潜在的な問題を示すネットワーク関連のイベントが記録されていないかどうかを確認します。

  3. Active Directory サイトの設計を調べます。この仕様に従ってネットワークが区分されていない場合は、ネットワークをより多くの Active Directory サイトに区分することを検討してください。

Win32_PingStatus WMI クラスの詳細については、MSDN の文書「Win32_PingStatus」(http://go.microsoft.com/fwlink/?linkid=33549) を参照してください (このサイトは英語の場合があります)。

Active Directory サイト設計の詳細については、「Designing the Site Topology」(http://go.microsoft.com/fwlink/?linkid=33551) を参照してください (このサイトは英語の場合があります)。


ホップが多すぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft Windows® Management Instrumentation (WMI) クラスの MessageID プロパティに対してクエリを実行して、メッセージの送信先の各サーバーを調べます。

メッセージは、最終的な宛先に届く前に、多数の異なる SMTP サーバーを経由する場合があります。この経路上の各サーバーのことを "ホップ" といいます。

特定の MessageID の Exchange_MessageTrackingEntry のインスタンス数が 30 に達したことが Exchange Server アナライザによって検出されると、エラーが表示されます。

このエラーは、テスト メッセージの伝送がループしている可能性があることを表します。そのため、Exchange Server アナライザは、無限ループ状況に陥る可能性を回避するために、追加の Exchange_MessageTrackingEntry インスタンスのクエリを停止します。

Exchange Server アナライザ出力のメッセージ追跡ログ セクションの追加分析は、ループ状況が存在するかどうかを調べるのに役立ちます。


サポートされていない仮想コンピュータの構成 - クラスタ化された Exchange サーバーが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーに値 "Virtual Machine" が設定されているかどうかを判断します。

また Win32_Service WMI クラスに対してもクエリを実行し、Windows クラスタ サービスである ClusSvc の Started キーの値を判断します。Started キーの値が True の場合はクラスタ サービスが開始されており、値が False の場合はクラスタ サービスは開始されていません。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Model キーの値が "Virtual Machine" に設定されている。

  • クラスタ サービスの Started キーの値が True に設定されている。

このエラーは、Exchange サーバーが、仮想コンピュータ環境で実行されているクラスタ化された Exchange サーバーであることを示します。この構成はサポートされていません。

このエラーを修正するには

  1. 物理クラスタを構築し、仮想環境で実行されているクラスタ化された Exchange サーバーから物理クラスタにメールボックスを移動します。

  2. 物理クラスタを構築できない場合は、次のようにこのエラーを修正します。

    1. 仮想環境で実行されている Exchange Server のメールボックスを、仮想化されていないスタンドアロンの Exchange Server コンピュータに移動します。

    2. 必要に応じて、パブリック フォルダを再格納し、クラスタ化された Exchange サーバーが実行していた役割を転送します。

    3. Exchange Server を仮想コンピュータからアンインストールして、その Exchange の使用を停止し、Exchange Server インフラストラクチャおよび Active Directory から削除します。

仮想環境で実行される Exchange Server 2003 に対する Microsoft のサポート ポリシーの詳細については、Microsoft サポート技術情報の文書番号 320220 「ポリシーでハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 をサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください。


サポートされていない仮想コンピュータの構成 - Exchange Server 2003 Service Pack 2 以降が検出されない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が "Virtual Machine" に設定されているかどうかを判断します。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータでは Exchange Server 5.5 が実行されています。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Exchange 2000 Server が実行されています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 が実行されています。文字列値に "Version 6.5" および "Service Pack 2" が含まれている場合、コンピュータでは Exchange Server 2003 Service Pack 2 (SP2) が実行されています。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Model キーが "Virtual Machine" に設定されている。

  • コンピュータで Exchange Server 2003 SP2 以降のバージョンが実行されていない。

このエラーは、Exchange サーバーが仮想コンピュータであるが、Exchange Server 2003 SP2 以降がインストールされていないことを示しています。この構成はサポートされていません。

このエラーを修正するには

  1. Exchange Server 2003 Service Pack 2 以降のバージョンをインストールします。

  2. Microsoft サポート技術情報の文書番号 320220「ポリシーでハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 をサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください。

  3. Service Pack 2 以降のバージョンを適用できない場合は、次のようにこのエラーを修正します。

    1. メールボックスを、Vitual Server 2005 環境下で実行している Exchange Server から、仮想 Exchange Server コンピュータ以外のコンピュータに移動します。

    2. 必要に応じて、パブリック フォルダを再格納し、仮想 Exchange サーバーが実行していた役割を転送します。

    3. Exchange Server を仮想コンピュータからアンインストールして、その Exchange の使用を停止し、Exchange Server インフラストラクチャおよび Active Directory から削除します。


サポートされていない仮想コンピュータの構成 - 仮想コンピュータ追加機能が検出されない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーに値 "Virtual Machine" が設定されているかどうかを判断します。

Exchange Server アナライザは、次のレジストリ エントリを読み取り、仮想コンピュータ追加機能がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

このレジストリ パスが存在する場合は、仮想コンピュータ追加機能がインストールされています。このレジストリ パスが存在しない場合は、仮想コンピュータ追加機能はインストールされていません。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Model キーの値が "Virtual Machine" に設定されている。

  • このレジストリ パスが存在しない。

このエラーは、Exchange サーバーが仮想コンピュータであるが、仮想コンピュータ追加機能がインストールされていないことを示しています。この構成はサポートされていません。

仮想コンピュータ追加機能をインストールするには、次の操作を実行します。

  1. 仮想環境で実行している Exchange Server をバックアップします。

  2. Virtual Server 2005 管理コンソールまたは Web サイトを使用して、Virtual Machine Additions をインストールします。

Exchange Server 2003 を仮想環境で実行する方法の詳細については、Microsoft サポート技術情報の文書番号 320220「ポリシーでハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 をサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください。


夏時間の更新プログラムを入手可能
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、各 Exchange Server オブジェクトの versionNumber 属性の値を判断します。versionNumber 属性は、コンピュータで実行されている Exchange Server のバージョンを表します。

また、Exchange アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、STORE.exe プロセスの Version キーの値を判断します。

  • Version キーの値 7638 は、Exchange Server 2003 Service Pack 2 を示します。

  • Version キーの値 7226 は、Exchange Server 2003 Service Pack 1 を示します。

  • Version キーの値 6944 は、最初のリリースの Exchange Server 2003 を示します。

  • 上記のバージョンの間の値は、サーバーが Store.exe プロセスの修正プログラム更新バージョンを実行していることを示します。

Exchange アナライザが、Exchange Server 2003 SP2 を実行するサーバーの Store.exe の Version キーの値が、7561 未満であるか、または Exchange Server 2003 SP1 を実行するサーバーの値が 7234 未満である、と判断した場合、警告が表示されます。

この警告は、Exchange Server コンピュータが、2007 年の夏時間の変更の更新プログラムをインストールせずに、Exchange Server 2003 Service Pack 1 または Exchange Server 2003 SP2 を実行していることを示します。

この更新プログラムをインストールしないと、CDO ベースのプログラムと Outlook Web Access のカレンダ項目は、夏時間の追加の週の期間中でも、標準時間が有効であるかのように作動します。

Exchange Server 2003 SP2でこの警告を修正するには

  1. Microsoft サポート技術情報の文書番号 926666「Exchange 2003 Service Pack 2 の 2007 年夏時間変更の更新プログラム」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=926666) のガイダンスに従ってください。
Exchange Server 2003 SP1でこの警告を修正するには

  1. Microsoft サポート技術情報の文書番号 931978「Exchange 2003 Service Pack 1 の 2007 年夏時間変更の更新プログラム」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=931978) のガイダンスに従ってください。


Windows 2000 SP4 の更新プログラム ロールアップがインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、ServicePackMajorVersion キーの値を判断します。また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Windows のバージョンを確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

対象のシステムで Windows 2000 Server オペレーティング システムが実行されていても、Windows 2000 Server Service Pack 4 の更新プログラム ロールアップが実行されていないと判断されると、警告が表示されます。

ベスト プラクティスとして、Exchange を展開した環境内に存在するすべてのソフトウェアに最新の Service Pack およびロールアップをインストールすることをお勧めします。

この警告を修正するには

  1. Windows 2000 Server を実行しているすべてのドメイン コントローラとグローバル カタログ サーバーを Service Pack 4 の更新プログラム ロールアップに更新し、Windows Update から最新の修正プログラムと更新を適用します。

  2. すべての Exchange Server コンピュータを、最新のロールアップと更新プログラム ロールアップに更新します。

Windows 2000 SP4 の更新ロールアップの詳細については、Microsoft サポート技術情報の文書番号 891861「Windows 2000 Service Pack 4 対応の更新プログラム ロールアップ 1 と既知の問題」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=891861) を参照してください。

Exchange Server Service Pack とロールアップの取得およびインストール方法の詳細については、Exchange Server Web サイト (http://go.microsoft.com/fwlink/?LinkId=21573) を参照してください (このサイトは英語の場合があります)。


URLScan がインストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバー上の次の場所に次のファイルが存在するかどうかを判断します。

%WINDOWSPATH%\\SYSTEM32\\INETSRV\URLSCAN\URLSCAN.DLL

Urlscan.dll が存在する場合は、Exchange サーバーに URLScan ツールがインストールされています。Exchange Server アナライザによって、Exchange サーバーに URLScan ツールがインストールされていることが検出されると、ベスト プラクティスのメッセージが表示されます。

URLScan は ISAPI (Internet Server Application Programming Interface) フィルタであり、Web サイト管理者はこれを使用して、サーバーで処理される HTTP 要求の種類を制限することができます。URLScan フィルタは、特定の HTTP 要求をブロックすることにより、問題を引き起こす可能性のある要求がサーバーにアクセスして損害を発生させるのを防ぐことができます。

Exchange サーバーで URLScan を実行する場合は、Urlscan.ini が Exchange サーバーの役割に合わせて調整されていることを確認する必要があります。Exchange サーバーのセキュリティを強化するには、Urlscan.ini 構成ファイルを編集して、無関係な機能を削除する必要があります。Urlscan.ini ファイルを特定の Exchange Server 2003 コンピュータの役割に合わせてカスタマイズするには、Urlscan.ini ファイルの [AllowVerbs] セクションにあるコマンドを削除する必要があります。ただし、必要な機能を使用できるように、該当するコンピュータの役割に推奨されるコマンドは確実に含めるようにしてください。単一のコンピュータで複数の Web ベース機能が必要な場合は、[AllowVerbs] セクションに対する適切な要件を結合する必要があります。

Urlscan.ini ファイルを Exchange Server 2003 コンピュータの役割に基づいて変更するには、Microsoft サポート技術情報の文書番号 823175「Urlscan ユーティリティを Exchange 2003 環境で使用する場合の調整方法および既知の問題」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823175) に含まれている Exchange Server 2003 URLScan テンプレートの情報を使用できます。

URLScan の詳細については、「UrlScan Security Tool」(http://go.microsoft.com/fwlink/?LinkId=24490) を参照してください (このサイトは英語の場合があります)。

Exchange Server 環境で URLScan を使用する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 309677「[XADM] IIS Lockdown Wizard を Exchange 2000 環境で使用する場合の問題および調整方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=309677)

  • 文書番号 309598「[XCCC] Exchange 環境での IIS Lockdown と URLscan の構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=309508)

  • 文書番号 325965「URLScan ツールと、Outlook Web Access で問題が発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325965)

  • 文書番号 326444「[HOWTO] URLScan ツールの構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326444)


USERVA の設定が正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-09-19

Microsoft® Exchange Server アナライザ ツールは、3 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータの物理メモリの容量と、その Exchange Server コンピュータで実行されるユーザー モード プロセスに割り当てられている仮想アドレス スペースの容量を判断します。以下の表に、Exchange Server アナライザによって評価されるクラスとキーを示します。

クエリを実行されるクラス | クエリを実行されるキー | 説明
Win32_OperatingSystem | MaxProcessMemorySize | プロセスに割り当てることのできるメモリの最大サイズ (KB)
Win32_ComputerSystem | TotalPhysicalMemory | コンピュータに実装されたランダム アクセス メモリ (RAM) のバイト数。
Win32_Service | Started | サービスの状態。値が True の場合、サービスが実行されていることを示し、値が False の場合、サービスが実行されていないことを示します。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで実行されている Microsoft Windows のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、Microsoft Windows NT® Server 4.0 上で Exchange Server コンピュータが実行されていることを示します。値が 5.0 の場合、Exchange Server コンピュータは Windows 2000 Server 上で、5.2 の場合は Windows Server™ 2003 上で実行されています。

最後に、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、メールボックス ストア オブジェクト (msExchPrivateMDB) の homeMDBBL 属性のカウントを判断します。判明したカウントは、Exchange Server コンピュータで見つかったメールボックスの数です。

Exchange Server アナライザによって、以下の条件にすべて当てはまると判断されると、警告が表示されます。

  • Exchange Server コンピュータが Windows Server 2003 上で実行されている。

  • TotalPhysicalMemory の値が、1073741824 より大きい。

  • MaxProcessMemorySize の値が、3145600 と等しい。

  • クラスタ サービス (ClusSvc) の Win32_Service\Started 値が True であるか、Exchange Server コンピュータに 20 を超えるメールボックスが格納されている。

この警告は、仮想メモリの使用について、Exchange Server コンピュータが最適に構成されていないことを示します。具体的には、Exchange Server コンピュータの Boot.ini ファイルに、/USERVA=3030 起動スイッチが指定されていません。このスイッチを追加すると、スケーラビリティとパフォーマンスが向上する可能性があります。

Windows Server 2003 では、Boot.ini の起動スイッチとして、/3GB と /USERVA の 2 種類がサポートされています。これらのスイッチを使用すると、メモリの使用量およびメモリのアドレス スペースの割り当てを調整できます。Windows は、システムに搭載されている物理メモリの容量にかかわらず 4 GB の仮想アドレス スペースを使用し、アプリケーションなどのユーザー モード プロセスに 2 GB を割り当て、オペレーティング システムやカーネル モードのドライバなどのカーネル モード プロセスに 2 GB を割り当てます。1 GB 以上の物理メモリを搭載したシステムでは、これらの起動スイッチを使用して、アプリケーションにはより多くのメモリ (3 GB) を割り当て、オペレーティング システムにはより少ないメモリ (1 GB) を割り当てることができます。Exchange Server コンピュータでは、この追加の仮想アドレス スペースは、インフォメーション ストア プロセスの仮想アドレス スペースにおけるメモリの断片化を減らすために役立ちます。/3GB スイッチは、この割り当て変更を生じさせるために使用されます。このスイッチは、システムの Boot.ini ファイルに入力されて、再起動後に有効になります。このスイッチは、以下のオペレーティング システムが実行され、1 GB 以上のメモリ容量を持つ Exchange サーバーでのみ使用してください。

  • Microsoft Windows Server 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

重要 :
Windows 2000 Server では、/3GB スイッチはサポートされていません。アプリケーションやオペレーティング システムのクラッシュを引き起こす可能性があるため、使用しないでください。/3GB スイッチがサポートされるのは、物理メモリが 1 GB 以上搭載されている上記のオペレーティング システムのみです。また、/3GB スイッチは、Windows Server 2003 Standard Edition を実行する Active Directory サーバー (ドメイン コントローラおよびグローバル カタログ サーバー) では使用できません。

/USERVA スイッチは Windows Server 2003 で新しく導入されました。このスイッチは、ユーザー モード プロセスとカーネル モード プロセスの間で仮想アドレス スペースを分割する方法を、より細かく制御できるようにすることを目的としています。このスイッチは、Exchange Server 2003 など、このスイッチをサポートするアプリケーションに対して、各アプリケーションでサポートされている特定の値を指定して使用する必要があります。Exchange Server 2003 システムで使用する場合、/USERVA は常に 3030 に設定する (/USERVA=3030) 必要があります。この値を指定すると、オペレーティング システムに追加の 40 MB が割り当てられ、利用可能なシステム リソースをすべて消費しないでより多くのユーザーを追加できます。

Windows Server 2003 でこの警告を修正するには

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [詳細設定] タブをクリックします。

  3. [起動と回復] 領域で、[設定] をクリックします。[起動と回復] ダイアログ ボックスが表示されます。

  4. [起動システム] 領域で、[編集] をクリックします。この操作によって、Windows の Boot.ini ファイルがメモ帳で開かれます。

  5. [Operating Systems] セクションで、起動行にスイッチとして "/3GB /USERVA=3030" を追加します。

  6. 変更を保存して、メモ帳を閉じます。

  7. [OK] を 2 回クリックして、開かれているダイアログ ボックスを閉じてから、Exchange Server コンピュータを再起動して変更を有効にします。

/3GB および /USERVA 起動スイッチの使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 297812 の 4GT RAM チューニング機能の使用方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=297812)。

  • 文書番号 311901 のシステム ページ テーブル エントリでの 4GT チューニングの影響についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=311901)。

  • 文書番号 316739 の/userva スイッチと/3GB スイッチを使用してユーザー モード領域を 2 ～ 3 GB の間でチューニングする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)。

  • 文書番号 325044 の [HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)。

  • 文書番号 815372 の Exchange Server 2003 でメモリ使用量を最適化する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)。


このコンピュータにインストールされているバージョンの Tcpip.sys ファイルには修正プログラムが必要である可能性がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Tcpip.sys ファイルの Version キーに設定されている値を判断します。Version キーの値が特定のバージョンの Tcpip.sys ファイルに対応していることが検出されると、警告が表示されます。

この警告の詳細については、Microsoft サポート技術情報の文書番号 898060「セキュリティ更新プログラム MS05-019 または Windows Server 2003 Service Pack 1 のインストール後、クライアントとサーバー間のネットワーク接続が機能しないことがある」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=898060) に記載されている推奨事項に従ってください。


仮想コンピュータの構成が検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が "Virtual Machine" に設定されているかどうかを判断します。

また Win32_Service WMI クラスに対してもクエリを実行し、Windows クラスタ サービスである ClusSvc の Started キーの値を判断します。Started キーの値が True の場合は、クラスタ サービスが開始されています。値が False の場合、クラスタ サービスは開始されていません。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6.5" および "Service Pack 2" が含まれている場合、コンピュータでは Exchange Server 2003 Service Pack 2 (SP2) が実行されています。

最後に、Exchange Server アナライザは次のレジストリ エントリを読み取り、仮想コンピュータ追加機能がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

このレジストリ パスが存在する場合は、仮想コンピュータ追加機能がインストールされています。このレジストリ パスが存在しない場合は、仮想コンピュータ追加機能はインストールされていません。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • Exchange サーバーが Microsoft Virtual Server 2005 の下でゲストとして実行されている。

  • Exchange サーバーが Exchange Server 2003 Service Pack 2 以降を実行している。

  • Exchange サーバーがクラスタ化されていない。

  • Exchange サーバーに Virtual Server 2005 用の仮想コンピュータ追加機能がインストールされている。

この構成で実行するためにはいくつかの要件がありますが、Exchange Server アナライザではこの構成を検出できません。したがって、Virtual Server 2005 環境で Exchange Server 2003 を実行する前に、以下の Microsoft サポート技術情報の文書でこの構成に対するサポート状況およびパフォーマンス チューニングの最新情報を確認することをお勧めします。

文書番号 320220「ポリシーでハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 をサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220)


仮想メモリが断片化している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2007-02-15

Microsoft Exchange アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、MSExchangeIS のイベント 9582 エラーが過去 24 時間以内にログに記録されていないかどうかを判断します。

イベント 9582 が過去 24 時間以内にログに記録されていることが検出されると、エラーが表示されます。

このエラーは、Exchange サーバーの実行に必要な仮想メモリが断片化していることを示します。

32 ビット版の Microsoft Windows システムには、2 種類のメモリがあります。

  • 物理メモリ システムにインストールされている実際のメモリの容量

  • 仮想メモリ アドレス スペース 仮想化された 4 GB のメモリ スペース

システムに取り付けられている物理メモリの量とは無関係に、仮想アドレス スペースの合計サイズは常に同じ 4 GB です。すべての 32 ビット アプリケーションに当てはまるわけではありませんが、Exchange Server の場合、仮想アドレス スペースは仮想メモリに一致します。これらの用語は同義で使用されます。

通常の動作中、Exchange ストアは繰り返し仮想メモリの割り当て、使用、および割り当ての解除を行います。仮想メモリの割り当て、使用、割り当て解除が頻繁に行われると、仮想メモリの断片化が発生することがあります。仮想メモリの断片化は、時間が経過すると発生することがあるファイル システムの断片化に似ています。しばらくすると、割り当てられた仮想メモリのセグメントが連続的ではなくなって、パフォーマンスが低下し始めます。ファイル システムの場合、ファイル システムを最適化するアプリケーションを実行できます。ほとんどの場合、ファイル システムの最適化はシステムがオンラインでアクセスされている場合に実行できます。仮想メモリの断片化の場合、最適化ツールはありません。代わりに、この問題を解決するために、Microsoft Exchange Information Store サービスを停止してから開始するか、システムを再起動する必要があります。

この問題を解決するには、次の操作を行います。

  • 仮想メモリの断片化は、store/inetinfo プロセスを実行しているサードパーティ製のソフトウェアによって引き起こされることがあります。サードパーティ製のアプリケーションに対して最新のドライバが適用されていることを確認してください。

  • パフォーマンス ログと警告ツールを使用して、MSExchangeIS パフォーマンス オブジェクトの VM Total Large Free Block Bytes カウンタを監視します。このカウンタから収集されたデータを使用して、今後 36 ～ 72 時間以内にサーバーをシャットダウンして再起動するウィンドウを判断します。

注 :
このサーバーがクラスタ化されたサーバーである場合は、クラスタのリソースを移動する前にパッシブ ノードを停止して再起動し、移動先の仮想メモリのアドレス スペースが空いていることを確認してください。
  • 再起動した後も問題が再発する場合は、サードパーティ製のソフトウェアを無効にすることを検討します。

  • ユーザーのメールボックスを別のサーバーに移動してサーバーの負荷を減らすことを検討し、問題が解決されるかどうかを確認します。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

詳細情報

  • MSExchangeIS Event 9852 の詳細については、イベントおよびエラー メッセージ センターのイベント詳細についてのページ (http://go.microsoft.com/fwlink/?LinkId=83209) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 パフォーマンスとスケーラビリティ ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server パフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Microsoft Exchange Server 2003 および Exchange 2000 Server における仮想メモリ断片化のトラブルシューティング方法に関する詳細については、マイクロソフト サポート技術情報の文書番号 325044「Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。

  • 仮想メモリの使用量を最適化する方法の詳細については、マイクロソフト サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


Virtual Server 2005 R2 以降が検出されない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Vssrvc.exe (Microsoft Virtual Server 2005 に含まれる Virtual Server サービスによって表されるプロセス) の Version キーの値を判断します。Vssrvc.exe の Version キーの値が 1.1.465.0 に等しいことが検出されると、エラーが表示されます。

このエラーは、この Exchange サーバーが、Virtual Server 2005 R2 以降を実行していない Microsoft Virtual Server 2005 環境でゲストとして実行されていることを示します。この構成はサポートされていません。Exchange Server 2003 Service Pack 2 以降のバージョンは、Microsoft Virtual Server 2005 R2 以降でのみ、仮想環境でゲストとして実行することができます。

このエラーを修正するには

  1. Microsoft サポート技術情報の文書番号 320220「ポリシーでハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 をサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください。

  2. Microsoft Virtual Server 2005 R2 以降をインストールします。Microsoft Virtual Server 2005 R2 については、Microsoft Virtual Server 2005 R2 Web サイト (http://go.microsoft.com/fwlink/?LinkId=34938) を参照してください (このサイトは英語の場合があります)。

  3. Virtual Server 2005 R2 以降をインストールできない場合は、次のようにこのエラーを修正します。

    1. メールボックスを、Vitual Server 2005 の下で実行されている Exchange Server から、仮想化されていない Exchange Server コンピュータか、または Virtual Server 2005 R2 の下で実行されている仮想 Exchange Server コンピュータに移動します。

    2. 必要に応じて、パブリック フォルダを再格納し、サポートされていない仮想 Exchange サーバーが実行していた役割を転送します。

    3. Exchange Server をサポートされていない仮想コンピュータからアンインストールして、その Exchange の使用を停止し、Exchange Server インフラストラクチャおよび Active Directory から削除します。


Virus Scan Queue Length がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-27

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの Virus Scan Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Virus Scan Queue Length カウンタの 90 パーセンタイル値が 10 を超えたことが検出されると、Exchange Server アナライザによってエラーが表示されます。

Virus Scan Queue Length パフォーマンス カウンタは、ウイルス スキャン用のキューに入れられている、現在未解決の要求の数を示します。

このエラーは、次のパフォーマンスの問題が発生していることを示している場合があります。

  • 通常、CPU のボトルネックが原因で発生するサーバーのパフォーマンスの低下

  • 通常よりも高いサーバーの負荷

  • 古いウイルス スキャン エンジン

  • 正しく構成されていないウイルス スキャン エンジン

このエラーを解決するには、次の操作を行います。

  • ウイルス エンジンの更新を調べます。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。

  • スレッド構成の正確性やファイル レベルの除外などについて、ウイルス スキャン エンジンの構成を確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • パフォーマンス モニタ (Perfmon.msc) ツールを使用して、ボトルネックがサーバーの負荷の増大によって発生しているのか、サーバーのサイズが小さいために発生しているのかを判断します。サーバーの負荷が増大している場合は、原因を突き止めて負荷を減らします。サーバーのリソースが不十分な場合は、必要なリソースを増やすか、ユーザーをサーバーから移動します。

プロセッサのボトルネックの解消

Exchange サーバーのプロセッサのボトルネックを解消する多くの方法があります。

  • 最初に、サーバーで負荷を引き起こしているアプリケーションまたはタスクを確認します。アプリケーションがプロセッサ時間を使用する必要があるのかどうか、またはプロセスに問題がある可能性があるのかどうかを判断します。

  • Exchange 以外のアプリケーションがそのサーバーに対して重要でない場合は、そのアプリケーションを別のサーバーで実行します。アプリケーションを別のサーバーで実行できる場合は、サーバーの役割も別のコンピュータに移動します。たとえば、Inetinfo プロセスが大量の CPU 使用率を消費している場合は、Inetinfo が実行するプロトコル作業を担当するフロントエンド サーバーを追加することを検討します。パブリック フォルダ アクセスを専用のパブリック フォルダ サーバーに移動することもできます。最後に、サーバーが多くの配布リストの展開を実行する場合は、配布リストの展開を専用の配布リスト展開サーバーに移動して、CPU の使用率を減らすことができます。

  • 可能な場合は、プロセッサをさらに追加するか、より速いプロセッサを追加します。また、プロセッサによってサポートされている場合は、ハイパー スレッディングを有効にします。ハイパー スレッディングはシステム BIOS を構成して有効にすることができます。詳細については、コンピュータの製造元のヘルプ ドキュメントを参照してください。

  • プロセッサの処理能力を高めることができない場合は、プロセッサの負荷を減らす必要があります。サーバーに対する全体的な影響を減らすには、I/O、CPU、またはメモリを集中的に使用するタスクを通常の運用時間外に実行することを確実に行います。

  • バックアップ、保守などの CPU を集中的に使用するタスクをピーク時間外に実行されるようにします。また、これらのタスクが段階的に実行されるようにします。段階的なタスクの実行とは、各タスクに対して、異なる開始時刻、さらに可能であれば異なる終了時刻を設定することを意味します。また、データベースまたはストレージ グループの保守およびバックアップを段階的に実行すると、これらのリソースを集中的に使用するタスクの影響が少なくなります。

詳細情報

  • Exchange Server およびウイルス スキャンの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • ウイルス スキャンと Exchange Server の詳細については、Microsoft サポート技術情報の文書番号 285667「[XADM] Exchange 2000 Server SP1 のウイルス検索 API 2.0 について」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=285667) を参照してください。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


Virus Scan Queue Length が警告のしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、MSExchangeIS パフォーマンス オブジェクトの Virus Scan Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

サンプル期間中に Virus Scan Queue Length カウンタの 90 パーセンタイル値が 5 を超えたことが検出されると、Exchange Server アナライザによって警告が表示されます。

Virus Scan Queue Length パフォーマンス カウンタは、ウイルス スキャン用のキューに入れられている、現在未解決の要求の数を示します。

この警告は、このサーバーでパフォーマンスが問題になる可能性があることを示しています。パフォーマンスの問題は、次の項目に関連している場合があります。

  • 通常、CPU のボトルネックが原因で発生するパフォーマンスの低下

  • 通常よりも高いサーバーの負荷

  • 古いウイルス スキャン エンジン

  • 正しく構成されていないウイルス スキャン エンジン

この警告に対処するには、次の操作を行います。

  • ウイルス エンジンの更新を調べます。

  • ウイルス スキャン ソフトウェアの再インストールを検討します。

  • スレッド構成の正確性やファイル レベルの除外などについて、ウイルス スキャン エンジンの構成を確認します。Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • パフォーマンス モニタ (Perfmon.msc) ツールを使用して、ボトルネックがサーバーの負荷の増大によって発生しているのか、サーバーのサイズが小さいために発生しているのかを判断します。サーバーの負荷が増大している場合は、原因を突き止めて負荷を減らします。サーバーのリソースが不十分な場合は、必要なリソースを増やすか、ユーザーをサーバーから移動します。

プロセッサのボトルネックの解消

Exchange サーバーのプロセッサのボトルネックに対処する多くの方法があります。

  • 最初に、サーバーで負荷を引き起こしているアプリケーションまたはタスクを確認します。アプリケーションがプロセッサ時間を使用する必要があるのかどうか、またはプロセスに問題がある可能性があるのかどうかを判断します。

  • Exchange 以外のアプリケーションがそのサーバーに対して重要でない場合は、そのアプリケーションを別のサーバーで実行します。可能な場合は、サーバーの役割も他のコンピュータに移動します。たとえば、Inetinfo プロセスが大量の CPU 使用率を消費している場合は、Inetinfo が実行するプロトコル作業を担当するフロントエンド サーバーを追加することを検討します。パブリック フォルダ アクセスを専用のパブリック フォルダ サーバーに移動することもできます。最後に、サーバーが多くの配布リストの展開を実行する場合は、配布リストの展開を専用の配布リスト展開サーバーに移動して、CPU の使用率を減らすことができます。

  • 可能な場合は、プロセッサをさらに追加するか、より速いプロセッサを追加します。また、プロセッサによってサポートされている場合は、ハイパー スレッディングを有効にします。ハイパー スレッディングはシステム BIOS を構成して有効にすることができます。詳細については、コンピュータの製造元のヘルプ ドキュメントを参照してください。

  • プロセッサの処理能力を高めることができない場合は、プロセッサの負荷を減らす必要があります。サーバーに対する全体的な影響を減らすには、I/O、CPU、またはメモリを集中的に使用するタスクを通常の運用時間外に実行することを確実に行います。

  • バックアップ、保守などの CPU を集中的に使用するタスクをピーク時間外に実行されるようにします。また、これらのタスクが段階的に実行されるようにします。段階的なタスクの実行とは、各タスクに対して、異なる開始時刻、さらに可能であれば異なる終了時刻を設定することを意味します。また、データベースまたはストレージ グループの保守およびバックアップを段階的に実行すると、これらのリソースを集中的に使用するタスクの影響が少なくなります。

詳細情報

  • Exchange Server およびウイルス スキャンの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • ウイルス スキャンと Exchange Server の詳細については、Microsoft サポート技術情報の文書番号 285667「[XADM] Exchange 2000 Server SP1 のウイルス検索 API 2.0 について」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=285667) を参照してください。

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


ボリューム マウント ポイントのエラー : Windows Server 2003 SP1 がインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile WMI (Windows® Management Instrumentation) に対してクエリを実行し、Mountmgr.sys ドライバが存在することを確認します。

Exchange Server アナライザは、次のレジストリ値を読み取り、Exchange サーバー上で実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 5.0 の場合、Exchange サーバーは Microsoft Windows 2000 Server 上で実行されています。CurrentVersion の値が 5.2 の場合、Exchange サーバーは Microsoft Windows Server™ 2003 上で実行されています。

また、Exchange Server アナライザは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリも実行し、クラスタ サービス (ClusSvc) に対する Started キーの値を判断します。値が TRUE の場合はクラスタ サービスが開始されており、値が FALSE の場合はクラスタ サービスは実行されていません。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • Exchange Server コンピュータが Windows Server 2003 上で実行されている。

  • Windows Server 2003 SP1 がインストールされていない。

  • Exchange Server がクラスタ化された環境で実行されている。

  • ボリューム マウント ポイントが存在する。

この警告は、Exchange クラスタ ノード環境が Windows Server 2003 SP1 にアップグレードされている場合に、次のセクションで参照する更新プログラムが必要になることを示します。この更新プログラムがないと、アップグレード後にボリューム マウント ポイントでエラーが発生する場合があります。

この警告を修正するには、次の操作を行います。

  • 更新プログラムを適用してください。詳細については、Microsoft サポート技術情報の文書番号 898790「Windows Server 2003 Service Pack 1 をインストールした後に、サーバー クラスタ内のディスクのボリューム マウント ポイントは断続的に利用できません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790) を参照してください。


Exchange Server で Windows ファイアウォール サービスが有効になっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Windows ファイアウォール サービス (SharedAccess) の Started キーの値を判断します。この値が True の場合は、この Exchange サーバーで Windows ファイアウォール サービスが有効になっています。

Exchange Server アナライザによって、Exchange Server コンピュータで Windows ファイアウォール サービスが有効になっていることが検出されると、警告が表示されます。Windows ファイアウォール サービスが有効になっていると、以下の問題が発生する可能性があります。

  • メッセージ追跡サービスやリモート プロシージャ コール (RPC) 通信など、Exchange Server の一部のコンポーネントが応答しなくなる場合があります。

  • 使用可能なメモリが不足していることを通知するエラー メッセージが表示される場合があります。

既定では、Windows ファイアウォール サービスは、Microsoft Windows Server™ 2003 Service Pack 1 (SP1) が適用されると停止されます。ただし、以下の条件のいずれかが満たされると、再び開始するように自動的に設定されます。

  • 管理者が Windows ファイアウォール サービスを手動で有効にした。

  • セキュリティの構成ウィザードを実行した後で Windows ファイアウォール サービスを有効にした。

この警告を修正するには

  • プログラムの除外を確認します。

  • ポートの除外を確認します。

  • クライアントが Exchange サーバーに接続できない場合は、ファイアウォールの例外を確認します。

  • Exchange システム マネージャおよび Microsoft Exchange 管理ツールを実行できるように、ファイアウォールのポートを手動で開きます。Windows ファイアウォール サービスのポートを開くと、他のプログラムがこれらのポートを経由してコンピュータにアクセスできる可能性が高くなります。Windows ファイアウォール サービスのポートを開く前に、ネットワークのセキュリティ要件を慎重に検討してください。

  • Windows ファイアウォール サービスを停止します。


Windows Management Instrumentation サービスが LocalSystem アカウントで実行されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ObjectName の値のデータを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winmgmt

このレジストリ ブランチ内の ObjectName 値は、Microsoft WMI (Windows® Management Instrumentation) サービスのサービス アカウント設定を示しています。Exchange Server アナライザによって ObjectName の値のデータが "LocalSystem" に等しくないことが検出されると、エラーが表示されます。

このエラーは、WMI サービスが、サポートされている構成で実行されていないことを示しています。WMI サービスを LocalSystem アカウント以外のアカウントで実行すると、アクセス許可のエラーやアクセス エラーが発生する場合があります。

このエラーを解決するには、LocalSystem (SYSTEM) アカウントで開始されるように WMI サービスを構成する必要があります。

WMI サービス アカウントを構成するには

  1. [サービス] Microsoft 管理コンソール (MMC) スナップインを開きます。

  2. Windows Management Instrumentation サービスを見つけて停止します。

  3. [Windows Management Instrumentation] サービスをダブルクリックします。

  4. [Windows Management Instrumentation のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択し、[適用] をクリックします。

  5. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  6. [サービス] スナップインを終了します。


Windows Server 2003 SP1: Outlook Web Access の修正プログラムが必要である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、さまざまな Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下の情報を収集します。

  • Exchange Server がインストールされている Microsoft Windows Server オペレーティング システムのバージョン

  • クラスタ上で Exchange Server が実行されているかどうか

以下の条件に当てはまると判断されると、エラーが表示されます。

  • Exchange Server 2003 Service Pack 1 (SP1) がインストールされている。

  • Microsoft Windows Server™ 2003 Service Pack 1 (SP1) がインストールされている。

  • クラスタ サービスが実行されている。

  • Davex.dll の Version の値が 6.5.7232 より小さい。

この構成を実行している場合、Windows Server 2003 SP1 をインストールする前に、Exchange Server の修正プログラムをダウンロードしてインストールする必要があります。Exchange Server の修正プログラムをインストールしないと、Microsoft Office Outlook® Web Access for Exchange Server 2003 ユーザーはメールボックスにログオンすることができません。クラスタ上でホストされているメールボックスを持つユーザーが Outlook Web Access を使用してメールボックスに接続しようとすると、次のエラー メッセージが表示されます。

  • "500 - 内部サーバー エラー"

このエラーは、Windows Server 2003 SP1 に含まれている一部のセキュリティ強化機能が原因で発生します。

ユーザーが Outlook Web Access を使用してメールボックスにログオンしようとすると、HTTP はログオン ユーザーに偽装して、クラスタ API に要求を送信します。しかし、Windows Server 2003 SP1 ではセキュリティに関する変更があり、リモート レジストリへのアクセスを行う API に対するセキュリティ制限が変更されました。このため、ログインは成功しません。

このエラーを修正するには、Microsoft サポート技術情報の文書番号 841561「クラスタ化された Exchange Server 2003 のバックエンド サーバーにユーザーが Outlook Web Access を使用してアクセスするとき、"500 - 内部サーバー エラー" というエラー メッセージが表示される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=841561) で説明されている Exchange Server 修正プログラムをダウンロードしてインストールする必要があります。


Windows Server 2003 SP1 セキュリティの構成ウィザードが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、Exchange サーバー上で実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 5.0 の場合、Exchange サーバーは Microsoft Windows 2000 Server 上で実行されています。CurrentVersion の値が 5.2 の場合、Exchange サーバーは Microsoft Windows Server™ 2003 上で実行されています。

Exchange Server アナライザ ツールは、さらに次のレジストリ値を読み取り、Windows Program Files ディレクトリのパスを特定します。

HKLM\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir

次に、Windows Program Files ディレクトリを調べて、Windows Program Files ディレクトリに Exchange Server 用の \Exchsrvr フォルダが含まれているかどうかを判断します。

Exchange Server アナライザ ツールは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、ServicePackMajorVersion キーの値を判断します。ServicePackMajorVersion キーの値は、コンピュータにインストールされている Windows Service Pack を示します。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • Exchange Server コンピュータが Windows Server 2003 Service Pack 1 上で実行されていると判断した。

  • Exchange Server 2003 が既定のパスである \Program Files\Exchsrvr にインストールされていないと判断した。

この警告は、Exchange Server 2003 がサーバーの既定の Program Files フォルダにインストールされていないこと、および Exchange サーバー上にセキュリティの構成ウィザード がインストールされていることを示します。セキュリティの構成ウィザードは Windows Server 2003 Service Pack 1 にオプションのコンポーネントとして含まれているツールです。セキュリティの構成ウィザードが Exchange サーバー上にインストールされている場合は、ネットワーク セキュリティのセクションを手動で構成する必要があります。

注 :
セキュリティの構成ウィザードをインストールするには、最初に Windows Server 2003 Service Pack 1 をインストールする必要があります。Service Pack 1 をインストールしたら、コントロール パネルの [プログラムの追加と削除] を開き、セキュリティの構成ウィザードをインストールします。

セキュリティの構成ウィザードを使用すると、サーバーの機能要件を決定するための一連の質問をユーザーに対して行うことによって、Windows サーバーが攻撃にさらされる機会を低減することができます。具体的には、セキュリティの構成ウィザードは以下のことを行います。

  • 不要なサービスを自動的に無効にする。

  • 使用されていないポートを自動的にブロックする。

  • 開いたままになっているポートに対する、追加のアドレス制限またはセキュリティ制限の適用を助ける。

  • 必要に応じて、不要なインターネット インフォメーション サービス (IIS) Web 拡張の使用を防ぐ。

  • サーバー メッセージ ブロック (SMB)、LanMan、およびライトウェイト ディレクトリ アクセス プロトコル (LDAP) に対するプロトコルの公開を抑止する。

  • 高度な SN (signal-to-noise) 監査ポリシーを定義する。

セキュリティの構成ウィザードによって画面に表示されるガイドに従って、サーバーの選択された役割に基づいたセキュリティ ポリシーの作成、編集、適用、またはロールバックを行うことができます。セキュリティの構成ウィザードを使用して作成されるセキュリティ ポリシーは XML ファイルで、サービス、ネットワーク セキュリティ、特定のレジストリ値、および監査ポリシーを適用する際は、この XML ファイルによって構成が行われます。必要に応じて、インターネット インフォメーション サービス (IIS) も構成されます。

セキュリティの構成ウィザードにはネットワーク セキュリティ機能が含まれています。ネットワーク セキュリティ機能は、Windows ファイアウォールの構成、Windows ファイアウォールへの例外の追加、およびその他の機能を実行します。Windows ファイアウォールは、Windows Server 2003 Service Pack 1 に含まれるステートフル パケット フィルタの最新バージョンです。Windows ファイアウォールは Windows XP Service Pack 2 で初めて導入され、Windows XP Service Pack 2 ではインターネット接続ファイアウォールと呼ばれていました。

Exchange Server が既定のパスにインストールされていない Exchange サーバー上でセキュリティの構成ウィザードのネットワーク セキュリティ機能を実行すると、既知の問題が発生します。この構成では、ポリシーが適用されたアプリケーションによって、クライアントから Exchange Server にアクセスできなくなる場合があります。Exchange Server が既定のパスにインストールされていない Exchange サーバー上でネットワーク セキュリティ機能を使用する場合、セキュリティの構成ウィザードは Windows ファイアウォールを構成して、TPC/IP ポートへの Exchange Server プロセスからのアクセスをブロックできます。Exchange Server プロセスには、システム アテンダント (Mad.exe)、Microsoft Exchange Information Store (Store.exe)、メッセージ転送エージェント (Emsmta.exe) などがあります。この構成では、セキュリティの構成ウィザードによって各プロセスの横に [Not Found!] と表示されます。横に [Not Found!] と表示されたプロセスが完了するまでセキュリティの構成ウィザードが実行されている場合、セキュリティの構成ウィザードは、そのプロセスによってネットワーク アクセスがブロックされた Windows ファイアウォールに対してセキュリティ ポリシーを適用します。

ブロックされたプロセスに 1 つ以上の Exchange Server プロセスが含まれている場合、クライアントおよび他のサーバーから Exchange Server にアクセスできなくなる場合があります。この状況が発生した場合は、以下のいずれかの手順を実行して問題を修正する必要があります。

この問題を修正するには

  • 問題を修正するには、以下のいずれかの手順を実行します。

    • セキュリティの構成ウィザードのロールバック機能を使用して、セキュリティ ポリシーを、適用された後の状態にロールバックします。この操作方法の詳細については、Windows Server 2003 Service Pack 1 に付属しているセキュリティの構成ウィザードのヘルプ ファイルを参照してください。Windows Server 2003 Service Pack 1 およびセキュリティの構成ウィザードの詳細については、「Windows Server 2003 TechCenter」(http://go.microsoft.com/fwlink/?LinkId=45315) を参照してください (このサイトは英語の場合があります)。

    • セキュリティの構成ウィザードで、[アプリケーション パス] フィールドに手動で入力し、Exchange Server プロセスの実行可能ファイルの場所を指定します。これを行うには、横に [Not Found!] と表示されているプロセスを選択し、[編集] をクリックします。Exchange サーバーでセキュリティの構成ウィザードを実行し、各 Exchange Server プロセスの実行可能ファイルのパスが正しいことを確認することをお勧めします。プロセスの実行可能ファイルが承認された後は、セキュリティの構成ウィザードのセキュリティ ポリシーを適用することができます。また、Exchange Server には、機能するために必要なネットワーク アクセスが備わります。

Windows Server 2003 Service Pack 1 およびセキュリティの構成ウィザードの詳細については、「Windows Server 2003 TechCenter」(http://go.microsoft.com/fwlink/?LinkId=45315) を参照してください (このサイトは英語の場合があります)。


XESE.DLL ファイルが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Xese.dll というファイルの Version キーの値を判断します。

Exchange Server アナライザでこのファイルの Version 値を取得できることは Xese.dll ファイルが存在することを示し、この場合はエラーが表示されます。

ESE ベースのウイルス対策プログラムの中には、Exchange のインフォメーション ストアと ESE (Extensible Storage Engine) の間のサポートされていないインターフェイスを使用しているものがあります。この種類のソフトウェアを使用していると、ソフトウェアの実装に誤りがある場合に、データベースの損傷やデータ損失が発生するリスクを負うことになります。

ESE ベースのスキャナは、インストール中に、ESE ベースのウイルス対策プログラムのサービスに依存するように Microsoft Exchange Information Store サービスを変更します。これにより、ESE ベースのウイルス対策プログラムのサービスが開始されてから、Microsoft Exchange Information Store サービスが開始されます。ESE ベースのウイルス対策プログラムが起動すると、Exchange Server に含まれているバージョンの Ese.dll の名前が一時的に Xese.dll に変更され、元のファイルは ESE ベースのウイルス対策プログラムのバージョンの Ese.dll に置き換えられます。ESE ベースのウイルス対策プログラムに組み込まれているバージョンの Ese.dll がロードされたら、Exchange Server に組み込まれているバージョンの方は Ese.dll という名前に戻され、Microsoft Exchange Information Store サービスの開始処理が完了します。

この警告を解決するには、以下の対策を行います。

  1. Exchange Server コンピュータでは、Microsoft 以外の企業による ESE の実装を使用しないことを強くお勧めします。Microsoft 製品サポート サービスに連絡すると、問題を特定しやすくするために ESE ベースのウイルス対策プログラムを無効にするよう依頼されることがありますが、問題の根本的な原因が正しく診断された後は、再びそのプログラムを有効にしてもかまいません。

  2. 最も広く使用されている ESE ベースのウイルス対策プログラムは、Sybari Software 製の Antigen for Microsoft Exchange です。Microsoft と Sybari 社は、Sybari Antigen を無効にすることが、問題の原因を特定するために有効なトラブルシューティングの手順であることに同意しています。Sybari Software に連絡する方法については、Sybari Software Web サイト (http://www.sybari.com) を参照してください (このサイトは英語の場合があります)。

    注 :
    サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。

  3. AntiVirus API (AVAPI) とも呼ばれる、Virus Scanning Application Programming Interface (VSAPI) をサポートしているウイルス対策プログラムを使用することをお勧めします。

Exchange Server でのウイルス対策ソフトウェアの実行に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=)

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=)


ハードウェア
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクション内の文書には、Microsoft® Exchange Server アナライザ ツールによるハードウェアの評価に関する詳細が記載されています。さらに、これらの文書には、Exchange Server アナライザによって検出されたハードウェアに関連するエラー、警告、および既定以外の構成を解決するための対処法も説明されています。


BIOS が旧式である
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_BIOS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMBIOSBIOSVersion キーと ReleaseDate キーの値を判断します。返される値はそれぞれ、コンピュータにインストールされている BIOS のバージョン番号とリリース日を表します。Exchange Server アナライザは Win32_ComputerSystem WMI クラスに対してもクエリを実行し、Model キーの値を判断します。

ReleaseDate の値が 1 年以上前の日付を示しており、Model キーに以下に示す文字列のいずれかが含まれていることが検出されると、警告が表示されます。

  • ProLiant DL320

  • ProLiant DL320 G2

  • ProLiant DL320 G3

  • ProLiant DL360

  • ProLiant DL360 G2

  • ProLiant DL360 G3

  • ProLiant DL360 G4

  • ProLiant DL380

  • ProLiant DL380 G2

  • ProLiant DL380 G3

  • ProLiant DL380 G4

  • ProLiant DL560

  • ProLiant DL570 G3

  • ProLiant DL580

  • ProLiant DL580 G2

  • ProLiant DL580 G3

  • ProLiant DL585 G1

  • ProLiant ML350

  • ProLiant ML350 G2

  • ProLiant ML350 G3

  • ProLiant ML350 G4

  • ProLiant ML370

  • ProLiant ML370 G2

  • ProLiant ML370 G3

  • ProLiant ML370 G4

  • ProLiant ML530

  • ProLiant ML530 G2

  • ProLiant ML570

  • ProLiant ML570 G2

  • ProLiant ML750

この警告を修正するには、新しいバージョンの BIOS を取得して更新する方法について、Hewlett-Packard Web サイトの「ROM-BIOS/Firmware Updates」(http://h18023.www1.hp.com/support/files/server/us/romtabl.html) を参照してください (このサイトは英語の場合があります)。

Hewlett-Packard ProLiant サーバーの詳細については、Hewlett-Packard の Web サイト (http://www.hp.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Dell PowerEdge サーバーの BIOS が古い
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_BIOS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMBIOSBIOSVersion キーの値を判断します。返される値は、コンピュータにインストールされている BIOS のバージョン番号を表しています。Exchange Server アナライザは Win32_ComputerSystem WMI クラスに対してもクエリを実行し、Model キーの値を判断します。

Model キーに次の文字列のいずれかが含まれており、SMBIOSBIOSVersion がモデルの最新のバージョンではないことが検出されると、警告が表示されます。

  • PowerEdge 2400

  • PowerEdge 2450

  • PowerEdge 2500

  • PowerEdge 2550

  • PowerEdge 2600

  • PowerEdge 2650

  • PowerEdge 2800

  • PowerEdge 2850

  • PowerEdge 3250

  • PowerEdge 4300

  • PowerEdge 4350

  • PowerEdge 4400

  • PowerEdge 4600

  • PowerEdge 6300

  • PowerEdge 6350

  • PowerEdge 6400

  • PowerEdge 6450

  • PowerEdge 6600

  • PowerEdge 6650

  • PowerEdge 6800

  • PowerEdge 6850

  • PowerEdge 7150

  • PowerEdge 7250

  • PowerEdge 8450

この警告を修正するには、新しいバージョンの BIOS を取得して更新する方法について、Dell Web サイトのダウンロード ページ (http://support.dell.com/support/downloads) を参照してください (このサイトは英語の場合があります)。

Dell PowerEdge サーバーの詳細については、Dell Web サイト (http://www.dell.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


BIOS 用の更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Win32_BIOS に対してクエリを実行し、SMBIOSBIOSVersion キーの値を判断します。返される値は、コンピュータにインストールされている BIOS のバージョン番号とリリース日を表しています。さらに、Exchange Server アナライザは、Win32_ComputerSystem WMI クラスを調べ、Model キーの値を判断します。そのコンピュータが、BIOS のバージョンが REJT48A より古い IBM X445 システムであることが検出されると、エラーが表示されます。

このエラーを修正し、新しい BIOS バージョンの入手と更新に関する情報を得るには、IBM Web サイト「Flash BIOS Update (DOS update package) - IBM eServer xSeries 445」(http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54089) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


クラスタ ネットワークのインターフェイス カードで DHCP が有効になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ内にあるすべてのネットワーク インターフェイスについて、DHCPEnabled キーの値を判断します。クラスタ内のいずれかのプライベート ネットワーク インターフェイスについて、DHCPEnabled の値が True に設定されていることが検出されると、エラーが表示されます。

DHCPEnabled WMI キーの値が True の場合、ネットワーク インターフェイスが DHCP (Dynamic Host Configuration Protocol) を使用するように構成されていることを示しています。Microsoft では、Windows サーバー クラスタのプライベート ネットワーク上にあるノードのために DHCP を使用することはサポートしていません。また、Windows サーバー クラスタ内のパブリック ネットワーク上にあるノードについては、静的 IP アドレスを使用することをお勧めします。DHCP によるパブリック ネットワークの動的な構成を使用することは推奨されていません。これは、DHCP リースの更新が失敗したためにクラスタの動作が中断する場合があるためです。さらに、DHCP によるプライベート ネットワークでの動的構成の使用はサポートされていないため、この方法は実行しないでください。

この問題を解決するには、静的 IP アドレスを使用するようにプライベート ネットワークのネットワーク インターフェイスを再構成する必要があります。アドレスは以下の範囲内で選択することをお勧めします。

  • 10.0.0.0 ～ 10.255.255.255 (クラス A ネットワーク)

  • 172.16.0.0 ～ 172.31.255.255 (クラス B ネットワーク)

  • 192.168.0.0 ～ 192.168.255.255 (クラス C ネットワーク)

このエラーを修正するには

  1. [ネットワーク接続] ウィンドウで、プライベート ネットワーク アダプタのネットワーク接続を右クリックし、[プロパティ] をクリックします。

  2. [インターネット プロトコル (TCP/IP)] をクリックし、[プロパティ] をクリックします。

  3. [全般] タブで、パブリック ネットワーク用アダプタのサブネットまたはネットワークとは異なるサブネットまたはネットワーク上の静的 IP アドレスを入力します。プライベート アダプタでの使用に適した IP アドレスとしては、たとえば、サブネット マスクを 255.0.0.0 にして、ノード 1 には 10.10.10.10、ノード 2 には 10.10.10.11 を指定します。パブリック ネットワークで 10.x.x.x. ネットワークと 255.0.0.0 サブネット マスクを使用している場合は、他に選択できるプライベート ネットワーク IP とサブネットを使用します。

  4. [デフォルト ゲートウェイ] ボックスに、値が設定されていないことを確認します。

  5. [次の DNS サーバーのアドレスを使う] ボックスに、値が定義されていないことを確認します。

  6. [詳細設定] をクリックします。

  7. [DNS] タブで、定義済みの値がないことを確認します。[この接続のアドレスを DNS に登録する] チェック ボックスと [この接続の DNS サフィックスを DNS 登録に使う] チェック ボックスがオフになっていることを確認します。

  8. [WINS] タブで、定義済みの値がないことを確認します。[NetBIOS over TCP/IP を無効にする] をクリックします。

  9. ダイアログ ボックスを閉じるときに、次のダイアログが表示されることがあります。"この接続には空のプライマリ WINS アドレスが設定されています。続行しますか?" というダイアログが表示されたら、[はい] をクリックします。

  10. [OK] をクリックして変更を保存します。

  11. クラスタ内に存在する他のすべてのノードについて、ここまでの手順を完了します。

Windows サーバー クラスタの最適なネットワーク構成の詳細については、『Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003』(http://go.microsoft.com/fwlink/?linkid=34304) を参照してください (このサイトは英語の場合があります)。

クラスタの適切なハートビート構成の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


コンピュータのプライマリ DNS サフィックスが、コンピュータの配置先ドメインの FQDN と一致しない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-05-18

Microsoft® Exchange Server アナライザ ツールは、以下のレジストリ エントリを読み取り、この Exchange Server のプライマリ ドメイン ネーム システム (DNS) サフィックスを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\NV Domain

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain

Exchange Server アナライザで、NV Domain の値と Domain の値が一致しないことが検出されると、警告が表示されます。

NV Domain レジストリ値には、コンピュータのプライマリ DNS サフィックスが含まれます。Domain レジストリ値には、コンピュータのプライマリ DNS ドメインが含まれます。既定では、コンピュータの完全修飾ドメイン名 (FQDN) の一部であるプライマリ DNS サフィックスは、そのコンピュータの配置先である Active Directory® ディレクトリ サービス ドメインの名前と一致している必要があります。名前が一致していないと、DNS 登録を正しく実行できません。コンピュータの DNS ドメイン名が Active Directory のドメイン名と一致しない場合は、コンピュータのシステム イベント ログに 22 分おきにエラーが記録されます。このような状態を、名前空間の不整合といいます。異なるプライマリ DNS サフィックスを許可するには、ドメイン オブジェクト コンテナ内にmsDS-AllowedDNSSuffixes と呼ばれる Active Directory 属性を作成して、許可されているサフィックスの制限リストを作成します。

名前空間の不整合が正しく構成されていることを確認するための手順は、Active Directory のドメイン コントローラに使用するオペレーティング システムによって異なります。

  • Active Directory のドメイン コントローラで Microsoft Windows® 2000 Server オペレーティング システムを実行している場合は、Microsoft サポート技術情報の文書番号 258503「DNS Registration Errors 5788 and 5789 When DNS Domain and Active Directory Domain Name Differ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258503) に説明されている手順に従うことにより、名前空間を正しく構成できます (このサイトは英語の場合があります)。この文書には、意図しない名前空間の不整合を修正するための手順、および名前空間の不整合を意図的に構成する場合の正しい手順が記載されています。

  • Active Directory のドメイン コントローラで Microsoft Windows Server™ 2003 を実行している場合で、名前空間の不整合を意図しないときは、以下に示す最初の手順に従って、意図しない名前空間の不整合を修正し、この警告を解決します。Active Directory のドメイン コントローラで Windows Server 2003 を実行している場合で、名前空間の不整合を意図する場合は、以下に示す 2 番目の手順に従って、名前空間の不整合を正しく構成します。

以下に示す 2 番目の手順を実行するには、Active Directory サービス インターフェイス (ADSI) Edit や LDP (Ldp.exe) ツールなどの、Active Directory エディタを使用する必要があります。LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745) を参照してください。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Windows Server 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

名前空間の不整合を意図しない場合

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [コンピュータ名] タブをクリックします。

  3. [変更] をクリックします。[コンピュータ名の変更] ダイアログ ボックスが表示されます。

  4. [詳細] をクリックします。[DNS サフィックスと NetBIOS コンピュータ名] ダイアログ ボックスが表示されます。

  5. [メインのメンバシップが変更されるときにプライマリ DNS サフィックスを変更する] チェック ボックスをオンにします。

  6. [OK] をクリックして変更を保存したら、[OK] をクリックして [コンピュータ名の変更] ダイアログ ボックスを閉じます。

  7. [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じ、コンピュータを再起動して変更を有効にします。

名前空間の不整合を意図する場合

  1. 上記の手順に従って、[ドメインのメンバシップが変更されるときにプライマリ DNS サフィックスを変更する] チェック ボックスがオフになっていることを確認します。

  2. ドメイン オブジェクト コンテナで msDS-AllowedDNSSuffixes という Active Directory 属性を変更します。ADSI Edit を使用してこの属性を変更する場合は、以下の手順を実行します。

    1. 修正するドメインのドメイン ディレクトリ パーティションをダブルクリックします。

    2. ドメイン コンテナ オブジェクトを右クリックし、[プロパティ] をクリックします。

    3. [Attribute Editor] タブの [属性] ボックスで、属性 [msDS-AllowedDNSSuffixes] をダブルクリックします。

    4. [Multi-valued String Editor] ダイアログ ボックスの [Value to add] ボックスに DNS サフィックスを入力し、[追加] をクリックします。

    5. ドメインのすべての DNS サフィックスを入力したら、[OK] をクリックします。

    6. [OK] をクリックして、そのドメインの [プロパティ] ダイアログ ボックスを閉じます。

    7. 複数のドメインを同様に設定する場合は、この手順を繰り返します。

msDS-AllowedDNSSuffixes 属性の詳細については、Windows Server 2003 ヘルプおよびサポート センターを参照してください。この属性を編集する手順の詳細については、ドメイン名の変更を実装するためのステップバイステップ ガイド (http://go.microsoft.com/fwlink/?LinkId=41359) を参照してください (このドキュメントは英語の場合があります)。


BIOS 用の重要な更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは、Win32_BIOS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMBIOSBIOSVersion キーの値を判断します。SMBIOSBIOSVersion キーの値は、サーバーにインストールされている BIOS のバージョンを表します。また、Exchange Server アナライザは Win32_ComputerSystem WMI クラスに対してクエリを実行し、Model キーの値も判断します。Model キーの値は、ハードウェアの製造元が提供したとおりに、ハードウェアのモデルに関する情報を表します。

Model キーが eserver xSeries 445 で始まるサーバーで、Version キーの値が 42B であることが検出されると、エラーが表示されます。このエラーは、IBM xSeries 445 サーバーの BIOS を更新する必要があることを示しています。

42B バージョンの BIOS ファームウェアには、データの破損を引き起こす可能性がある既知の問題が存在します。この問題が発生するのは、BIOS 42B (Version 1.15) がインストールされている X445 システムに限られます。この問題は、BIOS 45A で修正されています。できだけ早期に、このサーバーの BIOS を 45A 以降のものに更新する必要があります。

このエラーを修正するには

  1. この問題の詳細については、IBM の Web site「Flash BIOS Update (DOS update package) - IBM eServer xSeries 445」(http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54089#BIOSVersion) を参照してください (このサイトは英語の場合があります)。

  2. 詳細については、BIOS 更新プログラムの Readme ファイル (ftp://ftp.software.ibm.com/pc/pccbbs/pc_servers/39y4888.txt) を参照してください (このファイルは英語の場合があります)。

  3. BIOS 更新プログラムは、IBM の Web サイト (http://www-307.ibm.com/pc/support/site.wss/license.do?filename=pc_servers/26r0663.exe) からダウンロードします (このサイトは英語の場合があります)。

  4. サーバーの BIOS を更新します。

BIOS 用のこの重要な更新プログラムの適用の詳細については、IBM の Web サイト (http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-3TEPF6) を参照してください。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


現在のプロセッサ速度が最大可能速度に達していない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Processor Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、MaxClockSpeed および CurrentClockSpeed の現在の値を判断します。CurrentClockSpeed の値が MaxClockSpeed の値より小さいことが検出されると、警告が表示されます。

CurrentClockSpeed 値は、各プロセッサの現在の速度 (MHz) です。MaxClockSpeed は、各プロセッサの最高速度 (MHz) です。この警告が表示された場合は、Exchange サーバー上の 1 つ以上のプロセッサが最高速度で動作していないことを示しています。これに対する既知の原因には、次のものがあります。

  1. Exchange Server が、Windows 2000 Server Service Pack 3 以降がインストールされていない、Microsoft Windows® 2000 Server または Windows 2000 Advanced Server を実行しているコンピュータにインストールされている。Windows 2000 Service Pack 3 では、WMI が MaxClockSpeed または CurrentClockSpeed の正しい値を返さないという問題が修正されました。

  2. Exchange サーバーの BIOS にある省電力設定が正しくないために、プロセッサが強制的に省電力モードの低い速度で実行させられている可能性がある。

この警告を修正するには

  1. Exchange Server が、Windows 2000 Server Service Pack 3 以降がインストールされていない、Windows 2000 Server または Windows 2000 Advanced Server を実行しているコンピュータにインストールされている場合は、最新の Service Pack をインストールする必要があります。Windows 2000 の最新の Service Pack の詳細については、Windows 2000 Service Pack Web サイト (http://go.microsoft.com/fwlink/?LinkId=18353) を参照してください (このサイトは英語の場合があります)。

  2. Exchange Server が、Windows 2000 Service Pack 3 以降がインストールされている、Windows 2000 Server または Windows 2000 Advanced Server を実行しているコンピュータにインストールされている場合は、Exchange サーバーの BIOS 設定を確認してください。また、BIOS や、コントロール パネルまたはデバイス マネージャにある電源管理設定も確認する必要があります。

システム BIOS、プロセッサ、および電源管理設定の表示および構成の方法については、ハードウェアの製造元に問い合わせてください。

Windows 2000 Server の電源管理機能の詳細については、Microsoft サポート技術情報の文書番号 244806「Windows 2000 でのパワーマネジメントの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=244806) を参照してください。

Microsoft Windows Server™ 2003 の電源管理機能の詳細については、Windows Server 2003 を実行しているコンピュータの [スタート] ボタンから実行できる Windows Server 2003 のヘルプとサポート センターで、「電源管理」および「電源オプション」を検索してください。

Windows 2000 Server の電源管理機能の詳細については、Windows 2000 Server を実行しているコンピュータの [スタート] ボタンから実行できる Windows 2000 Server のヘルプで、「電源管理」および「電源オプション」を参照してください。


Windows Server 2003 で DisableDHCPMediaSense が正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-10-02

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、メディア検出機能が正しく構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSense

また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Windows のバージョンを確認します。

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合は Windows® 2000 Server オペレーティング システムを、値が 5.2 の場合は Windows Server™ 2003 オペレーティング システムを実行しています。

さらに、Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、ClusSvc (Microsoft Windows クラスタ サービス) の Started キーの値を判断します。この値が True のときは Windows クラスタ サービスが実行されており、False のときは Windows クラスタ サービスは実行されていません。

Windows クラスタ サービスが Windows Server 2003 Enterprise Edition または Windows Server 2003, Datacenter Edition 上で実行され、かつ DisableDHCPMediaSense レジストリ キーが 1 に設定されていることが検出されると、警告が表示されます。

Windows Server 2003 クラスタ サービスを使用している場合は、Windows 2000 Server での動作とは異なり、ネットワーク接続が失われても既定では TCP/IP スタックはアンロードされません。その結果、DisableDHCPMediaSense レジストリ キーを設定する必要はなくなりました。Windows 2000 Server では、ネットワーク接続が失われると TCP/IP スタックがアンロードされたため、Exchange 仮想サーバーのリソースを含め、IP アドレスに依存するすべてのクラスタ リソースがオフラインになりました。ネットワークがオンラインに戻ると、クラスタ リソースのネットワークでの役割は既定の設定 (クライアントおよびプライベート) に戻ります。メディア検出機能を既定で無効にすると、ネットワークの役割が保持されると同時に、IP アドレスに依存するリソースもオンラインに維持されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. 右側のペインで、右クリックして DisableDHCPMediaSense レジストリ値を変更 (無効にするために 0 に設定) するか削除します。

  4. レジストリ エディタを終了します。

  5. すべてのクラスタ リソースを別のノードに移動するか、またはリソースをオフラインにします。次に、クラスタ ノードを再起動して変更を有効にします。

  6. クラスタ内のこの警告が発生したその他のすべてのノードに対してこの手順を繰り返します。

Microsoft Windows レジストリの詳細については、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

メディア検出機能と Windows クラスタの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 254651「クラスタ ネットワークの役割が自動的に変更される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=254651)

  • 文書番号 239924「Windows で TCP/IP のメディア検出機能を無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=239924)

  • 文書番号 242430「クラスタのクロスオーバー ケーブルと構成中に、利用可能でないネットワーク アダプタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=242430)

  • 文書番号 278007「Windows Server 2003 クラスタで利用可能な機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=278007)


Windows 2000 Server で DisableDHCPMediaSense が正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、メディア検出機能が正しく構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSense

また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Windows のバージョンを判断します。

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合は、コンピュータで Microsoft Windows NT® Server 4.0 が実行されています。値が 5.0 の場合はコンピュータで Microsoft Windows® 2000 Server オペレーティング システムが実行されており、値が 5.2 の場合は Microsoft Windows Server™ 2003 オペレーティング システムが実行されています。

さらに、Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、ClusSvc (Microsoft Windows クラスタ サービス) の Started キーの値を判断します。この値が True のときは Windows クラスタ サービスが実行されており、False のときは Windows クラスタ サービスは実行されていません。

Exchange Server アナライザによって、Windows クラスタ サービスが Windows 2000 Advanced Server または Windows 2000 Datacenter Server 上で実行されていること、および DisableDHCPMediaSense レジストリ キーが存在する場合に値が 1 に設定されていないことが検出されると、警告が表示されます。

Windows 2000 Server クラスタ サービスの使用時には、ネットワーク接続が切断されると、TCP/IP スタックはアンロードされます。これは、IP アドレスに依存していたすべてのクラスタ リソースが、Exchange 仮想サーバー内のリソースを含めてオフラインになることを意味します。ネットワークがオンラインに戻ると、クラスタ リソースのネットワークでの役割は既定の設定 (クライアントおよびプライベート) に戻ります。このような状態の発生を防止するため、すべての Windows 2000 Server ベースのクラスタでメディア検出機能を無効にすることをお勧めします。メディア検出機能は、Windows Server 2003 ベースのクラスタでは自動的に無効にされます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

  3. [Parameters] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。名前には「DisableDHCPMediaSense」と入力し、Enter キーを押します。

  4. 右側のペインで、[DisableDHCPMediaSense] をダブルクリックし、[値のデータ] ボックスに「1」と入力します。

  5. レジストリ エディタを終了します。

  6. すべてのクラスタ リソースを別のノードに移動するか、それらをオフラインにします。次に、クラスタ ノードを再起動して変更を有効にします。

  7. この警告が生成されたクラスタ内のすべてのノードで、この手順を繰り返します。

Microsoft Windows レジストリの詳細については、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

メディア検出機能と Windows クラスタの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 254651「クラスタ ネットワークの役割が自動的に変更される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=254651)

  • 文書番号 239924「Windows で TCP/IP のメディア検出機能を無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=239924)

  • 文書番号 242430「クロスオーバー ケーブルのクラスタ構成の間、利用できないネットワーク アダプタ。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=242430)

  • 文書番号 278007「Windows Server 2003 クラスタで利用可能な機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=278007)


ディスク タイムアウト値が既定値に設定されていない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ディスク タイムアウト値が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue

TimeOutValue が存在し、10 以外の値で構成されており、サーバーがクラスタ化されていないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。また、TimeOutValue が存在し、20 以外の値で構成されており、サーバーがクラスタ化されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ディスク タイムアウト値は、ハード ディスクがコマンドに応答するまで Microsoft Windows® が待つ時間を定義するレジストリ設定です。クラスタ化されていないシステムでは、このキーは存在せず、すべてのディスクに対して既定値の 10 秒が使用されます。Windows クラスタにはこのキーが存在し、既定値の 20 秒が使用されます。タイムタウトの時間がこのレジストリ設定の値より長い場合、Windows によってエラーが表示され、ディスク アクセスが停止されます。マルチパス ディスク アクセス ソフトウェアを実行している場合、このキーはより大きな値に設定されることがあります。マルチパス ソフトウェアを使用すると、冗長性のために複数の物理的なパス (ファイバなど) を単一のディスク ドライブに接続できます。マルチパス ソフトウェアは、Windows で処理するディスクへのハンドルが 1 つだけになるように、複数の物理的な接続を管理します。

ホスト バス アダプタ (HBA) やその他の記憶域コントローラを取り付けると、このキーの作成と構成が行われる場合があります。これらのためのドライバをインストールまたは再インストールすると、TimeOutValue レジストリ値は、それらのドライバに必要な値で上書きされます。ハードウェア ベンダに連絡して、実際の構成に適した TimeOutValue レジストリ値を判断することが必要な場合もあります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

  3. 右側のペインで、[TimeOutValue] エントリを削除します。または、[TimeOutValue] エントリをダブルクリックし、以下のいずれかの値に設定します。

    • クラスタ化されていないサーバーでは、値を "10" に設定します。

    • クラスタ化されているサーバーでは、値を "20" に設定します。

    • ハードウェアの製造元が、クラスタ化されたシステムやクラスタ化されていないシステムに対して異なる値を推奨している場合は、上の値の代わりに、ハードウェアの製造元の値を使用します。

  4. レジストリ エディタを終了し、コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

クラスタ化されたシステムでの TimeOutValue エントリの詳細については、Microsoft サポート技術情報の文書番号 818877「Windows Server 2003 の Windows クラスタ機能のインストールまたはアップグレード後、クラスタ サーバーでドライブへの接続がタイムアウトする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=818877) を参照してください。


DNS 検索順序が空になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DNSServerSearchOrder に値が設定されているかどうかを判断します。Exchange サーバーで、このキーの値が空になっている場合、警告が表示されます。

この警告は、このコンピュータに存在する 1 つ以上のネットワーク アダプタに、DNS の IP アドレスが関連付けられていないことを示しています。そのためこのコンピュータが他のコンピュータに接続しようとするときには、IP アドレスを探してローカル ネットワーク全体にブロードキャストが行われています。したがって名前解決の速度が低下するため、Exchange の速度が低下する場合があります。

有効な DNS サーバーの IP アドレスを、少なくも 1 つ入力しておくことをお勧めします。コンピュータに複数のアダプタが搭載されている場合は、すべてのアダプタで、有効な DNS サーバーの IPアドレスが少なくとも 1 つ設定されていることを確認してください。

ネットワーク アダプタに対して DNS の IP アドレスを設定するには

  1. [ネットワーク接続] ウィンドウで、適切なローカル エリア ネットワーク アダプタを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[インターネット プロトコル (TCP/IP)] をダブルクリックします。

  3. [インターネット プロトコル (TCP/IP)] ページの [全般] タブで、有効な DNS サーバーの IP アドレスを 1 つ以上入力し、[OK] をクリックします。

Exchange と共に動作する DNS の構成の詳細については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322856) を参照してください。


ハートビート接続に既定のゲートウェイが構成されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_NetworkAdapter Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NetConnectionID キーの値を判断します。NetConnectionID キーの値に、文字列として Internal または HEART が含まれている場合、インターフェイスがクラスタのプライベート (ハートビート) ネットワークであることを示しています。

Exchange Server アナライザ ツールはまた、Win32_NetworkAdapterConfiguration WMI クラスに対してもクエリを実行し、DafaultPGateway キーに値が設定されているかどうかを判断します。この値が設定されている場合は、このネットワーク インターフェイスに対して既定のゲートウェイが構成されていることを示しています。

クラスタ ハートビート ネットワークに使用されているネットワーク インターフェイス上の DefaultPGateway キーに値が設定されていることが検出されると、警告が表示されます。

プライベート クラスタ ネットワークは内部のクラスタ通信に使用されるため、既定のゲートウェイを構成する必要はありません。通信の問題が発生しないようにするために、クラスタ プライベート ネットワーク アダプタに使用されているネットワーク アダプタから、不要なネットワーク トラフィックをすべて削除することをお勧めします。

この警告を修正するには

  1. [ネットワーク接続] ウィンドウを開きます。[マイネットワーク] を右クリックし、[プロパティ] をクリックします。または、[マイネットワーク] がデスクトップに表示されていない場合は、[スタート] ボタン、[プログラム]、[アクセサリ] 、[通信]、[ネットワーク接続] の順にクリックします。

  2. [ネットワーク接続] ウィンドウで、プライベート ネットワークに使用されているネットワーク アダプタを右クリックし、[プロパティ] をクリックします。

  3. [インターネット プロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  4. [次の IP アドレスを使用する] で、既定のゲートウェイ IP アドレスを削除します。

  5. [OK] を 2 回クリックして、変更を保存します。

  6. クラスタ内の各ノードに対して、手順 1. ～ 5. を繰り返します。

Windows サーバー クラスタでのプライベート ネットワークの推奨設定の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


ハートビート接続に DNS 検索アドレスが構成されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_NetworkAdapter Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NetConnectionID キーの値を判断します。NetConnectionID キーの値に、文字列として Internal または HEART が含まれている場合、インターフェイスがクラスタのプライベート (ハートビート) ネットワークであることを示しています。

また、Exchange Server アナライザは Win32_NetworkAdapterConfiguration WMI クラスに対してもクエリを実行し、DNSServerSearchOrder キーに値が設定されているかどうかを判断します。この値が設定されている場合は、このネットワーク インターフェイスに対してドメイン ネーム システム (DNS) 検索アドレスが構成されていることを示します。

クラスタ ハートビート ネットワークに使用されているネットワーク インターフェイスの DNSServerSearchOrder キーに値が設定されていることが検出されると、警告が表示されます。

プライベート クラスタ ネットワークは内部のクラスタ通信に使用されるため、DNS サーバーを構成する必要はありません。通信の問題が発生しないようにするために、クラスタ プライベート ネットワーク アダプタに使用されているネットワーク アダプタから、不要なネットワーク トラフィックをすべて削除することをお勧めします。

この警告を修正するには

  1. [ネットワーク接続] ウィンドウを開きます。[マイネットワーク] を右クリックし、[プロパティ] をクリックします。または、[マイネットワーク] がデスクトップに表示されていない場合は、[スタート] ボタン、[プログラム]、[アクセサリ] 、[通信]、[ネットワーク接続] の順にクリックします。

  2. [ネットワーク接続] ウィンドウで、プライベート ネットワークに使用されているネットワーク アダプタを右クリックし、[プロパティ] をクリックします。

  3. [インターネット プロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  4. [詳細設定] をクリックします。

  5. [DNS] タブで、DNS サーバー アドレスを選択し、[削除] をクリックします。一覧表示された各 DNS サーバー アドレスに対して、この手順を繰り返します。

  6. [この接続のアドレスを DNS に登録する] チェック ボックスと [この接続の DNS サフィックスを DNS 登録に使う] チェック ボックスをオフにします。

  7. [OK] を 3 回クリックして、変更を保存します。

  8. クラスタ内の各ノードについて、手順 1. ～ 7. を繰り返します。

Windows サーバー クラスタでのプライベート ネットワークの推奨設定の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


ハートビート接続に WINS アドレスが割り当てられている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_NetworkAdapter Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NetConnectionID キーの値を判断します。NetConnectionID キーの値に、文字列として Internal または HEART が含まれている場合、インターフェイスがクラスタのプライベート (ハートビート) ネットワークであることを示しています。

Exchange Server アナライザはさらに、Win32_NetworkAdapterConfiguration WMI クラスに対してもクエリを実行し、WINSPrimaryServer キーに値が設定されているかどうかを判断します。値が設定されている場合、このネットワーク インターフェイスに対してプライマリ WINS (Windows Internet Name Service) アドレスが構成されていることを示します。

Exchange Server アナライザによって、クラスタのハートビート ネットワークに使用されているネットワーク インターフェイスの WINSPrimaryServer キーに値が設定されていることが検出されると、警告が表示されます。

プライベート クラスタ ネットワークは、クラスタの内部的な通信に使用されるため、WINS を構成したり、NetBIOS を使用したりする必要はありません。通信の問題が発生しないようにするために、クラスタ プライベート ネットワーク アダプタとして使用されているネットワーク アダプタから、不要なネットワーク トラフィックをすべて削除することをお勧めします。

この警告を修正するには

  1. [ネットワーク接続] ウィンドウを開きます。[マイ ネットワーク] を右クリックし、[プロパティ] をクリックします。または、デスクトップに [マイ ネットワーク] が表示されていない場合は、[スタート] ボタン、[プログラム]、[アクセサリ]、[通信]、[ネットワーク接続] の順にクリックします。

  2. [ネットワーク接続] ウィンドウで、プライベート ネットワークに使用されているネットワーク アダプタを右クリックし、[プロパティ] をクリックします。

  3. [インターネット プロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  4. [詳細設定] をクリックします。

  5. [WINS] タブで、WINS アドレスを選択してから [削除] をクリックします。一覧にある WINS アドレスそれぞれについて、この手順を繰り返します。

  6. [NetBIOS 設定] で [NetBIOS over TCP/IP を無効にする] を選択します。

  7. [OK] を 3 回クリックして変更を保存します。1 回目の [OK] をクリックした後に、次のダイアログが表示されることがあります。"この接続には空のプライマリ WINS アドレスが設定されています。続行しますか?" というダイアログが表示されたら、[はい] をクリックします。

  8. クラスタ内の各ノードについて、手順 1. ～ 7. を繰り返します。

Windows サーバー クラスタでのプライベート ネットワークの推奨設定の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


ハートビート接続が TCP/IP バインド順序で最初に設定されており、パブリック接続ではない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、2 つの Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次の操作を行います。

  • Win32_NetworkConfiguration WMI クラスに対してクエリを実行し、クラスタ内のすべてのネットワーク インターフェイスについて SettingID キーの値を判断します。SettingsID キーの値は、一意のネットワーク アダプタを表す GUID です。

  • Win32_NetworkAdapter WMI クラスに対してクエリを実行し、Exchange クラスタでプライベート ネットワーク通信に使用されているネットワーク アダプタを判断します。プライベート ネットワークは、クラスタ ハートビートなどクラスタ内部の通信に使用されます。

  • また、Exchange Server アナライザは次のレジストリ エントリを調べ、ネットワーク アダプタのバインド順序を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Linkage\Bind

Bind レジストリの値は複数行文字列値で、ネットワーク アダプタのバインド順による一覧を含んでいます。一覧の最初のエントリは最初にバインドされるネットワーク アダプタ、2 番目のエントリはバインド順で 2 番目のネットワーク アダプタです。

クラスタのハートビート ネットワーク アダプタがバインド順序の最初であることが検出されると、警告が表示されます。

この問題を修正するには、パブリック ネットワーク アダプタをバインド一覧の先頭に置いて、最初にバインドされるようにします。パブリック ネットワーク アダプタが複数個ある場合、プライベート ハートビート ネットワーク アダプタを必ず一覧の最後に置きます。ハートビート ネットワーク アダプタが一覧の先頭にあると、Service Pack とアップグレードが正常にインストールできなくなる可能性があります。

この警告を修正するには

  1. [ネットワーク接続] ウィンドウで、[詳細設定] をクリックし、[詳細設定] をクリックします。

  2. [アダプタとバインド] タブをクリックします。

  3. [接続] フィールドで、プライベート ネットワーク アダプタを選択し、下向きの矢印 を使用してそのプライベート ネットワーク アダプタを一覧の最後に移動します。

  4. クラスタ内の各ノードについて、以上の手順を繰り返します。

Windows サーバー クラスタの最適なネットワーク構成の詳細については、「Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003」(http://go.microsoft.com/fwlink/?linkid=34304) を参照してください (このサイトは英語の場合があります)。

クラスタの適切なハートビート構成の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


ハートビートのネットワーク速度が自動検出されるように設定されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_NetworkAdapter Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NetConnectionID キーの値を判断します。NetConnectionID キーの値に、文字列として Internal または HEART が含まれている場合、インターフェイスがクラスタのプライベート (ハートビート) ネットワークであることを示しています。

Exchange Server アナライザは次のレジストリ値も読み取り、クラスタのハートビート ネットワークに使用されているネットワーク インターフェイス カードのリンク速度と二重化の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\<NetworkCardDeviceID>\SpeedDuplex

さらに、Exchange Server アナライザは次のレジストリ値を読み取り、ネットワーク速度の自動検出が有効かどうかの判断も行います。

HKLM\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\%NICDEVICEID%\Ndi\Params\SpeedDuplex\enum\0

0 キーの値に文字列 AUTO が含まれている場合、ネットワーク速度の自動検出が有効であることを示します。

Exchange Server アナライザによって、SpeedDuplex が 0 に設定されており、同時にクラスタのハートビート ネットワークに対するネットワーク速度の自動検知が有効になっていると確認されると、警告が表示されます。

クラスタ操作を円滑に行うためには、サーバー クラスタのノード間の通信が不可欠です。クラスタの通信に、複数の速度に対応したイーサネット ネットワーク アダプタを使用しており、ネットワーク速度を自動検出するようにアダプタを構成している場合、クラスタ内で、アダプタが原因となって問題が発生する可能性があります。検出処理の間、アダプタはパケットを扱うことができないので、パケットをキューに入れる必要があります。一部のアダプタは、誤って繰り返し自動検出処理を開始することがあります。このため、通信がキューに入れられて遅延します。この種類の遅延によって、クラスタ ノードが重要なパケットを直ちに受信しなくなり、クラスタ リソースの早すぎるフェールオーバーが引き起こされます。クラスタのハートビート ネットワークは、手動で 10 Mbps、半二重に設定することをお勧めします。この構成で、十分な帯域幅と信頼性の高い通信が提供されます。

この警告を修正するには

  • リンク速度は 10 Mbps、二重化の設定は半二重にしてハートビート ネットワークのインターフェイス カードを構成します。構成手順はネットワーク カードごとに異なるため、ハードウェアの製造元の指示に従ってハートビート ネットワークを正しく構成してください。これらのオプションを構成するために、更新されたドライバが必要になることがあります。

Windows サーバー クラスタでのプライベート ネットワークの推奨設定の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


ホスト バス アダプタのキューの深さが 32 に設定されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-10-11

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータにインストールされているホスト バス アダプタ (HBA) のキューの深さを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\elxstor\Parameters\Device\DriverParameter

DriverParameter の値が 32 に設定されていることが検出された場合、警告が表示されます。

HBA は、ストレージ エリア ネットワーク (SAN) 用のディスク コントローラです。HBA のキューの深さは、キューに入る未解決の要求の最大数を定義します。通常推奨される DriverParameter の値は 128 ですが、さまざまな Exchange Server コンピュータと HBA の組み合わせに対して、最適な値ではない場合があります。このため、HBA の製造元に問い合わせて、使用している特定のハードウェアに最適な値の情報を入手する必要があります。

この警告を修正するには

  1. ハードウェアの製造元に問い合わせて、使用している HBA に最適な設定を決定します。

  2. Microsoft Windows® のシステム モニタ ユーティリティを使用して、ディスクのパフォーマンスを監視します。

  3. HBA ハードウェアのファームウェアとドライバを最新のものに更新します。

Exchange Server の記憶域の設計と最適化の詳細については、Exchange Server 2003 の記憶域の最適化についての Web サイト (http://go.microsoft.com/fwlink/?linkid=49324) (英語) を参照してください。


ホット アド メモリの構成
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-02-22

Microsoft® Exchange Server アナライザ ツールは、Win32_Computer System Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、サーバーがホット アド メモリ機能をサポートするかどうかを判断します。また、Exchange Server アナライザは Win32_OperatingSystem WMI クラスに対してクエリを実行し、以下についても判断します。

  • Boot.ini ファイルに /3GB オプションが設定されているかどうか。

  • 物理アドレス拡張 (PAE) カーネルが読み込まれているかどうか。

  • サーバーでどのエディションのオペレーティング システムが実行されているか。

最後に、Exchange Server アナライザは、以下のレジストリ エントリに対してクエリを実行し、DynamicMemory 構成パラメータが存在し、正しく設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

以下のすべての条件に当てはまると判断されると、エラー メッセージが表示されます。

  • コンピュータがホット アド メモリをサポートしていて、既定で、その機能が有効になっている。

  • コンピュータが Microsoft Windows Server™ 2003 Enterprise Edition または Windows Server 2003 Datacenter Edition を実行している。

  • PAE カーネルが読み込まれている。

  • Boot.ini で /3GB オプションが設定されている。

  • DynamicMemory レジストリ構成パラメータが、設定されていない、値 0 に設定されている、または 3 より大きい値に設定されている。

注 :
コンピュータがホット アド メモリをサポートするが、ハードウェアの製造元がその機能を既定で無効にしている場合は、エラー メッセージではなく警告メッセージが表示されます。

ホット アド メモリ機能は、システム管理者がコンピュータを再起動せずに物理メモリを追加できるようにするために、Windows Server 2003 Enterprise Edition および Windows Server 2003 Datacenter Edition で導入されました。この機能は、Microsoft SQL Server などのメモリを集中的に使用するリレーショナル データベース アプリケーションをサポートするサーバーで役立ちます。ただし、Exchange Server は 4 GB を超える物理メモリを使用できないため、この機能は Exchange Server には役立ちません。

一部のコンピュータはホット アド メモリをサポートしません。ホット アド メモリをサポートするコンピュータに対して、既定でその機能を有効にするハードウェアの製造元もあれば、基本入出力システム (BIOS) 内で制御を提供するハードウェアの製造元もあります。ブート処理中にホット アド メモリが有効になった場合、オペレーティング システム カーネルは、コンピュータに今後追加される可能性があるメモリを処理するために領域を事前に割り当てる必要があります。このため、カーネル リソースは、実際にインストールされている内容ではなく、コンピュータの機能に基づいて割り当てられます。カーネル メモリは、Microsoft Exchange Server を実行するコンピュータ上の貴重なリソースです。カーネルは決してインストールされない大量のリソースをメモリに割り当てるため、および Exchange Server によって使用される物理メモリの性質により、ホット アド メモリ機能を無効にすることで、パフォーマンスやスケーラビリティの向上が実現することがあります。機能を有効のままにすると、ページ プールの最大サイズが予期したよりもはるかに小さくなる可能性があります。これにより、パフォーマンスの大幅な低下、システム ロックアップ、最終的にサービス停止が発生する可能性があります。

予期される最大ページ プール サイズの例 (サイズが大きいほど適します):

  • 240 MB ホット アド メモリがサポートされていない、またはサポートが無効になっている、4 GB の物理メモリを搭載したコンピュータ

  • 210 MB 4 GB の物理メモリを搭載しているが、最大 32 GB のホット アド メモリをサポートできるコンピュータ

  • 160 MB 4 GB の物理メモリを搭載しているが、最大 64 GB のホット アド メモリをサポートできるコンピュータ

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Windows Server 2003 Service Pack 1 (SP1) 以降を実行するコンピュータでこの問題を修正するには

  1. 以下のレジストリ パラメータを設定してホット アド メモリ機能を無効にします。

    パス

    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

    値

    DynamicMemory

    型

    REG_DWORD

    データ

    0x1
    注 :
    この構成パラメータの値は、ホット アド メモリを含むアドレス可能な最大物理メモリの量を、ギガバイト単位の数で表します。ただし、これは起動時にインストールされる物理メモリの容量が小さい場合です。値を 1 に設定すると、カーネルは合計 1 GB のシステム メモリに対して領域を予約するか、またはブート時にインストールされる物理メモリの容量が 1 GB より大きい場合には、この物理メモリに対して領域を予約します。

  2. コンピュータを再起動します。
SP1 がインストールされていない Windows Server 2003 を実行するコンピュータでこの問題を修正するには

  • ハードウェア ベンダに問い合わせて、ホット アド メモリ機能を BIOS で無効にできるかどうかを判断します。

  • ホット アド メモリをハードウェアを介して制御できない場合、Windows Server 2003 SP1 にアップグレードし、ここに記載されている解決の手順に従って DynamicMemory パラメータを実装する方法をお勧めします。SP1 にアップグレードできない場合、代わりに Boot.ini ファイルで /NOPAE オプションを設定します。このオプションを設定すると、コンピュータは 4 GB 境界を超えるメモリを認識しないようすることができます。このオプションは SP1 より前の Windows Server 2003 を実行するコンピュータで使用してください。データ実行防止 (DEP) サポートを含む新機能を誤って無効にする可能性があるので、SP1 を実行するコンピュータでは使用しないようにする必要があります。

詳細情報

Windows Server 2003 でのホット アド メモリのサポートの詳細については、『Hot-Add Memory Support in Windows Server 2003』(http://go.microsoft.com/fwlink/?linkid=57183) を参照してください (このサイトは英語の場合があります)。


Internet SCSI イニシエータ ソフトウェアが古くなっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-04-03

Microsoft® Exchange Server アナライザ ツールは Win32_SCSIController Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、iScsciPrt ドライバの DriverName キーの値を判断します。Exchange Server アナライザは、CIM_Datafile WMI クラスに対してもクエリを実行し、iScsciPrt ドライバ ファイルに記載されている Version キーの値を判断します。iScsciPrt ドライバの Version キーの部分文字列の値が 1748 より小さいことが検出されると、警告が表示されます。

iSCSI (Internet Small Computer System Interface) は、インターネット プロトコル (IP) パケット内にカプセル化した SCSI (Small Computer System Interface) コマンドを TCP/IP ネットワーク経由で送信するために設計された、IP ベースの手法です。iSCSI は IP ベースなので、LAN (Local Area Network)、WAN (Wide Area Network)、およびインターネットを介して遠隔地の記憶域の場所にデータを転送できます。Microsoft Windows オペレーティング システムでは、iSCSI ハード ディスクは、Exchange Server 2003 や Exchange 2000 Server のようなプログラムには Exchange Server コンピュータに直接接続されたハード ディスクとして表示されます。

Microsoft では、iSCSI を使用する Exchange Server 2003 または Exchange 2000 Server を展開する場合には、十分注意することをお勧めします。iSCSI は、SCSI 転送プロトコルを使用してブロック データを TCP/IP ネットワーク経由で転送するため、ネットワークとの関係が生じます。それにより、以前であれば高速な入出力パスとは見なされないコンポーネントが導入される可能性があります。スループットを最大にするには、キャッシュ動作を最大限に行うように Exchange Server を構成してテストを実施し、iSCSI トラフィックに伴う待ち時間が最小限になることを確認する必要があります。ストレージ ベンダが他の方法を推奨していない限り、入手できる Microsoft iSCSI Software Initiator の最新のビルドを使用することを強くお勧めします。

この警告を修正するには

  1. 最新バージョンの Microsoft iSCSI Software Initiator を Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=33817) からダウンロードします (このサイトは英語の場合があります)。

  2. リリース ノートの内容を、Microsoft Web サイト (http://go.microsoft.com/fwlink/?LinkId=40951) で確認します (このサイトは英語の場合があります)。

  3. Microsoft Web サイト (http://go.microsoft.com/fwlink/?LinkId=40951) にあるユーザー ガイドを読みます (このサイトは英語の場合があります)。

  4. コンピュータの完全なバックアップを作成します。

  5. 最新バージョンの更新を適用します。

Exchange 2000 Server および Exchange Server 2003 での iSCSI のサポートの詳細については、サポート技術情報の文書番号 839686「Exchange Server での iSCSI テクノロジ コンポーネントのサポート。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839686) を参照してください。

iSCSI テクノロジと Microsoft の iSCSI サポートの詳細については、Microsoft の Web サイト「Microsoft Storage Technologies - iSCSI」(http://go.microsoft.com/fwlink/?LinkId=27514) を参照してください (このサイトは英語の場合があります)。


論理ディスクおよび物理ディスクのパフォーマンス カウンタが無効になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、論理ディスクおよび物理ディスクのパフォーマンス カウンタが無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters

Disable Performance Counters の値が存在し、さらにそれが値 1 で構成されていることが検出されると、警告が表示されます。

Microsoft Windows® オペレーティング システムが動作するサーバー コンピュータに発行されるディスク関連のパフォーマンス カウンタには、以下の 2 種類があります。

  • Microsoft Win32® パフォーマンス サブシステムおよび WMI (Windows Management Instrumentation) が使用するパフォーマンス カウンタ

  • IOCTL_DISK_PERFORMANCE API を呼び出して生のカウンタ情報を取得する従来のアプリケーションが使用するパフォーマンス カウンタ

  • 既定では、Win32 および WMI によって使用されるパフォーマンス カウンタは、Microsoft Windows Server™ 2003 および Windows 2000 Server で有効になっています。既定では、生のカウンタは、上記 2 つのオペレーティング システムで無効になっています。既定ではどちらのオペレーティング システムにも存在しない Disable Performance Counters レジストリ エントリが追加され、値 1 で構成されている場合、Win32/WMI パフォーマンス カウンタは無効になり、この 2 つのカウンタのパフォーマンス データは収集できません。

Win32/WMI カウンタを無効にする最も一般的な方法は、Extensible Counter List tool (ExCtrLst.exe) を使用することです。このグラフィカルなツールは、Windows 2000 Server と Windows Server 2003 の両方のリソース キットに付属しています。これを使用すると、管理者はパフォーマンス オブジェクトの発行について有効/無効を選択的に決定できます。ExCtrLst.exe を使用してパフォーマンス オブジェクトを無効にすると、Disable Performance Counters エントリがレジストリに追加され、値 1 で構成されます。その後、無効になっていたカウンタを ExCtrLst.exe を使用して再度有効にすると、Disable Performance Counters の値が 0 に変更されます (Disable Performance Counters エントリは削除されません)。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance

  3. 右側のペインで、[Disable Performance Counters] をダブルクリックし、値を 0 に設定します。または、Disable Performance Counters エントリを削除して、カウンタを再度有効にすることもできます。

  4. レジストリ エディタを終了し、パフォーマンス データを収集するアプリケーションを再起動して、変更を有効にします。

ExCtrLst.exe の詳細については、「Exctrlst.exe: Extensible Performance Counter List」(http://go.microsoft.com/fwlink/?linkid=34436) を参照してください (このサイトは英語の場合があります)。


複数のデフォルト ゲートウェイが検出された
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DefaultIPGateway キーのインスタンスの数を判断します。各ネットワーク アダプタは、構成済みのデフォルト ゲートウェイのアドレスを、このキーを介して WMI に発行します。Exchange Server アナライザによって、構成済みの DefaultIPGateway キーのインスタンスが 2 つ以上あると判断されると、警告が表示されます。

この警告は、複数のネットワーク アダプタが検出されたこと、およびそれらのアダプタの 2 つ以上に構成済みのデフォルト ゲートウェイがあることを示します。複数のアダプタが使用され、別個のデフォルト ゲートウェイが構成されている場合、リモート ネットワーク上のコンピュータへの接続が失われることがあります。また、異なるネットワーク サブネットにリンクされた複数のデフォルト ゲートウェイを使用すると、ドメイン ネーム システム (DNS) での解決、SMTP (Simple Message Transfer Protocol) メッセージの配信、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリ、および Microsoft Office Outlook® 2003 クライアントへの新着メールの通知で問題が発生することがわかっています。これらの問題のほとんどで、Exchange Server の起動やメッセージの送受信ができなくなる可能性があります。

Exchange Server コンピュータに搭載されたネットワーク インターフェイス アダプタのうちの 1 枚に構成された 1 つのデフォルト ゲートウェイを除き、すべてのデフォルト ゲートウェイを削除することをお勧めします。Microsoft Internet Security and Acceleration (ISA) Server が同じコンピュータにインストールされている場合、Exchange Server コンピュータはしばしばマルチホーム構成になっています。Exchange Server と ISA Server を同じコンピュータで実行している場合でも、複数のデフォルト ゲートウェイを使用することはお勧めできません。Exchange Server と ISA Server を同じコンピュータにインストールしていない場合は、Exchange Server コンピュータをマルチホームにしないことをお勧めします。

この警告を修正するには

  1. [ネットワーク接続] ウィンドウを開きます。[マイ ネットワーク] を右クリックし、[プロパティ] をクリックします。または、デスクトップに [マイ ネットワーク] が表示されていない場合は、[スタート] ボタン、[プログラム]、[アクセサリ]、[通信]、[ネットワーク接続] の順にクリックします。

  2. [ネットワーク接続] ウィンドウで、削除するデフォルト ゲートウェイのエントリが含まれるネットワーク接続を右クリックし、[プロパティ] をクリックします。

  3. [インターネット プロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  4. [デフォルト ゲートウェイ] フィールドから IP アドレスを削除します。

  5. [OK] を 2 回クリックして変更を保存します。

  6. 維持する予定の 1 つのエントリを除いて、デフォルト ゲートウェイのエントリを含む他のすべてのネットワーク接続に対してこの手順を繰り返します。

複数のデフォルト ゲートウェイを使用するコンピュータで発生する問題の詳細については、Microsoft サポート技術情報の文書番号 159168「デフォルト ゲートウェイの複数使用による接続上の問題」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159168) を参照してください。

マルチホームのコンピュータでのデフォルト ゲートウェイの構成に関する詳細については、Microsoft サポート技術情報の文書番号 157025「マルチホーム コンピュータのデフォルト ゲートウェイ設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=157025) を参照してください。


ページ ファイルのサイズが物理メモリの総量より大きい
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange アナライザ ツールは、Win32_PageFile WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、MaximumSize キーの値を判断します。このキーは、現在構成されているページ ファイルの最大サイズを表しています。

Exchange アナライザは、Win32_ComputerSystem WMI クラスに対してもクエリを実行し、TotalPhysicalMemory キーに設定された値を判断します。この値は、コンピュータに搭載されている RAM の量を表します。

Exchange アナライザが、Win32_PageFile の MaximumSize キーの値が、Win32_ComputerSystem TotalPhysicalMemory キーの値の 1.5 倍より大きいと判断した場合、エラーが表示されます。

ページ ファイル (pagefile.sys) は、ハード ディスク上の隠しファイルであり、システムの RAM が不足したときに Windows が一時データを保持するために使用します。ページ ファイルは、ページング ファイルまたはスワップ ファイルとも呼ばれます。仮想メモリは、ページ ファイルと RAM で構成されます。

推奨されるページ ファイルのサイズは RAM 容量の 1.05 倍であり、その上限は 4,095 MB です。つまり、ボリュームごとに設定できる最大のページング ファイル サイズは 4,095 MB です。

注 :
ページ ファイルの断片化を防ぐために、ページング ファイル サイズの初期値と最大値を、同じ値に設定することをお勧めします。ページ ファイルの初期サイズまたは最大サイズの設定を小さく変更した場合は、コンピュータを再起動して、これらの変更の影響を確認する必要があります。これらの設定を大きくした場合は通常、再起動は必要ありません。
ページ ファイルの設定を変更するには

  1. [スタート] ボタンをクリックし、[コントロール パネル] をポイントします。次に、[システム] をクリックします。

  2. [詳細設定] タブで、[パフォーマンス] の下の [設定] をクリックします。

  3. [パフォーマンス オプション] ダイアログ ボックスの [詳細設定] タブで、[仮想メモリ] の下にある [変更] をクリックします。

  4. [ドライブ [ボリューム ラベル]] で、変更するページング ファイルを含むドライブをクリックします。

  5. [選択したドライブのページング ファイル サイズ] ボックスの [カスタム サイズ] をクリックし、[初期サイズ (MB)] および [最大サイズ (MB)] ボックスに推奨されるページ ファイル サイズを MB 単位で入力します。次に、[設定] をクリックします。

ページ ファイルの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 197379「Windows Server 2003、Windows 2000、および Windows NT で最適化と回復用にページ ファイルを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=197379)

  • 文書番号 307973「Windows でシステム障害と回復のオプションを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307973)

  • 文書番号 254649「Windows 2000、Windows XP および Windows Server 2003 のメモリ ダンプ ファイル オプションの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=254649)

  • 文書番号 241046「以上 4 GB RAM でコンピュータの Memory.dmp ファイルは作成できません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=241016)


セカンダリ WINS サーバーのアドレスが空になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、WINSSecondaryServer キーに値が設定されているかどうかを判断します。Exchange サーバーでこのキーの値が空になっていることが検出されると、警告が表示されます。

Exchange Server 2003 および Exchange 2000 Server には、NetBIOS に依存している部分があります。さらに、Microsoft Office Outlook 2003 より前の Microsoft Outlook® を実行しているクライアントでも、NetBIOS 名前解決を必要とします。たとえば、以下の Exchange 機能は、NetBIOS 名前解決に依存しています。

  • Exchange Server 2003 および Exchange 2000 Server のセットアップ プログラム (特に、クラスタ化されたサーバーの場合)

  • Exchange Server 2003 コンピュータまたは Exchange 2000 Server コンピュータで実行する Exchange Mailbox Merge Wizard (ExMerge)

  • Outlook Web Access を使用した Exchange Server 2003 または Exchange 2000 Server のメールボックスのパスワード変更

  • Exchange Server 2003 コンピュータまたは Exchange 2000 Server コンピュータで実行する Exchange システム マネージャ

組織のネットワーク トポロジによっては、この警告を無視できる場合があります。単一サブネットで構成されているネットワークでは、通常、NetBIOS ブロードキャストが Exchange デプロイメントの NetBIOS 名前解決要件を処理します。

大規模な組織では、ブロードキャストを使用した NetBIOS 名前解決が正常に機能しない場合があります。NetBIOS ブロードキャストは通常、サブネットを横断しないため、ルーティングが行われるネットワークでは別の方法で NetBIOS 名を解決する必要があります。WINS (Windows Internet Name Service) を使用することをお勧めします。WINS は、ネットワークで使用されるコンピュータおよびグループについて、NetBIOS 名の動的マッピングを登録したりクエリを実行したりするための分散データベースを実現します。WINS は、NetBIOS 名を IP アドレスと対応付けます。WINS は、ルーティングが行われる環境で NetBIOS 名前解決が原因で発生した問題を解決することを目的として設計されました。NetBIOS over TCP/IP を使用する、ルーティングが行われるネットワークでの NetBIOS 名前解決には、WINS が最適です。

大規模な組織またはサブネットに分割された組織での WINS を使用しない Exchange Server 2003 および Exchange 2000 Server の操作と機能については、十分にテストされていません。Microsoft としては、ルーティングが行われたりセグメント化されているネットワークで Exchange を実行している企業が、WINS を使用して NetBIOS 名前解決をするようお願いしています。このような環境で WINS を使用せずに Exchange を実行することは、サポートされていません。

少なくとも 2 台の WINS サーバーを含む、フォールト トレランスを備えた WINS 環境を展開することをお勧めします。WINS サーバーは、クライアントにとって、プライマリ WINS サーバーとして機能することも、セカンダリ WINS サーバーとして機能することも可能です。プライマリ WINS サーバーとセカンダリ WINS サーバーの違いは、クライアントがサーバーに接続する際にどちらを優先するかという点のみです。クライアントが NetBIOS 名前サービス操作を実行するために接続する最初のサーバーが、プライマリ WINS サーバーです。プライマリ WINS サーバーが要求を満たすことができない場合にのみ、クライアントはセカンダリ WINS サーバーに接続します。たとえば、クライアントが要求を出したときに使用できない状態になっている場合や、クライアントの名前を解決できない場合などです。

プライマリ WINS サーバーが要求を満たすことができない場合、クライアントはセカンダリ WINS サーバーに対して同じ要求を生成します。クライアントに 3 つ以上の WINS サーバーが構成されている場合、クライアントは、一覧内のサーバーをすべて試行するか、セカンダリ WINS サーバーのいずれかが要求の対応に成功するまで、他のセカンダリ WINS サーバーへの接続を試行します。セカンダリ WINS サーバーが使用された場合、将来の名前サービス要求に備えて、クライアントは定期的にそのサーバーをプライマリ WINS サーバーに切り替えようとします。

ベスト プラクティスは、ルーティングが行われるかセグメント化されたネットワーク上の Exchange サーバー コンピュータに、少なくとも 1 台はセカンダリ WINS サーバーを構成することです。

この警告を修正するには

  1. ネットワーク接続を開きます。

  2. 構成するネットワーク接続を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブ (ローカル エリア接続の場合) または [ネットワーク] タブ (その他すべての接続の場合) で、[インターネット プロトコル (TCP/IP)] をクリックし、[プロパティ] をクリックします。

  4. [詳細設定] をクリックし、[WINS] タブをクリックします。次に、[追加] をクリックします。

  5. [TCP/IP WINS サーバー] に セカンダリ WINS サーバーの IP アドレス を入力し、[追加] をクリックします。

  6. WINS サーバーを追加する場合は、追加する WINS サーバーの IP アドレスごとに手順 4. と手順 5. を繰り返し、[OK] をクリックします。方向キーを使用すると、WINS サーバーの優先順位を変更できます。

  7. [NetBIOS over TCP/IP を有効にする] がオンになっていることを確認します。

  8. [OK] をクリックし、変更を保存します。

Exchange の NetBIOS 名前解決要件の詳細については、Microsoft サポート技術情報の文書番号 837391「Exchange Server 2003 および Exchange 2000 Server が完全に機能するには NetBIOS 名前解決が必要である」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=837391) を参照してください。


サーバーが仮想 PC である
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2007-03-28

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータの Model キーの値を判断します。このキーの値に "Virtual Machine" の文字列が含まれていると、エラーが表示されます。

"Virtual Machine" の文字列が含まれている場合、その Exchange Server コンピュータは Microsoft Virtual PC 200x 仮想コンピュータ内で実行されています。Virtual PC 200x は、1 台のワークステーションで複数の PC ベース オペレーティング システムを同時に実行できるようにするためのソフトウェア仮想化ソリューションです。Microsoft は、どのバージョンの Microsoft Exchange Server についても、仮想マシンやエミュレータ上での実行をサポートしていません。この点は、Microsoft Virtual Server 200x、Microsoft Virtual PC 200x、またはその他の任意のサード パーティ製仮想マシン プログラム上で実行される Exchange Server にも当てはまります。Microsoft Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Catalog」(http://go.microsoft.com/fwlink/?linkid=17219) (このサイトは英語の場合があります) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています。

このエラーを修正するには

  1. メールボックスを、Virtual PC 200x の下で実行されている Exchange Server から、仮想化されていない Exchange Server コンピュータへ移動します。

  2. パブリックフォルダをすべて再格納し、仮想 Exchange サーバーが保持しているロールを必要に応じて転送します。

  3. Exchange を仮想コンピュータからアンインストールして、その Exchange の使用を停止し Exchange インフラストラクチャおよび Active Directory® ディレクトリ サービスから削除します。

仮想環境で実行される Exchange Server コンピュータのサポートの詳細については、Microsoft サポート技術情報の文書番号 320220「ハードウェア仮想化ソフトウェアで実行されている Exchange Server 2003 のポリシーをサポートします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください。

Microsoft Virtual PC の詳細については、Microsoft Virtual PC のホーム ページ (http://go.microsoft.com/fwlink/?linkid=34663) を参照してください (このサイトは英語の場合があります)。


使用しているディスクからエラーが報告されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_DiskDrive Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各ディスクの Status キーの値を判断します。いずれかのディスクについて、Status キーの値が OK ではないと判断されると、エラーが表示されます。

Status キーは、ディスク オブジェクトの現在の状態を表します。さまざまな操作可能な状態と操作不可能な状態を定義できます。操作可能な状態には以下の種類があります。

  • OK

  • 低下

  • 障害が発生する可能性あり (SMART 対応ハード ディスクなどの要素は、正しく動作していても近いうちにエラーが発生すると予測されています)。

  • 操作不可能な状態には以下の種類があります。

  • エラー

  • 開始中

  • 停止動作中

  • サービス (この状態は、ディスク ミラーの再構築や、ユーザー アクセス許可の一覧の再読み込みなどの管理タスクを実行している間に該当します)。

Status キーは、以下の値を含む CIM_ManagedSystemElement WMI クラスから継承されています。

  • OK

  • エラー

  • 低下

  • 不明

  • 障害が発生する可能性あり

  • 開始中

  • 停止動作中

  • サービス

  • 圧縮済み

  • 回復なし

  • 連絡先なし

  • 通信の切断

Microsoft では通常、特定のハードウェア ベンダのディスク エラーに関するトラブルシューティングのドキュメントは提供していません。

このエラーを修正するには

  1. すべてのディスクとケーブルの接続を確認し、10 分間待機します。次に Status の値を確認します。

  2. 返された値が保守モードの値ではない (たとえば、値が "サービス" と一致しない) 場合、使用しているハード ディスクの製造元が推奨する、ディスクのトラブルシューティング手順に従う必要があります。場合によっては、ハード ディスクの製造元に、インストールして問題を分析することができるトラブルシューティング用のソフトウェアが用意されている場合があります。

Exchange に関連する一般的な記憶域の情報については、Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=1715) にある『Storage Solutions for Microsoft Exchange 2000 Server』を参照してください (このサイトは英語の場合があります)。

Microsoft Windows Server™ 2003 に関連する一般的な記憶域の情報については、Microsoft Windows Server 2003 TechCenter (http://go.microsoft.com/fwlink/?LinkId=33811) にある「Windows Server 2003 Storage Services」を参照してください (このサイトは英語の場合があります)。

Windows 2000 Server に関連する一般的な記憶域の情報については、Windows 2000 Web サイト (http://go.microsoft.com/fwlink/?LinkId=33812) にある「Windows 2000 Storage Services」を参照してください (このサイトは英語の場合があります)。


Exchange サーバーに 8 基を超えるプロセッサが搭載されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Win32_ComputerSystem に対してクエリを実行し、NumberOfProcessors の現在の値を判断します。NumberOfProcessors の値が 8 より大きいことが検出されると、警告が表示されます。ただし、このサーバーが Intel のハイパー スレッディング テクノロジを使用するように構成されている場合、この警告は無視してかまいません。ハイパー スレッディング テクノロジによって、マルチスレッド対応のソフトウェア アプリケーションではスレッドが同時に実行されます。ハイパー スレッディング テクノロジを使用するには、ハイパー スレッディング テクノロジをサポートしている Intel Pentium 4 プロセッサを搭載したコンピュータ システムと、HT テクノロジに対応したチップセット、BIOS、およびオペレーティング システムが必要です。

Exchange 2000 Server と Exchange Server 2003 で有効に使用できるプロセッサは、コンピュータあたり 8 基のみです。特に Microsoft Exchange Information Store サービスは、8 プロセッサで最大のパフォーマンスとなるように最適化されています。

8 基を超えるプロセッサを搭載したコンピュータでは、ハードウェアのパーティショニングにより、コンピュータを 8 プロセッサまたは 4 プロセッサの複数のコンピュータに分割することをお勧めします。または、Microsoft Exchange Information Store プロセス (Store.exe) 用に CPU アフィニティを 8 基のプロセッサに限定して構成することもできます。

CPU アフィニティやハードウェアのパーティショニングによって Microsoft Exchange Information Store のプロセスを 8 プロセッサに制限した場合は、すぐに最新の Service Pack および Exchange 更新プログラムのロールアップにアップグレードすることをお勧めします。これは特に、Exchange Server 2003 を実行している場合に重要です。

以前は、バックエンド サーバーのプロセッサ数が 4 基を超えても、Exchange サーバーのパフォーマンスはわずかに向上するだけでした。プロセッサ数が 8 基を超えると、パフォーマンスの向上はほとんど見られず、実際にはパフォーマンスが低下する場合もありました。プロセッサを追加するとパフォーマンス向上の幅が減少するという問題は、最近のコンピュータで使用されている種類のプロセッサに多く見られます。Exchange Server 2003 Service Pack 1 では、プロセッサの追加によるスケーラビリティが大幅に強化されています。ハイパー スレッディングに対応している場合、8 プロセッサのサーバーでは、4 プロセッサのサーバーに比べてパフォーマンスが 50% も向上しています。8 プロセッサのコンピュータをバックエンド サーバーとして使用することは、今では多くのシナリオにおいて妥当であると考えられています。フロントエンド サーバーについては、デュアル プロセッサのサーバーを充てることが今でも推奨されています。

前に説明したとおり、この Exchange Server コンピュータでハイパー スレッディング テクノロジを使用している場合、この警告は無視してかまいません。

ハイパー スレッディング テクノロジを使用していないシステムでこの警告を修正するには

  1. Exchange 用の最新の Service Pack と更新プログラムのロールアップを適用します。これらは、Downloads for Exchange Server 2003 Web サイト (http://go.microsoft.com/fwlink/?linkid=25097) からダウンロードできます (このサイトは英語の場合があります)。

  2. Microsoft Exchange Information Store サービス (Store.exe) の CPU アフィニティを 8 CPU に設定するか、ハードウェアのパーティショニングを使用して 8 プロセッサの Exchange サーバーを作成します。これらの作業を行う方法の詳細については、ハードウェアの製造元に問い合わせてください。

Exchange Server リソースのスケーラビリティの詳細については、Microsoft サポート技術情報の文書番号 827281「Exchange 2000 および Exchange 2003 の CPU とメモリのスケーラビリティについて」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827281) を参照してください。

詳細については、サポート技術情報の文書番号 271088「[XGEN] 6 個または 8 個のプロセッサを使用する Windows 2000 Active Directory サーバーで Exchange 2000 を実行するための最適化」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=271088) を参照してください。

ハイパー スレッディング テクノロジの詳細については、Intel の Web サイト (http://www.intel.com/info/hyperthreading) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Exchange サーバーに 4 GB を超えるメモリが実装されている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2006-06-20

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Exchange Server コンピュータの TotalPhysicalMemory キーの値を判断します。

TotalPhysicalMemory の値が 4294967296 より大きく、6442450944 より小さいことが検出されると、警告が表示されます。

TotalPhysicalMemory の値が 6442450944 より大きいことが検出されると、エラーが表示されます。

TotalPhysicalMemory の値が 4294967296 より大きい場合は、この Exchange Server コンピュータに 4 GB を超えるメモリが実装されていることを示し、TotalPhysicalMemory の値が 6442450944 より大きい場合は、Exchange Server コンピュータに 6 GB を超えるメモリが実装されていることを示します。コンピュータに 4 GB 以上の物理メモリが実装されていても、Exchange Server は 3 GB までのメモリしか使用しません。そのため、このコンピュータが Exchange Server 専用の場合は、4 GB を超えるメモリを実装しても何もメリットはありません。

さらに重要なのは、物理 RAM が多く存在するほど、必要な仮想アドレスから物理アドレスへのマッピングを行うために必要なオペレーティング システムのカーネル アドレス エントリが多くなるということです。これにより、空いているシステム ページ テーブル エントリ (PTE) の数とシステムで利用可能なページ プール メモリの両方が減るため、システムが不安定になります。

たとえば、8 GB の物理 RAM を備えたコンピュータは、4 GB の物理 RAM を備えたコンピュータよりも、空いているシステム ページ テーブル エントリ (PTE) の数が 3,000 少なくなり、最大ページ プール サイズが 30 MB 減少します。

次の 2 つの解決策のいずれかを実行することをお勧めします。

  • システム内のメモリ量を 4 GB に減らします。

  • この文書の後の説明に従い、Boot.ini ファイルの BurnMemory パラメータを設定して物理メモリを 4 GB に減らします。

さらに、追加メモリを必要とする複数のアプリケーションを実行している場合は、4 GB を超える RAM が実装されているときに発生する Exchange インフォメーション ストアの失敗の防止に役立つ、Windows の修正プログラムを実行することができます。ただし、推奨されるベスト プラクティスは、コンピュータを Exchange Server 専用にすることです。この修正プログラムの詳細については、Microsoft サポート技術情報の文書番号 834628「Windows Server 2003 ベースのコンピュータで PAE を有効にするとデータが破損する」(http://go.microsoft.com/fwlink/?linkid=3052) を参照してください。

この警告を修正するには

  1. エクスプローラから、システム パーティションに移動します。

  2. boot.ini ファイルが表示されない場合は、[フォルダ オプション] が [保護されたオペレーティング システム ファイルを表示しない] に設定されていることが考えられます。この場合は、エクスプローラで [ツール] をクリックし、[フォルダ オプション] をクリックします。次に、[表示] をクリックします。[保護されたオペレーティング システム ファイルを表示しない (推奨)] チェック ボックスをオフにします。警告メッセージが表示されたら、[はい] をクリックします。

  3. エクスプローラに Boot.ini ファイルが表示されたら、そのファイルを右クリックし、[プログラムから開く] をクリックします。次に、[Notepad] を選択して、ファイルを開きます。

  4. [Operating Systems] セクションで、起動行に /BURNMEMORY=<MB 単位の値> スイッチを追加します。

    次に、いくつかの例を示します。

    6 GB の物理メモリが搭載されている場合は、/BURNMEMORY=2048 を使用して、使用可能なメモリを 4 GB に減らします。8 GB の物理メモリが搭載されている場合は、/BURNMEMORY=4096 を使用します。

  5. 変更を保存して、メモ帳を閉じます。

  6. Exchange Server コンピュータを再起動して、変更を有効にします。

Boot.ini ファイルで使用可能なパラメータの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 833721「Windows XP および Windows Server 2003 の Boot.ini ファイルで使用可能なスイッチ オプション」(http://go.microsoft.com/fwlink/?linkid=3052)

  • 文書番号 102873「[NT] BOOT.INI と ARC パスの名前付け規約と使用法」(http://go.microsoft.com/fwlink/?linkid=3052)


論理ディスクの使用可能な領域が 3 GB に満たない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2007-03-14

Microsoft® Exchange Server アナライザ ツールは、Win32_LogicalDisk Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Win32_LogicalDisk DriveType キーが 3 (ローカル ディスクを示す) に設定されているディスクの FreeSpace キーの値を判断します。Exchange Server コンピュータ内のローカル ディスクの FreeSpace キーの値が 3 GB 未満の場合、警告が表示されます。Exchange Server コンピュータ内の、メールボックスが含まれているすべてのディスクには、少なくとも 50% の空き領域を常に確保することをお勧めします。

十分なディスク容量を用意することは非常に重要です。データベースのディスク領域が不足すると、データベースはオフラインになります。トランザクション ログのディスク領域が不足すると、そのストレージ グループ内のデータベースがすべてオフラインになります。多くの場合、追加の領域をすばやく用意することは難しく、オフライン圧縮を実行して空き領域を回復するには長い時間がかかる可能性があります。ほとんどの場合、ディスク領域の不足によって 1 つ以上のデータベースが一定の期間利用できなくなり、通常はほとんどの回復時間目標 (RTO) を超過する結果になります。

この警告を修正するには、次の操作を行います。

  1. このディスクから不要なファイルを削除し、ディスクの空き領域を増やします。

  2. 空き領域が 50% 未満のディスクに、別のディスクに安全に移動できるデータ (メールボックス、Windows ページ ファイルなど) が格納されている場合は、そのデータを移動するために必要な手順を実行します。

  3. Exchange Server コンピュータのディスク容量を増やします。

Exchange Server 2003 でのメールボックス移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server と Exchange Server 5.5 との間でメールボックスを移動する方法の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server 2003 のシステム ポリシーを使用してメールボックスの制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 822938「[HOWTO] Exchange Server 2003 でシステム ポリシーを使用してメールボックス格納域の制限を構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822938) を参照してください。

Exchange 2000 Server のシステム ポリシーを使用してメールボックスの制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 319130「HOW TO: Exchange 2000 でメールボックスの格納域の制限を構成するために、システム ポリシーを使用します。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319130) を参照してください。

詳細


マウント ポイントの使用可能な領域が 3 GB に満たない
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Volume Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server コンピュータで使用するボリューム マウント ポイントの FreeSpace キーの値を判断します。FreeSpace の値を 1,000,000,000 で割り、整数値に切り上げた値が 4 未満の場合は、警告が表示されます。

この警告は、ボリューム マウント ポイントの使用可能な記憶域の容量が 3 GB 未満であることを示しています。Exchange Server 2003 が Microsoft Windows Server™ 2003 Enterprise Edition または Windows Server 2003 Datacenter Edition を実行しているコンピュータにインストールされている場合は、ボリューム マウント ポイント (NTFS ファイル システム接続点とも呼ばれます) が、クラスタ化された構成内のデータ記憶域のための場所としてサポートされています。NTFS ボリューム マウント ポイント機能では、26 のアルファベット文字数の制限はありません。ボリューム マウント ポイントを使用すると、対象のパーティションを、別の物理ディスク上のフォルダに移植、つまりマウントすることができます。ボリューム マウント ポイントは、Exchange Server 2003 などのプログラムに対して透過的です。

マウント ポイントは、以下のシナリオではサポートされません。

  • Exchange Server 2003 バイナリのための記憶場所として使用される場合。

  • Microsoft Exchange 2000 Server 以前のバージョンが実行されている Exchange クラスタで使用される場合。

  • Microsoft Windows 2000 Server 以前のバージョンが実行されている Windows クラスタで使用される場合。

Exchange Server で使用されるボリュームが、ローカルの物理ディスク、論理ボリューム、ボリューム マウント ポイントのいずれであっても、Exchange Server 実装では、すべてのドライブに少なくとも 50% の空きディスク領域を確保することがベスト プラクティスです。一般的な経験則としては、Eseutil や Isinteg のようなデータベース ユーティリティを使用して実行される作業などの Exchange の保守のために、少なくとも 25 ～ 30% の空きディスク領域を確保することをお勧めします。さらに、オフラインでの最適化などの一部の保守作業では、最適化する容量より 100% 多い空き領域を確保することをお勧めします。たとえば、1 GB のデータベースを最適化する場合は、少なくとも 1 GB の空きディスク領域を確保してください。

十分な空きディスク領域を確保することは、セキュリティと可用性の両方の観点からもメリットがあります。サービス拒否攻撃、メッセージ ループ、または広範囲にわたるウイルス感染が発生すると、メッセージ トラフィックやトランザクション ログ記録などが増加するため、ディスク領域が過剰に消費される場合があります。

この警告を修正するには

  1. 再生利用するディスク領域を調査し、空き容量を増やします。

  2. ディスク領域が極端に少ない場合は、容量に制約のない別の Exchange Server コンピュータまたは Exchange 仮想サーバーにデータを移動することを検討します。メールボックスの制限をまだ設定していない場合は、この設定を行うと、ディスク利用の管理に役立つ場合があります。

Exchange Server 2003 クラスタでのボリューム マウント ポイントの使用の詳細については、Microsoft サポート技術情報の文書番号 318458「Windows Server 2003 ベースのシステムの Exchange Server 2003 クラスタのボリューム マウント ポイント サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=318458) を参照してください。

Windows Server 2003 クラスタでのボリューム マウント ポイントの使用の詳細については、Microsoft サポート技術情報の文書番号 280297「クラスタ サーバーでボリューム マウント ポイントを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=280297) を参照してください。


ネットワーク カードで DHCP が有効になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DHCPEnabled プロパティに値が設定されているかどうかを判断します。Exchange サーバーのこのプロパティの値が 1 であることが検出されると、エラーが表示されます。

DHCP が有効なネットワーク カードでの Exchange の実行は、サポートされている構成です。しかし、この構成はお勧めできません。DHCP が有効なコンピュータ上で Exchange を実行すると、DHCP サービスが失敗または中断した場合に Exchange メール配信の停止などの障害が発生する可能性があるため、ベスト プラクティスとは言えません。

Exchange を実行しているすべてのコンピュータを、静的 IP アドレスを使用するように構成することをお勧めします。

Windows TCP/IP ネットワークの設計の詳細については、Microsoft TechNet ネットワーク Web サイト (http://go.microsoft.com/fwlink/?LinkId=33819) を参照してください (このサイトは英語の場合があります)。


プライマリ WINS サーバーのアドレスが空になっている
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_NetworkAdapterConfiguration Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、WINSPrimaryServer に値が設定されているかどうかを判断します。Exchange サーバー上でこのキーに対する値が空になっていることが検出されると、警告が表示されます。

Exchange Server 2003 および Exchange 2000 Server には、NetBIOS に依存している部分があります。さらに、Microsoft Office Outlook 2003 より前のバージョンの Microsoft Outlook® を実行するクライアントでも、NetBIOS 名前解決を必要とします。たとえば、以下の Exchange 機能は、NetBIOS 名前解決に依存しています。

  • Exchange Server 2003 および Exchange 2000 Server のセットアップ プログラム (特に、クラスタ化されたサーバーの場合)

  • Exchange Server 2003 コンピュータまたは Exchange 2000 Server コンピュータで実行する Exchange Mailbox Merge Wizard (ExMerge)

  • Outlook Web Access を使用した Exchange Server 2003 または Exchange 2000 Server のメールボックスのパスワード変更

  • Exchange Server 2003 コンピュータまたは Exchange 2000 Server コンピュータで実行する Exchange システム マネージャ

組織のネットワーク トポロジによっては、この警告を無視できる場合があります。単一サブネットで構成されているネットワークでは、通常、NetBIOS ブロードキャストが Exchange デプロイメントの NetBIOS 名前解決要件を処理します。

大規模な組織では、ブロードキャストを使用した NetBIOS 名前解決が正常に機能しない場合があります。NetBIOS ブロードキャストは通常、サブネットを横断しないため、ルーティングが行われるネットワークでは別の方法で NetBIOS 名を解決する必要があります。WINS (Windows Internet Name Service) を使用することをお勧めします。WINS は、ネットワークで使用されるコンピュータおよびグループについて、NetBIOS 名の動的マッピングを登録したりクエリを実行したりするための分散データベースを実現します。WINS は、NetBIOS 名を IP アドレスと対応付けます。WINS は、ルーティングが行われる環境で NetBIOS 名前解決が原因で発生した問題を解決することを目的として設計されました。NetBIOS over TCP/IP を使用する、ルーティングが行われるネットワークでの NetBIOS 名前解決には、WINS が最適です。

大規模な組織またはサブネットに分割された組織での WINS を使用しない Exchange Server 2003 および Exchange 2000 Server の操作と機能については、十分にテストされていません。Microsoft としては、ルーティングが行われたりセグメント化されているネットワークで Exchange を実行している企業が、WINS を使用して NetBIOS 名前解決をするようお願いしています。このような環境で WINS を使用せずに Exchange を実行することは、サポートされていません。

少なくとも 2 台の WINS サーバーを含む、フォールト トレランスを備えた WINS 環境を展開することをお勧めします。WINS サーバーは、クライアントにとって、プライマリ WINS サーバーとして機能することも、セカンダリ WINS サーバーとして機能することも可能です。プライマリ WINS サーバーとセカンダリ WINS サーバーの違いは、クライアントがサーバーに接続する際にどちらを優先するかという点のみです。クライアントが NetBIOS 名前サービス操作を実行するために接続する最初のサーバーが、プライマリ WINS サーバーです。プライマリ WINS サーバーが要求を満たすことができない場合にのみ、クライアントはセカンダリ WINS サーバーに接続します。たとえば、クライアントが要求を出したときに使用できない状態になっている場合や、クライアントの名前を解決できない場合などです。

プライマリ WINS サーバーが要求を満たすことができない場合、クライアントはセカンダリ WINS サーバーに対して同じ要求を生成します。クライアントに 3 つ以上の WINS サーバーが構成されている場合、クライアントは、一覧内のサーバーをすべて試行するか、セカンダリ WINS サーバーのいずれかが要求の対応に成功するまで、他のセカンダリ WINS サーバーへの接続を試行します。セカンダリ WINS サーバーが使用された場合、将来の名前サービス要求に備えて、クライアントは定期的にそのサーバーをプライマリ WINS サーバーに切り替えようとします。

ベスト プラクティスは、ルーティングが行われるかセグメント化されたネットワーク上の Exchange サーバー コンピュータに、少なくとも 1 台はセカンダリ WINS サーバーを構成することです。

この警告を修正するには

  1. ネットワーク接続を開きます。

  2. 構成するネットワーク接続を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブ (ローカル エリア接続の場合) または [ネットワーク] タブ (その他すべての接続の場合) で、[インターネット プロトコル (TCP/IP)] をクリックし、[プロパティ] をクリックします。

  4. [詳細設定] をクリックし、[WINS] タブをクリックします。次に、[追加] をクリックします。

  5. [TCP/IP WINS サーバー] に WINS サーバーの IP アドレス を入力し、[追加] をクリックします。

  6. WINS サーバーを追加する場合は、追加する WINS サーバーの IP アドレスごとに手順 4. と手順 5. を繰り返し、[OK] をクリックします。方向キーを使用すると、WINS サーバーの優先順位を変更できます。

  7. [NetBIOS over TCP/IP を有効にする] がオンになっていることを確認します。

  8. [OK] をクリックし、変更を保存します。

Exchange の NetBIOS 名前解決要件の詳細については、Microsoft サポート技術情報の文書番号 837391「Exchange Server 2003 および Exchange 2000 Server が完全に機能するには NetBIOS 名前解決が必要である」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=837391) を参照してください。


仮想サーバーが検出された
Microsoft Exchange Server アナライザ - 文書 > ハードウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が Virtual Machine に設定されているかどうかを判断します。

さらに、次のレジストリ値の有無も確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

Model キーに "Virtual Machine" という文字列が含まれており、かつ上記のレジストリ ブランチが存在することが検出されると、エラーが表示されます。

Model キーの値が Virtual Machine の場合、Microsoft Virtual Server 2005 または Microsoft Virtual PC 2004 いずれかの仮想コンピュータ上で、Exchange Server コンピュータがゲストとして実行されていることを示します。上記のレジストリ ブランチを作成するのは Virtual Server 2005 だけなので、このブランチが存在すれば、Exchange Server コンピュータは Virtual Server 2005 のゲスト仮想コンピュータとして実行されていることになります。

Microsoft は、どのバージョンの Microsoft Exchange Server についても、仮想マシンやエミュレータ上での実行をサポートしていません。この点は、Microsoft Virtual Server 2005、Microsoft Virtual PC 2004、またはその他の任意のサードパーティー製仮想マシン プログラム上で実行される Exchange Server にも当てはまります。Microsoft Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Calatog」(http://go.microsoft.com/fwlink/?linkid=17219) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています (このサイトは英語の場合があります)。

このエラーを修正するには

  1. メールボックスを、Virtual Server 2005 の下で実行されている Exchange Server から、仮想化されていない Exchange Server コンピュータに移動します。

  2. パブリックフォルダをすべて再格納し、仮想 Exchange サーバーが保持しているロールを必要に応じて転送します。

  3. Exchange を仮想コンピュータからアンインストールして、その Exchange の使用を停止し Exchange インフラストラクチャおよび Active Directory® ディレクトリ サービスから削除します。

メールボックスの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

Microsoft Virtual Server 2005 の詳細については、Microsoft Virtual Server 2005 Web サイト (http://go.microsoft.com/fwlink/?LinkId=34938) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual PC 2004 の詳細については、Microsoft Virtual PC 2004 Web サイト (http://go.microsoft.com/fwlink/?linkid=34663) を参照してください (このサイトは英語の場合があります)。


ネットワーク
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクションの文書では、Mcrosoft® Exchange Server アナライザ ツールで、ネットワークに関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出されたネットワーク関連のエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


DNS 'ホスト' レコードが存在しないように見える
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2006-04-13

Microsoft® Exchange Server アナライザ ツールは、DNS サーバーに対してドメイン ネーム システム (DNS) 参照を実行し、Exchange サーバーのホスト (A) レコードを取得します。DNS 参照操作で IP アドレスが返されない場合、Exchange Server アナライザは、ホスト (A) レコードが存在しないように見えることを通知する警告を表示します。

以下の理由によって、Exchange Server 2003 コンピュータによるホスト (A) レコードの DNS 参照が失敗することがあります。

  • DNS サーバーが停止しているか、またはネットワーク障害などの理由により応答していない。

  • ホスト (A) レコードを使用できない、レコードが正しくない、動的なホスト レコードの更新を許可するように DNS サーバーが構成されていないなどの理由で、Exchange Server 2003 のホスト レコードが DNS サーバー上で見つからない。

DNS サーバーが停止すると、メールのルーティングに遅延が発生したり、他のサービスにエラーが発生したりする場合があります。

注 :
Exchange Server 2003 は、ネットワーク内のローカルおよび外部両方の SMTP 対応メッセージング システムに対して、ホスト名解決を使用します。ホスト名解決は主に DNS に基づいて実行されるため、DNS は重要なネットワーク サービスになります。DNS サーバーに障害が発生すると、ユーザーは使用しているメッセージング システムを見つけることができなくなります。Active Directory および Exchange Server 2003 組織は、DNS がないと機能できません。メッセージング クライアントは、DNS に対してクエリを実行し、ドメイン コントローラやメールボックス サーバーなどの内部リソースを見つけます。一方、Exchange Server 2003 は DNS を使用して、ディレクトリ参照用のドメイン コントローラのインターネット プロトコル (IP) アドレスを取得したり、インターネットにメッセージを送信するときに、外部の SMTP (Simple Mail Transfer Protocol) ホストの IP アドレスを取得したりします。

この問題を解決するには、DNS サーバーが動作中で、ホスト (A) レコードが登録されていることを確認します。

DNS サーバーがオンラインになっていて、ホスト レコードが存在することを確認するには

  1. 以下の手順の 1 つ以上を実行し、DNS サーバーが動作していることを確認します。

    • DNS サーバーの DNS 管理プログラムを使用して、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup を使用して、DNS サーバーが応答するかどうかを調べます。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、DNS サーバーにホスト (A) レコードが存在することを確認します。詳細については、DNS に A レコードが存在することを確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63001) を参照してください (このサイトは英語の場合があります)。

  3. ホスト (A) リソース レコードが存在しない場合、A リソース レコードを手動で追加または変更するか、または動的なレコードの更新を許可するように DNS サーバーを構成します。

    • A リソース レコードを手動で追加します。詳細については、DNS ゾーンにリソース レコードを追加する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください (このサイトは英語の場合があります)。

    • A リソース レコードを手動で変更します。詳細については、既存のリソース レコードを変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63014) を参照してください (このサイトは英語の場合があります)。

    • DNS サーバーで動的にホスト レコードを更新できるようにします。詳細については、Microsoft サポート技術情報の文書番号 816592「Windows Server 2003 で DNS 動的更新を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592) を参照してください。
  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 で転送およびルーティングを行う方法のガイド (http://go.microsoft.com/fwlink/?LinkId=47579) の Exchange Server 2003 における転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS のトラブルシューティング方法については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 のシステム モニタについては、Exchange Server 2003 Management Pack for MOM 2000 SP1 のガイド (http://go.microsoft.com/fwlink/?LinkId=47573) の Exchange Server 2003 Management Pack のシステム モニタに関する章を参照してください (このサイトは英語の場合があります)。

  • ホスト (A) リソース レコードについては、リソース レコードの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63004) を参照してください (このサイトは英語の場合があります)。


DNS 応答が UDP と TCP で異なる
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange アナライザ ツールは Win32_NetworkAdapterConfiguration Microsoft WMI (Windows Management Instrument) クラスに対してクエリを実行し、DNSServerSearchOrder 属性を取得します。この属性は、ドメイン ネーム システム (DNS) サーバーに対するクエリで使用されるサーバー IP アドレスの配列です。

プライマリ DNS サーバーのアドレスを取得した後で、Exchange アナライザは、各 Active Directory ディレクトリ サービス サーバーで構成されている DNS サーバーに対して、DNS クエリの実行を試みます。この接続は、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) の両方の名前解決要求を実行するカスタム オブジェクト プロセッサを使用して行われます。

TCP と UDP の名前解決要求が両方とも成功した場合、Exchange アナライザは、成功した要求によって返された応答を比較します。TCP と UDP のそれぞれのクエリによって返された応答が同一でない場合、Exchange アナライザによって警告が表示されます。

この警告は、DNS サーバーの構成に問題が存在する可能性があり、メール フローのパフォーマンスに影響を及ぼす恐れがあることを示しています。

SMTP (Simple Mail Transfer Protocol) は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

Exchange Server が SMTP サービス経由で送信インターネット メッセージを配信するには、次の方法で DNS を利用する必要があります。

  1. 内部ユーザーがリモート ドメインの受信者にメッセージを送信します。

  2. 受信者がローカルとリモートのどちらであるかを判断するため、送信側の Exchange サーバーの SMTP 仮想サーバーは、内部トランスポート関数を使用して、受信者のアドレスに関するクエリをグローバル カタログ サーバーに対して発行します。メッセージの受信者アドレスが受信者ポリシーに含まれていない場合、このアドレスは Active Directory には格納されていません。このため、Exchange はそのメッセージがリモート ドメイン宛てであると判断します。

  3. 必要に応じて、Exchange サーバーはメッセージを適切な SMTP 仮想サーバーに配信します。

  4. SMTP 仮想サーバーは、IIS メタベースの情報を使用して、メッセージをリモート ドメインに配信する方法を決定します。

  5. 次に、Exchange サーバー上の SMTP 仮想サーバーは、次のいずれかの動作を実行します。

    • DNS を使用して送信先ドメインの IP アドレスを検索してから、メッセージの配信を試みます。

    • DNS 解決とメッセージの配信を担当するスマート ホストにメッセージを転送します。

この警告に対処する方法については、Microsoft サポート技術情報の文書番号 820284「サーバーの OS が Windows Server 2003 である場合に、特定のドメインにメールが配信されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=820284) の指示について検討してください。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート ウェブキャスト : Microsoft Exchange 2000 server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


Exchange Server がゲストとしてインストールされた Virtual Server 2005 が DNS サーバーで実行されている
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Model キーの値が Virtual Machine に設定されているかどうかを判断します。

さらに、次のレジストリ値の有無も確認します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Virtual Machine\Guest\Parameters

また、Win32_Services WMI クラスに対してクエリを実行し、Microsoft Virtual Server 2005 を実行している物理コンピュータ上でドメイン ネーム システム (DNS) サービスが実行されているかどうかも判断します。

Model キーに文字列 Virtual Machine が含まれていること、および上記のレジストリ ブランチが存在し、かつ DNS が実行されていることが検出されると、エラーが表示されます。

Model キーの値が Virtual Machine の場合、Virtual Server 2005 または Microsoft Virtual PC 2004 いずれかの仮想コンピュータ上で、Exchange Server コンピュータがゲストとして実行されていることを示します。上記のレジストリ ブランチを作成するのは Virtual Server 2005 だけなので、このブランチが存在すれば、Exchange Server コンピュータは Virtual Server 2005 のゲスト仮想コンピュータとして実行されていることになります。

Microsoft では、バージョンに関係なく、仮想マシンまたはエミュレータでの Microsoft Exchange Server の実行をサポートしていません。この点は、Virtual Server 2005、Virtual PC 2004、またはその他の任意のサードパーティー製仮想マシン プログラム上で実行される Exchange Server にも当てはまります。Microsoft Exchange Server プラットフォームは物理的なハードウェア、特に「Windows Server Calatog」(http://go.microsoft.com/fwlink/?linkid=17219) に記載されているハードウェア プラットフォーム上でのみ実行するように、設計とテストが行われています (このサイトは英語の場合があります)。

また、ドメイン ネーム システムが実行されているコンピュータで Exchange を Virtual Server 2005 のゲストとして動作させることは、サービス全体で適切な冗長性を確保できないという点で、ベスト プラクティスであるとは言えません。

このエラーを修正するには

  1. メールボックスを、Virtual Server 2005 の下で実行されている Exchange Server から、仮想化されていない Exchange Server コンピュータに移動します。

  2. 必要に応じて、パブリック フォルダを再格納し、仮想 Exchange サーバーが保持していた役割を転送します。

  3. Exchange を仮想コンピュータからアンインストールして、その Exchange の使用を停止し Exchange インフラストラクチャおよび Active Directory® ディレクトリ サービスから削除します。

メールボックスの移動の詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822892「Exchange 2003 のメールボックスの移動で強化された機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822892)

  • 文書番号 224975「[XADM] メールボックスの移動方法の相違点」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=224975)

仮想環境で実行される Exchange Server コンピュータに対するサポートの詳細については、Microsoft サポート技術情報の文書 320220「Support Boundaries for Exchange Server on a Virtual Machine or an Emulation Machine」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320220) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual Server 2005 の詳細については、Microsoft Virtual Server 2005 Web サイト (http://go.microsoft.com/fwlink/?linkid=34938) を参照してください (このサイトは英語の場合があります)。

Microsoft Virtual PC 2004 の詳細については、Microsoft Virtual PC 2004 Web サイト (http://go.microsoft.com/fwlink/?linkid=34663) を参照してください (このサイトは英語の場合があります)。


外部 DNS サーバーの応答が UDP と TCP で異なる
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを発行し、各 Exchange Server オブジェクトについて protocolCfgSMTPServer クラスの msExchSmtpExternalDNSServers 属性値を判断します。msExchSmtpExternalDNSServers 属性値が設定されている場合、この値は SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスが使用する外部ドメイン ネーム システム (DNS) サーバーのアドレスを指定します。

プライマリ外部 DNS サーバーのアドレスを取得した後で、Exchange アナライザは、各 Active Directory ディレクトリ サービス サーバーで構成されている DNS サーバーに対して、DNS クエリの実行を試みます。この接続は、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) の両方の名前解決要求を実行するカスタム オブジェクト プロセッサを使用して行われます。

TCP と UDP の名前解決要求が両方とも成功した場合、Exchange アナライザは、成功した要求によって返された応答を比較します。TCP と UDP のそれぞれのクエリによって返された応答が同一でない場合、Exchange アナライザによって警告が表示されます。

この警告は、外部 DNS サーバーの構成に問題が存在する可能性があり、メール フローのパフォーマンスに影響を及ぼす恐れがあることを示しています。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

Exchange Server が SMTP サービス経由で送信インターネット メッセージを配信するには、次の方法で DNS を利用する必要があります。

  1. 内部ユーザーがリモート ドメインの受信者にメッセージを送信します。

  2. 受信者がローカルとリモートのどちらであるかを判断するため、送信側の Exchange サーバーの SMTP 仮想サーバーは、内部トランスポート関数を使用して、受信者のアドレスに関するクエリをグローバル カタログ サーバーに対して発行します。メッセージの受信者アドレスが受信者ポリシーに含まれていない場合、このアドレスは Active Directory には格納されていません。このため、Exchange はそのメッセージがリモート ドメイン宛てであると判断します。

  3. 必要に応じて、Exchange サーバーはメッセージを適切な SMTP 仮想サーバーに配信します。

  4. SMTP 仮想サーバーは、IIS メタベースの情報を使用して、メッセージをリモート ドメインに配信する方法を決定します。

  5. 次に、Exchange サーバー上の SMTP 仮想サーバーは、次のいずれかの動作を実行します。

    • DNS を使用して送信先ドメインの IP アドレスを検索してから、メッセージの配信を試みます。

    • DNS 解決とメッセージの配信を担当するスマート ホストにメッセージを転送します。

この警告に対処する方法については、Microsoft サポート技術情報の文書番号 820284「サーバーの OS が Windows Server 2003 である場合に、特定のドメインにメールが配信されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=820284) を参照してください。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート ウェブキャスト : Microsoft Exchange 2000 server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


ネットワークの Bytes Total/sec がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Network Interface パフォーマンス オブジェクトの Bytes Total/sec パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Bytes Total/sec パフォーマンス カウンタは、ネットワーク アダプタが 1 秒あたりに処理するデータ バイトの数を示しています。このカウンタには、パケット ヘッダーなどのプロトコル情報に加えて、すべてのアプリケーションとファイルのデータが含まれています。Bytes Total/sec パフォーマンス カウンタは、Network Interface\Bytes Received/sec と Network Interface/Bytes Sent/sec の合計です。

Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。100 Mbps (メガビット/秒) のネットワーク アダプタの場合、Bytes Total/sec パフォーマンス カウンタの値は 7 MB/秒以下である必要があります。1000 Mbps のネットワーク アダプタの場合、Bytes Total/sec パフォーマンス カウンタの値は 70 MB/秒以下である必要があります。Bytes Total/sec がネットワーク帯域幅の 7% を超える場合は、Exchange Server アナライザによってエラーが表示されます。

このエラーは通常、サーバーで応答がない状態が生じており、メール フローの速度低下や停止が引き起こされていることを示しています。また、このサーバーに接続する Microsoft Outlook® クライアントに、[要求の取り消し] ダイアログ ボックスが表示されることがあります。

このエラーの考えられる原因について、次にいくつか示します。

  • コンピュータ上のネットワーク インターフェイス カード (NIC) が、使用しているネットワーク インフラストラクチャでサポートされる最大帯域幅をサポートできない。

  • サーバーの負荷が高すぎる。

  • ウイルスまたはスパムが、ネットワーク使用率を急上昇させるパターンを引き起こしている。

このエラーを解決するには、次の操作を行います。

  • NIC がネットワークの最大帯域幅をサポートしていない場合は、より高速な帯域幅をサポートする NIC にアップグレードします。

  • サーバーの負荷を減らします。このためには、メールボックスを、メールボックス数がより少ないサーバーに移動します。必要に応じて、さらに Exchange サーバーを環境に追加します。

  • 通常より高い負荷が、サーバー上のメールボックスが多すぎることが原因で発生しているのではない場合は、高い負荷を生み出している原因を突き止めて解決します。

  • 次の文書で紹介されているベスト プラクティスを検討します。

    • ネットワーク帯域幅の考慮事項の詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) の「Understanding Exchange Performance」のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。

    • ネットワークの問題に関するトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Ruling Out Network-Bound Problems」を参照してください (このサイトは英語の場合があります)。


ネットワーク インターフェイス カード (NIC) チーミングが有効になっている
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2006-10-16

Microsoft® Exchange Server アナライザ ツールは、TCP/IP プロトコルにバインドされているすべてのネットワーク インターフェイス カード (NIC) で、Microsoft WMI (Windows® Management Instrument) クラスの Win32_NetworkAdapter に対してクエリを実行します。

次に、Exchange Server アナライザは、以下のレジストリ ブランチに対してクエリを実行し、これらのアダプタに対して TeamAdapters キーが存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\%NICDEVICEID%\

Exchange Server アナライザによって、分析対象のサーバー上の 1 つまたは複数の NIC に対して TeamAdapters キーが存在すると判断されると、警告が表示されます。

この警告は、分析対象の Exchange サーバー上で NIC チーミングが有効になっていることを示しています。通常、NIC チーミングがメール フローの問題となることはありませんが、チーミングが利用可能な最新の NIC ドライバで正しく構成されていることを必ず確認する必要があります。

この問題を解決するには

  • メール フローの問題が NIC チーミングを有効にしたサーバーで発生している場合は、チーミングを一時的に無効にしてメール フローの問題が解決されるかどうかを確認します。

  • NIC ドライバを NIC 製造元から入手できる最新のドライバに更新します。

  • NIC 製造元のチーミング構成の推奨事項を順守します。

NIC チーミングの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 278431 の Network Load Balancing 対応の NIC チーミング アダプタについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=278431)

  • 文書番号 814607のサードパーティ製システム コンポーネントを含むサーバー クラスタに対する Microsoft サポートについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=814607)


ネットワークの送信パケットがしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、パフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Network Interface パフォーマンス オブジェクトの Packet Outbound errors パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Packet Outbound errors パフォーマンス カウンタは、エラーのために送信できなかった送信パケット数を示します。Packet Outbound errors パフォーマンス カウンタの値は 0 である必要があります。Exchange Server アナライザによって、Packet Outbound errors パフォーマンス カウンタの値が 0 を超えていると判断されると、エラーが表示されます。

このエラーは通常、サーバーで応答がない状態が生じており、メール フローの速度低下や停止が引き起こされていることを示しています。また、このサーバーに接続する Microsoft Outlook® クライアントに、[要求の取り消し] ダイアログ ボックスが表示されることがあります。

このエラーはほとんどの場合、ネットワーク インターフェイス カード (NIC) の障害または破損が原因で発生します。

このエラーを解決するには、送信パケットのエラーの原因を判断し、問題を修正する必要があります。送信パケットのエラーが NIC の障害が原因で発生している場合は、そのカードを直ちに交換します。

次の文書で紹介されているベスト プラクティスを検討します。

  • ネットワーク帯域幅の考慮事項の詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) の「Understanding Exchange Performance」のネットワークのパフォーマンスに関するセクションを参照してください (このサイトは英語の場合があります)。

  • ネットワークの問題に関するトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) の「Ruling Out Network-Bound Problems」を参照してください (このサイトは英語の場合があります)。


Network Output Queue Length がしきい値を超えている
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するための、パフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Network Interface パフォーマンス オブジェクトの Output Queue Length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Output Queue Length パフォーマンス カウンタでは、複数のパケットで発信パケットのキューの長さを示します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの最大値を報告します。平均値が 10 を超えていることが検出されると、エラーが表示されます。

このエラーは通常、サーバーで応答がない状態が生じており、メール フローの速度低下や停止が引き起こされていることを示しています。また、このサーバーに接続する Outlook クライアントに、[要求の取り消し] ダイアログ ボックスが表示されることがあります。

このエラーの考えられる原因について、次にいくつか示します。

注 :
状況によっては、Microsoft Windows 2000 Server オペレーティング システムを実行するマシンで、Output Queue Length パフォーマンス カウンタがゼロよりも大きいランダムな値を定常的に示す場合があります。Output Queue Length パフォーマンスがランダムな値を示す状況と、これを修正する方法の詳細については、マイクロソフト サポート技術情報の文書番号 834940 の、システム モニタには、Output Queue Length パフォーマンス カウンタの大きな値が Windows 2000で表示される現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=834940) を参照してください。
  • コンピュータ上のネットワーク インターフェイス カード (NIC) が、使用しているネットワーク インフラストラクチャでサポートされる最大帯域幅をサポートできない。

  • サーバーの負荷が高すぎる。

  • ウイルスまたはスパムが、ネットワーク使用率を急上昇させるパターンを引き起こしている。

このエラーを解決するには、次の操作を行います。

  • NIC がネットワークの最大帯域幅をサポートしていない場合は、より高速な帯域幅をサポートする NIC にアップグレードします。

  • サーバーの負荷を減らします。このためには、メールボックスを、メールボックス数がより少ないサーバーに移動します。必要に応じて、さらに Exchange サーバーを環境に追加します。

  • 通常より高い負荷が、サーバー上のメールボックスが多すぎることが原因で発生しているのではない場合は、高い負荷を生み出している原因を突き止めて解決します。

次の文書で紹介されているベスト プラクティスを検討します。

  • ネットワーク帯域幅の考慮事項の詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドの Exchange のパフォーマンスに関する説明 (http://go.microsoft.com/fwlink/?LinkId=47576) (英語) を参照してください。

  • ネットワークの問題に関するトラブルシューティングの詳細については、Microsoft Exchange Server パフォーマンスのトラブルシューティングに関するページのネットワーク関連の問題を排除する方法についての説明 (http://go.microsoft.com/fwlink/?LinkId=47588) (英語) を参照してください。


プライマリ DNS が UDP 接続への応答に失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange アナライザ ツールは Win32_NetworkAdapterConfiguration Microsoft WMI (Windows Management Instrument) クラスに対してクエリを実行し、DNSServerSearchOrder 属性を取得します。この属性は、DNS サーバーへのクエリで使用されるサーバー IP アドレスの配列です。

プライマリ ドメイン ネーム システム (DNS) サーバーのアドレスを取得すると、Exchange アナライザは、Active Directory ディレクトリ サービス サーバーごとに構成されている DNS サーバーに対して DNS クエリを実行します。この接続は、ユーザー データグラム プロトコル (UDP) 名前解決要求を実行して結果を分析するカスタム オブジェクト プロセッサを使用することによって作成されます。

UDP 名前解決要求が失敗すると、Exchange アナライザによって警告が表示されます。

この警告は、プライマリ DNS サーバーが TCP クエリだけを受け付けるように構成されている可能性があることを示しています。

SMTP (Simple Mail Transfer Protocol) は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

Exchange Server が SMTP サービス経由で送信インターネット メッセージを配信するには、次の方法で DNS を利用する必要があります。

  1. 内部ユーザーがリモート ドメインの受信者にメッセージを送信します。

  2. 受信者がローカルとリモートのどちらであるかを判断するため、送信側の Exchange サーバーの SMTP 仮想サーバーは、内部トランスポート関数を使用して、受信者のアドレスに関するクエリをグローバル カタログ サーバーに対して発行します。メッセージの受信者アドレスが受信者ポリシーに含まれていない場合、このアドレスは Active Directory には格納されていません。このため、Exchange はそのメッセージがリモート ドメイン宛てであると判断します。

  3. 必要に応じて、Exchange サーバーはメッセージを適切な SMTP 仮想サーバーに配信します。

  4. SMTP 仮想サーバーは、IIS メタベースの情報を使用して、メッセージをリモート ドメインに配信する方法を決定します。

  5. 次に、Exchange サーバー上の SMTP 仮想サーバーは、次のいずれかの動作を実行します。

    • DNS を使用して送信先ドメインの IP アドレスを検索してから、メッセージの配信を試みます。

    • DNS 解決とメッセージの配信を担当するスマート ホストにメッセージを転送します。

既定では、DNS サーバーは、名前解決クエリなどの通信を UDP ソケット 53 上で待機します。

Exchange Server 上の SMTP サービスが UDP クエリだけを送信するように構成されており、プライマリ DNS サーバーが TCP クエリだけを受け付けるように構成されている場合、メールのルーティング エラーが発生して、メール フローのパフォーマンスに悪影響を与えることがあります。

この警告に対処するには、次の操作を行います。

  1. DNS サーバーが起動し、ネットワークに接続されていることを確認します。

  2. ネットワーク ファイアウォールまたはパケット フィルタが、UDP ポート 53 などの既知の DNS ポートを意図的にブロックしていないことを確認します。

  3. プライマリ DNS サーバーが UDP 名前解決クエリをサポートするように構成されていることを確認します。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート ウェブキャスト : Microsoft Exchange 2000 server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


プライマリ DNS サーバーに到達できない
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Win32_NetworkAdapterConfiguration に対してクエリを実行し、DNSServerSearchOrder 属性を取得します。この属性は、DNS サーバーへのクエリで使用されるサーバー IP アドレスの配列です。プライマリ DNS サーバーのアドレスを取得した後、Exchange Server アナライザは、サーバーのポート 53 への TCP ソケット接続を開きます。この接続は、接続に成功した場合に特定の文字列を返すカスタム オブジェクト プロセッサを使用することにより、確立します。返された文字列の一部に 53 Available が含まれていない場合は、警告が表示されます。

この警告は、TCP ポート 53 上での接続の試みに対して、そのサーバーが応答しなかったことを示しています。既定では、DNS サーバーは、名前解決クエリなどの通信を TCP ソケット 53 上で待機します。

プライマリ DNS サーバーに到達できず、さらに Exchange 2000 Server を実行している場合は、メール配信に時間がかかる可能性があります。プライマリ DNS サーバーが使用できないときに、外部受信者へのメッセージ配信に予期した以上の時間がかかる問題を修正するための修正プログラムが Microsoft から提供されています。この修正プログラムの入手については、Microsoft 製品サポート サービスに問い合わせてください。

さらに、プライマリ DNS サーバーが使用できない原因に関するトラブルシューティングを行うか、または Exchange サーバーの DNS 設定を変更して名前解決に別の DNS サーバーを使用するようにします。

この警告を修正するには

  1. DNS サーバーが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、DNS サーバーが到達可能かどうかを判断します。

プライマリ DNS サーバーが使用できないときにメール配信に時間がかかる問題や、この問題の修正プログラムの入手方法の詳細については、Microsoft サポート技術情報の文書番号 829722「In exchange プライマリ DNS サーバーが使用できない 2000 メール配信が低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829722) を参照してください。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(322856http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート : Microsoft Exchange 2000 Server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


プライマリ外部 DNS サーバーが TCP 接続への応答に失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを発行し、各 Exchange Server オブジェクトについて protocolCfgSMTPServer クラスの msExchSmtpExternalDNSServers 属性値を判断します。msExchSmtpExternalDNSServers 属性値が設定されている場合、この値は SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスが使用する外部ドメイン ネーム システム (DNS) サーバーのアドレスを指定します。

プライマリ外部 DNS サーバーのアドレスを取得した後、Exchange Server アナライザは、サーバーのポート 53 への TCP ソケット接続を開きます。この接続は、接続に成功すると特定の文字列を返すカスタム オブジェクト プロセッサを使用して確立されます。返された文字列の一部に 53 Available が含まれていない場合は、警告が表示されます。

この警告は、TCP ポート 53 上での接続の試みに対して、そのサーバーが応答しなかったことを示しています。既定では、DNS サーバーは、名前解決クエリなどの通信を TCP ソケット 53 上で待機します。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

Exchange Server が SMTP サービス経由で送信インターネット メッセージを配信するには、次の方法で DNS を利用する必要があります。

  1. 内部ユーザーがリモート ドメインの受信者にメッセージを送信します。

  2. 受信者がローカルとリモートのどちらであるかを判断するため、送信側の Exchange サーバーの SMTP 仮想サーバーは、内部トランスポート関数を使用して、受信者のアドレスに関するクエリをグローバル カタログ サーバーに対して発行します。メッセージの受信者アドレスが受信者ポリシーに含まれていない場合、このアドレスは Active Directory には格納されていません。このため、Exchange はそのメッセージがリモート ドメイン宛てであると判断します。

  3. 必要に応じて、Exchange サーバーはメッセージを適切な SMTP 仮想サーバーに配信します。

  4. SMTP 仮想サーバーは、IIS メタベースの情報を使用して、メッセージをリモート ドメインに配信する方法を決定します。

  5. 次に、Exchange サーバー上の SMTP 仮想サーバーは、次のいずれかの動作を実行します。

    • DNS を使用して送信先ドメインの IP アドレスを検索してから、メッセージの配信を試みます。

    • DNS 解決とメッセージの配信を担当するスマート ホストにメッセージを転送します。

プライマリ外部 DNS サーバーに到達できず、さらに Exchange 2000 Server を実行している場合は、メール配信に時間がかかる可能性があります。プライマリ外部 DNS サーバーが使用できないときに、外部受信者へのメッセージ配信に予期した以上の時間がかかる問題を修正するための修正プログラムが Microsoft から提供されています。この修正プログラムの入手については、Microsoft 製品サポート サービスに問い合わせてください。

さらに、プライマリ外部 DNS サーバーが使用できない原因に関するトラブルシューティングを行うか、または Exchange サーバーの DNS 設定を変更して名前解決に別の DNS サーバーを使用するようにします。

この警告を修正するには、次の操作を行います。

  1. 外部 DNS サーバーが起動されていて、Exchange ネットワークからそのサーバーへの接続が確立されていることを確認します。

  2. PING コマンドを使用して、外部 DNS サーバーが到達可能かどうかを判断します。

プライマリ DNS サーバーが使用できないときにメール配信に時間がかかる問題や、この問題の修正プログラムの入手方法の詳細については、Microsoft サポート技術情報の文書番号 829722「プライマリ DNS サーバーが使用できない場合、メール配信が Exchange 2000 で低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829722) を参照してください。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート ウェブキャスト : Microsoft Exchange 2000 server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


プライマリ外部 DNS が UDP 接続に応答できない
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを発行し、各 Exchange Server オブジェクトについて protocolCfgSMTPServer クラスの msExchSmtpExternalDNSServers 属性値を判断します。msExchSmtpExternalDNSServers 属性値が設定されている場合、この値は SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスが使用する外部ドメイン ネーム システム (DNS) サーバーのアドレスを指定します。

プライマリ外部 DNS サーバーのアドレスを取得した後で、Exchange アナライザは、各 Active Directory ディレクトリ サービス サーバーで構成されている外部 DNS サーバーに対して、DNS クエリの実行を試みます。この接続は、ユーザー データグラム プロトコル (UDP) 名前解決要求を実行して結果を分析するカスタム オブジェクト プロセッサを使用することによって作成されます。

UDP 名前解決要求が失敗すると、Exchange アナライザによって警告が表示されます。

この警告は、プライマリ外部 DNS サーバーが、TCP クエリのみを受け付けるように構成されている可能性があることを示しています。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

Exchange Server が SMTP サービス経由で送信インターネット メッセージを配信するには、次の方法で DNS を利用する必要があります。

  1. 内部ユーザーがリモート ドメインの受信者にメッセージを送信します。

  2. 受信者がローカルとリモートのどちらであるかを判断するため、送信側の Exchange サーバーの SMTP 仮想サーバーは、内部トランスポート関数を使用して、受信者のアドレスに関するクエリをグローバル カタログ サーバーに対して発行します。メッセージの受信者アドレスが受信者ポリシーに含まれていない場合、このアドレスは Active Directory には格納されていません。このため、Exchange はそのメッセージがリモート ドメイン宛てであると判断します。

  3. 必要に応じて、Exchange サーバーはメッセージを適切な SMTP 仮想サーバーに配信します。

  4. SMTP 仮想サーバーは、IIS メタベースの情報を使用して、メッセージをリモート ドメインに配信する方法を決定します。

  5. 次に、Exchange サーバー上の SMTP 仮想サーバーは、次のいずれかの動作を実行します。

    • DNS を使用して送信先ドメインの IP アドレスを検索してから、メッセージの配信を試みます。

    • DNS 解決とメッセージの配信を担当するスマート ホストにメッセージを転送します。

既定では、DNS サーバーは、名前解決クエリなどの通信を UDP ソケット 53 上で待機します。

Exchange サーバー上の SMTP サービスが UDP クエリのみを送信するように構成され、プライマリ外部 DNS サーバーが TCP クエリのみを受け付けるように構成されている場合、メールのルーティングに障害が発生し、メール フローのパフォーマンスに悪影響を及ぼす可能性があります。

この警告に対処するには、次の操作を行います。

  1. 外部 DNS サーバーが起動されていること、およびネットワークからそのサーバーへの接続が可能であることを確認します。

  2. ネットワーク ファイアウォールまたはパケット フィルタが、UDP ポート 53 などの既知の DNS ポートを意図的にブロックしていないことを確認します。

  3. プライマリ外部 DNS サーバーで UDP 名前解決クエリをサポートするように構成されていることを確認します。

DNS および Exchange Server の詳細については、以下の Microsoft サポート技術情報の文書および WebCast を参照してください。

  • 文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • 文書番号 263237「[XCON] Windows 2000 と Exchange 2000 の SMTP の DNS 問い合わせ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=263237)

  • 文書番号 324759「サポート ウェブキャスト : Microsoft Exchange 2000 server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759)


プライマリ WINS サーバーで応答に失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Windows® Management Instrument) クラスの Win32_NetworkAdapterConfiguration に対してクエリを実行し、WINSPrimaryServer 属性を取得します。この属性は、Exchange Server コンピュータ用のプライマリ WINS (Windows Internet Name Service) サーバーの IP アドレスです。Exchange Server アナライザは、プライマリ WINS サーバーのアドレスを取得した後で、サーバーのポート 137 への TCP ソケット接続を開きます。この接続は、接続に成功した場合に特定の文字列を返すカスタム オブジェクト プロセッサを使用することにより、確立します。返された文字列に "137 Available" が含まれていない場合、警告が表示されます。

この警告は、TCP ポート 137 上での接続の試みに対して、そのサーバーが応答しなかったことを示しています。既定では、WINS サーバーは、名前解決クエリなどの通信を TCP ソケット 137 上で待機します。

プライマリ WINS サーバーに到達できず、さらに Exchange Server を実行している場合、大規模な組織では特に、メール配信に時間がかかる可能性があります。プライマリ WINS サーバーが使用できない原因に関するトラブルシューティングを行うか、または Exchange サーバーの WINS 設定を変更して、名前解決に別の WINS サーバーを使用する必要があります。

この警告を修正するには

  1. WINS サーバーが起動し、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、WINS サーバーが到達可能かどうかを判断します。

Exchange 2000 Server と Exchange Server 2003 で WINS が必要な理由については、Microsoft サポート技術情報の文書番号 837391「Exchange Server 2003 および Exchange 2000 Server が完全に機能するには NetBIOS 名前解決が必要である」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=837391) を参照してください。


ポート 389 で応答に失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory 内のすべてのドメイン コントローラの dNSHostName 属性値を判断します。ドメイン コントローラの名前を取得すると、Exchange Server アナライザは、各ドメイン コントローラでポート 389 への TCP ソケット接続を開きます。この接続は、接続に成功した場合に特定の文字列を返すカスタム オブジェクト プロセッサを使用することにより、確立します。返された文字列に 389 Available が含まれていない場合、警告が表示されます。

この警告は、TCP ポート 389 での接続の試行にドメイン コントローラが応答しなかったことを示します。TCP ポート 389 は、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 通信用の既定のポートです。

この警告が表示された場合は、Exchange Server アナライザとドメイン コントローラの間で接続の問題が発生している可能性があります。Exchange Server アナライザがドメイン コントローラに対してクエリを実行したときに、ドメイン コントローラが LDAP 要求を適切に処理できない理由は多数あります。

この警告を修正するには

  1. ツールを実行するアカウントにドメイン コントローラに対するクエリの実行が許可されていることを確認します。ドメイン コントローラが実行されているドメインでは、ユーザー レベルのアクセス許可が必要です。Exchange Server アナライザを実行するために必要なアクセス許可の詳細については、ツールに付属しているヘルプ ファイルを参照してください。Exchange Server アナライザを起動してヘルプ ファイルを開き、[ヘルプ] をクリックします。次に、[Microsoft Exchange Server Analyzer Tool ヘルプ] をクリックします。

  2. Exchange Server アナライザが実行されているコンピュータと、応答に失敗したドメイン コントローラの間に、ファイアウォールおよびポートの制限がないことを確認します。

  3. ドメイン コントローラがネットワークに接続され、正常に機能していることを確認します。

Active Directory の接続の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 816103「[HOWTO] Portqry を使用して Active Directory の接続の問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103) を参照してください。

ドメイン コントローラで Microsoft Windows® Time サービスを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 816042「Windows Server 2003 で権限のあるタイム サーバーを構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816042) を参照してください。


ポート 636 で応答に失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Active Directory 内のすべてのドメイン コントローラの dNSHostName 属性の値を判断します。ドメイン コントローラの名前を取得すると、Exchange Server アナライザは、各ドメイン コントローラでポート 636 への TCP ソケット接続を開きます。この接続は、接続に成功すると特定の文字列を返すカスタム オブジェクト プロセッサを使用して確立されます。返された文字列に 636 Available が含まれていない場合、警告が表示されます。

この警告は、TCP ポート 636 での接続の試行にドメイン コントローラが応答しなかったことを示します。TCP ポート 636 は、Secure LDAP (LDAP over SSL) 通信用の既定のポートです。

Exchange 2000 Server Service Pack 3 の導入により、Exchange Server は、Exchange Server コンピュータ上のローカルの証明書ストアに有効な証明書が存在する場合は、LDAP over SSL を使用して接続するようになります。そのような証明書が存在しない場合や、証明書に関連したエラー (たとえば、ドメイン コントローラが Exchange 証明書を信頼しない、使用されている証明書に強力なキーの保護が必要である、など) が返された場合は、自動的に SSL を使用しない LDAP に戻ります。この警告が表示された場合は、Exchange Server アナライザとドメイン コントローラの間で接続の問題が発生している可能性があります。この警告では、公開キー基盤 (PKI) やその他の証明書の問題は公開されません。

Exchange Server アナライザがクエリを実行したときに、LDAP over SSL 要求がドメイン コントローラによって適切に処理されない原因は多数存在します。

この警告を修正するには

  1. ツールを実行するアカウントにドメイン コントローラに対するクエリの実行が許可されていることを確認します。ドメイン コントローラが動作しているドメインには、ユーザー レベルのアクセス許可が必要になります。Exchange Server アナライザを実行するために必要なアクセス許可の詳細については、ツールに付属しているヘルプ ファイルを参照してください。Exchange Server アナライザを起動してヘルプ ファイルを開き、[ヘルプ] をクリックします。次に、[Microsoft Exchange Server Analyzer Tool ヘルプ] をクリックします。

  2. Exchange Server アナライザが実行されているコンピュータと、応答に失敗したドメイン コントローラの間に、ファイアウォールおよびポートの制限がないことを確認します。

  3. ドメイン コントローラがネットワークに接続され、正常に機能していることを確認します。

  4. Exchange Server アナライザを実行しているコンピュータでの時刻と、応答に失敗したドメイン コントローラでの時刻の同期がとれていることを確認します。ドメイン コントローラ上の Microsoft Windows® タイム サービスが停止しているか、または無効になっていると、ドメイン コントローラのローカル時間が同期していない可能性があります。この場合は、クロックの同期がとれるまで、ドメイン コントローラは LDAP over SSL 要求に応答しません。

LDAP over SSL の使用の詳細については、Microsoft サポート技術情報の文書番号 321051「SSL でどのようにサードパーティの証明機関と LDAP を有効にするには。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321051) を参照してください。

Active Directory の接続の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 816103「[HOWTO] Portqry を使用して Active Directory の接続の問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816103) を参照してください。

Windows タイム サービスの詳細については、Microsoft サポート技術情報の文書番号 816042「Windows Server 2003 で権限のあるタイム サーバーを構成する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=816042) を参照してください。


SMTP サーバーが X-LINK2STATE コマンドをサポートしていない
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーで SMTP セッションを開始して、正しい Exchange SMTP コマンドの一覧が作成されることを確認します。その一覧に X-LINK2STATE コマンドがない場合は、警告が表示されます。

Exchange は X-LIND2STATE コマンドを使用して、ルーティング マスタにあるリンク状態テーブルを更新します。リンク状態テーブルには、Exchange 組織全体にわたる SMTP リンクの状態に関する最新の情報が記録されています。Exchange は、この情報を使用して、メッセージを配信する場合にコストが最小で、信頼性が最も高いルートを選択します。この機能は "インテリジェント ルーティング" とも呼ばれます。

X-LINK2STATE コマンドは、Exchange の効率的なルーティングにとっては必要ですが、他の SMTP プロバイダでは使用されていません。そのため、この機能は Exchange セットアップでインストールおよび登録されたファイル (xlsasink.dll) で提供されます。

この警告が表示される既知の原因として、次の 2 つがあります。最初に、提供されているインテリジェント ルーティング機能を回避するために、管理者が xlsasink.dll を無効にしている可能性があります。この方法は、推奨されるベスト プラクティスではなく、パフォーマンスや信頼性の問題につながる可能性があります。この場合は、影響を受けたコンピュータに Exchange を再インストールして、xlsasink.dll をインストールおよび登録することをお勧めします。

2 番目として、独自の SMTP プロトコル スタックをインストールし、それを使用してメッセージをスキャンするウイルス対策製品を実行している場合に、この警告が返される可能性があります。この場合は、ウイルス対策ソフトウェアが独自の SMTP スタックを実行して、メッセージが Exchange SMTP スタックに届く前にその取得とスキャンを行う可能性があります。このとき、ウィルス対策ソフトウェアの SMTP スタックは X-LINK2STATE コマンドを使用しません。ウイルス対策ソフトウェアを、Exchange サーバーに独自の SMTP スタックをインストールする必要のないモードで実行することをお勧めします。

Exchange で使用されている X-LINK2STATE やその他の専用コマンドの詳細については、Microsoft サポート技術情報の文書番号 812455「2 つの Exchange Server 間で使用される動詞の定義」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812455) を参照してください。

Exchange コマンドの表示および Exchange 2000 Server の再インストールの方法の詳細については、Microsoft サポート技術情報の文書番号 319885「[XCON] Exchange 2000 Server 組織内で送信されたメッセージが配信されない」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319885) を参照してください。

Exchange コマンドの表示および Exchange Server 2003 の再インストールの方法の詳細については、Microsoft サポート技術情報の文書番号 822939「Exchange Server 2003 組織いる NOT で送信されるメッセージは、配信しました。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822939) を参照してください。


SMTP サーバーがメール受信テストに失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、以下のタスクを実行して SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントにメッセージを送信しようとします。

  • SMTP サーバーへのソケット接続を開く。Exchange Server アナライザが、応答コード 220 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • EHLO SMTP コマンドを送信する。Exchange Server アナライザが、一連の応答コード 250 (250-X-LINK2STATE および 250-XEXCH50 を含む応答など) を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • MAIL FROM: ExBPA-MailAcceptTest@Fabrikam.com SMTP コマンドを送信する。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • RCPT TO: Postmaster@<ドメイン名>.com SMTP コマンドを送信する。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

正常に完了できない手順が 1 つでもあると、エラーが表示されます。エラーは、一般的なメール フローに問題が存在する可能性があることを示します。以下に、トラブルシーティングを行う際に役立つリンクを、サーバー レベルからネットワーク レベルまで、実行すべき順序で示します。

このエラーを修正するには

  1. 『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?linkid=47579) の「Troubleshooting Routing」を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 324867「サポート: Microsoft Exchange 2000 Server: メール フロー (revisit された) 問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324867) を参照してください。

  3. Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」((http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823489) を参照してください。

  4. Microsoft サポート技術情報の文書番号 324759「サポート: Microsoft Exchange 2000 Server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759) を参照してください。

Exchange Server におけるポストマスタ アカウントの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 223860「[XCON] SMTP: ポストマスタ メールボックスは手動で設定する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=223860)

  • 文書番号 313832「[HOW TO] Exchange 2000 Server で SMTP ポストマスタ アカウントを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313832)


SMTP サーバーがオープン リレー テストに失敗した
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2007-03-14

Microsoft® Exchange Server アナライザ ツールは、以下のタスクを実行することによって、SMTP (Simple Mail Transfer Protocol) サーバーを経由するメッセージの中継を試みます。

  • SMTP サーバーへのソケット接続を開きます。Exchange Server アナライザが、応答コード 220 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • EHLO SMTP コマンドを送信します。Exchange Server アナライザが、一連の応答コード 250 (250-X-LINK2STATE および 250-XEXCH50 を含む応答など) を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • "MAIL FROM: ExBPA-OpenRelayTest@Fabrikam.com" SMTP コマンドを送信します。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • "RCPT TO: ExBPA-OpenRelayTest@Fabrikam.com" SMTP コマンドを送信します。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

Exchange Server アナライザは、Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーの値は、Windows Server オペレーティング システムの特定のバージョンに対応します。

Exchange Server アナライザが、Microsoft Windows Small Business Server 2000 または Microsoft Windows Small Business Server 2003 のインストールの一部である Exchange Server コンピュータですべての手順を正常に完了できた場合、エラーが表示されます。

このエラーは、このサーバーがオープン リレー サーバーとして構成されていることを示します。

ベスト プラクティスとしては、オープン リレーを許可することはお勧めできません。

オープン リレーは、電子メール サーバーで、中継対象の電子メールに対して制限や制御を一切行わずに、そのシステムを経由した電子メール メッセージの中継を許可している場合に発生します。

注 :
何らかの理由で Exchange 組織が Fabrikam.com という名前の SMTP ドメインを使用している場合、このエラーが発生する可能性があります。この場合は、このエラーを無視してかまいません。Fabrikam.com ドメインは Microsoft Corporation が所有しており、トレーニング、ドキュメント、およびそれらに類似した目的のために使用されています。

SMTP は中継を目的として設計されたため (詳細については、http://ietf.org で RFC 2821 ドキュメントのセクション 2.1 と 3.7 を参照)、中継は本来、悪いことではありません。ただし中継が制御されていないと (制御されていないホストはオープン リレー ホストと呼ばれます)、悪意を持つユーザーが中継を使用して、迷惑な商用電子メール メッセージ (スパムまたは UCE) を大量に送信するおそれがあります。これらの迷惑な電子メール メッセージを中間のホストを介して転送することで、悪意を持つユーザーは自分の身元を隠そうとします。この動作によって中継ホストのリソースも占有されて、中継ホストによる有効な電子メール メッセージの送信が妨害される場合があります。特に問題なのは、そのような迷惑な電子メール メッセージを送信するユーザーの大半は、メールを送信するために自分の帯域幅を使用しないで膨大な数の受信者に 1 つのメッセージを送信できる点です。

インターネットに面している SMTP 仮想サーバーで匿名の中継を許可していないことを確認してください。Exchange は、既定の構成では、認証されたユーザーのみにメールの中継を許可します。認証されたユーザーのみが、Exchange を使用して外部ドメインにメールを送信できます。権限のないユーザーの中継を許可するように既定の中継設定を変更する場合、または、コネクタ経由でドメインへのオープン リレーを許可する場合、権限のないユーザーや悪意のあるワームがスパムの送信に Exchange サーバーを使用できるようになります。このようなサーバーはブロック リストに記載され、正当なリモート サーバーにメールを送信できなくなる可能性があります。権限のないユーザーが Exchange サーバーを使用してメールを中継しないようにするには、最低でも既定の中継制限を使用してください。

中継を行う正当な理由がある場合、使用する実装においてセキュリティが維持されることを保証するためのガイドラインに従ってください。これは主に、既定値をすべて拒否した状態で、中継するメールを受け付ける IP アドレスのみを追加し、認証されたユーザーのアクセスを無効にする方法によって行われます。

ゲートウェイ サーバーで、ビルトイン アカウント (ローカルの Administrator) および他のユーザーがどのように使用されているかを確認します。ビルトイン アカウントを、いずれかの種類の中継に使用することは通常はありません。中継を行っている場合、その中継は通常は 1 組の既知のユーザーまたはコンピュータによるものです。中継の権限は、明示的に指定したユーザーとコンピュータ、または IP アドレスに制限することをお勧めします。

中継のためのアクセス許可を明示的に構成すると、サーバーの防護をより強化するために役立ちます。悪意のあるユーザーがブルート フォース攻撃を使用して、ビルトイン アカウントや、インターネットで見つけたユーザー アカウントのパスワードを入手し、サーバーをスパムのプロキシとして使用できるようにしようと試みる可能性があります。したがって、認証されたすべてのコンピュータに中継を許可する既定の設定は、インターネットからアクセス可能なコンピュータでは使用しないことをお勧めします。この設定は無効にすることをお勧めします。

以下の手順では、SMTP 仮想サーバーがインターネットに面しているかどうかに基づいて、匿名の中継を無効にする方法について説明します。この文書で前に説明したように、どのような形式の匿名中継であっても、組織がセキュリティ上のリスクを理解し、それを許容できる場合に限って実施する必要があります。この文書の最後にある参照情報では、中継を使用する方法の詳細が紹介されています。

SMTP 仮想サーバーがインターネットからアクセスできない場合は、中継の構成を既定値にリセットすることをお勧めします。これによって SMTP 仮想サーバーは、認証されたコンピュータからの内部的な中継のみを許可するようになります。

インターネットからアクセスできる SMTP 仮想サーバーの場合は、中継に関する既定の構成のセキュリティを強化し、明示的なアクセス許可を持つユーザーとコンピュータのみに中継を許可することをお勧めします。

Exchange が中継をブロックするように構成されていることを確認した後も、Exchange Server アナライザでこのエラーを受け取る場合は、ファイアウォール ソフトウェア、ウイルス対策ソフトウェア、スパム対策ソフトウェアなどのプロキシ サーバーやプロセスで匿名の中継が許可されていないことを確認する必要があります。

内部の SMTP 仮想サーバーで匿名中継の構成を既定の設定にリセットするには

  1. Exchange システム マネージャを起動します。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. 中継の制限を適用する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[アクセス] タブをクリックし、[中継] をクリックします。

  5. [中継の制限] ダイアログ ボックスの [この仮想サーバーを中継に使用するコンピュータを選択してください。] で、[以下のリストに含まれるコンピュータのみ] を選択し、[上のコンピュータの一覧に関係なく、正しく認証されたすべてのコンピュータが、この仮想サーバーを中継に使用する] チェック ボックスをオンにします。次に [OK] をクリックします。

Exchange Server 2003 で、インターネットに面している SMTP 仮想サーバーに対して明示的な中継のアクセス許可を構成するには

  1. Exchange システム マネージャを起動します。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. 中継の制限を適用する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[アクセス] タブをクリックし、[中継] をクリックします。

  5. [中継の制限] ダイアログ ボックスで、[上のコンピュータの一覧に関係なく、正しく認証されたすべてのコンピュータが、この仮想サーバーを中継に使用する] チェック ボックスをオフにします。次に、[ユーザー] をクリックし、この SMTP 仮想サーバーでの中継アクセス許可を与えるユーザーのサブセットを指定します。

  6. [発信および中継のアクセス許可] ダイアログ ボックスで、グループまたはユーザーを削除するには、そのグループまたはユーザーを選択し、[削除] をクリックします。

  7. グループまたはユーザーを追加するには、[追加] をクリックし、アクセス許可を指定するグループまたはユーザーを選択します。次のいずれかのオプションを選択します。

    • Microsoft Windows Server™ 2003 では、[ユーザー、コンピュータまたはグループの選択] ダイアログ ボックスで、[選択するオブジェクト名を入力してください] にユーザーまたはグループの名前を入力します。ユーザーまたはグループを検索する場合は、[詳細設定] をクリックし、ユーザーまたはグループの名前を検索します。次に、[名前の確認] をクリックして入力した名前を検証します。

      ヒント :
      [(例)] リンクをクリックすると、使用可能な入力形式を表示することができます。
    • Windows 2000 Server では、[ユーザー、コンピュータ、またはグループの選択] ダイアログ ボックスで、発信アクセス許可を与えるグループまたはユーザーを選択し、[追加] をクリックします。

  8. [OK] をクリックし、[発信および中継のアクセス許可] ダイアログ ボックスに戻ります。

  9. [グループ名またはユーザー名] ボックスの一覧で、追加したグループを選択します。

  10. 必要に応じて、[<選択したグループ> のアクセス許可] で [発信アクセス許可] の隣にある [許可] チェック ボックスをオンにして、選択したユーザーまたはグループに、この SMTP 仮想サーバーを介したメールの発信を許可します。

  11. [中継アクセス許可] の隣にある [許可] の下のチェック ボックスをオンにして選択したオブジェクトにこの SMTP 仮想サーバーの中継を許可するか、[拒否] の下のチェック ボックスをオンにして選択したオブジェクトがこのコネクタを中継できないようにします。

    注 :
    [中継アクセス許可] を許可する場合は、[発信アクセス許可] を許可する必要があります。

  12. [OK] をクリックします。

Exchange 22000 Server で、インターネットに面している SMTP 仮想サーバーに対して中継アクセス許可を構成するには

  1. Exchange システム マネージャを起動します。

  2. コンソール ツリーで、[サーバー] を展開し、構成するサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. 中継の制限を適用する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[アクセス] タブをクリックし、[中継] をクリックします。

  5. [中継の制限] ダイアログ ボックスの [この仮想サーバーを中継に使用するコンピュータを選択してください。] で、[以下のリストに含まれるコンピュータのみ] を選択します。

  6. [追加] をクリックして単一のコンピュータ、コンピュータのグループ、または SMTP ドメイン名を追加し、[OK] をクリックします。追加するエントリごとに、この手順を繰り返します。

  7. [上のコンピュータの一覧に関係なく、正しく認証されたすべてのコンピュータが、この仮想サーバーを中継に使用する] チェック ボックスをオンにし、[OK] を 2 回クリックします。

メッセージの中継とセキュリティの詳細については、Exchange Server 2003 テクニカル ライブラリの以下のガイドを参照してください。

  • 『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?linkid=47579) (このサイトは英語の場合があります)

  • 「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?linkid=47587) (このサイトは英語の場合があります)

Exchange および Microsoft Windows 環境でのオープン リレーの動作テストとセキュリティ保護の詳細については、Microsoft サポート技術情報の文書番号 304897「[XIMS] サード パーティのテストでマイクロソフトの SMTP サーバーが電子メール メッセージを受け入れ、中継しているように見えることがある」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=304897) を参照してください。


実行しているバージョンの SMTP で XEXCH50 コマンドがサポートされていない
Microsoft Exchange Server アナライザ - 文書 > ネットワーク >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーで SMTP セッションを開始して、正しい Exchange SMTP コマンドの一覧が作成されることを確認します。その一覧に XEXCH50 コマンドがない場合は、警告が表示されます。

XEXCH50 コマンドは、特に、Exchange によってパブリック フォルダのレプリケーションのために使用されます。Exchange サーバーで XEXCH50 コマンドをサポートしていないバージョンの SMTP を実行すると、パブリック フォルダのレプリケーションが中断されます。

XEXCH50 コマンドは、他の SMTP プロバイダでは使用されません。そのため、この機能は、Exchange セットアップでインストールおよび登録されたファイル (peexch50.dll) で提供されます。

メッセージのスキャンのために独自の SMTP プロトコル スタックをインストールして使用するウイルス対策製品を実行している場合は、Exchange Server アナライザによってこの警告が返される可能性があります。この場合は、メッセージが Exchange SMTP スタックに届く前に、ウイルス対策ソフトウェアが独自の SMTP スタックを使用してメッセージの取得およびスキャンを行います。このとき、ウイルス対策ソフトウェアの SMTP スタックは XEXCH50 コマンドを使用しません。

ウイルス対策ソフトウェアは、Exchange サーバーに独自の SMTP スタックをインストールする必要のないモードで実行するか、または SMTP ネットワークの受信境界で実行することをお勧めします。ウイルス対策ソフトウェアの SMTP スタックを無効にしても引き続きこの警告が表示される場合は、Exchange を再インストールして、peexch50.dll を正しくインストールおよび登録してください。

Exchange で使用される XEXCH50 やその他の専用コマンドの詳細については、Microsoft サポート技術情報の文書番号 812455「2 つの Exchange Server 間で使用される動詞の定義」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812455) を参照してください。

Exchange コマンドの表示および Exchange 2000 Server の再インストールの方法の詳細については、Microsoft サポート技術情報の文書番号 319885「[XCON] Exchange 2000 Server 組織内で送信されたメッセージが配信されない」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319885) を参照してください。

Exchange コマンドの表示および Exchange Server 2003 の再インストールの方法の詳細については、Microsoft サポート技術情報の文書番号 822939「Exchange Server 2003 組織いる NOT で送信されるメッセージは、配信しました。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822939) を参照してください。


プロトコル
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクションの文書では、Mcrosoft® Exchange Server アナライザ ツールで、インターネット プロトコルに関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出されたインターネット プロトコル関連のエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


Active Directory ラウンド トリップの応答エラー
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PingStatus Microsoft WMI (WindowsR Management Instrumentation) クラスに対してクエリを実行し、Active Directory® ディレクトリ サービス サーバーから返される StatusCode キーの値を判断します。Win32_PingStatus が返すオブジェクトには 24 のプロパティがあり、クラスが送信する ping パケットについて詳しい情報を提供しています。

このキーの値が次の表に示すいずれかの値と一致することが検出されると、エラーが表示されます。

Exchange Server アナライザには、Active Directory サーバーの名前と、エラーと共に返された対応する StatusCode 値が表示されます。

StatusCode 値 意味 説明

11001

バッファが小さすぎます

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11002

宛先ネットワークに到達できません

宛先のコンピュータが含まれるネットワークに到達できないために要求が失敗しました。宛先コンピュータへの有効なルートが存在しません。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11003

宛先ホストに到達できません

宛先コンピュータに到達できないために要求が失敗しました。

詳細については、「Active Directory サーバーが停止しているか、Active Directory サーバーに到達できない」を参照してください。

このエラーはその他に、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールや、DNS エラーのために発生する場合があります。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11004

宛先プロトコルに到達できません

宛先コンピュータがパケットのプロトコルに応答しないために要求が失敗しました。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11005

宛先ポートに到達できません

宛先コンピュータのポートを使用できないために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11006

リソースがありません

ネットワーク リソースが不足しているために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11007

オプションが正しくありません

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11008

ハードウェア エラーです

ハードウェア エラーのために要求が失敗しました。

コンピュータの製造元から提供されているハードウェアの稼動状態確認ツールを実行して、ドメイン コントローラが適切に動作可能であることを確認してください。

11009

パケットが大きすぎます

要求を含むパケットのサイズが、送信元と宛先の間にあるノード (ルーターまたはゲートウェイ) の最大転送ユニット (MTU) より大きいため、要求が失敗しました。MTU は、転送可能なパケットの最大サイズを定義します。

Exchange Server アナライザから送信される要求のサイズは、10 KB より大きくありません。組織内のルーターとゲートウェイが適切に構成されていることを確認してください。

詳細については、Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と対処」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211) を参照してください。

11010

要求がタイムアウトしました

割り当てられた時間内に応答を受信しませんでした。応答に許されている既定の時間は 5 秒です。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11011

要求が正しくありません

エンコードが正しくないために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11012

無効なルートです

送信元コンピュータと宛先コンピュータの間に有効なルートがないため、要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11013

転送中に TimeToLive 有効期限が切れました

TTL (Time to Live) の値が 0 に達したため要求が失敗しました。転送を行うノード (ルーターまたはゲートウェイ) では、このためにパケットが破棄されています。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11014

再構築中に TimeToLive 有効期限が切れました

パケットが転送用の断片に分割されて、再構築に割り当てられている時間内にすべての断片が受信されなかったため、要求が失敗しました。RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) では、すべてのパケットの断片を受信する必要がある時間制限として、60 秒が指定されています。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11015

パラメータに問題があります

パケット ヘッダーの処理中にノード (ルーターまたはゲートウェイ) で問題が発生したため、要求が失敗しました。この状態は、たとえば、ヘッダーに無効なフィールド データや認識できないオプションが含まれている場合に発生します。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11016

発信元が抑制されています

パケットが破棄されたため要求が失敗しました。この問題は、送信元コンピュータの出力キューに十分な記憶域がないか、処理するには速すぎる速度でパケットが宛先に到着している場合に発生します。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11017

オプションが大きすぎます

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11018

宛先が正しくありません

宛先 IP アドレスが PING 要求を受信することができないか、どの IP データグラムの宛先アドレス フィールドにも宛先 IP アドレスが含まれていてはいけないため、要求が失敗しました。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11032

IPSEC のネゴシエート中です

IPsec 接続をネゴシエートできなかったために要求が失敗しました。

11050

一般エラーです

不明な理由で要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


Active Directory から Exchange へのラウンド トリップの応答エラー
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-15

Microsoft® Exchange Server アナライザ ツールは、Win32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Active Directory® ディレクトリ サービス サーバーから返される StatusCode キーの値を判断します。Win32_PingStatus が返すオブジェクトには 24 のプロパティがあり、クラスが送信する ping パケットについて詳しい情報を提供しています。

このキーの値が次の表に示すいずれかの値と一致することが検出されると、エラーが表示されます。

Exchange Server アナライザには、Active Directory サーバー名、Exchange Server 名、およびこのエラーと共に返された対応する StatusCode 値が表示されます。

StatusCode 値 意味 説明

11001

バッファが小さすぎます

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11002

宛先ネットワークに到達できません

宛先コンピュータが含まれるネットワークに到達できないために要求が失敗しました。宛先コンピュータへの有効なルートが存在しません。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11003

宛先ホストに到達できません

宛先コンピュータに到達できないために要求が失敗しました。

詳細については、「Active Directory サーバーが停止しているか、Active Directory サーバーに到達できない」を参照してください。

また、このエラーは次のいずれかの条件により発生する可能性があります。

  • Exchange Server アナライザが実行されている場所と対象のドメイン コントローラの間にファイアウォールが存在する。

  • DNS エラー。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11004

宛先プロトコルに到達できません

宛先コンピュータがパケットのプロトコルに応答しないために要求が失敗しました。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11005

宛先ポートに到達できません

宛先コンピュータのポートを使用できないために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11006

リソースがありません

ネットワーク リソースが不足しているために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11007

オプションが正しくありません

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11008

ハードウェア エラーです

ハードウェア エラーのために要求が失敗しました。

コンピュータの製造元から提供されているハードウェアの稼動状態確認ツールを実行して、ドメイン コントローラが適切に動作可能であることを確認してください。

11009

パケットが大きすぎます

要求を含むパケットのサイズが、送信元と宛先の間にあるルーターまたはゲートウェイ ノードの最大転送ユニット (MTU) より大きいため、要求が失敗しました。MTU は、転送可能なパケットの最大サイズを定義します。

Exchange Server アナライザから送信される要求は、10 KB より大きくありません。組織内のルーターとゲートウェイが適切に構成されていることを確認してください。

詳細については、Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と問題解決」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211) を参照してください。

11010

要求がタイムアウトしました

割り当てられた時間内に応答を受信しませんでした。応答に許されている既定の時間は 5 秒です。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11011

要求が正しくありません

エンコードが正しくないために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11012

無効なルートです

送信元コンピュータと宛先コンピュータの間に有効なルートがないため、要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11013

転送中に TimeToLive 有効期限が切れました

TTL (Time to Live) の値が 0 に達したために要求が失敗しました。転送しているルーターまたはゲートウェイ ノードでは、このためにパケットが破棄されます。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11014

再構築中に TimeToLive 有効期限が切れました

パケットが転送用の断片に分割されて、再構築に割り当てられている時間内にすべての断片が受信されなかったため、要求が失敗しました。RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) では、すべてのパケットの断片を受信する必要がある時間制限として、60 秒が指定されています。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11015

パラメータに問題があります

パケット ヘッダーの処理中にルーターまたはゲートウェイ ノードで問題が発生したため、要求が失敗しました。この状態は、ヘッダーに無効なフィールド データや認識できないオプションが含まれている場合に発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11016

発信元が抑制されています

パケットが破棄されたため要求が失敗しました。この問題は、送信元コンピュータの出力キューに十分な記憶域がない場合に発生します。また、処理するには速すぎる速度でパケットが宛先に到着した場合にも発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11017

オプションが大きすぎます

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11018

宛先が正しくありません

次のいずれかの理由により要求が失敗しました。

  • 宛先 IP アドレスが PING 要求を受信できない。

  • 宛先 IP アドレスが IP データグラムの宛先アドレス フィールドに含まれている。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11032

IPSEC のネゴシエート中です

IPsec 接続をネゴシエートできなかったために要求が失敗しました。

11050

一般エラーです

不明な理由で要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


内部の SMTP 仮想サーバーと、IMAP および POP クライアント専用の SMTP 仮想サーバーで、匿名アクセスが許可されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server オブジェクトの protocolCfgSMTPServer クラスの msExchAuthenticationFlags 属性値を判断します。protocolCfgSMTPServer クラスには、SMTP 仮想サーバーの設定が含まれています。msExchAuthenticationFlags 属性は、SMTP サーバーで許可される認証の種類を表します。以下の条件に当てはまる場合は、警告メッセージが表示されます。

  • msExchAuthenticationFlags 属性の認証が、SMTP サーバーへの匿名アクセスを許可するように構成されている。

  • サーバーで Microsoft Small Business Server 2000 または Microsoft WindowsR Small Business Server 2003 が実行されていない。

  • Exchange Server で、20 を超えるメールボックスがホストされている。

セキュリティを強化するため、受信したインターネット メールを受け付けない内部 SMTP 仮想サーバーでは匿名アクセスを無効にしてください。セキュリティをさらに強化するために、リモートの IMAP および POP ユーザー専用の SMTP 仮想サーバーでも匿名アクセスを無効にすることができます。

重要 :
インターネット ブリッジヘッド SMTP 仮想サーバーでは、匿名アクセスを無効にしないでください。インターネットからのメールを受け付ける SMTP 仮想サーバーでは、匿名アクセスを許可する必要があります。

内部メールを送信する場合、組織内の Exchange Server は相互に認証を行ってメールを送信します。したがって、内部 SMTP 仮想サーバーで匿名アクセスを有効にする必要はありません。内部サーバーでの匿名アクセスを防止することによって、メール フローは中断されず、内部 SMTP 仮想サーバーに追加のセキュリティ層が備わります。

同様に、IMAP クライアントや POP クライアントは SMTP 仮想サーバーにメールを送信する前に、それらのサーバーとの間で認証を行います。したがって、IMAP および POP クライアント専用の SMTP 仮想サーバーを使用する場合は、認証済みアクセスのみを許可するようにこれらのサーバーを構成できます。これらのサーバーで匿名アクセスを無効にすると、権限のないユーザーによるサーバーへのアクセス防止に役立ちます。

パートナー企業による認証のように、ビジネス上の理由によって SMTP 仮想サーバーで認証済みアクセスを無効にできない場合は、以下の手順に従って、ゲートウェイ サーバーでのセキュリティを強化します。

  • すべてのユーザー アカウント (特に管理者アカウント) に対し、強力なパスワード ポリシーを適用します。

  • Guest アカウントを無効にします。Guest アカウントの無効化の詳細については、Microsoft サポート技術情報の文書番号 320053「Windows 2000 の管理者と Guest アカウントの名前を変更する方法。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=320053) を参照してください。この文書は Windows 2000 Server を対象としていますが、同様の原則が Windows Server 2003 にも当てはまります。

SMTP 仮想サーバーの匿名アクセスの認証を無効にするには、次の操作を行います。

  1. Exchange システム マネージャで、[サーバー] を展開し、<使用している受信 Exchange サーバー> を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. 受信 SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  3. [アクセス] タブをクリックし、[認証] をクリックします。

  4. [認証] ダイアログ ボックスで、[匿名アクセス] チェック ボックスをオフにします。

インターネット メールをより安全に送受信できる Exchange Server 2003 組織の構成の詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


バックグラウンド ウイルス対策スキャンが有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、バックグラウンド ウイルス対策スキャンが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

BackgroundScanning エントリの値が 1 に設定されていることが検出されると、警告が表示されます。

BackgroundScanning レジストリ エントリが存在し、1 に設定されている場合、ウイルス対策プログラムの署名ファイルを更新するたびに、すべてのメッセージがバックグラウンドで再スキャンされます。この動作によって、ウイルス対策署名ファイルを更新するたびにパフォーマンスが大幅に低下するため、Microsoft ではお勧めしていません。

VSAPI (Virus Scanning Application Programming Interface) 2.0 に基づくウイルス対策プログラムを使用している状態で、クライアントがメッセージを開こうとすると、メッセージ本文と添付ファイルが最新のウイルス シグネチャ ファイルによってスキャンされたことを確認するために、比較が行われます。最新の署名パターン ファイルを使用して内容をスキャンしなかった場合は、その旨のメッセージがウイルス対策プログラムに送信されてから、そのメッセージがクライアントで開けるようになります。

インストールされているウイルス対策プログラムに、バックグラウンド スキャンを無効にするユーザー インターフェイスが組み込まれていない場合は、以下の手順に従って Exchange Server コンピュータのレジストリを変更し、この動作を制御します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. 右側のペインで、[BackgroundScanning] 値をダブルクリックします。

  4. [値のデータ] ボックスで、値を 0 に変更します。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスおよびウイルス対策ソフトウェアのサービスを再開して、変更を有効にします。
  • レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

  • Exchange によって使用される各種ウイルス対策スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。


CheckPop3Tail 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\CheckPop3Tail

CheckPop3Tail 値が存在し、1 に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

インターネット特別技術調査委員会 (IETF) の RFC (Request for Comments) 1939 (http://www.ietf.org/rfc/rfc1939.txt) には、POP3 メッセージでの CRLF の終了シーケンスが規定されています (このサイトは英語の場合があります)。Exchange の用語では、CRLF シーケンスを POP3Tail と呼びます。Microsoft Office Outlook® 2003 や Microsoft Outlook Express などの POP3 クライアントが、POP3Tail が正しくない、形式に誤りのあるメッセージ (たとえば、CRLF がない場合) を受信すると、応答を停止します。さらに、受信トレイ内にあるメッセージのすべてをダウンロードすることに失敗する可能性があります。CheckPop3Tail レジストリ値を使用すると、管理者は構成を変更して、各 POP3 メッセージの POP3Tail を確認し、それが消失している場合は正しい終了シーケンスを追加するよう Microsoft Exchange POP3 サービスに指示することができます。

注 :
この設定により、形式に誤りのあるメッセージが修正され、POP3 クライアントはユーザーの受信トレイ内にあるすべてのメッセージをダウンロードできるようになります。ただし、各メッセージについて POP3Tail の正しさが確認されるため、パフォーマンスもわずかに低下します。

必要な場合は、以下の手順を使用して CheckPop3Tail レジストリ値を削除することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

CheckPop3Tail レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. CheckPop3Tail という名前の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange POP3 サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

CheckPop3Tail レジストリ値の使用方法の詳細については、Microsoft サポート技術情報の文書番号 816896「[XCCC] メッセージのダウンロード時に POP3 クライアントが応答を停止するか、タイムアウトが発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816896) を参照してください。


Defense Message System が有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、heuristics 属性が Defense Message System を有効にするように構成されているかどうかを判断します。既定では、heuristics 属性は構成されていません。Exchange Server アナライザによって、heuristics 属性が 256 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Defense Message System (DMS) プログラムは、writer-to-reader 要件を満たし、コストとスタッフを抑え、機能、セキュリティ、存続性、可用性を向上させる、一般ユーザーの統合メッセージ システム開発を促進および調整するために、Under Secretary of Defense (Acquisition) によって確立されました。

Defense Message System の詳細については、Lockheed Martin Web サイト (http://www.lockheedmartin.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Disable MAPI clients に関する警告
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-05-01

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、MAPI クライアント ブロックが設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable MAPI Clients

Disabled MAPI Clients が -10、-11 または -12 で始まる値で設定されていることが検出されると、警告が表示されます。

既定では、Disable MAPI Clients キーは有効になっていません。したがって、管理者は特定のバージョンの Microsoft Office® Outlook が Exchange 2000 Server、Exchange Server 2003 または Exchange Server 2007 を実行しているコンピュータに接続できないようにすることができます。

Disabled MAPI Clients キーが -10、-11 または -12 で始まる値に設定されている場合は、その範囲のすべての MAPI のバージョンがブロックされます。これらの範囲は、Outlook 2000、Outlook 2003 および Outlook 2007 のバージョン、および Exchange Server 2003 の Exchange System Attendant に対応します。Exchange System Attendant サービスをブロックすると、Exchange Server に誤動作が発生する可能性があります。

この警告を修正するには、「すべてのバージョンの Outlook がサーバーへのアクセスを許可されている」に記載されている推奨事項と手順に従ってください。

特定の MAPI クライアントが Exchange 2000 Server または Exchange Server 2003 コンピュータに接続できないようにする方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328240「Exchange 2000 メールボックスへのアクセスに使用されるクライアントにサーバー側の制限を置く方法。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328240)

  • 文書番号 288894「[XADM] MAPI クライアントのアクセスを禁止する機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=288894)

Exchange Server 2007 を実行しているコンピュータで特定の MAPI クライアントからの接続をブロックする方法については、Exchange Server 2007 の製品ドキュメントで Exchange Management Shell の "Set-CasMailbox" コマンドレットについてのページを参照してください (http://go.microsoft.com/fwlink/?LinkId=80698) (このサイトは英語の場合があります)。

古いバージョンの Outlook 用セキュリティ更新プログラムをダウンロードする方法、および他のバージョンの Outlook のブロックに関する詳細については、Exchange Server 2003 環境で電子メール経由のウイルスを鎮静化および遮断する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=30732) を参照してください (このサイトは英語の場合があります)。


DisableSMTPMailboxAddressing 値が設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-08-11

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、値が SMTP (Simple Mail Transfer Protocol) メールボックスのアドレス指定を無効にするように設定されているかどうかを判断します。

HKeyLocalMachine\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\DisableSMTPMailboxAddressing

DisableSMTPMailboxAddressing キーの値 1 は SMTP メールボックスのアドレス指定が無効 (True) であることを示し、値 0 はSMTP メールボックスのアドレス指定が有効 (False) であることを示します。

SMTP メールボックスのアドレス指定を無効にするように DisableSMTPMailboxAddressing キーの値が 1 に設定されていると判断すると、Exchange Server アナライザは警告を表示します。

このエラーは、SMTP メールボックスのアドレス指定が無効であることを示します。このエラーは、このサーバーに接続する Microsoft Exchange ActiveSync クライアントの同期エラーを引き起こす可能性があります。

この警告を修正するには、DisableSMTPMailboxAddressing キーの値を 0 に設定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
DisableSMTPMailboxAddressing キーの値を変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

HKeyLocalMachine\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA

  1. 右側のペインで、[DisableSMTPMailboxAddressing] を見つけてダブルクリックします。

  2. 値を 1 から 0 に変更します。

  3. レジストリ エディタを終了し、このサーバー サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、マイクロソフト サポート技術情報の文書番号 256986 の、Microsoft Windows レジストリの説明についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この警告に関連する同期エラーの詳細については、マイクロソフト サポート技術情報の文書番号 886346 の、モバイル デバイスと Microsoft Exchange Server 2003 との同期時に HTTP_500 のエラー メッセージが表示される現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=886346) を参照してください。


ユーザー負荷の分散
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、サーバーの 1 秒あたりの RPC 操作数が多くなっていると判断しました。

サーバーの 1 秒あたりの RPC 操作数が多くなっている場合、Exchange Server User Monitor (ExMon) を使用して、負荷がどのように分散されているかを識別することができます。以下のいずれの状況で負荷が発生しているかを判断することが重要です。

  • アクティブ ユーザーの数が比較的少ない。

  • 負荷が多くのユーザーに分散されている。

1 人のユーザーが高い割合で負荷を引き起こしていると識別された場合、Exchange Server アナライザは、高い使用率が 1 人のユーザーによるものであることを示す警告を表示します。そうでない場合は、負荷が多くのユーザー間に分散していることを示すメッセージが表示されます。

注 :
RPC トラフィックは、時間と共に変化します。したがって、ユーザーの Exchange の使用法に関するデータを統計的に取得するには、データを複数回収集する必要があります。

また、いくつかの一般的なユーザー操作が一時的に大量の CPU リソースを使用することもよくあることです。同じユーザーが大量の CPU リソースを頻繁に、または長時間にわたって使用している場合を除き、この状況は心配する必要はありません。

注 :
高い負荷になることが予想されていて、どのプロセスが多数のユーザーの要求を処理し、個々のユーザーよりも負荷が高くなるかがわかっているサービスやプロセスが原因である場合は、この警告を無視してかまいません。たとえば、モバイル デバイスを同期させるサービス、空き時間情報を管理するサーバー プロセス、ボイス メールやユニファイド メッセージングに関連するサービス、ユーザーを移動するサーバー プロセスなどには、個々のユーザーよりも負荷が高くなる可能性があるサービスやプロセスがいくつかあります。
この問題を修正するには

  • RPC 率が高い場合 (1 人のユーザーまたはすべてのユーザーについて)、ユーザーがデスクトップ検索エンジン、サードパーティ製のクライアント プラグイン、または電子メールとユーザーのメールボックスを同期するモバイル デバイスを使用しているかどうかを調べます。サードパーティ製アプリケーションのトラブルシューティングの詳細については、「クライアントでサードパーティ製のアドインを無効にする」を参照してください。

  • ユーザーが既定の、または使用頻度の高いフォルダに持つアイテムの数は 5,000 未満になるようにします。

  • ベスト プラクティスとして、メールボックスのサイズは 1 GB 以下にしてください。高い負荷を引き起こしているユーザーについては、そのユーザーのメールボックス アイテムを .pst ファイルにアーカイブすることをお勧めします。次に、Exchange Performance (Perfmon) ツールを再度実行し、そのユーザーが継続的に高い負荷を引き起こしているかどうかを調べます。

  • ユーザーに問い合わせ、クライアントの電子メール プログラムにアクセスしている可能性があるクライアント アプリケーションを特定します。これらのアプリケーションを削除してから 1 つずつ再インストールし、サーバーに与える影響を調べます。

  • ユーザー負荷のトラブルシューティングを行うときに、誤検出が行われることがよくあります。したがって、負荷の高い時間帯に ExMon を再度実行し、分析が整合しているかどうかを確認することをお勧めします。

詳細情報

  • Exchange Server User Monitor (ExMon) をダウンロードするには、Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=54983) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • Outlook クライアントのパフォーマンスに関する問題のトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 905803「Exchange Server 2003 または Exchange 2000 Server を実行しているサーバーに多くの項目を含むフォルダを使用する場合、Outlook ユーザーで不完全なパフォーマンスが発生します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803) を参照してください。

  • デスクトップ検索ソフトウェアの詳細については、Microsoft サポート技術情報の文書番号 905184「Exchange 2000 Server と Exchange Server 2003 パフォーマンスが Outlook または他の MAPI クライアント コンピュータでデスクトップ検索エンジン ソフトウェアが実行されている場合、影響される可能性があります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905184) を参照してください。


OMA および EAS の Exchange 仮想ディレクトリが無効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ActiveSync® の SMTP プロキシ アドレスが無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir

ExchangeVDir レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ExchangeVDir レジストリ エントリは、Microsoft Outlook® Mobile Access および Exchange ActiveSync が使用します。このエントリは、ユーザーのメールボックスが配置されている Exchange Server 2003 バックエンド サーバー上にある Microsoft Office Outlook Web Access for Exchange Server 2003 テンプレートおよび WebDAV にアクセスする際に Outlook Mobile Access および Exchange ActiveSync が使用する仮想ディレクトリを指定します。

ExchangeVDir エントリが存在しない場合、またはこのエントリに対して値が設定されていない場合は、既定値の /Exchange が使用されます。それ以外の場合、エントリにはスラッシュ (/) を含む仮想ディレクトリ名が含まれています。Outlook Mobile Access または Exchange ActiveSync の仮想ディレクトリを指定する場合は、この値を構成します。

Exchange Server 2003 には、単一の Exchange Server 2003 コンピュータ トポロジでフォーム ベース認証を使用したときに、Exchange モバイル サービスが動作しない、という既知の問題があります。Exchange Server 2003 バックエンド サーバー上で /Exchange 仮想ディレクトリが SSL (Secure Sockets Layer) を必要とするよう構成されているか、またはフォーム ベース認証が有効になっている場合、Outlook Mobile Access はこの仮想ディレクトリにアクセスできません。フロントエンド サーバー上で、/Exchange 仮想ディレクトリのこれらの設定を有効にしている場合、この問題は発生しません。

ExchangeVDir レジストリ値を作成することにより、この問題を解決できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MasSync\Parameters

  3. ExchangeVDir 値を調べ、必要に応じて変更します。

  4. レジストリ エディタを終了します。変更を加えた場合は、Exchange Server コンピュータを再起動し、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この問題を解決方法の詳細については、Microsoft サポート技術情報の文書番号 817317「複数のバックエンド同じサーバーの仮想ルート ディレクトリに複数のプロキシ アドレスをマップするようサポートされていません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=817317) を参照してください。


Exchange Virus Scanning API 対応製品が検出されたが、現在有効になっていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Exchange Server コンピュータで VSAPI (Virus Scanning Application Programming Interface) 対応ソフトウェアが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

また、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、ESE (Extensible Storage Engine) とも呼ばれる Exchange データベース ストレージ エンジン、Ese.dll の Version キーの値を判断します。

最後に、Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスのすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータは Microsoft Exchange 2000 Server を実行しています。文字列値に "Version 6.5" が含まれている場合、コンピュータは Microsoft Exchange Server 2003 を実行しています。

Version 値のバージョン情報の一部に "6" という部分文字列は含まれていないが、serialNumber の値によって Exchange 2000 Server または Exchange Server 2003 がインストールされていることが示されている場合は、Exchange Server 上で Exchange 以外のバージョンの ESE が実行されています。

Exchange Server アナライザによって、Exchange 以外のバージョンの ESE が実行されておらず、VirusScan \Enabled レジストリ キーの値が 0 に等しいことが検出されると、警告が表示されます。Exchange Server 上で Exchange 以外のバージョンの ESE が実行されていることが検出されると、別の警告が表示されます。

一般に、SMTP (Simple Mail Transfer Protocol) ゲートウェイか、またはメールボックスをホストしている Exchange Server コンピュータ上でのメッセージング システム用に設計されたウイルス対策ソフトウェアを展開することをお勧めします。最大限の保護を提供するには、受信 MIME メッセージをスキャンするウイルス対策ソフトウェアをゲートウェイで実行し、VSAPI 2.0 (Exchange 2000 Server) または VSAPI 2.5 (Exchange Server 2003) を使用するウイルス検索プログラムを Exchange Server コンピュータで実行します。

さらに、クライアント コンピュータでウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、クライアント コンピュータではファイルレベルのウイルス検出プログラムを実行すれば十分です。

この警告を修正するには

  1. ウイルス対策ソフトウェア プログラムのユーザー イン?ターフェイスで、VSAPI スキャンを有効にします。

  2. VSAPI スキャンを有効にしても依然として問題が発生する場合は、ウイルス対策ソフトウェア ベンダに問い合わせてください。

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。


Exchange Virus Scanning API 互換製品が検出されたが、その製品が正しくインストールされていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、VSAPI (Virus Scanning Application Programming Interface) に準拠したソフトウェアがコンピュータで実行されているかどうか、およびそのソフトウェアが有効なライブラリを参照しているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Library の値に VSAPI ウイルス対策ソフトウェア ライブラリ ファイル (DLL) の有効なパスが含まれていないことが検出されると、警告が表示されます。

一般に、メッセージング システム用に設計されたウイルス対策ソフトウェアは、SMTP (Simple Mail Transfer Protocol) ゲートウェイか、メールボックスをホストする Exchange Server コンピュータに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするウイルス対策ソフトウェアをゲートウェイで実行し、VSAPI 2.0 (Exchange 2000 Server) または VSAPI 2.5 (Exchange Server 2003) を使用するウイルス検索プログラムを Exchange Server コンピュータで実行します。

さらに、クライアント コンピュータでウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、クライアント コンピュータではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

この警告を修正するには

  1. ウイルス対策ソフトウェアをアンインストールし、再インストールします。

  2. ソフトウェアを再インストールした後も引き続き問題が発生する場合は、ウイルス対策ソフトウェアのベンダに相談してください。

Microsoft Exchange Server 2003 で一般に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「[XADM] Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。


Exchange Virus Scanning API のスレッド数が少ない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、ScanningThreads の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

ScanningThreads レジストリ値は、スキャン用に割り当てられている VSAPI (Virus Scanning API) スレッドの最大数を表します。

Exchange Server アナライザはまた、次のレジストリ エントリも読み取り、VSAPI メッセージ スキャンが有効になっているかどうかを判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 の場合は、VSAPI スキャンが有効になっていることを示します。値が 0 の場合は、VSAPI スキャンが有効になっていないことを示します。

Exchange Server アナライザはさらに、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、NumberOfProcessors キーに設定されている値を判断します。この値は、コンピュータに搭載されているプロセッサの数を表し、物理プロセッサと論理プロセッサの両方を含んでいます。Intel のハイパースレッディング テクノロジを使用すると、物理プロセッサを 2 つの論理プロセッサに分割することができます。

Exchange Server アナライザによって、ScanningThreads の値が、VSAPI スキャンが有効になっている Exchange Server コンピュータでの計算値 "(2 x プロセッサ数) + 1" より小さいことが検出されると、警告が表示されます。ScanningThreads の最適な値は、"(2 x プロセッサ数) + 1" です。たとえば、プロセッサを 2 つ搭載した Exchange Server コンピュータでは、ScanningThreads の最適な値は "5" です。

注 :
ハイパースレッディングが有効な場合、NumberOfProcessors の値は物理プロセッサの数の 2 倍になります。ウイルス対策ソフトウェアの製造元に問い合せて、上の式で物理プロセッサと論理プロセッサのどちらを使用する必要があるかを判断することをお勧めします。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

  3. 右側のペインで、[ScanningThreads] をダブルクリックします。

  4. 前述した式から得られた値を入力します。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ハイパー スレッディング テクノロジの詳細については、Intel の Web サイト (http://www.intel.com/technology/hyperthread) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


外部 DNS サーバーが SMTP に使用されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server オブジェクトの protocolCfgSMTPServer クラスの msExchSMTPExternalDNSServers 属性値を判断します。protocolCfgSMTPServer クラスには、SMTP 仮想サーバーの設定が含まれています。msExchSMTPExternalDNSServers 属性が設定されている場合、SMTP 仮想サーバーは外部 DNS サーバーを使用します。Exchange Server アナライザによって、msExchSMTPExternalDNSServers 属性が設定されていることが検出されると、警告が表示されます。

SMTP 仮想サーバーが外部 DNS サーバーを使用するように構成されていると、パフォーマンスの問題が発生する可能性があります。そのため、この構成はお勧めできません。

SMTP 仮想サーバーで外部 DNS の設定を変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、<使用している受信 Exchange サーバー>を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  3. [配信] タブをクリックし、[詳細設定] をクリックします。

  4. [構成] をクリックし、外部 DNS サーバーを構成します。

  5. 外部 DNS サーバーを追加するには、[追加] をクリックし、[追加] ダイアログ ボックスで外部 DNS サーバーの IP アドレスを入力します。次に、[OK] をクリックします。

  6. 外部 DNS サーバーを削除するには、IP アドレスを選択し、[削除] をクリックします。

  7. [OK] をクリックします。

Exchange Server 2003 組織で DNS を構成する方法の詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Configuring DNS」を参照してください (このサイトは英語の場合があります)。

Exchange で SMTP コネクタを構成してインターネット ドメインにリンクする方法の詳細については、Microsoft サポート技術情報の文書番号 319426「[HOWTO] SMTP コネクタを構成し Exchange 2000 でインターネット ドメインにリンクする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319426) を参照してください。


フロントエンド サーバーが基本認証を使用している
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、フロントエンド サーバーとバックエンド サーバーの間に基本認証が構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\MSExchangeWeb\DAV\UseBasicAuthToBE

UseBasicAuthToBE キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Exchange Server 2003 フロントエンド サーバーは Kerberos 認証を使用して、フロントエンド サーバーとバックエンド サーバーの間でユーザー資格情報を保護します。Kerberos 認証に失敗すると、警告イベントがログに記録され、フロントエンド サーバーは代わりに NTLM 認証を試みます。NTLM に失敗すると、エラーがログに記録されます。30 分後には、Kerberos が再試行されます。Exchange 2000 Server または Exchange Server 2003 フロントエンド コンピュータが Exchange 2000 Server バックエンド コンピュータを認証する場合は、NTLM が使用されます。

UseBasicAuthToBE レジストリ キーを設定すると、この既定のロジックが上書きされ、Exchange フロントエンド サーバーはバックエンド サーバーとのすべての通信に基本認証を使用するように強制されます。Exchange 組織内に 1,000 を超えるメールボックスが存在する場合は、このレジストリ キーを設定する必要があります。既知の問題として、Microsoft Office Outlook® Web Access for Exchange Server 2003 から、メールボックス ストアが 1,000 を超える組織内のフロントエンド サーバーを通してメールボックスにアクセスしているユーザーがメールボックスにアクセスできないという問題があります。

メールボックス ストアの数が 1,000 以下の場合や、基本認証を強制する理由がない場合は、UseBasicAuthToBE レジストリ キーを削除することを検討してください。

基本認証では、資格情報がクリア テキストで送信されます。 UseBasicAuthToBE レジストリ キーが設定された状態で Exchange フロントエンド サーバーを実行している場合は、IPSec 暗号化を使用することを強くお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

UseBasicAuthToBE レジストリ キーを削除するには

  1. Exchange フロントエンド サーバーで、Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Service\MSExchangeWeb\Dav\ UseBasicAuthToBE

  3. [UseBasicAuthToBE] を右クリックし、[削除] をクリックします。次に、[はい] をクリックします。

  4. [サービス] MMC スナップインを開き、[IIS Admin サービス] を右クリックして、[再起動] をクリックします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ゲートウェイ サーバーの PING が失敗する
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Win32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange ではないゲートウェイ サーバーから返される StatusCode キーの値を判断します。Win32_PingStatus が返すオブジェクトには 24 のプロパティがあり、クラスが送信する ping パケットについて詳しい情報を提供しています。

このキーの値が次の表に示すいずれかの値と一致することが検出されると、エラーが表示されます。

Exchange Server アナライザには、ゲートウェイ サーバー名、Exchange Server 名、およびエラーと共に返された対応する StatusCode 値が表示されます。

StatusCode 値 意味 説明

11001

バッファが小さすぎます

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11002

宛先ネットワークに到達できません

宛先コンピュータが含まれるネットワークに到達できないために要求が失敗しました。宛先コンピュータへの有効なルートが存在しません。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11003

宛先ホストに到達できません

宛先コンピュータに到達できないために要求が失敗しました。

詳細については、「Active Directory サーバーが停止しているか、Active Directory サーバーに到達できない」を参照してください。

また、このエラーは次のいずれかの条件により発生する可能性があります。

  • Exchange Server アナライザが実行されている場所と対象のドメイン コントローラの間にファイアウォールが存在する。

  • DNS エラー。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11004

宛先プロトコルに到達できません

宛先コンピュータがパケットのプロトコルに応答しないために要求が失敗しました。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11005

宛先ポートに到達できません

宛先コンピュータのポートを使用できないために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11006

リソースがありません

ネットワーク リソースが不足しているために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11007

オプションが正しくありません

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11008

ハードウェア エラーです

ハードウェア エラーのために要求が失敗しました。

コンピュータの製造元から提供されているハードウェアの稼動状態確認ツールを実行して、ドメイン コントローラが適切に動作可能であることを確認してください。

11009

パケットが大きすぎます

要求を含むパケットのサイズが、送信元と宛先の間にあるルーターまたはゲートウェイ ノードの最大転送ユニット (MTU) より大きいため、要求が失敗しました。MTU は、転送可能なパケットの最大サイズを定義します。

Exchange Server アナライザから送信される要求は、10 KB より大きくありません。組織内のルーターとゲートウェイが適切に構成されていることを確認してください。

詳細については、Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と問題解決」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211) を参照してください。

11010

要求がタイムアウトしました

割り当てられた時間内に応答を受信しませんでした。応答に許されている既定の時間は 5 秒です。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11011

要求が正しくありません

エンコードが正しくないために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11012

無効なルートです

送信元コンピュータと宛先コンピュータの間に有効なルートがないため、要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11013

転送中に TimeToLive 有効期限が切れました

TTL (Time to Live) の値が 0 に達したために要求が失敗しました。転送しているルーターまたはゲートウェイ ノードでは、このためにパケットが破棄されます。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11014

再構築中に TimeToLive 有効期限が切れました

パケットが転送用の断片に分割されて、再構築に割り当てられている時間内にすべての断片が受信されなかったため、要求が失敗しました。RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) では、すべてのパケットの断片を受信する必要がある時間制限として、60 秒が指定されています。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11015

パラメータに問題があります

パケット ヘッダーの処理中にルーターまたはゲートウェイ ノードで問題が発生したため、要求が失敗しました。この状態は、ヘッダーに無効なフィールド データや認識できないオプションが含まれている場合に発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11016

発信元が抑制されています

パケットが破棄されたため要求が失敗しました。この問題は、送信元コンピュータの出力キューに十分な記憶域がない場合に発生します。また、処理するには速すぎる速度でパケットが宛先に到着した場合にも発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11017

オプションが大きすぎます

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11018

宛先が正しくありません

次のいずれかの理由により要求が失敗しました。

  • 宛先 IP アドレスが PING 要求を受信できない。

  • 宛先 IP アドレスが IP データグラムの宛先アドレス フィールドに含まれている。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11032

IPSEC のネゴシエート中です

IPsec 接続をネゴシエートできなかったために要求が失敗しました。

11050

一般エラーです

不明な理由で要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。


IIS 6.0 の MaxFieldLength パラメータが正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、HTTP 要求の最大フィールド長がレジストリにハードコードされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength

また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合は Microsoft Windows 2000 Server オペレーティング システムを、値が 5.2 の場合は Microsoft Windows Server™ 2003 オペレーティング システムを実行しています。

最後に、Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI (Windows Management Instrumentation) クラスを調べて、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。

以下の条件を満たす Exchange バックエンド サーバーで MaxFieldLength の値が 32,768 に設定されていないことが検出されると、警告が表示されます。

  • Exchange バックエンド サーバーが Windows Server 2003 を実行している。

  • Exchange バックエンド サーバーがフロントエンド サーバーとして構成されていない。

  • Exchange バックエンド サーバーに 500 を超えるメールボックスが存在している。

MaxFieldLength IIS レジストリ パラメータ (既定では存在しない) は、個々の HTTP クライアント要求の最大サイズを指定します。この値は通常、関連する値である MaxRequestBytes と合わせて設定されます。大規模な環境では、これらの値が 32,768 に設定されていないと、Microsoft Office Outlook® Web Access for Exchange Server ユーザーがログオンに失敗する可能性があります。具体的には、これらの値が存在しないと、"HTTP 400 - 正しくない要求" のエラーが発生する可能性があります。MaxFieldLength レジストリ値を構成した場合は、MaxRequestBytes パラメータも 32768 に設定して、75 を超えるグループのメンバであるユーザーが Outlook Web Access にログオンできるようにする必要があります。MaxRequestBytes レジストリ値により、要求行とヘッダーの合計サイズの上限が決定されます。この値が MaxFieldLength より小さい場合は、MaxFieldLength 値が調整されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxRequestBytes パラメータと MaxFieldLength パラメータを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\HTTP\Parameters

  3. [Parameters] を右クリックし、[新規]、[DWORD 値] をクリックして、この値に MaxFieldLength という名前を付けます。

  4. [Parameters] を右クリックし、[新規]、[DWORD 値] をクリックして、この値に MaxRequestBytes という名前を付けます。

  5. 右側のウィンドウで、[MaxFieldLength] を右クリックし、その値を 32,768 (10 進数) に設定します。

  6. 右側のウィンドウで、[MaxRequestBytes] を右クリックし、その値を 32,768 (10 進数) に設定します。

  7. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

インターネット インフォメーション サービス (IIS) の HTTP レジストリ設定の詳細については、サポート技術情報の文書番号 820129「[INF]: IIS 用の Http_sys レジストリ設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=820129) を参照してください。


IIS 6.0 MaxRequestBytes パラメータが正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、HTTP 要求の最大サイズがレジストリにハードコードされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes

また、Exchange Server アナライザは次のレジストリ エントリも調べて、対象のコンピュータで実行されている Microsoft Windows® オペレーティング システムのバージョンを判断します。

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion

CurrentVersion の値が 4.0 の場合、そのコンピュータは Microsoft Windows NT® Server 4.0 を実行しています。値が 5.0 の場合は Microsoft Windows 2000 Server オペレーティング システムを、値が 5.2 の場合は Microsoft Windows Server™ 2003 オペレーティング システムを実行しています。

最後に、Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI (Windows Management Instrumentation) クラスを調べて、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。

Exchange Server アナライザにより、次の条件を満たす Exchange バックエンド サーバーで MaxRequestBytes の値が 32,768 に設定されていることが検出されると、警告が表示されます。

  • Exchange バックエンド サーバーが Windows Server 2003 を実行している。

  • Exchange バックエンド サーバーがフロントエンド サーバーとして構成されていない。

  • Exchange バックエンド サーバーに 500 を超えるメールボックスが存在している。

MaxRequestBytes レジストリ値は、要求行とヘッダーの合計サイズの上限を指定します。ただし、既定では存在しません。この値は通常、関連値 MaxFieldLength と連動して設定します。MaxFieldLength IIS レジストリ パラメータは、個々の HTTP クライアント要求の最大サイズを指定します。大規模な環境では、これらの値が 32,768 に設定されていないと、Microsoft Office Outlook® Web Access for Exchange Server ユーザーがログオンに失敗する可能性があります。特に、これらの値が存在していないと、HTTP 400 - 正しくない要求のエラーが発生する可能性があります。MaxFieldLength レジストリ値を構成した場合は、MaxRequestBytes パラメータも 32768 に設定して、75 を超えるグループのメンバであるユーザーが Outlook Web Access にログオンできるようにする必要があります。この値が MaxFieldLength より小さい場合は、MaxFieldLength 値が調整されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxRequestBytes パラメータと MaxFieldLength パラメータを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\HTTP\Parameters

  3. [Parameters] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックし、この値に MaxFieldLength という名前を付けます。

  4. [Parameters] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックし、この値に MaxRequestBytes という名前を付けます。

  5. 右側のウィンドウで、[MaxFieldLength] をダブルクリックし、その値を 32768 (10 進数) に設定します。

  6. 右側のウィンドウで、[MaxRequestBytes] をダブルクリックし、その値を 32768 (10 進数) に設定します。

  7. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

インターネット インフォメーション サービス (IIS) の HTTP レジストリ設定の詳細については、Microsoft サポート技術情報の文書番号 820129「[INF] IIS 用の Http.sys レジストリ設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=820129) を参照してください。


IMAP4 互換性に関するフラグがレジストリに設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\Compatibility

Compatibility の値が存在しており、0xfffffffe (16 進数) の値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

IMAP4 および POP3 (Post Office Protocol 3) を使用する Exchange Server インターネット プロトコル (IP) クライアントは、ストリーミング ストア (.stm) ファイルを使用してデータの読み書きを行います。IP クライアントが POP3 または IMAP4 経由でメッセージのダウンロードを要求すると、ユーザーのメールボックスが格納されている Exchange インフォメーション ストアはメッセージを転送する前に、クライアントに送信するために受信トレイにあるメッセージの正確なサイズを計算します。大規模な環境、特にホストされている Exchange 環境では、この計算に長い時間がかかる可能性があります。Compatibility の値は、メッセージ サイズを正確に計算する代わりにおおよそのメッセージ サイズを使用するように、管理者が Exchange ストアに指定できるようにする構成機能を表しています。

Compatibility レジストリ値は、この文書で説明するように、Exchange IMAP4 サービスに対して使用できます。また、「レジストリに POP3 Compatibility フラグが設定されている」で説明するように、Exchange POP3 サービスに対しても使用できます。

Compatibility レジストリ値は、多数のメールボックスの移動中や、いくつかの MIME メッセージを含むメールボックスの移動中にも役立ちます。データは移動の際に、ストリーミング ストアから MAPI ストア (.edb ファイル) に昇格されます。POP3 や IMAP4 を使用してメールボックスにアクセスするクライアントでは、データベース間またはサーバー間でメールボックスを移動した後にパフォーマンスの問題が発生する場合があります。ユーザーのログオン後、メッセージのサイズを計算する必要があり、サーバーのメモリ内とディスク上で MAPI から MIME への変換が発生します。極端な場合には、この動作が発生したときに、非常に大きな一時ファイルが Exchange Server コンピュータ上に作成されることがあります。

POP3 および IMAP4 メール クライアントの中には、Compatibility レジストリ値が設定されていると正しく動作しないものもあります。この設定を変更すると、Fetchmail などの一部の古いメール クライアントが動作しなくなります。また、このレジストリ キーを設定すると、IMAP4 プロトコルの RFC 準拠も失われます。POP3 や IMAP4 でメッセージをダウンロードする際に問題が発生しており、Compatibility レジストリ値を使用している場合は、以下の手順を、メッセージのダウンロードに関する問題のトラブルシューティング手順として使用して、この値を削除することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Compatibility レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. Compatibility という名前の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスと IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Compatibility レジストリ値の使用方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 317722「[XADM] Exchange 2000 がメールを MAPI 形式から MIME 形式に変換する際にクライアントの待ち時間が発生する」?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317722)

  • 文書番号 329067「メールボックスの移動機能は, .stm ファイルの内容に昇格するのに昇格します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329067)


IMAP4 の MaxBufferSize 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-08-07

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

MaxBufferSize 値が存在し、0 より大きい数値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MaxBufferSize レジストリ値は、Exchange フロントエンドおよびバックエンド トポロジで使用されます。この値は、フロントエンド サーバーとバックエンド サーバー間の TCP/IP バッファ サイズを定義しています。既定のバッファ サイズは 1 KB です。待ち時間の長いネットワークでは、MaxBufferSize 値を調整すると、IMAP4 クライアントのパフォーマンスが向上する可能性があります。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。組織に最適な値を決定するために、次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,536 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると Exchange Server コンピュータで使用されるメモリが増えるため、フロントエンド サーバーにアクセスできるユーザー数が減る可能性があります。MaxBufferSize レジストリ値として使用できる最大値に制限はありませんが、このレジストリ エントリに大きすぎる値を割り当てると、パフォーマンスが不安定になったりメモリの問題が発生したりする場合があります。

注 :
MaxBufferSize レジストリ値を使用するには、Exchange 2000 Server Service Pack 2 以降を実行している必要があります。

MaxBufferSize レジストリ値の設定が低すぎると、パフォーマンスが向上せず、Exchange Server アナライザによって、「IMAP4 の MaxBufferSize 値が小さすぎる」で説明しているようなエラー メッセージが表示されます。MaxBufferSize レジストリ値の設定が高すぎると、システムが不安定になる場合があります。この場合、Exchange Server アナライザによって「IMAP4 の MaxBufferSize 値が大きすぎる」で説明しているようなエラー メッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxBufferSize 値を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. MaxBufferSize という名前の新しい DWORD 値を作成します。

  4. MaxBufferSize 値をダブルクリックし、新しいバッファ サイズ (バイト単位) を設定します。たとえば、「8192」と入力すると 8,192 バイトに設定されます。

  5. レジストリ エディタを終了し、Microsoft Exchange IMAP4 サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


IMAP4 の MaxBufferSize 値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-08-07

Microsoft® Exchange Server アナライザ ツールは Exchange Server コンピュータのレジストリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

MaxBufferSize 値が存在し、32,768 より大きい数値で構成されていることが検出されると、警告が表示されます。

MaxBufferSize レジストリ値は、Exchange フロントエンドおよびバックエンド トポロジで使用されます。この値は、フロントエンド サーバーとバックエンド サーバー間の TCP/IP バッファ サイズを定義しています。既定のバッファ サイズは 1 KB です。待ち時間の長いネットワークでは、MaxBufferSize 値を調整すると、IMAP4 クライアントのパフォーマンスが向上する可能性があります。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

このレジストリ エントリを使用する場合は、少なくとも 1,024 に設定する必要があります。MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,536 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると Exchange Server コンピュータで使用されるメモリが増えるため、フロントエンド サーバーにアクセスできるユーザー数が減る可能性があります。MaxBufferSize レジストリ値として使用できる最大値に制限はありませんが、このレジストリ エントリに大きすぎる値を割り当てると、パフォーマンスが不安定になったりメモリの問題が発生したりする場合があります。

注 :
MaxBufferSize レジストリ値を使用するには、Exchange 2000 Server Service Pack 2 以降を実行している必要があります。

MaxBufferSize レジストリ値が小さすぎるとパフォーマンスが向上せず、Exchange Server アナライザによって、「IMAP4 の MaxBufferSize 値が小さすぎる」で説明されているエラー メッセージが表示されます。MaxBufferSize レジストリ値が大きすぎるとシステムが不安定になる可能性があり、Exchange Server アナライザによって、この文書で説明しているメッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. MaxBufferSize という名前の新しい DWORD 値を作成します。

  4. MaxBufferSize 値をダブルクリックし、新しいバッファ サイズ (バイト単位) を設定します。たとえば、「8192」と入力すると 8,192 バイトに設定されます。

  5. レジストリ エディタを終了し、Microsoft Exchange IMAP4 サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


IMAP4 の MaxBufferSize 値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-08-07

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4Svc\Parameters\MaxBufferSize

MaxBufferSize 値が存在し、さらにそれが 0 より大きく、1024 よりも小さい任意の数値で構成されていることが検出されると、エラーが表示されます。

MaxBufferSize レジストリ値は、Exchange フロントエンドおよびバックエンド トポロジで使用されます。この値は、フロントエンド サーバーとバックエンド サーバー間の TCP/IP バッファ サイズを定義しています。既定のバッファ サイズは 1 KB です。待ち時間の長いネットワークでは、MaxBufferSize 値を調整すると、IMAP4 クライアントのパフォーマンスが向上する可能性があります。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。組織に最適な値を決定するために、次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

このレジストリ エントリを使用する場合は、少なくとも 1,024 に設定する必要があります。MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,536 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると Exchange Server コンピュータで使用されるメモリが増えるため、フロントエンド サーバーにアクセスできるユーザー数が減る可能性があります。MaxBufferSize レジストリ値として使用できる最大値に制限はありませんが、このレジストリ エントリに大きすぎる値を割り当てると、パフォーマンスが不安定になったりメモリの問題が発生したりする場合があります。

注 :
MaxBufferSize レジストリ値を使用するには、Exchange 2000 Server Service Pack 2 以降を実行している必要があります。

MaxBufferSize レジストリ値が小さすぎるとパフォーマンスが向上せず、Exchange Server アナライザによって、この文書で説明しているエラー メッセージが表示されます。MaxBufferSize レジストリ値が大きすぎるとシステムが不安定になる可能性があり、Exchange Server アナライザによって、「IMAP4 の MaxBufferSize 値が大きすぎる」で説明されているメッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\IMAP4Svc\Parameters

  3. MaxBufferSize という名前の新しい DWORD 値を作成します。

  4. MaxBufferSize 値をダブルクリックし、新しいバッファ サイズ (バイト単位) を設定します。たとえば、「8192」と入力すると 8,192 バイトに設定されます。

  5. レジストリ エディタを終了し、Microsoft Exchange IMAP4 サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


MAPI の操作エラー
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、そのサーバーで多くの MAPI エラーが発生していると判断しました。一部の MAPI 操作は、エラーを返すことがあると予想されています。しかし、クライアント アプリケーションがそのエラーに正しく応答しないことがあります。この結果、アプリケーションがエラーを引き起こした RPC 要求を再発行し、サーバーの負荷が増える可能性があります。

頻繁に発生するクライアント エラーの例として、MAPI クライアントがアイテムの一覧をバッチで要求し、その要求が Exchange から返された後も、クライアントがそれらのアイテムを引き続き要求する場合が考えられます。たとえば、クライアント コンピュータが特定のフォルダにある添付ファイルを含むすべてのアイテムを要求するとします。また、このクライアントは 1 回のバッチでアイテムを 30 ずつ返すように要求するとします。場合によっては、Exchange サーバーが要求の最後のアイテムを返した後も、クライアントが引き続き次のバッチで 30 のアイテムを要求することがあります。この場合、Exchange は "見つかりません" というエラーを返します。"見つかりません" というエラーが返された後も、クライアント コンピュータが引き続きアイテムを要求する場合、このクライアント コンピュータはエラーに正しく応答していないことになります。このシナリオでは、Exchange Server User Monitor (ExMon) により複数の MAPI エラーが報告されます。この場合、操作回数に対するエラーの割合が高いにもかかわらず、高いエラー率が予想されます。高いエラー率が予想される MAPI 操作には、GetPerUserGuid、ImportMsgMove、およびLogon があります。

このエラーを修正するには

  1. ExMon を使用して、大量の MAPI エラーを引き起こしているユーザーまたはユーザーのグループを判断します。

  2. この問題を引き起こしているクライアント コンピュータのアプリケーションを判断します。

  3. 問題を引き起こしているアプリケーションを修正または削除します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


MaxClientRequestBuffer が既定以外の値に設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、そのキーが存在しているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\w3svc\Parameters\MaxClientRequestBuffer

MaxClientRequestBuffer キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、このレジストリ値は存在しません。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

MaxClientRequestBuffer レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 260694「[IIS] MaxClientRequestBuffer レジストリ値について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260694) を参照してください。


MaxClientRequestBuffer の設定値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、MaxClientRequestBuffer 値のデータを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

MaxClientRequestBuffer 値の値データが 16,384 より小さいことが検出されると、警告が表示されます。

MaxClientRequestBuffer の値が小さすぎると、Microsoft Office Outlook® Web Access ユーザーに対してエラーが発生する場合があります。具体的には、ブラウザに HTTP 400 - Bad Request が返される可能性があります。この警告を修正するには、値を 16,384 を超えるように変更するか、レジストリ値を削除して既定の設定に戻すことをお勧めします。MaxClientRequestBuffers 値は、既定では存在しません。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
値のデータを大きくして、この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

  3. [MaxClientRequestBuffer] 値をダブルクリックして、値のデータを編集します。値のデータを 16,384 以上の 10 進数に設定します。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動します。
値を削除して、この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\W3SVC\Parameters\MaxClientRequestBuffer

  3. [MaxClientRequestBuffer] 値を右クリックして、[削除] をクリックします。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxClientRequestBuffer レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 260694「[IIS] MaxClientRequestBuffer レジストリ値について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260694) を参照してください。


複数の SMTP ポートのバインドが構成されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchServerBindings 属性用に構成されている値が複数のポートのバインドで構成されているかどうかを判断します。既定では、msExchServerBindings 属性は TCP ポート 25 用に構成されています。Exchange Server アナライザによって、msExchServerBindings 属性が複数のポートのバインドで構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchServerBindings 属性は、SMTP (Simple Mail Transfer Protocol) サーバーが受信接続を待機する TCP ポートを表します。SMTP 仮想サーバーは、1 つ以上の TCP ポートで接続要求を待機するように構成できます。既定では、すべての SMTP 仮想サーバーが、TCP ポート 25 で接続要求を待機するように構成されています。この SMTP リスニング ポートは、内部のメッセージング インフラストラクチャの他の部分をそれに従って変更しさえすれば変更できます。ただし、インターネットから直接メッセージを受け付ける SMTP 仮想サーバーについては、インターネット上の SMTP サーバーがポート 25 経由でメッセージを送信するため、通常はポート 25 を使用する必要があります。

Exchange Server アナライザが Exchange の SMTP プロトコル仮想サーバーの値を確認することに注意してください。この Exchange の SMTP プロトコル仮想サーバーは、インターネットから直接メッセージを受信する SMTP サーバーの場合とそうでない場合があります。ウイルス対策製品やスパム対策製品の中には、ポート 25 でインターネットからの SMTP メッセージを受信し、別のポートの Exchange SMTP 仮想サーバーにリダイレクトするように設計されているものがあります。

SMTP 仮想サーバーのリスニング ポートを表示または変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、[Exchange サーバー] を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブをクリックし、[詳細設定] をクリックします。

  4. IP アドレスとポートの一覧が表示されます。

    • 既存のポートを変更するには、IP アドレスを選択し、[編集] をクリックします。

    • 既存のポートを削除するには、IP アドレスを選択し、[削除] をクリックします。

  5. [OK] をクリックして変更を保存した後、[OK] をクリックして [詳細設定] ダイアログ ボックスを閉じます。

  6. [OK] をクリックして、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


PING 応答のサイズが異なる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、特定の BufferSize 設定値を使用して Win32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、返される BufferSize 値との比較を行うことによりこれらの値が同じかどうかを判断します。

返された BufferSize 値が送信した値と異なる場合は、警告が表示されます。

この警告は、転送中のどこかでパケットが切り詰められたことを示しています。この状態は、一般的なネットワーク障害が発生したか、または環境内にブラック ホール ルーターが存在することを示している可能性があります。

TCP/IP ワイド エリア ネットワーク (WAN) では、中間のネットワーク セグメントのパケット サイズが通信しているホストのパケット サイズより小さく、各ルーターがこの状態に合わせて適切な ICMP 応答を送信していない場合、複数のルーターを経由した通信が失敗する可能性があります。あるいは、経路上にあるファイアウォールがこのような応答を破棄する場合もあります。この状態を引き起こすルーターを、ブラック ホール ルーターと呼ぶことがあります。

ブラック ホール ルーターが存在すると、プログラムがローカル サブネット上のコンピュータに接続している場合には発生しない、さまざまなエラーが発生する可能性があります。この動作は断続的に見える可能性がありますが、状況をよく調べてみると、たとえば、クライアントがリモート ホストから送信された大きなファイルを読み取るときにこの動作を再現できることがわかる場合があります。

詳細については、Microsoft サポート技術情報の文書番号 314825「ブラック ホール ルーターの問題をトラブルシュートする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825) に記載されている手順に従ってください。

詳細情報

ブラック ホールになっている可能性のあるルーターを検出して問題解決する方法の詳細については、以下のリソースを参照してください。

  • Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と問題解決」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211)

  • PMTU (Path Maximum Transmission Unit) ブラック ホール ルーターについてのページ (http://go.microsoft.com/fwlink/?LinkId=66963) (このサイトは英語の場合があります)


ping テストが実行されていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-08-09

Microsoft® Exchange Server アナライザ ツールは、Win32_PingStatus Microsoft WMI (Windows® Management Instrument) クラスに対してクエリを実行し、メール フローに固有の各種構成設定の応答オブジェクトを分析します。

通常、Win32_PingStatus が返すオブジェクトには 24 のプロパティがあり、クラスが送信する ping パケットについて詳しい情報を提供しています。

クエリを 6 回続けて試行しても応答で予期したオブジェクトを受信しなかった場合、Exchange Server アナライザは警告を表示します。

この警告は、Win32_PingStatus を実行できなかったことを示します。

このエラーは、ほとんどの場合、Win32_PingStatus コマンドを実行しようとしているコンピュータで Microsoft Windows® 2000 Server オペレーティング システムが実行されていることが原因です。Windows 2000 Server では、Win32_PingStatus WMI クラスはサポートされていません。

Win32_PingStatus コマンドを実行しようとしているコンピュータで Windows 2000 Server オペレーティング システムが実行されていない場合は、ネットワークに関する一般的な問題か、またはアクセス許可の問題が原因の可能性があります。

このエラーを修正するには

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. Exchange Server アナライザを実行しているコンピュータから PING コマンドを実行して、対象の Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. 対象の Exchange サーバーと同じサブネット上にあるサーバーから PING コマンドを実行して、対象の Exchange Server コンピュータにアクセスできるかどうかを確認します。

  4. ファイアウォールが設置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを調べます。

  5. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange サーバーで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワーク接続の問題に関する詳細については、マイクロソフト サポート技術情報の文書番号 325487 の、ネットワーク接続の問題のトラブルシューティング方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server ベスト プラクティス アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールでの接続に関する問題のトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください。

Win32_PingStatus WMI クラスの詳細については、MSDN® の Win32_PingStatus に関する文書 (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=33549) を参照してください。


テキストに対するウイルス対策スキャンが無効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、リッチ テキスト形式 (RTF) のメッセージに対するウイルス対策スキャンの値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

ScanPlainText の値が 0 に設定されていることが検出されると、警告が表示されます。

ScanPlainText レジストリ キーは、Exchange VSAPI (Virus Scanning API) を使用するサード パーティ ウイルス対策ベンダによって設定されます。テキスト形式のメッセージを含め、すべての種類のメッセージに対してウイルス対策スキャンを行うことをお勧めします。Exchange Server コンピュータを経由するすべてのメッセージに対して、ウイルス対策スキャンを有効にする必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  • Exchange 対応のウイルス対策アプリケーションで、すべてのメッセージのスキャンを有効にします。

    または

  • 次の手順を実行して、レジストリ内のエントリを手動で変更します。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

    3. ScanPlainText レジストリ エントリをダブルクリックし、その値のデータを 1 に設定します。

    4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスおよび Exchange 対応ウイルス対策ソフトウェアのサービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ウイルス対策の詳細については、Web サイト「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。


レジストリに POP3 Compatibility フラグが設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\Compatibility

Compatibility の値が存在しており、0xfffffffe (16 進数) の値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

IMAP4 および POP3 (Post Office Protocol Version 3) を使用する Exchange Server インターネット プロトコル (IP) クライアントは、ストリーミング ストア (.stm) ファイルを使用してデータの読み書きを行います。IP クライアントが POP3 または IMAP4 でのメッセージ ダウンロードを要求すると、そのユーザーのメールボックスが含まれている Exchange ストアはメッセージを送信する前に、受信トレイにあるメッセージの正確なサイズを計算してそのクライアントに送信します。大規模な環境、特にホストされている Exchange 環境では、この計算には相当の時間がかかります。Compatibility 値を使用すると、管理者は構成を変更して、メッセージ サイズを正確に計算する代わりに概算のメッセージ サイズを使用するよう Exchange ストアに指示することができます。

Compatibility レジストリ値は、Exchange POP3 サービス (この文書で説明) および Exchange IMAP4 サービス (「IMAP4 互換性に関するフラグがレジストリに設定されている」で説明) で使用できます。

また、Compatibility レジストリ値は、大量のメールボックス、または大量の MIME (Multipurpose Internet Mail Extentions) メッセージを含むメールボックスを移動するときに使用しても有効です。データを移動する場合、そのデータはストリーミング ストアから MAPI ストア (.edb ファイル) に昇格されます。POP3 や IMAP4 を使用してメールボックスにアクセスしているクライアントのメールボックスをデータベースまたはサーバー間で移動すると、そのクライアントにパフォーマンスの問題が発生する可能性があります。そのユーザーがログオンすると、メッセージ サイズを計算する必要が発生し、また、サーバーのメモリやディスク上で MAPI から MIME への変換が行われます。極端な場合は、この動作中に、Exchange Server コンピュータ上に非常に大きな一時ファイルが作成されることがあります。

Compatibility レジストリ値を設定しても、すべての POP3 および IMAP4 メールクライアントが正常に動作するとは限りません。この設定を変更すると、一部の古いメール クライアント (Fetchmail など) は動作しなくなります。また、このレジストリ キーを設定すると、POP3 プロトコルの RFC 準拠も失われます。POP3 または IMAP4 でのメッセージ ダウンロードで問題が発生し、Compatibility レジストリ値を使用している場合は、メッセージ ダウンロードの問題のトラブルシューティング手順の一部として、以下の手順を使用してこのレジストリ値を削除できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Compatibility レジストリ値を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. Compatibility という値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスと IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Compatibility レジストリ値の使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 317722「[XADM] Exchange 2000 がメールを MAPI 形式から MIME 形式に変換する際にクライアントの待ち時間が発生する」?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317722)

  • 文書番号 329067「メールボックスの移動機能は, .stm ファイルの内容に昇格するのに昇格します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329067)


POP3 MaxBufferSize の値が変更されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

MaxBufferSize の値が存在し、0 より大きい数値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MaxBufferSize レジストリ値は、Exchange のフロントエンド/バックエンド トポロジで使用されます。この値によって、フロントエンド サーバーとバックエンド サーバーの間の TCP/IP バッファ サイズを定義します。既定のバッファ サイズは 1 KB です。待機時間の長いネットワークでは、MaxBufferSize 値を調整することによって、POP3 クライアントのパフォーマンスを改善できます。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

このレジストリ エントリを使用する場合は、少なくとも 1,024 に設定する必要があります。MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,536 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると、Exchange Server コンピュータのメモリ使用量もそれだけ増えるため、フロントエンド サーバーにアクセス可能なユーザー数が減少する可能性があります。MaxBufferSize レジストリ値に使用できる最大値に制限がなければ、このレジストリ値に大きすぎる値が割り当てられた場合に、パフォーマンスが不安定になったり、メモリに関連するエラーが発生する可能性があります。

注 :
MaxBufferSize レジストリの値を使用するには、Exchange 2000 Server Service Pack 2 以降のバージョンを実行している必要があります。

MaxBufferSize レジストリ値が小さすぎるとパフォーマンスが向上せず、Exchange Server アナライザによって、「POP3 MaxBufferSize 値が小さすぎる」で説明されているエラー メッセージが表示されます。MaxBufferSize レジストリ値が大きすぎるとシステムが不安定になる可能性があり、Exchange Server アナライザによって、「POP3 の MaxBufferSize 値が大きすぎる」で説明されているエラー メッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. MaxBufferSize という DWORD 値を新たに作成します。

  4. [MaxBufferSize] 値をダブルクリックして、新しいバッファ サイズをバイト単位で設定します。たとえば、このレジストリ値を 8,192 バイトに設定するには、「8192」と入力します。

  5. レジストリ エディタを終了し、Microsoft Exchange POP3 サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


POP3 の MaxBufferSize 値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

MaxBufferSize 値が存在し、32768 より大きい数値で構成されていることが検出されると、警告が表示されます。

MaxBufferSize レジストリ値は、Exchange フロントエンドおよびバックエンド トポロジで使用されます。この値は、フロントエンド サーバーとバックエンド サーバー間の TCP/IP バッファ サイズを定義しています。既定のバッファ サイズは 1 KB です。待ち時間の長いネットワークでは、MaxBufferSize 値を調整すると、POP3 クライアントのパフォーマンスが向上する可能性があります。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

このレジストリ エントリを使用する場合は、少なくとも 1,024 に設定する必要があります。MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,535 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると Exchange Server コンピュータで使用されるメモリが増えるため、フロントエンド サーバーにアクセスできるユーザー数が減る可能性があります。MaxBufferSize レジストリ値として使用できる最大値に制限はありませんが、このレジストリ エントリに大きすぎる値を割り当てると、パフォーマンスが不安定になったりメモリの問題が発生したりする場合があります。

注 :
MaxBufferSize レジストリ値を使用するには、Exchange 2000 Server Service Pack 2 以降を実行している必要があります。

MaxBufferSize レジストリ値が小さすぎるとパフォーマンスが向上せず、Exchange Server アナライザによって、「POP3 MaxBufferSize 値が小さすぎる」で説明されているエラー メッセージが表示されます。MaxBufferSize レジストリ値が大きすぎるとシステムが不安定になる可能性があり、Exchange Server アナライザによって、この文書で説明しているメッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. MaxBufferSize という名前の新しい DWORD 値を作成します。

  4. MaxBufferSize 値をダブルクリックし、新しいバッファ サイズ (バイト単位) を設定します。たとえば、「8192」と入力すると 8,192 バイトに設定されます。

  5. レジストリ エディタを終了し、Microsoft Exchange POP3 サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


POP3 MaxBufferSize 値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次のレジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3Svc\Parameters\MaxBufferSize

MaxBufferSize 値が存在し、さらにそれが 0 より大きく、1024 よりも小さい任意の数値で構成されていることが検出されると、エラーが表示されます。

MaxBufferSize レジストリ値は、Exchange のフロントエンド/バックエンド トポロジで使用されます。この値によって、フロントエンド サーバーとバックエンド サーバーの間の TCP/IP バッファ サイズを定義します。既定のバッファ サイズは 1 KB です。待機時間の長いネットワークでは、MaxBufferSize 値を調整することによって、POP3 クライアントのパフォーマンスを改善できます。

MaxBufferSize レジストリ値で TCP/IP バッファ サイズを設定する場合は、バッファ サイズを常に 1,024 の倍数に設定する必要があります。組織に最適な値を決定するために、次のバッファ サイズを使用して、フロントエンドおよびバックエンド サーバー構成のパフォーマンスをテストすることをお勧めします。

  • 8,192 バイト

  • 16,384 バイト

  • 32,768 バイト

このレジストリ エントリを使用する場合は、少なくとも 1,024 に設定する必要があります。MaxBufferSize レジストリ エントリは、32,768 以下の値に設定することをお勧めします。ただし、ネットワークの状態によっては、バッファ サイズの値を 65,535 にするとパフォーマンスが向上する場合があります。バッファ サイズを大きくすると、Exchange Server コンピュータのメモリ使用量もそれだけ増えるため、フロントエンド サーバーにアクセス可能なユーザー数が減少する可能性があります。MaxBufferSize レジストリ値に使用できる最大値に制限がなければ、このレジストリ値に大きすぎる値が割り当てられた場合に、パフォーマンスが不安定になったり、メモリに関連するエラーが発生する可能性があります。

注 :
MaxBufferSize レジストリ値を使用するには、Exchange 2000 Server Service Pack 2 以降を実行している必要があります。

MaxBufferSize レジストリ値が小さすぎるとパフォーマンスが向上せず、Exchange Server アナライザによって、この文書で説明しているエラー メッセージが表示されます。MaxBufferSize レジストリ値が大きすぎるとシステムが不安定になる可能性があり、Exchange Server アナライザによって、「POP3 の MaxBufferSize 値が大きすぎる」で説明されているメッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\POP3Svc\Parameters

  3. MaxBufferSize という DWORD 値を新たに作成します。

  4. [MaxBufferSize] 値をダブルクリックして、新しいバッファ サイズをバイト単位で設定します。たとえば、このレジストリ値を 8,192 バイトに設定するには、「8192」と入力します。

  5. レジストリ エディタを終了し、Microsoft Exchange POP3 サービスを再開して、変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxBufferSize レジストリ値を使用する時期や方法の詳細については、Microsoft サポート技術情報の文書番号 823857「IMAP4 と POP3 パフォーマンスは、フロント エンドとバックエンド サーバーの低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823857) を参照してください。


ポートからの応答がない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、ユーザー定義のサーバーに対してクエリを実行し、既定の構成である TCP ポート 25 またはユーザー定義ポート上の指定されたサーバーへのソケット接続を開こうと試みます。予期したカスタム応答である xx Available (xx は、既定のポートの 25 またはユーザーが定義した代替ポート番号) が返されなかった場合は、エラーが表示されます。

このエラーは、目的の TCP ポート上でサーバーにアクセスできず、障害が発生した可能性があることを示しています。このエラーを修正するために、そのサーバーに関する接続の問題をトラブルシューティングすることができます。

サーバーに関する接続の問題をトラブルシューティングするには、次の項目を確認します。

  1. 指定したサーバー自体から目的のポートへの telnet 接続が可能ですか。これが可能でない場合、問題はネットワークに関するものではありません。

  2. すべてのケーブルが正しく接続されていますか。すべてのハードウェアが正しく機能していますか。

  3. DNS は動作していて、正しく構成されていますか。

  4. ルーターは正しく機能していますか。

  5. 接続を妨げているファイアウォールはありませんか。

サーバーの接続の問題をトラブルーシューティングする方法の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる接続の問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。


潜在的なブラック ホール ルーター
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、各種の特定の BufferSize および NoFragmentation 設定値を使用して Win32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、WAN 環境内にブラック ホール ルーターが存在する可能性があるかどうかを判断します。

BufferSize の設定 | NoFragmentation の設定
548 | True
1472 | True
1472 | False
4096 | True
4096 | False

以下の条件に当てはまる場合は、エラーが表示されます。

  • BufferSize がより小さく、NoFragmentation = True の PING が成功する。

  • BufferSize がより大きく、NoFragmentation = True の PING がタイム アウトする。

  • BufferSize がより大きく、NoFragmentation = False の PING は成功するが、応答の BufferSize サイズが送信した BufferSize とは異なっている。

このエラーは、ワイド エリア ネットワーク (WAN) 上に 1 台以上のブラック ホール ルーターが存在する可能性を示しています。

TCP/IP WAN では、以下の条件に当てはまる場合、複数のルーターを経由した通信が失敗する可能性があります。

  • 中間のネットワーク セグメントのパケット サイズが、通信しているホストのパケット サイズより小さい。

  • 各ルーターがこの状態に合わせて適切な ICMP 応答を送信していない。

あるいは、経路上にあるファイアウォールがこのような応答を破棄する場合もあります。この状態を引き起こすルーターを、ブラック ホール ルーターと呼ぶことがあります。

ブラック ホール ルーターが存在すると、プログラムがローカル サブネット上のコンピュータに接続している場合には発生しない、さまざまなエラーが発生する可能性があります。この動作は断続的に見える可能性がありますが、たとえば、クライアントがリモート ホストから送信された大きなファイルを読み取るときにこの動作を再現できることがわかる場合があります。

詳細については、Microsoft サポート技術情報の文書番号 314825「ブラック ホール ルーターの問題をトラブルシュートする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825) に記載されている手順に従ってください。

詳細情報

ブラック ホールになっている可能性のあるルーターを検出して問題解決する方法の詳細については、以下のリソースを参照してください。

  • Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と問題解決」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211)

  • 「The Cable Guy - July 2004」のコラムの PMTU (Path Maximum Transmission Unit) ブラック ホール ルーターについてのページ (http://go.microsoft.com/fwlink/?LinkId=66963) (このサイトは英語の場合があります)


リモート ホストの PING が失敗する
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは、さまざまな BufferSize や NoFragmentation 設定を使用して Win32_PingStatus Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ネットワークの最大転送ユニット (MTU) のサイズを判断し、存在する可能性のあるブラック ホール ルーターを特定します。Exchange Server アナライザは、各設定の組み合わせに対してリモート ホストから返される StatusCode キーの値を調べることで判断を下します。

BufferSize の設定 | NoFragmentation の設定
548 | True
1472 | True
1472 | False
4096 | True
4096 | False

Win32_PingStatus が返すオブジェクトには 24 のプロパティがあり、クラスが送信する ping パケットについて詳しい情報を提供しています。

このキーの値が次の表に示すいずれかの値と一致することが検出されると、エラーが表示されます。

Exchange Server アナライザには、リモート ホスト名、Exchange Server 名、およびエラーと共に返された対応する StatusCode 値が表示されます。

StatusCode 値 意味 説明

11001

バッファが小さすぎます

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11002

宛先ネットワークに到達できません

宛先コンピュータが含まれるネットワークに到達できないために要求が失敗しました。宛先コンピュータへの有効なルートが存在しません。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11003

宛先ホストに到達できません

宛先コンピュータに到達できないために要求が失敗しました。

詳細については、「Active Directory サーバーが停止しているか、Active Directory サーバーに到達できない」を参照してください。

また、このエラーは次のいずれかの条件により発生する可能性があります。

  • Exchange Server アナライザが実行されている場所と対象のドメイン コントローラの間にファイアウォールが存在する。

  • DNS エラー。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11004

宛先プロトコルに到達できません

宛先コンピュータがパケットのプロトコルに応答しないために要求が失敗しました。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11005

宛先ポートに到達できません

宛先コンピュータのポートを使用できないために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11006

リソースがありません

ネットワーク リソースが不足しているために要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11007

オプションが正しくありません

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11008

ハードウェア エラーです

ハードウェア エラーのために要求が失敗しました。

コンピュータの製造元から提供されているハードウェアの稼動状態確認ツールを実行して、ドメイン コントローラが適切に動作可能であることを確認してください。

11009

パケットが大きすぎます

要求を含むパケットのサイズが、送信元と宛先の間にあるルーターまたはゲートウェイ ノードの最大転送ユニット (MTU) より大きいため、要求が失敗しました。MTU は、転送可能なパケットの最大サイズを定義します。

Exchange Server アナライザから送信される要求は、10 KB より大きくありません。組織内のルーターとゲートウェイが適切に構成されていることを確認してください。

詳細については、Microsoft サポート技術情報の文書番号 159211「ブラック ホール ルーターの診断と問題解決」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159211) を参照してください。

11010

要求がタイムアウトしました

割り当てられた時間内に応答を受信しませんでした。応答に許されている既定の時間は 5 秒です。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11011

要求が正しくありません

エンコードが正しくないために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11012

無効なルートです

送信元コンピュータと宛先コンピュータの間に有効なルートがないため、要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11013

転送中に TimeToLive 有効期限が切れました

TTL (Time to Live) の値が 0 に達したために要求が失敗しました。転送しているルーターまたはゲートウェイ ノードでは、このためにパケットが破棄されます。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11014

再構築中に TimeToLive 有効期限が切れました

パケットが転送用の断片に分割されて、再構築に割り当てられている時間内にすべての断片が受信されなかったため、要求が失敗しました。RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) では、すべてのパケットの断片を受信する必要がある時間制限として、60 秒が指定されています。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

11015

パラメータに問題があります

パケット ヘッダーの処理中にルーターまたはゲートウェイ ノードで問題が発生したため、要求が失敗しました。この状態は、ヘッダーに無効なフィールド データや認識できないオプションが含まれている場合に発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11016

発信元が抑制されています

パケットが破棄されたため要求が失敗しました。この問題は、送信元コンピュータの出力キューに十分な記憶域がない場合に発生します。また、処理するには速すぎる速度でパケットが宛先に到着した場合にも発生する可能性があります。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11017

オプションが大きすぎます

無効なオプションが含まれているために要求が失敗しました。

Exchange Server アナライザは標準的な要求を生成するため、このエラーが返されることはほとんどありません。

11018

宛先が正しくありません

次のいずれかの理由により要求が失敗しました。

  • 宛先 IP アドレスが PING 要求を受信できない。

  • 宛先 IP アドレスが IP データグラムの宛先アドレス フィールドに含まれている。

このエラーは、Exchange Server アナライザが実行されている場所と調査対象のドメイン コントローラの間にあるファイアウォールのために発生する場合があります。

11032

IPSEC のネゴシエート中です

IPsec 接続をネゴシエートできなかったために要求が失敗しました。

11050

一般エラーです

不明な理由で要求が失敗しました。

詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

これらのテストの詳細については、Microsoft サポート技術情報の文書番号 314825「ブラック ホール ルーターの問題をトラブルシュートする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=314825) を参照してください。


ルーティング エンジンが停止している
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Routing Engine サービス (RESvc) および SMTP (Simple Mail Transfer Protocol) サービス (SMTPSVC) が実行されているかどうかを判断します。次の条件のいずれかに当てはまることが検出されると、エラーが表示されます。

  • SMTPSVC が実行されている。

  • RESvc が実行されていない。

メッセージを中継するすべての Exchange サーバーで RESvc が実行されていないと、ルーティングの問題が発生する場合があります。RESvc を実行せずにメッセージを中継する Exchange Server 構成はサポートされません。

Exchange Server 2003 は Exchange 2000 Server と同様に、リンク状態のルーティング アルゴリズムとルーティング プロトコルを使用して、リンク状態テーブルの形でリンク状態情報を伝達します。リンク状態テーブルは、組織内のすべての Exchange 2000 Server および Exchange Server 2003 サーバーのメモリに格納されます。

リンク状態アルゴリズムには、次の利点があります。

  • 各 Exchange サーバーは、リンクを利用できないルートにメッセージを送信せずに、送信元で最適なメッセージのルートを選択することができます。

  • 代替ルートまたは冗長なルートを利用できるかどうかについての最新の情報が各 Exchange サーバーにあるため、メッセージがサーバー間で行ったり来たりすることがありません。

  • メッセージのループが発生しません。以前のバージョンの Exchange Server では、メッセージのループが問題になることがありました。

Exchange Server は、リンク状態テーブルから次の情報を収集します。

  • Exchange 組織全体のルーティング トポロジ。

  • トポロジの各コネクタの可用性情報。利用可能なトポロジは "up"、利用できないトポロジは "down" で示されます。

  • 利用可能な各コネクタに関連付けられたコストとアドレス スペース。

Exchange Server はこの情報を使用して、送信先アドレスへのコストが最小になるルートを決定します。最小コストのルート上に利用できないコネクタがある場合、Exchange Server はコストとコネクタの可用性に基づいて、最善の代替ルートを決定します。リンク状態ルーティングには RESvc が必要です。

このエラーを修正するには、RESvc を自動的に開始されるように構成する必要があります。また、運用時間中に RESvc が必ず実行されるようにする必要があります。

このエラーを修正するには

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[管理ツール] をポイントし、[サービス] をクリックします。

  2. サービスの一覧の [Microsoft Exchange Routing Engine] を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[スタートアップの種類] の [自動] をクリックし、[OK] をクリックします。

  4. [Microsoft Exchange Routing Engine] を右クリックし、[開始] をクリックします。

Exchange Server 2003 におけるメッセージのルーティングの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


RPC Performance Counters Indicate Poor Server Performance
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-08-24

Microsoft® Exchange Server アナライザ ツールは、使用しているサーバーが最適なパフォーマンスで動作していないと判断しました。Exchange Server アナライザは、多くのリモート プロシージャ コール (RPC) のパフォーマンス カウンタを評価します。RPC パフォーマンス カウンタで報告されるデータが次の表のレベルよりも低い場合は、この警告が表示されます。

Exchange Server のユーザー数 | RPC Averaged Latency のしきい値
500 未満 | 平均値が 15 より大きい
500 以上 3000 未満 | 平均値が 30 より大きい
3000 より大きい | 平均値が 50 より大きい

ここで説明する以下のすべてのパフォーマンス カウンタは、MSExchangeIS パフォーマンス オブジェクトによって管理されています。

  • RPC Averaged Latency

  • RPC Requests

RPC Averaged Latency

RPC Averaged Latency パフォーマンス カウンタは、最新の 1024 パケットを処理するために要する平均時間をミリ秒単位 (ms) で記録します。待ち時間は、Store.exe プロセスがパケットを受信して、そのパケットがそこに返されるまでにかかる時間を表します。RPC Averaged Latency パフォーマンス カウンタには、ネットワーク待ち時間、または紹介した Store.exe プロセス以外の待ち時間は含まれません。RPC Averaged Latency パフォーマンス カウンタのデータは、ネットワーク転送時間が含まれませんが、クライアント コンピュータがサーバーからの応答を待つ最短の時間に関するデータを提供します。RPC Averaged Latency パフォーマンス カウンタのデータが 50 ミリ秒より短い場合、サーバーは適切な時間で要求を処理できていることになります。50 ミリ秒より長い状態が数秒間続く場合は、負荷の対応についてサーバーで問題が発生している可能性を示しています。結果的に、ユーザーが自分の電子メールにアクセスするときに遅延が発生する可能性があります。平均待ち時間が 100 ミリ秒を超える場合は、使用している Microsoft Office Outlook® クライアント コンピュータに "Exchange Server サーバーからデータを取得しています" というポップアップ ウィンドウが表示されます。

RPC Averaged Latency パフォーマンス カウンタの解釈

RPC Averaged Latency カウンタについて、次の 2 つの状況で判断を誤る可能性があります。

  • 1 つ目の状況は、一部の MAPI 操作は長い時間がかかると予想されている場合です。たとえば、クライアント コンピュータが任意の場所にある数千アイテムを含むフォルダに対して、複雑な条件に一致するすべてのアイテムを検索する場合、このような操作には通常数秒間かかります。サーバーにユーザーがほとんどいない場合、この実行中の操作が RPC Average Latency のスパイクを引き起こす可能性があります。サーバーの RPC 負荷が低い場合は、この値の一時的な短期間の動きではなく、少なくとも数分間の長期間の平均値を確認します。

  • 2 つ目の状況は、サーバーの RPC 負荷が非常に低い場合に発生します。活動量の最も多いユーザーの操作に応じて、待ち時間に大きく影響する場合があります。サーバーの負荷が特に強調されるため、1 人のユーザーによる集中的な操作の結果、RPC 平均待ち時間のデータに誤差がでる可能性があります。

RPC Requests

RPC Requests パフォーマンス カウンタは、Exchange で現在処理されているクライアント コンピュータの要求の数を記録します。このカウンタは、100 が最大値です。Exchange ストアで処理されている RPC 操作が 100 に達すると、新しい接続が頻繁に拒否されます。正常なサーバーでは、未解決の要求の数は 50 未満である必要があります。この数が長い時間 50 を超えている場合は、RPC がバックアップされていて処理されるのを待っているために、クライアント コンピュータで待ち時間が発生している可能性があることを示しています。

RPC Requests の解釈

要求のしきい値の 50 は、厳密なしきい値ではありません。負荷の少ないサーバーでは、カウンタが 30 に達する前にパフォーマンスの問題が発生する場合もあります。ただし、負荷の高いサーバーでは、要求が 50 でも正常に動作する場合があります。理想的には、サーバーごとにこのカウンタの基準値を測定する必要があります。Exchange Server パフォーマンス トラブルシューティング アナライザは、多くの大規模サーバーに適切なしきい値として 50 を使用しています。

負荷の高いサーバーと比較すると、負荷の低いサーバーでは RPC 要求の値が少なくなります。これは、負荷の低いサーバーでは、遅延なく処理を行うために必要なスレッドの数が少ないためです。負荷の高いサーバーほど、遅延を回避し、RPC 要求の値をより高くするために、多数の同時作業を実行する必要があります。したがって、負荷の高いサーバーでは、RPC 要求の値が高いというだけではパフォーマンスの問題を意味しません。サーバーの遅延を評価するには、RPC Average Latency パフォーマンス カウンタと共に考慮する必要があります。

待ち時間の原因

待ち時間の増加は、次のことが原因で発生します。

  • RPC 負荷の増大

  • 1 つまたは複数のサーバー リソースのボトルネック

さらに、ボトルネックは次の理由により発生する可能性があります。

  • 高い RPC 負荷 (または、サーバーのその他の負荷)

  • ハードウェアの故障または構成エラー

このエラーを修正するには

  • 次の Exchange Server 2003 のガイドで提供されている推奨事項またはベスト プラクティスに従います。

    • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)

    • 『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) (このサイトは英語の場合があります)


クラスタ化されていないサーバーで RPC ポートの範囲が設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、ポートに対して設定されている値のデータを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet\Ports

以下の条件に当てはまると判断されると、エラーが表示されます。

  • HKLM\Software\Microsoft\Rpc\Internet\Ports キーが存在している。

  • サーバーがクラスタ化された Exchange サーバーではない。

  • サーバーで他のエラーが発生している。

このレジストリ エントリが存在する場合は、Exchange Server の RPC 呼び出し用のポートが特定の範囲に制限されます。Exchange サーバーの負荷が高くなり、現在使用できるより多くのポートが必要になった場合は、エラーが発生する可能性があります。

この問題を修正するには、問題が発生しなくなるまで、HKLM\Software\Microsoft\Rpc\Internet\Ports キーに 100 ポートずつ追加する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedt32.exe のレジストリ エディタを起動します。

    注 :
    REG_MULTI_SZ 値を編集するには、Regedit.exe ではなく Regedt32.exe を使用する必要があります。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Rpc\Internet

  3. 右側のペインで、Ports キーをダブルクリックします。値のボックスで、ポートの範囲を増やします。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

HKLM\Software\Microsoft\Rpc\Internet レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 154596「ファイアウォールで動作するように RPC の動的ポート割り当てを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=154596) を参照してください。


クラスタ化されたサーバーで RPC ポートの範囲が設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、ポートに対して設定されている値のデータを判断します。HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet\Ports

以下の条件に当てはまることが検出されると、エラーが表示されます。

  • HKLM\Software\Microsoft\Rpc\Internet\Ports キーが存在している。

  • サーバーがクラスタ化された Exchange サーバーである。

  • サーバーで他のエラーが発生している。

このレジストリ エントリが存在する場合は、Exchange Server の RPC 呼び出し用のポートが特定の範囲に制限されます。Exchange サーバーの負荷が高くなり、現在使用できるより多くのポートが必要になった場合は、エラーが発生する可能性があります。

この問題を修正するには、問題が発生しなくなるまで、HKLM\Software\Microsoft\Rpc\Internet\Ports キーに 100 ポートずつ追加する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedt32.exe のレジストリ エディタを起動します。

    注 :
    REG_MULTI_SZ 値を編集するには、Regedit.exe ではなく Regedt32.exe を使用する必要があります。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Rpc\Internet

  3. 右側のペインで、Ports キーをダブルクリックします。値のボックスで、ポートの範囲を増やします。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

HKLM\Software\Microsoft\Rpc\Internet レジストリ キーの詳細については、Microsoft サポート技術情報の文書番号 154596「ファイアウォールで動作するように RPC の動的ポート割り当てを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=154596) を参照してください。


パフォーマンス カウンタが提供する RPC ユーザー操作
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-02-14

Microsoft® Exchange Server アナライザ ツールによって、現在、サーバーでリモート プロシージャ コール (RPC) の負荷が高くなっていることが判断されました。

1 秒間の RPC 処理数は、サーバー上にどれだけの RPC 負荷が存在するかを示します。場合によっては、RPC 処理の負荷の予期しない増加により、サーバーのパフォーマンスが低下することがあります。サーバーでパフォーマンスの問題が発生している場合は、最初にサーバー上の負荷が予期するよりも高いかどうかを識別する必要があります。サーバーでの RPC 操作に関する情報を提供するパフォーマンス カウンタは複数あります。ここで説明する以下のすべてのパフォーマンス カウンタは、MSExchangeIS、MSExchangeIS Public、または MSExchangeIS Mailbox パフォーマンス オブジェクトの下にあります。

  • RPC Operations/sec

  • Active User Count

  • Active Client Logons (MSExchangeIS Public)

  • Active Client Logons (MSExchangeIS Mailbox)

クライアント RPC 負荷の識別

クライアント コンピュータの現在の操作速度を識別するのに使用できるカウンタは 2 つあります。

  • RPC Operations/sec このカウンタは、クライアント コンピュータがサーバーから現在要求されている 1 秒間の RPC 操作数を示します。以下の方法でユーザーをカウントできます。

    • サーバー上のメールボックスの合計数をカウントできます。

    • ログオンの合計数を (MSExchangeIS Public の Active Client Logons と MSExchangeIS Mailbox の Active Client Logons の合計から) カウントできます。

    • ログオンの合計数を Active User Count からカウントできます。

    Exchange Server アナライザは最後の方法を使用します。アクティブ ユーザーあたりの数を計算するには、平均 RPC Operations/sec を Active User Count で割ります。

  • RPC Operations/sec per user このカウンタは、ユーザーがサーバー上でどのぐらいアクティブかを示します。通常、Microsoft Office Outlook® を使用するナレッジ ワーカーの場合、メールボックス サーバー上でのユーザーあたりの操作数は 1 秒間に約 0.1 です。サーバー上のユーザーがその他のアプリケーションを実行している場合、この数値は大きくなる可能性があります。

Exchange Server アナライザによってユーザーあたりの 1 秒間の RPC 操作数が 0.15 より大きく 0.25 より小さいことが検出された場合、ユーザーは適度にアクティブであると見なされ、警告が表示されます。

ユーザーあたりの 1 秒間の RPC 操作数が 0.25 より大きいことが検出されると、ユーザーは著しくアクティブであると見なされ、エラーが表示されます。

RPC 負荷が高い場合の対処方法

1 秒間の操作数が予期される値よりも多い場合は、最初に高い負荷の原因を特定してから負荷を減らす必要があります。Exchange Server User Monitor (ExMon) ツールを使用すると、特定のユーザーが RPC 操作の数が多い原因であるかどうかを識別することができます。

サーバー上の負荷を減らすことができない場合は、パフォーマンスのボトルネックを特定し、サーバーの処理能力を高める必要があります。

多数のログオンの識別

サーバーはユーザー メモリとカーネル メモリの両方のメモリ内へのログオンに関する一部の情報を保持する必要があります。限られた容量のメモリが確保されています。このメモリが使用される場合、サーバーでメモリのボトルネックが発生する可能性があります。この理由から、Exchange サーバーでパフォーマンスの問題が発生した場合は、ユーザーあたりのログオンの合計数が過剰ではないことを確認する必要があります。

標準的なナレッジ ワーカーのログオン数は 2 ～ 3 です。ユーザーがその他のアプリケーションを実行している場合、ログオン数は増える可能性があります。Exchange Server アナライザは、サーバーへの合計ログオン数をサーバー上のメールボックス数で割って、ユーザーあたりのログオン数を計算します。サーバーへの合計ログオン数は、MSExchangeIS Mailbox および MSExchangeIS Public パフォーマンス オブジェクトの Active Client Logons パフォーマンス カウンタを合計することで判断できます。メールボックス サーバーまたはメールボックスとパブリック フォルダが混在するサーバーでは、Exchange Server アナライザは、この比率のみを調べます。

注 :
多くのユーザーが他のユーザーの共有フォルダ (共有予定表など) を表示している場合、ログオン数も高くなることがあります。

ユーザーあたりの平均ログオン数が 5 より大きく、サーバーでメモリのボトルネックが発生している場合、これは、ユーザーが多数のログオンを作成するアプリケーションを実行していることを示している可能性があります。ユーザーが業務に必要のないアプリケーションを実行している場合は、Exchange サーバーへの過剰なログオンを引き起こすアプリケーションを実行しないよう要求します。

ユーザーが実行しているアプリケーションの数を減らすことができない場合は、ユーザーを別のサーバーに移動して、サーバーあたりのユーザー数を減らす必要があります。ログオンが多くのユーザーによって引き起こされているのか、それとも 1 人のユーザーが過度に高い数のログオンを行っているのかを判断するには、Exchange システム マネージャを使用して各ユーザーのアクティブ ログオンを表示します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 パフォーマンスとスケーラビリティ ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、Microsoft Exchange Server 2003 パフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


RTF のウイルス対策スキャンが無効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、リッチ テキスト形式 (RTF) のメッセージに対するウイルス対策スキャンの値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

ScanRTF の値が 0 に設定されていることが検出されると、警告が表示されます。

ScanRTF レジストリ キーは、Exchange Virus Scanning API (VSAPI) を使用するサード パーティのウイルス対策ベンダによって設定されます。RTF メッセージでは、色、フォント、および書式設定を使用できますが、RTF の読み込みが可能なのは Microsoft Office Outlook® 2003 のみです。Exchange Server RTF 形式の読み込みは、Microsoft Office Word 2003 などのワード プロセッサで RTF 形式のファイルを読み込むこととは異なります。

RTF メッセージを含め、すべての種類のメッセージに対してウイルスのスキャンを行うことをお勧めします。Exchange Server コンピュータ経由で配信されるすべてのメッセージのウイルス スキャンを有効にする必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Exchange 対応のウイルス対策アプリケーションで、すべてのメッセージのスキャンを有効にします。

    または

  2. または、次の手順を実行してレジストリ内のエントリを手動で変更します。

    • Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    • 次の場所に移動します。

      HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan

    • ScanRTF レジストリ エントリをダブルクリックし、その値のデータを 1 に設定します。

    • レジストリ エディタを終了し、Microsoft Exchange Information Store サービスおよび Exchange 対応ウイルス対策ソフトウェアのサービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ウイルス対策の詳細については、Web サイト『Slowing and Stopping E-mail Transmitted Viruses in an Exchange 2003 Environment』(http://go.microsoft.com/fwlink/?LinkId=30732) を参照してください (このサイトは英語の場合があります)。


SMTP バナーがカスタマイズされている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにメッセージを送信しようとします。そのアカウントから次の既定の応答とは異なる応答を受け取ると、警告が表示されます。

"220 Computer Name .Domain Name .com Microsoft ESMTP MAIL Service, Version:Version Number ready at Date Time +0000"

この警告は、セットアップ プログラムが Exchange SMTP 仮想サーバーに接続するときに表示される既定の応答が、カスタマイズされていることを示します。

Exchange Server 管理者が、Microsoft サポート技術情報の文書番号 281224「[XCON] SMTP バナーを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224) の説明に従って SMTP バナーを意図的に変更している場合、このバナーがカスタマイズされていても問題はありません。

Exchange Server 管理者が既定の SMTP バナーを意図的にカスタマイズしていない場合、この警告は、ESMTP (Exchange Server Extended SMPT) コマンドをフィルタ処理するファイアウォールまたは SMTP プロキシの内側に Exchange Server が存在することを示している可能性があります。

Exchange Server の ESMTP コマンドがフィルタ処理されると、Exchange のパフォーマンスに大きな影響を与えたり、Microsoft サポート技術情報の文書番号 320027「Cisco PIX ファイアウォールの内側で電子メール メッセージを送受信できない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027) に説明されている現象が発生したりする可能性があります。

カスタマイズされた SMTP バナーの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 「[XCON] SMTP バナーを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224)

  • 「Cisco PIX ファイアウォールの内側で電子メール メッセージを送受信できない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027)


SMTP のインスタンスが一時停止する
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、IIS メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの各インスタンスの ServerState プロパティの値を判断します。

ServerState プロパティは、サーバー インスタンスの現在の状態を示します。この状態とそれに対応する状態コードは次のとおりです。1 (開始中)、2 (開始)、3 (停止中)、4 (停止)、5 (一時停止中)、6 (一時停止)、または 7 (続行中)。

Exchange Server アナライザによって、SMTP 仮想サーバー インスタンスの ServerState プロパティの値が 6 (一時停止) に等しいことが検出されると、エラーが表示されます。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

仮想サーバーは、他のサーバー プロセスと同様に、ユーザーが開始、停止、および一時停止できるサーバー プロセスの下で実行されます。たとえば、仮想サーバーの構成の変更やその他の保守作業を実行する場合は、仮想サーバーを停止し、変更を行ってから、再び開始することが必要になる場合があります。仮想サーバーを停止すると、ユーザーからの接続が受け付けられなくなるため、このサーバーを使用してメールを配信したり取得したりすることはできません。

仮想サーバーを停止する代わりに、サーバーを一時停止する方法があります。仮想サーバーを一時停止すると、クライアントからの新しい接続は受け付けられませんが、現在の接続は維持されます。SMTP 仮想サーバーを一時停止すると、アクティブなクライアントは引き続きメッセージを送信可能で、仮想サーバーは配信のためキューに置かれている既存のメッセージを配信できます。ただし、新しい接続は受け付けられません。

通常のメッセージ操作に対しては、Exchange Server SMTP 仮想サーバー インスタンスを開始にする必要があります。

このエラーを解決するには、以下の手順を実行して SMTP 仮想サーバー インスタンスを開始します。

SMTP 仮想サーバー インスタンスを開始するには、次の操作を行います。

  1. Exchange システム マネージャで、開始する仮想サーバー インスタンスを右クリックします。

  2. [操作] メニューの [開始] をクリックします。

SMTP 仮想サーバーを開始、停止、または一時停止する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

  • 「[XIMS] Exchange 2000 Server で SMTP メール キューをフラッシュする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=251087)

  • 「XGEN: プロトコルを無効に 2000 Exchange でします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=291330)


SMTP インスタンスが停止している
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、IIS メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの各インスタンスの ServerState プロパティの値を判断します。

ServerState プロパティは、サーバー インスタンスの現在の状態を示します。この状態とそれに対応する状態コードは次のとおりです。1 (開始中)、2 (開始)、3 (停止中)、4 (停止)、5 (一時停止中)、6 (一時停止)、または 7 (続行中)。

Exchange Server アナライザ ツールによって、SMTP 仮想サーバー インスタンスの ServerState プロパティの値が 4 (停止) に等しいことが検出されると、エラーが表示されます。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

仮想サーバーは、他のサーバー プロセスと同様に、ユーザーが開始、停止、および一時停止できるサーバー プロセスの下で実行されます。たとえば、仮想サーバーの構成の変更やその他の保守作業を実行する場合は、仮想サーバーを停止し、変更を行ってから、再び開始することが必要になる場合があります。仮想サーバーを停止すると、ユーザーからの接続が受け付けられなくなるため、このサーバーを使用してメールを配信したり取得したりすることはできません。

通常のメッセージ操作に対しては、Exchange Server SMTP 仮想サーバー インスタンスを開始にする必要があります。

このエラーを解決するには、以下の手順を実行して SMTP 仮想サーバー インスタンスを開始します。

SMTP 仮想サーバー インスタンスを開始するには、次の操作を行います。

  1. Exchange システム マネージャで、開始する仮想サーバー インスタンスを右クリックします。

  2. [操作] メニューの [開始] をクリックします。

SMTP 仮想サーバーを開始、停止、または一時停止する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

  • 「[XIMS] Exchange 2000 Server で SMTP メール キューをフラッシュする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=251087)

  • 「XGEN: プロトコルを無効に 2000 Exchange でします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=291330)


SMTP 最大受信者数の設定が小さすぎる可能性がある
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxRecipients 属性の構成値が 250 未満であるかどうかを判断します。既定では、msExchSmtpMaxRecipients 属性は 64,000 の受信者数に構成されています。msExchSmtpMaxRecipients 属性が 250 未満の値で構成されていることが検出されると、警告が表示されます。

セキュリティの観点からは、ベスト プラクティスとして、各メッセージの最大受信者数を制限することをお勧めします。msExchSmtpMaxRecipients 属性は、既定値の 64000 に設定されたままにしておくことをお勧めします。

組織はそれぞれ、許容可能な最大受信者数を、独自のビジネス要件に基づいて決定する必要があります。ただし、複数の配布リストに宛てられたメッセージでは受信者数が 250 を超える可能性があるため、最大受信者数を 250 未満には設定しないようにすることをお勧めします。最大受信者数を 250 未満の値に設定すると、Exchange は残りの受信者を、メッセージの追加コピーを使用して処理する必要があります。これらの追加コピーにより、ネットワーク トラフィックが増加します。

最大受信者数を表示して構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [メッセージ] タブをクリックします。

  5. 既定の設定である 64000 に戻すには、[メッセージごとの受信者の制限数] チェック ボックスがオンになっていることを確認し、値として「64000」と入力します。他の構成方法として、必要な値でこのボックスを構成したり、チェック ボックスをオフにして、無制限の数の受信者を許可したりすることもできます。

  6. [OK] をクリックして変更内容を保存し、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


EAS 用の SMTP プロキシ アドレスが変更されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

エラー メッセージ

Intro

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ActiveSync® の SMTP プロキシ アドレスが変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters\SMTPProxy

SMTPProxy レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

SMTP アドレスは、Exchange Server のメールボックスへのパスを特定するために使用されるため、一意である必要があります。各アドレスには、アットマーク (@) で区切られた、左側 (LHS: Left-Hand Side) の部分と右側 (RHS: Right-Hand Side) の部分があります。たとえば、SMTP アドレスの形式は次のようになります。

Username@domain.com = 左側@右側 (または、LHS@RHS)

Exchange ActiveSync は、WebDAV 要求を使用して Exchange サーバーからメールボックスの情報にアクセスします。Exchange ActiveSync は、SMTP プロキシ アドレスを表す LHS@RHS の形式をした、関連する RHS 値を選択して WebDAV 要求内で使用します。ユーザーのプライマリ SMTP アドレスとは別の、既定の RHS アドレスが使用されている環境では、SMTPProxy レジストリ値により、Exchange ActiveSync が代替 SMTP プロキシ アドレスを使用できるように構成できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

SMTPProxy レジストリ値を表示または変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MasSync\Parameters

  3. SMTPProxy 値を調べ、必要に応じて変更します。

  4. 変更が完了したら、レジストリ エディタを終了し、Exchange Server コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange ActiveSync の詳細については、『Exchange Server 2003 ActiveSync Architecture』(http://go.microsoft.com/fwlink/?linkid=34203) を参照してください (このサイトは英語の場合があります)。

モバイル アクセスと Exchange Server 2003 の詳細については、「Mobile Access Using Exchange Server 2003」(http://go.microsoft.com/fwlink/?linkid=20098) を参照してください (このサイトは英語の場合があります)。


SMTP サーバーで基本認証が許可されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server オブジェクトの protocolCfgSMTPServer クラスの msExchAuthenticationFlags 属性値を判断します。protocolCfgSMTPServer クラスには、SMTP 仮想サーバーの設定が含まれています。msExchAuthenticationFlags 属性は、SMTP サーバーで許可される認証の種類を表します。Exchange Server アナライザによって、SMTP サーバー上で基本認証が構成されており、サーバーが Microsoft Small Business Server 2000 または Microsoft Windows® Small Business Server 2003 ではないことが検出されると、警告メッセージが表示されます。

SMTP サーバー上で基本認証が構成されていると、セキュリティ侵害のリスクが高くなります。基本認証では、ユーザー名とパスワードをネットワークを経由してクリア テキストで送信できます。暗号化されていないユーザー名とパスワードは、インターネット上で簡単に取得できます。

基本認証を使用する場合は、TLS (Transport Layer Security) を併用してセキュリティを強化することを強くお勧めします。TLS は、ユーザー名、パスワード、およびメッセージ データを暗号化します。SMTP 仮想サーバーに接続するクライアントには、TLS 暗号化を使用するよう要求することができます。TLS は、送信メッセージの保護に役立つように設計されていますが、クライアントからサーバーに送信されるトラフィックの保護には役立ちません。

TLS は Microsoft Outlook Express でサポートされています。SMTP 仮想サーバーで TLS 暗号化を使用するには、キー ペアを作成し、キー証明書を構成する必要があります。それにより、クライアントが TLS を使用して SMTP サービスとのセッションを暗号化できるようになります。したがって、すべてのメッセージが送信されます。SMTP サービスで TLS を使用して、リモート サーバーとのセッションを暗号化することもできます。

注 :
TLS をサポートしていないクライアントは、仮想サーバーを経由して電子メール メッセージを中継できません。

パートナー企業による認証のように、ビジネス上の理由によって SMTP 仮想サーバーで認証済みアクセスを無効にできない場合は、以下の手順に従って、ゲートウェイ サーバーでのセキュリティを強化します。

  • すべてのユーザー アカウント (特に管理者アカウント) に対し、強力なパスワード ポリシーを適用します。

  • Guest アカウントを無効にします。Guest アカウントの無効化の詳細については、Microsoft サポート技術情報の文書番号 320053「Windows 2000 の管理者と Guest アカウントの名前を変更する方法。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=320053) を参照してください。この文書は Microsoft Windows 2000 Server に適用されますが、同様の原則が Windows Server™ 2003 にも適用されます。

基本認証を無効にするには

  1. Exchange システム マネージャで、[サーバー] を展開し、<使用している受信 Exchange サーバー>を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. 受信 SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  3. [アクセス] タブをクリックし、[認証] をクリックします。

    [認証] ダイアログ ボックス

  4. [認証] で、[基本認証] チェック ボックスをオフにします。

    重要 :
    基本認証を使用する場合は、TLS を実装することによってセキュリティを強化することを検討してください。デジタル証明書がある場合は、[TLS 暗号化を要求する] チェック ボックスを使用します。デジタル証明書は、セキュリティが強化された環境では一般的です。このチェック ボックスをオンにする場合は、対応する [既定のドメイン] ボックスに、ユーザーがドメインを指定しない場合にそのユーザーの認証に使用される Windows 2000 Server ドメイン名または Windows Server 2003 ドメイン名を入力する必要があります。TLS 暗号化の詳細については、Exchange のオンライン ドキュメントを参照してください。

インターネット メールをより安全に送受信できるように Exchange Server 2003 組織を構成する方法の詳細については、『Exchange Server 2003 Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=26041) を参照してください (このサイトは英語の場合があります)。


SMTP サービスが無効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの StartMode キーに設定されている値を判断します。Disabled の値は、SMTP (Simple Mail Transfer Protocol) サービスが無効になっており、StartMode 値が Manual または Automatic のどちらかに変更されるまで開始できないことを示します。

また、Exchange Server アナライザは Win32_Service WMI クラスに対してクエリを実行し、SMTP サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合、サービスは実行されています。

Exchange Server アナライザによって、SMTP サービスが開始されている Exchange Server コンピュータで StartMode キーの値が Disabled に設定されていることが検出されると、エラーが表示されます。

Windows SMTP サービスはインターネット インフォメーション サービス (IIS) のコンポーネントであり、Inetinfo.exe の一部として実行されます。Exchange Server は、そのネイティブ トランスポート プロトコルとして SMTP サービスに依存しています。そのため、Exchange は SMTP を使用して、内部および外部のすべてのメッセージをルーティングします。

すべての Exchange Server コンピュータで、SMTP サービスを Automatic に設定しておく必要があります。

このエラーを解決するには、メールのルーティングを行うサーバーで SMTP サービスが自動的に開始されるように構成する必要があります。

SMTP (Simple Mail Transfer Protocol) サービスが自動的に開始されるように構成するには、次の操作を行います。

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. [Simple Mail Transfer Protocol (SMTP)] サービスをダブルクリックします。

  3. [Simple Mail Transfer Protocol (SMTP) のプロパティ] ページの [全般] タブで、[スタートアップの種類] 一覧から [自動] をクリックし、[適用] をクリックします。

  4. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  5. サービス スナップインを終了します。

SMTP サービスと Exchange Server の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、SMTP トランスポート アーキテクチャに関するセクションを参照してください (このサイトは英語の場合があります)。

Exchange で SMTP サービスを構成する方法の詳細については、Microsoft Exchange 2000 Server での SMTP 構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=24866) を参照してください (このサイトは英語の場合があります)。


SMTP サービスが開始されていない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2007-03-13

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、SMTP サービスは実行されていません。値が True の場合、SMTP サービスは実行されています。

Started キーの値が False に設定されていることが検出されると、エラーが表示されます。

Windows SMTP サービスはインターネット インフォメーション サービス (IIS) のコンポーネントであり、Inetinfo.exe の一部として実行されます。Exchange Server は、そのネイティブ トランスポート プロトコルとして SMTP サービスに依存しています。そのため、Exchange は SMTP を使用して、内部および外部のすべてのメッセージをルーティングします。

Exchange サーバー上では SMTP サービスが常に実行されている必要があります。

このエラーを修正するには、次の操作を行います。

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. 右側のペインで、[Simple Mail Transfer Protocol (SMTP)] サービスまで下にスクロールし、このサービスをダブルクリックします。この操作によって [Simple Mail Transfer Protocol (SMTP) のプロパティ] ダイアログ ボックスが表示されます。

  3. [スタートアップの種類] ボックスの一覧から [自動] をクリックします。

  4. [開始] をクリックしてシステム アテンダント サービスを開始します。

  5. [OK] をクリックして変更を保存し、[Simple Mail Transfer Protocol (SMTP) のプロパティ] ダイアログ ボックスを閉じます。

  6. サービス スナップインを終了します。

SMTP (Simple Mail Transfer Protocol) サービスと Exchange Server の詳細については、Exchange Server 2003 テクニカル リファレンス ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47891) の、SMTP トランスポート アーキテクチャに関するセクションを参照してください (このサイトは英語の場合があります)。

Exchange で SMTP サービスを構成する方法の詳細については、Microsoft Exchange 2000 Server での SMTP 構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=24866) を参照してください (このサイトは英語の場合があります)。


SMTP サービスが手動に設定されている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの StartMode キーに設定されている値を判断します。Manual の値は、SMTP (Simple Mail Transfer Protocol) サービスが手動で開始されるように設定されており、自動的には開始しないことを示します。

また、Exchange Server アナライザは Win32_Service WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、SMTP サービスの Started キーの値も判断します。値が False の場合、サービスは実行されていません。値が True の場合、サービスは実行されています。

Exchange Server アナライザによって、SMTP サービスが開始されている Exchange Server コンピュータで StartMode キーの値が Manual に設定されていることが検出されると、警告が表示されます。

Windows SMTP サービスはインターネット インフォメーション サービス (IIS) のコンポーネントであり、Inetinfo.exe の一部として実行されます。Exchange Server は、そのネイティブ トランスポート プロトコルとして SMTP サービスに依存しています。そのため、Exchange は SMTP を使用して、内部および外部のすべてのメッセージをルーティングします。

起動時に SMTP サービスが自動的に開始されないと、このサービスを見落とす可能性があります。これによって、重大なメール フローの問題が発生する場合があります。

すべての Exchange Server コンピュータで、SMTP サービスを Automatic に設定しておく必要があります。

このエラーを解決するには、メールのルーティングを行うサーバーで SMTP サービスが自動的に開始されるように構成する必要があります。

SMTP (Simple Mail Transfer Protocol) サービスが自動的に開始されるように構成するには、次の操作を行います。

  1. [サービス] MMC (Microsoft 管理コンソール) スナップインを開きます。

  2. [Simple Mail Transfer Protocol (SMTP)] サービスをダブルクリックします。

  3. [Simple Mail Transfer Protocol (SMTP) のプロパティ] ページの [全般] タブで、[スタートアップの種類] 一覧から [自動] をクリックし、[適用] をクリックします。

  4. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  5. サービス スナップインを終了します。

SMTP サービスと Exchange Server の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、SMTP トランスポート アーキテクチャに関するセクションを参照してください (このサイトは英語の場合があります)。

Exchange で SMTP サービスを構成する方法の詳細については、Microsoft Exchange 2000 Server での SMTP 構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=24866) を参照してください (このサイトは英語の場合があります)。


SMTP サービスの状態が不明
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、SMTP サービスは実行されていません。値が True の場合、SMTP サービスは実行されています。

Started キーの値を判断できない場合は、エラーが表示されます。

このエラーは、要求されたデータを WMI クエリで取得できなかったことを示しています。

このエラーには、次のような原因が考えられます。

  • Exchange Server アナライザを実行するアカウントが、WMI クラスに対してクエリを実行するための十分なアクセス許可を持っていない。

  • ネットワークの問題により、Exchange Server アナライザからコンピュータにアクセスできない。

  • 原因不明な一時的な状態により、クエリのタイムアウトが発生した。

このエラーを修正するには

  1. Exchange Server を実行するサーバーが起動され、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、Exchange サーバーにアクセスできるかどうかを確認します。

  3. ファイアウォールが設置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを調べます。

  4. Exchange Server アナライザの実行に使用するアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange サーバーで、ローカルの管理者アクセス許可を持っている必要があります。

    または、次の手順に従って、Exchange Server アナライザの実行に使用するアカウントに、特定の WMI アクセス許可を与えることもできます。

    1. Exchange サーバーで、Microsoft 管理コンソール (MMC) の [コンピュータの管理] ツリーを開きます。

    2. [サービスとアプリケーション] で、[WMI コントロール] を右クリックし、[プロパティ] をクリックします。

    3. [WMI コントロールのプロパティ] ダイアログ ボックスで、[セキュリティ] タブをクリックし、[Root] を展開します。

    4. [CIMV2] フォルダを選択し、[セキュリティ] をクリックします。

    5. [セキュリティ ROOT\CIMV2] ページで、Exchange Server アナライザの実行に使用するアカウントを追加します。

  5. 手順 5 で追加したアカウントを選択します。[<選択したアカウント> のアクセス許可] の [許可] 列で、[リモートの有効化] チェック ボックスと [セキュリティの読み取り] チェック ボックスをオンにし、[OK] をクリックします。

SMTP サービスと Exchange Server の詳細については、Exchange Server 2003 テクニカル リファレンス ガイド (http://go.microsoft.com/fwlink/?LinkId=47891) の SMTP トランスポートのアーキテクチャに関するページを参照してください。

Exchange で SMTP サービスを構成する方法の詳細については、Microsoft Exchange 2000 Server における SMTP の構成に関するページ (http://go.microsoft.com/fwlink/?LinkId=24866) を参照してください。

ネットワーク接続に関する問題をトラブルシューティングする方法の詳細については、マイクロソフト サポート技術情報の記事 325487 の、ネットワーク接続の問題のトラブルシューティング方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題をトラブルシューティングする方法の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) (英語) を参照してください。


UseAltRegionalCharset および UseRegionalCharset レジストリ値が両方とも有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Outlook® Web Access クライアントで使用される言語の設定を判断します。

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

    この値を 1 に設定すると、UTF-8 メッセージの本文が、UTF-8 形式の代わりに地域の文字セットまたはコードページでストアに保存されます。これは、Exchange Server 2003 の UseRegionalCharset レジストリ値の既定の設定です。

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseAltRegionalCharset

以下の条件に当てはまる場合は、ブラウザのレベルによってメッセージのエンコードが決定されます。

  • UseAltRegionalCharset キーが設定されていないか、0 に設定されている。

  • 関連する UseRegionalCharset が同様に設定されていないか、0 に設定されている。

上位のブラウザ (Internet Explorer 5 以降) では、UTF-8 でメッセージを送信します。以前のブラウザ (Internet Explorer 5 以外) では、ブラウザが受け付ける言語に適したエンコードでメッセージを送信します。

UseAltRegionalCharset キーは、以下の一覧にある言語用に構成されたブラウザの動作のみを変更します。

  • 韓国語 : KS_C_5601-1987

  • 日本語 : shift_jis

  • 西ヨーロッパ言語 : windows-1252

  • ロシア語 : windows-1251

  • 中央ヨーロッパ言語 : windows-1250

UseAltRegionalCharset キーが 1 に設定されている場合は、上位のブラウザおよび以前のブラウザはいずれも以下のエンコードでメッセージを送信します。

  • 韓国語 : euc_kr

  • 日本語 : iso-2022-jp (JIS)

  • 西ヨーロッパ言語 : iso-8859-1

  • ロシア語 : koi8-r

  • 中央ヨーロッパ言語 : iso-8859-2

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。

  • 文字列値に "Version 6.0" が含まれている場合、コンピュータでは Exchange 2000 Server が実行されています。

  • 文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 が実行されています。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • UseAltRegionalCharset および UseRegionalCharset の両方が存在する。

  • UseAltRegionalCharset および UseRegionalCharset の両方が、Exchange 2000 サーバーまたは Exchange 2003 サーバーで値 1 を使用するように構成されている。

Exchange 2000 Server および Exchange Server 2003 では、以下の条件に当てはまる場合、代わりの文字セットが優先されます。

  • 地域の文字の使用が有効になっている (UseRegionalCharset レジストリ キーの REG_DWORD 値が -1 に設定されている)。

  • 代わりの文字セットの使用が有効になっている (UseAltRegionalCharset レジストリ キーの REG_DWORD 値が 0x1 に設定されている)。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この問題を修正するには

  1. Exchange コンピュータで、Regedit.exe または Regedt32.exe などのレジストリ エディタを起動します。

  2. Outlook Web Access の言語の設定が Exchange Server 環境に適しているかどうかを判断し、適切でないキーを削除します。

    1. 次の場所に移動します。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

    2. 削除するキーを選択し、右クリックして、ボックスの一覧から [削除] を選択します。

  3. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook Web Access の言語設定の詳細については、以下の Exchange Server のリソースを参照してください。

『Exchange Server Client Access Guide』(http://go.microsoft.com/fwlink/?LinkId=47568)(このサイトは英語の場合があります)

Microsoft サポート技術情報の文書番号 311342「[XCCC] Exchange 2000 Server SP2 のサーバー側の OWA レジストリ キー」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311342)


UseAltRegionalCharset レジストリ値が Exchange 2000 Server で有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Outlook® Web Access のクライアントの言語設定に UseAltRegionalCharset が使用されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseAltRegionalCharset

以下の条件に当てはまる場合は、ブラウザのレベルによってメッセージのエンコードが決定されます。

  • UseAltRegionalCharset キーが設定されていないか、0 に設定されている。

  • 関連する UseRegionalCharset が同様に設定されていないか、0 に設定されている。

UseAltRegionalCharset キーは、以下の一覧にある言語用に構成されたブラウザの動作のみを変更します。

  • 韓国語 : KS_C_5601-1987

  • 日本語 : shift_jis

  • 西ヨーロッパ言語 : windows-1252

  • ロシア語 : windows-1251

  • 中央ヨーロッパ言語 : windows-1250

UseAltRegionalCharset キーが 1 に設定されている場合は、上位のブラウザおよび以前のブラウザはいずれも以下のエンコードでメッセージを送信します。

  • 韓国語 : euc_kr

  • 日本語 : iso-2022-jp (JIS)

  • 西ヨーロッパ言語 : iso-8859-1

  • ロシア語 : koi8-r

  • 中央ヨーロッパ言語 : iso-8859-2

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Exchange 2000 Server が実行されています。

Exchange Server アナライザ ツールによって、Exchange 2000 Server を実行しているコンピュータで UseAltRegionalCharset が 0 より大きい値を使用するように構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

このメッセージは、この Exchange 2000 サーバーで UseAltRegionalCharset レジストリ パラメータが有効になっていることを示します。組織の Outlook Web Access ユーザーがさまざまな文字セットを使用する受信者宛てに頻繁にメールを送信すると予想される場合は、Internet Explorer 5 以降を実行しているユーザーが UTF-8 でエンコードされた UNICODE 文字を使用してメールを送信できるようにレジストリ設定を変更することができます。複数の文字セットを必要としない場合は、以下の手順を実行して既定の構成を復元することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Outlook Web Access の既定の言語設定を復元するには、次の操作を行います。

  1. Exchange コンピュータで、Regedit.exe または Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. 右側のペインにある [UseAltRegionalCharSet] レジストリ値を削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook Web Access の言語設定の詳細については、Microsoft サポート技術情報の文書番号 311342「[XCCC] Exchange 2000 Server SP2 のサーバー側の OWA レジストリ キー」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=311342) を参照してください。


UseAltRegionalCharset レジストリ値が Exchange Server 2003 で有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、UseAltRegionalCharset レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\

UseAltRegionalCharset レジストリ値は、Microsoft Outlook® Web Access ユーザーが代わりの文字セットを使用して電子メールをエンコードできるようにします。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 が実行されています。

Exchange Server アナライザ ツールによって、Exchange 2003 サーバーを実行しているコンピュータで、UseAltRegionalCharset レジストリ値が 0 より大きい値を使用するように構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

このメッセージは、UseAltRegionalCharset がこの Exchange 2003 サーバーで構成されていることを示します。この設定により、Outlook Web Access メッセージの文字セットで意図しないエンコードが使用され、一部のクライアントで一部のメッセージが解読できなくなることがあります。クライアントの言語設定が正しいことを確認することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Exchange Server 2003 で Outlook Web Access の既定の言語設定を復元するには

  1. Exchange コンピュータで、Regedit.exe または Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. 右側のペインにある [UseAltRegionalCharSet] レジストリ値を削除します。

  4. UseRegionalCharset レジストリ値が存在しない場合は、次の手順に従って作成します。

    1. [編集] メニューで、[新規] をクリックし、[DWORD 値] をクリックします。

    2. DWORD 値の名前として「UseRegionalCharset」と入力し、Enter キーを押します。

  5. UseRegionalCharset が存在する場合は、ダブルクリックして変更します。

  6. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  7. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

UseAltRegionalCharSet レジストリ値および UseRegionalCharset レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 283214「[XCCC] Outlook Web Access で日本語のメッセージが SJIS で送信される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=283214) を参照してください。


UseRegionalCharset レジストリ値が Exchange 2000 Server で有効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Outlook® Web Access のクライアントによって使用される言語設定を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

UseRegionalCharset レジストリ値により、UTF-8 メッセージの本文は、UTF-8 形式の代わりに地域の文字セットまたはコードページでストアに格納されます。

Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer のすべてのオブジェクトの serialNumber 属性の値も判断します。この文字列値に "Version 6.0" が含まれている場合は、コンピュータで Exchange 2000 Server が実行されています。

Exchange Server アナライザによって、Exchange 2000 Server を実行しているコンピュータで UseRegionalCharset が 1 以上の値を使用するように構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

このメッセージは、この Exchange 2000 サーバー上で UseRegionalCharset レジストリ パラメータが有効になっていることを示しています。組織の Outlook Web Access ユーザーがさまざまな文字セットを使用する受信者宛てに頻繁にメールを送信することが予期される場合は、Internet Explorer 5 以降のバージョンを実行しているユーザーが UTF-8 でエンコードされた UNICODE 文字を使用してメールを送信できるようにレジストリ設定を変更することができます。複数の文字セットを必要としない場合は、以下の手順を実行して既定の構成を復元することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Outlook Web Access の既定の言語設定を復元するには

  1. Exchange コンピュータで、Regedit.exe、RegEdt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. 右側のペインにある、UseRegionalCharSet レジストリ値を削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


UseRegionalCharset レジストリの値が無効になっている
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Outlook® Web Access クライアントで使用される言語の設定を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

UseRegionalCharset レジストリ値を使用すると、UTF-8 メッセージの本文が、UTF-8 形式の代わりに地域の文字セットまたはコードページでストアに保存されます。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 が実行されています。

Exchange Server アナライザ ツールによって、Exchange Server 2003 を実行しているコンピュータで UseRegionalCharset が値 0 を使用するように構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

このメッセージは、この Exchange 2003 サーバーで UseRegionalCharset レジストリ パラメータが無効になっていることを示しています。この設定により、Outlook Web Access メッセージの文字セットで意図しないエンコードが使用され、一部のクライアントで一部のメッセージが解読できなくなることがあります。

Microsoft Internet Explorer 5 以降を使用して Outlook Web Access にアクセスしている場合、Exchange Server 2003 はブラウザの言語設定を使用して、電子メール メッセージや会議出席依頼などの情報のエンコードに使用する文字セットを判断します。

組織の Outlook Web Access ユーザーがさまざまな文字セットを使用する受信者宛てに頻繁にメールを送信すると予想される場合は、Internet Explorer 5 以降を実行しているユーザーが UTF-8 でエンコードされた UNICODE 文字を使用してメールを送信できるようにレジストリ設定を変更することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Outlook Web Access の既定の言語設定を復元するには、次の操作を行います。

  1. Exchange コンピュータで、Regedit.exe または Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. UseRegionalCharset が存在しない場合は、次の手順に従って作成します。

    1. [編集] メニューで、[新規] をクリックし、[DWORD 値] をクリックします。

    2. DWORD 値の名前として「UseRegionalCharset」と入力し、Enter キーを押します。

  4. UseRegionalCharset が存在する場合は、ダブルクリックして変更します。

  5. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  6. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook Web Access の言語設定の詳細については、『Exchange Server Client Access Guide』(http://go.microsoft.com/fwlink/?LinkId=47568) を参照してください (このサイトは英語の場合があります)。


Exchange Server 2003 で UseRegionalCharset レジストリ値が無効である、または存在しない
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Outlook® Web Access クライアントで使用される言語の設定を判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\UseRegionalCharset

UseRegionalCharset レジストリ値を使用すると、UTF-8 メッセージの本文が、UTF-8 形式の代わりに地域の文字セットまたはコードページでストアに保存されます。

Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してもクエリを実行し、オブジェクト クラスが msExchExchangeServer であるすべてのオブジェクトの serialNumber 属性の値を判断します。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Exchange Server 2003 が実行されています。

以下の条件のいずれかに当てはまる場合は、警告メッセージが表示されます。

  • Exchange 2003 サーバーに UseRegionalCharset エントリが存在しない。

  • UseRegionalCharset エントリの値が 1 以外である。

このメッセージは、この Exchange 2003 サーバーの UseRegionalCharset レジストリ パラメータが無効であるか、レジストリ エントリが存在しないことを示しています。この設定により、Outlook Web Access メッセージの文字セットで意図しないエンコードが使用され、一部のクライアントで一部のメッセージが解読できなくなることがあります。

Microsoft Internet Explorer 5 以降を使用して Outlook Web Access にアクセスしている場合、Exchange Server 2003 はブラウザの言語設定を使用して、電子メール メッセージや会議出席依頼などの情報のエンコードに使用する文字セットを判断します。

組織の Outlook Web Access ユーザーがさまざまな文字セットを使用する受信者宛てに頻繁にメールを送信することが予期される場合は、Internet Explorer 5 以降のバージョンを実行しているユーザーが UTF-8 でエンコードされた UNICODE 文字を使用してメールを送信できるようにレジストリ設定を変更することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Outlook Web Access の既定の言語設定を復元するには

  1. Exchange コンピュータで、Regedit.exe または Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\

  3. UseRegionalCharset が存在しない場合は、次の手順に従って作成します。

    1. [編集] メニューで、[新規] をクリックし、[DWORD 値] をクリックします。

    2. DWORD 値の名前として「UseRegionalCharset」と入力し、Enter キーを押します。

  4. UseRegionalCharset が存在する場合は、ダブルクリックして変更します。

  5. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  6. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Outlook Web Access の言語設定の詳細については、『Exchange Server Client Access Guide』(http://go.microsoft.com/fwlink/?LinkId=47568) を参照してください (このサイトは英語の場合があります)。


ユーザー負荷と MAPI 操作
Microsoft Exchange Server アナライザ - 文書 > プロトコル >

トピックの最終更新日時 : 2006-10-17

Microsoft® Exchange Server アナライザ ツールによって、サーバー上のいくつかの MAPI 操作がサーバー ユーザー負荷のかなりの割合を占めると判断されました。この判断は、すべての RPC 要求の処理で使用される CPU 時間の合計の 4% を超える CPU 時間を消費している操作に対してクエリを実行した結果です。

MAPI 操作で CPU 割合が高くなる一般的な原因

Exchange Server の低パフォーマンスについて調査する管理者は、低パフォーマンスを示しているすべてのサーバーで平均のメールボックス サイズが大きいかどうかを確認する必要があります。これは、個々のフォルダが非常に大きい (ユーザーの受信トレイ、送信済みアイテム、削除済みアイテム、または予定表フォルダに 5,000 アイテム以上ある) かどうかで判断されます。フォルダおよびメールボックスが大きくなると、CPU および I/O の負荷が高くなることがあります。各フォルダのビューの数の増加も、多くの MAPI 操作にオーバーヘッドを追加する可能性があります。

ビュー

一般的な実行時間の長い MAPI 操作の多くはビューと関連します。Restrict と FindRow はよく知られています。これらの操作には必ずしも長時間を要するわけではありません。パフォーマンスに問題がある場合は、理由を理解する必要があります。次の理由に加えて、リソース (通常はディスクまたは CPU) のボトルネックがあると常に操作の待ち時間が長くなることに注意してください。

注 :
TaskQ User Known が Restrict または FindRow 操作との組み合わせで大きく影響する場合があります。これは、これらの操作に対する作業のいくつかが TaskQ で実行され、そのコストが TaskQ User Known に現れるためです。

制限

MAPI Restrict 操作は、特定の条件を満たす項目を選択するために使用します。サーバーによって、ビュー、つまり制限という関連付けられた条件を持つ効果的なテーブルが作成されます。一致する制限を持つビューが既にある場合は、サーバーは既存のビューを使用してユーザー要求を満たします。このビューを使用するとコストが比較的低くなりますが、新しいビューを作成するとコストが比較的高くなります。既定では、ストアはフォルダごとに 11 のビューのみをキャッシュします。サーバーは 12 番目のビューの作成を要求されると、最も古いビューを削除して新しいビューを作成します。ビューによって、そのビューの制限を満たすアイテムに対するすべての処理にオーバーヘッドが追加されます。

Findrow

クライアント アプリケーションは、MAPI 操作 SeekRow または FindRow を使用して、ビューの行間でカーソルを移動します。SeekRow はカーソルを移動する行数を指定し、CPU 時間の条件で非常に低コストです。FindRow のコストが非常に高いのは、制限条件を満たす、実現されない (キャッシュされない) ビューにある最初の項目にカーソルを移動し、次にクライアント アプリケーションが処理を完了した後でビューを削除するためです。FindRow の最終的な CPU コストは、制限の複雑さ、および条件と一致する最初の項目を検索するまでにストアが確認する必要がある行数によって異なるため、フォルダ内のアイテム数との相互関係が少しあります。

Restrict および FindRow で発生する可能性のある高いコストによって、これらはサーバーのコストを減らすキャッシュ モードを実行する適切な候補になります。これらによって消費される高い CPU 割合の原因が共有予定表であって、キャッシュ モードが利用できない場合もあることに注意してください。これらの操作による CPU 時間の高い使用率は、多くのビューの作成、コストの高いビュー、またはアイテム数が多いフォルダを示している可能性があります。

詳細情報

詳細については、以下の Exchange Server リソースを参照してください。

  • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)

  • Exchange Server 2003 のパフォーマンスに関する考察についてのページ (http://go.microsoft.com/fwlink/?LinkId=56460) (このサイトは英語の場合があります)


記憶域
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクション内の文書には、Microsoft® Exchange Server アナライザ ツールによる記憶域の評価に関する詳細が記載されています。さらに、これらの文書には、Exchange Server アナライザによって検出された記憶域に関連するエラー、警告、および既定以外の構成を解決するための対処法も説明されています。


メールボックス ストアの Aging Clean Interval が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、使用されていないデータベース インデックスを削除する期間が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Aging Clean Interval

Aging Clean Interval キーが存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ESE (Extensible Storage Engine) の機能の 1 つとして、情報が再分類されたり、異なる並び替えの順序で情報が要求されたときにインデックスを動的に作成する機能があります。結果として、Exchange ストア データベースでは、テーブルに大量のインデックスが作成される可能性があります。Exchange ストアは、インデックスに有効期限を割り当てることによってこの状況を処理しています。インデックスに関する情報は、インデックス エージング テーブルと呼ばれる内部テーブルに追加されます。オンライン保守中には、インデックス エージング テーブルが確認されて、各エントリの削除時刻の値が現在の時刻と比較されます。有効期限が切れているインデックスは削除されます。既定では、この処理は 24 時間ごとに Exchange ストアの保守サイクル中に実行され、Exchange Server 5.5 では 8 日より古いエントリ、Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 では 40 日より古いエントリが削除されます。Aging Clean Interval キーは、使用されていないインデックスの削除を Exchange ストアが試みる間隔 (ミリ秒単位) です。レジストリ キーを使用してこの既定値を上書きし、カスタムの間隔でこの機能を実行できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Aging Clean Interval キーを削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Aging Clean Interval キーの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 159197「[XADM] フォルダ インデックス エイジングの制御」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=159197)

  • 文書番号 216076「[XADM] インフォメーション ストア フォルダにアクセスすると、処理速度が低下する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=216076)


パブリック フォルダ ストアの Aging Clean Interval が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、使用されていないデータベース インデックスを削除する期間が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\Aging Clean Interval

Aging Clean Interval キーが存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ESE (Extensible Storage Engine) の機能の 1 つとして、情報が再分類されたり、異なる並び替えの順序で情報が要求されたときにインデックスを動的に作成する機能があります。結果として、Exchange ストア データベースでは、テーブルに大量のインデックスが作成される可能性があります。Exchange ストアは、インデックスに有効期限を割り当てることによってこの状況を処理しています。インデックスに関する情報は、インデックス エージング テーブルと呼ばれる内部テーブルに追加されます。オンライン保守中には、インデックス エージング テーブルが確認されて、各エントリの削除時刻の値が現在の時刻と比較されます。有効期限が切れているインデックスは削除されます。既定では、この処理は 24 時間ごとに Exchange ストアの保守サイクル中に実行され、Exchange 5.5 では 8 日より古いエントリ、Exchange 2000 Server および Exchange Server 2003 では 40 日より古いエントリが削除されます。Aging Clean Interval キーは、Exchange ストアがインデックスの削除を試みる間隔 (ミリ秒単位) です。レジストリ キーを使用してこの既定値を上書きし、カスタムの間隔でこの機能を実行できます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Aging Clean Interval キーを削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Aging Clean Interval キーの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 159197「[XADM] フォルダ インデックス エイジングの制御」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=159197)

  • 文書番号 216076「[XADM] インフォメーション ストア フォルダにアクセスすると、処理速度が低下する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=216076)


すべてのバージョンの Outlook がサーバーへのアクセスを許可されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Microsoft Office Outlook® のいずれかのバージョンが、Exchange Server に接続できないようにされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Disable MAPI Clients キーが存在しないことが検出されると、警告が表示されます。

Disable MAPI Clients キーは既定では有効になっていません。管理者はこのキーを使用すると、特定のバージョンの Outlook が、Exchange 2000 Server、Exchange Server 2003、または Exchange Server 2007 を実行しているコンピュータに接続できないようにすることができます。

Outlook の新しいリリースや Service Pack には、セキュリティとウイルス対策の拡張機能が多数組み込まれています。Outlook 2002 から、添付ファイルのブロック機能とオブジェクト モデル ガードが組み込まれるようになり、これらは既定で有効になっています。これらの機能は、総合的なウイルス対策において非常に重要なコンポーネントです。Microsoft 製品サポート サービスでサポートしている Outlook の最も古いバージョンは、Outlook 2000 Service Pack 3 (SP3) です。組織で実行している Outlook のバージョンがこれより古い場合は、Outlook 2003 にアップグレードするか、少なくとも最新のセキュリティ リリースを使用して Outlook クライアントを更新してください。

Outlook を更新した後は、更新されていない以前のバージョンの Outlook から Exchange へのアクセスをロックアウトすることができます。添付ファイルのブロックとオブジェクト モデル ガードをサポートしていない以前のバージョンの Outlook をロックアウトすると、MAPI クライアントの接続に関して、レベルが明らかなセキュリティをクライアントに提供するために役立ちます。

古いバージョンの Outlook (Outlook 97、Outlook 98、SP3 より前の Outlook 2000、およびそれ以前のバージョン) のすべてから保護できるように、ビルド番号が 5.3164.0.0 以下のすべてのバージョンの Outlook を Exchange に接続できないようにすることをお勧めします。

クライアントのバージョン文字列は、クライアント自体によって示されます。この文字列は、クライアントの [バージョン情報] ダイアログ ボックスで報告されるバージョン番号と似ています。しかし、このバージョン番号では判断しないでください。代わりに、Exchange システム マネージャを使用し、[メールボックス ストア] の [ログオン] ページで [クライアント バージョン] プロパティを表示します。

重要 :
修正プログラムと Service Pack のリリースがクライアントのバージョン文字列に影響を与える可能性に注意して、変更を加えてください。サーバー側の Exchange コンポーネントも MAPI を使用してログオンする必要があるため、クライアント アクセスを制限する場合は注意が必要です。SMTP や OLEDB のように、クライアントのバージョンをコンポーネント名として報告するコンポーネントと、6.0.4712.0 のような Exchange のビルド番号を報告するコンポーネントがあります。このため、6.<x.x> で始まるバージョン番号を持つクライアントを制限することは避けてください。たとえば、MAPI アクセスを完全に防止するには、0.0.0-65535.65535.65535 と指定するのではなく、0.0.0-5.9.9; 7.0.0-65535.65535.65535 のように 2 つの範囲を指定し、サーバー コンポーネントがログオンできるようにします。 0.0.0-5.9.9; 7.0.0-65535.65535.65535.
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Disable MAPI Clients という名前の新しい文字列値エントリを作成します。

  4. [Disable MAPI Clients] レジストリ エントリをダブルクリックし、値のデータを必要なレベルに設定します。[値のデータ] ボックスの文字列として記述する値の一覧は、ある範囲のバージョンの MAPI クライアントを無効にすることができるさまざまな方法を表しています。バージョン (vX) は通常、以下の形式で示されます。

    • Microsoft Outlook 2003 および Outlook 2007 の場合 : メジャー.マイナー.ビルド

    • Microsoft Outlook 2000 の場合 : メジャー.ビルド.ドット

    • これ以前のバージョンの Microsoft Outlook の場合 : メジャー.マイナー.ビルド

    この設定で無効にするすべての特定のバージョン、またはバージョンの範囲を示すことができます。Exchange Server 2003 のメールボックス ストアに接続している MAPI クライアントのバージョンを確認するには、Exchange システム マネージャを使用してください。Exchange システム マネージャで、メールボックス ストアのログオン コンテナを見つけます。[クライアント バージョン] 列には、メールボックス ストアに接続されている MAPI クライアントのバージョンが表示されます。

    Exchange Server 2007 では、Exchange 管理シェルで Get-LogonStatistics コマンドレットを使用して、メールボックス データベースに接続されている MAPI クライアントのバージョンを取得します。
重要 :
MAPI クライアントのバージョンは、Exchange システム マネージャおよび Exchange 管理シェルで、X.0.Y.Z のように表示されます。このバージョンは、レジストリ値に X.Y.Z のように入力する必要があります。たとえば、Exchange システム マネージャが MAPI クライアントのバージョンを 5.0.2819.0 のようにリストする場合、[Disable MAPI Clients] レジストリ値に 5.2819.0 を入力します。
  1. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

特定の MAPI クライアントが Exchange 2000 Server または Exchange Server 2003 コンピュータに接続できないようにする方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328240「Exchange 2000 メールボックスへのアクセスに使用されるクライアントにサーバー側の制限を置く方法。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328240)

  • 文書番号 288894 の、[XADM]MAPI クライアントのアクセスを禁止する機能についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=288894)

古いバージョンの Outlook 用セキュリティ更新プログラムのダウンロードと、他のバージョンの Outlook のブロックに関する詳細については、Exchange Server 2003 環境を電子メールによるウイルス感染から守るための指針についての記事 (http://go.microsoft.com/fwlink/?LinkId=47587) (英語) を参照してください。

Get-LogonStatistics コマンドレットの詳細については、Exchange Server 2007 製品ドキュメントの "Get-LogonStatistics" (http://go.microsoft.com/fwlink/?LinkId=80699) を参照してください (このサイトは英語の場合があります)。


AssertOnEvent が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Information Store に対してデバッグが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\AssertOnEvent

AssertOnEvent に値が設定されていることが検出されると、警告が表示されます。

AssertOnEvent レジストリ値は、Microsoft Exchange Information Store のデバッグ モードを引き起こすストア イベントを指定する 10 進数の値を保持しています。AssertOnEvent レジストリは、store.exe のデバッグ バージョンが実行されている場合のみ有効です。Microsoft Exchange Information Store は、デバッグ モードで実行されると大量のリソースを使用します。ベスト プラクティスとして、運用環境ではストアをデバッグしないようにすることをお勧めします。

Microsoft 製品サポート サービスの支援を受けて Exchange Information Store の問題のトラブルシューティングを行うことが多い場合を除き、AssertOnEvent レジストリ値は削除してください。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
AssertOnEvent レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、AssertOnEvent 値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


少なくとも 1 つの破損メッセージが検出された
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、PoisonIDs 値のエントリ数を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<Exchange サーバー名> \Private- <プライベート インフォメーション ストアの GUID>

PoisonIDs 値のエントリ数が 0 より多いことが検出されると、警告が表示されます。

Exchange Server 2003 Service Pack 1 以降のバージョンでは、破損メッセージや悪質なメッセージにより Microsoft Exchange Information Store サービスが予期せず停止したり、Exchange Information Store サービスの正常な開始が妨げられたりすることを防止するための動作が実装されています。

Exchange Server 2003 Service Pack 1 以降のバージョンでは、MAPI 形式から MIME 形式への変換時に予期しない Exchange Information Store サービスの停止を引き起こすメッセージが追跡されます。クラッシュが発生すると、破損メッセージのメッセージ ID がレジストリに格納されます。ある破損メッセージのためにストアが 3 回予期せず停止した場合は、この情報を使用して、Exchange Information Store サービスが 4 回目に再開されたときに二度とこのメッセージを処理しないようにします。

破損メッセージのために Exchange Information Store サービスが予期せず停止すると、PoisonIDs レジストリ値が次の場所に作成されます。

HKLM\System\CurrentControlSet\Services\MSExchangeIS \<Exchange サーバー名> \Private- <プライベート インフォメーション ストアの GUID>

また、管理者は PoisonThreshold レジストリ エントリを作成することができます。PoisonThreshold キーは、メッセージが PoisonIDs レジストリ キーに追加されるまでに Exchange インフォメーション ストアを通過できる最大の回数を制御します。既定では、このしきい値は 2 です。この動作を引き起こすには、しきい値を超える必要があります。そのため、Exchange Information Store サービスは、破損メッセージがブロックされるまでにその破損メッセージのために 3 回停止する可能性があります。たとえば、あるメッセージがクラッシュを 3 回引き起こしたとすると、3 はしきい値の 2 より大きいため、そのメッセージはブロックされます。

レジストリに破損メッセージ イベントが書き込まれると、アプリケーション イベント ログにエラー イベント メッセージ (イベント ID 9680 および 9681) が記録されます。Exchange Information Store サービスが正常に開始された後、Exchange はそのメッセージをブロックし、そのメッセージに対する配信不能レポートの送信を試みます。場合によっては、Exchange が配信不能レポートを送信できないことがあります。その場合、ブロックされたメッセージは、有効期限が切れるまでキューに残る可能性があります。PoisonIDs レジストリ キーには、メッセージ ID 値が最大 10 個まで保持されます。10 個の制限を超えると、新しい破損メッセージ イベントが追加されます。そのとき、最も古いクラッシュの日付を含む破損メッセージ イベントが削除されます。

この警告を修正するには

  1. 破損メッセージの問題が発生しているメールボックス ストアがある場合は、その問題をさらに詳しく調査する必要があります。マイクロソフト IT で実行される、破損した Exchange データベースの回復方法については、マイクロソフト IT についての Web サイト (http://go.microsoft.com/fwlink/?LinkId=56372) を参照してください (このサイトは英語の場合があります)。

  2. 破損メッセージのために Exchange Server 2003 のシャットダウンで問題が発生している場合は、Exchange Server コンピュータでエラーの自動報告を有効にすると役立つ可能性があります。このエラー報告のデータは、使用しているソフトウェア内にある問題の検出や修正のために使用されます。Exchange エラー報告を有効にする方法の詳細については、「Exchange エラー報告が無効になっている」を参照してください。

Exchange Server 2003 Service Pack 1 の詳細については、「Exchange Server 2003 Service Pack 1」(http://go.microsoft.com/fwlink/?linkid=29090) を参照してください。


メールボックス ストアの Background Cleanup が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Background Cleanup レジストリ値の現在の値のデータを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Background Cleanup

Background Cleanup の値のデータが 60,000 (10 進) または 0xEA60 (16 進) 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。Background Cleanup は既定値に設定することをお勧めします。

Background Cleanup の値が大きすぎると、バックグラウンドでのクリーンアップ プロセスが十分な頻度で実行されず、次のような多くの問題が発生する可能性があります。

  • メールボックスの移動に失敗し、エラー コード 0x4e3 を含むイベント 1205 がログ記録される場合があります。

  • Exchange システム マネージャまたは Exchange 管理コンソールに表示されるフォルダ サイズやアイテムの数が Microsoft Outlook® に表示される内容と大幅に異なる場合があります。さらに、これらのアイテムによって占有されるデータベースの領域が再割り当てされない場合があります。

  • 開封されずに削除されたアイテムに対する未開封通知が、特定の状況において生成されない場合があります。

  • DeliveredTo テーブル内の古いエントリのクリーンアップが行われなくなります。DeliveredTo テーブルは、Exchange ストアが、重複メッセージを配信しないようにするために使用します。

Background Cleanup の値が小さすぎると、バックグラウンドでのクリーンアップ プロセスによって、サーバーに不必要な負荷がかかる可能性があります。

注意 :
このトピックの手順を実行して大きすぎる値を既定の構成に戻すと、通常は既定の間隔でクリーンアップされるすべてのアイテムに対してバックグラウンドでのクリーンアップが完了するまでは、サーバーの負荷が増加する可能性があります。したがって、これらの変更は、ユーザーへの影響が最小限に抑えられる時間帯に行うことをお勧めします。さらに、開封通知を要求するメッセージが開封されずに削除され、この問題が原因でクリーンアップされなかった場合、この警告を修正すると、このような各メッセージに対して未開封通知が生成されます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Background Cleanup の値を 60,000 (10 進) または 0xEA60 (16 進) に変更します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


メールボックス ストアに対するバックグラウンドでのクリーンアップ間隔が存在しない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Background Cleanup レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Background Cleanup

Background Cleanup 値が存在しないことが検出されると、警告が表示されます。

Background Cleanup 値が存在しないと、バックグラウンドでのクリーンアップ プロセスが実行されず、次のような多くの問題が発生する可能性があります。

  • メールボックスの移動に失敗し、エラー コード 0x4e3 を含むイベント 1205 がログ記録される場合があります。

  • Exchange システム マネージャまたは Exchange 管理コンソールに表示されるメールボックス サイズやアイテムの数が Microsoft Outlook® に表示される内容と大幅に異なる場合があります。さらに、これらのアイテムによって占有されるデータベースの領域が再割り当てされない場合があります。

  • 開封されずに削除されたアイテムに対する未開封通知が、特定の状況において生成されない場合があります。

  • DeliveredTo テーブルのクリーンアップが行われなくなります。DeliveredTo テーブルは、Exchange ストアが、重複メッセージを配信しないようにするために使用します。Track Duplicates の値は、DeliveredTo テーブルのエントリが保持される時間範囲を制御します。Background Cleanup 値は存在するが、Track Duplicates 値が存在しない場合、24 時間以上経過したエントリはバックグラウンドでのクリーンアップによって削除されます。Track Duplicates の推奨値は 1 (10 進数または 16 進数) です。

Background Cleanup は既定値の 60,000 (10 進数) または 0xEA60 (16 進数) に設定することをお勧めします。

注意 :
以下の手順を実行してこの警告を修正すると、通常は定期的にクリーンアップされるすべてのアイテムに対してバックグラウンドでのクリーンアップが完了するまでは、サーバーの負荷が増加する可能性があります。したがって、これらの変更は、ユーザーへの影響が最小限に抑えられる時間帯に行うことをお勧めします。さらに、開封通知を要求するメッセージが開封されずに削除され、この問題が原因でクリーンアップされなかった場合、この警告を修正すると、このような各メッセージに対して未開封通知が生成されます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Background Cleanup という名前の DWORD 値を作成し、その値のデータを 60,000 (10 進数) または 0xEA60 (16 進数) に設定します。

  4. レジストリ エディタを終了します。変更を有効にするには、次のいずれかを実行します。

    • 影響を受けるインフォメーション ストアをいったん解除してから再度マウントします。

    • Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


パブリック フォルダ ストアのバックグラウンドでのクリーンアップ間隔が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Background Cleanup レジストリ値の現在の値のデータを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<PublicStoreGUID>\Background Cleanup

Background Cleanup の値のデータが 60,000 (10 進) または 0xEA60 (16 進) 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。Background Cleanup は既定値に設定することをお勧めします。

Background Cleanup の値が大きすぎると、バックグラウンドでのクリーンアップ プロセスが十分な頻度で実行されず、次のような多くの問題が発生する可能性があります。

  • Exchange システム マネージャに表示されるフォルダ サイズやアイテムの数が Microsoft Outlook® に表示される内容と大幅に異なる場合があります。さらに、これらのアイテムによって占有されるデータベースの領域が再割り当てされない場合があります。

  • 開封されずに削除されたアイテムに対する未開封通知が、特定の状況において生成されない場合があります。

  • DeliveredTo テーブル内の古いエントリのクリーンアップが行われなくなります。DeliveredTo テーブルは、Exchange ストアが、重複メッセージを配信しないようにするために使用します。

Background Cleanup の値が小さすぎると、バックグラウンドでのクリーンアップ プロセスによって、サーバーに不必要な負荷がかかる可能性があります。

注意 :
以下の手順を実行して大きすぎる値を既定の構成に戻すと、通常は既定の間隔でクリーンアップされるすべてのアイテムに対してバックグラウンドでのクリーンアップが完了するまでは、サーバーの負荷が増加する可能性があります。したがって、これらの変更は、ユーザーへの影響が最小限に抑えられる時間帯に行うことをお勧めします。さらに、開封通知を要求するメッセージが開封されずに削除され、この問題が原因でクリーンアップされなかった場合、この警告を修正すると、このような各メッセージに対して未開封通知が生成されます。
重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<PublicStoreGUID>

  3. Background Cleanup の値のデータを 60,000 (10 進) または 0xEA60 (16 進) に変更します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


パブリック フォルダ ストアに対するバックグラウンドでのクリーンアップ間隔が存在しない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Background Cleanup レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>\Background Cleanup

Background Cleanup 値が存在しないことが検出されると、警告が表示されます。

Background Cleanup の値が存在しない場合、バックグラウンドのクリーンアップ プロセスが実行されず、次のような多くの問題が発生する可能性があります。

  • Exchange システム マネージャまたは Exchange 管理コンソールに表示されるフォルダ サイズやアイテムの数が Microsoft Outlook® に表示される内容と大幅に異なる場合があります。さらに、これらのアイテムによって占有されるデータベースの領域が再割り当てされない場合があります。

  • 開封されずに削除されたアイテムに対する未開封通知が、特定の状況において生成されない場合があります。

  • DeliveredTo テーブルのクリーンアップが行われなくなります。DeliveredTo テーブルは、Exchange ストアが、重複メッセージを配信しないようにするために使用します。Track Duplicates の値は、DeliveredTo テーブル内のエントリを保持する時間範囲を制御します。Background Cleanup 値は存在するが、Track Duplicates 値が存在しない場合、24 時間以上経過したエントリはバックグラウンドでのクリーンアップによって削除されます。Track Duplicates の推奨値は 1 (10 進数または 16 進数) です。

Background Cleanup は既定値の 60,000 (10 進数) または 0xEA60 (16 進数) に設定することをお勧めします。

注意 :
以下の手順を実行してこの警告を修正すると、通常は定期的にクリーンアップされるすべてのアイテムに対してバックグラウンドでのクリーンアップが完了するまでは、サーバーの負荷が増加する可能性があります。したがって、これらの変更は、ユーザーへの影響が最小限に抑えられる時間帯に行うことをお勧めします。さらに、開封通知を要求するメッセージが開封されずに削除され、この問題が原因でクリーンアップされなかった場合、この警告を修正すると、このような各メッセージに対して未開封通知が生成されます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicStoreGUID>

  3. Background Cleanup という名前の DWORD 値を作成し、その値のデータを 60,000 (10 進数) または 0xEA60 (16 進数) に設定します。

  4. レジストリ エディタを終了します。変更を有効にするには、次のいずれかの操作を行います。

    • 影響を受けるインフォメーション ストアをいったん解除してから再度マウントします。

    • Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


BreakOnEvent が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Information Store に対してデバッグが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\BreakOnEvent

BreakOnEvent レジストリ値に値が設定されていることが検出されると、警告が表示されます。

BreakOnEvent レジストリ値は、Microsoft Exchange Information Store のデバッグ モードを引き起こすストア イベントを指定する 10 進数の値を保持しています。Microsoft Exchange Information Store は、デバッグ モードで実行されると大量のリソースを使用します。ベスト プラクティスとして、運用環境ではストアをデバッグしないようにすることをお勧めします。

Microsoft 製品サポート サービスの支援を受けて Exchange Information Store の問題のトラブルシューティングを行うことが多い場合を除き、BreakOnEvent レジストリ値は削除してください。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
BreakOnEvent レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、BreakOnEvent 値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


呼び出しのトレースが無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Call Trace logging が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable Call Tracing

Disable Call Tracing のレジストリ値が存在し、その値として 1 を使用するように構成され、かつコンピュータが Exchange Server 2003 を実行していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Call Trace logging が有効になっていると、Store.exe プロセスに対する関数呼び出しデータがログ出力されます。既定では、Exchange Server 2003 が実行されているコンピュータでは呼び出しのトレースは有効になっています。Exchange 2000 Server ではこの機能が既定で無効になっていることに注意してください。ただし、Exchange Server 2003 を実行している場合は、Microsoft 製品サポート サービスから特別な指示がない限り、呼び出しのトレースを有効にする必要があります。呼び出しのトレースが有効になっていると、ストアプロセスで発生する任意の問題のトラブルシューティングに使用できる重要な情報が収集されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. レジストリ エディタ (Regedit.exe または Regedt32.exe) を起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Disable Call Tracing レジストリ値を 0 に設定します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


呼び出しのトレースが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Call Trace logging が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable Call Tracing

Disable Call Tracing のレジストリ値が存在し、値 0 で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Call Trace logging が有効になっていると、Store.exe プロセスに対する関数呼び出しデータがログ出力されます。Call Trace logging によって、パフォーマンスが最大 4% 低下する場合があります。Store.exe プロセスが応答しない場合、または応答が遅いためにトラブルシューティングが必要な場合以外は、この機能を有効にしないでください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Disable Call Tracing レジストリ値を 1 に設定します。Flush Call Traces キー、RPC Requests Threshold キー、および Call Tracing Logging Interval キーは、呼び出しのトレースが無効になっているときには使用されません。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


クラスタでチェックポイントの深さが正しく設定されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループの msExchESEParamCheckpointDepthMax 属性の値を判断します。Exchange 2000 Server クラスタで msExchESEParamCheckpointDepthMax 属性が 5,242,880 に等しくないことが検出されると、警告が表示されます。

msExchESEParamCheckpointDepthMax 属性はバイト単位で設定されており、チェックポイントの最大の深さを規定します。チェックポイントの深さは、Exchange ストアにコミットされるのを待っているデータの量です。チェックポイントの最大の深さは、任意の時点で保留にすることができるデータの最大量です。したがって、チェックポイントの最大の深さが 20 MB に設定されている場合は、この 20 MB が、任意の時点で (Exchange ストアにコミットせずに) 保留にしておくことができるデータの最大量になります。クラスタ化された環境では、このパラメータの値を小さくするとフェールオーバー時間が短くなります。Exchange Server 2003 でのテスト結果を見ると、このパラメータの値を 5 MB (5,242,880 バイト) にした場合 (これに対して、Exchange 2000 Server での既定値は 20 MB でした)、サーバーの I/O パフォーマンスに重大な影響を与えることなく、フェールオーバー時間が格段に短くなっています。

Exchange 2000 Server クラスタでは、この値を常に 5,242,880 に設定してください。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory® ディレクトリ サービス オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

ADSI Edit を使用して msExchESEParamCheckpointDepthMax 属性を設定するには

  1. Active Directory サービス インターフェイス (ADSI) Edit を実行します。ADSI Edit は、Microsoft Windows® 2000 Server および Microsoft Windows Server™ 2003 のサーバー サポート ツールに含まれています。

  2. コンソール ツリーで、[ADSI Edit] を右クリックし、[Connect To] をクリックします。次に、接続先として [Naming Context] の Configuration Container を選択します。

  3. [Configuration] コンテナを、[CN=Configuration]、[CN=Services]、[CN=Microsoft Exchange]、[CN=<組織名>]、[CN=Administrative Groups]、[CN=<管理グループ名>]、[CN=Servers]、[CN=<サーバー名>]、[CN=Information Store] の順に展開します。

  4. [CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  5. プロパティの一覧で、[msExchESEParamCheckpointDepthMax] を選択します。

  6. [Edit Attribute] ボックスで、設定するサイズを 5 MB 単位で入力します。この値はバイト単位で入力する必要があります。たとえば、5 MB のチェックポイントの深さは 5,242,880 バイト、10 MB のチェックポイントの深さは 10,485,760 バイトになります。入力できる最小サイズは 5 MB です。20 MB を超える値を入力すると、Microsoft Exchange Information Store サービスのリソースのフェールオーバー時間が長くなります。

  7. ADSIEdit を終了し、Microsoft Exchange Information Store サービスを再開します。

Exchange 2000 Server クラスタの展開の詳細については、『Deploying Microsoft Exchange 2000 Server Clusters』(http://go.microsoft.com/fwlink/?LinkID=14578) を参照してください (このサイトは英語の場合があります)。


チェックポイント ファイルの配置
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange サーバー上の各ストレージ グループのチェックポイント ファイル パス (msExchESEParamSystemPath) がそのストレージ グループのトランザクション ログ パス (msExchESEParamLogFilePath) に一致するかどうかを判断します。ストレージ グループのチェックポイント ファイル パスがトランザクション ログ パスに一致しないことが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

チェックポイント ファイルの場所がトランザクション ログ ファイルの場所に一致しないと、ディスク障害が発生した場合のダウンタイムが長くなる可能性があります。

Exchange 2000 Server および Exchange Server 2003 で Exchange ストレージ グループのチェックポイント ファイルの場所を変更するには、次の操作を行います。

  1. Exchange システム マネージャで、ストレージ グループを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブの [システム パスの場所] で、[参照] をクリックし、チェックポイント ファイルの場所を選択します。
Exchange 2000 Server および Exchange Server 2003 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を変更するには、次の操作を行います。

  1. Exchange システム マネージャで、ストレージ グループを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブの [トランザクション ログの場所] で、[参照] をクリックし、トランザクション ログ ファイルの場所を選択します。
Exchange Server 2007 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を変更するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループ ログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80702) の手順に従ってください (このサイトは英語の場合があります)。

トランザクション ログ ファイルの場所の詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Mailbox Stores and Public Folder Stores」を参照してください (このサイトは英語の場合があります)。

チェックポイント ファイルの詳細については、『Using Recovery Storage Groups in Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47589) の「Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003」を参照してください (このサイトは英語の場合があります)。


フロントエンド サーバーで循環ログが無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-03-27

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、循環ログ (msExchESEParamCircularLog) 属性用に構成されている値を判断します。この属性が 0 の値で構成されていることが検出されると、警告が表示されます。

msExchESEParamCircularLog 属性の値が 1 の場合は、循環ログが有効になっていることを示します。msExchESEParamCircularLog 属性の値が 0 の場合は、循環ログが無効になっていることを示します。

Exchange Server で使用される標準のトランザクション ログでは、ストレージ グループ内の各データベース トランザクションはログ ファイルに書き込まれてからデータベースに書き込まれます。ログ ファイルが一定のサイズに達すると、そのログ ファイルの名前は変更され、新しいログ ファイルが作成されます。これにより、時間の経過と共にログ ファイルのセットが作成されます。クラッシュが発生した場合は、これらのログ ファイルからデータベースにデータを再生することにより、トランザクションを復元できます。

循環ログでは、最初のログ ファイルに含まれているデータがデータベースに書き込まれると、そのログ ファイルを上書きして再利用します。Exchange Server では、循環ログは既定で無効になっています。循環ログを有効にするとドライブ記憶域の要件を減らすことはできますが、完全なトランザクション ログ ファイルがないと、最終の完全なバックアップより新しい状態には復元できません。このため、メールボックスやパブリック フォルダのデータが格納されている運用サーバーでは、循環ログの使用はお勧めできません。しかし、メールボックスやパブリック フォルダが格納されていないフロントエンド Exchange サーバーでは、コミットされるメッセージは配信不能レポート (NDR) のみです。そのため、これらのサーバーのトランザクション ファイルを保持する必要はなく、また、これらのサーバーをバックアップする理由もあまりありません。フロントエンド サーバーで循環ログを有効にすると、トランザクション ログを上書きできるため、データが 20 MB を超えることはありません。

循環ログを有効にするには

  1. Exchange システム マネージャで、[サーバー] を展開し、Exchange サーバーを展開します。

  2. 循環ログを有効にするストレージ グループを右クリックし、[プロパティ] を選択します。ストレージ グループのプロパティのダイアログ ボックスが表示されます。

  3. [循環ログを有効にする] チェック ボックスをオンにし、[OK] をクリックして変更を保存します。

  4. Exchange システム マネージャを終了し、Microsoft Exchange Information Store を再起動して、変更を有効にします。

循環ログの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 258470「[XADM] 循環ログの設定を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=258470)

  • 文書番号 147524「[XADM] トランザクション ログの使用への循環ログの影響」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)

  • 文書番号 296788「Exchange のオフライン バックアップと復元処理」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=296788)

  • 文書番号 314605「[HOW TO] Exchange 2000 Server で循環ログを有効または無効にする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314605)


循環ログが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange サーバー上のストレージ グループごとに、msExchESEParamCircularLog 属性の値を判断します。値が 1 の場合、そのストレージ グループに対して循環ログが有効になっています。値が 2 の場合は、そのストレージ グループに対して循環ログは有効になっていません。さらに、Exchange Server アナライザは、Active Directory に対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性のエントリ数は、メールボックス ストア上のメールボックスの数を表します。

また、Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間の Exchange_Server Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、IsFrontEndServer キーの値を判断します。値が True の場合は、Exchange Server コンピュータはフロントエンド サーバーです。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。

Exchange Server アナライザ ツールによって、msExchESEParamCircularLog 属性の値が 1 に設定されていること、IsFrontEndServer キーの値が False に設定されていること、および homeMDBBL 属性の値が 20 より大きいことが検出されると、警告が表示されます。

この値の組み合わせは、20 を超えるメールボックスを含むメールボックス サーバーで循環ログが有効になっていることを示します。Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 で使用される標準のトランザクション ログでは、ストレージ グループ内のデータベース トランザクションは、それぞれログ ファイルに書き込まれてからデータベースに書き込まれます。ログ ファイルが一定のサイズに達すると、そのファイルの名前が変更されて、新しいログ ファイルが作成されます。時間が経過すると、一連のログ ファイルが作成されることになります。クラッシュが発生した場合は、これらのログ ファイルからデータベースにデータを再生すると、トランザクションを回復できます。

循環ログは、ログに含まれるデータがデータベースに書き込まれた後、最初のログ ファイルを上書きして再利用します。Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 では、循環ログは既定で無効になっています。循環ログを有効にすることで、ドライブで必要とされる記憶域は減少しますが、完全なトランザクション ログ ファイルがないと、最後の完全バックアップより新しい状態には回復できません。したがって、通常の運用環境では循環ログは推奨されません。

Exchange 2000 Server および Exchange Server 2003 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、変更するサーバーを展開します。

  3. 変更するストレージ グループを右クリックし、[プロパティ] をクリックします。

  4. プロパティ ダイアログ ボックスで、[循環ログを有効にする] チェック ボックスをオフにします。

  5. [OK] をクリックして設定を保存します。

  6. Exchange システム マネージャを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

Exchange Server 2007 で Exchange 管理コンソールを使用してこの警告を修正するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、変更するサーバーを展開します。

  3. 変更するストレージ グループを右クリックし、[プロパティ] をクリックします。

  4. [プロパティ] ダイアログ ボックスで、[循環ログを有効にする] チェック ボックスをオフにします。

  5. [OK] をクリックして設定を保存します。

  6. Exchange 管理コンソールを終了し、Microsoft Exchange Information Store サービスを再起動して変更を有効にします。

Exchange Server 2007 で Exchange 管理シェルを使用してこの警告を修正するには、次の操作を行います。

  1. 次のコードは、ストレージ グループ 'MyStorageGroup' の循環ログを無効にする Set-StorageGroup コマンドの例を示しています。
コードのコピー
Set-StorageGroup -Identity MyStorageGroup -CircularLoggingEnabled $false
  • 循環ログの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 147524「[XADM] トランザクション ログの使用への循環ログの影響 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)」

  • 文書番号 240145「[XADM] 安全に移動できるトランザクション ログ ファイルを特定する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=240145)


循環ログが無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-03-23

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、msExchESEParamCircularLog 属性用に構成されている値を判断します。

msExchESEParamCircularLog 属性値が 1 の場合は、循環ログが有効になっていることを示します。msExchESEParamCircularLog 属性値が 0 の場合は、循環ログが無効になっていることを示します。

また、Exchange アナライザは、以下の状況についても判断します。

  • Exchange Server がフロントエンド サーバーとして構成されているかどうか。

  • SMTP サービスが実行されているかどうか。および、構成されているメールボックスの数。

Exchange アナライザによって以下の状況にあることが検出されると、警告が表示されます。

  • msExchESEParamCircularLog 属性が値 0 で構成されている。

  • サーバーがフロントエンド サーバーとして構成されていない。

  • 構成されているメールボックスの数が 20 未満である。

Exchange Server で使用される標準のトランザクション ログでは、ストレージ グループ内の各データベース トランザクションはログ ファイルに書き込まれてからデータベースに書き込まれます。ログ ファイルが一定のサイズに達すると、そのファイルの名前が変更されて、新しいログ ファイルが作成されます。時間の経過と共に、この標準のトランザクション ログによって一連のログ ファイルが作成されます。システム障害が発生した場合は、これらのログ ファイルからデータベースにデータを再生することにより、トランザクションを回復できます。

循環ログでは、ログに含まれるデータがデータベースに書き込まれた後、最初のログ ファイルを上書きして再利用します。Exchange Server では、循環ログは既定で無効になっています。

重要 :
循環ログを有効にすると、ドライブ記憶域の要件を減らすことができます。ただし、完全なトランザクション ログ ファイルがないと、最後に取得された完全なバックアップよりも新しいデータは回復できません。このため、メールボックスのデータやパブリック フォルダのデータが格納されている運用サーバーでは、循環ログの使用はお勧めできません。

フロントエンド Exchange サーバー、メッセージング ルーティング サーバー (インフラストラクチャ サーバーとも呼ばれます)、およびユーザーのメールボックスやパブリック フォルダが格納されていないブリッジヘッド サーバーでは、コミットされるメッセージは配信不能レポート (NDR) のみです。そのため、これらのサーバーではトランザクション ファイルを保持する必要はありません。また、これらのサーバーはバックアップも必要ありません。ユーザーのメールボックスが格納されていないサーバーで循環ログを有効にすると、トランザクション ログ ファイルを上書きすることができるため、トランザクション ログ ファイルのデータが 20 MB を超えることはありません。

Exchange 2000 Server および Exchange Server 2003 で循環ログを有効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、Exchange サーバーを展開します。

  3. 循環ログを有効にするストレージ グループを右クリックし、[プロパティ] を選択します。ストレージ グループのプロパティのダイアログ ボックスが表示されます。

  4. [循環ログを有効にする] チェック ボックスをオンにし、[OK] をクリックして変更を保存します。

  5. Exchange システム マネージャを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。
Exchange Server 2007 で Exchange 管理コンソールを使用して循環ログを有効にするには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、変更するサーバーを展開します。

  3. 変更するストレージ グループを右クリックし、[プロパティ] をクリックします。

  4. [プロパティ] ダイアログ ボックスで、[循環ログを有効にする] チェック ボックスをオンにします。

  5. [OK] をクリックして設定を保存します。

  6. Exchange 管理コンソールを終了し、Microsoft Exchange Information Store サービスを再起動して変更を有効にします。
Exchange Server 2007 で Exchange 管理シェルを使用して循環ログを有効にするには、次の操作を行います。

  1. 次のコードは、ストレージ グループ MyStorageGroup の循環ログを有効にする Set-StorageGroup コマンドの例を示しています。
コードのコピー
Set-StorageGroup -Identity MyStorageGroup -CircularLoggingEnabled $true

循環ログの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 258470「[XADM] 循環ログの設定を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=258470)

  • 文書番号 147524「[XADM] トランザクション ログの使用への循環ログの影響」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=147524)

  • 文書番号 296788「Exchange のオフライン バックアップと復元処理」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=296788) を参照してください。

  • 文書番号 314605「[HOW TO] Exchange 2000 Server で循環ログを有効または無効にする方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314605)


クライアント/サーバーの RPC 圧縮が無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、リモート プロシージャ コール (RPC) 圧縮が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Rpc Compression Enabled

Rpc Compression Minimum Size の値が存在し、0 で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Microsoft Office Outlook® 2003 または Outlook 2007 と、Exchange Server 2003 または Exchange Server 2007 の間で転送される RPC データは、サイズにかかわらず、すべて圧縮されます。状況によっては、RPC 圧縮を制御することができます。たとえば、ネットワーク経由で送信されたパケットを表示して接続の問題をトラブルシューティングしようとしている場合は、RPC 圧縮が使用されていると、圧縮されたデータのみがトレースに表示されるために分析が困難になる可能性があります。

RPC 圧縮の設定を構成するには、システム設定に次のレジストリ キーの値を追加します。

  • Rpc Compression Minimum Size

  • Rpc Compression Enabled

  • Rpc Packing Enabled

Rpc Compression Enabled レジストリの値は、RPC 圧縮アルゴリズムを使用するかどうかを判断します。このキーが存在しない場合、RPC 圧縮は有効になり、使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Rpc Compression Enabled キーを削除します。Rpc Compression Minimum Size キーや Rpc Packing Enabled キーが存在する場合は、それらも削除します。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC 圧縮を制御する方法の詳細については、Microsoft サポート技術情報の文書番号 825371「Exchange Server 2003 でのリモート プロシージャ呼び出し圧縮を変更します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371) を参照してください。


ClientMonitoringReportLevel パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server 2003 が Microsoft Office Outlook® 2003 のネットワーク パフォーマンス データを監視する方法を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

ClientMonitoringReportLevel レジストリ キーの値が 1 に設定されていないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server は ClientMonitoringReportLevel レジストリ キーの値を使用して、Outlook 2003 クライアントのネットワーク エラーや待ち時間の問題を識別します。ClientMonitoringReportLevel レジストリ キーに設定できる値は次の 3 つです。

値 | 機能
0 | Outlook 2003 クライアントからパフォーマンス データを収集しません。
1 | 高速のネットワーク接続を使用している Outlook 2003 クライアントからのみパフォーマンス データを収集します。
2 | すべての Outlook 2003 からパフォーマンス データを収集します。

ClientMonitoringReportLevel レジストリ キーを値 1 または 2 を使用して有効にすると、Outlook 2003 クライアントはサーバーにデータを送信します。サーバーに送信されるデータは、ネットワーク接続のステータスと状態を示しています。サーバーに送信されるデータには、失敗したリモート プロシージャ コール (RPC) 要求やエラー状態に関する情報が含まれます。サーバーはこれらの情報を集計し、イベント ログのエントリに記録します。

Exchange セットアップでは、ClientMonitoringReportLevel レジストリ キーは作成されません。ただし、Exchange Server 2003 は既定で、高速のネットワーク接続を使用している Outlook 2003 クライアントからのみパフォーマンス データを収集します。この Exchange Server 2003 の既定の動作は、ClientMonitoringReportLevel レジストリ キーの値が 1 に設定されている場合の機能と同じです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定値に戻す場合は、ClientMonitoringReportLevel レジストリ キーの値を編集することができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [ClientMonitoringReportLevel] をダブルクリックします。

  4. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


格納域の制限の実装を検討する
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 rivate メッセージ データベース (MDB) オブジェクトにメールボックス クォータが設定されているかどうかを判断します。特定のプライベート MDB に 20 を超えるメールボックスが含まれていて、その MDB にクォータが設定されていないことが検出されると、ベスト プラクティスの構成を推奨するメッセージが表示されます。

ベスト プラクティスとして、ユーザー メールボックスをホストする Exchange Server コンピュータ上のすべてのデータベースにクォータを適用することをお勧めします。データベース レベルで設定する必要がある制限は 3 つあります。これらの制限は、メールボックス ストアのプロパティ ページの [制限] タブで設定します。それぞれの制限は、KB 単位で示されます。

  • 警告 メールボックスのサイズが Issue warning 制限で定義された値に達すると、ユーザーに警告の電子メールが送信されます。この警告の電子メールは、ユーザーに対して、メールボックスのサイズが Prohibit send 制限に近づいていることを通知します。

  • 送信禁止 メールボックスのサイズが Prohibit send 制限で定義された値に達すると、ユーザーは電子メールの送信ができなくなります。ユーザーは Exchange サーバーから、メールボックスのサイズ制限を超えたことを説明する電子メールを受信します。

  • 送受信禁止 メールボックスのサイズが Prohibit send and receive 制限で定義された値に達すると、ユーザーは電子メールの送信と受信の両方ができなくなります。ユーザーに送信されたメールはすべて、配信不能レポート (NDR) と共に送信者に返されます。

これらの規則を設定するときには、送信禁止の制限と送受信禁止の制限の間に十分な差分を与えるようにしてください。2 つの制限の間の差分が小さすぎると、ユーザーがメールボックスをクリーンアップする前にメールボックスがメッセージを拒否する可能性があります。このため、ベストプラクティスとして、送信禁止の制限と送受信の禁止の制限の間には少なくとも 20% のバッファを与えることをお勧めします。たとえば、ユーザーのメールボックスが 100 MB に達したときに新しいメッセージの送信を禁止する場合、送受信禁止の制限は少なくとも 120 MB に設定します。

Exchange 2000 Server および Exchange Server 2003 でメールボックスの制限を設定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. Exchange Server アナライザでこの問題点に関連してメッセージが表示されたメールボックス ストアを見つけます。

  3. [<メールボックス ストア名>] を右クリックし、[プロパティ] をクリックします。

  4. [制限] タブをクリックします。

  5. [警告を表示するサイズ (KB)]、[送信を禁止するサイズ (KB)]、および [送受信を禁止するサイズ (KB)] の制限を変更します。

  6. [適用] をクリックし、[OK] をクリックします。
Exchange Server 2007 で Exchange 管理コンソールを使用してメールボックスの制限を設定するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. Exchange Server アナライザでこの問題点に関連してメッセージが表示されたメールボックス ストアを見つけます。

  3. [<メールボックス ストア名>] を右クリックし、[プロパティ] をクリックします。

  4. [制限] タブをクリックします。

  5. [警告を表示するサイズ (KB)]、[送信を禁止するサイズ (KB)]、および [送受信を禁止するサイズ (KB)] の制限を変更します。

  6. [適用] をクリックし、[OK] をクリックします。
Exchange Server 2007 で Exchange 管理シェルを使用してメールボックスの制限を設定するには、次の操作を行います。

  1. 次の例は、警告メッセージがユーザーに送信される、メールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の警告クォータの属性セットを持たないすべてのメールボックスに適用されます。整数または "unlimited" を指定する必要があります。既定値は 1.9 ギガバイト (GB) です。

    コードのコピー
    Set-MailboxDatabase "Mailbox Database Name" -IssueWarningQuota 1991680

  2. 次の例は、このメールボックス データベース内のメールボックスに関連付けられているユーザーがメッセージを送信できなくなるメールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の送信禁止クォータの属性セットを持たないすべてのメールボックスに適用されます。制限値の設定は、整数または "unlimited" のいずれかである必要があります。

    コードのコピー
    Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendQuota 2097152

  3. 次の例は、このメールボックスに関連付けられているユーザーがメッセージを送受信できなくなるメールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の送受信禁止クォータの属性セットを持たないすべてのメールボックスに適用されます。整数または "unlimited" を指定する必要があります。

    コードのコピー
    Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendReceiveQuota 2411520

Exchange Server 2003 での Exchange メールボックスの管理方法の詳細については、Exchange Server 2003 ストアの操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47595) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 での Exchange メールボックス制限の管理方法の詳細については、データベースの制限とプロパティの構成方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80746) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアでコンテンツのインデックス処理が有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、コンテンツのインデックス処理の再構築スケジュール (msExchCIRebuildSchedule) 属性が NULL 以外の値に設定されているかどうか、およびコンテンツのインデックス処理の再構築スタイル (msExchCIRebuildSchedule) 属性が設定されているかどうかを判断します。これらは、各プライベート メールボックス データベースの属性です。この両方の属性がインデックス用に構成されていることが検出されると、警告が表示されます。

インデックス処理はリソースを集中的に使用し、またメールボックス データは頻繁に変更されるため、メールボックス ストアでコンテンツのインデックス処理 (「フルテキスト インデックス処理」とも呼ばれます) を実行することはお勧めできません。特定のデータベースのインデックスを最新の状態に保つことは、リソースを非常に集中的に使用するプロセスです。フルテキスト インデックス処理は、パブリック フォルダの方に適しています。

メールボックス ストアでフルテキスト インデックス処理を実行する場合は、インデックス処理のスケジュールを頻繁に更新されるように設定し、コンピュータのパフォーマンスを監視して、コンテンツのインデックスが作成されている間もコンピュータが過負荷の状態にならず、メールの配信やクライアント要求への応答が可能な状態になるように保証することをお奨めします。

それ以外の場合は、メールボックス ストアのフルテキスト インデックスを削除して、フルテキスト インデックス処理を無効にすることをお勧めします。

特定のメールボックス ストアのフルテキスト インデックス処理を無効にするには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、対象の管理グループ、[サーバー] 、対象のサーバー、ストレージ グループの順に展開します。[メールボックス ストア] を右クリックし、[フルテキスト インデックスの削除] をクリックします。

Exchange でのフルテキスト インデックス処理の構成とトラブルシューティングの詳細については、Microsoft サポート技術情報の文書「HOW TO: 2003 にメールボックス ストアでの Exchange でのフルテキスト インデックス処理を構成します」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=822932) を参照してください。


パブリック フォルダ ストアでコンテンツのインデックス処理が有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、コンテンツのインデックス処理の再構築スケジュール (msExchCIRebuildSchedule) 属性と、コンテンツのインデックス処理の再構築方式 (msExchCIRebuildStyle) 属性が存在しており、0 以外の値に設定されているかどうかを判断します。これらは、各パブリック インフォメーション ストア データベースの属性です。

これらの属性がどちらも存在し、0 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

これら 2 つの属性がどちらも 1 に設定されている場合、インフォメーション ストア データベースに対するフルテキスト インデックス処理が有効になっていたことを示します。フルテキスト インデックス処理は、指定したデータベース内のすべての単語にインデックスを付けて、強力で高速な検索を可能にしています。フルテキスト インデックス処理を展開する場合は、インデックス処理を行うパブリック フォルダやメールボックス ストアを個々に選択します。ユーザーはその後、パブリック フォルダまたはメールボックス ストアに含まれるメッセージと添付ファイルに対して、フルテキスト検索を実行できます。

インデックスには、既定でメッセージの件名と本文、送信者と受信者の名前、および CC と BCC のフィールドに指定されたすべての名前が含まれます。また, .doc, .xls, .ppt, .html, .htm, .asp, .txt、および .eml (埋め込み MIME (Multipurpose Internet Mail Extensions) メッセージ) ファイルなどの種類の添付ファイルのテキストも含まれます。画像やサウンドなどのバイナリ添付ファイルはインデックス処理されません。

検索結果の正確さは、インデックスが最後に更新されたタイミングに依存します。パブリック フォルダやメールボックス ストアの内容を変更したときは、新しい内容を反映するようにインデックスを更新する必要があります。インデックスの更新は、手動で行うか、スケジュールに従って自動で行います。

フルテキスト インデックス処理に関するファイルの種類は、主に 4 つに分けられます。これらのファイルのディスク上での場所を以下のように配置することによって、フルテキスト インデックス処理のパフォーマンスを最適化できます。

  • カタログ カタログは主要なインデックスです。Exchange ストアごとに 1 つのカタログが存在できます。カタログは RAID-0+1 アレイ上に配置してください。カタログを作成するときに、Exchange システム マネージャでカタログの場所を指定できます。

  • プロパティ ストア これは、カタログでインデックス処理されたアイテムのさまざまなプロパティを格納するデータベースです。プロパティ ストアは各サーバーに 1 つだけ存在します。フルテキスト プロパティ ストアは RAID アレイ上に配置してください。既定では、このファイルは Exchange Server と同じドライブにインストールされます。

  • 一時ファイル これらのファイルは、Microsoft Search サービスで使用される一時的な情報を保持します。フルテキスト インデックス処理の一時ディレクトリは RAID アレイ上に配置してください。既定では、これらのファイルはシステム ドライブにインストールされます。システム ドライブでは通常、RAID アレイのような I/O スループットは得られません。

  • 収集ログ これらのファイルは、インデックス処理サービスのログ情報を保持します。カタログごとに 1 組のログが存在します。収集ログは既定の場所に残すことができますが、必要に応じて移動することもできます。

フルテキスト インデックス処理を有効または無効にするには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、操作しようとしているパブリック フォルダ ストアが含まれるストレージ グループを展開します。

  3. 目的のパブリック フォルダ ストアを右クリックし、[プロパティ] をクリックします。

  4. [フルテキスト インデックス処理] タブをクリックします。

  5. [更新の間隔] フィールドを必要に応じて編集します。

  6. [OK] をクリックして変更を保存し、パブリック フォルダ ストアのプロパティ ダイアログ ボックスを閉じます。

パブリック フォルダのフルテキスト インデックス処理の詳細については、Microsoft サポート技術情報の文書番号 319433「[HOWTO] パブリック フォルダでフルテキスト インデックスを構成する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319433) を参照してください。

メールボックスのフルテキスト インデックス処理に関する構成とトラブルシューティングの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822932「HOW TO: 2003 にメールボックス ストアでの Exchange でのフルテキスト インデックス処理を構成します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822932)

  • 文書番号 319436「[HOWTO] Exchange 2000 のメールボックス ストアにフルテキスト インデックス処理を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319436)

複数言語環境でのフルテキスト インデックス処理の詳細については、Microsoft サポート技術情報の文書番号 325624「XGEN: 複数の言語とのインデックス フルテキスト」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325624) を参照してください。

フルテキスト インデックス処理のベスト プラクティスの詳細については、Microsoft サポート技術情報の文書番号 326186「[XADM] ホワイト ペーパー『The Best Practices for Deploying Full-Text Indexing』」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326186) を参照してください。


現在 DSN がメッセージとして処理されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server コンピュータで配信状態通知 (DSN) が標準メッセージとして処理されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent\RenderDSNsAsMessages

Exchange Server アナライザによって、RenderDSNsAsMessages レジストリ エントリの存在が検出され、さらにそれが 0 より大きい値で構成されていることが確認されると、既定以外の構成であることを示すメッセージが表示されます。

RenderDSNsAsMessages レジストリ エントリはその名前のとおり、管理者が Exchange 2000 Server コンピュータ、Exchange Server 2003 コンピュータ、および Exchange Server 2007 コンピュータで DSN を処理する方法を制御するための構成です。

  • RenderDSNsAsMessages の値データが 0 に設定されている場合、DSN (配信レポートおよび配信不能レポートを含む) は標準の MAPI メッセージとして処理されます。

  • RenderDSNsAsMessages の値データが 0 より大きい値の場合、DSN は multipart/mixed MIME メッセージとして処理されます。

このレジストリ値は既定では存在しないため、使用する場合は手動で追加する必要があります。さらに、このエントリを Exchange 2000 Server で有効にするには、最低でも 2003 年 9 月公開の Exchange 2000 Server Service Pack 3 以降のロールアップをコンピュータで実行する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

  3. RenderDSNsAsMessages レジストリ エントリを削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。
  • レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

  • 配信状態通知の形式に関する問題の詳細については、Microsoft サポート技術情報の文書番号 812806「[XADM] Exchange ユーザーにカスタム NDR ではなく標準の NDR が配信される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=812806) を参照してください。

  • Exchange 2000 Server Service Pack 3 以降のロールアップの詳細については、Microsoft サポート技術情報の文書番号 824282「2003 年 9 月公開の Exchange 2000 Server Service Pack 3 以降のロールアップについて」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=824282) を参照してください。


データベースの Aging Keep Time 期間が既定値から変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange クライアントのビュー データベース インデックスについて既定の保存期間の値が無効にされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Private-<プライベート インフォメーション ストアの GUID>\Aging Keep Time

Aging Keep Time レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange データベース テーブル内に Exchange クライアントによって作成されたビューで使用されているインデックスが一定の時間使用されない場合、それらのインデックスは保存期間の設定に従ってクリーン アップされます。以下のレジストリ エントリは、インデックスの保存期間の制御に使用されます。

  • Aging Keep Time インデックスが削除されるまでの最短期間。既定値は、Exchange Server 5.5 では 8 日、Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 では 40 日です。

  • Aging Clean Interval インデックス保存期間のタスクが実行される最短間隔 (ミリ秒単位)。既定値は 24 時間です。

  • Reset Views この設定が存在し、0 以外の値の場合、キャッシュされているインデックスはすべて、インデックス保存期間のタスクが次に実行されるときに強制的に削除されます。インデックス保存期間のタスクが完了すると、Reset Views の値は 0 に設定されます。

Aging Keep Time レジストリ値は、Microsoft 製品サポート サービスの指示がない限り追加しないようにすることをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Aging Keep Time レジストリ値を表示または変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Private-<プライベート インフォメーション ストアの GUID>

  3. Aging Keep Time の値を調べ、必要に応じて変更します。

  4. レジストリ エディタを終了します。変更を加えた場合は、Exchange Server コンピュータを再起動し、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


データベースとログ ファイルが同じディスク ボリュームに格納されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、このメールボックス ストアのデータベース ファイルが、このストレージ グループのトランザクション ログ ファイルと物理的に同じディスク上に置かれているかどうかを判断します。具体的には Active Directory に対してクエリを実行し、以下のことを判断します。

  • メールボックス ストアに 100 より多いメールボックスがあるかどうか。これは、メールボックス ストア オブジェクト (msExchPrivateMDB クラス) の homeMDBBL 属性の値をカウントして判断します。メールボックス ストアにあるメールボックスの数が 100 より少なければ、ファイルの場所がパフォーマンスに与える影響は限られたものになります。

  • メールボックス ストアのデータベース ファイルのパス。これは、メールボックス ストア オブジェクトの msExchEDBFile の値を読み取って判断します。

  • ストレージ グループのトランザクション ログ ファイルのパス。これは、ストレージ グループ オブジェクト (msExchStorageGroup クラス) の msExchESEParamLogFilePath の値を読み取って判断します。

  • msExchESEParamLogFilePath のパスが、msExchEDBFile のパスと同じディスク上にあるかどうか。

さらに、Exchange Server アナライザは以下のことを判断します。

  • サーバーで Windows Powered NAS 用の Exchange Server 拡張機能が実行されているかどうか。これは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server NAS 拡張機能 (wssexchmap) の Started 属性値を調べて判断します。Windows Powered NAS 用の Exchange Server 拡張機能が実行されている場合、調査中のファイルはローカル ドライブには置かれておらず、パフォーマンスについての考慮事項が当てはまらない可能性があることを意味します。

  • ファイルが、3 文字より長い名前のディスク ボリューム上にあるかどうか。これは、Win32_Volume WMI クラスに対してクエリを実行して判断します。この場合も、ファイルはローカル ドライブには置かれておらず、パフォーマンスについての考慮事項が当てはまらないことを意味する可能性があります。

ハード ディスクに障害が発生した場合にフォールト トレランスを提供するには、Exchange のトランザクション ログ ファイルとデータベース ファイルを物理的に別のハード ディスクに保管します。これらのログ ファイルとデータベース ファイルを別個のハード ディスクに保管すると、ハード ディスクの I/O パフォーマンスを大幅に向上させることができます。

注 :
データベースの復元が必要な場合にフォールト トレランスを提供するため、各ストレージ グループ専用のトランザクション ログ ファイルのセットが使用されます。トランザクション ログ ファイルは、そのストレージ グループ内に存在するすべてのデータベースに加えられたすべての変更の記録を保持します。トランザクション ログ ファイルは、ストレージ グループ内のすべてのデータベースに関して完全バックアップが作成されるまで削除されません。

以下の例では、バックアップを作成済みで、トランザクション ログ ファイルが別のディスクにある場合に、データベース ファイルやトランザクション ログ ファイルが含まれるハード ディスクが機能しなくなったなどの極端な状況であってもデータを回復する方法を示します。

  • データベース ファイルを含むハード ディスクに障害が発生した場合は、そのハード ディスクを交換し、データベース ファイルの最新のバックアップを復元します。次に、別のハード ディスクに格納されていた現在のログ ファイルを使用すると、Exchange サーバー上のデータを復元してデータをハード ディスクの障害が発生した時点の最新状態にすることができます。

  • トランザクション ログ ファイルを含むハード ディスクに障害が発生しても、データベース ファイルを含むハード ディスクが機能していて、データベース ストア ファイルが正しく閉じられた場合は、障害が発生したトランザクション ログ ディスクを修復し、データベース ストアを再マウントできる可能性があります。データベース ストア ファイルは、正しく閉じられないと不整合状態のままになり、eseutil.exe を使用したハード リペア後にのみマウント可能になります。その結果、一部のデータが失われることがあります。他の選択肢として、バックアップからデータベース ストア ファイルを復元することもできます。この場合、バックアップの時点より後に作成された新しいメールボックスのデータは、復元されるファイルに含まれません。

重要 :
Exchange データベースとトランザクション ログ ファイルを物理的に同じハード ディスク上に保存していて、そのハード ディスクに障害が発生した場合、最後のバックアップの後に作成されたデータは失われます。

さらに、データベース ファイルとトランザクション ログ ファイルを別個の物理ディスクに配置すると、全体としてのパフォーマンスが高まります。Exchange は、各トランザクションをまずトランザクション ログ ファイルに書き込み、次にデータベース ファイルに書き込みます。加えて、トランザクション ログ ファイルは、ストレージ グループ内のすべてのメールボックス ストアによって共有されます。これらのファイルが同一の物理ディスク上に存在すると、ドライブのヘッドは現在のトランザクション ログ ファイルの場所と、データベース ファイルの場所の間を行ったり来たり移動して、書き込み操作を完了する必要があります。これらのファイルが別のディスク上にあると、1 つのドライブ ヘッドは所定の位置にとどまってトランザクション ログ ファイルに書き込むので、ファイルが 1 つのディスク上にある場合より迅速にトランザクションを完了できます。1 つのトランザクションでのパフォーマンスの違いはわずかですが、システムの負荷が高い場合には大きな違いになることがあります。

この構成を修正するために、トランザクション ログ ファイルとデータベース ファイルのいずれかを移動することができます。

Exchange 2000 Server または Exchange Server 2003 でトランザクション ログ ファイルを新しいドライブに移動するには、次の操作を行います。

  1. Exchange システム マネージャで、適切な Exchange サーバー オブジェクトを展開し、目的のストレージ グループを右クリックします。次に、[プロパティ] をクリックします。

  2. [全般] タブで、ファイルの新しい場所を指定します。

    たとえば、E:\ ドライブにこのストレージ グループ用のログ ファイルのみを格納する場合は、[トランザクション ログの場所] で [参照] をクリックし、E:\ ドライブを選択します。

Exchange Server 2007 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を変更するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループ ログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80702) の手順に従ってください (このサイトは英語の場合があります)。

Exchange 2000 Server または Exchange Server 2003 でデータベース ファイルを新しいドライブに移動するには、次の操作を行います。

  1. Exchange システム マネージャで、ストアが配置されている Exchange サーバー オブジェクトを展開し、適切なストレージ グループ コンテナを展開します。次に、目的のメールボックス ストア オブジェクトを右クリックし、[プロパティ] をクリックします。

  2. メールボックス ストア オブジェクトのプロパティ ダイアログ ボックスの [データベース] タブで、新しいファイルの場所を指定します。
注意 :
データベース ファイルを移動するには、データベースのマウントを一時的に解除し、その後再マウントする必要があります。これはウィザードによって自動的に行われますが、この処理中は、すべてのユーザーがそのデータベースにアクセスできなくなります。

Exchange Server 2007 でデータベース パスの移動ウィザードを使用してデータベース ファイルを新しいドライブに移動するには、次の操作を行います。

  1. ストレージ グループが格納されているサーバー上で Exchange 管理コンソールを起動します。

  2. コンソール ツリーで、[サーバーの構成] を展開し、[メールボックス] をクリックします。

  3. 結果ウィンドウで、対象のストレージ グループ コンテナを展開し、目的のメールボックス データベース オブジェクトを右クリックします。次に、[データベース パスの移動] をクリックします。データベース パスの移動ウィザードが表示されます。

  4. [概要] ページで、[データベース ファイルのパス] ボックスにデータベース ファイルが現在格納されている場所が表示されます。[参照] をクリックし、これらのファイルの移動先を指定します。

  5. [移動] をクリックします。

  6. [完了] ページで、データベース ファイルのパスが正しく変更されたことを確認します。状態が [完了] となっている場合は、ウィザードがタスクを正常に完了したことを示しています。状態が [失敗] となっている場合は、タスクが完了されなかったことを示しています。タスクが失敗した場合は、概要を確認した後、[戻る] をクリックし、構成の変更を行います。[終了] をクリックすると、データベース パスの移動ウィザードが終了します。
注 :
Exchange Server 2007 では、Exchange 管理シェルを使用してデータベース ファイルを移動することもできます。詳細については、Move- DatabasePath についてのページを参照してください (このサイトは英語の場合があります)。

Exchange Server データベース ファイルの詳細については、次のトピックを参照してください。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Mailbox Stores and Public Folder Stores」(このサイトは英語の場合があります)

  • 『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Understanding the Exchange Server 2003 Store」(このサイトは英語の場合があります)

Exchange Server データベース ファイルの管理の詳細については、Microsoft サポート技術情報の文書番号 328794「ハード ディスク障害から Exchange データを保護する方法。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328794) を参照してください。

Exchange データベース ストアのハード修復操作の詳細については、Microsoft サポート技術情報の文書番号 296788「Exchange のオフライン バックアップと復元処理」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296788) を参照してください。

Exchange データベース ストア ファイルのハード修復操作の実行に関する詳細については、Microsoft サポート技術情報の文書番号 810190「[XADM] "The Information Store Terminated Abnormally" というエラー メッセージが表示され、イベント ID 447 がログに出力される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810190) を参照してください。


データベースにすべてのログ ファイルが存在する
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、このデータベースの回復に必要なすべてのログ ファイルが存在し、回復を行うための正しい場所にあると判断しました。したがって、この回復エラーはトランザクション ログ ファイルの不足または不一致により発生したのではありません。

データベースまたはトランザクション ログ ファイルが破損しているか、または他のファイルが回復処理を妨げていると考えられます。

このエラーを修正するには

  • Exchange システム マネージャを使用してこのストレージ グループ内のデータベースのうちの 1 つをマウントし、アプリケーション ログを調べてエラーの原因を示す可能性のあるエラーがないかどうかを確認します。

  • データベースを個別に回復します。データベースの分析後に、Exchange Server アナライザによって、データベースを個別に回復するための手順が表示されます。

  • Eseutil.exe /ML を実行し、必須のログ ファイルの整合性を確認します。Eseutil の使用方法の詳細については、Microsoft サポート技術情報の文書番号 248122「Exchange 2000 Server と in exchange トランザクション ログをテストするために、Eseutil を使用するのが提出する方法、サーバー 2003 を破損します。(http://go.microsoft.com/fwlink/?linkid=3052&kbid=248122) を参照してください。


データベースがクリーン シャットダウン状態である
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange データベースがクリーン シャットダウン状態であるかどうかを判断します。

クリーン シャットダウン状態のデータベースは正常にシャットダウンされており、ログ ファイルのストリームから切断されています。したがって、データベースを再度マウントする場合に、回復操作を実行する必要がない場合があります。

クリーン シャットダウン状態のデータベースをマウントできない場合、データベースが追加のトランザクション ログ ファイルの再生を必要としていることが理由ではありません。ただし、同じストレージ グループの他のデータベースで必要なトランザクション ログの再生により、クリーン シャットダウン状態のデータベースがマウントできない可能性があります。Exchange ストレージ グループ内のデータベースをマウントする前に、ストレージ グループ内のすべてのデータベースを回復し、マウント可能な状態にする必要があります。

クリーン シャットダウン状態にあるデータベースは、以前のトランザクション ログまたは別のトランザクション ログのセットを使用してマウントすることができます。クリーン シャットダウン状態のデーベースをマウントするときにトランザクション ログが存在しない場合は、新しいトランザクション ログのセットが生成されます。

注 :
通常、ストレージ グループのすべてのデータベースがクリーン シャットダウン状態にある場合でも、既存のトランザクション ログ ファイルは削除しないでください。既存のトランザクション ログ ファイルを削除すると、以前のバックアップからロール フォワードできなくなります。ただし、ストレージ グループ内のすべてのデータベースがクリーン シャットダウン状態にあるときに、トランザクション ログ ファイルを削除しても、現在のデータベースには影響ありません。ベスト プラクティスとして、ストレージ グループのすべてのトランザクション ログ ファイルを削除する場合は、直ちにストレージ グループのすべてのデータベースを完全バックアップしてください。


データベースがダーティ シャットダウン状態になっているがログが要求されない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、データベースがダーティ シャットダウン状態になっていると判断しました。

定義によると、ダーティ シャットダウン状態のデータベースは、少なくとも 1 つのトランザクション ログ ファイルの再生を必要とします。ダーティ シャットダウンとは、データベースがマウントできない状態であり、通常の動作中には発生しません。

このエラーを修正するには

  • このデータベースおよびログ ファイルの高度な分析については、Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?linkid=3052&kbid=31845) にお問い合わせください。


データベースが不明な状態にある
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、データベースが不明な状態にあると判断しました。通常、データベースはクリーン シャットダウンまたはダーティ シャットダウン状態にあります (Exchange 2000 Server 以前では、これらの状態はそれぞれ "整合" および "不整合" と呼ばれます)。

このエラーを修正するには

  • データベースの状態の高度な分析については、Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?LinkId=31845) にお問い合わせください。


データベースにオプションのログ ファイルと必須のログ ファイルが存在しない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、このデータベースの回復に必要なログ ファイルが、ログ ファイル フォルダにないと判断しました。必須のログ ファイルがない場合、ログ ファイルが見つかるまでデータベースを回復することはできません。

Exchange データベースが正常にシャットダウンされなかった場合、データベースを再度マウントする前にデータベースに再生する必要があるログ ファイルが必ず存在します。再生が必要なログ ファイルは、少なくとも 1 つ存在します。ただし、通常は複数のログ ファイルが存在します。

必須のログ ファイル以外にも、データベースに再生できるログ ファイルが存在する場合があります。データベースをマウントする前にこれらのオプションのログ ファイルを必ずしも再生しなければならないわけではありませんが、これらのログ ファイルを使用すると、その他のデータも回復できます。これらのオプションのログ ファイルを再生しなかった場合は、これに含まれていたデータはすべて失われます。

このエラーを修正するには

  • 不足しているトランザクション ログ ファイルを検索し、適切なフォルダに追加します。

  • オプションのログ ファイルをすべて見つけられなかった場合は、必須のログ ファイルのみを使用してデータベースを回復できます。オプションのログ ファイルを使用しないでデータベースを回復するには、Exchange Server アナライザの指示に従います。オプションのログ ファイルを使用しないでデータベースを回復する場合、オプションのファイルに含まれていたデータは失われることに注意してください。

    ただし、どのログ ファイルが不足しているかにもよりますが、オプション ログ ファイルの一部をデータベースに再生できることがあります。たとえば、次のシナリオを考えてみてください。1 から 10 までの連番が付けられたログ ファイルがあるとします。10 番目のログ ファイルが必須で (残りのファイルはオプション)、6 番目のログ ファイルが見つからないとします。この場合、必須ファイルまで連番が続いているので、7 番目から 10 番目までのログ ファイルを再生することができます。

  • 現在のデータベースを修復します。

    注 :
    データベースの修復が成功する可能性は高いですが、保証はされません。修復に成功した場合でも、小さなまたは大きなデータの損失が発生する可能性があります。Exchange データベースの修復の詳細については、Microsoft サポート技術情報の文書番号 812357「[XADM] Eseutil /p ツールで修復した Exchange データベースの管理」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357) を参照してください。

  • データベースの修復と復元の両方を含む戦略を実装します。追加のログ ファイルを使用してロール フォワードできない場合でも、データベースを復元できることがあります。この場合、データベースの以前のコピーを復元すると同時に、マウントできない現在のデータベースのコピーを修復できます。続いて、データベースの内容を結合して、最大限のデータを復旧することができます。これは高度な戦略であるため、実装の前に Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?LinkId=31845) に問い合わせることをお勧めします。この戦略の詳細については、『Using Recovery Storage Groups in Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。


データベースにオプションのログ ファイルが存在しないが、必須のログ ファイルは存在する
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、データベースの 1 つが正常にシャットダウンされていないと判断しました。

Exchange データベースが正常にシャットダウンされなかった場合、データベースを再度マウントする前にデータベースに再生する必要があるログ ファイルが必ず存在します。再生が必要なログ ファイルは、少なくとも 1 つ存在します。ただし、通常は複数のログ ファイルが存在します。

必須のログ ファイル以外にも、データベースに再生できるログ ファイルが存在する場合があります。データベースをマウントする前にこれらのオプションのログ ファイルを再生する必要があるわけではありませんが、これらのログ ファイルを使用すると、その他のデータも回復できます。これらのオプションのログ ファイルを再生しなかった場合は、これに含まれていたデータはすべて失われます。

このエラーを修正するには

  • 不足しているオプションのログ ファイルを検索し、適切なトランザクション ログ フォルダにコピーします。

  • オプションのログ ファイルをすべて見つけられなかった場合は、必須のログ ファイルのみを使用してデータベースを回復できます。オプションのログ ファイルを使用しないでデータベースを回復するには、Exchange Server アナライザの指示に従います。オプションのログ ファイルを使用しないでデータベースを回復する場合、オプションのファイルに含まれていたデータは失われることに注意してください。

    ただし、どのログ ファイルが不足しているかにもよりますが、オプション ログ ファイルの一部をデータベースに再生できることがあります。たとえば、次のシナリオを考えてみてください。1 から 10 までの連番が付けられたログ ファイルがあるとします。10 番目のログ ファイルが必須で (残りのファイルはオプション)、6 番目のログ ファイルが見つからないとします。この場合、必須ファイルまで連番が続いているので、7 番目から 10 番目までのログ ファイルを再生することができます。


データベースに必要なログ ファイルが見つからない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、このデータベースの回復に必要なログ ファイルが、ログ ファイル フォルダに見つからないと判断しました。必要なログ ファイルがない場合、ログ ファイルが見つかるまでデータベースを回復することができません。

このエラーを修正するには

  • 見つからないトランザクション ログ ファイルを検索し、適切なフォルダに追加します。

  • バックアップからデータベースを復元します。次に、残っているトランザクション ログ ファイルをデータベースに再生して、データベースをロール フォワードします。

    重要 :
    見つからないログ ファイルおよび以降のログ ファイルのデータは失われます。バックアップからデータベースを復元する前に、現在のデータベースのコピーを保存する必要があります。復元に失敗した場合、現在のデータベースを修復できる場合があります。

  • 現在のデータベースを修復します。

    注 :
    データベースの修復が成功する可能性は高いですが、保証はされません。修復に成功した場合でも、大小のデータ損失が発生する可能性があります。Exchange データベースを修復する方法の詳細については、Microsoft サポート技術情報の文書番号 812357「[XADM] Eseutil /p ツールで修復した Exchange データベースの管理」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357) を参照してください。

  • データベースの修復と復元の両方を含む戦略を実装します。しかし、追加のログ ファイルを使用してロール フォワードできない場合でも、データベースを復元できる場合もあります。これらの場合、以前のデータベースのコピーを復元すると同時に、マウントできない現在のデータベースのコピーを修復できます。続いて、データベースの内容を結合して、最大限のデータを回収することができます。これは高度な戦略であるため、実装の前に Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?LinkId=31845) に問い合わせることをお勧めします。この戦略の詳細については、『Using Recovery Storage Groups in Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。


ストレージ グループのデータベースがバックアップ中にゼロ ページに設定されない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバーの各ストレージ グループについて msExchESEParamZeroDatabaseDuringBackup 属性の値を判断します。msExchESEParamZeroDatabaseDuringBackup 属性が 1 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchESEParamZeroDatabaseDuringBackup 属性は、削除されたレコードや長い値をバックアップ時にゼロで上書きできるようにする構成設定を表しています。これは、"領域の解放" と呼ばれる処理です。データベース ページの領域の解放は、ストレージ グループ レベルで制御できます。ストレージ グループごとに、削除されたデータベース ページの領域の解放についてのポリシーがあります。

既定では領域の解放は無効になっており、msExchESEParamZeroDatabaseDuringBackup 属性の値は 0 に設定されています。この属性が 1 に設定されている場合、削除されたデータベース ページは、そのストレージ グループに属するデータベースのオンライン バックアップの最後に他の文字で上書きされます。

Exchange 2000 Server および Exchange Server 2003 における領域の解放の有効化と無効化は、この文書で説明する方法で、Exchange システム マネージャを使用して実行できます。Exchange Server 2007 における領域の解放の有効化と無効化は、この文書で説明する方法で、Exchange 管理シェルを使用して実行できます。このオプションを使用すると、よりセキュリティが高まりますが、サーバーのパフォーマンスに影響があります。

注 Exchange 2000 Server コンピュータで領域の解放を有効にする場合は、Exchange 2000 Server Service Pack 3 以降のバージョンをインストールすることをお勧めします。Service Pack 3 では、Exchange Information Store の応答の停止を引き起こす既知の問題点が修正されています。この問題点の詳細については、Microsoft サポート技術情報の文書番号 320883「XADM: The Information Store Stops Responding During an Online Backup If Database Zeroing Is Turned On」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=320883) を参照してください (このサイトは英語の場合があります)。

Exchange 2000 Server および Exchange Server 2003 で領域の解放を有効または無効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、変更するサーバーを展開します。

  3. 変更するストレージ グループを右クリックし、[プロパティ] をクリックします。

  4. プロパティのダイアログ ボックスで、必要に応じて [削除されたデータベース ページの領域を解放する] チェック ボックスをオンまたはオフにします。チェック ボックスをオンにすると領域の解放が有効になり、チェック ボックスをオフにすると領域の解放が無効になります。

  5. [OK] をクリックして設定を保存します。

  6. Exchange システム マネージャを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

Exchange Server 2007 で削除されたページの領域の解放を有効または無効にするには、次の操作を行います。

  1. 次のコードは、ストレージ グループ 'MyStorageGroup' にあるデータベースの領域の解放を有効または無効にする Set-StorageGroup コマンドの例を示しています。
コードのコピー
Set-StorageGroup -Identity MyStorageGroup -ZeroDatabasePages
 $false
Set-StorageGroup -Identity MyStorageGroup -ZeroDatabasePages
 $true

削除されたデータベース ページの上書きによるパフォーマンスへの影響については、Microsoft サポート技術情報の文書番号 815068「[XADM] オンライン バックアップのパフォーマンスが、回数を重ねるごとに低下する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815068) を参照してください。


Debug Break At Startup が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Information Store に対してデバッグが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Debug Break At Startup

Debug Break At Startup に値が設定されていることが検出されると、警告が表示されます。

Debug Break At Startup レジストリ値は、Microsoft Exchange Information Store サービスが次に開始されたときにデバッグ モードを有効にします。Microsoft Exchange Information Store は、デバッグ モードで実行されると大量のリソースを使用します。ベスト プラクティスとして、運用環境ではストアをデバッグしないようにすることをお勧めします。

Microsoft 製品サポート サービスの支援を受けてストアの問題のトラブルシューティングを行うことが多い場合を除き、Debug Break At Startup レジストリ値は削除してください。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Debug Break At Startup レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、Debug Break At Startup 値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


既定の ESE ログ バッファが変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービス内で、Exchange Server コンピュータ上の各ストレージ グループの msExchESEParamLogBuffers 属性値を検索します。msExchESEParamLogBuffers の値が 512 であることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchESEParamLogBuffers ストレージ グループ属性は、Exchange Information Store が使用する ESE (Extensible Storage Engine) ログ バッファの数を制御します。ESE は、一連のログ バッファを使用して情報を RAM に保持しておいてから、トランザクション ログにまとめて書き込みます。このバッファを使用すると、トランザクション ログ出力のパフォーマンスが向上します。大規模なサーバーの場合、既定値の 84 では低すぎます。この設定にすると、トランザクション ログ ドライブへのディスク I/O 処理が過度に発生する場合があります。したがって、サーバーに負荷がかかった場合、またはユーザーがサイズの大きなメッセージを送信した場合には、パフォーマンスが大幅に低下する可能性があります。ESE ログ バッファの数を増やすと、パフォーマンスは向上しますが、仮想メモリの使用量も増加します。

この値を正しく設定するには、以下の情報を参照してください。

  • Exchange 2000 Server、Exchange 2000 Server Service Pack 1 (SP1)、または Exchange 2000 Server Service Pack 2 (SP2) の場合は、この値を 9,000 に設定します。

  • Exchange 2000 Server Service Pack 3 (SP3) の場合は、この値を 512 に設定します。

  • Exchange Server 2003 の場合、既定値 500 が使用されていますが、msExchESEParamLogBuffers 属性値を 9000 に変更する必要があります。

注 :
既にログ バッファ数が 9,000 に設定されている場合は、Exchange 2000 Server SP3 の適用後、必ずこの値を手動で小さくしてください。ログ バッファ数の変更は、Exchange 2000 Server SP3 のインストール時に自動的に行われません。

ログのストールは、バッファが小さすぎることが原因で発生する場合があります。この値は 9,000 まで上げられます。Database\Log Record Stalls/sec パフォーマンス カウンタを監視することにより、ログのストールが発生しているかどうかを判断できます。トランザクション ログ ファイルが破損することがあるので、9,000 を超える値は指定しないでください。

注 :
Log Record Stalls/sec は、ログ バッファがいっぱいになっているためにこのバッファに追加できないログ レコードの 1 秒あたりの数です。このカウンタがほぼ常に 0 以外になっている場合は、ログ バッファ サイズがボトルネックになっていることがあります。

この値を修正するには、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、または他の任意のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

既定の構成に戻すには

  1. ADSI Edit を起動します。

  2. Configuration コンテナをダブルクリックし、[CN=Services] を展開します。次に、[CN=Microsoft Exchange] を展開して [CN=<Exchange 組織名>] を展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を展開して [CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  5. Attribute Editor で、[msExchESEParamLogBuffers] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] ボックスの値を、Exchange 2000 Server では 512 に、Exchange Server 2003 では 9000 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

ESE ログ バッファの詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、 Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466) を参照してください。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server ヘルプのトピック「Adsiedit.msc: ADSI Edit」 を参照してください (このページは英語の場合があります)。


既定のパブリック フォルダ ストアがリモートである
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-03

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストアの msExchHomePublicMDB 属性にローカル Exchange Server が含まれているかどうかを判断します。既定では、メールボックス ストアのパブリック フォルダ ストアはローカル Exchange Server 上に存在します。msExchHomePublicMDB 属性にローカル Exchange Server が含まれていない場合、メールボックス ストアにはリモートの既定のパブリック フォルダ ストアが存在します。Exchange Server アナライザによって、メールボックス ストアにリモートの既定のパブリック フォルダ ストアが存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定のパブリック フォルダ ストアを変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、[<使用している Exchange サーバー>]を展開します。次に、[<ストレージ グループ>] を展開し、メールボックスを右クリックして、[プロパティ] を選択します。

  2. [全般] タブの [既定のパブリック ストア] で、[参照] をクリックしてパブリック フォルダ ストアを選択します。

メールボックス ストアおよびパブリック フォルダ ストアの詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Mailbox Stores and Public Folder Stores」を参照してください (このサイトは英語の場合があります)。


メールボックス ストアの Deletion Thread Period が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、削除済みのアイテムを削除する間隔が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>\Deletion Thread Period

Deletion Thread Period キーが存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

メッセージが削除されると、Exchange はメッセージに削除のためのマークを付けます。また、Exchange ストアから完全に削除されるまで、メッセージには非表示のマークが付けられます。Exchange ストアは、メッセージ ID によって参照される特定のフォルダにあるメッセージを削除する要求を受信すると、メッセージを回復可能として削除するか、完全に削除するかを判断します。削除済みアイテムの保存期間が経過している場合、メッセージは完全に削除されます。回復可能な削除は、論理的な削除とも呼ばれます。また、完全な削除は物理的な削除とも呼ばれます。

既定では、削除済みアイテムの格納場所のクリーンアップ処理が 24 時間ごとに実行され、アイテムの完全削除を実行する時期であるかどうかが判断されます。削除済みアイテムの格納場所のクリーンアップ処理は、Exchange ストアのオンライン保守プロセスの一部として実行されます。削除済みアイテムの保存期間が経過している場合、アイテムは完全に削除されます。Deletion Thread Period レジストリ値は、既定の 24 時間の間隔を変更し、削除済みアイテムの格納場所のクリーンアップ処理の間隔を独自に指定するために使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Deletion Thread Period キーを削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

削除済みアイテムの保存と回復の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 249680「[XADM] 削除済みアイテムの保存期間およびメッセージ削除処理について」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=249680)

  • 文書番号 287544「XADM: パブリック インフォメーション ストアは、いつ削除された項目保有機能が有効の拡張を大幅に行います。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=287544)

  • 文書番号 822938「[HOWTO] Exchange Server 2003 でシステム ポリシーを使用してメールボックス格納域の制限を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822938)


パブリック フォルダ ストアの Deletion Thread Period が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、削除済みのアイテムを削除する間隔が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\Deletion Thread Period

Deletion Thread Period キーが存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

メッセージを削除すると、Exchange によってメッセージに削除のマークが付けられます。Exchange はさらに、メッセージが Exchange ストアから完全に削除されるまでメッセージを非表示としてマークします。インフォメーション ストアが、メッセージ ID によって参照されている特定のフォルダ内のメッセージを削除する要求を受け取った場合、Exchange ストアは、そのメッセージに対して回復可能な削除または回復不可能な削除のどちらを行うかを判断します。回復可能な削除は「論理的な削除」とも呼ばれ、また、回復不可能な削除は「物理的な削除」とも呼ばれます。メッセージは、その削除済みアイテムの保存期間が経過すると完全に削除されます。

既定では、アイテムに対して回復不可能な削除を行う時期になったかどうかを判断する、削除済みアイテムの格納場所のクリーンアップ プロセスが 24 時間ごとに実行されます。削除済みアイテムの格納場所のクリーンアップ プロセスは、Exchange ストアのオンライン保守プロセスの一部です。削除済みアイテムの保存期間が経過すると、アイテムに対して回復不可能な削除が行われます。Deletion Thread Period レジストリ値は、既定の 24 時間の間隔を上書きして、削除済みアイテムの格納場所のクリーンアップ プロセスのカスタムの間隔を指定するために使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. Deletion Thread Period キーを削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

削除済みアイテムの保存と回復の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 249680「XADM: 理解は、項目保有とメッセージ削除プロセスを削除しました。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=249680)

  • 文書番号 287544「XADM: パブリック インフォメーション ストアによって削除された項目保有機能が有効な場合、大幅に拡張されます。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=287544)

  • 文書番号 319098「HOW TO: Exchange 2000 Server でパブリック フォルダ格納域の制限を構成するために、システム ポリシーを使用します。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319098)


ディスクのボトルネックが検出された
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-11-14

Microsoft® Exchange Server アナライザ ツールによって、現在、ディスク システムが予期される最大可能スループットの 20% 以内で実行されていることが検出されました。この判断は、以下のいずれかの計算によって行われます。

  • ディスクの待ち時間の測定。待ち時間を示すパフォーマンス カウンタは、LogicalDisk\Avg. Disk sec/Read および LogicalDisk\Avg. Disk sec/Write です。

  • 現在のディスク構成およびスピンドル数から最大可能な 1 秒あたりのディスク入出力 (IOPS) とパフォーマンス モニタ (Perfmon) によって記録された現在の IOPS 値との比較。

許容可能な待ち時間

アクセスされているデータの種類に応じて、遅延に対する Exchange サーバーの許容範囲は異なります。このため、最大の許容可能な平均待ち時間しきい値は、ディスク上にあるリソースの種類に基づいて与えられます。次の一覧に示されている場合を除くすべてのケースにおいて、読み取りまたは書き込みの待ち時間に対する最大許容値は 50 ミリ秒です。

  • トランザクション ログ ドライブ トランザクション ログをホストするドライブの平均書き込み待ち時間は 10 ミリ秒未満にする必要があります。書き込み待ち時間のスパイクは 50 ミリ秒未満にする必要があります。トランザクション ログへの書き込みは同期です。つまり、Store.exe プロセスでスレッドが別のタスクを実行できるようになるには、スレッドは書き込みが完了するのを待つ必要があります。トランザクション ログの書き込み待ち時間を短くすることは、サーバーのパフォーマンスにとって重要です。トランザクション ログ ドライブに対する平均読み取り待ち時間は 20 ミリ秒未満にする必要があります。読み取り待ち時間のスパイクは 50 ミリ秒未満にする必要があります。1 秒あたりの Database Log Record Stalls は 10 未満にする必要があります。Database Log Threads Waiting は 10 未満にする必要があります。

    通常、Exchange サーバーはトランザクション ログから読み取りません。したがって、そのドライブに対する読み取り待ち時間は問題にはなりません。ただし、トランザクション ログの書き込み待ち時間は Exchange のパフォーマンスにとって非常に重要であるため、大規模なサーバーでは、その他の目的のためのトランザクション ログをホストするドライブを使用しないようにすることをお勧めします。この場合、LogicalDisk\Disk Reads/sec で測定される読み取り速度は、LogicalDisk\Disk Writes/sec の書き込み速度と比較すると最小である必要があります。Exchange Server アナライザは、トランザクション ログ ドライブで書き込みに対する読み取りの比率が 0.10 より大きい (10 の書き込みに対して読み込みが 1 を超える) かどうかを検出します。

    すべての書き込みに対して 0.10 を超える読み取りが存在する場合は、トランザクション ログ ドライブから読み取りを行っているアプリケーションを識別し、この動作が発生しないようにする必要があります。

  • データベース ドライブ Exchange データベース ファイル (*edb ファイルおよび *stm ファイル) を含むドライブの許容可能な待ち時間は次のとおりです。以下の値より高い値はディスクのボトルネックを示します。

    • データベース ドライブでの Logical Disk\Avg. Disk sec/Read の最大値は、50 ms. (0.050 秒) 未満にする必要があります。

    • データベース ドライブでの Logical Disk\Avg. Disk sec/Read の平均値は、20 ミリ秒 (0.020 秒) 未満にする必要があります。

  • TEMP ドライブおよび TMP ドライブ TEMP ディレクトリおよび TMP ディレクトリを含むドライブの待ち時間は、読み取りおよび書き込み共に 10 ミリ秒未満にする必要があります。読み取りまたは書き込み待ち時間の最大値は 50 ミリ秒未満にする必要があります。

  • ページおよびシステム ドライブ ページ ファイルおよび Windows システム ファイルを含むドライブの待ち時間は、読み取りおよび書き込み共に 10 ミリ秒未満にする必要があります。

  • SMTP ドライブ SMTP サーバー ファイルを含むドライブの待ち時間は、読み取りおよび書き込みの待ち時間を 10 ミリ秒未満にする必要があります。

待ち時間の原因

ディスク サブシステムがサポート可能な速度よりも高速でアクセスされるディスクは、ディスクの待ち時間の最も一般的な原因の 1 つです。この場合、ディスクはボトルネックであると見なされます。また、ディスク サブシステムがスループット処理能力の上限に達している、または上限を超えていることを意味します。

ディスク IOPS の速度 (LogicalDisk\Disk Transfers/sec) が予測される処理能力に近い、またはそれを超えている場合、ディスクは "スループット処理能力を超えた" または "処理能力を超えた" ものと見なされます。これらの場合、サーバー パフォーマンスを向上させるには、(ユーザーを別のサーバーに移動して) ディスク サブシステムの負荷を減らす、または (より多くの、またはより速いスピンドルを追加して) ドライブの容量を増やす必要があります。

ハードウェアが予期されるとおりに実行されていない場合、入出力速度が予測される処理能力を大幅に下回っている場合でも待ち時間が発生することがあります。

ディスクの待ち時間の削減

ディスク サブシステム上の負荷を減らすには、サーバーによって実行される一部のタスクを減らすことができます。具体的には、ディスク負荷の原因となるオプションのアプリケーションを削除する必要があります。Store.exe プロセスは、データベースおよびトランザクション ログ ドライブにアクセスする必要がある唯一のアプリケーションです。

現在のディスク システム構成に応じて、複数の動作を実行し、この問題の影響を減らすことができます。

ディスクの待ち時間を減らすには

  • データベースまたはトランザクション ログ ドライブでボトルネックが発生した場合は、最大容量に近づいていないドライブにホストされているデータベースまたはストレージ グループにユーザーを移動し、そのドライブの負荷を小さくすることができます。すべてのデータベースまたはトランザクション ログ ドライブが容量に近づいているときは、ユーザーを別のサーバーに移動する必要がある場合があります。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

  • 過剰な MAPI 操作が原因のため、入出力速度が高い期間が短いことがあります。その場合、高い入出力速度の原因となっているユーザーまたは動作を判断するには、Exchange Server User Monitor (ExMon) ツールを論理ディスク パフォーマンス カウンタと組み合わせて使用できます。ユーザーを分離できる場合は、より大きい負荷を生成しているクライアント アプリケーションを識別できる可能性があります。ExMon は Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=54983) からダウンロードできます (このサイトは英語の場合があります)。

  • RAID-5 ディスク アレイを実行している場合は、RAID-10 ディスク アレイに変更して、ディスク サブシステムに対してサポートされる IOPS を向上させることができます。

  • サポートされる IOPS を向上させるには、ディスク サブシステムにディスクを追加することを検討します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 パフォーマンスとスケーラビリティ ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、Microsoft Exchange Server 2003 パフォーマンスのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=72988) を参照してください。

  • ユーザーのメールボックスを移動してサーバーの負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。

  • ディスクのサイズの変更、待ち時間、および入出力速度の詳細については、Microsoft Exchange Team Blog の Web サイトにある以下のページを参照してください。

    • ディスク サイズの基本概念についてのページ (http://go.microsoft.com/fwlink/?linkid=39538) (このサイトは英語の場合があります)

    • ディスク IO と計算に関する詳細な考慮事項についてのページ (http://go.microsoft.com/fwlink/?linkid=39539) (英語)

    • ディスク I/O 要件の計算方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=69747)


トランザクション ログ ファイルを含むディスクでディスクのボトルネックを見つけた
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange Server ログ ファイルを保持するディスク システムに過度の負担がかかり、パフォーマンスのボトルネックが発生していると判断しました。この判断は、以下のパフォーマンス カウンタを 1 つ以上確認することで実行されます。

  • 平均の Database\Log Record Stalls/sec が 10 より大きい。

  • 最大の Database\Log Record Stalls/sec が 100 より大きい。

  • 平均の Database\Log Threads Waiting が 1 より大きい。

  • 最大の Database\Log Threads Waiting が 20 より大きい。

これらのしきい値のいずれかを満たす場合、使用しているログ ドライブがディスクのボトルネックであることを示すエラーが表示されます。ログ ファイルは、短い書き込みの待ち時間を必要とします。ログ ファイルへの書き込みでのバックアップまたはストールは、サーバー パフォーマンスの問題を引き起こす可能性があります。ログのストールは、ログ バッファの設定 msExchESEParamLogBuffers が低い、またはサーバーに接続しているユーザーの数が多すぎるために発生する場合があります。

ログ ディスクの待ち時間を減らすには

  • ESE バッファ パラメータ msExchESEParamLogBuffers を 9,000 に上げることができます。トランザクション ログ ファイルが破損することがあるので、9,000 を超える値は使用しないでください。詳細については、「既定の ESE ログ バッファが変更されている」を参照してください。

  • データベースまたはトランザクション ログ ドライブでボトルネックが発生した場合は、最大容量に近づいていないドライブにホストされているデータベースまたはストレージ グループにユーザーを移動し、そのドライブの負荷を小さくすることができます。すべてのデータベースまたはトランザクション ログ ドライブが容量に近づいているときは、ユーザーを別のサーバーに移動する必要がある場合があります。詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


EnableChangeNotification が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、ExIFS (Exchange Installable File System) のファイル変更通知が有効であるかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIFS\Parameters\ EnableChangeNotification

EnableChangeNotification キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、ExIFS のファイル変更通知は無効になっています。ExIFS は、ファイルまたはディレクトリの変更通知を送信するときに、キャッシュされたファイルまたはディレクトリをクリアしません。その結果、Exchange Server や Microsoft SharePoint® Portal Server などのアプリケーションが変更通知を受信し、ファイルまたはディレクトリを再度読み込むときに、アプリケーションは変更されたファイルまたはディレクトリではなく、キャッシュされたファイルやディレクトリを取得します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\EXIFS\Parameters

  3. EnableChangeNotification キーを削除します。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Installable File System の詳細については、以下の文書を参照してください。

  • 『Exchange 2000 Server Resource Kit』の「Chapter 26 - Exchange 2000 Architecture」(http://go.microsoft.com/fwlink/?LinkId=51224) (このサイトは英語の場合があります)

  • 『Technical Reference Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47891) (このサイトは英語の場合があります)


ログ ディレクトリへのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、その Exchange サーバーで定義されているこのストレージ グループのトランザクション ログのパスにアクセスできない状態になっていると判断しました。

このエラーを修正するには

  • そのパスが実際にサーバーに存在することを確認します。

  • トランザクション ログのパスに格納されたファイルの読み取りに必要なアクセス許可があることを確認します。


ストリーミング データベース ファイルへのアクセス時のエラー
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange ストリーミング データベース (.stm) ファイルにアクセスできないと判断しました。

Exchange 2000 Server と Exchange Server 2003 の個々のデータベースは, .edb Exchange データベース ファイルと .stm ストリーミング データベース ファイルの 2つのファイルで構成されます。これらのファイルは、同時にアクセスおよび処理する必要があります。

このエラーを修正するには

  • .stm ファイルのパスを確認します。このパスは、Exchange システム マネージャの各データベース オブジェクトのデータベース プロパティ ページで定義されています。

  • このデータベースの .stm ファイルが存在することを確認します。

  • .stm ファイルがあるフォルダにアクセスするためのアクセス許可があることを確認します。

  • 別のプロセスによって、ファイルが排他的にロックされていないことを確認します。これを確認する 1 つの方法のとして、ファイル名を変更してみます。ファイルの名前を正しく変更できる場合は、ファイルは排他的にロックされていないことを示します。ファイル名を元のファイル名に戻すことを忘れないようにしてください。


ログ ファイルのエラー チェック
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、トランザクション ログ ファイルを読み取ることができませんでした。

このエラーを修正するには

  • トランザクション ログ ファイルのフォルダにアクセスするために必要なアクセス許可があることを確認します。

  • ファイルが別のプロセスによって排他的にロックされていないことを確認します。これを確認する 1 つの方法として、ファイルの名前を変更してみます。ファイルの名前を正しく変更できる場合は、ファイルは排他的にロックされていないことを示します。ファイル名を元のファイル名に戻すことを忘れないようにしてください。


ストレージ グループに対する ESE ログ バッファの設定が最大数になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループについて msExchESEParamLogBuffers 属性値を判断します。msExchESEParamLogBuffers 属性の値が 9,000 であることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ESE (Extensible Storage Engine) は、一連のログ バッファを使用して情報を RAM に保持しておいてから、トランザクション ログにまとめて書き込みます。このバッファを使用すると、トランザクション ログ出力のパフォーマンスが向上します。大規模なサーバーの場合、既定値の 84 では低すぎます。この設定にすると、トランザクション ログ ドライブへのディスク I/O 処理が過度に発生する場合があります。したがって、サーバーに負荷がかかった場合、またはユーザーがサイズの大きなメッセージを送信した場合には、パフォーマンスが大幅に低下する可能性があります。ESE ログ バッファの数を増やすと、パフォーマンスは向上しますが、仮想メモリの使用量も増加します。

この値を正しく設定するには、以下の情報を参照してください。

  • Exchange 2000 Server、Exchange 2000 Server Service Pack 1 (SP1)、または Exchange 2000 Server Service Pack 2 (SP2) の場合は、この値を 9,000 に設定します。

  • Exchange 2000 Server Service Pack 3 (SP3) の場合は、この値を 512 に設定します。

  • Exchange Server 2003 の場合、既定値 500 が使用されていますが、msExchESEParamLogBuffers 属性値を 9000 に変更する必要があります。

注 :
既にログ バッファ数が 9,000 に設定されている場合は、Exchange 2000 Server SP3 の適用後、必ずこの値を手動で小さくしてください。ログ バッファ数の変更は、Exchange 2000 Server SP3 のインストール時に自動的に行われません。

ログのストールは、バッファが小さすぎることが原因で発生する場合があります。この値は 9000 まで上げられます。Database\Log Record Stalls/sec パフォーマンス カウンタを監視することにより、ログのストールが発生しているかどうかを判断できます。トランザクション ログ ファイルが破損することがあるので、9000 を超える値は指定しないでください。

注 :
Log Record Stalls/sec は、ログ バッファがいっぱいになっているためにこのバッファに追加できないログ レコードの 1 秒あたりの数です。このカウンタがほぼ常に 0 以外になっている場合は、ログ バッファ サイズがボトルネックになっていることがあります。

この値を修正するには、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、または他の任意のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

既定の構成に戻すには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services] を展開します。次に、[CN=Microsoft Exchange] を展開し、[CN=<Exchange 組織名>] を展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を展開して [CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  5. Attribute Editor で、[msExchESEParamLogBuffers] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] ボックスの値を、Exchange 2000 Server では 512 に、Exchange Server 2003 では 9000 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

ESE ログ バッファの設定の詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファと、 Microsoft Exchange Information Store サービスが応答を停止するのが発生します。」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466) を参照してください。


ストレージ グループに対する ESE ログ バッファの設定が低すぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、InformationStore コンテナ内の各ストレージ グループ オブジェクト (msExchStorageGroup クラス) の msExchESEParamLogBuffers 値を判断します。この属性値が 500 未満であることが検出されると、警告が表示されます。

ESE (Extensible Storage Engine) は、一連のログ バッファを使用して情報を RAM に保持しておいてから、トランザクション ログにまとめて書き込みます。このバッファを使用すると、トランザクション ログ出力のパフォーマンスが向上します。大規模なサーバーの場合、既定値の 84 では低すぎます。この設定にすると、トランザクション ログ ドライブへのディスク I/O 処理が過度に発生する場合があります。したがって、サーバーに負荷がかかった場合、またはユーザーが大容量メッセージを送信した場合には、パフォーマンスが大幅に低下する可能性があります。ESE ログ バッファの数を増やすと、パフォーマンスは向上しますが、仮想メモリの使用量も増加します。

この値を正しく設定するには、以下の情報を参照してください。

  • Exchange 2000 Server、Exchange 2000 Server Service Pack 1 (SP1)、または Exchange 2000 Server Service Pack 2 (SP2) の場合は、この値を 9,000 に設定します。

  • Exchange 2000 Server Service Pack 3 (SP3) の場合は、この値を 512 に設定します。

  • Exchange Server 2003 の場合、既定値 500 が使用されていますが、msExchESEParamLogBuffers 属性値を 9000 に変更する必要があります。

注 :
既にログ バッファ数が 9,000 に設定されている場合は、Exchange 2000 Server SP3 の適用後、必ずこの値を手動で小さくしてください。ログ バッファ数の変更は、Exchange 2000 Server SP3 のインストール時に自動的に行われません。

ログのストールは、バッファが小さすぎることが原因で発生する場合があります。この値は 9,000 まで上げられます。Database\Log Record Stalls/sec パフォーマンス カウンタを監視することにより、ログのストールが発生しているかどうかを判断できます。トランザクション ログ ファイルが破損することがあるので、9000 を超える値は指定しないでください。

注 :
Log Record Stalls/sec は、ログ バッファがいっぱいになっているためにこのバッファに追加できないログ レコードの 1 秒あたりの数です。このカウンタがほぼ常に 0 以外になっている場合は、ログ バッファ サイズがボトルネックになっていることがあります。

この値を修正するには、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、または他の任意のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

この警告を修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services] を展開します。次に、[CN=Microsoft Exchange] を展開し、[CN=<Exchange 組織名>] を展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を展開して [CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  5. Attribute Editor で、[msExchESEParamLogBuffers] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] ボックスの値を、Exchange 2000 Server では 512 に、Exchange Server 2003 では 9000 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

ESE ログ バッファの詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、 Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466) を参照してください。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ESE ログ バッファの設定の詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466) を参照してください。

ADSI Edit の操作の詳細については、Windows Server ヘルプのトピック「Adsiedit.msc: ADSI Edit」 を参照してください (このページは英語の場合があります)。


ストレージ グループに設定されている ESE ログ バッファの設定が高すぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループについて msExchESEParamLogBuffers 属性の値を判断します。いずれかのストレージ グループについて msExchESEParamLogBuffers 属性の値が 9,000 を超えていることが検出されると、エラーが表示されます。

ESE (Extensible Storage Engine) は、一連のログ バッファを使用して情報を RAM に保持しておいてから、トランザクション ログにまとめて書き込みます。このバッファを使用すると、トランザクション ログ出力のパフォーマンスが向上します。大規模なサーバーの場合、既定値の 84 では低すぎます。この設定にすると、トランザクション ログ ドライブへのディスク I/O 処理が過度に発生する場合があります。したがって、サーバーに負荷がかかった場合、またはユーザーがサイズの大きなメッセージを送信した場合には、パフォーマンスが大幅に低下する可能性があります。ESE ログ バッファの数を増やすと、パフォーマンスは向上しますが、仮想メモリの使用量も増加します。

この値を正しく設定するには、以下の情報を参照してください。

  • Exchange 2000 Server、Exchange 2000 Server Service Pack 1 (SP1)、または Exchange 2000 Server Service Pack 2 (SP2) の場合は、この値を 9,000 に設定します。

  • Exchange 2000 Server Service Pack 3 (SP3) の場合は、この値を 512 に設定します。

  • Exchange Server 2003 の場合、既定値 500 が使用されていますが、msExchESEParamLogBuffers 属性値を 9000 に変更する必要があります。

注 :
既にログ バッファ数が 9,000 に設定されている場合は、Exchange 2000 Server SP3 の適用後、必ずこの値を手動で小さくしてください。ログ バッファ数の変更は、Exchange 2000 Server SP3 のインストール時に自動的に行われません。

ログのストールは、バッファが小さすぎることが原因で発生する場合があります。この値は 9,000 まで上げられます。Database\Log Record Stalls/sec パフォーマンス カウンタを監視することにより、ログのストールが発生しているかどうかを判断できます。トランザクション ログ ファイルが破損することがあるので、9,000 を超える値は指定しないでください。

注 :
Log Record Stalls/sec は、ログ バッファがいっぱいになっているためにこのバッファに追加できないログ レコードの 1 秒あたりの数です。このカウンタがほぼ常に 0 以外になっている場合は、ログ バッファ サイズがボトルネックになっていることがあります。

この値を修正するには、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、または他の任意のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのツールを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services] を展開します。次に、[CN=Microsoft Exchange] を展開し、[CN=<Exchange 組織名>] を展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を展開して [CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  5. Attribute Editor で、[msExchESEParamLogBuffers] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] ボックスの値を、Exchange 2000 Server では 512 に、Exchange Server 2003 では 9000 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ESE ログ バッファの設定の詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=328466) を参照してください。


ESE ログのファイル サイズが手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、InformationStore コンテナの msExchESEParamLogFileSize 属性の値を判断します。msExchESEParamLogFileSize 属性の値が 5120 に等しくないことが検出されると、エラーが表示されます。

この値は、サーバー上のすべてのストレージ グループに適用されます。この特定のエラーは、この属性の値が既定値 (5,120 KB つまり 5 MB) から変更されている場合に発生します。これがサポートされている唯一の値であり、変更することはできません。

この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、その他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどのユーティリティを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動し、Active Directory 内にあるこの Exchange Server コンピュータ用の InformationStore オブジェクトを見つけます。

    msExchESEParamLogFileSize 属性は次の場所にあります。

    CN=Configuration, DC=ドメイン名, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Administrative Groups, CN=管理グループ名, CN=Servers, CN=サーバー名, CN=InformationStore

  2. [msExchESEParamLogFileSize] 属性をダブルクリックし、その値を 5,120 に設定します。

  3. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

LDP.exe を使用して Active Directory の属性を編集する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

ADSI Edit の操作の詳細については、Windows Server ヘルプのトピック「Adsiedit.msc: ADSI Edit」 を参照してください (このページは英語の場合があります)。


ESE の最大オープン テーブルがハードコードされている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server オブジェクトの InformationStore オブジェクトの下にあるストレージ グループ オブジェクトのいずれかに msExchESEParamMaxOpenTables 属性が存在するかどうかを判断します。msExchESEParamMaxOpenTables 属性が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Exchange 2000 Server および Exchange Server 2003 にはこの属性が存在しますが、値は設定されていません。Exchange Server は、現在アクセスされていないフォルダに関するデータをキャッシュします。場合によっては、これにより仮想メモリが断片化されることがあります。この問題の緩和策の 1 つに、同時に開くことができるデータベース テーブルの最大数を減らす方法があります。このために推奨される実際の値は、Exchange Server のバージョンと、インストールされている Exchange Service Pack に応じて異なります。Exchange 2000 Server Service Pack 2 では、8 プロセッサ サーバーに対する既定の設定はストレージ グループあたり 85,000 テーブルです。Exchange 2000 Server Service Pack 3 では、8 プロセッサ サーバーに対するこの値が 27,600 に減ります。4 プロセッサ サーバーに対しては 13,800 です。この値を減らすことにより、仮想メモリ断片化の問題を軽減できます。ただし、この値を減らすと、オープン テーブルが多すぎるという理由で操作に失敗する可能性があります。このエラーは、同時に開くことができるテーブルの最大数を減らしたために発生したものであり、間もなくその最大数に達することを示しています。

Exchange Server 2003 は、現在アクセスされていないフォルダに関するデータを、別の方法を使用してキャッシュしています。そのため、オープン テーブルの最大数を減らすことは、仮想メモリの断片化の問題を軽減するためには必要なく、また効果もありません。Exchange Server 2003 サーバーでは、この属性を設定する必要はありません。

Microsoft 製品サポート サービスからここに値を入力するように指示されている場合を除き、Active Directory サービス インターフェイス (ADSI) Edit ツールを使用して、この属性に設定されている値を消去してください。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchESEParamMaxOpenTables 属性の値を消去するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=Exchange 組織名] の順に展開します。

  3. [CN=Administrative Groups] を展開し、[CN=管理グループ名] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=Exchange サーバー名]、[CN=InformationStore] の順に展開し、[CN=ストレージ グループ名] を右クリックして、[プロパティ] をクリックします。

  5. [Select a property to view] ボックスで、[msExchESEParamMaxOpenTables] をクリックします。

  6. [Edit Attribute] ボックスで、[Clear] をクリックして値を "<not set>" に変更します。

  7. [OK] をクリックし、再度 [OK] をクリックします。

  8. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

この属性の詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325044) を参照してください。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。


Exchange データベースのサイズが 100 GB を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Exchange インフォメーション ストア データベースの FileSize キーの値を判断します。インフォメーション ストアの .edb ファイルと .stm ファイルの合計サイズが 100 GB を超えていると、警告が表示されます。

インフォメーション ストアのデータベースは、サイズが 50 GB を超えないようにすることをお勧めします。適切な保守を実施していれば、50 GB より大きいメールボックス ストアを維持しても操作上の問題はありません。しかし、バックアップと復元の時間のために、大きなメールボックス ストアが一部のサービス レベル契約 (SLA) には適さなくなる可能性があります。

50 GB より大きいメールボックス ストアを維持する場合は、大きなデータベースの復元がサービス レベル契約の範囲内になるなど、ハードウェアが SLA に適合していていることを確認してください。それ以外の場合は、1 つのメールボックス ストアのサイズが 50 GB を超えないように、複数のメールボックス ストアにメールボックスを分散させることをお勧めします。

この警告を修正するには

  1. サイズが大きいインフォメーション ストアから、メールボックスの一部を現在の、または別の Exchange Server コンピュータ上の新しいインフォメーション ストアに移動することを検討します。

  2. メールボックスをこのインフォメーション ストアから別のストアに最近移動したばかりの場合、またはこのメールボックス ストアからメールボックスを最近削除したばかり場合は、最適化をオフラインで実行することによりファイル サイズが縮小される場合があります。

  3. メールボックスまたはメッセージのサイズに制限を設定して、インフォメーション ストア データベースが無制限に大きくならないようにすることを検討します。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。

Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server でのメールボックス移動の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server データベースをオフラインで最適化する方法の詳細については、Microsoft サポート技術情報の文書番号 328804「[XADM] Exchange のデータベースを最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804) を参照してください。

メッセージ サイズの制限値設定の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679) を参照してください。


Exchange データベース ファイルが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange インフォメーション ストア データベース ファイルを含むフォルダの Compressed キーの値を判断します。このフォルダについて Compressed の値が True に設定されている場合は、エラーが表示されます。

Exchange 2000 Server または Exchange Server 2003 コンピュータでは、インフォメーション ストア データベースは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\mdbdata

Exchange Server 2007 コンピュータでは、データベース ファイルは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>

Microsoft では、NTFS 圧縮ボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。また、インフォメーション ストア データベースは一定のサイズ (約 4 GB) に達すると、マウントに失敗したり壊れたりする可能性があります。

Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

ESE (Extensible Storage Engine) で管理されているファイルは、圧縮ドライブに格納するようには設計されていません。ESE は、ログ ベースの回復をセクタの独立性に依存しており、ファイルを圧縮することによりセクタの独立性は無効になります。ESE データベース、または先行書き込みログを使用するデータベースのいずれかをホストするボリュームでは、圧縮を有効にしないでください。

Exchange 2000 Server Service Pack 3 より前のバージョンでは、圧縮されたインフォメーション ストア データベースのマウントが許可されていました。しかし、NTFS 圧縮を使用して圧縮された Exchange 2000 Server インフォメーション ストア データベースやインフォメーション ストア ログは、いずれも破損する可能性があります。

Exchange 2000 Server Service Pack 3 では、128 MB 以下の圧縮されたインフォメーション ストア データベース ファイルは自動的に圧縮解除されます。データベース ファイルが大きくなり 128 MB を超えると、データベースはマウントされず、アプリケーション ログにエラー メッセージが生成されます。Exchange 2000 Server Service Pack 3 では、128 MB を超える圧縮ファイルはマウントされません。

特定のフォルダに対するファイル圧縮を無効にするには

  1. ファイルの圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 でデータベース ファイルを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、操作する管理グループ、[サーバー]、操作するサーバー、操作するストレージ グループの順に展開します。次に、[メールボックス ストア] を右クリックして [プロパティ] をクリックします。

  3. [データベース] タブの [Exchange データベース] または [Exchange ストリーミング データベース] で、[参照] をクリックし、圧縮が有効になっていないフォルダのパスを入力します。次に、[OK] をクリックします。

  4. [OK] または [適用] をクリックして変更を適用し、警告メッセージが表示されたら [はい] をクリックします。

    [はい] をクリックすると、ストア (データベース) のマウントが解除され、移動後に再マウントされます。これらの手順が正常に完了すると、次の情報メッセージが表示されます。

    "データベース ファイルは正常に移動されました"

Exchange Server 2007 で Exchange ストレージ グループのデータベース ファイルの場所を移動するには

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループのパスを移動する方法についてのページ (http://go.microsoft.com/fwlink/?LinkID=80747) の手順に従ってください (このサイトは英語の場合があります)。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。


Exchange データベース ファイルが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange データベース ファイル パスの FSName キーの値を判断します。FSName キーの値が "NTFS File System" に等しくないことが検出されると、エラーが表示されます。

Microsoft では、NTFS ではないボリュームへの Exchange データ ファイルの格納をサポートしていません。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .chk ファイル

  • .eml ファイル

このエラーが表示された場合は、データベース ファイルを NTFS ドライブ上のフォルダに移動する必要があります。または、データベース ファイルが置かれているドライブが FAT ドライブとしてフォーマットされている場合、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

Exchange 2000 Server または Exchange Server 2003 で Exchange データベース ファイルを移動するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、操作する管理グループ、[サーバー]、操作するサーバー、操作するストレージ グループの順に展開します。次に、[メールボックス ストア] を右クリックして [プロパティ] をクリックします。

  3. [データベース] タブの [Exchange データベース] または [Exchange ストリーミング データベース] で、[参照] をクリックし、NTFS ボリュームにあるフォルダへのパスの場所を入力します。次に、[OK] をクリックします。

  4. [OK] または [適用] をクリックして、変更を有効にします。変更を適用しない場合は [キャンセル] をクリックします。

  5. [OK] または [適用] をクリックした場合、次の警告メッセージが表示されます。

    注 次の処理を実行しようとしています。

    • Exchange データベースの場所を変更します

    • Exchange ストリーミング データベースの場所を変更します

    この処理を実行するには、ストアのマウントを一時的に解除する必要があります。この間、すべてのユーザーがこのストアにアクセスできなくなります。

    続行しますか?

    注 :
    選択した操作のみが、警告メッセージに示されます。警告メッセージには、[はい] ボタンと [いいえ] ボタンがあります。

  6. 処理を進める準備ができていれば [はい] をクリックし、その他の場合は [いいえ] をクリックします。

  7. [はい] をクリックすると、ストア (データベース) のマウント解除、移動、および再マウントが行われます。これらの手順が正常に完了すると、次の情報メッセージが表示されます。

    "データベース ファイルは正常に移動されました"

Exchange Server 2007 で Exchange ストレージ グループのデータベース ファイルの場所を移動するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループのパスを移動する方法についてのページ (http://go.microsoft.com/fwlink/?LinkID=80747) の手順に従ってください (このサイトは英語の場合があります)。

上記の手順を実行する代わりに、ファイルが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用してそのドライブを NTFS に変換することができます。convert.exe コマンド ライン ツールを使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579) を参照してください。


Exchange データベース ファイルが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Wndows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange インフォメーション ストア データベース ファイルが格納されているフォルダの Encrypted キーの値を判断します。Encrypted の値が True に設定されていることが検出されると、エラーが表示されます。

Exchange 2000 Server コンピュータや Exchange Server 2003 コンピュータでは、データベース ファイルは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\mdbdata

Exchange Server 2007 コンピュータでは、データベース ファイルは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームに Exchange データ ファイルを格納することをサポートしていません。Exchange データ ファイルを暗号化ボリュームに格納するとオーバーヘッドが増え、Exchange のパフォーマンスに大きく影響します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティ保護に役立てるため、Exchange コンピュータに対する権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

このエラーを解決するには、データベース ファイルの書き込み先フォルダでファイルの暗号化を無効にするか、暗号化が有効になっていない場所にデータベース ファイルを移動する必要があります。

ファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 でデータベース ファイルを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、操作する管理グループ、[サーバー]、操作するサーバー、操作するストレージ グループの順に展開します。次に、[メールボックス ストア] を右クリックして [プロパティ] をクリックします。

  3. [データベース] タブの [Exchange データベース] または [Exchange ストリーミング データベース] で、[参照] をクリックし、暗号化が有効になっていないフォルダへのパスの場所を入力します。次に、[OK] をクリックします。

  4. [OK] または [適用] をクリックして変更を適用し、警告メッセージが表示されたら [はい] をクリックします。

  5. [はい] をクリックした後に、ストア (データベース) のマウント解除、移動、および再マウントが行われます。これらの手順が正常に完了すると、次の情報メッセージが表示されます。

    "データベース ファイルは正常に移動されました"

Exchange Server 2007 で Exchange ストレージ グループのデータベース ファイルの場所を移動するには

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループのパスを移動する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80747) の手順に従ってください (このサイトは英語の場合があります)。

データベース ファイルの移動の詳細については、Microsoft サポート技術情報の文書番号 821915「Exchange Server 2003 で Exchange のデータベースおよびログを移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915) を参照してください。

Exchange Server のデータ ファイルと EFS の詳細については、Microsoft サポート技術情報の文書番号 834638「ストレージに関するデータの情報は、暗号化されたボリュームに Exchange でサーバーを提出します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Exchange Server 2003 でメッセージをセキュリティで保護する方法については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?linkid=47574) を参照してください (このサイトは英語の場合があります)。


Exchange データベースがダーティ シャットダウン状態になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-10-30

Microsoft® Exchange Server アナライザ ツールは、データベースの 1 つが正しくシャットダウンされていないと判断しました。このため、データベース ファイルがログ ファイルに接続されたままになっています。

ダーティ シャットダウン状態は、データベースが破損または損傷していることを示すわけではありません。この状態は、データベース ファイルがログ ストリームから正しく切断されていないことを示しているにすぎません。したがって、データベースを再び起動する前に、データベース ファイルを回復する必要があります。

データベースが次にマウントされたとき、この回復は自動的に行われます。自動的に回復できなかった場合は、Microsoft Exchange Server 障害回復アナライザ ツールを使用して障害の原因を分析できます。分析後に、Exchange Server 障害回復アナライザによって、データベース ファイルを手動で回復するための推奨事項が提示されます。

このエラーを修正するには

  • 必要なトランザクション ログ ファイルをデータベースに再生して、データベースをクリーン シャットダウン状態にします。ログ ファイルを再生するには、データベースをマウントします。これに失敗した場合は、Exchange Server 障害回復アナライザ ツールを使用して、障害の原因を切り離します。

Exchange Server 障害回復アナライザ ツールの詳細については、マイクロソフト サポート技術情報の記事 922247 の、Exchange Server 2003 用の Microsoft Exchange Server 障害回復アナライザ ツールの説明のページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=922247) を参照してください。


Exchange データベースのオンライン保守スケジュールが Never に設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、メールボックス ストアとパブリック ストアの activationSchedule 属性の値を判断します。activationSchedule の値が Never に解決されることが検出されると、警告が表示されます。

activationSchedule 属性は、オンラインのデータベース保守スケジュールの設定を表しています。Exchange Server では、オンラインのデータベース保守は非常に重要です。保守時間中には、削除済みアイテムの格納場所のクリーンアップ (保存期間を過ぎたメッセージが削除される)、パブリック フォルダの有効期限の処理 (特定の日付より古いパブリック フォルダ内のメッセージが期限切れになる)、削除されたメールボックスのクリーンアップ、オンラインでの最適化 (使用されなくなったデータベース オブジェクトの検出と削除が行われ、利用可能なデータベース領域が拡大される)、などのタスクが実行されます。これらの処理によって、Exchange Server コンピュータが正常な状態に保たれ、パフォーマンスが安定します。オンラインの保守は、最低でも 1 日で 4 時間実行するように設定する必要があります。この設定を行わないと、時間が経つにつれてパフォーマンスが低下します。

オンラインのデータベース保守は、それぞれのデータベース (メールボックス ストアまたはパブリック フォルダ ストア) で毎日 4 時間実行するように構成することをお勧めします。オンライン保守の時間帯は、バックアップのスケジュールと重ならないようにします。たとえば、バックアップが午前 0 時から午前 2 時まで実行される場合、オンライン保守は午前 3 時から午前 7 時まで実行します。

バックアップ セッションが実行中だとオンライン保守は開始されないため、この点は重要です。スケジュールが重複すると、保守よりもバックアップが優先されます。この場合、Exchange はバックアップが完了したかどうかを 15 分ごとに確認します。保守は、バックアップの完了後に開始されます。

保守の実行時にストアで行われるタスクは 18 あります。タスクが 1 つ開始されると、そのタスクは保守の時間枠に関係なく最後まで行われます。ただし、時間枠が終了している場合、次の新しいタスクは開始されません。したがって、場合によっては、与えられた保守時間中にすべてのタスクが完了しないことがあります。保守が途中で打ち切られた場合、次の保守サイクルの開始時に、打ち切られた時点から保守が再開されます。

Exchange 2000 Server および Exchange Server 2003 でオンラインのデータベース保守を有効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、操作するサーバーを展開します。

  3. 操作するストレージ グループを展開します。

  4. 詳細ウィンドウにある利用可能なデータ ストアの一覧で、操作するストアを右クリックし、[プロパティ] をクリックします。

  5. 該当するストアの [プロパティ] ダイアログ ボックスで、[データベース] タブをクリックします。

  6. 以下のいずれかを実行します。

    • [保守の間隔] の一覧で、間隔をクリックします。

    • [カスタマイズ] をクリックし、[スケジュール] ダイアログ ボックスでカスタムの間隔を作成します。

  7. [OK] をクリックします。

Exchange Server 2007 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、操作するサーバーを選択します。

  3. 操作するストレージ グループを展開します。

  4. 操作するストアを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[保守のスケジュール] ボックスをクリックして間隔を選択するか、または [カスタマイズ] をクリックしてカスタム スケジュールを作成します。

オンラインのデータベース保守タスクの詳細については、マイクロソフト サポート技術情報の文書番号 159196「[XADM] IS 保守スケジュールで制御されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159196) を参照してください。


Exchange Information Store サービスが LocalSystem として実行されるように構成されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-02-27

Microsoft® Exchange Server アナライザ ツールは、Win32_Services Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Information Store サービス (MSExchangeIS) の StartName プロパティで指定されている開始アカウントが LocalSystem アカウントを使用しているかどうかを判断します。Exchange 2000 Server、Exchange Server 2003 または Exchange Server 2007 コンピュータでこのプロパティの値が LocalSystem (SYSTEM アカウントとも呼ばれます) 以外のアカウントであることが検出されると、警告が表示されます。Exchange Server 5.5 コンピュータの場合は、Microsoft Exchange Information Store サービスをユーザー アカウントで実行することが前提になっており、また必須でもあるため、この警告は表示されません。

Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 は、特定のユーザー アカウント (およびパスワード) との関連付けによりこれらのサービスを開始するのではなく、LocalSystem セキュリティ コンテキストで開始される必要があります。これによって、パスワードの変更やユーザー アカウントの削除により Exchange が正常に動作しなくなることが防止されます。LocalSystem として実行されている Exchange サービスがリモート サーバーにアクセスすると、Microsoft Windows 2000 Server または Windows Server™ 2003 はコンピュータ アカウントの資格情報を使用してそのサービスを認証します。

コンピュータ アカウントのパスワードは、標準のパスワード変更機構を使用して 7 日ごとに変更されます。これによって、コンピュータ アカウントは、一般のユーザー アカウントよりもセキュリティが強固になります。一般のアカウントでは、パスワードがあまり変更されず、しかもランダムに生成されるコンピュータ アカウントのパスワードと比較してパスワードのランダム性は高くありません。

Exchange Server 5.5 ではサービスでユーザー アカウントが使用されるため、その使用経験がある管理者の中には、Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 サービスの開始アカウントが既定の LocalSystem アカウントでなくユーザー アカウントを使用するように変更を加えている方もいます。

Exchange 2000 Server、Exchange Server 2003 および Exchange Server 2007 では、Microsoft Exchange Information Store サービスを LocalSystem 以外のアカウントで実行することをサポートしていません。

このエラーを修正するには

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[管理ツール] をポイントし、[サービス] をクリックします。

  2. サービスの一覧の [Microsoft Exchange Information Store] を右クリックし、[プロパティ] をクリックします。

  3. [ログオン] タブで、[ログオン] の下の [ローカル システム アカウント] をクリックし、[OK] をクリックします。

  4. [Microsoft Exchange Information Store] を右クリックし、[再起動] をクリックします。

Exchange サービスの詳細については、マイクロソフト サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


Exchange Information Store サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの設定値が、True と False のどちらに設定されているかを判断します。

値が False の場合、この Exchange Server コンピュータ上で Microsoft Exchange Information Store サービスは実行されていません。この値が True の場合は、Microsoft Exchange Information Store サービスが実行されています。

また、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_Server WMI クラスも調べ、IsFrontEndServer キーの値を判断します。値が False の場合は、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True の場合は、Exchange Server コンピュータは Exchange Server 2003 または Exchange 2000 Server のフロントエンド サーバーです。

Exchange 2000 Server および Exchange Server 2003 システムでは、評価されたキーの値がどちらも False の場合、警告が表示されます。

Exchange Server コンピュータが Exchange Server 2007 を実行しており、Win32_Service Started キーについて返された値が False の場合、警告が表示されます。

Microsoft Exchange Information Store サービスの開始に失敗する場合は、この Exchange Server コンピュータにさらに重大な問題があることを示している可能性があります。この場合は、イベント ログでエラーに関する詳細を調べる必要があります。また、使用している Exchange Server のバージョンに対応する最新の Service Pack が実行されていることを確認する必要があります。

Exchange Server 2003 の最新の Service Pack は、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=25097) で入手できます。

Microsoft Exchange Information Store サービスの失敗に関する既知の原因の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 827915「2003 に Exchange で PR_MESSAGE_CLASS プロパティを含まないメッセージを変換するが、インフォメーション ストア サービスは、突然停止することがあります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827915)

  • 文書番号 830602「Exchange Server 2003 情報格納サービスは、応答を停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=830602)

  • 文書番号 839115「Exchange Server 2003 にアップグレードすると、Information Store サービスが開始されません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=839115)

  • 文書番号 330197「突然インフォメーション ストア サービスが ID がローカルに配信されるいるのに NULL インターネット メッセージでメッセージのとき、停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=330197)

  • 文書番号 831130「Exchange Server 2003 コンピュータ上のメールボックスに OWA を使用してアクセスしたときに、[フォルダ] ウィンドウが表示されないか、Information Store サービスが予期せず終了する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=831130)

  • 文書番号 823163「インフォメーション ストア サービスを開始するとエラー メッセージ "グローバル カタログ サーバーに接続できません。" が表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823163)

  • 文書番号 822579「Exchange Server 2003 のインストール後にイベント ID 7024 が発生し、Exchange Information Store サービスが開始しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822579)

  • 文書番号 833841「Microsoft Exchange Information Store サービスが予期せず応答を停止する。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833841)

Exchange Server 2003 および Exchange 2000 Server のフロントエンド サーバーの使用方法の詳細については、以下の Web サイトを参照してください。

  • 『Using Microsoft Exchange 2000 Front-End Servers』(http://go.microsoft.com/fwlink/?linkid=12055) (このサイトは英語の場合があります)

  • 『Exchange Server 2003 and Exchange 2000 Server Front-End and Back-End Topology』(http://go.microsoft.com/fwlink/?linkid=34216) (このサイトは英語の場合があります)


フロントエンド サーバーで Exchange Information Store サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Information Store および SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合は、サービスが実行されています。

Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間の Exchange_Server WMI クラスに対してもクエリを実行し、IsFrontEndServer キーの値を判断します。値が False のときは、Exchange Server コンピュータはフロントエンド サーバーではありません。値が True のときは、Exchange Server コンピュータはフロントエンド サーバーです。

Exchange Server アナライザによって、SMTP サービスの Started の値が True であり、かつ Microsoft Exchange Information Store サービスの Started の値が False であり、さらに IsFrontEndServer の値が True であることが検出されると、警告が表示されます。

Exchange 2000 Server および Exchange Server 2003 はフロントエンド サーバーを使用して、POP3、IMAP4、および Microsoft Office Outlook® Web Access クライアントの要求をプロキシします。さらに、フロントエンド サーバーは、インターネットに直接接続された SMTP サーバーとしても使用できます。このフロントエンド サーバーが SMTP メッセージを受け入れてルーティングする場合、(メッセージの送信に SMTP を使用する) IMAP クライアントをサポートする場合、またはこのフロントエンド サーバーで VSAPI (Virus Scanning API) 対応ソフトウェアが実行されている場合は、Microsoft Exchange Information Store サービスが実行されている必要があります。そうでない場合、フロントエンド サーバーは SMTP メッセージの処理や、VSAPI を使用したメッセージのスキャンを行うことができません。

フロントエンド サーバーで SMTP または VSAPI 対応のウイルス対策ソフトウェアを使用している場合以外は、フロントエンド サーバーにあるすべてのパブリック フォルダ ストアを切断し、削除すると共に、Microsoft Exchange Information Store サービスを停止してから無効に設定することをお勧めします。さらに、SMTP サービスを使用していない場合は、このサービスを停止する必要があります。SMTP または VSAPI 対応のソフトウェアを使用している Exchange Server コンピュータ上で、メッセージの配信やメッセージング クライアントへのサービス提供を行うには、Microsoft Exchange Information Store サービスが実行されている必要があります。

この警告を修正するには

  1. [サービス] MMC スナップインを起動します。

  2. [Microsoft Exchange Information Store] サービスを右クリックし、[プロパティ] をクリックします。

  3. [Microsoft Exchange Information Store のプロパティ] ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [Microsoft Exchange Information Store] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。

Microsoft Exchange Information Store サービスの開始に失敗する場合は、この Exchange Server コンピュータにさらに重大な問題があることを示している可能性があります。この場合は、イベント ログで失敗の詳細を調べる必要があります。また、使用しているバージョンの Exchange Server の最新の Service Pack を実行していることも確認する必要があります。Exchange Server の最新の Service Pack は、Microsoft Exchange Server ホームページ (http://go.microsoft.com/fwlink/?LinkId=21573) で入手できます (このサイトは英語の場合があります)。

Microsoft Exchange Information Store サービスの失敗に関する既知の原因の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 827915「2003 に Exchange で PR_MESSAGE_CLASS プロパティを含まないメッセージを変換するが、インフォメーション ストア サービスは、突然停止することがあります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827915)

  • 文書番号 830602「Exchange Server 2003 情報格納サービスは、応答を停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=830602)

  • 文書番号 839115「Exchange Server 2003 にアップグレードすると、Information Store サービスが開始されません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=839115)

  • 文書番号 330197「突然インフォメーション ストア サービスが ID がローカルに配信されるいるのに NULL インターネット メッセージでメッセージのとき、停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=330197)

  • 文書番号 831130「Exchange Server 2003 コンピュータ上のメールボックスに OWA を使用してアクセスしたときに、[フォルダ] ウィンドウが表示されないか、Information Store サービスが予期せず終了する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=831130)

  • 文書番号 823163「インフォメーション ストア サービスを開始するとエラー メッセージ "グローバル カタログ サーバーに接続できません。" が表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823163)

  • 文書番号 822579「Exchange Server 2003 のインストール後にイベント ID 7024 が発生し、Exchange Information Store サービスが開始しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822579)

  • 文書番号 833841「Microsoft Exchange Information Store サービスが予期せず応答を停止する。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833841)

フロントエンド サーバーの使用方法の詳細については、『Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000 Server』(http://go.microsoft.com/fwlink/?linkid=47567) を参照してください (このサイトは英語の場合があります)。


Exchange Installable File System ドライブが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-28

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ExIFS (Exchange Installable File System、IFS とも呼ばれます) ドライブ文字の割り当てが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

DriveLetter レジストリ値が (M などの) ドライブ文字で構成されていることが検出されると、エラーが表示されます。

Exchange 2000 Server では、IFS という機能が導入されました。IFS は、Exchange Information Store 内のデータの一部を Microsoft Windows® ファイル システムに公開するカーネルレベルのドライバです。Exchange 2000 Server の新規インストール、および Exchange Server 5.5 から Exchange 2000 Server へのアップグレードでは、IFS が自動的にインストールされ、ドライブ文字 (既定ではドライブ M) がインフォメーション ストアに割り当てられ、マップされました。この割り当ては、\\.\BackOfficeStorage\ 名前空間を使用して実行されていました。

Exchange Server 2003 も IFS をサポートしていますが、既定では、ドライブ文字の割り当ては無効になっています。Exchange Server 2003 の新規インストール、および Exchange 2000 Server から Exchange Server 2003 へのアップグレードでは、DriveLetter レジストリ値とこのレジストリ値データは存在しません。したがって、ドライブ文字の割り当ては削除されています。

ベスト プラクティスとしては、Exchange Server 2003 で IFS ドライブ文字の割り当てを有効にせず、Exchange 2000 Server でそのドライブ文字の割り当てを削除することをお勧めします。IFS に割り当てたドライブ文字に対して、ウイルス対策アプリケーションまたはファイル システム ベースのアプリケーションでアクセスまたはスキャンを行うと、既知の問題が発生する可能性があります。このため、IFS 機能を使用しない場合は、ドライブ文字の割り当てを削除することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\EXIFS\Parameters

  3. 右側のペインで、[DriveLetter] 値をダブルクリックします。

  4. [値のデータ] ボックスで、表示されている文字を削除し、[値のデータ] ボックスが空になるようにします。

  5. レジストリ エディタを終了し、Microsoft Exchange System Attendant サービスおよび World Wide Web Publishing サービスを再開して、変更を有効にします。システム アテンダント サービスを再開すると、Microsoft Exchange MTA Stacks サービスや Microsoft Exchange Information Store サービスなど、システム アテンダント サービスに依存するサービスもすべて再開されます。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange 2000 Server でのドライブ文字 M の割り当ての削除の詳細については、Microsoft サポート技術情報の文書番号 305145「[HOW TO: XADM] ドライブ M の IFS 割り当てを削除する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=305145) を参照してください。

Exchange Server 2003 でのドライブ文字 M の割り当ての追加の詳細については、Microsoft サポート技術情報の文書番号 821836「Exchange Server 2003 では、ドライブ M の IFS 割り当てをデフォルトでは使用できない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821836) を参照してください。


Exchange Server の構成およびパフォーマンス
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーが最適なパフォーマンスに構成されていないと判断しました。

通常の動作中に、Exchange サーバーはさまざまなファイルにアクセスします。これらのファイルの場所が、パフォーマンスのボトルネックの原因になっている可能性があります。トランザクション ログ ドライブなどの独立したファイルのグループはリソースとも呼ばれます。

これらのリソースの分散がディスクのボトルネックの原因である場合、Exchange サーバー上のリソースの場所に関する警告またはエラーが表示されます。特定のリソースを他の負荷要求から分離するには、リソースを専用の記憶装置に配置します。次の一覧では、リソースの推奨される構成方法を含む各リソースの使用方法を説明します。

  • トランザクション ログ ドライブ トランザクション ログ ファイルは, .edb ファイルおよび .stm ファイルの状態と整合性を維持します。これは、実質的にはログ ファイルがデータを表すことを意味します。各ストレージ グループにトランザクション ログ ファイルのセットが存在します。トランザクション ログは Exchange サーバー データベース ファイルのデータの重要なバックアップ コンポーネントであるため、Exchange サーバーはデータの多くのトランザクションを完了する前に、すべてのデータをログ ファイルにコミットする必要があります。トランザクション ログ ドライブへの書き込みによる遅延は、サーバーのパフォーマンスが大幅に低下する可能性があります。したがって、トランザクション ログ ドライブを分離して、ドライブに他のサーバー、アプリケーション、またはリソースと共用されていない専用のディスク サブシステムを割り当てることが重要です。パフォーマンスを最適化するには、各トランザクション ログに専用のドライブを割り当てる必要があります。

  • TEMP ドライブの場所 最初のインストール時に、オペレーティング システムは一時ファイルの場所をオペレーティング システムが使用するドライブと同じドライブに設定します。これは、TEMP ドライブの I/O は、同じドライブから実行されるプログラムやページ ファイルの操作の I/O と競合することを意味します。この I/O の競合はパフォーマンスに影響します。TEMP ドライブは、メール配信と大きなメッセージのコンテンツ変換に使用されます。TEMP ドライブにボトルネックがある場合、メール フローと一部のクライアント アプリケーションに影響します。オペレーティング システムと TEMP ドライブの I/O が競合することを避け、Exchange サーバーでパフォーマンスの問題が発生するリスクを減らすために、次のことをお勧めします。

    • TEMP のグローバル環境設定を、別のディスクをポイントするように変更します。

    • TEMP ドライブを専用のディスクに移動します。

  • .edb ファイルおよび .stm ファイルの場所 Exchange データベースは、次の 2 つのファイルで構成されています。

    • .edb ファイル (MAPI コンテンツ) このファイルには、すべての MAPI メッセージとテーブルが格納され、Store.exe プロセスによって .edb ファイルと .stm ファイルのすべてのメッセージおよびチェックサム、あるいは MAPI メッセージを見つけるために使用されます。

    • .stm ファイル (MAPI コンテンツ以外) このファイルには、ネイティブ インターネット コンテンツで送信されるメッセージが含まれます。

    これらのファイルへのアクセスはいずれも通常ランダムであるため、どちらのファイル タイプも同じディスク ボリュームに含めることができます。ただし, .edb ファイルおよび .stm ファイルを、トランザクション ログと同じドライブに配置しないことは重要です。また、データベース ファイルを含むドライブでパフォーマンスのボトルネックを避けることは重要なため、これらのファイルをストレージ グループごとに専用のドライブに配置することをお勧めします。

  • SMTP ディレクトリの場所 SMTP キューは、Exchange が SMTP メッセージをデータベース (メールボックス ストアまたはパブリック フォルダ ストア) に書き込むか、別のサーバーまたはコネクタにメッセージを送信するまで、SMTP メッセージを格納します。通常、SMTP キューではランダムで小規模な I/O が発生します。Exchange Server アナライザは、SMTP ディレクトリが次のいずれかと共有されているドライブに配置されている場合に警告を表示します。

    • その他の Exchange データ ファイル

    • TEMP ディレクトリまたは TMP ディレクトリ

    • ページ ファイル

    • システム ドライブ

    SMTP ディレクトリに対するディスクのボトルネックがない場合は、この警告を無視してかまいません。ただし、このドライブへのトラフィックが大量で、ドライブにパフォーマンスのボトルネックが発生している場合は、SMTP ディレクトリを専用のドライブに移動するか、SMTP ディレクトリをホストしているドライブの容量を増やします。

  • ページ ファイルの場所 ページ ファイルは、物理メモリの拡張として機能します。具体的には、ページ ファイルは、使用されていないページや、システムが後で必要とするページをシステムが格納する場所です。ページ ファイルは、空きメモリの十分な容量がある場合も、サーバーに常に使用されます。この継続的な使用は、オペレーティング システムが必要なページだけを保存して、操作に十分な空き領域を確保しようとするために発生します。たとえば、起動時のみに使用される印刷ツールは、一部のメモリがディスクにページ化され、使用されない限り元に戻されません。

    物理メモリの使用率が高いサーバーでは、ページ ファイルへのすべてのアクセスをできるだけ高速になるようにしてください。ページ ファイルの専用のドライブに 2 つ目のページ ファイルを作成することをお勧めします。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=72988) を参照してください。

  • ディスクのサイズ変更、待ち時間、および入出力速度の詳細については、ディスク I/O 要件の計算方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=69747) を参照してください。


Exchange ストアの TCP/IP ポートが手動で無効にされている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-03-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ストア インターフェイスのポート値が手動で無効にされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

Exchange Server アナライザによって TCP/IP Port が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が構成されている最も一般的な理由は、MAPI クライアントから、ファイアウォールの向こう側にある Exchange サーバーに接続できるようにするためです。このシナリオでは、Microsoft Office Outlook 2003® または Outlook 2007 クライアントが MAPI を使用して Exchange サーバーに (通常はインターネット経由で) 接続できるようにするために、ファイアウォールで複数のポートを開くことが必要になります。この構成はサポートされています。MAPI クライアントをファイアウォール経由で Exchange に接続できるように構成する方法の詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange 2000 および Exchange 2003 の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。ただし、このシナリオを使用しない場合は、このレジストリ キーを削除する必要があります。

Outlook を MAPI モードで使用して、インターネット経由で Exchange サーバーに接続できるようにする展開では、Microsoft Windows Server™ 2003、Exchange Server 2003、Outlook 2003、Exchange Server 2007、Outlook 2007 および Microsoft Windows® XP Professional にある RPC over HTTP 機能を使用することをお勧めします。MAPI モードは、以前は "企業" または "ワークグループ" モードと呼ばれていました。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP Port レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. TCP/IP Port レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTPS を展開するには

  1. Exchange Server 2003 における RPC over HTTP の展開シナリオについてのページ (http://go.microsoft.com/fwlink/?linkid=47577) を参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 833401「Exchange Server 2003 の単一のサーバーで RPC over HTTP を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833401) を参照してください。

  3. Microsoft サポート技術情報の文書番号 827330「Office Outlook 2003 のクライアント RPC over HTTP 接続の問題に関するトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=827330) を参照してください。

  4. Microsoft Support WebCast「[Support WebCast] [OL2003] Outlook 2003 でインターネット (RPC/HTTP) を経由して Microsoft Exchange を使用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=829134) を参照してください。


Exchange ストアの TCP/IP ポートが 5000 より小さい
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-01-11

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ストアの TCP/IP Port 設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP Port

TCP/IP Port の値が 5,000 (10 進数) 未満に設定されていることが検出されると、警告が表示されます。

TCP/IP Port 設定を固定する必要がある場合、5000 を少し超える値または 5000 に設定することをお勧めします。この値が 5000 よりも小さい場合は、Exchange サーバーがポートでの待機を停止する原因になる可能性があります。サービスが再開するまで、Exchange サーバーにはこの状態が残ります (このサービスの再開は、ハードコードされている Exchange のコンポーネントに依存します)。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

TCP/IP ポートのレジストリ キーを設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [TCP/IP Port] キーをダブルクリックし、[値のデータ] ボックスに 5000 (10 進数) を少し超える整数を設定します。

  4. レジストリ エディタを終了します。

  5. Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ポートの設定の詳細については、Microsoft サポート技術情報の文書番号 270836「Exchange Server の静的ポートの割り当て」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270836) を参照してください。


Exchange トランザクション ログが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-02-27

エラー メッセージ

概要

Microsoft Exchange アナライザ ツールは、Win32_Directory Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Exchange トランザクション ログ ファイルのパスの FSName キーの値を判断します。FSName キーの値が NTFS ではないことが検出されると、エラーが表示されます。

Microsoft では、NTFS ではないボリュームへの Exchange データ ファイルの格納をサポートしていません。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

このエラーが表示された場合は、トランザクション ログを NTFS ドライブのフォルダに移動する必要があります。トランザクション ログ ディレクトリが置かれているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

Exchange 2000 Server または Exchange Server 2003 上のトランザクション ログを移動するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. [全般] タブの [トランザクション ログの場所] で、[参照] をクリックします。

  4. ログ ファイル用の新しい場所へのパスを入力し、[OK] をクリックします。

  5. [OK] をクリックします。

Exchange Server 2007 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を移動するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループ ログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkID=80702) の手順に従ってください (このサイトは英語の場合があります)。

または、フォルダが格納されているドライブが FAT ドライブとしてフォーマットされている場合、上記の手順を実行する代わりに、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。コマンド ライン ツールの convert.exe を使用して FAT パーティションを NTFS パーティションに変換する方法については、マイクロソフト サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=214579) を参照してください。


Exchange トランザクション ログが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange インフォメーション ストア トランザクション ログを含むフォルダの Compressed キーの値を判断します。このフォルダについて Compressed の値が True に設定されている場合は、エラーが表示されます。

Exchange に配信されるメッセージは、まず、トランザクション ログに書き込まれてから、ストアにコミットされ、配信されます。Exchange 2000 Server または Exchange Server 2003 コンピュータでは、トランザクション ログは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\mdbdata

Exchange Server 2007 コンピュータでは、トランザクション ログは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>

Microsoft では、NTFS 圧縮ボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。また、インフォメーション ストア データベースは一定のサイズ (約 4 GB) に達すると、マウントに失敗したり壊れたりする可能性があります。

Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

ESE (Extensible Storage Engine) で管理されているファイルは、圧縮ドライブに格納するようには設計されていません。ESE は、ログ ベースの回復をセクタの独立性に依存しており、ファイルを圧縮することによりセクタの独立性は無効になります。ESE データベース、または先行書き込みログを使用するデータベースのいずれかをホストするボリュームでは、圧縮を有効にしないでください。

Exchange 2000 Server Service Pack 3 より前のバージョンでは、圧縮されたインフォメーション ストア データベースのマウントが許可されていました。しかし、NTFS 圧縮を使用して圧縮された Exchange 2000 Server インフォメーション ストア データベースやインフォメーション ストア ログは、いずれも破損する可能性があります。

Exchange 2000 Server Service Pack 3 の使用時には、128 MB 以下の圧縮されたインフォメーション ストア データベース ファイルで、自動的に圧縮が解除されます。データベース ファイルが大きくなり 128 MB を超えると、データベースはマウントされず、アプリケーション ログにエラー メッセージが生成されます。Exchange 2000 Server Service Pack 3 では、128 MB を超える圧縮ファイルはマウントされません。

特定のフォルダに対する圧縮を無効にするには

  1. ファイルの圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 上のトランザクション ログを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. [全般] タブの [トランザクション ログの場所] で、[参照] をクリックします。

  4. ログ ファイル用の新しい場所へのパスを入力し、[OK] をクリックします。

  5. [OK] をクリックします。

Exchange Server 2007 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を移動するには

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループ ログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80702) の手順に従ってください (このサイトは英語の場合があります)。

Exchange Server 2003 上でのログ ファイルの移動の詳細については、Microsoft サポート技術情報の文書番号 821915「Exchange Server 2003 で Exchange のデータベースおよびログを移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915) を参照してください。

Exchange 2000 Server 上でのログ ファイルの移動の詳細については、Microsoft サポート技術情報の文書番号 239944「[XADM] トランザクションまたはシステム ログを別の場所に移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239944) を参照してください。


Exchange トランザクション ログが暗号化フォルダに書き込まれる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-02-27

Microsoft Exchange アナライザ ツールは、Win32_Directory Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、インフォメーション ストア トランザクション ログが含まれているフォルダの Encrypted キーの値を判断します。Encrypted の値が True に設定されていることが検出されると、エラーが表示されます。

メッセージが Exchange に配信される場合、そのメッセージは最初にトランザクション ログに書き込まれ、次にインフォメーション ストアにコミットされて配信されます。Exchange 2000 Server または Exchange Server 2003 コンピュータでは、トランザクション ログは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Exchsrvr\mdbdata

Exchange Server 2007 コンピュータでは、トランザクション ログは次の既定の場所に書き込まれます。

<ドライブ> :\Program Files\Microsoft\Exchange Server\Mailbox\<ストレージ グループ名>

Microsoft は、Exchange データ ファイルを暗号化ファイル システム (EFS) の暗号化ボリュームに格納することをサポートしていません。Exchange データ ファイルを暗号化ボリュームに格納するとオーバーヘッドが増え、Exchange Server のパフォーマンスに大きく影響します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルをセキュリティで保護しやすくするために、Exchange コンピュータへの権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

このエラーを解決するには、トランザクション ログが書き込まれるフォルダでのファイルの暗号化を無効にするか、またはトランザクション ログを暗号化が無効になっているフォルダに移動する必要があります。

指定されたフォルダでのファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 上のトランザクション ログを移動するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] を展開し、操作する管理グループを展開します。次に、[サーバー] を展開し、操作するストレージ グループを右クリックして [プロパティ] をクリックします。

  3. [全般] タブの [トランザクション ログの場所] で、[参照] をクリックします。

  4. ログ ファイル用の新しい場所へのパスを入力し、[OK] をクリックします。

  5. [OK] をクリックします。

Exchange Server 2007 で Exchange ストレージ グループのトランザクション ログ ファイルの場所を移動するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、ストレージ グループ ログ ファイルの場所を設定または変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkID=80702) の手順に従ってください (このサイトは英語の場合があります)。

ログ ファイルの移動の詳細については、マイクロソフト サポート技術情報の文書番号 821915「Exchange Server 2003 で Exchange のデータベースおよびログを移動する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821915) を参照してください。

Exchange Server のデータ ファイルと EFS の詳細については、マイクロソフト サポート技術情報の文書番号 834638「ストレージについてのデータの情報は、暗号化されたボリュームに Exchange でサーバーをファイルします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Microsoft Exchange Server 2003 でメッセージをセキュリティ保護する方法の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?linkid=47574) を参照してください (このサイトは英語の場合があります)。


ESE 拡張パフォーマンス カウンタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ キーを読み取り、Exchange サーバーで、パフォーマンス カウンタのライブラリに ESE (Extensible Storage Engine) 拡張カウンタが含まれているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ESE\Performance\Show Advanced Counters

Show Advanced Counters レジストリ キーのデータ値が 1 であることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
ESE 拡張パフォーマンス カウンタを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. レジストリ内の HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESE\Performance キーの下にある Show Advanced Counters 値を削除します。

  3. レジストリ エディタを終了します。

  4. パフォーマンス モニタを再起動して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


拡張ストア パフォーマンス カウンタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、Exchange Server のパフォーマンス カウンタ ライブラリに Mdbperfx.dll が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Performance

Library 値に "mdbperfx.dll" という文字列が含まれていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

DLL Mdbperf.dll には、ストア パフォーマンス カウンタの既定のセットが含まれています。DLL Mdbperfx.dll には、ストア パフォーマンス カウンタの同じ既定のセットが含まれていますが、ストア パフォーマンス カウンタの拡張セットも含まれています。

既定では、Library の値のデータに DLL Mdbperf.dll は含まれていますが、DLL Mdbperfx.dll は含まれていません。次の表に、DLL Mdbperfx.dll に含まれている拡張ストア パフォーマンス カウンタを示します。

カウンタ | 収集する情報
FXGetBufferRopsCalled | FxGetBuffer リモート プロシージャ コール (RPC) 操作の合計数。
FXGetBufferRopsCalledPerSec | FXGetBuffer RPC 操作の 1 秒あたりの数。
FXGetBufferRopsAcceptedPerSec | 受け付けられた FXGetBuffer RPC 操作の 1 秒あたりの数。
FXGetBufferRopsDenied | 拒否された FXGetBuffer RPC 操作の合計数。
FXGetBufferRopsDeniedPerSec | 拒否された FXGetBuffer RPC 操作の 1 秒あたりの数。
FXGetBufferCurrentCallerCount | FXGetBuffer RPC 同時操作の数。
FXGetBufferCurrentUsersExecuting | 実行されている FXGetBuffer RPC 同時操作の数。
Messages Scanned as MIME | ウイルス スキャン ソフトウェアによって MIME として処理されたトップレベル メッセージの合計数。
Messages Scanned as MIME/sec | ウイルス スキャン ソフトウェアによって MIME として処理されたトップレベル メッセージの 1 秒あたりの数。
Messages Scanned as MAPI | ウイルス スキャン ソフトウェアによって MAPI として処理されたトップレベル メッセージの合計数。
Messages Scanned as MAPI/sec | ウイルス スキャン ソフトウェアによって MAPI として処理されたトップレベル メッセージの 1 秒あたりの数。
Bytes Read | ウイルス スキャン ソフトウェアによって読み取られた合計のバイト数。
Bytes Written | ウイルス スキャン ソフトウェアによって書き込まれた合計のバイト数。
Queue Length (Low Priority) | ウイルス スキャン用のキューに入れられている、優先度が低く現在未解決の要求の数。
Threads | ウイルス スキャンで使用されるスレッド プールに現在存在するスレッドの数。この値には、バックグラウンドでのスキャンで使用されるスレッドの数は含まれません。
Checks Satisfied by MFT Stamp | Message Folder Table のスタンプ情報によってウイルス スキャンの確認が満たされた回数。
Checks Satisfied by MFT Stamp/sec | Message Folder Table のスタンプ情報によってウイルス スキャンの確認が満たされた 1 秒あたりの数。
Checks Satisfied by Instance Stamp | インスタンス スタンプ情報によってウイルス スキャンの確認が満たされた回数。
Checks Satisfied by Instance Stamp/sec | インスタンス スタンプ情報によってウイルス スキャンの確認が満たされた 1 秒あたりの数。
Checks Satisfied by Master Instance Stamp/sec | マスタのインスタンス スタンプ情報によってウイルス スキャンの確認が満たされた 1 秒あたりの数。
Checks Not Satisfied | どのスタンプ情報によってもウイルス スキャンの確認が満たされなかった回数。
Checks Not Satisfied/sec | どのスタンプ情報によってもウイルス スキャンの確認が満たされなかった 1 秒あたりの数。
Checks Blocked | ウイルス スキャンが完了するまでの待機が原因で処理が停止された回数。
Checks Blocked/sec | ウイルス スキャンが完了するまでの待機が原因で処理が停止された 1 秒あたりの数。
Check Timeouts | ウイルス スキャンが完了するまでの待機が原因で操作がタイムアウトになった回数。
Check Timeouts/sec | ウイルス スキャンが完了するまでの待機が原因で操作がタイムアウトになった 1 秒あたりの数。
重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定のストア パフォーマンス カウンタのみを有効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次のレジストリ キーの下で Library 値を見つけます。

    HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Performance

  3. [編集] メニューの [変更] をクリックします。

  4. [値のデータ] ボックスで、値を [c:\Program Files\Exchsrvr\bin\mdbperfx.dll] から [c:\Program Files\exchsrvr\bin\mdbperf.dll] に変更します。

  5. [OK] をクリックし、レジストリ エディタを終了します。

  6. パフォーマンス モニタを再起動して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange ストアに関するパフォーマンス データを収集する方法の詳細については、Microsoft サポート技術情報の文書番号 821912「インフォメーション ストア問題のトラブルシューティングに役立てられるため、どのように診断データを収集します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821912) を参照してください。


FXGetBuffer Backoff Constant パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、FXGetBuffer Backoff Constant の値が作成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

FXGetBuffer Backoff Constant レジストリ キーに ParametersSystem の値が作成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

FXGetBuffer Backoff Constant 値を使用すると、Exchange Server 2003 サーバーと一度に同期する Microsoft Office Outlook® 2003 クライアントの数を制御できます。それには、FXGetBuffer Backoff Constant 値を設定して、Outlook クライアントが再び同期を試みる前に待機する時間を構成します。FXGetBuffer Backoff Constant の既定値は 500 ミリ秒です。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定の構成に戻す場合は、FXGetBuffer Backoff Constant レジストリ キーを削除することができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. FXGetBuffer Backoff Constant 値を削除します。

  4. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

レジストリ キーを設定して Exchange Server 2003 と同期できる Outlook クライアントの数を制御する方法の詳細については、Microsoft サポート技術情報の文書番号 818484「レジストリが値で、Outlook クライアント同期を設定し、そして監視するのに使用できることをカウンタする。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484) を参照してください。


FXGetBuffer Retry Count パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、FXGetBuffer Retry Count の値が作成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

ParametersSystem レジストリ キーに FXGetBuffer Retry Count の値が作成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

FXGetBuffer Retry Count 値を使用すると、Exchange Server 2003 サーバーと一度に同期する Microsoft Outlook® 2003 クライアントの数を制御できます。FXGetBuffer Retry Count の値を設定することで、アクセスを許可されるまでに Outlook クライアントが同期を試行できる回数を構成します。既定値は 10 です。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定の構成に戻す場合は、FXGetBuffer Retry Count レジストリ キーを削除することができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. FXGetBuffer Retry Count の値を削除します。

  4. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

レジストリ キーを設定して Exchange Server 2003 と同期できる Outlook クライアントの数を制御する方法の詳細については、Microsoft サポート技術情報の文書番号 818484「レジストリが値で、Outlook クライアント同期を設定し、そして監視するのに使用できることをカウンタする。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484) を参照してください。


Ignore Bad Oof Rule レジストリパラメータが設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Exchange Server コンピュータのレジストリを調べて、Ignore Bad Oof Rule レジストリ エントリが存在するかどうかを判断します。このレジストリ値は、次の場所にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

Ignore Bad Oof Rule レジストリ エントリが存在し、1 以上の値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Ignore Bad Oof Rule レジストリ エントリは、Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 のための構成設定であり、Microsoft サポート技術情報の文書番号 828875「Exmerge.exe ユーティリティを使用後に Exchange メールボックスを移動できない」(http://go.microsoft.com/fwlink/?LinkID=3052&kbid=828875) で説明されている修正プログラムで機能するように特別に設計されています。

Microsoft Exchange Mailbox Merge プログラム (Exmerge.exe) を使用して、あるメールボックス ストアのメールボックスから別のメールボックス ストアのメールボックスにメッセージやその他のアイテムを移動した後、2 番目のメールボックスを移動しようとすると失敗することがあります。この現象は、そのメールボックスに設定されている不在時 (OOF) のルールが正しくないために発生する場合があります。必要な場合は、以下の手順を使用して既定の構成に戻すことができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. 右側のウィンドウで、Ignore Bad Oof Rule 値を見つけ、削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


Ignore Zombie Users レジストリ パラメータが設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange Server コンピュータのレジストリを調べて、Ignore Zombie users レジストリ エントリが存在するかどうかを確認します。このレジストリ値は、次の場所にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Ignore Zombie users レジストリ エントリが存在しており、1 以上の値で構成されていることが Exchange Server アナライザによって検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 5.5 および Exchange 2000 Server を含む混在モードの Exchange Server 組織や、以前に混在モードであった環境では、以下の条件が存在する場合に問題が発生する可能性があります。

  • Exchange Server 5.5 のメールボックスおよびパブリック フォルダのアクセス制御リスト (ACL) を Exchange 2000 Server にアップグレードする。

  • その ACL に、Active Directory® ディレクトリ サービスでは表示されないユーザー アカウントが含まれている。

これらの未使用のアクセス制御エントリ (ACE) は、ゾンビ ユーザーとも呼ばれます。2003 年 3 月に公開された Exchange 2000 Server Service Pack 3 以降の修正プログラムのロールアップで、ゾンビ ユーザーの処理に関する既定の動作が変更されました。Ignore Zombie users レジストリ キーを使用すると、この動作を制御できます。

Ignore Zombie users レジストリ値は、Exchange 2000 Server Service Pack 3 以降がインストールされているサーバーで使用できます。このレジストリ エントリは注意して使用する必要があるため、ゾンビ ユーザーが存在する理由が、待ち時間などの Active Directory コネクタ (ADC) レプリケーションの問題ではないことが確かな場合のみ使用してください。このレジストリ値によって、Exchange Server はゾンビ ユーザーを無視し、メールボックスやパブリック フォルダの ACL からそれらのユーザーを削除します。ACL がアップグレードされた時点で、有効であっても Active Directory 内に存在しないユーザーは削除されます。そのようなユーザーは後で、各 ACL に手動で追加する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、[Ignore Zombie users] の値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Ignore Zombie Users レジストリ キーの使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 812963「Ignore Zombie Users レジストリ キーの使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812963)

  • 文書番号 324323「[XADM] アクセス制御リストの変換中に Active Directory に表示されないユーザー アカウントをスキップする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=324323)


IMAIL 例外処理が手動で無効にされている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ExceptionHandling レジストリ値の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

ExceptionHandling レジストリ値が 0 で構成されていることが検出されると、警告が表示されます。

Exchange Server では、IMAIL 例外処理は既定で有効に設定されており、ユーザー インターフェイスから無効にすることはできません。ただし、IMAIL 例外処理は、レジストリを使用して無効にすることができます。

問題を実際にトラブルシューティンしている場合以外は、IMAIL 例外処理を有効のままにしておくことをお勧めします。たとえば、問題のある MIME (Multipurpose Internet Mail Extensions) または MAPI コンテンツに基づいてイベントをトリガするカスタム アプリケーションがある場合は、IMAIL 例外処理を無効にします。IMAIL 例外処理の無効化は、Microsoft 製品サポート サービスのサポート担当からのアドバイスや指示がある場合にのみ行うようにすることをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

  3. [ExceptionHandling] をダブルクリックします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ExchangeHandling レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 832174「Exchange 2000 Server で IMAIL の例外処理を無効にできない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832174) を参照してください。


インフォメーション ストア サービスがデスクトップと対話するように構成されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange Information Store (MSExchangeIS) サービスの DesktopInteract プロパティの値を判断します。Microsoft Exchange Information Store サービスがデスクトップと対話するように構成されていることが検出されると、エラーが表示されます。

この構成は、Microsoft 製品サポート サービスからの指示に基づいてのみ使用するようにしてください。Microsoft 製品サポート サービスから Microsoft Exchange Information Store サービスをこの構成で実行するように指示されている場合以外は、Microsoft Exchange Information Store サービスのプロパティを、デスクトップと対話しないように再構成することをお勧めします。

Exchange Information Store サービス アカウントを構成するには

  1. [サービス] MMC スナップインを開きます。

  2. Microsoft Exchange Information Store サービスを見つけて停止します。

  3. [Microsoft Exchange Information Store] サービスをダブルクリックします。

  4. [Microsoft Exchange Information Store のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択します。

  5. [デスクトップとの対話をサービスに許可] チェック ボックスをオフにし、[適用] をクリックします。

  6. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  7. [サービス] スナップインを終了します。

正しい Exchange サービス構成の詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


メールボックス ストアの最大データベース サイズを増やす
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下の情報を判断します。

  • Exchange データベース ファイルの完全なパス

  • メールボックス ストアの現在のサイズ

また、Exchange Server アナライザは Win32_OperatingSystem WMI キーに対してクエリを実行し、以下の追加情報を判断します。

  • Exchange サーバー上で実行されている Windows オペレーティング システムのバージョン

  • インストールされている Exchange Server のバージョン

  • インストールされている Exchange Server のエディション

  • Exchange Server の Service Pack のレベル

最後に、Exchange Server アナライザは次のレジストリ エントリも読み取り、Database Size in Gb 値が設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Private-<メールボックス ストアの GUID>

以下の条件に当てはまる場合は、エラーが表示されます。

  • サーバーが Exchange Server 2003 を実行している。

  • Exchange Server 2003 の Service Pack 2 がインストールされている。

  • Exchange Server データベースのサイズが 16 GB を超えている。

  • Database Size in Gb レジストリ値が設定されていない。

このエラーは、その Exchange データベースのサイズが制限値に近づいていることを示します。Exchange Server 2003 の Service Pack 2 では、データベース格納域の制限値が 16 GB から 75 GB に増えています。ただし、新しい制限を使用するには、Exchange Server に Database Size in Gb レジストリ値を手動で追加する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Database Size in Gb レジストリ値を追加してこのエラーを修正するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe または RegEdt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Private-<メールボックス ストアの GUID>

  3. [メールボックス ストアの GUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。[OK] をクリックします。

  6. [メールボックス ストアの GUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の値を入力して、どの時点でデータベースの最大サイズに近づいていることを警告するイベントをログに記録するかを指定します。[OK] をクリックします。

    注 :
    既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。

  9. [メールボックス ストアの GUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。[OK] をクリックします。

    注 :
    既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (05:00:00 時) にデータベース サイズをチェックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server データベースのサイズ制限の構成および管理方法の詳細については、「Database Size Limit Configuration and Management」(http://go.microsoft.com/fwlink/?LinkId=57029) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 Standard Edition および Exchange 2000 Server Standard Edition の最大データベース サイズについては、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイトにある「Why Try Service Pack 2 for Exchange Server 2003?」(http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアの最大データベース サイズを増やす
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下の情報を判断します。

  • Exchange Server データベース ファイルの完全なパス

  • パブリック フォルダ ストアの現在のサイズ

また、Exchange Server アナライザは Win32_OperatingSystem WMI キーに対してクエリを実行し、以下の追加情報を判断します。

  • Exchange サーバー上で実行されている Windows オペレーティング システムのバージョン

  • インストールされている Exchange Server のバージョン

  • インストールされている Exchange Server のエディション

  • Exchange Server の Service Pack のレベル

最後に、Exchange Server アナライザは次のレジストリ エントリも読み取り、Database Size in Gb 値が設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

以下の条件に当てはまる場合は、エラーが表示されます。

  • サーバーが Exchange Server 2003 を実行している。

  • Exchange Server 2003 の Service Pack 2 がインストールされている。

  • Exchange データベースのサイズが 16 GB を超えている。

  • Database Size in Gb レジストリ値が設定されていない。

このエラーは、その Exchange Server データベースのサイズが制限値に近づいていることを示します。Exchange Server 2003 の Service Pack 2 では、データベース格納域の制限値が 16 GB から 75 GB に増えています。ただし、新しい制限を使用するには、Exchange Server に Database Size in Gb レジストリ値を手動で追加する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
Database Size in Gb レジストリ値を追加してこのエラーを修正するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe や RegEdt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. [PublicStoreGUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。[OK] をクリックします。

  6. [PublicStoreGUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の値を入力して、どの時点でデータベースの最大サイズに近づいていることを警告するイベントをログに記録するかを指定します。[OK] をクリックします。

    注 :
    既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。

  9. [PublicStoreGUID] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。[OK] をクリックします。

    注 :
    既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (05:00:00 時) にデータベース サイズをチェックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange データベースのサイズ制限を構成および管理する方法の詳細については、「Database Size Limit Configuration and Management」(http://go.microsoft.com/fwlink/?LinkId=57029) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 Standard Edition および Exchange 2000 Server Standard Edition の最大データベース サイズについては、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイトにある「Why Try Service Pack 2 for Exchange Server 2003?」(http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


トランザクション ログのログ バッファの設定を強化する
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、サーバーのログ バッファの数が少なすぎると判断しました。サーバーの Database (Information Store Instance)\Log Record Stalls/sec の値が、1 秒あたり 10 ストールを超えていることが検出されました。値が 10 を超えている場合、トランザクション ログへのバックアップの書き込みが行われていることを示します。この状況は、トランザクション ログ ドライブのスループット容量を超えているか、ログ バッファの設定が小さすぎるために発生します。

ログの書き込み I/O は順次に実行されるシングル スレッドです。したがって、ログ I/O の待ち時間は、多くの場合システムのボトルネックになります。ログ I/O は最初にログ バッファに書き込まれ、次に高速コミットまたは容量コミットのいずれかによりバッファがクリアされます。高速コミットでは、ログ バッファが直ちにディスクに書き込まれます。容量コミットでは、ログ バッファがいっぱいになったときにディスクに書き込まれます。

ログ バッファのサイズを増やすと、容量フラッシュの頻度が低下し、ログの書き込みサイズが増加するため、全体的なログへの書き込みの待ち時間が減少します。ログ I/O の書き込みの待ち時間を減らすことは、Exchange 展開のパフォーマンスおよびスケーラビリティを向上させる重要な方法です。

一般的には、バッファ サイズを Exchange Server 2003 の場合は最大 9,000、Exchange 2000 Server の場合は最大 512 にすることをお勧めします。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
この警告を修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=Exchange 組織名] の順に展開します。

  3. [CN=Administrative Groups] を展開し、[CN=AdministrativeGroupName] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=ExchangeServerName] を展開し、[CN=InformationStore] を展開します。次に、[CN=Storage Group Name] を右クリックし、[プロパティ] をクリックします。

  5. [Select a property to view] ボックスで、[msExchESEParamLogBuffers] をクリックします。

  6. [Edit Attribute] ボックスに、実行している Exchange のバージョンに適切な msExchESEParamLogBuffers の値を入力し、[Set] をクリックします。

    注 :
    Exchange 2000 Server、Exchange 2000 Server Service Pack 1 (SP1)、または Exchange 2000 Server Service Pack 2000 (SP2) の場合は、この値を 512 に設定します。Exchange Server 2003 の最初のリリース、または Exchange Server 2003 SP1 を実行しているコンピュータは、この値を 9,000 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • バッファの操作の詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328466) を参照してください。


Initial Memory Percentage が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Initial Memory Percentage の値が設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Initial Memory Percentage の値が存在し、0 を超える値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Initial Memory Percentage レジストリ設定は、Exchange インフォメーション ストアに割り当てられるメモリの初期容量を Exchange サーバーの総物理メモリの 10% に調整するためのメカニズムとして導入されました。この初期割り当てで開始し、そこから増加するようにすれば、仮想メモリの断片化が頻繁に発生することはありません。このレジストリ値を任意に設定することはせず、Microsoft 製品サポート サービスからのアドバイスや指示に基づいてのみ使用するようにしてください。

Exchange Server 2003 以降のバージョンの Exchange Server では、仮想メモリの断片化を削減するのに役立つ、Microsoft Windows® 2000 Advanced Server および Windows Server™ 2003 にある特殊な起動スイッチがサポートされています。さらに、Exchange Server クラスタでの仮想メモリの断片化を防止するのに役立つ変更も追加されています。このため、Initial Memory Percentage レジストリ値は、Exchange Server 2003 以降のバージョンの Exchange Server では必要なくなりました。

Initial Memory Percentage レジストリ値は、Exchange 2000 Server を実行しているコンピュータでのみ機能します。この値が存在しても Exchange Server 2003 および Exchange Server 2007 では無視されるため、この値の効果はまったくありません。そのため、この Exchange サーバーを Exchange 2000 Server から Exchange Server 2003 にアップグレードする前に、このレジストリ エントリを削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Initial Memory Percentage レジストリ設定を削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のウィンドウで、Initial Memory Percentage 値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。
  • このレジストリ値の使用時に発生する既知の問題の詳細については、Microsoft サポート技術情報の文書番号 810883「[XADM] Initial Memory Percentage レジストリ値が有効にならない」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810883) を参照してください。

  • レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?Linkid=3052&kbid=256986) を参照してください。


Initial Reserve Size KB レジストリ エントリが設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-04-27

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Initial Reserve Size KB レジストリ エントリが存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

Initial Reserve Size KB レジストリ値が存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Initial Reserve Size KB レジストリ値は、ヒープ領域用の追加のメモリを確保しておくために使用されます。指定された値は KB 単位です。ほとんどの Exchange サーバーでの既定値は 655360 KB (640 MB に相当) です。この値を減らすことにより、利用可能な空きメモリの容量を増やし、仮想メモリの断片化を削減することができます。この値の設定は、Microsoft 製品サポート サービスのサポート担当からのアドバイスや指示がある場合にのみ行うようにしてください。このメッセージは情報メッセージであり、このレジストリ値が Microsoft 製品サポート サービスのサポート担当者のアドバイスに基づいて追加されている場合は、修正操作を行う必要はありません。

このエントリが正しく設定されていないと考えられる場合は、そのエントリを削除し、既定の構成に戻すことができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成設定に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

  3. Initial Reserve Size KB という名前の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

仮想メモリ断片化のトラブルシューティングの詳細については、Microsoft サポート技術情報の文書「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。


Exchange データベースの legacyExchangeDN が Exchange サーバーと一致しない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server コンピュータ上のすべてのメールボックス ストア データベースについて legacyExchangeDN 属性値を判断します。メールボックス ストアの legacyExchangeDN 属性の値が、そのメールボックスを格納している Exchange Server コンピュータと一致しないことが検出されると、エラーが表示されます。

legacyExchangeDN が一致しないのは、障害回復時にデータベースを回復するため管理者が Active Directory を変更したことが原因として考えられます。このエラーを解決するには、LDP (ldp.exe) ツールや Active Directory サービス インターフェイス (ADSI) Edit などの Active Directory エディタを使用して、legacyExchangeDN 属性を変更する必要があります。

legacyExchangeDN 属性が正しいことを確認するには、このデータベースが格納されているサーバーの legacyExchangeDN 属性を調べます。このデータベースはそのサーバーの子オブジェクトであり、このデータベースにも同じ legacyExchangeDN が設定されるためです。

このエラーが発生していない、この Exchange サーバー上にある他のデータベースも調べる必要があります。これらのデータベースにも、同じ legacyExchangeDN が設定されています。他にもこの属性を持つシステム オブジェクトが複数存在することに注意してください。データベースで legacyExchangeDN 属性が一致しないという状況では、他の複数のシステム オブジェクトでもこの属性が一致していない可能性が高いです。したがって、LDP や ADSI Edit を使用して legacyExchangeDN 値を修正する場合は、他のすべてのシステム オブジェクトについても同様の修正を行う必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration[ドメイン名]] を展開し、[CN=Configuration,DC=ドメイン名,DC=ドメイン サフィックス] を展開します。

  3. [CN=Services] を展開し、[CN=Microsoft Exchange] を展開します。

  4. [CN=組織名] を展開し、[CN=Administrative Groups] を展開します。次に、[CN=管理グループ名] を展開します。

  5. [CN=Servers] を展開し、[CN=サーバー名] を展開します。次に、[CN=InformationStore] を展開します。

  6. [CN=ストレージ グループ名] を選択し、右側のウィンドウで、legacyExchangeDN 属性が一致しないメールボックス ストアを右クリックして [プロパティ] をクリックします。

  7. 下にスクロールして legacyExchangeDN を選択し、[Edit] をクリックします。

  8. [Value] ボックスに、正しい legacyExchangeDN を入力します。

  9. Active Directory エディタを終了し、Exchange Server コンピュータを再起動して、変更を有効にします。

ADSI Edit を使用した legacyExchangeDN 属性の新規作成の詳細については、Microsoft サポート技術情報の文書番号 273863「[HOW TO] ADSI Edit を使用して legacyExchangeDN 属性を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863) を参照してください。


Exchange データベースに legacyExchangeDN 値がない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server コンピュータ上のすべてのメールボックス ストア データベースについて legacyExchangeDN 属性値を判断します。legacyExchangeDN 属性の値がどのメールボックス ストアにもないことが検出されると、エラーが表示されます。

legacyExchangeDN 属性がない原因として、管理者が障害回復時にデータベースを回復しようとして Active Directory を変更したことが考えられます。このエラーを解決するには、LDP (ldp.exe) ツールや Active Directory サービス インターフェイス (ADSI) Edit などの Active Directory エディタを使用して、legacyExchangeDN 属性を変更する必要があります。

legacyExchangeDN 属性が正しいことを確認するには、このデータベースが格納されているサーバーの legacyExchangeDN 属性を調べます。このデータベースはそのサーバーの子オブジェクトであり、このデータベースにも同じ legacyExchangeDN が設定されるためです。

このエラーが発生していない、この Exchange サーバー上にある他のデータベースも調べる必要があります。これらのデータベースにも、同じ legacyExchangeDN が設定されています。この同じ属性が設定されているシステム オブジェクトが、他にもいくつかあることを認識する必要があります。データベース上に legacyExchangeDN 属性がない状況を考慮すると、その他のいくつかのシステム オブジェクトにもこの属性がない可能性があります。そのため、LDP や ADSI Edit を使用して新しい legacyExchangeDN 値を追加する場合は、他のすべてのシステム オブジェクトに対しても同じ操作が必要になります。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration]、[ドメイン名]、[CN=Configration]、[DC=ドメイン名]、[DC=ドメイン サフィックス] の順に展開します。

  3. [CN=Services] を展開し、[CN=Microsoft Exchange] を展開します。

  4. [CN=組織名] を展開し、[CN=Administrative Groups] を展開します。次に、[CN=管理グループ名] を展開します。

  5. [CN=Servers] を展開し、[CN=<サーバー名>] を展開します。次に、[CN=InformationStore] を展開します。

  6. [CN=ストレージ グループ名] を選択します。次に、右側のウィンドウで、legacyExchangeDN 属性がないメールボックス ストアを右クリックし、[プロパティ] をクリックします。

  7. 下にスクロールして legacyExchangeDN を選択し、[Edit] をクリックします。

  8. [Value] ボックスに、正しい legacyExchangeDN を入力します。

  9. Active Directory エディタを終了し、Exchange Server コンピュータを再起動して、変更を有効にします。

ADSI Edit を使用した legacyExchangeDN 属性の新規作成の詳細については、Microsoft サポート技術情報の文書番号 273863「[HOW TO] ADSI Edit を使用して legacyExchangeDN 属性を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=273863) を参照してください。


LimitBodyParts パラメータが手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、メッセージ内の添付ファイルに対する既定の制限が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent\LimitBodyParts

LimitBodyParts レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

設計やセキュリティ上の理由から、Exchange Server では添付ファイル (ボディ部とも呼ばれます) の数が 250 に制限されています。1 つのメッセージに 250 を超える添付ファイルが含まれている場合は、MAPI_E_TOO_BIG エラーが生成されます。さらに、Microsoft Exchange インフォメーション ストア サービスでは、多数のファイルが添付されているメッセージの処理中に、過剰なメモリおよび CPU リソースが消費される可能性があります。

管理者は、LimitBodyParts レジストリ値を追加し、そのレジストリを 250 より大きな値を使用するように構成することができます。このエントリがない場合は、既定値の 250 が使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

LimitBodyParts レジストリ値を表示または変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

  3. LimitBodyParts 値を調べ、必要に応じて変更します。このレジストリには、250 ～ 4294967295 の範囲の任意の整数を入力できます。

  4. 変更を行った場合は、Exchange Server コンピュータを再起動して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


LimitEmbeddingDepth パラメータが手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange における既定の MIME ヘッダー制限が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

LimitEmbeddingDepth に何らかの値が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange 2000 Server Service Pack 3、Exchange Server 2003 および Exchange Server 2007 には、大きな MIME や不規則な形式の MIME の処理方法を定義できる、インフォメーション ストア プロセス (store.exe) の更新された機能が含まれています。この機能は、悪意のある MIME メッセージと、意図せず大きく、複雑な MIME メッセージの両方によるサービス拒否攻撃に対抗して、Exchange Server をさらに強力にセキュリティで保護するために追加されました。ストアに送信される MIME メッセージに対して設定される制限の例としては、受信者数の制限、埋め込まれたメッセージ数の制限、個々の MIME ヘッダーのサイズの制限などがあります。

インフォメーション ストア プロセス内には、これらの各種 MIME ヘッダー制限の既定値が設定されています。ただし、これらの制限のいずれかを定義するためにレジストリ キーが設定されると、このレジストリ キーによって store.exe の既定値が上書きされます。ある MIME メッセージが各種制限のいずれかを超えると、送信者に配信不能レポート (NDR) が送信されます。

MIME の埋め込みの深さの制限とは、互いの中に埋め込むことのできる MIME メッセージの数を指します。たとえば、メッセージ (m2) が添付されているメッセージ (m1) を受信するとします。添付されたメッセージ (m2) を開くと、メッセージ (m2) にもメッセージ (m3) が添付されていることがわかります。この場合、元のメッセージ (m1) には、3 レベルの深さまで埋め込まれたメッセージがあることになります。Exchange では、既定で、100 レベルの深さまで埋め込まれたメッセージが許可されます。100 レベルの深さを超えるメッセージが埋め込まれたメッセージを受信すると、Exchange サーバーがそのメッセージの "包みを開け"、解析して、MAPI に変換するのに時間がかかるため、サーバー上のすべてのメモリが消費される可能性があります。どのような電子メール クライアントやサーバーでも、これだけの深さまでメッセージが埋め込まれたメッセージを生成する可能性はほとんどありません。こうしたメッセージは、どちらかと言えば、メッセージング システムにサービス拒否攻撃を試みている、悪意のあるユーザーによる可能性の方が高くなります。

既定の構成に戻すには

  • 必要な操作はありません。このレジストリ エントリは、Microsoft サポート技術情報の文書番号 833607「Exchange 2000 Server または Exchange Server 2003 で Microsoft Exchange Information Store サービスの CPU 使用率が 100% になる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=833607) の修正プログラムをインストールしている場合にのみ存在します。この修正プログラムによって、LimitEmbeddingDepth レジストリ エントリが作成され、その値が 10 に設定されます。

Exchange Server の Service Pack と修正プログラムの詳細については、Microsoft サポート技術情報の文書番号 328839「Exchange の Service Pack と修正プログラムを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328839) を参照してください。


LimitNestingLevels パラメータが手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange の既定の MIME (Multipurpose Internet Mail Extensions) ヘッダー制限が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

LimitNestingLevels の値が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

メッセージ アイテム内の MIME ボディ部は、入れ子構造にすることができます。入れ子の階層が深いと、メッセージ全体をデコードするために、変換処理でより多くのリソースが必要になります。入れ子の階層が 700 になった MIME ボディ部を持つメッセージを 1 通処理する場合、最大 10 分かかることがあります。入れ子になった MIME ボディ部を持つメッセージをインターネットを介して受信する場合、MIME ボディ部の変換処理が原因で、これらのメッセージの配信が遅くなることがあります。これらのメッセージを配信する際、サーバーには大量のシステム リソース、特にメモリが必要になります。このようなメッセージを同時に多数受信すると、仮想メモリの残量が不足していることを示すメッセージが表示される場合があります。

MIME の入れ子レベルの制限とは、相互に入れ子にできる MIME コンテンツの種類 (multipart/mixed、multipart/alternative など) の数のことです。ほとんどの電子メール クライアント (Microsoft Outlook®、Outlook Express など) および電子メール サーバーによって生成されるメッセージには、入れ子構造になった MIME コンテンツの種類はほとんど含まれません。たとえば、通常のメッセージは複数の返信があったとしても、MIME メッセージでは単一のコンテンツの種類として表示されます。入れ子レベルが複数になるのは、通常、特定の使用目的 (ワークフロー アプリケーションなど) のために MIME メッセージを作成するプロセスが自動化されているか、またはメール サーバー上のリソースを消費するという悪質な目的でメッセージが作成されているためです。

Exchange Server は、コンテンツの種類に従って入れ子レベルを適用するだけでなく、LimitNestingLevels 値 (レジストリ値として、またはストア プロセスでの既定値として定義される値) を使用して、埋め込みメッセージに制限を適用します。LimitNestingLevels レジストリ値を定義しない場合、既定値 30 が入れ子レベルに適用されます。埋め込みメッセージの制限は、LimitNestingLevels 値を 16 倍することによって定義します。したがって、埋め込みメッセージ数の既定値は 480 です。たとえば、LimitNestingLevels の値が 5 に構成されている場合は、最大 80 の添付ファイルを受け取ることができます。

既定の構成に戻すには

  • 操作は特に必要ありません。Exchange Server アナライザによって、参考のために既定以外の構成が表示されます。

LimitNestingLevels レジストリ値に関する Exchange 2000 Server の修正プログラムの詳細については、Microsoft サポート技術情報の文書番号 289775「[XADM] 埋め込みメッセージが多数あると Exchange 2000 Server でメモリ リークが発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=289775) を参照してください。


LimitRecipient パラメータが手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange における既定の MIME ヘッダー制限が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent

LimitRecipients に何らかの値が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange 2000 Server Service Pack 2 (SP2) およびそれ以降のバージョンの Exchange Server には、大きな MIME や不規則な形式の MIME の処理方法を定義できる、ストア プロセス (store.exe) の更新された機能が含まれています。この機能は、悪意のある MIME メッセージと、例外的な (意図せず大きく、複雑な) MIME メッセージの両方によるサービス拒否攻撃の標的としての Exchange Server をさらに強力にセキュリティで保護するために追加されました。ストアに送信される MIME メッセージに対して設定される制限の例としては、受信者数の制限、埋め込まれたメッセージ数の制限、個々の MIME ヘッダーのサイズの制限などがあります。以前のバージョンの Exchange では、Exchange ストア内に MIME ヘッダーを無制限に入力して処理することが可能であったため、MIME メッセージが過剰に大きかったり、複雑であったりすると、MIME の解析、インデックス作成、処理などにほぼすべてのリソース (主に CPU) が消費されてしまう可能性がありました。

インフォメーション ストア プロセス内には、これらの各種 MIME ヘッダー制限の既定値が設定されています。ただし、これらの制限のいずれかを定義するためにレジストリ キーが設定されると、このレジストリ キーによって store.exe の既定値が上書きされます。ある MIME メッセージが各種制限のいずれかを超えると、送信者に配信不能レポート (NDR) が送信されます。

LimitRecipients レジストリ キーが設定されているとすると、このキーは公開されていないため、Microsoft 製品サポート サービスからのアドバイスの結果である可能性があります。したがって、この設定を変更することはお勧めできません。

ストア プロセスでの LimitRecipients の既定値 (レジストリキーが存在しない場合) は、MIME メッセージあたり 65,535 の受信者数です。


レプリケートされたディスク ストレージを持ち、Exchange Server 2003 を実行しているサーバー用にログ バッファが最適化されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の条件に当てはまるかどうかを判断します。

  • コンピュータが Exchange Server 2003 を実行している。

  • msExchESEParamLogBuffers の値が 0 ～ 8,960 である。

Exchange Server アナライザは、Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、次の条件に当てはまるかどうかを判断します。

  • VMLargestBlockSize の値が 150,000,000 より大きい。

Exchange Server アナライザは、次のサービスが実行されているかどうかを判断します。

  • GeoSpanService

  • SRDFService

上記のすべての条件に当てはまる場合、エラーが表示されます。

ESE (Extensible Storage Engine) は、トランザクションをトランザクション ログにコミットする前に、ログ バッファを使用してメモリにトランザクションを保持します。十分なログ バッファがない場合、トランザクション ログ ドライブで過度なディスク I/O が発生して、パフォーマンスが低下する可能性があります。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
このエラーを修正するには

  1. Active Directory サービス インターフェイス (ADSI) Edit で、[Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=ExchangeOrganizationName] の順に展開します。

  2. [CN=Administrative Groups] を展開し、[CN=AdministrativeGroupName] を展開します。次に、[CN=Servers] を展開します。

  3. [CN=ExchangeServerName] を展開し、[CN=InformationStore] を展開します。次に、[CN=Storage Group Name] を右クリックし、[プロパティ] をクリックします。

  4. [Select a property to view] ボックスで、[msExchESEParamLogBuffers] をクリックします。

  5. [Edit Attribute] ボックスで、msExchESEParamLogBuffers に「9000」と入力し、[Set] をクリックします。

  6. [適用] をクリックし、[OK] をクリックします。

  7. 変更を有効にするには、Microsoft Exchange Information Store サービスを再開する必要があります。

詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが原因で応答を停止できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466) を参照してください。


Exchange Server 2003 が実行されている、多数のメールボックスを含むサーバーのログ バッファが十分でない可能性がある
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-03-27

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、以下の条件に当てはまるかどうかを判断します。

  • コンピュータが Exchange Server 2003 を実行している。

  • msExchESEParamLogBuffers の値が 0 ～ 8,960 の範囲にある。

  • ストレージ グループ内のメールボックスの数が 500 を超えている。

Exchange Server アナライザは、Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、以下の条件に当てはまるかどうかを判断します。

  • VMLargestBlockSize の値が 150,000,000 を超えている。

これらのすべての条件に当てはまると、警告が表示されます。

ESE (Extensible Storage Engine) は、トランザクション ログにコミットする前に、ログ バッファを使用してトランザクションをメモリ内に保持します。十分なログ バッファが存在しないと、トランザクション ログ ドライブで過剰なディスク I/O が発生する可能性があり、それによりパフォーマンスが低下します。

この警告を修正するには、次の操作を行います。

  1. Active Directory サービス インターフェイス (ADSI) Edit で、[Configuration] コンテナをダブルクリックし、[CN=<サービス>] を展開します。次に、[CN=Microsoft Exchange] を展開し、[CN=<Exchange 組織名>] を展開します。

  2. [CN=<管理グループ>] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=<サーバー>] を展開します。

  3. [CN=<Exchange サーバー名>] を展開し、[CN=<インフォメーション ストア>] を展開します。次に、[CN=<ストレージ グループ名>] を右クリックし、[プロパティ] をクリックします。

  4. [Select a property to view] ボックスで、[msExchESEParamLogBuffers] をクリックします。

  5. [Edit Attribute] ボックスで、msExchESEParamLogBuffers に「9000」と入力し、[Set] をクリックします。

  6. [適用] をクリックし、[OK] をクリックします。

  7. 変更を有効にするには、Microsoft Exchange Information Store サービスを再開する必要があります。
注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

詳細については、Microsoft サポート技術情報の文書番号 328466「非常に低く設定された ESE ログ バッファは、Microsoft Exchange Information Store サービスが応答を停止するのを引き起こす可能性があります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328466) を参照してください。


ログ ファイルがネットワーク ドライブに格納されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループ オブジェクトの msExchESEParamLogFilePath 属性値を判断します。この属性は、ストレージ グループ内のデータベースによって使用されるトランザクション ログ ファイルの場所を指定します。

Exchange Server アナライザは Active Directory に対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性のエントリ数は、メールボックス ストア上のメールボックスの数を表します。

Exchange Server アナライザによって、50 を超えるメールボックスが配置された Exchange Server の msExchESEParamFilePath 属性が \\ で始まっていることが検出されると、エラーが表示されます。

このエラーは、ストレージ グループのトランザクション ログ ファイルがネットワーク共有上に格納されていることを示します。msExchESEParamLogFilePath 属性が \\ で始まる場合、ログ ファイルのパスに汎用名前付け規則 (UNC) パスが使用されていることを示します。ネットワーク接続が中断されると、トランザクション ログおよびデータベースのエラーの原因となり、データ損失やデータベースの破損に至るため、共有への格納は推奨されません。この問題はできだけ早期に修正することをお勧めします。

このエラーを修正するには

  • トランザクション ログをネットワーク共有からローカル ディスクに移動します。パフォーマンスを最適化するには、すべてのトランザクション ログを異なるドライブに置きます。

トランザクション ログを別の場所へ移動する方法の詳細については、Microsoft サポート技術情報の文書番号 239944「[XADM] トランザクションまたはシステム ログを別の場所に移動する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=239944) を参照してください。


ログ生成の不一致
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、ログ ファイルの生成に不一致があると判断しました。このエラーは、トランザクション ログ ファイルの名前の変更が不適切なシーケンス番号で行われたことを示しています。

Microsoft トランザクション ログ ファイルは、EnnXXXXX.log という形式に基づいて名前を変更されました。

  • XXXXX は、5 桁の 16 進数によるシーケンス番号です。新しいトランザクション ログ ファイルのセットが生成されると、最初のログには 00001、次のログには 00002 という順序で番号が付きます。各トランザクション ログ レコードにはヘッダーに独自のシーケンス番号があるため、ログ ファイル名が変更されているかどうかを判断できます。

  • Enn は、ログのプレフィックスです。このストレージ グループのすべてのトランザクション ログで共有される、3 文字のシーケンスです。通常、プレフィックスは、E00、E01、E02、E03、または R00 (回復用のストレージ グループ) になります。

書き込まれている現在のログは、ログのプレフィックスのみの名前になります。このログは、ファイルが閉じられて新しい現在のログが生成されるまでシーケンス番号を取得しません。したがって、現在のログ ファイルは E00.log という名前になります。このログ ファイルがいっぱいになると、E0012345.log のような名前に変更されます。新しい E00.log は、12346 の内部のシーケンス番号で生成されます。

このエラーを修正するには

  • 適切なシーケンス番号にログ ファイルの名前を変更する。
内部のシーケンス番号を表示するには

  • 次のコマンドを実行します。

    C:\Program Files\Exchsrvr\Bin\Eseutil.exe /ML <ログ ファイル名>

    このコマンドの出力の lGeneration 値が、ログ ファイルの実際のシーケンス番号を一覧にします。


ログのペアに不整合がある
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、必要なログ ファイルの一部に不整合があると判断しました。このエラーは、ログ ファイルに変更が加えられているか、あるいは手動による移動、コピー、名前の変更、または削除が行われた可能性があることを示します。

このエラーを修正するには

  • このログ ファイルの高度な分析については、Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?LinkId=31845) にお問い合わせください。


ログの署名の不一致
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、1 つまたは複数のログ ファイルで、同じフォルダの他のログ ファイルとログの署名が一致していないと判断しました。

この問題は、ログ ファイルを手動で移動、削除、または不適切な操作を行わない限り発生しません。

注 :
これは高度な回復のシナリオであるため、実装の前に Microsoft サポート オンライン (http://go.microsoft.com/fwlink/?LinkId=31845) に問い合わせることをお勧めします。

各 Exchange トランザクション ログ ファイルには、ログの署名という署名がスタンプされます。この署名は、同じ系列のログに属する個別のログ ファイルを識別するものです。各 Exchange データベースは、データベースが最後に添付されたトランザクション ログ系列のログの署名を記録します。

Exchange データベースには、データベースの署名という署名もあります。データベースの署名は、データベースを最初に作成するときに生成されます。Eseutil を使用してデータベースの最適化または修復を行う場合、修復および最適化の処理がこれらの変更をトランザクション ログに記録せずにデータベース ファイルを変更するため、この署名が変更されます。ログを記録する目的で、修復または最適化の操作結果であるデータベースは、新しいデータベースまたは別のデータベースとなります。

データベースの署名と異なり、ログの署名はログ ファイルの系列の有効期限期間は変更されません。

ログ ファイルには、ログが作成されたときに付加されたすべてのデータベースに関するデータベースの署名が記録されます。データベースでは、データベースが付加されている最新のログ系列に関するログの署名が記録されます。したがって、データベースの署名およびログの署名は、データベースとトランザクション ログ ファイルを対応させるのに役立ちます。

Exchange データベースは、ログのセットから切断して、別のセットに付加することができます。この操作を実行するには、データベースを別のストレージ グループに移動するか、ストレージ グループのすべてのトランザクション ログを削除して新しいログの系列を開始します。

データベースがダーティ シャットダウン状態にある場合は、データベース ヘッダーにログの署名と一致する署名があるトランザクション ログ ファイルのみ、データベースに正常に再生することができます。ダーティ シャットダウン状態では、データベースは特定のログ ストリームに接続したままであり、そのログ ストリームを使用してのみ回復を実行できます。

データベースがクリーン シャットダウン状態にある場合は、データベース ヘッダーに現在のログの署名と一致する署名がないトランザクション ログ ファイルも再生することができます。この処理は、次の状況でのみ成功します。

  1. 以前の一連のログ ファイルの最後に、データベースが正常にシャットダウンされている。

  2. その後、データベースは新しい一連のトランザクション ログ ファイルに接続され、新しいログのセットにデータベースが最初に接続しているトランザクション ログにアクセスできる。

このエラーを修正するには

  • データベースの履歴と、データベースに関してトランザクション ログが生成された状況を確認する必要があります。

  • この状況では、回復を行う前に、トランザクション ログとデータベース ファイルの両方のコピーを常に作成しておきます。回復に失敗した場合、トランザクション ログまたはデータベース ファイルが変更され、他の回復を試すことができなくなる可能性があります。

  • データベースでトランザクション ログのセットを一度に 1 つだけ再生します。他のトランザクション ログは、回復フォルダから移動しておきます。

  • データベースがダーティ シャットダウン状態にある場合は、データベースを接続してクリーン シャットダウン状態にするトランザクション ログを、正常に再生する必要があります。その後、2 つ目のログ ファイルのセットをデータベースで再生できます。

  • データベースがクリーン シャットダウン状態にある場合は、ログまたはデータベースを調査できず、最終的に最初に再生するトランザクション ログのセットを判断することができません。


ログオンが特定のユーザーに制限されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Exchange Server コンピュータの次のレジストリ エントリを読み取り、Exchange インフォメーション ストアへのログオンを許可されているユーザーのリストが制限されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Logon Only As

Logon Only AS レジストリ値が存在することが検出されると、警告が表示されます。

Logon ONly As レジストリ値は、Exchange インフォメーション ストアにログオンする権限のあるアカウントの legacyExchangeDN 属性のリストが含まれている複数行文字列値 (REG_MULTI_SZ) です。このレジストリ値 (既定では存在しない) は、通常、トラブルシューティング、保守、メールボックスの移動処理などの期間中に追加されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、Logon Only As レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

Logon Only As レジストリ値の詳細については、Microsft サポート技術情報の文書番号 146764「XADM: インフォメーション ストアへのログオンを制限します。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=146764) を参照してください。

メールボックスの移動処理中にログオンを制限する方法の詳細については、Microsoft サポート技術情報の文書番号 218920「XADM:移動の間、ログオンを防ぐ方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=218920) を参照してください。


Lookup SID Cache Expire レジストリ値が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、Lookup Sid Cache Expire レジストリ エントリが存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

以下の条件に当てはまる場合は、既定以外の構成であることを示すメッセージが表示されます。

  • Lookup Sid Cache Expire レジストリ エントリが存在する。

  • Lookup Sid Cache Expire レジストリ エントリに 3,600 以外の値が設定されている。

Exchange 2000 Server Service Pack 3 以降を実行している Exchange サーバーでは、インフォメーション ストアはセキュリティ識別子 (SID) を含むキャッシュを作成し、SID がユーザー オブジェクトかグループ オブジェクトかを示します。このキャッシュは、最初にパブリック フォルダへのアクセスがあったときに作成されます。キャッシュが作成されると、アカウントの SID を参照するすべての呼び出しは、まずインフォメーション ストア キャッシュに対して行われます。SID がインフォメーション ストア キャッシュにない場合はドメイン コントローラへの呼び出しが行われ、次にその SID に関する情報がキャッシュに追加されます。

既定では、キャッシュが保持される時間は 1 時間です。キャッシュのエントリが 8 KB (既定値) を超える場合、新しいキャッシュ エントリ用の容量を確保するために古いエントリが削除されます。2 つのレジストリ キーを使用して、既定のキャッシュ保持時間 (Lookup Sid Cache Expire) と既定のキャッシュ サイズ (Lookup Sid Cache Size) を変更できます。この既定値を変更することでパフォーマンスが向上することが確実な場合を除き、この既定値を変更しないことをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. 右側のペインで、Lookup Sid Cache Expire 値を見つけて削除します。Lookup SID Cache Size 値が設定されている場合、それも削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Lookup Sid Cache Expire レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 328907「[XADM]アクセス制御リストがパフォーマンスの原因パブリック フォルダ低下をアップグレードします。Exchange 2000 SP2 が修正プログラムに必要。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328907) を参照してください。


Lookup SID Cache Size レジストリ値が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、Lookup Sid Cache Size レジストリ エントリが存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

以下の条件に当てはまる場合は、既定以外の構成であることを示すメッセージが表示されます。

  • Lookup Sid Cache Size レジストリ エントリが存在する。

  • Lookup Sid Cache Size レジストリ エントリに 1,024 以外の値が設定されている。

Exchange 2000 Server Service Pack 3 以降を実行している Exchange サーバーでは、インフォメーション ストアはセキュリティ識別子 (SID) を含むキャッシュを作成し、SID がユーザー オブジェクトかグループ オブジェクトかを示します。このキャッシュは、最初にパブリック フォルダへのアクセスがあったときに作成されます。キャッシュが作成されると、アカウントの SID を参照するすべての呼び出しは、まずインフォメーション ストア キャッシュに対して行われます。SID がインフォメーション ストア キャッシュにない場合はドメイン コントローラへの呼び出しが行われ、次にその SID に関する情報がキャッシュに追加されます。

既定では、キャッシュが保持される時間は 1 時間です。キャッシュのエントリが 8 KB (既定値) を超える場合、新しいキャッシュ エントリ用の容量を確保するために古いエントリが削除されます。2 つのレジストリ キーを使用して、既定のキャッシュ保持時間 (Lookup Sid Cache Expire) と既定のキャッシュ サイズ (Lookup Sid Cache Size) を変更できます。この既定値を変更することでパフォーマンスが向上することが確実な場合を除き、この既定値を変更しないことをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. 右側のペインで、Lookup Sid Cache Size 値を見つけて削除します。Lookup SID Cache Expire 値が設定されている場合、それも削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Lookup Sid Cache Size レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 328907「[XADM]アクセス制御リストがパフォーマンスの原因パブリック フォルダ低下をアップグレードします。Exchange 2000 SP2 が修正プログラムに必要。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328907) を参照してください。


仮想メモリ不足のエラー イベントが変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリのエントリを読み取り、仮想メモリの断片化に関するイベントをログ出力する際のしきい値が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\VM Error Level

VM Error Level レジストリ値が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

32 ビット Microsoft Windows® システムには、物理メモリ (システムに実装されている実際のメモリの容量) と仮想メモリ アドレス スペース (仮想化された 4 GB のメモリ スペース) という 2 種類のメモリがあります。システムに取り付けられている物理メモリの量とは無関係に、仮想アドレス スペースの合計サイズは常に同じ 4 GB です。すべての 32 ビット アプリケーションに当てはまるわけではありませんが、Exchange Server の場合、仮想アドレス スペースは仮想メモリに一致するため、これらの用語は同義で使用されます。

通常の動作中、Exchange インフォメーション ストアは繰り返し仮想メモリの割り当て、使用、および割り当ての解除を行います。仮想メモリの割り当て、使用、および割り当て解除が頻繁に行われると、仮想メモリの断片化が発生することがあります。仮想メモリの断片化は、時間が経過すると発生することがあるファイル システムの断片化に似ています。しばらくすると、割り当てられた仮想メモリのセグメントが連続的ではなくなって、パフォーマンスが低下し始めます。ファイル システムの場合、ファイル システムを最適化するアプリケーションを実行することができ、これはほとんどの場合、システムがオンライン状態でアクセスされている間に実行できます。仮想メモリの断片化が発生した場合の最適化ツールはありません。この問題を解決するには、Microsoft Exchange Information Store サービスを停止してから開始するか、システムを再起動する必要があります。

Exchange Server コンピュータで、連続して確保できる仮想アドレス スペースが 16 MB 未満になると、次のエラー メッセージがアプリケーション イベント ログに出力されます。

ソース : | MSExchangeIS
分類 : | パフォーマンス
ID : | 9582
種類 : | エラー
説明 : | Exchange サーバーの実行に必要な仮想メモリが断片化しているため、通常の操作を開始できない可能性があります。Exchange 関連のサービスをすべて再開して、この問題を修正することをお勧めします。

VM Error Level レジストリ値を使用すると、管理者が、既定の 16 MB レベルの警告を上書きして代わりの値を設定できるようになります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、VM Error Level の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

Exchange Server 2003 および Exchange 2000 Server における仮想メモリ断片化のトラブルシューティングに関する詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。


仮想メモリ不足の警告イベントが無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、仮想メモリの断片化に関するイベントをログ出力する際のしきい値が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\VM Warning Level

VM Warning Level レジストリ値が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

32 ビット版の Microsoft Windows® システムには、2 種類のメモリがあります。物理メモリ (システムに実装されている実際のメモのリ容量) と仮想メモリ アドレス スペース (仮想化された 4 GB のメモリ スペース) です。システムに取り付けられている物理メモリの量とは無関係に、仮想アドレス スペースの合計サイズは常に同じ 4 GB です。すべての 32 ビット アプリケーションに当てはまるわけではありませんが、Exchange Server の場合、仮想アドレス スペースは仮想メモリに一致するため、これらの用語は同義で使用されます。

通常の動作中、Exchange インフォメーション ストアは繰り返し仮想メモリの割り当て、使用、および割り当ての解除を行います。仮想メモリの割り当て、使用、および割り当て解除が頻繁に行われると、仮想メモリの断片化が発生することがあります。仮想メモリの断片化は、時間が経過すると発生することがあるファイル システムの断片化に似ています。しばらくすると、割り当てられた仮想メモリのセグメントが連続的ではなくなって、パフォーマンスが低下し始めます。ファイル システムの場合、ファイルを最適化するアプリケーションを実行できます。この処理は通常、システムがオンラインになっていて、アクセスされている間に実行することが可能です。仮想メモリの断片化の場合、最適化ツールはありません。代わりに、この問題を解決するために、Microsoft Exchange Information Store サービスを停止してから開始するか、システムを再起動する必要があります。

既定では、Exchange Server コンピュータで、連続して確保できる仮想アドレス スペースが 32 MB 未満になると、次の警告メッセージがアプリケーション イベント ログに出力されます。

ソース : | MSExchangeIS
分類 : | パフォーマンス
ID : | 9582
種類 : | 警告
説明 : | Exchange サーバーの実行に必要な仮想メモリが断片化しているため、パフォーマンスに影響する可能性があります。Exchange 関連のサービスをすべて再開して、この問題を修正することをお勧めします。

VM Warning Level レジストリ値を設定すると、管理者は既定の 32 MB レベルの警告を無効にして代わりの値を設定できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、VM Warning Level の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

Exchange Server 2003 および Exchange 2000 Server における仮想メモリ断片化のトラブルシューティングに関する詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。


Mailbox Cache Age Limit が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-15

Microsoft® Exchange Server アナライザ ツールは、Exchange Server コンピュータのレジストリを調べて、Mailbox Cache Age Limit レジストリ エントリが存在するかどうかを確認します。このレジストリ値は、次の場所にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Mailbox Cache Age Limit レジストリ エントリが存在しており、1 以上の値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server では、メールボックスにサイズ制限 (クォータ) を設定できます。クォータの設定は、Active Directory® ディレクトリ サービスに格納されています。Exchange Server は Active Directory の情報を定期的に読み取り、これらの制限が変更されていないかどうかを判断します。既定では、Exchange Server は、2 時間 (120 分) おきにこの情報をキャッシュし、その後、Active Directory 内の情報を再度読み取ります。

Mailbox Cache Age Limit レジストリ値は、分単位で表され、既定の時間を変更する場合に使用します。このレジストリ値は、特に、メールボックスの限界に達しているためにユーザーがメールボックスにアクセスできないような場合に役立ちます。既定のキャッシュ保存期間が有効になっている場合、ユーザーは最大 2 時間にわたってメールボックスにアクセスできません。推奨値は 20 分です。パフォーマンスの問題が発生する可能性があるので、小さすぎる値は設定しないでください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate

  3. 右側のウィンドウで、Mailbox Cache Age Limit 値を見つけ、削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Mailbox Cache Age Limit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 327378「Exchange 2000 および Exchange 2003 のメールボックス サイズが長時間に渡って制限値を超えたままになる (修正には Exchange 2000 SP3 が必要)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378) を参照してください。


メールボックス キャッシュのアイドル制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、メールボックス キャッシュのアイドル制限が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Mailbox Cache Idle Limit レジストリ エントリが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server では、メールボックスにサイズ制限 (クォータ) を設定することができます。クォータの設定は、Active Directory® ディレクトリ サービスに格納されています。Exchange サーバーは Active Directory の情報を定期的に読み取り、これらの制限が変更されていないかどうかを判断します。Exchange Server はこの情報を一定期間キャッシュした後、Active Directory 内の情報を再度読み取ります。

Mailbox Cache Age Limit の設定と Mailbox Cache Idle Limit の設定は、メールボックス情報キャッシュ内のエントリがどれだけの期間保持されるかを制御します。Mailbox Cache Age Limit に設定されている時間 (秒単位) より長くキャッシュ内にあるアイテムは、キャッシュから削除されます。Mailbox Cache Idle Limit に設定されている時間 (秒単位) 使用されていないアイテムは、キャッシュから削除されます。これらの設定の既定値は、Mailbox Cache Age Limit は 7,200 秒 (120 分)、Mailbox Cache Idle Limit は 900 秒 (15 分) です。Mailbox Cache Idle Limit の設定の値は、Mailbox Cache Age Limit の設定の値以下にする必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem.

  3. 右側のペインで、Mailbox Cache Idle Limit 値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Mailbox Cache Age Limit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 327378「[XADM] Exchange 2000 のメールボックス サイズが長時間、制限値を超えたままになる (修正には Exchange 2000 SP3 が必要)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378) を参照してください。


Mailbox Cache Size が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Mailbox Cache Size が存在しているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Mailbox Cache Size レジストリ エントリが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Mailbox Cache Size の値は、メールボックス キャッシュのサイズを制御します。既定値は 256 MB です。Exchange Server では、メールボックスにサイズ制限 (クォータ) を設定できます。クォータの設定は Active Directory® ディレクトリ サービスに格納されます。Exchange Server は定期的に ActiveDirectory 内のこの情報を読み取り、これらの設定に変更が加えられたかどうかを判断します。既定では、Exchange Server は、2 時間 (7,200 秒) おきにこの情報をキャッシュし、その後、Active Directory 内の情報を再度読み取ります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、[Mailbox Cache Size] 値を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Mailbox Cache Age Limit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 327378「[XADM] Exchange 2000 のメールボックス サイズが長時間、制限値を超えたままになる (修正には Exchange 2000 SP3 が必要)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378) を参照してください。


Mailbox Cache Size が 0 に設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ キーを読み取り、Mailbox Cache Size 値の設定を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Mailbox Cache Size レジストリ値が 0 に設定されていることが検出されると、エラーが表示されます。

Exchange Server では、メールボックスにサイズ制限 (クォータ) を設定することができます。クォータの設定は、Active Directory® ディレクトリ サービスに格納されています。Exchange Server は Active Directory の情報を定期的に読み取り、これらの制限が変更されていないかどうかを判断します。Mailbox Cache Size 値は、このメール ボックス キャッシュのサイズを制御します。既定値は 256 MB です。この値が 0 に設定されていると、メールボックス キャッシュは無効になります。この場合、DSAccess (Directory Service Access) コンポーネントによる Active Directory 検索が頻繁に実行されるようになるため、この値を 0 に設定することはお勧めできません。さらに、この値を 0 に設定すると、Exchange ストアの障害や、メールボックス移動時の失敗が発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、Mailbox Cache Size 値を見つけ、削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Mailbox Cache Age Limit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 327378「[XADM] Exchange 2000 のメールボックス サイズが長時間、制限値を超えたままになる (修正には Exchange 2000 SP3 が必要)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327378) を参照してください。


メールボックス ストアがポリシーによって制御されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-06-06

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストア オブジェクトの msExchPolicyList 属性の値を判断します。msExchPolicyList 属性は、Exchange Server メールボックス ポリシーが作成され、メールボックス ストアに割り当てられているかどうかを判断します。Exchange Server アナライザによって msExchPolicyList 属性が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、メールボックスの作成時にメールボックス ポリシーは割り当てられていません。ただし、ほとんどの場合、管理者はメールボックス ポリシーを作成して、複数のメールボックス ストアに割り当てます。これらのポリシーは、記憶域の制限、インデックスの更新、保守の間隔、パブリック ストアとオフライン アドレス一覧へのマッピングなどの管理設定に適用されます。メールボックス ポリシーが作成され、メールボックス ストアに割り当てられている場合、そのメールボックス ストアが現在メールボックス ポリシーにより制御されていることを示すメッセージが表示されます。操作は必要ありません。

メールボックス ストアからメールボックス ポリシーを削除するには

  1. Exchange システム マネージャを開き、コンソール ツリーの [管理グループ] を展開します。

  2. [最初の管理グループ] を展開し、[システム ポリシー] をクリックします。

  3. 結果ペインで、[メールボックス ストア] を右クリックし、[ポリシーから削除] をクリックします。

  4. [Exchange システム マネージャ] ウィンドウで、[はい] をクリックしてメールボックス ストアの削除を確認します。
注 :
[システム ポリシー] ノードが Exchange システム マネージャのコンソール ツリーに表示されていない場合、管理グループが表示されるように Exchange システム マネージャを構成します。

メールボックス ストアのポリシーの詳細については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822938「[HOWTO] Exchange Server 2003 でシステム ポリシーを使用してメールボックス格納域の制限を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822938)

  • 文書番号 256141「[XADM] Exchange 2000 でシステム ポリシーを作成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256141)

Exchange Server データベース ファイルの詳細については、Exchange Server 2003 に関する次のトピックを参照してください。

  • Exchange Server 2003 管理ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47617) の、メールボックス ストアとパブリック フォルダ ストアの管理に関するセクション (このサイトは英語の場合があります)

  • Exchange Server 2003 ストアの操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47595) の、Exchange Server 2003 ストアに関するセクション (このサイトは英語の場合があります)


メールボックス ストアのデータベース ファイルがネットワーク ドライブに格納されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoftt® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストア オブジェクトの msExchEDBFile 属性の値を判断します。この属性は、このメールボックス ストアが使用しているデータベース ファイルの場所を指定します。

Exchange Server アナライザは Active Directory に対してクエリを実行し、このサーバーに配置されている各メールボックス ストアの homeMDBBL 属性に列挙されている値の数も判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。Exchange Server アナライザは、それを基に、このサーバーが管理しているメールボックスの合計数を計算することができます。

50 を超えるメールボックスを含む Exchange サーバーで msExchEDBFile 属性が \\ で始まっていることが検出されると、エラーが表示されます。

このエラーは、メール ボックス ストアのデータベース ファイルがネットワーク共有に格納されていることを示します。msExchEDBFile 属性が \\ で始まる場合は、ログ ファイルのパスに汎用名前付け規則 (UNC) パスが使用されています。ネットワーク共有への格納は、ネットワーク接続の中断によってデータベース エラーが発生し、それによりデータの損失やデータベースの破損が生じる可能性があるためお勧めできません。可能な限り速やかにこの問題を修正することをお勧めします。

データベース ファイルを新しいドライブに移動するには

  1. Exchange システム マネージャで、ストアが格納されている Exchange サーバー オブジェクトを展開し、該当するストレージ グループ コンテナを展開します。対象のメールボックス ストア オブジェクトを右クリックし、[プロパティ] をクリックします。

  2. [プロパティ] ダイアログ ボックスの [データベース] タブで、新しいファイルの場所を指定します。

Exchange Server データベース ファイルの詳細については、次のトピックを参照してください。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Mailbox Stores and Public Folder Stores」(このサイトは英語の場合があります)

  • 『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Understanding the Exchange Server 2003 Store」(このサイトは英語の場合があります)

ネットワーク ドライブでの Exchange Server の使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328879「Exchange Server と SAN デバイスおよび NAS デバイスの使用について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328879)

  • 文書番号 839687「Exchange Server 2003 の network-attached 記憶域デバイスの使用の Microsoft Support ポリシー」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839687)

  • 文書番号 317173「[XADM] Exchange 2000 Server と Network Attached Storage について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317173)

  • 文書番号 317172「[XADM] Exchange Server 5.5 と Network Attached Storage について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317172)


メールボックス ストア データベースのサイズ制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、メールボックス ストア データベースの Database Size Limit in Gb レジストリ値が存在し、構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

Database Size Limit in Gb 値が存在し、構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 Standard Edition に Exchange Server 2003 Service Pack 2 (SP2) が適用されると、ハードコードされたライセンス データベースのサイズ制限が 16 GB から 75 GB に引き上げられます。意図せずにデータベースのサイズが拡大するのを防ぐ目的で、保護のためのデータベース サイズ制限を設定できます。SP2 では、既定のサイズ制限値は 18 GB ですが、この既定値は Database Size Limit in Gb レジストリ値を作成することによって上書きできます。

Exchange Server 2007 Standard Edition のハードコードされたライセンス データベースの 50 GB というサイズ制限も、Database Size Limit in Gb レジストリ値を作成することによって拡大することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-<MailboxStoreGUID>

  3. Database Size Limit in Gb 値を削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアに既定のパブリック フォルダ ストアが関連付けられていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPrivateMDB 属性に、メールボックス ストアに割り当てられた既定のパブリック フォルダ ストアが指定されているかどうかを判断します。

msExchPrivateMDB 属性は、メールボックス ストア オブジェクトのプライベート データベース構成です。既定では、msExchHomePublicMDB 属性がメールボックス ストアに関連付けられています。msExchPrivateMDB 属性は、ホーム パブリック メッセージ データベース (MDB) です。

Exchange Server アナライザによって、msExchHomePublicMDB 属性が削除されているか、または正しく構成されていないことが検出されると、エラーが表示されます。

各メールボックス ストアには、ローカル サーバーまたは別のサーバー上にある既定のパブリック フォルダ ストアが関連付けられている必要があります。特定のメールボックス ストアでサポートされている、メールボックスが有効な各ユーザーの場合、関連付けられたパブリック フォルダ ストアがそのユーザーのホーム パブリック フォルダ ストアになります。可能な場合は、同じサーバー上にある既定のパブリック フォルダ ストアをメールボックス ストアとして使用してください。

注 :
同じサーバー上にある既定のパブリック フォルダ ストアをメールボックス ストアとして使用すると、ユーザーがパブリック フォルダにアクセスする場合のパフォーマンスが向上すると共に、パブリック フォルダへのアクセスに関する問題のトラブルシューティングが簡略化されます。
メールボックス ストアに既定のパブリック フォルダ ストアを割り当てるには

  1. Exchange システム マネージャで、メールボックス ストアが存在しているストレージ グループを右クリックします。

  2. メールボックス ストアを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[既定のパブリック ストア] の [参照] をクリックし、このメールボックス ストアに関連付けるパブリック フォルダ ストアを選択します。

    注 :
    新しいメールボックス ストアを作成している場合は、[パブリック フォルダ] ツリーに関連付けられた既定のパブリック フォルダ ストアと、ユーザーがオフラインでの使用のためにダウンロードするオフライン アドレス帳が Exchange Server によって自動的に選択されます。

メールボックス ストアとパブリック フォルダ ストアの管理の詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47617) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアのサイズが 12 GB を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-28

Microsoft® Exchange Server アナライザ ツールは、CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange メールボックス ストアのデータベース ファイル (.edb ファイル) とストリーミング ファイル (.stm ファイル) のそれぞれについて FileSize キーの値を判断します。また、以下のレジストリ ブランチも読み取り、インストールされている Exchange Server のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange Product GUID>

Microsoft Exchange Server 2003 Standard Edition または Microsoft Exchange 2000 Server Standard Edition を実行中のコンピュータで、メールボックス ストアのデータベース ファイルとストリーミング ファイルの合計サイズが 12 GB を超えていることが検出されると、警告が表示されます。

Exchange Server 2003 Standard Edition と Exchange 2000 Server Standard Edition での Exchange ストア データベースは、16 GB を超えて拡大することはできません。この上限に達すると、メールボックス ストアはマウントされなくなり、Exchange にはアクセスできなくなります。Exchange Server 2003 Enterprise Edition と Exchange 2000 Server Enterprise Edition の場合、Exchange ストアのデータベースは 16 GB に制限されていません。使用可能なハードウェアによってのみ制限されますが、理論上の最大サイズは 16 テラバイトです。

この警告を修正するには

  1. メールボックスの一部を、大容量のメールボックス ストアから、同じまたは別の Exchange Server コンピュータ上の新しいメールボックス ストアへ移動することを検討します。

  2. メールボックスをこのインフォメーション ストアから別のストアに最近移動したばかりの場合、またはこのメールボックス ストアからメールボックスを最近削除したばかり場合は、最適化をオフラインで実行することによりファイル サイズが縮小される場合があります。

  3. メールボックス ストアが無制限に大きくならないように、メールボックスやメッセージ サイズの制限を設定することを検討します。
注 :
Exchange Server 2003 Standard Edition 用の Exchange Server 2003 Service Pack 2 (SP2) のリリースでは、ハードコードされたライセンス データベース サイズ制限が 16 GB から 75 GB に拡大されました。管理者は、保護のためのデータベースのサイズ制限を設定できます (意図せずにデータベースのサイズが拡大するのを防ぐため)。Standard Edition 用の SP2 では、既定値は 18 GB で、この既定値は Database Size Limit in Gb レジストリ キーを編集することによって上書きできます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange Server 2003 SP2 でデータベースのデータベース サイズ制限を構成するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe を起動します。

  2. 次のレジストリ キーを開きます。HKLM\System\CurrentControlSet\Services\MSExchangeIS\サーバー名\Private-メールボックス ストアの GUID

  3. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。Exchange Server 2003 Standard Edition では、1 ～ 75 の 10 進数の値を入力します (既定値は 18 GB)。Exchange Server 2003 Enterprise Edition では、1 ～ 8000 の 10 進数の値を入力します (既定値は 8,000 GB)。[OK] をクリックします。

  6. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の 10 進数の値を入力して、データベースの最大サイズに近づいていることを警告するイベントをログに記録する時点を指定します。既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。[OK] をクリックします。

  9. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (午前 5 時) にデータベース サイズをチェックします。[OK] をクリックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。

Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server データベースのオフラインでの最適化を実行する方法の詳細については、Microsoft サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804) を参照してください。

メッセージ サイズの制限値設定の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679) を参照してください。

Exchange Server 2003 Standard Edition または Microsoft Exchange 2000 Server Standard Edition がデータベース サイズの上限に到達した場合の詳細については、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアのサイズが 15 GB を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-28

Microsoft® Exchange Server アナライザ ツールは、CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange メールボックス ストアのデータベース ファイル (.edb ファイル) とストリーミング ファイル (.stm ファイル) のそれぞれについて FileSize キーの値を判断します。また、以下のレジストリ ブランチも読み取り、インストールされている Exchange Server のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange 製品の GUID>

Microsoft Exchange Server 2003 Standard Edition または Microsoft Exchange 2000 Server Standard Edition が実行されているコンピュータで、メールボックス ストア データベースとストリーミング ファイルのペアの合計サイズが 15 GB を超えていることが検出されると、エラーが表示されます。

Exchange Server 2003 Standard Edition と Exchange 2000 Server Standard Edition での Exchange ストア データベースは、16 GB を超えて拡大することはできません。この上限に達すると、メールボックス ストアはマウントされなくなり、Exchange にはアクセスできなくなります。Exchange Server 2003 Enterprise Edition と Exchange 2000 Server Enterprise Edition の場合、Exchange ストアのデータベースは 16 GB に制限されていません。使用可能なハードウェアによってのみ制限されますが、理論上の最大サイズは 16 テラバイトです。

このエラーを修正するには

  1. メールボックスの一部を、大容量のメールボックス ストアから、同じまたは別の Exchange Server コンピュータ上の新しいメールボックス ストアへ移動することを検討します。

  2. メールボックスをこのインフォメーション ストアから別のストアに最近移動したばかりの場合、またはこのメールボックス ストアからメールボックスを最近削除したばかり場合は、最適化をオフラインで実行することによりファイル サイズが縮小される場合があります。

  3. メールボックス ストアが無制限に大きくならないように、メールボックスやメッセージ サイズの制限を設定することを検討します。
注 :
Exchange Server 2003 Standard Edition 用の Exchange Server 2003 Service Pack 2 (SP2) のリリースでは、ハードコードされたライセンス データベース サイズ制限が 16 GB から 75 GB に拡大されました。管理者は、保護のためのデータベースのサイズ制限を設定できます (意図せずにデータベースのサイズが拡大するのを防ぐため)。Standard Edition 用の SP2 では、既定値は 18 GB で、この既定値は Database Size Limit in Gb レジストリ キーを編集することによって上書きできます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange Server 2003 SP2 でデータベースのデータベース サイズ制限を構成するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe を起動します。

  2. 次のレジストリ キーを開きます。HKLM\System\CurrentControlSet\Services\MSExchangeIS\サーバー名\Private-メールボックス ストアの GUID

  3. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。Exchange Server 2003 Standard Edition では、1 ～ 75 の 10 進数の値を入力します (既定値は 18 GB)。Exchange Server 2003 Enterprise Edition では、1 ～ 8000 の 10 進数の値を入力します (既定値は 8,000 GB)。[OK] をクリックします。

  6. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の 10 進数の値を入力して、データベースの最大サイズに近づいていることを警告するイベントをログに記録する時点を指定します。既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。[OK] をクリックします。

  9. [プライベート ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (午前 5 時) にデータベース サイズをチェックします。[OK] をクリックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。

Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server データベースのオフラインでの最適化を実行する方法の詳細については、Microsoft サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804) を参照してください。

メッセージ サイズの制限値設定の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679) を参照してください。

Exchange Server 2003 Standard Edition および Exchange 2000 Server Standard Edition の最大データベース サイズへの到達に関する詳細については、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


メールボックス ストアの完全バックアップが 9 日以上実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、各メールボックス ストアに対してクエリを実行し、完全バックアップが最後に実行された日時を判断します。また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストア内にメールボックスを保持するユーザーの数を判断します。以下の両方の条件に当てはまる場合は、警告メッセージが表示されます。

  • メールボックス ストアの完全バックアップを最後に実行してから 8 日を超える日数が経過している。

  • メールボックス ストア内のメールボックスの数が 10 より多い。

メールボックス ストアは、Microsoft Exchange Server 2003 および Exchange Server 2007 のメールボックスを格納するためのデータベースです。メールボックス ストアは、リッチテキスト (.edb) ファイルとストリーミング ネイティブ インターネット コンテンツ (.stm) ファイルで構成されています。.edb ファイルと .stm ファイルの 2 つのファイルが存在しますが、これらのファイルが 2 つの別のデータベースになっているのではなく、1 つのデータベースを構成しています。

Exchange Server データベース内のメールボックス ストアとパブリック フォルダ ストアのデータ、およびトランザクション ログ ファイルは、Exchange Server 組織でバックアップする必要のある最も重要なデータです。Exchange Server データベースのバックアップを使用すると、破損したメールボックスを、Exchange Server を実行している動作中のサーバーに復元できます。また、Exchange Server データベースのバックアップを使用して、Exchange Server データベースを別のサーバーに復元することもできます。

データベース ファイルとトランザクション ログの完全バックアップは毎日行うのが理想です。ストレージ グループの完全バックアップが完了したら、Exchange Server データベースのコミットされたトランザクション ログ ファイルはサーバーから削除されます。完全バックアップでは、1 つのテープ セットですべてのデータを復元できるため、回復シナリオが高速化されるという利点があります。

注 :
ベスト プラクティスとして、トランザクション ログ ファイルはデータベース ファイルとは別の専用ディスクに保存することをお勧めします。これにより、データベースのディスクが故障した場合のフォールト トレランスの向上に寄与します。また、データベースのパフォーマンスの向上につながる場合もあります。
重要 :
ファイルとフォルダのバックアップや復元を行うには、それに必要なアクセス許可や権限がログインしたユーザー アカウントに割り当てられている必要があります。Exchange Server のバックアップを作成するには、ドメイン レベルのバックアップ オペレータ権限が必要です。Microsoft Windows Server™ 2003 オペレーティング システムのバックアップを作成するには、少なくともローカルの Backup Opeator の権限が必要です。

Exchange Server データに関して選択するバックアップ戦略は、ストアのサイズ、バックアップに使用するソフトウェアやハードウェアの速度、ハードウェアの容量、時間に関する要件などによって異なります。

バックアップ戦略および障害回復操作の詳細については、以下のサイトを参照してください。

  • 『Exchange Server 2003 障害回復ガイド』(http://go.microsoft.com/fwlink/?LinkId=47570) (このサイトは英語の場合があります)

  • データベースのバックアップと復元についてのページ (http://go.microsoft.com/fwlink/?LinkId=80766) (このサイトは英語の場合があります)


メールボックス ストアの完全バックアップが 61 日以上実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、各メールボックス ストアに対してクエリを実行し、完全バックアップが最後に実行された日時を判断します。また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストア内にメールボックスを保持するユーザーの数を判断します。次の両方の条件に当てはまる場合は、エラーが表示されます。

  • メールボックス ストアの完全バックアップが最後に実行されてからの日数が 60 日を超えている。

  • メールボックス ストア内のメールボックスの数が 10 より多い。

メールボックス ストアは、Microsoft Exchange Server 2003 および Microsoft Exchange Server 2007 のメールボックスを格納するためのデータベースです。メールボックス ストアは、リッチテキスト (.edb) ファイルとストリーミング ネイティブ インターネット コンテンツ (.stm) ファイルで構成されています。.edb ファイルと .stm ファイルの 2 つのファイルが存在しますが、これらのファイルが 2 つの別のデータベースになっているのではなく、1 つのデータベースを構成しています。

Exchange Server データベース内のメールボックス ストアとパブリック フォルダ ストアのデータ、およびトランザクション ログ ファイルは、Exchange Server 組織でバックアップする必要のある最も重要なデータです。Exchange Server データベースのバックアップを使用すると、破損したメールボックスを、Exchange Server を実行している動作中のサーバーに復元できます。また、Exchange Server データベースのバックアップを使用して、Exchange Server データベースを別のサーバーに復元することもできます。

データベース ファイルとトランザクション ログの完全バックアップは毎日行うのが理想です。ストレージ グループの完全バックアップが完了した後、Exchange Server データベース上のコミット済みのトランザクション ログ ファイルはサーバーから削除されます。完全バックアップでは、1 つのテープ セットですべてのデータを復元できるため、回復シナリオが高速化されるという利点があります。

注 :
ベスト プラクティスとして、トランザクション ログ ファイルはデータベース ファイルとは別の専用ディスクに保存することをお勧めします。これにより、データベースのディスクが故障した場合のフォールト トレランスの向上に寄与します。また、データベースのパフォーマンスの向上につながる場合もあります。
重要 :
ファイルとフォルダのバックアップや復元を行うには、それに必要なアクセス許可や権限がログインしたユーザー アカウントに割り当てられている必要があります。Exchange Server のバックアップを作成するには、ドメイン レベルのバックアップ オペレータ権限が必要です。Microsoft Windows Server™ 2003 オペレーティング システムのバックアップを作成するには、少なくともローカル バックアップ オペレータ権限が必要です。

Exchange Server データに関して選択するバックアップ戦略は、ストアのサイズ、バックアップに使用するソフトウェアやハードウェアの速度、ハードウェアの容量、時間に関する要件などによって異なります。

バックアップ戦略および障害回復操作の詳細については、以下のサイトを参照してください。

  • 『Exchange Server 2003 障害回復ガイド』(http://go.microsoft.com/fwlink/?LinkId=47570) (このサイトは英語の場合があります)

  • データベースのバックアップと復元についてのページ (http://go.microsoft.com/fwlink/?LinkID=80766) (このサイトは英語の場合があります)


メールボックス ストアのオンライン保守スケジュールが重複している
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ストレージ グループに属するすべてのメールボックス ストアの保守スケジュールが同じであるかどうかを判断します。ストレージ グループ コンテナ (クラス msExchStorageGroup) に 2 つ以上のメールボックス ストア オブジェクト (クラス msExchPrivMDB) が存在している場合、Exchange Server アナライザは各メールボックス ストア オブジェクトの activationSchedule 属性をチェックします。これらの値 (オクテット文字列として格納されている) がそれぞれのメールボックス ストアで同じである (重複している) ことが検出されると、警告が表示されます。

既定では、メールボックス ストアの保守プロセスは夜の午前 1:00 から午前 5:00 までに実行されます。保守プロセスに必要なサーバー リソースの理由から、メールボックス ストアのスケジュールが最低 15 分ずつずれるように保守スケジュールを変更することをお勧めします。

Exchange 2000 Server および Exchange Server 2003 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、操作するサーバーを展開します。

  3. 操作するストレージ グループを展開します。

  4. 操作するストアを右クリックし、[プロパティ] をクリックします。

  5. [データベース] タブで、[保守の間隔] をクリックし、新しい間隔をクリックするか、[カスタマイズ] をクリックしてカスタムのスケジュールを作成します。

Exchange Server 2007 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、操作するサーバーを選択します。

  3. 操作するストレージ グループを展開します。

  4. 操作するストアを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[保守のスケジュール] ボックスをクリックして別の間隔を選択するか、または [カスタマイズ] をクリックしてカスタム スケジュールを作成します。

Exchange Server 2003 でのストアの保守の詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Configuring Store Maintenance and Backup Options」を参照してください (このサイトは英語の場合があります)。


メールボックス ストアの送受信禁止の制限が近すぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、メールボックスに設定されているメールボックス サイズの制限を判断します。Prohibit send と Prohibit send and receive のメールボックス制限の差が 20% 未満であることが検出されると、ベスト プラクティスの構成を推奨するメッセージが表示されます。

ベスト プラクティスとして、Prohibit send と Prohibit send and receive の制限の差を 20% 以上にすることをお勧めします。これらの制限の差が 20% 未満の場合は、メールボックス ユーザーがメールボックスをクリーンアップするための十分な時間を取れないうちに、メールボックスによるメッセージの拒否が開始される可能性があります。たとえば、メールボックスのサイズが 100 MB に達するとユーザーが新しいメッセージを送信できなくなる場合は、Prohibit send and receive の制限を 120 MB 以上にする必要があります。

注 :
また、メールボックスに警告制限を設定することも重要です。メールボックスのサイズが警告制限に達すると、メールボックスが Prohibit send で定義された制限に近づいていることを警告する電子メール メッセージがユーザーに送信されます。

この問題を解決するには、Prohibit send と Prohibit send and receive のメールボックスの制限の差を 20% 以上に増やす必要があります。

メールボックスの制限を設定するには

  1. Exchange システム マネージャを起動します。

  2. Exchange Server アナライザのメッセージに表示されているメールボックス ストアを見つけます。

  3. [<メールボックス ストア名>] を右クリックし、[プロパティ] をクリックします。

  4. [制限] タブをクリックします。

  5. [送信を禁止するサイズ (KB)] の制限、[送受信を禁止するサイズ (KB)] の制限、または両方の制限を変更します。

  6. [適用] をクリックし、[OK] をクリックします。
Exchange Server 2007 で Exchange 管理コンソールを使用してメールボックスの制限を設定するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. Exchange Server アナライザでこの問題点に関連してメッセージが表示されたメールボックス ストアを見つけます。

  3. [<メールボックス ストア名>] を右クリックし、[プロパティ] をクリックします。

  4. [制限] タブをクリックします。

  5. [警告を表示するサイズ (KB)]、[送信を禁止するサイズ (KB)]、および [送受信を禁止するサイズ (KB)] の制限を変更します。

  6. [適用] をクリックし、[OK] をクリックします。
Exchange Server 2007 で Exchange 管理シェルを使用してメールボックスの制限を設定するには、次の操作を行います。

  1. 次の例は、警告メッセージがユーザーに送信される、メールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の警告クォータの属性セットを持たないすべてのメールボックスに適用されます。整数または "unlimited" を指定する必要があります。既定値は 1.9 ギガバイト (GB) です。
コードのコピー
Set-MailboxDatabase "Mailbox Database Name" -IssueWarningQuota 1991680
  1. 次の例は、このメールボックス データベース内のメールボックスに関連付けられているユーザーがメッセージを送信できなくなるメールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の送信禁止クォータの属性セットを持たないすべてのメールボックスに適用されます。制限値の設定は、整数または "unlimited" のいずれかである必要があります。

コードのコピー
Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendQuota 2097152
  1. 次の例は、このメールボックスに関連付けられているユーザーがメッセージを送受信できなくなるメールボックス サイズの設定方法を示しています。この属性は、このメールボックス データベース内の独自の送受信禁止クォータの属性セットを持たないすべてのメールボックスに適用されます。整数または "unlimited" を指定する必要があります。

コードのコピー
Set-MailboxDatabase "Mailbox Database Name" -ProhibitSendReceiveQuota 2411520

Exchange メールボックスの管理の詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 で Exchange メールボックスの制限を管理する方法の詳細については、データベースの制限とプロパティの構成方法についてのページ (http://go.microsoft.com/fwlink/?LinkID=80746) を参照してください (このサイトは英語の場合があります)。


サービス開始時にメールボックス ストアがマウントされない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPrivateMDB クラスを含むすべてのオブジェクトについて、msExchEDBOffline 属性の値を判断します。このクラスを含むオブジェクトは、メールボックス ストアです。

msExchEDBOffline 属性値が True の場合、Microsoft Exchange Information Store サービスの開始時にメールボックス ストアが自動的にマウントされることはありません。この属性値が False の場合、開始時にメールボックスがマウントされます。Exchange Server アナライザによってこの属性値が True であることが検出されると、警告が表示されます。

この警告は、[起動時にこのストアをマウントしない] チェック ボックスがオンになっていることを示しています。このチェック ボックスは、メールボックス ストアのプロパティダイアログ ボックスの [データベース] タブにあります。このチェック ボックスがオンになっていると、メールボックス ストアは Microsoft Exchange Information Store サービスの開始時に自動的にマウントされません。サーバーの再起動の後など、次に Microsoft Exchange Information Store サービスが開始されたとき、この属性が True に設定されているメールボックス ストアはマウントされません。Microsoft Exchange Information Store サービスの開始時にはメールボックス ストアが自動的にマウントされるようにすることをお勧めします。

Exchange 2000 Server または Exchange Server 2003 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、変更するメールボックス ストアが含まれたサーバーを展開します。

  3. 変更するメールボックス ストアが含まれたストレージ グループを展開します。

  4. メールボックス ストアを右クリックし、[プロパティ] をクリックします。

  5. [データベース] タブで、[起動時にこのストアをマウントしない] チェック ボックスをオフにします。

  6. [OK] をクリックして設定を保存します。

  7. Exchange システム マネージャを終了します。

Exchange Server 2007 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、操作するサーバーを選択します。

  3. 操作するストレージ グループを展開します。

  4. 操作するデータベースを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[起動時にこのデータベースをマウントしない] チェック ボックスをオフにします。

  6. [OK] をクリックして設定を保存します。

  7. Exchange 管理コンソールを終了します。

このオプションの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 314218「[HOW TO] Exchange 2000 Server で起動時にデータ ストアの自動マウントをオフまたはオンにする」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314218)

  • 文書番号 285169「[XADM] "/disasterrecovery" スイッチの使用後にインフォメーション ストアがマウントしない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=285169)


Max FXGetBuffer Users パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Max FXGetBuffer Users レジストリ キーが作成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Max FXGetBuffer Users レジストリ キーが ParametersSystem の下に作成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Max FXGetBuffer Users レジストリ キーを使用すると、Exchange Server 2003 サーバーと一度に同期する Microsoft Office Outlook® 2003 クライアントの数を制御できます。Max FXGetBuffer Users レジストリ キーの値を設定して、Outlook クライアントが確立できる同時リモート プロシージャ コール (RPC) 接続数の上限を変更します。これらの接続は、ropFXSrcGetBuffers とも呼ばれます。Max FXGetBuffer Users レジストリ キーの既定値は、サーバー上のプロセッサ数に 2 を掛けた後、3 を加えて計算します。たとえば、2 つのプロセッサが実装された Exchange Server 2003 サーバーの場合、既定値は 7 ([2 * 2] + 3 = 7) になります。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Max FXGetBuffer Users の値を削除します。

  4. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

レジストリ キーを設定して Exchange Server 2003 と同期できる Outlook クライアントの数を制御する方法の詳細については、Microsoft サポート技術情報の文書番号 818484「レジストリが値で、Outlook クライアント同期を設定し、そして監視するのに使用できることをカウンタする。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=818484) を参照してください。


1 回のメッセージ発信で添付できる最大ファイル数が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、1 回のメッセージ発信で添付できる既定の最大ファイル数が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtAttachment

objtAttachment レジストリ値が存在し、下の表以外の値を使用して構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

エントリ | Exchange Server 2003 の RTM の既定値 | Exchange Server 2003 SP1 以降の既定値 | Exchange Server 2007 の既定値
objtAttachment | 100 | 500 | 500

手動で追加および構成されている場合、objtAttachment レジストリ値は、1 台の MAPI クライアントが 1 回のメッセージ発信で添付できる最大ファイル数を指定します。許容される数を超えるファイルが添付されたメッセージを MAPI クライアントが送信しようとすると、クライアントのメールボックスが格納されている Exchange Server コンピュータのアプリケーション イベント ログに以下のイベントが記録されます。

イベントの種類 : | エラー
イベント ID : | 9646
ソース : | MSExchangeIS
イベント カテゴリ : | 全般
説明 : | オブジェクトの種類 "objtAttachment" の許容される最大数 xxx を超えたため、Mapi セッション "/o=組織名/ou=管理グループ名/cn=受信者/cn=ユーザー名" を閉じます。

objtAttachment レジストリ値を設定すると、管理者は MAPI クライアントが使用する Exchange Server リソースをさらにきめ細かく制御できるようになります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession

  3. objtAttachment レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

または、objtAttachment レジストリ値を使用する場合は、このレジストリ値を削除する代わりに、設定を既定値のままにしておくか、必要に応じて調整します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

詳細については、Microsoft サポート技術情報の文書番号 830829「Exchange Server 2003 コンピュータは、MAPI クライアントが特定のサーバー オブジェクトの既定値より最も開いた後、応答を停止することがあります。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829) を参照してください。


最大キャッシュ ビューが変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、データベースごとのキャッシュ ビューの最大数が変更されているかどうかを判断します。msExchMaxCachedViews 属性が既定値の 11 から変更されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。データベースごとに構成しているキャッシュ ビューの数は、Exchange Server アナライザの出力に含まれています。ベスト プラクティスとして、キャッシュ ビューの数を 5 ～ 20 に設定することをお勧めします。

msExchMaxCachedViews は、msExchangePrivateMDB オブジェクト クラスの属性です。したがって、Active Directory の各メールボックス データベース ストア オブジェクトには、msExchMaxCachedViews 属性値が存在します。msExchMaxCachedViews 属性値は、メールボックス内の特定のフォルダでキャッシュされるビューの最大数を指定します。この場合の "ビュー" は、ユーザーが別のユーザーの Microsoft Office Outlook® 2003 メールボックスにアクセスしたときに表示されるフォルダを表します。ユーザーが Outlook フォルダへのアクセスを他のユーザーと共有している場合、個人的なアイテムを非表示にしたビューが Exchange Server によって生成されます。

Outlook ユーザーが別のユーザーの予定表、連絡先フォルダ、またはその他のデータを最初に表示するときは、遅延が発生する場合があります。一度ユーザーがフォルダを表示した後は高速に表示されるようになる可能性がありますが、ある程度の時間が経過した後に再度フォルダへのアクセスを試みると、遅延が発生することがあります。この遅延は一般に、フォルダに多数のアイテムが存在する場合に最も顕著になります。多数のアイテムとは、5,000 以上を指します。

フォルダにビューを適用すると、Outlook フォルダにアクセスするユーザーごとに、Exchange ストアに検索フォルダが作成されます。検索フォルダは作成時に、後で使用するためにキャッシュされます。Exchange Server は、新しい検索フォルダを作成する前に、検索フォルダが既に存在しているかどうかを判断します。検索フォルダが存在する場合、Exchange Server はキャッシュされた検索フォルダを使用して、以降の表示を高速化します。

msExchMaxCachedViews 属性は、特定のフォルダにキャッシュされる検索フォルダの数を定義します。たとえば、msExchMaxCachedViews 属性により、予定表フォルダにキャッシュされる検索フォルダの数を定義できます。

多数のユーザーが Outlook フォルダを共有している場合、サーバーのリソースの割り当てと、許容できるクライアント パフォーマンスの間のバランスをどのように調整するかを決定する必要があります。検索フォルダがキャッシュされる際は、検索フォルダ内のデータの変更に応じて、検索フォルダが最新の状態に維持されます。これらの更新には、CPU とディスクのリソースが使用されます。検索フォルダの複数のキャッシュが保持されている場合は、CPU とディスクのパフォーマンスがさらに影響を受けます。

一方、Exchange Server が検索フォルダを最初に作成するときは、検索フォルダの作成のために Outlook フォルダにアクセスするユーザーが遅延を感じる可能性があります。

たとえば、11 の検索フォルダが構成されている Exchange Server について考えます。11 は、既定の検索フォルダ数です。ユーザー A は、他の 15 人のユーザーと予定表フォルダを共有しています。ユーザーB がフォルダにアクセスすると、自分の検索フォルダが作成されている間は遅延を感じます。ユーザー B 用の検索フォルダが作成されると、ユーザー A の予定表フォルダへのアクセスは高速になります。ユーザー B は、その日はそれ以上フォルダにはアクセスしなかったとします。その間に、他の 11 人のユーザーがフォルダにアクセスすると、各ユーザーに個別の検索フォルダが作成されます。キャッシュされる検索フォルダは 11 だけのため、次にユーザー B がユーザー A の予定表にアクセスしたとき、ユーザー B は再び新しい検索フォルダの作成による遅延を感じることになります。

ベスト プラクティスとして、検索フォルダのキャッシュの最大数を 20 以下に制限することをお勧めします。この値を超えると、特に 5,000 アイテムを超えるフォルダの場合は、サーバーがキャッシュされたフォルダを維持しようとするために過剰な負荷がかかる可能性があります。

また、キャッシュの数は 5 以上に設定するのが適切です。ユーザーが複数のユーザーと Outlook フォルダを共有している場合は、4 つの検索フォルダをキャッシュするだけではクライアントのパフォーマンスに悪影響を及ぼし、またサーバーでの新しいキャッシュのさらに頻繁な作成のためにより多くのリソースが使用されます。

msExchMaxCachedViews 属性は、パブリック フォルダ データベースでも設定できます。検索フォルダは、パブリック フォルダに対しても作成されます。既定では、パブリック フォルダは、多数のユーザーにアクセスされる可能性のある共有リソースです。パブリック フォルダが多数のポストを受信する場合は、検索フォルダの更新によって Exchange Server の CPU とディスクの使用率が高くなるため、検索フォルダを最小化する必要があります。また、多数のユーザーがパブリック フォルダにアクセスする場合に、検索フォルダのキャッシュの数を増やしてクライアントの動作を最適化しようとすることは適切な処置とは言えません。これらのキャッシュは、新しいユーザー用の検索フォルダが作成されるときに破棄されることになります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
msExchMaxCachedViews 属性を変更するには

  1. Microsoft Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

    • [InformationStore]

    • [<ストレージ グループ名>]

  3. 詳細ペインで、[データベース名] を右クリックし、[プロパティ] をクリックします。

  4. [Attribute Editor] ボックスで、[msExchMaxCachedViews] をダブルクリックします。

  5. [Integer Attribute Editor] ダイアログ ボックスで、[値] ボックスに 5 ～ 20 の整数を入力し、[OK] をクリックします。

  6. [適用] をクリックし、ADSI Edit を終了します。

  7. レプリケーションが完了するまで、少なくとも 15 分待機します。次に、変更を行った Exchange Server で、Microsoft Exchange Information Store サービスを再開します。


最大キャッシュ ビューの設定値が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、データベースごとのキャッシュ ビューの最大数が変更されているかどうかを判断します。msExchMaxCachedViews 属性が 20 より大きい値に設定されていることが検出されると、警告が表示されます。データベースごとに構成しているキャッシュ ビューの数は、Exchange Server アナライザの出力に含まれています。ベスト プラクティスとして、キャッシュ ビューの数を 5 ～ 20 に設定することをお勧めします。

msExchMaxCachedViews は、msExchangePrivateMDB オブジェクト クラスの属性です。したがって、Active Directory の各メールボックス データベース ストア オブジェクトには、msExchMaxCachedViews 属性値が存在します。msExchMaxCachedViews 属性値は、メールボックス内の特定のフォルダでキャッシュされるビューの最大数を指定します。この場合の "ビュー" は、ユーザーが別のユーザーの Microsoft Office Outlook® 2003 メールボックスにアクセスしたときに表示されるフォルダを表します。ユーザーが Outlook フォルダへのアクセスを他のユーザーと共有している場合、個人的なアイテムを非表示にしたビューが Exchange Server によって生成されます。

Outlook ユーザーが別のユーザーの予定表、連絡先フォルダ、またはその他のデータを最初に表示するときは、遅延が発生する場合があります。一度ユーザーがフォルダを表示した後は高速に表示されるようになる可能性がありますが、ある程度の時間が経過した後に再度フォルダへのアクセスを試みると、遅延が発生することがあります。この遅延は一般に、フォルダに多数のアイテムが存在する場合に最も顕著になります。多数のアイテムとは、5,000 以上を指します。

フォルダにビューを適用すると、Outlook フォルダにアクセスするユーザーごとに、Exchange ストアに検索フォルダが作成されます。検索フォルダは作成時に、後で使用するためにキャッシュされます。Exchange Server は、新しい検索フォルダを作成する前に、検索フォルダが既に存在しているかどうかを判断します。検索フォルダが存在する場合、Exchange Server はキャッシュされた検索フォルダを使用して、以降の表示を高速化します。

msExchMaxCachedViews 属性は、特定のフォルダにキャッシュされている検索フォルダの数を定義します。たとえば、msExchMaxCachedViews 属性により、予定表フォルダにキャッシュされる検索フォルダの数を定義できます。

多数のユーザーが Outlook フォルダを共有している場合、サーバーのリソースの割り当てと、許容できるクライアント パフォーマンスの間のバランスをどのように調整するかを決定する必要があります。検索フォルダがキャッシュされる際は、検索フォルダ内のデータの変更に応じて、検索フォルダが最新の状態に維持されます。これらの更新には、CPU とディスクのリソースが使用されます。検索フォルダの複数のキャッシュが保持されている場合は、CPU とディスクのパフォーマンスがさらに影響を受けます。

一方、Exchange Server が検索フォルダを最初に作成するときは、検索フォルダの作成のために Outlook フォルダにアクセスするユーザーが遅延を感じる可能性があります。

たとえば、11 の検索フォルダが構成されている Exchange Server について考えます。11 は、既定の検索フォルダ数です。ユーザー A は、他の 15 人のユーザーと予定表フォルダを共有しています。ユーザーB がフォルダにアクセスすると、自分の検索フォルダが作成されている間は遅延を感じます。ユーザー B 用の検索フォルダが作成されると、ユーザー A の予定表フォルダへのアクセスは高速になります。ユーザー B は、その日はそれ以上フォルダにはアクセスしなかったとします。その間に、他の 11 人のユーザーがフォルダにアクセスすると、各ユーザーに個別の検索フォルダが作成されます。キャッシュされる検索フォルダは 11 だけのため、次にユーザー B がユーザー A の予定表にアクセスしたとき、ユーザー B は再び新しい検索フォルダの作成による遅延を感じることになります。

ベスト プラクティスとして、検索フォルダのキャッシュの最大数を 20 以下に制限することをお勧めします。この値を超えると、特に 5,000 アイテムを超えるフォルダの場合は、サーバーがキャッシュされたフォルダを維持しようとするために過剰な負荷がかかる可能性があります。

また、キャッシュの数は 5 以上に設定するのが適切です。ユーザーが複数のユーザーと Outlook フォルダを共有している場合は、4 つの検索フォルダをキャッシュするだけではクライアントのパフォーマンスに悪影響を及ぼし、またサーバーでの新しいキャッシュのさらに頻繁な作成のためにより多くのリソースが使用されます。

msExchMaxCachedViews 属性は、パブリック フォルダ データベースでも設定できます。検索フォルダは、パブリック フォルダに対しても作成されます。既定では、パブリック フォルダは、多数のユーザーにアクセスされる可能性のある共有リソースです。パブリック フォルダが多数のポストを受信する場合は、検索フォルダの更新によって Exchange Server の CPU とディスクの使用率が高くなるため、検索フォルダを最小化する必要があります。また、多数のユーザーがパブリック フォルダにアクセスする場合に、検索フォルダのキャッシュの数を増やしてクライアントの動作を最適化しようとすることは適切な処置とは言えません。これらのキャッシュは、新しいユーザー用の検索フォルダが作成されるときに破棄されることになります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
msExchMaxCachedViews 属性を変更するには

  1. Microsoft Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

    • [InformationStore]

    • [<ストレージ グループ名>]

  3. 詳細ペインで、[データベース名] を右クリックし、[プロパティ] をクリックします。

  4. [Attribute] ボックスで、[msExchMaxCachedViews] をダブルクリックします。

  5. [Integer Attribute Editor] ダイアログ ボックスで、[値] ボックスに 5 ～ 20 の整数を入力し、[OK] をクリックします。

  6. [適用] をクリックし、ADSI Edit を終了します。

  7. レプリケーションが完了するまで、少なくとも 15 分待機します。次に、変更を行った Exchange Server で、Microsoft Exchange Information Store サービスを再開します。


最大キャッシュ ビューの設定値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、データベースごとのキャッシュ ビューの最大数が変更されているかどうかを判断します。msExchMaxCachedViews 属性値が 5 未満に設定されていることが検出されると、警告が表示されます。データベースごとに構成しているキャッシュ ビューの数は、Exchange Server アナライザの出力に含まれています。ベスト プラクティスとして、キャッシュ ビューの数を 5 ～ 20 に設定することをお勧めします。

msExchMaxCachedViews は、msExchangePrivateMDB オブジェクト クラスの属性です。したがって、Active Directory の各メールボックス データベース ストア オブジェクトには、msExchMaxCachedViews 属性値が存在します。msExchMaxCachedViews 属性値は、メールボックス内の特定のフォルダでキャッシュされるビューの最大数を指定します。

この場合の "ビュー" は、ユーザーが別のユーザーの Microsoft Office Outlook® 2003 メールボックスにアクセスしたときに表示されるフォルダを表します。ユーザーが Outlook フォルダへのアクセスを他のユーザーと共有している場合、個人的なアイテムを非表示にしたビューが Exchange Server によって生成されます。

Outlook ユーザーが別のユーザーの予定表、連絡先フォルダ、またはその他のデータを最初に表示するときは、遅延が発生する場合があります。一度ユーザーがフォルダを表示した後は高速に表示されるようになる可能性がありますが、ある程度の時間が経過した後に再度フォルダへのアクセスを試みると、遅延が発生することがあります。この遅延は一般に、フォルダに多数のアイテムが存在する場合に最も顕著になります。多数のアイテムとは、5,000 以上を指します。

フォルダにビューを適用すると、Outlook フォルダにアクセスするユーザーごとに、Exchange ストアに検索フォルダが作成されます。検索フォルダは作成時に、後で使用するためにキャッシュされます。Exchange Server は、新しい検索フォルダを作成する前に、検索フォルダが既に存在しているかどうかを判断します。検索フォルダが存在する場合、Exchange Server はキャッシュされた検索フォルダを使用して、以降の表示を高速化します。

msExchMaxCachedViews 属性は、特定のフォルダにキャッシュされている検索フォルダの数を定義します。たとえば、msExchMaxCachedViews 属性により、予定表フォルダにキャッシュされる検索フォルダの数を定義できます。

多数のユーザーが Outlook フォルダを共有している場合、サーバーのリソースの割り当てと、許容できるクライアント パフォーマンスの間のバランスをどのように調整するかを決定する必要があります。検索フォルダがキャッシュされる際は、検索フォルダ内のデータの変更に応じて、検索フォルダが最新の状態に維持されます。これらの更新には、CPU とディスクのリソースが使用されます。検索フォルダの複数のキャッシュが保持されている場合は、CPU とディスクのパフォーマンスがさらに影響を受けます。

一方、Exchange Server が検索フォルダを最初に作成するときは、検索フォルダの作成のために Outlook フォルダにアクセスするユーザーが遅延を感じる可能性があります。

たとえば、11 の検索フォルダが構成されている Exchange Server について考えます。11 は、既定の検索フォルダ数です。ユーザー A は、他の 15 人のユーザーと予定表フォルダを共有しています。ユーザーB がフォルダにアクセスすると、自分の検索フォルダが作成されている間は遅延を感じます。ユーザー B 用の検索フォルダが作成されると、ユーザー A の予定表フォルダへのアクセスは高速になります。ユーザー B は、その日はそれ以上フォルダにはアクセスしなかったとします。その間に、他の 11 人のユーザーがフォルダにアクセスすると、各ユーザーに個別の検索フォルダが作成されます。キャッシュされる検索フォルダは 11 だけのため、次にユーザー B がユーザー A の予定表にアクセスしたとき、ユーザー B は再び新しい検索フォルダの作成による遅延を感じることになります。

ベスト プラクティスとして、検索フォルダのキャッシュの最大数を 20 以下に制限することをお勧めします。この値を超えると、特に 5,000 アイテムを超えるフォルダの場合は、サーバーがキャッシュされたフォルダを維持しようとするために過剰な負荷がかかる可能性があります。

また、キャッシュの数は 5 以上に設定するのが適切です。ユーザーが複数のユーザーと Outlook フォルダを共有している場合は、4 つの検索フォルダをキャッシュするだけではクライアントのパフォーマンスに悪影響を及ぼし、またサーバーでの新しいキャッシュのさらに頻繁な作成のためにより多くのリソースが使用されます。

msExchMaxCachedViews 属性は、パブリック フォルダ データベースでも設定できます。検索フォルダは、パブリック フォルダに対しても作成されます。既定では、パブリック フォルダは、多数のユーザーにアクセスされる可能性のある共有リソースです。パブリック フォルダが多数のポストを受信する場合は、検索フォルダの更新によって Exchange Server の CPU とディスクの使用率が高くなるため、検索フォルダを最小化する必要があります。また、多数のユーザーがパブリック フォルダにアクセスする場合に、検索フォルダのキャッシュの数を増やしてクライアントの動作を最適化しようとすることは適切な処置とは言えません。これらのキャッシュは、新しいユーザー用の検索フォルダが作成されるときに破棄されることになります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
msExchMaxCachedViews 属性を変更するには

  1. Microsoft Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Administrative Groups]

    • [<管理グループ名>]

    • [Servers]

    • [InformationStore]

    • [<ストレージ グループ名>]

  3. 詳細ペインで、[データベース名] を右クリックし、[プロパティ] をクリックします。

  4. [Attribute Editor] ボックスで、[msExchMaxCachedViews] をダブルクリックします。

  5. [Integer Attribute Editor] ダイアログ ボックスで、[値] ボックスに 5 ～ 20 の整数を入力し、[OK] をクリックします。

  6. [適用] をクリックし、ADSI Edit を終了します。

  7. レプリケーションが完了するまで、少なくとも 15 分待機します。次に、変更を行った Exchange サーバーで、Microsoft Exchange Information Store サービスを再開します。


ESE キャッシュの上限が手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、すべてのメールボックス ストア オブジェクトについて msExchESEParamCacheSizeMax 属性の値を判断します。msExchESEParamCacheSizeMax 属性に 0 より大きく、219727 より小さい値が設定されているメールボックス ストアが 1 つでも存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange 2000 Server の場合、STORE.EXE によって使用される仮想メモリの大部分は ESE バッファ用に割り当てられます。Exchange 2000 Server は、このバッファのためにハード コードされた既定値の 858 MB を使用します。Exchange Server 2003 の場合、ESE バッファの割り当ては、Boot.ini ファイル内に /3GB スイッチがあるかどうかに基づきます。/3GB スイッチが存在する場合、ESE バッファは 896 MB に調整されます。/3GB スイッチが存在しない場合、ESE バッファは 576 MB に調整されます。自動調整はどの場合でも便利ですが、状況によっては、自動調整を無効にし、より環境に適した値を手動で設定する必要があります。この値には 8,192 の倍数であれば任意の値を設定できますが、以下の表に示されている値のみを使用することをお勧めします。

推奨値 | メモリ割り当て量 | コメント
147456 | 576 MB | 最小推奨値です。これよりも小さい値は設定しないでください。この値は、仮想メモリに制約があるサーバー、および Microsoft Windows® 2000 Server 上で実行されている Exchange Server 2003 に対して有効です。Windows 2000 Server では /3GB スイッチをサポートしていません。この値は、/3GB スイッチを使用していないシステムに対する既定値でもあります。
196608 | 768 MB | この値は、イベント 9582 が頻繁にログに記録される、大容量の仮想メモリを持つサーバーに対する推奨値です。
219726 | 858 MB | Exchange 2000 Server における既定値です。インプレース アップグレードを実行する、大容量の仮想メモリを備えたシステムに適しています。
229376 | 896 MB | これは Exchange Server 2003 の既定値です。アプリケーション イベント ログにイベント 9582 が存在するために他の値が適切だとわかる場合を除き、新しいシステムで使用するのに適した値です。
311296 | 1.2 GB | 設定可能な最大値です。この値を使用するのは、物理メモリを 2 GB 以上搭載したシステムのみにしてください。

この値を構成し直す前に、STORE.EXE プロセスによって消費される仮想メモリの量を監視する必要があります。このためには、Windows の Process パフォーマンス オブジェクトを監視します。/3GB スイッチを使用するシステムでは、Process オブジェクトの STORE.EXE インスタンスの Virtual Bytes カウンタが、2.8 GB 未満であることが必要です。/3GB スイッチを使用しないシステムでは、1.8 GB 未満であることが必要です。値がこれよりも大きい場合は、msExchESEParamCacheSizeMax の値を小さくする必要がある場合があります。値がこれよりも小さい場合は、msExchESEParamCacheSizeMax の値を大きくする必要がある場合があります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchESEParamCacheSizeMax 属性を調整するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックします。

  3. [CN=Services] を展開します。

  4. [CN=Microsoft Exchange] を展開します。

  5. [CN=<Exchange 組織名>] を展開します。

  6. [CN=Administrative Groups] を展開します。

  7. [CN=<管理グループ名>] を展開します。

  8. [CN=Servers] を展開します。

  9. [CN=<Exchange サーバー名>] を展開します。

  10. [CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  11. [Attributes] ボックスで、[msExchESEParamCacheSizeMax] までスクロールしてダブルクリックします。

  12. [Value] ボックスに、設定する値を入力します。上記の表を参考にして、使用するシステムに最適の値を決定します。値は 8192 の倍数である必要があることに注意してください。

  13. [OK] をクリックし、再度 [OK] をクリックします。

  14. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

メモリ使用量の最適化の詳細については、Microsoft サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。

msExchESEParamCacheSizeMax 属性の詳細については、Microsoft サポート技術情報の文書番号 266768「Exchange 2000 Server でストア データベースの最大キャッシュ サイズを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768) を参照してください。


ESE キャッシュ サイズの最大値の設定が大きすぎる
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、すべてのメールボックス ストア オブジェクトについて msExchESEParamCacheSizeMax 属性の値を判断します。また、Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、VMLargestBlockSize キーの値を判断します。VMLargestBlockSize キーは、仮想メモリの最大空きブロックのサイズ (バイト単位) を表します。

さらに、Exchange Server アナライザは Active Directory に対してクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されている値の数は、メールボックス ストア上のメールボックスの数を表します。

20 を超えるメールボックスがある Exchange Server コンピュータで、msExchESEParamCacheSizeMax の値が 219,726 より大きく、VMLargestBlockSize の値が 50,000,000 より大きく 150,000,000 より小さいことが検出されると、エラーが表示されます。このエラーは、Exchange Server コンピュータで msExchESEParamCacheSizeMax 属性が設定されている値が大きすぎることを示します。

Exchange 2000 Server では、STORE.EXE によって使用される大きな仮想メモリ領域が、ESE バッファに割り当てられます。Exchange 2000 Server は、このバッファのためにハード コードされた既定値の 858 MB を使用します。Exchange Server 2003 では、ESE バッファの割り当ては、Boot.ini ファイル内に /3GB スイッチが記述されているかどうかに基づいて行われます。/3GB スイッチが存在する場合、ESE バッファは 896 MB に調整されます。/3GB スイッチが存在しない場合、ESE バッファは 576 MB に調整されます。自動調整は、全体的には有効ですが、自動調整を無効にして、実際の環境により適した値を手動で設定したい場合があります。この値は、8,192 の任意の倍数に調整することが可能ですが、次の表に示した値のみを使用することをお勧めします。

推奨値 | メモリ割り当て量 | コメント
147456 | 576 MB | 最小推奨値です。これよりも小さい値は設定しないでください。この値は、仮想メモリに制約があるサーバー、および Microsoft Windows 2000 Server 上で実行されている Exchange Server 2003 に対して有効です。Windows 2000 Server は /3GB スイッチをサポートしていません。この値は、/3GB スイッチを使用していないシステムに対する既定値でもあります。
196608 | 768 MB | この値は、イベント 9582 が頻繁にログに記録される、大容量の仮想メモリを持つサーバーに対する推奨値です。
219726 | 858 MB | Exchange 2000 Server における既定値です。インプレース アップグレードを実行する、大容量の仮想メモリを備えたシステムに適しています。
229376 | 896 MB | これは Exchange Server 2003 の既定値です。アプリケーション イベント ログにイベント 9582 が存在するために他の値が適切だとわかる場合を除き、新しいシステムで使用するのに適した値です。
311296 | 1.2 GB | 設定可能な最大値です。この値は、物理メモリを 2 GB 以上搭載したシステムでのみ使用してください。

この値を構成し直す前に、STORE.EXE プロセスによって消費される仮想メモリの量を監視する必要があります。このためには、Windows の Process パフォーマンス オブジェクトを監視します。/3GB スイッチを使用するシステムでは、Process オブジェクトの STORE.EXE インスタンスの Virtual Bytes カウンタが、2.8 GB 未満であることが必要です。/3GB スイッチを使用しないシステムでは、1.8 GB 未満であることが必要です。値がこれらの量より大きい場合は、msExchESEParamCacheSizeMax の値を減らすことが必要な場合があります。値がこれらの量より小さい場合は、msExchESEParamCacheSizeMax の値を増やすことができます。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchESEParamCacheSizeMax 属性を調整するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックします。

  3. [CN=Services] を展開します。

  4. [CN=Microsoft Exchange] を展開します。

  5. [CN=<Exchange 組織名>] を展開します。

  6. [CN=Administrative Groups] を展開します。

  7. [CN=<管理グループ名>] を展開します。

  8. [CN=Servers] を展開します。

  9. [CN=<Exchange サーバー名>] を展開します。

  10. [CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  11. [Attributes] 一覧で、[msExchESEParamCacheSizeMax] までスクロールしてダブルクリックします。

  12. [Value] ボックスに、設定する値を入力します。上の表を使用して、システムに最適な値を判断します。使用する値は、8192 の倍数にする必要があることに注意してください。

  13. [OK] をクリックし、再度 [OK] をクリックします。

  14. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

メモリ使用量の最適化の詳細については、Microsoft サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。

msExchESEParamCacheSizeMax 属性の詳細については、Microsoft サポート技術情報の文書番号 266768「Exchange 2000 Server でストア データベースの最大キャッシュ サイズを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768) を参照してください。


ESE の最大キャッシュ サイズが増やされている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-02-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、すべてのメールボックス ストア オブジェクトについて msExchESEParamCacheSizeMax 属性の値を判断します。

また、Win32_PerfRawData_MSExchangeIS_MSExchangeIS Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、VMLargestBlockSize キーの値を判断します。VMLargestBlockSize キーは、仮想メモリの最大空きブロックのサイズ (バイト単位) を表します。

さらに、Exchange Server アナライザは Active Directory に対してクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されている値の数は、メールボックス ストア上のメールボックスの数を表します。

msExchESEParamCacheSizeMax の値が 219,726 を超えており、かつ、20 を超えるメールボックスが含まれている Exchange Server コンピュータ上の VMLargestBlockSize の値が次の範囲内にないことが検出されると、警告が表示されます。

  • 50,000,000 より大きく 150,000,000 未満である

  • 0 より大きく 50000001 未満である

この警告は、この Exchange Server コンピュータの msExchESEParamCacheSizeMax 属性の値が増やされているため、仮想メモリが少なくなる可能性があることを示しています。

Exchange 2000 Server の場合、STORE.EXE によって使用される仮想メモリの大部分は ESE バッファ用に割り当てられます。Exchange 2000 Server は、このバッファのためにハード コードされた既定値の 858 MB を使用します。Exchange Server 2003 の場合、ESE バッファの割り当ては、Boot.ini ファイル内に /3GB スイッチがあるかどうかに基づきます。/3GB スイッチが存在する場合、ESE バッファは 896 MB に調整されます。/3GB スイッチが存在しない場合、ESE バッファは 576 MB に調整されます。自動調整はどの場合でも便利ですが、状況によっては、自動調整を無効にし、より環境に適した値を手動で設定する必要があります。この値には 8192 の倍数であれば任意の値を設定できますが、以下の表に示されている値のみを使用することをお勧めします。

推奨値 | メモリ割り当て量 | コメント
147456 | 576 MB | 最小推奨値です。これよりも小さい値は設定しないでください。この値は、仮想メモリに制約があるサーバー、および Microsoft Windows 2000 Server 上で実行されている Exchange Server 2003 に対して有効です。Windows 2000 Server は /3GB スイッチをサポートしていません。この値は、/3GB スイッチを使用していないシステムに対する既定値でもあります。
196608 | 768 MB | この値は、イベント 9582 が頻繁にログに記録される、大容量の仮想メモリを持つサーバーに対する推奨値です。
219726 | 858 MB | Exchange 2000 Server における既定値です。インプレース アップグレードを実行する、大容量の仮想メモリを備えたシステムに適しています。
229376 | 896 MB | これは Exchange Server 2003 の既定値です。アプリケーション イベント ログにイベント 9582 が存在するために他の値が適切だとわかる場合を除き、新しいシステムで使用するのに適した値です。
311296 | 1.2 GB | 設定可能な最大値です。この値は、物理メモリを 2 GB 以上搭載したシステムでのみ使用してください。

この値を構成し直す前に、STORE.EXE プロセスによって消費される仮想メモリの量を監視する必要があります。このためには、Windows の Process パフォーマンス オブジェクトを監視します。/3GB スイッチを使用するシステムでは、Process オブジェクトの STORE.EXE インスタンスの Virtual Bytes カウンタが、2.8 GB 未満であることが必要です。/3GB スイッチを使用しないシステムでは、1.8 GB 未満であることが必要です。値がこれよりも大きい場合は、msExchESEParamCacheSizeMax の値を小さくする必要がある場合があります。値がこれよりも小さい場合は、msExchESEParamCacheSizeMax の値を大きくする必要がある場合があります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

msExchESEParamCacheSizeMax 属性を調整するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックします。

  3. [CN=Services] を展開します。

  4. [CN=Microsoft Exchange] を展開します。

  5. [CN=<Exchange 組織名>] を展開します。

  6. [CN=Administrative Groups] を展開します。

  7. [CN=<管理グループ名>] を展開します。

  8. [CN=Servers] を展開します。

  9. [CN=<Exchange サーバー名>] を展開します。

  10. [CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  11. [Attributes] 一覧で、[msExchESEParamCacheSizeMax] までスクロールしてダブルクリックします。

  12. [Value] ボックスに、設定する値を入力します。上記の表を参考にして、使用するシステムに最適の値を決定します。値は 8192 の倍数である必要があることに注意してください。

  13. [OK] をクリックし、再度 [OK] をクリックします。

  14. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

メモリ使用量の最適化の詳細については、Microsoft サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。

msExchESEParamCacheSizeMax 属性の詳細については、Microsoft サポート技術情報の文書番号 266768「Exchange 2000 Server でストア データベースの最大キャッシュ サイズを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266768) を参照してください。


MaxOpenMessagesPerLogon が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-05-14

Microsoft Exchange アナライザ ツールは、次のレジストリ エントリを読み取り、MaxOpenMessagesPerLogon レジストリ値が存在し構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Exchange アナライザによって、MaxOpenMessagesPerLogon レジストリ値が存在し、さらにそれが 0 より大きい値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server コンピュータ上の MAPI クライアントまたはアプリケーションがメッセージを開くたびに、Microsoft Exchange Information Store サービス (store.exe) は少量の物理メモリを消費します。Microsoft Office Outlook 2003 または Outlook 2007 クライアントによってメッセージが閉じられると、メモリは解放されます。1 つ以上の MAPI クライアントで、Exchange Information Store サービスによる継続的なメモリの割り当てが行われないようにするために、Exchange 2000 Server Service Pack 1 (SP1) では、各 MAPI クライアントのログオン セッションで同時に開くことができるメッセージ数を管理者が制限できるという新しい構成機能が導入されました。特定のクライアント アプリケーションが大量のメッセージを誤って開くことにより、サーバー全体のパフォーマンスが低下するような場合、このような制限値を使用中の環境で設定しておくと役立つことがあります。

この機能は、MaxOpenMessagesPerLogon レジストリ値を使用して Exchange Server コンピュータに実装されています。制限値は 1,000 未満に設定することをお勧めします。制限値を 1,000 に設定すると、各クライアントで約 4 ～ 6 メガバイト (MB) のメモリを使用することになります。環境によっては、制限値の設定を 500 にした方がよい場合もあります。

重要 :
この文書には、レジストリを編集する方法に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

同時に開くメッセージの最大数を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 以下を開きます。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [ParametersSystem] を右クリックして、[新規] をポイントします。次に、[DWORD 値] をクリックして、新しい値として MaxOpenMessagesPerLogon の名前を指定します。

  4. 右側のウィンドウで、[MaxOpenMessagesPerLogon] 値をダブルクリックし、同時に開くメッセージの最大数を 10 進数で入力します。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxOpenMessagesPerLogon レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 289109 の MAPI ログオンごとに開かれるメッセージの数を制限する方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=289109) を参照してください (このサイトは英語の場合があります)。


ストレージ グループあたりのデータベースの最大数が手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループの msExchMaxStoresPerGroup 属性の値を判断します。いずれかのストレージ グループについて、msExchMaxStoresPerGroup 属性の値が 5 ではないことが検出されると、エラーが表示されます。

この値は、サーバー上のすべてのストレージ グループに適用されます。このエラーは、この属性の値が既定値の 5 から変更されている場合に発生します。サポートされているのはこの値だけなので、変更しないでください。この値を増やすと、Exchange Server は正常に機能しません。

この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントといったツールを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services] を展開します。次に、[CN=Microsoft Exchange] を展開して [CN=<Exchange 組織名>] を展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. [CN=<サーバー名>] を展開し、[CN=InformationStore] を右クリックします。次に、[プロパティ] をクリックします。

  5. [Attribute Editor] で、[msExchMaxStoresPerGroup] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] ボックスで、値を 5 に設定します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

許可されるストレージ グループの最大数の詳細については、Microsoft サポート技術情報の文書番号 251123「[XADM] データベース容量計画のための Exchange 2000 内ストレージ グループの最大数」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=251123) を参照してください。

ADSI Edit の操作の詳細については、Windows Server ヘルプのトピック「Adsiedit.msc: ADSI Edit」 を参照してください (このページは英語の場合があります)。


ストレージ グループの最大数が手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各 InformationStore コンテナの msExchMaxStorageGroups 属性の値を判断します。msExchMaxStorageGroups 属性の値が 4 に等しくないことが検出されると、エラーが表示されます。

msExchMaxStorageGroups 属性に対してサポートされる値は 4 のみであり、この値を変更することはできません。この値が変更されると、Exchange は正常に動作しません。

この値は、Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP (ldp.exe) ツール、または他の任意のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントなどの Active Directory エディタを使用して修正する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. ADSI Edit または同様のツールを使用して、Active Directory 内にあるこのサーバーの InformationStore オブジェクトを見つけます。

    msExchMaxStorageGroups 属性は次の場所にあります。

    [CN=Configuration,DC=Domain,CN=com]、[CN=Services]、[CN=Microsoft Exchange]、[CN=組織名]、[CN=Administrative Groups]、[CN=管理グループ名]、[CN=Servers]、[CN=サーバー名]、[CN=InformationStore]

  2. msExchMaxStorageGroups 属性を、新しい値として「4」と入力して編集します。

  3. Active Directory エディタを終了し、Exchange Server コンピュータを再起動して、変更を有効にします。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリテイを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。


1 回のログオンで開かれるフォルダ オブジェクトの最大数が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、1 回の MAPI セッションで開かれるフォルダの既定の最大数が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtFolder

objtFolder レジストリ値が存在し、さらにそれが 500 以外の値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

手動で追加および構成されている場合、objtFolder レジストリ値は、1 台の MAPI クライアントが開くことができる最大フォルダ数を指定します。Exchange Server 2003 および Exchange Server 2007 では、開かれるフォルダの数は既定で 500 までに制限されます。MAPI クライアントが 500 を超えるフォルダを開こうとすると、クライアントのメールボックスが格納されている Exchange Server コンピュータのアプリケーション イベント ログに以下のイベントが記録されます。

イベントの種類 : | エラー
イベント ID : | 9646
ソース : | MSExchangeIS
イベント カテゴリ : | 全般
説明 : | オブジェクトの種類 "objtFolder" の許容される最大数 500 を超えたため、Mapi セッション "/o=組織名/ou=管理グループ名/cn=Recipients/cn=ユーザー名" を閉じます。

objtFolder レジストリ値を設定すると、管理者は MAPI クライアントが使用する Exchange Server リソースをさらにきめ細かく制御できるようになります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession

  3. objtFolder レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

  5. または、objtFolder レジストリ値を使用する場合は、このレジストリ値を削除する代わりに、設定を既定値のままにしておくか、必要に応じて調整します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

詳細については、Microsoft サポート技術情報の文書番号 830829「Exchange Server 2003 コンピュータは、MAPI クライアントが特定のサーバー オブジェクトの既定値より最も開いた後、応答を停止することがあります。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829) を参照してください。


1 回のログオンで開かれるフォルダ ビューの最大数が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、MAPI セッションごとに開くことのできるフォルダ ビューの既定の最大数が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtFolderView

objtFolderView レジストリ値が存在し、500 以外の値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

objtFolderView レジストリ値は、手動で追加および構成されると、MAPI クライアントごとに開くことのできるフォルダ ビューの最大数を規定します。Exchange Server 2003 および Exchange Server 2007 では、開かれるフォルダ ビューの数は既定で 500 までに制限されます。MAPI クライアントが 500 を超えるフォルダ ビューを開こうとすると、そのクライアントのメールボックスが含まれている Exchange Server コンピュータのアプリケーション イベント ログに次のイベントが記録されます。

イベントの種類 :エラー

イベント ソース :MSExchangeIS

イベント カテゴリ :全般

説明 : オブジェクトの種類 "objtFolderView" の許容される最大数 500 を超えたため、Mapi セッション "/o= <組織名> /ou= <管理グループ名> /cn=Recipients/cn= ユーザー名 " を閉じます。

管理者は objtFolderView レジストリ値を構成することによって、MAPI クライアントによって使用される Exchange Server リソースをより高いレベルで制御できるようになります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession

  3. objtFolderView レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

  5. あるいは、objtFolderView レジストリ キーを使用する場合は、削除しないで既存の値に設定されたままにしておくか、または必要に応じて調整します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

詳細については、Microsoft サポート技術情報の文書番号 830829「Exchange Server 2003 コンピュータは、MAPI クライアントが特定のサーバー オブジェクトの既定値より最も開いた後、応答を停止することがあります。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829) を参照してください。


1 回のログオンで開かれるメッセージ オブジェクトの最大数が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、1 回の MAPI セッションで開かれるメッセージの既定の最大数が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession\objtMessage

objtMessage レジストリ値が存在し、さらにそれが 250 以外の値で構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

手動で追加および構成されている場合、objtMessage レジストリ値は、1 台の MAPI クライアントが開くことができる最大メッセージ数を指定します。Exchange Server 2003 および Exchange Server 2007 では、開かれるメッセージの数は既定で 250 までに制限されます。MAPI クライアントが 250 を超えるメッセージを開こうとすると、クライアントのメールボックスが格納されている Exchange Server コンピュータのアプリケーション イベント ログに以下のイベントが記録されます。

イベントの種類 :エラー

イベント ID : 9646

ソース :MSExchangeIS

イベント カテゴリ :全般

説明 : オブジェクトの種類 "objtMessage" の許容される最大数 250 を超えたため、Mapi セッション "/o= <組織名> /ou= <管理グループ名> /cn=Recipients/cn= ユーザー名 " を閉じます。

objtMessage レジストリ値を設定すると、管理者は MAPI クライアントが使用する Exchange Server リソースをさらにきめ細かく制御できるようになります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。

    HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession

  3. objtMessage レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

  5. または、objtMessage レジストリ値を使用する場合は、このレジストリ値を削除する代わりに、設定を既定値のままにしておくか、必要に応じて調整します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

詳細については、Microsoft サポート技術情報の文書番号 830829「Exchange Server 2003 コンピュータは、MAPI クライアントが特定のサーバー オブジェクトの既定値より最も開いた後、応答を停止することがあります。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830829) を参照してください。


Maximum Polling Frequency が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、RPC over HTTP を使用して Exchange Server 2003 または Exchange Server 2007 にアクセスする Microsoft Office Outlook® 2003 および Outlook 2007 クライアントのポーリング間隔が、既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ Maximum Polling Frequency

Maximum Polling Frequency キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange サーバーに最初に接続するときに、Outlook は新着メッセージの通知に自身を登録します。Outlook ユーザーのメールボックスで新着メッセージを受信すると、Exchange はユーザー データグラム プロトコル (UDP) を使用して Outlook に通知を送信します。Outlook はこの通知を受信すると、Exchange サーバーからメッセージを取得して適切なフォルダに表示します。新着メールの通知を受信しない場合、Outlook は Exchange サーバーをポーリングします。ポーリングは Outlook によって開始されますが、ポーリング間隔は Exchange サーバーによって指定されます。

既定では、Outlook 2003 は 60 秒ごとにポーリングを行います。ポーリング間隔は、ユーザーのメールボックスを格納している Exchange サーバーに Maximum Polling Frequency レジストリ エントリを追加することで変更できます。入力する値は、最短のポーリング間隔を表すミリ秒単位の値です。Maximum Polling Frequency が存在しない場合は、既定の 60 秒 (60,000 ミリ秒) が使用されます。この既定値は、ポーリングが 60 秒ごとに実行されることを意味するわけではありません。この値とその 2 倍の値の範囲内で、ポーリングが実行されることを意味します。たとえば、Maximum Polling Frequency が 90 秒に設定されている場合は、前回のポーリングから 90 ～ 180 秒後にポーリングが実行されます。

Exchange、Outlook、およびネットワークのパフォーマンスが低下するのを防ぐため、既定値 (60 秒) よりも小さい値には設定しないようにしてください。さまざまなユーザーの操作によって新着メッセージが内部的にチェックされるため、この値を調整する必要がない場合もあります。たとえば、ユーザーがフォルダを移動したりメッセージを開いたりすると、サーバー上の新しいアイテムが表示されます。この動作が起こる経緯は次のとおりです。Outlook がユーザーの操作を有効にする目的で必要な RPC 要求を Exchange に送信すると、新しいメッセージ フラグがチェックされます。フラグが存在すれば、Outlook に送信される RPC 応答に新しいメッセージ通知が含まれることになります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Maximum Polling Frequency レジストリ値を削除します。

  4. Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC over HTTP の詳細については、『Exchange Server 2003 RPC over HTTP Deployment Scenarios』(http://go.microsoft.com/fwlink/?LinkId=47577) を参照してください (このサイトは英語の場合があります)。


ESE の最小キャッシュ サイズが手動で変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-01-16

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、すべてのメールボックス ストア オブジェクトの msExchESEParamCacheSizeMin 属性の値を判断します。いずれかのメールボックス ストアの msExchESEParamCacheSizeMin 属性の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Microsoft Exchange Information Store サービスは、ストア データをディスクに書き込むとき、バッファとして ESE (Extensible Storage Engine) キャッシュを使用します。Exchange 2000 Server は、858 MB の最大キャッシュ サイズを使用します。Exchange Server 2003 は、サーバーに実装されている物理ランダム アクセス メモリ (RAM) の量に基づいて msExchESEParamCacheSizeMin プロパティの既定値を動的に決定します。

たとえば、boot.ini ファイルで /3 GB スイッチが設定されている Exchange Server 2003 コンピュータの最大キャッシュ サイズは 896 MB です。/3GB スイッチが設定されていない場合の最大キャッシュ サイズは 576 MB です。

以下の情報を使用すると、msExchESEParamCacheSizeMin プロパティをその元の値に戻すことができます。

  • Exchange Server 2003 が Microsoft Windows Server™ 2003 上で実行されており、サーバーに 2 GB 以上の RAM が実装されている場合、msExchESEParamCacheSizeMin は 131,072 (512 MB) です。

  • Exchange 2003 が Windows Server 2003 上で実行されており、サーバーに 768 MB 以上、2 GB 未満の RAM が実装されている場合、msExchESEParamCacheSizeMin は "RAM/4*(4*1024)" です。

  • Exchange Server 2003 が Windows Server 2003 上で実行されており、サーバーに 768 MB 未満の RAM が実装されている場合、msExchESEParamCacheSizeMin は "RAM/8*(4*1024)" です。

次に、いくつかの例を示します。

  • 512 MB の RAM が実装された Windows Server 2003 では、msExchESEParamCacheSizeMin の既定値は 16,384 (4 KB ページ) になります。

  • 1 GB の RAM が実装された Windows Server 2003 では、msExchESEParamCacheSizeMin の既定値は 65,536 (4 KB ページ) になります。

  • 4 GB の RAM が実装された Windows Server 2003 では、msExchESEParamCacheSizeMin の既定値は 131,072 (4 KB ページ) になります。

  • Exchange Server 2003 が Microsoft Windows® 2000 Server 上で実行されている場合、msExchESEParamCacheSizeMin の既定値は設定されません。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Windows Server 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

この警告を修正するには

  1. ADSI Edit などの Active Directory エディタを起動します。

  2. [Configuration] コンテナをダブルクリックします。

  3. [CN=Services] を展開します。

  4. [CN=Microsoft Exchange] を展開します。

  5. [CN=<Exchange組織名>] を展開します。

  6. [CN=Administrative Groups] を展開します。

  7. [CN=<管理グループ名>] を展開します。

  8. [CN=Servers] を展開します。

  9. [CN=<Exchange サーバー名>] を展開します。

  10. [CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  11. [Attributes] 一覧で、msExchESEParamCacheSizeMin までスクロールしてダブルクリックします。

  12. [Value] ボックスに、設定する値を入力します。既定の数式を使用し、それを状況に合わせて編集することができます。使用する値は 32 MB の倍数にする必要があります。

  13. [OK] をクリックし、再度 [OK] をクリックします。

  14. Active Directory エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

msExchESEParamCacheSizeMin 属性のチューニングの詳細については、Microsoft サポート技術情報の文書番号 822894「バックアップまたはコンテンツ インデックス操作の間、正しく Jet データベースは動作しません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822894) を参照してください。


ストア プロセス用のスレッドの数が多い
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Process Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange インフォメーション ストア プロセスの ThreadCount の値を判断します。この値は、サーバー上でアクティブなストア スレッドの数を表します。アクティブなストア スレッドが 400 より多い場合、警告のメッセージが表示されます。

この問題の最も一般的な原因は、互換性のないウイルス対策ソフトウェアが同じコンピュータで実行されていることです。

この警告を修正するには

  1. ソフトウェア ベンダに連絡を取り、最新で Exchange と互換性のあるウイルス対策ソフトウェアを実行していることを確認します。

  2. 使用しているウイルス対策ソフトウェアを更新します。

ウイルス対策ソフトウェアと Exchange Server 2003 の詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。


OAB Bandwidth Threshold (KBps) レジストリ パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、OAB Bandwidth Threshold (KBps) レジストリ キーが作成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

OAB Bandwidth Threshold (KBps) レジストリ キーが ParametersSystem の下に作成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Microsoft Exchange Server 2003 Service Pack 1 (SP1) では、管理者は OAB Bandwidth Threshold (KBps) レジストリ キーを設定および構成することにより、既定の機能を無効にして、特定のパブリック ストアからのオフライン アドレス帳の完全なダウンロードに使用される帯域幅を制限することができます。

既定では、オフライン アドレス帳の完全なダウンロードを要求するすべてのクライアント要求が直ちに処理されます。また、パブリック ストアでも、オフライン アドレス帳の完全なダウンロードの同時発生数は制限されません。Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定の構成に戻す場合は、OAB Bandwidth Threshold (KBps) レジストリ キーを削除することができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [OAB Bandwidth Threshold (KBps)] 値を削除します。

  4. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

オフライン アドレス帳のダウンロード中に消費される帯域幅を調整する方法の詳細については、Microsoft サポート技術情報の文書番号 867623「全オフライン アドレス帳スロットリングは、Exchange Server 2003 での LAN 上の効果を制限するために、ダウンロードされます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=867623) を参照してください。


オフライン アドレス帳が特定のメールボックス ストアに関連付けられていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPrivateMDB クラスの msExchUseOAB 属性が、データベース上の特定のメールボックス ストア用に特定のオフライン アドレス帳を使用するように構成されているかどうかを判断します。msExchPrivateMDB クラスによって、プライベート データベース上の構成が決定されます。msExchUseOAB 属性によって、特定のメールボックス ストアが使用する特定のオフライン アドレス帳が決定されます。Exchange Server アナライザによって、データベース上のメールボックス ストアに対応するオフライン アドレス帳が存在しないことが検出されると、エラー メッセージが表示されます。

Exchange 2000 Server 以降のバージョンでは、オフライン アドレス一覧は、インフォメーション ストアに含まれるすべてのユーザーに関連付けられています。オフライン アドレス一覧を自動的に特定のメールボックスに関連付けたり、インフォメーション ストアまたはストレージ グループに対するグローバル オフライン アドレス一覧の設定を無効にしたりすることはできません。

オフライン アドレス一覧を特定のメールボックスに関連付けるには、まず、グローバル アドレス一覧のフィルタ済みのコピーを含むオフライン アドレス一覧を作成する必要があります。次に、Active Directory サービス インターフェイス (ADSI) Edit またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用して msExchUseOAB 属性にオフライン アドレス一覧の完全な識別名を設定することにより、オフライン アドレス一覧を特定のメールボックスに関連付ける必要があります。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他の LDAP Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

オフライン アドレス帳を特定のメールボックスに関連付ける方法の詳細については、Microsoft サポート技術情報の文書番号 275203「[XADM] オフライン アドレス帳はサーバーではなくユーザーが関連付ける必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=275203) を参照してください。

オフライン アドレス帳の詳細については、「Offline Address Book Best Practice Guide」(http://go.microsoft.com/fwlink/?LinkId=47583) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアの OLD Completion Time が既定値でない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、オンラインでの最適化が開始するまでの遅延時間が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\OLD Completion Time

OLD Completion Time キーが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。OLD Completion Time キーは、インフォメーション ストアの保守時間枠の後でオンラインの最適化が実行されるまでの時間 (秒) を指定します。既定値は 1 時間 (3,600 秒) です。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. OLD Completion Time キーを削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


パブリック フォルダ ストアの OLD Minimum RunTime が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、オンラインでの最適化の最小実行時間が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>\OLD Minimum RunTime

OLD Minimum RunTime キーが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。OLD Minimum RunTime キーは、オンラインの最適化が実行される最小時間 (秒) を指定します。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<PublicFolderStoreGUID>

  3. OLD Minimum RunTime キーを削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


オンラインでの最適化が無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループ オブジェクトの msExchESEParamEnableOnlineDefrag 属性の値を判断します。値が True の場合は、構成されたスケジュールに従ってデータベースのオンライン保守が行われることを示します。値が False の場合には、オンライン保守は行われません。Exchange Server アナライザによって、msExchESEParamEnableOnlineDefrag 属性の値が False に設定されていることが検出されると、エラーが表示されます。

最適化を含むデータベースのオンライン保守は、Exchange Server とって非常に重要です。保守時間中には、削除済みアイテムの格納場所のクリーンアップ (保存期間を過ぎたメッセージが削除される)、パブリック フォルダの有効期限の処理 (特定の日付より古いパブリック フォルダ内のメッセージが期限切れになる)、削除されたメールボックスのクリーンアップ、オンラインでの最適化 (使用されなくなったデータベース オブジェクトの検出と削除が行われ、利用可能なデータベース領域が拡大される)、などのタスクが実行されます。これらの処理は、Exchange サーバーを正常に動作させ、安定したパフォーマンスを維持する助けになります。データベースのオンライン保守は、[実行しない] に設定してはいけません。これは、時間が経つにつれてパフォーマンスが低下する原因になるためです。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

このエラーを修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「MMC」と入力して [OK] をクリックします。

  2. MMC (Microsoft 管理コンソール) で、[ファイル] メニューの [スナップインの追加と削除] をクリックします。

  3. [追加] をクリックし、[利用できるスタンドアロン スナップイン] の一覧で [ADSI Edit] を選択します。次に [追加] をクリックし、[閉じる] をクリックします。[スナップインの追加と削除] ダイアログ ボックスで [OK] をクリックします。

  4. [ADSI Edit] を右クリックし、[Connect to] をクリックします。ダイアログ ボックスの [Select a well known Naming Context] ボックスの一覧で、[Configuration] を選択し、[OK] をクリックします。

  5. [Configuration] コンテナを、[CN=Configuration]、[CN=Services]、[CN=Microsoft Exchange]、[CN=<組織名>]、[CN=Administrative Groups]、[CN=<管理グループ名>]、[CN=Servers]、[CN=<サーバー名>]、[CN=Information Store] の順に展開します。

  6. [CN=<ストレージ グループ名>] を右クリックし、[プロパティ]　をクリックします。

  7. そのストレージ グループのプロパティ ダイアログ ボックスで、属性の一覧から [msExchESEParamEnableOnlineDefrag] をクリックし、[Edit] をクリックします。次に、値を [True] に変更します。

  8. ADSI Edit を終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

オンラインのデータベース保守の詳細については、以下の Exchange 関連のリソースを参照してください。

  • Microsoft サポート技術情報の文書番号 314214「[HOW TO] Exchange 2000 Server でデータ ストアの保守の間隔を設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=314214)

  • Exchange Server 2007 Insider にある Exchange ストアの保守についての文書 (http://go.microsoft.com/fwlink/?LinkId=80787) (このサイトは英語の場合があります)


優先するバックフィルのソースが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Preferred Backfill Source キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Preferred Backfill Source

既定では、Preferred Backfill Source キーは存在しません。Exchange Server アナライザによって、Preferred Backfill Source キーが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。

バックフィル アレイは指定された期間 (バックフィル タイムアウト)、この情報を格納します。この期間中に以降のレプリケーション メッセージで不足している更新が受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。値は、不足している更新がどこにあるか、および過去にそれらの更新が要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィル元として使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える。停止しているか、または使用できないサーバーは一覧の最後に記載されます。

  • 優先するバックフィル サーバーに基づいて並べ替える (バックフィル サーバーが存在する場合。この機能を使用できるのは Exchange Server 2003 以降のみです)。Exchange Server 2003 は、Active Directory® ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先するバックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの場合、バックフィル プロセスは Exchange Server 2003 が自動的にバックフィル サーバーを選択する場合に最も効率が良くなります。Exchange Server 2003 のほとんどの展開には、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順)。同じサイト内のサーバーは、リモート サイトのサーバーより優先度が高くなります。サーバーのトランスポート コストは Exchange Server 2003 ルーティング エンジンによって算出され、通常、メッセージを配信する最も効率的な経路を算出するために使用します。Exchange Server 2003 より前のバージョンの Exchange では、並べ替えにおけるトランスポート コストの優先順位は低く、Exchange のバージョンおよび利用できる変更の数がトランスポート コストより先に考慮されることに注意してください。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)。

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順)。不足している変更がないサーバーは一覧から削除されます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。各要求の後、Exchange の以前のバージョンは再試行のタイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止とマークされたサーバーは一覧の最後に記載されます。

ほとんどの場合、Exchange Server にバックフィル サーバーの自動選択を許可すると、トポロジが効率的に動作します。トラブルシューティングの目的で、Microsoft 製品サポート サービスが Preferred Backfill Source を設定することをお勧めする場合があります。しかしこの方法は、特定の問題を解決するために必要な場合のみ使用してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Preferred Backfill Source レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Preferred Backfill Source の値を調査するか、編集します。

    このレジストリ エントリの値は KB 単位です。既定値に戻すには、Preferred Backfill Source を削除し、Microsoft Exchange Information Store サービスを再開する必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Store』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


優先するパブリック フォルダのバックフィルのソースが有効化されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、パブリック フォルダ階層について優先するバックフィルのソースが指定された状態で Exchange が構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック インフォメーション ストアの GUID>\Preferred Backfill Source

Preferred Backfill Source レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 では、msexchPreferredBackfillSource という名前の新しい Active Directory® ディレクトリ サービス属性が導入されており、この属性を使用することによって、バックフィル要求メッセージを受信する Exchange Server を指定できます。

パブリック フォルダでコンテンツのレプリケートを行う必要がある場合は、そのパブリック フォルダが Exchange 組織にバックフィル要求のクエリを送信します。最初に応答したパブリック フォルダ サーバーを使用して、データのバックフィルを実行します。このロジックは、最も近くにあるパブリック フォルダ サーバーが最初に応答することを前提としていますが、常にこうなるとは限りません。Exchange Server 2003 では、管理者がバックフィル用に優先するサーバーを指定できるようになりました。

Exchange Server 2003 では、Active Directory 属性またはパブリック フォルダ サーバーの Preferred Backfill Source レジストリ エントリのいずれかを使用して、パブリック フォルダ階層およびコンテンツのバックフィルに使用する優先サーバーを設定できます。最初に Active Directory パラメータがチェックされます。このパラメータが NULL の場合、レジストリ パラメータがチェックされます。このパラメータも存在しない場合は、パブリック フォルダ バックフィル用の既定のアルゴリズムが使用されます。

Active Directory 属性を使用するには、パブリック フォルダ ストア オブジェクトの msExchPreferredBackfillSource 属性で､必要なバックフィル パブリック フォルダ ストアの識別名 (DN) を設定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Active Directory 内の msExchPreferredBackfillSource 属性を編集する場合は、Active Directory サービス インターフェイス (ADSI) Edit や LDP (Ldp.exe) ツールなどの Active Directory エディタを使用する必要があります。

注意 :
ADSI Edit、LDP ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

レジストリで優先するパブリック フォルダ バックフィルのソースを指定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック インフォメーション ストアの GUID>

  3. Preferred Backfill Source 値を調べ、必要に応じて変更します。入力する値は、ソースとして優先的に使用する Exchange パブリック フォルダ ストアの識別名 (DN) です。

  4. 変更を加えた場合は、パブリック インフォメーション ストアのマウントをいったん解除してから再度マウントし、変更を有効にします。

Active Directory で優先するパブリック フォルダ バックフィルのソースを指定するには

  1. 対象となる msExchPreferredBackfillSource のパブリック フォルダ ストア オブジェクトの値を変更し、目的のバックフィルのソースをポイントします。msExchPreferredBackfillSource 属性は次の場所にあります。CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Administrative Groups, CN=管理グループ名, CN=Servers, CN=サーバー名, CN=InformationStore, CN=ストレージ グループ名, CN=パブリック フォルダ ストア

  2. 入力する値は、ソースとして優先的に使用する Exchange パブリック フォルダ ストアの識別名 (DN) です。

  3. 変更を加えた場合は、パブリック インフォメーション ストアのマウントをいったん解除してから再度マウントし、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

LDP ツールを使用して Active Directory を変更する方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260745) を参照してください。


より多くのディスク領域を準備する
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、Exchange Server を実行しているコンピュータのディスク領域が許容レベルに達していないと判断しました。Exchange Server アナライザは、利用可能なディスク領域を測定して、この領域が許容範囲内であることを確認します。ディスク領域が許容レベルに達していないことが検出されると、エラー メッセージが表示されます。Exchange Server を実行しているコンピュータ内の、メールボックスが含まれているすべてのディスクには、少なくとも 10% の空き領域を常に確保することをお勧めします。

Exchange Server アナライザは、以下のドライブのテストを実行します。

  • データベース ドライブ

  • 一時ドライブ

  • MailRoot ドライブ

  • STM ドライブ

  • システム ドライブ

  • ログ ドライブ

    注 :
    状態テーブルに対しては、ログ ドライブのサイズを増やし、ログをアーカイブする必要があります。
  • ページ ドライブ

このエラーを修正するには

  1. ディスクの空き領域を増やすには、ディスクから不要なファイルを削除します。

  2. 空き領域が 10% 未満のディスクに、別のディスクに安全に移動できるデータ (メールボックス、Microsoft Windows® ページ ファイルなど) が格納されている場合は、そのデータを移動するために必要な手順を実行します。

  3. Exchange Server を実行しているコンピュータのディスク容量を増やします。

  4. メールボックスのサイズを小さくするか、または別のサーバーにユーザーを移動します。

詳細情報

  • Exchange Server 2003 でのメールボックスの移動の詳細については、マイクロソフト サポート技術情報の文書番号 821829 の、Exchange Server 2003 でのメールボックスの移動についてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

  • Exchange 2000 Server と Exchange 5.5 Server との間でメールボックスを移動する方法の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

  • Exchange Server 2003 のシステム ポリシーを使用してメールボックスの制限を設定する方法の詳細については、マイクロソフト サポート技術情報の文書番号 822938 の、Exchange Server 2003 でシステム ポリシーを使用してメールボックス格納域の制限を構成する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822938) を参照してください。

  • Exchange 2000 Server のシステム ポリシーを使用してメールボックスの制限を設定する方法の詳細については、マイクロソフト サポート技術情報の文書番号 319130 の、Exchange 2000 でシステム ポリシーを使用してメールボックス格納域の制限を構成する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=319130) を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Exchange Server 2003 Performance and Scalability Guide』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ストレージ アーキテクチャ設計に関するベスト プラクティスの詳細については、複数のアーキテクチャに共通するベスト プラクティスについてのページ (英語ページの可能性があります)(http://go.microsoft.com/fwlink/?linkid=72988) を参照してください。

  • ディスクのサイズ変更、待ち時間、および入出力速度の詳細については、ディスク I/O 要件の計算方法についてのページ (英語ページの可能性があります)(http://go.microsoft.com/fwlink/?linkid=69747) を参照してください。


パブリック フォルダ ストアのデータベース ファイルがネットワーク ドライブに格納されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストア オブジェクトの msExchEDBFile 属性の値を判断します。この属性は、パブリック フォルダ ストアが使用するデータベース ファイルの場所を指定します。

Exchange Server アナライザは Active Directory に対してクエリを実行し、このサーバーに配置されている各メールボックス ストアの homeMDBBL 属性に列挙されている値の数も判断します。この属性に列挙されている値の数は、メールボックス ストア上のメールボックスの数を表します。Exchange Server アナライザは、それを基に、このサーバーが管理しているメールボックスの合計数を計算することができます。

Exchange Server アナライザによって、50 を超えるメールボックスが配置された Exchange Server の msExchEDBFile 属性が \\ で始まっていることが検出されると、エラーが表示されます。

このエラーは、パブリック フォルダ ストアのデータベース ファイルがネットワーク共有上に格納されていることを示します。msExchEDBFile 属性が \\ で始まる場合、ログ ファイルのパスに汎用名前付け規則 (UNC) パスが使用されています。ネットワーク接続の中断によってデータベース エラーが発生し、それによりデータの損失やデータベースの破損が生じる可能性があるため、共有への格納はお勧めできません。この問題はできだけ早く修正することをお勧めします。

データベース ファイルを新しいドライブに移動するには

  1. Exchange システム マネージャで、ストアが格納されている Exchange サーバー オブジェクトを展開し、該当するストレージ グループ コンテナを展開します。次に、目的のパブリック フォルダ ストア オブジェクトを右クリックして [プロパティ] をクリックします。

  2. パブリック フォルダ ストア オブジェクトのプロパティ ダイアログ ボックスの [データベース] タブで、新しいファイルの場所を指定します。

Exchange Server データベース ファイルの詳細については、次のトピックを参照してください。

  • 『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Managing Mailbox Stores and Public Folder Stores」(このサイトは英語の場合があります)

  • 『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Understanding the Exchange Server 2003 Store」(このサイトは英語の場合があります)

ネットワーク ドライブでの Exchange Server の使用の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328879「Exchange Server と SAN デバイスおよび NAS デバイスの使用について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328879)

  • 文書番号 839687「Exchange Server 2003 の network-attached 記憶域デバイスの使用の Microsoft Support ポリシー」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=839687)

  • 文書番号 317173「[XADM] Exchange 2000 Server と Network Attached Storage について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317173)

  • 文書番号 317172「[XADM] Exchange Server 5.5 と Network Attached Storage について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=317172)


パブリック フォルダ ストア データベースのサイズ制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Database Size Limit in Gb レジストリ値が存在し、パブリック フォルダ ストアに対して構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Public-<MailboxStoreGUID>

Database Size Limit in Gb 値が存在して構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 Standard Edition に Exchange Server 2003 Service Pack 2 (SP2) が適用されると、ハードコードされたライセンス データベースのサイズ制限が 16 GB から 75 GB に引き上げられます。意図せずにデータベースのサイズが拡大するのを防ぐ目的で、保護のためのデータベース サイズ制限を設定できます。SP2 では、既定のサイズ制限値は 18 GB ですが、この既定値は Database Size Limit in Gb レジストリ値を作成することによって上書きできます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<MailboxStoreGUID>

  3. Database Size Limit in Gb 値を削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアの完全バックアップが 9 日以上実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、パブリック フォルダ ストアに対してクエリを実行し、完全バックアップが最後に実行された日時を判断します。パブリック フォルダ ストアの完全バックアップが最後に実行されてからの日数が 8 よりも大きいことが検出されると、警告が表示されます。

パブリック フォルダ ストアは、ツリーの構造やツリーに含まれているフォルダなど、特定のパブリック フォルダ ツリーに関連付けられた情報を保持しています。また、パブリック フォルダの内容も保持されています。パブリック フォルダ ストアは、リッチテキストである .edb ファイルと、ストリーミング ネイティブ インターネット コンテンツである .stm ファイルで構成されています。

Exchange Server データベース内のメールボックス ストアとパブリック フォルダ ストアのデータ、およびトランザクション ログ ファイルは、Exchange Server 組織でバックアップする必要のある最も重要なデータです。Exchange Server データベースのバックアップを使用すると、破損したパブリック フォルダ ストアを、Exchange Server を実行している動作中のサーバーに復元できます。また、Exchange Server データベースのバックアップを使用して、Exchange Server データベースを別のサーバーに復元することもできます。

データベース ファイルとトランザクション ログの完全バックアップは毎日行うのが理想です。ストレージ グループの完全バックアップが完了した後、Exchange Server データベース上のコミット済みのトランザクション ログ ファイルはサーバーから削除されます。完全バックアップでは、1 つのテープ セットですべてのデータを復元できるため、回復シナリオが高速化されるという利点があります。

注 :
ベスト プラクティスとして、トランザクション ログ ファイルはデータベース ファイルとは別の専用ディスクに保存することをお勧めします。これにより、データベースのディスクが故障した場合のフォールト トレランスの向上に寄与します。また、データベースのパフォーマンスの向上につながる場合もあります。
重要 :
ファイルとフォルダのバックアップや復元を行うには、それに必要なアクセス許可や権限がログインしたユーザー アカウントに割り当てられている必要があります。Exchange Server のバックアップを作成するには、ドメイン レベルのバックアップ オペレータ権限が必要です。Microsoft Windows Server™ 2003 オペレーティング システムのバックアップを作成するには、少なくともローカル バックアップ オペレータ権限が必要です。

Exchange Server データに関して選択するバックアップ戦略は、ストアのサイズ、バックアップに使用するソフトウェアやハードウェアの速度、ハードウェアの容量、時間に関する要件などによって異なります。

バックアップ戦略および障害回復操作の詳細については、以下のサイトを参照してください。

  • 『Exchange Server 2003 障害回復ガイド』(http://go.microsoft.com/fwlink/?linkid=47570) (このサイトは英語の場合があります)

  • データベースのバックアップと復元についてのページ (http://go.microsoft.com/fwlink/?LinkID=80766) (このサイトは英語の場合があります)


パブリック フォルダ ストアの完全バックアップが 61 日以上実行されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、パブリック フォルダ ストアに対してクエリを実行し、完全バックアップが最後に実行された日時を判断します。パブリック フォルダ ストアの完全バックアップが最後に実行されてからの日数が 60 日を超えていることが検出されると、エラーが表示されます。

パブリック フォルダ ストアは、ツリーの構造やツリーに含まれているフォルダなど、特定のパブリック フォルダ ツリーに関連付けられた情報を保持しています。また、パブリック フォルダの内容も保持されています。パブリック フォルダ ストアは、リッチテキストである .edb ファイルと、ストリーミング ネイティブ インターネット コンテンツである .stm ファイルで構成されています。

Exchange Server データベース内のメールボックス ストアとパブリック フォルダ ストアのデータ、およびトランザクション ログ ファイルは、Exchange Server 組織でバックアップする必要のある最も重要なデータです。Exchange Server データベースのバックアップを使用すると、破損したパブリック フォルダ ストアを、Exchange Server を実行している動作中のサーバーに復元できます。また、Exchange Server データベースのバックアップを使用して、Exchange Server データベースを別のサーバーに復元することもできます。

データベース ファイルとトランザクション ログの完全バックアップは毎日行うのが理想です。ストレージ グループの完全バックアップが完了した後、Exchange Server データベース上のコミット済みのトランザクション ログ ファイルはサーバーから削除されます。完全バックアップでは、1 つのテープ セットですべてのデータを復元できるため、回復シナリオが高速化されるという利点があります。

注 :
ベスト プラクティスとして、トランザクション ログ ファイルはデータベース ファイルとは別の専用ディスクに保存することをお勧めします。これにより、データベースのパフォーマンスが向上するだけでなく、データベース ディスクが破壊された場合のフォールト トレランスが実現されます。
重要 :
ファイルとフォルダのバックアップや復元を行うには、それに必要なアクセス許可や権限がログインしたユーザー アカウントに割り当てられている必要があります。Exchange Server のバックアップを作成するには、ドメイン レベルのバックアップ オペレータ権限が必要です。Microsoft Windows Server™ 2003 オペレーティング システムのバックアップを作成するには、少なくともローカル バックアップ オペレータ権限が必要です。

Exchange Server データに関して選択するバックアップ戦略は、ストアのサイズ、バックアップに使用するソフトウェアやハードウェアの速度、ハードウェアの容量、時間に関する要件などによって異なります。

バックアップ戦略および障害回復操作の詳細については、以下のサイトを参照してください。

  • 『Exchange Server 2003 障害回復ガイド』(http://go.microsoft.com/fwlink/?linkid=47570) (このサイトは英語の場合があります)

  • データベースのバックアップと復元についてのページ (http://go.microsoft.com/fwlink/?LinkId=80766) (このサイトは英語の場合があります)


パブリック フォルダ ストアのサイズが 12 GB を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Exchange パブリック フォルダ ストアのデータベース ファイル (.edb ファイル) とストリーミング ファイル (.stm ファイル) の FileSize キーの値を判断します。また、以下のレジストリ ブランチも読み取り、インストールされている Exchange Server のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange の製品 GUID>

Microsoft Exchange Server 2003 Standard Edition または Exchange 2000 Server Standard Edition を実行しているコンピュータ上のパブリック フォルダ ストアのデータベース ファイルとストリーミング ファイルのペアの合計サイズが 12 GB を超えていることが検出されると、警告が表示されます。

Exchange Server 2003 Standard Edition と Exchange 2000 Server Standard Edition での Exchange ストア データベースは、16 GB を超えて拡大することはできません。この上限に達すると、メールボックス ストアはマウントされなくなり、Exchange にはアクセスできなくなります。Exchange Server 2003 Enterprise Edition と Exchange 2000 Server Enterprise Edition の場合、Exchange ストアのデータベースは 16 GB に制限されていません。使用可能なハードウェアによってのみ制限されますが、理論上の最大サイズは 16 テラバイトです。

この警告を修正するには

  1. パブリック フォルダ に有効期限ポリシーを設定することにより、一定期間が過ぎたメッセージを削除することを検討します。

  2. パブリック フォルダ ストアと個々のパブリック フォルダの両方に記憶域の制限を設定し、パブリック フォルダ ストアの無制限な増大を防止することを検討します。

  3. 最近、このパブリック フォルダ ストアから大量のメッセージまたはパブリック フォルダのレプリカを削除している場合は、オフラインでの最適化を実行することによりファイルのサイズが減る可能性があります。
注 :
Exchange Server 2003 Standard Edition 用の Exchange Server 2003 Service Pack 2 (SP2) のリリースでは、ハードコードされたライセンス データベース サイズ制限が 16 GB から 75 GB に拡大されました。管理者は、保護のためのデータベースのサイズ制限を設定できます (意図せずにデータベースのサイズが拡大するのを防ぐため)。Standard Edition 用の SP2 では、既定値は 18 GB で、この既定値は Database Size Limit in Gb レジストリ キーを編集することによって上書きできます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange Server 2003 SP2 でデータベースのデータベース サイズ制限を構成するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe を起動します。

  2. 次のレジストリ キーを開きます。HKLM\System\CurrentControlSet\Services\MSExchangeIS\サーバー名\Public-パブリック ストアの GUID

  3. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。Exchange Server 2003 Standard Edition では、1 ～ 75 の値を入力します (既定値は 18 GB です)。Exchange Server 2003 Enterprise Edition では、1 ～ 8000 の値を入力します (既定値は 8000 GB です)。[OK] をクリックします。

  6. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の値を入力して、どの時点でデータベースの最大サイズに近づいていることを警告するイベントをログに記録するかを指定します。既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。[OK] をクリックします。

  9. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (午前 5 時) にデータベース サイズをチェックします。[OK] をクリックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。

Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server データベースのオフラインでの最適化を実行する方法の詳細については、Microsoft サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804) を参照してください。

パブリック フォルダの記憶域の制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 823144 「HOW TO: 格納域の制限を 2003 パブリック フォルダの Exchange で構成します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823144) を参照してください。

Exchange Server 2003 Standard Edition および Exchange 2000 Server Standard Edition の最大データベース サイズへの到達に関する詳細については、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアのサイズが 15 GB を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_DataFile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、各 Exchange パブリック フォルダ ストアのデータベース ファイル (.edb ファイル) とストリーミング ファイル (.stm ファイル) について FileSize キーの値を判断します。また、以下のレジストリ ブランチも読み取り、インストールされている Exchange Server のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Exchange の製品 GUID>

Microsoft Exchange Server 2003 Standard Edition か Exchange 2000 Server Standard Edition を実行しているコンピュータで、パブリック フォルダ ストアのデータベース ファイルとストリーミング ファイルの合計サイズが 15 GB を超えていることが検出されると、エラーが表示されます。

Exchange Server 2003 Standard Edition と Exchange 2000 Server Standard Edition での Exchange ストア データベースは、16 GB を超えて拡大することはできません。この上限に達すると、メールボックス ストアはマウントされなくなり、Exchange にはアクセスできなくなります。Exchange Server 2003 Enterprise Edition と Exchange 2000 Server Enterprise Edition の場合、Exchange ストアのデータベースは 16 GB に制限されていません。使用可能なハードウェアによってのみ制限されますが、理論上の最大サイズは 16 テラバイトです。

このエラーを修正するには

  1. パブリック フォルダ に有効期限ポリシーを設定することにより、一定期間が過ぎたメッセージを削除することを検討します。

  2. パブリック フォルダ ストアと個々のパブリック フォルダの両方に記憶域の制限を設定し、パブリック フォルダ ストアの無制限な増大を防止することを検討します。

  3. 最近、このパブリック フォルダ ストアから大量のメッセージまたはパブリック フォルダのレプリカを削除している場合は、オフラインでの最適化を実行することによりファイルのサイズが減る可能性があります。
注 :
Exchange Server 2003 Standard Edition 用の Exchange Server 2003 Service Pack 2 (SP2) では、ハードコードされたライセンス データベースのサイズ制限が 16 GB から 75 GB に拡大されました。管理者は、保護のためのデータベースのサイズ制限を設定できます (意図せずにデータベースのサイズが拡大するのを防ぐため)。Standard Edition 用の SP2 では、既定値は 18 GB で、この既定値は Database Size Limit in Gb レジストリ キーを編集することによって上書きできます。
重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange Server 2003 SP2 でデータベースのデータベース サイズ制限を構成するには、次の操作を行います。

  1. Exchange Server を実行しているコンピュータで、Regedit.exe を起動します。

  2. 次のレジストリ キーを開きます。HKLM\System\CurrentControlSet\Services\MSExchangeIS\サーバー名\Public-パブリック ストアの GUID

  3. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  4. 新しい値の名前として、「Database Size Limit in Gb」と入力します。

  5. [Database Size Limit in Gb] をダブルクリックします。[値のデータ] に、最大データベース サイズの適切な値 (GB) を入力します。Exchange Server 2003 Standard Edition では、1 ～ 75 の値を入力します (既定値は 18 GB です)。Exchange Server 2003 Enterprise Edition では、1 ～ 8000 の値を入力します (既定値は 8000 GB です)。[OK] をクリックします。

  6. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  7. 新しい値の名前として、「Database Size Buffer in Percentage」と入力します。

  8. [Database Size Buffer in Percentage] をダブルクリックします。[値のデータ] に 1 ～ 100 の値を入力して、どの時点でデータベースの最大サイズに近づいていることを警告するイベントをログに記録するかを指定します。既定値の 10 に設定されている場合、データベースの最大サイズまでの残りが 10% になったときに警告イベントがログに記録されます。[OK] をクリックします。

  9. [パブリック ストアの GUID] を右クリックし、[新規] をポイントします。次に [DWORD 値] をクリックします。

  10. 新しい名前として、「Database Size Check Start Time in Hours From Midnight」と入力します。

  11. [Database Size Check Start Time in Hours From Midnight] をダブルクリックします。[値のデータ] ボックスに 0 ～ 23 の値を入力し、Exchange がどの時点でデータベース サイズをチェックするかを指定します。既定値の 5 に設定されている場合、Exchange Server は深夜 0 時から 5 時間後 (午前 5 時) にデータベース サイズをチェックします。[OK] をクリックします。

  12. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

.stm ファイルと .edb ファイルの詳細については、Microsoft サポート技術情報の文書番号 232323「[XADM] Exchange 2000 で通常行われるコンテンツの保存方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=232323) を参照してください。

Exchange Server 2003 でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=821829) を参照してください。

Exchange 2000 Server でのメールボックスの移動の詳細については、Microsoft サポート技術情報の文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328810) を参照してください。

Exchange Server データベースのオフラインでの最適化を実行する方法の詳細については、Microsoft サポート技術情報の文書番号 328804「Exchange のデータベースを最適化する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328804) を参照してください。

パブリック フォルダの記憶域の制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 823144 「HOW TO: 格納域の制限を 2003 パブリック フォルダの Exchange で構成します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823144) を参照してください。

Exchange Server 2003 Standard Edition および Exchange 2000 Server Standard Edition の最大データベース サイズへの到達に関する詳細については、Microsoft サポート技術情報の文書番号 828070「メールボックス ストア データベースが上限の 16 GB に達すると Exchange Server メールボックス ストアがマウントされない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアに電子メール アドレスがない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-03-28

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各パブリック フォルダ ストアの mail 属性のために構成されている値を判断します。mail 属性が構成されていないパブリック フォルダ ストアがあることが検出されると、警告が表示されます。

パブリック フォルダ ストアが SMTP (Simple Mail Transfer Protocol) アドレスを使用して構成されていない場合、そのストアに対するパブリック フォルダ階層のレプリケーションは正しく機能しません。

技術的には、パブリック フォルダ ストアは特別な種類の Exchange メールボックスです。メールボックスが有効なすべてのオブジェクトと同様に、パブリック フォルダ ストアでも、メールを送受信するためには以下の属性が正しく構成されている必要があります。

  • legacyExchangeDN Exchange 形式のオブジェクトの識別名です。

  • proxyAddresses この属性は、この受信者にメールを送信するために使用される可能性があるすべての電子メール アドレスを保持します。

  • textEncodedORAddress この属性にはプライマリ X.400 アドレスが格納されます。

  • Mail この属性には、オブジェクトのプライマリ SMTP アドレスが、アドレスのプレフィックスを付けずに格納されます。

  • mailNickname この属性は、メールボックスにアクセスするための URL を生成するために使用されます。

  • displayName この属性には、グローバル アドレス一覧や、そのオブジェクトがメンバとして属している他のアドレス一覧で使用されている形式で、オブジェクトの表示名が格納されます。

パブリック フォルダ ストアの mail 属性が設定されていない場合、受信者更新サービスが正しく構成されていないか、動作していないことがよくあります。受信者更新サービスには、2 つの種類があります。1 つは Configuration コンテナ内にある Exchange システム オブジェクトの処理を担当するエンタープライズ受信者更新サービス、もう 1 つは各ドメインの受信者の処理を担当するドメイン受信者更新サービスです。

Configuration コンテナは Active Directory フォレスト全体で 1 つしかないため、エンタープライズ受信者更新サービスも 1 つだけ存在します。パブリック フォルダ ストアの mail 属性の構成は、この受信者更新サービスによって行われます。この受信者更新サービスが無効にされていて、正しく構成されていない場合、または受信者更新サービスで問題が発生している場合、mail 属性が正しく構成されないことがあり、その場合はパブリック フォルダのレプリケーションが正しく動作しなくなります。この問題は、エンタープライズ受信者更新サービスの構成を確認して解決する必要があります。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、[受信者更新サービス] ノードを選択します。

  3. 右側のペインで、名前の一部として (Enterprise Configuration) を含む受信者更新サービスを右クリックし、[プロパティ] をクリックします。

  4. [ドメイン] ボックスに正しいドメイン名が示されていることを確認します。

  5. [Exchange サーバー] および [Windows ドメイン コントローラ] ボックスに表示されているコンピュータが、ネットワーク上で常に動作していて使用可能であることを確認します。これらのボックスに列挙されたシステムがダウンしている場合、使用できない場合、または受信者更新サービスのタスクを実行するために必要なシステムではない場合は、ボックスの [参照] ボタンを使用して代わりのコンピュータを指定できます。

  6. [更新の間隔] が [常時実行する] に設定されていることを確認します。

  7. [OK] をクリックし、変更を保存します。

  8. 右側のペインで、名前の一部として (Enterprise Configuration) を含む受信者更新サービスを右クリックし、[再構築] をクリックします。次のメッセージが表示されます。

    "この操作を実行すると、スケジュール済みの次回の更新時に、アドレス一覧のメンバシップおよび 'contoso.com' 内のすべてのユーザーの受信者ポリシーの設定が再計算されます。ドメイン内の受信者数により、処理に数時間かかる場合があります。続行しますか?"

  9. [はい] をクリックして受信者更新サービスを再構築します。

  10. 15 分後に、Microsoft サポート技術情報の文書番号 246127「Exchange 受信者更新サービスの進行状況を確認する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127) で概要が示されている手順に従って、受信者更新サービスの進行状況の監視を開始します。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 296479「[XADM] 受信者更新サービスを無効にするための要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=296479)

  • 文書番号 328738「受信者更新サービスで受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 文書番号 253770「Exchange 受信者更新サービスで実行されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)

  • 文書番号 288807「受信者更新サービスのトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=288807)

  • 文書番号 319065「Exchange 受信者更新サービスの使用方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319065)


サービス開始時にパブリック フォルダ ストアがマウントされない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchPublicMDB クラスを含むすべてのオブジェクトについて、msExchEDBOffline 属性の値を判断します。このクラスを含むオブジェクトは、パブリック フォルダ ストアです。

msExchEDBOffline 属性値が True の場合、Microsoft Exchange Information Store サービスの開始時にパブリック フォルダ ストアが自動的にマウントされることはありません。この属性値が False の場合、開始時にパブリック フォルダがマウントされます。Exchange Server アナライザによって、この属性値が True に設定されていることが検出されると、警告が表示されます。

この警告は、[起動時にこのストアをマウントしない] チェック ボックスがオンになっていることを示しています。このチェック ボックスは、パブリック フォルダ ストアのプロパティダイアログ ボックスの [データベース] タブにあります。このチェック ボックスがオンになっていると、パブリック フォルダ ストアは Microsoft Exchange Information Store サービスの開始時に自動的にマウントされません。サーバーの再起動の後など、次に Microsoft Exchange Information Store サービスが開始されたとき、この属性が True に設定されているパブリック フォルダ ストアはマウントされません。Microsoft Exchange Information Store サービスの開始時にパブリック フォルダ ストアが自動的にマウントされるようにすることをお勧めします。

Exchange 2000 Server および Exchange Server 2003 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、変更するパブリック フォルダ ストアが含まれるサーバーを展開します。

  3. 変更するパブリック フォルダ ストアが含まれるストレージ グループを展開します。

  4. パブリック フォルダ ストアを右クリックし、[プロパティ] をクリックします。

  5. [データベース] タブで、[起動時にこのストアをマウントしない] チェック ボックスをオフにします。

  6. [OK] をクリックして設定を保存します。

  7. Exchange システム マネージャを終了します。

Exchange Server 2007 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [サーバーの構成] を展開し、操作するサーバーを選択します。

  3. 操作するストレージ グループを展開します。

  4. 操作するパブリック フォルダ データベースを右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[起動時にこのデータベースをマウントしない] チェック ボックスをオフにします。

  6. [OK] をクリックして設定を保存します。

  7. Exchange 管理コンソールを終了します。

このオプションの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 314218「[HOW TO] Exchange 2000 Server で起動時にデータ ストアの自動マウントをオフまたはオンにする」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=314218)

  • 文書番号 285169「[XADM] "/disasterrecovery" スイッチの使用後にインフォメーション ストアがマウントしない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=285169)


パブリック フォルダ ツリー データベースの割り当て
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 msExchPFTree オブジェクト クラスの msExchOwningPFTreeBL 属性の値を判断します。msExchOwningPFTreeBL 属性には、パブリック フォルダ ツリーのレプリカが含まれたパブリック フォルダ ストアの識別名の一覧が格納されています。Exchange Server アナライザによって、パブリック フォルダ ツリー オブジェクトの msExchOwningPFTreeBL 属性が空であることが検出されると、警告が表示されます。この警告は、パブリック フォルダ ツリーがどのパブリック フォルダ ストアにも所有されていないことを示します。

各パブリック フォルダ ツリー ("パブリック フォルダ階層" とも呼ばれます) は、パブリック フォルダ ストアへリンクされます。最初にツリーを作成してからストアを作成する必要があります。ツリーがデータベースにリンク済みでない場合は、この警告が表示されます。各パブリック フォルダ ツリーには、特定のサーバー上の 1 つのストアのみ格納できます。各ストアが別々のサーバーにある場合、ツリーは複数のストアを持つことができます。このような構成では、Exchange はストア間で情報をレプリケートして階層の整合性を維持します。

Microsoft Office Outlook® Web Access クライアントが、パブリック フォルダ ストアが関連付けられていないツリー内にあるパブリック フォルダのいずれかに接続を試みると、"サービスを使用できません" (HTTP 503) エラーが発生します。

この警告を修正するには、次の手順のいずれかを実行する必要があります。

  • パブリック フォルダ ツリーをパブリック フォルダ データベースにリンクします。パブリック フォルダ ツリーをパブリック フォルダ データベースにリンクするには、最初に新しいパブリック フォルダ データベースを作成し、次にパブリック フォルダ ツリーを見つけてその 2 つをリンクします。

  • パブリック フォルダ ツリーを削除します。パブリック フォルダ ツリーがパブリック フォルダ データベースにリンク済みでない場合は、このツリーを削除してもユーザー データは失われません。

パブリック フォルダ ツリーをパブリック フォルダ データベースにリンクするには

  1. Exchange システム マネージャで、パブリック フォルダ ストアを追加するサーバーを展開します。

  2. 特定のストレージ グループを右クリックし、[新規作成] をポイントします。次に、[パブリック ストア] をクリックします。

  3. [名前] に、新しいデータベースの名前を入力します。

  4. パブリック フォルダ ツリーをそのデータベースと関連付けるために、[参照] をクリックし、Exchange Server アナライザの警告に表示されたパブリック フォルダ ツリーを選択します。

  5. 設定を保存するには、[OK] をクリックします。

  6. 新しいストアをマウントするには、[はい] をクリックします。

パブリック フォルダ ツリーを削除するには

  1. Exchange システム マネージャで、パブリック フォルダ ツリーが格納されている [フォルダ] ノードを展開します。

  2. 削除するパブリック フォルダ ツリーを右クリックし、[削除] をクリックします。次に、[はい] をクリックします。

パブリック フォルダの管理の詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?linkid=47617) の「Managing Mailbox Stores and Public Folder Stores」を参照してください (このサイトは英語の場合があります)。

詳細については、「Exchange Server 2003 Service Pack 1 (SP1) Online Help」(http://go.microsoft.com/fwlink/?LinkId=29847) も参照してください (このサイトは英語の場合があります)。


回復用ストレージ グループが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchStorageGroup クラスを含むすべてのオブジェクトについて、msExchESEParamBaseName 属性の値を判断します。このクラスを持つオブジェクトは、ストレージ グループ オブジェクトです。msExchESEParamBaseName 属性の値が R00 である場合、そのストレージ グループ オブジェクトは回復用ストレージ グループです。Exchange Server アナライザによって、この属性値が R00 であることが検出されると、警告が表示されます。

この警告は、回復用ストレージ グループが存在することを示します。回復用ストレージ グループは、回復処理の完了後に削除することをお勧めします。回復用ストレージ グループを削除しないと、回復用ストレージ グループのことを知らない管理者が後日、通常の回復を実行する際に混乱する可能性があります。

Exchange 2000 Server および Exchange Server 2003 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、削除する回復用ストレージ グループを含むサーバーを展開します。

  3. 回復用ストレージ グループを右クリックし、[削除] をクリックします。

  4. Exchange システム マネージャを終了します。

Exchange Server 2007 の場合にこの警告を修正するには、次の操作を行います。

  1. Exchange Server 2007 の主要ドキュメントにある、回復用ストレージ グループを削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80783) の手順に従ってください (このサイトは英語の場合があります)。

回復用ストレージ グループと Exchange Server 2003 の詳細については、Exchange Server 2003 での回復用ストレージ グループの使用に関するページ (http://go.microsoft.com/fwlink/?LinkId=23233) (このサイトは英語の場合があります)、および Microsoft サポート技術情報の文書番号 824126「Exchange Server 2003 の回復用ストレージ グループの使用方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=824126) を参照してください。

回復用ストレージ グループおよび Exchange Server 2007 の詳細については、回復用ストレージ グループについてのページ (http://go.microsoft.com/fwlink/?LinkId=80784) を参照してください (このサイトは英語の場合があります)。


回復用ストレージ グループ機能が無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchMaxRestoreStorageGroups 属性が変更されているかどうかを判断します。msExchMaxRestoreStorageGroups 属性が 0 に設定されていることが検出されると、エラーが表示されます。

msExchMaxRestoreStorageGroups 属性は、各 Exchange コンピュータのインフォメーション ストア オブジェクトのバイナリ属性です。msExchMaxRestoreStorageGroups 属性が 0 に設定されている場合、特定の Exchange コンピュータに対して回復用ストレージ グループを作成できません。

このエラーは、Windows クラスタ上で Exchange 2000 Server SP3 から Exchange Server 2003 SP1 へのインプレース アップグレードが実行されている場合に発生する可能性があります。この場合、Exchange 仮想サーバーが Exchange Server 2003 にアップグレードされていません。このインプレース アップグレードは、Outlook® Mobile Access が失敗する原因にもなる場合があることに注意してください。

各 Exchange コンピュータのインフォメーション ストア オブジェクトの msExchMaxRestoreStorageGroups 属性を 1 に設定することで、回復用ストレージ グループのエラーを修正する必要があります。影響を受けるインフォメーション ストア オブジェクトは、Exchange Server アナライザの出力に表示されます。Outlook Mobile Access に関する問題で支援が必要な場合は、Microsoft サポートに問い合わせてください。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP ツール (ldp.exe)、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 や、Exchange Server 2003 または Exchange Server 2007 の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
回復用ストレージ グループのエラーを修正するには

  1. ADSI Edit を起動します。

  2. [Configuration] コンテナをダブルクリックし、[CN=Services]、[CN=Microsoft Exchange]、[CN=<Exchange 組織名>] の順に展開します。

  3. [CN=Administrative Groups] を展開し、[CN=<管理グループ名>] を展開します。次に、[CN=Servers] を展開します。

  4. 詳細ウィンドウで、[CN=InformationStore] を右クリックし、[プロパティ] をクリックします。

  5. [Attribute Editor] で、[msExchMaxRestoreStorageGroups] 属性をクリックし、[Edit] をクリックします。

  6. [Edit Attribute] に「1」と入力します。

  7. [適用] をクリックし、[OK] をクリックします。

  8. ADSI Edit を終了します。Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

LDP ツールの使用方法の詳細については、Microsoft サポート技術情報の文書番号 260745「[XADM] LDP ユーティリティを使用して AD オブジェクト属性を変更する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=260745) を参照してください。

Exchange の回復用ストレージ グループの詳細については、以下の Exchange 関連のリソースを参照してください。

  • Exchange Server 2003 での回復用ストレージ グループの使用法についてのページ (http://go.microsoft.com/fwlink/?LinkId=47589) (このサイトは英語の場合があります)

  • 回復用ストレージ グループの理解についてのページ (http://go.microsoft.com/fwlink/?LinkID=80784) (このサイトは英語の場合があります)


パブリック フォルダ サーバーの Replication Expiry が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-05-25

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、保存期間を過ぎたアイテムが Exchange ストアによって削除される間隔が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック フォルダ GUID>\Replication Expiry

Replication Expiry レジストリ値が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

メッセージの有効期限とは、指定された時間値を超えたパブリック フォルダ内のメッセージを有効期限切れにするプロセスです。メッセージの有効期限の既定の間隔は 24 時間です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>

  3. Replication Expiry レジストリ値を削除します。

  4. Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダの複製の詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?LinkId=47595) (このサイトは英語の場合があります) および Microsoft サポート技術情報の文書番号 273479「パブリック フォルダの複製と参照について」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=273479) を参照してください。


パブリック フォルダ ストアの Replication Folder Conflict Age Limit が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、フォルダ競合の許容期間が既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>\Replication Folder Conflict Age Limit

Replication Folder Conflict Age Limit レジストリ値が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

2 人のユーザーが、パブリック フォルダ内の同じメッセージを編集して変更した場合、保存されたメッセージは競合していると定義されます。この状況は、同じパブリック フォルダ サーバーで同時保存が発生する場合や、フォルダのレプリカを含む 2 つのサーバーでメッセージが編集される場合に発生することがあります。競合の許容期間内にパブリック フォルダの所有者が対応しない場合、許容期間が経過した後、競合はパブリック フォルダ ストアによって解決されます。Replication Folder Conflict Age Limit レジストリ値は、この許容期間を設定します。レジストリの値は、アイテムの競合状態が許容される日数です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder GUID>

  3. Replication Folder Conflict Age Limit レジストリ値を削除します。

  4. Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、Microsoft サポート技術情報の文書番号 273479「パブリック フォルダの複製と参照について」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=273479) を参照してください。


Replication Folder Count Limit 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Replication Folder Count Limit キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Folder Count Limit

Replication Folder Count Limit が存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Folder Count Limit は存在しません。Replication Folder Count Limit 値は、階層のレプリケーション メッセージにパックするフォルダの最大数を表します (パブリック フォルダ ツリーおよびパブリック フォルダのプロパティの階層をレプリケートするために使用)。この値は 1 ～ 1000 の範囲内にある必要があり、既定値は 20 です。このレジストリ キーは、Exchange Server 2003 以降のバージョンでは無効であり、以前のバージョンの Exchange Server でのみ使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Folder Count Limit レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Folder Count Limit の値を調べるか、または編集します。

    このレジストリ エントリの値は KB 単位です。既定値に戻すには、Replication Folder Count Limit を削除し、Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Store』(http://go.microsoft.com/fwlink/?Linkld=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Replication Folder Tree RMQ Timeout 値が変更された
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Replication Folder Tree RMQ Timeout キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Folder Tree RMQ Timeout

Replication Folder Tree RMQ Timeout が存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Folder Tree RMQ Timeout は存在しません。Exchange は、階層メッセージを使用してパブリック フォルダ ツリーの階層と、パブリック フォルダのプロパティをレプリケートします。パブリック フォルダ ストアは、レプリケートされた変更を受信した後、変更をメモリ (レプリケーション メッセージ キュー) に読み込んで処理します。Replication Folder Tree RMQ Timeout 値は、レプリケートされた階層の変更がメモリに保持される最大の時間を表します。この値は秒単位で、3,600 (1 時間) から 2,592,000 (30 日) までである必要があります。既定値は 604,800 (7 日) です。正常に処理された変更は、直ちにメモリから削除されます。それ以外の場合、変更は、処理が可能になるかタイムアウトの有効期間が経過するまでメモリに保持され、その後削除されます。

たとえば、フォルダについての変更がレプリケートされ、さらに、そのフォルダのサブフォルダについての別の変更がレプリケートされたとします。トポロジと、変更の間に経過した時間に応じて、変更は宛先のパブリック フォルダ ストアにさまざまな順序で到着する可能性があります。サブフォルダへの変更が最初に到着し、親フォルダへの変更が適用されるまでサブフォルダへの変更を正常に処理できない場合、サブフォルダへの変更は親フォルダへの変更が到着して処理されるまで、パブリック フォルダ ストアによってメモリに保持されます。親フォルダへの変更が処理される前にタイムアウトの時間が経過した場合、サブフォルダへの変更はメモリから削除されます。親フォルダへの変更が処理された後で、パブリック フォルダ ストアがサブフォルダへの変更のコピーを受信し、変更が正常に処理されることがあります。パブリック フォルダ ストアがサブフォルダへの変更のコピーを受信しない場合、そのストアはトポロジに属する別のパブリック フォルダ ストアの状態と自身の状態を照合する際に、自身のパブリック フォルダ ツリーのコピーにサブフォルダへの変更が欠けていることを検出し、変更のバックフィル処理を開始します。

ほとんどの場合、Replication Folder Tree RMQ Timeout を既定値から変更することはお勧めしません。この値が変わっている場合、レプリケーション トラフィックが多い期間 (たとえば、新しいパブリック フォルダ ストアが追加された後) に一時的に増加した可能性があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Folder Tree RMQ Timout レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Folder Tree RMQ Timeout の値を確認または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Folder Tree RMQ Timeout を削除し、Microsoft Exchange Information Store サービスを再開する必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、「Working with Exchange Server 2003 Stores」(http://go.microsoft.com/fwlink/?Linkld=33049) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ ストアの Replication Folder Tombstone Age Limit が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、パブリック フォルダ削除標識エントリを削除する期間が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder Store GUID>\Replication Folder Tombstone Age Limit

レジストリに Replication Folder Tombstone Age Limit が存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

削除標識の情報は、パブリック フォルダのレプリケーションで使用されます。フォルダの削除標識の一覧が無制限に大きくなるのを防ぐために、保存期間は必要です。既定値は 180 日ですが、この値は Replication Folder Tombstone Age Limit レジストリ値で変更できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<Public Folder Store GUID>

  3. Replication Folder Tombstone Age Limit レジストリ値を削除します。

  4. Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Replication Folder Tombstone Age Limit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 159196「[XADM] IS 保守スケジュールで制御されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=159196) を参照してください。


Replication Long Backfill Request Delay 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Replication Long Backfill Request Delay キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Long Backfill Request Delay

Replication Long Backfill Request Delay キーが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Long Backfill Request Delay キーは存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウト)、この情報を格納します。この期間中に以降のレプリケーション メッセージで不足している更新が受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。値は、不足している更新がどこにあるか、および過去にそれらの更新が要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィル元として使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える。停止しているか、または使用できないサーバーは一覧の最後に記載されます。

  • 優先するバックフィル サーバーに基づいて並べ替える。バックフィル サーバーが存在する場合。この機能を使用できるのは Exchange Server 2003 以降のみです。Exchange Server 2003 は、Active Directory® ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先するバックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの場合、バックフィル プロセスは Exchange Server 2003 が自動的にバックフィル サーバーを選択する場合に最も効率が良くなります。Exchange Server 2003 のほとんどの展開には、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順)。同じサイト内のサーバーは、リモート サイトのサーバーより優先度が高くなります。サーバーのトランスポート コストは Exchange Server 2003 ルーティング エンジンによって算出され、通常、メッセージを配信する最も効率的な経路を算出するために使用します。Exchange Server 2003 より前のバージョンの Exchange ではトランスポート コストの優先度が低く、トランスポート コストは Exchange のバージョンおよび利用できる変更数の後でしか考慮されません。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)。

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順)。不足している変更がないサーバーは一覧から削除されます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。各要求の後、Exchange の以前のバージョンは再試行のタイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止とマークされたサーバーは一覧の最後に記載されます。

Replication Long Backfill Request Delay 値は、同じ Exchange サイト内で使用できないデータに対するバックフィル要求を送信する前にストアが待機する時間を表します。この値は秒単位で、900 から 2,592,000 秒 (30 日) までである必要があります。既定値は 43,200 秒 (12 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Long Backfill Request Delay レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Long Backfill Request Delay の値を調査するか、編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Long Backfill Request Delay を削除し、Microsoft Exchange Information Store サービスを再開する必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Store』(http://go.microsoft.com/fwlink/?LinkId=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Replication Long Backfill Request Timeout 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Replication Long Backfill Request Timeout キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Long Backfill Request Timeout

Replication Long Backfill Request Timeout キーが存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Long Backfill Request Timeout キーは存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウトと呼ばれる) だけ、この情報を格納します。不足している更新が、この期間内に以降のレプリケーション メッセージで受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。これらの値は、不足している更新が存在する場所や、不足している更新が以前に要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィル元として使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える 停止しているサーバーや使用できないサーバーは、一覧の最後に移動されます。

  • 優先するバックフィル サーバーに基づいて並べ替える この機能は、Exchange Server 2003 以降でのみ使用できます。Exchange Server 2003 は、Active Directory ディレクトリ サービス内のパブリック フォルダ ストア オブジェクトをチェックし、優先するバックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの環境では、Exchange Server 2003 がバックフィル サーバーを自動的に選択する場合に、バックフィル プロセスが最も効率的に実行されます。Exchange Server 2003 のほとんどの展開では、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順) 同じサイト内のサーバーは、リモート サイトのサーバーより優先度が高くなります。サーバーのトランスポート コストは、Exchange Server 2003 ルーティング エンジンによって計算され、通常、メッセージを配信する最も効率的な経路を計算するために使用されます。Exchange Server 2003 より前のバージョンの Exchange ではトランスポート コストの優先度が低く、トランスポート コストは Exchange のバージョンおよび利用できる変更数の後でしか考慮されません。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順) 不足している変更がないサーバーは一覧から削除されます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。Exchange の以前のバージョンでは、1 つの要求を処理した後に再試行タイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止とマークされたサーバーは一覧の最後に記載されます。

Replication Long Backfill Request Timeout 値は、同じ Exchange サイト内で使用できないデータに対するバックフィル要求の送信を試みるときにパブリックフォルダストアが使用するタイムアウト値を表します。この値 (秒単位) は、900 ～ 2,592,000 秒 (30 日) にする必要があります。既定値は 86,400 秒 (24 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Long Backfill Request Timeout レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Long Backfill Request Timeout の値を調べるか、または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Long Backfill Request Timeout を削除し、Microsoft Exchange Information Store サービスを再開する必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、「Working with Exchange Server 2003 Stores」(http://go.microsoft.com/fwlink/?Linkld=33049) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Replication Long Backfill Request Timeout Retry 値が変更された
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Replication Long Backfill Request Timeout Retry キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Long Backfill Request Timeout Retry

Replication Long Backfill Request Timeout Retry キーが存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Long Backfill Request Timeout Retry は存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウト)、この情報を格納します。この期間中に以降のレプリケーション メッセージで不足している更新が受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。値は、不足している更新がどこにあるか、および過去にそれらの更新が要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィルのソースとして使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える 停止しているか、または使用できないサーバーは一覧の最後に記載されます。

  • 優先するバックフィル サーバー (存在する場合) に基づいて並べ替える この機能は Exchange Server 2003 以降でのみ利用できます。Exchange Server 2003 は、Active Directory® ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先するバックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの場合、バックフィル プロセスは Exchange Server 2003 が自動的にバックフィル サーバーを選択する場合に最も効率が良くなります。Exchange Server 2003 のほとんどの展開には、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順) 同じサイト内のサーバーは、リモート サイトのサーバーより優先度が高くなります。サーバーのトランスポート コストは Exchange Server 2003 ルーティング エンジンによって算出され、通常、メッセージを配信する最も効率的な経路を算出するために使用します。Exchange Server 2003 より前のバージョンの Exchange ではトランスポート コストの優先度が低く、Exchange のバージョンと利用できる変更の数の後でのみ並べ替えが考慮されます。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順) 不足している変更がないサーバーは一覧から削除されます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。Exchange の以前のバージョンでは、1 つの要求を処理した後に再試行タイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止とマークされたサーバーは一覧の最後に記載されます。

Replication Long Backfill Request Timeout Retry 値は、同じ Exchange サイト内で使用できないデータに対するバックフィル要求を送信するとき、およびこの要求が前のバックフィル要求の再試行であるときにパブリック フォルダ ストアが使用するタイムアウト値を表します。この値は秒単位で、900 から 2,592,000 秒 (30 日) までの必要があります。既定値は 172,800 秒 (48 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Long Backfill Request Timeout Retry レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Long Backfill Request Timeout Retry の値を確認または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Long Backfill Request Timeout Retry を削除し、Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Store』(http://go.microsoft.com/fwlink/?Linkld=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


起動時のレプリケーション メッセージが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange が以下のパブリック フォルダ階層の状態要求メッセージを生成するように構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック インフォメーション ストアの GUID>\Enable Replication Messages At Startup

Enable Replication Messages At Startup レジストリ エントリが存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 5.5 では、パブリック フォルダ ストアを保有する各コンピュータが状態要求メッセージを毎晩送信し、パブリック フォルダ階層の状態を判断します。Exchange 2000 Server と Exchange Server 2003 では、これは実行しません。Exchange 2000 Server と Exchange Server 2003 の場合、状態要求メッセージが送信されるのは通常、パブリック フォルダ ストアの有効期間内に一度だけ、つまりストアが作成されるときのみです。

ただし、状況によっては、状態要求メッセージの生成が必要となる場合があります。たとえば、Exchange 2000 Server コンピュータまたは Exchange Server 2003 コンピュータ上でパブリック フォルダ階層がレプリケートしていないように思われる場合、またはパブリック フォルダ階層のレプリケートに非常に時間がかかるような場合は、状態要求メッセージを生成することによって、パブリック フォルダ階層のレプリケートを続行させることができます。パブリック フォルダ ストアの作成時に送信された元の状態要求メッセージが削除されて認識できなくなった場合、またはメッセージがきわめて不完全な階層を持つサーバーに送信された場合は、パブリック フォルダ階層のレプリケーションに問題が発生する場合があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Aging Keep Time レジストリ値を表示または変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック インフォメーション ストアの GUID>

  3. Enable Replication Messages At Startup 値を確認し、必要に応じて変更します。有効にするには、この REG_DWORD 値を 1 に設定する必要があります。この値を 0 (既定の設定) に設定すると、パブリック インフォメーション ストアの起動時に状態要求メッセージが送信されません。

  4. 変更を加えた場合は、レジストリ エディタを終了し、パブリック インフォメーション ストアのマウントをいったん解除してから再度マウントし、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーション状態メッセージおよび Enable Replication Messages At Startup レジストリ値の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 321082「XADM: How to Send Replication Status Request Messages in Exchange 2000 Server」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=321082) (このサイトは英語の場合があります)

  • 文書番号 842273「Exchange 2000 Server および Exchange Server 2003 におけるパブリック フォルダのレプリケーションの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=842273)


Replication Short Backfill Request Delay の値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Replication Short Backfill Request Delay キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Short Backfill Request Delay

Replication Short Backfill Request Delay キーが存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Short Backfill Request Delay は存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウト)、この情報を格納します。この期間中に以降のレプリケーション メッセージで不足している更新が受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。値は、不足している更新がどこにあるか、および過去にそれらの更新が要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィルのソースとして使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える停止しているか使用できないサーバーは、一覧の最後に記載されます。

  • 優先バックフィル サーバー (存在する場合) に基づいて並べ替えるこの機能は Exchange Server 2003 以降でのみ利用可能です。Exchange Server 2003 は、Active Directory® ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先バックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの場合、バックフィル プロセスは Exchange Server 2003 が自動的にバックフィル サーバーを選択する場合に最も効率が良くなります。Exchange Server 2003 のほとんどの展開には、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順)同じサイトにあるサーバーが、リモート サイトのサーバーより優先されます。サーバーのトランスポート コストは Exchange Server 2003 ルーティング エンジンによって算出され、通常、メッセージを配信する最も効率的な経路を算出するために使用します。Exchange Server 2003 より前のバージョンの Exchange では、トランスポート コストは優先度が低く、Exchange のバージョンや利用可能な変更数の後でしか考慮されないことに注意してください。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順) 欠けている変更がないサーバーは一覧から除かれます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。Exchange の以前のバージョンでは、1 つの要求を処理した後に再試行タイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止としてマークされたサーバーは一覧の最後に記載されます。

Replication Short Backfill Request Delay の値は、パブリック フォルダ ストアが同じ Exchange サイトに存在しているデータへのバックフィル要求を送信するまでの待ち時間を表しています。この値 (秒単位) は、900 ～ 2,592,000 秒 (30 日) にする必要があります。既定値は 21,600 秒 (6 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Short Backfill Request Delay レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Short Backfill Request Delay の値を確認または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Short Backfill Request Delay を削除し、Microsoft Exchange Information Store サービスを再開する必要があります。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、「Working with Exchange Server 2003 Stores」(http://go.microsoft.com/fwlink/?Linkld=33049) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Replication Short Backfill Request Timeout の値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Replication Short Backfill Request Timeout キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Short Backfill Request Timeout

Replication Short Backfill Request Timeout が存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Short Backfill Request Timeout は存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウト)、この情報を格納します。この期間中に以降のレプリケーション メッセージで不足している更新が受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。値は、不足している更新がどこにあるか、および過去にそれらの更新が要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィルのソースとして使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える停止しているか使用できないサーバーは、一覧の最後に記載されます。

  • 優先バックフィル サーバー (存在する場合) に基づいて並べ替えるこの機能は Exchange Server 2003 以降でのみ利用可能です。Exchange Server 2003 は、Active Directory ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先バックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの場合、バックフィル プロセスは Exchange Server 2003 が自動的にバックフィル サーバーを選択する場合に最も効率が良くなります。Exchange Server 2003 のほとんどの展開には、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて並べ替える (最も低いコストから最も高いコストの順)同じサイトにあるサーバーが、リモート サイトのサーバーより優先されます。サーバーのトランスポート コストは Exchange Server 2003 ルーティング エンジンによって算出され、通常、メッセージを配信する最も効率的な経路を算出するために使用します。Exchange Server 2003 以前のバージョンの Exchange では、トランスポート コストの優先度は低く、Exchange のバージョンと利用可能な変更の数の後でのみ検討されることに注意してください。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)

  • サーバーで利用できる必要な変更の数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順) 欠けている変更がないサーバーは一覧から除かれます。

あるサーバーに必要な変更がすべて不足している場合、Exchange Server 2003 は並べ替えられた一覧内の次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。Exchange の以前のバージョンでは、1 つの要求を処理した後に再試行タイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

指定したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークして選択プロセスを継続します。停止とマークされたサーバーは一覧の最後に記載されます。

Replication Short Backfill Request Timeout の値は、パブリック フォルダ ストアが同じ Exchange サイトに存在しているデータへのバックフィル要求の送信を試みるときに使用するタイムアウト時間を表します。この値は秒単位で、900 から 2,592,000 秒 (30 日) までである必要があります。既定値は 43,200 秒 (12 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Short Backfill Request Timeout レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Short Backfill Request Timout の値を確認または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Short Backfill Request Timeout を削除し、Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with Exchange Server 2003 Stores』(http://go.microsoft.com/fwlink/?Linkld=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Replication Short Backfill Request Timeout Retry 値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Replication Short Backfill Request Timeout Retry キーが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\\<サーバー名>\Public-<パブリック ストアの GUID>\Replication Short Backfill Request Timeout Retry

Replication Short Backfill Request Timeout Retry が存在していることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Replication Short Backfill Request Timeout Retry キーは存在しません。バックフィルは、パブリック フォルダ ストアが、レプリケートされるフォルダ (または階層) に対する一部の更新を受信しておらず、不足している更新を別のストアから取得する必要があると判断したときに実行されます。

バックフィル プロセスを効率化するために、Exchange Server は不足している更新に関する情報をバックフィル アレイに格納します。バックフィル アレイは指定された期間 (バックフィル タイムアウトと呼ばれる) だけ、この情報を格納します。不足している更新が、この期間内に以降のレプリケーション メッセージで受信された場合、それらの更新はバックフィル アレイから削除されます。次の表に、既定のバックフィル タイムアウトの値を示します。これらの値は、不足している更新が存在する場所や、不足している更新が以前に要求されたことがあるかどうかによって異なります。

要求の種類 | 内容がローカル サイトの?ストアにある場合 | 内容がリモート サイトの?ストアにある場合
初回のバックフィル | 6 時間 | 12 時間
バックフィルの最初の再試行 | 12 時間 | 24 時間
バックフィルの 2 回目以降の再試行 | 24 時間 | 48 時間

バックフィル タイムアウトの期限が切れても更新が不足している場合、Exchange Server 2003 は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを特定します。

Exchange Server 2003 は、バックフィル元として使用する 1 つ以上のサーバーを選択するために、最初にフォルダのレプリカを保有するすべてのサーバーの一覧を作成し、次に以下の方法で一覧を並べ替えます。

  • サーバーの状態に基づいて並べ替える 停止しているサーバーや使用できないサーバーは、一覧の最後に移動されます。

  • 優先するバックフィル サーバーに基づいて並べ替える この機能は、Exchange Server 2003 以降でのみ使用できます。Exchange Server 2003 は、Active Directory® ディレクトリ サービスのパブリック フォルダ ストア オブジェクトを調べ、優先するバックフィル サーバーがあるかどうかを確認します。この設定はほとんど使用されません。ほとんどの環境では、Exchange Server 2003 がバックフィル サーバーを自動的に選択する場合に、バックフィル プロセスが最も効率的に実行されます。Exchange Server 2003 のほとんどの展開では、優先するバックフィル サーバーは必要ありません。Microsoft 製品サポート サービスは、展開で必要となる場合に、優先するバックフィル サーバーを設定するスクリプトを提供できます。

  • トランスポート コストに基づいて (コストの低い方から高い方に) 並べ替える 同じサイト内のサーバーの優先度は、リモート サイトのサーバーより高くなります。サーバーのトランスポート コストは、Exchange Server 2003 ルーティング エンジンによって計算され、通常、メッセージを配信する最も効率的な経路を計算するために使用されます。Exchange Server 2003 以前のバージョンの Exchange では、トランスポート コストの優先度は低く、Exchange のバージョンと利用可能な変更の数の後でのみ検討されることに注意してください。

  • Exchange のバージョンによって並べ替える (最も新しいバージョンから最も古いバージョンの順)

  • サーバーで利用できる必要な変更数に基づいて並べ替える (変更数が最も多いものから最も少ないものの順) 不足している変更を保持していないサーバーは、一覧から削除されます。

あるサーバーが、必要な変更の一部を保持していない場合、Exchange Server 2003 は並べ替えられた一覧にある次のサーバーを選択し、バックフィル要求をそのサーバーにも送信します。この処理は、すべての変更が要求されるまで繰り返されます。これは Exchange Server 2003 以降にのみ存在する機能です。以前のバージョンの Exchange は、特定のフォルダに不足しているすべての更新をどのサーバーも保持していない場合、一度に 1 つのサーバーにしかバックフィル要求を送信しません。Exchange の以前のバージョンでは、1 つの要求を処理した後に再試行タイムアウト (24 ～ 48 時間) が経過してから次の要求を送信します。

選択したサーバーがバックフィル要求に応答しない場合、ストアはそのサーバーを停止とマークし、選択プロセスを繰り返します。停止とマークされたサーバーは、一覧の最後に移動されます。

Replication Short Backfill Request Timeout Retry 値は、同じ Exchange サイト内で使用できないデータに対するバックフィル要求を送信するとき、およびこの要求が前のバックフィル要求の再試行であるときにパブリック フォルダ ストアが使用するタイムアウト値を表します。この値は秒単位で、900 から 2,592,000 秒 (30 日) までの必要があります。既定値は 86,400 秒 (24 時間) です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Replication Short Backfill Request Timeout Retry レジストリ キーをリセットするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Public-<パブリック ストアの GUID>

  3. Replication Short Backfill Request Timeout Retry の値を調べるか、または編集します。

    このレジストリ エントリの値は秒単位です。既定値に戻すには、Replication Short Backfill Request Timeout Retry を削除し、Microsoft Exchange Information Store サービスを再開します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

パブリック フォルダのレプリケーションの詳細については、『Working with the Exchange Server 2003 Store』(http://go.microsoft.com/fwlink/?Linkld=47595) の「Controlling Exchange Server 2003 Public Folder Replication」を参照してください (このサイトは英語の場合があります)。


Reserve Increment KB レジストリ値が設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Reserve Increment KB の値が設定されているかどうかを判断します。HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 5.5 が実行されています。文字列値に "Version 6.0" が含まれている場合は、コンピュータで Microsoft Exchange 2000 Server が実行されています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 2003 が実行されています。文字列値に "Version 8.0" が含まれている場合、コンピュータでは Microsoft Exchange Server 2007 が実行されています。

Exchange Server アナライザによって、Exchange Server 2003 を実行しているコンピュータ上に Reserve Increment KB レジストリ値が存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Reserve Increment KB レジストリ値は、Microsoft Windows® 本来のメモリ ヒープの値を変更します。Windows は、プロセス全体を管理し、すべてのプロセスのメモリ操作を処理するヒープ マネージャを備えています。1 つのプロセスがインスタンス化するたびに、そのプロセスのために既定のヒープ (プロセス ヒープと呼ばれます) が作成されます。プロセスに読み込まれるプログラムやモジュールも、必要に応じて追加のヒープを作成できます。Microsoft Exchange Information Store サービスの Store.exe は、必要なときに追加のヒープを作成するプロセスの例です。既定では、Store.exe はヒープ領域として予約される初期メモリを、物理 RAM の 20% に設定します。Reserve Increment KB 値は、ヒープ用に予約する初期メモリの量を物理メモリの 10% に変更します。

Reserve Increment KB レジストリ値が役立つ場合は限られています。また、この値は Microsoft 製品サポート サービスの助言や指示があった場合のみ設定してください。この値を誤って設定または使用すると、パフォーマンスが低下したり、仮想メモリの断片化が加速されることがあります。Microsoft 製品サポート サービスに相談しないでこの値が設定された場合、次の手順で値を削除することを検討してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のウィンドウで、[Reserve Increment KB] 値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

Exchange Server 2003 のチューニング方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372)


RPC バッファ パッキングが無効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、リモート プロシージャ コール (RPC) のバッファ パッキングが無効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc Packing Enabled

Rpc Packing Enabled レジストリ キーの値のデータが 0 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。Rpc Packing Enabled レジストリ キーの値のデータが 0 に設定されている場合、このレジストリ キーは無効です。

Rpc Packing Enabled レジストリ キーの値のデータは、Microsoft Office Outlook® 2003 と Exchange Server 2003 の間の RPC 圧縮を構成するために管理者が追加することができる、3 つのレジストリ エントリの 1 つです。

Outlook 2003 は、96 KB のデータ バッファを要求できます。ただし、Exchange Server 2003 によるデータの圧縮後は、Outlook 2003 が要求したサイズよりデータ バッファが大幅に小さくなる可能性があります。

Exchange Server 2003 はバッファ パッキングのサポートにより、さまざまな圧縮率に対応し、効率のためにバッファを最大に維持します。

Rpc Packing Enabled レジストリ キーが有効な場合、Exchange Server 2003 はバッファがいっぱいになるまで圧縮データを追加し続けます。Outlook 2003 は以下の理由で、それぞれのデータ要求について以前のバージョンの Outlook よりも大幅に多いデータをダウンロードできます。

  • Outlook 2003 がより大きなバッファ サイズを要求する。

  • Exchange Server 2003 でバッファ パッキングがサポートされている。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定の構成に戻す場合は、Rpc Packing Enabled レジストリ キーを削除することができます。Rpc Packing Enabled レジストリ キーの値のデータを 1 に設定し、RPC バッファ パッキングを有効にすることもできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

    • エントリを削除するには、Rpc Packing Enabled の値を削除します。

    • エントリを残して RPC バッファ パッキングを有効にするには、[Rpc Packing Enabled] をダブルクリックし、値を 1 に設定します。次に、[OK] をクリックします。

  3. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

レジストリ キーを設定して Outlook クライアントと Exchange Server 2003 の間に RPC 圧縮を構成する方法の詳細については、Microsoft サポート技術情報の文書番号 825371「Exchange Server 2003 でのリモート プロシージャ呼び出し圧縮を変更します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371) を参照してください。


RPC Compression Minimum Size が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、リモート プロシージャ コール (RPC) の最小パケット サイズを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Rpc Compression Minimum Size

Rpc Compression Minimum Size の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

既定では、Microsoft Office Outlook® 2003 または Outlook 2007 と、Exchange Server 2003 または Exchange Server 2007 の間で転送される RPC データは、サイズにかかわらず、すべて圧縮されます。状況によっては、RPC 圧縮を制御することができます。たとえば、ネットワーク経由で送信されたパケットを表示して接続の問題をトラブルシューティングしようとしている場合は、RPC 圧縮が使用されていると、圧縮されたデータのみがトレースに表示されるために分析が困難になる可能性があります。

RPC 圧縮の設定を構成するには、システム設定に次のレジストリ キーの値を追加します。

  • Rpc Compression Minimum Size

  • Rpc Compression Enabled

  • Rpc Packing Enabled

Rpc Compression Minimum Size レジストリ値は、圧縮を行うために RPC パケットに必要な最小バイト数を決定します。このキーが存在しない場合は、既定値の 1,024 バイトが使用されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Rpc Compression Minimum Size キーを削除します。Rpc Compression Enabled キーや Rpc Packing Enabled キーが存在する場合は、それらも削除します。

  4. レジストリ エディタを終了し、Exchange サーバーを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RPC 圧縮を制御する方法の詳細については、Microsoft サポート技術情報の文書番号 825371「Exchange Server 2003 でのリモート プロシージャ呼び出し圧縮を変更します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=825371) を参照してください。


RpcEtwTracing パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、その値のデータを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\RpcEtwTracing

RpcEtwTracing レジストリ キーの値のデータが 1 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

RpcEtwTracing レジストリ キーの値のデータは、Microsoft Office Outlook® 2003 と Exchange Server の間のネットワークに関する問題のトラブルシューティングを行う場合にのみ使用します。現在、問題のトラブルシューティングを行っていない場合は、RpcEtwTracing レジストリ キーを無効にすることをお勧めします。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。ただし、既定の構成に戻す場合は、RpcEtwTracing レジストリ キーを削除することができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. RpcEtwTracing 値を削除します。

  4. レジストリ エディタを終了します。

Microsoft Exchange Information Store サービスによって、数分内に変更が検出されます。コンピュータを再起動する必要はありません。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


サーバーのストレージ グループ数は 4 未満だが、定義されているメールボックス ストアの数は 4 を超えている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directoyr® ディレクトリ サービスに対してクエリを実行し、Exchange Server 2003 を実行しているサーバーの StorageGroup オブジェクトと MailboxGroup オブジェクトの数をカウントします。StorageGroup オブジェクトの総数が 4 未満で、かつ MailboxStore オブジェクトの総数が 4 を超えていることが検出されると、エラーが表示されます。

Exchange Server 2003 Standard Edition を使用している場合、各 Exchange Server コンピュータは 1 つのストレージ グループを持つことができ、それぞれが 1 つのメールボックス ストアと 1 つのパブリック フォルダをサポートします。Exchange Server 2003 Enterprise Edition を使用している場合、各サーバーは最大 4 つのストレージ グループを持つことができ、それぞれが最大 5 つのデータベース (メールボックス ストアまたはパブリック フォルダ ストア) をサポートします。

Exchange Server 2003 Enterprise Edition を実行しているコンピュータでストレージ グループを構成する際に推奨されるベスト プラクティスは、作成できるストレージ グループ数の上限まで、新しいデータベースのそれぞれについてストレージ グループを追加することです。これによって、Exchange Server ストレージ トポロジ内でのメールボックスの負荷を、できる限り多くのストレージ グループに分散できます。このようなトポロジには、次の利点があります。

  • ストレージ トポロジの信頼性が向上します。

  • ストレージ トポロジの回復性が向上します。

  • ドライブ I/O をより適切に管理できます。

Exchange Server 2003 Enterprise Edition を実行しているサーバーのストレージ グループが 4 つ未満で、メールボックス ストアが 4 つより多い場合は、次の手順を使用して、できる限り多くのストレージ グループにメールボックスを分散します。

このエラーを解決するには

  1. Exchange システム マネージャで、このエラーが報告されたサーバーを選択します。サーバーにあるストレージ グループとメールボックス ストアの数を書き留めます。複数のメールボックス ストアを含むストレージ グループを書き留めます。

  2. Exchange Server 2003 Enterprise Edition を実行しているコンピュータで、ストレージ グループが 4 つになるまで追加します。新しいストレージ グループを追加する方法については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Adding a Storage Group」を参照してください (このサイトは英語の場合があります)。

  3. 新たに作成した各ストレージ グループに、新しいメールボックス ストアを作成します。新しいメールボックス ストアを作成する方法については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Adding a Mailbox Store」を参照してください (このサイトは英語の場合があります)。

  4. メールボックスを、複数のメールボックス ストアを含むストレージ グループにあるメールボックス ストアの 1 つから、新しく作成したストレージ グループにあるメールボックス ストアに移動します。メールボックスを移動するには、メールボックスの移動ウィザードを使用します。メールボックスの移動ウィザードの使用方法の詳細については、『Exchange Server 2003 Deployment Guide』(http://go.microsoft.com/fwlink/?LinkId=47569) の「Migrating from Exchange Server 5.5 to Exchange Server 2003」の「Using Exchange Task Wizard to Move Mailboxes」を参照してください (このサイトは英語の場合があります)。

Exchange Server 2003 でストレージ グループを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 890699「ストレージの構成方法が Exchange でサーバー 2003 をグループ化します。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=890699) を参照してください。

ストレージ グループを構成する方法の詳細については、『Exchange Server 2003 High Availability Guide』(http://go.microsoft.com/fwlink/?LinkId=47571) の「Planning a Reliable Back-End Storage Solution」のストレージ グループの構成に関するセクションを参照してください (このサイトは英語の場合があります)。

可用性、フォールト トレランス、パフォーマンスを最大化するために役立つ全般的な推奨事項については、「Optimizing Storage for Exchange Server 2003」(http://go.microsoft.com/fwlink/?LinkId=49324) を参照してください (このサイトは英語の場合があります)。


データベース ファイルとストリーミング ファイルの署名が一致しない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange データベース (.edb) ファイルと、対応する Exchange ストリーミング データベース (.stm) ファイルの署名が一致しないと判断しました。

Exchange 2000 Server と Exchange Server 2003 の個々のデータベースは, .edb MAPI データベース ファイルと .stm ストリーミング データベース ファイルの 2つのファイルで構成されます。これらの対応するファイルどうしの組み合わせは、共通のデータベース署名を共有します。データベースの署名が一致しない場合、これらのファイルは対応していません。

.edb ファイルと .stm ファイルは、単一のファイルのように扱う必要があります。これらのファイルを移動またはコピーする場合は、必ず一緒に行ってください。

このエラーを修正するには

  • データベース ファイルの履歴を調べます。ファイルが手動でコピー、移動、または削除された可能性があります。データベースを回復する前に、この問題を修正する必要があります。

  • 対応する .edb ファイルと .stm ファイルが見つからない場合、Eseutil.exe を使用して .edb ファイルのみを修復し、Eseutil を /createstm スイッチと共に使用して .stm ファイルを破棄できます。この方法を使用すると、ストリーミング データベースの情報はすべて失われます。

    注 :
    データベースのユーザーがすべて Microsoft Office Outlook® などの MAPI クライアントを使用してデータベースに接続している場合、ストリーミング データベースには最小限の情報のみが格納されます。ユーザーが POP3、IMAP、または Outlook Web Access クライアントを使用してデータベースに接続している場合は、ユーザーのメールボックスの内容の一部またはすべてがストリーミング データベースに格納されます。

Exchange データベースを修復する方法の詳細については、Microsoft サポート技術情報の文書番号 812357「[XADM] Eseutil /p ツールで修復した Exchange データベースの管理」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812357) を参照してください。


既定の受信者ポリシーに SMTP アドレスが定義されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-12-03

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange Server 組織内の既定の受信者ポリシーの gatewayProxy 属性に SMTP アドレスが指定されているかどうかを判断します。gatewayProxy 属性に SMTP アドレスが含まれていないことが検出されると、エラーが表示されます。

このエラーは重大なエラーです。Exchange Server 組織内の既定の受信者ポリシーの gatewayProxy 属性に SMTP アドレス (たとえば、SMTP:@contoso.com) を追加する必要があります。既定の受信者ポリシーには SMTP アドレスが含まれている必要があります。既定の受信者ポリシーに SMTP アドレスが含まれていないと、Microsoft Exchange Information Store サービスは再開後に初期化されません。このエラーは、次回 Microsoft Exchange Information Store サービスが再開されると、Exchange Server 組織内のすべての Exchange サーバーにわたって発生します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003、Exchange Server 2003 か Exchange Server 2007、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
既定の受信者ポリシーの gatewayProxy 属性に SMTP アドレスを追加するには

  1. Microsoft Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • 構成

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Recipient Policies]

  3. 詳細ペインで、[CN=Default Policy] を右クリックし、[プロパティ] をクリックします。

  4. [Attribute Editor] ボックスで、[gatewayProxy] をダブルクリックします。

  5. [Multi-valued String Editor] ダイアログ ボックスで、[Value to add] ボックスに「SMTP:@<ドメイン名>.com」と入力し、[Add] をクリックします。

    注 :
    ここで入力する構文は重要です。Exchange Server 組織のドメイン名の前に「SMTP:@」を追加する必要があります。この文字列に空白は含まれません。

  6. [OK] をクリックし、[適用] をクリックします。次に、ADSI Edit を終了します。

  7. レプリケーションが完了するまで、少なくとも 15 分待機します。


Store RPC prorate レジストリ パラメータが正しい値に設定されていない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、3 つのレジストリ キーを読み取り、それらの値が既定値から変更されているかどうかを判断します。3 つのキーはすべて DWORD 値で、次の場所にあります。

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options\STORE.EXE\RpcThreadPoolThrottle

キーの名前と既定値は次のとおりです。

DWORD 値 既定の 10 進値
  • ProrateStart
  • 40
  • ProrateMax
  • 10,000
  • ProrateFactor
  • 100

Exchange Server アナライザによって上の既定値のいずれかが変更されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定値に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options\STORE.EXE\RpcThreadPoolThrottle

  3. 右側のペインで、値が変更されているエントリをダブルクリックし、既定値に構成します。

  4. 複数の値が変更されている場合は、手順 3. を繰り返します。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ストア処理のスレッドの詳細については、Microsoft サポート技術情報の文書番号 267255「XADM: Store.exe Threads Use Up Available Memory」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=267255) を参照してください (このサイトは英語の場合があります)。


ストアの作業ディレクトリが存在しないか正しくない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-30

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange Information Store サービスの作業ディレクトリを確認します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory

以下の条件に当てはまる場合は、警告が表示されます。

  • 作業ディレクトリとして指定されたディレクトリが存在しない。

  • Exchange 2000 Server、Exchange Server 2003、または Exchange Server 2007 を実行している。

Exchange Server は、作業ディレクトリを一時的な記憶域として使用します。たとえば、Exchange Server は、メッセージの変換処理中に作業ディレクトリを使用します。また、ディスクの最適化中には、作業ディレクトリを使用して一時データベースを格納します。作業ディレクトリが正しく指定されていないと、以下の問題が発生する可能性があります。

  • 添付ファイルのあるメッセージが、SMTP ローカル配信キューに蓄積される。

  • メッセージが添付ファイルなしで受信される。

  • メッセージが正常に配信されない。

Exchange 2000 Server および Exchange Server 2003 では、既定の作業ディレクトリは Exchange Server をインストールしたディレクトリの下にある mdbdata ディレクトリに設定されます。たとえば、Exchange Server を C:\Program Files\Exchsrvr ディレクトリにインストールした場合、C:\Program Files\Exchsrvr\mdbdata が作業ディレクトリとして設定されます。

Exchange Server 2007 では、既定の作業ディレクトリは Exchange Server をインストールしたディレクトリの下にあるメールボックス データベース ディレクトリに設定されます。たとえば、Exchange Server を C:\Program Files\Exchange Server ディレクトリにインストールした場合、Exchange Server 2007 では、C:\ Program Files\Exchange Server\Mailbox\MDBTemp が作業ディレクトリとして設定されます。

この警告を修正するには、Exchange サーバー上に存在するディレクトリを作業ディレクトリとして指定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
regedit を使用して作業ディレクトリを指定するには

  1. レジストリ エディタ (regedit) を起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Microsoft Exchange Information Store サービス用の Working Directory レジストリ値を、C:\Program Files\Exchsrvr\mdbdata などの正しい作業ディレクトリを指定して更新します。

    注 :
    この変更では、Microsoft Exchange Information Store サービスを再開する必要はありません。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Working Directory レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 298415「添付ファイルのあるメッセージが正常に配信されず、イベント ID 12003 および 327 メッセージがログに出力される」(http://go.microsoft.com/fwlink/?Linkid=3052&kbid=298415) を参照してください。


配布リストへの不在メッセージの送信を抑制するように設定されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-02-27

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、配布リストへの不在メッセージの送信が抑制されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\SuppressOOFsToDistributionLists

SuppressOOFsToDistributionLists の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

不在アシスタントが有効になっているメールボックスにメッセージが送信されると、送信者は [宛先] または [CC] フィールドにアドレスが記入されていないメッセージを受信しますが、メッセージには [BCC] フィールドに配布リストが含まれており、不在メッセージは [BCC] フィールドで指定されている配布リストに送信されます。

メッセージがある受信者に送信され、その受信者が配布リストには含まれておらず [BCC] フィールドにのみ指定されている場合、受信者が不在アシスタントを有効にしていると、受信者のメールボックス ストアからは、SuppressOOFsToDistributionLists レジストリ値が設定されている場合でも不在メッセージが送信されます。この制限が当てはまるのは、受信者が [BCC] フィールドで指定されていて、[宛先] および [CC] フィールドが空である場合のみです。[宛先] または [CC] フィールドに少なくとも 1 人のユーザーが指定されていれば、Exchenge Server コンピュータのレジストリ パラメータによって、[BCC] フィールドに列挙されている受信者が不在メッセージを生成しないようにされます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

不在メッセージの生成動作を変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. [ParametersSystem] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。

  4. 新しい値に SuppressOOFsToDistributionLists という名前を付けます。

  5. [SuppressOOFsToDistributionLists] を右クリックし、[変更] をクリックします。

  6. [値のデータ] ボックスに「1」と入力し、[OK] をクリックします。

  7. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

SuppressOOFsToDistributionLists レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 825370「Out-of-Office メッセージは、BCC フィールドに存在する配布リストに送信されます。」(http://go.microsoft.com/fwlink/?linkid=3052 & kbid=825370) を参照してください。


破損メッセージがストアを通過できる回数を制御するしきい値が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-08

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、PoisonThreshold の値を判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS \<Exchange サーバー名> \Private- <プライベート インフォメーション ストアの GUID>

Exchange Server アナライザにより、PoisonThreshold の値が 2 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 Service Pack 1 以降のバージョンでは、破損メッセージや悪質なメッセージにより Microsoft Exchange Information Store サービスが予期せず停止したり、Microsoft Exchange Information Store サービスの正常な開始が妨げられたりすることを防止するための動作が実装されています。

Exchange Server 2003 Service Pack 1 以降では、MAPI 形式から MIME 形式への変換時に予期しない Microsoft Exchange Information Store サービスの停止を引き起こすメッセージが追跡されます。障害が発生した場合、破損メッセージのメッセージ ID がレジストリに格納されます。ある破損メッセージのためにストアが 3 回予期せず停止した場合は、この情報を使用して、Microsoft Exchange Information Store サービスが 4 回目に再開されたときに二度とこのメッセージを処理しないようにします。

破損メッセージのために Microsoft Exchange Information Store サービスが予期せず停止すると、PoisonIDs レジストリ値が次の場所に作成されます。

HKLM\System\CurrentControlSet\Services\MSExchangeIS \<Exchange サーバー名> \Private- <プライベート インフォメーション ストアの GUID>

また、管理者が PoisionThreshold レジストリ エントリを作成することもできます。PoisonThreshold キーは、メッセージが Exchange インフォメーション ストアを何回通過した後で PoisonIDs レジストリ キーに追加されるかを示しています。既定では、このしきい値は 2 です。この動作を引き起こすには、しきい値を超える必要があります。したがって、破損メッセージがブロックされるまでに、Microsoft Exchange Information Store サービスはそのメッセージが原因で 3 回停止する可能性があります。たとえば、あるメッセージがクラッシュを 3 回引き起こしたとすると、3 はしきい値の 2 より大きいため、そのメッセージはブロックされます。

レジストリに破損メッセージ イベントが書き込まれると、アプリケーション イベント ログにエラー イベント メッセージ (イベント ID 9680 および 9681) が記録されます。Microsoft Exchange Information Store サービスが正常に開始した後、Exchange ではそのメッセージがブロックされ、メッセージについての配信不能レポートの送信が試みられます。場合によっては、Exchange が配信不能レポートを送信できないことがあります。このような場合、ブロックされたメッセージは有効期限が経過するまでキューに置かれたままになることがあります。PoisonIDs レジストリ キーは、10 までのメッセージ ID の値を保持します。10 個の制限を超えると、新しい破損メッセージ イベントが追加されます。そのとき、最も古いクラッシュの日付を含む破損メッセージ イベントが削除されます。

注 :
それぞれの破損メッセージについてのトラブルシューティングの手順は、Exchange Server アナライザの範囲外です。場合によっては Microsoft 製品サポート サービスが、それぞれの破損メッセージのトラブルシューティングに役立つことがあります。破損メッセージのために Exchange Server 2003 以降のシャットダウンで問題が発生している場合は、Exchange Server コンピュータでエラーの自動報告を有効にすると役立つ可能性があります。このエラー報告のデータは、使用しているソフトウェア内にある問題の検出や修正のために使用されます。Exchange エラー報告を有効にする方法の詳細については、「Exchange エラー報告が無効になっている」を参照してください。

PoisonThreshold の値は、既定値の 2 に戻すことをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\<Exchange サーバー名>\Private-<プライベート インフォメーション ストアの GUID>

  3. 右側のウィンドウで、[PoinsonThreshold] をダブルクリックします。

  4. [値のデータ] ボックスに「2」(10 進数) と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ストア プロセスでトレースが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Enable Tracing レジストリ エントリおよび Trace User LegacyDN レジストリ値の両方の有無について、レジストリを確認します。これらのレジストリ値は、次のレジストリ キーの下にあります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

両方のレジストリ エントリが存在し構成されていることが検出されると、警告が表示されます。

Enable Tracing DWORD レジストリ値を使用すると、Microsoft Exchange Information Store サービスは、トレースできるようになります。トレースは、Exchange Store の起動に関する問題のトラブルシューティングに使用しますが、パフォーマンスが大幅に低下する場合があります。問題のトラブルシューティングを行う場合以外は、このレジストリ設定を使用しないでください。Trace User LegacyDN レジストリ文字列値を追加すると、特定のユーザーを対象としてトレース (フィルタが適用されたトレース) できます。Trace User LegacyDN 値が存在しない場合は、すべてのユーザーを対象としたトレースが有効になっています。Trace User LegacyDN 値が存在する場合は、このキーの下に示されている特定のユーザーを対象としたトレースが行われています。

Exchange Server コンピュータでトラブルシューティングを実行していない場合、これらのレジストリ値は不要です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Enable Tracing と Trace User LegacyDN の両方のレジストリ値を削除します。

  4. レジストリ エディタを終了し、コンピュータを再起動して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange サーバーにおける各ユーザーのトレースの詳細については、Microsoft サポート技術情報の文書番号 296624「[XADM] Exchange 2000 Server Service Pack 1 (SP1) に追加された各ユーザーのトレース機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296624) を参照してください。


Microsoft Exchange Information Store サービスで、すべてのユーザーについてトレースが有効になっている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchnage Server アナライザ ツールは、次のレジストリを読み取り、Enable Tracing エントリが存在しているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSexchangeIS\ParametersSystem

Enable Tracing レジストリ値が存在し構成されていることが検出されると、警告が表示されます。

Enable Tracing DWORD レジストリ値を使用すると、Microsoft Exchange Information Store サービスのトレースが可能になります。トレースは、Store の起動に関する問題のトラブルシューティングに使用しますが、パフォーマンスが大幅に低下する場合があります。問題のトラブルシューティングを行うとき以外は、このレジストリ設定は使用しないでください。Trace User LegacyDN レジストリ文字列値を追加すると、特定のユーザーを対象としてトレースできます。この値が存在しない場合、すべてのユーザーについてトレースが有効になります。

Exchange Server コンピュータでトラブルシューティングを実行していない場合、この値は不要です。

注 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. Enable Tracing レジストリ値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange サーバーにおける各ユーザーのトレースの詳細については、Microsoft サポート技術情報の文書番号 296624「[XADM] Exchange 2000 Server Service Pack 1 (SP1) に追加された各ユーザーのトレース機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=296624) を参照してください。


トランザクション ログ ファイル名が使い果たされた
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、サーバー ディスク上のログ ファイルをチェックして、各ストレージ グループのトランザクション ログ ファイルの状態を確認します。ログ ファイルの場所を見つけるため、Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行します。ログ ファイルへのファイル パスは、ストレージ グループ オブジェクト (msExchStorageGroup クラス) ごとに、msExchESEParamLogFilePath 属性に格納されます。

トランザクション ログ ファイル名には、ログ ファイルの順序を示す 16 進数の連番が含まれます。たとえば、既定の "最初のストレージ グループ" を示す最初のログ ファイルには E0000001.log という名前が付けられ、2 番目のログ ファイルには E0000002.log という名前が付けられます。連番は E00FFFFF.log まで発番できます。Exchange では、最大 1,030,000 個の一意のログ ファイルを作成できます。ただし、連番の最後まで到達すると、制限に達した後でマウントが解除される場合、影響を受けるストレージ グループ内のストアはマウントされなくなります。マウントされたままの場合、Jet 操作が発生する可能性がないにもかかわらず、ストアはデータベースのマウントを解除しません。通常、この限界の到達するまでには、数年かかります。

特定のサーバーが 950,000 を超えるトランザクション ログ ファイルを使用すると、このメッセージが警告として表示されます。

特定のサーバーが 1,020,000 を超えるトランザクション ログ ファイルを使用すると、このメッセージがエラーとして表示されます。

この限界に達した場合にストアが適切にデータベースのマウントを解除できるようにするために、Exchange Server 2003 Service Pack 1 には修正プログラムが含まれています。Exchange2000 Server では Service Pack 3 より後の修正プログラムが利用可能になっています。この情報については、Microsoft サポート技術情報の文書番号 830408「ストレージ グループで利用可能なトランザクション ログがなくなっても、Exchange のストア データベースがマウントされたままになる」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830408) を参照してください。

Exchange が 1,030,000 のトランザクション ログの制限にまだ達していない場合は、できる限り早くサーバーの完全オンライン バックアップを実行してください。Exchange ストアの完全オンライン バックアップの実行方法の詳細については、『Exchange 2003 Disaster Recovery Operations Guide』(http://go.microsoft.com/fwlink/?LinkId=47570) を参照してください (このサイトは英語の場合があります)。

Exchange がこの制限に達した場合は、既存のトランザクション ログをすべて別の場所に移動する必要があります。この作業を行った後、0x00001 で始まる新しい順序のログ ファイルが生成されます。Exchange ストアが適切にデータベースのマウントを解除できるようにするには、実行している Exchange のバージョンに応じた修正プログラムを適用する必要もあります。

注 :
トランザクション ログを移動する前に、ストレージ グループ内のすべてのデータベースがクリーン シャットダウン状態にあることを確認する必要があります。
重要 :
以下の手順を実行すると、以前のバックアップはすべて無効になります。これは、バックアップの復元ができないことを意味するわけではありませんが、追加のトランザクション ログを使用してバックアップをロール フォワードすることができなくなります。トランザクション ログを削除した後で以前のバックアップを復元する必要が生じた場合、データを復元できるのは、新しいログ生成が作成されたときまでのみです。

この問題を解決するには

  1. Exchange Server 2003 の場合は、Service Pack 1 をインストールします。Service Pack 1 は、Exchange Server のダウンロード Web サイト (http://go.microsoft.com/fwlink/?LinkId=29090) で入手できます。

    または

    Exchange 2000 Server の場合は、Microsoft サポート技術情報の文書番号 830408「ストレージ グループで利用可能なトランザクション ログがなくなっても、Exchange のストア データベースがマウントされたままになる」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=830408) で参照されている修正プログラムを入手してインストールします。

  2. トランザクション ログ ファイルが使い果たされたストレージ グループで、すべてのデータベースのマウントを解除します。それには、次の手順に従います。

    1. Exchange システム マネージャを起動します。

    2. [管理グループ]、[<管理グループ名>]、[サーバー]、[<サーバー名>]、[<ストレージ グループ名>] の順に展開します。

    3. このストレージ グループ内の最初のストアを右クリックし、[ストアのマウントを解除] をクリックします。このストレージ グループ内の各ストアに対し、この手順を繰り返します。

  3. ストレージ グループ内の各データベースがクリーン シャットダウン状態であることを確認します。それには、次の手順に従います。

    1. Exchange システム マネージャで、トランザクション ログ ファイルが使い果たされたストレージ グループ内の最初のストアを右クリックし、[プロパティ] をクリックします。

    2. [データベース] タブをクリックし、[Exchange データベース] ボックスおよび [Exchange ストリーミング データベース] ボックスに表示されているデータベース ファイルのパスとファイル名を書き留めます。個々の Exchange データベースは、ファイル名の拡張子が .edb と .stm である 1 対のファイルのセットで構成されています。ストレージ グループ内の各ストアに対し、この手順を繰り返します。

    3. コマンド プロンプトで、ディレクトリを Exchange Server の bin フォルダに変更します。たとえば、C:\Program Files\Exchsrvr\bin に変更します。

    4. 「Eseutil /mh データベース ファイル名」と入力し、Enter キーを押します。ストレージ グループ内の各ストアに対し、この手順を繰り返します。このコマンドによって、データベース ファイルのヘッダーが表示されます。ヘッダには、State:Clean Shutdown または State:Dirty Shutdown のどちらかの行が含まれています。

  4. ヘッダに State:Dirty Shutdown の行が含まれている場合は、ログ ファイルを削除する前にデータベースを手動で回復する必要があります。それには、次の手順に従います。

    1. Exchange システム マネージャで、トランザクション ログ ファイルが使い果たされたストレージ グループを右クリックし、[プロパティ] をクリックします。

    2. [全般] タブをクリックし、[トランザクション ログの場所] ボックスに表示されたトランザクション ログのパスを書き留めます。

    3. [システム パスの場所] ボックスに表示されたチェックポイント ファイルのパスを書き留めます。

    4. コマンド プロンプトで、ディレクトリを Exchange Server の bin フォルダに変更します。

    5. 次のコマンドを入力して、Enter キーを押します。Eseutil /r 3-文字のログ ファイル ベース名 /lDirectory:\ログ ファイルのパス /sDirectory:\チェックポイント ファイルのパス

      注 :
      オプション スイッチとディレクトリ パスの間にスペースを入力しないでください。コマンドに記述するパスに入力エラーがあると、回復に失敗することがあります。そのような事態を防ぐため、チェックポイント ファイルをトランザクション ログ ファイルのフォルダにコピーすることができます。既定の場所がログファイルのディレクトリになるコマンド プロンプトで、コマンドとして Eseutil /r 3 文字のログ ファイル ベース名 を実行します。/l スイッチと /s スイッチは既定で現在のディレクトリになるため、ログ ファイルのパスやチェックポイント ファイルのパスを指定する必要はありません。
    6. 回復の完了後、トランザクション ログ ファイルとチェックポイント ファイルを移動する前に、すべてのデータベース ファイルがクリーン シャットダウン状態であることを確認します。データベースがダーティ シャットダウン状態である場合にログ ファイルを移動すると、データベースを再起動できなくなります。すべてのデータベースをクリーン シャットダウン状態へ回復できない場合は、詳細について Microsoft 製品サポート サービスにお問い合わせください。

  5. Exchange システム マネージャで、トランザクション ログ ファイルが使い果たされたストレージ グループを右クリックし、[プロパティ] をクリックします。

  6. [全般] タブをクリックし、[トランザクション ログの場所] ボックスに表示されたトランザクション ログのパスを書き留めます。

  7. [システム パスの場所] ボックスに表示されたチェックポイント ファイルのパスを書き留めます。

  8. トランザクション ログ ファイルとチェックポイント ファイルを別の場所へ移動します。ログ ファイルのファイル名拡張子は .log で、チェックポイント ファイルのファイル名拡張子は .chk です。

  9. Exchange システム マネージャで、ストレージ グループ内のマウントを解除した最初のストアを右クリックし、[ストアのマウント] をクリックします。

  10. ストレージ グループ内の各ストアに対し、この手順を繰り返します。これで、ストレージ グループでログ ファイルの順序がリセットされました。

  11. ストレージ グループのすべてのデータベースについて、完全バックアップを実行します。

Exchange Server の Service Pack の詳細については、Exchange Server の Web サイト (http://go.microsoft.com/fwlink/?LinkId=21573) を参照してください (このサイトは英語の場合があります)。


VM の最大ブロック サイズが小さい
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_MSExchangeIS_MSExchangeISMicrosoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、VMLargestBlockSize キーの値を判断します。VMLargestBlockSize キーは、仮想メモリの最大空きブロックのサイズをバイト単位で表します。

Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されているエントリの数は、メールボックス ストア上のメールボックスの数を表します。

Exchange Server アナライザによって、20 を超えるメールボックスが置かれた Exchange Server コンピュータで、VMLargestBlockSize の値が 50,000,000 より大きく 150,000,000 より小さいことが検出されると、警告が表示されます。

Exchange Server は、特に、MIME 形式と MAPI 形式の間でメッセージを変換するときにメッセージを格納するために、あるいはトランザクション ログのメッセージをコミットしたりストアにコミットしたりする場合のバッファとして仮想メモリを使用します。多くの場合、この操作をすばやく効率的に完了するため、大きな連続した仮想メモリのブロックが必要になります。この警告が表示された場合、Exchange コンピュータ上の仮想メモリが使い果たされて、連続した領域が 150 MB 未満になっています。これは、仮想メモリの断片化と呼ばれます。

仮想メモリが消費されすぎると、仮想メモリのエラーであるエラー メッセージ (イベント ID 9582) がイベント ログに表示されるようになります。仮想メモリがさらに減少すると、イベント ID 12800 が表示されます。これは、メッセージを処理するためのメモリが不足しているためにメッセージが配信されないことを意味します。

この警告を解決するには、以下に示した順序で推奨事項を実行します。

Exchange Server アナライザの出力で、"ESE キャッシュ サイズの最大値に到達しました" というエラーを探す

この仮想メモリの断片化に関する警告が返される Exchange コンピュータと同じコンピュータで "ESE キャッシュ サイズの最大値に到達しました" というエラーが返される場合は、文書「ESE キャッシュ サイズの最大値の設定が大きすぎる」に記載されている推奨事項に従ってください。

これら 2 つのメッセージの組み合わせは、おそらく、ESE キャッシュが手動で増やされた結果として仮想メモリの断片化の問題が発生したことを示しています。

Exchange Information Store サービスを再開する

このエラー メッセージの説明で、Exchange Server アナライザは、Microsoft Exchange Information Store サービスが実行されている日数を示します。示された日数が 30 日を超えている場合、サービスを再開します。

Microsoft Exchange Information Store サービスを再開するには

  1. [サービス] MMC スナップインを開きます。

  2. [Microsoft Exchange Information Store] サービスを右クリックし、[再起動] をクリックします。

メッセージ サイズの制限を評価する

30 MB を超える大きなメッセージを送信するユーザーが多く存在する場合は、大きなメッセージを送信しないユーザーが多い場合よりも短期間に仮想メモリが断片化する可能性があります。前述したように、仮想メモリは、データがストア プロセスによってログ ファイルから移動され、ストアにコミットされるときにバッファとして使用されます。移動されるデータのサイズが大きい場合が多いと、仮想メモリの大きな連続したブロックが短時間に消費されます。

大きなデータが電子メールを使用して頻繁に送信されていて、それらのデータが内部で送信されている場合は、ファイル サーバーに、ユーザーが大きなデータを投稿できる共有ディレクトリを設定することを検討してください。

メッセージの最大サイズの制限値は、30 MB 以下に設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、送信メッセージの最大サイズの制限を 30 MB より大きい値に増やすこともできます。メッセージ サイズの制限を 30 MB より大きくすると、仮想メモリの断片化に加えて、悪意のある攻撃に対するシステムの脆弱性が高まるおそれもあります。30 MB を超えるメッセージ サイズ制限は許可しないようにすることをお勧めします。

メッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開し、[メッセージ配信] を右クリックします。次に、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[送信メッセージ サイズ] の [最大サイズ (KB)] オプションをクリックし、必要なサイズの制限値を入力します。

ウイルス対策ソフトウェアが最新の状態に維持されていることを確認する

場合によっては、Exchange Virus Scanning API (VSAPI) モードで実行されている古いウイルス対策ソフトウェアのために仮想メモリの断片化が発生することがあります。ウイルス対策ソフトウェアを VSAPI モードで実行している場合は、ウイルス対策ソフトウェアの製造元に連絡し、最新バージョンのソフトウェアとドライバを実行していることを確認してください。

メールボックスを別の Exchange サーバーに移動する

以上の手順をすべて実行しても Exchange Server アナライザで依然としてこの警告が表示される場合は、問題が生じているサーバーからメールボックスを移動して負荷を減らす必要があります。このサーバーにあるメールボックスが多すぎます。

Exchange 2000 Server や Exchange Server 2003 でメールボックスを移動するには

  1. Active Directory ユーザーとコンピュータで、メールボックスを移動するユーザーを選択します。

  2. 前の手順で選択したユーザーの一覧を右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

Exchange Server 2003 でメールボックスを移動するには

  1. Exchange システム マネージャで、[サーバー] を展開し、メールボックスを移動するサーバーを展開します。次に、メールボックスの移動元の ストレージ グループを展開して移動するメールボックスが含まれる メールボックス ストアを展開し、[メールボックス] をクリックします。

  2. 詳細ペインで、メールボックスを移動するユーザーを右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

仮想メモリの断片化に関する問題解決の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 838233「Exchange 2000 Server コンピュータの速度が低下するか、応答が停止し、イベント ID 9582 および 1160 が繰り返し記録される。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=838233)

メッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

メールボックスの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328810)

  • 文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821829)


VM の最大ブロック サイズが致命的な値に到達しようとしている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_MSExchangeIS_MSExchangeISMicrosoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、VMLargestBlockSize キーの値を判断します。VMLargestBlockSize キーは、仮想メモリの最大空きブロックのサイズをバイト単位で表します。

さらに、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されているエントリの数は、メールボックス ストア上のメールボックスの数を表します。

Exchange Server アナライザによって、20 を超えるメールボックスが置かれた Exchange Server コンピュータで、VMLargestBlockSize の値が 0 より大きく 50000001 より小さいことが検出されると、エラーが表示されます。

特に Exchange サーバーは、MIME 形式と MAPI 形式の間でメッセージを変換する際に仮想メモリを使用してメッセージを格納し、トランザクション ログにあるメッセージをコミットしてストアにコミットする際にはバッファとして仮想メモリを使用します。多くの場合、この操作をすばやく効率的に完了するため、大きな連続した仮想メモリのブロックが必要になります。このエラーが表示された場合、Exchange コンピュータ上の仮想メモリが使い果たされて、連続した領域が 50 MB 未満になっています。これは、仮想メモリの断片化と呼ばれます。Exchange メールボックス サーバーが、連続した仮想メモリ領域が 50 MB 未満の状態で実行されると、重大なエラーが発生します。

仮想メモリの消費量が多すぎると、仮想メモリのエラーを示すエラー警告 (イベント ID 9582) がイベント ログに表示されるようになります。仮想メモリがさらに減少すると、イベント ID 12800 が表示されます。これは、メッセージを処理するためのメモリが十分にないためにメッセージが配信されないことを意味します。

このエラーを修正するには、以下に示した順序で推奨事項を実行します。

Exchange Server アナライザの出力で、"ESE キャッシュ サイズの最大値に到達しました" というエラーを探す。

この仮想メモリの断片化に関する警告が返される Exchange コンピュータと同じコンピュータで "ESE キャッシュ サイズの最大値に到達しました" というエラーが返される場合は、文書「ESE キャッシュ サイズの最大値の設定が大きすぎる」に記載されている推奨事項に従ってください。

これら 2 つの警告の組み合わせは、おそらく、ESE キャッシュが手動で増やされた結果として仮想メモリの断片化の問題が発生したことを示しています。

Exchange Information Store サービスを再開する

この警告の説明で、Exchange Server アナライザは、Microsoft Exchange Information Store サービスが実行されている日数を示します。示された日数が 30 日を超えている場合、サービスを再開します。

Exchange Information Store を再起動するには

  1. [サービス] MMC スナップインを開きます。

  2. [Microsoft Exchange Information Store] サービスを右クリックし、[再起動] をクリックします。

メッセージ サイズの制限を評価する

30 MB を超える大きなメッセージを送信するユーザーが多く存在する場合は、大きなメッセージを送信しないユーザーが多い場合よりも短期間に仮想メモリが断片化する可能性があります。前述したように、仮想メモリは、データがストア プロセスによってログ ファイルから移動され、ストアにコミットされるときにバッファとして使用されます。移動されるデータのサイズが大きい場合が多いと、仮想メモリの大きな連続したブロックが短時間に消費されます。

大きなデータが電子メールを使用して日常的に送信されていて、それらのデータが内部で送信されている場合は、ファイル サーバーに、ユーザーが大きなデータを投稿できる共有ディレクトリを設定することを検討してください。

メッセージの最大サイズの制限は、30 MB を超えないように設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、送信メッセージの最大サイズの制限を 30 MB より大きい値に増やすこともできます。メッセージ サイズの制限を 30 MB より大きくすると、仮想メモリの断片化に加えて、悪意のある攻撃に対するシステムの脆弱性が高まるおそれもあります。そのため、30 MB を超えるメッセージ サイズの制限を許可することは推奨されません。

メッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開し、[メッセージ配信] を右クリックします。次に、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[送信メッセージ サイズ] の [最大サイズ (KB)] オプションをクリックし、必要なサイズの制限値を入力します。

ウイルス対策ソフトウェアが最新の状態に維持されていることを確認する

場合によっては、Exchange Virus Scanning API (VSAPI) モードで実行されている古いウイルス対策ソフトウェアのために仮想メモリの断片化が発生することがあります。ウイルス対策ソフトウェアを VSAPI モードで実行している場合は、ウイルス対策ソフトウェアの製造元に連絡し、最新バージョンのソフトウェアとドライバを実行していることを確認してください。

メールボックスを別の Exchange サーバーに移動する

上で説明したすべての手順を実行しても Exchange Server アナライザでこのエラー、または同様の内容の警告 (連続した仮想メモリ領域の残りが 150 MB 未満の場合) が表示される場合は、問題が生じているサーバーからメールボックスを移動して負荷を減らす必要があります。このサーバーにあるメールボックスが多すぎます。

Exchange 2000 Server や Exchange Server 2003 でメールボックスを移動するには

  1. Active Directory ユーザーとコンピュータで、メールボックスを移動するユーザーを選択します。

  2. 前の手順で選択したユーザーの一覧を右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

Exchange Server 2003 でメールボックスを移動するには

  1. Exchange システム マネージャで、[サーバー] を展開し、メールボックスを移動するサーバーを展開します。次に、メールボックスの移動元の ストレージ グループを展開して移動するメールボックスが含まれる メールボックス ストアを展開し、[メールボックス] をクリックします。

  2. 詳細ペインで、メールボックスを移動するユーザーを右クリックし、[Exchange タスク] をクリックします。

  3. Exchange タスク ウィザードの [実行可能なタスク] ページで、[メールボックスの移動] をクリックし、[次へ] をクリックします。

  4. 指示を注意して読み、ウィザードの残りの手順に従います。

仮想メモリの断片化に関する問題解決の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044)

  • 文書番号 838233「Exchange 2000 Server コンピュータの速度が低下するか、応答が停止し、イベント ID 9582 および 1160 が繰り返し記録される。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=838233)

メッセージ サイズの制限値設定の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

メールボックスの移動の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328810「[XADM] サーバー間でメールボックスを移動する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328810)

  • 文書番号 821829「Exchange Server 2003 でのメールボックスの移動」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821829)


VirtualReserveSize is non-default
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザは、次のレジストリの値を読み取り、ExIPC (Exchange Interprocess Communication) コンポーネントの初期メモリ割り当てが既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EXIPC\Parameters\VirtualReserveSize

VirtualReserveSize キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ExIPC は、Inetinfo.exe (インターネット インフォメーション サービス) と Store.exe (Microsoft Exchange Information Store サービス) がデータを迅速に移動できるようにするものです。一般には、ExIPC の既定の初期メモリ割り当てで十分です。既定では、VirtualReserveSize キーは存在していません。このキーは、Microsoft コンサルティング サービスまたは Microsoft 製品サポート サービスからの指示があった場合にのみ追加および構成してください。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\EXIPC\Parameters

  3. VirtualReserveSize キーを削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスと IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ExIPC の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821879「キーの定義は、Exchange Server 2003 でのコンポーネントをトランスポート。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821879)

  • 文書番号 260995「[XCON] Exchange 2000 における主要なトランスポート コンポーネントの定義」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=260995)


仮想メモリのイベントの間隔が変更されている
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、仮想メモリの断片化に関するイベントをログ出力する際のしきい値が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ VM Info Update Interval

VM Info Update Interval レジストリ値が存在しており、値が 3600 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

32 ビット版の Microsoft Windows® システムには、2 種類のメモリがあります。物理メモリ (システムに実装されている実際のメモのリ容量) と仮想メモリ アドレス スペース (仮想化された 4 GB のメモリ スペース) です。システムに取り付けられている物理メモリの量とは無関係に、仮想アドレス スペースの合計サイズは常に同じ 4 GB です。すべての 32 ビット アプリケーションに当てはまるわけではありませんが、Exchange Server の場合、仮想アドレス スペースは仮想メモリに一致するため、これらの用語は同義で使用されます。

通常の動作中、Microsoft Exchange Information Store サービスは繰り返し仮想メモリの割り当て、使用、および割り当ての解除を行います。仮想メモリの割り当て、使用、および割り当て解除が頻繁に行われると、仮想メモリの断片化が発生することがあります。仮想メモリの断片化は、時間が経過すると発生することがあるファイル システムの断片化に似ています。しばらくすると、割り当てられた仮想メモリのセグメントが連続的ではなくなって、パフォーマンスが低下し始めます。ファイル システムの場合、ファイル システムを最適化するアプリケーションを実行することができ、これはほとんどの場合、システムがオンライン状態でアクセスされている間に実行できます。仮想メモリの断片化の場合、最適化ツールはありません。代わりに、この問題を解決するために、Microsoft Exchange Information Store サービスを停止してから開始するか、システムを再起動する必要があります。

既定では、Microsoft Exchange Information Store サービスは、仮想メモリの空きを 1 時間に 1 回 (3,600 秒ごと) 確認します。VM Info Update Interval レジストリ値は、管理者が既定の 3,600 秒の間隔を変更できるようにする構成機能です。既定のレベルを変更する場合、5 分 (300 秒) より小さい値を設定しないことをお勧めします。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

  3. 右側のペインで、VM Info Update Interval の値を削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Information Store サービスを再開して変更を適用します。

Exchange Server 2003 および Exchange 2000 Server における仮想メモリ断片化のトラブルシューティングに関する詳細については、Microsoft サポート技術情報の文書番号 325044「[HOWTO] Exchange Server 2003 および Exchange 2000 Server における仮想メモリの断片化のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325044) を参照してください。


ライトバック キャッシュが有効でない
Microsoft Exchange Server アナライザ - 文書 > 記憶域 >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールによって、トランザクション ログをホストするドライブに対するディスク アレイ コントローラのライトバック キャッシュの設定が正しくないと判断されました。

トランザクション ログをホストするすべてのドライブについて、アレイ コントローラのライトバック キャッシュを 100% 有効化することをお勧めします。トランザクション ログから読み取ることはほとんどありません。トランザクション ログ ドライブへの書き込み速度が上がるほど、Exchange Server を実行しているサーバーのパフォーマンスは向上します。

この警告を修正するには、次の操作を行います。

  • ライトバック キャッシュを有効化します。

Exchange サーバーのハード ディスクを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 188589「Exchange DB とハード ディスクおよびコントローラの書き込みキャッシュについて」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=188589) を参照してください。


サードパーティ製のソフトウェア
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクション内の文書には、Microsoft® Exchange Server アナライザ ツールによるサードパーティ製のソフトウェアの評価に関する詳細が記載されています。さらに、これらの文書には、Exchange Server アナライザによって検出されたサードパーティ製のソフトウェアに関連するエラー、警告、および既定以外の構成を解決するための対処法も説明されています。


ウイルス対策のフォルダの除外が構成されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange Server に Symantec AntiVirus Corporate Edition (Symantec AV) がインストールされており、リアルタイム保護 (RTP) が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Storages\Filesystem\RealTimeScan

HaveExceptionDirs レジストリ値が 0 に設定されていることが検出されると、エラーが表示されます。HaveExceptionDirs レジストリ値が 0 の場合、フォルダの除外は無効になっています。

フォルダの除外を有効にすると、リアルタイムのウイルス対策スキャン中に特定のフォルダがスキャンされなくなります。Exchange Server でフォルダの除外を有効にしていないと、以下の問題が発生する可能性があります。

  • Symantec AV RTP によって、通常のプログラムの動作中にアクセスされる特定の正常なファイルがウィルスに感染しているという、誤った報告が行われる場合があります。

  • Symantec AV RTP によって、企業のセキュリティ ポリシーで既に Exchange Server での実行が許可されているソフトウェア ファイルがウイルスに感染しているという、誤った報告が行われる場合があります。

  • Symantec AV RTP によって Exchange Server ディレクトリ構造がスキャンされ、不正確なウイルス検出が行われたり、Exchange サーバーが予測しない動作を行ったり、さらには Exchange Server データベースが損傷したりする場合があります。

重要 :
ファイル ベースのスキャン ソフトウェアを、Exchange Server のデータベース、ログ、一時ファイル、インターネット インフォメーション サービス (IIS) システムのファイル、または IFS (Installable File System) ドライブ (ドライブ M) に対しては絶対に実行しないでください。ウイルス対策ソフトウェアは、これらのファイルを含むフォルダをスキャンしないように構成してください。

Exchange Server コンピュータのオペレーティング システムと Exchange Server のプログラム ファイル (Exchsrvr\Bin フォルダ) に対しては、ファイル ベースのウイルス対策ソフトウェアを実行できます。ただし、以下のファイルとフォルダに対しては、ファイル ベースのウイルス対策ソフトウェアを実行しないでください。

  • Exchange Server データベース (.mdb および .stm) ファイルおよびトランザクション ログ (.log) ファイル (既定の場所は \Exchsrvr\MDBData)

  • Exchange Server .mta ファイル (既定の場所は \Exchsrvr\Mtadata)

  • Exchange Server メッセージ追跡ログ ファイル (既定の場所は \Exchsrvr\<サーバー名>.log)

  • 仮想サーバー フォルダ (既定の場所は \Exchsrvr\Mailroot)

  • サイト レプリケーション サービス (SRS) ファイル (既定の場所は \Exchsrvr\Srsdata)

  • インターネット インフォメーション サービス (IIS) のシステム ファイル (既定の場所は \%SystemRoot%\System32\Inetsrv)

  • Internet Mail コネクタのファイル (既定の場所は \Exchsrvr\IMCData)

  • メッセージ変換に使用されるストリーミング一時ファイルを格納するために使用される作業フォルダ。既定では、この作業フォルダの場所は \Exchsrvr\MDBData です。

  • Eseutil.exe などのオフライン保守ユーティリティと共に使用される一時フォルダ。既定では, .exe ファイルを実行する場所はこのフォルダになりますが、この場所はユーティリティの実行時に構成できます。

ファイル ベースのスキャンは、以下のフォルダに対して実行することができます。

  • Exchsrvr\Address

  • Exchsrvr\Bin

  • Exchsrvr\Exchweb

  • Exchsrvr\Res

  • Exchsrvr\Schema

Symantec AntiVirus Corporate Edition のリアルタイム スキャンで除外を構成する方法の詳細については、Symantec のウイルス対策 Web サイト (http://www.symantec.com/) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange Server 環境を強化する方法の詳細については、「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Antigen がパブリック フォルダのレプリケーション メッセージをスキャンする
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-03-13

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 Exchange サーバーにパブリック フォルダ ストアが存在しているかどうかを判断します。InformationStore オブジェクトが msExchPublicMDB オブジェクト クラスのオブジェクトであることが検出された場合、サーバーはパブリック フォルダ ストアをホストします。

また、Microsoft® Exchange Server アナライザは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ANTIGENVSAPI.DLL の Version キーの値を判断します。ANTIGENVSAPI.DLL の Version キーの値が 1517 以上の場合、Sybari Antigen for Microsoft Exchange Version 8.0 SR3 またはそれ以降のバージョンが Exchange Server にインストールされていることを示します。

最後に、Exchange Server アナライザは次のレジストリ ブランチに対してクエリを実行し、DoNotScanIPMReplicationMessages キーが存在していて、このキーが 0 より大きい値に設定されているかどうかを確認します。

HKEY_LOCAL_MACHINE\Software\Sybari Software\Antigen for Exchange\DoNotScanIPMReplicationMessages

DoNotScanIPMReplicationMessages キーの値に応じて、インストールされている Sybari Antigen が Exchange Server パブリック フォルダのレプリケーション メッセージをスキャンし、場合によってはそれを削除するかどうかが決まります。DoNotScanIPMReplicationMessages キーの値が 1 未満の場合は、Antigen が winmail.dat ファイルに対してウイルスのスキャンを行います。Exchange Server は、サーバー間でのパブリック フォルダのレプリケーションを容易にするなど、いくつかの目的で Winmail.dat ファイルを使用します。Antigen がこれらの Winmail.dat ファイルのいずれかを変更すると、パブリック フォルダのレプリケーション処理が失敗します。

Exchange Server アナライザは、以下の条件に当てはまることを確認すると、エラーを表示します。

  • Exchange Server が 1 つ以上のパブリック フォルダ ストアをホストしている。

  • サーバーに Sybari Antigen Build 1517 またはそれ以降のバージョンがインストールされている。

  • DoNotScanIPMReplicationMessages キーが存在していないか、または存在していても 0 より大きい値に設定されていない。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
このエラーを修正するには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Sybari Software\Antigen for Exchange

  3. 右側のペインに DoNotScanIPMReplicationMessages.subkey が既に表示されている場合は、それをダブルクリックして値を 1 に設定します。

  4. DoNotScanIPMReplicationMessages.subkey が表示されていない場合は、右側のペインを右クリックし、新しい DWORD 値としてサブキーを作成します。

  5. DoNotScanIPMReplicationMessages 値を、設定を 1 にして構成します。

    注 :
    パブリック フォルダのレプリケーションでウイルスがレプリケートされると、この新しいレジストリ キーを有効にしている場合でも、Antigen はリアルタイム スキャン ジョブでウイルスを検出します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange Server コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)


CA eTrust: EML/LOG/EDB/STM/DAT ファイルがリアルタイム ファイル除外リストに含まれていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているファイル拡張子の一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeExtList

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeExtList

Exchange データ ファイルの種類 (.eml, .log, .edb, .stm、または .dat) に対応するファイル拡張子が szExcludeExtList の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では、このフォルダは .exe ファイルが実行される場所にありますが、ツールの実行時に場所を変更できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange データ ドライブが手動によるジョブ スキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus で手動によるファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAnitvirus\CurrentVersion\Job\szExcludeDirs

また、Exchange Server アナライザ ツールは、Exchange システム データ ファイルの場所に対応するストレージ グループ属性である、Active Directory® ディレクトリサービス内の MsExchESEParamSystemPath 属性の値も読み取ります。

Exchange システム データ ファイルの場所に対応するパスが szExcludeDir の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、この場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange データ ドライブがリアルタイムのスキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

また、Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ストレージ グループについて MsExchESEParamSystemPath 属性の値を判断します。この属性は、Exchange データ ファイルのパスを表しています。

Exchange システム データ ファイルの場所に対応するパスが szExcludeDir の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイル レベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイル レベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange IFS パスが手動によるジョブ スキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus で手動によるファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAnitvirus\CurrentVersion\Job\szExcludeDirs

また、次のレジストリ エントリも読み取り、Exchange IFS (Installable File System) ドライブを表すドライブ文字を取得します。

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

Exchange 2000 Server では、既定のドライブ文字は M です。Exchange Server 2003 では、IFS ドライブは既定でオフになっています。

Exchange Server アナライザにより、IFS ドライブに対応するパスが szExcludeDirs の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • IFS で表されているドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange IFS パスがリアルタイムのスキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

また、次のレジストリ エントリも読み取り、Exchange IFS (Installable File System) ドライブを表すドライブ文字を取得します。

HKLM\System\CurrentControlSet\Services\EXIFS\Parameters\DriveLetter

Exchange 2000 Server では、既定のドライブ文字は M です。Exchange Server 2003 では、IFS ドライブは既定でオフになっています。

Exchange Server アナライザにより、IFS ドライブに対応するパスが szExcludeDirs の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • IFS で表されているドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: 拡張子に関係なくすべてのファイルをスキャンするようにリアルタイム スキャンが設定されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているファイル名拡張子の一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\dwFileFilterType

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\dwFileFilterType

dwFileFilterType の値が、ファイル名拡張子に関係なくすべてのファイルをスキャンするように構成されていることが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: ストレージ グループ ドライブが手動によるジョブ スキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus で手動によるファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Job\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAnitvirus\CurrentVersion\Job\szExcludeDirs

また、Exchange Server アナライザ ツールは、Exchange システム ログ ファイルの場所に対応するストレージ グループ属性である、Active Directory® ディレクトリサービス内の MsExchESEParamSystemPath 属性の値も読み取ります。

Exchange システム ログ ファイルの場所に対応するパスが szExcludeDir の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

  • Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: ストレージ グループ ドライブがリアルタイムのスキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているディレクトリの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\Realtime\szExcludeDirs

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeDirs

Exchange Server アナライザはさらに、Exchange システム データ ファイルの場所に対応するストレージ グループ属性である Active Directory® ディレクトリ サービス内の MsExchESEParamSystemPath 属性の値に対してクエリを実行します。

Exchange システム データ ファイルの場所に対応するパスが szExcludeDir の値に含まれていないことが検出されると、警告が表示されます。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを判断するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これにより、Exchange Server に重大な障害が発生することがあり、データベース エラーが発生することもあります。

  • Exchange IFS (Installable File System) によって表現されるドライブ (通常はドライブ M) をファイルレベルのウイルス スキャン ソフトウェアでスキャンすると、さらに多くの問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表されている Exchange Server ドライブ。既定では、これは M ドライブです。

  • Exchange データベースとログ ファイル。既定では、これらのファイルは Exchsrvr\Mdbdata フォルダにあります。

  • Exchsrvr\Mtadata フォルダの Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミングの一時ファイルを格納する作業フォルダ。このフォルダは既定では \Exchsrvr\MDBData にありますが、この場所は変更できます。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では、このフォルダは .exe ファイルが実行される場所にありますが、ツールの実行時に場所を変更できます。

  • Exchsrvr\Srsdata フォルダのサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダの Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダの IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブのスキャン時に発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


CA eTrust: Exchange プロセスがリアルタイムのスキャンから除外されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは以下のレジストリ エントリを読み取り、Computer Associates の eTrust Antivirus による、リアルタイムのファイルレベルのウイルス対策スキャンから除外されているプロセスの一覧を取得します。

eTrust Antivirus 6.0

HKEY_LOCAL_MACHINE\Software\ComputerAssociates\InoculateIT\6.0\RealTime\szExcludeProcessNames

eTrust Antivirus 7.0

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\Realtime\szExcludeProcessNames

szExcludeProcessNames の値に STORE.EXE、EMSMTA.EXE、および MAD.EXE が含まれていないことが検出されると、警告が表示されます。

Microsoft Exchange Information Store プロセス (Store.exe)、Exchange MTA プロセス (Emsmta.exe)、またはシステム アテンダント プロセス (Mad.exe) が実行されているときには、ファイルレベルのウイルス スキャン ソフトウェアでこれらのプロセスをスキャンしないことをお勧めします。

eTrust Antivirus は、ファイルレベルのウイルス対策スキャン プログラムです。Exchange Server コンピュータにインストールされている eTrust Antivirus のバージョンを確認するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[eTrust Antivirus] をポイントし、[eTrust Antivirus] をクリックしてアプリケーションを起動します。

  2. eTrust Antivirus のアプリケーション メニューで、[Help] メニューの [About eTrust Antivirus] をクリックします。

  3. [Product Version] フィールドを調べて、eTrust Antivirus のバージョンを判断します。

Exchange Server コンピュータでファイルレベルのウイルス スキャン ソフトウェアを使用すると、次の問題が発生する場合があります。

  • ファイルレベルのウイルス スキャン ソフトウェアは、使用中のファイルやスケジュールされた間隔内にあるファイルをスキャンし、Exchange がそのファイルの使用を試みると Exchange ログやデータベース ファイルをロックまたは隔離することがあります。これによって Exchange Sever で重大な障害が発生し、データベース エラーも発生する可能性があります。

  • ファイルレベルのウイルス スキャン ソフトウェアを使用して、IFS によって表されるドライブ (通常は M ドライブ) をスキャンすると、さらに問題が発生する可能性があります。

どのファイルレベルのウイルス対策プログラムを使用していても、次のファイルとフォルダは必ずファイルレベルのウイルス スキャン ソフトウェアから除外しておく必要があります。

  • .eml, .edb, .stm, .log, .dat、および .chk ファイル。

  • IFS で表される Exchange Server ドライブ。既定では、ドライブ M です。

  • Exchange のデータベースとログ ファイル。既定では、これらは、Exchsrvr\Mdbdata フォルダに置かれています。

  • Exchsrvr\Mtadata フォルダ内の Exchange MTA ファイル。

  • Exchsrvr\<サーバー名>.log ファイルなどの追加のログ ファイル。

  • Exchsrvr\Mailroot 仮想サーバー フォルダ。

  • メッセージ変換に使用されるストリーミング一時ファイルを格納するために使用される作業フォルダ。既定では、このフォルダは \Exchsrvr\MDBData に置かれますが、場所の構成が可能です。

  • Eseutil.exe などのオフライン保守ツールで使用される一時フォルダ。既定では, .exe ファイルが実行される場所はこのフォルダですが、実行場所はツールを実行するときに構成できます。

  • Exchsrvr\Srsdata フォルダ内のサイト レプリケーション サービス (SRS) ファイル。

  • %SystemRoot%\System32\Inetsrv フォルダ内の Microsoft インターネット インフォメーション サービス (IIS) システム ファイル。

  • %SystemRoot%\IIS Temporary Compressed Files フォルダ内の IIS 作業ファイル。

この警告を修正するには

  1. eTrust Antivirus ユーザー インターフェイスを使用して、上の一覧にあるフォルダとファイルを、ファイルレベルのウイルス対策スキャンから除外します。

  2. Exchange Server コンピュータで eTrust Antivirus を使用するための最新情報については、Computer Associates eTrust Antivirus Web サイト (http://www3.ca.com/Solutions/Product.asp?ID=156) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server とウイルス対策ソフトウェアの併用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 32841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

IFS ドライブをスキャンすると発生する可能性がある問題の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298924「Exchange 2000 の M ドライブのバックアップまたはスキャンを行うと問題が発生する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298924)

  • 文書番号 300608「[XADM] データベースをマウントしようとすると、C1041737 エラーとイベント ID 470 のメッセージが表示される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=300608)

  • 文書番号 299046「[XADM] 予定表アイテムがユーザーのフォルダから削除される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=299046)


Client Service Messaging Security for SMB v2.0 更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取ります。

HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Version の値が 6.2100 である場合、Trend Micro ScanMail Client Service Messaging Security for SMB v2.0 がインストールされていることを示します。

また、Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、インストールされている Client Service Messaging Security for SMB v2.0 のバージョンを判断します。メジャー ビルド番号が 1145 より小さい場合は、警告が表示されます。

この警告は、Exchange サーバーに Client Server Messaging Security for SMB v2.0 がインストールされており、推奨されるソフトウェア更新プログラムが存在することを示しています。推奨される更新プログラムは、Client Server Messaging Security for SMB v2.0 Patch 2 for Messaging Component です。この更新プログラムの使用は強く推奨されており、サーバーの全体的なパフォーマンスと信頼性を向上させることができます。

この警告を修正するには、次の操作を行います。

  1. Client Server Messaging Security for SMB を入手できる Trend Micro の Update Center (英語) (http://www.trendmicro.com/download/product.asp?productid=39) にアクセスします。

  2. Patch 2 をダウンロードしてインストールします。
注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。

その他の Trend Micro 製品向け更新プログラムの詳細については、Trend Micro の Update Center Web サイト (英語) (http://www.trendmicro.com/download/) を参照してください。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange Server コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、「Exchange Server Partners」(http://go.microsoft.com/fwlink/?linkid=16226) のウイルス対策に関するページを参照してください (このサイトは英語の場合があります)。


HP Command View EVAPerf のインストールを検討する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-09

Microsoft® Exchange Server アナライザ ツールは、Win32_SCSIController Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Name キーの値を判断します。Name キーの値が Compaq HSV110CCL である場合、サーバーの最低 1 つのディスク ボリュームが HP EVA ストレージ エリア ネットワーク (SAN) によって提供されていることを示します。

また、Exchange Server アナライザは Win32_Service WMI クラスに対してもクエリを実行し、HP StorageWorks Command View EVAPerf (EVSPDCS) サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合、サービスは実行されています。

以下の両方の条件に当てはまる場合は、ベスト プラクティスのメッセージが表示されます。

  • サーバーの最低 1 つのディスク ボリュームが HP EVA SAN によって提供されている。

  • HP StorageWorks Command View EVAPerf (EVSPDCS) サービスが存在しないか、実行されていない。

HP StorageWorks SAN 用の追加のパフォーマンス カウンタを公開する無償のソフトウェア管理アプリケーションが HP から提供されています。管理者はこの管理アプリケーションを使用して、SAN の個々のコントローラと物理ディスクのパフォーマンスを監視できます。

推奨されているベスト プラクティスに従うには、次のようにします。

  1. HP StorageWorks Command View EVAPerf Software Web サイトから、HP Command View EVAPerf アプリケーション (http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?pnameOID=471498&locale=en_US&taskId=135&prodSeriesId=471497&prodTypeId=12169&swEnvOID=1005http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?pnameOID=471498&locale=en_US&taskId=135&prodSeriesId=471497&prodTypeId=12169&swEnvOID=1005) をダウンロードします (このサイトは英語の場合があります)。

    注 :
    サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。

  2. ダウンロードした自己抽出型の実行可能ファイルを実行し、指示に従ってアプリケーションをインストールします。


EMC PowerPath Service が停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、EMC PowerPath Service サービスの Started キーの値を判断します。値が True の場合は EMC PowerPath Service サービスが実行されています。値が False の場合は EMC PowerPath Service サービスは実行されていません。Exchange Server アナライザによって、Started キーの値が False であることが検出されると、警告が表示されます。

EMC PowerPath は、マルチパス入出力 (MPIO) ソフトウェアです。マルチパス機能を使用すると、外部記憶装置へのアクセスに 1 台のホストで最大 32 個のパスを使用でき、フェールオーバーや負荷分散の機能が向上するため、高可用性データ アクセスが可能になります。マルチパス機能はオペレーティング システムの機能ではありませんが、MPIO Driver Development Kit (DDK) を通してサポートされています。ストレージ ベンダは MPIO DDK を使用することにより、相互運用可能なマルチパス ソリューションを作成できます。

MPIO ソフトウェアが実行されていると、Microsoft Windows® は 1 つのドライブだけを検出しますが、MPIO ソフトウェアがさまざまな記憶装置への複数の接続を管理します。MPIO ソフトウェアが停止した場合、Windows では、接続されているすべての記憶域ドライブが別個のドライブとして検出されます。これが、記憶装置のエラーや誤動作につながる可能性があります。

EMC PowerPath Service サービスを開始するには

  1. サービス MMC スナップインを開きます。

  2. EMC PowerPath Service サービスを右クリックし、[プロパティ] をクリックします。

  3. MC PowerPath サービスのプロパティ ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は、[適用] をクリックし、[OK] をクリックします。

  4. EMC PowerPath Service サービスを右クリックし、[開始] をクリックします。

  5. このサービスのスナップインを終了します。

Windows でのさまざまな記憶域テクノロジの展開に関する一般的な情報については、「Planning to Use Windows Storage Features with SANs」(http://go.microsoft.com/fwlink/?LinkId=33626) を参照してください (このサイトは英語の場合があります)。


EMC PowerPath Version Mismatch Between Cluster Nodes
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2007-07-25

Microsoft Exchange アナライザ ツールは、次のレジストリ エントリを読み取り、クラスタ内の各ノードにインストールされている EMC PowerPath のバージョンを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\EMC\PowerPath\Version

Exchange クラスタ内の 2 番目以降のノードの Version の値が最初のノードの Version の値と異なることが検出されると、エラーが表示されます。

このエラーは、この Exchange クラスタ内の各ノードで、同じレベルの EMC PowerPath ドライバが実行されていないことを示しています。ベスト プラクティスとして、Exchange クラスタ内のすべてのノードで同じレベルの EMC PowerPath ドライバを実行することをお勧めします。

EMC PowerPath は、マルチパス入出力 (MPIO) ソフトウェアです。マルチパス機能を使用すると、外部記憶装置へのアクセスに 1 台のホストで最大 32 個のパスを使用でき、フェールオーバーや負荷分散の機能が向上するため、高可用性データ アクセスが可能になります。マルチパスはオペレーティング システムの機能ではありませんが、MPIO Driver Development Kit (DDK) を通してサポートされています。このキットはストレージ ベンダにとって、相互運用可能なマルチパス ソリューションを構築するための手段となっています。

MPIO ソフトウェアが実行されていると、Microsoft Windows は 1 つのドライブだけを検出しますが、MPIO ソフトウェアがさまざまな記憶装置への複数の接続を管理します。MPIO ドライバがクラスタのノード間で一致しない場合、クラスタ フェールオーバーの問題が発生する可能性があります。

この問題を解決するには、すべてのノードを同じ EMC PowerPath ドライバのバージョンにアップグレードする必要があります。

詳細情報

Windows でのさまざまな記憶域テクノロジの展開の詳細については、SAN と Windows ストレージ機能の使用についてのページ (http://go.microsoft.com/fwlink/?LinkId=33626) を参照してください (このサイトは英語の場合があります)。


Emulex FC ポート ドライバが 2 年以上更新されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-19

Microsoft® Exchange Server アナライザ ツールは、Win32_SCSIController Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DriverName キーに値が設定されているかどうかを判断します。以下の状況について判断します。

  • Exchange サーバーに Emulex FC ポート ドライバがインストールされている。

  • Exchange サーバーに、最新バージョンの Emulex FC ポート ドライバがインストールされている。

  • その Emulex FC ポート ドライバが、過去 2 年以内に更新されている。

Exchange Server アナライザによって、DriverName キーの値が 2 年以上更新されていないことが検出されると、警告が表示されます。

Emulex FC ポート ドライバは、1 つまたは複数のホスト バス アダプタ (HBA) 内で、SCSI のみ、または SCSI と IP の並行動作の機能を提供します。この FC ポート ドライバは、ファイバ チャネル アービトレーテッド ループ (FC-AL) トポロジ、ポイント ツー ポイント トポロジ、およびファブリック トポロジをサポートしています。FC ポート ドライバは、ホストベースの論理ユニット番号 (LUN) マッピングまたは固定バインドが必要な、特殊なアプリケーション用に設計されています。

Emulex FC ポート ドライバを更新するには、「Downloads and Manuals for Windows」(http://www.emulex.com/ts/docfc/winframe.htm) を参照してください。特殊な OEM ドライバが必要な場合は、Emulex のソフトウェアとドキュメントについての Web サイト (http://www.emulex.com/ts/index.html) を参照してください。

注 :
このトピックにあるサードパーティの Web サイトは、必要な技術情報の検索に利用することを目的として用意されています。これらの URL は通知なしに変更される場合があります。


Emulex SCSIport ミニポート ドライバが 2 年以上更新されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-06-14

Microsoft® Exchange Server アナライザ ツールは、Win32_SCSIController Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DriverName キーに値が設定されているかどうかを判断します。以下の状況について判断します。

  • Emulex SCSIport ミニポート ドライバが Exchange サーバーにインストールされている。

  • 最新のバージョンの Emulex SCSIport ミニポート ドライバが Exchange サーバーにインストールされている。

  • Emulex SCSIport ミニポート ドライバが過去 2 年以内に更新されている。

Exchange Server アナライザによって、DriverName キーの値が 2 年以上更新されていないことが検出されると、警告が表示されます。

SCSIport ミニポート ドライバは、FC-AL (Fibre Channel Arbitrated Loop) トポロジ、Point-to-Point トポロジ、およびファブリック トポロジで SCSI 機能を提供します。

Emulex SCSIport ミニポート ドライバを更新するには、「Downloads and Manuals for Windows」(http://www.emulex.com/ts/docfc/winframe.htm) (英語) を参照してください。特殊な OEM ドライバが必要な場合は、「OEM software and documentation」(http://www.emulex.com/ts/index.html) (英語) を参照してください。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Emulex Storport ミニポート ドライバが 2 年以上更新されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-06-14

Microsoft® Exchange Server アナライザ ツールは、Win32_SCSIController Microsoft® WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、DriverName キーに値が設定されているかどうかを判断します。以下の状況について判断します。

  • Emulex Storport ミニポート ドライバが Exchange サーバーにインストールされている。

  • 最新バージョンの Emulex Storport ミニポート ドライバが Exchange サーバーにインストールされている。

  • Emulex Storport ミニポート ドライバが最近 2 年間に更新された。

Exchange Server アナライザによって、DriverName キーの値が 2 年以上更新されていないことが検出されると、警告が表示されます。

Emulex Storport ミニポート ドライバは、ストレージ エリア ネットワーク (SAN) およびハードウェア ベースのディスク アレイのパフォーマンスと管理性を最適化します。また、Emulex Storport ミニポート ドライバは、FC-AL (Fibre Channel arbitrated loop) トポロジ、ポイントツーポイント トポロジ、およびファブリック トポロジをサポートします。

Emulex Storport ミニポート ドライバを更新するには、「Downloads and Manuals for Windows」(http://www.emulex.com/ts/docfc/winframe.htm) を参照してください。特殊な OEM ドライバが必要な場合は、「OEM software and documentation」(http://www.emulex.com/ts/index.html) を参照してください。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Exchange 以外のプロセスの CPU 使用率が高いことが検出された
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

  • Microsoft® Exchange Server アナライザ ツールは、このサーバーの使用可能な CPU に対する Exchange Server 以外のプロセスによる使用率が、現在 20% を超えていると判断しました。使用可能な CPU に対する Exchange Server 以外のプロセスによる使用率が 20% を超えている場合、エラーが表示されます。

  • Exchange Server を実行するサーバーは可能な限り Exchange Server 専用にし、Exchange 以外に実行するアプリケーションまたはサービスをできるだけ少なくすることをお勧めします。

このエラーを修正するには

  • 別のプロセスが CPU の大半を消費している場合は、次のいずれかの方法を試してください。

    • そのプロセスを無効にし、問題が解消されるかどうかを確認します。

    • 可能であれば、そのプロセスを別のサーバーに移動します。

    • そのプロセスが正しく構成されているかどうかを確認し、この問題に対応する更新プログラムが Microsoft およびプロセスのプロバイダから提供されていないかどうかを調べます。

    • そのプロセスが不要であれば、アンインストールします。

  • そのプロセスを移動または修正できない場合は、Exchange Server 以外のプロセスにより追加される負荷を許容できるようにサーバーを再調整する必要があります。この再調整を行う際には、ユーザーを別の Exchange サーバーに移動することも検討します。


HP/Compaq Secure Path サービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、HP/Compaq Secure Path サービスが実行中かどうかを判断します。HP/Compaq Secure Path サービスが実行中ではないことが検出されると、警告が表示されます。

HP/Compaq Secure Path サービスは、マルチパス I/O (MPIO) のソフトウェアです。マルチパスによって、ホストは外部の記憶装置にアクセスするパスを最大 32 持つことが可能になるため、フェールオーバーや負荷分散に役立つデータ アクセスの高可用性に必要なものが提供されます。マルチパスはオペレーティング システムの機能ではありませんが、MPIO Driver Development Kit (DDK) を通してサポートされています。このキットはストレージ ベンダにとって、相互運用可能なマルチパス ソリューションを構築するための手段となっています。

MPIO ソフトウェアの実行中、Windows オペレーティング システムで検出されるドライブは 1 つだけですが、MPIO ソフトウェアはさまざまな記憶装置への複数の接続を管理しています。MPIO ソフトウェアが停止した場合、Windows では、接続されているすべての記憶域ドライブが別個のドライブとして検出されます。この問題からは、おそらく記憶域のエラーや誤動作が生じます。

この警告を修正するには

  1. [サービス] MMC スナップインを開きます。

  2. [HP/Compaq Secure Path] サービスを右クリックし、[プロパティ] をクリックします。

  3. [HP/Compaq Secure Path] サービスのプロパティ ページにある [全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。そのようになっていない場合は、[適用] をクリックし、[OK] をクリックします。

  4. [HP/Compaq Secure Path] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを閉じます。

Windows を使用して異なる記憶域テクノロジを展開することの一般的な情報については、「Planning to Use Windows Storage Features with SANs」(http://go.microsoft.com/fwlink/?linkid=33626) を参照してください (このサイトは英語の場合があります)。


サードパーティ製のソフトウェアの影響
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーでサードパーティ製のソフトウェアが実行されていると判断しました。このサードパーティ製のソフトウェアは、サーバーのパフォーマンスの問題が発生する原因になる場合があります。サードパーティ製のソフトウェアには、制限がないため、次のようなソフトウェアが含まれています。

  • ファイルレベルのウイルス対策製品

  • Exchange 対応の電子メール ウイルス対策製品

  • スパム対策製品

  • FAX サーバー ソフトウェア

  • 外部メールまたは共同作業のコネクタ

  • ファイル サービスおよび印刷サービス

  • モバイル デバイス コネクタ

このエラーを修正するには

  • サードパーティ製のソフトウェアによって Exchange Server のパフォーマンスが低下している疑いがある場合は、サードパーティ製のソフトウェアをアンインストールまたは無効にして、Exchange Server のパフォーマンスを測定します。

  • サードパーティ製のソフトウェアがパフォーマンスの低下の原因であるが、このソフトウェアがサーバーの機能に重要である場合は、別の専用サーバーを用意して 2 つのサーバーで負荷を分散することを検討します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


INO_FLPY.SYS のバージョンの更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Computer Associates のウイルス対策フィルタ ドライバである Ino_flpy.sys のバージョンを判断します。

具体的には、CIM_Datafile WMI クラスに対してクエリを実行し、Ino_flpy.sys の Version キーの値を判断します。このバージョン ビルド番号によっては、ソフトウェア更新プログラムが必要になる場合があります。Version キーの値によって Ino_flpy.sys ファイルのバージョン番号が 5.00.6100.109 未満であることが示されている場合は、警告が表示されます。

バージョン番号が 5.00.6100.109 未満の場合は、Exchange Server コンピュータに最新バージョンの Ino_flpy.sys ファイルがインストールされていないことを示しており、より新しいバージョンのフィルタ ドライバをインストールする必要があります。Ino_flpy.sys ファイル用のウイルス対策ソフトウェアの更新プログラムは、Computer Associates の Web サイトにあります。このウィルス対策ソフトウェアの更新プログラムの使用は強く推奨されており、Exchange Server コンピュータの総合的なパフォーマンスと信頼性を高めることができます。

Exchange 2000 Server または Exchange Server 2003 コンピュータに Inoculan Computer Associates eTrust Antivirus Version 6.x または 7.x および InoculateIT Version 6.x ウイルス対策ソフトウェア プログラムがインストールされると、セットアップ プログラムによって、Ino_flpy.sys および Ino_fltr.sys ウイルス対策フィルタ ドライバ ファイルが %systemroot%\system32\drivers フォルダにコピーされます。ウイルス対策ドライバ ファイルは、必要なウイルス対策サービスを開始するために使用される Windows NT® カーネル モード ドライバです。古いバージョンのフィルタ ドライバを使用すると、Exchange Server コンピュータで予期しない結果が生じる場合があります。

この警告を修正するには

  1. ino_flpy.sys ファイル用の最新のウイルス対策ソフトウェアの更新プログラムを入手するには、Computer Associates の Web サイト (http://supportconnectw.ca.com/premium/antivirus/downloads/nt/4.5/ildrvupdate.asp) にアクセスします (このサイトは英語の場合があります)。

  2. 適切な更新されたバージョンの eTrust または InoculateIT をダウンロードします。

  3. Ino_flpy.sys ファイルのバックアップを含む、Exchange Server コンピュータの完全バックアップを実行します。

  4. eTrust または InoculateIT に対する最新の更新プログラムをインストールします。
注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 240309「ウイルス対策ソフトウェアによるファイルのフィルタリングを完全に無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240309)

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


INO_FLTR.SYS バージョン更新が可能
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、no_fltr.sys Computer Associates ウイルス対策フィルタ ドライバのバージョンを判断します。

また、CIM_Datafile WMI クラスに対してクエリを実行し、Ino_fltr.sys の Version キーの値を判断します。バージョンのビルド番号によっては、ソフトウェアの更新が必要になる場合があります。Version キーの値によって、Ino_fltr.sys ファイルのバージョン番号が 5.00.6100.142 より小さいことが示されると、警告が表示されます。

5.00.6100.142 より小さいバージョン番号は、Ino_fltr.sys ファイルの最新バージョンが Exchange Server コンピュータにインストールされていないため、フィルタ ドライバの最新バージョンをインストールする必要があることを示します。Ino_fltr.sys ファイルに対するウイルス対策ソフトウェアの更新は、Computer Associates Web サイトから入手できます。このウイルス対策ソフトウェアの更新は強く推奨されており、Exchange Server コンピュータの全体的なパフォーマンスと信頼性を向上させることができます。

Inoculan Computer Associates eTrust Antivirus Version 6.x または 7.x、および InoculateIT Version 6.x ウイルス対策ソフトウェア プログラムを Exchange 2000 Server または Exchange Server 2003 コンピュータにインストールすると、セットアップ プログラムによって、Ino_flpy.sys および Ino_fltr.sys ウイルス対策フィルタ ドライバ ファイルが %systemroot%\system32\drivers フォルダにコピーされます。ウイルス対策ドライバ フィルタ ファイルは、必要なウイルス対策サービスを開始するために使用される Windows NT® カーネル モードのドライバです。古いバージョンのフィルタ ドライバは、Exchange Server コンピュータで予期しない結果を引き起こす可能性があります。

この警告を修正するには

  1. Ino_fltr.sys ファイル用の最新のウイルス対策ソフトウェア更新は、Computer Associates Web サイト (http://supportconnectw.ca.com/premium/antivirus/downloads/nt/4.5/ildrvupdate.asp) から入手できます (このサイトは英語の場合があります)。

  2. eTrust または InoculateIT の適切な更新バージョンをダウンロードします。

  3. Ino_fltr.sys ファイルのバックアップを含む、Exchange Server コンピュータの完全バックアップを実行します。

  4. eTrust または InoculateIT に最新の更新プログラムをインストールします。
注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 240309「ウイルス対策ソフトウェアによるファイルのフィルタリングを完全に無効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240309)

  • 文書番号 32841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、「Exchange Server Partners: Antivirus」(http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


McAfee GroupShield 5.2 for Microsoft Exchange の Exchange 用更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-19

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、VSAPI (Virus Scanning Application Programming Interface) ライブラリ ファイルが Microsoft Exchange Information Store サービスに登録されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

McAfee GroupShield 5.2 for Microsoft Exchange を Exchange 2000 Server または Exchange Server 2003 にインストールすると、Library レジストリ エントリに GSEVS2.DLL の値が作成されます。このライブラリ ファイルは、GroupShield 5.2 for Microsoft Exchange で、VSAPI 関連の機能をいくつか実行します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、GSEVS2.DLL の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 682 より小さいことが示されると、警告が表示されます。

GSEVS2.DLL のバージョン番号が 682 より小さい場合は、最新バージョンの GroupShield 5.2 for Microsoft Exchange がインストールされていないことを示します。GroupShield 5.2 for Microsoft Exchange のソフトウェア更新プログラムは、McAfee の Web サイトから入手できます。この更新プログラムの使用は強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。さらに、GroupShield for Microsoft Exchange 5.2.682 にアップグレードすると、重要な DLL の最新バージョンが使用されることも保証されます。Exchange Server のメッセージング展開では、最新バージョンの gsevs2.dll を使用することによってパフォーマンスと信頼性が大幅に向上しました。

この警告を修正するには

  1. McAfee Web サイトの情報検索のページ (http://knowledgemap.nai.com/) にアクセスして、GroupShield 5.2 for Microsoft Exchange Server の最新バージョンを確認します。最新バージョンを確認するには、以下の McAfee Solutions KnowledgeBase 文書、および上記サイトに掲載されているその他の McAfee Solutions KnowledgeBase 文書を参照してください。

    • ソリューション ID KB40567「Getting the latest version of GroupShield and/or SpamKiller」

    • ソリューション ID KB nai18117「Product Version Information for GroupShield for Exchange 2000」

  2. McAfee Web サイト (https://secure.nai.com/us/forms/downloads/upgrades/login.asp) にアクセスします。

  3. 使用しているバージョンの GroupShield 5.2 for Microsoft Exchange Server に対応する最新の更新プログラムをダウンロードします。

  4. Exchange Server コンピュータの完全バックアップを作成します。

  5. GroupShield 5.2 for Microsoft Exchange Server に最新の更新プログラムをインストールします。
注 :
このトピックにあるサードパーティの Web サイトは、必要な技術情報の検索に利用することを目的として用意されています。これらの URL は通知なしに変更される場合があります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


McAfee GroupShield 6.0 for Microsoft Exchange の Exchange 用更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、VSAPI (Virus Scanning Application Programming Interface) ライブラリ ファイルが Microsoft Exchange Information Store サービスに登録されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

McAfee GroupShield 6.0 for Microsoft Exchange が Exchange 2000 Server または Exchange Server 2003 にインストールされていると、Library レジストリ エントリの値は VSAPISCANSOURCE.DLL になります。このライブラリ ファイルは、GroupShield 6.0 for Microsoft Exchange で、VSAPI 関連の機能をいくつか実行します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI （Windows® Management Instrumentation) クラスに対してクエリを実行し、VSAPISCANSOURCE.DLL の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 6.0.1148.0 より小さいことが示されると、警告が表示されます。

VSAPISCANSOURCE.DLL のバージョン番号が 6.0.1148.0 より小さい場合は、GroupShield 6.0 for Microsoft Exchange の最新バージョンがインストールされていないことを示します。GroupShield 6.0 for Microsoft Exchange のソフトウェア更新プログラムは、McAfee の Web サイトから入手できます。この更新プログラムの使用は強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。

この警告を修正するには

  1. McAfee の Web サイト (http://knowledgemap.nai.com/) の「Guided Knowledge Search」ページを参照して、GroupShield 6.0 for Microsoft Exchange の最新バージョンを確認します (このサイトは英語の場合があります)。以下の McAfee Solutions の文書、およびそのサイトにある他の McAfee Solutions の文書を使用して、最新バージョンを確認します。

    • ソリューション ID nai18117「Product Version Information for GroupShield for Exchange 2000」(このサイトは英語の場合があります)

    • ソリューション ID KB37636「Version numbers for McAfee GroupShield 6.x for Microsoft Exchange」(このサイトは英語の場合があります)

    • ソリューション ID KB40567「Getting the latest version of GroupShield and/or SpamKiller」(このサイトは英語の場合があります)

  2. McAfee の Web サイト (https://secure.nai.com/us/forms/downloads/upgrades/login.asp) の「Product Downloads」ページを参照します (このサイトは英語の場合があります)。

  3. 使用中のバージョンの GroupShield 6.0 for Microsoft Exchange に対応する最新の更新プログラムをダウンロードします。

  4. Exchange Server コンピュータの完全バックアップを作成します。

  5. GroupShield 6.0 for Microsoft Exchange に最新の更新プログラムをインストールします。
注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、「Exchange Server Partners: Antivirus」(http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーに McAfee GroupShield がインストールされているが、このサービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、McAfee GroupShield for Microsoft Exchange がインストールされているかどうか、および McAfee GroupShield サービスが Exchange コンピュータ上で実行されているかどうかを判断します。

さらに、Win32_Service WMI クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの値が True なのかそれとも False なのかをも判断します。

値が False の場合、Exchange Server コンピュータ上で Information Store サービスは実行されていません。値が True の場合、Microsoft Exchange Information Store サービスは実行されています。

Exchange Server アナライザによって、Microsoft Exchange Information Store サービスが実行されていること、および McAfee GroupShield はインストールされているが McAfee GroupShield サービスが開始されていないことが検出されると、警告が表示されます。

McAfee GroupShield は、Exchange のウイルス対策を実現します。McAfee GroupShield サービスの停止を引き起こしていると思われる理由とその解決方法を以下に示します。

  • Exchange Server 上で実行されているソフトウェアが、評価版または有効期限が切れたトライアル版である。この場合、McAfee GroupShield の再インストールが必要となる場合があります。McAfee GroupShield の使用を継続するには、少なくともライセンス認証を行う必要があります。

  • 管理者が誤って McAfee GroupShield サービスを停止してしまった。このサービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。サービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、必要に応じてシステムのウイルス駆除を行います。

Microsoft では通常、メッセージング システム用に設計されたウイルス対策ソフトウェアを、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することを推奨しています。最大限の保護を実現するには、着信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。

McAfee GroupShield サービスを開始するには

  1. サービス MMC スナップインを開きます。

  2. [McAfee GroupShield] サービスを右クリックし、[プロパティ] をクリックします。

  3. [McAfee GroupShield] プロパティ ページの [全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。[自動] に設定されていない場合は、[適用] をクリックし、[OK] をクリックします。

  4. [McAfee GroupShield] サービスを右クリックし、[開始] をクリックします。

  5. サービス スナップインを終了します。

また、ユーザーのデスクトップでもクライアント ウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

  • Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

  • Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

  • 電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、Microsoft ホワイト ペーパー『Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment』(http://go.microsoft.com/fwlink/?LinkId=30732) を参照してください (このサイトは英語の場合があります)。


Messageware Plus Pack がインストールされている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、いずれかの Exchange Server に Messageware Plus Pack がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Messageware Incorporated\Core Services\PlusPack\Load

Load の値のデータが 1 に等しいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Messageware Plus Pack は、Messageware Incorporated 社によって作成された Microsoft Office Outlook® Web Access for Exchange Server 2003 アドインです。Messageware Plus Pack は、Outlook Web Access Basic ユーザーと Outlook Web Access Premium ユーザーの両方に対して Outlook Web Access の機能拡張を提供します。

Messageware Plus Pack の詳細については、Messageware OWA Suite の Web サイト (http://www.messageware.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Microsoft Antigen データ実行防止の互換性
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2007-02-19

Microsoft Exchange アナライザ ツールは、Win32_Service Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Microsoft Antigen サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合は、サービスが実行されています。

Exchange アナライザは、次のレジストリ エントリを読み取り、Microsoft Antigen の Kaspersky スキャン エンジンが Exchange Server にインストールされているかどうかを判断します。このレジストリ エントリは、Kaspersky スキャン エンジンが Exchange Server にインストールされている場合にのみ存在します。

HKEY_LOCAL_MACHINE\Software\Sybari Software\Antigen for Exchange\Scan Engines\Kaspersky

Exchange Server を Microsoft Windows Server 2003 Service Pack 1 (SP1) 以降のバージョンで実行している場合、Exchange アナライザは Win32_ComputerSystem WMI クラスに対してクエリを実行し、SystemStartupOptions キーの値に文字列 '/NOEXECUTE=OPTOUT' または '/NOEXECUTE=ALWAYSON' が含まれているかどうかを判断します。この文字列が含まれている場合は、サーバー上でデータ実行防止 (DEP) が有効になっています。データ実行防止は 1 組のハードウェアおよびソフトウェアのテクノロジで、メモリに対して追加のチェックを実行し、悪意のあるコードがシステム上で実行されることを防止します。

Exchange アナライザ ツールによって以下の条件に当てはまると判断されると、警告が表示されます。

  • サーバー上で Microsoft Antigen サービスが有効になっている。

  • Antigen の Kaspersky スキャン エンジンがインストールされている。

  • Exchange サーバーが Microsoft Windows Server 2003 Service Pack 1 (SP1) 以降のバージョンで実行されている。

  • サーバー上でデータ実行防止が有効になっている。

この警告は、現在のサーバー構成により、メッセージングおよびウイルス スキャンのパフォーマンスに問題が発生する可能性があることを示します。

この警告に対処するには、マイクロソフト サポート技術情報の文書番号 905952「Antigen クライアントがメッセージングのパフォーマンスが Antigen の期待より低下し、応答を停止します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=905952) で説明されている手順に従い、プログラムごとに DEP を無効にします。

詳細情報

データ実行防止の詳細については、マイクロソフト サポート技術情報の文書番号 875352「Windows XP Service Pack 2、Windows XP Tablet PC Edition 2005、および Windows Server 2003 のデータ実行防止 (DEP) 機能の詳細」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=875352) を参照してください。


NSI Software の Double-Take がインストールされている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Double-Take サービスの Started キーの値を判断します。この値が True の場合は、この Exchange サーバー上で Double-Take サービスが実行されていることを示しています。Exchange サーバー上で Double-Take サービスが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザは、既定以外の構成であることを示すこのメッセージを、情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

NSI Software, Inc. の Double-Take は、ユーザーが選択したファイルまたはボリューム全体を、標準のネットワーク接続を経由して 1 つ以上のソース サーバーから 1 つ以上のターゲット サーバーにコピーします。これらのコピーによって、企業は障害やシステム停止が回復した後、ユーザーの手動による操作の有無にかかわらず、迅速に業務を再開できます。

Double-Take の詳細については、Double-Take Web サイト (http://www.nsisoftware.com/pro/doubletake) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Double-Take はデータ レプリケーション ソフトウェアです。Exchange 2000 Server および Exchange Server 2003 の複数サイト データ レプリケーションの詳細については、Microsoft サポート技術情報の文書番号 895847「Exchange 2003 と Exchange 2000 の複数サイト データ レプリケーション サポート」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895847) を参照してください。


Exchange 以外のプロセスが 20% を超えるプロセッサ時間を消費している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの %Processor Time (_Total) カウンタからデータを収集し、パフォーマンス データを分析します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • プロセッサのボトルネックが発生している。

  • Exchange 以外の 1 つ以上のプロセスが使用する、サーバー CPU 時間の合計平均が 20% を超えている。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • プロセッサのボトルネックが発生している。

  • Exchange 以外の 1 つ以上のプロセスが使用する、サーバー CPU 時間の合計平均が 10% を超えている。

Process パフォーマンス オブジェクトの下にあるこの % Processor Time (_Total) パフォーマンス カウンタは、プロセッサの全体的な使用率を示します。平均 CPU 使用率は、常に 80% 未満にする必要があります。これより高い平均はプロセッサのボトルネックを示します。90% を超えるプロセッサ時間の頻繁な急上昇もプロセッサのボトルネックを示しています。

プロセッサのボトルネックの解消

Exchange サーバーのプロセッサのボトルネックを解消する多くの方法があります。

  • 最初に、サーバーで負荷を引き起こしているアプリケーションまたはタスクを確認します。アプリケーションがプロセッサ時間を使用する必要があるのかどうか、またはプロセスに問題がある可能性があるのかどうかを判断します。

  • Exchange 以外のアプリケーションがそのサーバーに対して重要でない場合は、そのアプリケーションを別のサーバーで実行します。可能な場合は、サーバーの役割も他のコンピュータに移動します。たとえば、Inetinfo プロセスが大量の CPU 使用率を消費している場合は、Inetinfo が実行するプロトコル作業を担当するフロントエンド サーバーを追加することを検討します。パブリック フォルダ アクセスを専用のパブリック フォルダ サーバーに移動することもできます。最後に、サーバーが多くの配布リストの展開を実行する場合は、配布リストの展開を専用の配布リスト展開サーバーに移動して、CPU の使用率を減らすことができます。

  • 可能な場合は、プロセッサをさらに追加するか、より速いプロセッサを追加します。また、プロセッサによってサポートされている場合は、ハイパー スレッディングを有効にします。ハイパー スレッディングはシステム BIOS を構成して有効にすることができます。詳細については、コンピュータの製造元のヘルプ ドキュメントを参照してください。

  • プロセッサの処理能力を高めることができない場合は、プロセッサの負荷を減らす必要があります。サーバーに対する全体的な影響を減らすには、I/O、CPU、またはメモリを集中的に使用するタスクを通常の運用時間外に実行することを確実に行います。

  • バックアップ、保守などの CPU を集中的に使用するタスクをピーク時間外に実行されるようにします。また、これらのタスクが段階的に実行されるようにします。段階的なタスクの実行とは、各タスクに対して、異なる開始時刻、さらに可能であれば異なる終了時刻を設定することを意味します。また、データベースまたはストレージ グループの保守およびバックアップを段階的に実行すると、これらのリソースを集中的に使用するタスクの影響が少なくなります。

詳細情報

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。

  • ユーザー メールボックスを移動してサーバー負荷を減らす方法の詳細については、「ユーザーのメールボックスを別のサーバーに移動する」を参照してください。


Exchange 以外のプロセスが 50% を超えるプロセッサ時間を消費している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。このパフォーマンス データ収集エンジンは、Processor パフォーマンス オブジェクトの %Processor Time (_Total) カウンタからデータを収集し、パフォーマンス データを分析します。

Process パフォーマンス オブジェクトの下にあるこの % Processor Time (_Total) パフォーマンス カウンタは、プロセッサの全体的な使用率を示します。平均 CPU 使用率は、常に 80% 未満にする必要があります。これより高い平均はプロセッサのボトルネックを示します。90% を超えるプロセッサ時間の頻繁な急上昇もプロセッサのボトルネックを示しています。

Exchange 以外のプロセスが使用するサーバー CPU 時間の合計平均が 50% を超えることが Exchange Server アナライザによって検出されると、実際のプロセッサのボトルネックが検出されなくても、警告が表示されます。

潜在的なプロセッサのボトルネックの解消

Exchange サーバーには、潜在的なプロセッサのボトルネックを解消する多くの方法があります。

  • 最初に、サーバーで負荷を引き起こしているアプリケーションまたはタスクを確認します。アプリケーションがプロセッサ時間を使用する必要があるのかどうか、またはプロセスに問題がある可能性があるのかどうかを判断します。

  • Exchange 以外のアプリケーションがそのサーバーに対して重要でない場合は、そのアプリケーションを別のサーバーで実行します。可能な場合は、サーバーの役割も他のコンピュータに移動します。たとえば、Inetinfo プロセスが大量の CPU 使用率を消費している場合は、Inetinfo が実行するプロトコル作業を担当するフロントエンド サーバーを追加することを検討します。パブリック フォルダ アクセスを専用のパブリック フォルダ サーバーに移動することもできます。最後に、サーバーが多くの配布リストの展開を実行する場合は、配布リストの展開を専用の配布リスト展開サーバーに移動して、CPU の使用率を減らすことができます。

  • 可能な場合は、プロセッサをさらに追加するか、より速いプロセッサを追加します。また、プロセッサによってサポートされている場合は、ハイパー スレッディングを有効にします。ハイパー スレッディングはシステム BIOS を構成して有効にすることができます。詳細については、コンピュータの製造元のヘルプ ドキュメントを参照してください。

  • プロセッサの処理能力を高めることができない場合は、プロセッサの負荷を減らす必要があります。サーバーに対する全体的な影響を減らすには、I/O、CPU、またはメモリを集中的に使用するタスクを通常の運用時間外に実行することを確実に行います。

  • バックアップ、保守などの CPU を集中的に使用するタスクをピーク時間外に実行されるようにします。また、これらのタスクが段階的に実行されるようにします。段階的なタスクの実行とは、各タスクに対して、異なる開始時刻、さらに可能であれば異なる終了時刻を設定することを意味します。また、データベースまたはストレージ グループの保守およびバックアップを段階的に実行すると、これらのリソースを集中的に使用するタスクの影響が少なくなります。

詳細情報

  • プロセッサのボトルネックの詳細については、「プロセッサのボトルネック」を参照してください。

  • Exchange Server のパフォーマンスの詳細については、『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


古いバージョンの HP/Compaq Secure Path がインストールされている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-13

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーにインストールされている HP/Compaq Secure Path ソフトウェアのバージョンを判断します。Secure Path のバージョンが 3.7.2.540 ではない場合、警告が表示されます。

この警告を解決するには、Secure Path ソフトウェアを更新します。HP/Compaq の販売店に連絡し、このソフトウェアを更新してください。

HP/Compaq Secure Path ソフトウェア更新の詳細については、HP サイトの「HP StorageWorks Secure Path」(http://h18006.www1.hp.com/products/sanworks/softwaredrivers/securepath/index.html) を参照してください (このサイトは英語の場合があります)。

注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


ポート 25 がブロックされている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、次のレジストリの値を読み取り、Exchange Server を実行しているサーバーに、Microsoft Exchange 用の McAfee VirusScan がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Network Associates\TVD\VirusScan Enterprise\CurrentVersion

また、次のレジストリ ブランチに対してクエリを実行し、VirusScan 製品がどのようにポートをブロックするように構成されているかを判断します。

HKLM\Software\Network Associates\TVD\Shared Components\On Access Scanner\BehaviourBlocking

このブランチのキーは、VirusScan 製品のオンアクセス機能を使用してブロックまたは許可するプロセスおよびポートの構成に使用されます。

また、Exchange Server アナライザは、McAfee VirusScan サービスの Started キーの値について、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、McAfee VirusScan サービスが Exchange サーバーで実行されているかどうかを判断します。

値が False の場合は、この Exchange サーバー上で McAfee VirusScan サービスは実行されていません。値が True の場合は、McAfee VirusScan サービスは実行されています。

次の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • McAfee VirusScan が Exchange サーバー上にインストールされ実行されている。

  • "マス メール型ワームによるメールの送信を防止する" ブロック ルールがポート 25 に対して有効になっている。

  • Exchange Server の SMTP (Simple Mail Transfer Protocol) サービスがブロック ルールから除外されていない。

この警告は、McAfee VirusScan アプリケーションが、Exchange Server とのポート 25 を使用した正当な通信をブロックする可能性があるように構成されていることを示しています。これによって、メール フローの問題を引き起こす可能性があります。

この問題を解決するには

  • "マス メール型ワームによるメールの送信を防止する" ブロック ルールを無効にするかどうか検討します。

  • Exchange Server の SMTP サービスを、"マス メール型ワームによるメールの送信を防止する" ブロック ルールの除外リストに追加します。

詳細情報

  • Microsoft Exchange 用 McAfee VirusScan の構成方法の詳細については、McAfee サービス ポータル (http://knowledge.mcafee.com/) にアクセスしてください (このサイトは英語の場合があります)。

    注 :
    サードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供しているものです。この URL は予告なしに変更されることがあります。
  • Microsoft Exchange Server 2003 で一般的に使用されるさまざまな種類のウイルス スキャン プログラムの詳細については、マイクロソフト サポート技術情報の記事 823166 の、Exchange Server 2003 とウイルス対策ソフトウェアの概要のページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

  • Microsoft Exchange 2000 Server で一般的に使用されるさまざまな種類のウイルス スキャン プログラムの詳細については、マイクロソフト サポート技術情報の記事 328841 の、Exchange とウイルス対策ソフトウェアに関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

  • 電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、Exchange 環境を電子メール送信によるウイルス感染から守るための指針に関する Microsoft ホワイト ペーパー (http://go.microsoft.com/fwlink/?LinkId=30732) を参照してください。


Red Earth Software Policy Patrol for Exchange Server Needs Update
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2007-07-24

Microsoft Exchange アナライザ ツールは、レジストリを読み取り、次の 2 つのどちらのサブキーが存在するかを判断します。

HKEY_LOCAL_MACHINE\Software\Red Earth Software\Policy Patrol\3.0

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Red Earth Software\Policy Patrol\3.0

これらのブランチのいずれかが存在する場合は、Red Earth Software の Policy Patrol Version 3.0 for Exchange Server がローカル コンピュータにインストールされていることを示します。

Exchange アナライザによって Policy Patrol Version 3 for Exchange Server がローカル コンピュータにインストールされていることが検出されると、警告が表示されます。

この警告は、Policy Patrol for Exchange Server の推奨される更新プログラムが利用可能であることを示しています。

この警告を修正するには、次の操作を行います。

  1. Red Earth Software の Policy Patrol for Exchange Server ダウンロード サイト (http://www.policypatrol.com/download.htm) にアクセスします (このサイトは英語の場合があります)。

  2. Policy Patrol for Exchange Server に必要な更新プログラムまたは推奨される更新プログラムをダウンロードして、インストールします。
注 :
サードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供しているものです。この URL は予告なしに変更されることがあります。


InterScan for Microsoft Exchange および CA eTrust が同時に動作する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange サーバーにインストールされている Trend Micro InterScan for Microsoft Exchange のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Version 値の値データが 7 で始まっている場合、InterScan for Microsoft Exchange Version 7 がインストールされていることを示しています。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Exchange サーバーに Computer Associates の eTrust from がインストールされているかどうかを判断します。

HKLM\Software\ComputerAssociates\eTrustAntivirus\CurrentVersion\

CurrentVersion レジストリ値が存在する場合は、Exchange サーバーに Computer Associates の eTrust Antivirus バージョン 7 がインストールされていることを示しています。

最後に、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、eTrust Antivirus の InoRT サービス (eTrust Antivirus Realtime Server サービス) で使用される Started キーの値を判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • InterScan for Microsoft Exchange と eTrust Antivirus の両方が、Exchange サーバーにインストールされている。

  • eTrust Antivirus Realtime Server サービスが開始されている。

Trend Micro では、InterScan for Microsoft Exchange のフォルダを、eTrust Antivirus などのファイル システム ベースのウイルス対策ソフトウェアのスキャン対象から除外することを推奨しています。InterScan for Microsoft Exchange は、パス内の一時フォルダを使用して独自のスキャン活動を行います。ファイル システム ベースのウイルス スキャン ソフトウェアがこれらの一時フォルダをスキャンすると、InterScan for Microsoft Exchange の正常な動作に干渉する可能性があります。

ベスト プラクティスとして、ファイル システム ベースのウイルス対策ソフトウェア (Computer Associates の eTrust Antivirus など) のリアルタイムによるスキャンから、InterScan for Microsoft Exchange のフォルダを除外してください。ファイル システム ベースのウイルス対策ソフトウェアがインストールされているコンピュータで、InterScan for Microsoft Exchange を使用する方法の詳細については、Trend Micro サポート技術情報の記事「Installing another antivirus application with ScanMail for Exchange also installed on the same server.」(http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=8540) を参照してください。

注 :
サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


InterScan for Microsoft Exchange のアーカイブ ディレクトリに含まれるファイルが多すぎる
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

次に、InterScan for Microsoft Exchange が使用するアーカイブ ディレクトリにあるファイル数がカウントされます。既定では、アーカイブ ディレクトリのパスは次のとおりです。

C:\Program Files\Trend Micro\Smex\Storage\Archive

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange Version 7.0 がインストールされている。

  • InterScan for Microsoft Exchange が使用するアーカイブ ディレクトリにあるファイルが 1,000 を超えている。

この警告は、InterScan for Microsoft Exchange が使用するアーカイブ ディレクトリに多くのファイルがあることを示します。Trend Micro は、ユーザーが InterScan for Microsoft Exchange の使用するアーカイブ フォルダを定期的に調べてクリーンアップすることを推奨しています。


InterScan for Microsoft Exchange のバックアップ ディレクトリに含まれるファイルが多すぎる
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

次に、Exchange Server アナライザは、InterScan for Microsoft Exchange が使用するバックアップ ディレクトリに存在するファイルの数を数えます。既定では、バックアップ ディレクトリのパスは次のとおりです。

C:\Program Files\Trend Micro\Smex\Storage\Backup

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange Version 7.0 がインストールされている。

  • InterScan for Microsoft Exchange が使用するバックアップ ディレクトリに、1,000 を超えるファイルが存在する。

この警告は、InterScan for Microsoft Exchange が使用するバックアップ ディレクトリに多数のファイルが存在することを示しています。Trend Micro では、InterScan for Microsoft Exchange が使用するバックアップ フォルダを定期的に確認し、クリーンアップすることを推奨しています。


InterScan for Microsoft Exchange のバックアップの除外
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、Windows バックアップを使用したバックアップから除外されているファイルとフォルダを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

具体的には、"SMEX\DATA" を含む文字列を検索します。

Exchange Server アナライザによって、FilesNotToBackup キーに "SMEX\DATA" という文字列を持つ値が含まれていることが検出されると、警告が表示されます。

Windows バックアップを使用していない場合、この警告は無視してかまいません。Windows バックアップを使用している場合は、SMEX\DATA ディレクトリの除外を無効にすることをお勧めします。Trend Micro では、このフォルダ内のファイル名の拡張子が .mdb であるファイルをすべてバックアップすることを推奨しています。SMEX\DATA フォルダ内の製品 .mdb ファイルが破損したり削除されたりした場合に、バックアップ ファイルを使用することができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

  3. 左側のペインで [FilesNotToBackup] を選択します。

  4. 右側のペインで、"SMEX\DATA" という文字列を含む値を右クリックし、[削除] をクリックします。

  5. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


InterScan for Microsoft Exchange のデバッグ モードが有効になっている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro の InterScan for Microsoft Exchange でデバッグ モードが有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\DebugModule

DebugModule の値のデータに以下の文字列が 1 つ以上含まれている場合、警告が表示されます。

  • HOST:1

  • CONFIG:1

  • MASTER:1

  • WATCHER:1

  • STORE:1

  • INETINFO:1

  • TCHER:1

  • MON:1

  • MONITOR:1

この警告は、1 つ以上の InterScan for Microsoft Exchange モジュールに対して現在デバッグ モードが有効になっていることを示します。Trend Micro は、トラブルシューティングなど、必要な場合にのみデバッグ モードを有効にすることを推奨しています。Trend Micro は、それ以外の通常の操作についてはデバッグ モードを無効にすることを推奨しています。

この警告を修正するには

  1. Trend Micro の技術情報の記事「Enabling the ScanMail for Exchange (SMEX) 7.0 debugging through the Registry Editor」(http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=25532) を参照してください (このサイトは英語の場合があります)。

  2. Trend Micro の技術情報の記事に記載されている指示に従い、すべてのモジュールに対してデバッグを無効にします。
注 :
サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


InterScan for Microsoft Exchange の検疫ディレクトリに含まれるファイルが多すぎる
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

次に、InterScan for Microsoft Exchange が使用する検疫ディレクトリのファイル数がカウントされます。既定では、検疫ディレクトリのパスは次のとおりです。

C:\Program Files\Trend Micro\Smex\Storage\Quarantine

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange のバージョン 7.0 がインストールされている。

  • InterScan for Microsoft Exchange が使用する検疫ディレクトリにあるファイルが 1,000 を超えている。

この警告は、InterScan for Microsoft Exchange が使用する検疫ディレクトリに多くのファイルがあることを示します。Trend Micro は、ユーザーが InterScan for Microsoft Exchange の使用する検疫フォルダを定期的に調べてクリーンアップすることを推奨しています。


InterScan for Microsoft Exchange の SharedResPool ディレクトリが既定のパスに存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2007-06-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、インストールされている Trend Micro InterScan for Microsoft Exchange のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Exchange Server アナライザは、次のレジストリ エントリも読み取り、SharedResPool フォルダの場所を判断します。

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\SharedResPool

最後に、Exchange Server アナライザは次のレジストリ エントリを読み取り、InterScan for Microsoft Exchange がインストールされている場所を判断します。

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\HomeDir

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • InterScan for Microsoft Exchange Version 7.0 がインストールされている。

  • SharedResPool フォルダが、InterScan のルート ディレクトリのパスに置かれている。

ベスト プラクティスとして、SharedResPool ディレクトリは、InterScan for Microsoft Exchange が使用するルート ディレクトリがあるドライブよりも高速なドライブに移動することをお勧めします。Trend Micro では、パフォーマンスの向上のため、SharedResPool フォルダを高速なドライブに移動することを推奨しています。SharedResPool ディレクトリには、InterScan for Microsoft Exchange Version 7.0 に含まれているプロセス間で共有されるリソース用のメモリ マッピング ファイルが含まれています。7.0. このディレクトリの内容を削除しないでください。

SharedResPool フォルダの詳細については、ScanMail for Exchange (SMEX) 7.0 の SharedResPool ディレクトリと Engine ディレクトリについての説明のページ (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=26898) を参照してください (このサイトは英語の場合があります)。

SharedResPool フォルダの移動の詳細については、InterScan for Microsoft Exchange (SMEX) 7.0 の SharedResPool ディレクトリの別の場所への移動に関するページ (http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-127549&id=EN-127549) (英語) を参照してください 。

注 :
サード パーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


メールボックス サーバーで InterScan for Microsoft Exchange SMTP のスキャンを有効にする
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、Microsoft インターネット インフォメーション サービス (IIS) メタベース内の次のプロパティを読み取り、Trend Micro の InterScan for Microsoft Exchange の現在の構成設定を判断します。

LM/SmtpSvc/%SMTPINSTANCE%/EventManager/EventTypes/{76719654-05A6-11d2-9dfd-00C04FA322BA}/Bindings/{6BA0CE4C-AC34-411E-B58A-EB715D04019D}/Enabled

次に、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange サーバー オブジェクトの serverRole 属性値を判断します。serverRole 属性の値が 1 である場合、Exchange サーバーがフロントエンド サーバーとして構成されていることを示しています。値が 0 の場合は、Exchange サーバーがフロントエンド サーバーとして構成されていません。

また、Exchange Server アナライザは Win32_OperatingSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーの OSProductSuite キーの値を判断します。このクエリにより、Exchange サーバーで実行されている特定のオペレーティング システムが判断されます。

Exchange Server アナライザは、次のレジストリ値を読み取り、Exchange サーバーで実行されている InterScan for Exchange のバージョンを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Version 値の値データが 7 で始まっている場合、InterScan for Microsoft Exchange Version 7 がインストールされていることを示しています。

最後に、Exchange Server アナライザは、Active Directory に対してクエリを実行し、homeMDBBL 属性が構成されているオブジェクトの数を判断します。homeMDBBL 属性が構成されているオブジェクトは、メールボックスが有効なオブジェクトです。したがって、homeMDBBL が構成されているオブジェクトの数は、存在しているメールボックスの数となります。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • InterScan for Microsoft Exchange Version 7 がインストールされている。

  • InterScan for Microsoft Exchange が、フロントエンド サーバーとして構成されていない Exchange サーバーで SMTP スキャンを実行するように構成されている。

  • Exchange サーバーに 20 を超えるメールボックスが含まれている。

  • Exchange サーバーで Microsoft Windows Small Business Server 2003 または Microsoft Small Business Server 2000 が実行されていない。

独立した専用のゲートウェイまたはブリッジヘッド サーバーがある場合、Trend Micro は InterScan for Microsoft Exchange Version 7 のユーザーに、メールボックス サーバーで ScanMail 管理コンソールを使用する SMTP スキャンを無効にすることを推奨しています。Trend Micro では、最適なパフォーマンスとセキュリティを得るために、SMTP スキャンをメールボックス サーバーではなくゲートウェイ ブリッジヘッド サーバーで有効にすることを推奨しています。


InterScan for Microsoft Exchange の TEMP ディレクトリに多数のファイルが含まれている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

次に、Exchange Server アナライザ ツールは、InterScan for Microsoft Exchange が使用する TEMP ディレクトリに含まれるファイルの数を数えます。既定では、InterScan for Microsoft Exchange が使用する TEMP ディレクトリのパスは次のとおりです。

C:\Program Files\Trend Micro\Smex\Temp

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange Version 7.0 がインストールされている。

  • InterScan for Microsoft Exchange が使用する TEMP ディレクトリに、100 を超えるファイルが存在する。

この警告は、InterScan for Microsoft Exchange が使用する TEMP ディレクトリに多数のファイルが存在することを示しています。このフォルダにあるファイルは、InterScan for Microsoft Exchange によって使用される一時ファイルです。InterScan for Microsoft Exchange は、本来はこれらのファイルを自動的に削除します。

現在の日付より以前のファイルが多数存在する場合、Trend Micro では古いファイルを手動で削除することを推奨しています。


InterScan for Microsoft Exchange の TEMP ディレクトリに含まれるファイルが多すぎる
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

InterScan for Microsoft Exchange Version 7 がインストールされている場合、Exchange Server アナライザは次のレジストリ エントリを読み取り、InterScan for Microsoft Exchange が使用する TEMP ディレクトリの場所を判断します。

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

次に、Exchange Server アナライザは、InterScan for Microsoft Exchange が使用する TEMP ディレクトリに含まれるファイルの数を数えます。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange Version 7.0 がインストールされている。

  • InterScan for Microsoft Exchange が使用する TEMP ディレクトリに、100 を超えるファイルが存在する。

この警告は、InterScan for Microsoft Exchange が使用する TEMP ディレクトリに多数のファイルが存在することを示しています。このフォルダにあるファイルは、InterScan for Microsoft Exchange によって使用される一時ファイルです。InterScan for Microsoft Exchange は、本来はこれらのファイルを自動的に削除します。

現在の日付より以前のファイルが多数存在する場合、Trend Micro では古いファイルを手動で削除することを推奨しています。


InterScan for Microsoft Exchange 用一時フォルダのパスの変更
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Exchange Server アナライザは、次のエントリも読み取り、InterScan for Microsoft Exchange が使用する一時フォルダの場所を判断します。

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

TempFolderPath 値がレジストリに存在し、構成されている場合は、InterScan for Microsoft Exchange が使用する一時フォルダが InterScan の既定の場所から移動されています。

最後に、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、AdapterSMTP.dll の Version キーの値を判断します。このモジュールは、Trend Micro の InterScan for Microsoft Exchange に含まれています。AdapterSMTP.dll の Version キーの値が 7.0.1366 より小さい場合は、InterScan for Microsoft Exchange の更新されたバージョンが必要です。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に警告を表示します。

  • InterScan for Microsoft Exchange Version 7 がインストールされている。

  • InterScan for Microsoft Exchange が使用する一時フォルダが元の場所から移動されている。

  • adapterSMTP.dll のファイルのバージョンが 7.0.1366 またはそれ以前である。

Trend Micro では、InterScan for Microsoft Exchange の最近のビルドで一時フォルダを再配置する機能を導入しました。この機能は、7.0.1366 以降のビルドでのみ機能します。この警告は、一時フォルダは再配置されているが、このサーバーが一時フォルダの再配置をサポートしない InterScan for Microsoft Exchange の以前のビルドを実行しているためにその再配置が有効にならないことを示しています。

この警告を修正するには

  1. Trend Micro の Update Center Web サイト (http://www.trendmicro.com/download) にアクセスします (このサイトは英語の場合があります)。

  2. InterScan for Microsoft Exchange に必要な更新プログラムまたは推奨される更新プログラムをダウンロードして、インストールします。
注 :
サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


InterScan for Microsoft Exchange 用一時フォルダのパスの最適化
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Trend Micro InterScan for Microsoft Exchange Version 7.0 がインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Exchange Server アナライザは、次のエントリも読み取り、InterScan for Microsoft Exchange が使用する一時フォルダの場所を判断します。

HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\TempFolderPath

TempFolderPath 値がレジストリに存在し、構成されている場合は、InterScan for Microsoft Exchange が使用する一時フォルダが InterScan の既定の場所から移動されています。

最後に、Exchange Server アナライザは CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、AdapterSMTP.dll の Version キーの値を判断します。このモジュールは、Trend Micro の InterScan for Microsoft Exchange に含まれています。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • InterScan for Microsoft Exchange Version 7 がインストールされている。

  • InterScan for Microsoft Exchange が使用する一時フォルダが、既定の場所のままである。

  • AdapterSMTP.dll のバージョンが、InterScan for Microsoft Exchange が使用する一時フォルダのリダイレクトをサポートするバージョンである。

Trend Micro では、InterScan for Microsoft Exchange の最近のビルドで一時フォルダを再配置する機能を導入しました。この機能は、7.0.1366 以降のビルドでのみ機能します。バージョン 7.0.1366 以降の InterScan for Microsoft Exchange のビルドを使用している場合、Trend Micro は一時フォルダを高速なドライブに再配置することを推奨しています。

一時フォルダを再配置するには

  1. Trend Micro の技術情報の記事「Can users change the location of the ScanMail for Exchange (SMEX) 7.0 temporary folder?」(http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=26343) を参照してください (このサイトは英語の場合があります)。

  2. 記事に示されている手順を実行して、一時フォルダを高速なドライブに再配置します。
注 :
サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


InterScan for Microsoft Exchange の更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-12-15

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、adapterSMTP.dll の Version キーの値を判断します。このモジュールは、Trend Micro の InterScan for Microsoft Exchange に含まれています。

Exchange Server アナライザによって、adapterSMTP.dll の Version キーの値が 7.0.1366 より小さいことが検出されると、警告が表示されます。

この警告は、Exchange サーバーに InterScan for Microsoft Exchange Version 7 がインストールされており、推奨されるソフトウェア更新プログラムが存在することを示しています。この更新プログラムの使用は強く推奨されており、サーバーの全体的なパフォーマンスと信頼性を向上させることができます。

この警告を修正するには

  1. Trend Micro の Update Center Web サイト (http://www.trendmicro.com/download/) にアクセスします (このサイトは英語の場合があります)。

  2. InterScan for Microsoft Exchange に必要な更新プログラムまたは推奨される更新プログラムをダウンロードして、インストールします。
注 :
サードパーティの Web サイト情報は、必要な技術情報を検索できるように提供しています。URL は通知なしに変更される場合があります。


SMTP トランスポートのウイルス対策スキャンが有効になっていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMSMSE (Symantec Mail Security for Microsoft Exchange) サービスの Started キーに値が設定されているかどうかを判断します。Win32_Service クラスによって、Exchange Server 2003 コンピュータに SMSMSE がインストールされているかどうかが判断されます。この値が True の場合は、SMSMSE サービスが実行されていることを示しています。この値が False の場合は、SMSMSE サービスが実行されていないことを示しています。以下の条件に当てはまる場合は、警告が表示されます。

  • Exchange Server 2003 コンピュータに SMSMSE がインストールされている。

  • SMTP トランスポートのウイルス対策スキャンが有効になっていない。

Exchange Server 2003 では、アドバンスド キュー エンジンが、メッセージを宛先に配信するための 6 つのトランスポート イベント シンクの 1 つとして Exchange Transport AntiVirus API を使用しています。Exchange Transport AntiVirus API イベント シンクは OnSubmit.dll に実装されており、Symantec などの Microsoft 以外のベンダがこれを使用してウイルス スキャン ソフトウェアを実装できるようになっています。これらのウイルス スキャン ソフトウェアは各メッセージを検査して、悪意のある添付ファイルやデータ構造を、それらが宛先に到着する前に検出します。このイベントは、OnSubmission イベントとして登録されます。

トランスポートのウイルス対策スキャンを有効にすると、メッセージが SMTP レイヤと Exchange ストアのそれぞれで 1 回の計 2 回スキャンされるようになるため、既定では有効になっていません。ただし、Exchange 組織のインターネット接続のためにフロントエンド サーバーを使用している場合は、これらのサーバーでトランスポートのウイルス対策スキャンを有効にすることができます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
トランスポートのウイルス対策スキャンを有効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\TransportAVAPI に移動します。

  3. Enabled という名前の新しい DWORD 値を作成します。Enabled に、値のデータ 1 を割り当てます。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

注 :
トランスポート スキャン機能は、VSAPI (Virus Scanning Application Programming Interface) 2.5 をベースにした Exchange ウイルス スキャン ソフトウェアでのみ使用できます。

SMTP トランスポート アーキテクチャの詳細については、『Technical Reference Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47891) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Simpler-Webb Exchange Resource Manager の更新プログラムが提供されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-14

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile WMI (Microsoft Windows® Management Instrumentation) クラスに対してクエリを実行し、ERME2KAsyncSink.dll の Version キーに設定されている値を判断します。ERME2KAsyncSink.dll の Version キーの値が 1015 未満であることが検出されると、警告が表示されます。

ERME2KAsyncSink.dll ファイルは、Simpler-Webb Exchange Resource Manager (ERM) のコア バイナリです。ERME2KAsyncSink.dll のバージョンが 1015 未満の場合、ERM version 1.2 以前のリソース マネージャがサーバーにインストールされています。ERM version 1.2 については、Exchange OLE DB が ERM イベント シンクから返される呼び出しを待っているときに、Exchange ローカル配信キューが原因でメッセージの配信が停止する場合がある、という問題があることがわかっています。Exchange ストアをシャットダウンしている間、Microsoft Exchange OLEDB は、OnSyncSave の呼び出しから復帰するためのイベント シンク (ERME2KAsyncSink.dll) を待機しています。

この呼び出しでエラーが返されると、Exchange ストアが正しくシャットダウンされない可能性があります。この問題は、ERM Version 1.35 で解決されています。

この警告を修正するには

  1. [プログラムの追加と削除] を使用して、手動で ERM Version 1.2 を削除します。

  2. ERM Version 1.35 をインストールします。このバージョンは、Simpler-Webb の Web サイト (http://www.swinc.com/products/ERM/upgrade/) で入手できます。

    注 :
    このトピックにあるサードパーティの Web サイトは、必要な技術情報の検索に利用することを目的として用意されています。これらの URL は通知なしに変更される場合があります。


Sybari Antigen 7.5 for Microsoft Exchange の Exchange 用更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、VSAPI (Virus Scanning Application Programming Interface) ライブラリ ファイルが Microsoft Exchange Information Store サービスに登録されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Antigen 7.5 for Microsoft Exchange は Sybari の製品です。Antigen 7.5 for Microsoft Exchange を Exchange 2000 Server または Exchange Server 2003 にインストールすると、Library レジストリ エントリに ANTIGENVSAPI.DLL の値が作成されます。このライブラリ ファイルは、Antigen 7.5 for Microsoft Exchange で、VSAPI 関連の機能をいくつか実行します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI （Windows® Management Instrumentation) クラスに対してクエリを実行し、ANTIGENVSAPI.DLL の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 1316 より小さいことが示されると、警告が表示されます。

ANTIGENVSAPI.DLL のバージョン番号が 1316 より小さい場合は、最新バージョンの Antigen 7.5 for Microsoft Exchange がインストールされていないことを示します。Antigen 7.5 for Microsoft Exchange のソフトウェア更新プログラムは、Sybari の Web サイトから入手できます。この更新プログラムの使用は強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。

この警告を修正するには

  1. Sybari の Web サイト「Licensed Download Center」(http://www.sybari.com/portal/alias__Rainbow/lang__en-US/tabID__3359/DesktopDefault.aspx) にアクセスします (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

  2. 使用中のバージョンの Antigen 7.5 for Microsoft Exchange に対応する最新の更新プログラムをダウンロードします。

  3. Exchange Server コンピュータの完全バックアップを実行します。

  4. Antigen 7.5 for Microsoft Exchange に最新の更新プログラムをインストールします。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Sybari Antigen 8.0 for Microsoft Exchange の Exchange 用更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-01-09

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ値を読み取り、VSAPI (Virus Scanning Application Programming Interface) ライブラリ ファイルが Microsoft Exchange Information Store サービスに登録されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Antigen 8.0 for Microsoft Exchange は Sybari の製品です。Antigen 8.0 for Microsoft Exchange を Exchange 2000 Server または Exchange Server 2003 にインストールすると、Library レジストリ エントリに ANTIGENVSAPIEx.DLL の値が作成されます。このライブラリ ファイルは、Antigen 8.0 for Microsoft Exchange で、VSAPI 関連の機能をいくつか実行します。

また、Exchange Server アナライザは CIM_Datafile Microsoft WMI （Windows® Management Instrumentation) クラスに対してクエリを実行し、ANTIGENVSAPI.DLL の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 1517 より小さいことが示されると、警告が表示されます。

ANTIGENVSAPI.DLL のバージョン番号が 1517 より小さい場合は、最新バージョンの Antigen 8.0 for Microsoft Exchange がインストールされていないことを示します。Antigen 8.0 for Microsoft Exchange のソフトウェア更新プログラムは、Sybari の Web サイトから入手できます。この更新プログラムの使用は強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。

この警告を修正するには

  1. Sybari の Web サイト「Licensed Download Center」(http://www.sybari.com/portal/alias__Rainbow/lang__en-US/tabID__3359/DesktopDefault.aspx) にアクセスします (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

  2. 使用中のバージョンの Antigen 8.0 for Microsoft Exchange に対応する最新の更新プログラムをダウンロードします。

  3. Exchange Server コンピュータの完全バックアップを実行します。

  4. Antigen 8.0 for Microsoft Exchange に最新の更新プログラムをインストールします。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーに Sybari Antigen がインストールされているが、AntigenStore サービスが実行されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Sybari Antigen がインストールされているかどうか、および Exchange コンピュータ上で AntigenStore サービスが実行されているかどうかを判断します。

さらに、Win32_Service WMI クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの値が True なのかそれとも False なのかをも判断します。

値が False の場合、この Exchange Server コンピュータ上で Microsoft Exchange Information Store サービスは実行されていません。値が True の場合、Microsoft Exchange Information Store サービスが実行されています。

Microsoft Exchange Information Store サービスが実行されており、Sybari Antigen がインストールされているが AntigenStore サービスが開始されていないことが検出されると、警告が表示されます。

Sybari Antigen は、Exchange 用のウイルス対策機能を提供します。Sybari AntigenStore サービスが停止しているいくつかの原因と、それらの解決方法を以下に示します。

  • Exchange Server 上で実行しているソフトウェアが、有効期限が切れた評価版 (または試用版) である可能性があります。この場合は、Sybari Antigen の再インストールが必要になることがあります。少なくとも、継続して使用するには、そのソフトウェアをアクティブにする必要があります。

  • 管理者が誤って Sybari Antigen サービスを停止した可能性があります。このサービスが自動的に開始するように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。このサービスが自動的に開始するように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、必要に応じてシステムのウイルス駆除を行います。

メッセージング システム用に設計されたウイルス対策ソフトウェアは、一般に、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。さらに、ユーザーのデスクトップ上でクライアント用のウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

AntigenStore サービスを開始するには

  1. サービス MMC スナップインを開きます。

  2. [AntigenStore] サービスを右クリックし、[プロパティ] をクリックします。

  3. AntigenStore のプロパティ ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [AntigenStore] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でウイルス対策ソフトウェアを使用する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーに Sybari Antigen がインストールされているが、このサービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Sybari Antigen がインストールされているかどうか、および Exchange Server コンピュータ上で AntigenService サービスが実行されているかどうかを判断します。

さらに、Win32_Service WMI クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの値が True なのかそれとも False なのかをも判断します。

値が False の場合、この Exchange Server コンピュータ上で Microsoft Exchange Information Store サービスは実行されていません。値が True の場合、Microsoft Exchange Information Store サービスが実行されています。

Microsoft Exchange Information Store サービスが実行されており、Sybari Antigen がインストールされているが AntigenService サービスが開始されていないことが検出されると、警告が表示されます。

Sybari Antigen は、Exchange 用のウイルス対策機能を提供します。Sybari Antigen サービスが停止しているいくつかの理由と、それらの解決方法を以下に示します。

  • Exchange サーバー上で実行しているソフトウェアが、有効期限が切れた評価版 (または試用版) である可能性があります。この場合は、Sybari Antigen の再インストールが必要になることがあります。少なくとも、継続して使用するには、そのソフトウェアをアクティブにする必要があります。

  • 管理者が誤って Sybari Antigen サービスを停止した可能性があります。このサービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。サービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、必要に応じてシステムのウイルス駆除を行います。

メッセージング システム用に設計されたウイルス対策ソフトウェアは、一般に、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。さらに、クライアント コンピュータでウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

AntigenService サービスを開始するには

  1. [サービス] MMC スナップインを起動します。

  2. [AntigenService] サービスを右クリックし、[プロパティ] をクリックします。

  3. [AntigenService のプロパティ] ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [AntigenService] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。
  • 電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でウイルス対策ソフトウェアを使用する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Symantec Antivirus の定義が 31 日以上更新されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、次の条件に当てはまるかどうかを判断します。

  • このサーバーに Symantec Antivirus がインストールされている。

  • 次のウイルス対策定義ファイルが更新されている。

    HKEY_LOCAL_MACHINE\Software\Symantec\SharedDefs\MicroDefs

Exchange Server アナライザによって、BinHubStamp レジストリ キーの値のデータが 31 日以上更新されていないことが検出されると、警告が表示されます。

Symantec Antivirus for Microsoft Exchange Server は、Exchange Server 用のウイルス対策保護機能を提供します。最新の Symantec Antivirus 定義ファイルがリリースされたら、直ちにダウンロードすることをお勧めします。組織内の次の層には、必ずウイルス対策定義ファイルの更新を展開するようにしてください。

  • メッセージ ゲートウェイ サーバー

  • Exchange サーバー

  • クライアント ワークステーション

最新のウイルス定義ファイルをダウンロードするには、Symantec Antivirus Web サイト (http://www.symantec.com) を参照してください (このサイトは英語の場合があります)。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Exchange サーバーに Symantec Antivirus がインストールされているが、このサービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Started キーに値が設定されているかどうかを判断します。Win32_Service クラスで、Symantec Antivirus for Exchange Server がインストールされているかどうかを判断できます。Started キーの値が True に設定されている場合は、Exchange Server コンピュータで Symantec Antivirus サービスが実行されています。Started キーの値が False に設定されている場合は、Exchange Server コンピュータで Symantec Antivirus サービスは実行されていません。

Exchange Server アナライザによって、Exchange Server コンピュータに Symantec Antivirus がインストールされているが、Symantec Antivirus サービスが開始されていないことが検出されると、警告が表示されます。

Symantec Antivirus は、Exchange Server 用のウイルス対策機能を提供します。Symantec Antivirus サービスが停止する原因となりうるいくつかの状況と、それらの解決方法を以下に示します。

  • Exchange サーバー上で実行しているソフトウェアが、有効期限が切れた評価版または試用版である可能性があります。この場合、Symantec Antivirus の再インストールが必要になる場合があります。少なくとも、継続して使用するには、そのソフトウェアをアクティブにする必要があります。

  • 管理者が誤って Symantec Antivirus サービスを停止した可能性があります。このサービスが自動的に開始するように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。このサービスが自動的に開始するように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、感染している場合はシステムのウイルス駆除を行います。

メッセージング システム用に設計されたウイルス対策ソフトウェアは、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。

Symantec Antivirus サービスを開始するには

  1. [サービス] MMC スナップインを起動します。

  2. [Symantec Antivirus] サービスを右クリックし、[プロパティ] をクリックします。

  3. Symantec Antivirus のプロパティ ページの [全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は、[適用] をクリックし、[OK] をクリックします。

  4. [Symantec Antivirus] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。

また、ユーザーのデスクトップでもクライアント用のウイルス対策ソフトウェアを実行する必要があります。次の状況のいずれかが当てはまる場合は、デスクトップでファイル レベルのウイルス スキャン ソフトウェアを使用することが、十分な保護対策となります。

  • MIME の解析とスキャンを行うことができる、メッセージング システム用に設計されたウイルス対策ソフトウェアを、ゲートウェイで実行している。

  • MIME の解析とスキャンを行うことができる、メッセージング システム用に設計されたウイルス対策ソフトウェアを、Exchange サーバーで実行している。

Microsoft Exchange Server 2003 で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166) を参照してください。

Microsoft Exchange 2000 Server で一般的に使用されるウイルス スキャン プログラムの詳細については、Microsoft サポート技術情報の文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841) を参照してください。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。


Symantec Mail Security for Exchange によるウイルス対策スキャンの構成に関する警告
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMSMSE (Symantec Mail Security for Microsoft Exchange) サービスの Started キーに設定されている値を判断します。

値が True の場合は、Symantec Mail Security for Microsoft Exchange Server がこの Exchange Server コンピュータにインストールされていて、SMSMSE サービスが実行されています。値が False の場合は、SMSMSE サービスは実行されていません。

さらに、Win32_Service WMI クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの値が True なのかそれとも False なのかをも判断します。

値が False の場合、この Exchange Server コンピュータ上で Microsoft Exchange Information Store サービスは実行されていません。値が True の場合は、Microsoft Exchange Information Store サービスが実行されています。

Microsoft Exchange Information Store サービスが実行されており、Symantec Mail Security for Microsoft Exchange がインストールされていても、SMSMSE サービスが実行されていないことが Exchange Server アナライザによって検出されると、警告が表示されます。

組織の環境に対する重大な脅威の 1 つは、電子メール メッセージを介して送信されるウイルスです。電子メールによるウイルスは、コンピュータ システム自体を攻撃する場合もあれば、システムが過負荷の状態になるまで大量のメッセージを送信して電子メール環境を攻撃する場合もあります。組織の環境では、ウイルスに対する十分な保護対策が用意されているようにする必要があります。ウイルスに対する保護対策は、ファイアウォール、SMTP ゲートウェイの外部、各 Exchange サーバー、およびすべてのクライアント上で提供することを検討する必要があります。

この警告を修正するには

  1. Exchange Server コンピュータで、Windows サービス スナップインを起動します。

  2. 右側のペインで、[Symantec Mail Security for Microsoft Exchange] サービスまで下にスクロールし、このサービスをダブルクリックします。

  3. [スタートアップの種類] ボックスの一覧の値が、[自動] に設定されていることを確認します。

  4. [開始] をクリックして、Symantec Mail Security for Microsoft Exchange サービスを開始します。

  5. [OK] をクリックして変更を保存します。次に、この プロパティ ダイアログ ボックスを閉じて、スナップインを終了します。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server とウイルス対策ソフトウェアの併用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 32841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Symantec Mail Security for Microsoft Exchange 4.5 の更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-02-14

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Savfmsevsapi.dll の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 4.5 であることが示されると、警告が表示されます。

Savfmsevsapi.dll のバージョン番号が 4.5 である場合は、Symantec Mail Security for Microsoft Exchange 4.6x の最新バージョンが実行されていないことを示します。Symantec Mail Security for Microsoft Exchange 4.6x のソフトウェア更新プログラムは、Symantec の Web サイトから入手できます。4.63 以降のバージョンへのアップグレードが強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。

次に、Savfmsevsapi.dll のバージョン 4.5 を実行した場合に発生する既知の問題をいくつか示します。

  • Exchange サーバーのメール フロー プロセスの通常の動作中に、パフォーマンスが低下する状況が発生する。

  • ディレクトリ参照キューやローカル配信キューなどの SMTP キューがバックアップされる。

  • Microsoft Exchange Information Store サービスを停止できない。

  • Microsoft Outlook® クライアントが Exchange サーバーに接続できない。

  • Outlook クライアントからのメッセージ送信が、通常の Exchange サーバーへのメッセージ配信よりも大幅に時間がかかる。Outlook クライアントが 30 秒間応答しない場合がある。

この警告を修正するには、次の操作を行います。

  1. Symantec の Web サイト「Symantec Enterprise Support」(英語) (http://www.symantec.com/techsupp/enterprise/) にアクセスします。

  2. バージョン 4.63 以降のバージョンにアップグレードします。
注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange Server コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、「Exchange Server Partners」(http://go.microsoft.com/fwlink/?linkid=16226) のウイルス対策に関するページを参照してください (このサイトは英語の場合があります)。


Trend Micro InterScan for Microsoft Exchange の更新プログラムが存在する
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-01-09

Microsoft® Exchange Server アナライザ ツールは次のレジストリ値を読み取り、VSAPI (Virus Scanning Application Programming Interface) ライブラリ ファイルが Microsoft Exchange Information Store に登録されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Library

Trend Micro の製品である InterScan for Microsoft Exchange が Exchange 2000 Server または Exchange Server 2003 にインストールされると、Library レジストリ エントリに SMXS3DLL.DLL の値が存在するようになります。このライブラリ ファイルは、InterScan for Microsoft Exchange で、VSAPI 関連の機能をいくつか実行します。

Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、SMXS3DLL.DLL の Version キーの値を判断します。Version キーの値によって、このファイルのビルド番号が 1174 より小さいことが示されると、警告が表示されます。

SMXS3DLL.DLL のバージョン番号が 1174 より小さい場合、最新バージョンの InterScan for Microsoft Exchange がインストールされていないことを示します。InterScan for Microsoft Exchange のソフトウェア更新プログラムは、Trend Micro の Web サイトから入手できます。この更新プログラムの使用は強く推奨されており、総合的なパフォーマンスと信頼性を高めることができます。

この警告を修正するには

  1. Trend Micro Web サイト「Update Center, ScanMail for Microsoft Exchange」(http://www.trendmicro.com/download/product.asp?productid=8) にアクセスします (このサイトは英語の場合があります)。

  2. 使用中のバージョンの InterScan for Microsoft Exchange に対応する最新の更新プログラムをダウンロードします。

  3. Exchange Server コンピュータの完全バックアップを作成します。

  4. InterScan for Microsoft Exchange に最新の更新プログラムをインストールします。

Exchange Server とウイルス対策ソフトウェアの併用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Trend Micro ServerProtect for Microsoft Windows が停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SpntSvc サービスの Started キーの値を判断します。SpntSvc サービスは、Trend Micro の製品である ServerProtect for Microsoft Windows によりインストールされます。Started キーの値が True の場合はこのサービスが実行されていることを示し、False の場合はこのサービスが実行されていないことを示します。SpntSvc サービスが開始されていないことが検出されると、警告が表示されます。

ServerProtect for Microsoft Windows は、リアルタイムでのウイルスの検出と削除など、サーバーでのファイル システム ベースのウイルス対策スキャンを行います。

SpntSvc サービスを開始するには

  1. サービス MMC スナップインを開きます。

  2. [ServerProtect Server] サービスを右クリックし、[プロパティ] をクリックします。

  3. [ServerProtect Server のプロパティ] ページの [全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。自動に設定されていない場合、この設定を [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [ServerProtect Server] サービスを右クリックし、[開始] をクリックします。

  5. サービス スナップインを閉じます。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Trend Micro InterScan の構成 : パフォーマンスが最適化されていない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-09-05

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、TempFileThreshold の値を判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

TempFileThreshold レジストリ値は、メッセージ本文および添付ファイルのスキャンに適用されます。メッセージ本文または添付ファイルのサイズが TempFileThreshold キーで指定した値よりも大きい場合、一時ファイルがディスク上に作成されます。それ以外の場合は、メモリ内に作成されます。TempFileThreshold の既定値は 3,072 KB (3 MB) です。

さらに、Exchange Server アナライザは、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、TotalPhysicalMemory キーに設定された値を判断します。この値は、コンピュータに実装されたランダム アクセス メモリ (RAM) のバイト数を表します。

また、Active Directory® ディレクトリ サービスに対してもクエリを実行し、次の場所にあるグローバル設定の delivContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= <組織名> , CN=Global Settings, CN=Message Delivery

この属性は、受信する SMTP メッセージの最大サイズを表します。

TempFileThreshold の値が、1 GB 以上の RAM を実装した Exchange Server コンピュータで受信可能な最大受信メッセージ サイズの 70% 未満であることが検出されると、警告が表示されます。

この警告は、TempFileThreshold レジストリ値が環境に合わせて最適化されていない可能性があることを示します。この値は、少なくとも、使用する Exchange サーバーに設定した添付ファイル サイズの制限値と同等の値にする必要があります。

注 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

  3. 右側のペインで、[TempFileThreshold] をダブルクリックします。

  4. 組織内のメッセージの平均サイズと同じ値を KB 単位で入力します。たとえば、メッセージの平均サイズが 10 MB の場合は、「10240」と入力します。
注 :
この値を増やす場合は、追加のシステム メモリが必要になることがあります。たとえば、ScanningThreads の値を 8 に設定し、TempFileThreshold の値を 10240 に設定する場合、ウイルス スキャンに必要な最小メモリは 80 MB になります (ScanningThreads * TempFileThreshold)。
  1. レジストリ エディタを終了し、ScanMail_RealTimeScan サービスと Microsoft Exchange Information Store サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、マイクロソフト サポート技術情報の文書番号 256986 の、Microsoft Windows レジストリの説明についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


Trend Micro InterScan の構成 : QuerySender レジストリ値が有効になっている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-20

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Trend Micro InterScan for Microsoft Exchange の InterScan_Action サービスに関する Started キーの値を判断します。値が True の場合は、InterScan_Action サービスが実行されています。値が False の場合は、サービスは実行されていません。

Exchange Server アナライザは次のレジストリ エントリを読み取り、InterScan for Microsoft Exchange が、Active Directory® ディレクトリ サービスに対するワイルドカード文字による検索のために構成されているかどうかも判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\QuerySender

QuerySender レジストリ エントリの値が 0 の場合、ワイルドカードによる検索が無効になっています。QuerySender レジストリ エントリの値が 1 の場合、ワイルドカードによる検索が有効になっています。

さらに、Exchange Server アナライザは Active Directory に対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性に列挙されている値の数は、メールボックス ストア上のメールボックスの数を表します。

InterScan_Action サービスが実行されていること、Exchange Server に 100 を超えるメールボックスが含まれていること、および QuerySender レジストリ エントリが 0 に設定されていないことが検出されると、警告が表示されます。

Trend Micro InterScan for Exchange は、Exchange Server 用のウイルス対策機能を提供します。InterScan for Exchange は、配布リストに送信されたメッセージをスキャンしているときの既定の動作として、すべてのメッセージ受信者について、Active Directory グローバル カタログに照会します。配布リストに多数の受信者が含まれている場合、この動作のためにパフォーマンスの問題が発生することがあります。また、この文書に記載する推奨事項が実行されていない場合は、以下のパフォーマンス カウンタの値が高くなります。

  • MSExchangeIS/Virus Scan Queue Length

  • MSExchangeIS/RPC Requests

  • MSExchangeIS/RPC Averaged Latency

QuerySender の値を 0 に設定することで、InterScan for Microsoft Exchange が配布リストに送信されたメッセージをスキャンするときに、受信者全員についてグローバル カタログに照会しないようにします。

この警告を修正するには

  1. QuerySender レジストリ値の使用について、Trend Micro (http://www.trendmicro.com/en/about/overview.htm) に問い合わせます。

  2. QuerySender レジストリ値の詳細については、Trend Micro のソリューション ID 120393 についてのページ (http://esupport.trendmicro.com/support/viewxml.do?ContentID=en-120393) を参照してください。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Viruses in an Exchange Server 2003 Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Trend Micro ScanMail の構成 : ScanMail_Monitor サービスがクラスタ サービスに依存しない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは、クラスタのノードである各サーバーの次のレジストリ エントリを読み取ります。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\Version

Version の値が 6.2.000 である場合は、ScanMail for Microsoft Exchange のバージョン 6.2 がインストールされていることを示します。

また、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。この値が True の場合は、クラスタ サービスが実行されています。この値が False の場合は、クラスタ サービスは実行されていません。

Exchange Server アナライザは、クラスタのノードである各サーバーの次のレジストリ エントリも読み取ります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ScanMail_Monitor

ClusSvc の値である複数の値を持つレジストリ エントリ DependOnService が ScanMail_Monitor キーに含まれていないと検出される場合、ScanMail_Monitor サービスはクラスタ サービスに依存していません。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告メッセージを表示します。

  • サーバーが TrendMicro ScanMail for Microsoft Exchange 6.2 のバージョンを実行している。

  • サーバーがクラスタ サービス (ClusSvc) を実行している。

  • ScanMail_Monitor サービスが、クラスタ サービスに依存するように構成されていない。

ScanMail for Microsoft Exchange 6.2 のビルドのインストール後、クラスタ サービスに依存するように ScanMail_Monitor サービスを構成する必要があります。この依存関係を構成しないと、ノードが再起動されるたびにクラスタ サービスが停止します。

この警告を修正するには、次の操作を行います。

  1. Trend Micro の Web サイトにあるソリューション ID 21441「The Microsoft Exchange Cluster Service unexpectedly stops after applying ScanMail for Exchange (SMEX) 6.2 Patch 1」(英語) (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=21441&id=21441) を参照してください。

    注 :
    ソリューション ID 21441 の文書では、特に Patch 1 のインストール後にこの依存関係を構成するための要件について言及していますが、この文書は ScanMail for Microsoft Exchange 6.2 のすべてのビルドを実行しているサーバーに適用されます。

  2. ソリューション ID 21441 の文書にある「Solutions」セクションに記載されているように、レジストリに DependOnService 複数行文字列値を追加します。
注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。

その他の Trend Micro 製品向け更新プログラムの詳細については、Trend Micro の Update Center Web サイト (英語) (http://www.trendmicro.com/download/) を参照してください。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「ウイルス対策ソフトウェアがインストールされている Exchange Server コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、「Exchange Server Partners」(http://go.microsoft.com/fwlink/?linkid=16226) のウイルス対策に関するページを参照してください (このサイトは英語の場合があります)。


Trend Micro InterScan の構成 : SkipWildcardSearchInGC レジストリ値が 0 に設定されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Trend Micro InterScan for Microsoft Exchange の InterScan_Action サービスに関する Started キーの値を判断します。値が True の場合は、InterScan_Action サービスが実行されています。値が False の場合は、サービスは実行されていません。

Exchange Server アナライザは次のレジストリ エントリを読み取り、InterScan for Microsoft Exchange が、Active Directory® ディレクトリ サービスに対するワイルドカード文字による検索のために構成されているかどうかも判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion\SkipWildcardSearchInGC

SkipWildcardSearchInGC レジストリ エントリの値が 1 の場合、ワイルドカード検索は無効になっています。SkipWildcardSearchInGC レジストリ エントリの値が 0 の場合は、ワイルドカード検索が有効になっています。

さらに、Exchange Server アナライザは、Active Directory に対してもクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数を判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。

InterScan_Action サービスが実行されていること、Exchange Server に 100 を超えるメールボックスが含まれていること、および SkipWildcardSearchInGC レジストリ エントリが 0 に設定されていることが検出されると、警告が表示されます。

Trend Micro InterScan for Microsoft Exchange は、Exchange Server 用のウイルス対策機能を提供します。SkipWildcardSearchInGC 値を 1 に設定することにより、InterScan for Microsoft Exchange はワイルドカード文字 (*) を含む名前を解決できなくなります。ワイルドカード文字を含む名前に関してクエリを実行すると、InterScan for Exchange が結果的にディレクトリ全体をチェックすることになるため、Exchange Server コンピュータのパフォーマンスが大幅に低下する場合があります。また、この文書に記載する推奨事項が実行されていない場合は、以下のパフォーマンス カウンタの値が高くなります。

  • MSExchangeIS/Virus Scan Queue Length

  • MSExchangeIS/RPC Requests

  • MSExchangeIS/RPC Averaged Latency

この警告を修正するには

  1. SkipWildcardSearchInGC レジストリ値の使用について、Trend Micro (http://www.trendmicro.com/en/about/overview.htm) に問い合わせます (このサイトは英語の場合があります)。

  2. SkipWildcardSearchInGC レジストリ値の詳細については、Trend Micro のソリューション ID 20393 (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=20393) を参照してください (このサイトは英語の場合があります)。

    注 :
    Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus の Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Trend Micro InterScan の構成 : MaxMessageCount レジストリ値が 500 に満たない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、MaxMessageCount の値を判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\CurrentVersion

さらに、Exchange Server アナライザは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各メールボックス ストアの homeMDBBL 属性に列挙されているエントリの数も判断します。この属性の数は、メールボックス ストア内のメールボックス数を表します。

Exchange Server に 100 を超えるメールボックスが含まれ、MaxMessageCount の値が 500 未満であることが検出されると、警告が表示されます。

Trend Micro InterScan for Microsoft Exchange は、Exchange Server 用のウイルス対策機能を提供します。InterScan for Exchange スキャン スレッドは、タクスの終了後、スキャン結果をキューに書き込みます。キューに項目が非常に多く並んでいる場合、スキャン スレッドは、キューに書き込んでスレッドを解放できるようになるまでかなり待つ必要があります。スキャン結果を書き込むキューのサイズのしきい値は、MaxMessageCount によって制御します。MaxMessageCount 値を 500 に設定すると、InterScan for Exchange のパフォーマンスを最適化できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\TrendMicro\ScanMail for Exchange\CurrentVersion

  3. 右側のペインで、[MaxMessageCount] をダブルクリックします。

  4. 「500」 (10 進数) と入力します。

  5. レジストリ エディタを終了し、InterScan_RealTimeScan サービスと Microsoft Exchange Information Store サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxMessageCount レジストリ エントリの使用の詳細については、Trend Micro の Web サイト (http://www.trendmicro.com/en/about/overview.htm) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのウイルス対策ソフトウェアの使用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Trend Micro の InterScan がすべての添付ファイルを削除するように構成されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、いくつかのレジストリ エントリを読み取り、InterScan for Microsoft Exchange Server が添付ファイルを削除するように構成されているかどうかを判断します。読み取られる値は、レジストリの次の場所にあります。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

値 | 説明
ActionType | 添付ファイルのブロックが有効になっている場合、どの添付ファイルをブロックするかを表しています。値が 0 の場合、すべての添付ファイルがブロックされます。値が 3 の場合は、管理者がファイルの拡張子、ファイル名、または正しいファイルの種類の一覧を指定しています。この設定は、InterScan 管理コンソールの [Attachment Blocking Settings] ダイアログ ボックスで適切なオプションを選択して構成できます。
EnableAlert | 添付ファイルのブロックが有効かどうかを表しています。値が 1 の場合、添付ファイルのブロックが有効になっています。値が 0 の場合は無効になっています。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable attachment blocking] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

値 | 説明
EnableEManager | InterScan eManager が有効になっているかどうかを示します。値が 1 の場合、eManager が有効になっています。値が 0 の場合は無効になっています。この設定は、InterScan 管理コンソールの [Enable eManager] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。この設定を使用できるのは、別の関連製品である InterScan eManager がインストールされている場合だけです。
EnableWebStoreDalMail | 受信メッセージに対して InterScan アクティブ メッセージ フィルタが有効になっていることを示します。値が 1 の場合、アクティブ メッセージ フィルタが受信メッセージについて有効になっています。値が 0 の場合、受信メッセージについて有効になっていません。この設定は、InterScan 管理コンソールの [Active Message Filter] ダイアログ ボックスの [Inbound Messages] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

また、Exchange Server アナライザは次のレジストリ エントリも読み取り、VSAPI (Virus Scanning API) のメッセージ スキャンが有効になっているかどうかを判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 のときは、VSAPI のスキャンが有効になっています。この値が 0 のときは、VSAPI のスキャンが無効になっています。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable VS API virus scanning] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

Exchange Server アナライザによって以下の条件がすべて当てはまることが検出されると、警告が表示されます。

  • VSAPI スキャンが InterScan for Exchange で有効になっている

  • EnableAlert の値が 1 である

  • ActionType の値が 0 である

  • EnableEManager の値が 1 である

  • EnableWebStoreDelMail の値が 1 である

この警告は、InterScan がスケジュールされたまたは手動でのスキャンを次回実行する時に、すべての添付ファイルを削除するように構成されていることを表しています。

この警告を修正するには

  1. 添付ファイルの削除を目的としていることを確認します。

  2. 必要に応じて、添付ファイルのブロックを無効にするか、動作を [Delete] から [Quarantine] に変更します。これによって、管理者は隔離されたファイルを調べ、保存が必要な添付ファイルがあるかどうかを確認できます。

InterScan for Microsoft Exchange と InterScan eManager の詳細については、Trend Micro の Web サイト (http://www.trend.com) にアクセスしてください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Trend Micro の InterScan が、特定のファイル名の添付ファイルを削除するように構成されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、いくつかのレジストリ エントリを読み取り、InterScan for Microsoft Exchange が添付ファイルを削除するよう構成されているかどうかを判断します。レジストリの次の場所にある値が読み取られます。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

値 | 説明
ActionType | 添付ファイルのブロックが有効になっている場合に、どの添付ファイルをブロックするかを示します。値が 0 の場合は、すべての添付ファイルがブロックされることを示します。値が 3 の場合は、管理者がファイル名の拡張子、ファイル名、または正しいファイルの種類を一覧で指定済みであることを示します。この設定は、InterScan 管理コンソールの [Attachment Blocking Settings] ダイアログ ボックスで必要なオプションを選択することによって構成できます。
EnableAlert | 添付ファイルのブロックが有効になっているかどうかを示します。値が 1 の場合、添付ファイルのブロックが有効になっていることを示します。値が 0 の場合、この機能が無効になっていることを示します。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable attachment blocking] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。
FileName | 削除するファイルの一覧が含まれる、セミコロンで区切られた文字列値です。指定したファイルがブロックされるようにしている場合、この設定は、InterScan 管理コンソールの [Attachment Blocking Settings] ダイアログ ボックスで、必要なファイル名を入力することによって構成できます。

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

値 | 説明
EnableEManager | InterScan eManager が有効になっているかどうかを示します。値が 1 の場合、eManager が有効になっていることを示します。値が 0 の場合、この機能が無効になっていることを示します。この設定は、InterScan 管理コンソールの [Enable eManager] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。この設定を使用できるのは、別の関連製品である InterScan eManager がインストールされている場合だけです。
EnableWebStoreDalMail | 受信メッセージに対して InterScan アクティブ メッセージ フィルタが有効になっていることを示します。値が 1 の場合、受信メッセージに対してアクティブ メッセージ フィルタが有効になっていることを示します。値が 0 の場合、受信メッセージに対してこのフィルタが有効になっていないことを示します。この設定は、InterScan 管理コンソールの [Active Message Filter] ダイアログ ボックスの [Inbound Messages] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

Exchange Server アナライザは次のレジストリ エントリを読み取り、Virus Scanning API (VSAPI) メッセージ スキャンが有効になっているかどうかも判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 の場合は、VSAPI スキャンが有効になっていることを示します。値が 0 の場合、VSAPI スキャンは有効になっていません。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable VS API virus scanning] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

Exchange Server アナライザによって、以下の条件にすべて当てはまることが検出されると、警告が表示されます。

  • VSAPI スキャンが InterScan for Exchange で有効になっている

  • EnableAlert の値が 1 である

  • ActionType の値が 3 である

  • EnableEManager の値が 1 である

  • EnableWebStoreDelMail の値が 1 である

  • FileName が NULL でも空でもない

この警告は、次にスケジュールされているスキャンまたは手動によるスキャンの際に、FileName キーに列挙されている名前を持つすべての添付ファイルを削除するように InterScan が構成されていることを示します。

この警告を修正するには

  1. FileName キーに列挙されている名前の添付ファイルを削除する必要があることを確認します。

  2. 必要に応じて、添付ファイルのブロックを無効にするか、動作を "削除" から "検疫" に変更します。これにより管理者は、検疫されたファイルの、保持することが必要な場合がある添付ファイルを調査することができます。

ScanMail for Microsoft Exchange と ScanMail eManager の詳細については、Trend Micro の Web サイト (http://www.trend.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Trend Micro の InterScan が、特定のファイル拡張子を持つ添付ファイルを削除するように構成されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、いくつかのレジストリ エントリを読み取り、InterScan for Microsoft Exchange Server が添付ファイルを削除するように構成されているかどうかを判断します。レジストリの次の場所にある値が読み取られます。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption\Advance

値 | 説明
ActionType | 添付ファイルのブロックが有効になっている場合に、どの添付ファイルをブロックするかを示します。値が 0 の場合は、すべての添付ファイルがブロックされることを示します。値が 3 の場合は、管理者がファイルの拡張子、ファイル名、または正しいファイルの種類を一覧で指定済みであることを示します。この設定は、InterScan 管理コンソールの [Attachment Blocking Settings] ダイアログ ボックスで必要なオプションを選択することによって構成できます。
EnableAlert | 添付ファイルのブロックが有効になっているかどうかを示します。値が 1 の場合、添付ファイルのブロックが有効になっていることを示します。値が 0 の場合、この機能が無効になっていることを示します。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable attachment blocking] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。
Extension | 削除する添付ファイルの拡張子の一覧が含まれる、セミコロンで区切られた文字列値です。指定した添付ファイルがブロックされるようにしている場合、この設定は、InterScan 管理コンソールの [Attachment Blocking Settings] ダイアログ ボックスで、必要な拡張子を入力することによって構成できます。

HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

値 | 説明
EnableEManager | InterScan eManager が有効になっているかどうかを示します。値が 1 の場合、eManager が有効になっていることを示します。値が 0 の場合、この機能が無効になっていることを示します。この設定は、InterScan 管理コンソールの [Enable eManager] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。この設定を使用できるのは、別の関連製品である InterScan eManager がインストールされている場合だけです。
EnableWebStoreDelMail | 受信メッセージに対して InterScan アクティブ メッセージ フィルタが有効になっていることを示します。値が 1 の場合、受信メッセージに対してアクティブ メッセージ フィルタが有効になっていることを示します。値が 0 の場合、受信メッセージに対してこのフィルタが有効になっていないことを示します。この設定は、InterScan 管理コンソールの [Active Message Filter] ダイアログ ボックスの [Inbound Messages] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

Exchange Server アナライザは次のレジストリ エントリを読み取り、Virus Scanning API (VSAPI) メッセージ スキャンが有効になっているかどうかも判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 の場合は、VSAPI スキャンが有効になっていることを示します。値が 0 の場合、VSAPI スキャンは有効になっていません。この設定は、InterScan 管理コンソールの [Virus Scan] | [Options] ページの [Enable VS API virus scanning] チェック ボックスをオン (有効) またはオフ (無効) にすることによって構成できます。

Exchange Server アナライザによって、以下の条件にすべて当てはまることが検出されると、警告が表示されます。

  • VSAPI スキャンが InterScan for Exchange で有効になっている

  • EnableAlert の値が 1 である

  • ActionType の値が 3 である

  • EnableEManager の値が 1 である

  • EnableWebStoreDelMail の値が 1 である

  • Extension が NULL または空ではない

この警告は、次にスケジュールされているスキャンまたは手動によるスキャンの際に、Extension キーに列挙されている拡張子を持つすべての添付ファイルを削除するように InterScan が構成されていることを示します。

この警告を修正するには

  1. Extension キーに列挙されている拡張子を持つ添付ファイルを削除する必要があることを確認します。

  2. 必要に応じて、添付ファイルのブロックを無効にするか、動作を [Delete] から [Quarantine] に変更します。これにより管理者は、検疫されたファイルの、保持することが必要な場合がある添付ファイルを調査することができます。

ScanMail for Microsoft Exchange Server と ScanMail eManager の詳細については、Trend Micro Web サイト (http://www.trend.com) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Trend Micro の InterScan がメッセージを 2 回処理するように構成されている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、ScanMail_RealTimeScan サービスの Started キーの値を判断します。値が True の場合は InterScan_RealTimeScan サービスが開始されており、値が False の場合は InterScan_RealTimeScan サービスは開始されていません。ScanMail_RealTimeScan サービスは、Trend Micro の ScanMail for Microsoft Exchange アプリケーションのコンポーネントです。Trend Micro InterScan for Microsoft Exchange は、Exchange 用のウイルス対策機能を提供します。

さらに、Exchange Server アナライザは次のレジストリ エントリを読み込み、Enabled 値の設定を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\TransportAVAPI

Enabled の値が 1 の場合、トランスポートレベルのウイルス対策スキャン (SMTP (Simple Mail Transfer Protocol) スキャンと呼ばれることもあります) が有効になっており、値が 0 の場合は、SMTP スキャンが有効になっていません。

Exchange Server アナライザによって、Enabled が 1 に設定されており、InterScan_RealTimeScan サービスの Started キーの値が True に設定されていることが検出されると、警告が表示されます。

この警告は、この Exchange Server コンピュータを経由して配信されるメッセージは、同一のアプリケーションおよびウイルス スキャン エンジンによって 2 回スキャンされることを示しています。メッセージが Exchange Server のトランスポートおよび記憶域のコンポーネントを移動する際に同じメッセージが 2 回スキャンされることで、不必要にリソースが消費され、追加の保護や利点は提供されていません。VSAPI (Virus Scanning API) ウイルス スキャンは有効にしたまま、ScanMail 管理コンソールを使用して SMTP メール スキャンを無効にすることをお勧めします。

一般的に、メッセージング システム用に設計されたウイルス対策ソフトウェアは、SMTP ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。さらに、ユーザーのデスクトップでクライアント用のウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

この警告を修正するには

  1. InterScan 管理コンソール を起動し、ログオン資格情報を入力します。

  2. [Virus Scan] | [Options] ページの [Enable VS API virus scanning] チェック ボックスがオンになっていることを確認します。

  3. 同じページで、[Enable SMTP mail scanning] チェック ボックスをオフにします。

  4. [Apply] をクリックして変更を保存します。

  5. InterScan 管理コンソールを閉じます。

Trend Micro ScanMail for Microsoft Exchange の詳細については、Trend Micro の Web サイト (http://kb.trendmicro.com/solutions/search) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。

Exchange Server とウイルス対策ソフトウェアの併用に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 32841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)


Trend Micro の InterScan のスレッド数が少ない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、MaxScanningThreadCount の値を判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

MaxScanningThreadCount レジストリ値は、InterScan for Exchange がスキャンのために作成できるスレッドの最大数を表します。既定値は 12 です。

Exchange Server アナライザは次のレジストリ エントリを読み取り、Virus Scanning API (VSAPI) メッセージ スキャンが有効になっているかどうかも判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 の場合は、VSAPI スキャンが有効になっていることを示します。値が 0 の場合、VSAPI スキャンは有効になっていません。

Exchange Server アナライザはさらに、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NumberOfProcessors キーに設定されている値を判断します。この値は、コンピュータに搭載されているプロセッサの数を表し、物理プロセッサと論理プロセッサの両方を含んでいます。Intel のハイパースレッディング テクノロジを使用すると、物理プロセッサを 2 つの論理プロセッサに分割することができます。

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchPrivateMDB であるオブジェクトの数も判断します。これらのオブジェクトの数は、この Exchange Server コンピュータに格納されているメールボックス ストアの数を表します。

MaxScanningThreadCount の値が、VSAPI スキャンが有効になっている Exchange Server コンピュータでの計算値 (2 x プロセッサ数 + 1) + 3 + メールボックス ストアの数) より小さいことが検出されると、警告が表示されます。

注 :
ハイパースレッディングが有効な場合、NumberOfProcessors の値は物理プロセッサの数の 2 倍になります。複数の物理プロセッサを持つシステムと、物理プロセッサと論理プロセッサの両方を持つシステムには、上の式を当てはめることをお勧めします。

この警告は、MaxScanningThreadCount レジストリ値が、使用中の環境に合わせて最適化されていない可能性があることを示します。この値は少なくとも、Exchange サーバーで設定した添付ファイルのサイズ制限以上に設定する必要があります。関連するレジストリ値の詳細については、「Trend Micro の InterScan のスレッド プール数が少ない」を参照してください。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

  3. 右側のペインで、[MaxScanningThreadCount] をダブルクリックします。

  4. Exchange Server アナライザによって推奨された値を入力します。

  5. レジストリ エディタを終了し、ScanMail_RealTimeScan サービスと Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxScanningThreadCount レジストリ値の詳細については、Trend Micro のソリューション ID 13176 (http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionID=13176) を参照してください (このサイトは英語の場合があります)。

ハイパー スレッディング テクノロジの詳細については、Intel の Web サイト (http://www.intel.com/technology/hyperthread) を参照してください (このサイトは英語の場合があります)。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Trend Micro の InterScan のスレッド プール数が少ない
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、ScanningThreadPoolCount の値を判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

ScanningThreadPoolCount レジストリ値は、InterScan for Exchange サービスの開始時に初期化されて使用準備が行われるスキャン スレッドの数を表します。既定値は 12 です。開始時に作成されたすべてのスレッドが使用されると、InterScan for Exchange は、「Trend Micro の InterScan のスレッド数が少ない」で説明されている MaxScanningThreadCount レジストリ値によって制御されるスレッド数に達するまで、追加のスレッドを作成して使用します。

また、Exchange Server アナライザは次のレジストリ エントリも読み取り、VSAPI (Virus Scanning API) のメッセージ スキャンが有効になっているかどうかを判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 のときは、VSAPI のスキャンが有効になっています。この値が 0 のときは、VSAPI のスキャンが無効になっています。

Exchange Server アナライザはさらに、Win32_ComputerSystem Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、NumberOfProcessors キーに設定されている値を判断します。この値は、コンピュータに搭載されているプロセッサの数を表し、物理プロセッサと論理プロセッサの両方を含んでいます。Intel のハイパースレッディング テクノロジを使用すると、物理プロセッサを 2 つの論理プロセッサに分割することができます。

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してクエリを実行し、オブジェクト クラスが msExchPrivateMDB であるオブジェクトの数も判断します。これらのオブジェクトの数は、この Exchange Server コンピュータに格納されているメールボックス ストアの数を表します。

ScanningThreadPoolCount の値が、VSAPI スキャンが有効になっている Exchange Server コンピュータでの計算値 (2 x プロセッサ数 + 1) + 3 + メールボックス ストアの数) より小さいことが検出されると、警告が表示されます。

注 :
ハイパースレッディングが有効な場合、NumberOfProcessors の値は物理プロセッサの数の 2 倍になります。複数の物理プロセッサを持つシステムと、物理プロセッサと論理プロセッサの両方を持つシステムには、上の式を当てはめることをお勧めします。

この警告は、ScanningThreadPoolCount レジストリ値が、使用中の環境に合わせて最適化されていない可能性があることを示します。この値は、少なくとも、使用する Exchange サーバーに設定した添付ファイル サイズの制限値と同等の値にする必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\TrendMicro\ScanMail for Exchange\RealTimeScan\ScanOption

  3. 右側のペインで、[ScanningThreadPoolCount] をダブルクリックします。

  4. Exchange Server アナライザによって推奨された値を入力します。

  5. レジストリ エディタを終了し、InterScan_RealTimeScan サービスと Microsoft Exchange Information Store サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

ハイパー スレッディング テクノロジの詳細については、Intel の Web サイト (http://www.intel.com/technology/hyperthread) を参照してください。

注 :
Web アドレスは変更される場合があるため、ここで紹介した Web サイトに接続できないことがあります。


Trend Micro の InterScan がデバッグ モードになっている
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-06-22

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、ModuleName の値を判断します。

HKEY_LOCAL_MACHINE\Software\TrendMicro\ScanMail for Exchange\Tools\Debug

ModuleName レジストリ値は、使用されているデバッグ モジュール ファイルの名前を表します。

Exchange Server アナライザは次のレジストリ エントリを読み取り、Virus Scanning API (VSAPI) メッセージ スキャンが有効になっているかどうかも判断します。

HKLM\System\CurrentControlSet\Services\MSExchangeIS\VirusScan\Enabled

Enabled の値が 1 のときは、VSAPI のスキャンが有効になっています。この値が 0 のときは、VSAPI のスキャンが無効になっています。

VSAPI のスキャンが有効であり、かつ ModuleName レジストリ値が空または NULL になっていないことが検出されると、警告が表示されます。

デバッグ モードで実行すると、バックグラウンドの診断トレースが必要になるため、パフォーマンスが大幅に低下します。Exchange の InterScan をデバッグ モードで実行する必要がある問題をトラブルシューティングしている場合以外は、デバッグ モードをオフにする必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\TrendMicro\ScanMail for Exchange\Tools\Debug.

  3. 右側のペインで、[ModuleName] をダブルクリックします。

  4. このエントリの値のデータを削除し、文字列を空にします。ModuleName キーは削除しないでください。

  5. レジストリ エディタを終了し、InterScan_RealTimeScan サービスと Microsoft Exchange Information Store サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

デバッグ モードが無効になっていることを確認する方法の詳細については、Trend Micro のソリューション ID 119149 (http://esupport.trendmicro.com/support/viewxml.do?ContentID=en-119149) を参照してください。

注 :
このトピックにあるサードパーティの Web サイトは、必要な技術情報の検索に利用することを目的として用意されています。これらの URL は通知なしに変更される場合があります。


Exchange サーバーに Trend Micro のInterScan Mail Action サービスがインストールされているが、このサービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Trend Micro ScanMail for Exchange がインストールされているかどうか、および Exchange コンピュータ上で IScanMail_MailAction サービスが実行されているかどうかを判断します。

さらに、Win32_Service WMI クラスに対してクエリを実行し、Microsoft Exchange Information Store サービスの Started キーの値が True なのかそれとも False なのかをも判断します。

値が False の場合、この Exchange Server コンピュータ上で Microsoft Exchange Information Store サービスは実行されていません。値が True の場合、Microsoft Exchange Information Store サービスが実行されています。

Microsoft Exchange Information Store サービスが実行されており、Trend Micro InterScan for Exchange がインストールされているが InterScan_MailAction サービスが開始されていないことが検出されると、警告が表示されます。

Trend Micro InterScan for Exchange は、Exchange Server 用のウイルス対策機能を提供します。Trend Micro の InterScan サービスが停止しているいくつかの原因と、それらの解決方法を以下に示します。

  • Exchange サーバー上で実行しているソフトウェアが、有効期限が切れた評価版または試用版である可能性があります。この場合は、Trend InterScan の再インストールが必要になることがあります。少なくとも、継続して使用するには、そのソフトウェアをアクティブにする必要があります。

  • 管理者が誤って InterScan_MailAction サービスを停止した可能性があります。このサービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。サービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、必要に応じてシステムのウイルス駆除を行います。

メッセージング システム用に設計されたウイルス対策ソフトウェアは、一般に、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。さらに、ユーザーのデスクトップ上でクライアント用のウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

InterScan_MailAction サービスを開くには

  1. サービス MMC スナップインを開きます。

  2. [InterScan_MailAction] サービスを右クリックし、[プロパティ] をクリックします。

  3. [InterScan_MailAction のプロパティ] ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [ScanMail_MailAction] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。
  • 電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、「Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment」(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でウイルス対策ソフトウェアを使用する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


Exchange サーバーに Trend Micro の InterScan リアルタイム サービスがインストールされているが、このサービスが停止している
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Trend Micro InterScan for Microsoft Exchange がインストールされているかどうか、および Exchange Server コンピュータ上で InterScan_RealTimeScan サービスが実行されているかどうかを判断します。Trend Micro InterScan for Microsoft Exchange はインストールされているが InterScan_RealTimeScan サービスが開始されていないことが検出されると、警告が表示されます。

Trend Micro InterScan for Microsoft Exchange は、Exchange 用のウイルス対策機能を提供します。InterScan_RealTimeScan サービスの停止を引き起こす可能性があるいくつかの理由と、その解決方法を以下に示します。

  • Exchange サーバー上で実行しているソフトウェアが、有効期限が切れた評価版 (または試用版) である可能性があります。この場合は、Trend Micro InterScan for Microsoft Exchange の再インストールが必要になることがあります。少なくとも、継続して使用するには、そのソフトウェアをアクティブにする必要があります。

  • 管理者が誤って InterScan_RealTimeScan サービスを停止した可能性があります。このサービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。

  • 悪意のあるワーム、ウイルス、またはその他のプログラムによってサービスが停止された可能性があります。サービスが自動的に開始されるように設定されていることを確認し、サービスを開始します。該当するエラー イベントが発生せずにサービスが不意に停止することが続く場合は、コンピュータが悪質なワームに感染していないかどうかを確認し、必要に応じてシステムのウイルス駆除を行います。

メッセージング システム用に設計されたウイルス対策ソフトウェアは、一般に、SMTP (Simple Mail Transfer Protocol) ゲートウェイ、またはメールボックスをホストしている Exchange サーバーに展開することをお勧めします。最大限の保護を実現するには、受信 MIME メッセージをスキャンするゲートウェイでウイルス対策ソフトウェアを実行し、VSAPI (Virus Scanning API) Version 2.5 を使用する Exchange Server でウイルス検出プログラムを実行します。さらに、ユーザーのデスクトップ上でクライアント用のウイルス対策ソフトウェアを実行する必要があります。ゲートウェイまたは Exchange サーバーで、メッセージング システム用に設計されたウイルス対策ソフトウェア (MIME の解析とスキャンが可能なもの) を実行している場合、デスクトップではファイルレベルのウイルス スキャン ソフトウェアを実行すれば十分です。

InterScan_RealTimeScan サービスを開始するには

  1. [サービス] MMC スナップインを開きます。

  2. [InterScan_RealTimeScan] サービスを右クリックし、[プロパティ] をクリックします。

  3. [InterScan_RealTimeScan のプロパティ] ページの[全般] タブで、[スタートアップの種類] が [自動] に設定されていることを確認します。設定されていない場合は [自動] に設定し、[適用] をクリックします。次に、[OK] をクリックします。

  4. [InterScan_RealTimeScan] サービスを右クリックし、[開始] をクリックします。

  5. [サービス] スナップインを終了します。
  • 電子メールによって送信されるウイルスとワームの影響を受けないように Exchange 環境を強化する方法の詳細については、『Slowing and Stopping E-Mail Transmitted Viruses in an Exchange Environment』(http://go.microsoft.com/fwlink/?LinkId=47587) を参照してください (このサイトは英語の場合があります)。

Exchange Server でウイルス対策ソフトウェアを使用する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 328841「Exchange とウイルス対策ソフトウェア」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328841)

  • 文書番号 823166「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166)

  • 文書番号 306105「[XGEN] Exchange 2000 のアンチウイルス ソリューションに関するマイクロソフトの見解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=306105)

  • 文書番号 245822「[XGEN] ウイルス対策ソフトウェアがインストールされている Exchange コンピュータのトラブルシューティングに関する推奨事項」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=245822)

Exchange Server で利用できるサードパーティ製のウイルス対策ソフトウェアの一覧については、Exchange Server Partners: Antivirus Web サイト (http://go.microsoft.com/fwlink/?linkid=16226) を参照してください (このサイトは英語の場合があります)。


クライアントでサードパーティ製のアドインを無効にする
Microsoft Exchange Server アナライザ - 文書 > サードパーティ製のソフトウェア >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、以下のサードパーティ製ソフトウェアのいずれかの種類が実行されていると判断しました。

  • ウイルス対策ソフトウェア、FAX ソフトウェアなど、サード パーティ製の Microsoft Office Outlook® アドイン

  • 使用している Exchange サーバーにアクセスするサードパーティ製のアプリケーション

  • モバイル デバイス用のサードパーティ製の同期ソフトウェア

ユーザーが実行しているサードパーティ製のアプリケーションの種類を検出するか、それらのアプリケーションに対して制限を設定するか、またはアプリケーションを完全に削除するかを決定することをお勧めします。サードパーティ製のソフトウェアを実行すると、サーバー上で頻繁に過度の負荷が発生する可能性があることに注意してください。

Outlook でサードパーティ製のアドインを無効にするには

  1. Outlook で、[ツール] メニューの [オプション] をクリックします。

  2. [オプション] で、[その他] タブをクリックし、[詳細オプション] をクリックします。

  3. [詳細オプション] で、[アドイン マネージャ] をクリックします。

  4. サードパーティ製のアドインのチェック ボックスをオフにします。

  5. [OK] をクリックします。

  6. Outlook を再起動します。

詳細情報

  • Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイド (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server のパフォーマンスに関する問題のトラブルシューティングの詳細については、『Troubleshooting Microsoft Exchange Server Performance』(http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください (このサイトは英語の場合があります)。


トランスポート
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2005-11-18

このセクション内の文書には、Microsoft® Exchange Server アナライザ ツールによる Exchange トランスポート コンポーネントの評価に関する詳細が記載されています。さらに、これらの文書には、Exchange Server アナライザによって検出されたトランスポートに関連するエラー、警告、および既定以外の構成を解決するための対処法も説明されています。


8BITMIME が登録されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールは、ESMTP (EHLO Extended Simple Mail Transfer Protocol) コマンドをリモート サーバーのポート 25 に送信し、その応答を分析して、リモート サーバーが 8BITMIME ESMTP コマンドをサポートしているかどうかを判断します。

リモート サーバーから受信した応答に '250-8BITMIME' の文字が含まれていない場合、Exchange Server アナライザは警告を表示します。

Exchange Server 2003 では、Exchange 固有の拡張 SMTP コマンドを使用して、組織内で Exchange Server を実行している他のサーバーと通信します。Exchange 固有の拡張 SMTP コマンドを使用して通信する方が、標準の SMTP を使用するよりも効率的です。ESMTP コマンド セットのサポートを無効にすると、Exchange Server のパフォーマンスが低下することがあります。

このエラーは、リモート サーバーで ESMTP 8BITMIME コマンドがサポートされていないことを示します。このエラーはリモート サーバーが Exchange サーバーであるかどうかを示すものではありません。どちらの場合でも、8BITMIME 拡張機能を必要とするメッセージはルーティングされません。

この問題を修正するには、SMTP キューの内容を調べて 8BITMIME 拡張機能を必要とするメッセージがないか確認します。

これらのコマンドの既定のサポートを削除または復元する方法の詳細については、マイクロソフト サポート技術情報の文書番号 257569 の、Exchange 2000 Server および Exchange Server 2003 で ESMTP コマンドをオフにする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569) を参照してください。

Exchange Server で ESMTP コマンドを使用する方法の詳細については、Exchange Server のトランスポートおよびルーティングに関するガイドの、Exchange SMTP を正しく読み込む方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=71800) を参照してください 。


ADAM LDAP Port Identified
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-07-23

Microsoft Exchange アナライザ ツールは、次のレジストリ エントリを読み取り、エッジ トランスポート サーバー上の ADAM (Active Directory Application Mode) ディレクトリ サービスによって使用されるポートを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\EdgeTransportRole\AdamSettings\MsExchangeAdam\LdapPort

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\EdgeTransportRole\AdamSettings\MsExchangeAdam\SslPort

ADAM は、ディレクトリが有効なアプリケーションで使用するように特別に設計されたライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリ サービスです。ADAM はアプリケーション固有の情報のみを格納およびレプリケートするため、ドメイン コントローラ上に展開する必要はなく、Active Directory ディレクトリ サービスにも依存しません。ADAM は、ネットワーク オペレーティング システムの認証や承認を行いません。

Microsoft Exchange Server 2007 で、エッジ トランスポート サーバーの役割は、ADAM を使用してコンテンツ フィルタ用の構成情報および受信者データを格納します。ADAM を Active Directory と同期させた場合は、ADAM を使用して、メッセージ セキュリティのために受信者参照を実行することもできます。

Active Directory から ADAM にデータが送信されるとき、データは次の既定以外のポート経由で LDAP 接続を使用して送信されます。

  • LDAP: ポート 50389/TCP

  • Secure LDAP: ポート 50636/UDP

Exchange アナライザによって ADAM により使用されるポートが識別されると、ベスト プラクティス メッセージが表示されます。

ベスト プラクティスとして、外部アクセスへの不要なポートはすべてブロックすることをお勧めします。

この問題に対処するには、Exchange アナライザによって識別されるポートが ADAM 用であって、外部アクセスに対して開かれていないことを確認します。

注意 :
ポート 50636/UDP は、Exchange EdgeSync サービスに使用され、EdgeSync 機能が必要な場合は開いたままにしておく必要があります。
識別された外部アクセスへの ADAM ポートを Windows ファイアウォールを使用してブロックするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「firewall.cpl」と入力し、[OK] をクリックします。

  2. [例外] タブをクリックします。

  3. [名前] ボックスに一覧表示されている各プログラムまたはサービスを選択し、[編集] をクリックして、開かれているポートを確認します。

  4. Exchange アナライザによって ADAM 用に使用されたと報告されたポートが一覧に表示されていないことを確認します。

  5. 識別されたポートが一覧に表示されている場合は、他の必要な通信に使用されていないことを確認し、[サービスの編集] ウィンドウで選択を解除してポートを閉じます。

  6. [OK] を 2 回クリックして、Windows ファイアウォールの構成を終了します。

詳細情報

Exchange 2007 によって使用されるすべてのデータ パス用のポート、認証、および暗号化の詳細については、「データ パス セキュリティ リファレンス」(http://go.microsoft.com/fwlink/?LinkId=95630) を参照してください (このサイトは英語の場合があります)。


ウイルス対策プラグインがインストールされている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリをスキャンして、Symantec Antivirus Corporate Edition 9.x Internet E-Mail Auto Protect プラグインがインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail

このレジストリ ブランチが存在する場合、Exchange Server を実行しているサーバーに Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインがインストールされていることを示します。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインが有効になっているかどうかも判断します。

HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail\RealTimeScan\OnOff

OnOff の値が 1 の場合、Auto-Protect プラグインが有効になっていることを示します。値が 0 の場合、Auto-Protect プラグインが有効になっていないことを示します。

以下の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインがインストールされている。

  • Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインが有効になっていない。

この警告は、ベンダが推奨する最新のベスト プラクティスと照らし合わせて、プラグインのインストールと設定を見直す必要があることを示します。

このプラグインに関してベンダが推奨するベスト プラクティスの詳細については、Microsoft Exchange サーバーで Symantec AntiVirus Corporate Edition 9.x の Auto-Protect を使用する際のベスト プラクティスについてのページ (英語ページの可能性があります) (http://service1.symantec.com/SUPPORT/ent-security.nsf/c9b1ac1936fbf63488256e77006521df/3d1bcbc855fce10288256e9e007e01f0?OpenDocument&src=bar_sch_nam) を参照してください。

注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


ウイルス対策プラグインが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリをスキャンして、Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインがインストールされているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail

このレジストリ エントリが存在する場合、Exchange Server を実行しているサーバーに Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインがインストールされていることを示します。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインが有効になっているかどうかも判断します。

HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\Snap-In\InternetMail\RealTimeScan\OnOff

OnOff の値が 1 の場合、Auto-Protect プラグインが有効になっていることを示します。値が 0 の場合、Auto-Protect プラグインが有効になっていないことを示します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインがインストールされている。

  • Symantec Antivirus Corporate Edition 9.x のインターネット電子メール Auto-Protect プラグインが有効になっている。

このエラーは、ベンダが推奨する最新のベスト プラクティスと照らし合わせて、プラグインのインストールと設定を見直す必要があることを示します。

このプラグインに関してベンダが推奨するベスト プラクティスの詳細については、Microsoft Exchange サーバーで Symantec AntiVirus Corporate Edition 9.x の Auto-Protect を使用する際のベスト プラクティスについてのページ (英語ページの可能性があります) (http://service1.symantec.com/SUPPORT/ent-security.nsf/c9b1ac1936fbf63488256e77006521df/3d1bcbc855fce10288256e9e007e01f0?OpenDocument&src=bar_sch_nam) を参照してください。

注 :
このトピックにあるサードパーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


BCC の履歴保持が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、BCC の履歴保持が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\JournalBCC

JournalBCC の値が 1 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

BCC の履歴保持は、BCC 受信者の取得機能が追加された、メッセージのみの履歴保持です。BCC の履歴保持が有効になっている場合、Exchange Server は BCC 受信者を含め、発信元のサーバーで既知であるすべての受信者を取得します。この受信者一覧に、隠し配布グループ、クエリベース配布グループ、または別のサーバーで展開された配布グループが含まれていると、これらのグループの受信者は履歴を保持するメールに含まれません。

BCC の履歴保持機能は、レジストリ キーを設定することにより有効になります。このレジストリ キーの設定方法の詳細については、Microsoft サポート技術情報の文書番号 810999「XADM: BCC 情報は、in exchange 2000 journaled メッセージに対する失われます。」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=810999) を参照してください。

特定のサーバーで BCC の履歴保持を有効にするには、最初にメッセージのみの履歴保持を構成する必要があります。以下の条件に当てはまる場合、JournalBCC 設定は有効になっていません。

  • JournalBCC レジストリが 1 に設定されている。

  • メッセージのみの履歴保持が、同じサーバー上のどのデータベースでも有効になっていない。

メッセージの履歴保持によって、ディスク、ネットワーク、CPU リソースなどの消費が増える場合があります。このため、履歴を保持する際は十分な展開計画が必要です。履歴の保持は、総合的な履歴保持のソリューション フレームワークを展開するケースにおいてのみ有効にしてください。

以下の条件に当てはまる場合は、既定以外の構成を示すこのメッセージを無視してかまいません。

  • 業務上、履歴の保持が必要である。

  • 履歴保持のソリューション フレームワークを既に展開している。

これらの状況に該当しない場合は、履歴保持機能を無効にする必要があります。データベースで履歴保持を無効にすると、履歴保持は無効になります。

データベースでメッセージのみの履歴保持を無効にするには

  1. Exchange システム マネージャで [サーバー] を展開し、[<使用している Exchange サーバー>]を展開します。次に、[<ストレージ グループ>] を展開し、メールボックス ストアを右クリックします。

  2. [全般] タブで、[このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] チェック ボックスをオフにします。

  3. Exchange ストアに変更が適用されるまで 15 分待ちます。Microsoft Exchange Information Store サービスを再開する必要はありません。

Exchange Server アナライザによって再度このメッセージが表示されないようにするには、JournalBCC レジストリ キーを削除する必要があります。履歴保持機能を無効にするために、JournalBCC レジストリ キーを削除する必要はありません。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
JournalBCC レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\

  3. 右側のペインで、JournalBCC 値を見つけて削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

履歴保持ソリューションの展開の詳細については、『Journaling with Exchange Server』(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


BDAT が登録されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールは、ESMTP (EHLO Extended Simple Mail Transfer Protocol) コマンドをリモート サーバーのポート 25 に送信し、応答を分析して、リモート サーバーが BDAT ESMTP コマンドをサポートしているかどうかを判断します。

Exchange Server アナライザが取得不能エラーを示す文字列を持つ応答をリモート サーバーから受信すると、Exchange Server アナライザはエラーを表示します。

Exchange Server 2003 では、Exchange 固有の拡張 SMTP コマンドを使用して、組織内で Exchange Server を実行している他のサーバーと通信します。Exchange 固有の拡張 SMTP コマンドを使用して通信する方が、標準の SMTP を使用するよりも効率的です。ESMTP コマンド セットのサポートを無効にすると、Exchange Server のパフォーマンスが低下することがあります。

このエラーは、リモート サーバーで ESMTP BDAT コマンドがサポートされていないことを示します。このエラーはリモート サーバーが Exchange サーバーであるかどうかを示すものではありません。どちらの場合でも、BDAT 拡張機能を必要とするメッセージはルーティングされません。

この問題を修正するには、SMTP キューの内容を調べて SMTP 拡張機能を必要とするメッセージがないか確認します。

これらのコマンドの既定のサポートを削除または復元する方法の詳細については、マイクロソフト サポート技術情報の文書番号 257569 の、Exchange 2000 Server および Exchange Server 2003 で ESMTP コマンドをオフにする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569) を参照してください。

Exchange Server で ESMTP コマンドを使用する方法の詳細については、Exchange Server のトランスポートおよびルーティングに関するガイドの、Exchange SMTP を正しく読み込む方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=71800) を参照してください 。


配布グループの RGC に対する配信制限をチェックするブリッジヘッド サーバー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-18

Microsoft® Exchange Server アナライザは、Active Directory® ディレクトリ サービスで検出された各ルーティング グループ コネクタ オブジェクト (msExchRoutingGroupConnector) の次の属性に対してクエリを実行し、配布グループ メンバシップに基づいた配信の制限が設定されているかどうかを判断します。

dLMemRejectPerms | このルーティング グループ コネクタ経由の送信を許可されていないメンバの配布リスト (DL) のドメイン名 (DN) が含まれています。
dLMemSubmitPerms | このルーティング グループ コネクタ経由の送信を許可されていないメンバの配布リスト (DL) の DN が含まれています。

Exchange Server アナライザは、配布グループ メンバシップに基づいた配信の制限が設定されたルーティング グループ コネクタを検出すると、検出したルーティング グループ コネクタの msExchSourceBridgeheadServersDN 属性に対してクエリを実行し、分析対象のサーバーがそれらのコネクタのいずれかのブリッジヘッド サーバーとして設定されているかどうかを判断します。

さらに、Exchange Server アナライザは、次のレジストリ キーを読み取り、CheckConnectorRestrictions レジストリの値が存在し、構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

以下の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • ルーティング グループ コネクタが、配布グループ メンバシップに基づいた配信の制限に使用されている。

  • 分析対象の Exchange サーバーが、そのルーティング グループ コネクタのブリッジヘッド サーバーとして指定されており、配布グループの展開を行う役割を担っている。

  • CheckConnectorRestrictions キーが存在し、1 に設定されているため、有効になっている。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

ルーティング グループを作成するときに、互いに直接通信できるサーバーのグループを指定します。異なるルーティング グループにあるサーバー間で互いに通信するためには、ルーティング グループを接続する必要があります。

ルーティング グループ コネクタはルーティング グループの接続を目的として設計されているため、このコネクタを使用することをお勧めします。

ルーティング グループ コネクタを介してメールを送信できるサーバーがブリッジヘッド サーバーです。ブリッジヘッド サーバーは、SMTP (Simple Mail Transfer Protocol) 仮想サーバーと、コネクタを経由するすべてのメッセージの配信を行う Exchange サーバーを組み合わせたものです。

ルーティング グループ コネクタを作成するときに、すべてのサーバーをそのコネクタのブリッジヘッド サーバーとするか、または選択したサーバー セットのみがそのコネクタのブリッジヘッド サーバーとして機能するように指定するかを選択できます。指定されたブリッジヘッドが、配布グループ メンバシップの展開を行うサーバーになります。

配布グループ メンバシップに基づいた配信制限が設定されているルーティング グループ コネクタを使用してメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

この警告は、配布グループ メンバシップに基づいた配信制限が設定されているため、カテゴライザが制限を確認するときにブリッジヘッド宛のメッセージがキューに入れられる可能性があることを示します。

この警告に対処するには、次の操作を行います。

  • ルーティング グループ コネクタをローカル ルーティング グループに構成します。その方法については、マイクロソフト サポート技術情報の文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • コネクタ用に指定するブリッジヘッド サーバーとして、専用の、より堅牢性の高いグローバル カタログ サーバーを使用します。

  • マイクロソフト サポート技術情報の文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • SMTP 送信者フィルタの実装を検討します。

  • Microsoft Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange 2003 SP2 より前のバージョンの Exchange を実行するサーバーでは、Exchange 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

SMTP 送信者フィルタの詳細については、Exchange Server 2003 の管理ガイドの、送信者フィルタを有効にする方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=71832) を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • 文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。


ブリッジヘッド サーバーが、SMTP コネクタに対して配布グループによる配信制限を確認する
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出された各 SMTP (Simple Mail Transfer Protocol) コネクタ オブジェクト (msExchRoutingSMTPConnector) の次の属性に対してクエリを実行し、配布グループ メンバシップに基づいた配信制限が設定されているかどうかを判断します。

dLMemRejectPerms | この SMTP コネクタ経由の送信を許可されていないメンバの配布リスト (DL) のドメイン名 (DN) が含まれています。
dLMemSubmitPerms | この SMTP コネクタ経由の送信を許可されていないメンバの配布リスト (DL) の DN が含まれています。

Exchange Server アナライザは、配布グループ メンバシップに基づいた配信の制限が設定された SMTP コネクタを検出すると、検出した SMTP コネクタの msExchSourceBridgeheadServersDN 属性に対してクエリを実行し、分析対象のサーバーがそれらのコネクタのいずれかのブリッジヘッド サーバーとして設定されているかどうかを判断します。

さらに、Exchange Server アナライザは、次のレジストリ キーを読み取り、CheckConnectorRestrictions レジストリの値が存在し、構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

以下の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • SMTP コネクタが、配布グループ メンバシップに基づいた配信の制限に使用されている。

  • 分析対象の Exchange サーバーが、その SMTP コネクタのブリッジヘッド サーバーとして指定されており、配布グループの展開を行う役割を担っている。

  • CheckConnectorRestrictions キーが存在し、1 に設定されているため、有効になっている。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

配布グループからのメッセージを受信または拒否するコネクタを使用してメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

指定されたブリッジヘッドが、配布グループ メンバシップの展開を行うサーバーになります。

制限の確認処理は CheckConnectorRestrictions レジストリの値により制御されます。この値は、確認の対象となるコネクタのソースとなっている Exchange ブリッジヘッド サーバーで設定する必要があります。制限を指定しても、CheckConnectorRestrictions レジストリの値を作成しないと、制限の確認は行われません。

既定では、コネクタの制限は無効になっています。システムを通過するメッセージごとに配布グループの展開と制限の確認を行うと、システム パフォーマンスに大きく影響します。

この警告は、配布グループ メンバシップに基づいた配信制限が設定されているため、カテゴライザが制限を確認するときにブリッジヘッド宛のメッセージがキューに入れられる可能性があることを示します。

この警告に対処するには、次の操作を行います。

  • コネクタ制限専用のルーティング グループを設計し、ローカル ルーティング グループとして構成します。その方法については、マイクロソフト サポート技術情報の文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • コネクタ用に指定するブリッジヘッド サーバーとして、専用の、より堅牢性の高いグローバル カタログ サーバーを使用します。

  • マイクロソフト サポート技術情報の文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • SMTP 送信者フィルタの実装を検討します。

  • Microsoft Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange 2003 SP2 より前のバージョンの Exchange を実行するサーバーでは、Exchange 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

SMTP 送信者フィルタの詳細については、Exchange Server 2003 の管理ガイドの、送信者フィルタを有効にする方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=71832) を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • 文書番号 895407 の Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。


ポート 25 でルーティング マスタに接続できない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-24

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、現在の管理グループ内の各ルーティング グループの msExchRoutingMasterDN 属性値を判断します。次に、Exchange Server アナライザは TCP ポート 25 上のルーティング マスタへのソケット接続を開こうと試みます。予期されるカスタム応答である 25 Available が返されなかった場合は、エラーが表示されます。

このエラーは、TCP ポート 25 上のルーティング マスタにアクセスできずに、ルーティング障害が発生した可能性があることを示しています。このエラーを修正するには、ルーティング マスタに関する接続の問題のトラブルシューティングを行うか、または新しいルーティング マスタを割り当てます。

ルーティング マスタに関する接続の問題のトラブルシューティングを行うには

  1. ルーティング マスタ自体からポート 25 への telnet 接続が可能ですか。これが可能でない場合、問題はネットワークに関するものではありません。

  2. すべてのケーブルが正しく接続されていますか。すべてのハードウェアが正しく機能していますか。

  3. DNS は動作していて、正しく構成されていますか。

  4. ルーターは正しく機能していますか。

  5. 接続を妨げているファイアウォールまたはアプリケーションはありませんか。
新しいルーティング マスタを割り当てるには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインでツリーの一番上にある [組織名 (Exchange)] アイコン (組織名は Exchange 2000 組織として選択した名前) を右クリックし、[プロパティ] をクリックします。

  3. [管理グループを表示する]、[ルーティング グループを表示する]、[OK] の順にクリックします。

  4. [管理グループ] を展開し、[<管理グループ>] を展開します。次に、[ルーティング グループ] を展開します。

  5. ルーティング グループを展開し、[メンバ] をクリックします。

  6. 右側のペインで、ルーティング グループ マスタとして構成する Exchange コンピュータを右クリックし、[マスタに設定] をクリックします。

ルーティングのトラブルシューティング、ルーティング トポロジの構成、および高度なルーティングの概念の詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Troubleshooting Routing」を参照してください (このサイトは英語の場合があります)。


ポート 691 上のルーティング マスタに接続できない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-24

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、現在の管理グループ内の各ルーティング グループの msExchRoutingMasterDN 属性の値を判断します。次に、Exchange Server アナライザは TCP ポート 691 上のルーティング マスタへのソケット接続を開こうとします。予期されたカスタム応答である "691 Available" が返されない場合は、エラーが表示されます。

このエラーは、TCP ポート 691 上のルーティング マスタにアクセスできずに、ルーティング障害が発生した可能性があることを示しています。このエラーを修正するには、ルーティング マスタに関する接続の問題のトラブルシューティングを行うか、または新しいルーティング マスタを割り当てます。

ルーティング マスタに関する接続の問題のトラブルシューティングを行うには

  1. ルーティング マスタ自体からポート 691 への telnet 接続が可能ですか。これが可能でない場合、問題はネットワークに関するものではありません。

  2. すべてのケーブルが正しく接続されていますか。すべてのハードウェアが正しく機能していますか。

  3. DNS は動作していて、正しく構成されていますか。

  4. ルーターは正しく機能していますか。

  5. 接続を妨げているファイアウォールはありませんか。
新しいルーティング マスタを割り当てるには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインでツリーの一番上にある [組織名 (Exchange)] アイコン (組織名は Exchange 2000 組織として選択した名前) を右クリックし、[プロパティ] をクリックします。

  3. [管理グループを表示する]、[ルーティング グループを表示する]、[OK] の順にクリックします。

  4. [管理グループ] を展開し、[<管理グループ>] を展開します。次に、[ルーティング グループ] を展開します。

  5. ルーティング グループを展開し、[メンバ] をクリックします。

  6. 右側のペインで、ルーティング グループ マスタとして構成する Exchange コンピュータを右クリックし、[マスタに設定] をクリックします。

ルーティングのトラブルシューティング、ルーティング トポロジの構成、ルーティングの概念などの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Troubleshooting Routing」を参照してください (このサイトは英語の場合があります)。


'ホスト' レコードまたは 'MX' レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-05-10

Microsoft Exchange アナライザ ツールは、ドメイン ネーム システム (DNS) 参照を実行し、ドメイン用の MX (Mail Exchanger) レコードを取得します。Exchange アナライザが DNS サーバーからドメイン用の MX レコードを取得できない場合は、再度 DNS 参照を試み、Exchange サーバーがメッセージを送信しようとしているドメインのホスト (A) レコードを取得します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • Exchange アナライザがドメイン用の MX レコードを取得できない。

  • DNS 参照操作で、いずれのホスト (A) レコードの IP アドレスも返されない。

このエラーは、ドメインおよびサーバーの DNS MX (Mail Exchanger) レコードとホスト (A) レコードが存在しないように見えることを示します。このエラーにより、他のメッセージのルーティングやサービスに遅延が発生するのに加え、リモート ドメイン宛のメッセージが Exchange サーバーのリモート配信キューにバックアップされることがあります。

送信 Exchange サーバーは、メール ホストを確認するために MX レコードをチェックします。次に、アドレス レコード (A レコード) をチェックして、MX レコードを IP アドレスに解決します。

以下の理由によって、MX (Mail Exchanger) レコードおよびホスト (A) レコードの DNS 参照が失敗することがあります。

  • ネットワーク障害やその他の原因により DNS サーバーが停止しているか、または DNS サーバーに到達できない。

  • リモート サーバーのホスト (A) レコードが使用できないか、または正しくないため、DNS サーバーから見つからない。

  • DNS サーバーが動的なホスト レコードの更新を有効にするように構成されていない。

  • 発信元のドメインを偽装している可能性があるスパム メッセージに応答して、システムが配信不能レポート (NDR) を送信しようとしている。この場合は、これらのメッセージを削除する必要があります。この文書の「詳細情報」セクションにある、Exchange Server の不正メールの削除およびアーカイブ ツールに関するリンク先を参照してください。

DNS サーバーがオンラインになっていて、MX レコードおよびホスト レコードが存在することを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、MX (Mail Exchanger) レコードが正しく構成されていることを確認します。詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Nslookup を使用して MX レコードの構成を確認する方法に関するセクションを参照してください (このサイトは英語の場合があります)。

  3. nslookup を使用して、DNS サーバーにホスト (A) レコードが存在することを確認します。詳細については、DNS に A リソース レコードが存在することを確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63001) を参照してください (このサイトは英語の場合があります)。

  4. ホスト (A) リソース レコードが存在しない場合、A リソース レコードを手動で追加または変更するか、または動的なレコードの更新を有効するように DNS サーバーを構成します。

    • A リソース レコードを手動で追加します。詳細については、DNS ゾーンにリソース レコードを追加する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください (このサイトは英語の場合があります)。

    • A リソース レコードを手動で変更します。既存のリソース レコードを変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63014) を参照してください (このサイトは英語の場合があります)。

    • 動的なホスト レコードの更新を有効するように DNS サーバーを構成します。詳細については、Microsoft サポート技術情報の文書番号 816592「Windows Server 2003 で DNS 動的更新を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592) を参照してください。

詳細情報

  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Exchange Server 2003 の転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS をトラブルシューティングする方法の詳細については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 のシステム モニタについては、Exchange Server 2003 Management Pack for MOM 2005 についてのページ (http://go.microsoft.com/fwlink/?LinkId=47573) の、Exchange Management Pack を使用したシステム モニタに関するトピックを参照してください (このサイトは英語の場合があります)。

  • ホスト (A) リソース レコードについては、リソース レコードの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63004) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server での不正メール削除およびアーカイブの詳細については、Exchange Server の不正メール削除およびアーカイブについてのページ (http://go.microsoft.com/fwlink/?LinkId=84239) を参照してください (このサイトは英語の場合があります)。


送信者を識別できない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-08

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの proxyAddress 属性値に対してクエリを実行し、すべてのユーザー オブジェクトがユーザー指定のローカル送信者の SMTP (Simple Mail Transfer Protocol) アドレスと一致するかどうかを判断します。

proxyAddress がユーザー指定のローカル送信者の SMTP アドレスと一致することを検出できない場合、Exchange Server アナライザはエラーを表示します。

このエラーは、以下の条件のいずれかに当てはまることを示します。

  • ローカル Exchange Server 組織にローカル送信者が存在しない。

  • ユーザー指定のローカル送信者の SMTP アドレスが誤って入力された。

このエラーを解決するには、指定したローカル送信者の SMTP アドレスを確認し、操作を再試行します。

ローカル送信者のアドレスを確認するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開し、次に [すべてのグローバル アドレス一覧] を展開します。

  3. [既定のグローバル アドレス一覧] を右クリックし、[プロパティ] を選択します。

  4. [プレビュー] をクリックし、既定のグローバル アドレス一覧に含まれる受信者の SMTP アドレスを表示します。

  5. 指定したローカル送信者が表示されていることを確認し、SMTP アドレスを書き留めます。


CatDbgSink イベント シンクがインストールされている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの LM/SmtpSvc/%SMTPINSTANCE%/EventManager/EventTypes プロパティのデータを読み取り、Exchange 2000 Server または Exchange Server 2003 が実行されているコンピュータに CatDbgSink メール フロー診断アプリケーションがインストールされているかどうかを判断します。

CatDbgSink アプリケーションは、Exchange 2000 Server または Exchange Server 2003 が実行されているコンピュータでメール フローの問題をトラブルシューティングする際に使用できるイベント シンクです。Exchange サーバーに CatDbgSink アプリケーションがインストールされている場合は、Exchange Server アナライザによって、CatDbgSink アプリケーションがインストールされていること、およびこのアプリケーションの使用はメール フローの問題をトラブルシューティングする場合だけにする必要があることを通知する警告が表示されます。

CatDbgSink アプリケーションは一般に、Exchange 2000 Server および Exchange Server 2003 コンピュータの両方でメール フローの問題をトラブルシューティングするために顧客に送付されます。CatDbgSink アプリケーションは通常、Microsoft 製品サポート サービス (PSS) の指示に基づいてインストールされます。CatDbgSink アプリケーションをインストールして正しく登録すると、顧客は CatDbgSink アプリケーションを使用して、Exchange サーバーでのメール フローの問題に関するトラブルシューティング情報を収集するためのログ ファイルを作成できるようになります。

場合によっては、1 つまたは複数の問題を分離し、解決した後でも、運用環境の Exchange サーバーから CatDbgSink アプリケーションを削除できないことがあります。CatDbgSink アプリケーションが Exchange コンピュータから削除されないと、CatDbgSink アプリケーションによって大きな負荷が発生し、そのために Exchange サーバーで望ましくないパフォーマンスの問題が発生します。運用環境の Exchange サーバーでメール フローの問題を診断し終えたら、CatDbgSink アプリケーションを削除する必要があります。

この警告を修正するには

  1. ローカルの CatDbgSink インストール フォルダを見つけます。このフォルダには、Setup.vbs、CatDbgSink.dll、CatDbgSink.pdb、および MustReadMe.txt のセットアップ ファイルが含まれています。

  2. コマンド プロンプト ウィンドウから、セットアップ ファイルのローカル ドライブの場所 (たとえば、C:\CatDbgSink) にディレクトリを変更します。

  3. コマンド プロンプトで、「cscript setup.vbs uninstall 1 」と入力します。
注 :
コマンド ラインの 1 という数字は、1 から始まる SMTP 仮想サーバー インスタンスを示しています。

CatDbgSink アプリケーションの詳細については、Microsoft 製品サポート サービス (http://support.microsoft.com/default.aspx?pr=cntactms) に問い合わせてください。


SMTP インスタンスのカテゴライザが無効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの LM/SmtpSvc/%SMTPInstance%/RoutingSources プロパティのデータを読み取り、Exchange 2000 Server または Exchange Server 2003 が実行されているコンピュータ上の各 SMTP 仮想サーバー インスタンス (VSI) のメッセージ カテゴライザの状態を判断します。

Exchange Server アナライザ は、IIS メタベースに SMTPDSUseCat キーが存在するかどうかを判断し、その結果を報告します。SMTPDSUseCat が存在し、無効 (0X000000) に設定されていることが検出されると、エラーが表示されます。メッセージ カテゴライザが無効になっている場合は、Exchange サーバーで重大なメール フローの問題が発生します。

既定では、Microsoft Windows®°2000 Server または Microsoft Windows Server™ 2003 が実行されているコンピュータに SMTP サービスがインストールされると、IIS メタベース内に SMTPDSUseCat キーが作成されます。既定では、SMTPDSUseCat キーは無効 (0) になっています。Exchange Server がインストールされると、SMTPDSUseCat IIS メタベース キーは削除されます。これにより、メッセージ カテゴライザが有効になります。Windows 2000 Server または Windows Server 2003 が実行されているコンピュータに SMTP サービスまたは Exchange Server がインストールされると、既定の (1 つの) STMP VSI が作成されます。コンピュータに Exchange Server がインストールされている状態で、SMTP サービスがアンインストールされ、次に再インストールされると、メッセージ カテゴライザが無効になる場合があります。メッセージ カテゴライザは、サードパーティ製のソフトウェアがインストールされるか、または管理構成エラーが発生した場合にも無効になることがあります。

注 :
Exchange サーバー上の各 SMTP 仮想サーバー インスタンスは、メッセージ カテゴライザの状態を個別に制御します。

メッセージ カテゴライザは、各 SMTP VSI に送信されたすべてのメッセージを調査し、そのオプションを判断します。メッセージの宛先は、ローカル ストアや、メッセージ転送エージェント (MTA) 経由のリモート ホスト、または SMTP 経由のリモート ホストである可能性があります。メッセージ カテゴライザはまた、配布リスト (DL) の拡張も処理します。メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージ カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを TCP ポート 3268 で実行する、アドバンスド キュー エンジンへのプラグインです。メッセージ カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。

注 :
SMTP 再インストール ツール (Smtpreinstall.exe) は、Exchange 2000 Server SP2 CD-ROM の \SUPPORT\UTILS\I386 フォルダに収録されています。
SMTP 再インストール ツールを使用してメッセージ カテゴライザを有効にするには

  1. Smtpreinstall.exe を \Exchsrvr\Bin フォルダにコピーします。

  2. \Exchsrvr\Bin フォルダの Smtpreinstall.exe をダブルクリックします。

  3. [Microsoft Exchange SMTP Reinstall] ダイアログボックスで、[OK] をクリックして Exchange サーバーを再起動します。

IIS メタベース内のプロパティを表示する必要がある場合は、IIS 4.0/5.0 では Metaedit 2.2 ユーティリティ、IIS 6.0 では IIS Metabase Explorer ユーティリティをインストールすれば表示できます。

注意 :
メタベースを直接編集することはお勧めできません。

メッセージ カテゴライザまたは使用可能な IIS メタベース ユーティリティの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 290290「[XIMS] IIS SMTP サービスの再インストール後にメールを送信できない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=290290)

  • 文書番号 319885「[XCON] Exchange 2000 Server 組織内で送信されたメッセージが配信されない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319885)

  • 文書番号 231729「[XCON] DSUseCat キーとメッセージ カテゴライザ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231729)

  • 文書番号 232068「[HOWTO] IIS MetaEdit 2.2 ユーティリティをダウンロード、インストール、およびアンインストールする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232068)

IIS 6.0 リソース キット ツールをダウンロードするには、「Internet Information Services (IIS) 6.0 Resource Kit Tools」(http://go.microsoft.com/fwlink/?LinkId=33134) を参照してください (このサイトは英語の場合があります)。


カテゴライザの警告イベント (ID: 6004) が過去 24 時間以内にログに記録されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-05

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) クラスに対してクエリを実行し、MSExchangeTransport のイベント 6004 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

MSExchangeTransport のイベント 6004 警告が過去 24 時間以内にログに記録されていることが検出されると、警告が表示されます。

この警告は、カテゴライザでメッセージを処理しようとしたときにエラーが発生したことを示します。

メッセージ カテゴライザは、SMTP (Simple Mail Transfer Protocol) サーバーに到着したメッセージを調査し、メッセージの処理方法を判断します。メッセージの宛先は、ローカル インフォメーション ストア、メッセージ転送エージェント (MTA) の使用によるリモート ホスト、または、SMTP の使用によるリモート ホストである可能性があります。カテゴライザは、配布リストの展開も処理します。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを TCP ポート 3268 で実行する、アドバンスド キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザは、アドレス解決とメール転送の実行、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行います。また、カテゴライザは、他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージがメッセージ カテゴライザに入ると、カテゴライザは直ちに Active Directory® ディレクトリ サービスのプロキシ アドレス属性に含まれているアドレスを検索し、エンベロープ送信者を解決します。また、カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索して、エンベロープ受信者も解決します。たとえば、一覧に配布リストが含まれている場合、そのサーバーで配布リストの展開が許可されていれば配布リストを展開し、それらのメンバを含めます。

Possible causes of MSExchangeTransport 警告イベント 6004 には、次のことが含まれます。

  • ディレクトリ サービス アクセス (DSAccess) に関する問題

  • ディレクトリのレプリケーションの待ち時間または障害

  • グローバル カタログ サーバーの過負荷

  • DNS に関する問題

この警告に対処するには、次の操作を行います。

  • Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。これには、Windows のネットワーク モニタ ツールを使用すると便利です。

  • 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN に、配信不能レポート (NDR) を含めることができます。DSN には、永続的な配信エラー メッセージと、最終的に永続的な配信エラーとなることが多い一時的なエラー メッセージが記載されています。

  • メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  • Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  • システム モニタ を使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージ センターのページ (http://go.microsoft.com/fwlink/?LinkId=34258) (英語) を参照してください。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、マイクロソフト サポート技術情報の文書番号 284204 の、Exchange Server および Small Business Server における配信状態通知についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server のメッセージ追跡センターの使用方法の詳細については、マイクロソフト サポート技術情報の次の記事を参照してください。

  • 文書番号 262162 の、[XADM] メッセージ追跡センターを使用したメッセージの追跡についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856 の、[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905 の、Exchange Server 2003 のメッセージ追跡イベント ID についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864 の、Exchange Server 2003 の強化されたメッセージ追跡機能についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題をトラブルシューティングする方法の詳細については、Help and Support のメッセージ カテゴライザと NDR トラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798 の、[XCON] Exchange 2000 Service Pack 2 での Archive Sink ユーティリティの利用についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題をトラブルシューティングする方法に関する一般的な情報については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 821910 の、Exchange Server 2003 トランスポート問題のトラブルシューティング方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265 の、Exchange 2000 Server および Exchange Server 2003 でのトランスポートに関する問題の一般的なトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

  • 文書番号 895853 の、Exchange Server 2003 と Exchange 2000 Server でのメール中継に関する問題のトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853)

  • Exchange Server トランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkID=67875) (英語)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連する利用可能なパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734 の [XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。


カテゴライザの警告イベント (ID: 6006) が過去 24 時間以内にログに記録されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) クラスに対してクエリを実行し、MSExchangeTransport のイベント 6006 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

MSExchangeTransport のイベント 6006 警告が過去 24 時間以内にログに記録されていることが検出されると、警告が表示されます。

この警告は、メッセージがメッセージ カテゴライザにトラップされていることを示します。

メッセージ カテゴライザは、SMTP (Simple Mail Transfer Protocol) サーバーに到着したメッセージを調査し、メッセージの処理方法を判断します。メッセージの宛先は、ローカル インフォメーション ストア、メッセージ転送エージェント (MTA) の使用によるリモート ホスト、または、SMTP の使用によるリモート ホストである可能性があります。カテゴライザは、配布リストの展開も処理します。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを TCP ポート 3268 で実行する、アドバンスド キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザは、アドレス解決とメール転送の実行、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行います。また、カテゴライザは、他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージがメッセージ カテゴライザに入ると、カテゴライザは直ちに Active Directory® ディレクトリ サービスのプロキシ アドレス属性に含まれているアドレスを検索し、エンベロープ送信者を解決します。また、カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索して、エンベロープ受信者も解決します。たとえば、一覧に配布リストが含まれている場合、そのサーバーで配布リストの展開が許可されていれば配布リストを展開し、それらのメンバを含めます。

Possible causes of MSExchangeTransport 警告イベント 6006 には、次のことが含まれます。

  • 古いウイルス対策ソフトウェアが構成されているか、誤って構成されている。

  • 配布グループが過度に展開されている。

  • 履歴保持用の受信者が誤って構成されている。

  • Active Directory の Exchange オブジェクトに対するアクセス許可が誤って構成されている。

この警告に対処するには、次の操作を行います。

  • 特定の Exchange Server のディレクトリを除外するように 5 段階のウイルス対策アプリケーションを正しく構成していることを確認します。Microsoft Exchange Server を実行しているサーバーをスキャンする場合に、スキャン対象から除外する必要のあるフォルダの説明については、Microsoft サポート技術情報の文書番号 823166 の、Exchange Server 2003 とウイルス対策ソフトウェアの概要についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823166) を参照してください。

  • 最新バージョンのウイルス対策アプリケーション ソフトウェアを実行していることを確認します。

  • 配布グループによる配信の制限の設定を調べて、不要な制限を削除します。

  • 構成が誤っている可能性がないか、履歴保持の設定を調べます。

  • Active Directory の Exchange オブジェクトに対するアクセス許可が誤って構成されていないかを調べます。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスおよび外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)

  • 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)

  • 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)

履歴保持ソリューションを展開する方法の詳細については、Exchange Server における履歴保持についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) (英語) を参照してください。

カテゴライザの警告イベント ID 6006 の考えられる原因の詳細については、Microsoft サポート技術情報の文書番号 922256 の、電子メール メッセージが Exchange Server 2003 組織の [ディレクトリ参照待ち] キューに入ったままになっている現象についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=922256) を参照してください。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージ センターのページ (http://go.microsoft.com/fwlink/?LinkId=34258) (英語) を参照してください。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、マイクロソフト サポート技術情報の文書番号 284204 の、Exchange Server および Small Business Server における配信状態通知についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

メッセージ カテゴライザに関する問題をトラブルシューティングする方法の詳細については、Help and Support のメッセージ カテゴライザと NDR トラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

トランスポート関連の問題をトラブルシューティングする方法に関する一般的な情報については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 821910 の、Exchange Server 2003 トランスポート問題のトラブルシューティング方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265 の、Exchange 2000 Server および Exchange Server 2003 でのトランスポートに関する問題の一般的なトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

  • 文書番号 895853 の、Exchange Server 2003 と Exchange 2000 Server でのメール中継に関する問題のトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853)

  • Exchange Server トランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkID=67875) (英語)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、マイクロソフト サポート技術情報の文書番号 231734 の、[XCON]メッセージ カテゴライザ用のパフォーマンス モニタ カウンタについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。


カテゴライザの警告イベント (ID: 6008) が過去 24 時間以内にログに記録されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) クラスに対してクエリを実行し、MSExchangeTransport のイベント 6008 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

MSExchangeTransport のイベント 6008 警告が過去 24 時間以内にログに記録されていることが検出されると、警告が表示されます。

この警告は、カテゴライザでメッセージを処理しようとしたときにエラーが発生したことを示します。

メッセージ カテゴライザは、SMTP (Simple Mail Transfer Protocol) サーバーに到着したメッセージを調査し、メッセージの処理方法を判断します。メッセージの宛先は、ローカル インフォメーション ストア、メッセージ転送エージェント (MTA) の使用によるリモート ホスト、または、SMTP の使用によるリモート ホストである可能性があります。カテゴライザは、配布リストの展開も処理します。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを TCP ポート 3268 で実行する、アドバンスド キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザは、アドレス解決とメール転送の実行、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行います。また、カテゴライザは、他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージがメッセージ カテゴライザに入ると、カテゴライザは直ちに Active Directory® ディレクトリ サービスのプロキシ アドレス属性に含まれているアドレスを検索し、エンベロープ送信者を解決します。また、カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索して、エンベロープ受信者も解決します。たとえば、一覧に配布リストが含まれている場合、そのサーバーで配布リストの展開が許可されていれば配布リストを展開し、それらのメンバを含めます。

Possible causes of MSExchangeTransport 警告イベント 6008 には、次のことが含まれます。

  • ディレクトリ サービス アクセス (DSAccess) に関する問題

  • ディレクトリのレプリケーションの待ち時間または障害

  • グローバル カタログ サーバーの過負荷

  • DNS に関する問題

  • 配布グループの過度な展開

この警告に対処するには、次の操作を行います。

  • Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。これには、Windows のネットワーク モニタ ツールを使用すると便利です。

  • 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN に、配信不能レポート (NDR) を含めることができます。DSN には、永続的な配信エラー メッセージと、最終的に永続的な配信エラーとなることが多い一時的なエラー メッセージが記載されています。

  • メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  • Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  • システム モニタ を使用して、カテゴライザのパフォーマンス カウンタを監視します。

  • 配布グループによる配信の制限の設定を調べて、不要な制限を削除します。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージ センターのページ (http://go.microsoft.com/fwlink/?LinkId=34258) (英語) を参照してください。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、マイクロソフト サポート技術情報の文書番号 284204 の、Exchange Server および Small Business Server における配信状態通知についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server のメッセージ追跡センターの使用方法の詳細については、マイクロソフト サポート技術情報の次の記事を参照してください。

  • 文書番号 262162 の、[XADM] メッセージ追跡センターを使用したメッセージの追跡についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856 の、[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905 の、Exchange Server 2003 のメッセージ追跡イベント ID についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864 の、Exchange Server 2003 の強化されたメッセージ追跡機能についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題をトラブルシューティングする方法の詳細については、Help and Support のメッセージ カテゴライザと NDR トラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798 の、[XCON] Exchange 2000 Service Pack 2 での Archive Sink ユーティリティの利用についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)

  • 文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)

トランスポート関連の問題をトラブルシューティングする方法に関する一般的な情報については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 821910 の、Exchange Server 2003 トランスポート問題のトラブルシューティング方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265 の、Exchange 2000 Server および Exchange Server 2003 でのトランスポートに関する問題の一般的なトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

  • 文書番号 895853 の、Exchange Server 2003 と Exchange 2000 Server でのメール中継に関する問題のトラブルシューティングについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853)

  • Exchange Server トランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkID=67875) (英語)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連する利用可能なパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734 の [XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタについての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。


接続フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchServerBindingsFiltering プロパティが、SMTP 仮想サーバー インスタンスに対して接続フィルタが有効になっていることを示しているかどうかを判断します。

また、Active Directory に対してクエリを実行し、msExchSmtpConnectionRulesPriority、msExchSMTPGlobalIPAcceptList、または msExchSMTPGlobalIPDenyList プロパティが、グローバル設定のレベルでも接続フィルタが有効になっていることを示しているかどうかを判断します。

以下の条件に当てはまる場合は、警告メッセージが表示されます。

  • SMTP 仮想サーバー インスタンスで接続フィルタが有効になっている。

  • グローバル設定のレベルで接続フィルタが有効になっている。

この警告は、接続フィルタが実質的に有効になっていることを示しています。接続フィルタは一般に問題にはなりません。ただし、このサーバーに関連するメール フローの問題をトラブルシューティングする場合は、フィルタの構成を確認するか、または接続フィルタを一時的に無効にして、有効な受信者へのメールが誤ってブロックされていないかどうかを判断する必要があります。

SMTP 仮想サーバーの接続フィルタを無効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. フィルタを無効にする SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[全般] タブの [詳細設定] をクリックします。

  5. [詳細設定] で、フィルタを無効にする IP アドレスを選択し、[編集] をクリックします。

  6. [識別] で、[接続フィルタを適用する] チェック ボックスをオフにしてフィルタを無効にします。

  7. 仮想サーバーが複数ある場合は、フィルタを無効にする各仮想サーバーに対して手順 3. ～ 6. を繰り返します。

接続フィルタを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 823866「Exchange 2003 で接続フィルタを構成してリアルタイム ブロック リスト (RBL) を使用する方法と受信者フィルタを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823866) を参照してください。

インテリジェント メッセージ フィルタの詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


コネクタに受信制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ルーティング グループ内の各 SMTP コネクタの dLMemDefault 属性値を判断します。また、Active Directory に対してクエリを実行し、各コネクタの authOrig および unauthOrig 属性値も判断します。unauthOrig および authOrig 属性には、アカウントの識別名 (DN) の一覧が含まれています。

既定では、すべてのユーザーが、すべての SMTP コネクタを経由してメッセージを送信できます。dLMemDefault が既定の設定である 1 に設定されている場合は、unauthOrig 属性に列挙されているアカウントを除くすべてのアカウントからのメッセージが受信されます。dLMemDefault が 0 に設定されている場合は、authOrig 属性に列挙されているアカウントを除くすべてのアカウントからのメッセージが拒否されます。

以下の条件に当てはまる場合は、既定以外の構成であることを示すメッセージが表示されます。

  • dLMemDefault属性の値が 0 に設定されている。

  • authOrig 属性に値が含まれている。

Exchange Server アナライザによって指定されるコネクタは、一部のメッセージのみを許可するように構成されています。コネクタの [配信の制限] タブで明示的なアクセス許可を与えられたアカウントのみが、そのコネクタを経由してメッセージを送信できます。

Exchange Server アナライザは、既定以外の構成であることを示すメッセージを情報提供のためにのみ表示します。

コネクタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


コネクタにアクセス拒否のための制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ルーティング グループ内の各 SMTP コネクタの dLMemDefault 属性値を判断します。また、Active Directory に対してクエリを実行し、各コネクタの authOrig および unauthOrig 属性値も判断します。unauthOrig および authOrig 属性には、アカウントの識別名 (DN) の一覧が含まれています。

既定では、すべてのユーザーが、すべての SMTP コネクタを経由してメッセージを送信できます。dLMemDefault が既定の設定である 1 に設定されている場合は、unauthOrig 属性に列挙されているアカウントを除くすべてのアカウントからのメッセージが許可されます。dLMemDefault が 0 に設定されている場合は、authOrig 属性に列挙されているアカウントを除くすべてのアカウントからのメッセージが拒否されます。

以下の条件に当てはまる場合は、既定以外の構成であることを示すメッセージが表示されます。

  • dLMemDefault 属性値が 1 に設定されている。

  • unauthOrig 属性に値が含まれている。

Exchange Server アナライザによって指定されるコネクタは、一部のメッセージを拒否するように構成されています。コネクタの [配信の制限] タブで明示的にアクセス許可を拒否されているアカウントは、そのコネクタを経由してメッセージを送信できません。

Exchange Server アナライザは、既定以外の構成であることを示すメッセージを情報提供のためにのみ表示します。

コネクタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


コネクタが既定ですべてのメッセージを拒否している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各コネクタの dLMemDefault 属性値を判断します。dLMemDefault 属性は、既定でメッセージを受信するか拒否するかを制御します。

dLMemDefault 属性値が 0 の場合、メッセージは既定で拒否されます。dLMemDefault 属性値が 1 の場合、メッセージは既定で受信されます。Exchange Server アナライザによって、dLMemDefault 属性値が 0 であることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server アナライザによって報告されたコネクタは、既定で、すべてのメッセージを拒否するように構成されています。コネクタの [配信の制限] タブで明示的にアクセス許可を与えられているアカウントだけが、このコネクタ経由でメッセージを送信することを許されます。

Exchange Server アナライザは、既定以外の構成であることを示すメッセージを情報提供のためにのみ表示します。

コネクタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


コネクタの制限の確認処理が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ ブランチを読み取り、CheckConnectorRestrictions レジストリの値が存在し、構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

CheckConnectorRestrictions の値が存在し、1 に設定されていることが検出されると、警告が表示されます。

コネクタに配布リスト ベースの制限を適用する必要があるときは、これらの制限について確認処理を手動で有効にする必要があります。制限の確認処理は CheckConnectorRestrictions レジストリの値により制御されます。この値は、確認の対象となるコネクタのソースとなっている Exchange ブリッジヘッド サーバーで設定する必要があります。制限を指定しても、CheckConnectorRestrictions レジストリの値を作成しないと、制限の確認は行われません。

コネクタの制限の確認処理は、既定で無効になっています。これは、システムを通過する各メッセージについて配布グループの展開と制限の確認処理を実行すると、パフォーマンスに大きな影響が及ぶためです。この設定は、必要な場合 (たとえば、制限が適用されているコネクタのブリッジヘッド サーバー上で) のみ有効にすることをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

コネクタの制限の確認処理を無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Resvc\Parameters

  3. 右側のペインで、CheckConnectorRestrictions を見つけて削除します。

  4. レジストリ エディタを終了し、Microsoft Exchange Routing Engine サービスと SMTP (Simple Mail Transfer Protocol) サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

コネクタの制限の確認処理に関するレジストリ値の詳細については、Microsoft サポート技術情報の文書番号 277872「[XCON] コネクタ配信制限が正常に機能しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872) を参照してください。


コネクタのスコープがローカル ルーティングに限定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-04-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 SMTP コネクタの msExchRoutingSMTPConnector 属性の値を判断します。msExchRoutingSMTPConnector 属性の値に文字列 "Local:" が含まれていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。文字列 "Local:" が存在する場合は、SMTP コネクタのスコープがローカル ルーティングに限定されていることを示します。

SMTP コネクタは、メール用に独立したルートを指定します。SMTP コネクタを使用して、インターネット メールのゲートウェイを設定したり、特定のドメインやメール システムに接続したりできます。コネクタの利用により、指定したメール ルートに対して特定のオプションを定義できます。

SMTP 仮想サーバーを使用してインターネット メールを送受信することもできますが、多くの組織が、専用の SMTP コネクタを使用してインターネット メールをルーティングするように構成しています。SMTP コネクタはインターネット宛てのメール用に独立したルートを用意するため、SMTP コネクタを使用することをお勧めします。また、SMTP コネクタでは、SMTP 仮想サーバーよりも多くの構成オプションを利用できます。

Exchange Server アナライザは、既定以外の構成であることを示すメッセージを情報提供のためにのみ表示します。

SMTP コネクタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


階層のない制限の確認を検討する
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内の各 Exchange Server オブジェクトについて、serialNumber 属性の値を判断します。Exchange Server 2003 サーバー オブジェクトの serialNumber 属性の文字列値に、"Service Pack 2" が含まれていることが検出されると、次に Exchange Server アナライザは、次のレジストリ キーを読み取り、CheckConnectorRestrictions レジストリ値が存在し、構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Resvc\Parameters

この状況は、メッセージの処理の前にサーバーが送受信の制限を確認することを示します。

CheckConnectorRestrictions の値が存在し、この値が 1 に設定されている (有効になっている) ことが検出されると、Exchange Server アナライザは HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod レジストリ キーも読み取り、RestrictionMethod レジストリ値が存在しているかどうか、およびどのように構成されているかを判断します。

RestrictionMethod レジストリ キーが存在しない、または 2 以外の値に設定されていることが検出されると、ベスト プラクティスを推奨するメッセージが表示されます。

要するに、以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • Exchange Server 2003 サーバーに SP2 がインストールされている。

  • HKLM\System\CurrentControlSet\Services\Resvc\Parameters の CheckConnectorRestrictions レジストリ値が、ローカル コンピュータのコネクタに対して配布リスト ベースの制限を使用するように構成されている。

  • HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod の RestrictionMethod レジストリ値が存在しない、または 2 以外の値に設定されている。

RestrictionMethod の値は、カテゴライザが制限を処理する方法を判断します。既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。この既定の動作はパフォーマンスに重大な影響を与える可能性があるため、ベスト プラクティスではありません。

RestrictionMethod の値を 2 に設定している場合、この Exchange サーバーのトランスポート コンポーネントは、サーバーが制限を確認するときに配布グループのメンバシップを展開しません。この構成では、制限の確認に対して最適なパフォーマンスが得られます。また、RestrictionMethod レジストリ エントリを有効にするには、配信が制限されているユーザーを含むすべての配布グループをフラットな構成にする必要があります。つまり、制限のある配布グループでは、配布グループを入れ子にしないようにする必要があります。制限のある配布グループが入れ子になっている場合、展開ロジックは機能しません。

コネクタの制限で使用される配布グループでは、メールボックスを持たないコネクタ ブリッジヘッド サーバーで RestrictionMethod レジストリ エントリの値を設定することをお勧めします。Active Directory ユーザーの制限では、制限のある配布グループに展開サーバーがある場合、展開サーバーで RestrictionMethod レジストリ エントリを作成することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
RestrictionMethod レジストリ エントリを作成して、値を 2 に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

  3. 左側のペインで、[Parameters] をクリックします。

  4. [編集] メニューの [新規] をクリックし、[DWORD 値] をクリックします。

  5. 「RestrictionMethod」と入力し、Enter キーを押して、新しいレジストリ エントリに名前を付けます。

  6. [RestrictionMethod] を右クリックし、[変更] をクリックします。

  7. 「2」と入力し、Enter キーを押します。

  8. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RestrictionMethod レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 895407「配布グループに基づく配信制限を構成した後に、in exchange 低下するのが必要だより、in exchange ローカル メールボックスにと外部メールボックスにサーバー メッセージの配信 2003 が低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407) を参照してください。

レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 277872「[XCON] コネクタ配信制限が正常に機能しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872) を参照してください。


ConvertDSNInternetContent レジストリ キーがすべてのメッセージのコンテンツ変換を実行するように構成されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ConvertDSNInternetContent レジストリ値が、Exchange Server 2003 コンピュータの Exchange Information Store によって受信されるすべてのメッセージのコンテンツ変換を実行するように構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

以下の条件に当てはまる場合は、エラーが表示されます。

  • ConvertDSNInternetContent レジストリ値が手動で作成された。

  • ConvertDSNInternetContent レジストリ値のデータが 1 に設定されている。

ConvertDSNInternetContent レジストリ値のデータが 0 の場合、または値がない場合、Exchange Information Store による SMTP メッセージのコンテンツ変換は無効です。値のデータが 1 の場合、すべての SMTP 仮想サーバー インスタンス (VSI) 上または個々の VSI への SMTP メッセージを含むすべてのメッセージのコンテンツ変換が有効です。

既定では、ConvertDSNInternetContent レジストリ値は Exchange Server 2003 インストール時に作成されません。ConvertDSNInternetContent レジストリ値は、Exchange Server 2003 コンピュータでのコンテンツ変換の動作を変更するために、Exchange Server のインストール後に手動で作成できます。通常は、送信された SMTP メッセージに対してコンテンツ変換を実行しないでください。SMTP メッセージを含むすべてのメッセージに対してコンテンツ変換を有効にすると、Exchange サーバーでの処理オーバーヘッドが増加します。この余分な処理オーバーヘッドによって、パフォーマンスやログ ファイル ストレージの問題が発生する場合があります。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。レジストリを編集して、Exchange Server 2003 コンピュータのコンテンツ変換の動作を最も効果的なコンテンツ変換の方法に戻す必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. レジストリ キー HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters に移動します。

  3. 詳細ペインで、[ConvertDSNInternetContent] レジストリ値を右クリックし、[変更] をクリックします。次に、[値のデータ] を 80 に変更し、[OK] をクリックします。

    注 :
    ConvertDSNInternetContent レジストリ値を削除するには、詳細ペインで [ConvertDSNInternetContent] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  4. レジストリ エディタを終了します。

  5. Exchange Server を再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


共通の宛先として識別された配布グループ
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | キューの存在する仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、 Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信タイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは取得したこれらのデータを使用して、各 Recipient オブジェクトの distinguishedName の値について、Active Directory® ディレクトリ サービスに対してクエリを実行します。次に、Exchange Server アナライザは、受信者が、ユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判別します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先が特定の配布グループになっていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先が特定の配布グループになっていると判断すると、Exchange Server アナライザはエラーを表示します。

これらの警告またはエラーは、識別された配布グループが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、次に示すように対象の配布グループを調査して、メッセージがキューに入る原因となる構成上の問題またはその他の異常点を見つける必要があります。

  • 配布グループ オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • 配布グループ オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • 配布グループが特別な用途のユーザー オブジェクト、つまり指定された履歴保持用の受信者を含む場合は、そのユーザー オブジェクトが関連付けられているサービスまたはコンポーネントの構成が正しいことを確認します。

  • 配布グループに対する迷惑な商用電子メール メッセージ (UCE)、スパム、またはウイルス攻撃の可能性を調べます。

  • 配布グループの配信の制限が不適切に設定されていないか確認します。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=67875) (英語)

  • マイクロソフト サポート技術情報の文書番号 823489 のキュー ビューアを使用してメール フローの問題をトラブルシューティングする方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を構成した後にローカル メールボックスおよび外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)

  • 文書番号 329171 の、[XADM]グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)

  • 文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)


前の分類が再試行可能なエラーで失敗した
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Cat: Categorizations in progress および Categorizer Queue length パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Cat: Categorizations in progress パフォーマンス カウンタは処理中の分類の数を示し、Categorizer Queue length パフォーマンス カウンタはカテゴライザ キューにあるメッセージの数を示します。

このクエリの場合、Exchange Server アナライザは 2 分間の間に 6 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの平均値を報告します。

Exchange Server アナライザは、処理中の分類の平均数を調べ、その数を、まだキューにある分類の数と比較します。

サンプル期間中に以下の条件に当てはまると、Exchange Server アナライザはエラーを表示します。

  • 処理中の分類の平均数が 0 である。

  • カテゴライザ キューの長さの平均が 0 より大きい。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

このエラーは、再試行可能なエラーで分類に失敗したためにカテゴライザ キューに入ったままになっているメッセージがあることを示します。

一般に、メッセージがキュー内に蓄積される状態は、アドバンスド キュー エンジンがそのメッセージを分類できないことが原因です。アドバンスド キュー エンジンが、グローバル カタログ サーバーにアクセスできず、受信者情報にアクセスできない状態になっている可能性があります。あるいは、グローバル カタログ サーバーが到達不能か、またはパフォーマンスが低下しています。さらに、以下の理由でメッセージが蓄積される場合もあります。

  • Active Directory® ディレクトリ サービスが使用不可能である。

    注 :
    カテゴライザは Active Directory を使用してメッセージを分類します。
  • 分類前のキューに多数のメッセージが格納されている場合は、Active Directory の負荷が高くなりすぎている可能性がある。

  • 変換で障害が発生している。カテゴライザはコンテンツの変換も処理します。

  • メッセージ カテゴライザがメールボックス ストアを見つけることができない。

  • SMTP (Simple Mail Transfer Protoco) が再インストールまたは削除された場合、IIS メタベース キー/smtpsvc/DsUseCat および/smtpsvc/vsi#/DsUseCat が無効になる可能性がある。

    注 :
    SMTP を再インストールまたは削除したかどうかを確認してください。

キューのプロパティを調べることで、失敗の原因を判断することができます。たとえば、キューのプロパティに "SMTP エラーが発生しました" のようなメッセージが表示される場合は、サーバーのイベント ログを確認して SMTP エラーを見つける必要があります。ログにイベントが記録されていない場合は、SMTP のログ出力のレベルを上げる必要があります。

Exchange キューおよび SMTP キューのトラブルシューティング方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=67875)。

  • マイクロソフト サポート技術情報の文書番号 823489 の、キュー ビューアを使用して Exchange Server 2003 のメール フローに関する問題のトラブルシューティングを行う方法ついてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)。

  • マイクロソフト サポート技術情報の文書番号 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)。

  • マイクロソフト サポート技術情報の文書番号 264054 の、[XCON] Exchange 2000 サーバーのキューの状態についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)。

  • Microsoft Exchange Server のパフォーマンスのトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47588)。

  • Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576)。

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、マイクロソフト サポート技術情報の文書番号 231734 の、[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。


インテリジェント メッセージ フィルタの自動更新を有効にする
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-02-13

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内のすべての Exchange Server オブジェクトについて、serialNumber 属性の値を判断します。serialNumber 属性は、Exchange Server のバージョンと、インストールされている Service Pack のバージョン (インストールされている場合) を含む文字列値です。serialNumber 属性の値が Version 6.5 (Build 7638: Service Pack 2) である場合は、そのサーバーが Exchange Server 2003 Service Pack 2 を実行していることを示します。

また、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、クラスタ サービス (ClusSvc) の Started キーの値を判断します。この値が True の場合は、クラスタ サービスが実行されています。この値が False の場合は、クラスタ サービスは実行されていません。

また、Exchange Server アナライザは、次のレジストリ エントリを読み取り、Microsoft Exchange インテリジェント メッセージ フィルタがサーバーにインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

ContentFilter レジストリ キー内に ContentFilterBindings エントリは存在するが、ContentFilterBindings 値が構成されていない場合は、このサーバーでインテリジェント メッセージ フィルタが有効になっていないことを示します。

最後に、Exchange Server アナライザは、次のレジストリ エントリに対してクエリを実行し、ContentFilterState サブキーが存在し、このサーバーでインテリジェント メッセージ フィルタの自動更新が有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\

ContentFilterState サブキーの値が 1 以外である場合は、インテリジェント メッセージ フィルタの自動更新が有効になっていないことを示します。

以下の条件に当てはまる場合、Exchange Server アナライザはベスト プラクティスを推奨するメッセージを表示します。

  • サーバーが Exchange Server 2003 Service Pack 2 を実行している

  • Exchange Server がクラスタ化されていない

  • インテリジェント メッセージ フィルタが有効になっている

  • インテリジェント メッセージ フィルタの自動更新が有効になっていない

既定では、インテリジェント メッセージ フィルタ機能は Exchange Server 2003 SP2 と共にインストールされます。この新しいメッセージ フィルタ テクノロジを利用するには、インテリジェント メッセージ フィルタ機能を手動で有効にする必要があります。インテリジェント メッセージ フィルタ機能を有効にした後で, .dat ファイルおよび .dll ファイルを定期的に更新し、最新のフィルタを有効にする必要があります。以下のセクションで参照する文書では、インテリジェント メッセージ フィルタを最新の状態に保つための更新プロセスについて説明します。

インテリジェント メッセージ フィルタの自動更新を有効にする方法の詳細については、Microsoft サポート技術情報の文書番号 907747「Exchange Server 2003 SP2 のインテリジェント メッセージ フィルタ 2 バージョンを更新する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=907747) を参照してください。


エンベロープの履歴保持が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-03-30

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、heuristics 属性がエンベロープの履歴保持を有効にするように構成されているかどうかを判断します。既定では、heuristics 属性は構成されていません。Exchange Server アナライザによって、heuristics 属性が 512 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

エンベロープの履歴保持を使用すると、P1 メッセージ ヘッダーをアーカイブできます。P1 メッセージ ヘッダーは、メッセージ転送エージェント (MTA) がメールをルーティングするために使用するアドレス情報です。このアドレス情報には、BCC 受信者や、配布グループのメンバである受信者も含め、実際にメッセージを受信する受信者に関する情報が含まれています。エンベロープの履歴保持では、履歴保持レポートと元のメッセージを含むエンベロープ メッセージを使用して、アーカイブされるためのフラグが付いたメッセージを配信します。元のメッセージは添付ファイルとして配信されます。履歴保持レポートの本文には、アーカイブされるメッセージのトランスポート エンベロープ データが含まれます。

特定のサーバーで BCC の履歴保持を有効にするには、最初にデータベース レベルでメッセージのみの履歴保持を構成する必要があります。以下の条件に当てはまる場合、heuristics 属性は有効になっていません。

  • heuristics 属性が 512 に設定されている。

  • メッセージのみの履歴保持が、どのデータベース ストアでも有効になっていない。

メッセージの履歴保持によって、ディスク、ネットワーク、CPU リソースなどの消費が増える場合があります。このため、履歴を保持する際は十分な展開計画が必要です。履歴の保持は、総合的な履歴保持のソリューション フレームワークを展開するケースにおいてのみ有効にしてください。

以下の条件に当てはまる場合は、既定以外の構成を示すこのメッセージを無視してかまいません。

  • 業務上、履歴の保持が必要である。

  • 履歴保持のソリューション フレームワークを既に展開している。

これらの状況に該当しない場合は、履歴保持機能を無効にする必要があります。

データベースでメッセージのみの履歴保持を無効にするには

  1. Exchange システム マネージャで [サーバー] を展開し、[<使用している Exchange サーバー>] を展開します。次に、[<ストレージ グループ>] を展開し、メールボックス ストアを右クリックします。

  2. [全般] タブで、[このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] チェック ボックスをオフにします。

  3. Exchange ストアに変更が適用されるまで 15 分待ちます。Microsoft Exchange Information Store サービスを再開する必要はありません。

Exchange Server アナライザによって再度このメッセージが表示されないようにするには、heuristics 属性を無効にする必要があります。履歴保持機能を無効にするために、heuristics 属性を無効にする必要はありません。

エンベロープの履歴保持を無効にするには、E-Mail Journaling Advanced Configuration ツール (Exejcfg.exe) を使用します。このツールは、Active Directory にアクセス可能な任意のサーバーから実行できますが、ドメイン コントローラから実行することをお勧めします。

E-Mail Journaling Advanced Configuration ツールとそのドキュメントを入手するには、http://go.microsoft.com/fwlink/?LinkId=33122 でこのツールのパッケージをダウンロードしてください。E-Mail Journaling Advanced Configuration ツールは、Exchange 2000 Server 環境と Exchange Server 2003 環境で使用できます。

heuristics 属性を無効にするには

  1. E-Mail Journaling Advanced Configuration ツールをダウンロードし、任意のディレクトリに解凍します。

  2. コマンド プロンプトを開きます。

  3. E-Mail Journaling Advanced Configuration ツールをインストールしたディレクトリに移動します。

  4. 次のコマンドを入力して、エンベロープの履歴保持を無効にします。

    コードのコピー
    exejcfg -d

履歴保持ソリューションの展開の詳細については、『Journaling with Exchange Server』(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


ESMTP コマンドがサポートされていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの各インスタンスの msExchSmtpInboundCommandSupportOptions 属性値が、受信接続のための既定の拡張 SMTP コマンドをサポートするように構成されているかどうかを判断します。

これらの拡張 SMTP コマンドの一覧を次の表に示します。Exchange Server アナライザによって、ここに示されている受信接続のための既定の拡張 SMTP コマンドのいずれかがサポートされていないことが検出されると、警告が表示されます。

Exchange Server 2003 は、これらの Exchange 固有の拡張 SMTP コマンドを使用することにより、標準の SMTP の場合に比べて効率的に組織内の他の Exchange サーバーと通信します。これらのコマンドは、メタベースおよび Exchange Server イベント シンク内で制御されます。Exchange Server 2003 では、DS2MB プロセスが、メタベース内の値を Active Directory からのコピーによって更新する役割を果たします。イベント シンクを無効にすると、Exchange Server のパフォーマンスが低下する場合があります。

拡張 SMTP コマンド コメント

8BITMIME

ローカルの SMTP 仮想サーバーが 8 ビット MIME メッセージをサポートしていることを示します。

BDAT、CHUNKING

DATA コマンドの代わりのコマンドです。このコマンドは 2 つの引数を取ります。SMTP 仮想サーバーが EHLO キーワードに CHUNKING で応答した場合は、BDAT コマンドをサポートしており、メッセージのチャンクを受け付けることを示しています。

  • 最初の引数は、バイナリ データ パケットの長さを示します。そのため、SMTP ホストがデータの最後まで連続してスキャンする必要はありません。受信側のサーバーは、メッセージのバイト数をカウントします。メッセージ サイズが BDAT コマンドで送信された値に等しくなったら、サーバーはすべてのメッセージ データを受信したと見なします。

  • 2 番目の引数は、データ パケットが現在の転送での最後のパケットであるかどうかを示します。2 番目の引数は省略可能です。

BINARYMIME

SMTP 仮想サーバーが、MAIL コマンドで値が BINARYMIME の BODY パラメータを使用することにより、バイナリ データを含むメッセージをトランスポートのエンコードなしで受け付けることを示します。SMTP サーバーが、値が BINARYMIME の BODY パラメータを含む MAIL コマンドを受け付けた場合、このサーバーは、BDAT コマンドで渡される各オクテット内のすべてのビットを保持することに同意しています。BINARYMIME の SMTP 拡張は、CHUNKING でのみ使用できます。

DSN

RFC (Request for Comments) 1891 で定義された配信状態通知を有効にする ESMTP コマンドです。

ENHANCEDSTATUSCODES

SMTP サーバーが、拡張されたエラー状態コードを提供することを示します。初期応答と HELO や EHLO への応答を除くすべての SMTP 状態応答のテキスト部分の前には、RFC 1893 で定義された状態コードが置かれます。

ETRN

SMTP サーバーによって送信され、ローカル仮想サーバーに対して、ETRN コマンドで示すドメインのキューに保持しているすべての電子メール メッセージを送信するよう要求します。

TURN

リモート ホストとローカル ホストが役割を切り替えて、新しい接続を確立しなくても逆方向にメールを送信できるようにします。

これらのコマンドの既定のサポートを復元する方法の詳細については、Microsoft サポート技術情報の文書番号 257569「Exchange 2000 Server および Exchange Server 2003 で ESMTP コマンドをオフにする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569) を参照してください。


拡張されたコマンドは Exchange サーバーで公表されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft®Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベース内の SmtpInboundCommandSupportOptions プロパティを読み取り、Exchange Server が拡張されたコマンドをサポートするように構成されているかどうかを判断します。Exchange Server アナライザによって、SmtpInboundCommandSupportOptions が 7697601 に設定されていないことが検出されると、警告が表示されます。

拡張された SMTP コマンドは、Exchange 2000 Server および Exchange Server 2003 の両方で必要です。IIS メタベース内の値は、Active Directory® ディレクトリ サービスで設定されている値と一致する必要があります。混在モード環境で Exchange Server を実行している場合、この値は 7697601 に設定されている必要があります。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
SmtpInboundCommandSupportOptions の既定値に戻すには

  1. ADSI Edit を開き、ドメイン コントローラに接続します。

  2. [Configuration Container] を開きます。

  3. 次の場所に移動します。

    Configuration/Services/Microsoft Exchange/<自分の組織>/Administrative Groups/<自分の管理グループ>/Servers/<自分の Exchange Server>/Protocols/SMTP/<自分の仮想サーバー>

  4. 仮想サーバー オブジェクトを右クリックし、[プロパティ] をクリックします。

  5. [Select a property to view] で、[msExchSmtpInboundCommandsSupportOptions] を選択します。

  6. [Edit Attribute] に「7697601」と入力します。

  7. [Set] をクリックし、[Apply] をクリックします。次に、[OK] をクリックします。

  8. ADSI Edit を終了します。


停止したキューが検出された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、サーバー上の SMTP (Simple Mail Transfer Protocol) キューの StateFrozen キーの値を判断します。

Exchange サーバー上のいずれかの SMTP キューの StateFrozen キーの値が True に設定されていることが検出されると、警告が表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

影響を受けている特定の SMTP キューとその考えられる原因については、Exchange Server アナライザ ツールの以下の文書を参照してください。

  • [ディレクトリ参照待ちのメッセージ] キューが停止している

  • [ルーティング待ちのメッセージ] キューが停止している

  • [発信が保留されているメッセージ] キューが停止している

  • [ローカル配信] キューが停止している

  • [リモート配信] キューが停止している

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


インテリジェント メッセージ フィルタ用のフィルタ更新プログラムが使用可能である
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server 上の次のパスに MSExchange.UceContentFilter.dll が存在するかどうかを判断します。

<Exchange サーバー バイナリ ファイルへのパス>\MSCFv2\MSExchange.UceContentFilter.dll

注 :
このパスの <Exchange サーバー バイナリ ファイルへのパス> は、bin フォルダの場所を指しています。

MSExchange.UceContentFilter.dll がこの場所に存在しない場合は、ベスト プラクティスを推奨するメッセージが表示されます。

Microsoft Exchange インテリジェント メッセージ フィルタ用のフィルタ更新プログラムは、インテリジェント メッセージ フィルタがインストールされているすべての Exchange Server にインストールすることをお勧めします。インテリジェント メッセージ フィルタ用のフィルタ更新プログラムは、インテリジェント メッセージ フィルタ用の最新のインテリジェント メッセージ フィルタ SmartScreen™ フィルタ更新プログラムを提供します。SmartScreen フィルタ用のフィルタ更新プログラムには、不要な商用電子メール メッセージ (スパムともいう) をブロックするインテリジェント メッセージ フィルタの機能を強化する、更新されたスパム特性が含まれています。

注 :
この更新プログラムをインストールする前に、インテリジェント メッセージ フィルタをインストールする必要があります。インテリジェント メッセージ フィルタをインストールするには、ローカルの管理者権限を持ち、かつ Exchange 管理者の役割が適用されているグループのメンバであるアカウントを使用します。

インテリジェント メッセージ フィルタをインストールした後、次の手順を実行して更新プログラムをインストールします。

インテリジェント メッセージ フィルタの更新プログラムを入手してインストールするには

  1. http://go.microsoft.com/fwlink/?LinkId=41026 で、Exchange インテリジェント メッセージ フィルタ用の最新の更新プログラムを入手します (このサイトは英語の場合があります)。

  2. http://go.microsoft.com/fwlink/?LinkId=41027 で、Exchange インテリジェント メッセージ フィルタ用の更新プログラムのリリース ノートを確認します (このサイトは英語の場合があります)。

  3. 更新プログラム パッケージを実行し、更新プログラム パッケージのセットアップ ウィザードの指示に従います。

詳細については、「Exchange Intelligent Message Filter」Web サイト (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


フラットな制限の確認処理が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、ディレクトリ内の各 Exchange Server オブジェクトについて、serialNumber 属性の値を判断します。Exchange Server 2003 サーバー オブジェクトの serialNumber 属性の文字列値に Service Pack 2 が含まれている場合は、Exchange サーバーで Exchange Server 2003 Service Pack 2 のプレリリース版が実行されていることを示しています。

Exchange Server アナライザは、次のレジストリ エントリも読み取り、RestrictionMethod レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

以下の条件に当てはまる場合、Exchange Server アナライザによって既定以外の構成であることを示すメッセージが表示されます。

  • Exchange Server 2003 Service Pack 2 がインストールされている。

  • RestrictionMethod レジストリ値が存在し、値が 2 に構成されている。

この構成は、この Exchange サーバー上のトランスポート コンポーネントが、サーバーが制限を確認するときに配布グループのメンバシップを展開しないことを意味します。この構成では、制限の確認に対して最適なパフォーマンスが得られます。

RestrictionMethod レジストリ値の存在と設定が誤りである場合は、次の手順を実行して既定の構成に戻すことができます。ただし、Exchange Server 2003 Service Pack 2 でこのキーが存在することは、制限の確認に対するベスト プラクティスであるため、RestrictionMethod レジストリを現在の設定のまま維持することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\

  3. 右側のペインで、[RestrictionMethod] を右クリックし、[削除] を選択します。

  4. レジストリ エディタを終了し、IIS Admin サービスおよび Microsoft Exchange Routing Engine サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

RestrictionMethod レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 895407「配布グループに基づく配信制限を構成した後に、 in exchange 低下するのが必要だより、 in exchange ローカル メールボックスにと外部メールボックスにサーバー メッセージの配信 2003 が低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407) を参照してください。


'ホスト' レコードは見つかるが 'MX' レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、使用しているドメイン ネーム システム (DNS) サーバーに対して、Exchange の送信先のリモート ドメインの MX (Mail Exchanger) レコードに関するクエリを実行します。次に、DNS 参照を実行してリモート ドメインのホスト (A) レコードを取得します。

DNS 参照操作でリモート ドメインの MX レコードが返されず、その後の参照操作で同じリモート ドメインのホスト (A) レコードが取得できる場合は警告が表示されます。

このような状況では、MX レコードの取得に失敗した後、Exchange Server はホスト (A) レコードが指すサーバーにメールを送信しようとします。このため、これらのホスト (A) レコードが正しいメール サーバーを指していることが非常に重要になります。

ドメインによっては、ホスト (A) レコードがインターネット サービス プロバイダ (ISP) を指すように構成されている場合があります。ただし、その ISP に有効なメール サーバーが用意されていても、目的の受信者に対しては権限のないメール サーバーであることがあります。この場合、メールが拒否されます。

DNS サーバーが停止しているか、またはネットワーク障害などの理由により DNS サーバーに到達できない場合は、MX レコードの DNS 参照が失敗する可能性があります。

DNS サーバーがオンラインになっていて、MX レコードが存在することを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、MX レコードが正しく構成されていることを確認します。詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Nslookup を使用して MX レコードの構成を確認する方法に関するセクションを参照してください (このサイトは英語の場合があります)。

詳細情報

  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Exchange Server 2003 の転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS をトラブルシューティングする方法の詳細については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。


IIS PoolThreadLimit レジストリの値が手動で追加および構成されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、インターネット インフォメーション サービス (IIS) プール スレッドの最大数が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\Inetinfo\Parameters\PoolThreadLimit

PoolThreadLimit が存在し、既定値と異なる値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

PoolThreadLimit レジストリの値は、Inetinfo.exe プロセスで作成できる入出力 (I/O) ワーカー スレッドの最大数を指定します。これは、IIS に対して作成できる同時接続の最大数を制御することになります。各プール スレッドは、ネットワーク要求を監視し、静的ファイルを戻すか、または要求を ISAPI 拡張 DLL (ASP.DLL など) か CGI (Common Gateway Interface) アプリケーションに渡すことで要求を処理します。ISAPI 拡張機能により要求が同期的に処理され、要求の処理に長い時間がかかる場合、その処理によってワーカー スレッドが保持されるため、IIS が他の要求を処理するために使用できるワーカー スレッドが少なくなります。このため、ASP などの適切に作成された ISAPI 拡張機能は、独自のスレッド プールを実装し、要求をキューに置き、独自のスレッドで非同期的に処理することで、IIS ワーカー スレッドを保持しないようにしています。

既定では、PoolThreadLimit は IIS により次の値に設定されます。

コンピュータに搭載されている RAM のサイズ の 2 倍 (MB 単位)

この値が 256 よりも大きい場合は、256 に抑えられます。このレジストリ値は既定では存在しません。レジストリにこの値が存在する場合は、IIS の既定の計算より優先されます。

一般に、既定の制限である 256 スレッドで不足がある場合、ISAPI 拡張機能が適切に作成されていないために IIS ワーカー スレッドを保持していると考えられます。256 という多数のスレッドが同時に アクティブになると、同期とコンテキスト切り替えにかなりのオーバーヘッドが発生します。

PoolThreadLimit レジストリの値は、HTTP、FTP、NNTP、SMTP サービスなどすべての IIS ワーカー スレッドを含むハード リミットです。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. PoolThreadLimit の値を調べ、削除または修正します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。


受信メッセージと送信メッセージのサイズ制限
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-01

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、送信メッセージのサイズ制限の属性である submissionContLength と、受信メッセージのサイズ制限の属性である delivContLength が異なっているかどうかを判断します。送信メッセージと受信メッセージの制限値が異なっていることが検出されると、ベスト プラクティスのメッセージが表示されます。

メッセージの制限に一貫性を持たせるため、送信メッセージのサイズ制限と受信メッセージのサイズ制限を同じ値に設定することをお勧めします。

Exchange 2000 Server と Exchange Server 2003 の送信メッセージのサイズ制限を変更するには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインで、[グローバル設定] を展開します。

  3. [メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  4. [既定] タブで、[送信メッセージ サイズ] の [最大サイズ (KB)] をクリックし、数値を入力します。
Exchange Server 2007 に送信メッセージのサイズ制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxSendSize <size>

たとえば、Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize 10MB

Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize unlimited
 受信メッセージ サイズの制限値を変更するには

  1. Exchange システム マネージャを起動します。

  2. 左側のペインで、[グローバル設定] を展開します。

  3. [メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  4. [既定] タブで、[受信メッセージ サイズ] の [最大サイズ (KB)] をクリックし、数値を入力します。
Exchange Server 2007 に受信メッセージのサイズ制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxReceiveSize <size>

たとえば、Exchange 組織の受信者によって受信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize 10MB

Exchange 組織のユーザーによって受信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize unlimited

Exchange 2000 Server および Exchange Server 2003 でメッセージのサイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679) を参照してください。

Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの Set-TransportConfig についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。


インテリジェント メッセージ フィルタのカスタム応答が存在する
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、CustomRejectResponse レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

以下の条件に当てはまる場合は、既定以外の構成であることを示すメッセージが表示されます。

  • CustomRejectResponse 値が存在する。

  • 値が有効な文字列である。

    注 :
    有効な値として認識されるためには、応答文字列の値は 550 5.7.1 で始まっている必要があります。

このメッセージへの対処は必要ありません。

Exchange Server 2003 Service Pack 2 (SP2) にはインテリジェント メッセージ フィルタがインストールされており、SP2 をインストールした時点ですぐに使用できる状態になっています。Exchange Server 2003 SP2 では、生成され送信者へ返送される 配信不能レポート (NDR) に付加されるサーバー応答の応答文字列をカスタマイズすることができます。既定の応答 "550 5.7.1 Requested action not taken:message refused" を変更し、ブロックされた正当なユーザーにメッセージがブロックされた理由を伝えるための、合理的な説明を追加することができます。この説明によって、不要な調査を減らし、スパム対策処理のサポート コストを削減できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
カスタム応答文字列を変更するには、次の操作を行います。

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\Software\Microsoft\Exchange\ContentFilter

  3. 右側のタスク ペインで CustomRejectResponse 値を右クリックし、[変更] を選択します。

  4. カスタム応答として使用する文字列値として、550 5.7.1 で始まる文字列を入力します。たとえば、「550 5.7.1 Domain not an allowed sender」 と入力すると、この文字列が NDR に付加される有効な文字列として設定されます。

  5. 変更を保存し、レジストリ エディタを終了し、SMTP サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

インテリジェント メッセージ フィルタの詳細については、Exchange Intelligent Message Filter の Web サイト (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。

インテリジェント メッセージ フィルタ タスクを実行する方法の詳細については、Exchange Server 2003 SP2 オンライン ヘルプの「Configure Intelligent Message Filtering」(英語) を参照してください。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


インテリジェント メッセージ フィルタのカスタムの語句の一覧が存在する
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、CIM_Datafile WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーに MSExchange.UCEContentFilter.xml ファイルが存在するかどうかを判断します。Exchange サーバーに MSExchange.UCEContentFilter.xml ファイルが存在することが検出されると、既定以外の構成であることを示すメッセージが表示されます。このメッセージへの対処は必要ありません。

MSExchange.UCEContentFilter.xml ファイルは、Exchange Server 2003 Service Pack 2 (SP2) 用のインテリジェント メッセージ フィルタに含まれるカスタム重み付け機能のコンポーネントです。

SP2 用のインテリジェント メッセージ フィルタのカスタム重み付け機能を使用すると、管理者は、電子メール メッセージの本文または件名行、あるいはその両方に含まれる語句を基に、インテリジェント メッセージ フィルタの動作をカスタマイズできます。カスタム重み付け機能に関連付けられたユーザー インターフェイスはありません。カスタム重み付け機能は、XML 構成ファイル MSExchange.UCEContentFilter.xml として提供されます。このファイルは、初期化時にインテリジェント メッセージ フィルタによって読み取られ、ファイルが変更されるたびに再読み込みされます。インテリジェント メッセージ フィルタを起動したときに MSExchange.UCEContentFilter.xml ファイルがない場合は、SMTP サービスを再開する必要があります。カスタム重み付けファイル MSExchange.UceContentFilter.xml は、MSExchange.UceContentFilter.dll ファイルおよび .dat ファイルと同じディレクトリに置く必要があります。

カスタム重み付けファイルの詳細については、Exchange Server 2003 Service Pack 2 のリリース ノートを参照してください。Exchange Server 2003 Service Pack 2 のリリース ノートは、SP2 の CD および Exchange Server 2003 Service Pack 2 リリース ノート Web サイト (http://go.microsoft.com/fwlink/?LinkId=52072) から入手できます (このサイトは英語の場合があります)。

Exchange Server 2003 SP2 の詳細については、Exchange Server 2003 Service Pack 2 の Web サイト (http://go.microsoft.com/fwlink/?LinkId=52073) を参照してください (このサイトは英語の場合があります)。


インテリジェント メッセージ フィルタのカスタム応答が無効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ キーを読み取り、CustomRejectResponse レジストリ値が存在するかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

以下の条件に当てはまる場合は、警告が表示されます。

  • CustomRejectResponse 値が存在している。

  • この値が 550 5.7.1 で始まっていない。

    注 :
    有効な値として認識されるためには、応答文字列の値は 550 5.7.1 で始まっている必要があります。

Exchange Server 2003 Service Pack 2 (SP2) では、生成され送信者へ返送される 配信不能レポート (NDR) に付加されるサーバー応答の応答文字列をカスタマイズすることができます。既定の応答 "550 5.7.1 Requested action not taken:message refused" を変更し、ブロックされた正当なユーザーにメッセージがブロックされた理由を伝えるための、合理的な説明を追加することができます。この説明によって、不要な調査を減らし、スパム対策処理のサポート コストを削減できます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\Software\Microsoft\Exchange\ContentFilter

  3. 右側のタスク ペインで CustomRejectResponse 値を右クリックし、[変更] を選択します。

  4. カスタム応答として使用する文字列値として、550 5.7.1 で始まる文字列を入力します。たとえば、「550 5.7.1 Domain not an allowed sender」 と入力すると、この文字列が NDR に付加される有効な文字列として設定されます。

  5. 変更を保存し、レジストリ エディタを終了し、SMTP サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

インテリジェント メッセージ フィルタの詳細については、Exchange Intelligent Message Filter の Web サイト (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。

インテリジェント メッセージ フィルタ タスクを実行する方法の詳細については、Exchange Server 2003 SP2 オンライン ヘルプの「Configure Intelligent Message Filtering」(英語) を参照してください。


メールボックス サーバーでインテリジェント メッセージ フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange インテリジェント メッセージ フィルタがサーバーにインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\ Software\Microsoft\Exchange\ContentFilter

Exchange Server アナライザは、ContentFilter レジストリ キーの ContentFilterBindings 値を読み取り、サーバーにインテリジェント メッセージ フィルタがインストールされ、有効になっているかどうかを判断します。

次に、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server オブジェクトの msExchAuthenticationFlags 属性値を判断します。msExchAuthenticationFlags 属性は、サーバーで許可される認証の種類を表します。以下の条件に当てはまる場合は、警告メッセージが表示されます。

  • msExchAuthenticationFlags 属性の認証が、サーバーへの匿名アクセスを許可するように構成されている。

  • そのサーバーでメールボックスもホストされている。

インテリジェント メッセージ フィルタは、迷惑な商用電子メール (UCE) である可能性が高いメッセージを識別します。ゲートウェイで Microsoft 以外の電子メール サーバーを使用している場合、効果的に UCE をフィルタ処理するには、Exchange ゲートウェイ サーバーまたは Exchange ブリッジヘッド サーバーにインテリジェント メッセージ フィルタを展開する必要があります。これらのゲートウェイ サーバーは、受信するインターネット電子メール メッセージを受け付け、これらのメッセージを適切なメールボックス サーバーに転送します。一般的に、ゲートウェイ サーバーではメールボックスをホストしません。

さらに、Exchange ゲートウェイ サーバー上でインターネット電子メール メッセージを受け付ける各 SMTP 仮想サーバーで、インテリジェント メッセージ フィルタを有効にする必要があります。

重要 :
インターネット ゲートウェイ SMTP 仮想サーバーでは、匿名アクセスを無効にしないでください。インターネットからのメールを受け付けるこれらの SMTP 仮想サーバーでは、匿名アクセスを許可する必要があります。

UCE をフィルタ処理するために、ゲートウェイと Exchange メールボックス ストアの両方で、受信メッセージに割り当てられる Spam Confidence Level (SCL) のしきい値を設定してインテリジェント メッセージ フィルタを構成することができます。インテリジェント メッセージ フィルタはそれぞれの受信メッセージを評価し、そのメッセージが UCE である可能性に基づいて、メッセージに SCL レベルを割り当てます。Exchange メールボックス サーバーは、そのメールボックス ストアに指定されている SCL のしきい値と設定を使用して、メッセージをユーザーの受信トレイに配信するか、迷惑メール フォルダに配信するかを判断します。

重要 :
インテリジェント メッセージ フィルタは、Exchange メールボックス サーバーにインストールする必要はありません。インテリジェント メッセージ フィルタがゲートウェイの SMTP 仮想サーバーにインストールされ、有効になっている場合、Exchange メールボックス サーバーは各受信メッセージと共に SCL レベルを受け取り、適切な動作を行います。

詳細については、Exchange Intelligent Message Filter Web サイト (http://go.microsoft.com/fwlink/?LinkId=28649) を参照してください。インターネット メールを送受信できる Microsoft Exchange Server 2003 組織の構成の詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。


サーバーでインテリジェント メッセージ フィルタが有効になっていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange インテリジェント メッセージ フィルタがサーバーにインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\ Software\Microsoft\Exchange\ContentFilter

ContentFilter レジストリ キーに ContentFilterBindings 値のエントリは存在するが、ContentFilterBindings 値が構成されていないことが検出されると、警告が表示されます。

注 :
ContentFilter レジストリ キーに ContentFilterBindings 値のエントリは存在するが、ContentFilterBindings 値が構成されていない場合は、このサーバーでインテリジェント メッセージ フィルタが有効になっていないことを示します。
重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Microsoft Exchange インテリジェント メッセージ フィルタは、迷惑な商用電子メール (UCD) である可能性が高いメッセージを識別します。受信電子メールを受け付ける Exchange ゲートウェイ サーバーまたは Exchange ブリッジヘッド サーバーにインテリジェント メッセージ フィルタを展開した後、インターネット電子メール メッセージを受け付ける各 SMTP 仮想サーバーでインテリジェント メッセージ フィルタを有効にする必要があります。

ContentFilter レジストリ キーを表示するには

  1. レジストリ エディタ (regedit) の詳細ペインで、[ContentFilter] を右クリックし、ContentFilterBindings の設定を表示します。

    注 :
    SMTP 仮想サーバーで Exchange インテリジェント メッセージ フィルタを構成していない場合は、ContentFilterBindings 値は NULL です。

    レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

インテリジェント メッセージ フィルタがインストールされているすべての Exchange サーバーで Exchange インテリジェント メッセージ フィルタを有効にすることをお勧めします。SMTP 仮想サーバーでインテリジェント メッセージ フィルタを有効にするには、次の手順を実行します。インテリジェント メッセージ フィルタを有効にした後で、レジストリの ContentFilter レジストリ キーの値を確認できます。

インテリジェント メッセージ フィルタを有効にするには

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. Exchange システム マネージャで、[サーバー]、[サーバー名]、[プロトコル]、[SMTP] の順に展開し、[インテリジェント メッセージ フィルタ] を右クリックして、[プロパティ] をクリックします。

  3. [全般] タブの [以下の IP アドレスを持つ仮想サーバーにインテリジェント メッセージ フィルタを適用します] の下で、インテリジェント メッセージ フィルタを有効にする各 SMTP 仮想サーバーの横にあるチェック ボックスをクリックします。

    [インテリジェント メッセージ フィルタのプロパティ] ダイアログ ボックス

詳細については、Exchange Intelligent Message Filter Web サイト (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


無効な受信者更新サービス サーバーが指定された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange アナライザ ツールは、Active Directory ディレクトリ サービスに対してクエリを実行し、ディレクトリ内の受信者更新サービス オブジェクトのそれぞれについて msExchAddressListServiceLink 属性の値を判断します。msExchAddressListServiceLink 属性は、アドレス一覧サービスから、受信者更新サービス (RUS) が実行されている Exchange Server コンピュータへのリンクです。

次に、Exchange アナライザ ツールは、CIM_Datafile WMI (Microsoft Windows® Management Instrumentation) クラスに対してクエリを実行し、特定された Exchange Server コンピュータのアドレス帳のビューおよび動的グループ サービス (abv_dg.dll) の Version キーの値を判断します。Version WMI キーは、このファイルのビルド番号を示しています。

特定されたコンピュータの中に、abv_dg.dll ファイルのビルド番号が 80 で始まるコンピュータがあることを Exchange アナライザが検出した場合には、エラーが表示されます。

このエラーは、RUS サーバーとして指定されたコンピュータが、Microsoft Exchange Server 2007 を実行していることを示します。

受信者更新サービスは、Exchange 2000 Server と Exchange Server 2003 の Exchange System Attendant サービスのコンポーネントです。Exchange 2000 と Exchange 2003 の受信者更新サービスにより、Active Directory に Exchange 固有の属性値が作成され、保持されます。この機能は Exchange 2007 の受信者作成プロセスで扱われるので、Exchange 2007 サーバーで実行されている場合、従来の受信者更新サービスは、更新処理を行いません。

このエラーに対処するには、受信者更新サービスをホストするよう Exchange 2000 Server または Exchange Server 2003 を指定します。

このエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [受信者] で、[受信者更新サービス] をクリックします。右側の移動ウィンドウで、受信者更新サービスの該当するインスタンスを右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[Exchange サーバー] の横の [参照] をクリックし、この RUS インスタンスを実行する新しい Exchange 2000 Server または Exchange Server 2003 サーバーを指定します。

  4. [OK] をクリックし、[OK] を再度クリックして、変更を有効にします。


処理中の分類の数が多い
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Cat: Categorizations in progress パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Cat: Categorizations in progress パフォーマンス カウンタは、処理中の分類の数を示します。

このクエリの場合、Exchange Server アナライザは 2 分間の間に 6 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの平均値を報告します。

サンプル期間中に、処理中の分類の平均数が 800 を超えたことを検出すると、Exchange Server アナライザはエラーを表示します。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

このエラーは、サーバーに非常に高い負荷が発生しているか、またはパフォーマンスに関する問題が発生していることを示す場合があります。

このエラーを解決するには、次の操作を行います。

  • カテゴライザにかかる負荷が、予想負荷によるものであるか、通常の負荷によるものであるかを調べます。カテゴライザにかかる負荷が予想負荷によるものである場合は、以下の Microsoft TechNet の文書を参照して、Exchange のパフォーマンスに関する指示を確認してください。

    • Exchange Server 2003 のパフォーマンスのトラブルシューティングに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47588)。

    • Exchange Server 2003 のパフォーマンスとスケーラビリティ ガイドに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576)。

  • カテゴライザにかかる負荷が予想負荷によるものではない場合は、ウイルスの発生やスパムによる負荷が発生していないか確認します。

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、マイクロソフト サポート技術情報の文書番号 231734 の、[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。


多数のメールボックスで配布グループによる配信の制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出されたすべてのドメイン内の各ユーザー オブジェクトについて次の属性を照会し、配布グループ メンバシップに基づいた配信の制限が設定されているメールボックスがドメイン内にあるかどうかを判断します。

dLMemDefault | 既定でメッセージを受信するか拒否するかを制御します。既定の設定である 1 に設定されている場合は、すべてのメッセージの受信が許可されます。
dLMemRejectPerms | この受信者への送信を許可されていないメンバの配布リスト (DL) の DN が含まれている。
dLMemSubmitPerms | この受信者への送信を許可されているメンバの配布リスト (DL) の DN が含まれている。

Exchange Server アナライザは、配布グループ メンバシップに基づいた配信の制限が設定されているメールボックスがドメイン内に 500 以上あると判断すると、エラーを表示します。

このエラーは、多数のメールボックスで配布グループ メンバシップに基づいた配信の制限が設定されていることが Exchange のメール フローのパフォーマンスに影響する可能性があることを示します。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

配布グループからのメッセージを受信または拒否するユーザーにメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに同じ DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

このエラーを修正するには、次の操作を行います。

  • 配布グループによる配信制限が設定されているユーザーを調べて、不要な制限を削除します。

  • マイクロソフト サポート技術情報の文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange Server 2003 SP2 より前のバージョンの Exchange を実行しているサーバーでは、Exchange Server 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。

  • 文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)。


混在モードの組織で、最小コストのルーティングが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、混在モード環境で Exchange Server Version 5.5 が実行されているサーバーで、最小コストのルーティングが有効になっているかどうかを判断します。以下の条件に当てはまる場合は、警告が表示されます。

  • 最小コストのルーティングが有効になっている。

  • Exchange Server 2003 を、Exchange Server 5.5 との混在モード環境で実行している。

混在モード環境で最小コストのルーティングが有効になっていると、メッセージ ループが作成される可能性があります。Exchange Server 2003 は、リンク状態によるルーティングを使用します。このため Exchange Server 2003 は、リンクが停止していることを検出すると、メッセージを別のサーバーに再ルーティングします。Exchange 5.5 サーバーで、[メッセージ転送エージェント プロパティ] プロパティ ページの [最小コストのルーティングのみ使用] チェック ボックスがオンになっている場合は、一般に、メッセージを送信してきたばかりの Exchange Server 2003 サーバーに戻るルートが最適であると判断されます。メッセージが Exchange Server 2003 サーバーに送り返されると、ルートがループになります。

Exchange Server 5.5 と Exchange Server 2003 の両方を実行している混在モードの組織では、Exchange Server 5.5 を実行しているすべてのサーバーで、最小コストのルーティング オプションを無効にすることをお勧めします。

Exchange Server 5.5 で最小コストのルーティングを無効にするには

  1. Microsoft Exchange 管理ツールで、[<組織名>] コンテナを展開し、[<サイト名>] コンテナを展開します。次に、[設定] コンテナを展開し、[サーバー] コンテナを展開して目的のサーバー オブジェクトをクリックします。

  2. 右側のペインで、[メッセージ転送エージェント] オブジェクトをクリックします。

  3. [ファイル] メニューの [プロパティ] をクリックします。

  4. [メッセージ転送エージェント プロパティ] ダイアログ ボックスの [全般] タブで、[最小コストのルーティングのみ使用] チェック ボックスをオフにします。

  5. [OK] をクリックします。


SMTP のリスニング ポートが既定の 25 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchServerBindings 属性の構成済みの値が既定値の 25 から変更されたかどうかを判断します。既定では、msExchServerBindings 属性は TCP ポート 25 に設定されます。この属性の値が 25 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchServerBindings 属性は、この SMTP (Simple Mail Transfer Protocol) サーバーが受信接続待ちを行う TCP ポートを表します。SMTP 仮想サーバーは、1 つ以上の TCP ポートで接続要求待ちを行うように構成できます。既定では、すべての SMTP 仮想サーバーが、TCP ポート 25 (既定の SMTP ポート) で接続要求待ちを行うように構成されます。SMTP のリスニング ポートが既定から変更されて、リスニング ポートの一覧に TCP ポート 25 が含まれなくなっていると、メールの流れが中断される可能性があります。

SMTP のリスニング ポートを変更しても問題がないのは、この変更に合わせて内部メッセージング インフラストラクチャの残りの部分も変更される場合のみです。ただし一般的に、インターネット上の SMTP サーバーはポート 25 を通してメッセージを送信するので、インターネットから直接メッセージを受け付ける SMTP 仮想サーバーで代わりのポートを使用することはできません。

Exchange Server アナライザは、Exchange の SMTP プロトコル仮想サーバーの値を確認することに注意してください。この SMTP プロトコル仮想サーバーは、インターネットから直接メッセージを受信する SMTP サーバーである場合とそうではない場合があります。ウイルス対策製品やスパム対策製品の中には、ポート 25 でインターネットからの SMTP メッセージを受信し、別のポートの Exchange SMTP 仮想サーバーにリダイレクトするように設計されているものがあります。この場合は、ポート 25 以外のポートで接続要求待ちを行う Exchange SMTP 仮想サーバーの構成を使用することができます。

SMTP 仮想サーバーのリスニング ポートを表示または変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブをクリックし、[詳細設定] をクリックします。

  4. IP アドレスとポートの一覧が表示されます。

    • 既存のポートを変更するには、IP アドレスを選択し、[編集] をクリックします。[TCP ポート] ボックスの値を 25 に変更します。

    • 追加のリスニング ポートとして 25 を追加するには、[追加] をクリックして、新しい IP アドレスとポートの組み合わせを追加します。接続、送信者、または受信者のフィルタを使用している場合は、必ず適切なチェック ボックスをオンにしてください。

  5. [OK] をクリックして変更を保存したら、[OK] をクリックして [詳細設定] ダイアログ ボックスを閉じます。[OK] をクリックして、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


[ローカル配信] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) ローカル配信キューの StateFrozen キーの値を判断します。

Exchange サーバー上のローカル配信キューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

ローカル配信キューには、Exchange Server メールボックスまたはパブリック フォルダ ストアへのローカル配信のために Exchange サーバー上のキューに格納されるメッセージが含まれています。

Exchange サーバーがローカル配信用のメッセージを受け付けていない場合は、メッセージがこのキューに蓄積されます。メッセージ配信が遅延したり途切れたりする場合は、メッセージのループまたはパフォーマンスの問題が発生していることを示している可能性があります。

このエラーを解決するには、MSExchangeTransport サービスの診断ログを増やし、カテゴライザ コンポーネントに関する情報を収集します。

ログの設定を変更する方法の詳細については、トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、ログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[ローカル配信] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) ローカル配信キューの StateRetry キーの値を判断します。

Exchange サーバー上のローカル配信キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があることに注意してください。

ローカル配信キューには、Exchange Server メールボックスまたはパブリック フォルダ ストアへのローカル配信のために Exchange サーバー上のキューに格納されるメッセージが含まれています。

Exchange サーバーがローカル配信用のメッセージを受け付けていない場合は、メッセージがこのキューに蓄積されます。メッセージ配信が遅延したり途切れたりする場合は、メッセージのループまたはパフォーマンスの問題が発生していることを示している可能性があります。

このエラーを解決するには、MSExchangeTransport サービスの診断ログを増やし、カテゴライザ コンポーネントに関する情報を収集します。

ログの設定を変更する方法の詳細については、トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、ログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


メール受信エラー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、次の手順に従って、SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにメッセージを送信しようとします。

  • Exchange Server アナライザが SMTP サーバーへのソケット接続を開きます。Exchange Server アナライザが、応答コード 220 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • Exchange Server アナライザが、EHLO SMTP コマンドを送信します。以下の条件に当てはまる場合は、この手順が正常に完了したと見なされます。

    • Exchange Server アナライザが一連の応答コード 250 を受信した。

    • これらの応答のいずれかに、250-X-LINK2STATE および 250-XEXCH50 が含まれている。

  • Exchange Server アナライザが、MAIL FROM:ExMFA-MailAcceptTest@Fabrikam.com SMTP コマンドを送信します。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • Exchange Server アナライザが、RCPT TO:Postmaster (またはユーザー定義アカウント)@<ドメイン名>.com SMTP コマンドを送信します。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

  • Exchange Server アナライザが、ピリオドで終了するサンプルのメッセージ本文を含む DATA SMTP コマンドを送信します。Exchange Server アナライザが、応答コード 250 を受け取った場合は、この手順が正常に完了したと見なすことができます。

Exchange Server アナライザがすべての手順を完了できない場合は、エラーが表示されます。エラーは、一般的なメール フローに問題が存在する可能性があることを示します。以下に、トラブルシーティングを行う際に役立つリンクを、サーバー レベルからネットワーク レベルまで、実行する順序に沿って示します。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?linkid=47579) の、ルーティングのトラブルシューティングに関するセクションを参照してください (このサイトは英語の場合があります)。

  2. Microsoft サポート技術情報の文書番号 324867「サポート: Microsoft Exchange 2000 Server: メール フロー (revisit された) 問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324867) を参照してください。

  3. Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489) を参照してください。

  4. Microsoft サポート技術情報の文書番号 324759「サポート: Microsoft Exchange 2000 Server: トランスポートでの DNS トラブルシューティング」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324759) を参照してください。

Exchange Server におけるポストマスタ アカウントの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 223860「[XCON] SMTP: ポストマスタ メールボックスは手動で設定する必要がある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=223860)

  • 文書番号 313832「[HOW TO] Exchange 2000 Server で SMTP ポストマスタ アカウントを設定する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313832)


メール受信エラー、BDAT コマンド
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、ESMTP (EHLO Extended Simple Mail Transfer Protocol) コマンドをリモート サーバーのポート 25 に送信し、応答を分析して、リモート サーバーが BDAT ESMTP コマンドをサポートしているかどうかを判断します。

BDAT コマンドに対する返信としてリモート サーバーから受信した応答に回復不能エラーが示されていない場合、Exchange Server アナライザはリモート サーバーにテスト メッセージを送信し、その応答を分析して、メッセージ転送が正常に行われたかどうかを判断します。

予期した "250" の応答文字列を受信しなかった場合、Exchange Server アナライザはエラーを表示します。

Exchange Server 2003 では、Exchange 固有の拡張 SMTP コマンドを使用して、組織内で Exchange Server を実行している他のサーバーと通信します。Exchange 固有の拡張 SMTP コマンドを使用して通信する方が、標準の SMTP を使用するよりも効率的です。ESMTP コマンド セットのサポートを無効にすると、Exchange Server のパフォーマンスが低下することがあります。

BDAT ESMTP コマンドは、DATA コマンドの代わりに使用できます。SMTP 仮想サーバーが EHLO キーワードに CHUNKING で応答した場合は、BDAT コマンドをサポートしており、メッセージのチャンクを受け付けることを示しています。このコマンドは、次の 2 つの引数を取ります。

  • 最初の引数は、バイナリ データ パケットの長さを示します。そのため、SMTP ホストがデータの最後まで連続してスキャンする必要はありません。受信側のサーバーは、メッセージのバイト数をカウントします。メッセージ サイズが BDAT コマンドで送信された値に等しくなったら、サーバーはすべてのメッセージ データを受信したと見なします。

  • 2 番目の引数は、データ パケットが現在の転送での最後のパケットであるかどうかを示します。2 番目の引数は省略可能です。

このエラーは、リモート サーバーで BDAT ESMTP コマンドがサポートされているにもかかわらず、その後の BDAT メール受信テストに失敗したことを示します。

このエラーを解決するには、メッセージング環境に BDAT コマンドをブロックしている問題や構成がないか確認します。その例を次に示します。

  • 一時的なネットワーク停止

  • SMTP プロキシ

  • ファイアウォール

  • アプリケーション

これらのコマンドの既定のサポートを削除または復元する方法の詳細については、マイクロソフト サポート技術情報の文書番号 257569 の、Exchange 2000 Server および Exchange Server 2003 で ESMTP コマンドをオフにする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=257569) を参照してください。

Exchange Server で ESMTP コマンドを使用する方法の詳細については、Exchange Server のトランスポートおよびルーティングに関するガイドの、Exchange SMTP を正しく読み込む方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=71800) を参照してください 。


共通の宛先として識別されたメールボックス ストア
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | キューの存在する仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、 Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信のタイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは取得したこれらのデータを使用して、各 Recipient オブジェクトの以下の値について、Active Directory® ディレクトリ サービスに対してクエリを実行します。次に、Exchange Server アナライザは、受信者が、ユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判別します。

distinguishedName | オブジェクトの識別名を示します。
msExchHomeServerName | この受信者が配置されているサーバーを示します。
homeMDB | 受信者のメールボックス ストアを示します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先の受信者のメールボックスが同一メールボックス ストアに配置されていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先の受信者のメールボックスが同一メールボックス ストアに配置されていると判断すると、Exchange Server アナライザはエラーを表示します。

この警告またはエラーは、識別されたメールボックス ストアが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、次に示すように対象のメールボックス ストアを調査して、メッセージがキューに入る原因となる構成の問題またはその他の異常点を見つける必要があります。

  • ストア オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • ストア オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • メールボックス ストアが特別な用途のユーザー オブジェクトに、つまり指定された履歴保持用の受信者に使用するストアである場合は、そのユーザー オブジェクトが関連付けられているサービスまたはコンポーネントの構成が正しいことを確認します。

  • ストアの受信者に対する迷惑な商用電子メール メッセージ (UCE)、スパム、またはウイルス攻撃の可能性を調べます。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=67875) (英語)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)


[配信先に到達できないメッセージ] キューにメッセージが保持されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、サーバー上の SMTP (Simple Mail Transfer Protocol) キューの TypeCurrentlyUnreachable、LinkName、および NumberofMessages プロパティの値を判断します。

True に設定されている場合、TypeCurrentlyUnreachable プロパティは、現在到達できない宛先のメッセージをリンク (Exchange キュー) が保持するよう指定します。

LinkName プロパティはリンクの名前を指定します。

NumberOfMessages プロパティは、リンク間の転送を待機するメッセージ数を指定します。

Exchange Server アナライザは、[配信先に到達できないメッセージ] SMTP キューにメッセージが含まれることを判別すると、エラーを表示します。

このエラーは、目的のサーバーに到達できないメッセージがキューにあることを示します。たとえば、Exchange で最終的な宛先へのルートまたはコネクタを判断できない場合などです。または、利用可能なルートまたはコネクタがすべて停止としてマークされている場合です。

このエラーに対処するには、次の操作を行います。

  • [配信先に到達できないメッセージ] キューにあるメッセージが正当かどうかを確認します。

  • Exchange Server アナライザによって提供された、エラーに対する指示およびリンクを確認します。

  • 以下の「詳細情報」の指示に従います。

詳細情報

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドに関するページ のメール フローと SMTP のトラブルシューティングについての説明 (http://go.microsoft.com/fwlink/?linkid=47579) (英語)

  • マイクロソフト サポート技術情報の文書番号 823489 のキュー ビューアを使用してメール フローの問題をトラブルシューティングする方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)


[配信先に到達できないメッセージ] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の ExchangeLink クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) の [配信先に到達できないメッセージ] キューの StateFrozen キーの値を判断します。

Exchange サーバー上の[配信先に到達できないメッセージ] キューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、トランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。

[配信先に到達できないメッセージ] キューには、目的のサーバーに到達できないメッセージが含まれています。たとえば、Exchange で最終的な宛先へのルートまたはコネクタを判断できない場合などです。または、利用可能なルートまたはコネクタがすべて停止としてマークされている場合です。以下の条件のいずれかに当てはまる場合に、メッセージがこのキューに蓄積されます。

  • メッセージ配信のルートが存在しない。

  • Exchange コネクタまたはリモート配信キューが使用できない。

  • Exchange コネクタまたはリモート配信キューが再試行状態であり、そのコネクタまたはリモート配信先への利用可能な代替ルートが存在しない場合に、新しいメッセージがこのキューに移動される。

このエラーに対処するには、各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更します。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続が直ちに有効になります。このエラーが引き続き発生する場合は、以下の「詳細情報」で説明するとおりに、キュー エンジンの診断ログのレベルを上げてください。

詳細情報

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイド のメールの流れと SMTP に関するトラブルシューティングに関するセクションにある MSExchangeTransport のログ出力の設定を変更する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドのメールの流れと SMTP に関するトラブルシューティングのページ (http://go.microsoft.com/fwlink/?LinkId=47579)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • マイクロソフト サポート技術情報の記事 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • マイクロソフト サポート技術情報の記事 264054 の、[XCON] Exchange 2000 サーバーのキュー状態の理解に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[配信先に到達できないメッセージ] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) [配信先に到達できないメッセージ] キューの StateRetry キーの値を判断します。

Exchange サーバー上の [配信先に到達できないメッセージ] キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

[配信先に到達できないメッセージ] キューには、目的のサーバーに到達できないメッセージが含まれています。たとえば、Exchange で最終的な宛先へのルートまたはコネクタを判断できない場合などです。または、利用可能なルートまたはコネクタがすべて停止としてマークされている場合です。以下の条件のいずれかに当てはまる場合に、メッセージがこのキューに蓄積されます。

  • メッセージ配信のルートが存在しない。

  • Exchange コネクタまたはリモート配信キューが使用できない。

  • Exchange コネクタまたはリモート配信キューが再試行状態であり、そのコネクタまたはリモート配信先への利用可能な代替ルートが存在しない場合に、新しいメッセージがこのキューに移動される。

このエラーを修正するには、[再接続] コマンドを使用して、再試行の状態にあるキューをアクティブの状態に変更します。これにより、キューは再試行間隔が経過したかのように機能します。ただし、この方法は、常に機能するとは限りません。このエラーが引き続き発生する場合は、以下の「詳細情報」で説明するとおりに、キュー エンジンの診断ログのレベルを上げてください。

詳細情報

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイド のメールの流れと SMTP に関するトラブルシューティングに関するセクションにある MSExchangeTransport のログ出力の設定を変更する方法に関する説明 (http://go.microsoft.com/fwlink/?LinkId=47579) (英語) を参照してください。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドに関するページ のメール フローと SMTP のトラブルシューティングについての説明 (http://go.microsoft.com/fwlink/?linkid=47579) (英語)

  • マイクロソフト サポート技術情報の文書番号 823489 のキュー ビューアを使用してメール フローの問題をトラブルシューティングする方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • マイクロソフト サポート技術情報の文書番号 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)。

  • マイクロソフト サポート技術情報の文書番号 264054 の、[XCON]Exchange 2000 サーバーのキューの状態についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)。


配布グループの配信制限が設定されたメールボックス
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスにあるすべてのドメイン内の各ユーザー オブジェクトの以下の属性に対してクエリを実行し、ドメイン内のメールボックスが、配布グループのメンバシップに基づいて配信制限が設定されているかどうかを判断します。

dLMemDefault | 既定でメッセージを受信するか拒否するかを制御します。既定の設定である 1 に設定されている場合は、すべてのメッセージの受信が許可されます。
dLMemRejectPerms | この受信者への送信を許可されていないメンバの配布リスト (DL) の DN が含まれている。
dLMemSubmitPerms | この受信者への送信を許可されているメンバの配布リスト (DL) の DN が含まれている。

Exchange Server アナライザは、ドメイン内に配布グループのメンバシップに基づいた配信制限が設定されたメールボックスが存在すると判断すると、警告を表示します。

この警告は、配布グループのメンバシップに基づいた配信制限が Exchange Server のメール フローのパフォーマンスに影響を与える可能性があることを示します。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

配布グループからのメッセージを受信または拒否するユーザーにメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに同じ DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

この警告に対処するには、次の操作を行います。

  • 配布グループによる配信制限が設定されているユーザーを調べて、不要な制限を削除します。

  • マイクロソフト サポート技術情報の文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange Server 2003 SP2 より前のバージョンの Exchange を実行しているサーバーでは、Exchange Server 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。

  • 文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)。


最大受信メッセージ サイズが設定されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の delivContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Global Settings, CN=Message Delivery

delivContLength 属性の値が 1 より小さいことが検出されると、エラーが表示されます。

このエラーは、最大受信メッセージ サイズの制限値が設定されていないことを示します。組織のネットワーク帯域幅とユーザー要件によっては、メッセージ サイズを制限することをお勧めします。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。Exchange Server 2003 のこの既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange2000 Server からのアップグレードに適用されます。

メッセージ サイズの制限値として、ユーザーがサイズの大きな電子メール メッセージを送受信できないようにする値を設定することにより、システム リソースを節約できます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、最大サイズをテキスト ボックスに KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織の送信者は、指定のサイズ制限を超えるメッセージをユーザーに送信すると、NDR を受信することになります。[インターネット メッセージ形式] で構成した NDR 設定によっては、外部の送信者が NDR を受信できない場合があります。

Exchange Server 2007 では、Exchange 管理シェルを使用して、Exchange 組織の TransportConfig MaxReceiveSize パラメータを設定できます。

最大メッセージ サイズの制限値は、10 MB 以下に設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、受信メッセージの最大サイズの制限を 30 MB に増やすこともできます。メッセージ サイズの制限値を 30 MB を超える値に設定すると、ネットワーク パフォーマンスが低下する可能性があります。さらには、システムがセキュリティ攻撃を受けやすくなる場合もあります。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開します。次に、[メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[受信メッセージ サイズ] の [最大サイズ (KB)] オプションをクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxReceiveSize <size>

たとえば、Exchange 組織の受信者によって受信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize 10MB

Exchange 組織のユーザーによって受信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の記事「Exchange Server でメッセージ サイズの制限を設定する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

  • Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、Exchange Server 2003 管理ガイドの SMTP ポリシーを使用した送信メールの形式と自動応答の制御についての説明 (http://go.microsoft.com/fwlink/?LinkId=47617) (英語) を参照してください。


最大受信メッセージ サイズの設定が大きすぎる (30MB より大きい)
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-02-27

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の delivContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Global Settings, CN=Message Delivery

delivContLength 属性の値が 30720 より大きいことが検出されると、エラーが表示されます。

このエラーは、受信メッセージの最大サイズの制限値が、30 MB より大きい値に設定されていることを示します。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。この既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange 2000 Server からのアップグレードに適用されます。

メッセージ サイズの制限値として、ユーザーがサイズの大きな電子メール メッセージを送受信できないようにする値を設定することにより、システム リソースを節約できます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、テキスト ボックスに最大サイズを KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織の送信者は、指定のサイズ制限を超えるメッセージをユーザーに送信すると、配信不能レポート (NDR) を受信することになります。[インターネット メッセージ形式] で構成した NDR 設定によっては、外部の送信者が NDR を受信できない場合があります。

Exchange Server 2007 では、Exchange 管理シェルを使用して、Exchange 組織の TransportConfig MaxSendSize パラメータを設定できます。

最大メッセージ サイズの制限値は、30 MB 以下に設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、受信メッセージの最大サイズの制限を 30 MB より大きくすることもできます。メッセージ サイズの制限値を 30 MB を超える値に設定すると、ネットワーク パフォーマンスが低下する可能性があります。さらには、システムがセキュリティ攻撃を受けやすくなる場合もあります。

重要 :
同じように見えますが、以下の設定の結果は、Exchange 2000 Server および Exchange Server 2003 のみの環境と Exchange Server 2007 環境とでは大きく異なります。

Exchange 2000 Server および Exchange Server 2003 のみの環境においてメールボックスが有効なユーザーのグローバル設定に対し、送信および受信メッセージ サイズ制限の値を 0 に設定すると、メッセージ サイズ制限が完全に解除されます。

Exchange 2007 のみの環境で TransportConfig -MaxSendSize と TransportConfig -MaxreceiveSize パラメータの値を 0 に設定すると、サイズにかかわらずメッセージの送信が制限されます。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開します。次に、[メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[受信メッセージ サイズ] の [最大サイズ (KB)] オプションをクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxReceiveSize <size>

たとえば、Exchange 組織の受信者によって受信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize 10MB

Exchange 組織のユーザーによって受信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、マイクロソフト サポート技術情報の文書番号 322679「Exchange Server でメッセージ サイズの制限を設定する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、『Administration Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47617) の「Configuring SMTP Policies to Control Outbound Mail Formatting and Automatic Responses」を参照してください (このサイトは英語の場合があります)。


最大受信メッセージ サイズの設定が小さすぎる (1MB より小さい) 可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の delivContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Global Settings, CN=Message Delivery

delivContLength 属性の値が 0 より大きく、1024 より小さいことが検出されると、エラーが表示されます。

このエラーは、受信メッセージの最大サイズの制限が 1 MB より小さい値に設定されていることを示します。これほど小さな値に制限されていると、組織に送信されてきたメッセージの一部を Exchange Server が受け付けられなくなる可能性があります。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。この既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange 2000 Server からのアップグレードに適用されます。

メッセージ サイズの制限値として、ユーザーがサイズの大きな電子メール メッセージを送受信できないようにする値を設定することにより、システム リソースを節約できます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、テキスト ボックスに最大サイズを KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織の送信者は、指定のサイズ制限を超えるメッセージをユーザーに送信しようとすると NDR を受信します。[インターネット メッセージ形式] で構成した NDR 設定によっては、外部の送信者が NDR を受信できない場合があります。

Exchange Server 2007 では、Exchange 管理シェルを使用して、Exchange 組織の TransportConfig MaxSendSize パラメータを設定できます。

最大メッセージ サイズの制限値は、10 MB 以下に設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、受信メッセージの最大サイズの制限を 30 MB に増やすこともできます。メッセージ サイズの制限値を 30 MB を超える値に設定すると、ネットワーク パフォーマンスが低下する可能性があります。さらには、システムがセキュリティ攻撃を受けやすくなる場合もあります。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開します。次に、[メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[受信メッセージ サイズ] の [最大サイズ (KB)] オプションをクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxReceiveSize <size>

たとえば、Exchange 組織の受信者によって受信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize 10MB

Exchange 組織のユーザーによって受信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxReceiveSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679「Exchange Server でメッセージ サイズの制限を設定する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、Exchange Server 2003 管理ガイドの SMTP ポリシーを使用した送信メールの形式と自動応答の制御についての説明 (http://go.microsoft.com/fwlink/?LinkId=47617) (英語) を参照してください。


MaxDSNSize が設定されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、配信状態通知 (DSN) メッセージの最大サイズが設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MaxDSNSize

また、Exchange Server アナライザは Active Directory® ディレクトリ サービスに対してもクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。文字列値に "Version 5.5" が含まれている場合、コンピュータは Microsoft Exchange Server 5.5 を実行しています。文字列値に "Version 6.0" が含まれている場合、コンピュータでは Microsoft Exchange 2000 Server が実行されています。文字列値に "Version 6.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 2003 が実行されています。

Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータに、MaxDSNSize レジストリ値が存在しないことが検出されると、警告が表示されます。

MaxDSNSize レジストリ値は、DSN のサイズを制限する Exchange Server のオプションの値です。このオプションは、メッセージの配信が不能な場合に添付ファイルを削除するように Exchange を構成します。このレジストリ値を追加する場合は、値として 10240000 (10 GB) を使用することをお勧めします。

注 :
MaxDSNSize レジストリ値は、Exchange 2000 Server の Service Pack 2 (SP2) で導入されたため、値を機能させるには Exchange 2000 Server SP2 以降のバージョンが必要です。また、Exchange Server 2003 の Service Pack 1 以降のバージョンでは、MaxDSNSize レジストリ値がない場合には、値として 10 MB が使用されます。必要な場合は、MaxDSNSize レジストリ値を追加して、この既定の動作を変更することができます。

このオプションを有効にすると、サーバーとネットワークのリソースを節約できます。ただし、SMTP (Simple Mail Transfer Protocol) 添付ファイルを取り除くこの実装には欠点があります。このオプションを有効にして、配信不能レポート (NDR) から添付ファイルを取り除いた場合、閲覧ウィンドウに通知を表示するために必要な詳細情報も取り除かれており、メッセージの発信者は、[再送信] オプションを使用することができません。メッセージの発信者が NDR から再送信オプションを使用しようとすると、次のエラー メッセージが表示されます。"このメッセージを再送信できません。配信不可通知に元のメッセージに関する十分な情報が含まれていません。メッセージを再送信するには、送信済みアイテム フォルダの再送信するメッセージを開き、[アクション] メニューの [このメッセージを再送] をクリックします。"

しかし、メッセージの発信者は、エラー メッセージで指示された方法に従ってもメッセージを再送することができません。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc

  3. [SMTPSvc] を右クリックし、[新規] をポイントします。次に、[キー] をクリックします新しいキーの名前は Queuing にして、クラスは空のままにします。

  4. [Queuing] を右クリックし、[新規] をポイントします。次に、[DWORD 値] をクリックします。新しい値の名前は MaxDSNSize にします。

  5. 右側のペインで、[MaxDSNSize] レジストリ値をダブルクリックし、必要なサイズの制限 (バイト単位) を [値のデータ] ボックスに入力します。この値より大きいメッセージによって NDR が生成された場合、メッセージからは添付ファイルやメッセージのプロパティ全体が返されません。

  6. レジストリ エディタを終了し、SMTP (Simple Mail Transfer Protocol) サービスを再開して変更を有効にします。

MaxDSNSize のレジストリ設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 308303「[XCON] NDR を生成するメッセージの添付ファイルを取り除くオプション」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308303)

  • 文書番号 323484「[XCON] Exchange 2000 の multipart/report インターネット メッセージ形式の説明 」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=323484)


送信メッセージの最大サイズが設定されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の submissionContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Global Settings, CN=Message Delivery

submissionContLength 属性の値が 1 未満であることが検出されると、エラーが表示されます。

このエラーは、送信メッセージの最大サイズの制限が設定されていないことを示します。組織のネットワーク帯域幅とユーザーの要件に基づいて、メッセージ サイズを制限することをお勧めします。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。この既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange 2000 Server からのアップグレードに適用されます。

メッセージ サイズの制限値として、ユーザーがサイズの大きな電子メール メッセージを送受信できないようにする値を設定することにより、システム リソースを節約できます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、最大サイズをボックスに KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織の送信者は、指定のサイズ制限を超えるメッセージをユーザーに送信すると、NDR を受信することになります。外部の送信者は、[インターネット メッセージ形式] で構成した NDR 設定に応じて、NDR を受信する場合としない場合があります。

Exchange Server 2007 については、Exchange Management Shell を使用して、Exchange 組織の TransportConfig MaxSendSize パラメータを設定できます。

メッセージの最大サイズの制限は、10 MB を超えないように設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、送信メッセージの最大サイズの制限を 30 MB に増やすこともできます。メッセージ サイズの制限値を 30 MB を超えて大きくすると、ネットワークのパフォーマンスが低下する可能性があり、セキュリティの攻撃に対するシステムの脆弱性が高まるおそれもあります。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開し、[メッセージ配信] を右クリックします。次に、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[送信メッセージ サイズ] の [最大サイズ] をクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトの範囲で、B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxSendSize <size>

たとえば、Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize 10MB

Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679 の Exchange Server でメッセージ サイズの制限を設定する方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

  • Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、Exchange Server 2003 管理ガイドの送信メールの書式設定と自動応答を制御する SMTP ポリシーの構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47617) (英語) を参照してください。


最大送信メッセージ サイズの設定が大きすぎる (30 MB より大きい)
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の submissionContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=組織名, CN=Global Settings, CN=Message Delivery

submissionContLength 属性の値が 30720 より大きいことが検出されると、エラーが表示されます。

このエラーは、最大送信メッセージ サイズの制限値が 30 メガバイト (MB) を超える値に設定されていることを示しています。組織のネットワーク帯域幅とユーザー要件によっては、メッセージをさらに小さいサイズに制限することをお勧めします。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。この既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange 2000 Server からのアップグレードに適用されます。

メッセージ サイズ制限を設定して、ユーザーが大きな電子メール メッセージの送受信を行えないようにすることにより、システム リソースを節約することができます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、テキスト ボックスに最大サイズを KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織の送信者は、指定のサイズ制限を超えるメッセージをユーザーに送信すると、NDR を受信することになります。外部の送信者は、[インターネット メッセージ形式] で構成した NDR 設定に応じて、NDR を受信する場合としない場合があります。

Exchange Server 2007 については、Exchange Management Shell を使用して、Exchange 組織の TransportConfig MaxSendSize パラメータを設定できます。

メッセージの最大サイズの制限は、10 MB を超えないように設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織全体に送信するためにメッセージ サイズ制限値を大きくする必要がある場合は、最大送信メッセージ サイズの制限値を 30 MB にすることができます。メッセージ サイズの制限値を 30 MB を超えて大きくすると、ネットワークのパフォーマンスが低下する可能性があり、セキュリティの攻撃に対するシステムの脆弱性が高まるおそれもあります。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開します。次に、[メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[送信メッセージ サイズ] の [最大サイズ] をクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトを B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxSendSize <size>

たとえば、Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize 10MB

Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679 の Exchange Server でメッセージ サイズの制限を設定する方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、Exchange Server 2003 管理ガイドの SMTP ポリシーを使用した送信メールの形式と自動応答の制御についての説明 (http://go.microsoft.com/fwlink/?LinkId=21769) を参照してください。


最大送信メッセージ サイズが小さすぎる可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の場所にあるグローバル設定の submissionContLength 属性の値を判断します。

CN=Configuration, CN=Services, CN=Microsoft Exchange, CN= <組織名> , CN=Global Settings, CN=Message Delivery

submissionContLength 属性の値が 1024 より小さく 0 より大きいことが検出されると、警告が表示されます。

この警告は、送信メッセージの最大サイズの制限が 1 MB より小さい値に設定されていることを示しています。組織のネットワーク帯域幅やユーザー要件によっては、大きなメッセージに対応できるようにメッセージ サイズを増やすことをお勧めします。Exchange 2000 Server と Exchange Server 2007 の場合、既定のメッセージ サイズ制限値はありません。Exchange Server 2003 では、送信および受信メッセージの既定のサイズ制限は 10,240 KB です。この既定のサイズ制限は、新規インストールと、メッセージ サイズ制限のない Exchange 2000 Server からのアップグレードに適用されます。

メッセージ サイズの制限値として、ユーザーがサイズの大きな電子メール メッセージを送受信できないようにする値を設定することにより、システム リソースを節約できます。これにより、ネットワーク トラフィックを制限し、ディスク容量を節約して、全体的なネットワーク パフォーマンスを向上させることができます。Exchange 2000 Server と Exchange Server 2003 については、[グローバル設定] の [メッセージ配信のプロパティ] にある [既定] タブを使用すると、受信メッセージと送信メッセージについて、メッセージ配信の制限を指定できます。各メッセージの最大サイズを設定するには、[最大サイズ (KB)] をクリックし、テキスト ボックスに最大サイズを KB 単位で入力します。メッセージのサイズを制限しない場合は、[制限なし] をクリックします。組織内の送信者は、指定されたサイズ制限を超えるメッセージをユーザーに送信すると、配信不能レポート (NDR) を受信することになります。外部の送信者は、[インターネット メッセージ形式] で構成した NDR 設定に応じて、NDR を受信する場合としない場合があります。

Exchange Server 2007 については、Exchange Management Shell を使用して、Exchange 組織の TransportConfig MaxSendSize パラメータを設定できます。

メッセージの最大サイズの制限は、30 MB を超えないように設定することをお勧めします。ただし、サイズの大きいファイルが添付されたメッセージを Exchange 組織を通して送信するためにメッセージ サイズの制限値を大きくする必要がある場合は、送信メッセージの最大サイズの制限を 30 MB より大きい値に増やすこともできます。メッセージ サイズの制限値を 30 MB を超えて大きくすると、ネットワークのパフォーマンスが低下する可能性があり、セキュリティの攻撃に対するシステムの脆弱性が高まるおそれもあります。

Exchange 2000 Server と Exchange Server 2003 にメッセージ サイズの制限を設定するには

  1. Exchange システム マネージャで、[グローバル設定] を展開します。次に、[メッセージ配信] を右クリックし、[プロパティ] をクリックします。

  2. [メッセージ配信のプロパティ] ダイアログ ボックスの [既定] タブで、[送信メッセージ サイズ] の [最大サイズ] をクリックし、必要なサイズの制限値を入力します。

Exchange Server 2007 にメッセージ サイズの制限を設定するには

  1. Exchange Management Shell で、次のコマンドを実行します。<size> には、既定の「unlimited」か、0 ～ 2147483647 バイトの範囲で、B (バイト)、KB (キロバイト)、または MB (メガバイト) の単位で表したサイズを入力します。
コードのコピー
Set-TransportConfig -MaxSendSize <size>

たとえば、Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを 10 MB に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize 10MB

Exchange 組織のユーザーによって送信可能な最大メッセージ サイズを既定の無制限に設定するには、次のように入力します。

コードのコピー
Set-TransportConfig -MaxSendSize unlimited
  • Exchange 2000 Server と Exchange Server 2003 のメッセージ サイズ制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 322679 の Exchange Server でメッセージ サイズの制限を設定する方法についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=322679) を参照してください。

Exchange Server 2007 の TransportConfig コマンドレットの詳細については、Exchange Server 2007 テクニカル リファレンスの TransportConfig の設定についてのページ (http://go.microsoft.com/fwlink/?LinkID=79237) (英語) を参照してください。

  • インターネット メッセージ形式の詳細については、Exchange Server 2003 管理ガイドの送信メールの書式設定と自動応答を制御する SMTP ポリシーの構成についての説明 (http://go.microsoft.com/fwlink/?LinkId=47617) (英語) を参照してください。


メッセージのみの履歴保持が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchMessageJournalRecipient 属性がメールを受信者メールボックスにコピーするように構成されているかどうかを判断します。msExchMessageJournalRecipient 属性は、Active Directory 内のメールボックス ストア オブジェクトの属性です。既定では、msExchMessageJournalRecipient 属性は構成されていません。Exchange Server アナライザによって、msExchMessageJournalRecipient 属性が構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。このとき、メッセージのみのジャーナリングが有効になっているデータベース名およびサーバー名も表示されます。

Exchange Server 2003 のメッセージのみの履歴保持、または Exchange Server 2007 の標準のジャーナリングでは、メールボックス データベース上のユーザーが送受信したすべてのメッセージとそれに対応する P2 メッセージ ヘッダー データのコピーが作成され、そのメッセージ コピーが特定のメールボックスに送信されます。P2 メッセージ ヘッダーには、送信者が受信者に対して公表したメッセージ受信者データのみが含まれます。インターネットから外部メッセージが受信されると、Exchange Server は P1 メッセージ ヘッダーをジャーナル処理します。P1 メッセージ ヘッダーは、メッセージ転送エージェント (MTA) がメールをルーティングするために使用するアドレス情報です。既定では、メッセージのみのジャーナリングが有効になっていると、BCC 受信者、トランスポートの転送ルールに従ってルーティングされている受信者、または別のサーバーに拡張された配布グループのメンバである受信者については記録が残りません。また、開封通知や不在通知などの MAPI レポート メッセージもアーカイブしません。

ジャーナリング メッセージによって、ディスク、ネットワーク、CPU リソースなどの消費が増える場合があります。このため、ジャーナリングを行う際は十分な展開計画が必要です。ジャーナリングは、総合的なジャーナリング ソリューション フレームワークを展開するケースにおいてのみ有効にしてください。

以下の条件に当てはまる場合は、既定以外の構成を示すこのメッセージを無視してかまいません。

  • 業務上、ジャーナリングが必要である。

  • ジャーナリング ソリューション フレームワークを既に展開している。

これらの状況に該当しない場合は、ジャーナリング機能を無効にする必要があります。

Exchange 2000 Server および Exchange Server 2003 のデータベースでメッセージのみの履歴保持を無効にするには、次の操作を行います。

  1. Exchange システム マネージャで、[サーバー] を展開し、[<使用している Exchange サーバー>] を展開します。次に、[<ストレージ グループ>] を展開し、メールボックス ストアを右クリックします。

  2. [全般] タブで、[このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] チェック ボックスをオフにします。

  3. Exchange ストアに変更が適用されるまで 15 分待ちます。Microsoft Exchange Information Store サービスを再開する必要はありません。
Exchange Server 2007 のデータベースで標準のジャーナリングを無効にするには、次の操作を行います。

  1. Exchange Server 2007 の製品ドキュメントのメールボックスごとのデータベースのジャーナリングを無効にする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=80889) の手順に従ってください (このサイトは英語の場合があります)。

Exchange Server 2003 における履歴保持ソリューションの展開方法の詳細については、Exchange Server 2003 の履歴についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 におけるジャーナリング ソリューションの展開方法の詳細については、ジャーナリングの概要についてのページ (http://go.microsoft.com/fwlink/?LinkId=80820) を参照してください (このサイトは英語の場合があります)。


メッセージ ルーティングのループが存在する可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 SMTP (Simple Mail Transfer Protocol) 仮想サーバーの msExchAlternateServer 属性値を判断します。また、組織のいずれかの受信者ポリシーに msExchNonAuthoritativeDomains 属性が構成されているかどうかも判断します。以下の条件に当てはまる場合は、警告が表示されます。

  • msExchAlternateServer 属性のインスタンスが設定されている。

  • いずれかの受信者ポリシーに msExchNonAuthoritativeDomains 属性が設定されている。

これらの構成によりメッセージ ループが発生する場合があるため、Exchange Server アナライザによって警告が表示されます。1 つの組織内で異なるメッセージング システムが一緒に動作するように構成されていると、メッセージ ループが発生する場合があります。このシナリオでは、Exchange Server 受信者ポリシーと SMTP 構成が、異種のメッセージング システムにわたって存在するユーザー グループへのメッセージのルーティングと配信を行うために使用されています。

msExchAlternateServer 属性は、SMTP 仮想サーバーのプロパティ ページにある [解決できない受信者を含むメールの転送先ホスト] ボックスにアドレスを指定した場合に設定されます。

msExchNonAuthoritativeDomains 属性は、特定の受信者ポリシーの SMTP アドレスのプロパティ ページにある [このアドレスへのメール配信すべてに、この Exchange 組織を使用する] チェック ボックスをオフにした場合に設定されます。

したがって、[このアドレスへのメール配信すべてに、この Exchange 組織を使用する] チェック ボックスをオフにして SMTP ドメインを権限がない状態に設定し、かつ、いずれかの SMTP 仮想サーバー上で解決できない受信者用のアドレスを指定していると、Exchange Server アナライザによって警告が表示されます。ただし、この警告が表示されても、必ずしも組織内にメッセージ ループが存在することを示しているわけではない点に注意してください。

権限のないドメインが存在し、かつ組織内の少なくとも 1 台のサーバーに msExchAlternateServer が設定されていると、メッセージ ルーティングのループが存在する可能性があります。次の条件が満たされているかどうかを確認する必要があります。

  • 組織内のすべてのドメインについて、権限のあるドメインが存在している。

  • 解決できないすべてのメッセージが権限のあるドメインで処理されるように SMTP 仮想サーバーが構成されている。

特に、ドメイン名を別の組織と共有している場合は、そのドメイン名前空間に対する受信パスが 1 つだけになるように設定することをお勧めします。ループが発生しないように、そのドメインに関して 1 台のメール サーバーまたは 1 つのメール システムだけが権限を持つようにする必要があります。権限のあるサーバーは、受信パス上の最後のシステムになるように設定する必要があります。

どのシステムが最初に受信するかは重要ではありません。また、最初に受信するシステムが 3 つ以上あるかどうかも重要ではありません。重要なのは、最後の宛先が 1 つのシステムだけであることです。

msExchAlternateServer 属性を変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、[<サーバー名>] を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  3. SMTP 仮想サーバーのプロパティ ダイアログ ボックスで、[メッセージ] タブをクリックします。

  4. [解決できない受信者を含むメールの転送先ホスト] ボックスに、未解決のメールを受信するサーバーの FQDN を入力します。サーバーの IP アドレスを角かっこ ([ ]) で囲んで入力することもできます。

  5. [OK] をクリックします。
msExchNonAuthoritativeDomains 属性を変更するには

  1. Exchange システム マネージャで、[受信者] を展開し、[<受信者ポリシー名>] をダブルクリックします。

  2. [電子メール アドレス (ポリシー)] タブで、SMTP アドレスをダブルクリックします。

  3. [SMTP アドレスのプロパティ] ページで、[このアドレスへのメール配信すべてに、この Exchange 組織を使用する] チェック ボックスをオンにすると msExchNonAuthoritativeDomains 属性がクリアされます。このチェック ボックスをオフにすると、[アドレス] ボックスで指定された SMTP アドレスに msExchNonAuthoritativeDomains 属性が設定されます。

SMTP アドレス空間の共有の詳細については、Microsoft サポート技術情報の文書番号 321721「[XCON] Exchange 2000 で SMTP アドレス スペースを共有する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321721) を参照してください。

インターネット接続に関する展開シナリオの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Deployment Scenarios for Internet Connectivity」を参照してください (このサイトは英語の場合があります)。


[ディレクトリ参照待ちのメッセージ] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) のディレクトリ参照待ちのメッセージキューの StateFrozen キーの値を判断します。

Exchange Server アナライザによって、Exchange サーバー上のディレクトリ参照待ちのメッセージキューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

ディレクトリ参照待ちのメッセージ キューには、Active Directory® ディレクトリ サービスに対してまだ解決されていない受信者へのメッセージが格納されます。メッセージはまた、配布リストが展開されている間もこのキューに保持されます。

一般に、メッセージがこのキュー内に蓄積される状態は、アドバンスド キュー エンジンがそのメッセージを分類できないことが原因です。アドバンスド キュー エンジンがグローバル カタログ サーバーにアクセスできず、受信者情報にアクセスできない状態になっている可能性があります。あるいは、グローバル カタログ サーバーが到達不能か、またはパフォーマンスが低下しています。さらに、以下の理由でメッセージが蓄積される場合もあります。

  • Active Directory が使用不可能である。

    注 :
    カテゴライザは Active Directory を使用してメッセージを分類します。
  • 分類前のキューに多数のメッセージが格納されている場合は、Active Directory の負荷が高くなりすぎている可能性がある。

  • 変換で障害が発生している。カテゴライザはコンテンツの変換も処理します。

  • メッセージ カテゴライザがメールボックス ストアを見つけることができない。

  • SMTP が再インストールまたは削除された場合は、IIS メタベース キー /smtpsvc/DsUseCat および /smtpsvc/vsi#/DsUseCat が無効になる可能性がある。

    注 :
    SMTP を再インストールまたは削除したかどうかを確認してください。

このエラーを解決するには、MSExchangeDSAccess サービスおよび MSExchangeTransport サービスの診断ログを増やし、カテゴライザ コンポーネントに関する情報を収集します。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[ディレクトリ参照待ちのメッセージ] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) ディレクトリ参照待ちのメッセージ キューの StateRetry キーの値を判断します。

Exchange サーバー上のディレクトリ参照待ちのメッセージ キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

ディレクトリ参照待ちのメッセージ キューには、Active Directory® ディレクトリ サービスに対してまだ解決されていない受信者へのメッセージが格納されます。メッセージはまた、配布リストが展開されている間もこのキューに保持されます。

一般に、メッセージがこのキュー内に蓄積される状態は、アドバンスド キュー エンジンがそのメッセージを分類できないことが原因です。アドバンスド キュー エンジンがグローバル カタログ サーバーにアクセスできず、受信者情報にアクセスできない状態になっている可能性があります。あるいは、グローバル カタログ サーバーが到達不能か、またはパフォーマンスが低下しています。さらに、以下の理由でメッセージが蓄積される場合もあります。

  • Active Directory が使用不可能である。

    注 :
    カテゴライザは Active Directory を使用してメッセージを分類します。
  • 分類前のキューに多数のメッセージが格納されている場合は、Active Directory の負荷が高くなりすぎている可能性がある。

  • 変換で障害が発生している。カテゴライザはコンテンツの変換も処理します。

  • メッセージ カテゴライザがメールボックス ストアを見つけることができない。

  • SMTP が再インストールまたは削除された場合は、IIS メタベース キー /smtpsvc/DsUseCat および /smtpsvc/vsi#/DsUseCat が無効になる可能性がある。

    注 :
    SMTP を再インストールまたは削除したかどうかを確認してください。

このエラーを解決するには、キューのプロパティを調べて、そのキューが再試行状態にある原因を判断します。たとえば、キューのプロパティに "SMTP エラーが発生しました" のようなメッセージが表示される場合は、サーバーのイベント ログを確認して SMTP エラーを見つける必要があります。ログにイベントが記録されていない場合は、SMTP プロトコルのログ レベルを上げる必要があります。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?linkid=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[発信が保留されているメッセージ] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-16

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 発信が保留されているメッセージキューの StateFrozen キーの値を判断します。

Exchange サーバー上の発信が保留されているメッセージ キューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

発信が保留されているメッセージ キューには、SMTP サービスによって認識され受け入れられたメッセージが保持されます。

このキューに置かれているメッセージは、まだ処理されていません。常にメッセージが蓄積されていると、パフォーマンスに問題が発生することがあります。CPU パフォーマンスが複数回にわたって上限に達すると、このキューにメッセージが断続的に現れる場合があります。たとえば、ウイルス対策用や免責用のカスタム SMTP 処理コードなど、イベント シンクで頻繁に問題が発生すると、このキューにメッセージが蓄積されます。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[発信が保留されているメッセージ] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 発信が保留されているメッセージキューの StateRetry キーの値を判断します。

Exchange サーバー上の発信が保留されているメッセージ キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

発信が保留されているメッセージ キューには、SMTP サービスによって認識され受け入れられたメッセージが保持されます。

このキューに置かれているメッセージは、まだ処理されていません。常にメッセージが蓄積されていると、パフォーマンスに問題が発生することがあります。CPU パフォーマンスが複数回にわたって上限に達すると、このキューにメッセージが断続的に現れる場合があります。たとえば、ウイルス対策用や免責用のカスタム SMTP 処理コードなど、イベント シンクで頻繁に問題が発生すると、このキューにメッセージが蓄積されます。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[ルーティング待ちのメッセージ] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) のルーティング待ちのメッセージキューの StateFrozen キーの値を判断します。

Exchange Server アナライザによって、Exchange サーバー上のディレクトリ参照待ちのメッセージキューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

[ルーティング待ちのメッセージ] キューは、次の送信先サーバーが決定するまでメッセージを保持してから、個々のリンク キューにメッセージを移動します。

Exchange Server のルーティングに問題がある場合、メッセージはこのキューに蓄積されます。メッセージ ルーティングはバックアップされている場合があります。

このエラーを解決するには、MSExchangeDSAccess サービスおよび MSExchangeTransport サービスの診断ログを増やし、カテゴライザ コンポーネントに関する情報を収集します。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[ルーティング待ちのメッセージ] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) ルーティング待ちのメッセージ キューの StateRetry キーの値を判断します。

Exchange サーバー上のディレクトリ参照待ちのメッセージ キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

ルーティング待ちのメッセージ キューは、次の送信先サーバーが決定し、対応するリンク キューに移動するまでメッセージを保持します。

Exchange Server のルーティングに問題がある場合、メッセージはこのキューに蓄積されます。メッセージ ルーティングはバックアップされている場合があります。

このエラーを解決するには、MSExchangeTransport サービスの診断ログを増やし、カテゴライザ コンポーネントに関する情報を収集します。コネクタを制限するとサーバーのパフォーマンスが大幅に低下する場合があるため、不要なコネクタ制限はすべて無効にしてください。いくつかの制限については、CheckConnectorRestrictions レジストリ キーをオンにすることが必要な場合があります。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


見つからないトランスポート イベント シンクのバインド
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-01-11

Microsoft® Exchange Server アナライザ ツールは、Microsoft Internet Information Service (IIS) メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) トランスポート イベント シンクのバインドの一覧を列挙します。Exchange Server アナライザは、前もって作成された次の一覧に基づいて、いくつかの標準のイベント バインドの場所を特定します。

  • カスタム Exchange DNS シンク

  • XLSA 用の EHLO 受信コマンド ハンドラ シンク

  • X-LSA 用の EHLO 応答ハンドラ シンク

  • EOD 受信コマンド ハンドラ シンク

  • Exchange カテゴライザ

  • Exchange LoadBalancer

  • Exchange NTFS ストア ドライバ

  • Exchange Router

  • Exchange SMTP プロトコル ログ収集シンク

  • Exchange SMTP プロトコル セキュリティ EHLO シンク

  • Exchange SMTP プロトコル セキュリティ EXPS シンク

  • Exchange SMTP プロトコル セキュリティ EXPS-Aux シンク

  • Exchange SMTP プロトコル セキュリティ EXPS-EOD シンク

  • Exchange SMTP プロトコル セキュリティ Mail シンク

  • Exchange SMTP プロトコル XEXCH50 データ送信前シンク

  • Exchange SMTP プロトコル XEXCH50 EHLO 応答シンク

  • Exchange SMTP プロトコル XEXCH50 EOD シンク

  • Exchange SMTP プロトコル XEXCH50 受信 EHLO シンク

  • Exchange SMTP プロトコル XEXCH50 受信 MAIL シンク

  • Exchange SMTP プロトコル XEXCH50 受信 RCPT シンク

  • Exchange SMTP プロトコル XEXCH50 受信 XEXCH50 シンク

  • Exchange SMTP プロトコル XEXCH50 受信者単位のイベント シンク

  • Exchange SMTP プロトコル XEXCH50 RCPT 応答シンク

  • Exchange SMTP プロトコル XEXCH50 応答シンク

  • Exchange ストア ドライバ

  • Exchange Transport AntiVirus API

  • Exchange トランスポート XEXCH50 発信シンク

  • TURF 用の MAIL 受信コマンド ハンドラ シンク

  • モバイル カテゴライザ

  • MSExchange コンテンツ フィルタ EOD シンク

  • MsgTrackLog シンク

  • RCPT 受信コマンド ハンドラ シンク

  • SMTP Eventlog シンク

  • UmConvSink

  • X-LSA 受信コマンド ハンドラ シンク

  • X-LSA 応答ハンドラ シンク

  • X-LSA シンク

Exchange Server アナライザによって、1 つ以上の標準のイベント バインドが見つからないことが検出されると、警告が表示されます。

SMTP トランスポート イベントは SMTP サービスでメッセージ データが送受信されたときに発生します。したがって、すべてのメッセージがイベントによって処理されます。これらには、X.400 および RPC の送受信メッセージが含まれます。受信トランスポート イベントの一般的な例には、SMTP サービスにネットワーク経由でメッセージが送信されたときに発生するイベントや、SMTP ピックアップ ディレクトリに送信されたときに発生するイベントなどがあります。このトランスポート イベントが発生すると、このイベント ソースによってトランスポート イベント シンクに通知され、メッセージのデータの内容に基づいた動作が実行されます。メッセージ データをシンクに渡した後に、シンクがそのイベントを完了して返すまで、システムがメッセージ データを使用して別の動作を実行することはありません。シンクが動作しているときは、シンクでメッセージのデータや状態が排他的に制御されます。

見つからないトランスポート イベント シンクのバインドがメール フローの問題の原因になります。Exchange Server でメッセージがキューに入るなどのメール フローの問題の兆候が現れた場合は、トランスポート イベント シンクを再登録します。

トランスポート イベント シンクを再登録するには、次の操作を実行します。

  1. Exchange Server でコマンド プロンプト ウィンドウを開き、\Program Files\Exchsrvr\Bin フォルダに移動します。

  2. トランスポート イベント シンクを再登録するには、次のコマンドを入力します。

    regsvr32 /i exps.dll

    regsvr32 /i miscat.dll

    regsvr32 /i onsubmit.dll

    regsvr32 /i peexch50.dll

    regsvr32 /i phatcat.dll

    regsvr32 /i protolog.dll

    regsvr32 /i reapi.dll

    regsvr32 /i regsinks.dll

    regsvr32 /i tranmsg.dll

    regsvr32 /i turflist.dll

    regsvr32 /i xlsasink.dll

    regsvr32 /i msgfilter.dll

  3. Exchange Server アナライザに戻り、警告が表示されないことを確認します。イベント シンクに関する警告が表示され、メール フローの問題が解決しない場合は、Microsoft 製品サポート サービス (PSS) にお問い合わせください。

トランスポート イベント シンクのバインドの詳細については、次の Exchange に関するリソースを参照してください。

  • Microsoft サポート技術情報の文書番号 258224「[XCON] 登録済みのトランスポート イベント シンクを表示する」(http://go.microsoft.com/fwlink/?linkID=3052&kbid=258224)

  • 『Technical Reference Guide for Exchange Server 2003』の「SMTP Service Design」(http://go.microsoft.com/fwlink/?LinkId=58876) (このサイトは英語の場合があります)


msExchAlternateServer 属性が設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 SMTP (Simple Mail Transfer Protocol) 仮想サーバーの msExchAlternateServer 属性値を判断します。既定では、msExchAlternateServer 属性値は設定されていません。Exchange Server アナライザによって msExchAlternateServer 属性が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchAlternateServer 属性は、次のようなシナリオで設定されます。Exchange Server 2003 と他の電子メール システムの間で、SMTP ドメインなどの SMTP アドレス空間を共有しているとします。このシナリオでは、Exchange Server 2003 がインターネットからの受信メールを受け付けます。Exchange Server 2003 は、一致する受信者が Exchange Server 組織内に存在するかどうかを検索します。一致する受信者が見つからなければ、Exchange Server はそのメールを他の外部メール システムに転送します。そのメールを受信したシステムも同様に、一致する受信者を検索します。一致する受信者が見つからなければ、そのメールはさらに第 3 の電子メール システムに転送される可能性があります。チェーン内の最後のシステムは、ドメインに対する権限を持っている必要があります。最後にメールを受信したシステムは、必ず一致する受信者を見つける必要があります。一致する受信者が見つからなければ、そのメッセージに対する配信不能レポート (NDR) を生成する必要があります。受信したシステムが一致する受信者を検索し、見つからなかった場合にメッセージを元のシステムに転送すると、メッセージのループが発生します。

msExchAlternateServer 属性を変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、[<サーバー名>] を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  3. SMTP 仮想サーバーのプロパティ ダイアログ ボックスで、[メッセージ] タブをクリックします。

  4. [解決できない受信者を含むメールの転送先ホスト] ボックスに、未解決のメールを受信するサーバーの FQDN を入力します。サーバーの IP アドレスを角かっこ ([ ]) で囲んで入力することもできます。

  5. [OK] をクリックします。

SMTP アドレス空間の共有の詳細については、Microsoft サポート技術情報の文書番号 321721「[XCON] Exchange 2000 で SMTP アドレス スペースを共有する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=321721) を参照してください。

インターネット接続に関する展開シナリオの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) の「Deployment Scenarios for Internet Connectivity」を参照してください (このサイトは英語の場合があります)。


msExchMaxIncomingConnections の値が既定の設定から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各 SMTP 仮想サーバーの msExchSmtpMaxIncomingConnections 属性のために構成されている値を判断します。

既定では、Microsoft Windows® Small Business Server 2003 のインストールの一部ではない Exchange Server コンピュータの msExchSmtpMaxIncomingConnections 属性は、この属性の既定値である 2000000000 が示すように、無制限に接続を受け付けるように構成されます。Microsoft Windows Small Business Server 2003 のインストールの一部である Exchange Server コンピュータでは、受信接続の既定の最大数は 500 です。

Exchange Server アナライザは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーの値は、Windows Server オペレーティング システムの特定のバージョンに対応します。

Exchange Server アナライザによって、Microsoft Windows Small Business Server 2003 のインストールの一部ではない Exchange Server コンピュータの msExchSmtpMaxIncomingConnections 属性の値が 2000000000 でないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。この属性に使用される値 2000000000 は、論理上の制限でもあり、この値をユーザーが構成できるようにするユーザー インターフェイス要素に適用される制限でもあります。

また、Microsoft Windows Small Business Serve 2003 のインストールの一部である Exchange Server コンピュータの msExchSmtpMaxIncomingConnections 属性の値が 500 でないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

セキュリティの観点から、受信接続の数を制限すると有効な場合があります。実質的に無制限の数の受信 SMTP 接続を受け付ける機能は、それ自体がサービス拒否の状況を引き起こす可能性があります。仮想サーバーへの同時接続数が多すぎると、ネットワークに過剰な負荷がかかり、パフォーマンスが低下する可能性があります。この属性の適切な値は、それぞれの組織で決定する必要があります。

受信接続の最大数を表示または構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [全般] タブをクリックします。

    • 受信接続の最大数を制限するには、[接続数を制限する] チェック ボックスをオンにして、設定する値を入力します。

    • 受信接続を制限しない既定の設定に戻すには、[接続数を制限する] チェック ボックスをオフにします。

  5. [OK] をクリックし、変更を保存します。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxHopCount 値が既定値から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxHopCount 属性の構成値が既定値から変更されているかどうかを判断します。

Exchange 2000 Server では、msExchSmtpMaxHopCount 属性は既定値の 15 で構成されています。Exchange Server 2003 では、この属性の既定値は 30 です。Exchange Server アナライザによって、この属性が既定値に設定されていないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

メッセージは、最終的な宛先に届く前に、多くの異なる SMTP サーバー (それぞれをホップという) を経由する場合があります。管理者は、メッセージが繰り返し誤ってルーティングされる状態 (これをメッセージ ループという) を防ぐために、許可されるホップの最大数を制御できます。mxExchSmtpMaxHopCount 属性は、送信者に配信不能として戻されるまでにメッセージが通過できる SMTP サーバーの数を指定します。

Exchange 2000 Server と Exchange Server 2003 のどちらの SMTP 仮想サーバーに対しても、この値を 30 に設定することをお勧めします。

このエラーを修正するには

  1. Exchange システム マネージャで、[サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] を選択します。

  3. [配信] タブを選択し、[詳細設定] をクリックします。

  4. [最大ホップ数] ボックスに希望する値を入力し、[OK] をクリックして変更を保存します。

  5. [OK] をクリックし、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxMessageSize の値が既定値の 0 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxMessageSize 属性の値が既定値の 0 から変更されているかどうかを判断します。既定では、msExchSmtpMaxMessageSize 属性はメッセージ サイズの制限を設けないように構成されています。この属性の値が 0 でないこと、および Exchange が Microsoft Windows® Small Business Server 2003 上で実行されていないことが検出されると、警告メッセージが表示されます。

msExchSmtpMaxMessageSize 属性は、送受信することができる各 SMTP メッセージの最大サイズを表します。セキュリティの観点からは、インターネットとの間で送受信することができる SMTP メッセージの最大サイズを制限することをお勧めします。ただし、同じ組織内の Exchange サーバー間で送信されるメッセージのような内部の SMTP メッセージについては、msExchSmtpMaxMessageSize 属性を 0 に設定したままにすることをお勧めします。

Exchange は、内部的に SMTP メッセージを使用して、パブリック フォルダのレプリケーションなどのタスクを処理します。小さすぎる制限値で msExchSmtpMaxMessageSize 属性が構成されている場合、パブリック フォルダのレプリケーションの問題や、組織内のメッセージ配信に関するその他のエラーが発生する可能性があります。

この Exchange サーバーが、インターネットとの間で SMTP メッセージを転送するブリッジヘッド サーバーである場合、この警告は無視してかまいません。この Exchange サーバーで内部の SMTP メッセージを処理している場合は、msExchSmtpMaxMessageSize 属性の値を既定の設定の 0 に戻す必要があります。

注 :
設定するメッセージ サイズ制限が小さすぎると、Exchange Server コンピュータ間のオフライン アドレス帳レプリケーションができなくなる可能性があります。この問題の詳細については、Microsoft サポート技術情報の文書番号 326154「XADM: メッセージのサイズ制限のトランスポート レベルで設定するならば、 OAB が複製されません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154) を参照してください。

SMTP メッセージの最大サイズを表示して構成するには

  1. Exchange システム マネージャで、[サーバー] を展開し、操作対象の Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] を選択します。

  3. [メッセージ] タブをクリックします。

  4. 既定の設定の 0 に戻すには、[メッセージ サイズの制限値 (KB)] チェック ボックスをオフにします。または、このチェック ボックスをオンのままにしておき、必要な値を設定します。

  5. [OK] をクリックして変更を保存し、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxOutboundMsgPerDomain の値が既定値の 20 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxOutboundMsgPerDomain 属性の構成値が既定値の 20 から変更されているかどうかを判断します。既定では、msExchSmtpMaxOutboundMsgPerDomain 属性は、接続あたりの送信 SMTP メッセージの最大数が 20 であるように構成されます。Exchange Server アナライザ ツールによって、この属性の値が 20 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchSmtpMaxOutboundMsgPerDomain 属性は、Exchange サーバー上の 1 つの SMTP 仮想サーバーによって送信可能なメッセージの、接続あたりの最大数を表します。たとえば、SMTP サーバーに microsoft.com に送信するメッセージが 35 あり、msExchSmtpMaxOutboundMsgPerDomain 属性が 20 に設定されている場合、microsoft.com へのメッセージの処理を担当するメール サーバーに対して、2 つの接続が作成されます。最初の接続で、最大数である 20 のメッセージが送信され、次に 2 つ目の接続が作成されて残りの 15 のメッセージが送信されます。

一般に、この属性の正しい値を決定するための、ベスト プラクティスによる推奨事項は存在しません。各組織が、設定する適切な値を独自に決定する必要があります。

接続あたりのメッセージの最大数を設定するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、設定しようとしている Exchange サーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [メッセージ] をクリックします。

  5. msExchSmtpMaxOutboundMsgPerDomain 属性の現在の値は、[ドメインごとに接続数を制限する] ボックスに示されています。必要に応じてこのボックスを変更し、[OK] をクリックして変更を保存します。このボックスには、1 ～ 1999999999 の任意の整数を指定できます。

  6. [OK] をクリックして、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 266686 の、[XADM] SMTP サービスの構成方法 (第 1 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163 の、[XADM] SMTP サービスの構成方法 (第 2 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxOutgoingConnections の値が既定値の 1000 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxOutgoingConnections 属性の構成値が既定値の 1,000 から変更されているかどうかを判断します。既定では、msExchSmtpMaxOutgoingConnections 属性は、送信 SMTP (Simple Mail Transfer Protocol) 接続の最大数が 1000 になるように構成されます。Exchange Server アナライザ ツールによって、この属性の値が 1000 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchSmtpMaxOutgoingConnections 属性は、Exchange サーバー上の 1 台の SMTP 仮想サーバーによって作成することができる送信接続の最大数を表します。

一般に、この属性の正しい値を決定するための、ベスト プラクティスによる推奨事項は存在しません。各組織が、設定する適切な値を独自に決定する必要があります。ただし、一部の組織にとっては、既定値では多すぎることがあります。Exchange サーバーで以下のパフォーマンス カウンタを収集することで、1 台の Exchange SMTP 仮想サーバーによって作成される SMTP 送信接続の実際の数を監視し、判断することができます。

オブジェクト | カウンタ | 説明
SMTP Server | Outbound Connections Current | 現在の送信接続の数
SMTP Server | Outbound Connections Total | 試行された送信接続の合計数。

組織がこの Exchange サーバーで送信 SMTP を頻繁に使用しない場合は、この属性の値を小さくすることを検討してください。ある時点で作成可能な、同時に接続できる送信 SMTP 接続の最大数を減らすと、誤った構成、不注意による間違い、悪意のある活動、メッセージ ループや他の誤動作、またはウイルスの発生やセキュリティの侵害によって発生することがある、SMTP サーバーの活動のスパイクを軽減できる可能性があります。

送信接続の制限を表示して構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] をクリックし、[送信接続] をクリックします。

  5. msExchSmtpMaxOutgoingConnections 属性の現在の値は、[ドメインごとに接続数を制限する] ボックスに示されています。必要に応じてこのボックスを変更し、[OK] をクリックして変更を保存します。このボックスには、1 ～ 1999999999 の任意の整数を指定できます。

  6. [OK] をクリックし、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxOutgoingConnectionsPerDomain 値が既定値の 100 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxOutgoingConnectionsPerDomain 属性の構成値が既定の設定から変更されているかどうかを判断します。msExchSmtpMaxOutgoingConnectionsPerDomain 属性は、Microsoft Exchange サーバー上の SMTP 仮想サーバーが確立できる、ドメインあたりの送信接続の最大数を表します。Microsoft® Windows® Small Business Server 2003 インストールに含まれていない Exchange Server コンピュータの場合、既定では、msExchSmtpMaxOutgoingConnectionsPerDomain 属性は 100 の既定値で構成されています。Windows Small Business Server 2003 インストールに含まれている Exchange Server コンピュータの場合、ドメインあたりの送信接続の最大数の既定値は 10 です。

また、Exchange Server アナライザは、Win32_OperatingSystem WMI (Windows Management Instrumentation) クラスに対してもクエリを実行し、OSProductSuite キーの値を判断します。このキーの値は、Windows Server オペレーティング システムの特定のバージョンに対応します。

Exchange Server アナライザによって、Windows Small Business Server 2003 のインストールの一部ではない Exchange Server コンピュータの msExchSmtpMaxOutgoingConnectionsPerDomain 属性の値が 500 でないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

また、Microsoft Windows Small Business Server 2003 のインストールの一部である Exchange Server コンピュータの msExchSmtpMaxOutgoingConnectionsPerDomain 属性の値が 10 でないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

一般に、この属性の正しい値を決定するための、推奨されるベスト プラクティスは存在しません。各組織が、設定すべき適切な値を決定する必要があります。ただし、組織によっては、既定値は大きすぎる可能性があります。Exchange サーバー上で次のパフォーマンス カウンタの値を収集することにより、Exchange SMTP 仮想サーバーによって確立される SMTP 送信接続の実際の数を監視し、決定することができます。

オブジェクト | カウンタ | 説明
SMTP Server | Outbound Connections Current | 現在の送信接続の数です。
SMTP Server | Outbound Connections Total | 試行された送信接続の合計数です。

組織がこの Exchange サーバー上で送信 SMTP を広範囲に使用していない場合は、この属性の値を小さくすることを検討してください。任意の時点で同時に確立できる送信 SMTP 接続の最大数を小さくすると、正しくない構成、単純なミス、悪意のある活動、メッセージ ループやその他の誤動作、ウイルスの発生やセキュリティ侵害などによって発生する可能性のある、SMTP サーバー動作におけるスパイクを抑制できる場合があります。

ドメインあたりの送信接続の制限を表示し、構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] をクリックし、[送信接続] をクリックします。

  5. [ドメインごとに接続数を制限する] ボックスに、msExchSmtpMaxOutgoingConnectionsPerDomain 属性の現在の値が一覧で表示されます。必要に応じてこのボックスを変更し、[OK] をクリックして変更を保存します。このボックスには、1 ～ 1999999999 の範囲の任意の整数を入力できます。

  6. [OK] をクリックして、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxRecipients の値が既定値の 64000 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxRecipients 属性の構成値が既定値の 64,000 から変更されているかどうかを判断します。既定では、msExchSmtpMaxRecipients 属性は 64,000 人の受信者用に構成されています。Exchange Server アナライザ ツールによって、この属性の値が 64000 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

セキュリティの観点からは、各メッセージの最大受信者数を制限することをお勧めします。許容できる値は、それぞれの組織が決定する必要があります。この値を他の値に構成する理由がある場合を除き、msExchSmtpMaxRecipients 属性は、既定値の 64000 に設定したままにしておくことをお勧めします。

最大受信者数を表示して構成するには

  1. Exchange システム マネージャで、[サーバー] を展開し、操作対象の Exchange サーバーを展開します。次に、[プロトコル] を展開して、[SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  3. [メッセージ] タブをクリックします。

  4. 既定の設定である 64,000 に戻すには、[メッセージごとの受信者の制限数] チェック ボックスがオンになっていることを確認し、値として「64000」と入力します。他の構成方法として、必要な値でこのボックスを構成したり、チェック ボックスをオフにして、無制限の数の受信者を許可したりすることもできます。

  5. [OK] をクリックして変更を保存し、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpMaxSessionSize 値が既定値の 0 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxSessionSize 属性の構成値が既定値の 0 から変更されているかどうかを確認します。既定では、msExchSmtpMaxSessionSize 属性はメッセージ サイズを制限しないように構成されています。この属性の値が 0 ではないことが検出されると、警告メッセージが表示されます。

msExchSmtpMaxSessionSize 属性は、各 SMTP セッションに対して受け付けられる最大データ量 (KB 単位) を表します。セキュリティの観点からは、インターネットとの間で送受信されるメッセージについて SMTP セッションのサイズを制限することがベスト プラクティスです。ただし、同じ組織内の Exchange サーバー間の場合のような内部の SMTP セッションでは、msExchSmtpMaxSessionSize 属性を 0 に設定されたままにしておくことをお勧めします。

内部的には、Exchange は SMTP メッセージを使用して、パブリック フォルダのレプリケーションなどのタスクを処理しています。msExchSmtpMaxSessionSize 属性が小さすぎる制限値で構成されていると、パブリック フォルダのレプリケーションでの問題や、その他の組織内でのメッセージ配信の失敗が発生する場合があります。

この Exchange サーバーが、インターネットとの間で SMTP メッセージを転送するブリッジ ヘッド サーバーとして使用されている場合は、この警告を無視してかまいません。この Exchange サーバーが内部の SMTP メッセージを処理している場合は、msExchSmtpMaxSessionSize 属性の値を既定の設定の 0 に戻す必要があります。

SMTP セッションの最大サイズを表示し、構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、対象の Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [メッセージ] をクリックします。

  5. 既定の設定の 0 に戻すには、[セッション サイズの制限値 (KB)] チェック ボックスをオフにします。あるいは、このチェック ボックスをオンにしたまま、希望する任意の値に構成します。

  6. [OK] をクリックして変更内容を保存し、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpOutgoingPort 値が既定値の 25 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpOutgoingPort 属性の構成値が既定値の 25 から変更されているかどうかを判断します。既定では、msExchSmtpOutgoingPort 属性は TCP ポート 25 用に構成されています。この属性が 25 以外のポート用に構成されていることが検出されると、警告が表示されます。

既定では、SMTP (Simple Mail Transfer Protocol) サーバーは、TCP ポート 25 で受信接続を受け付けるように構成されています。msExchSmtpOutgoingPort パラメータは、この Exchange サーバーがすべてのリモート SMTP サーバー上で接続を試みる TCP ポートを表します。リモート SMTP サーバーがこのポートで接続要求待ちを行うように構成されていないと、接続を確立できません。

内部メッセージング インフラストラクチャの一部または全体が標準以外のポートを使用するように変更されていない限り、すべての SMTP 通信に TCP ポート 25 を使用することをお勧めします。

既定の送信 SMTP ポートを表示または変更するには

  1. Exchange システム マネージャで、[サーバー] を展開し、[Exchange サーバー] を展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP Virtual Server]) を右クリックし、[プロパティ] をクリックします。

  3. [配信] をクリックし、[送信接続] をクリックします。

  4. [TCP ポート] ボックスに、送信接続に使用するポートを入力します。通信相手のリモート SMTP サーバーは、指定したポートで接続を受け付けるように構成されている必要があります。ほとんどの場合、この値を変更する必要はありません。

  5. 必要に応じてこのボックスを変更し、[OK] をクリックして変更を保存します。

  6. [OK] をクリックし、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


msExchSmtpRelayForAuth の値が既定値の True から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpRelayForAuth 属性のために構成されている値が既定値から変更されたかどうかを判断します。既定では、msExchSmtpRelayForAuth 属性は True の値を使用して構成されます。Exchange Server アナライザ ツールによって、msExchSmtpRelayForAuth 属性の値が True ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が True に設定されている場合、認証された SMTP 接続のみが、この SMTP 仮想サーバー経由で SMTP メッセージを中継できます。この設定が False に変更されている場合は、SMTP 仮想サーバーの プロパティ ダイアログ ボックスの中継設定で、[上のコンピュータの一覧に関係なく、正しく認証されたすべてのコンピュータが、この仮想サーバーを中継に使用する] チェック ボックスがオフになっていることを示します。

中継は、SMTP サーバーへの受信接続が、外部ドメインに電子メール メッセージを送信するために使用される動作です。不要な商用電子メール メッセージでは、組織外のドメインの受信者を複数指定した 1 つの電子メール メッセージを組織の SMTP サーバーに送信することで、中継を行います。SMTP サーバーの既定の設定では匿名認証が使用されるため、不要な商用電子メール メッセージの伝達に使用されるシステムは、一般的には受信メッセージを受け付けます。

SMTP サーバーは、メッセージを受け付けた後に、メッセージの受信者が外部ドメインに属していることを認識し、メッセージを配信します。そのため、不要な商用電子メール メッセージを送信する認証されていないユーザーは、SMTP サーバーに 1 つの受信メッセージを送信するだけで、数千の受信者にメッセージを配信することができます。これにより、Exchange Server コンピュータの応答速度は低下し、キューが混雑して、メッセージが受信トレイに到着したときに受信者の不満を引き起こします。

中継を制御する主な手段は、他のホストに中継アクセスを許可しないようにすることです。しかし、中継が必要な場合もあります。たとえば、メッセージの配信のために SMTP に依存している POP3 (Post Office Protocol) クライアントや IMAP4 (Internet Message Access Protocol) クライアントが存在しており、外部ドメインに電子メール メッセージを送信する正当な理由がある場合などです。この問題は、2 台目の SMTP 仮想サーバーを作成し、POP3 および IMAP4 クライアントからの電子メール メッセージの受信専用に使用することで回避できます。この追加の SMTP 仮想サーバーでは、SSL (Secure Sockets Layer) ベースの暗号化と組み合わせた認証を使用することが可能であり、認証されたクライアントには中継が可能なように構成できます。この構成の実装に関する詳細については、Microsoft サポート技術情報の文書番号 319267「[HOWTO] Exchange 2000 で SMTP クライアントのメッセージ配信をセキュリティ保護する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=319267) を参照してください。

システム マネージャで msExchSmtpRelayForAuth 値の表示や変更を行うには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [アクセス] タブをクリックし、[中継] をクリックします。

  5. [上のコンピュータの一覧に関係なく、正しく認証されたすべてのコンピュータが、この仮想サーバーを中継に使用する] チェック ボックスをオフまたはオンにします。

  6. [OK] をクリックして変更を保存します。

このチェック ボックスがオンの場合、msExchSmtpRelayForAuth 属性は True に設定されるはずです。このチェック ボックスがオフの場合、msExchSmtpRelayForAuth 属性は False に設定されるはずです。

メッセージの中継が可能なアカウントの制御に関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 818778「リレー メッセージの権限を使わないでユーザーは、SMTP 仮想サーバーを介してメッセージを送信できます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=818778)

  • 文書番号 310380「[HOWTO] Windows 2000 で Exchange 2000 がメール リレーとして使用されるのを防ぐ方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)


msExchSmtpSmartHostType の値が既定値の 0 から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpSmartHostType 属性の構成済みの値が既定値の 0 から変更されたかどうかを判断します。既定では、msExchSmtpSmartHostType 属性は 0 に設定されます。この属性が 0 ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

msExchSmtpSmartHostType 属性は、SMTP 仮想サーバーが、メッセージ配信のためにスマート ホストを使用するように構成されているかどうかを示します。リモート ドメイン宛てのすべての送信メッセージを受信先のドメインへ直接送信せずに、スマート ホスト経由でルーティングすることができます。Exchange がスマート ホストを使用するように構成されている場合、msExchSmtpSmartHostType 属性値は、次の表に示されている詳細に従って変更されます。

スマート ホストの設定 | msExchSmtpSmartHostType 属性値
スマート ホストを使用しない | 0
スマート ホストを使用する | 2
最初に直接配信を試行してからスマート ホストを使用する | 1

Exchange Server 2003 コンピュータでは、この値は 0 または 2 になります。Exchange 2000 Server コンピュータでは、値は 0、1、または 2 です。値 1 は、[スマート ホストへ送信する前に直接配信を試行する] チェック ボックスがオンになっているときに設定されます。このチェック ボックスがあるのは Exchange 2000 Server コンピュータのみです。Exchange Server 2003 に、このチェック ボックスは用意されていません。

この操作を行う特別な理由がある場合を除き、msExchSmtpSmartHostType 属性は既定値の 0 のままにしておくことをお勧めします。

実際の環境でスマート ホストが必要とされており、その環境に複数の Exchange Server コンピュータが存在する場合 (または使用する予定の場合)、すべてのスマート ホスト エントリに対して 1 つの SMTP コネクタを使用することをお勧めします。このようにすると、内部メールはすべて Exchange Server によってルーティングされ、外部メールのみがスマート ホストを介してルーティングされます。

スマート ホストの設定を表示して構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、設定しようとしている Exchange サーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] タブをクリックし、[詳細設定] をクリックします。

  5. 使用するスマート ホストを入力します。スマート ホストは、完全修飾ドメイン名または IP アドレスで識別することができます。IP アドレスを使用する場合は、IP アドレスを角かっこ [ ] で囲む必要があります。Exchange は、まずサーバー名があるかどうかを調べ、次に IP アドレスを調べます。角かっこによって値が IP アドレスとして識別されるため、DNS の参照は省略されます。

  6. このサーバーが Exchange 2000 Server コンピュータの場合は、必要に応じて [スマート ホストへ送信する前に直接配信を試行する] チェック ボックスをオンにします。

  7. [OK] をクリックして変更を保存し、もう一度 [OK] をクリックして SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


MTA スタック サービスがデスクトップと対話するように構成されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Microsoft Exchange MTA Stacks (MSExchangeMTA) サービスの DesktopInteract プロパティの値を判断します。MTA サービスがデスクトップと対話するように構成されていることが検出されると、エラーが表示されます。

この構成は、Microsoft 製品サポート サービス (PSS) からの指示に基づいてのみ使用するようにしてください。PSS から MTA サービスをこの構成で実行するように指示されている場合以外は、MTA スタック サービスのプロパティを、デスクトップと対話しないように再構成することをお勧めします。

Exchange MTA Stacks サービス アカウントを構成するには

  1. [サービス] MMC スナップインを開きます。

  2. Microsoft Exchange MTA Stacks サービスを見つけて停止します。

  3. [Microsoft Exchange MTA Stacks] サービスをダブルクリックします。

  4. [Microsoft Exchange MTA Stacks のプロパティ] ページの [ログオン] タブで、[ログオン] の [ローカル システム アカウント] を選択します。

  5. [デスクトップとの対話をサービスに許可] チェック ボックスをオフにし、[適用] をクリックします。

  6. [サービスの状態] の下の [開始] をクリックし、[OK] をクリックします。

  7. [サービス] スナップインを終了します。

正しい Exchange サービス構成の詳細については、Microsoft サポート技術情報の文書番号 239762「Exchange のサービスは LocalSystem のコンテキストで実行される」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=239762) を参照してください。


'MX' レコード用の 'ホスト' レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは、ドメイン ネーム システム (DNS) 参照を実行し、ドメイン用の MX (Mail Exchanger) レコードを取得します。MX レコードが正常に取得されると、DNS 参照を実行してその MX レコードが指すサーバーのホスト (A) レコードを取得します。DNS 参照操作でこれらのホスト (A) レコードの IP アドレスが 1 つも返されない場合は、エラーを表示します。

このエラーは、サーバーの DNS ホスト (A) レコードが存在しないように見えることを示します。このエラーにより、リモート ドメイン宛のメッセージが Exchange サーバーのリモート配信キューにバックアップされることがあります。また、このエラーによって、その他のルーティングまたはサービスに遅延が発生することもあります。

以下の理由によって、MX レコード用のホスト (A) レコードの DNS 参照が失敗することがあります。

  • DNS サーバーが停止しているか、またはネットワーク障害などの理由により応答していない。

  • リモート サーバーのホスト (A) レコードが使用できないか、または正しくないため、DNS サーバーから見つからない。

  • DNS サーバーが動的なホスト レコードの更新を有効にするように構成されていない。

DNS サーバーがオンラインになっていて、ホスト レコードが存在することを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、DNS サーバーにホスト (A) レコードが存在することを確認します。詳細については、DNS に A リソース レコードが存在することを確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63001) を参照してください (このサイトは英語の場合があります)。

  3. ホスト (A) リソース レコードが存在しない場合、A リソース レコードを手動で追加または変更するか、または動的なレコードの更新を有効するように DNS サーバーを構成します。

    • A リソース レコードを手動で追加します。詳細については、DNS ゾーンにリソース レコードを追加する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください (このサイトは英語の場合があります)。

    • A リソース レコードを手動で変更します。詳細については、既存のリソース レコードを変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63014) を参照してください (このサイトは英語の場合があります)。

    • 動的なホスト レコードの更新を有効するように DNS サーバーを構成します。詳細については、Microsoft サポート技術情報の文書番号 816592「Windows Server 2003 で DNS 動的更新を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592) を参照してください。

詳細情報

  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Exchange Server 2003 の転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS をトラブルシューティングする方法の詳細については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 のシステム モニタについては、Exchange Server 2003 Management Pack for MOM 2000 SP1 のガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47573) の、Exchange Server 2003 Management Pack を使用したシステム モニタに関する章を参照してください (このサイトは英語の場合があります)。

  • ホスト (A) リソース レコードについては、リソース レコードの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63004) を参照してください (このサイトは英語の場合があります)。


'ホスト' レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-04

Microsoft® Exchange Server アナライザ ツールは、ドメイン ネーム システム (DNS) 参照を実行して、Exchange サーバーがメッセージを送信しようとしているリモート サーバーのホスト (A) レコードを取得します。DNS 参照操作で IP アドレスが返されない場合は、エラーが表示されます。

このエラーは、リモート サーバーの DNS ホスト (A) レコードが存在しないように見えることを示しています。このエラーにより、メッセージが Exchange サーバーのリモート配信キューにバックアップされることがあります。

以下の理由によって、リモート サーバーによるホスト (A) レコードの DNS 参照が失敗することがあります。

  • DNS サーバーが停止しているか、またはネットワーク障害などの理由により応答していない。

  • リモート サーバーのホスト (A) レコードが使用できないか、または正しくないため、DNS サーバーから見つからない。

  • DNS サーバーが動的なホスト レコードの更新を有効にするように構成されていない。

DNS サーバーがオンラインになっていて、ホスト レコードが存在することを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、DNS サーバーにホスト (A) レコードが存在することを確認します。詳細については、DNS に A リソース レコードが存在することを確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63001) を参照してください (このサイトは英語の場合があります)。

  3. ホスト (A) リソース レコードが存在しない場合、A リソース レコードを手動で追加または変更するか、または動的なレコードの更新を有効するように DNS サーバーを構成します。

    • A リソース レコードを手動で追加します。詳細については、DNS ゾーンにリソース レコードを追加する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください (このサイトは英語の場合があります)。

    • A リソース レコードを手動で変更します。詳細については、既存のリソース レコードを変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63014) を参照してください (このサイトは英語の場合があります)。

    • 動的なホスト レコードの更新を有効するように DNS サーバーを構成します。詳細については、Microsoft サポート技術情報の文書番号 816592「Windows Server 2003 で DNS 動的更新を構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=816592) を参照してください。
  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Exchange Server 2003 の転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS をトラブルシューティングする方法の詳細については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 のシステム モニタについては、Exchange Server 2003 Management Pack for MOM 2000 SP1 のガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47573) の、Exchange Server 2003 Management Pack を使用したシステム モニタに関する章を参照してください (このサイトは英語の場合があります)。

  • ホスト (A) リソース レコードについては、リソース レコードの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63004) を参照してください (このサイトは英語の場合があります)。


'MX' レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、使用しているドメイン ネーム システム (DNS) サーバーに対して、Exchange の送信先のリモート ドメインの MX (Mail Exchanger) レコードに関するクエリを実行します。

使用している DNS サーバーからリモート ドメインの MX レコードを取得できない場合は、警告が表示されます。

この警告は、リモート ドメインの DNS MX レコードが存在しないように見えることを示しています。

送信 Exchange サーバーは、メール ホストを確認するために MX レコードをチェックします。次に、アドレス (A) レコードをチェックして、MX レコードを IP アドレスに解決します。

リモート ドメインの MX レコードが見つからない場合は、そのリモート ドメイン宛のメッセージが Exchange サーバーのリモート配信キューにバックアップされるだけでなく、他のルーティングやサービスにも遅延が発生します。

DNS サーバーが停止しているか、またはネットワーク障害などの理由により DNS サーバーに到達できない場合は、MX レコードの DNS 参照が失敗する可能性があります。

DNS サーバーがオンラインになっていて、MX レコードが存在することを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。

  2. nslookup を使用して、MX レコードが正しく構成されていることを確認します。詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Nslookup を使用して MX レコードの構成を確認する方法に関するセクションを参照してください (このサイトは英語の場合があります)。

詳細情報

  • Exchange Server 2003 で DNS を使用して外部 IP アドレスを解決する方法については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、Exchange Server 2003 の転送の依存関係に関するセクションを参照してください (このサイトは英語の場合があります)。

  • DNS 名前解決については、Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856) を参照してください。

  • DNS をトラブルシューティングする方法の詳細については、DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) を参照してください (このサイトは英語の場合があります)。

  • Exchange Server 2003 のシステム モニタについては、Exchange Server 2003 Management Pack for MOM 2000 SP1 のガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47573) の、Exchange Server 2003 Management Pack を使用したシステム モニタに関する章を参照してください (このサイトは英語の場合があります)。


配信の制限に入れ子の配布グループある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出されたすべてのドメイン内の各配布グループ オブジェクトの次の属性値に対してクエリを実行し、グループのメンバシップに基づいた配信の制限の設定に使用されているグループがあるかどうかを判断します。

dLMemRejectPermsBL | このグループからのメッセージを受け入れない受信者またはコネクタの DN が含まれます。
dLMemSubmitPermsBL | このグループからのメッセージを受け入れる受信者またはコネクタの DN が含まれます。

Exchange Server アナライザは、配信の制限の設定に使用されているグループ オブジェクトがあることを検出すると、それらのグループを調べて、入れ子になったグループが含まれているかどうかを判断します。

また、Exchange Server アナライザは、次のレジストリ キーを読み取り、RestrictionMethod レジストリ値が存在するかどうか、およびその構成方法を調べます。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

以下の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • 配布グループ メンバシップを使用して配信の制限が設定されている。

  • 配信の制限が設定されている配布グループ内に入れ子の配布グループが存在する。

  • RestrictionMethod レジストリ値が存在し、フラットな制限確認処理を強制する設定になっていない。

このエラーは、配布グループ メンバシップに基づいた配信の制限が Exchange メール フローのパフォーマンスに大きな影響を及ぼす可能性があることを示します。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

配布グループからのメッセージを受信または拒否するユーザーにメールを送信するときや、配布グループからのメッセージを受信または拒否するコネクタを通過するメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

RestrictionMethod の値により、カテゴライザが制限を処理する方法が決まります。RestrictionMethod の値を 2 に設定している場合、Exchange Server を実行するサーバー上のトランスポート コンポーネントは、サーバーが制限を確認するときに配布グループのメンバシップを展開しません。この構成では、制限の確認処理で最適なパフォーマンスが得られます。また、RestrictionMethod レジストリ エントリを有効にするには、配信が制限されているユーザーを含むすべての配布グループをフラットな構成にする必要があります。つまり、制限のある配布グループでは、配布グループを入れ子にしないようにする必要があります。制限のある配布グループが入れ子になっている場合、展開ロジックは機能しません。

コネクタの制限で使用される配布グループでは、メールボックスを持たないコネクタ ブリッジヘッド サーバーで RestrictionMethod レジストリ エントリの値を設定することをお勧めします。Active Directory ユーザーの制限では、制限のある配布グループに展開サーバーがある場合、展開サーバーで RestrictionMethod レジストリ エントリを作成することをお勧めします。

このエラーを修正するには、次の操作を行います。

  • 配布グループによる配信の制限が設定されているユーザーを調べて、不要な制限を削除します。

  • マイクロソフト サポート技術情報の文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • Microsoft Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange 2003 SP2 より前のバージョンの Exchange を実行するサーバーでは、Exchange 2003 SP2 へのアップグレードを検討します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
RestrictionMethod レジストリ エントリを作成して値を 2 に設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters

  3. 左側のペインで、[Parameters] をクリックします。

  4. [編集] メニューの [新規] をポイントし、[DWORD 値] をクリックします。

  5. 「RestrictionMethod」と入力し、Enter キーを押して、新しいレジストリ エントリに名前を付けます。

  6. [RestrictionMethod] を右クリックし、[変更] をクリックします。

  7. 「2」と入力し、Enter キーを押します。

  8. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、マイクロソフト サポート技術情報の文書番号 256986 の Microsoft Windows レジストリの説明についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 895407 の Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。

  • 文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)。

RestrictionMethod レジストリ値の詳細については、マイクロソフト サポート技術情報の文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407) を参照してください。

レジストリ値の詳細については、マイクロソフト サポート技術情報の文書番号 277872 の [XCON] コネクタの配信制限が正常に機能しない場合についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872) を参照してください。


入れ子化された配布グループが検出されたが、フラットな制限の確認処理が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出されたすべてのドメイン内の各配布グループ オブジェクトの次の属性値に対してクエリを実行し、グループのメンバシップに基づいた配信の制限の設定に使用されているグループがあるかどうかを判断します。

dLMemRejectPermsBL | このグループからのメッセージを受け入れない受信者またはコネクタの DN が含まれます。
dLMemSubmitPermsBL | このグループからのメッセージを受け入れる受信者またはコネクタの DN が含まれます。

Exchange Server アナライザは、配信の制限の設定に使用されているグループ オブジェクトがあることを検出すると、それらのグループを調べて、入れ子になったグループが含まれているかどうかを判断します。

また、Exchange Server アナライザは、次のレジストリ キーを読み取り、RestrictionMethod レジストリ値が存在するかどうか、およびその構成方法を調べます。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

以下の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • 配布グループ メンバシップを使用して配信の制限が設定されている。

  • 配信の制限が設定されている配布グループ内に入れ子の配布グループが存在する。

  • RestrictionMethod レジストリ値が存在し、フラットな制限確認処理を強制する設定になっている。

この警告は、RestrictionMethod レジストリ値がフラットな (階層のない) 制限の確認処理を強制実行するように設定されている場合でも、配信制限が設定された配布グループに埋め込まれた (入れ子化された) 他の配布グループが存在することを示します。配布グループに入れ子化された配布グループが含まれる場合、フラットな制限の確認処理は、許可または拒否された送信者を正しく識別しません。フラットな制限の確認処理では、入れ子化された配布グループは展開されません。

既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。

配布グループからのメッセージを受信または拒否するユーザーにメールを送信するときや、配布グループからのメッセージを受信または拒否するコネクタを通過するメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

RestrictionMethod の値により、カテゴライザが制限を処理する方法が決まります。RestrictionMethod の値を 2 に設定している場合、Exchange Server を実行するサーバー上のトランスポート コンポーネントは、サーバーが制限を確認するときに配布グループのメンバシップを展開しません。この構成では、制限の確認処理で最適なパフォーマンスが得られます。また、RestrictionMethod レジストリ エントリを有効にするには、配信が制限されているユーザーを含むすべての配布グループをフラットな構成にする必要があります。つまり、制限のある配布グループでは、配布グループを入れ子にしないようにする必要があります。

この警告に対処するには、フラットな制限の確認処理が有効な場合に、配信制限に使用される他の配布グループ内に配布グループを入れ子化しないようにします。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 895407 の Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。

  • 文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)。

RestrictionMethod レジストリ値の詳細については、マイクロソフト サポート技術情報の文書番号 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

レジストリ値の詳細については、マイクロソフト サポート技術情報の文書番号 277872 の、[XCON] コネクタ配信制限が正常に機能しない現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872)。


指定した送信者からのメッセージがない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-07

Microsoft Exchange Server アナライザ ツールは、Active Directory ディレクトリ サービスの proxyAddress 属性値に対してクエリを実行し、すべてのユーザー オブジェクトがユーザー指定のローカル送信者の SMTP (Simple Mail Transfer Protocol) アドレスと一致するかどうかを判断します。

ユーザー オブジェクトの proxyAddress との一致が見つかった場合、Exchange Server アナライザは、Active Directory のユーザー オブジェクトの msExchHomeServerName 属性値に対してクエリを実行し、値がユーザー指定の Exchange Server の名前に一致するかどうかを判断します。

最後に、Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows Management Instrumentation) クラスの SenderAddress プロパティに対してクエリを実行し、ユーザー指定の送信者からのメッセージ追跡ログによって追跡されたメッセージを識別します。

Exchange Server アナライザがユーザー指定の送信者の legacyDN または SMTP アドレスと一致する senderAddress プロパティ値を持つメッセージ追跡ログ エントリを検出できない場合、Exchange Server アナライザはエラーを表示します。

  • このエラーは、以下の 1 つ以上の条件に当てはまることを示します。

  • ユーザー指定の送信者がメッセージを送信しなかった。

  • メッセージ追跡ログの保存期間が経過し、関連するログ エントリが既に削除されている。

  • サーバーのメッセージ追跡が有効になっていない。

この問題を解決するには、次の操作を行います。

  • 指定した送信者から指定した受信者に別のメッセージを送信させる。

  • メッセージ追跡センターを有効にする。

  • メッセージ追跡ログの保存期間を延長し、より多くの現在のメッセージを追跡する。

メッセージ追跡センターを有効にする方法の詳細については、Exchange Server トランスポートおよびルーティング ガイド (http://go.microsoft.com/fwlink/?LinkID=67875) のメールの流れと SMTP のトラブルシューティングに関するページで、サーバーのメッセージ追跡センターを有効にする方法に関する記述 (http://go.microsoft.com/fwlink/?LinkId=71257) を参照してください (このサイトは英語の場合があります)。

メッセージ追跡の使用方法の詳細については、Microsoft サポート技術情報の文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162) を参照してください。


指定した受信者へのメッセージがない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-07

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの proxyAddress 属性値に対してクエリを実行し、すべてのユーザー オブジェクトがユーザー指定のローカル送信者の SMTP (Simple Mail Transfer Protocol) アドレスと一致するかどうかを判断します。

ユーザー オブジェクトの proxyAddress との一致が見つかった場合、Exchange Server アナライザは、Active Directory のユーザー オブジェクトの msExchHomeServerName 属性値に対してクエリを実行し、値がユーザー指定の Exchange Server の名前に一致するかどうかを判断します。

Exchange Server アナライザは、root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの SenderAddress プロパティに対してクエリを実行し、ユーザー指定の送信者からのメッセージ追跡ログによって追跡されたメッセージを識別します。

最後に、Exchange Server アナライザは、Exchange_MessageTrackingEntry WMI クラスの RecipientAddress プロパティに対してクエリを実行し、ユーザー指定の受信者へのメッセージ追跡ログによって追跡されたメッセージを識別します。

Exchange Server アナライザがユーザー指定の受信者の SMTP アドレスと一致する RecipientAddress プロパティ値を持つメッセージ追跡ログ エントリを検出できない場合、Exchange Server アナライザはエラーを表示します。

このエラーは、以下の 1 つ以上の条件に当てはまることを示します。

  • ユーザー指定の送信者がユーザー指定の受信者にメッセージを送信しなかった。

  • メッセージ追跡ログの保存期間が経過し、関連するログ エントリが既に削除されている。

この問題を解決するには、次の操作を行います。

  • 指定した受信者のアドレスが正しいことを確認する。

  • 指定した送信者から指定した受信者に別のメッセージを送信させる。

  • メッセージ追跡ログの保存期間を延長し、より多くの現在のメッセージを追跡する。

メッセージ追跡センターのログの保存期間を延長する方法の詳細については、サーバーのメッセージ追跡センターを有効にする方法に関するページ (http://go.microsoft.com/fwlink/?LinkID=71257) を参照してください。

メッセージ追跡の使用方法の詳細については、マイクロソフト サポート技術情報の記事 262162 の、[XADM] メッセージ追跡センターを使用してメッセージを追跡する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=262162) を参照してください。


キューの状態が取得できないため SMTP キューの分析を中止した
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-15

Microsoft Exchange アナライザ ツールは、ExchangeLink Microsoft WMI (Windows Management Instrumentation) クラスに対してクエリを実行し、Exchange サーバーの SMTP (Simple Mail Transfer Protocol) キューの状態を確認します。

SMTP は、Exchange サーバーのメール発信およびメール転送のためのネイティブなメール プロトコルです。つまり、クライアントは SMTP を使用してメッセージを送信し、Exchange サーバーは SMTP を使用してメッセージおよびメッセージ データを配信します。

ExchangeLink WMI クラスのプロパティは、メール サーバー間のメッセージ処理リンク (キュー) に関する情報を返します。リンクには 0 個以上の ExchangeQueue オブジェクトが含まれることがあります。この数は、リンクの現在のメッセージ トラフィックによって異なります。

SMTP は、SMTP キューを使用して内部または外部のメールを配信します。メッセージの分類および配信時には、アドバンスト キュー エンジンが SMTP 仮想サーバーの SMTP キューを介してすべてのメールを送信します。処理のいずれかの時点でメッセージの配信に問題があった場合、メッセージは問題の発生したキューに残ります。

SMTP キューの説明

SMTP キュー 説明

[ローカル ドメイン名] (ローカル配信)

Exchange メールボックスまたはパブリック フォルダ ストアへのローカル配信のために Exchange サーバー上のキューに格納されるメッセージが含まれています。

ディレクトリ参照待ちのメッセージ

Microsoft Active Directory ディレクトリ サービスに対してまだ解決されていない受信者へのメッセージが格納されます。メッセージはまた、配布リストが展開されている間もこのキューに保持されます。

ルーティング待ちのメッセージ

次の送信先サーバーが決定するまでメッセージを保持してから、個々のリンク キューにメッセージを移動します。

リモート配信

[コネクタ名 |

サーバー名 | リモート ドメイン]

リモート配信のためのメッセージが保持されています。キューの名前は、リモート配信の宛先 (コネクタ、サーバー、ドメインのいずれか) と一致します。

配信先に到達できないメッセージ

これらのメッセージの最終的な宛先のサーバーに到達できません。たとえば、Exchange で最終的な宛先へのネットワーク パスを判断できない場合などです。

送信前

SMTP サービスによって認識され受け入れられたメッセージが保持されます。これらのメッセージの処理は開始されませんでした。

発信を保留中の DSN メッセージ

Exchange によって配信される準備ができている配信状態通知 (配信不能レポートとも呼ばれます) が含まれます。

注 次の操作は、このキューでは使用できません。

  • すべてのメッセージを削除 (NDR を送信しない)

  • すべてのメッセージを削除 (NDR を送信する)

失敗したメッセージの再試行キュー

いくつかの種類のキュー送信処理に失敗したメッセージが保持されます。多くの場合、他の処理が行われる前にここに保持されます。既定では、このキュー内のメッセージは、60 分後に再度処理されます。

遅延配信のキューに置かれているメッセージ

後で配信するためにキューに入れられているメッセージが含まれます。これらのメッセージには、古いバージョンの Outlook によって送信されたメッセージなどがあります (このオプションは Outlook クライアント コンピュータで設定できます)。

以前のバージョンの Outlook では、メッセージの配信はメッセージ転送エージェント (MTA) に依存します。ただし現在は、MTA ではなく、SMTP がメッセージ配信を処理します。したがって、古いバージョンの Outlook によって送信されるメッセージは、違う方法で遅延配信を扱います。

これらのメッセージは、スケジュールされた配信時間までこのキューに残ります。

サーバーの ExchangeLink WMI クラスに対するクエリを正常に完了できない場合、Exchange アナライザはエラーを表示します。

このエラーは、要求されたデータを WMI クエリで取得できなかったことを示しています。

このエラーには、次のような原因が考えられます。

  • Exchange アナライザを実行するアカウントが、WMI クラスに対してクエリを実行するための十分なアクセス許可を持っていない。

  • ネットワークの問題により、Exchange アナライザからコンピュータにアクセスできない。

  • 原因不明な一時的な状態により、クエリのタイムアウトが発生した。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  3. ファイアウォールが設置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを調べます。

  4. Exchange アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange サーバーで、ローカルの Administrator アクセス許可を持っている必要があります。

    または、次の手順に従って、Exchange アナライザの実行に使用するアカウントに、特定の WMI アクセス許可を与えることもできます。

    1. Exchange コンピュータで、[コンピュータの管理] Microsoft 管理コンソール (MMC) のツリーを開きます。

    2. [サービスとアプリケーション] で、[WMI コントロール] を右クリックし、[プロパティ] をクリックします。

    3. [WMI コントロールのプロパティ] ページで、[セキュリティ] タブをクリックし、[Root] を展開します。

    4. [CIMV2] フォルダを選択し、[セキュリティ] をクリックします。

    5. [セキュリティ ROOT\CIMV2] ページで、Exchange アナライザの実行に使用するアカウントを追加します。

  5. 前の手順 4. で追加したアカウントを選択します。[<選択したアカウント> のアクセス許可] の [許可] 列で、[リモートの有効化] チェック ボックスと [セキュリティの読み取り] チェック ボックスをオンにし、[OK] をクリックします。

ネットワーク接続の問題に関するトラブルシューティングの詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange ベスト プラクティス アナライザ ツールの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールでの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Windows サーバー システムのサービス概要およびネットワーク ポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


DNS レコード テストに使用可能なリモート サーバーまたはドメインがなかった
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、リモート配信キュー内のメールが配信されるリモート サーバーの完全修飾ドメイン名 (FQDN)、IP アドレス、およびドメイン名を特定し、それらの一覧を作成します。

リモート サーバーの FQDN、IP アドレス、およびドメイン名の一覧は、次のように作成されます。

  • 簡易メール転送プロトコル (SMTP) 仮想サーバーの Active Directory® ディレクトリ サービス オブジェクトの msExchSmtpFullyQualifiedDomainName プロパティに対して、クエリが実行されます。

    注 :
    msExchSmtpFullyQualifiedDomainName プロパティは、指定されたターゲット ブリッジヘッド サーバーでルーティング グループ コネクタ ディレクトリ オブジェクトの msExchTargetBridgeheadServersDN プロパティに対してクエリが実行されると、このプロパティから読み取られます。
  • SMTP コネクタ Active Directory オブジェクトの msExchSmtpSmartHost プロパティに対して、SMTP コネクタの指定されたスマート ホストに関するクエリが実行されます。

  • Microsoft Windows® Management Instrumentation (WMI) クラス ExchangeLink の LinkName プロパティに対して、リモート サーバーの直接接続があるかどうかを問い合わせるクエリが実行されます。

この一覧を作成しようとしてエントリがないことが検出されると、エラーが表示されます。

このエラーは次のことを示します。

  • メールの流れに関する問題の原因となる、ネットワークまたは Active Directory の断続的な接続の問題が発生している可能性がある。

  • Exchange Server アナライザを実行するアカウントが、この情報のクエリを実行するための十分なアクセス許可を持っていない可能性がある。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

  3. Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  4. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  5. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを確認します。

  6. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワークの接続に関する問題の詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


SMTP コマンド テストに使用できるサーバーがない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-16

Microsoft® Exchange Server アナライザ ツールは、リモート配信キュー内のメールの宛先となっているリモート サーバーの完全修飾ドメイン名 (FQDN)、IP アドレス、およびドメイン名の識別および一覧の作成を試行します。

リモート サーバーの FQDN、IP アドレス、およびドメイン名の一覧は、次のように作成されます。

  • SMTP (Simple Mail Transfer Protocol) 仮想サーバーの Active Directory® ディレクトリ サービス オブジェクトの msExchSmtpFullyQualifiedDomainName プロパティに対して、クエリが実行されます。

    注 :
    msExchSmtpFullyQualifiedDomainName プロパティは、ルーティング グループ コネクタ ディレクトリ オブジェクトの msExchTargetBridgeheadServersDN プロパティに対して、指定された対象のブリッジヘッド サーバーについてのクエリが実行されると、このプロパティから読み取られます。
  • SMTP コネクタ Active Directory オブジェクトの msExchSmtpSmartHost プロパティに対して、SMTP コネクタに指定されているスマート ホストについてのクエリが実行されます。

  • Microsoft Windows® Management Instrumentation (WMI) クラス ExchangeLink の LinkName プロパティに対して、リモート サーバーの直接接続があるかどうかを問い合わせるクエリが実行されます。

Exchange Server アナライザで、この一覧を作成しようとしてエントリがないことが検出されると、エラーが表示されます。

このエラーは次のことを示します。

  • 断続的なネットワークまたは Active Directory 接続の問題がメール フローの問題の原因となっている可能性がある。

  • Exchange Server アナライザを実行するアカウントが、この情報のクエリを実行するための十分なアクセス許可を持っていない可能性がある。

このエラーを修正するには

  1. Exchange Server を実行するサーバーが起動され、ネットワークに接続されていることを確認します。

  2. Active Directory ドメイン コントローラにネットワーク接続できることを確認します。

  3. Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  4. PING コマンドを使用して、Exchange サーバーにアクセスできるかどうかを確認します。

  5. ファイアウォールが配置されている場合は、リモート プロシージャ コール (RPC) ポートがブロックされているかどうかを確認します。

  6. Exchange Server アナライザの実行に使用するアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワーク接続の問題に関する詳細については、マイクロソフト サポート技術情報の文書番号 325487 の、ネットワーク接続の問題のトラブルシューティング方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) (英語) を参照してください。

ポート要件の詳細については、マイクロソフト サポート技術情報の文書番号 832017 の、Windows サーバー システムのサービス概要およびネットワーク ポート要件についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


接続のテストに使用できるサーバーがない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、リモート配信キュー内のメールが配信されるリモート サーバーの完全修飾ドメイン名 (FQDN)、IP アドレス、およびドメイン名を特定し、それらの一覧を作成します。

  • リモート サーバーの FQDN、IP アドレス、およびドメイン名の一覧は、次のように作成されます。

  • 簡易メール転送プロトコル (SMTP) 仮想サーバーの Active Directory® ディレクトリ サービス オブジェクトの msExchSmtpFullyQualifiedDomainName プロパティに対して、クエリが実行されます。

    注 :
    msExchSmtpFullyQualifiedDomainName プロパティは、指定されたターゲット ブリッジヘッド サーバーでルーティング グループ コネクタ ディレクトリ オブジェクトの msExchTargetBridgeheadServersDN プロパティに対してクエリが実行されると、このプロパティから読み取られます。
  • SMTP コネクタ Active Directory オブジェクトの msExchSmtpSmartHost プロパティに対して、SMTP コネクタの指定されたスマート ホストに関するクエリが実行されます。

  • Microsoft Windows® Management Instrumentation (WMI) クラス ExchangeLink の LinkName プロパティに対して、リモート サーバーの直接接続があるかどうかを問い合わせるクエリが実行されます。

この一覧を作成しようとしてエントリがないことが検出されると、エラーが表示されます。

このエラーは次のことを示します。

  • メールの流れに関する問題の原因となる、ネットワークまたは Active Directory の断続的な接続の問題が発生している可能性がある。

  • Exchange Server アナライザを実行するアカウントが、この情報のクエリを実行するための十分なアクセス許可を持っていない可能性がある。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

  3. Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  4. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  5. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを確認します。

  6. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワークの接続に関する問題の詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


SMTP インスタンス名のチェックに使用可能なサーバーがなかった
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、リモート配信キュー内のメールが配信されるリモート サーバーの完全修飾ドメイン名 (FQDN)、IP アドレス、およびドメイン名を特定し、それらの一覧を作成します。

リモート サーバーの FQDN、IP アドレス、およびドメイン名の一覧は、次のように作成されます。

  • 簡易メール転送プロトコル (SMTP) 仮想サーバーの Active Directory® ディレクトリ サービス オブジェクトの msExchSmtpFullyQualifiedDomainName プロパティに対して、クエリが実行されます。

    注 :
    msExchSmtpFullyQualifiedDomainName プロパティは、指定されたターゲット ブリッジヘッド サーバーでルーティング グループ コネクタ ディレクトリ オブジェクトの msExchTargetBridgeheadServersDN プロパティに対してクエリが実行されると、このプロパティから読み取られます。
  • SMTP コネクタ Active Directory オブジェクトの msExchSmtpSmartHost プロパティに対して、SMTP コネクタの指定されたスマート ホストに関するクエリが実行されます。

  • Microsoft Windows® Management Instrumentation (WMI) クラス ExchangeLink の LinkName プロパティに対して、リモート サーバーの直接接続があるかどうかを問い合わせるクエリが実行されます。

この一覧を作成しようとしてエントリがないことが検出されると、エラーが表示されます。

このエラーは次のことを示します。

  • メールの流れに関する問題の原因となる、ネットワークまたは Active Directory の断続的な接続の問題が発生している可能性がある。

  • Exchange Server アナライザを実行するアカウントが、この情報のクエリを実行するための十分なアクセス許可を持っていない可能性がある。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

  3. Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  4. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  5. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを確認します。

  6. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワークの接続に関する問題の詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


既定以外のルーティング サービス キャッシュ設定
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、ルーティング サービス キャッシュに対する既定の設定が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\

ServerCacheRefreshInterval レジストリ値が手動で作成され、既定の Exchange Server バイナリ設定 900 が変更されていることが検出されると、警告メッセージが表示されます。既定では、ServerCacheRefreshInterval レジストリ値は Exchange Server インストールによって作成されません。ただし、既定のルーティング サービス キャッシュ設定を変更するため、Exchange Server のインストール後に ServerCacheRefreshInterval レジストリ値を手動で作成できます。レジストリ値が手動で作成され、レジストリ値の設定が誤って構成されている場合、Exchange Server ではメール フローの問題が発生します。

ServerCacheRefreshInterval レジストリ値の作成または変更は、慎重に検討してから行うことをお勧めします。Exchange Server に対するバイナリの既定値は、ほとんどの Exchange Server 環境での使用で最適なパフォーマンスが得られるように慎重に選択されたものです。一般的なベスト プラクティスは、レジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本原因に対処することです。ベスト プラクティスに準拠するため、ServerCacheRefreshInterval レジストリ値が存在する場合、このレジストリ値を削除し、Exchange Server を構成してルーティング サービス キャッシュに対する既定のバイナリ設定に戻すことができます。ただし、その判断は Exchange Server のカスタム構成設定や Exchange 環境によって異なります。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集して、このレジストリ値を既定の設定に戻すこともできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで、次のレジストリ キーに移動し、クリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\RESvc\Parameters\

  3. 詳細ペインで、[ServerCacheRefreshInterval] レジストリ値を右クリックします。値のデータを 900 に変更します。

  4. 必要に応じて、詳細ペインで [ServerCacheRefreshInterval] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP LdapRequestTimeLimit レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の LdapRequestTimeLimit が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

LdapRequestTimeLimit レジストリ値が手動で作成され、Exchange サーバー バイナリの既定の設定値である 600 秒から変更されていることが検出されると、既定以外の構成であることを示す警告メッセージが表示されます。既定では、LdapRequestTimeLimit レジストリ値は Exchange Server をインストールしても作成されません。ただし、単一の LDAP 要求がキュー内で待機する最大時間 (秒単位) を変更するために、Exchange Server のインストール後に LdapRequestTimeLimit レジストリ値を手動で作成できます。このレジストリ値が手動で作成され、そのレジストリ値の設定が正しく構成されていないと、Exchange サーバーでメッセージ トランスポートの問題が発生する可能性があります。

LdapRequestTimeLimit レジストリ値を作成または変更する場合は、事前に十分な検討を行うことをお勧めします。Exchange サーバーのバイナリにおける既定値は、ほとんどの Exchange サーバー環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、レジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。ベスト プラクティスに準拠するために、LdapRequestTimeLimit レジストリ値が存在する場合は、このレジストリ値を削除して Exchange サーバーを既定のバイナリ設定に戻すように構成し直すこともできます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集してレジストリ値を既定の設定に戻すことが必要になる場合もあります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで、次のレジストリ キーを見つけ、クリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、LdapRequestTimeLimit レジストリ値を右クリックします。値のデータを 600 に変更します。

  4. あるいは、詳細ペインで LdapRequestTimeLimit レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP LdapResultTimeout レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の LdapResultTimeout が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

LdapResultTimeout レジストリ キーが手動で作成され、既定の Exchange サーバーのバイナリ設定である 121 秒が変更されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。既定では、LdapResultTimeout レジストリ キーは Exchange Server のインストール時に作成されません。ただし、Exchange Server のインストール後に LdapResultTimeout レジストリ キーを手動で作成し、タイムアウトの値を変更することができます。LdapResultTimeout は、カテゴライザの LDAP 接続用の LDAP 完了スレッドが処理を待つ時間の上限 (秒単位) を示しています。タイムアウト時間が経過し、グローバル カタログ サーバーから新しい結果が受信されない場合、待機中の検索は接続に失敗し、LDAP_SERVER_DOWN が返されます。このプロセスは、これらの待機中の検索を新しい接続に対して再発行できるようにします。レジストリ値が手動で作成され、レジストリ値の設定が誤って構成されている場合、Exchange サーバーでメッセージ トランスポートの問題が発生することがあります。

LdapResultTimeout レジストリ値は、慎重に考慮したうえでのみ作成または変更することをお勧めします。Exchange Server のバイナリに含まれている既定値は、ほとんどの Exchange Server 環境で最適のパフォーマンスとなるように慎重に選択されています。一般的なベスト プラクティスは、このレジストリを手動で構成して Exchange の既定の動作を変更するのではなく、問題の根本的な原因に対処することです。ベスト プラクティスに従い、LdapResultTimeout レジストリ キーが存在している場合は、このレジストリ値を削除して Exchange サーバーを既定のバイナリ設定に戻すことができます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集してこのレジストリ値を既定の設定に戻すことができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで次のレジストリ キーを探してクリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、[LdapResultTimeout] レジストリ値を右クリックします。値のデータを 121 に変更します。

  4. または、詳細ペインで [LdapResultTimeout] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックし、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


既定以外の SMTP MaxConnectionRetries レジストリ値
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の MaxConnectionRetries が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

MaxConnectionRetries レジストリ値が手動で作成され、既定の Exchange Server バイナリ設定 20 が変更されていることが検出されると、既定以外の設定であることを示す警告メッセージが表示されます。既定では、MaxConnectionRetries レジストリ値は Exchange Server インストールによって作成されません。ただし、MaxConnectionRetries レジストリ値は、Exchange Server のインストール後に手動で作成して、値を変更できます。MaxConnectionRetries 値は、単一の分類が LDAP 接続に失敗した後で、新しい接続で再送信できる最大回数を設定します。MaxConnectionRetries 回の接続の分類が失敗すると、再試行キューに入れられます。レジストリ値が手動で作成され、レジストリ値の設定が誤って構成されている場合、Exchange Server でメッセージの転送エラーが発生する場合があります。

MaxConnectionRetries レジストリ値の作成または変更は、慎重に検討してから行うことをお勧めします。Exchange Server に対するバイナリの既定値は、ほとんどの Exchange Server 環境での使用で最適なパフォーマンスが得られるように慎重に選択されたものです。一般的なベスト プラクティスは、レジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本原因に対処することです。ベスト プラクティスに準拠するため、MaxConnectionRetries レジストリ値が存在する場合、このレジストリ値を削除し、Exchange Server を構成して既定のバイナリ設定に戻すことができます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集して、このレジストリ値を既定の設定に戻すこともできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで、次のレジストリ キーに移動し、クリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、[MaxConnectionRetries] レジストリ値を右クリックします。値を 20 に変更します。

  4. 必要に応じて、詳細ペインで [MaxConnectionRetries] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  5. Exchange Server を再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP MaxLdapConnections レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の MaxLdapConnections が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

MaxLdapConnections レジストリ値が手動で作成され、Exchange サーバー バイナリの既定の設定値である 8 から変更されていることが検出されると、既定以外の構成であることを示す警告メッセージが表示されます。既定では、MaxLdapConnections レジストリ値は Exchange をインストールしても作成されません。ただし、Exchange のインストール後に、MaxLdapConnections レジストリ値を手動で作成して値を変更することができます。MaxLdapConnections 値は、カテゴライザが単一のグローバル カタログ サーバーに対して開くことのできる LDAP 接続の最大数を設定します。このレジストリ値が手動で作成され、そのレジストリ値の設定が正しく構成されていないと、Exchange サーバーでメッセージ トランスポートの問題が発生する可能性があります。

注意 :
MaxLdapConnections レジストリ値は、HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters\MaxPoolThreads レジストリ値の設定と常に一致している必要があります。

MaxLdapConnections レジストリ値を作成または変更する場合は、事前に十分な検討を行うことをお勧めします。Exchange サーバーのバイナリにおける既定値は、ほとんどの Exchange サーバー環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、レジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。ベスト プラクティスに準拠するために、MaxLdapConnections レジストリ値が存在する場合は、このレジストリ値を削除して Exchange サーバーを既定のバイナリ設定に戻すように構成し直すこともできます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集してレジストリ値を既定の設定に戻すことが必要になる場合もあります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで、HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters というレジストリ キーを見つけてクリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、MaxLdapConnections レジストリ値を右クリックします。値のデータを 8 に変更します。

  4. あるいは、詳細ペインで MaxLdapConnections レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP MaxPendingSearches レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の MaxPendingSearches が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

MaxPendingSearches レジストリ値が手動で作成され、Exchange サーバー バイナリの既定の設定値である 60 から変更されていることが検出されると、既定以外の構成であることを示す警告メッセージが表示されます。既定では、MaxPendingSearches レジストリ値は Exchange Server をインストールしても作成されません。しかし、Exchange のインストール後に、MaxPendingSearches レジストリ値を手動で作成して値を変更することができます。MaxPendingSearches 値は、カテゴライザが特定の時点で特定のグローバル カタログ サーバーに対して保持する保留中の LDAP 検索の数を設定します。SP3 より前の Exchange 2000 Server では、接続あたりの保留中の検索の最大数は 1024 でした。Exchange 2000 Server SP3 および Exchange Server 2003 では、この既定値が 60 に設定されています。たとえば、この値を既定値の 60 から 30 に変更すると、カテゴライザがグローバル カタログ サーバーに対して保持する LDAP 検索の総数が減少します。

このレジストリ値が手動で作成され、そのレジストリ値の設定が正しく構成されていないと、Exchange サーバーでメッセージ トランスポートの問題が発生する可能性があります。

MaxPendingSearches レジストリ値を作成または変更する場合は、事前に十分な検討を行うことをお勧めします。Exchange サーバーのバイナリにおける既定値は、ほとんどの Exchange サーバー環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、レジストリを手動で構成して Exchange の既定の動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。ベスト プラクティスに準拠するために、MaxPendingSearches レジストリ値が存在する場合は、このレジストリ値を削除して Exchange サーバーを既定のバイナリ設定に戻すように構成し直すこともできます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集してレジストリ値を既定の設定に戻すことが必要になる場合もあります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで、次のレジストリ キーを見つけ、クリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、MaxPendingSearches レジストリ値を右クリックします。値のデータを 60 に変更します。

  4. あるいは、詳細ペインで MaxPendingSearches レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP MaxSearchBlockSize レジストリが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定の MaxSearchBlockSize が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters

MaxSearchBlockSize レジストリ値が手動で作成され、Exchange サーバー バイナリの既定の設定値である 20 から変更されていることが検出されると、既定以外の構成であることを示す警告メッセージが表示されます。既定では、MaxSearchBlockSize レジストリの値は Exchange Server のインストール時に作成されません。ただし、Exchange Server のインストール後に MaxSearchBlockSize レジストリ値を手動で作成し、値を変更することができます。MhelpsBlockSize の値は、単一の LDAP 検索として同時に送信できるカテゴライザ検索の最大数を示します。カテゴライザ検索の最大数を設定すると、カテゴライザ用の検索フィルタを簡略化することができます。

このプロセスは、これらの待機中の検索を新しい接続に対して再発行できるようにします。レジストリ値が手動で作成され、レジストリ値の設定が誤って構成されている場合、Exchange サーバーでメッセージ トランスポートの問題が発生することがあります。

MaxSearchBlockSize レジストリ値は、慎重に考慮したうえでのみ作成または変更することをお勧めします。Exchange Server のバイナリに含まれている既定値は、ほとんどの Exchange Server 環境で最適のパフォーマンスとなるように慎重に選択されています。一般的なベスト プラクティスは、このレジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本的な原因に対処することです。ベスト プラクティスに従い、MaxSearchBlockSize レジストリ キーが存在している場合は、このレジストリ値を削除して Exchange サーバーを既定のバイナリ設定に戻すことができます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリを編集してこのレジストリ値を既定の設定に戻すことができます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. コンソール ツリーで次のレジストリ キーを探してクリックします。 HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 詳細ペインで、[MaxSearchBlockSize] レジストリ値を右クリックします。値のデータを 20 に変更します。

  4. または、詳細ペインで [MaxSearchBlockSize] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックし、レジストリ値の削除を確認します。

  5. Exchange サーバーを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP TopoRecheckSecs レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\TopoRecheckSecs.

TopoRecheckSecs の値が既定値の 900 秒ではないことが検出されると、既定以外の構成であることを示すメッセージが表示されます。Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。操作は必要ありません。これは、DSAccess はグローバル カタログ一覧を再構築する間隔を設定するために TopoRecheckSecs レジストリの値を使用するので、設定を誤るとパフォーマンスが低下する可能性があります。ベスト プラクティスとして、可能な限り Exchange Server の既定の構成設定を使用します。ただし、このレジストリの値が存在している場合、以前に発生した問題を修正するために Microsoft 製品サポート サービスの指示によって追加され、構成されたものである可能性があります。このレジストリ値が Microsoft PSS または他の専門家の指示によって追加され、構成されたものでない場合は、削除することを検討してください。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
TopoRecheckSecs レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess

  3. 右側のペインで、TopoRecheckSecs 値を見つけて削除します。

  4. レジストリ エディタを終了します。

  5. 変更を永続的にするため、システム アテンダントを再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server のグローバル カタログの配置を最適化する方法の詳細については、『Understanding and Troubleshooting Directory Access』(http://go.microsoft.com/fwlink/?LinkId=39012) を参照してください (このサイトは英語の場合があります)。


Exchange 以外のゲートウェイ サーバーがスマート ホストとして設定されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-09

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの protocolCfgSMTPServer オブジェクト クラスの distingushedName 属性値に対してクエリを実行し、ユーザーが指定した Exchange ゲートウェイのすべての SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスの一覧を表示します。

次に、Active Directory に対して各 msExchRoutingSMTPConnector オブジェクトの msExchSourceBridgeheadServersDN および routingList 属性値に対してクエリを実行し、検出された SMTP 仮想サーバー インスタンスの 1 つが外部 SMTP アドレス スペースへのローカル ブリッジヘッドとして SMTP コネクタに正しく設定されているかどうかを判断します。

最後に、Active Directory に対して、検出されたすべての SMTP コネクタ (msExchRoutingSMTPConnector オブジェクト) の msExchSmtpSmartHost 属性値に対してクエリを実行し、そのうちの 1 つが Exchange 以外のユーザー指定ゲートウェイ サーバーのスマート ホストとして指定されているかどうかを判断します。

Exchange 以外のユーザー指定ゲートウェイ サーバーが SMTP コネクタの 1 つのスマート ホストとして設定されていないと判断した場合、Exchange Server アナライザは警告を表示します。

この警告は、ユーザー指定の Exchange ゲートウェイ サーバーから Exchange 以外のユーザー指定ゲートウェイ サーバーへの経路が明示的に設定されていないため、Exchange 以外のゲートウェイから組織の外部に誤ってメッセージがルーティングされる可能性があることを示します。

この問題を解決するには、Exchange 以外のゲートウェイ サーバーを SMTP コネクタのスマート ホストとして指定します。

スマート ホストの設定を表示して構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、目的の Exchange サーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] タブ、[詳細設定] の順にクリックします。

  5. 使用するスマート ホストを入力します。スマート ホストは、完全修飾ドメイン名または IP アドレスで識別することができます。IP アドレスを使用する場合は、IP アドレスを角かっこ ([ ]) で囲む必要があります。Exchange は、まずサーバー名があるかどうかを調べ、次に IP アドレスを調べます。角かっこがあると、その値は IP アドレスとして識別されます。そのため、DNS の参照は省略されます。

  6. Exchange 2000 Server を実行しているサーバーの場合は、必要に応じて [スマート ホストへ送信する前に直接配信を試行する] チェック ボックスをオンにします。

  7. [OK] をクリックして変更を保存し、もう一度 [OK] をクリックして SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

スマート ホスト コネクタの構成方法の詳細については、マイクロソフト サポート技術情報の文書番号 821911 の、スマート ホスト IP アドレスを使用するように Exchange Server 2003 を構成する方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821911) を参照してください。

SMTP コネクタの使用方法の詳細については、マイクロソフト サポート技術情報の文書番号 294736 の、Exchange 2000 以降のバージョンで SMTP コネクタの作成が必要な場合についてのページ (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=294736) を参照してください。

SMTP コネクタの詳細については、Exchange Server 2003 のトランスポートおよびルーティングに関するガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください。


カテゴライザで過負荷が発生している可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Cat:Messages submitted/sec および Cat:Categorizations completed/sec パフォーマンス カウンタからデータを収集して、そのパフォーマンス データを分析します。

Cat:Messages submitted/sec パフォーマンス カウンタは、カテゴライザに送信される 1 秒あたりのメッセージの数を示し、Cat:Categorizations completed/sec パフォーマンス カウンタは、1 秒あたりの完了した分類の数を示します。

Exchange Server アナライザは、2 つのカウンタの合計平均を比較して、メッセージが処理される以上に定常的に送信されているかどうかを判断します。

Exchange Server アナライザが、カテゴライザに送信される 1 秒あたりのメッセージ数の合計平均が 1 秒あたりの分類が完了するメッセージ数の合計平均よりも定常的に 2 つのメッセージ分だけ大きいと判断した場合、Exchange Server アナライザは警告を表示します。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

この警告は、カテゴライザの負荷が高い可能性があることを示します。考えられる原因を調べ、可能な場合は修正する必要があります。

カテゴライザの高負荷は、次の理由により多くのメッセージを処理する要求が原因で発生する場合があります。

  • 迷惑な商用電子メール (UCE) またはスパム。

  • ウイルスの蔓延。

  • サーバーのパフォーマンスの問題。

この警告に対処するには、次の操作を行います。

  • カテゴライザにかかる負荷が、予想負荷によるものであるか、通常の負荷によるものであるかを調べます。カテゴライザにかかる負荷が予想負荷によるものである場合は、以下の Microsoft TechNet 文書を参照して、Exchange のパフォーマンスに関する指示を確認してください。

    • Exchange Server 2003 のパフォーマンスのトラブルシューティングに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47588)。

    • Exchange Server 2003 のパフォーマンスとスケーラビリティ ガイドに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576)。

  • カテゴライザにかかる負荷が予想負荷によるものではない場合は、ウイルスの発生やスパムによる負荷が発生していないか確認します。


ゲートウェイで問題が発生している可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-09

Microsoft® Exchange Server アナライザ ツールは、Exchange Server を実行するサーバーからユーザー定義外部アカウントにテスト メッセージを送信します。次に、Exchange Server アナライザは、サーバーのメッセージ追跡ログをスキャンして、テスト メッセージの配信に問題があったかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntryMicrosoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、1 つまたは複数のメッセージ追跡ログ エントリが作成された原因を特定します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • メッセージ追跡ログを正常にスキャンできる。

  • テスト メッセージがキューから正常に転送されなかった。

  • 配信不能レポート (NDR) が生成されなかった。

  • EntryType プロパティの値が 1034 になっている。

  • メッセージが指定されたローカル Exchange 送信ゲートウェイ サーバーに届いた。

このエラーは、ユーザー指定のローカル Exchange 送信ゲートウェイ サーバーとリモート サーバーの間に接続問題があることを示す場合があります。

このエラーを解決するには、NSlookup ユーティリティを使用して、ドメイン ネーム システム (DNS) の解決に関する問題がないかどうかを確認します。ホスト到達不能エラーなどの接続やプロトコルの問題については、Telnet.exe を使用して宛先コンピュータへの接続を試みてください。プロトコル エラーをトラブルシューティングするには、SMTP (Simple Mail Transfer Protocol) コンポーネント用の MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイド (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション。

  • マイクロソフト サポート技術情報の文書番号 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)。

  • マイクロソフト サポート技術情報の文書番号 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)。

  • マイクロソフト サポート技術情報の文書番号 264054 の、[XCON] Exchange 2000 サーバーのキュー状態の理解に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)。


Inetinfo で問題が発生している可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。パフォーマンス データ収集エンジンは、SMTP Server パフォーマンス オブジェクトの Cat: Categorizations in progress パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Cat: Categorizations in progress パフォーマンス カウンタは、処理中の分類の数を示します。

このクエリの場合、Exchange Server アナライザは 2 分間の間に 6 秒ごとにサンプルを取得します。Exchange Server アナライザは、収集期間中のパフォーマンス カウンタの平均値を報告します。

サンプル期間中に、処理中の分類の最小数が一度も 0 にならなかったと判断すると、Exchange Server アナライザは警告を表示します。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

サーバーが高負荷の状態ではない場合、この警告は、Inetinfo.exe プロセス、または Inetinfo.exe プロセスが依存するリソースでデッドロックが発生していることを示している可能性があります。

Inetinfo.exe プロセスでは SMTP (Simple Mail Transfer Protocol) サービスが実行され、メッセージがトランスポート サブシステムを通過するときに、SMTP によってインターネット インフォメーション サービス (IIS) リソースが頻繁に使用されます。

デッドロックは、2 つ以上のプロセス (またはスレッド) が、それぞれのプロセスを続行するために他方のプロセスが完了するのを待っている場合に発生します。その結果、すべてのプロセス (またはスレッド) が応答を停止 (ハング) します。デッドロック状態では、プロセスは実行を完了することがなく、システム リソースは占有されます。このため、他のジョブの開始が妨げられます。

この警告に対処するには、次の操作を行います。

  • カテゴライザにかかる負荷が予想負荷によるものであるか、通常の負荷によるものであるかを調べます。カテゴライザが高負荷の状態ではない場合は、後の「詳細情報」に示されている参照情報を使用して、Inetinfo.exe プロセスまたは関連リソースで発生している可能性があるパフォーマンスの問題を特定します。

  • Inetinfo.exe プロセスが稼働しているかどうかを確認します。

  • マイクロソフト サポート技術情報の文書番号 919791 の、デバッグ診断ツールを使用して IIS のプロセスによる高い CPU 使用率のトラブルシューティングを行う方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=919791) のデバッグ手順に従って、Inetinfo.exe がデッドロック状態になっていないか確認します。

詳細情報

Inetinfo.exe の詳細については、Exchange Server 2003 テクニカル リファレンス ガイドの、インターネット インフォメーション サービスに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=72966) を参照してください。

デッドロック状態になっているプロセスのトラブルシューティング方法の詳細については、マイクロソフト サポート技術情報の文書番号 919791 の、デバッグ診断ツールを使用して IIS のプロセスによる高い CPU 使用率のトラブルシューティングを行う方法についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=919791) を参照してください。

Exchange Server のパフォーマンスの詳細については、Exchange Server 2003 のパフォーマンスとスケーラビリティのガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576) を参照してください。

Exchange Server のパフォーマンスに関する問題のトラブルシューティング方法の詳細については、Microsoft Exchange Server のパフォーマンスに関するトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47588) を参照してください。


ゲートウェイ以外で問題が発生している可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-09

Microsoft® Exchange Server アナライザ ツールは、Exchange Server を実行するサーバーから、ユーザー指定の外部受信者の SMTP アドレスにテスト メッセージを送信します。次に、Exchange Server アナライザは、サーバーのメッセージ追跡ログをスキャンして、テスト メッセージの配信に問題があったかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntryMicrosoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、1 つまたは複数のメッセージ追跡ログ エントリが作成された原因を特定します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • メッセージ追跡ログを正常にスキャンできる。

  • テスト メッセージがキューから正常に転送されなかった。

  • 配信不能レポートが生成されなかった。

  • EntryType プロパティの値が 1034 になっている。

  • メッセージが指定されたローカル Exchange 送信ゲートウェイ サーバーに届かなかった。

このエラーは、送信サーバーの SMTP (Simple Mail Transfer Protocol) リモート配信キューの 1 つにテスト メッセージが残されていて、そのキューに問題があることを示す場合があります。

リモート配信キューには、リモート配信用のメッセージが格納されます。キューの名前は、リモート配信の宛先と一致します。この宛先は、コネクタ、サーバー、ドメインのいずれかです。

プロトコル エラーをトラブルシューティングするには、SMTP コンポーネント用の MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。問題を再現するために、キューにメッセージを入れてもう一度試してみる作業が必要になる場合があります。イベント ログを調べて、Microsoft Exchange Information Store サービスに関連するエラーがないかどうかを確認してください。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイド (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47579) のメールの流れと SMTP に関するトラブルシューティングに関するセクションにある MSExchangeTransport のログ出力の設定を変更する方法に関する記述を参照してください。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション。

  • マイクロソフト サポート技術情報の文書番号 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)。

  • マイクロソフト サポート技術情報の文書番号 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)。

  • マイクロソフト サポート技術情報の文書番号 264054 の、[XCON] Exchange 2000 サーバーのキュー状態の理解に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)。


SMTP プロキシが検出された可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-12-06

Microsoft® Exchange Server アナライザ ツールは、SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにメッセージを送信しようとします。

Exchange Server アナライザが SMTP サーバーへのソケット接続を開くと、次の既定の応答が表示されます。

"220 Computer Name .Domain Name .com Microsoft ESMTP MAIL Service, Version:Version Number ready at Date Time +0000"

Exchange Server アナライザがサードパーティ固有の文字列を含む既定以外の応答を受信すると、Exchange Server アナライザはエラーを表示します。

このエラーは、リモート サーバーの内側で実行されるサードパーティ製の SMTP プロキシ サーバーが存在する可能性があることを示します。

Exchange Server 管理者が既定の SMTP バナーを意図的にカスタマイズしていない場合、この警告は、ESMTP (Exchange Server Extended Simple Mail Transfer Protocol) コマンドをフィルタ処理する SMTP プロキシの内側に Exchange Server が存在することを示している可能性があります。

Exchange Server の ESMTP コマンドがフィルタ処理されると、Exchange のパフォーマンスに大きな影響を与えたり、マイクロソフト サポート技術情報の文書番号 320027 の、Cisco PIX ファイアウォールの内側で電子メール メッセージを送受信できない現象に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=320027) に説明されている現象が発生したりする可能性があります。

カスタマイズされた SMTP バナーの詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 281224「[XCON] SMTP バナーを変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281224)


カテゴライザでパフォーマンスの問題が発生している可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink Microsoft WMI (Windows® Management Instrumentation) クラスに対して SMTP (Simple Mail Transfer Protocol) ProtocolName インスタンスの TypePendingCategorization 属性値に対してクエリを実行し、ディレクトリ参照待ちのメッセージ (MADL) SMTP キュー内のメッセージ数を判断します。

ExchangeLink WMI クラスのプロパティは、メール サーバー間のメッセージ処理リンク (キュー) に関する情報を返します。リンクには 0 個以上の ExchangeQueue オブジェクトが含まれることがあります。この数は、リンクの現在のメッセージ トラフィックによって異なります。

また、Exchange Server アナライザには、Exchange 2000 Server または Exchange Server 2003 を実行しているコンピュータ上のパフォーマンス カウンタ オブジェクトに対してクエリを発行するためのパフォーマンス データ収集エンジンが含まれています。

現在 MADL キューに 50 を超えるメッセージがあると判断すると、Exchange Server アナライザは、パフォーマンス データ収集エンジンで SMTP Server パフォーマンス オブジェクトの Cat: Messages Categorized および Cat: Categorizations completed パフォーマンス カウンタからデータを収集し、パフォーマンス データを分析します。

Cat: Messages Categorized パフォーマンス カウンタは、キューに入れるためにカテゴライザが送信したメッセージの数を示し、Cat: Categorizations completed パフォーマンス カウンタは、カテゴライザに送信されて完了したメッセージの総数を示します。

カテゴライザは、次の基本的な操作を実行します。

  • すべての受信者を解決し、確認する。

  • すべての受信者に対する制限を決定する。

  • 必要に応じて配布リストを展開する。

  • メッセージがローカル配信されるか、またはリモート配信されるかを判断する。

Exchange Server アナライザは、2 つのカウンタの平均総数を調べて、サンプリング期間中にそれらの数が増えたかどうかを判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • MADL キューに 50 以上のメッセージがある。

  • Cat: Messages Categorized パフォーマンス カウンタが、送信されたメッセージが次のプロセスに渡されている状態のサンプル期間中に増加した。

  • Cat: Categorizations completed パフォーマンス カウンタが、送信されたメッセージの分類が正常に完了している状態のサンプル期間中に増加した。

このエラーは、カテゴライザはメッセージを正常に処理しているが、キューの長さは大きいままであるためにパフォーマンスが低下している可能性があることを示しています。

カテゴライザのパフォーマンスは、以下の原因で多数のメッセージの処理を要求されることによって影響を受ける場合があります。

  • 迷惑な商用電子メール (UCE) またはスパム。

  • ウイルスの蔓延。

  • サーバーのパフォーマンスの問題。

この警告に対処するには、次の操作を行います。

  • カテゴライザにかかる負荷が、予想負荷によるものであるか、通常の負荷によるものであるかを調べます。カテゴライザにかかる負荷が予想負荷によるものである場合は、以下の Exchange リソースを参照して、Exchange のパフォーマンスに関する指示を確認してください。

    • Exchange Server 2003 のパフォーマンスのトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47588)

    • Exchange Server 2003 のパフォーマンスとスケーラビリティに関するガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47576)

  • カテゴライザにかかる負荷が予想負荷によるものではない場合は、ウイルスの発生やスパムによる負荷が発生していないか確認します。


配布グループの展開に関する問題が検出された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取って、Exchange サーバーが Exchange Server 2003 Service Pack 2 (SP2) を実行し、配信の制限をチェックするときに配布グループを展開するように構成されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters\RestrictionMethod

  • このエントリの値が 1 の場合、配信の制限をチェックするときに配布グループを展開するようにサーバーが構成されていることを示します。

  • このエントリの値が 2 の場合、配信の制限をチェックするときに配布グループを展開するようにサーバーが構成されていることを示します。

Exchange Server アナライザは、配信の制限をチェックするときに配布グループを展開するようにサーバーが設定されていることを検出すると、サーバーのイベント ログをチェックし、過去 24 時間以内にエラー イベント 6004、6006、および 6008 のすべてが発生したかどうかを判断します。

これらのイベントは、メッセージがメッセージ カテゴライザにトラップされていることを示します。メッセージ カテゴライザは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリをグローバル カタログ サーバーに送信してディレクトリ参照を実行する、アドバンスド キュー エンジンのコンポーネントです。

最後に、Active Directory® ディレクトリ サービスに対してクエリを実行し、以下のことを判断します。

  • 送信者を許可または禁止するために少なくとも 1 つの配布グループを使用するように配信の制限が設定されたフォレスト内に、500 を超えるメールボックスがあるかどうか。

  • ルーティング グループ コネクタに配布グループ メンバシップに基づいた配信の制限が設定され、ブリッジヘッド サーバーのコネクタ制限のチェックが有効に設定されているかどうか。

  • SMTP コネクタに配布グループ メンバシップに基づいた配信の制限が設定され、ブリッジヘッド サーバーのコネクタ制限のチェックが有効に設定されているかどうか。

以下の条件に当てはまる場合は、エラーが表示されます。

  • 配信の制限をチェックするときに配布グループを展開するように Exchange Server 2003 SP2 サーバーが構成されている。

  • Exchange サーバーが過去 24 時間以内にイベント 6004、6006、および 6008 を記録した。

  • 送信者を許可または禁止するために少なくとも 1 つの配布グループを使用するように配信の制限が設定されたフォレスト内に、500 を超えるメールボックスがあるか、配布グループ メンバシップに基づいた配信の制限が設定されたルーティング グループ コネクタがあり、ブリッジヘッド サーバーのコネクタ制限のチェックが有効に設定されているか、または、SMTP コネクタに配布グループ メンバシップに基づいた配信の制限が設定され、ブリッジヘッド サーバーのコネクタ制限のチェックが有効に設定されている。

RestrictionMethod の値は、カテゴライザが制限を処理する方法を判断します。既定では、カテゴライザは配布グループを再帰的に展開し、システムを通過するメッセージごとに制限を確認します。特定の配布グループまたはセキュリティ グループのメンバからのメッセージを拒否する制限を使用するように構成されている受信者に対して電子メール メッセージが送信されると、Exchange Server はそのグループを展開し、送信者が制限グループのメンバでないことを確認する必要があります。このグループを展開した結果はキャッシュされないため、毎回展開する必要があります。このため、カテゴライザ キューにメッセージが保持され、メッセージの処理に遅延が発生することがあります。

RestrictionMethod の値を 2 に設定している場合、この Exchange サーバーのトランスポート コンポーネントは、サーバーが制限を確認するときに配布グループのメンバシップを展開しません。この構成では、制限の確認に対して最適なパフォーマンスが得られます。また、RestrictionMethod レジストリ エントリを有効にするには、配信が制限されているユーザーを含むすべての配布グループをフラットな構成にする必要があります。つまり、制限のある配布グループでは、配布グループを入れ子にしないようにする必要があります。制限のある配布グループが入れ子になっている場合、展開ロジックは機能しません。

コネクタの制限で使用される配布グループでは、メールボックスを持たないコネクタ ブリッジヘッド サーバーで RestrictionMethod レジストリ エントリの値を設定することをお勧めします。Active Directory ユーザーの制限では、制限のある配布グループに展開サーバーがある場合、展開サーバーで RestrictionMethod レジストリ エントリを作成することをお勧めします。

配信の制限を構成したときに発生する現象の詳細については、Microsoft サポート技術情報の文書番号 812298「[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) を参照してください。

RestrictionMethod レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 895407「配布グループに基づく配信制限を構成した後に、 in exchange 低下するのが必要だより、 in exchange ローカル メールボックスにと外部メールボックスにサーバー メッセージの配信 2003 が低下します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407) を参照してください。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。

コネクタの制限の詳細については、Microsoft サポート技術情報の文書番号 277872「[XCON] コネクタの配信制限が正常に機能しないことがある」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872) を参照してください。

SMTP キューの詳細については、Microsoft サポート技術情報の文書番号 884996「待つディレクトリ検索メッセージなののにメッセージは、Exchange Server 2003 または Exchange 2000 Server SMTP キューのままになります。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=884996) を参照してください。


メッセージ履歴保持用の受信者に関する問題が検出された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは Win32_NTLogEvent Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、過去 24 時間以内にカテゴライザの警告イベント/エラー イベントの次の組み合わせが発生していないかどうかを判断します。

  • イベント 9004 およびイベント 9003

  • イベント 9035 およびイベント 6004

これらのイベントは、メッセージがメッセージ カテゴライザにトラップされていることを示します。メッセージ カテゴライザは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリをグローバル カタログ サーバーに送信してディレクトリ参照を実行する、アドバンスド キュー エンジンのコンポーネントです。

  • Exchange Server アナライザはまた、Active Directory® ディレクトリ サービスに対してクエリを実行し、以下のいずれかの条件に当てはまるかどうかも判断します。

  • ストア用に指定された履歴保持用の受信者が削除済みのオブジェクトを示している。

  • ストア用に指定された履歴保持用の受信者が、有効な mailNickname を持たないオブジェクトを示している。

  • ストア用に指定された履歴保持用の受信者が無効なアカウントを示している。

以下の条件に当てはまる場合は、エラーが表示されます。

  • 上記の警告イベント/エラー イベントのいずれかの組み合わせが発生している。

  • 指定された履歴保持用の受信者も、上記のいずれかの条件に当てはまる。

このエラーは、Exchange 環境の履歴保持に、メッセージのキューへの格納を引き起こす問題が発生している可能性があることを示しています。

この問題を修正する方法については、問題に関連する Exchange Server アナライザの次の文書を参照してください。

  • 履歴保持用の受信者が削除済みのオブジェクトを示す

  • ジャーナリング受信者が有効ではない

  • 履歴保持用の受信者が無効なアカウントを示す

  • Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。


メッセージ ジャーナリングとストア サービスに関する問題が検出された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、過去 24 時間以内にカテゴライザ警告イベント 9004 が発生していないかどうかを判断します。

また、Win32_Service WMI クラスに対してもクエリを実行し、Microsoft Exchange Information Store (MSExchangeIS) サービスが開始または停止されているかどうかを判断します。MSExchangeIS インスタンスの値が Started 以外の場合は、MSExchangeIS サービスが停止していることを示します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • サーバーが過去 24 時間以内にカテゴライザ警告イベント 9003 をログに記録した。

  • MSExchangeIS サービスが停止している。

このエラーは、メッセージ ジャーナリングまたは Microsoft Exchange Information Store サービス (Store.exe) に関連する問題が発生し、メッセージがキューに置かれている可能性があることを示します。

以下の条件のいずれかに当てはまる場合、この問題が発生することがあります。

  • Active Directory® ディレクトリ サービスから履歴保持用の受信者オブジェクトが削除されている。

  • SMTP ブリッジヘッド サーバーとして機能する Exchange Server コンピュータ上で、Information Store サービスが実行されていないか、無効になっている。

  • SMTP ブリッジヘッド サーバー上で 1 つ以上のメールボックス ストアがマウント解除されている。

この問題を解決するには、次の操作を行います。

  • SMTP ブリッジヘッド サーバーの Information Store サービスが有効で実行されていることを確認します。SMTP ブリッジヘッド サーバーのメールボックス ストアがマウントされていることを確認します。

  • メールボックス ストアの履歴保持用の受信者オブジェクトが Active Directory から削除されていないことを確認します。

メールボックス ストアの履歴保持用の受信者を確認するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス ストアを右クリックして [プロパティ] を選択します。

  3. [全般] タブで、[このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] チェック ボックスのすぐ下に表示されるアカウントを調べます。このアカウントが履歴保持用の受信者として使用されます。

    注 :
    各メールボックス ストア オブジェクトの履歴保持用の受信者があることを確認します。
新しいユーザー メールボックスを履歴保持用の受信者として指定するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、[<使用している Exchange サーバー>]、[<ストレージ グループ>] の順に展開し、メールボックス ストアを右クリックして [プロパティ] を選択します。

  3. [全般] タブで、[このストアのメールボックスで送受信したすべてのメッセージをアーカイブする] の右にある [参照] をクリックして、メールボックスを履歴保持用のメールボックスとして指定します。

    注 :
    このメールボックス ストア上の送信者の履歴保持対象のメッセージはすべて、指定したメールボックスに送信されます。

この問題については、「履歴保持用の受信者が削除済みのオブジェクトを示す」を参照してください。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。

履歴保持ソリューションを展開する方法の詳細については、Exchange Server における履歴保持についてのページ (http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


アクセス許可に関する潜在的な問題が検出された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは Win32_NTLogEvent Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、過去 24 時間以内に次の Exchange Server エラー イベントが発生していないかどうかを判断します。

  • イベント 929.

  • イベント 9035.

  • イベント 9003、9004、および 6004 の組み合わせ

Exchange Server エラー イベント 929 は、Active Directory® ディレクトリ サービス内の Exchange Server オブジェクトに対するアクセス許可が正しくない場合に発生することがあります。

Exchange Server エラー イベント 9003、9004、および 6004 は、メッセージがメッセージ カテゴライザにトラップされていることを示します。メッセージ カテゴライザは、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリをグローバル カタログ サーバーに送信してディレクトリ参照を実行する、アドバンスド キュー エンジンのコンポーネントです。

また、Exchange Server アナライザは Active Directory に対してもクエリを実行し、Exchange に関連するオブジェクトの属性が、これらのオブジェクトでアクセス許可の継承に関する問題が発生していることを示しているかどうかを判断します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • ディレクトリ参照待ちのメッセージ キューにメッセージが格納されているサーバーで、過去 24 時間以内に次のイベントまたはイベントの組み合わせのいずれかがログに記録されている。

    • イベント 929.

    • イベント 9035.

    • イベント 9003、9004、および 6004 の組み合わせ

  • Exchange に関連するオブジェクトにアクセス許可がないか、またはそのアクセス許可が正しくない。

このエラーは、Exchange 環境内に、メールがキューに格納される可能性のある、アクセス許可の継承に関連する問題が発生していることを示します。

この問題を解決するには、Microsoft サポート技術情報の文書番号 907969「ID 929 イベントが記録され、1 つのメール サーバーから Exchange 2000 Server 組織内の別のメール サーバーにメールが配信されません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=907969) に記載されている手順に従ってください。

Exchange Server 2003 のイベントとエラーの詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。


共通の宛先として識別されたパブリック フォルダ
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | キューの存在する仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、 Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信のタイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは取得したこれらのデータを使用して、各 Recipient オブジェクトの distinguishedName の値について、Active Directory® ディレクトリ サービスに対してクエリを実行します。次に、Exchange Server アナライザは、受信者が、ユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判別します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先が特定のパブリック フォルダになっていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先が特定のパブリック フォルダになっていると判断すると、Exchange Server アナライザはエラーを表示します。

この警告またはエラーは、識別されたパブリック フォルダが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、次に示すように対象のパブリック フォルダを調査して、メッセージがキューに入る原因となる構成の問題またはその他の異常点を見つける必要があります。

  • パブリック フォルダ オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • パブリック フォルダ オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • 対象のパブリック フォルダに対する迷惑な商用電子メール メッセージ (UCE)、スパム、またはウイルス攻撃の可能性を調べます。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=67875) (英語)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)


共通の宛先として識別されたパブリック フォルダ ストア
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | キューの存在する仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、 Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信のタイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは、取得したこれらのデータを使用して、各 Recipient オブジェクトの distinguishedName の値について、Active Directory® ディレクトリ サービスに対してクエリを実行します。次に、Exchange Server アナライザは、受信者が、ユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判別します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先の受信者のメールボックスが同一パブリック フォルダ ストアに配置されていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先の受信者のメールボックスが同一パブリック フォルダ ストアに配置されていると判断すると、Exchange Server アナライザはエラーを表示します。

この警告またはエラーは、識別されたパブリック フォルダ ストアが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、次に示すように対象のパブリック フォルダ ストアを調査して、メッセージがキューに入る原因となる構成の問題、レプリケーション ストーム、またはその他の異常点を見つける必要があります。

  • ストア オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • ストア オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • 対象のパブリック フォルダに対する迷惑な商用電子メール メッセージ (UCE)、スパム、またはウイルス攻撃の可能性を調べます。

  • パブリック フォルダ ストア間で多くのレプリケーションを生成した可能性のあるパブリック フォルダ階層またはコンテンツへの変更を確認します。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=67875) (英語)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • マイクロソフト サポート技術情報の記事 842273 の、Exchange 2000 Server および Exchange Server 2003 におけるパブリック フォルダのレプリケーションの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842273)


受信者フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchServerBindingsFiltering プロパティが、SMTP 仮想サーバー インスタンスに対して受信者フィルタが有効になっていることを示しているかどうかを判断します。

また、Active Directory に対してクエリを実行し、msExchRecipTurfListNames または msExchRecipTurfListOptions プロパティが、グローバル設定レベルでも受信者フィルタが有効になっていることを示しているかどうかを判断します。

受信者フィルタが SMTP 仮想サーバーのインスタンスとグローバル設定のレベルの両方で有効になっていることが検出されると、警告が表示されます。

この警告は、受信者フィルタが実質的に有効になっていることを示しています。受信者フィルタは一般に問題にはなりません。ただし、このサーバーに関連するメール フローの問題をトラブルシューティングする場合は、フィルタの構成を確認するか、または受信者フィルタを一時的に無効にして、有効な受信者へのメールが誤ってブロックされていないかどうかを判断する必要があります。

SMTP 仮想サーバーの受信者フィルタを無効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. フィルタを無効にする SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP Virtual Server> のプロパティ] ダイアログ ボックスで、[全般] タブの [詳細設定] をクリックします。

  5. [詳細設定] で、フィルタを無効にする IP アドレスを選択し、[編集] をクリックします。

[識別] で、[受信者フィルタを適用する] チェック ボックスをオフにしてフィルタを無効にします。

  1. 仮想サーバーが複数ある場合は、フィルタを無効にする各仮想サーバーに対して手順 3. ～ 6. を繰り返します。

受信者フィルタを構成する方法の詳細については、Microsoft サポート技術情報の文書番号 823866「Exchange 2003 で接続フィルタを構成してリアルタイム ブロック リスト (RBL) を使用する方法と受信者フィルタを構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823866) を参照してください。

インテリジェント メッセージ フィルタの詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


[リモート配信] キューが停止している
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) リモート配信キューの StateFrozen キーの値を判断します。

Exchange サーバー上のリモート配信キューの StateFrozen キーの値が True に設定されていることが検出されると、エラーが表示されます。

停止したキューとは、そのキューのトランスポート セッションが停止しているキューを指します。停止したキューからメッセージは送信されませんが、新しいメッセージの追加は可能です。各リンク キューのショートカット メニューを使用して、接続の状態を手動で変更することができます。[再接続] コマンドを使用してキューの状態をアクティブに変更すると、そのキューからメッセージを送信するための接続を直ちに有効にすることができます。

リモート配信キューには、リモート配信のためのメッセージが保持されています。キューの名前は、リモート配信の宛先と一致します。この宛先は、コネクタ、サーバー、ドメインのいずれかです。

このエラーを解決するには、NSlookup ユーティリティを使用して、ドメイン ネーム システム (DNS) の解決に関する問題がないかどうかを確認します。ホスト到達不能エラーなどの接続やプロトコルの問題については、Telnet.exe を使用して宛先コンピュータへの接続を試みてください。プロトコル エラーをトラブルシューティングするには、SMTP プロトコル コンポーネント用の MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。問題を再現するために、キューにメッセージを入れてもう一度試してみる作業が必要になる場合があります。イベント ログを調べて、Microsoft Exchange Information Store サービスに関連するエラーがないかどうかを確認してください。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[リモート配信] キューが再試行状態にある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、ExchangeLink WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) のリモート配信キューの StateRetry キーの値を判断します。

Exchange サーバー上のリモート配信キューの StateRetry キーの値が True に設定されていることが検出されると、エラーが表示されます。

キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

リモート配信キューには、リモート配信のためのメッセージが保持されています。キューの名前は、リモート配信の宛先と一致します。この宛先は、コネクタ、サーバー、ドメインのいずれかです。

このエラーを解決するには、NSlookup ユーティリティを使用して、ドメイン ネーム システム (DNS) の解決に関する問題がないかどうかを確認します。ホスト到達不能エラーなどの接続やプロトコルの問題については、Telnet.exe を使用して宛先コンピュータへの接続を試みてください。プロトコル エラーをトラブルシューティングするには、SMTP プロトコル コンポーネント用の MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。問題を再現するために、キューにメッセージを入れてもう一度試してみる作業が必要になる場合があります。イベント ログを調べて、Microsoft Exchange Information Store サービスに関連するエラーがないかどうかを確認してください。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


[リモート配信] キューに問題がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリが作成された原因を判断します。

以下の条件に当てはまる場合は、エラーが表示されます。

  • メッセージ追跡ログを正常にスキャンできる。

  • テスト メッセージがキューから正常に転送されなかった。

  • 配信不能レポート (NDR) が生成されなかった。

  • EntryType プロパティの値が 1034 になっている。

このエラーは、送信サーバーの SMTP (Simple Mail Transfer Protocol) リモート配信キューの 1 つにテスト メッセージが残されていて、そのキューに問題があることを示しています。

リモート配信キューには、リモート配信用のメッセージが格納されます。キューの名前は、リモート配信の宛先と一致します。この宛先は、コネクタ、サーバー、ドメインのいずれかです。

このエラーを解決するには、NSlookup ユーティリティを使用して、ドメイン ネーム システム (DNS) の解決に関する問題がないかどうかを確認します。ホスト到達不能エラーなどの接続やプロトコルの問題については、Telnet.exe を使用して宛先コンピュータへの接続を試みてください。プロトコル エラーをトラブルシューティングするには、SMTP プロトコル コンポーネント用の MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。問題を再現するために、キューにメッセージを入れてもう一度試してみる作業が必要になる場合があります。イベント ログを調べて、Microsoft Exchange Information Store サービスに関連するエラーがないかどうかを確認してください。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


分類の再試行
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリの原因を判断します。

Exchange Server アナライザによって EntryType プロパティの値が 1032 であることが検出されると、警告が表示されます。

この警告は、テスト メッセージが、分類の再試行がスケジュールされたキューに格納されていることを示しています。キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

一般に、メッセージが再試行待ちでキュー内に蓄積される状態は、アドバンスド キュー エンジンがそのメッセージを分類できないことが原因です。アドバンスド キュー エンジンがグローバル カタログ サーバーにアクセスできず、受信者情報にアクセスできない状態になっている可能性があります。あるいは、グローバル カタログ サーバーが到達不能か、またはパフォーマンスが低下しています。さらに、以下の理由でメッセージが蓄積される場合もあります。

  • Active Directory が使用不可能である。

    注 :
    カテゴライザは Active Directory を使用してメッセージを分類します。
  • 分類前のキューに多数のメッセージが格納されている場合は、Active Directory の負荷が高くなりすぎている可能性がある。

  • 変換で障害が発生している。カテゴライザはコンテンツの変換も処理します。

  • メッセージ カテゴライザがメールボックス ストアを見つけることができない。

  • SMTP が再インストールまたは削除された場合は、IIS メタベース キー /smtpsvc/DsUseCat および /smtpsvc/vsi#/DsUseCat が無効になる可能性がある。

    注 :
    SMTP を再インストールまたは削除したかどうかを確認してください。

キューが "再試行" 状態にある場合は、キューのプロパティを調べて原因を判断します。たとえば、キューのプロパティに "SMTP エラーが発生しました" のようなメッセージが表示される場合は、サーバーのイベント ログを確認して SMTP エラーを見つける必要があります。ログにイベントが記録されていない場合は、SMTP プロトコルのログ レベルを上げる必要があります。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


ローカル配信の再試行
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-04

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリの原因を判断します。

Exchange Server アナライザによって EntryType プロパティの値が 1037 であることが検出されると、警告が表示されます。

この警告は、ローカル配信キューにあるメッセージの処理中に少なくとも 1 つのエラーが発生したことを示しています。

ローカル配信キューには、Exchange Server メールボックスまたはパブリック フォルダ ストアへのローカル配信のために Exchange サーバー上のキューに格納されるメッセージが含まれています。

Exchange サーバーがローカル配信用のメッセージを受け付けていない場合は、メッセージがこのキューに蓄積されます。メッセージ配信が遅延したり途切れたりする場合は、メッセージのループまたはパフォーマンスの問題が発生していることを示している可能性があります。

[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

このエラーを解決するには、MSExchangeIS および MSExchangeTransport サービスの SMTP ストア ドライブ コンポーネントの診断ログを増やします。

ログの設定を変更する方法の詳細については、トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、ログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


ルーティングの再試行
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザ ツールは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリの原因を判断します。

Exchange Server アナライザによって EntryType プロパティの値が 1035 であることが検出されると、警告が表示されます。

この警告は、テスト メッセージが、ルーティングの再試行がスケジュールされたキューに格納されていることを示しています。キューが再試行の状態にある場合は、キュー内のメッセージに対するこれまでの処理中に少なくとも 1 つのエラーが発生したことを示しています。[再接続] コマンドを使用して、再試行またはスケジュール済みの状態にあるキューをアクティブの状態に変更することができます。これにより、キューは再試行間隔が経過したか、またはスケジュールされた時間に達したかのように機能します。ただし、この方法は、常に機能するとは限りません。

注 :
キューのプロパティは、キューが再試行の状態にある特定の原因を示している場合があります。

Exchange Server にルーティングの問題が存在すると、メッセージが再試行待ちでキュー内に蓄積されます。メッセージがルーティングされなかったのは一時的なエラー、つまりルーティング エンジンの初期化の失敗が原因です。これらのメッセージは、再試行待ちでルーティング前のキューに格納されているか、または再ルーティングされているところです。

このエラーを解決するには、MSExchangeTransport サービスの診断ログを増やし、ルーティング カテゴリ コンポーネントに関する情報を収集します。コネクタを制限するとサーバーのパフォーマンスが大幅に低下する場合があるため、不要なコネクタ制限はすべて無効にしてください。いくつかの制限については、CheckConnectorRestrictions レジストリ キーをオンにすることが必要な場合があります。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション (このサイトは英語の場合があります)

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


DNS 逆引き参照がメタベースでは有効になっているが、Active Directory 内の関連付けられた SMTP サーバーでは有効になっていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの次のプロパティを読み取り、その値が Active Directory® ディレクトリ サービスの msExchSmtpPerformReverseDnsLookup 属性の構成値と一致するかどうかを判断します。

/LM/SmtpSvc/<SMTP virtual server instance>/EnableReverseDnsLookup

これらの値が一致しないことが検出されると、警告メッセージが表示されます。

IIS メタベースの値が Active Directory の値と一致しない場合は、Exchange 内で Active Directory のレプリケーションに問題が発生しているか、またはディレクトリ サービスからメタベースへのレプリケーション (DS2MB) に問題が発生していることを示している可能性があります。

DS2MB プロセスの機能は、構成情報を Active Directory からローカルのメタベースに転送することです。パフォーマンスとスケーラビリティの理由から、この構成はレジストリではなくローカル メタベースに格納されます。Exchange 2000 Server および Exchange Server 2003 では、すべてのインターネット プロトコル (SMTP、NNTP、POP3、IMAP4、および HTTP) が IIS のコンポーネントとして実行されます。

DS2MB プロセスは 15 分ごとに、サブツリー全体をその形状を変えずに Active Directory からコピーします。この処理は、Active Directory からメタベースへの一方的な書き込みであり、メタベースから Active Directory への書き込みはありません。

EnableReverseDnsLookup プロパティおよび msExchSmtpPerformReverseDnsLookup 属性はどちらも、TRUE または FALSE の値をとることができます。値が TRUE の場合は、この SMTP 仮想サーバーが、すべての受信メッセージに対して DNS 逆引き参照を実行します。値が FALSE の場合は、この SMTP 仮想サーバーは DNS 逆引き参照を実行しません。誤って構成された DNS レコードやインターネットへの断続的な接続のためにパフォーマンスが低下する可能性があるため、EnableReverseDnsLookup プロパティと msExchSmtpPerformReverseDnsLookup 属性は、既定で FALSE に設定されます。

EnableReverseDnsLookup プロパティが TRUE (有効) に設定され、msExchSmtpPerformReverseDnsLookup 属性が FALSE (無効) に設定されている場合は、Active Directory と IIS メタベースの同期がとれていません。問題が DS2MB プロセスのエラーのために発生している場合は、実行している Exchange Server のバージョンに対応する以下の手順に従って、問題を修正することができます。Active Directory レプリケーションの一部のエラーまたは完全なエラーのために問題が発生している場合は、Active Directory レプリケーション モニタ ユーティリティ (ReplMon.exe) を使用して、Active Directory レプリケーションの状態を確認できます。ReplMon.exe は、Windows Server CD-ROM の Windows® サポート ツールに含まれています。

Exchange Server 2003 でこのエラーを修正するには

  1. ソースが MSExchangeMU のアプリケーション イベント ログ エントリが存在するかどうかを確認します。DS2MB は、エラーが発生すると、Exchange Server 2003 でイベントをログ出力します。

  2. DS2MB のエラーが見つからない場合は、ReplMon を使用して Active Directory レプリケーションを診断します。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  3. DS2MB のエラーが見つかった場合、または Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange 2000 Server でこのエラーを修正するには

  1. ReplMon を使用して、Active Directory レプリケーションを診断します。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  2. Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange の DNS 逆引き参照機能の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、Microsoft サポート技術情報の文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686) および文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163) を参照してください。

Active Directory レプリケーションの詳細については、Microsoft サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

DS2MB プロセスの詳細については、Microsoft サポート技術情報の文書番号 240105「[XGEN] Exchange 2000 Server のディレクトリ サービス/メタベース同期に関する概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105) を参照してください。


ルーティング エンジン : AttachedTimeout パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\AttachedTimeout

AttachedTimeout レジストリ キーが存在し、300 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

AttachedTimeout レジストリ エントリは、ORG_INFO パケットが送信される頻度を判断する、Exchange Server のカスタム構成設定です。ルーティング クライアントがルーティング サーバーに接続しなくなるたびに、トポロジのユーザー バージョンがインクリメントされ、組織全体へ ORG_INFO パケットがブロードキャストされます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. AttachedTimeout レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

AttachedTimeout レジストリの値の詳細については、Microsoft サポート技術情報の文書番号 832281「Exchange 2000 Server および Exchange Server 2003 におけるリンク状態とルーティングの問題。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832281) を参照してください。


ルーティング エンジン : BestAddressMatchOnly パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\BestAddressMatchOnly

BestAddressMatchOnly レジストリ キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

BestAddressMatchOnly レジストリ エントリは、既存の制限にかかわらず、特定のドメイン宛てに送信されるメールを強制的に特定のコネクタを経由してルーティングする、Exchange Server のカスタム構成設定です。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. BestAddressMatchOnly レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ルーティング エンジン : CheckConnectorRestrictions パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\CheckConnectorRestrictions

CheckConnectorRestrictions レジストリ キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

CheckConnectorRestrictions レジストリ エントリは、確認対象のコネクタのソースになっている Exchange ブリッジヘッド サーバーで制限の確認を行えるようにする、Exchange Server 用のカスタム構成設定です。既定では、パフォーマンスに大きな影響を与える可能性があるため、コネクタの制限の確認処理は無効になっています。特に、多数の配布グループを使用する構成には大きな影響があります。制限の確認は、システムを通過して各配布グループのメンバそれぞれに送信されるメッセージごとに行われます。制限が指定されていても、このレジストリ エントリが存在しないと、制限の確認は実行されません。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. CheckConnectorRestrictions レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. IIS Admin サービスを再開します。

  6. コネクタの [配信の制限] タブで、制限のオプションを再度有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

CheckConnectorRestrictions レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 277872「[XCON] コネクタ配信制限が正常に機能しない」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=277872) を参照してください。


ルーティング エンジン :Configuration パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Exchange ルーティング エンジン設定用の Active Directory® ディレクトリ サービスの読み取り間隔が、既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\ReloadOsInterval

ReloadOsInterval の値のデータが 3600 以外に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

ReloadOsInterval 値は、Exchange を実行しているサーバー間でルーティングのリンク状態情報を更新する間隔を指定するために使用されます。Exchange はルーティングのリンク状態情報を使用して、各サーバーが最もコストの低いルートを判断してメッセージを配信できるようしたり、ルートを構成するコネクタが機能しているかどうかを判断したりします。既定では、Exchange サーバーは 3,600 秒 (1 時間) ごとに、Active Directory からリンク状態情報を読み取ります。

特定の状況において、Exchange 組織全体のサーバーに、ルーティングの状態情報が動的に正しく伝達されないことがあります。組織内の一部のサーバーは、古くなり、正しくなくなっている可能性があるルーティングの状態情報を使用して動作し続けます。そのため、WinRoute ツール (Winroute.exe) を使用してリモートのルーティング グループを表示したときに表示されない新しいコネクタが存在する可能性があります。WinRoute ツールを使用すると、リンク状態情報が伝達されていることを確認できます。それには、Exchange 組織内のいくつかの場所で WinRoute ツールを使用してリンク状態情報を表示し、各ルーティング グループのバージョン番号を比較します。WinRoute ツールは、Exchange Server コンピュータのリンク状態ポートに接続し、その Exchange 組織のリンク状態情報を抽出します。リンク状態情報は一連のグローバル一意識別子 (GUID) ですが、WinRoute は、コネクタとブリッジヘッド サーバーの GUID を Active Directory 内のオブジェクトと照合し、理解しやすい形式で情報を表示します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters

  3. 右側のペインで、[ReloadOsInterval] をダブルクリックします。

  4. [値のデータ] ボックスに「3600」と入力し、[OK] をクリックします。

  5. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986 の Microsoft Windows レジストリの説明についての記事 (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

ルーティングとリンクの状態情報の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 842026 の、Exchange 2000 Server または Exchange Server 2003 でルーティングの状態情報がすべてのサーバーに正しく伝達されない現象についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842026)

  • 文書番号 285130 の、[XCON] リンク状態データベース情報についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=285130)

ルーティング マスタで識別されているリンク状態情報の確認に役立つツール、WinRoute をダウンロードするには、Exchange Server WinRoute のページ (http://go.microsoft.com/fwlink/?LinkId=25049) (英語) を参照してください。


ルーティング エンジン : PollingInterval パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\PollingInterval

PollingInterval レジストリ キーが存在し、300 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

PollingInterval レジストリ キーは、ルーティング グループ間、特にルーティング グループ内のルーティング グループ マスタ間のリンク状態トラフィックの頻度の制御に役立つ Exchange Server 用のカスタム構成設定です。この設定を大きくすると接続エラーは回避されますが、ルーティング グループのメンバ間の低速リンクという、より大きな問題に対処できなくなる可能性があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. PollingInterval レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ルーティング エンジン : StateChangeDelay パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\StateChangeDelay

StateChangeDelay レジストリ キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

StateChangeDelay レジストリ エントリは、コネクタを使用不可としてマークする間隔や、コネクタとサーバーの状態が変化したために発生する通知の制御に役立つ Exchange Server 用のカスタム構成設定です。StateChangeDelay が 0 より大きい値に設定されている場合は、この値で設定されている各期間内に 1 回だけ、サーバーを使用可能または使用不可としてマークできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. StateChangeDelay レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


ルーティング エンジン : SuppressStateChanges パラメータが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP (Simple Mail Transfer Protocol) コネクタのルーティング ロジックが既定の設定から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters\SuppressStateChanges

SuppressStateChanges レジストリ キーが存在し、0 より大きい値に構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange Server 2003 には、リンク状態の変化を自動的に検出する機能があります。この情報を使用すると、Exchange Server 2003 を実行している他のサーバーに、最もコストが低い主ルートの代わりに代替ルートを使用する必要があることを通知できます。リンク状態の情報は、大きな変更と小さな変更に分かれます。大きな変更は、新しいコネクタやコストの変更を加えた場合など、管理者がルーティング トポロジを変更すると発生します。小さな変更は、システムで、リンクの障害や復元が自動的に検出された場合に発生します。

この機能は、小規模から中規模の組織で有効に機能します。ただし、大規模な複数サイトの環境では、ネットワークの変動要因が多数あるために、小さな更新によるリンク更新が大量に発生する可能性があります。この機能を本当に有効にするには、リンク状態のデータを組織内のすべてのサーバーにブロードキャストする必要があります。さらに、状態が変化するとリンク状態テーブル全体が再度ブロードキャストされるので、ネットワーク上に大量のデータが転送される可能性があります。このようなシナリオでは、小さなリンク状態の変更を無効にすると有用な場合があります。SuppressStateChanges レジストリ エントリは、小さなリンク状態の変更を無効にするために使用されるカスタム構成設定です。SuppressStateChanges が 0 より大きい値に設定されている場合、この Exchange Server コンピュータで発生したリンク状態の変更はすべて無効になります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\System\CurrentControlSet\Services\RESvc\Parameters

  3. SuppressStateChanges レジストリ キーを削除します。

  4. レジストリ エディタを終了します。

  5. SMTP (Simple Mail Transfer Protocol)、Microsoft Exchange Routing Engine、および Microsoft Exchange MTA Stacks の各サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

SuppressStateChanges レジストリ キーの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?linkid=47579) (このサイトは英語の場合があります)

  • 『Performance and Scalability Guide for Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47576) (このサイトは英語の場合があります)


ルーティング グループ コネクタに、配布グループによる配信の制限が設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出された各ルーティング グループ コネクタ オブジェクト (msExchRoutingGroupConnector) の次の属性に対してクエリを実行し、配布グループ メンバシップに基づいた配信の制限が設定されているかどうかを判断します。

dLMemRejectPerms | このルーティング グループ コネクタ経由の送信を許可されていないメンバの配布リスト (DL) のドメイン名 (DN) が含まれています。
dLMemSubmitPerms | このルーティング グループ コネクタ経由の送信を許可されているメンバの配布リスト (DL) のドメイン名 (DN) が含まれています。

配布グループ メンバシップに基づいた配信制限が設定されているルーティング グループ コネクタがあると判断すると、Exchange Server アナライザは警告を表示します。

この警告は、配布グループのメンバシップに基づいた配信制限が Exchange メール フローのパフォーマンスに影響を与える可能性があることを示します。

配布グループのメンバシップに基づいた配信制限が設定されているルーティング グループ コネクタを使用してメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

この警告に対処するには、次の操作を行います。

  • コネクタ制限専用のルーティング グループを設計し、ローカル ルーティング グループとして構成します。その方法については、マイクロソフト サポート技術情報の文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • コネクタ用に指定するブリッジヘッド サーバーとして、専用の、より堅牢性の高いグローバル カタログ サーバーを使用します。

  • マイクロソフト サポート技術情報の文書番号 812298 の [XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • SMTP (Simple Mail Transfer Protocol) 送信者フィルタの実装を検討します。

  • Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange 2003 SP2 より前のバージョンの Exchange を実行するサーバーでは、Exchange 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

SMTP 送信者フィルタの詳細については、Exchange Server 2003 の管理ガイドの、送信者フィルタを有効にする方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=72967) を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照してください。

  • 文書番号 895407 の Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。


ルーティング グループ マスタが削除されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、各ルーティング グループ コンテナの msExchRoutingMasterDN 属性の値を判断します。msExchRoutingMasterDN 属性の値に "DEL:" という文字列が含まれていることが検出されると、エラーが表示されます。

msExchRoutingMasterDN 属性は、各ルーティング グループのルーティング グループ マスタとして機能している Exchange Server コンピュータの識別名を格納する、単一値を持つ属性です。"DEL:" という文字列が存在する場合は、以前のルーティング グループ マスタが Active Directory ユーザーとコンピュータ ツールを使用して削除された可能性があることを示します。ルーティング グループ マスタがないと、Exchange はルーティング トポロジの正常な更新または管理を行うことができません。

ルーティング グループを作成する場合、そのルーティング グループの最初のサーバーに、"ルーティング グループ マスタ" の役割が割り当てられます。ルーティング グループ マスタは、ルーティング グループに対して現在のリンク状態情報を保持し、この情報をルーティング グループを持つ他のサーバーに適用します。ルーティング グループ マスタは、そのルーティング グループのみについて、Active Directory に書き込まれるルーティング構成を監視します。メンバ サーバーは、他のコネクタ状態またはサーバーの可用性情報をルーティング グループ マスタに通信します。たとえば、メンバ サーバーが、あるコネクタを介して、別のルーティング グループ内の別のサーバーとの通信を試み、そのリンクが使用できない場合、メンバ サーバーは直ちにルーティング グループ マスタに通知します。同様に、マスタ以外のサーバーは、新しいリンク状態情報を受信すると直ちにコネクタ状態情報をルーティング グループ マスタに転送します。このため、他のサーバーはルーティングの変更に関する情報を受信することができます。

このエラーを修正するには

  1. Exchange システム マネージャの [管理グループ] の下で、[<管理グループ名>] を展開し、[ルーティング グループ] を展開します。

  2. ルーティング グループを展開し、[メンバ] をクリックします。

  3. 右側のペインで、ルーティング グループ マスタとして構成する Exchange コンピュータを右クリックし、[マスタに設定] をクリックします。

ルーティング グループ マスタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?linkid=47579) の「Configuring a Routing Topology」を参照してください (このサイトは英語の場合があります)。


ルーティング グループのメンバシップ エラー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの Routing Group オブジェクトの msExchRoutingGroupMembersBL 属性の各値に対してクエリを実行し、後方リンクされたサーバーが専用の Microsoft Exchange Server 2007 管理グループである Exchange 管理グループ (FYDIBOHF23SPDLT) に属しているかどうかを判断します。

また、Exchange Server アナライザは、Routing Group オブジェクトの CN 属性の値に対してクエリを実行し、値が既定の Exchange 2007 ルーティング グループの Exchange ルーティング グループ (DWBGZMFD01QNBJR) と同等かどうかを判断します。

以下の条件に当てはまる場合、Exchange Server アナライザはエラーを表示します。

  • 後方リンクされたサーバーが専用の Microsoft Exchange Server 2007 管理グループである Exchange 管理グループ (FYDIBOHF23SPDLT) に属している。

  • ルーティング グループが既定の Exchange 2007 ルーティング グループである Exchange ルーティング グループ (DWBGZMFD01QNBJR) に属していない。

このエラーは、サーバーが既定の Exchange 2007 ルーティング グループから手動で移動された可能性があることを示します。これにより、ルーティングの問題が発生する場合があります。

Microsoft Exchange Server 2003 と Microsoft Exchange 2000 Server は、ルーティング グループを使用して Exchange 固有のルーティング トポロジを定義します。Exchange 2007 は Active Directory を使用してルーティング トポロジを定義します。Exchange 2003 と Exchange 2000 は、ルーティング グループとコネクタに基づくルーティング トポロジを使用します。Exchange 固有のルーティング構成は、完全な Exchange 2007 組織では不要になりました。完全な Exchange 2007 組織は、Active Directory サイトのトポロジを使用してルーティング トポロジを決定します。

これらの 2 つのルーティング トポロジの共存をサポートするために、Exchange 2007 のインストール時に、すべての Exchange 2007 サーバーが 1 つのルーティング グループに自動的に追加されます。Exchange 2007 ルーティング グループは、Exchange 2003 または Exchange 2000 の Exchange システム マネージャで、Exchange 管理グループ (FYDIBOHF23SPDLT) 内の Exchange ルーティング グループ (DWBGZMFD01QNBJR) として認識されます。

この問題を解決するには、Exchange 2007 サーバーを Exchange 2007 専用のルーティング グループに移動するか、サーバーを削除して、再インストールします。


送信コネクタが無効である
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-07-30

Microsoft Exchange アナライザ ツールは、次の Exchange 管理シェル コマンドレットを使用して、Enabled 属性が False に設定された Exchange 環境のすべての送信コネクタを照会します。送信コネクタの Enabled 属性が False に設定されていると、送信コネクタは無効になります。

Get-SendConnector | where { $_.Enabled -eq $False}

次に、Exchange アナライザは Active Directory ディレクトリ サービスに対してクエリを実行し、msExchExchangeServer オブジェクト クラスを持つすべてのオブジェクトについて serialNumber 属性の値を判断します。

文字列値に "Version 5.5" が含まれている場合、コンピュータでは Microsoft Exchange Server 5.5 が実行されています。この文字列値に "Version 6.0" が含まれている場合は、Exchange 2000 Server が実行されています。文字列値に "Version 6.5" が含まれている場合、Exchange Server 2003 が実行されています。文字列値に "Version 8" が含まれている場合、Exchange Server 2007 が実行されています。

Exchange アナライザが、Exchange 2000 または Exchange 2003 サーバーがある Exchange 環境で、送信コネクタが無効であると判断した場合には、エラーが表示されます。

このエラーは、Exchange 2007 ルーティングが、無効にされた送信コネクタを無視する一方で、Exchange 2000 または Exchange 2003 が、コネクタが無効にされたフラグを認識せず、無効にされたコネクタを経由するメッセージングを依然としてルーティングしようと試みる結果、ルーティングのループに陥ることがあることを示します。

このエラーに対処するには、無効にされた送信コネクタを Exchange 2000 または Exchange 2003 を実行している Exchange 環境から削除します。

無効にされた送信コネクタを削除するには、Exchange Server 2007 製品ドキュメントの「Remove-SendConnector」(http://go.microsoft.com/fwlink/?LinkId=96007) トピックにある Exchange 管理シェルの Remove-SendConnector コマンドレットの使用に関するガイダンスに従ってください。


送信者フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchServerBindingsTurflist プロパティが、SMTP 仮想サーバー インスタンスに対して送信者フィルタが有効になっていることを示しているかどうかを判断します。

また、Active Directory に対してクエリを実行し、msExchTurfListNames プロパティまたは msExchTurfListOptions プロパティが、グローバル設定のレベルでも送信者フィルタが有効になっていることを示しているかどうかを判断します。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • SMTP 仮想サーバー インスタンスに対して送信者フィルタが有効になっている。

  • グローバル設定のレベルで送信者フィルタが有効になっている。

この警告は、送信者フィルタが実質的に有効になっていることを示しています。送信者フィルタは一般に、この特定のサーバーに関連するメール フローの問題をトラブルシューティングしていない限り問題にはなりません。このトラブルシューティングを行っている場合は、フィルタ構成を確認するか、または送信者フィルタを一時的に無効にして、有効な送信者からの正当なメールが誤ってブロックされていないかどうかを判断する必要があります。

SMTP 仮想サーバーで送信者フィルタを無効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. フィルタを無効にする SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[全般] タブをクリックし、[詳細設定] をクリックします。

  5. [詳細設定] で、フィルタを無効にする IP アドレスを選択し、[編集] をクリックします。

  6. [識別] で、[送信者フィルタを適用する] チェック ボックスをオフにしてフィルタを無効にします。

  7. 仮想サーバーが複数ある場合は、フィルタを無効にする各仮想サーバーに対して手順 3. ～ 6. を繰り返します。

インテリジェント メッセージ フィルタの詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。

フィルタの構成方法やスパムの制御方法の詳細については、トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、フィルタの構成とスパムの制御に関するセクションを参照してください (このサイトは英語の場合があります)。


送信者 ID のフィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchServerBindingsFiltering プロパティが、SMTP 仮想サーバー インスタンスに対して送信者 ID フィルタが有効になっていることを示しているかどうかを判断します。

また、Exchange Server アナライザは Active Directory に対してクエリを実行し、UCE Content Filter オブジェクトの wWWHomePage 属性に送信者 ID と接続フィルタのエントリが含まれているかどうかも判断します。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • SMTP 仮想サーバー インスタンスに対して送信者フィルタが有効になっている。

  • 送信者フィルタが UCE Content Filter オブジェクト レベルで有効になっている。

この警告は、送信者 ID フィルタが実質的に有効になっていることを示しています。送信者 ID フィルタは一般に、この特定のサーバーに関連するメール フローの問題をトラブルシューティングしていない限り問題にはなりません。このトラブルシューティングを行っている場合は、フィルタ構成を確認するか、または送信者 ID フィルタを一時的に無効にして、有効な送信者からのメールが誤ってブロックされていないかどうかを判断する必要があります。

SMTP 仮想サーバーで送信者 ID フィルタを無効にするには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、[サーバー] を展開し、目的のサーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. フィルタを無効にする SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [<SMTP 仮想サーバー> のプロパティ] ダイアログ ボックスで、[全般] タブをクリックし、[詳細設定] をクリックします。

  5. [詳細設定] で、フィルタを無効にする IP アドレスを選択し、[編集] をクリックします。

  6. [識別] で、[送信者フィルタを適用する] チェック ボックスをオフにしてフィルタを無効にします。

  7. 仮想サーバーが複数ある場合は、フィルタを無効にする各仮想サーバーに対して手順 3. ～ 6. を繰り返します。

インテリジェント メッセージ フィルタの詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


共通の宛先として識別されたサーバー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | キューの存在する仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、 Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信のタイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは取得したこれらのデータを使用して、各 Recipient オブジェクトの以下の値について、Active Directory® ディレクトリ サービスに対してクエリを実行します。次に、Exchange Server アナライザは、受信者が、ユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判別します。

distinguishedName | オブジェクトの識別名を示します。
msExchHomeServerName | この受信者が配置されているサーバーを示します。
homeMDB | 受信者のメールボックス ストアを示します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先が特定サーバーの受信者になっていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先が特定サーバーの受信者になっていると判断すると、Exchange Server アナライザはエラーを表示します。

この警告またはエラーは、識別されたサーバーが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、次に示すように対象のサーバーを調査して、メッセージがキューに入る原因となる構成の問題またはその他の異常点を見つける必要があります。

  • サーバー オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • サーバー オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • サーバーが特別な用途のユーザー オブジェクトに、つまり指定された履歴保持用の受信者に使用するホーム サーバーである場合は、そのユーザー オブジェクトが関連付けられているサービスまたはコンポーネントの構成が正しいことを確認します。

  • 対象のパブリック フォルダに対する迷惑な商用電子メール メッセージ (UCE)、スパム、またはウイルス攻撃の可能性を調べます。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=67875) (英語)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスおよび外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)

  • 329171 の、[XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)

  • 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)


シンクの登録が見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-01-11

Microsoft® Exchange Server アナライザ ツールは、Microsoft Internet Information Service (IIS) メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) トランスポート イベント シンクのバインドの一覧を列挙します。Exchange Server アナライザは、前もって作成された以下の一覧に基づいて、いくつかの標準のイベント バインドの場所の特定を試みます。バインドごとに、Exchange Server アナライザは、次のブランチのレジストリにあるコンポーネント オブジェクト モデル (COM) 登録の詳細を確認します。

HKEY_CLASSES_ROOT\CLSID\

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • トランスポート イベント シンクのバインドがメタベースで見つかった。

  • 対応する COM 登録がレジストリに存在しない。

SMTP トランスポート イベントは SMTP サービスでメッセージ データが送受信されたときに発生します。したがって、すべてのメッセージがイベントによって処理されます。これらには、X.400 および RPC の送受信メッセージが含まれます。受信トランスポート イベントの一般的な例には、SMTP サービスにネットワーク経由でメッセージが送信されたときに発生するイベントや、SMTP ピックアップ ディレクトリに送信されたときに発生するイベントなどがあります。このトランスポート イベントが発生すると、このイベント ソースによってトランスポート イベント シンクに通知され、メッセージのデータの内容に基づいた動作が実行されます。メッセージ データをシンクに渡した後に、シンクがそのイベントを完了して返すまで、システムがメッセージ データを使用して別の動作を実行することはありません。シンクが動作しているときは、シンクでメッセージのデータや状態が排他的に制御されます。

トランスポート イベント シンクのバインド用の見つからない COM 登録がメール フローの問題の原因になります。Exchange Server でメッセージがキューに入るなどのメール フローの問題の兆候が現れた場合は、トランスポート イベント シンクを再登録します。

トランスポート イベント シンクを再登録するには、次の操作を実行します。

  1. Exchange Server でコマンド プロンプト ウィンドウを開き、\Program Files\Exchsrvr\Bin フォルダに移動します。

  2. トランスポート イベント シンクを再登録するには、次のコマンドを入力します。

    regsvr32 /i exps.dll

    regsvr32 /i miscat.dll

    regsvr32 /i onsubmit.dll

    regsvr32 /i peexch50.dll

    regsvr32 /i phatcat.dll

    regsvr32 /i protolog.dll

    regsvr32 /i reapi.dll

    regsvr32 /i regsinks.dll

    regsvr32 /i tranmsg.dll

    regsvr32 /i turflist.dll

    regsvr32 /i xlsasink.dll

    regsvr32 /i msgfilter.dll

  3. Exchange Server アナライザに戻り、警告が表示されないことを確認します。イベント シンクの登録に関する警告が表示され、メール フローの問題が解決しない場合は、Microsoft 製品サポート サービス (PSS) にお問い合わせください。

トランスポート イベント シンクのバインドの詳細については、次の Exchange に関するリソースを参照してください。

  • Microsoft サポート技術情報の文書番号 258224「[XCON] 登録済みのトランスポート イベント シンクを表示する」(http://go.microsoft.com/fwlink/?linkID=3052&kbid=258224)

  • 『Technical Reference Guide for Exchange Server 2003』の「SMTP Service Design」(http://go.microsoft.com/fwlink/?LinkId=58876) (このサイトは英語の場合があります)


SMTP 仮想サーバーでスマート ホストが設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、特定の SMTP 仮想サーバーで msExchSmtpSmartHost 属性が構成されているかどうかを判断します。msExchSmtpSmartHost 属性が構成されていることが検出されると、警告が表示されます。

ベスト プラクティスとして、SMTP 仮想サーバーではスマート ホストを構成しないようにすることをお勧めします。代わりに、SMTP コネクタを作成し、そこでスマート ホストの設定を構成する必要があります。

Exchange Server 2003 では、インターネット メール ウィザードを使用してインターネット メールの配信を構成します。詳細については、『Exchange Server Transport and Routing Guide』の「How to Use Internet Mail Wizard」(http://go.microsoft.com/fwlink/?LinkId=50099) を参照してください (このサイトは英語の場合があります)。

SMTP コネクタの作成方法の詳細については、『Exchange Server Transport and Routing Guide』の「How to Create an SMTP Connector」(http://go.microsoft.com/fwlink/?LinkId=50100) を参照してください (このサイトは英語の場合があります)。


SMTP AdditionalPoolThreadsPerProc レジストリ値が手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、追加のプール スレッドが手動で構成されたかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\AdditionalPoolThreadsPerProc

AdditionalPoolThreadsPerProc が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

SMTP には、ATQ スレッドと呼ばれるスレッドのプールを使用するワーク キューが 5 つあります。仕様により、これらのキューのうち 2 つは、既定で、使用可能なスレッドの 90% まで使用することができます。このスレッド プールは、POP および IMAP の要求を受け付けるプロセスによって共有されます。したがって、負荷が中程度から高程度のシナリオで、SMTP が POP および IMAP サービスのリソースを保持可能な状況が発生する可能性があります。

SMTP で使用できるスレッドの割合を制限することで、POP および IMAP 用のスレッドを十分確保できます。この変更を行うには、IIS で利用できるスレッドの総数を増やします。この変更による代償は、スレッドの追加によってメモリの使用量が増加することのみです。

ユーザーが SMTP スレッドの割合と、プロセッサあたりの追加スレッド数を制御できるようにするレジストリ値は、以下の 2 つです。

場所 : HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

値 : AdditionalPoolThreadsPerProc

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

値 : MaxPercentPoolThreads

種類 : REG_DWORD

クラスタ化された Exchange Server コンピュータでは、SMTP の処理量が多いために POP3 と IMAP4 のどちらか、または両方のリソースが不足する場合、両方のレジストリ値を調整する必要があります。次の計算式を使用して、クラスタの最適値を求めることができます。

レジストリ値 | 計算式
AdditionalPoolThreadsPerProc | ((9 / (MaxPercentPoolThreads/100)) - 4) / 2
MaxPercentPoolThreads | 90 / (2 x プロトコルの仮想サーバー数)

たとえば、2 つのプロトコル仮想サーバーがある Exchange Server クラスタの場合、MaxPercentPoolThreads を求める計算式は、"90 / (2 x 2) = 22" となります。MaxPercentPoolThreads 値を計算すると小数点を含む値になる場合は、結果の端数を切り捨てて整数にする必要があります。AdditionalPoolThreadsPerProc 値を計算し、結果が 200 より大きい値になる場合は、計算結果の値を次のレジストリ値にも割り当てる必要があります。

場所 : HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\

値 : PoolThreadLimit

種類 : REG_DWORD

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange クラスタで最適な設定を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. DWORD のレジストリ値を AdditionalPoolThreadsPerProc という名前で作成し、その値を、上の計算式で求めた適切な数値に設定します。

  4. DWORD のレジストリ値を MaxPercentPoolThreads という名前で作成し、その値を、上の計算式で求めた適切な数値に設定します。

  5. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この文書で説明した特定のクラスタ リソースの問題に関する詳細については、Microsoft サポート技術情報の文書番号 281868「[XADM] 負荷が大きいときに POP\IMAP4 仮想サーバーが繰り返しフェール オーバーする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281868) を参照してください。


SMTP Archive Sink: Archive P1 ヘッダーが設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP Archive Sink がインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Dump P1

Dump P1 の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

値が 0 の場合、P1 ヘッダーのアーカイブは無効になっています。値が 1 の場合、P1 ヘッダーのアーカイブは有効になっています。0 と 1 以外の値はサポートされていません。

SMTP Archive Sink ツールは、Exchange サーバー上の特定のフォルダで送受信されるすべてのメッセージのアーカイブを有効にするカスタム スクリプトです。既定では、SMTP Archive Sink が有効になっている場合、すべてのメッセージとその受信者は、Bcc 受信者を除き, .eml ファイルにアーカイブされます。

P1 ヘッダーは、"エンベロープ" データとも呼ばれます。エンベロープ データは、メッセージの転送時に Exchange が生成する実際の受信者一覧で、メッセージがすべての受信者に到達できるようにするためのものです。受信される特定のメール内で送信者によって宣言された受信者を含む P2 ヘッダーとは異なり、エンベロープ データは多くの宛先へ転送されるときに変更されます。これらの変更は、配布リストの展開と隠し配布リストの動作により発生します。

既定では、SMTP Archive Sink をインストールして有効にしたときに P1 ヘッダーはアーカイブされません。通常、P1 ヘッダーのアーカイブはトラブルシューティングの目的でのみ有効にします。

この Exchange コンピュータで P1 ヘッダーをアーカイブしない場合は、Dump P1 レジストリ キーを 0 に設定するか、SMTP Archive Sink をアンインストールします。SMTP Archive Sink をアンインストールすると、SMTP Archive Sink によって使用されているすべてのレジストリ キーが削除されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

P1 ヘッダーのアーカイブを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Dump P1 レジストリ キーをダブルクリックし、[値のデータ] ボックスに 「0」と入力し、[OK] をクリックします。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を有効にします。

SMTP Archive Sink をアンインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. C:\Program Files\Exchsrvr\bin フォルダで、「cscript archivesink_setup.vbs」と入力し、Enter キーを押します。

  3. 「cscript archivesink_setup.vbs uninstall Virtual Server ID」と入力します。ここで、Virtual Server ID は SMTP Archive Sink がインストールされている仮想サーバーの仮想サーバー番号です。

  4. コマンド プロンプト ウィンドウを終了し、IIS Admin サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 で SMTP Archive Sink をセットアップして構成する方法の詳細については、Microsoft サポート技術情報の文書番号 871110「インストールし、 Exchange Server 2003 の Archive Sink ユーティリティを使用する方法方法には」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110) を参照してください。

Exchange 2000 Server で SMTP Archive Sink をセットアップして構成する方法の詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

規制準拠を目的とした履歴保持ソリューションの展開については、『Journaling with Exchange Server』(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


SMTP Archive Sink が有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP Archive Sink がインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable Smtp Messages

Enable Smtp Messages の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が 0 の場合は、SMTP Archive Sink が無効になっていることを示します。この値が 1 の場合は、SMTP Archive Sink が有効になっていることを示します。0 または 1 以外の値はサポートされていません。

SMTP Archive Sink ツールは、Exchange サーバー上の特定のフォルダから送受信するすべてのメッセージをアーカイブできるようにするカスタム スクリプトです。既定では、SMTP Archive Sink が有効になっていると、すべてのメッセージおよびその受信者 （BCC 受信者は除く） が .eml ファイルにアーカイブされます。

既定では、SMTP Archive Sink で SMTP アーカイブを有効にすると、SMTP (Simple Mail Transfer Protocol)、Exchange ストア、またはその他の任意のシンクがトランスポートに送信するすべてのメッセージによってこのイベントがトリガされます。理論的には、このイベントは各メッセージに対して 1 回発生する可能性があり、またこのイベントは 1 回だけアーカイブできます。OnMessageSubmission イベントは、ルーティングまたはカテゴライザ イベントの前に発生します。そのため、これらのメッセージは PreCat メッセージとも呼ばれます。既定では、このイベントでメッセージがアーカイブされるのは、SMTP Archive Sink ツールがインストールされている場合です。このイベントでアーカイブされたメッセージには、ARCH_random number.xml というプレフィックス ファイル名が含まれています。

この Exchange コンピュータでメッセージをアーカイブしない場合は、Enable Smtp Messages レジストリ キーを 0 に設定するか、または SMTP Archive Sink をアンインストールすることができます。SMTP Archive Sink をアンインストールすると、SMTP Archive Sink が使用するすべてのレジストリ キーが削除されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

SMTP Archive Sink を無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. [Enable Smtp Messages] レジストリ キーをダブルクリックし、[値のデータ] フィールドに「0」と入力します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を有効にします。

SMTP Archive Sink をアンインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. C:\Program Files\Exchsrvr\bin フォルダで、「cscript archivesink_setup.vbs」と入力し、Enter キーを押します。

  3. 「cscript archivesink_setup.vbs uninstall Virtual Server ID」と入力します。ここで、Virtual Server ID は、SMTP Archive Sink がインストールされている仮想サーバーの仮想サーバー番号です。

  4. コマンド プロンプト ウィンドウを終了し、IIS Admin サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 871110「インストールする方法と Microsoft Exchange Server 2003 で Archive Sink ユーティリティを使用する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110) を参照してください。

Exchange 2000 Server での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798) を参照してください。

規制遵守を目的とした包括的な履歴保持ソリューションの展開の詳細については、「Journaling with Exchange Server」(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


SMTP Archive Sink: 分類後の設定
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP Archive Sink がインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable PostCat

Enable PostCat の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

値が 0 の場合、分類後のメッセージ アーカイブは無効です。値が 1 の場合、分類後のメッセージ アーカイブは有効です。0 または 1 以外の値はサポートされません。

SMTP Archive Sink ツールは、Exchange サーバーの特定のフォルダに入る、または特定のフォルダから出て行くすべてのメッセージのアーカイブを有効にするカスタム スクリプトです。既定では、SMTP Archive Sink が有効になっていると、すべてのメッセージおよびその受信者 （BCC 受信者は除く） が .eml ファイルにアーカイブされます。

Enable PostCat が 1 に設定されていると、メッセージの分類が行われた後でメッセージがアーカイブされます。メッセージによってこのイベントは複数回引き起こされることがありますが、メッセージが分類されてキューに入れられた後で再び列挙された場合のみ発生します。このイベントでアーカイブされたメッセージには、プレフィックス付きのファイル名 ARCH_POSTCAT_ランダム数.xml が含まれます。

この Exchange コンピュータに分類後のメッセージをアーカイブしない場合は、Enable PostCat レジストリ キーを 0 に設定してください。このコンピュータでまったくアーカイブしない場合は、SMTP Archive Sink をアンインストールしてください。SMTP Archive Sink をアンインストールすると、SMTP Archive Sink が使用するすべてのレジストリ キーが削除されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

分類後のメッセージ アーカイブを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. [Enable PostCat] レジストリ キーをダブルクリックし、[値のデータ] フィールドに「0」と入力し、[OK] をクリックします。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を有効にします。

SMTP Archive Sink をアンインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. C:\Program Files\Exchsrvr\bin フォルダで、「cscript archivesink_setup.vbs」と入力し、Enter キーを押します。

  3. 「cscript archivesink_setup.vbs uninstall Virtual Server ID」と入力します。ここで、Virtual Server ID は、SMTP Archive Sink がインストールされている仮想サーバーの仮想サーバー番号です。

  4. コマンド プロンプト ウィンドウを終了し、IIS Admin サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 871110「インストールする方法と Microsoft Exchange Server 2003 で Archive Sink ユーティリティを使用する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110) を参照してください。

Exchange 2000 Server での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798) を参照してください。

規制遵守を目的とした包括的な履歴保持ソリューションの展開については、『Journaling with Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


SMTP Archive Sink : 分類前のメッセージ アーカイブが設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP Archive Sink がインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Enable PreCat

Enable PreCat の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この値が 0 の場合は、分類前のメッセージ アーカイブが無効になっていることを示します。この値が 1 の場合は、分類前のメッセージ アーカイブが有効になっていることを示します。0 または 1 以外の値はサポートされていません。

SMTP Archive Sink ツールは、Exchange サーバー上の特定のフォルダから送受信するすべてのメッセージをアーカイブできるようにするカスタム スクリプトです。既定では、SMTP Archive Sink が有効になっていると、すべてのメッセージと Bcc 受信者を除くすべての受信者が .eml ファイルにアーカイブされます。

このイベントは、SMTP (Simple Mail Transfer Protocol)、Exchange ストア、またはその他のシンクがトランスポートに送信するすべてのメッセージによってトリガされます。理論的には、このイベントは各メッセージに対して 1 回発生する可能性があり、またこのイベントは 1 回だけアーカイブできます。OnMessageSubmission イベントは、ルーティングまたはカテゴライザ イベントの前に発生します。そのため、これらのメッセージは PreCat メッセージとも呼ばれます。既定では、このイベントでメッセージがアーカイブされるのは、SMTP Archive Sink ユーティリティがインストールされている場合です。このイベントでアーカイブされたメッセージには、ARCH_random number.xml というプレフィックス ファイル名が含まれています。

この Exchange コンピュータ上で分類前のメッセージをアーカイブしない場合は、Enable PreCat レジストリ キーを 0 に設定できます。このコンピュータ上でアーカイブをまったく行わない場合は、SMTP Archive Sink をアンインストールすることができます。SMTP Archive Sink をアンインストールすると、SMTP Archive Sink によって使用されているすべてのレジストリ キーが削除されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

分類前のメッセージ アーカイブを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. Enable PreCat レジストリ キーをダブルクリックし、[値のデータ] フィールドに「0」と入力します。次に、[OK] をクリックします。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を有効にします。

SMTP Archive Sink をアンインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. C:\Program Files\Exchsrvr\bin フォルダで、「cscript archivesink_setup.vbs」と入力し、Enter キーを押します。

  3. 「cscript archivesink_setup.vbs uninstall Virtual Server ID」と入力します。この Virtual Server ID は、SMTP Archive Sink がインストールされている仮想サーバーの仮想サーバー番号です。

  4. コマンド プロンプト ウィンドウを閉じ、IIS Admin サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 で SMTP Archive Sink をセットアップおよび構成する方法の詳細については、Microsoft サポート技術情報の文書番号 871110「インストールし、 Exchange Server 2003 の Archive Sink ユーティリティを使用する方法方法には」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110) を参照してください。

Exchange 2000 Server で SMTP Archive Sink をセットアップおよび構成する方法の詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798) を参照してください。

規制遵守を目的とした包括的な履歴保持ソリューションの展開の詳細については、「Journaling with Exchange Server」(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


SMTP Archive Sink: システム メッセージがアーカイブされている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP Archive Sink がインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\ArchiveSink\1\Archive System Messages

Archive System Messages の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

値が 0 の場合、システム メッセージはアーカイブされません。値が 1 の場合、システム メッセージはアーカイブされます。0 または 1 以外の値はサポートされません。

SMTP Archive Sink ツールは、Exchange サーバーの特定のフォルダに入る、または特定のフォルダから出て行くすべてのメッセージのアーカイブを有効にするカスタム スクリプトです。既定では、SMTP Archive Sink が有効になっていると、すべてのメッセージおよびその受信者 （BCC 受信者は除く） が .eml ファイルにアーカイブされます。

この Exchange コンピュータにシステム メッセージをアーカイブしない場合は、Archive System Messages レジストリ キーを 0 に設定します。このコンピュータでまったくアーカイブしない場合は、SMTP Archive Sink をアンインストールしてください。SMTP Archive Sink をアンインストールすると、SMTP Archive Sink が使用するすべてのレジストリ キーが削除されます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

システム メッセージのアーカイブを無効にするには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink\1

  3. [Archive System Messages] レジストリ キーをダブルクリックし、[値のデータ] フィールドに「0」と入力し、[OK] をクリックします。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して、変更を有効にします。

SMTP Archive Sink をアンインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「cmd」と入力し、[OK] をクリックします。

  2. C:\Program Files\Exchsrvr\bin フォルダで、「cscript archivesink_setup.vbs」と入力し、Enter キーを押します。

  3. 「cscript archivesink_setup.vbs uninstall Virtual Server ID」と入力します。ここで Virtual Server ID は、SMTP Archive Sink がインストールされている仮想サーバーの仮想サーバー番号です。

  4. コマンド プロンプト ウィンドウを閉じ、IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange Server 2003 での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 871110「インストールする方法と Microsoft Exchange Server 2003 で Archive Sink ユーティリティを使用する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=871110) を参照してください。

Exchange 2000 Server での SMTP Archive Sink の設定と構成の詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=307798) を参照してください。

規制遵守を目的とした包括的な履歴保持ソリューションの展開については、『Journaling with Exchange Server 2003』(http://go.microsoft.com/fwlink/?LinkId=47581) を参照してください (このサイトは英語の場合があります)。


SMTP 不正メール データが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) BadMail フォルダの Compressed キーの値を判断します。Compressed の値が True に設定されていることが検出された場合は、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP の不正メール データが格納されているフォルダに対してファイル圧縮を有効にすると、Exchange のパフォーマンスが大幅に低下する可能性があります。このため、SMTP の不明メール データが格納されているフォルダの圧縮はサポートされていません。

この警告が表示された場合は、SMTP 不正メール データが格納されているフォルダでの圧縮を無効にするか、SMTP 不正メール データを圧縮されていない別のフォルダに移動する必要があります。

Microsoft では、圧縮されたボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

特定のフォルダに対するファイル圧縮を無効にするには

  1. ファイル圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 の BadMail フォルダを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] をクリックし、操作する管理グループ、[サーバー]、操作するサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. 操作する SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. 操作する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[不正メール ディレクトリ] ボックスの横にある [参照] をクリックし、不正メール用フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?Linkld=3052&kbid=822933) を参照してください。


SMTP 不正メールのデータが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange の SMTP 不正メール ディレクトリの FSName キーの値を判断します。FSName キーの値が NTFS ではないことが検出されると、警告が表示されます。

Microsoft は、Exchange データ ファイルを NTFS 以外のボリュームに格納することをサポートしていません。Exchange データ ファイルには、次のファイルが含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

この警告が表示された場合は、SMTP 不正メール ディレクトリを NTFS ドライブ上のフォルダに移動する必要があります。あるいは、不正メール ディレクトリが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、コマンド ライン ツールの convert.exe を使用してそのドライブを NTFS に変換することもできます。

SMTP 不正メール ディレクトリを別のフォルダに移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、目的の管理グループ、[サーバー]、目的のサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[不正メール ディレクトリ] ボックスの横にある [参照] をクリックし、不正メール用フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?Linkld=3052&kbid=822933) を参照してください。

この手順の代わりに、ファイルが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、コマンド ライン ツールの convert.exe を使用してそのドライブを NTFS に変換することもできます。convert.exe コマンド ライン ツールを使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579) を参照してください。


SMTP の不正メール データが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Microsoft WMI (Wndows® Management Instrument) クラスの Win32_Directory に対してクエリを実行し、SMTP BadMail フォルダの Encrypted キーの値を判断します。Encrypted の値が True に設定されていることが検出されると、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP の不正メール データが格納されるフォルダで、ファイルの暗号化が有効になっている場合、Exchange のパフォーマンスが大幅に低下するおそれがあります。このため、SMTP の不明メール データが格納されるフォルダの暗号化はサポートされていません。

警告を受け取った場合は、SMTP 不正メール データが格納されているフォルダでの暗号化を無効にするか、SMTP 不正メール データを、暗号化されていないフォルダに移動する必要があります。

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームに Exchange データ ファイルを格納することをサポートしていません。暗号化されたボリュームに Exchange データ ファイルを格納すると、追加されるオーバーヘッドによって Exchange のパフォーマンスに大きな影響があります。以下のすべてのファイルが Exchange データ ファイルです。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティ保護に役立てるため、Exchange コンピュータに対する権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

このエラーを解決するには、BadMail フォルダでファイルの暗号化を無効にするか、暗号化が有効になっていない場所に BadMail フォルダを移動する必要があります。

ファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 の BadMail フォルダを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] をクリックし、操作する管理者グループ、[サーバー]、操作するサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. 操作する SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. 操作する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[不正メール ディレクトリ] ボックスの横にある [参照] をクリックし、不正メール用フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?Linkld=3052&kbid=822933) を参照してください。

Exchange Server のデータ ファイルと EFS の詳細については、Microsoft サポート技術情報の文書番号 834638「ストレージに関するデータの情報は、暗号化されたボリュームに Exchange でサーバーを提出します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Exchange Server 2003 でメッセージをセキュリティで保護する方法については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?linkid=47574) を参照してください (このサイトは英語の場合があります)。


SMTP CatRetryMinutes レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

CatRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値を変更する場合は、事前に十分な検討を行うことをお勧めします。既定値は、ほとんどの環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、Exchange Server でのキューの動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP キューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP 構成の警告
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-03

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpMaxMessageSize 属性の値が既定値の 0 から変更されているかどうかを判断します。既定では、msExchSmtpMaxMessageSize 属性はメッセージ サイズの制限を設けないように構成されています。

以下の条件に当てはまる場合は、警告が表示されます。

  • msExchSmtpMaxMessageSize 属性が値 0 に設定されていない。

  • Exchange が Microsoft Windows® Small Business Server 2003 上で実行されていない。

msExchSmtpMaxMessageSize 属性は、送受信することができる各 SMTP メッセージの最大サイズを表します。セキュリティの観点からは、インターネットとの間で送受信することができる SMTP メッセージの最大サイズを制限することをお勧めします。ただし、同じ組織内の Exchange サーバー間で送信されるメッセージのような内部の SMTP メッセージについては、msExchSmtpMaxMessageSize 属性を 0 に設定したままにすることをお勧めします。

内部的には、Exchange は SMTP メッセージを使用して、パブリック フォルダのレプリケーションなどのタスクを処理しています。小さすぎる制限値で msExchSmtpMaxMessageSize 属性が構成されている場合、パブリック フォルダのレプリケーションの問題や、組織内のメッセージ配信に関するその他のエラーが発生する可能性があります。

この Exchange サーバーが、インターネットとの間で SMTP メッセージを転送するブリッジヘッド サーバーである場合、この警告は無視してかまいません。この Exchange サーバーで内部の SMTP メッセージを処理している場合は、msExchSmtpMaxMessageSize 属性の値を既定の設定の 0 に戻す必要があります。

注 :
設定するメッセージ サイズ制限が小さすぎると、Exchange Server コンピュータ間のオフライン アドレス帳レプリケーションができなくなる可能性があります。詳細については、Microsoft サポート技術情報の文書番号 326154「Microsoft Outlook での Exchange 2000 Server でのオフライン アドレス帳はダウンロードできません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154) を参照してください。
SMTP メッセージの最大サイズを表示して構成するには

  1. Exchange システム マネージャで、[サーバー] を展開し、操作対象の Exchange サーバーを展開します。次に、[プロトコル] を展開して、[SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  3. [メッセージ] タブをクリックします。

  4. 既定の設定の 0 に戻すには、[メッセージ サイズの制限値 (KB)] チェック ボックスをオフにします。または、このチェック ボックスをオンのままにしておき、必要な値を設定します。

  5. [OK] をクリックして変更内容を保存し、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


配布グループの配信制限が設定された SMTP コネクタ
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスで検出された各 SMTP (Simple Mail Transfer Protocol) コネクタ オブジェクト (msExchRoutingSMTPConnector)) の次の属性に対してクエリを実行し、配布グループのメンバシップに基づいた配信制限が設定されているかどうかを判断します。

dLMemRejectPerms | メンバがこの SMTP コネクタを介して送信できない配布リスト (DL) のドメイン名 (DN) を含む。
dLMemSubmitPerms | メンバがこの SMTP コネクタを介して送信できる配布リスト (DL) のドメイン名 (DN) を含む。

配布グループのメンバシップに基づいた配信制限が設定された SMTP コネクタがあると判断すると、Exchange Server アナライザは警告を表示します。

この警告は、配布グループのメンバシップに基づいた配信制限が Exchange メール フローのパフォーマンスに影響を与える可能性があることを示します。

配布グループのメンバシップに基づいた配信制限が設定されている SMTP コネクタを使用してメールを送信するときに、メッセージ カテゴライザは配布グループのメンバシップを展開し、メンバの DN の完全なリストを取得して、その DN リストを送信者の DN リストと比較する必要があります。両方のリストに一致する DN があった場合に、アクセス操作または拒否操作が実行されます。配布グループ内に別の配布グループが入れ子になっている場合、入れ子の配布グループも展開されます。

この警告に対処するには、次の操作を行います。

  • マイクロソフト サポート技術情報の文書番号 329171 の、[XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171) を参照して、コネクタの制限のある専用ルーティング グループを設計し、ローカル ルーティング グループに構成します。

  • コネクタ用に指定するブリッジヘッド サーバーとして、専用の、より堅牢性の高いグローバル カタログ サーバーを使用します。

  • マイクロソフト サポート技術情報の文書番号 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298) に示されているように、配布グループではなくメールボックスごとに配信の制限を設定します。

  • SMTP 送信者フィルタの実装を検討します。

  • Exchange Server 2003 Service Pack 2 (SP2) 以降のバージョンを実行しているサーバーでは、階層のない制限の確認を実装することを検討します。Exchange 2003 SP2 より前のバージョンの Exchange を実行するサーバーでは、Exchange 2003 SP2 へのアップグレードを検討します。

詳細情報

階層のない制限の確認の詳細については、「階層のない制限の確認を検討する」を参照してください。

SMTP 送信者フィルタの詳細については、Exchange Server 2003 の管理ガイドの、送信者フィルタを有効にする方法についてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=72967) を参照してください。

配布グループの制限が Exchange のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 329171 の [XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • 文書番号 895407 の Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスや外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)。

  • 文書番号 839949 の Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)。


SMTP ドメインの書き換えが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、この Exchange サーバーに対する SMTP 仮想サーバー オブジェクトの heuristics 属性の値を判断します。heuristics 属性が既定値の 131072 ではないことが検出されると、エラーが表示されます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange Server Address Rewrite ツールについては、『Exchange Server Address Rewrite』(http://go.microsoft.com/fwlink/?LinkId=25932) を参照してください (このサイトは英語の場合があります)。


SMTP の FailedMsgQRetryMinutes レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

FailedMsgQRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値は、十分に考慮したうえでのみ変更することをお勧めします。既定の設定は、ほとんどの環境でパフォーマンスが最適となるように慎重に選択されています。一般的なベスト プラクティスは、Exchange Server のキュー動作を変更するのではなく、問題の根本的な原因に対処することです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP のキューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP LocalDeliveryMaxBatch レジストリが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、LocalDeliveryMaxBatch レジストリ値の既定の設定が変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\StoreDriver\Exchange\%SMTPVirtualServerInstance%.

LocalDeliveryMaxBatch レジストリ値の設定が手動で作成され、既定の Exchange サーバーのバイナリ設定 80 が変更されていることが検出されると、既定以外の設定であることを示す警告メッセージが表示されます。

既定では、LocalDeliveryMaxBatch レジストリ値は Exchange Server インストール時に作成されません。LocalDeliveryMaxBatch レジストリ値は、Exchange Information Store による内部処理およびメッセージの配信方法を変更するために、Exchange Server のインストール後に手動で作成できます。次の条件に当てはまる場合、Exchange サーバーではメッセージのトランスポートとストアのパフォーマンスに問題が発生することがあります。

  • LocalDeliveryMaxBatch レジストリ値が手動で作成されている。

  • LocalDeliveryMaxBatch レジストリ値の設定が誤って構成されている。

LocalDeliveryMaxBatch レジストリ値の作成または変更は、慎重に検討してから行うことをお勧めします。Exchange Server に対するバイナリの既定値は、ほとんどの Exchange Server 環境での使用で最適なパフォーマンスが得られるように慎重に選択されたものです。一般的なベスト プラクティスは、レジストリを手動で構成して Exchange Server の既定の動作を変更するのではなく、問題の根本原因に対処することです。ベスト プラクティスに準拠するため、LocalDeliveryMaxBatch レジストリ値が存在する場合、このレジストリ値を削除し、Exchange サーバーを構成して既定のバイナリ設定に戻すことができます。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。ただし、レジストリの編集によってこのレジストリ値を既定の設定に戻すこともできます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
この警告を修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. レジストリ キー HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\StoreDriver\Exchange\%SMTPVirtualServerInstance% に移動します。 HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\StoreDriver\Exchange\%SMTPVirtualServerInstance%

  3. 詳細ペインで、[LocalDeliveryMaxBatch] レジストリ値を右クリックし、[変更] をクリックします。次に、[値のデータ] を 80 に変更し、[OK] をクリックします。

    注 :
    LocalDeliveryMaxBatch レジストリ値を削除するには、詳細ペインで [LocalDeliveryMaxBatch] レジストリ値を右クリックし、[削除] をクリックします。ダイアログ ボックスで [はい] をクリックして、レジストリ値の削除を確認します。

  4. レジストリ エディタを終了します。

  5. Exchange Server を再起動します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Microsoft Windows レジストリの編集の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 322755「Windows 2000 でレジストリをバックアップ、編集、および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322755)

  • 文書番号 322756「Windows XP および Windows Server 2003 でレジストリをバックアップ、編集および復元する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322756)


SMTP インスタンスの FQDN が DNS で解決された名前と一致しない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchSmtpFullyQualifiedDomainName 属性の値を判断します。

また、Exchange Server アナライザは、構成済み DNS サーバーに対して、Exchange Server を実行しているサーバーの完全修飾ドメイン名 (FQDN) についてのドメイン ネーム システム (DNS) クエリの実行も試行します。この接続は、名前解決要求を実行し、その結果を分析するカスタム オブジェクト プロセッサを使用して行われます。

Exchange Server アナライザでは、これら 2 つのクエリの結果が比較されます。既定の SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchSmtpFullyQualifiedDomainName 属性の値が、Exchange サーバーの DNS FQDN に一致しない場合、Exchange Server アナライザは警告を表示します。

この警告は、これらの属性の値が手動で変更された可能性があることを示します。このため、変更されたこれらの値によって、対象のサーバーでメール フローの問題が生じる可能性があります。

msExchSmtpFullyQualifiedDomainName 属性の値は、SMTP 仮想サーバーの FQDN を指定し、ドメイン ネーム システム (DNS) ネットワーク プロトコルで解決可能である必要があります。

SMTP 仮想サーバーの FQDN の解決を試行するメッセージング サーバーで正しい IP アドレスを取得してメールを正しく転送するには、この属性の値には有効な DNS HOST (A) レコードの存在が必要です。

この警告に対処するには、値が正しい目的で意図的に変更されたかどうかを判別します。値が正しい目的で変更された場合は、次のいずれかの手順を実行します。

  • DNS FQDN に一致するように msExchSmtpFullyQualifiedDomainName 属性の値を変更します。

  • msExchSmtpFullyQualifiedDomainName 属性の値に一致するように Exchange Server の DNS FQDN を構成します。

注意 :
Active Directory サービス インターフェイス (ADSI) Edit、LDP (ldp.exe) ツール、または別のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
msExchSMTPFullyQualifiedDomainName 属性の値を更新するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、[サーバー] の順に展開して Exchange サーバーを展開し、[プロトコル]、[SMTP] の順に展開します。

  3. 既定の SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [配信] タブ、[詳細設定] の順にクリックします。

  5. 完全修飾ドメイン名の下に msExchSmtpFullyQualifiedDomainName 属性の値を入力します。

  6. [OK] をクリックして変更を保存し、もう一度 [OK] をクリックして SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。
Exchange Server の DNS FQDN を構成するには

  1. DNS サーバーの設定を構成する方法についての説明 (英語) の手順に従います。

Exchange の DNS 逆引き参照機能の詳細については、DNS ゾーンにリソース レコードを追加する方法についての説明 (http://go.microsoft.com/fwlink/?LinkId=63002) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

  • 文書番号 266686 の [XADM] SMTP サービスの構成方法 (第 1 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)。

  • 文書番号 268163 の [XADM] SMTP サービスの構成方法 (第 2 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)。

SMTP Service Design の詳細については、Exchange Server 2003 テクニカル リファレンス ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=58876) (英語) の、SMTP Service Design に関するセクションを参照してください。


送信 SMTP コネクタが設定されていない SMTP インスタンス
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-22

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの protocolCfgSMTPServer オブジェクト クラスの distingushedName 属性値に対してクエリを実行し、ユーザーが指定した Exchange ゲートウェイのすべての SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスの一覧を表示します。

次に、Exchange Server アナライザは、Active Directory の検出された各 msExchRoutingSMTPConnector オブジェクトの msExchSourceBridgeheadServersDN と routingList 属性の値に対してクエリを実行し、SMTP コネクタが、外部 SMTP アドレス スペースに対するローカルのブリッジヘッドとして、検出された SMTP 仮想サーバー インスタンスの設定のいずれかを所有しているかどうかを判断します。

SMTP コネクタは、メール用に独立したルートを指定します。SMTP コネクタを使用して、インターネット メールのゲートウェイを設定したり、特定のドメインやメール システムに接続したりできます。コネクタの利用により、指定したメール ルートに対して特定のオプションを定義できます。

Exchange Server アナライザが、指定した Exchange ゲートウェイ サーバーからのローカル ブリッジヘッド サーバーとしての SMTP 仮想サーバー インスタンスを持つ SMTP コネクタがないと判断した場合、Exchange Server アナライザは警告を表示します。

この警告は、ユーザーが指定した Exchange ゲートウェイ サーバー以外のサーバーが、誤ってメッセージを組織外にルーティングした可能性があることを示します。

指定した Exchange ゲートウェイ サーバー上にローカル ブリッジヘッドとして SMTP 仮想サーバー インスタンスを指定する SMTP コネクタを作成して、ユーザーが指定した Exchange ゲートウェイ サーバー以外のサーバーが意図せずにメッセージを組織外にルーティングする状況を回避することができます。

SMTP 仮想サーバーを使用してインターネット メールを送受信することもできますが、ベスト プラクティスとしてインターネット メールをルーティングする専用の SMTP コネクタを構成することをお勧めします。SMTP コネクタはインターネット宛てのメール用に独立したルートを用意するため、SMTP コネクタを使用することをお勧めします。また、SMTP コネクタでは、SMTP 仮想サーバーよりも多くの構成オプションを利用できます。

SMTP コネクタを使用する方法の詳細については、マイクロソフト サポート技術情報の文書番号 294736 の、Exchange 2000 以降で SMTP コネクタの作成が必要な場合 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=294736) を参照してください。

SMTP コネクタの詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください。


SMTP の LocalRetryMinutes レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

LocalRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値は、十分に考慮したうえでのみ変更することをお勧めします。既定の設定は、ほとんどの環境でパフォーマンスが最適となるように慎重に選択されています。一般的なベスト プラクティスは、Exchange のキュー動作を変更するのではなく、問題の根本的な原因に対処することです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP のキューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP FileCacheLifeTimeSeconds レジストリ値が手動で追加されているが、不要になった可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、キャッシュされた各インターネット インフォメーション サービス (IIS) ファイル ハンドルの既定の Time-to-Live が、既定値である 1,880 秒 (30分) から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\FileCacheLifeTimeSeconds

MsgHandleThreshold のエントリが存在しており、別の値でエントリが構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

FileCacheLifeTimeSeconds 値は、キャッシュされた IIS ファイル ハンドルの Time-to-Live を示します。ファイル ハンドルをキャッシュすると、サーバーによる冗長な入出力 (I/O) と CPU サイクルが減少するため、パフォーマンスが向上します。Exchange Server コンピュータ上の SMTP トランスポート スタックがメッセージを受信するたびに、そのメッセージはファイル システムに送信され、そこで配信先にルーティングされるのを待ちます。ファイル システムに書き込むためには、SMTP トランスポート スタックがファイル ハンドルを取得し、メッセージをそのハンドルに渡します。各ファイル ハンドルは、約 2 KB のページ プール メモリを消費します。IIS キャッシュ ファイル ハンドルの既定数は、32 MB ごとに 800 です。

Exchange 2000 Server Service Pack 2 (SP2) 以降、および Exchange Server 2003 では、最適な数のファイル ハンドルがキャッシュされるように構成されているため、このレジストリ値は既定では存在しません。Exchange Server 2003 では、SMTP ファイル ハンドルについて適切な設定が動的に計算されるため、これらの設定が不要になりました。したがって、これらの設定が指定されている Exchange 2000 Server コンピュータを Exchnage Server 2003 にアップグレードする場合は、事前にこれらのエントリをレジストリから削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. 右側のペインで、[FileCacheLifeTimeSeconds] 値を削除します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP FileCacheMaxHandles レジストリ値が手動で追加されているが、不要になった可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、インターネット インフォメーション サービス (IIS) のファイル キャッシュ ハンドルの最大数が既定値の 800 から変更されたかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\FileCacheMaxHandles

FileCacheMaxHandles のエントリが存在しており、800 以外の値でエントリが構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

FileCacheMaxHandles 値は、Exchange が物理メモリ 32 メガバイト (MB) ごとに使用する IIS のファイル ハンドルの最大数を示します。ファイル ハンドルは、パフォーマンスを向上させるためにキャッシュされます。パフォーマンスが向上するのは、ファイル ハンドルをキャッシュすることで、重複する入出力 (I/O) と CPU サイクルをサーバーで実行する必要がなくなるためです。Exchange Server コンピュータ上の SMTP トランスポート スタックがメッセージを受信するたび、メッセージはファイル システムに送信されて、送信先にルーティングされるまでそこで待機します。ファイル システムに書き込むため、SMTP トランスポート スタックはファイル ハンドルを取得してから、そのハンドルにメッセージを渡します。各ファイル ハンドルは、約 2 キロバイト (KB) のページ プール メモリを消費します。IIS キャッシュ ファイル ハンドルの既定数は、32 MB ごとに 800 です。

Exchange 2000 Server Service Pack 2 (SP2) が公開されるまでは、既定の設定で SMTP サービスのファイル ハンドル数が最大で 1,000 とされていたため、大きな SMTP メッセージ キュー (平均 1,000 件以上のメッセージ) を維持する Exchange サーバーではパフォーマンスが制約されていました。Exchange 2000 Server の既定では、ファイル ハンドルの最大数が 1,000 に設定されていたため、SMTP サービスは一度に 1,000 件を超えるメッセージをファイル システムに書き込むことができませんでした。

このような大規模システムのパフォーマンスを向上させるため、以下に示す 3 つのレジストリ エントリを頻繁かつ同時に調整することで、(より多くのメッセージを処理できるように) SMTP サービスが開くことのできるファイル ハンドルの最大数を増やし、(キューが大きくなった場合のメモリ不足を回避するため) 別のExchange コンポーネントである IFS (Installable File System) のために開かれるファイル ハンドルの数を減らしていました。これらのレジストリ値は、既定では存在していないため、手動で追加する必要がありました。

場所 : HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing

値 : MsgHandleThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing

値 : MsgHandleAsyncThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

値 : FileCacheMaxHandles

種類 : REG_DWORD

MsgHandleThreshold と MsgHandleAsyncThreshold のエントリは、一般に同じ値 (通常は 1,000 より大きい値) に設定し、FileCacheMaxHandles の値は、通常 800 から 600 に減らします。

Exchange 2000 Server Service Pack 2 (SP2) 以降では、使用するのに最適な値が動的に決定されるため、このレジストリ値は既定では存在しません。この Exchange サーバーが Exchange 2000 Server Service Pack 1 以前を実行している場合は、ベスト プラクティスとして、最新レベルの Service Pack およびロールアップ パッケージにアップグレードすることをお勧めします。最新のコードにアップグレードしたら、すぐにこれらのレジストリ エントリを削除します。

Exchange Server 2003 では、SMTP ファイル ハンドルの適切な設定が動的に計算されるため、これらの設定は必要なくなりました。したがって、これらの設定が指定されている Exchange 2000 Server コンピュータを Exchnage Server 2003 にアップグレードする場合は、事前にこれらのエントリをレジストリから削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

  3. FileCacheMaxHandles 値を削除します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP の GlitchRetrySeconds レジストリ値が手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、既定の GLITCH-RETRY の待機時間が手動で変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\GlitchRetrySeconds

GlitchRetrySeconds が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

Exchange 2000 Server または Exchange Server 2003 が、負荷の高い外部の SMTP システムにメッセージをルーティングしようとした場合、サーバー使用中エラーを受信することがあります。このエラーが発生すると、Exchange は "GLITCH-RETRY" と呼ばれる状態になります。この状態では、Exchange は 60 秒待ってからメッセージの再送を試みます。このプロセスを 3 回繰り返してから他の手段を使用します。外部の SMTP サーバーの使用頻度が定常的に高い場合は、GLITCH-RETRY の待機時間を減らして、大量のメッセージがキューに入るのを回避することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. 右側のウィンドウで、GlitchRetrySeconds 値を削除します。大量のキューが発生している場合は、代わりに GlitchRetrySeconds の値を減らすこともできます。

  4. レジストリ エディタを終了し、SMTP (Simple Mail Transfer Protocol) サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP の IgnorePFTimeLimit レジストリ値が手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは次のレジストリ エントリを読み取り、SMTP サービスのルーティング エンジンが新しいパブリック フォルダ ストアをバイパスする日数が手動で設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\IgnorePFTimeLimit

IgnorePFTimeLimit が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

新しいパブリック フォルダ ストアがオンラインになると、キュー ビューアのローカル配信キューが増えていることに気付くことがあります。パブリック フォルダの階層が大きい場合は、ローカル キュー内のメッセージが増え続け、配信にさらに時間がかかるようになる可能性があります。場合によっては、メッセージが配信されない可能性もあります。

新しいサーバーを導入すると、その識別名は、Active Directory® ディレクトリ サービス内にある管理グループの Folder Hierarchies Public Folder オブジェクトの msExchOwningPFTreeBL 属性に追加されます。パブリック フォルダ宛てのメッセージを受信するサーバーのカテゴライザが msExchOwningPFTreeBL 属性を読み取ったときに、ローカルのパブリック フォルダ ストアが存在すると、カテゴライザはそのパブリック フォルダ ストアを最初に選択します。負荷分散のために、それ以降は、一覧に示されている順序でパブリック フォルダ ストアを選択します。新しいサーバーが一覧の最初に示されているため、メッセージはそのサーバーにルーティングされた後、新しいサーバーのローカル配信キューに追加されます。パブリック フォルダ ストアがまだ階層のコピーを受け取っていない場合、そのサーバーは、宛先フォルダのコピーを所有するストアにメッセージをルーティングできません。

この問題を回避するには、新しいパブリック フォルダ サーバーのレジストリに IgnorePFTimeLimit 値を追加します。この値は、ルーティング エンジンが新しいパブリック フォルダ ストアをバイパスする日数を指定します。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. 右側のウィンドウで、IgnorePFTimeLimit 値を削除します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

この問題と IgnorePFTimeLimit レジストリ値の詳細については、Microsoft サポート技術情報の文書番号 328870「階層がレプリケートされています前、パブリック フォルダ ルーティングが有効です。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328870) を参照してください。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP インスタンスに複数ポートのバインドが構成されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchServerBindings 属性の構成値が既定値の 25 から変更されているかどうか、または複数の値が設定されているかどうかを判断します。既定では、msExchServerBindings 属性は TCP ポート 25 用に構成されています。この属性に複数の値が設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示され、同時に複数の値が設定された仮想 SMTP (Simple Mail Transfer Protocol) サーバーの名前も表示されます。

msExchServerBindings 属性は、この SMTP サーバーが受信接続待ちを行う TCP ポートを表します。SMTP 仮想サーバーは、1 つ以上の TCP ポートで接続要求待ちを行うように構成できます。既定では、すべての SMTP 仮想サーバーが、TCP ポート 25 (既定の SMTP ポート) で接続要求待ちを行うように構成されます。SMTP のリスニング ポートが既定から変更され、複数のポートのバインドを含んでいる場合は、メールの流れが中断される可能性があります。

SMTP のリスニング ポートの変更に合わせて内部メッセージング インフラストラクチャの他の部分も変更すれば、特に問題はありません。ただし一般に、インターネット上の SMTP サーバーはポート 25 を通してメッセージを送信するので、インターネットから直接メッセージを受け付ける SMTP 仮想サーバーでは代わりのポートを使用することはできません。

Exchange Server アナライザは、Exchange の SMTP プロトコル仮想サーバーの値を確認します。この SMTP プロトコル仮想サーバーは、インターネットから直接メッセージを受信する SMTP サーバーである場合とそうでない場合があります。ウイルス対策製品やスパム対策製品の中には、ポート 25 でインターネットからの SMTP メッセージを受信し、別のポートの Exchange SMTP 仮想サーバーにリダイレクトするように設計されているものがあります。この場合、複数のポートで受信接続待ちをしている Exchange SMTP 仮想サーバーの構成を使用できることがあります。

SMTP 仮想サーバーのリスニング ポートを表示または変更するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [全般] タブをクリックし、[詳細設定] をクリックします。

  5. IP アドレスとポートの一覧が表示されます。

    • 既存のポートを変更するには、IP アドレスを選択し、[編集] をクリックします。[TCP ポート] ボックスの値を 25 に変更します。

    • 追加のリスニング ポートとして 25 を追加するには、[追加] をクリックして、新しい IP アドレスとポートの組み合わせを追加します。接続、送信者、または受信者のフィルタを使用している場合は、必ず適切なチェック ボックスをオンにしてください。

  6. [OK] をクリックして変更を保存したら、[OK] をクリックして [詳細設定] ダイアログ ボックスを閉じます。

  7. [OK] をクリックして、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (一般エラー)
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、BadmailedMessagesGeneralFailure キーの値を判断します。このキーの値は、特定のカウンタに関連付けられていない理由のために不正メール ディレクトリに送信されたメッセージの数を表します。不正メール ディレクトリは、配信不能なメッセージを格納するために使用されます。その他の不正メールに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - 不正メール メッセージのホップ数のしきい値

  • SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (DSN の NDR)

カウンタには、ピックアップするファイルに問題がある、受信者が指定されていない、イベントによってトリガされたなど、他の理由で不正メール ディレクトリにメッセージが送信されたときに増加するものがあります。

また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SytemUpTime キーの値が 0 より大きく、かつ BadmailedMessagesGeneralFailure の値を SystemUpTime の値で割った結果が 1,000 より大きいことが検出されると、警告が表示されます。

この警告は、1 日あたり平均 1,000 以上のメッセージが配信不能としてマークされ、不正メール ディレクトリに格納されることを示します。不正メール ディレクトリ内のメッセージは手動で削除する必要があります。Exchange Server の定期的な保守の一部として、不正メール ディレクトリ内のメッセージの確認と削除を行うことをお勧めします。不正メール ディレクトリの拡大を無制限に許可すると、使用可能なディスク領域がすべて消費され、その結果 Exchange データベースのマウントが解除される可能性があります。

この警告を修正するには

  1. 不正メール ディレクトリ内のメッセージを調べて、メッセージの送信元が内部と外部のどちらであるかを判断します。不正メール ディレクトリ内のメッセージは ASCII 形式で格納されており、メモ帳や他のテキスト エディタで開いて表示することができます。

    • メッセージが内部で生成されたことがわかった場合は、メッセージ ヘッダーを調べて発信元を判断します。

    • メッセージが外部で生成されたことがわかった場合は、Exchange Server がメール リレーとして使用されています。

中継オプションの制御と構成方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 310380「[HOWTO] Windows 2000 で Exchange 2000 がメール リレーとして使用されるのを防ぐ方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)

  • 文書番号 313395「[HOW TO] Exchange 2000 Server で匿名 SMTP 接続に対する中継の制限を調査する方法と、一方的に送られてくる電子メールにフィルタを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313395)

空きディスク領域の不足によるデータベースのマウント解除の詳細については、Microsoft サポート技術情報の文書番号 321825「[XADM] ディスク領域不足のため、データベースがディスマウントされる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=321825) を参照してください。


SMTP メッセージのエラーに関する警告 - 不正メール メッセージのホップ数のしきい値
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、BadmailedMessagesHopCountExceeded キーの値を判断します。このキーの値は、最大ホップ数を超えたために不正メール ディレクトリに送信されたメッセージの数を表します。不正メール ディレクトリは、配信不能なメッセージを格納するために使用されます。その他の不正メール WMI カウンタについては、Exchange Server アナライザ ツールの文書「SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (一般エラー)」および「SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (DSN の NDR) 」を参照してください。

メッセージが、ピックアップ ファイルが正しくない、受信者がいない、イベント経由でトリガされたなどの、その他の理由で不正メール ディレクトリに送信されたときに増加するカウンタが存在します。

また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SytemUpTime キーの値が 0 より大きく、かつ BadmailedMessagesHopCountExceeded の値を SystemUpTime の値で割った結果が 100 より大きいことが検出されると、警告が表示されます。

この警告は、1 日あたり平均 100 以上のメッセージが配信不能としてマークされ、最大ホップ数を超えたために不正メール ディレクトリに格納されていることを示しています。最大ホップ数は、メッセージが送信者から受信者へ転送される間に経由できる SMTP サーバーの最大数です。メッセージが SMTP サーバーを経由するたびに、そのホップを表すテキスト行がメッセージ ヘッダーに追加されます。

メッセージの最適なホップ数は、ネットワークのトポロジやメッセージングのニーズに応じて異なります。管理者は、メッセージが繰り返し誤ってルーティングされる状態 (これをメッセージ ループという) を防ぐために、許可されるホップの最大数を制御できます。この制御は、SMTP 仮想サーバーの最大ホップ数を設定することにより実現されます。既定のホップ数は、Exchange 2000 Server では 15、Exchange Server 2003 では 30 です。どちらの SMTP 仮想サーバーでも、この値を 30 に設定することをお勧めします。

不正メール ディレクトリ内のメッセージは、手動で削除する必要があります。Exchange Server の定期的な保守の一部として、不正メール ディレクトリ内のメッセージを定期的に確認して削除することをお勧めします。不正メール ディレクトリを無制限に拡張できるようにすると、使用可能なディスク領域をすべて使い切り、それにより Exchange データベースのマウントが解除される可能性があります。

この警告を修正するには

  1. 不正メール ディレクトリ内のメッセージを調べて、メッセージのソースが内部または外部のどちらかを判断します。不正メール ディレクトリ内のメッセージは ASCII 形式で格納されているため、メモ帳やその他のテキスト エディタで開いて表示することができます。

    • メッセージが内部で生成されたことがわかった場合は、メッセージ ヘッダーを調べて発信元を判断します。

    • メッセージが外部で生成されたことがわかった場合は、Exchange Server がメール リレーとして使用されています。

  2. ホップの最大数を表す数値を 30 に設定します。

    1. Exchange システム マネージャを起動します。

    2. [サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

    3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

    4. [配信] タブをクリックし、[詳細設定] をクリックします。

    5. [最大ホップ数] ボックスに希望する値を入力し、[OK] をクリックして変更を保存します。

    6. [OK] をクリックして、SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

中継オプションを制御および構成する方法の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 310380「[HOWTO] Windows 2000 で Exchange 2000 がメール リレーとして使用されるのを防ぐ方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=310380)

  • 文書番号 313395「[HOW TO] Exchange 2000 Server で匿名 SMTP 接続に対する中継の制限を調査する方法と、一方的に送られてくる電子メールにフィルタを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313395)

空きディスク領域の不足によるデータベースのマウント解除の詳細については、Microsoft サポート技術情報の文書番号 321825「[XADM] ディスク領域不足のため、データベースがディスマウントされる」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=321825) を参照してください。


SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (DSN の NDR)
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-23

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、BadmailedMessagesNDRofDSN キーの値を判断します。このキーの値は、配信不能であるために不正メール ディレクトリに送信された配信状態通知 (DSN) メッセージの数を表します。不正メール ディレクトリは、配信不能なメッセージを格納するために使用されます。その他の不正メール WMI カウンタについては、Exchange Server アナライザの文書、「SMTP メッセージのエラーに関する警告 - 不正メール メッセージ (一般エラー)」、および「SMTP メッセージのエラーに関する警告 - 不正メール メッセージのホップ数のしきい値」を参照してください。

カウンタには、ピックアップするファイルに問題がある、受信者が指定されていない、イベントによってトリガされたなど、他の理由で不正メール ディレクトリにメッセージが送信されたときに増加するものがあります。

また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、かつ BadmailedMessagesNDRofDSN の値を SystemUpTime の値で割った結果が 1000 より大きいことが検出されると、警告が表示されます。

この警告は、配信不能のために、1 日あたり平均 1,000 以上の DSN メッセージが不正メール ディレクトリに格納されたことを示します。不正メール ディレクトリ内のメッセージは手動で削除する必要があります。Exchange Server の定期的な保守の一部として、不正メール ディレクトリ内のメッセージを定期的に確認して削除することをお勧めします。不正メール ディレクトリの拡大を無制限に許可すると、使用可能なディスク領域がすべて消費され、その結果 Exchange データベースのマウントが解除される可能性があります。

この警告を修正するには

  • 不正メール ディレクトリ内のメッセージを調査し、DSN の宛先が内部受信者であるか、外部受信者であるかを判断します。不正メール ディレクトリ内のメッセージは ASCII 形式で格納されており、メモ帳や他のテキスト エディタで開いて表示することができます。

    • DSN が内部受信者宛てである場合、メッセージの流れに問題があります。この問題のトラブルシューティングは、DSN で返される特定の数値コードに基づいて行います。

    • DSN が外部受信者宛てである場合、Exchange Server がメール リレーとして使用されています。この問題のトラブルシューティングもまた、返される特定の数値コードに基づいて行います。

配信に関する DSN 数値リターン コードの詳細については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」を参照してください。

中継オプションの制御と構成方法の詳細については、Microsoft サポート技術情報の文書番号 313395「[HOW TO] Exchange 2000 Server で匿名 SMTP 接続に対する中継の制限を調査する方法と、一方的に送られてくる電子メール メッセージにフィルタを適用する方法」を参照してください。

空きディスク領域の不足によるデータベースのマウント解除の詳細については、Microsoft サポート技術情報の文書番号 321825「ディスク領域不足のため、データベースのマウントが解除される」を参照してください。


SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-20

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatAddresslookupsnotfound キーの値を判断します。このキーの値は、メッセージ カテゴライザによって実行され、ディレクトリ サービス オブジェクトが見つからなかったアドレス参照の数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、CatAddresslookupsnotfound の値を SystemUpTime の値で割った結果が 5,000 より大きいと判断されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージは、メッセージ転送エージェント (MTA) を使用してローカル インフォメーション ストア (リモート ホスト) に送信される場合と、SMTP を使用してリモート ホストに送信される場合があります。カテゴライザは、配布リストの拡張も行います。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスト キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスト キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザはアドレス解決、メールの転送、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行い、同時に他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージ カテゴライザは、メッセージを受け取ると、Active Directory® ディレクトリ サービスのプロキシ アドレス属性でアドレスを検索することによって、エンベロープの送信者を解決します。カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索し、エンベロープの受信者も解決します。たとえば、一覧に配布リストが含まれている場合、サーバー上で配布リストの展開が許可されていれば、カテゴライザによってそれらのメンバを含むようにリストが展開されます。

この警告は、カテゴライザのアドレス参照が毎日平均で 5,000 回以上失敗していることを示します。これにはいくつかの原因があります。たとえば、DSAccess (Directory Service Access) の問題、ディレクトリ レプリケーションの遅延またはエラー、ディレクトリに対する辞書攻撃、DNS での問題、無効なアドレスの使用などが原因になります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには、次の操作を行います。

  1. Exchange Server コンピュータのイベント ログでエラーの調査を行います。

  2. 問題の解決に役立つイベントが見つからない場合は、MSExchangeTransport Categorizer の診断ログ機能を最大にすることを検討してください。診断ログ出力を有効にしたら、イベント ログでエラーを再確認します。診断ログ機能を最大に構成してもイベント ログ エントリが生成されない場合は、レジストリを使用して診断ログをレベル 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 がログに記録され、関数、エラーの理由、失敗した受信者の名前、および受信者の種類の詳細が記録されます。診断ログをレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のウィンドウで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタを使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「メッセージ追跡の Exchange Server 2003 でのイベント ID」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「メッセージ カテゴライザと NDR トラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー


SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatCategorizeationfailedDSlogonfailure キーの値を判断します。このキーの値は、ディレクトリ サービスのログオン障害のために失敗した分類の数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、CatCategorizationsfailedDSlogonfailure の値を SystemUpTime の値で割った結果が 50 より大きいことが検出されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージは、メッセージ転送エージェント (MTA) を使用してローカル インフォメーション ストア (リモート ホスト) に送信される場合と、SMTP を使用してリモート ホストに送信される場合があります。カテゴライザは、配布リストの拡張も行います。カテゴライザは、グローバル カタログ サーバーに対する ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスド キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザはアドレス解決、メールの転送、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行い、同時に他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージがメッセージ カテゴライザに入ると、カテゴライザは直ちに Active Directory® ディレクトリ サービスのプロキシ アドレス属性に含まれているアドレスを検索し、エンベロープ送信者を解決します。また、カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索して、エンベロープ受信者も解決します。たとえば、一覧に配布リストが含まれている場合、サーバー上で配布リストの展開が許可されていれば、カテゴライザによってそれらのメンバを含むようにリストが展開されます。

この警告は、ログオン障害により、メッセージ カテゴライザによって平均 50 回以上行なわれるディレクトリ サービス接続の試行が毎日エラーになっていることを示します。これには、ディレクトリ サービス アクセス (DSAccess) の問題、ディレクトリ レプリケーションの待ち時間やエラー、グローバル カタログ サーバーの過負荷、DNS の問題など、さまざまな原因が考えられます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Exchange Server コンピュータのイベント ログを調べ、エラーを探します。

  2. 問題の解決に役立つイベントが見つからない場合は、MSExchangeTransport Categorizer の診断ログ機能を最大にすることを検討してください。診断ログを有効にしたらすぐに、イベント ログを再チェックしてエラーがないかどうかを確認します。診断ログ機能を最大に構成してもイベント ログ エントリが生成されない場合は、レジストリを使用して診断ログをレベル 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 がログに記録され、関数、エラーの理由、失敗した受信者の名前、および受信者の種類の詳細が記録されます。診断ログをレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のペインで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタ を使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「メッセージ追跡の Exchange Server 2003 でのイベント ID」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「Exchange 2000 Server: Message Categorizer and NDR Troubleshooting」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連する利用可能なパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー


SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-20

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatCategorizationsfailedDSconnectionfailure キーの値を判断します。このキーの値は、ディレクトリ サービスとの接続サービス エラーのために失敗した分類の数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してクエリを実行し、SystemUpTime の値も判断します。

SystemUpTime キーの値が 0 より大きく、CatCategorizationsfailedDSconnectionfailure の値を SystemUpTime の値で割った結果が 50 より大きいことが検出されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージは、メッセージ転送エージェント (MTA) を使用してローカル インフォメーション ストア (リモート ホスト) に送信される場合と、SMTP を使用してリモート ホストに送信される場合があります。カテゴライザは、配布リストの拡張も行います。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスト キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスト キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザはアドレス解決、メールの転送、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行い、同時に他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージ カテゴライザは、メッセージを受け取ると、Active Directory® ディレクトリ サービスのプロキシ アドレス属性でアドレスを検索することによって、エンベロープの送信者を解決します。カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索し、エンベロープの受信者も解決します。たとえば、一覧に配布リストが含まれている場合、サーバー上で配布リストの展開が許可されていれば、カテゴライザによってそれらのメンバを含むようにリストが展開されます。

この警告は、メッセージ カテゴライザによって平均 50 回以上行なわれるディレクトリ サービス接続の試行が毎日エラーになっていることを示します。これには、ディレクトリ サービス アクセス (DSAccess) の問題、ディレクトリ レプリケーションの待ち時間やエラー、グローバル カタログ サーバーの過負荷、DNS の問題など、いくつかの原因が考えられます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには、次の操作を行います。

  1. Exchange Server コンピュータのイベント ログでエラーの調査を行います。

  2. 問題の解決に役立つイベントが見つからない場合は、MSExchangeTransport Categorizer の診断ログ機能を最大にすることを検討してください。診断ログを有効にしたらすぐに、イベント ログを再チェックしてエラーがないかどうかを確認します。診断ログ機能を最大に構成してもイベント ログ エントリが生成されない場合は、レジストリを使用して診断ログをレベル 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 がログに記録され、関数、エラーの理由、失敗した受信者の名前、および受信者の種類の詳細が記録されます。診断ログをレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のウィンドウで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタを使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「メッセージ追跡の Exchange Server 2003 でのイベント ID」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「メッセージ カテゴライザと NDR トラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー


SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatCategorizationsfailednonretryableerror キーの値を判断します。このキーの値は、ハードウェア エラー (再試行不能) のために失敗した分類の数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、CatCategorizationsfailednonretryableerror の値を SystemUpTime の値で割った結果が 50 より大きいことが検出されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調査し、メッセージの処理方法を判断します。メッセージの宛先は、 ローカルのインフォメーション ストアや、メッセージ転送エージェント (MTA) の使用によるリモート ホストの可能性があります。または、SMTP の使用によるリモート ホストが、メッセージの宛先である可能性もあります。カテゴライザは、配布リストの展開も処理します。カテゴライザは、グローバル カタログ サーバーに対する ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスド キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスド キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザでは、アドレス解決、メールの転送、コンテンツの変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成が実行されます。また、受信者の代替ルート検出、分割、ジャーナリングを始めとした多くの機能が実行されます。

メッセージ カテゴライザは、メッセージを受け取るとすぐに、Active Directory® ディレクトリ サービスのプロキシ アドレス属性でアドレスを検索することによって、エンベロープの送信者を解決します。カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索し、エンベロープの受信者も解決します。たとえば、一覧に配布リストが含まれている場合、そのサーバーで配布リストの展開が許可されていれば配布リストを展開し、それらのメンバを含めます。

この警告は、毎日、平均で 50 以上のハードウェア エラーが発生していることを示します。これには、ディレクトリ サービス アクセス (DSAccess) の問題、ディレクトリ レプリケーションの待ち時間やエラー、グローバル カタログ サーバーの過負荷、DNS の問題など、いくつかの原因が考えられます。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには

  1. Exchange Server コンピュータのイベント ログでエラーを確認します。

  2. 問題の解決を可能にするイベントが見つからない場合は、MSExchangeTransport カテゴライザに対する診断ログ出力のレベルを [最大] まで上げることを検討します。診断ログ出力を有効にした後、イベント ログでエラーを再確認します。診断ログ出力のレベルを最大に構成してもイベント ログのエントリがまったく生成されない場合は、レジストリを使用して、診断ログ出力のレベルを 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 が記録され、このイベントによって機能、エラーの理由、エラーが発生した受信者の名前、および受信者の種類が詳細に示されます。診断ログ出力をレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のペインで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタ を使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」?(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「Exchange Server 2003 での追跡イベント ID メッセージです。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「Exchange 2000 Server: Message Categorizer and NDR Troubleshooting」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用することができるパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー


SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-28

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatCategorizationsfailedOutOfMemory キーの値を判断します。このキーの値は、利用可能なメモリが不足しているために失敗した分類の回数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、CatCategorizationsfailedOutOfMemory の値を SystemUpTime の値で割った結果が 50 より大きいことが検出されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージは、メッセージ転送エージェント (MTA) を使用してローカル インフォメーション ストア (リモート ホスト) に送信される場合と、SMTP を使用してリモート ホストに送信される場合があります。カテゴライザは、配布リストの拡張も行います。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスト キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスト キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザはアドレス解決、メールの転送、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行い、同時に他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージ カテゴライザは、メッセージを受け取るとすぐに、Active Directory® ディレクトリ サービスのプロキシ アドレス属性でアドレスを検索することによって、エンベロープの送信者を解決します。カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索し、エンベロープの受信者も解決します。たとえば、一覧に配布リストが含まれている場合、サーバー上で配布リストの展開が許可されていれば、カテゴライザによってそれらのメンバを含むようにリストが展開されます。

この警告は、利用可能なメモリの不足が原因で、毎日平均 50 以上の分類に失敗していることを示します。これには、ディレクトリ サービス アクセス (DSAccess) の問題、ディレクトリ レプリケーションの待ち時間やエラー、グローバル カタログ サーバーの過負荷、DNS の問題など、いくつかの原因が考えられます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには、次の操作を行います。

  1. Exchange Server コンピュータのイベント ログを調べ、エラーを探します。

  2. 問題の解決に役立つイベントが見つからない場合は、MSExchangeTransport Categorizer の診断ログ機能を最大にすることを検討してください。診断ログ機能を有効にした後、イベント ログでエラーを再確認します。診断ログ機能を最大に構成してもイベント ログ エントリが生成されない場合は、レジストリを使用して診断ログをレベル 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 がログに記録され、関数、エラーの理由、失敗した受信者の名前、および受信者の種類の詳細が記録されます。診断ログをレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のウィンドウで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタを使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「メッセージ追跡の Exchange Server 2003 でのイベント ID」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「メッセージ カテゴライザと NDR トラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「Exchange 2000 Server および Exchange Server 2003 でのトランスポートに関する問題の一般的なトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用できるパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー


SMTP メッセージのエラーに関する警告 - カテゴライザの再試行可能なエラー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-03-20

Microsoft® Exchange Server アナライザ ツールは、Win32_PerfRawData_SMTPSVC_SMTPServer Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、CatCategorizationsfailedretryableerror キーの値を判断します。このキーの値は、再試行可能なエラーで失敗した分類の数を表します。また、Exchange Server アナライザは Win32_PerfRawData_PerfOS_System WMI キーに対してもクエリを実行し、SystemUpTime の値を判断します。

SystemUpTime キーの値が 0 より大きく、かつ CatCategorizationsfailedretryableerror の値を SystemUpTime の値で割った結果が 500 より大きいことが検出されると、警告が表示されます。

メッセージ カテゴライザは、SMTP サーバーに到着したメッセージを調べ、そのメッセージについて行う操作を決定します。メッセージは、メッセージ転送エージェント (MTA) を使用してローカル インフォメーション ストア (リモート ホスト) に送信される場合と、SMTP を使用してリモート ホストに送信される場合があります。カテゴライザは、配布リストの拡張も行います。カテゴライザは、グローバル カタログ サーバーに対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを、TCP ポート 3268 で実行するアドバンスト キュー エンジンへのプラグインです。カテゴライザは基本的に、アドバンスト キュー エンジンを通過するすべてのメッセージに関して高度なアドレス解決を実行するイベント シンクの集まりです。カテゴライザはアドレス解決、メールの転送、コンテンツ変換フラグの設定、配布リストの展開、グローバル設定の適用、および配信状態通知の生成を行い、同時に他の受信者ルートの検出、分割、ジャーナリング、およびその他多くの機能を実行します。

メッセージ カテゴライザは、メッセージを受け取るとすぐに、Active Directory® ディレクトリ サービスのプロキシ アドレス属性でアドレスを検索することによって、エンベロープの送信者を解決します。カテゴライザは Active Directory のプロキシ アドレス属性に含まれている各アドレスを検索し、エンベロープの受信者も解決します。たとえば、一覧に配布リストが含まれている場合、サーバー上で配布リストの展開が許可されていれば、カテゴライザによってそれらのメンバを含むようにリストが展開されます。

この警告は、毎日、平均 500 以上の分類が再試行可能なエラーで失敗していることを示しています。これには、ディレクトリ サービス アクセス (DSAccess) の問題、ディレクトリ レプリケーションの待ち時間やエラー、グローバル カタログ サーバーの過負荷、DNS の問題など、さまざまな原因が考えられます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

この警告を修正するには、次の操作を行います。

  1. Exchange Server コンピュータのイベント ログを調べ、エラーを探します。

  2. 問題の解決に役立つイベントが見つからない場合は、MSExchangeTransport Categorizer の診断ログ機能を最大にすることを検討してください。診断ログ機能を有効にした後、イベント ログでエラーを再確認します。診断ログ機能を最大に構成してもイベント ログ エントリが生成されない場合は、レジストリを使用して診断ログをレベル 7 に構成します。レベル 7 に設定すると、メッセージ カテゴライザによって生成されたイベント ID 9000 がログに記録され、関数、エラーの理由、失敗した受信者の名前、および受信者の種類の詳細が記録されます。診断ログをレベル 7 に設定するには、次の操作を行います。

    1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

    2. 次の場所に移動します。

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics

    3. 右側のウィンドウで [2 Categorizer] をダブルクリックし、値のデータを 7 に設定して [OK] をクリックします。

    4. レジストリ エディタを終了します。

      注 :
      トラブルシューティングが完了したら、[2 Categorizer] の値のデータを 0 に戻します。

  3. Exchange Server が 1 つ以上のグローバル カタログ サーバーに接続していることを確認します。それには、Windows のネットワーク モニタ ツールを使用すると便利です。

  4. 生成される配信状態通知 (DSN) メッセージをすべて確認します。DSN (配信不能レポート (NDR) を含む) には永続的なエラーを示すメッセージと一時的なエラーを示すメッセージが記載され、これらはよく永続的な配信エラーにつながります。

  5. メッセージの追跡機能を使用して、カテゴライザに入ったままになっているメッセージについてのトラブルシューティングを行います。

  6. Archive Sink ツールを使用して、Exchange Server で送受信されるメッセージのアーカイブと分析を行います。

  7. システム モニタを使用して、カテゴライザのパフォーマンス カウンタを監視します。

Exchange Server および Microsoft Windows Small Business Server によって生成される DSN と NDR の一覧については、Microsoft サポート技術情報の文書番号 284204「Exchange Server および Small Business Server における配信状態通知」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204) を参照してください。

Exchange Server でのメッセージ追跡センターの使用方法については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 262162「[XADM] メッセージ追跡センターを使用してメッセージを追跡する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=262162)

  • 文書番号 246856「[XADM] Exchange 2000 Server でメッセージの追跡を有効にする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246856)

  • 文書番号 821905「メッセージ追跡の Exchange Server 2003 でのイベント ID」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821905)

  • 文書番号 823864「Exchange Server 2003 での強化されたメッセージ追跡の機能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823864)

メッセージ カテゴライザに関する問題のトラブルシューティングの詳細については、Microsoft Support WebCast「メッセージ カテゴライザと NDR トラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=329137) を参照してください。

Archive Sink ツールの詳細については、Microsoft サポート技術情報の文書番号 307798「[XCON] Exchange 2000 Service Pack 2 で Archive Sink ユーティリティが利用可能」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=307798) を参照してください。

トランスポート関連の問題のトラブルシューティングに関する一般的な情報については、次の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 821910「[HOWTO] Exchange Server 2003 トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821910)

  • 文書番号 257265「[XCON] トランスポート問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=257265)

メッセージ カテゴライザのパフォーマンス カウンタは、SMTP 仮想サーバー インスタンスごとに個別に発行されます。メッセージ カテゴライザに関連して使用することができるパフォーマンス カウンタの一覧については、Microsoft サポート技術情報の文書番号 231734「[XCON] メッセージ カテゴライザ用のパフォーマンス モニタ カウンタ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=231734) を参照してください。

その他のカテゴライザに関する WMI カウンタの一部については、以下の Exchange Server アナライザ ツールの文書を参照してください。

  • SMTP メッセージのエラーに関する警告 - カテゴライザのアドレス参照が見つからない

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリのログオン障害

  • SMTP メッセージのエラーに関する警告 - カテゴライザ ディレクトリ サービス エラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザの再試行不能なエラー

  • SMTP メッセージのエラーに関する警告 - カテゴライザのメモリ不足による失敗


SMTP メール キュー データが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP メール キュー フォルダの Compressed キーの値を判断します。Compressed の値が True に設定されていることが検出された場合は、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP メール キュー データが格納されているフォルダに対してファイル圧縮を有効にすると、Exchange のパフォーマンスが大幅に低下します。そのため、SMTP メール キューが格納されているフォルダの圧縮はサポートされていません。

Microsoft では、圧縮されたボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

特定のフォルダに対するファイル圧縮を無効にするには

  1. ファイル圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 上の Mailroot フォルダを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] をクリックし、操作する管理グループ、[サーバー]、操作するサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. 操作する SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. 操作する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[キュー ディレクトリ] ボックスの横にある [参照] をクリックし、キュー フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?Linkld=3052&kbid=822933) を参照してください。


SMTP メール キュー データが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) メール キュー フォルダの Encrypted キーの値を判断します。Encrypted の値が True に設定されていることが検出されると、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP メール キュー データが格納されているフォルダに対してファイルの暗号化を有効にすると、Exchange のパフォーマンスが大幅に低下する場合があります。そのため、SMTP メール キューが格納されているフォルダの暗号化はサポートされていません。

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームへの Exchange データ ファイルの格納をサポートしていません。暗号化されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティを強化するため、Exchange コンピュータへの権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

このエラーを解決するには、SMTP メール キュー フォルダでファイルの暗号化を無効にするか、暗号化が有効になっていない場所に SMTP メール キュー フォルダを移動する必要があります。

特定のフォルダに対するファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ]をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

Exchange 2000 Server または Exchange Server 2003 上の SMTP メール キュー フォルダを移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ] をクリックし、操作する管理グループ、[サーバー]、操作するサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. 操作する SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. 操作する SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[不正メール ディレクトリ] ボックスの横にある [参照] をクリックし、不正メール用フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933) を参照してください。

Exchange Server のデータ ファイルと EFS の詳細については、Microsoft サポート技術情報の文書番号 834638「ストレージについてのデータの情報は、暗号化されたボリュームに Exchange でサーバーをファイルします。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Microsoft Exchange Server 2003 でメッセージをセキュリティで保護する方法の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?LinkId=47574) を参照してください (このサイトは英語の場合があります)。


SMTP メール キュー データが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange SMTP キュー ディレクトリの FSName キーの値を確認します。FSName キーの値が "NTFS File System" に等しくないことが検出されると、エラーが表示されます。

Microsoft は、Exchange データ ファイルを NTFS 以外のボリュームに格納することをサポートしていません。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

このエラーが表示された場合は、SMTP キュー ディレクトリを NTFS ドライブ上のフォルダに移動する必要があります。または、キュー ディレクトリが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

SMTP キューを別のフォルダに移動するには

  1. Exchange システム マネージャを起動します。

  2. [管理グループ]、目的の管理グループ、[サーバー]、目的のサーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバーを右クリックし、[停止] をクリックします。

  4. SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブで、[不正メール ディレクトリ] ボックスの横にある [参照] をクリックし、不正メール用フォルダの新しい場所のパスを入力します。

  6. [OK] をクリックします。

  7. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。

Mailroot フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=822933) を参照してください。

この文書に記載されている手順の代わりに、ファイルが格納されているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用してそのドライブを NTFS に変換することもできます。convert.exe コマンド ライン ツールを使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=214579) を参照してください。


SMTP MaxDSNSize 値が手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは次のレジストリ サブキーを読み取り、配信状態通知 (DSN) メッセージの最大サイズが手動で上書きされているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MaxDSNSize

MaxDSNSize が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MaxDSNSize レジストリ値を使用すると、メッセージを配信できない場合に、Exchange 2000 Server Service Pack 2 (SP2) 以降を実行しているコンピュータで添付ファイルを削除できるようになります。このオプションを有効にすると、サーバーネットワークのリソースを節約できます。ただし、SMTP 添付ファイルを削除するこの実装には欠点があります。

このオプションを有効にして配信不能レポート (NDR) から添付ファイルを削除すると、通知をプレビュー ウィンドウに表示するために必要な詳細情報も削除されるため、メッセージの発信者は再送信オプションを使用できなくなります。メッセージの発信者が NDR から再送信オプションを使用しようとすると、次のエラー メッセージが表示されます。

"このメッセージを再送信できません。配信不可通知に元のメッセージに関する十分な情報が含まれていません。メッセージを再送信するには、送信済みアイテム フォルダの再送信するメッセージを開き、[アクション] メニューの [このメッセージを再送] をクリックします。"

ただし、メッセージの発信者は、このエラー メッセージに示された方法を使用してもメッセージを再送信できません。そのため、このオプションは慎重に使用することをお勧めします。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

MaxDSNSize レジストリ値を変更するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. MaxDSNSize という名前の DWORD レジストリ値を作成し、その値のデータ (バイト単位) を希望する容量に設定します。

  4. レジストリ エディタを終了し、SMTP サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

MaxDSNSize レジストリ値の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 308303「[XCON] NDR を生成するメッセージの添付ファイルを取り除くオプション」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=308303)

  • 文書番号 323484「[XCON] Exchange 2000 の multipart/report インターネット メッセージ形式の説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=323484)


SMTP MaxPendingCat レジストリが既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

MaxPendingCat キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値は、十分に考慮したうえでのみ変更することをお勧めします。既定の設定は、ほとんどの環境でパフォーマンスが最適となるように慎重に選択されています。一般的なベスト プラクティスは、Exchange のキュー動作を変更するのではなく、問題の根本的な原因に対処することです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP のキューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP に関する MaxMessageObjects に設定されている値が小さすぎる
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、システムで割り当てることができるメール メッセージの最大数を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\MailMsg\MaxMessageObjects

MaxMessageObjects の値が 30001 より小さいことが検出されると、警告が表示されます。

キューに最大数のメッセージが格納されている場合、それ以上の受信メッセージは SMTP (Simple Mail Transfer Protocol) によって受け付けられません。SMTP キューにある各メール メッセージは、少なくとも 4 KB のメモリを使用します。そのため、キューが非常に大きいとメモリ不足の状況が発生する場合があります。

MaxMessageObjects 値は既定では存在しておらず、メッセージの最大数は 100,000 に設定されています。MaxMessageObjects を小さな値に設定すると、キュー内に存在できるメッセージの最大数が減少するため、SMTP の最大メモリ使用量を減らすことができます。この制限に達すると、サーバーに対して実行される各 SMTP 接続からメモリ不足エラーが返されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

キューに格納される SMTP メッセージの数に制限を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Exchange

  3. [Exchange] キーを右クリックし、[新規]、[キー] の順にクリックします。新しいキーの名前は "MailMsg" にします。

  4. [MailMsg] キーを右クリックし、[新規]、[DWORD 値] の順にクリックします。

  5. 新しい値を右クリックし、[名前の変更] をクリックします。次に、「MaxMessageObjects」と入力します。

  6. [MaxMessageObjects] 値をダブルクリックし、この値を任意の時点でキュー内に存在するメッセージの最大数に設定します。より数多くのメッセージを処理する必要がある場合を除き、最大値として 100,000 をお勧めします。

  7. レジストリ エディタを終了し、SMTP サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

キュー内のメッセージ数の制限を設定する方法の詳細については、Microsoft サポート技術情報の文書番号 258748「[XGEN] キュー内の SMTP メッセージ数を制限する設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258748) を参照してください。


SMTP MaxMessageObjects レジストリ パラメータが既定値から変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、システムで割り当てることができるメール メッセージの最大数を判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\MailMsg\MaxMessageObjects

MaxMessageObjects の値が 0 より大きいことが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューに最大数のメッセージが格納されている場合、それ以上の受信メッセージは SMTP によって受け付けられません。SMTP キューにある各メール メッセージは、少なくとも 4 KB のメモリを使用します。そのため、キューが非常に大きいとメモリ不足の状況が発生する場合があります。

MaxMessageObjects 値は既定では存在しておらず、メッセージの最大数は 100,000 に設定されています。MaxMessageObjects を小さな値に設定すると、キュー内に存在できるメッセージの最大数が減少するため、SMTP の最大メモリ使用量を減らすことができます。この制限に達すると、サーバーに対して実行される各 SMTP 接続からメモリ不足エラーが返されます。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

キューに格納される SMTP メッセージの数に制限を設定するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\Software\Microsoft\Exchange

  3. [Exchange] キーを右クリックし、[新規]、[キー] の順にクリックします。新しいキーの名前は "MailMsg" にします。

  4. [MailMsg] キーを右クリックし、[新規]、[DWORD 値] の順にクリックします。

  5. 新しい値を右クリックし、[名前の変更] をクリックします。次に、「MaxMessageObjects」と入力します。

  6. [MaxMessageObjects] 値をダブルクリックし、この値を任意の時点でキュー内に存在するメッセージの最大数に設定します。より多くのメッセージを処理する必要がある場合を除き、100,000 の最大値を使用することをお勧めします。

  7. レジストリ エディタを終了し、SMTP (Simple Mail Transfer Protocol) サービスを再開して変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=256986) を参照してください。

キュー内のメッセージに対する制限の設定の詳細については、Microsoft サポート技術情報の文書番号 258748「[XGEN] キュー内の SMTP メッセージ数を制限する設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258748) を参照してください。


SMTP MaxPercentPoolThreads レジストリ値が手動で設定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、追加のプール スレッドが手動で構成されたかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\MaxPercentPoolThreads

Exchange Server アナライザによって、MaxPercentPoolThreads が存在し構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

SMTP には、ATQ スレッドと呼ばれるスレッドのプールを使用するワーク キューが 5 つあります。仕様により、これらのキューのうち 2 つは、既定で、使用可能なスレッドの 90% まで使用することができます。このスレッド プールは、POP および IMAP の要求を受け付けるプロセスによって共有されます。したがって、負荷が中程度から高程度のシナリオで、SMTP が POP および IMAP サービスのリソースを保持可能な状況が発生する可能性があります。

SMTP で使用できるスレッドの割合を制限することで、POP および IMAP 用のスレッドを十分確保できます。この変更を行うには、IIS で利用できるスレッドの総数を増やす必要があります。この変更による代償は、スレッドの追加によってメモリの使用量が増加することのみです。

ユーザーが SMTP スレッドの割合と、プロセッサあたりの追加スレッド数を制御できるようにするレジストリ値は、以下の 2 つです。

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

値 : AdditionalPoolThreadsPerProc

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

値 : MaxPercentPoolThreads

種類 : REG_DWORD

クラスタ化された Exchange Server コンピュータでは、SMTP の処理量が多いために POP3 と IMAP4 のどちらか、または両方のリソースが不足する場合、両方のレジストリ値を調整する必要があります。次の計算式を使用して、クラスタの最適値を求めることができます。

レジストリ値 | 計算式
AdditionalPoolThreadsPerProc | ((9 / (MaxPercentPoolThreads/100)) - 4) / 2
MaxPercentPoolThreads | 90 / (2 x プロトコルの仮想サーバー数)

たとえば、2 つのプロトコルの仮想サーバーがある Exchange Server クラスタの場合、MaxPercentPoolThreads を求める計算式は、"90 / (2 x 2) = 22" となります。MaxPercentPoolThreads 値を計算すると小数点を含む値になる場合は、結果の端数を切り捨てて整数にする必要があります。AdditionalPoolThreadsPerProc 値を計算し、結果が 200 より大きい値になる場合は、計算結果の値を次のレジストリ値にも割り当てる必要があります。

場所 : HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\

値 : PoolThreadLimit

種類 : REG_DWORD

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

Exchange クラスタで最適な設定を構成するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Parameters

  3. DWORD のレジストリ値を AdditionalPoolThreadsPerProc という名前で作成し、その値を、上の計算式で求めた適切な数値に設定します。

  4. DWORD のレジストリ値を MaxPercentPoolThreads という名前で作成し、その値を、上の計算式で求めた適切な数値に設定します。

  5. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

この文書で説明した特定のクラスタ リソースの問題に関する詳細については、Microsoft サポート技術情報の文書番号 281868「[XADM] 負荷が大きいときに POP/IMAP4 仮想サーバーが繰り返しフェール オーバーする」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=281868) を参照してください。


SMTP MsgHandleAsyncThreshold レジストリ値が手動で追加されているが、不要になった可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、非同期のインターネット インフォメーション サービス (IIS) のファイル ハンドルの最大数が、既定値の 1,000 から変更されたかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MsgHandleAsyncThreshold

MsgHandleAsyncThreshold のエントリが存在しており、さらにそれが別の値で構成されていることが検出されると、警告が表示されます。

MsgHandleAsyncThreshold の値には、IIS が使用できる非同期のファイル ハンドルの最大数を指定します。ファイル ハンドルをキャッシュすると、サーバーによる冗長な入出力 (I/O) と CPU サイクルが減少するため、パフォーマンスが向上します。Exchange Server コンピュータ上の SMTP トランスポート スタックがメッセージを受信するたびに、そのメッセージはファイル システムに送信され、そこで配信先にルーティングされるのを待ちます。ファイル システムに書き込むためには、SMTP トランスポート スタックがファイル ハンドルを取得し、メッセージをそのハンドルに渡します。各ファイル ハンドルは、約 2 キロバイト (KB) のページ プール メモリを消費します。IIS キャッシュ ファイル ハンドルの既定数は、32 MB ごとに 800 です。

Exchange 2000 Server Service Pack 2 (SP2) が公開されるまでは、既定の設定で SMTP サービスのファイル ハンドル数が最大で 1,000 とされていたため、大きな SMTP メッセージ キュー (平均 1,000 件以上のメッセージなど) を維持する Exchange サーバーではパフォーマンスが制約されていました。Exchange 2000 Server の既定では、ファイル ハンドルの最大数が 1,000 に設定されていたため、SMTP サービスは一度に 1,000 件を超えるメッセージをファイル システムに書き込むことができませんでした。

このような大規模システムのパフォーマンスを向上させるため、以下に示す 3 つのレジストリ エントリを頻繁かつ同時に調整することで、(より多くのメッセージを処理できるように) SMTP サービスが開くことのできるファイル ハンドルの最大数を増やし、(キューが大きくなった場合のメモリ不足を回避するため) 別の Exchange コンポーネントである IFS (Installable File System) のために開かれるファイル ハンドルの数を減らしていました。これらのレジストリ値は、既定では存在していないため、手動で追加する必要がありました。

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

値 : MsgHandleThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

値 : MsgHandleAsyncThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

値 : FileCacheMaxHandles

種類 : REG_DWORD

MsgHandleThreshold と MsgHandleAsyncThreshold のエントリは、一般的に同じ値 (通常は 1,000 より大きい値) に設定し、FileCacheMaxHandles の値は、通常 800 から 600 に減らします。

Exchange 2000 Server SP2 以降では、使用に最適な値が動的に決定されるため、このレジストリ値は既定では存在しません。この Exchange サーバーが Exchange 2000 Server Service Pack 1 (SP1) 以前を実行している場合は、ベスト プラクティスとして、最新の Service Pack およびロールアップ パッケージにアップグレードすることをお勧めします。最新のコードにアップグレードしたら、これらのレジストリ エントリを削除します。

Exchange Server 2003 では、SMTP ファイル ハンドルの適切な設定が動的に計算されるため、これらの設定は必要なくなりました。したがって、Microsoft 製品サポート サービスによる指示がない限り、これらの設定が指定されている Exchange 2000 Server コンピュータを Exchnage Server 2003 にアップグレードする場合は、事前にこれらのエントリをレジストリから削除する必要があります。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

既定の構成に戻すには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. 右側のウィンドウで、MsgHandleAsyncThreshold 値を削除します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して変更を適用します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP の MsgHandleThreshold レジストリ値が手動で追加されているが、不要になった可能性がある
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、インターネット インフォメーション サービス (IIS) のファイル ハンドルの最大数が、既定値の 1,000 から変更されたかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing\MsgHandleThreshold

Exchange Server アナライザによって、MsgHandleThreshold のエントリが存在しており、別の値でエントリが構成されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

MsgHandleThreshold の値には、IIS が使用できるファイル ハンドルの最大数を指定します。ファイル ハンドルは、パフォーマンスを向上させるためにキャッシュされます。パフォーマンスが向上するのは、ファイル ハンドルをキャッシュすることで、重複する入出力 (I/O) と CPU サイクルをサーバーで実行する必要がなくなるためです。Exchange Server コンピュータ上の SMTP トランスポート スタックがメッセージを受信するたびに、そのメッセージはファイル システムに送信され、そこで配信先にルーティングされるのを待ちます。ファイル システムに書き込むため、SMTP トランスポート スタックはファイル ハンドルを取得してから、そのハンドルにメッセージを渡します。ファイル ハンドルはそれぞれ約 2 KB のページ化プール メモリを消費します。IIS キャッシュ ファイル ハンドルの既定の数は、32 MB ごとに 800 個です。

Exchange 2000 Server Service Pack 2 (SP2) 以前のバージョンの場合、SMTP サービスの既定の設定ではファイル ハンドルの最大数が 1,000 であったため、大きな SMTP メッセージ キュー (たとえば平均で 1,000 以上のメッセージ) を保持する Exchange サーバーでは、従来はパフォーマンスの制約が発生していました。Exchange 2000 Server の既定では、ファイル ハンドルの最大数が 1,000 に設定されていたため、SMTP サービスは一度に 1,000 件を超えるメッセージをファイル システムに書き込むことができませんでした。

このような大規模なシステムのパフォーマンスを向上させるため、3 つのレジストリ エントリを同時に調整し、(より多くのメッセージの処理が可能なように) SMTP サービスで開くことができるファイル ハンドルの最大数を増やし、(キューが大きくなった場合のメモリ不足を回避するため) 別のExchange コンポーネントである IFS (Installable File System) のために開かれるファイル ハンドルの数を減らすことがしばしば行われました。以下に示すこれらのレジストリ値は既定では存在しないため、手動で追加する必要がありました。

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

値 : MsgHandleThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

値 : MsgHandleAsyncThreshold

種類 : REG_DWORD

場所 : HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

値 : FileCacheMaxHandles

種類 : REG_DWORD

MsgHandleThreshold と MsgHandleAsyncThreshold のエントリは、一般に同じ値 (通常は 1,000 より大きい値) に設定し、FileCacheMaxHandles の値は、通常 800 から 600 に減らします。

この Exchange サーバーで Exchange 2000 Server が実行されている場合、ベスト プラクティスとして、最新レベルの Service Pack およびロールアップ パッケージにアップグレードすることをお勧めします。最新のコードにアップグレードした後は、MsgHandleThreshold の値を既定の 1000 に設定することをお勧めします。

Exchange Server 2003 では MsgHandleThreshold の既定値は 1000 であるため、レジストリの上書き設定は必要ありません。したがって、Microsoft 製品サポート サービスによる指示がない限り、これらの設定が指定されている Exchange 2000 Server コンピュータを Exchnage Server 2003 にアップグレードする場合は、事前にこれらのエントリをレジストリから削除する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。

このエラーを修正するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。HKLM\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. MsgHandleThreshold の値を削除します。

  4. レジストリ エディタを終了し、IIS Admin サービスを再開して、変更を有効にします。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。


SMTP PickUp ファイルが圧縮フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) PickUp フォルダの Compressed キーの値を判断します。Compressed の値が True に設定されていることが検出された場合は、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP PickUp データが格納されているフォルダに対してファイル圧縮を有効にすると、Exchange のパフォーマンスが大幅に低下します。そのため、SMTP PickUp データが格納されているフォルダの圧縮はサポートされていません。

この警告が表示された場合は、SMTP PickUp データが格納されているフォルダの圧縮を無効にするか、SMTP PickUp データを圧縮されていない別のフォルダに移動する必要があります。

Microsoft では、圧縮されたボリュームでの Exchange データ ファイルの格納をサポートしていません。圧縮されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、以下のファイルがすべて含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

特定のフォルダに対するファイル圧縮を無効にするには

  1. ファイル圧縮を無効にするフォルダを右クリックし、[プロパティ] をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

PickUp フォルダの移動の詳細については、Microsoft サポート技術情報の文書「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/?Linkld=3052&kbid=822933) を参照してください。


SMTP PickUp ファイルが暗号化フォルダに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) PickUp フォルダの Encrypted キーの値を判断します。Encrypted の値が True に設定されていることが検出されると、警告が表示されます。

SMTP サービスを通して Exchange コンピュータにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ名>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。SMTP PickUp データが格納されているフォルダに対してファイルの暗号化を有効にすると、Exchange のパフォーマンスが大幅に低下する場合があります。このため、SMTP PickUp データが格納されているフォルダの暗号化はサポートされていません。

この警告が表示された場合は、SMTP PickUp データが格納されているフォルダの暗号化を無効にするか、または SMTP PickUp データを暗号化されていないフォルダに移動する必要があります。

Microsoft は、暗号化ファイル システム (EFS) で暗号化されたボリュームへの Exchange データ ファイルの格納をサポートしていません。暗号化されたボリュームに Exchange データ ファイルを格納すると、追加のオーバーヘッドによって Exchange のパフォーマンスが大幅に低下します。Exchange データ ファイルには、次のファイルが含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

  • .chk ファイル

Exchange データ ファイルのセキュリティを強化するため、Exchange コンピュータへの権限のないアクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化することをお勧めします。

このエラーを解決するには、PickUp フォルダでファイルの暗号化を無効にするか、暗号化が有効になっていない場所に PickUp フォルダを移動する必要があります。

特定のフォルダに対するファイルの暗号化を無効にするには

  1. ファイルの暗号化を無効にするフォルダを右クリックし、[プロパティ]をクリックします。

  2. [全般] タブで、[詳細設定] をクリックします。

  3. [属性の詳細] ダイアログ ボックスで、[内容を暗号化してデータをセキュリティで保護する] チェック ボックスをオフにし、[OK] をクリックします。

PickUp フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/?LinkId=3052&kbid=822933) を参照してください。

Exchange Server のデータ ファイルと EFS の詳細については、Microsoft サポート技術情報の文書番号 834638「ストレージに関するデータの情報は、暗号化されたボリュームに Exchange でサーバーを提出します。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=834638) を参照してください。

Exchange Server 2003 でメッセージをセキュリティで保護する方法の詳細については、『Exchange Server Message Security Guide』(http://go.microsoft.com/fwlink/?linkid=47574) を参照してください (このサイトは英語の場合があります)。


SMTP Pickup ファイルが NTFS 以外のパーティションに書き込まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Win32_Directory Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange SMTP PickUp ディレクトリの FSName キーの値を判断します。FSName キーの値が NTFS ではないことが検出されると、警告が表示されます。

Microsoft では、NTFS ではないボリュームへの Exchange データ ファイルの格納をサポートしていません。Exchange データ ファイルには、次のファイルが含まれます。

  • .edb ファイル

  • .stm ファイル

  • .log ファイル

  • .dat ファイル

  • .eml ファイル

この警告が表示された場合、SMTP PickUp ディレクトリを、NTFS ファイル システムを使用しているドライブのフォルダに移動する必要があります。または、PickUp ディレクトリが置かれているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。

PickUp フォルダの移動の詳細については、Microsoft サポート技術情報の文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/?LinkId=3052&kbid=822933) を参照してください。

または、ファイルが置かれているドライブが FAT ドライブとしてフォーマットされている場合は、convert.exe コマンド ライン ツールを使用して、そのドライブを NTFS に変換できます。convert.exe コマンド ライン ツールを使用して FAT パーティションを NTFS パーティションに変換する方法の詳細については、Microsoft サポート技術情報の文書番号 214579「Convert.exe を使用してパーティションを NTFS ファイル システムに変換する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=214579) を参照してください。


SMTP ポートが変更されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-11

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベース内の次のプロパティを読み取り、その値が既定値の 25 と同じかどうかを判断します。

LM/SmtpSvc/<SMTP 仮想サーバー インスタンス>/SMTPPORT

SMTPPORT プロパティの値が 25 以外であることが検出されると、警告が表示されます。

SMTPPORT プロパティは、この SMTP (Simple Mail Transfer Protocol) サーバーが受信接続待ちを行う TCP ポートを表します。SMTP 仮想サーバーは、1 つ以上の TCP ポートで接続要求待ちを行うように構成できます。既定では、すべての SMTP 仮想サーバーが、TCP ポート 25 (既定の SMTP ポート) で接続要求待ちを行うように構成されます。SMTP のリスニング ポートが既定から変更されて、リスニング ポートの一覧に TCP ポート 25 が含まれなくなっていると、メールの流れが中断される可能性があります。

SMTP のリスニング ポートを変更しても問題がないのは、この変更に合わせて内部メッセージング インフラストラクチャの残りの部分も変更される場合のみです。ただし一般的に、インターネット上の SMTP サーバーはポート 25 を通してメッセージを送信するので、インターネットから直接メッセージを受け付ける SMTP 仮想サーバーで代わりのポートを使用することはできません。

注 :
Exchange Server アナライザは、Exchange の SMTP プロトコル仮想サーバーの値を調べます。この SMTP プロトコル仮想サーバーは、インターネットから直接メッセージを受信する SMTP サーバーではない場合があります。ウイルス対策製品やスパム対策製品の中には、ポート 25 でインターネットからの SMTP メッセージを受信し、別のポートの Exchange SMTP 仮想サーバーにリダイレクトするように設計されているものがあります。この場合は、ポート 25 以外のポートで接続要求待ちを行う Exchange SMTP 仮想サーバーの構成を使用することができます。
SMTP 仮想サーバーのリスニング ポートを表示または変更するには、次の操作を行います。

  1. Exchange システム マネージャで、[サーバー] を展開し、[Exchange サーバー] を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  2. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブをクリックし、[詳細設定] をクリックします。

  4. IP アドレスとポートの一覧が表示されます。

    • 既存のポートを変更するには、IP アドレスを選択し、[編集] をクリックします。[TCP ポート] ボックスの値を 25 に変更します。

    • 追加のリスニング ポートとして 25 を追加するには、[追加] をクリックして、新しい IP アドレスとポートの組み合わせを追加します。接続、送信者、または受信者のフィルタを使用している場合は、必ず適切なチェック ボックスをオンにしてください。

  5. [OK] をクリックして変更を保存したら、[OK] をクリックして [詳細設定] ダイアログ ボックスを閉じます。[OK] をクリックして、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SMTP キュー フォルダに多数のファイルが含まれている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールでは、各 SMTP (Simple Mail Transfer Protocol) 仮想サーバー インスタンスの QueueDirectory 属性の値を判断するために、インターネット インフォメーション サービス (IIS) メタベースに対してクエリが実行されます。

次に、各 SMTP 仮想サーバーに指定されているキュー フォルダ内のファイル数がカウントされます。

SMTP 仮想サーバーのキュー フォルダで 50,000 以上のファイルが検出された場合は、警告が表示されます。

SMTP 仮想サーバーのキュー フォルダで 90,000 以上のファイルが検出された場合は、エラーが表示されます。

この警告またはエラーは、その SMTP 仮想サーバー インスタンスで処理する必要のあるメッセージが蓄積されていることを示しています。また、そのサーバーが受信メールを適切な時間内に配信できないために、サーバーで重大なパフォーマンスの問題や停止が発生したことを示しています。以下の状況によってこの遅延が発生する可能性があります。

  • Active Directory® ディレクトリ サービスが直ちに参照されていない。

  • メッセージがローカル配信または SMTP に直ちに渡されていない。

この問題を解決するには

  • 迷惑な商用電子メール (UCE)、スパム、またはウイルス攻撃によってサーバーの負荷が異常に高くなっていないかどうかを確認するために、キュー フォルダ内のメッセージの妥当性を確認します。

  • SMTP サービスが有効になっており、実行されていることを確認します。

SMTP サービスが開始されていることを確認するには

  1. Microsoft 管理コンソール (MMC) のサービス スナップインを開きます。

  2. 右側のペインで、[Simple Mail Transfer Protocol (SMTP)] サービスまで下にスクロールし、このサービスをダブルクリックします。この操作によって [Simple Mail Transfer Protocol (SMTP) のプロパティ] ダイアログ ボックスが表示されます。

  3. [スタートアップの種類] ドロップダウン メニューの値が、[自動] に設定されていることを確認します。

  4. [開始] をクリックしてシステム アテンダント サービスを開始します。

  5. [OK] をクリックして変更を保存し、[Simple Mail Transfer Protocol (SMTP) のプロパティ] ダイアログ ボックスを閉じます。

  6. サービス スナップインを閉じます。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server トランスポートおよびルーティング ガイドのメールの流れと SMTP に関するトラブルシューティングのページ (http://go.microsoft.com/fwlink/?LinkId=47579)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • マイクロソフト サポート技術情報の記事 821877 の、SMTP および X.400 のキューのプロパティ タブに表示されるフィールドの説明に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • マイクロソフト サポート技術情報の記事 264054 の、[XCON] Exchange 2000 サーバーのキュー状態の理解に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


SMTP のキュー フォルダとピックアップ フォルダが同じになっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、特定の SMTP 仮想サーバーで、メッセージを受け取るディレクトリと、メッセージをキューに入れるディレクトリが同じでないことを確認します。キュー ディレクトリの属性である msExchSmtpQueueDirectory と、ピックアップ ディレクトリの属性である msExchSmtpPickupDirectory が同じであることが検出されると、エラーが表示されます。

このエラーは重大なエラーです。msExchSmtpQueueDirectory 属性と msExchSmtpPickupDirectory 属性が同じディレクトリに設定されていると、重複するメッセージが配信されます。これらの属性は、Active Directory サービス インターフェイス (ADSI) Edit を使用して更新することができます。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。
ADSI Edit を使用して msExchSmtpPickupDirectory または msExchSmtpQueueDirectory の属性を更新するには

  1. Windows® 2000 サポート ツールまたは Windows Server 2003 サポート ツールから、ADSI Edit ツールを起動します。

  2. 次のノードを展開します。

    • [Configuration] コンテナ

    • [Configuration]

    • [Services]

    • [Microsoft Exchange]

    • [<組織名>]

    • [Recipient Policies]

    • [<管理グループ名>]

    • [Servers]

    • [<サーバー名>]

    • [Protocols]

    • [SMTP]

  3. 詳細ペインで、[CN=1] を右クリックし (1 は既定の SMTP 仮想サーバーを表します)、[プロパティ] をクリックします。

  4. [Select which properties to view] ボックスの一覧の [Both] をクリックします。

  5. msExchSmtpQueueDirectory と競合しなくなるように、msExchSmtpPickupDirectory の属性を更新し、指定を終えたら [Set] をクリックします。

  6. [OK] をクリックし、[適用] をクリックします。次に、ADSI Edit を終了します。

  7. レプリケーションが完了するまで、少なくとも 15 分待機します。


SMTP キューがシステム パーティションと同じドライブ上に存在する
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpQueueDirectory 属性の構成値を判断します。

また、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してもクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、サービスは実行されていません。値が True の場合、サービスは実行されています。さらに、Exchange Server アナライザは Win32_OperatingSystem WMI クラスに対してクエリを実行し、WindowsDirectory キーの値を判断します。このキーの値は、Windows システム ドライブの場所を示します。

msExchSmtpQueueDirectory 属性が、システム ドライブと同じドライブが含まれるパスを使用して構成されていること、SMTP サービスが実行されていること、および Exchange が Microsoft Windows Small Business Server Edition 上で実行されていないことが検出されると、警告が表示されます。

msExchSmtpQueueDirectory 属性は、Mailroot フォルダとも呼ばれる SMTP キュー フォルダのパスを表します。SMTP サービスを通して Exchange サーバーにメッセージが到着すると、メッセージ データは .eml ファイルとしてハード ディスクに書き込まれます。既定では、これらのファイルは Exchange がインストールされたパーティション上の <ドライブ>:\Program Files\Exchsrvr\Mailroot フォルダに格納されます。

場合によっては (ブリッジヘッド サーバーを構成する場合など)、SMTP Mailroot ディレクトリを別のハード ディスクまたはパーティションに移動すると、Exchange サーバーのパフォーマンスを高めることができます。ベスト プラクティスとして、SMTP Mailroot フォルダは、Windows システム ドライブと同じドライブに置かないでください。最大のパフォーマンスを得るためには、システム ドライブではなく、高速なディスクまたはディスク サブシステム上に配く必要があります。

Mailroot フォルダは、Exchange Server 2003 SMTP 仮想サーバー上では Exchange システム マネージャで移動できますが、Exchange 2000 Server SMTP 仮想サーバー上で移動するには、Active Directory サービス インターフェイス (ADSI) Edit のような低レベルの Active Directory エディタを使用する必要があります。

注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

Exchange Server 2003 でこのエラーを修正するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[停止] をクリックします。

  4. SMTP 仮想サーバーをもう一度右クリックし、[プロパティ] をクリックします。

  5. [メッセージ] タブをクリックします。

  6. [キュー ディレクトリ] ボックスで、適切な Mailroot フォルダの完全なパスを指定します。[参照] をクリックするとローカル コンピュータのパスを参照できます。

  7. [OK] をクリックして変更を保存します。

  8. SMTP 仮想サーバーを右クリックし、[開始] をクリックします。新しい場所は直ちに使用されます。

Exchange 2000 Server でこのエラーを修正するには

  1. 変更する SMTP 仮想サーバーの Mailroot フォルダがある Exchange 2000 Server で、Exchange Server および IIS のサービスをすべて停止します。

  2. 影響が反映される SMTP 仮想サーバーが適切なパスで構成されるように、サーバーの msExchSmtpQueueDirectory の値を変更します。

  3. この Exchange サーバーが使用するグローバル カタログ サーバーに、Active Directory によってこの変更がレプリケートされるまで待機します。

  4. Microsoft Exchange System Attendant サービスを開始します。

  5. Exchange Server コンピュータのアプリケーション イベント ログで、イベント ソースが MSExchangeMU でカテゴリが General であるイベント ID 1005 のインスタンスが 3 つ存在するかどうかを確認します。

  6. Exchange Server コンピュータを再起動して変更を有効にします。

説明した両方の手順の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 822933「Exchange 2003 SMTP Mailroot フォルダの場所を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=822933)

  • 文書番号 318230「[XCON] Exchange 2000 SMTP Mailroot ディレクトリの場所を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=318230)

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SMTP ResetMessageStatus レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing

以下の条件に当てはまる場合は、エラーが表示されます。

  • ResetMessageStatus キーが 0 (ゼロ) に設定されていない。

  • Exchange Server 上でクラスタ サービスが実行されていない。

ResetMessageStatus レジストリ キーが 1 に設定されている場合は、Exchange Server が再起動されると、現在キュー内にあるすべてのメッセージがすべての内部処理キューでもう一度処理されます。たとえば、Exchange Server が再起動されると、現在キュー内にあるすべてのメッセージがカテゴライザでもう一度処理されます。そのため、Microsoft サポート技術情報の文書番号 279616「XCON: Adding a Registry Key to Re-Categorize Messages」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=279616) (このサイトは英語の場合があります) で説明されているように、ResetMessageStatus キーを 1 に設定するのは、SMTP のインストールに関する問題をトラブルシューティングしている場合だけにしてください。SMTP のインストールに関する問題をトラブルシューティングしていない場合は、このレジストリ キーを削除する必要があります。

重要 :
この文書には、レジストリの編集についての説明が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
ResetMessageStatus レジストリ キーを削除するには

  1. Regedit.exe や Regedt32.exe などのレジストリ エディタを起動します。

  2. 次の場所に移動します。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Queuing

  3. 右側のペインで、ResetMessageStatus 値を見つけて削除します。

  4. レジストリ エディタを終了します。

レジストリを編集する場合、およびレジストリを編集する方法を詳しく知りたい場合は、Microsoft サポート技術情報の文書番号 256986「Microsoft Windows レジストリの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986) を参照してください。

Exchange SMTP キューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


The SMTP ResetRoutesRetryMinutes registry value is non-default
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

ResetRoutesRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値は、十分に考慮したうえでのみ変更することをお勧めします。既定の設定は、ほとんどの環境でパフォーマンスが最適となるように慎重に選択されています。一般的なベスト プラクティスは、Exchange Server のキュー動作を変更するのではなく、問題の根本的な原因に対処することです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP のキューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP RoutingRetryMinutes レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

RoutingRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値を変更する場合は、事前に十分な検討を行うことをお勧めします。既定値は、ほとんどの環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、Exchange Server でのキューの動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP キューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP SecondsPerDSNPass レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SecondsPerDSNPass レジストリの値の設定を判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

SecondsPerDSNPass キーが存在し、10 以外の値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

この設定は、配信状態通知 (DSN) を最適化するために使用され、各 DSN 処理パスに対する秒数を示します。このしきい値を超えると、すぐに DSN 生成が停止され、その後に再開されます。既定値を変更する場合は、事前に十分な検討を行うことをお勧めします。この特定の設定を変更する場合は、その前に必ず Microsoft サポート サービスに相談してください。既定値は、ほとんどの環境で最適なパフォーマンスが得られるように慎重に選択されています。一般的なベスト プラクティスとして、Exchange Server でのキューの動作を変更するのではなく、問題の根本的な原因に対処することをお勧めします。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。


SMTP サーバーの NTLM 認証 が無効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-11-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchAuthenticationFlags 属性内に NTLM 認証プロトコル (別名、統合 Windows 認証) ビットが設定されているかどうかを判断します。このビットが設定されておらず、Microsoft Windows® Small Business Server 上で Exchange が実行されていないことが検出されると、警告が表示されます。

msExchAuthenticationFlags 属性は、プロトコル仮想サーバーが受け付ける認証の種類を示します。この属性は、以下に示す 3 ビット マスクを使用します。

ビット | 認証方法
0 | 匿名
1 | 基本
2 | NTLM (統合 Windows 認証)

NTLM 認証を制御するビットが設定されていない場合、SMTP 仮想サーバーは NTLM 認証を許可しません。このため、Exchange Server コンピュータ間で認証に関する問題が発生することがあります。

この警告を修正するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、サーバー名を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. Exchange SMTP 仮想サーバーを右クリックし、[プロパティ] をクリックします。

  4. [アクセス] タブをクリックして [認証] をクリックします。次に、[統合 Windows 認証] チェック ボックスをオンにします。

  5. [OK] をクリックし、再度 [OK] をクリックします。

  6. Exchange システム マネージャを終了します。

SMTP の認証方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) およびマイクロソフト サポート技術情報の記事 319267 の、Exchange 2000 で SMTP クライアントのメッセージ配信をセキュリティ保護する方法についての記事 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=319267) を参照してください。


SMTP の SubmissionRetryMinutes レジストリ値が既定値ではない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、SMTP キューの構成が既定値から変更されているかどうかを判断します。

HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\SMTPSvc\Queuing

SubmissionRetryMinutes キーが設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

キューの既定値は、十分に考慮したうえでのみ変更することをお勧めします。既定の設定は、ほとんどの環境でパフォーマンスが最適となるように慎重に選択されています。一般的なベスト プラクティスは、Exchange のキュー動作を変更するのではなく、問題の根本的な原因に対処することです。

Exchange Server アナライザは、この構成を情報提供のみを目的として報告します。このメッセージへの対処は必要ありません。

Exchange SMTP のキューの詳細については、Microsoft Exchange Team Blog のエントリ「Explaining the Mysterious SMTP Advanced Queuing Engine」(http://go.microsoft.com/fwlink/?LinkId=48585) を参照してください (このサイトは英語の場合があります)。


SMTP 仮想サーバーのメッセージ サイズ制限が、グローバル メッセージのサイズ制限よりも大きい
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP 仮想サーバーの受信メッセージ サイズ制限と、受信グローバル メッセージのサイズ制限を比較します。

SMTP 仮想サーバーの受信および送信メッセージ サイズ制限を表す Active Directory 属性は、msExchSmtpMaxMessageSize です。この値は、Active Directory 内の SMTP 仮想サーバー オブジェクトの属性であり、次の場所にあります。

[CN=<仮想サーバー番号>]、[CN=SMTP]、[CN=Protocols]、[CN=<サーバー名>]、[CN=Servers]、[CN=<管理グループ名>]、[CN=Administrative Groups]、[CN=<組織名>]、[CN=Microsoft Exchange]、[CN=Services]、[CN=Configuration, DC=<ドメイン名>, DC=com]

グローバル受信メッセージのサイズ制限を表す Active Directory 属性は、delivContLength です。この値は、Active Directory 内の組織のグローバル設定メッセージ配信オブジェクトの属性であり、次の場所にあります。

[CN=Message Delivery]、[CN=Global Settings]、[CN=<組織名>]、[CN=Microsoft Exchange]、[CN=Services]、[CN=Configuration, DC=<ドメイン名>, DC=com]

msExchSmtpMaxMessageSize の値が delivContLength の値より大きいことが検出されると、警告が表示されます。

いずれかの SMTP 仮想サーバーのメッセージ サイズ制限がグローバル メッセージのサイズ制限より大きいと、サイズの大きいメッセージが受け付けられた後、配信されなくなる可能性があります。この問題を解決するには、SMTP 仮想サーバーに、グローバル受信メッセージのサイズ制限以下の最大メッセージ サイズを設定します。

注 :
設定するメッセージ サイズ制限が小さすぎると、Exchange Server コンピュータ間のオフライン アドレス帳レプリケーションができなくなる可能性があります。この問題の詳細については、Microsoft サポート技術情報の文書番号 326154「XADM: メッセージのサイズ制限のトランスポート レベルで設定するならば、OAB が複製されません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=326154) を参照してください。

この警告を修正するには

  1. Exchange システム マネージャで、[サーバー] を展開し、Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  2. SMTP 仮想サーバー ([既定の SMTP 仮想サーバー] など) を右クリックし、[プロパティ] をクリックします。

  3. [メッセージ] タブをクリックします。

  4. [メッセージ サイズの制限値 (KB)] ボックスの値を、グローバル メッセージのサイズ制限以下になるように編集します。

  5. [OK] をクリックして変更を保存し、SMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

組織全体の設定の表示と編集の詳細については、Microsoft サポート技術情報の文書番号 821881「Exchange システム マネージャでのグローバル設定を変更する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821881) を参照してください。

グローバル メッセージのサイズ制限の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 298572「An e-mail message that is larger than the sending message size limit or the receiving message size limit is not delivered」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=298572)(このサイトは英語の場合があります)

  • 文書番号 322679「メッセージのサイズ制限の設定」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322679)

  • 文書番号 824111「Exchange Server 2003 で導入されたセキュリティ設定の変更および更新」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=824111)


SMTP 仮想サーバーが受信メッセージで DNS 逆引き参照を実行するように構成されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-24

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、msExchSmtpPerformReverseDnsLookup 属性の構成値が既定値の False から変更されているかどうかを判断します。既定では、msExchSmtpPerformReverseDnsLookup 属性は、受信メッセージで DNS 逆引き参照を実行しないように構成されます。Exchange Server アナライザによって、この属性が True に設定されていることが検出されると、警告が表示されます。

[受信メッセージで DNS 逆引き参照を実行する] オプションは、スパム電子メール メッセージの受信を防ぐ機能備えていません。このオプションを使用すると、Exchange Server は DNS クエリを実行し、受信メッセージの発信元のインターネット プロトコル (IP) アドレスをホスト名に解決します。このホスト名は次に、電子メール メッセージのヘッダーに付加されます。

この機能が有効になっていると、DNS レコードが正しく構成されていないため、またはインターネットへの接続が断続するためにパフォーマンスの低下が生じる場合があります。そのため、インターネット メールの配信に予期した以上の時間がかかる場合は、このオプションを無効にすることをお勧めします。

受信 SMTP メッセージで DNS 逆引き参照を有効または無効にするには

  1. Exchange システム マネージャを起動します。

  2. [サーバー] を展開し、目的の Exchange サーバーを展開します。次に、[プロトコル] を展開して [SMTP] を展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] タブをクリックし、[詳細設定] をクリックします。

    • DNS 逆引き参照を有効にするには、[受信メッセージで DNS 逆引き参照を実行する] チェック ボックスをオンにします。

    • DNS 逆引き参照を無効にするには、[受信メッセージで DNS 逆引き参照を実行する] チェック ボックスをオフにします。

  5. [OK] をクリックして変更を保存したら、[OK] をクリックしてSMTP 仮想サーバーのプロパティ ダイアログ ボックスを閉じます。

Exchange の DNS 逆引き参照機能の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686 の [XADM] SMTP サービスの構成方法 (第 1 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163 の [XADM] SMTP サービスの構成方法 (第 2 部) に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)


SP1 バージョンのインテリジェント メッセージ フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、Microsoft Exchange インテリジェント メッセージ フィルタがサーバーにインストールされ、有効になっているかどうかを判断します。

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter

Exchange Server アナライザは、ContentFilter レジストリ キーの ContentFilterBindings 値を読み取り、サーバーにインテリジェント メッセージ フィルタがインストールされ、有効になっているかどうかを判断します。

次に、Exchange Server アナライザは、CIM_Datafile Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、Exchange Server 上の次のパスに、Exchange Server 2003 Service Pack 1 (SP1) バージョンのインテリジェント メッセージ フィルタの MSExchange.UceContentFilter.dll が存在するかどうかを判断します。

<Exchange サーバー バイナリ ファイルへのパス>\MSCFv1\MSExchange.UceContentFilter.dll

注 :
このパスの <Exchange サーバー バイナリ ファイルへのパス> は、bin フォルダの場所を指しています。

Exchange Server 2003 SP1 バージョンのインテリジェント メッセージ フィルタがサーバー上にインストールされ有効になっている場合は、警告が表示されます。

この警告は、最新バージョンのインテリジェント メッセージ フィルタが提供されていることを示します。最新バージョンのインテリジェント メッセージ フィルタをインストールすることをお勧めします。このサーバーに関連するメール フローの問題をトラブルシューティングする場合は、一時的にインテリジェント メッセージ フィルタを無効にして、正当なメールが誤ってブロックされていないかどうかを判断する必要があります。

インテリジェント メッセージ フィルタを無効にするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. Exchange システム マネージャで、[サーバー]、[サーバー名]、[プロトコル]、[SMTP] の順に展開し、[インテリジェント メッセージ フィルタ] を右クリックして、[プロパティ] をクリックします。

  3. [全般] タブの [以下の IP アドレスを持つ仮想サーバーにインテリジェント メッセージ フィルタを適用します] の下で、インテリジェント メッセージ フィルタを無効にする各 SMTP 仮想サーバーの横にあるチェック ボックスをオフにします。

    [インテリジェント メッセージ フィルタのプロパティ] ダイアログ ボックス

詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


SP2 バージョンのインテリジェント メッセージ フィルタが有効になっている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-04

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバー オブジェクトの msExchServerBindingsFiltering プロパティが、SMTP 仮想サーバー インスタンスに対してインテリジェント メッセージ フィルタが有効になっていることを示しているかどうかを判断します。

また、Active Directory に対してもクエリを実行し、msExchUceEnabled がグローバル設定のレベルで有効になっているかどうかを判断します。

Exchange Server アナライザ ツールは、以下の条件に当てはまる場合に、警告を表示します。

  • SMTP 仮想サーバー インスタンスに対してインテリジェント メッセージ フィルタが有効になっている。

  • インテリジェント メッセージ フィルタがグローバル設定のレベルで有効になっている。

この警告は、Exchange Server 2003 Service Pack 2 (SP2) バージョンのインテリジェント メッセージ フィルタが有効になっていることを示します。SP2 バージョンのインテリジェント メッセージ フィルタが有効になっている状態は通常、この特定のサーバーに関連するメール フローの問題をトラブルシューティングしているのでなければ問題にはなりません。トラブルシューティングを行っている場合は、フィルタ構成を確認するか、インテリジェント メッセージ フィルタを一時的に無効にし、正当なメールが不適切にブロックされているかどうかを判断します。

インテリジェント メッセージ フィルタを無効にするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. Exchange システム マネージャで、[サーバー] を展開し、[サーバー名] を展開します。次に、[プロトコル] を展開し、[SMTP] を展開します。

  3. [SMTP 仮想サーバー のプロパティ] ダイアログ ボックスで、[全般] タブの [詳細設定] をクリックします。

  4. インテリジェント メッセージ フィルタを無効にする IP アドレスを選択し、[編集] をクリックします。

  5. [識別] で、[インテリジェント メッセージ フィルタを適用する] チェック ボックスをオフにします。

  6. 仮想サーバーが複数ある場合は、インテリジェント メッセージ フィルタを無効にするサーバーごとに手順 3. ～ 6. を繰り返します。

詳細については、Exchange インテリジェント メッセージ フィルタについてのページ (http://go.microsoft.com/fwlink/?LinkId=21607) を参照してください (このサイトは英語の場合があります)。


指定したゲートウェイ サーバーが使用されていない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-09

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーからユーザー定義外部アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンして、テスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは、外部受信者にメッセージをルーティングするために使用する Exchange ゲートウェイ サーバーがサーバー名と資格情報手順の [サーバーとユーザー情報の入力] ページのユーザーが指定したサーバーと同じかどうかを確認します。

Exchange Server アナライザが、メッセージは Exchange 組織の外部に正常にルーティングされたが、指定したゲートウェイ サーバーが使用されなかったと判断した場合、Exchange Server アナライザは警告を表示します。

この警告は、Exchange のルーティング トポロジに問題がある可能性があり、不明な送信ゲートウェイ サーバーが存在することを示します。

スマート ホスト エントリがコネクタ レベルではなく、仮想サーバー レベルに設定されている場合、ルーティングの問題が発生する可能性があります。推奨されるベスト プラクティスは、スマート ホスト エントリを SMTP コネクタ上に設定し、SMTP 仮想サーバー上には設定しないことです。

この警告をトラブルシューティングするには、次の操作を行います。

  • SMTP (Simple Mail Transfer Protocol) 仮想サーバーの構成を調べて、スマート ホスト エントリが設定されていないことを確認します。

  • ローカル ブリッジヘッド サーバーの構成を調べて、コネクタのアドレス空間とコストが適切であることを確認します。

スマート ホストの設定を表示して構成するには

  1. Exchange システム マネージャを起動します。

  2. [サーバー]、目的の Exchange サーバー、[プロトコル]、[SMTP] の順に展開します。

  3. SMTP 仮想サーバー (たとえば、[既定の SMTP 仮想サーバー]) を右クリックし、[プロパティ] をクリックします。

  4. [配信] タブ、[詳細設定] の順にクリックします。

  5. [スマート ホスト] にあるエントリを消去します。

  6. [OK] をクリックして変更を保存し、もう一度 [OK] をクリックして SMTP 仮想サーバーの [プロパティ] ダイアログ ボックスを閉じます。

SMTP コネクタを構成する方法の詳細については、マイクロソフト サポート技術情報の文書番号 822941 の、ルーティングに接続するために、SMTP コネクタを使用する方法が Exchange 2003 でグループ化する現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=822941) を参照してください。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?linkid=67875)。

  • マイクロソフト サポート技術情報の文書番号 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)。


異なるサーバー上に送信者が指定されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスの proxyAddress 属性値に対してクエリを実行し、すべてのユーザー オブジェクトがユーザー指定のローカル送信者の SMTP (Simple Mail Transfer Protocol) アドレスと一致するかどうかを判断します。

ユーザー オブジェクトの proxyAddress との一致が見つかった場合、Exchange Server アナライザは、Active Directory のユーザー オブジェクトの msExchHomeServerName 属性値に対してクエリを実行し、値がユーザー指定の Exchange Server の名前に一致するかどうかを判断します。

Exchange Server アナライザが、ユーザー指定の送信者の msExchHomeServerName 属性の値がユーザー指定の Exchange Server の名前と一致しないと判断した場合、Exchange Server アナライザは警告を表示します。

この警告は、誤った Exchange Server 名が含まれているか、またはメール フローの問題がユーザーが指定したサーバー以外のサーバーに影響を与えていることを示します。

この問題を修正するには、正しい Exchange Server 名が入力されていることを確認します。

指定したサーバーのユーザーのメールボックスを表示するには

  1. Exchange システム マネージャを起動します。

    [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. [Exchange システム マネージャ] で、次のコンテナに移動して、クリックします。

    \Administrative Groups\ GroupName \Servers\ ServerName \ StorageGroupName \Mailbox Store\Mailboxes

  3. 指定したユーザーのメールボックスが指定した Exchange サーバーに表示されることを確認します。


ターゲットの宛先サーバーを識別できない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、リモート配信キュー内のメールが配信されるリモート サーバーの完全修飾ドメイン名 (FQDN)、IP アドレス、およびドメイン名を特定し、それらの一覧を作成します。

リモート サーバーの FQDN、IP アドレス、およびドメイン名の一覧は、次のように作成されます。

  • 簡易メール転送プロトコル (SMTP) 仮想サーバーの Active Directory® ディレクトリ サービス オブジェクトの msExchSmtpFullyQualifiedDomainName プロパティに対して、クエリが実行されます。

    注 :
    msExchSmtpFullyQualifiedDomainName プロパティは、指定されたターゲット ブリッジヘッド サーバーでルーティング グループ コネクタ ディレクトリ オブジェクトの msExchTargetBridgeheadServersDN プロパティに対してクエリが実行されると、このプロパティから読み取られます。
  • SMTP コネクタ Active Directory オブジェクトの msExchSmtpSmartHost プロパティに対して、SMTP コネクタの指定されたスマート ホストに関するクエリが実行されます。

  • Microsoft Windows® Management Instrumentation (WMI) クラス ExchangeLink の LinkName プロパティに対して、リモート サーバーの直接接続があるかどうかを問い合わせるクエリが実行されます。

この一覧を作成しようとしてエントリがないことが検出されると、エラーが表示されます。

このエラーは次のことを示します。

  • メールの流れに関する問題の原因となる、ネットワークまたは Active Directory の断続的な接続の問題が発生している可能性がある。

  • Exchange Server アナライザを実行するアカウントが、この情報のクエリを実行するための十分なアクセス許可を持っていない可能性がある。

このエラーを修正するには、次の操作を行います。

  1. Exchange Server コンピュータが起動され、ネットワークに接続されていることを確認します。

  2. Active Directory ドメイン コントローラにネットワーク接続できるかどうかを確認します。

  3. Exchange Server アナライザで Active Directory ドメイン コントローラを指定します。

  4. PING コマンドを使用して、Exchange Server コンピュータにアクセスできるかどうかを確認します。

  5. ファイアウォールがある場合は、RPC ポートがブロックされているかどうかを確認します。

  6. Exchange Server アナライザの実行に使用されるアカウントのアクセス許可を調べます。Exchange Server アナライザの実行に使用するアカウントは、スキャン対象の各 Exchange Server コンピュータで、ローカルの Administrator アクセス許可を持っている必要があります。

ネットワークの接続に関する問題の詳細については、Microsoft サポート技術情報の文書番号 325487「ネットワーク接続の問題のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325487) を参照してください。

Exchange Server アナライザの接続に関する問題の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールの接続に関する問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=56285) を参照してください (このサイトは英語の場合があります)。

ポート要件の詳細については、Microsoft サポート技術情報の文書番号 832017「Microsoft Windows サーバー システムのポート要件」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=832017) を参照してください。


TarpitTime が実装されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-02-21

Microsoft® Exchange Server アナライザ ツールは、次のレジストリ エントリを読み取り、受信者フィルタのタール ピット機能が設定されているかどうかを判断します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSvc\Parameters\TarpitTime

TarpitTime の値が 0 より大きい値に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

タール ピット機能は、正当でない接続を意図的に遅延させることで、自動化されたスパムの送信率や辞書ハーベスト攻撃の実行率を低減する方法です。

Microsoft Windows Server™ 2003 Service Pack 1 (SP1) で利用できるタール ピット機能は、マイクロソフト サポート技術情報の文書番号 842851「Microsoft Windows Server 2003 の SMTP タール ピット機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=842851) で説明されているように、受信者フィルタ機能と組み合わせて使用することができます。具体的には、[グローバル設定] の [受信者のフィルタ] タブで [ディレクトリに存在しない受信者にフィルタを適用する] チェック ボックスがオンになっているときに、タール ピット機能により受信者フィルタの効果が強化されます。

タール ピット機能は、TarpitTime レジストリ サブキーを設定することで実装されます。TarpitTime レジストリ サブキーには 10 進数の値を使用します。この 10 進数の値は、受信者が対象の Exchange Server 組織に存在しない場合に、SMTP セッションが送信者に応答するまでに待機する秒数を表します。

タール ピット機能により、迷惑メールを送信するスパム業者はディレクトリ ハーベスト攻撃を自動化することがはるかに困難になります。ディレクトリ ハーベスト攻撃は、特定の組織から有効な電子メール アドレスの一覧を抽出しようとする試みです。

SMTP プロトコルは、SMTP セッション中に "2.1.5 Recipient OK" を返すことで、受け入れ可能な受信者を確認します。不明な受信者にメールが送信される場合、SMTP プロトコルは "5.x.x" エラーを返します。このため、スパム業者は、一般的な名前や辞書にある単語を使用して、特定のドメインへの電子メール アドレスを構築する自動化プログラムを作成できます。プログラムは、"2.1.5 Recipient OK" を返す電子メール アドレスをすべて収集し、"5.x.x" エラーを引き起こす電子メール アドレスをすべて破棄します。スパム業者は、収集した "有効な" 電子メール アドレスを販売したり、迷惑メールの受信者として使用することができます。

[ディレクトリに存在しない受信者にフィルタを適用する] チェック ボックスはオンになっているが、TarpitTime レジストリ サブキーが設定されていない場合、受信者が Active Directory® ディレクトリ サービスに存在しないとき、Exchange Server は SMTP セッション中に直ちに送信者に "5.x.x" エラーを返します。

TarpitTime レジストリ サブキーが設定されていて、[ディレクトリに存在しない受信者にフィルタを適用する] チェック ボックスがオンの場合は、"5.x.x" エラーを返すまでに SMTP が一定時間待機します。TarpitTime レジストリ サブキーに入力された 10 進数の値が、SMTP がエラーを返すまでに待機する秒数です。SMTP セッションを一時停止することにより、ディレクトリ ハーベスト攻撃を自動化することがはるかに難しくなります。

既に説明したように、TarpitTime レジストリ サブキーが設定されている場合、Exchange Server アナライザによって、既定以外の構成であることを示すメッセージが表示されます。このメッセージは、情報提供のみを目的としています。

重要 :
この文書には、レジストリの編集に関する情報が含まれています。レジストリを編集するには、問題発生時にレジストリを復元する方法を理解している必要があります。レジストリの復元方法の詳細については、Regedit.exe または Regedt32.exe のヘルプで、「レジストリを復元する」を参照してください。
TarpitTime レジストリ サブキーを表示または変更するには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスに「regedit」と入力し、[OK] をクリックします。

  2. 次のレジストリ サブキーを探してクリックします。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters\TarpitTime

  3. [値のデータ] ボックスには 10 進数が含まれています。この値は、Active Directory に存在しない各アドレスに対する SMTP アドレスの確認応答を遅延させる秒数です。

  4. TarpitTime レジストリ サブキーの値を変更したり、サブキーを削除した場合は、SMTP (簡易メール転送プロトコル) サービスを再開する必要があります。

詳細については、マイクロソフト サポート技術情報の文書番号 842851「Microsoft Windows Server 2003 の SMTP タール ピット機能」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=842851) を参照してください。


テスト メールで NDR が生成される
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリが作成された原因を判断します。

Exchange Server アナライザ ツールによって EntryType プロパティの値が 1030 であることが検出されると、警告が表示されます。

この警告は、テスト メッセージによって配信不能レポート (NDR) が生成されており、サーバーの SMTP (Simple Mail Transfer Protocol) の構成に問題がある可能性を示しています。NDR は一般に、対象の受信者が存在しない場合に生成されますが、テスト メッセージを正当な受信者に送信したときに生成された場合は問題があります。

トラブルシューティングの手順として、同じ受信者に別のメッセージを送信してみて、その NDR を確認することにより問題の原因を判断する方法があります。

NDR をトラブルシューティングする方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、NDR のトラブルシューティングに関するセクションを参照してください (このサイトは英語の場合があります)。


テスト メールが不正メール ディレクトリに送信された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-05-17

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリの原因を判断します。

Exchange Server アナライザによって EntryType プロパティの値が 1021 であることが検出されると、警告が表示されます。

この警告は、テスト メッセージが Exchange サーバーの不正メール ディレクトリに送信されており、サーバーの SMTP (Simple Mail Transfer Protocol) 構成に問題があることを示しています。

メールが不正メール ディレクトリに送信される原因は次のいずれかです。

  • 配信不可能である。

  • 再試行の最大回数を超えた。

  • 配信不能として送信者に返すことができない。

送信メールの流れをテストする方法の詳細については、Microsoft サポート技術情報の文書番号 297700「Pickup フォルダのファイルを使用して送信メールの流れをテストする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297700) を参照してください。

メールの流れと SMTP の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) の、メールの流れと SMTP のトラブルシューティングに関するセクションを参照してください (このサイトは英語の場合があります)。


SMTP キューに存在するテスト メッセージ
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-06

Microsoft® Exchange Server アナライザ ツールは、Exchange サーバーから SMTP (Simple Mail Transfer Protocol) ドメインのポストマスタ アカウントまたはユーザー定義アカウントにテスト メッセージを送信した後、サーバーのメッセージ追跡ログをスキャンしてテスト メッセージの配信に問題が発生していないかどうかを判断します。

このスキャンの一環として、Exchange Server アナライザは root\MicrosoftExchangeV2 名前空間内の Exchange_MessageTrackingEntry Microsoft WMI (Windows® Management Instrumentation) クラスの EntryType プロパティに対してクエリを実行し、メッセージ追跡ログ エントリが作成された原因を判断します。

以下の表は、返される EntryType 値の一覧です。

値の名前 | 値
X400 でメッセージが受信されました | 0
レポートが受信されました | 2
メッセージが発信されました | 4
メッセージが送信転送されました | 7
レポートが送信転送されました | 8
メッセージが配信されました | 9
レポートが配信されました | 10
配布リストが展開されました | 26
メッセージが着信転送されました | 28
メッセージが再ルーティングされました | 29
MTA によってサーバーがダウングレードされました | 31
レポートを集約しました | 33
レポートが生成されました | 34
ルーティング不能のレポートが破棄されました | 43
管理者によって削除されたメッセージ | 50
管理者によって削除された検索結果 | 51
管理者によって削除されたレポート | 52
メッセージがローカル配信されました | 1000
バックボーンを介してメッセージが受信転送されました | 1001
バックボーンを介してメッセージが送信転送されました | 1002
ゲートウェイを介してメッセージが送信転送されました | 1003
ゲートウェイを介してメッセージが受信転送されました | 1004
ゲートウェイを介してレポートが受信転送されました | 1005
ゲートウェイを介してレポートが送信転送されました | 1006
レポートが生成されました | 1007
SMTP : メッセージが送信キューに入れられました | 1010
SMTP : メッセージを送信転送しました | 1011
SMTP : 着信メッセージを受信しました | 1012
SMTP : 着信メッセージを転送しました | 1013
SMTP : メッセージが再ルーティングされました | 1014
SMTP : レポートが受信転送されました | 1015
SMTP : レポートが送信転送されました | 1016
SMTP : レポートが生成されました | 1017
SMTP : レポートを集約しました | 1018
SMTP : アドバンスド キューにメッセージが発信されました | 1019
SMTP : メッセージの送信転送を開始しました | 1020
SMTP : 不正メール ディレクトリにメッセージが送信されました | 1021
SMTP : アドバンスド キューのエラー | 1022
SMTP : メッセージがローカル配信されました | 1023
SMTP : カテゴライザにメッセージが発信されました | 1024
SMTP : アドバンスド キューへのメッセージの発信を開始しました | 1025
SMTP : アドバンスド キューによるメッセージの配信に失敗しました | 1026
SMTP ストア ドライバ : ストアからメッセージが発信されました | 1027
SMTP ストア ドライバ : メッセージはストアにローカル配信されました | 1028
SMTP ストア ドライバ : メッセージは MTA に発信されました | 1029
SMTP : 配信不能レポート (NDR) が生成されました | 1030
SMTP : メッセージが送信転送されました | 1031

返された EntryType 値が以下の状況に当てはまる場合は、Exchange Server アナライザによってエラーが表示されます。

  • テスト メッセージ追跡ログを正常にスキャンできる場合

  • テスト メッセージがキューから正常に転送されなかった場合

  • テスト メッセージに配信不能レポート (NDR) が生成されなかった場合

  • テスト メッセージが不正メール ディレクトリに転送されなかった場合

  • テスト メッセージがリモート配信のキューに入れられない場合

  • テスト メッセージがローカル ストアに正常に配信されなかった場合

  • テスト メッセージの分類の再試行がスケジュールされていない場合

  • テスト メッセージのルーティングの再試行がスケジュールされていない場合

  • テスト メッセージのローカル配信がスケジュールされていない場合

このエラーは、テスト メッセージが SMTP キューのいずれかに存在すること、およびそこに停滞している原因を判定するには詳細分析が必要であることを意味します。

このエラーを解決するには、NSlookup ユーティリティを使用して、ドメイン ネーム システム (DNS) の解決に関する問題がないかどうかを確認します。ホスト到達不能エラーなどの接続やプロトコルの問題については、Telnet.exe を使用して宛先コンピュータへの接続を試みてください。プロトコル エラーをトラブルシューティングするには、SMTP コンポーネントの MSExchangeTransport サービスの診断ログを増やし、エラーのログを確認します。あるいは、ネットワーク モニタ (Netmon.exe) ツールを使用して、ネットワーク接続エラーに関する情報を取得することもできます。問題を再現するために、キューにメッセージを入れてもう一度試してみる作業が必要になる場合があります。イベント ログを調べて、Microsoft Exchange Information Store サービスに関連するエラーがないかどうかを確認してください。

ログの設定を変更する方法の詳細については、Exchange Server トランスポートおよびルーティング ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47579) のメール フローと SMTP のトラブルシューティングのセクションにある、MSExchangeTransport のログ設定を変更する方法に関する記述を参照してください (このサイトは英語の場合があります)。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • 「Exchange Server トランスポートおよびルーティング ガイド」(http://go.microsoft.com/fwlink/?linkid=47579) の、メール フローと SMTP のトラブルシューティングに関するセクション

  • Microsoft サポート技術情報の文書番号 823489「キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

  • Microsoft サポート技術情報の文書番号 821877「SMTP と X.400 キューのプロパティ タブでフィールドの説明」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=821877)

  • Microsoft サポート技術情報の文書番号 264054「[XCON] Exchange 2000 サーバーのキュー状態の理解」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=264054)


ルーティング グループのコネクタ数が 900 を超えている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、特定のルーティング グループに存在するコネクタの数を判断します。これには、SMTP コネクタ、ルーティング グループ コネクタ、X.400 コネクタ、EDK コネクタも含まれます。単一のルーティング グループに存在するコネクタの総数が 900 を超えていることが検出されると、警告が表示されます。

どの種類の Exchange オブジェクトについても、1 つの種類についてインスタンスの数は最大 900 とすることをお勧めします。これは、Active Directory で任意の要求に対して返される最大ページ サイズの既定値が 1,000 であるためです。つまり、あるオブジェクトに対してライトウェイト ディレクトリ アクセス プロトコル (LDAP) 要求が実行され、Active Directory 内でそのオブジェクトのインスタンスの数が 1,000 を超えている場合、最大ページ サイズを超過するために結果が返されなくなります。

Exchange Server の場合、ある種類のオブジェクトについてさまざまなプロセスからインスタンスの作成が要求されます。たとえば、Exchange システム マネージャは Active Directory に対して LDAP 要求を実行し、ルーティング グループ内のコネクタすべての一覧を作成します。いずれかのルーティング グループに 1,000 を超えるコネクタが存在すると、Active Directory はクエリの結果を返しません。この状況が発生すると、Exchange システム マネージャにエラーが表示されます。

Active Directory の最大ページ サイズの値を増やすことはできますが、この操作は Exchange Server で推奨されず、サポートされていません。最大ページ サイズの値を増やした Exchange 環境では、奇妙な動作や障害が報告されています。

Exchange Server で単一の種類のオブジェクトについて推奨される数は 900 以下ですが、オブジェクトの種類は 1,000 までサポートされています。

この警告を修正するには

  1. コネクタを統合するか、または追加のルーティング グループを作成して、それらの間で既存のコネクタを負荷分散することを検討します。

  2. Active Directory に切り離されたコネクタがないかを調べて、Active Directory から削除します。

  3. 組織内の Exchange サーバーを統合することを検討します。

ルーティング グループの設計とコネクタの詳細については、『Exchange Server Transport and Routing Guide』(http://go.microsoft.com/fwlink/?LinkId=47579) を参照してください (このサイトは英語の場合があります)。

Exchange サーバーの統合の詳細については、「Exchange Server 2003 Server Consolidation」(http://go.microsoft.com/fwlink/?linkid=47586) を参照してください (このサイトは英語の場合があります)。


Active Directory とメタベースの間で完全修飾ドメイン名の設定が一致しない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2007-01-17

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの次のプロパティを読み取り、その値が Active Directory® ディレクトリ サービスの msExchSmtpFullyQualifiedDomainName 属性の構成値と一致するかどうかを判断します。

/LM/SmtpSvc/<SMTP virtual server instance>/FullyQualifiedDomainName

2 つの属性の値が一致しないことが検出されると、警告メッセージが表示されます。

IIS メタベースの値が Active Directory の値と一致しない場合は、Exchange 内で Active Directory のレプリケーションに問題が発生しているか、またはディレクトリ サービスからメタベースへのレプリケーション (DS2MB) に問題が発生していることを示している可能性があります。

DS2MB プロセスの機能は、構成情報を Active Directory からローカルのメタベースに転送することです。パフォーマンスとスケーラビリティの理由から、この構成はレジストリではなくローカル メタベースに格納されます。Exchange 2000 Server および Exchange Server 2003 では、すべてのインターネット プロトコル (SMTP、NNTP、POP3、IMAP4、および HTTP) が IIS のコンポーネントとして実行されます。

DS2MB プロセスは 15 分ごとに、サブツリー全体をその形状を変えずに Active Directory からコピーします。この処理は、Active Directory からメタベースへの一方的な書き込みであり、メタベースから Active Directory への書き込みはありません。

FullyQualifiedDomainName プロパティおよび msExchSmtpFullyQualifiedDomainName 属性は、Exchange サーバーの完全修飾ドメイン名 (server.domain.com など) に対応する既定のサーバー名を使用します。FullyQualifiedDomainName プロパティの値と msExchSmtpFullyQualifiedDomainName 属性値が同じ完全修飾ドメイン名ではない場合は、Active Directory と IIS メタベースが同期していないことを意味します。問題が DS2MB プロセスのエラーのために発生している場合は、実行している Exchange Server のバージョンに対応する以下の手順に従って、問題を修正することができます。Active Directory レプリケーションの一部のエラーまたは完全なエラーのために問題が発生している場合は、Active Directory レプリケーション モニタ ユーティリティ (ReplMon.exe) を使用して、Active Directory レプリケーションの状態を確認できます。ReplMon.exe は、Windows Server™ 2003 CD-ROM の Microsoft Windows® サポート ツールに含まれています。

Exchange Server 2003 でこの警告を修正するには

  1. ソースが MSExchangeMU のアプリケーション イベント ログ エントリが存在するかどうかを確認します。DS2MB は、エラーが発生すると、Exchange Server 2003 でイベントをログ出力します。

  2. DS2MB のエラーが見つからない場合は、ReplMon を使用して Active Directory レプリケーションを診断します。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  3. DS2MB のエラーが見つかった場合、または Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange 2000 Server でこの警告を修正するには

  1. ReplMon を使用して、Active Directory レプリケーションを診断します。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  2. Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange の DNS 逆引き参照機能の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、Microsoft サポート技術情報の文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686) および文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163) を参照してください。

Active Directory レプリケーションの詳細については、Microsoft サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

DS2MB プロセスの詳細については、Microsoft サポート技術情報の文書番号 240105「[XGEN] Exchange 2000 Server のディレクトリ サービス/メタベース同期に関する概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105) を参照してください。


Active Directory とメタベースの間で最大ホップ数の設定が一致しない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの次のプロパティを読み取り、その値が Active Directory® ディレクトリ サービスの msExchSmtpMaxHopCount 属性の構成値と一致するかどうかを判断します。

/LM/SmtpSvc/<SMTP virtual server instance>/HopCount

これらの値が一致しないことが検出されると、警告が表示されます。

IIS メタベースの値が Active Directory の値と一致しない場合は、Exchange 内で Active Directory のレプリケーションに問題が発生しているか、またはディレクトリ サービスからメタベースへのレプリケーション (DS2MB) に問題が発生していることを示している可能性があります。

DS2MB プロセスの機能は、構成情報を Active Directory からローカルのメタベースに転送することです。パフォーマンスとスケーラビリティの理由から、この構成はレジストリではなくローカル メタベースに格納されます。Exchange 2000 Server および Exchange Server 2003 では、すべてのインターネット プロトコル (SMTP、NNTP、POP3、IMAP4、および HTTP) が IIS のコンポーネントとして実行されます。

DS2MB プロセスは 15 分ごとに、サブツリー全体をその形状を変えずに Active Directory からコピーします。この処理は、Active Directory からメタベースへの一方的な書き込みであり、メタベースから Active Directory への書き込みはありません。

Exchange 2000 Server の SMTP 仮想サーバーでは、既定のホップ数は 15 です。Exchange Server 2003 の SMTP 仮想サーバーでは、既定のホップ数は 30 です。構成されている値にかかわらず、HopCount プロパティと msExchSmtpMaxHopCount 属性が一致しない場合は、Active Directory と IIS メタベースが同期していないことを意味します。問題が DS2MB プロセスのエラーのために発生している場合は、実行している Exchange Server のバージョンに対応する以下の手順に従って、問題を修正することができます。Active Directory レプリケーションの一部のエラーまたは完全なエラーのために問題が発生している場合は、Active Directory レプリケーション モニタ ユーティリティ (ReplMon.exe) を使用して、Active Directory レプリケーションの状態を確認できます。ReplMon.exe は、Windows Server™ 2003 CD-ROM の Microsoft Windows® サポート ツールに含まれています。

Exchange Server 2003 でこのエラーを修正するには

  1. ソースが MSExchangeMU のアプリケーション イベント ログ エントリが存在するかどうかを確認します。DS2MB は、エラーが発生すると、Exchange Server 2003 でイベントをログ出力します。

  2. DS2MB のエラーが見つからない場合は、ReplMon を使用して Active Directory レプリケーションの診断を行います。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  3. DS2MB のエラーが見つかった場合、または Active Directory レプリケーションの問題を除去または解決した後で、Exchange System Attendant サービスを再開します。

Exchange 2000 Server でこのエラー修正するには

  1. ReplMon を使用して、Active Directory レプリケーションの診断を行います。SMTP 仮想サーバーによって使用されているグローバル カタログ サーバーに特に注意してください。

  2. Active Directory レプリケーションの問題を除去または解決した後で、Exchange System Attendant サービスを再開します。

Exchange の DNS 逆引き参照機能の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

Active Directory レプリケーションの詳細については、Microsoft サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

DS2MB プロセスの詳細については、Microsoft サポート技術情報の文書番号 240105「[XGEN] Exchange 2000 Server のディレクトリ サービス/メタベース同期に関する概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105) を参照してください。


Active Directory とメタベースの間で最大メッセージ サイズの設定が一致しない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの次のプロパティを読み取り、その値が Active Directory™ ディレクトリ サービスの msExchSmtpMaxMessageSize 属性の構成値と一致するかどうかを判断します。

/LM/SmtpSvc/<SMTP 仮想サーバー インスタンス>/MaxMessageSize

これらの値が一致しないことが検出されると、警告が表示されます。

IIS メタベースの値が Active Directory の値と一致しない場合は、Exchange 内で Active Directory のレプリケーションに問題が発生しているか、またはディレクトリ サービスからメタベースへのレプリケーション (DS2MB) に問題が発生していることを示している可能性があります。

DS2MB プロセスの機能は、構成情報を Active Directory からローカル メタベースに転送することです。この構成は、パフォーマンスやスケーラビリティ上の理由から、レジストリではなくローカル メタベースに格納されます。Exchange 2000 Server と Exchange Server 2003 では、すべてのインターネット プロトコル (SMTP、NNTP、POP3、IMAP4、および HTTP) は IIS のコンポーネントとして実行されます。

DS2MB プロセスは、15 分ごとに、サブツリー全体を Active Directory からその形状を変えずにコピーします。この処理は Active Directory からメタベースへの一方向の書き込みであり、メタベースから Active Directory への書き込みはありません。

MaxMessageSize プロパティと msExchSmtpMaxMessageSize 属性のどちらも、既定の設定である 0 を使用しています。これは、メッセージ サイズの制限がないことを意味します。MaxMessageSize プロパティと msExchSmtpMaxMessageSize 属性値が異なる場合は、Active Directory と IIS メタベースが同期していないことを意味します。問題が DS2MB プロセスの失敗により発生している場合は、実行している Exchange Server のバージョンに対応した以下の手順に従うことにより問題を解決できます。問題が Active Directory のレプリケーションの部分的または完全な失敗により発生している場合は、Active Directory レプリケーション モニタ ユーティリティ (ReplMon.exe) を使用して Active Directory のレプリケーションの状態を確認できます。ReplMon.exe は、Windows Server™ 2003 CD-ROM の Microsoft Windows® サポート ツールに含まれています。

Exchange Server 2003 でこのエラーを修正するには

  1. MSExchangeMU のソースに、アプリケーション イベント ログ エントリが存在するかどうかを確認します。DS2MB は、エラーが発生すると、Exchange Server 2003 でイベントをログ出力します。

  2. DS2MB の失敗が表示されていない場合は、ReplMon を使用して Active Directory レプリケーションを診断します。SMTP 仮想サーバーで使用されているグローバル カタログ サーバーには、特に注意してください。

  3. DS2MB の失敗が表示されている場合、または Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange 2000 Server でこのエラーを修正するには

  1. ReplMon を使用して、Active Directory レプリケーションを診断します。SMTP 仮想サーバーで使用されているグローバル カタログ サーバーには、特に注意してください。

  2. Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange の DNS 逆引き参照の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 268163, "XCON:文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

Active Directory レプリケーションの詳細については、サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

DS2MB プロセスの詳細については、サポート技術情報の文書番号 240105「[XGEN] Exchange 2000 Server のディレクトリ サービス/メタベース同期に関する概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105) を参照してください。


Active Directory とメタベースの間で最大セッション サイズの設定が一致しない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、インターネット インフォメーション サービス (IIS) メタベースの /LM/SmtpSvc/<SMTP virtual server instance>/MaxSessionSize プロパティを読み取り、その値が Active Directory® ディレクトリ サービスの msExchSmtpMaxSessionSize 属性の構成値と一致するかどうかを判断します。

これらの値が一致しないことが検出されると、警告メッセージが表示されます。

IIS メタベースの値が Active Directory の値と一致しない場合は、Exchange 内で Active Directory のレプリケーションに問題が発生しているか、またはディレクトリ サービスからメタベースへのレプリケーション (DS2MB) コンポー ネントに問題が発生していることを示している可能性があります。

DS2MB プロセスの機能は、構成情報を Active Directory からローカル メタベースに転送することです。この構成は、パフォーマンスやスケーラビリティ上の理由から、レジストリではなくローカル メタベースに格納されます。Exchange 2000 Server と Exchange Server 2003 では、すべてのインターネット プロトコル (SMTP、NNTP、POP3、IMAP4、および HTTP) は IIS のコンポーネントとして実行されます。

DS2MB プロセスは、15 分ごとに、サブツリー全体を Active Directory からその形状を変えずにコピーします。この処理は Active Directory からメタベースへの一方向の書き込みであり、メタベースから Active Directory への書き込みはありません。

MaxSessionSize プロパティと msExchSmtpMaxSessionSize 属性はどちらも、既定の設定である 0 を使用しています。これは、メッセージ サイズの制限がないことを意味します。MaxSessionSize プロパティと msExchSmtpMaxSessionSize 属性値が異なる場合は、Active Directory と IIS メタベースが同期していないことを意味します。問題が DS2MB プロセスの失敗により発生している場合は、実行している Exchange Server のバージョンに対応した以下の手順に従うことにより問題を解決できます。問題が Active Directory のレプリケーションの部分的または完全な失敗により発生している場合は、Active Directory レプリケーション モニタ ユーティリティ (ReplMon.exe) を使用して Active Directory のレプリケーションの状態を確認できます。ReplMon は、Windows Server™ 2003 CD-ROM の Microsoft Windows® サポート ツールに含まれています。

Exchange Server 2003 でこのエラーを修正するには

  1. ソースが MSExchangeMU のアプリケーション イベント ログ エントリが存在するかどうかを確認します。DS2MB は、エラーが発生すると、Exchange Server 2003 でイベントをログ出力します。

  2. DS2MB の失敗が表示されていない場合は、ReplMon を使用して Active Directory レプリケーションを診断します。SMTP 仮想サーバーで使用されているグローバル カタログ サーバーには、特に注意してください。

  3. DS2MB の失敗が表示されている場合、または Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange 2000 Server でこのエラーを修正するには

  1. ReplMon を使用して、Active Directory レプリケーションを診断します。SMTP 仮想サーバーで使用されているグローバル カタログ サーバーには、特に注意してください。

  2. Active Directory のレプリケーションでの問題を解消または解決した後、Exchange System Attendant サービスを再開します。

Exchange の DNS 逆引き参照機能の詳細については、Microsoft サポート技術情報の文書番号 297412「[XCON] [受信メッセージで DNS 逆引き参照を実行する] オプションはホスト名解決に使用される」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=297412) を参照してください。

SMTP 仮想サーバーの設定の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 266686「[XADM] SMTP サービスの構成方法 (第 1 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=266686)

  • 文書番号 268163「[XADM] SMTP サービスの構成方法 (第 2 部)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=268163)

Active Directory レプリケーションの詳細については、Microsoft サポート技術情報の文書番号 232072「Active Directory ダイレクト複製パートナー間での複製の開始」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=232072) を参照してください。

DS2MB プロセスの詳細については、サポート技術情報の文書番号 240105「[XGEN] Exchange 2000 Server のディレクトリ サービス/メタベース同期に関する概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240105) を参照してください。


24 時間以内にトランスポート接続マネージャの警告イベントがログに記録された
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) クラスに対してクエリを実行し、MSExchangeTransport のイベント 4006 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

MSExchangeTransport のイベント 4006 警告が過去 24 時間以内にログに記録されていることが検出されると、警告が表示されます。

この警告は通常、リモート サーバーへのメール送信に失敗したことを示します。

MSExchangeTransport のイベント 4006 警告は、以下の状況が原因で発生することがあります。

  • リモート ホストによって接続が切断された。

  • リモートの SMTP (Simple Mail Transfer Protocol) サービスが AUTH ネゴシエーションを拒否した。

  • メッセージを配信しようとするサーバーがメッセージ内のメッセージ配信情報にアクセスできない。

  • SMTP エラーが発生した。

  • メッセージを配信しようとするサーバーがリモート サーバーに接続できない。

  • SMTP 仮想サーバーのプロパティで指定されたスマート ホストに何らかの理由で到達できない。

MSExchangeTransport のイベント 4006 警告の詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのメール中継に関する問題の詳細については、Microsoft サポート技術情報の文書番号 895853「Exchange Server 2003 と Exchange 2000 Server でのメール中継に関する問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853) を参照してください。

メールの流れと SMTP に関する問題の詳細については、『Exchange Server トランスポートおよびルーティング ガイド』(http://go.microsoft.com/fwlink/?LinkID=67875) の「メールの流れと SMTP に関するトラブルシューティング」を参照してください。


トランスポート接続マネージャの警告イベントが過去 24 時間以内にログに記録されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-07-07

Microsoft® Exchange Server アナライザ ツールは、Win32_NTLogEvent Microsoft Windows® Management Instrumentation (WMI) クラスに対してクエリを実行し、MSExchangeTransport のイベント 4001 警告が過去 24 時間以内にログに記録されていないかどうかを判断します。

MSExchangeTransport のイベント 4001 警告が過去 24 時間以内にログに記録されていることが検出されると、警告が表示されます。

この警告は通常、リモート サーバーへのメール送信に失敗したことを示します。

Exchange 2000 Server または Exchange Server 2003 の簡易メール転送プロトコル (SMTP) サービスにメール配信に関する問題が 1 つ以上ある場合、MSExchangeTransport のイベント 4001 警告が発生することがあります。メール配信に関する問題の原因として、ドメイン ネーム システム (DNS)、IP 構成、または正しくない DLL ファイルのインストールに関する問題が考えられます。

イベント 4001 警告の詳細については、イベントとエラーのメッセージについてのページ (http://go.microsoft.com/fwlink/?LinkId=34258) を参照してください (このサイトは英語の場合があります)。

Exchange Server でのメール中継に関する問題の詳細については、Microsoft サポート技術情報の文書番号 895853「Exchange Server 2003 と Exchange 2000 Server でのメール中継に関する問題のトラブルシューティング」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=895853) を参照してください。

メールの流れと SMTP に関する問題の詳細については、『Exchange Server トランスポートおよびルーティング ガイド』(http://go.microsoft.com/fwlink/?LinkID=67875) の「メールの流れと SMTP に関するトラブルシューティング」を参照してください。


トランスポート イベント シンクのファイルが見つからない
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-01-10

Microsoft® Exchange Server アナライザ ツールは、Microsoft Internet Information Service (IIS) メタベースに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) トランスポート イベント シンクのバインドの一覧を列挙します。Exchange Server アナライザは、前もって作成された以下の一覧に基づいて、いくつかの標準のイベント バインドの場所の特定を試みます。バインドごとに、Exchange Server アナライザは、次のブランチのレジストリにあるコンポーネント オブジェクト モデル (COM) 登録の詳細を確認します。

HKEY_CLASSES_ROOT\CLSID\

COM 登録の詳細は, .dll に関連付けられたファイルの完全なパスに含まれています。また、Exchange Server アナライザは Microsoft WMI （Windows® Management Instrumentation) を使用して, .dll ファイルの場所に移動し、そのバージョン番号を表示します。.dll ファイルを見つけられないと、見つからない .dll ファイルのファイル名とパスの詳細に関する警告が表示されます。

Exchange Server アナライザによって、1 つ以上の標準のイベント バインドが見つからないことが検出されると、警告が表示されます。

SMTP トランスポート イベントは SMTP サービスでメッセージ データが送受信されたときに発生します。したがって、すべてのメッセージがイベントによって処理されます。これらには、X.400 および RPC の送受信メッセージが含まれます。受信トランスポート イベントの一般的な例には、SMTP サービスにネットワーク経由でメッセージが送信されたときに発生するイベントや、SMTP ピックアップ ディレクトリに送信されたときに発生するイベントなどがあります。このトランスポート イベントが発生すると、このイベント ソースによってトランスポート イベント シンクに通知され、メッセージのデータの内容に基づいた動作が実行されます。メッセージ データをシンクに渡した後に、シンクがそのイベントを完了して返すまで、システムがメッセージ データを使用して別の動作を実行することはありません。シンクが動作しているときは、シンクでメッセージのデータや状態が排他的に制御されます。

トランスポート イベント シンクの COM 登録の見つからない .dll ファイルがメール フローの問題の原因になります。Exchange Server でメッセージがキューに入るなどのメール フローの問題の兆候が現れた場合は、識別された .dll ファイルの存在を確認し、必要に応じてそれらを再インストールします。

この問題を解決するには、次の操作を実行します。

  1. エクスプローラを使用して、識別された .dll ファイルを手動で見つけます。通常、このファイルは \Program Files\Exchsrvr\Bin フォルダにあります。

  2. 以下の条件に当てはまる場合は、Exchange Server アナライザによって表示される警告を無視して構いません。

    • .dll ファイルが一覧されたフォルダに存在する。

    • サーバーに、メール フローの問題の兆候がない。

  3. 以下の条件に当てはまる場合は、元の Exchange Server インストール メディアから見つからない .dll ファイルをコピーします。

    • Exchange Server アナライザが一覧表示したフォルダに .dll ファイルが存在しない。

    • サーバーに、メール フローの問題の兆候がある。

    あるいは、最新の Exchange Service Pack を再適用します。

  4. Exchange Server アナライザに戻り、警告が表示されないことを確認します。


リンク状態情報のユーザー バージョンの変更が抑制されている
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2005-11-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、heuristics 属性がリンク状態情報のユーザー バージョンの変更を抑制するように構成されているかどうかを判断します。既定では、heuristics 属性は構成されていません。Exchange Server アナライザによって、heuristics 属性が 2,048 に設定されていることが検出されると、既定以外の構成であることを示すメッセージが表示されます。

リンク状態テーブルは、効率的で信頼性の高いメッセージ ルーティングを保証するために使用されます。リンク状態テーブルには、各ルーティング グループのバージョン情報が、メジャー、マイナ、およびユーザー バージョン番号の形式で含まれています。メジャー バージョンの変更が最も優先度が高く、次にマイナ バージョンの変更、最後にユーザー バージョン番号の変更の順になります。

ユーザー バージョンの変更は、ベース レベルのディレクトリ サービスの更新が行われた場合に発生します。このような最小限の変更には、Exchange サーバーでサービスが開始または停止された場合、ルーティング グループに別のサービスが追加された場合、またはメンバ サーバーからルーティング グループ マスタへの接続が切断された場合の、ルーティング グループ マスタの変更が含まれます。

ベース レベルのディレクトリ サービスの更新は、Exchange Server 管理者がルーティング グループ レベルで何かを変更した場合に発生する可能性があります。たとえば、管理者がルーティング グループ名の変更や、サーバーの追加または削除を行うと、ユーザー バージョンの変更が発生します。ただし、ユーザー バージョンの変更の主な原因は、各サーバー内にある Microsoft WMI (Windows® Management Instrumentation) データです。このデータは、どのサービスが実行されているかを示しています。サービスを停止して開始すると、リンク状態テーブル内のユーザー バージョンの変更が、組織内のすべての Exchange Server コンピュータにレプリケートされます。

ユーザー バージョンの更新を頻繁に行うと、望ましくない大量のネットワーク トラフィックが発生する可能性があります。これを抑制するには、まず Microsoft 製品サポート サービスから修正プログラムを入手し、次に heuristics 属性を 2,048 (16 進数の 0x800) に設定します。

ユーザー バージョンの更新で過剰なネットワーク トラフィックが生成されていない場合は、ユーザー バージョンの更新を抑制しないようにすることをお勧めします。

既定の構成に戻すには

  1. Active Directory サービス インターフェイス (ADSI) Edit を起動します。

  2. ADSI Edit で、[Configuration] コンテナを展開し、[CN=Configuration]、[DC=<ドメイン名>]、[DC=com] の順に展開します。次に、[CN=Services] を展開し、[CN=Microsoft Exchange] を展開します。

  3. [CN=<組織名>] を右クリックし、[プロパティ] をクリックします。

  4. [Select a property to view] ボックスで、[Heuristics] をクリックします。

  5. [Edit Attribute] ボックスで、値 0x800 をクリアします。

  6. [Set] をクリックし、[OK] をクリックします。

  7. ADSI Edit を終了します。
注意 :
ADSI Edit、LDP (ldp.exe) ツール、またはその他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) Version 3 クライアントを使用する際に Active Directory オブジェクトの属性を誤って変更すると、重大な問題が発生する可能性があります。このような問題が発生すると、Microsoft Windows Server™ 2003 または Exchange Server 2003、あるいはその両方の再インストールが必要になる場合があります。Active Directory オブジェクトの属性の変更は、ご自身の責任で行ってください。

リンク状態およびユーザー バージョン番号の詳細については、『Technical Reference Guide for Exchange Server 2003』の「Link State Propagation」(http://go.microsoft.com/fwlink/?LinkId=49367) を参照してください (このサイトは英語の場合があります)。


共通の宛先として識別されたユーザー
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-09-06

Microsoft® Exchange Server アナライザ ツールは、WMI (Windows® Management Instrumentation) の Exchange_Queue クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) 仮想サーバーの SMTP キューの以下の属性の値を判断します。

LinkId | キューを含むリンクの識別子を示します。
QueueId | キューの識別子を示します。
QueueName | キューの名前を示します。
VirtualMachine | キューを含む仮想コンピュータの名前を示します。
VirtualServerName | このキューのある仮想サーバーの名前を示します。
MessageCount | キューに入っているメッセージの数を示します。

Exchange Server アナライザは、取得したこれらの情報を使用して、キューに入っているメッセージの以下の属性の値について、Exchange_QueuedSMTPMessage WMI クラスに対してクエリを実行します。

Recipients | メッセージの受信者を示します。
Received | メッセージの受信のタイム スタンプを示します。
MessageId | キューに入っているメッセージの識別子を示します。
StateRetry | 正常に配信されなかったメッセージの送信が再試行されていることを示します。

また、Exchange Server アナライザは、前述のクエリで取得したデータを使用して、各 Recipient オブジェクトの以下の値について Active Directory® ディレクトリ サービスに対してクエリを実行し、受信者がユーザー、配布グループ、パブリック フォルダ、またはパブリック フォルダ ストアかどうかを判断します。

distinguishedName | オブジェクトの識別名を示します。
msExchHomeServerName | この受信者が配置されているサーバーを示します。
homeMDB | 受信者のメールボックス ストアを示します。

キューに入ったままになっているメッセージの 25% 以上で、To: または Cc: フィールドに指定されている宛先が特定のユーザーになっていると判断すると、Exchange Server アナライザは警告を表示します。

キューに入ったままになっているメッセージの 50% 以上で、To: または Cc: フィールドに指定されている宛先が特定のユーザーになっていると判断すると、Exchange Server アナライザはエラーを表示します。

この警告またはエラーは、識別されたユーザーが、SMTP キューに入ったままになっているメッセージの共通の宛先であることを示しています。

この問題を解決するには、対象のユーザーを調査して、メッセージがキューに入る原因となる構成上の問題またはその他の異常点を見つける必要があります。

調査範囲には次のことが含まれます。

  • ユーザー オブジェクトの属性が正しく設定され、Active Directory の正しい値を含んでいることを確認します。

  • ユーザー オブジェクトの Active Directory のアクセス許可で、設定が正しいことを確認します。

  • ユーザーに対する迷惑な商用電子メール メッセージ (UCE またはスパム) またはウイルス攻撃の可能性を調べます。

  • 配信制限が不適切に設定されている配布グループにユーザーが属していないかどうかを確認します。

  • ユーザー オブジェクトが特別な用途、つまり指定された履歴保持用の受信者である場合は、そのユーザー オブジェクトが関連付けられているサービスまたはコンポーネントの構成が正しいことを確認します。

SMTP キューをトラブルシューティングする方法の詳細については、以下の Exchange リソースを参照してください。

  • Exchange Server のトランスポートおよびルーティングに関するガイドの、メール フローと SMTP のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkID=67875) (英語)

  • マイクロソフト サポート技術情報の記事 823489 の、キュー ビューアを使用してメール フローの問題をトラブルシューティングする方法に関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823489)

配布グループの制限が Exchange Server のメール フローに及ぼす影響の詳細については、次のマイクロソフト サポート技術情報の記事を参照してください。

  • 895407 の、Exchange Server 2003 で配布グループに基づいた配信の制限を設定した後にローカル メールボックスおよび外部メールボックスへのメッセージ配信が予想よりも遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=895407)

  • 329171 の、[XADM] グループ メンバシップに基づいた配信制限が設定されている受信者へのメールの配信が遅くなる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=329171)

  • 839949 の、Exchange 2000 Server と Exchange Server 2003 でのメールの転送と配布グループについてのトラブルシューティングに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=839949)

  • 812298 の、[XADM] 配布リストによる配信の制限を設定した後、メールの配信に時間がかかる現象についてのページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812298)


不明な SMTP の問題
Microsoft Exchange Server アナライザ - 文書 > トランスポート >

トピックの最終更新日時 : 2006-10-06

Microsoft® Exchange Server アナライザ ツールは、Win32_Service Microsoft WMI (Windows® Management Instrumentation) クラスに対してクエリを実行し、SMTP (Simple Mail Transfer Protocol) サービスの Started キーの値を判断します。値が False の場合、SMTP サービスは実行されていません。値が True の場合、SMTP サービスは実行されています。

また、Exchange Server アナライザは、インターネット インフォメーション サービス (IIS) メタベースに対してもクエリを実行し、SMTP 仮想サーバー インスタンスの ServerState プロパティの値を判断します。

ServerState プロパティは、サーバー インスタンスの現在の状態を示します。この状態コードとそれに対応する状態は、次のとおりです。

状態コード | 状態
1 | 開始動作中
2 | 開始
3 | 停止動作中
4 | 停止
5 | 一時停止動作中
6 | 一時停止
7 | 続行中

次の条件に当てはまる場合、Exchange Server アナライザは警告を表示します。

  • SMTP サービスが実行されている。

  • サーバー上のすべての SMTP 仮想サーバー インスタンスが開始されている。

この警告は、SMTP サービスおよび SMTP 仮想サーバー インスタンスが機能しているように見えても、さらに調査が必要な問題によって、SMTP ポートが正常に応答していないことを示しています。

この問題の原因としては、次のことが考えられます。

  • SMTP サービスがハング状態になっている。

  • ファイアウォールまたはウイルス対策アプリケーションが、SMTP ポートとの通信をブロックしている。

この問題を解決するには

  • SMTP サービスを再起動します。

  • SMTP ポートに関するファイアウォールまたはウイルス対策アプリケーションの構成をすべて確認します。

  • Exchange Server アナライザによって提供された、特定のエラーに対する指示およびリンクを確認します。

SMTP サービスを開始、停止、または一時停止するには

  1. [スタート] ボタンをクリックし、[管理ツール] をポイントします。次に、[コンポーネント サービス] をクリックします。

  2. コンソール ツリーで、[サービス (ローカル)] をクリックします。

  3. 結果ペインで、[Simple Mail Transfer Protocol (SMTP)] を右クリックし、[開始]、[停止]、または [一時停止] をクリックします。


Exchange Server 2007 への対応性
Microsoft Exchange Server アナライザ - 文書 >

トピックの最終更新日時 : 2006-07-18

このセクションの文書では、Microsoft Exchange Server® アナライザ ツールで、Exchange Server 2007 への対応性に関してどのような評価が行われているかについて詳細に説明します。さらにこれらの文書では、Exchange Server アナライザによって検出された前提条件に関連するエラー、警告、および既定以外の構成を解決するために実行できる操作について説明します。


アクセス制御リスト (ACL) の継承がブロックされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-06-19

必要なアクセス許可が伝達できなかったため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムでは、パブリック フォルダ ツリー オブジェクトでアクセス許可の継承が有効になっている必要があります。

この問題を解決するには、[親からの継承可能なアクセス許可をこのオブジェクトとすべての子オブジェクトに伝達できるようにします] の設定が有効なことを確認してから、Exchange Server 2007 セットアップ プログラムを再実行してください。

パブリック フォルダ ツリーの継承を再度有効にするには、次の操作を行います。

  1. Exchange Server 2003 システム マネージャを起動します。

  2. パブリック フォルダ ストアを右クリックし、[プロパティ] をクリックします。

  3. [セキュリティ] タブをクリックし、[親からの継承可能なアクセス許可をこのオブジェクトとすべての子オブジェクトに伝達できるようにします] チェック ボックスをオンにします。


Active Directory スキーマの拡張を使用するには Ldifde.exe がインストールされている必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-06-19

ローカル コンピュータで Active Directory スキーマを更新できないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、必要な拡張を Active Directory スキーマに加えるため、ローカル コンピュータに Ldifde.exe がインストールされている必要があります。

この問題を解決するには、ローカル コンピュータに Ldifde.exe をインストールして Exchange Server 2007 セットアップ プログラムを再実行するか、ドメイン コントローラから Exchange Server 2007 セットアップ プログラムを起動します。

注 :
Active Directory スキーマが拡張されている場合は、ローカル コンピュータに Exchange 2007 のサーバーの役割をインストールできます。ldifde.exe をインストールする必要はありません。
ローカル コンピュータに Ldifde.exe をインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、[名前] ボックスに「ServerManagerCmd -i RSAT-ADDS」と入力して実行します。


ADAM インストール パスが存在する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

ADAM (Active Directory Application Mode) をインストールしようとして失敗したため、Microsoft Exchange Server 2007 のセットアップ プログラムを続行できません。

ADAM の古いインストールが既定の場所に存在します。Exchange セットアップ プログラムは、既存の ADAM ディレクトリ構造に新しい ADAM をインストールできません。

この問題を解決するには、既存の ADAM フォルダを削除してから、Exchange セットアップ プログラムを再実行します。


ADAM がローカル コンピュータにインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-22

このコンピュータに ADAM (Active Directory Application Mode) がインストールされていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

ADAM は、ディレクトリが有効なアプリケーションで使用するように特別に設計されたライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリ サービスです。ADAM はアプリケーション固有の情報のみを格納およびレプリケートするため、ドメイン コントローラ上に展開する必要はなく、Active Directory ディレクトリ サービスにも依存しません。ADAM は、ネットワーク オペレーティング システムの認証や承認を行いません。

Exchange 2007 では、Exchange トランスポート サーバーの役割は ADAM を使用して構成情報を格納します。ADAM を Active Directory と同期させた場合は、ADAM を使用して、メッセージ セキュリティのために受信者参照を実行することもできます。

Microsoft Exchange セットアップ プログラムを続行するには、ローカル コンピュータに ADAM サービスがインストールされている必要があります。

この問題を解決するには、ADAM (Active Directory Application Mode) についてのページ (http://go.microsoft.com/fwlink/?linkid=71063) から ADAM Service Pack 1 (SP1) をインストールしてから、セットアップ プログラムを再実行します (このサイトは英語の場合があります)。


ADAM がローカル コンピュータ (Longhorn) にインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-08-13

この Windows Server 2008 ベースのコンピュータに ADAM (Active Directory Application Mode) がインストールされていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

ADAM は、ディレクトリが有効なアプリケーションで使用するように特別に設計されたライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリ サービスです。ADAM はアプリケーション固有の情報のみを格納およびレプリケートするため、ドメイン コントローラ上に展開する必要はなく、Active Directory ディレクトリ サービスにも依存しません。ADAM は、ネットワーク オペレーティング システムの認証や承認を行いません。

Exchange 2007 では、Exchange トランスポート サーバーの役割は ADAM を使用して構成情報を格納します。ADAM を Active Directory と同期させた場合は、ADAM を使用して、メッセージ セキュリティのために受信者参照を実行することもできます。

Microsoft Exchange セットアップ プログラムを続行するには、ローカル コンピュータに ADAM サービスがインストールされている必要があります。

この問題を解決するには、Windows Server 2008 オペレーティング システムを実行しているローカル コンピュータに ADAM をインストールしてから、セットアップ プログラムを再度実行してください。

Windows Server 2008 オペレーティング システムに ADAM をインストールするには

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、以下のコマンドを入力します。

  2. cmd.exe /c start /w pkgmgr.exe /iu:"DirectoryServices-ADAM"

  3. Exchange 2007 セットアップ プログラムを再度実行します。


アナライザによる検索の警告
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-08-09

このトピックの目的は、Exchange Server アナライザ ツールが提起した特定の問題に取り組むことです。解決策を適用する対象は、Exchange Server アナライザ ツールを実行し、その特定の問題が発生しているシステムに限定する必要があります。

無料でダウンロードして入手できる Exchange Server アナライザ ツールは、トポロジ内の各サーバーから構成データをリモートで収集し、データを自動的に分析します。生成されるレポートには、構成上の重要な問題点、潜在的な問題点、および製品の各種設定で既定値以外のものが、詳細に記載されます。これらの推奨事項に従うことにより、パフォーマンス、スケーラビリティ、信頼性、およびアップタイムの向上を達成できます。

このツールの詳細、または最新バージョンのダウンロードについては、「Exchange Server ベスト プラクティス アナライザ ツール バージョン 2 のダウンロード」(http://go.microsoft.com/fwlink/?linkid=34707) を参照してください。


32 ビット互換性の警告
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-08-13

32 ビット バージョンの Microsoft Exchange をインストールしようとすると、Microsoft Exchange Server 2007 セットアップ プログラムによってこの警告が表示されます。

Exchange 2007 は、2 つのプラットフォーム バージョンで提供されます。1 つのプラットフォーム バージョン (64 ビット バージョン) は実運用環境向けで、もう 1 つのプラットフォーム バージョン (32 ビット バージョン) は運用環境以外 (実験室、トレーニング施設、デモ、評価環境など) に向けたものです。32 ビットの Exchange 2007 サーバーを運用環境で実行することはできないため、購入できるのは 64 ビット バージョンのみです。

32 ビット プラットフォームの運用環境および運用環境以外での使用に関する例外として、Microsoft は最小限のサポートによる 32 ビット バージョンの運用環境での使用を、以下の条件において許可します。

  • 運用環境で 32 ビット バージョンの Exchange 管理ツールを使用し、Windows Server 2003 または Windows XP から Exchange 2007 サーバーを管理できます。現時点では、32 ビット バージョンと 64 ビット バージョンのいずれも、Windows Vista や Windows Server 2008 で使用することはできません。Windows Vista および Windows Server 2008 に対するサポートは、Exchange 2007 Service Pack 1 で提供される予定です。

  • 32 ビット バージョンのセットアップ プログラムを運用環境で使用して、Active Directory ディレクトリ サービス スキーマを拡張することができます。Active Directory を Exchange 2007 のために準備する詳細な手順については、Active Directory とドメインを準備する方法についてのページを参照してください。

運用環境で 32 ビット バージョンの Exchange 2007 をその他の目的で使用することは、すべてサポートされません。

32 ビット バージョンの Exchange 管理ツールをダウンロードするには、Microsoft Exchange Server 2007 管理ツール (32 ビット) についてのページ (http://go.microsoft.com/fwlink/?LinkId=82335) を参照してください (このサイトは英語の場合があります)。Exchange 2007 の各プラットフォーム バージョンの詳細については、Exchange 2007 製品ドキュメントの「Exchange Server 2007: プラットフォーム、エディション、およびバージョン」(http://go.microsoft.com/fwlink/?LinkId=88051) を参照してください。


Microsoft Windows オペレーティング システムの 2007 タイム ゾーン更新プログラムをインストールする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-02-20

更新プログラムを適用してこのコンピュータのタイム ゾーン情報設定を修正する必要があるため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、マイクロソフト サポート技術情報の文書番号 931836 で説明されている Windows オペレーティング システム用のタイム ゾーン更新プログラムがインストールされている必要があります。

この問題を解決するには、マイクロソフト サポート技術情報の文書番号 931836「Microsoft Windows オペレーティング システム用の 2007 年 2 月の累積的なタイム ゾーン更新プログラム」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=931836) で説明されている更新プログラムをインストールしてから、Exchange 2007 セットアップ プログラムを再実行します。


Active Directory が存在しないか接続できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-18

有効な Active Directory ディレクトリ サービス サイトに接続できないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Microsoft Exchange のインストールに使用するサーバーが Active Directory の構成名前付けコンテキストを見つけられる必要があります。

この問題を解決するには、Microsoft Exchange セットアップ プログラムを実行するユーザー アカウントが Active Directory にログオンしていることを確認した後に、セットアップ プログラムを再実行します。これで問題が解決されない場合は、以下のトピックに説明がある NETDIAG.Exe および DCDIAG.Exe サポート ツールを使用するときのガイダンスに従って、さらに問題を診断します。

Active Directory のトラブルシューティングおよび Microsoft Exchange の構成の詳細については、以下を参照してください。

  • Windows Server 2003 の操作についてのページの、Active Directory 操作のトラブルシューティングに関するセクション (http://go.microsoft.com/fwlink/?LinkId=68099) (このサイトは英語の場合があります)

  • Active Directory 運用ガイドについてのページの、Active Directory のトラブルシューティング用ツールに関するセクション (http://go.microsoft.com/fwlink/?LinkId=68100) (このサイトは英語の場合があります)

  • Exchange Server における Active Directory アクセス許可の使用についてのページの、構成名前付けコンテキストに関するセクション (http://go.microsoft.com/fwlink/?LinkId=47592) (このサイトは英語の場合があります)

  • Exchange Server における Active Directory アクセス許可の使用についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) (このサイトは英語の場合があります)

  • Netdiag の概要についてのページ (http://go.microsoft.com/fwlink/?LinkID=69481) (このサイトは英語の場合があります)

  • Dcdiag の概要についてのページ (http://go.microsoft.com/fwlink/?LinkID=68936) (このサイトは英語の場合があります)


Active Directory ドメインが混在モードである
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-10

既存の Active Directory ドメインが Microsoft Windows® 2000 Server ネイティブ モード以上に設定されていないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでは、Windows 2000 Server ネイティブ モード以上のドメインにのみ存在できるユニバーサル セキュリティ グループが作成されます。

この問題を解決するには、次の手順に従って、ドメインの機能レベルを Windows 2000 Server ネイティブ レベル以上に上げてから、Exchange 2007 セットアップ プログラムを再実行します。

ドメインの機能レベルを上げるには

  1. [Active Directory ドメインと信頼関係] を開きます。

  2. コンソール ツリーで、機能を上げるドメインを右クリックし、[ドメインの機能レベルを上げる] をクリックします。

  3. [利用可能なドメインの機能レベルを選択してください] で、次のいずれかの手順を使用します。

    • ドメインの機能レベルを Windows 2000 Server ネイティブに上げるには、[Windows 2000 ネイティブ]、[上げる] の順にクリックします。

    • ドメインの機能レベルを Windows Server® 2003 に上げるには、[Windows Server 2003]、[上げる] の順にクリックします。
注意 :

Windows NT® 4.0 以前を実行しているドメイン コントローラを使用している場合、または使用する予定の場合は、ドメインの機能レベルを Windows 2000 Server ネイティブに上げないでください。ドメインの機能レベルを Windows 2000 Server ネイティブに設定した後で、Windows 2000 Server 混在に戻すことはできません。

Windows NT 4.0 以前または Windows 2000 Server を実行しているドメイン コントローラを使用している場合、または使用する予定の場合は、ドメインの機能レベルを Windows Server 2003 に上げないでください。ドメインの機能レベルを Windows Server 2003 に設定した後で、Windows 2000 Server 混在または Windows 2000 Server ネイティブに戻すことはできません。


Active Directory の準備が必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

ドメインの準備を試みて失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムを実行するには、Active Directory ディレクトリ サービスを Exchange Server 2007 用に変更してから、Active Directory 内のドメインを準備する必要があります。

この問題を解決するには、Setup /PrepareAD コマンドを使用して Active Directory を準備してから、ドメインを準備します。

PrepareAD プロセスの実行方法の詳細については、Active Directory とドメインを準備する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください (このサイトは英語の場合があります)。


ADAM ポートが既に使用されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ゲートウェイ サーバーの役割をインストールしようとしたときに ADAM (Active Directory® Application Mode) の同期用に割り当てるポートが既に使用されていることが検出されたため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

ADAM は、ディレクトリが有効なアプリケーションで使用するように特別に設計されたライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリ サービスです。ADAM はアプリケーション固有の情報のみを格納およびレプリケートするため、ドメイン コントローラ上に展開する必要はなく、Active Directory サービスにも依存しません。ADAM は、ネットワーク オペレーティング システムの認証や承認を行いません。

Exchange 2007 では、ゲートウェイ サーバーは ADAM を使用して構成情報を格納します。ADAM を Active Directory ディレクトリ サービスと同期させた場合は、ADAM を使用して、メッセージ セキュリティのために受信者参照を実行することもできます。

Microsoft Exchange セットアップ プログラムでは、ゲートウェイ サーバーの役割をインストールするときに ADAM 同期プロセスに割り当てることのできる特定の (未使用の) ポートが必要になります。

この問題を解決するには、ADAM に必要なポートを既に使用しているプロセスを識別して停止するか、または既定の ADAM ポート割り当てを変更するコマンドライン スイッチを使用して Exchange 2007 セットアップ プログラムを実行します。

既定の ADAM ポート割り当てを変更してセットアップ プログラムを実行するには、次の操作を行います。

  1. コマンド プロンプトで次のように入力します。

    Setup.exe /adamport:xxxx /adamsslport:yyyy

    • /adamport:<ADAM に割り当てるポート番号>

    • /adamsslport:< ADAM に割り当てるポート番号>


アプリケーション パブリック フォルダ階層の存在
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービス ドメイン内のアプリケーション パブリック フォルダ階層を検索します。Exchange Server アナライザが MAPI 以外のパブリック フォルダ ツリーを検出すると、警告が表示されます。この警告は、Exchange 組織内に MAPI 以外のパブリック フォルダ ツリーが存在することを示します。Exchange Server 2007 では、このようなカスタム アプリケーション ツリーはサポートされません。

MAPI 以外のパブリック フォルダ ツリーは、カスタム アプリケーション開発に使用されます。このツリーは Microsoft Exchange 2000 Server および Microsoft Exchange Server 2003 で使用されていましたが、Exchange 2007 ではサポートされません。このため、Exchange 2007 を展開する前に、次のいずれかを実行することをお勧めします。

  • MAPI 以外のパブリック フォルダ ツリーを SharePoint Portal Server に移動する。

  • データを Exchange 2003 サーバーで管理する。

異なるパブリック フォルダ階層の詳細については、「Selecting the Appropriate Client for Exchange Public Folder Access」(http:// go.microsoft.com/fwlink/?LinkId =46439) を参照してください (このサイトは英語の場合があります)。


Active Directory サイトの名前を確認できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

有効な Active Directory® ディレクトリ サービス サイトにサーバーが属していないように見えるため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Exchange 2007 のインストールに使用するサーバーが有効な Active Directory サイトに属している必要があります。

この問題を解決するには、ローカル サーバーが有効な Active Directory サイトのメンバであることを確認してから、Exchange Server 2007 セットアップ プログラムを再実行します。

Nltest.exe コマンド ライン ツールの /DsGetSite オプションを使用すると、サイト メンバシップを確認および表示できます。詳細については、Windows Server 2003 テクニカル リファレンスのページ (http://go.microsoft.com/fwlink/?LinkId=27734) の NLTest (Nltest.exe) の概要に関するセクションを参照してください (このサイトは英語の場合があります)。

Active Directory のトラブルシューティングの詳細については、Windows Server 2003 の操作についてのページ (http://go.microsoft.com/fwlink/?linkid=68099) の Active Directory 操作のトラブルシューティングに関するセクションを参照してください (このサイトは英語の場合があります)。


受信者更新サービスが見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-16

既存の Exchange 組織内のドメインに対して使用される受信者更新サービス (RUS) が見つからないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、既存の Exchange 組織内の各ドメインに受信者更新サービスのインスタンスが存在する必要があります。

ドメインの受信者更新サービスのインスタンスが見つからない場合、そのドメイン内で作成される新しいユーザー オブジェクトは、自身宛てに発行される電子メール アドレスを受信できません。

この問題を解決するには、受信者更新サービスのインスタンスが各ドメインに存在することを確認し、インスタンスが存在しないドメインの受信者更新サービスのインスタンスを作成した後、Microsoft Exchange セットアップ プログラムを再実行します。

ドメインの受信者更新サービスのインスタンスを作成するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [受信者] を展開します。

  3. [受信者更新サービス] ノードを右クリックし、[新規作成] をクリックして、[受信者更新サービス] をクリックします。

  4. [新しいオブジェクト] ウィンドウで、[参照] をクリックして、ドメインの名前を見つけます。

  5. ドメイン名を選択し、[OK] をクリックします。

  6. [新しいオブジェクト] ウィンドウで、[次へ] をクリックし、[完了] をクリックします。

受信者更新サービスの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 「受信者更新サービスで受信者ポリシーを適用する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=328738)

  • 「受信者更新サービスにアドレス一覧を生成させる方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253828)

  • 「Exchange 受信者更新サービスの進行状況を確認する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=246127)

  • 「Exchange 受信者更新サービスで実行されるタスク」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=253770)


メールボックス データベースを削除できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-06-20

メールボックス サーバーの役割のアンインストール処理で、ローカル サーバーからユーザーのメールボックス データベース (ストア) を削除するとデータが失われる可能性があるため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、メールボックス サーバーの役割を削除する前に、サーバーからすべてのメールボックス ストアが削除されたかどうかを確認します。ただし、ユーザーのメールボックスがまだサーバーに残っている可能性があります。

この問題を解決するには、サーバー上にあるユーザーのすべてのメールボックスを移動するか無効にした後に、Exchange 2007 セットアップ プログラムを再実行します。

データベースにあるメールボックスの識別の詳細については、Exchange Server 2007 製品ドキュメントの Get-Mailbox コマンドレットについてのページ (http://go.microsoft.com/fwlink/?LinkId=93470) を参照してください (このサイトは英語の場合があります)。

メールボックスの無効化の詳細については、Exchange Server 2007 製品ドキュメントのメールボックスを無効にする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=93471) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 でメールボックス データベースを削除する方法の詳細については、Exchange Server 2007 製品ドキュメントのメールボックス データベースを削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=93473) を参照してください (このサイトは英語の場合があります)。

ユーザーのメールボックス データベース ストアまたはレプリカを管理する方法の詳細については、Exchange Server 2003 管理ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47617) の、メールボックス ストアとパブリック フォルダ ストアの管理方法に関するセクションを参照してください (このサイトは英語の場合があります)。


パブリック フォルダ データベースを削除できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-23

メールボックス サーバーの役割のアンインストール処理で、ローカル サーバーからパブリック フォルダ データベースを削除するとデータが失われる可能性があるため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、メールボックス サーバーの役割を削除する前に、パブリック フォルダ データベースを削除する必要があります。

パブリック フォルダのレプリカがサーバー上に残っているか、またはパブリック フォルダ データベースが Exchange 組織内で最後になっている可能性があります。

この問題を解決するには、サーバー上にあるパブリック フォルダ データベースを移動または削除した後に、Exchange Server 2007 を再実行します。

Exchange Server 2007 でパブリック フォルダ データベースを削除する方法の詳細については、Exchange Server 2007 の製品ドキュメントのパブリック フォルダ データベースを削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=81409) を参照してください (このサイトは英語の場合があります)。

パブリック フォルダ ストアまたはレプリカを管理する方法の詳細については、Exchange Server 2003 管理ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=47617) の、メールボックス ストアとパブリック フォルダ ストアの管理方法に関するセクションを参照してください (このサイトは英語の場合があります)。


ユニファイド メッセージング サーバーの役割を削除できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

ユニファイド メッセージング サーバーの役割をアンインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、アンインストールされるユニファイド メッセージング サーバーの役割がダイヤル プランのプロンプト公開ポイントをホストしているかどうか、およびそのダイヤル プランにリンクされている他のサーバーがあるかどうかを確認します。

ユニファイド メッセージング サーバーの役割がダイヤル プランのプロンプト公開ポイントをホストしている場合、アンインストール処理が失敗します。

この問題を解決するには、プロンプト公開ポイントを別のサーバーに移動してから、Exchange 2007 のセットアップ プログラムを再実行します。

ダイヤル プランのプロンプト公開ポイントを移動することの詳細については、プロンプト公開ポイントを変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=82356) を参照してください (このサイトは英語の場合があります)。


CMS データ パスに書き込めない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

共有クラスタ ドライブにクラスタ化メールボックス サーバーの役割をインストールできなかったため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムは、/CMSDataPath パラメータで指定された対象のインストール パスに書き込めませんでした。Exchange セットアップ プログラムでは、クラスタ化メールボックス サーバーのデータが置かれるパスは書き込み可能なボリュームである必要があります。

この問題を解決するには、/CMSDataPath に、書き込み可能な記憶域メディア上の対象パスを指定します。

クラスタ化メールボックス サーバーのインストールに関する詳細については、Exchange Server 2007 製品ドキュメントの、アクティブ ノードにメールボックス サーバーの役割をインストールする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86624) を参照してください (このサイトは英語の場合があります)。


Exchange 組織コンテナに書き込めない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-05-04

ログオン ユーザーが Active Directory ディレクトリ サービス内の組織コンテナに書き込むために必要なアカウントのアクセス許可を持っていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Exchange 2007 をインストールするときにログオンするユーザーが、Enterprise Admins グループのメンバまたは Exchange 組織管理者の資格情報を持っている必要があります。

Exchange 2007 セットアップ プログラムでは、インストール処理の一環として、Microsoft Exchange 組織コンテナ内にオブジェクトを作成しなければならない場合があります。

この問題を解決するには、ログオン ユーザーに Enterprise Admins グループのメンバまたは Exchange 組織管理者のアクセス許可を与えるか、またはこれらのアクセス許可を持つアカウントを使用してログオンした後、Exchange 2007 セットアップ プログラムを再実行します。

重要 :
フォレストを越えた Exchange 2007 のインストールはサポートされていません。Exchange 2007 をインストールしようとしている Active Directory フォレストのメンバであるアカウントを使用してください。

Microsoft Exchange に必要な Active Directory アクセス許可の詳細については、Exchange Server における Active Directory アクセス許可の操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


ローカル サイトでクライアント アクセスの役割が検出されない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

Microsoft® Exchange Server 2007 セットアップ プログラムは、ローカルの Active Directory® ディレクトリ サービス サイトで既存のクライアント アクセスの役割を検出できない場合にこの警告を表示します。

Active Directory サイトにクライアント アクセスの役割のインスタンスをインストールする前に、メールボックス サーバーの役割をインストールすることを選択しています。

クライアント アクセス サーバーの役割は、さまざまなクライアントから Exchange 2007 サーバーへの接続を受け付けます。Microsoft Outlook Express や Eudora などのソフトウェア クライアントは、POP3 接続または IMAP4 接続を使用して Exchange サーバーと通信します。モバイル デバイスなどのハードウェア クライアントは、ActiveSync、POP3、または IMAP4 を使用して Exchange サーバーと通信します。

ユーザーが Microsoft Office Outlook® 以外のクライアントを使用して受信トレイにアクセスする場合は、Exchange 組織にクライアント アクセス サーバーの役割をインストールする必要があります。

ユーザーは Outlook を使用して自分のメールボックスにログオンできますが、ローカル Active Directory サイトにクライアント アクセスの役割がインストールされるまでは、Outlook Web Access やモバイル デバイスを使用して同一のメールボックスにアクセスすることはできません。


クラスタ管理リソースを移動するか、またはオフラインにする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-09

新しいアクティブなクラスタ化メールボックス サーバーの役割のインストールが失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange Server 2007 では、セットアップ プログラムが実行されるクラスタ ノードでクラスタ管理リソースを非アクティブにする必要があります。

この問題を解決するには、そのノードが所有しているすべてのクラスタ管理リソース (Exchange Server 以外のクラスタ リソースも含む) を、クラスタ内の他のノードに移動します。または、それらのリソースをオフラインにしてから、セットアップ プログラムを再実行します。

Exchange 関連のクラスタ化された管理サービスを移動する方法の詳細については、Exchange Server 2007 製品ドキュメントの、Move-ClusteredMailboxServer コマンドレットのトピック (http://go.microsoft.com/fwlink/?LinkId=86627) を参照してください (このサイトは英語の場合があります)。

Exchange 関連のクラスタ化された管理サービスをオフラインにする方法の詳細については、Exchange Server 2007 製品ドキュメントの、Stop-ClusteredMailboxServer コマンドレットのトピック (http://go.microsoft.com/fwlink/?LinkId=86635) を参照してください (このサイトは英語の場合があります)。

Exchange 以外のクラスタ リソースを管理する方法の詳細については、Windows Server 2003 製品ヘルプの、リソースの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=86637) を参照してください (このサイトは英語の場合があります)。


クラスタ サービスが開始されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

Microsoft Windows Server クラスタ サービスが開始されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、クラスタ サービスがローカル コンピュータにインストールされるときに、このサービスが開始される必要があります。

この問題を解決するには、ローカル コンピュータでクラスタ サービスを開始してから、Exchange セットアップ プログラムを再実行します。

クラスタ サービスを開始する方法については、Windows Server 2003 テクニカル ライブラリの、クラスタ サービスの開始についてのページ (http://go.microsoft.com/fwlink/?LinkId=86638) を参照してください (このサイトは英語の場合があります)。


クラスタの更新が必要 (KB921181)
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-11

クラスタ ノードの更新が必要なため、Microsoft® Exchange Server 2007 のセットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、マイクロソフト サポート技術情報の文書番号 921181 で説明されているクラスタ ノード更新プログラムがインストールされている必要があります。

この問題を解決するには、マイクロソフト サポート技術情報の文書番号 921181 の、Windows Server 2003 Service Pack 1 ベースのサーバー クラスタにファイル共有監視機能および構成可能なクラスタ ハートビート機能を追加する更新プログラムの入手についてのページ (http://go.microsoft.com/fwlink/?LinkId=69785) で説明されている更新プログラムをインストールしてから、Exchange 2007 のセットアップ プログラムを再実行します。


CMS データ パスは NTFS ボリュームであることが必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-26

共有クラスタ ドライブにクラスタ化メールボックス サーバーの役割をインストールできなかったため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

/CMSDataPath パラメータで指定されたインストール先のパスが NTFS ボリュームでありません。Exchange セットアップ プログラムでは、クラスタ化メールボックス サーバーのデータが置かれるパスは NTFS ボリュームである必要があります。

この問題を解決するには、/CMSDataPath に別のパスを指定するか、対象のボリュームを NTFS へ変換してから、Exchange 2007 セットアップ プログラムを再実行します。

ボリュームを NTFS へ変換する方法の詳細については、Windows XP Professional 製品ドキュメントの、Convert についてのページ (http://go.microsoft.com/fwlink/?LinkId=86642) を参照してください (このサイトは英語の場合があります)。


現在のクラスタ ノードにクラスタ化管理サービスが属している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-09

クラスタ パッシブ ノードをアンインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange クラスタ化管理サービスは、このクラスタ ノードに属しています。Exchange 2007 セットアップ プログラムを実行するには、Exchange ファイルを削除する前にこのノードから Exchange クラスタ化管理サービスが移動されている必要があります。

この問題を解決するには、Exchange Server 以外のクラスタ リソースを含め、このノードに属しているすべてのクラスタ管理リソースをクラスタ内の別のノードに移動するか、オフラインにしてから、セットアップ プログラムを再実行します。

Exchange 関連のクラスタ化された管理サービスを移動する方法の詳細については、Exchange Server 2007 製品ドキュメントの Move-ClusteredMailboxServer コマンドレットのトピック (http://go.microsoft.com/fwlink/?LinkId=86627) を参照してください (このサイトは英語の場合があります)。

Exchange 関連のクラスタ化された管理サービスをオフラインにする方法の詳細については、Exchange Server 2007 製品ドキュメントの、Stop-ClusteredMailboxServer コマンドレットのトピック (http://go.microsoft.com/fwlink/?LinkId=86635) を参照してください (このサイトは英語の場合があります)。

Exchange 以外のクラスタ リソースを管理する方法の詳細については、Windows Server 2003 製品ヘルプの、リソースの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=86637) を参照してください (このサイトは英語の場合があります)。


セットアップを続行するために COM+ イベント システム サービスを開始する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。インストール先のコンピュータで COM+ イベント システム サービスが開始されていないため、クライアント アクセス サーバーの役割またはエッジ トランスポート サーバーの役割をインストールしようとして失敗したことが原因です。

Exchange 2007 のセットアップ プログラムを実行するには、Microsoft Exchange をインストールしようとしているコンピュータで、COM+ イベント システム サービスの状態が "開始" に設定されている必要があります。

COM+ イベント システム サービスは、購読する側の COM コンポーネントにイベントの自動配信を行う COM+ コンポーネントのために、システム イベント通知をサポートしています。

クライアント アクセス サーバーの役割とエッジ トランスポート サーバーの役割はどちらも、COM+ イベント システム サービスを購読する COM+ コンポーネントを必要とします。

この問題を解決するには、ローカル コンピュータで COM+ イベント システム サービスの状態が "開始" に設定されていることを確認してから、Microsoft Exchange セットアップ プログラムを再実行します。

COM+ イベント システム サービスの状態を "開始" に設定するには、次の操作を行います。

  1. [マイ コンピュータ] を右クリックし、[管理] をクリックします。

  2. [サービスとアプリケーション] ノードを展開し、[サービス] ノードをクリックします。

  3. 右側のウィンドウで、[Com+ Event System] を見つけます。

  4. [Com+ Event System] を右クリックし、[プロパティ] をクリックします。

  5. [スタートアップの種類] を [自動] に設定し、[サービスの状態] を [開始] に設定します。

  6. [適用] をクリックし、[OK] をクリックします。


複雑な Exchange 組織モデルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server 組織内のルーティング グループの数を判断します。また、Exhcange Server アナライザは、Active Directory に対してクエリを実行し、Microsoft Exchange 2000 Server または Microsoft Exchange Server 2003 を実行する Exchange サーバーを持つ Active Directory サイトの数を判断します。

Exhcange Server アナライザは、以下の条件に当てはまる場合、Exchange 組織を複雑な Exchange 組織として分類します。

  • 複数の Active Directory フォレストが存在する。

  • Microsoft Identity Integration Server (MIIS) が 1 つ以上のフォレストにインストールされている。

Microsoft Exchange Server 2007 の 4 つの定義済み組織モデルのうち、複雑な Exchange 組織は、複数の Active Directory フォレストを含むか、または同期テクノロジを使用する唯一のモデルです。

複雑な Exchange 組織を Exchange 2007 に移行するには

  1. Exchange 2007 オンライン製品ドキュメントに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=69434) を参照します。

  2. 複雑な Exchange 組織を作成する方法に関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=70505)」を確認します。


ローカル コンピュータ上に '既定の Web サイト' が見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

このサーバー上の既定の Web サイトにアクセスできないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、クライアント アクセスの役割のインストールで、Microsoft インターネット インフォメーション サービス (IIS) によって作成された既定の Web サイトにアクセスする必要があります。

クライアント アクセスの役割は、Microsoft Office Outlook® (HTTP での接続の場合)、Outlook Web Access、Exchange ActiveSync®、POP3 または IMAP4 プロトコルを使用するクライアントなどのクライアント アクセス機能を提供します。

IIS は、HTTP、POP3、IMAP4、SMTP (Simple Mail Transfer Protocol)、および NNTP (Network News Transfer Protocol) プロトコルのためのプロトコル エンジンとして機能します。

場合によっては、IIS の既定の Web サイトが存在しなくなっている状況も発生します。削除されたか、または '既定の Web サイト' 以外の名前に変更されている可能性があります。

この問題を解決するには、このサーバーで IIS を削除してから再インストールします。次に、Exchange 2007 セットアップ プログラムを再実行します。

重要 :
この問題を解決するには、IIS をアンインストールしてから再インストールすることが必要です。ディレクトリの再作成や、名前の変更だけでは不十分です。
コントロール パネルの [Windows コンポーネントの追加と削除] を使用して IIS をアンインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] をクリックします。

  7. [次へ] をクリックします。

  8. IIS のアンインストールが完了したら、[完了] をクリックします。
コントロール パネルを使用して IIS をインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] チェック ボックスをオンにします。

  7. [Windows コンポーネント ウィザード] に戻るまで、[OK] をクリックします。

  8. [次へ] をクリックし、Windows コンポーネント ウィザードを完了します。


セットアップを続行するために分散トランザクション コーディネータ サービスを開始する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-16

Microsoft Exchange Server 2007 のセットアップ プログラムを続行できません。インストール先のコンピュータで分散トランザクション コーディネータ サービスが開始されていないため、クライアント アクセス サーバーの役割またはユニファイド メッセージング サーバーの役割をインストールしようとして失敗したことが原因です。

Exchange 2007 のセットアップ プログラムを実行するには、Microsoft Exchange をインストールしようとしているコンピュータで、分散トランザクション コーディネータ サービスの状態が "開始" に設定されている必要があります。

分散トランザクション コーディネータ サービスは、システム、プロセス、および通信のエラーが発生した場合でも、トランザクションを正常に完了させるために設計されたサービスを提供します。

分散トランザクションに参加する各コンピュータは、それぞれのリソースとデータを管理しながら、トランザクションに参加する他のコンピュータとも連係して機能します。分散トランザクションはとりわけ、参加しているすべてのコンピュータに対して作業全体をコミットまたは中止する必要があります。分散トランザクション コーディネータは、関与するコンポーネントのトランザクション調整の役割を実行し、トランザクションを管理する各コンピュータのトランザクション マネージャとして機能します。

クライアント アクセス サーバーの役割とユニファイド メッセージング サーバーの役割はどちらも、分散トランザクション コーディネータ サービスを必要とします。

この問題を解決するには、ローカル コンピュータで分散トランザクション コーディネータ サービスの状態が "開始" に設定されていることを確認してから、Microsoft Exchange セットアップ プログラムを再実行します。

分散トランザクション コーディネータ サービスの状態を "開始" に設定するには、次の操作を行います。

  1. [マイ コンピュータ] を右クリックし、[管理] をクリックします。

  2. [サービスとアプリケーション] ノードを展開し、[サービス] ノードをクリックします。

  3. 右側のウィンドウで、[Distributed Transaction Coordinator] を見つけます。

  4. [Distributed Transaction Coordinator] を右クリックし、[プロパティ] をクリックします。

  5. [スタートアップの種類] を [自動] に設定し、[サービスの状態] を [開始] に設定します。

  6. [適用] をクリックし、[OK] をクリックします。


ローカル コンピュータに DNS サフィックスが設定されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

ローカル コンピュータの完全修飾ドメイン名 (FQDN) が設定されていないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータに有効なドメイン ネーム システム (DNS) サフィックスが設定されている必要があります。

この問題を解決するには、ローカル コンピュータの DNS サフィックスを設定し、コンピュータを再起動して Exchange 2007 セットアップ プログラムを再実行します。

ローカル コンピュータのプライマリ DNS サフィックスを設定するには、次の操作を行います。

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [コンピュータ名] タブをクリックします。

  3. [変更] をクリックします。[コンピュータ名の変更] ダイアログ ボックスが表示されます。

  4. [詳細] をクリックします。[DNS サフィックスと NetBIOS コンピュータ名] ダイアログ ボックスが表示されます。

  5. ドメインの適切な DNS サフィックスを入力します。

  6. [メインのメンバシップが変更されるときにプライマリ DNS サフィックスを変更する] チェック ボックスをオンにします。

  7. [OK] をクリックして変更を保存したら、[OK] をクリックして [コンピュータ名の変更] ダイアログ ボックスを閉じます。

  8. [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じ、コンピュータを再起動して変更を有効にします。

DNS 名の詳細については、Microsoft サポート技術情報の文書番号 909264「Active Directory の規則にコンピュータとドメインとサイトと OU の名前を付けます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=909264) を参照してください。


ドメイン コントローラの上書きがレジストリで設定されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

指定されたドメイン コントローラを使用しようとして失敗したため、Microsoft Exchange Server 2007 のセットアップ プログラムを続行できません。ドメイン コントローラはレジストリで静的にマップされていました。

Exchange 2007 セットアップ プログラムを実行するには、setup コマンドで指定したドメイン コントローラが、レジストリの上書きを使用して静的にマップされているドメイン コントローラと一致する必要があります。

この問題を解決するには、/DomainController: <静的にマップされているドメイン コントローラの FQDN> パラメータに、静的にマップされているドメイン コントローラを指定して、setup を再実行します。

DSAccess およびディレクトリ サービスの検出の詳細については、Microsoft サポート技術情報の文書番号 250570「ディレクトリ サービス サーバーの検出と DSAccess の使用法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=250570) を参照してください。


ドメインの準備が必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

サーバーの役割をインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、特定のサーバーの役割をインストールする前にローカル ドメインを Exchange Server 2007 のために準備する必要があります。

Exchange Server 2007 に向けたドメインの準備には、以下の作業が含まれます。

  • Exchange Servers、Exchange Organization Administrators、Authenticated Users、および Exchange Mailbox Administrators のドメイン コンテナに対するアクセス許可の設定。

  • Microsoft Exchange システム オブジェクト コンテナの作成 (存在しない場合) と、Exchange Servers、Exchange Organization Administrators、Authenticated Users の各 Microsoft Exchange システム オブジェクト コンテナに対するアクセス許可の設定。

  • 現在のドメインでの Exchange Install Domain Servers という新しいドメイン グローバル グループの作成。

  • ルート ドメインの Exchange Server USG に対する Exchange Install Domain Servers グループの追加。

この問題を解決するには、setup /PrepareDomain を実行してローカル ドメインを準備してから、サーバーの役割のインストールを再度試みます。

PrepareDomain プロセスの実行方法の詳細については、Active Directory とドメインを準備する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください (このサイトは英語の場合があります)。


ローカル コンピュータにエッジ トランスポートの役割をインストールできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-03

エッジ サーバーの役割をインストールしようとしたときに、このサーバーに既に他の Microsoft Exchange の役割がインストールされていることが検出されたため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、他の Microsoft Exchange の役割がインストールされているサーバーにはエッジ サーバーの役割をインストールできません。

Microsoft Exchange エッジ サーバーの役割は、組織の境界ネットワークに展開され、インターネットとの間のメール フローを処理します。信頼できる Microsoft Exchange 組織間で送信されるメッセージの暗号化や解読を行うと共に、スパムからも保護します。

この問題を解決するには、エッジ サーバーの役割を他の Microsoft Exchange の役割がインストールされていないコンピュータにインストールします。


トポロジに EDK コネクタが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-04

Microsoft™ Exchange Server アナライザ ツールは、Active Directory™ ディレクトリ サービスを調べて、Exchange 組織内に Exchange Development Kit (EDK) コネクタが存在するかどうか確認します。Active Directory に EDK コネクタが存在することが Exchange Server アナライザによって検出されると、警告が表示されます。この警告は、Microsoft Exchange Server 2007 では EDK コネクタがサポートされていないことを表します。

サード パーティ ベンダに問い合わせて、この EDK コネクタの代わりに、Exchange 2007 で使用できるコネクタを入手することをお勧めします。または、EDK コネクタをサポートしている Exchange 2003 か Microsoft Exchange 2000 Server を引き続き使用してください。

注 :
EDK コネクタは、ファックス、ショート メッセージ サービス (SMS)、テレックスなどの通信システムへの接続や、Lotus Notes など、ゲートウェイ コネクタを使用する他のメッセージング システムへの接続を目的として構築されたサード パーティ製のアプリケーションです。Microsoft 以外のベンダが、Exchange Development Kit (EDK) を使用して独自のコネクタを開発しています。


Esm.dll が 1 つ以上のプロセスによって使用されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-28

サーバーをアップグレードしようとしたときにモジュール アクセスの問題が発生したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、アップグレードにおいてバイナリ ファイルを変更できるように、特定のモジュールが実行されていないことが必要です。Esm.dll ファイルはこのようなモジュールの 1 つです。

この問題を解決するには、Esm.dll を開いているプロセスをアンロードしてから、Exchange 2007 セットアップ プログラムを再実行します。

Esm.dll を開いているプロセスを停止するには、次の操作を行います。

  1. Exchange 管理シェルを起動します。

  2. Get-Process コマンドレットを使用して、Exchange アナライザが識別したプロセスのプロセス ID を調べます。

  3. Get-Process < process name >

  4. Stop-Process コマンドレットを使用してプロセスを停止します。

  5. Stop-Process < process ID >

  6. <process ID> には、手順 2. の Get-Process コマンドレットから返されたプロセス ID の値が入ります。

Get-Process コマンドレットの詳細については、Windows PowerShell の操作方法に関するページで、Get-Process コマンドレットの使用についてのセクションを参照してください (このサイトは英語の場合があります)。


ExchHelp.chm が開いている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-16

サーバーをアップグレードしようとしたときにファイル アクセスの問題が発生したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、アップグレード処理でファイルに変更を加えたり、ファイルにアクセスするプロセスを変更できるように、特定のファイルが閉じられている必要があります。ローカルの Exchange ヘルプ (ExchHelp.chm) ファイルは、このようなファイルの 1 つです。

この問題を解決するには、ExchHelp.chm ファイルを閉じてから、Exchange 2007 セットアップ プログラムを再実行します。


Exchange 2000 Server コンピュータを SP3 にアップグレードする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

既存の組織内の 1 台以上のサーバーで実行されている Exchange 2000 Server に、Service Pack 3 またはそれ以降のバージョンが適用されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでは、組織内の既存の Exchange 2000 Server コンピュータすべてが、Exchange 2000 Server Service Pack 3 (SP3) を実行している必要があります。

この問題を解決するには、組織内の既存の Exchange 2000 Server コンピュータすべてを、Exchange 2000 Server SP3 またはそれ以降のバージョンにアップグレードしてから、Exchange 2007 セットアップ プログラムを再実行します。

Exchange 2000 Server コンピュータを Exchange 2000 Server SP3 またはそれ以降のバージョンにアップグレードする方法の詳細については、Exchange 2000 Server のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=86647) を参照してください (このサイトは英語の場合があります)。


Exchange 組織が混在モードになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

Microsoft® Exchange Server アナライザ ツールは、Exchange 組織コンテナに対してクエリを実行して、Exchange 組織のモードを判断します。Exchange Server アナライザは msExchangeMixedMode 属性の値をチェックします。msExchangeMixedMode 属性の値が True であることが Exchange Server アナライザによって検出されると、エラーが表示されます。このエラー メッセージは、Exchange 組織が混在モードで実行されていることを表します。Microsoft Exchange Server 2007 は、ネイティブ モードにある組織にのみインストール可能です。そのため、Exchange 2007 の展開の準備をするには、混在モードで実行されている組織をネイティブ モードに切り替える必要があります。

注 :
ネイティブ モードで実行されている組織には、Exchange 2000 以降のバージョンのサーバーのみ格納できます。

Exchange 2007 の展開の準備をするには、次の手順に従って、Exchange 組織をネイティブ モードに変換する必要があります。

  1. Exchange 5.5 サーバーが残っている場合は、そのサーバーを削除するか、または使用を停止します。

  2. Exchange システム マネージャで、Exchange 組織オブジェクトのプロパティを開き、ネイティブ モードに切り替えます。

ネイティブ モードへの Exchange 組織の変換方法の詳細については、『Exchange Server 2003 Deployment Guide』の「How to Convert from Mixed Mode to Native Mode in Exchange」(http://go.microsoft.com/fwlink/?LinkId=56642) を参照してください (このサイトは英語の場合があります)。

Microsoft Exchange の混在モードとネイティブ モードの詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 270143「[XADM] 混在モード vs. ネイティブ モード」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=270143)

  • 文書番号 327779「Exchange で混在モードからネイティブ モードに変換する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779)

  • 文書番号 272314「[XADM] 混在モードの組織をネイティブ モードに変換するための準備」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=272314)


Exchange Server 2003 コンピュータを SP2 にアップグレードする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

既存の組織内の 1 台以上のサーバーで実行されている Exchange Server 2003 に、Service Pack 2 またはそれ以降のバージョンが適用されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでは、組織内の既存の Exchange Server 2003 コンピュータすべてが、Exchange Server 2003 Service Pack 2 (SP2) またはそれ以降のバージョンを実行している必要があります。

この問題を解決するには、組織内の既存の Exchange Server 2003 コンピュータすべてを、Exchange Server 2003 SP2 またはそれ以降のバージョンにアップグレードしてから、Exchange 2007 セットアップ プログラムを再実行します。

Exchange Server 2003 コンピュータを Exchange Server 2003 SP2 またはそれ以降のバージョンにアップグレードする方法の詳細については、Exchange Server 2003 のダウンロード ページ (http://go.microsoft.com/fwlink/?LinkId=21030) を参照してください (このサイトは英語の場合があります)。


このバージョンの Windows で Exchange Server 2007 を使用できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

ローカル コンピュータで、Exchange Server 2007 がサポートするバージョンの Microsoft Windows Server オペレーティング システムが実行されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、Exchange Server 2007 のシステム要件で指定されているように、ローカル コンピュータ上の Windows Server のバージョンが、Exchange Server 2007 を実行するためにサポートされている必要があります。

この問題を解決するには、Exchange Server 2007 でサポートされているバージョンの Windows Server オペレーティング システムをローカル コンピュータにインストールするか、サポートされているバージョンの Windows Server を実行しているコンピュータに Exchange Server 2007 をインストールします。

Exchange Server 2007 のシステム要件の詳細については、Exchange Server 2007 のシステム要件についてのページ (http://go.microsoft.com/fwlink/?LinkId=86651) を参照してください (このサイトは英語の場合があります)。


ファイル共有監視機能が構成されていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-23

クラスタ連続レプリケーション (CCR) クラスタに対してファイル共有監視機能が構成されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

マジョリティ ノード セット (MNS) クォーラム クラスタに属するいずれか 1 つのノードの故障に耐えるには、利用可能と見なせるデバイスを少なくとも 3 つ用意する必要があります。ファイル共有監視機能を利用すると、外部ファイル共有を監視機能として使用できます。この監視機能は、2 ノードの MNS クォーラム クラスタ内で 3 番目の利用可能なデバイスとして機能します。

Exchange 2007 セットアップ プログラムを実行するには、CCR 環境内のクラスタ化メールボックス サーバーの役割のインストールに対して、ファイル共有監視機能が構成されている必要があります。

この問題を解決するには、ファイル共有監視機能を構成する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=78278) に記載されている手順に従ってファイル共有監視機能用のファイル共有を作成し、セキュリティで保護します (このサイトは英語の場合があります)。次に、MNSFileShare 値を設定し、クラスタ グループを 2 回移動し、Microsoft Exchange セットアップ プログラムを再実行します。


最初の役割のインストールを委任できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ログオン ユーザーがトポロジに最初のサーバーの役割をインストールするのに必要なアカウントのアクセス許可を持っていないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムでは、2 番目以降のサーバーの役割のインストールに委任を使用できますが、トポロジに最初の Exchange 2007 サーバーの役割をインストールするときに、ログオンしたユーザーが Exchange 組織管理者の資格情報を持っている必要があります。

最初のサーバーの役割をインストールする作業において、Exchange 2007 セットアップ プログラムでは Exchange 組織のコンテナ内へのオブジェクトの作成が必要になる場合があります。

この問題を解決するには、ログオン ユーザーに Exchange 組織管理者のアクセス許可を与えるか、またはこれらのアクセス許可を持つアカウントを使用してログオンした後、Exchange 2007 セットアップ プログラムを再実行します。


Forefront Security for Exchange Server サービスは無効になっている必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-06-20

ローカル コンピュータで Microsoft Forefront Security for Exchange Server サービスが実行されているため、Microsoft Exchange Server 2007 セットアップ プログラムは Exchange Server 2007 アップグレードを続行できません。

Exchange セットアップ プログラムを実行するには、Exchange Server 2007 アップグレードを続行する前に Forefront Security for Exchange Server サービスを無効にします。

この問題を解決するには、Forefront Security for Exchange Server サービスを無効にしてから、Exchange Server アップグレードを再度実行します。

Forefront Security を実行している Exchange Server に Service Pack またはソフトウェア更新プログラムをインストールする方法の詳細については、Microsoft サポート技術情報の文書番号 929080「先頭セキュリティを実行している Exchange Server コンピュータでの更新 Service Pack またはソフトウェアをインストールする方法」を参照してください。


Forefront Security for Exchange Server のアップグレードが必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

対象者 : Exchange Server 2007, Exchange Server 2007 SP1
トピックの最終更新日時 : 2007-08-08

ローカル コンピュータで、Exchange Server 2007 Service Pack 1 (SP1) がサポートしないバージョンの Microsoft Forefront Security for Exchange Server が実行されているため、Microsoft Exchange Server 2007 セットアップ プログラムは Exchange Server 2007 のアップグレードを続行できません。

Exchange Server 2007 のアップグレードを続行するには、Microsoft Forefront Security for Exchange Server のバージョンをアップグレードして、そのサービスを無効にする必要があります。

この問題を解決するには、Microsoft Forefront Security version 10.0 for Exchange Server を、Microsoft Forefront Security for Exchange Server SP1 にアップグレードします。次に、Microsoft Forefront Security for Exchange Server のサービスを無効にしてから、Exchange Server のアップグレードを再開します。

詳細情報

Forefront Security を実行している Exchange Server に、Service Pack またはソフトウェア更新プログラムをインストールする方法の詳細については、Microsoft サポート技術情報の文書番号 929080「先頭 セキュリティ を実行している Exchange Server コンピュータでの更新 Service Pack またはソフトウェアをインストールする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=929080) を参照してください。


コンピュータの完全修飾ドメイン名が受信者ポリシーと一致する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-16

ローカル コンピュータの完全修飾ドメイン名 (FQDN) が受信者ポリシーの SMTP (Simple Mail Transfer Protocol) アドレスと一致するため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Exchange 組織内にあるサーバーの FQDN が、同じ Exchange 組織内で設定されている受信者ポリシーのいずれの SMTP アドレスとも異なっている必要があります。

コンピュータの FQDN が受信者ポリシーの SMTP アドレスと一致すると、SMTP を介したメールの転送に失敗し、MTA キューに保持される可能性があります。

この問題を解決するには、ローカル コンピュータの名前を変更するか、または受信者ポリシーを削除するか名前を変更し、Microsoft Exchange セットアップ プログラムを再実行します。

ローカル コンピュータの名前を変更するには、次の操作を行います。

  1. [コントロール パネル] の [システム] を開きます。

  2. [コンピュータ名] タブで、[変更] をクリックします。

  3. [コンピュータ名] ボックスにそのコンピュータの新しい名前を入力し、[OK] をクリックします。ドメイン内でそのコンピュータの名前を変更するためのユーザー名とユーザー パスワードを入力するよう求められます。

  4. [OK] をクリックし、[システムのプロパティ] ダイアログ ボックスを閉じます。コンピュータを再起動して変更を適用するよう求められます。
重要 :
名前を変更するコンピュータがドメイン コントローラの場合は、ドメイン コントローラの名前の変更についてのページ (http://go.microsoft.com/fwlink/?LinkId=66828) を参照してください (このサイトは英語の場合があります)。
受信者ポリシーの SMTP アドレスを変更するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [組織] をクリックし、[受信者] をクリックします。次に、[受信者ポリシー] をクリックします。

  3. 変更するポリシーをダブルクリックします。

  4. [電子メール アドレス] タブをクリックし、目的の SMTP アドレスを変更します。

受信者ポリシーの名前付けに関する問題の詳細については、Microsoft サポート技術情報の文書番号 288175「[XCON] 受信者ポリシーは組織のサーバーの FQDN とは異なる必要がある (5.4.8 NDR)」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=288175) を参照してください。


グローバル カタログ サーバーがローカル サイトに存在しない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

Microsoft Exchange をインストールするサイトにグローバル カタログ サーバーが存在しないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、セットアップ プログラムを実行するコンピュータの Active Directory® ディレクトリ サービス サイトに、グローバル カタログとして動作するサーバーが含まれている必要があります。

この問題を解決するには、次のいずれかの操作を行います。

  • サイト内の既存のドメイン コントローラをグローバル カタログ サーバーにします。

  • グローバル カタログ サーバーの役割に新しいサーバーをインストールします。

既存のドメイン コントローラをグローバル カタログ サーバーにするには、次の操作を行います。

  1. Active Directory サイトとサービス スナップインを起動します。

  2. [サイト] を展開し、サイトを展開します。次に、[サーバー] を展開します。

  3. グローバル カタログ サーバーとして指定するドメイン コントローラを選択します。

  4. 右側のペインで、[NTDS Settings] を右クリックし、[プロパティ] を選択します。

  5. [全般] タブで、[グローバル カタログ] チェック ボックスをオンにします。変更は、サーバーを再起動しなくても動的に行われます。
  • グローバル カタログ サーバーを作成する方法の詳細については、Microsoft サポート技術情報の文書番号 313994「[HOWTO] Windows 2000 でグローバル カタログの作成または移動を行う方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=313994) を参照してください。

  • Exchange Server に関連したグローバル カタログ サーバーの配置と可用性の詳細については、Microsoft サポート技術情報の文書番号 875427「グローバル カタログ サーバーの配置と Exchange 2000 Server 組織または Exchange Server 2003 組織に率」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=875427) を参照してください。


一括更新を実行する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-09-19

ログオン ユーザーが Active Directory® ディレクトリ サービスの一括更新を実行するために必要なアクセス許可を持っていないため、Microsoft® Exchange Server 2007 セットアップを続行できません。

Microsoft Exchange セットアップを実行するには、Exchange 2007 のインストール時のログオン ユーザーが、Enterprise Adminis グループのメンバの資格情報を持っている必要があります。

インストール プロセスの一部として、Exchange 2007 セットアップでは以下の処理を実施する必要がある場合があります。

  • Active Directory ディレクトリ サービスでの Exchange 組織オブジェクトの作成または変更

  • Active Directory フォレスト内のすべてのドメインを Exchange 2007 に対応させるための準備

  • 既存の Exchange 2000 Server ドメインおよび Exchange Server 2003 ドメインを Exchange 2007 に対応させるための準備

この問題を解決するには、ログオン ユーザーに Enterprise Admins グループのメンバのアクセス許可を与えるか、またはこれらのアクセス許可を持つアカウントを使用してログオンした後、Exchange 2007 セットアップを再実行します。

Exchange に必要な Active Directory アクセス許可の詳細については、「Working with Active Directory Permissions in Exchange Server」(http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


DNS データベースにローカル コンピュータのホスト レコードが見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

ドメイン ネーム システム (DNS) データベースにこのコンピュータのホスト (A) レコードが見つからないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータの有効なホスト (A) レコードが、ドメインに対して権限のある DNS データベースに登録されている必要があります。

Microsoft Exchange は、内部または外部にある次の送信先サーバーの IP アドレスを解決するために DNS ホスト (A) レコードを使用します。

この問題を解決するには、次の操作を行います。

  • ローカルの TCP/IP 構成が正しい DNS サーバーを示していることを確認します。

    ローカルの TCP/IP 構成を確認するには、次の操作を行います。

    1. ローカルの TCP/IP 構成を見直します。詳細については、DNS を使用する場合の TCP/IP 構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=68094) を参照してください (このサイトは英語の場合があります)。
  • Nslookup.exe を使用して、DNS サーバーにホスト (A) レコードが存在することを確認します。詳細については、DNS に A リソース レコードが存在することを確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63001) を参照してください (このサイトは英語の場合があります)。

DNS の名前解決、トラブルシューティング、およびホスト (A) レコードの詳細については、以下の文書を参照してください。

  • Microsoft サポート技術情報の文書番号 322856「Exchange Server と一緒に使用する際の DNS の構成方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=322856)

  • DNS のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?LinkId=63003) (このサイトは英語の場合があります)

  • リソース レコードの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=63004) (このサイトは英語の場合があります)


ローカル サイトでハブ トランスポートの役割が検出されない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

Microsoft® Exchange Server 2007 セットアップ プログラムは、ローカルの Active Directory® ディレクトリ サービス サイトで既存のハブ トランスポート サーバーの役割を検出できなかった場合にこの警告を表示します。

Active Directory サイトにハブ トランスポートの役割のインスタンスをインストールする前に、メールボックス サーバーの役割をインストールすることを選択しています。

Exchange 2007 ハブ トランスポート サービスは、組織の Active Directory 内に展開されます。ハブ トランスポート サービスは、組織内におけるすべてのメール フローを処理し、組織のメール フローに関するルーティング規則を適用して、受信者のメールボックスにメッセージを配信する役割を果たします。

ユーザーは自分のメールボックスにはログオンできますが、ハブ トランスポートの役割がインストールされるまで、このメールボックス サーバーとの間でメールの送受信を行うことはできません。


Hub Transport Server Not Present in Active Directory Site
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-07-25

Microsoft Exchange アナライザ ツールは、Exchange Server 2007 固有の管理グループ識別子 FYDIBOHF23SPDLT を含む Exchange 組織内の msExchAdminGroupContainer クラスのオブジェクトの値について、Active Directory ディレクトリ サービスに対してクエリを実行します。

Exchange 組織に Exchange Server 2007 管理グループがあると判断すると、Exchange アナライザは、各 msExchExchangeServer オブジェクトの msExchCurrentServerRoles 属性の値について、組織内のすべての Active Directory サイトに対してクエリを実行し、検出されたサイトにメールボックス サーバーの役割がインストールされているかどうかを判断します。

最後に、メールボックス サーバーの役割がサイトにインストールされていると判断すると、Exchange アナライザはそのサイト内の各 msExchExchangeServer オブジェクトの msExchCurrentServerRoles 属性に対してクエリを実行し、同じサイトにハブ トランスポート サーバーの役割もインストールされているかどうかを判断します。

ハブ トランスポート サーバーの役割がインストールされていない Active Directory サイトにメールボックス サーバーの役割がインストールされていると判断されると、エラーが表示されます。

このエラーは、Active Directory サイトにメールボックス サーバーの役割はインストールされていて、メールボックスが同じサーバー上にあっても、少なくともサイトに 1 つのハブ トランスポート サーバーの役割がインストールされるまで、メールボックス間でメールが転送されないことを示します。

ハブ トランスポート サーバーの役割は、組織の Active Directory ディレクトリ サービス内部に展開されます。組織内部のすべてのメール フローを処理し、組織のメッセージ ポリシーを適用し、受信者のメールボックスにメッセージを配信する役割を果たします。ハブ トランスポート サーバーは、次の機能を提供します。

メール フロー メッセージが組織内部の受信者の受信トレイに配信されるか、組織外部のユーザーにルーティングされる前に、ハブ トランスポート サーバーの役割は Exchange 2007 組織内部で送信されるすべてのメッセージを処理します。この動作に対する例外はありません。

分類 カテゴライザは、Exchange 2007 トランスポート パイプラインを通過するすべてのメッセージの受信者解決、ルーティング解決、およびコンテンツの変換を行います。

ルーティング ハブ トランスポート サーバーの役割は、組織内で送受信されるすべてのメッセージのルーティング パスを判断します。

配信 メッセージは、ストア ドライバによって受信者のメールボックスに配信されます。組織内のユーザーによって送信されるメッセージは、ストア ドライバによって送信者の送信トレイから取得され、ハブ トランスポート サーバーの送信キューに置かれます。

このエラーに対処するには、メールボックス サーバーの役割がインストールされているサイトにハブ トランスポート サーバーの役割をインストールします。

詳細情報

サイトにハブ トランスポート サーバーの役割をインストールする方法の詳細については、Exchange Server 2007 製品ドキュメント「サーバーの役割の展開」(http://go.microsoft.com/fwlink/?LinkId=83282) を参照してください (このサイトは英語の場合があります)。


IIS 6 互換性コンポーネントがインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-08-13

Internet Information Server (IIS) 6 メタベース互換性コンポーネントと IIS 6 管理コンソール コンポーネントがインストールされていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行し、Windows Server 2008 ベースの対象のコンピュータにクライアント アクセス サーバーの役割、メールボックス サーバーの役割、または Exchange 2007 管理ツールをインストールできません。

Exchange 2007 セットアップ プログラムを実行するには、Exchange 2007 クライアント アクセス サーバーの役割、メールボックス サーバーの役割、または Exchange 2007 管理ツールをインストールする Windows Server 2008 ベースのコンピュータに、IIS 6 メタベース互換性コンポーネントと IIS 6 管理コンソール コンポーネントがインストールされている必要があります。

この問題に対処するには、IIS 6 メタベース互換性コンポーネントを対象のコンピュータにインストールしてから、Microsoft Exchange セットアップ プログラムに戻ります。

Windows Server 2008 サーバー マネージャを使用して IIS 6.0 管理互換コンポーネントをインストールするには

  1. [スタート] ボタンをクリックし、[管理ツール] をクリックします。次に、[サーバー マネージャ] をクリックします。

  2. 左側のナビゲーション ウィンドウで、[役割] を展開し、[Web サーバー (IIS)] を右クリックします。次に、[役割サービスの追加] を選択します。

  3. [役割サービスの選択] ウィンドウで、[IIS 6 と互換性のある管理] まで下にスクロールします。

  4. [IIS 6 メタベース互換性] チェック ボックスと [IIS 6 管理コンソール] チェック ボックスをオンにします。

  5. [役割サービスの選択] ウィンドウで [次へ] をクリックし、[インストール選択の確認] ウィンドウで [インストール] をクリックします。

  6. [閉じる] をクリックして、役割サービスの追加ウィザードを終了します。


IIS 7 コンポーネントがインストールされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-08-09

Microsoft Exchange Server 2007 セットアップを続行して、クライアント アクセス サーバーの役割を Microsoft Windows Server 2008 ベースのシステムにインストールできません。これは、必要とされる Internet Information Server (IIS) 7 のコンポーネントがインストールされていないからです。

Exchange 2007 のセットアップでは、クライアント アクセス サーバーの役割をインストールしている Windows Server 2008 ベースのコンピュータに、事前に次の IIS 7 のコンポーネントがインストールされていることが必要です。

必要とされる IIS 7 のコンポーネント

動的なコンテンツの圧縮

静的なコンテンツの圧縮

基本認証

Windows 認証

この問題に対処するには、必要とされる IIS 7 のコンポーネントを対象のコンピュータにインストールしてから、Microsoft Exchange セットアップ プログラムに戻ります。

Windows Server 2008 サーバー マネージャを使用して IIS 7 コンポーネントをインストールするには

  1. [スタート] ボタンをクリックし、[管理ツール] をクリックします。次に、[サーバー マネージャ] をクリックします。

  2. 左側のナビゲーション ウィンドウで、[役割] を展開し、[Web サーバー (IIS)] を右クリックします。次に、[役割サービスの追加] を選択します。

  3. [役割サービスの選択] ウィンドウで、[IIS] まで下にスクロールします。

  4. [基本認証] および [Windows 認証] の [セキュリティ] のチェック ボックスを、それぞれオンにします。

  5. [静的な圧縮] および [動的な圧縮] の [パフォーマンス] のチェック ボックスを、それぞれオンにします。

  6. [役割サービスの選択] ウィンドウで [次へ] をクリックし、[インストール選択の確認] ウィンドウで [インストール] をクリックします。

  7. [閉じる] をクリックして、役割サービスの追加ウィザードを終了します。


IIS 共通コンポーネントが必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-14

サーバーに Microsoft インターネット インフォメーション サービス (IIS) 共通コンポーネントがインストールされていないため、Microsoft® Exchange Server 2007 のセットアップ プログラムを続行できません。

Microsoft Exchange Management Shell は、IIS メタベースへのリモート アクセスを必要とする場合があります。このメタベースは、ほとんどの IIS 構成値のためのリポジトリです。メタベースへのリモート アクセスを行うには、適切な COM+ DLL がローカル コンピュータにインストールされている必要があります。

この問題を解決するには、このサーバーに IIS 共通コンポーネントをインストールして、Exchange 2007 のセットアップ プログラムを再実行します。

Windows Server™ 2003 でコントロール パネルを使用して IIS 共通コンポーネントをインストールするには

  1. [スタート] メニューの [コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [アプリケーション サーバーのサブコンポーネント] ボックスの一覧で、[インターネット インフォメーション サービス (IIS)] チェック ボックスをオンにします。

  7. [詳細] をクリックします。

  8. [共通コンポーネント] チェック ボックスをオンにします。

  9. [Windows コンポーネント ウィザード] に戻るまで、[OK] をクリックします。

  10. [次へ] をクリックし、Windows コンポーネント ウィザードを完了します。
Windows® XP でコントロール パネルを使用して IIS 共通コンポーネントをインストールするには

  1. [スタート] メニューの [コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[インターネット インフォメーション サービス (IIS)] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [共通コンポーネント] チェック ボックスをオンにします。

  7. [Windows コンポーネント ウィザード] に戻るまで、[OK] をクリックします。

  8. [次へ] をクリックし、Windows コンポーネント ウィザードを完了します。


IIS が 32 ビット互換モードである
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-11

この 64 ビット コンピュータでは Microsoft インターネット インフォメーション サービス (IIS) が 32 ビット モードで実行されているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 では、IIS が 64 ビット コンピュータで実行される場合、IIS は完全な 64 ビット モードであることが必要になります。

この問題を解決するには、IIS を 64 ビット モードに切り替えて、Microsoft Exchange セットアップ プログラムを再実行します。

IIS を 64 ビット モードに切り替えるには

  1. コマンド プロンプトを開きます。

  2. 次のように入力します。

    cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

  3. Enter キーを押します。


Active Directory を準備するためのアクセス許可が不足している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-21

ドメインの準備を試みて失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムを実行するには、Active Directory ディレクトリ サービスを Exchange Server 2007 用に変更してから、Active Directory 内のドメインを準備する必要があります。

setup /PrepareAD コマンドの実行に使おうとしていたアカウントは、Enterprise Admins グループに属しているようですが、このコマンドを実行するために必要なアクセス許可を持っていません。アカウントの有効期限が切れている可能性があります。

この問題を解決するには、ログオン ユーザーのアカウントが有効であり、Enterprise Admins グループに属していることを確認するか、またはこれらのアクセス許可を持つアカウントでログオンし、setup /PrepareAD を再実行します。

PrepareAD プロセスの実行方法の詳細については、Active Directory とドメインを準備する方法に関するページ (http://go.microsoft.com/fwlink/?LinkId=78453) を参照してください (このサイトは英語の場合があります)。

Microsoft Exchange に必要な Active Directory アクセス許可の詳細については、Exchange Server における Active Directory アクセス許可の操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


すべてのサーバーの役割を削除するためのアクセス許可が不足している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

すべてのサーバーの役割をアンインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、すべてのサーバーの役割をアンインストールためにログオンするユーザーが、Exchange Organization Administrators グループまたは Enterprise Admins グループのメンバである必要があります。

この問題を解決するには、ログオン ユーザーに Exchange Organization Administrator のアクセス許可を与えるか、このユーザーを Enterprise Admins グループに登録します。または、これらのアクセス許可を持つアカウントを使用してログオンした後、Exchange 2007 セットアップ プログラムを再実行します。

Microsoft Exchange に必要な Active Directory アクセス許可の詳細については、Exchange Server における Active Directory アクセス許可の操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


/PrepareDomain を実行するための十分なアクセス許可がない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

/PrepareDomain プロセスの実行が失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。ログオンしたユーザーに、/PrepareDomain プロセスを実行するための十分なアクセス許可がありません。

Exchange 2007 セットアップ プログラムでは、/PrepareDomain プロセスの実行時にログオンするユーザーは、準備するドメインの Domain Admins グループのメンバである必要があります。また、Exchange Organization Administrators グループまたは Enterprise Admins グループのメンバである必要もあります。

この問題を解決するには、準備するドメインの Domain Admins グループのアクセス許可をログオン ユーザーに与え、ログオン ユーザーを Exchange Organization Administrators グループまたは Enterprise Admins グループに登録します。または、これらのアクセス許可を持つアカウントを使用してログオンし、Exchange 2007 セットアップ プログラムを再実行します。

Microsoft Exchange に必要な Active Directory アクセス許可の詳細については、Exchange Server における Active Directory アクセス許可の操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


ドメイン ネーム システムのドメイン名が正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-13

ローカル コンピュータで設定されているドメイン ネーム システム (DNS) のドメイン名が正しくないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、DNS ドメイン名に "A ～ Z"、"a ～ z"、"0 ～ 9"、"."、および "-" 以外の文字が含まれないことが必要です。

この問題を解決するには、ローカル コンピュータのコンピュータ名または実際の DNS ドメイン名に無効な文字があるかどうかを確認します。

  • ローカル コンピュータのコンピュータ名に無効な文字が含まれる場合は、"A ～ Z"、"a ～ z"、"0 ～ 9"、"."、および "-" の範囲にある有効な文字のみを使用してローカル コンピュータ上のドメインの DNS ドメイン名をリセットし、コンピュータを再起動して、Exchange 2007 セットアップ プログラムを再実行します。

  • 組織の DNS ドメイン名に無効な文字が含まれる場合は、DNS ドメインの名前を変更すること、または新しいドメイン ツリーに Exchange 2007 をインストールすることが可能かどうかを検討します。

注意 :
DNS ドメイン名を変更すると、ネットワーク全体に大きな影響を与える可能性があります。DNS ドメイン名に変更を加える前に、ネットワーク管理者との調整を行ってください。
ローカル コンピュータの DNS ドメイン名を確認するには、次の操作を行います。

  1. [マイ コンピュータ] を右クリックし、[プロパティ] をクリックします。[システムのプロパティ] ダイアログ ボックスが表示されます。

  2. [コンピュータ名] タブをクリックします。

  3. [変更] をクリックします。[コンピュータ名の変更] ダイアログ ボックスが表示されます。

  4. [詳細] をクリックします。[DNS サフィックスと NetBIOS コンピュータ名] ダイアログ ボックスが表示されます。

  5. "A ～ Z"、"a ～ z"、"0 ～ 9"、"."、および "-" の範囲にある文字だけが使用されていることを確認します。

  6. [ドメインのメンバシップが変更されるときにプライマリ DNS サフィックスを変更する] チェック ボックスをオンにします。

  7. [OK] をクリックしてすべての変更を保存したら、[OK] をクリックして [コンピュータ名の変更] ダイアログ ボックスを閉じます。

  8. [OK] をクリックして [システムのプロパティ] ダイアログ ボックスを閉じ、コンピュータを再起動して変更を有効にします。

DNS 名の詳細については、Microsoft サポート技術情報の文書番号 909264「Active Directory の規則にコンピュータとドメインとサイトと OU の名前を付けます。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=909264) を参照してください。


インストール パスが正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

メールボックス サーバーまたはクラスタ メールボックス サーバーの役割を共有クラスタ ドライブにインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムを実行するには、Exchange Server の役割を、共有クラスタ リソースではないドライブにインストールする必要があります。

この問題を解決するには、メールボックス サーバーの役割またはクラスタ メールボックス サーバーを、共有クラスタ ドライブとして指定されていないパスにインストールします。

クラスタ構成の詳細については、Exchange Server 2007 製品ドキュメントの高可用性についてのページ (http://go.microsoft.com/fwlink/?linkid=68190) を参照してください (このサイトは英語の場合があります)。


CMS インストール先のパス形式が正しくない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

共有クラスタ ドライブにクラスタ化メールボックス サーバーの役割をインストールできなかったため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

指定された /CMSDataPath: <データベースへのパス> パラメータが、無効な汎用名前付け規則 (UNC) 形式でした。Exchange セットアップ プログラムを実行するには、指定する /CMSDataPath: <データベースへのパス> パラメータで、UNC 形式ではなく、有効なドライブ文字の割り当て (/CMSDataPath: s:\<データベースへのパス> など) を使用する必要があります。

この問題を解決するには、/CMSDataPath: <データベースへのパス> パラメータで、有効なドライブ文字の割り当てを使用します。

クラスタ化メールボックス サーバーのインストールに関する詳細については、Exchange Server 2007 製品ドキュメントの、アクティブ ノードにメールボックス サーバーの役割をインストールする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86624) を参照してください (このサイトは英語の場合があります)。


インストールされている MOUNTMGR.SYS のバージョンが Exchange Server と互換性がない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

インストールされている Mountmgr.sys のバージョンが Microsoft Exchange と互換性がないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、クラスタ ノードに Microsoft サポート技術情報の文書番号 898790 で説明されている更新プログラムがインストールされている必要があります。

クラスタ ノードに現在インストールされている Mountmgr.sys のバージョンが、ボリューム マウント ポイントのエラーの原因になる場合があります。この問題は Mountmgr.sys ドライバの問題によって発生します。これは、マウント ポイントにマウントされるボリュームを受け取る場合に発生する断続的なタイミングの問題です。

この問題を解決するには、Microsoft サポート技術情報の文書番号 898790 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790) で説明されている更新プログラムをインストールした後、Exchange 2007 セットアップ プログラムを再実行します。

この問題の詳細については、Microsoft サポート技術情報の文書番号 898790「Windows Server 2003 Service Pack 1 をインストールした後に、サーバー クラスタ内のディスクのボリューム マウント ポイントは断続的に利用できません。」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=898790) を参照してください。


インストールされている TCPIP.SYS のバージョンが Exchange Server と互換性がない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

インストールされている Tcpip.sys のバージョンが Microsoft Exchange と互換性がないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータに Microsoft サポート技術情報の文書番号 898060 で説明されている更新プログラムがインストールされている必要があります。

現在このコンピュータでは、Windows Server™ 2003 Service Pack 1 の Tcpip.sys ドライバが実行されています。このドライバによって、ワイド エリア ネットワークで接続に関連する問題が発生する可能性があります。

この問題を解決するには、Windows Server x64 Edition の更新についてのページ (http://go.microsoft.com/fwlink/?linkid=59272) から、Microsoft サポート技術情報の文書番号 898060 で説明されている更新プログラムをインストールした後、Exchange 2007 セットアップ プログラムを再実行します (このサイトは英語の場合があります)。

この警告の詳細については、Microsoft サポート技術情報の文書番号 898060「セキュリティ更新プログラム MS05-019 または Windows Server 2003 Service Pack 1 のインストール後、クライアントとサーバー間のネットワーク接続が機能しないことがある」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=898060) を参照してください。


大規模な Exchange 組織モデルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、Exchange Server 組織内のルーティング グループの数を判断します。また、Exhcange Server アナライザは、Active Directory に対してクエリを実行し、Microsoft Exchange 2000 Server または Microsoft Exchange Server 2003 を実行する Exchange サーバーを持つ Active Directory サイトの数を判断します。

Exhcange Server アナライザは、以下の条件に当てはまる場合、Exchange 組織を大規模な Exchange 組織として分類します。

  • Exchange 組織内に 5 つを超えるルーティング グループが存在する。

  • Exchange 2000 または Exchange 2003 を実行するサーバーが 5 つを超える Active Directory サイトにインストールされている。

大規模な Exchange 組織を Exchange 2007 に移行するには

  1. Microsoft Exchange Server 2007 オンライン製品ドキュメントに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=69434) を参照します。

  2. 大規模な Exchange 組織を作成する方法に関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=70504) を確認します。


ローカル コンピュータが子ドメインのドメイン コントローラである
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-12-29

ローカル コンピュータが子ドメインのドメイン コントローラであるため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

ドメイン コントローラがグローバル カタログ サーバーでない場合、Exchange 2007 セットアップ プログラムは子ドメインのドメイン コントローラにインストールを行いません。

この問題を解決するには、ドメイン コントローラをグローバル カタログ サーバーに昇格させるか、または子ドメインの中のドメイン コントローラ以外のメンバ サーバーに Exchange 2007 をインストールし、その後 Microsoft Exchange セットアップ プログラムを再実行します。

Exchange サーバーをグローバル カタログ サーバーにしてこの警告を修正するには

  1. ドメイン コントローラ上で [スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[管理ツール] をクリックし、[Active Directory サイトとサービス] をクリックします。

  2. コンソール ツリーで、[サイト] をダブルクリックし、サイトの名前をダブルクリックします。次に、[サーバー] をダブルクリックします。

  3. 対象のドメイン コントローラをダブルクリックします。

  4. 結果ウィンドウで [NTDS Settings] を右クリックし、[プロパティ] をクリックします。

  5. [全般] タブで、[グローバル カタログ] チェック ボックスをオンにします。

  6. ドメイン コントローラを再起動します。


ローカル コンピュータが既に Exchange Server を実行している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-15

ローカル コンピュータに以前の Microsoft Exchange コンポーネントがインストールされているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータに既存の Microsoft Exchange コンポーネントがインストールされていない状態にする必要があります。

この問題を解決するには、Microsoft Exchange 2000 Server コンポーネントまたは Microsoft Exchange Server 2003 コンポーネントをすべて削除してから、Microsoft Exchange セットアップ プログラムを再実行します。

Microsoft Exchange コンポーネントを削除するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[設定] をポイントします。次に、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [現在インストールされているプログラム] ボックスの一覧で、[Microsoft Exchange] をクリックし、[変更と削除] をクリックします。

  4. Microsoft Exchange インストール ウィザードで、[次へ] をクリックします。

  5. [コンポーネントの選択] ページのアクションの一覧で、インストールされている各コンポーネントの横にある下向きの矢印をクリックし、[削除] をクリックします。

    注 :
    アクションの一覧で、インストール済みのコンポーネントはチェック マークが付けられています。[削除] をクリックすると、このチェック マークが削除に変わります。

  6. [次へ] を 2 回クリックします。

  7. [完了] をクリックします。


ローカル コンピュータが Windows Server 2003 Service Pack 1 以降を実行していない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

ローカル コンピュータが Microsoft Windows Server™ 2003 Service Pack 1 (SP1) 以降のバージョンを実行していないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、Microsoft Exchange に使用するコンピュータで Windows Server 2003 SP1 以降のバージョンが実行されている必要があります。

この問題を解決するには、次の操作を行います。

  • Windows Server 2003 SP1 以降のバージョンを実行しているコンピュータで Exchange 2007 セットアップ プログラムを実行します。

  • Exchange 2007 セットアップ プログラムを実行するコンピュータを Windows Server 2003 SP1 以降のバージョンにアップグレードします。

Windows Server 2003 にアップグレードする方法の詳細については、Microsoft サポート技術情報の文書番号 810613「Windows Server 2003 または Windows Small Business Server 2003 へのサポートされているアップグレード パス」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=810613) を参照してください。

Windows Server 2003 の最新の Service Pack の入手については、Windows Server TechCenter のページ (http://go.microsoft.com/fwlink/?LinkId=45315) を参照してください (このサイトは英語の場合があります)。


ローカル コンピュータがグループ メンバシップを展開する役割を持っている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

グループ メンバシップを展開する役割を持っているハブ トランスポートの役割をアンインストールする試みが失敗したため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでハブ トランスポートの役割をアンインストールするには、現在のブリッジヘッド サーバーから配布リストの展開が削除されていることが必要です。

配布リストを展開すると、識別対象の配布リストに属する個々の受信者を識別したり、展開のためにどの配布リストを追加したらよいかを識別したりすることができます。展開された配布リストは、必要な任意の配信状態通知 (DSN) へのパスを返すことができます。DSN は、Microsoft Exchange 管理者または電子メールの送信者に、特定の電子メール メッセージの状態を通知します。さらに、配布リストを展開すると、不在メッセージや自動的に生成された返信を元のメッセージの送信者に送信するかどうかも識別されます。

この問題を解決するには、配布グループの展開を別のサーバーに移動した後、Microsoft Exchange セットアップ プログラムを再実行します。

配布グループまたは動的な配布グループの展開サーバーを変更するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. コンソール ツリーで、[受信者の構成] を展開します。

  3. コンソール ツリーで、[配布グループ] をクリックします。

  4. 現在のブリッジヘッド サーバーを展開サーバーとして使用するすべての配布グループおよび動的な配布グループを表示するためのフィルタを作成します。

    1. アクション ペインで、[フィルタの作成] をクリックします。

    2. プロパティのボックスの一覧で、[展開サーバー] をクリックします。

    3. 演算子のボックスの一覧で、[と等しい] をクリックします。

    4. 値のボックスで、[参照] をクリックし、現在展開サーバーとして機能しているブリッジヘッド サーバーを選択します。
注 :
以下の手順は省略可能です。
  1. [式の追加] をクリックして、追加のフィルタ条件を指定します。すべてのフィルタ条件を満たすメッセージのみが表示されます。

  2. [フィルタの適用] をクリックします。フィルタ条件を満たす結果が表示されます。

  1. 結果ペインで、展開サーバーを変更する配布グループをクリックし、アクション ペインの [プロパティ] をクリックします。

  2. [プロパティ] で、[詳細設定] タブをクリックします。

  3. [展開サーバー] ボックスの一覧で、一覧から特定のサーバーを選択するか、または [組織内の任意のサーバー] を選択します。

  4. このブリッジヘッド サーバーを展開サーバーとして使用するすべての配布グループまたは動的な配布グループについて、手順 5. ～ 7. を繰り返します。


ローカル コンピュータがオフライン アドレス帳を生成する役割を持っている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

オフライン アドレス帳を生成する役割を持っているメールボックスの役割をアンインストールする試みが失敗したため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでメールボックスの役割をアンインストールするには、そのメールボックスの役割が Exchange 組織内の最後のメールボックスの役割でない限り、現在のメールボックス サーバーからオフライン アドレス帳の生成が削除されていることが必要です。

この問題を解決するには、オフライン アドレス帳の生成を別のサーバーに移動した後、Microsoft Exchange セットアップを再実行します。

Exchange システム マネージャを使用してオフライン アドレス帳の生成を移動するには、次の操作を行います。

  1. Exchange システム マネージャを起動します。

  2. [受信者] の下にある [オフライン アドレス一覧] をクリックします。

  3. 右側のペインで、[既定のオフライン アドレス一覧] を右クリックし、[プロパティ] をクリックします。

    注 :
    このメッセージを生成するその他すべてのオフライン アドレス一覧について、同じ手順を実行します。

  4. [全般] タブの [オフライン アドレス一覧サーバー] で、[参照] をクリックし、使用する Exchange サーバーをクリックします。
Exchange 管理コンソールを使用してオフライン アドレス帳の生成を移動するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. [Microsoft Exchange] を展開し、[Organization Configuration] を展開します。次に、[メールボックス] を選択します。

  3. 結果ペインで、[オフライン アドレス帳] タブをクリックします。

  4. [オフライン アドレス帳] タブで、移動するオフライン アドレス帳を選択します。アクション ペインで、[移動] をクリックします。

  5. [Move Offline Address Book Wizard] が表示されたら、[参照] ボタンを使用してオフライン アドレス帳の生成をホストする新しいサーバーを選択し、[移動] をクリックします。

  6. ウィザードを閉じるには、[完了] をクリックします。
Exchange Management Shell を使用してオフライン アドレス帳の生成を移動するには、次の操作を行います。

  • 次のコマンドを実行します。

    コードのコピー
    Move-OfflineAddressBook -Identity <OfflineAddressBookIdParameter> -Server <ServerIdParameter> [-DomainController <String>]


ローカル コンピュータでエッジ トランスポートの役割が実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

Exchange 2007 の役割をインストールしようとしたときに、このサーバーに既にゲートウェイ サーバーの役割がインストールされていることが検出されたため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、Microsoft Exchange ゲートウェイ サーバーの役割がインストールされているサーバーには他のサーバーの役割をインストールできません。

Microsoft Exchange ゲートウェイ サーバーの役割は、組織の境界ネットワークに展開され、インターネットに面するすべてメール フローを処理します。また、信頼できる Microsoft Exchange 組織間で送信されるメッセージの暗号化や解読を行うと共に、スパムからも保護します。

この問題を解決するには、他の Microsoft Exchange 2007 の役割を、ゲートウェイ サーバーの役割がインストールされていないコンピュータにインストールします。


ローカル コンピュータで Windows Server 2003 Web Edition が実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ローカル コンピュータで Microsoft Windows Server™ 2003, Web Edition が実行されているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、サポートされているオペレーティング システムを実行しているコンピュータ上に Microsoft Exchange をインストールする必要があります。

この問題を解決するには、Web Edition 以外の Windows Server 2003 Service Pack 1 (SP1) 以降に Microsoft Exchange をインストールする必要があります。


ローカル ドメインを更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

ログオン ユーザーがドメインの準備に必要なアカウントのアクセス許可を持っていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange セットアップ プログラムを実行するには、Setup /PrepareDomain の実行時にログオンするユーザーが、Domain Administrators と Exchange Organization Administrators グループ、または Enterprise Admins グループのメンバである必要があります。

この問題を解決するには、ログオン ユーザーに Domain Admins と Exchange Organization Administrator のアクセス許可を与えるか、このユーザーを Enterprise Admins グループに登録します。または、これらのアクセス許可を持つアカウントを使用してログオンした後、Exchange 2007 セットアップ プログラムを再実行します。

Microsoft Exchange に必要な Active Directory アクセス許可の詳細については、Exchange Server における Active Directory アクセス許可の操作についてのページ (http://go.microsoft.com/fwlink/?LinkId=47592) を参照してください (このサイトは英語の場合があります)。


ローカルのメタベースにアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ローカルのメタベースからデータを読み取ることができなかったため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、メールボックス サーバーまたはクライアント アクセスの役割のインストールで、Microsoft インターネット インフォメーション サービス (IIS) メタベースからデータを読み取ることができる必要があります。

IIS メタベースには、HTTP のプロトコル設定、メールボックスやモバイル デバイス アクセスのための仮想ディレクトリ、HTTP セキュリティ設定などの、Microsoft Exchange に影響を与える情報が含まれています。

この問題を解決するには、IIS が正しくインストールされていることを確認した後、Microsoft Exchange セットアップ プログラムを再実行します。

IIS が正しくインストールされていることを確認するには、以下の文書を参照してください。

  • Microsoft サポート技術情報の文書番号 843093「Exchange 2000 Server または Exchange Server 2003 を実行している Windows 2000 Server ベースのコンピュータでの IIS メタベース破損のトラブルシューティング方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=843093)

  • Microsoft サポート技術情報の文書番号 240225「メタベースを修正する Adsutil と MetaEdit ユーティリティ」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=240225)

  • Microsoft サポート技術情報の文書番号 317678「[HOWTO] Exchange 2000 Server で Internet Information Services (IIS) を再起動する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=317678)

これらの文書の指示に従っても問題が解決されない場合は、IIS をアンインストールしてから再インストールすることが必要になる場合があります。

コントロール パネルの [Windows コンポーネントの追加と削除] を使用して IIS をアンインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] をクリックします。

  7. [次へ] をクリックします。

  8. IIS がアンインストールされたら、[完了] をクリックします。
コントロール パネルを使用して IIS をインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにします。

  5. [詳細] をクリックします。

  6. [インターネット インフォメーション サービス マネージャ] チェック ボックスをオンにします。

  7. [Windows コンポーネント ウィザード] に戻るまで、[OK] をクリックします。

  8. [次へ] をクリックし、Windows コンポーネント ウィザードを完了します。


ログオン ユーザーがローカルの Administrators グループのメンバではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ログオン ユーザーがローカル コンピュータの Administrators グループのメンバではないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、Microsoft Exchange をインストールするログオン ユーザーがローカル コンピュータへのフル アクセスを持っている必要があります。

この問題を解決するには、ローカルの管理者アクセス権を持つアカウントを使用してコンピュータにログオンし、Microsoft Exchange セットアップ プログラムを再実行します。


ログオン ユーザーが Schema Admins グループのメンバではない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-09-06

スキーマ更新プロセスに Active Directory® ディレクトリ サービスの Schema Admins グループのメンバと Enterprise Admins グループのメンバの資格情報が存在しないため、Microsoft® Exchange Server 2007 セットアップを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、Microsoft Exchange をインストールするログオン ユーザーが Active Directory フォレストの Schema Admins グループのメンバと Enterprise Admins グループのメンバの資格情報を持っている必要があります。

Microsoft Exchange セットアップ プログラムでは、インストール処理の一環として、Active Directory スキーマを拡張して Exchange 2007 固有のクラスと属性を追加します。

ログオン ユーザーが Schema Admins グループのメンバと Enterprise Admins グループのメンバの権限を持っていない場合、スキーマ更新プロセスは失敗します。

この問題を解決するには、ログオン ユーザーを Schema Admins グループと Enterprise Admins グループに追加して、再度ログオフし、ログオンするか、または既に Active Directory フォレストの Schema Admins グループのメンバと Enterprise Admins グループのメンバの資格情報を持っているアカウントを使用してログオンします。


アクティブ ノードが多すぎる
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-23

新しいアクティブ クラスタのメールボックス サーバーの役割を作成しようとして失敗したため、Microsoft Exchange Server 2007 のセットアップ プログラムを続行できません。

Exchange Server 2007 では、障害回復をサポートするために、クラスタの中で少なくとも 1 つのノードがパッシブである必要があります。

この問題に対処するには、別のパッシブ クラスタ化メールボックス サーバーの役割を環境にインストールしてから、セットアップ プログラムを再実行します。

アクティブ ノードとパッシブ ノードのインストールの詳細については、Exchange Server 2007 製品ドキュメントの高可用性についてのページ (http://go.microsoft.com/fwlink/?LinkId=68190) を参照してください (このサイトは英語の場合があります)。


メールボックス データベースのドライブの仕様が見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-15

このサーバーの以前のインストールで使用されたメールボックス データベース ドライブの仕様にアクセスできないため、Microsoft® Exchange Server 2007 障害回復セットアップ プログラムを続行できません。

Microsoft Exchange 障害回復セットアップ プログラムを実行するには、以前このサーバーに対して使用したものと同じメールボックス データベース ドライブの仕様が、復元時に使用できる必要があります。

この問題を解決するには、ドライブを元の論理ドライブ構成に一致するように構成した後、Microsoft Exchange 障害回復セットアップ プログラムを再実行します。

ドライブ文字の割り当てまたは変更

  1. [コンピュータの管理 (ローカル)] を開きます。

  2. コンソール ツリーで、[コンピュータの管理 (ローカル)] をクリックし、[記憶域] をクリックします。次に、[ディスクの管理] をクリックします。

  3. パーティション、論理ドライブ、またはボリュームを右クリックし、[ドライブ文字とパスの変更] をクリックします。

  4. 以下のいずれかの手順を使用します。

    • ドライブ文字を割り当てるには、[追加] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

    • ドライブ文字を変更するには、そのドライブ文字をクリックし、[変更] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

ドライブ文字を割り当てる方法の詳細については、ドライブ文字の割り当て、変更、または削除についてのページ (http://go.microsoft.com/fwlink/?LinkId=66764) を参照してください (このサイトは英語の場合があります)。


1 つ以上のキューにメッセージが存在している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

トランスポートの役割をアンインストールする際にトランスポート キューからデータが失われる可能性がある場合、Microsoft® Exchange Server 2007 セットアップ プログラムによってこの警告が表示されます。

Exchange 2007 セットアップ プログラムは、トランスポート キューの管理に関連する役割を削除する前に、トランスポート キューが空であることを確認します。

トランスポート キューに残っているメッセージを配信する前にトランスポートの役割を削除すると、そのメッセージはキューに格納され続けることになります。

この問題を解決するには、セットアップを続行する前に、該当するキューにメッセージが存在しないことを確認してください。

キューの内容を表示するには、次の操作を行います。

  1. Exchange 管理コンソールを開きます。

  2. コンソール ツリーで、[ツールボックス] をクリックします。

  3. 結果ペインで、[Exchange キュー ビューア] をクリックします。

  4. アクション ペインで、[Open Tool] をクリックします。

  5. キュー ビューアで、[キュー] タブをクリックします。接続しているサーバー上のすべてのキューの一覧が表示されます。

  6. 目的のキューを右クリックし、[プロパティ] をクリックしてキューのプロパティを表示します。
キューにあるメッセージを表示するには、次の操作を行います。

  1. 上記の手順 1. ～ 4. を実行します。

  2. キュー ビューアで、[メッセージ] タブをクリックします。接続しているサーバー上のすべてのメッセージの一覧が表示されます。表示内容を 1 つのキューのみに絞り込むには、[キュー] タブをクリックし、キューの名前をダブルクリックします。次に、表示される [Server\Queue] タブをクリックします。

  3. メッセージの詳細情報を表示するには、メッセージを選択し、アクション ペインで [プロパティ] をクリックします。


Microsoft .NET Framework を更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-02-26

ローカル コンピュータでソフトウェアの更新が必要なため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータに以下の Microsoft .NET Framework の更新プログラムをインストールする必要があります。

この問題を解決するには、Exchange 2007 のセットアップを終了し、以下の URL から適切な更新プログラム (32 ビットまたは 64 ビット) をダウンロードしてインストールしてから、Exchange 2007 のセットアップ プログラムを再実行します。

注 :
以下のリンクをクリックすると、ファイルを直接ダウンロードするよう求められます。
  • 64 ビット ダウンロード - http://go.microsoft.com/fwlink/?linkid=74465

  • 32 ビット ダウンロード - http://go.microsoft.com/fwlink/?linkid=74469


Microsoft Core XML Services (MSXML) 6.0 が必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-21

サーバーに Microsoft Core XML Services (MSXML) 6.0 がインストールされていないため、Microsoft® Exchange Server 2007 のセットアップ プログラムを続行できません。

Exchange 2007 のセットアップ プログラムですべてのユニファイド メッセージング サーバーの役割をインストールためには、Microsoft 音声認識サービスをサポートするコンピュータに MSXML 6.0 がインストールされている必要があります。

この問題を解決するには、http://go.microsoft.com/fwlink/?LinkId=70796 から MSXML 6.0 ソフトウェアをインストールしてから、Exchange 2007 のセットアップ プログラムを再実行します。


MNSFileShare パスが無効である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

MNSFileShare パスが無効であるため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

MNSFileShare 値は、クラスタの外部にあるファイル共有の汎用名前付け規則 (UNC) パスを含む文字列値 (\\<サーバー>\<共有名> など) に設定する必要があります。

この問題に対処するには、MNSFileShare プロパティに、有効な UNC パスである値を指定します。

MNSFileShare プロパティの構成方法の詳細については、ファイル共有監視機能の構成方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=78278) を参照してください (このサイトは英語の場合があります)。


MSDAPS.DLL を更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-12-05

ローカル コンピュータでソフトウェアの更新が必要なため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、ローカル コンピュータに以下の MSDAPS.DLL 更新プログラムをインストールする必要があります。

この問題を解決するには、以下のリンクから更新プログラムをダウンロードしてインストールしてから、Exchange 2007 のセットアップ プログラムを再実行します。

  • http://go.microsoft.com/fwlink/?linkid=74467


Network News Transport サービスが現在インストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-22

このコンピュータに Microsoft Windows® Server™ 2003 の NNTP (Network News Transfer Protocol) サービスがインストールされているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Exchange 2007 に使用するサーバーに NNTP サービスがインストールされていないようにする必要があります。

この問題を解決するには、NNTP サービスをアンインストールしてから Microsoft Exchange セットアップ プログラムを再実行します。

コントロール パネルの [Windows コンポーネントの追加と削除] を使用して NNTP サービスをアンインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにし、[詳細] をクリックします。

  5. [インターネット インフォメーション サービス マネージャ] を選択し、[詳細] をクリックします。

  6. [NNTP サービス] を選択し、チェック ボックスをオフにします。

  7. [OK] を 2 回クリックして [コンポーネント] ボックスの一覧に戻り、[次へ] をクリックします。

  8. NNTP サービスがアンインストールされたら、[完了] をクリックします。


クライアント アクセス サーバーの役割が見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-02-16

Microsoft Exchange アナライザ ツールは、Exchange Server 2007 固有の管理グループ識別子 FYDIBOHF23SPDLT を含む Exchange 組織内の msExchAdminGroupContainer クラスのオブジェクトの値について、Active Directory ディレクトリ サービスに対してクエリを実行します。

Exchange 組織に Exchange Server 2007 管理グループがあると判断すると、Exchange アナライザは、各 msExchExchangeServer オブジェクトの msExchCurrentServerRoles 属性の値について、組織内のすべての Active Directory サイトに対してクエリを実行し、検出されたサイトにメールボックス サーバーの役割がインストールされているかどうかを判断します。

最後に、メールボックス サーバーの役割がサイトにインストールされていると判断すると、Exchange アナライザはそのサイト内の各 msExchExchangeServer オブジェクトの msExchCurrentServerRoles 属性に対してクエリを実行し、同じサイトにクライアント アクセス サーバーの役割もインストールされているかどうかを判断します。

クライアント アクセス サーバーの役割がインストールされていない Active Directory サイトにメールボックス サーバーの役割がインストールされていると判断されると、警告が表示されます。

この警告は、Active Directory サイトにメールボックス サーバーの役割がインストールされていても、少なくとも 1 つのクライアント アクセス サーバーの役割が同じサイトにインストールされるまで、Microsoft Office Outlook Web Access および Exchange ActiveSync モバイル デバイス アクセス クライアントが、そのメールボックス サーバー上のメールにアクセスできないことを示します。

クライアント アクセス サーバーの役割は、さまざまなクライアントから Exchange 2007 サーバーへの接続を受け付けます。Microsoft Outlook Express や Eudora などのソフトウェア クライアントは、POP3 接続または IMAP4 接続を使用して Exchange サーバーと通信します。モバイル デバイスなどのハードウェア クライアントは、ActiveSync、POP3、または IMAP4 を使用して Exchange サーバーと通信します。

ユーザーが Microsoft Outlook 以外のクライアントを使用して受信トレイにアクセスする場合は、Exchange 組織にクライアント アクセス サーバーの役割をインストールする必要があります。

この警告に対処するには、Microsoft Outlook を使用せずにメールボックスにアクセスするクライアントが存在する場合は、メールボックス サーバーの役割がインストールされているサイトにクライアント アクセス サーバーの役割をインストールします。

詳細情報

サイトにクライアント アクセス サーバーの役割をインストールする方法の詳細については、Exchange Server 2007 製品ドキュメントの、サーバーの役割の展開についてのページ (http://go.microsoft.com/fwlink/?LinkId=83282) を参照してください (このサイトは英語の場合があります)。


非標準のアドレス スペースがある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-21

Microsoft® Exchange Server アナライザ ツールは、1 つ以上の受信者ポリシーに非標準のアドレス スペースがあることを検出した場合に、この警告を表示します。

非標準 (プロキシ) のアドレス スペースは、Exchange Server 受信者オブジェクトが外部メッセージング システムで認識されるためのアドレスです。

以前のバージョンの Exchange Server では、非標準のアドレス スペースのサポートは受信者更新サービスが行っていました。

Microsoft Exchange Server 2007 では、受信者更新サービスは実装されません。プロキシ アドレスの生成は Exchange 2007 管理コンソールで行われます。

管理コンソールには、検出された非標準のアドレス スペースことにプロキシ生成 DLL が読み込まれている必要があります。

重要 :
管理コンソールが 64 ビット コンピュータ上で動作している場合は、64 ビット版のプロキシ生成 DLL が必要になります。

この警告に対処するには、外部アドレス スペースをサポートするベンダに問い合わせて、Exchange 2007 互換のプロキシ生成 DLL を入手します。


スキーマ マスタ サイト/ドメインにない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-10

セットアップ プログラムを実行するコンピュータ (FSMO (Flexible Single Master Operation) とも呼ばれる) が、ドメイン スキーマ マスタの役割を割り当てられたサーバーと同じ Active Directory® ディレクトリ サービス サイトまたはドメインにないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、Exchange セットアップ プログラムを実行するローカル コンピュータと同じサイトおよびドメイン内にあるドメイン スキーマ マスタとして機能するドメイン コントローラが必要です。

ドメイン スキーマ マスタは、Active Directory スキーマに対するすべての更新と変更を制御します。

この問題を解決するには、ドメイン スキーマ マスタと同じサイトおよびドメインから Exchange Server 2007 セットアップ プログラムを実行します。

スキーマ マスタ ツールを使用して役割を識別することができます。ただし、スキーマ ツールを MMC スナップインとして使用できるようにするには、Schmmgmt.dll DLL を登録する必要があります。

現在のスキーマ マスタを表示するには

  1. コマンド プロンプトで、「regsvr32 schmmgmt.dll」と入力します。

    注 :
    次のダイアログ ボックスが表示される場合、RegSvr32 は正常に登録されています。

    [DllRegisterServer in schmmgmt.dll succeeded.]

  2. 新しい管理コンソールを開くには、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、「mmc」と入力します。

  3. コンソールのメニューで、[スナップインの追加と削除] をクリックします。

  4. [追加] をクリックし、[スタンドアロン スナップインの追加] ダイアログ ボックスを開きます。

  5. [Active Directory スキーマ] を選択し、[追加] をクリックします。

  6. 「Active Directory スキーマ」が [スナップインの追加と削除] に表示されます。[閉じる] をクリックし、[OK] をクリックして、コンソールに戻ります。

  7. [Active Directory スキーマ] を選択すると、[クラス] と [属性] セクションが右側に表示されます。

  8. [Active Directory スキーマ] を右クリックし、[操作マスタ] をクリックします。

  9. 現在のスキーマ マスタが表示されます。


ドメイン内に Windows Server 2003 SP1 ドメイン コントローラがない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

準備するドメイン内で、setup /PrepareLegacyExchangePermissions プロセスが、Microsoft Windows Server 2003 Service Pack 1 (SP1) 以降のバージョンを実行しているドメイン コントローラを見つけることができなかったため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

setup /PrepareLegacyExchangePermissions を実行する各ドメイン内で、セットアップ プログラムは Windows Server 2003 SP1 ドメイン コントローラと通信する必要があります。少なくとも 1 つの Windows Server 2003 SP1 ドメイン コントローラが見つからないと、Setup /PrepareLegacyExchangePermissions は正常に完了しません。

setup /PrepareLegacyExchangePermissions コマンドを実行すると、従来の受信者更新サービスを正常に機能させることができます。Exchange 2007 では、新しい Exchange 2007 スキーマをインポートする前に、Exchange Server 2003 または Exchange 2000 Server の DomainPrep が実行されていた各ドメイン内で新しいアクセス許可を付与する必要があります。setup /PrepareLegacyExchangePermissions コマンドはこれらの新しいアクセス許可を付与します。

この問題を解決するには、setup /PrepareLegacyExchangePermissions を実行する各ドメイン内で、少なくとも 1 つのドメイン コントローラを Windows Server 2003 SP1 以降のバージョンにアップグレードしてから、セットアップ プログラムを再実行します。

従来の Exchange アクセス許可を準備する方法の詳細については、Exchange Server 2007 製品ドキュメントの、従来の Exchange アクセス許可の準備についてのページ (http://go.microsoft.com/fwlink/?linkid=81776) を参照してください (このサイトは英語の場合があります)。


OAB サーバーが削除されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-21

クライアント アクセス サーバーの役割をインストールしようとして失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。オフライン アドレス帳 (OAB) をホストするように指定された Exchange メールボックス サーバーが削除されています。

Exchange 2007 セットアップ プログラムでクライアント アクセス サーバーの役割のインストールを続行するには、OAB の生成をホストする有効な Exchange メールボックス サーバーが存在する必要があります。

この問題を解決するには、有効な Exchange メールボックス サーバーを OAB 生成ホストとして指定してから、Exchange 2007 セットアップ プログラムを再実行します。

オフライン アドレス帳生成のホストとなる Exchange サーバーを指定する方法については、Exchange 2007 製品ドキュメントのオフライン アドレス帳の作成方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86314) を参照してください (このサイトは英語の場合があります)。


古いデータベース ファイルが存在している
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

対象のインストール パスに既存の Microsoft Exchange データベース ファイルが検出されたため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、対象のインストール パスに Microsoft Exchange データベース ファイルが存在しない状態になっている必要があります。

この問題を解決するには、対象のインストール パスから既存のすべてのファイルを削除した後、セットアップ プログラムを再実行します。

対象のインストール パスから既存の Exchange Server データベース ファイルを削除するには、次の操作を行います。

  1. [マイ コンピュータ] またはエクスプローラで、対象のインストール パスを見つけます。

    注 :
    既定では、データベース ファイルは次の場所にあります。

    <システム ドライブ>:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group

  2. 削除するファイルを右クリックし、[削除] を選択します。

  3. [ファイルの削除の確認] ダイアログ ボックスで、[はい] をクリックします。

  4. 対象のインストール パスにあるすべてのファイルに対して、手順 2. と 3. を繰り返します。


古いバージョンの ADAM が検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

ゲートウェイ サーバーの役割をインストールする際に、現在のサーバー上で古いバージョンの ADAM (Active Directory® Application Mode) が検出された場合、Microsoft® Exchange Server 2007 セットアップ プログラムによってこの警告が表示されます。

ADAM は、ディレクトリが有効なアプリケーションで使用するように特別に設計されたライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリ サービスです。ADAM はアプリケーション固有の情報のみを格納およびレプリケートするため、ドメイン コントローラ上に展開する必要はなく、Active Directory サービスにも依存しません。ADAM は、ネットワーク オペレーティング システムの認証や承認を行いません。

Exchange 2007 では、ゲートウェイ サーバーは ADAM を使用して構成情報を格納します。ADAM を Active Directory と同期させた場合は、ADAM を使用して、メッセージ セキュリティのために受信者参照を実行することもできます。

Exchange 2007 セットアップでは、ADAM は自動的に Service Pack 1 (SP1) バージョンにアップグレードされます。

ADAM のアップグレードを行わない場合を除き、特に操作は必要ありません。ADAM のアップグレードを行わない場合は、ローカル コンピュータにゲートウェイ サーバーの役割をインストールしないでください。


1 つ以上の Active Directory コネクタ サーバーが見つかった
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

現在の Microsoft Exchange 環境で 1 つ以上の Active Directory コネクタ (ADC) が見つかったため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

ADC は混在モードの Microsoft Exchange 環境で Exchange Server Version 5.5 から Active Directory® ディレクトリ サービスにオブジェクトをレプリケートします。これは Exchange 2007 ではサポートされていません。

Exchange 2007 セットアップ プログラムを実行するには、すべての ADC コンポーネントを削除する必要があります。

この問題を解決するには、すべての ADC コンポーネントを削除してから、Exchange 2007 セットアップ プログラムを再実行します。

Active Directory コネクタ コンポーネントを削除するには、次の操作を行います。

  1. ADC サービスを実行しているサーバーで ADC サービスを無効にするには、デスクトップの [マイ コンピュータ] を右クリックし、[管理] をクリックします。

  2. [サービスとアプリケーション] ノードを展開し、[サービス] ノードをクリックします。

  3. 右側のペインで [Microsoft Active Directory Connector] を右クリックし、[プロパティ] をクリックします。

  4. [スタートアップの種類] を [無効] に変更します。これにより、次回コンピュータを起動する際に ADC サービスが開始されなくなります。

  5. [適用] をクリックし、[OK] をクリックします。

  6. ADC サービスをアンインストールするには、Microsoft Exchange 2000 Server または Microsoft Exchange Server 2003 の CD に含まれている Active Directory インストール ウィザードを使用します。\ADC\I386 フォルダを開き、Setup.exe プログラムをダブルクリックします。表示されるメッセージに従って、ADC サービス コンポーネントをすべて削除します。

    重要 :
    この問題を解決するには、手順 6. を完了して ADC コンポーネントをすべて削除する必要があります。ADC サービスを無効にするだけでは不十分です。

ADC の詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • 文書番号 325300「サポート : Active Directory コネクタの概要」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325300)

  • 文書番号 325221「サポート : Active Directory コネクタを詳細 Microsoft」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325221)

  • 文書番号 312632「[HOW TO] Exchange 2000 Server で Active Directory コネクタをインストールおよび構成する方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=312632)


存在可能な CCR サーバーは 1 つのみである
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

新しいクラスタ化メールボックス サーバーの作成が失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange Server 2007 では、クラスタ連続レプリケーション (CCR) クラスタ内に存在できるクラスタ連続レプリケーションのクラスタ化メールボックス サーバーは 1 つだけです。この CCR クラスタには、クラスタ化メールボックス サーバーが既に存在しています。

この問題を解決するには、このクラスタに追加のクラスタ連続レプリケーションのクラスタ化メールボックス サーバーをインストールしないようにしてください。

CCR 環境へのクラスタ化メールボックス サーバーのインストールに関する詳細については、Exchange Server 2007 製品ドキュメントの、アクティブ ノードにメールボックス サーバーの役割をインストールする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86624) を参照してください (このサイトは英語の場合があります)。


クラスタ サーバーにはメールボックスの役割しかインストールできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-07

このクラスタ化されたサーバーにメールボックス サーバーの役割以外の役割をインストールする試みが失敗したため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange では、クラスタ サービスがインストールされているサーバー上でメールボックス サーバーの役割以外の Exchange 2007 の役割はサポートされていません。

この問題を解決するには、Exchange Server 2007 運用ガイドについてのページ (http://go.microsoft.com/fwlink/?LinkId=68190) の、Exchange 2007 の可用性向上に関するセクションを参照してください (このサイトは英語の場合があります)。


組織が混在モードになっている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-15

既存の Microsoft Exchange 組織がネイティブ モードではないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、既存の Exchange 組織がネイティブ モードである必要があります。

この問題を解決するには、既存の組織の Exchange Server Version 5.5 がアップグレードされた後か、Exchange 5.5 サーバーが使用停止になる前に、次の手順に従います。続いて、Exchange 2007 セットアップ プログラムを再実行します。

注 :
ネイティブ モードに切り替えた後で混在モードに戻すことはできません。
ネイティブ モードに切り替えるには、次の操作を行います。

  1. Exchange システム マネージャを起動します。[スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Exchange] をポイントし、[システム マネージャ] をクリックします。

  2. コンソール ツリーで、ネイティブ モードに切り替える組織を右クリックし、[プロパティ] をクリックします。

  3. [<組織名> のプロパティ] ダイアログ ボックスで、[処理モードの変更] の [モードの変更] をクリックします。

  4. ネイティブ モードに完全に切り替える場合は、警告ダイアログ ボックスで [はい] をクリックします。[適用] をクリックして、新しい Exchange モードに切り替えます。

Exchange のネイティブ モードを最大限に活用するには、組織内のすべての Exchange サーバーで、Microsoft Exchange Information Store サービスを再開する必要があります。すべての Microsoft Exchange Information Store サービスを同時に再開する必要はありませんが、サーバーで Exchange ネイティブ モードの機能をすべて利用するには、それぞれのサーバーでサービスを再開する必要があります。ネイティブ モードへの変更がローカルの Microsoft Windows® ドメイン コントローラにレプリケートされた後で、サーバーのサービスを再開します。

Microsoft Exchange Information Store サービスを再開するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「services.msc」と入力し、[OK] をクリックします。

  2. [サービス (ローカル)] ペインで、[Microsoft Exchange Information Store] サービスを見つけます。

  3. このサービスを右クリックし、[再開] をクリックします。

混在モードからネイティブ モードに変更する方法の詳細については、Microsoft サポート技術情報の文書番号 327779「[HOWTO] Exchange で混在モードからネイティブ モードに変換する」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=327779) を参照してください。


プライマリ DNS サーバーに接続できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

プライマリ ドメイン ネーム システム (DNS) サーバーとの通信を確立できないため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムでは、ローカル コンピュータが、ドメインに対して権限のある DNS データベースと通信する必要があります。

Microsoft Exchange は、内部または外部にある次の送信先サーバーの IP アドレスを解決するために DNS を使用します。

以下の理由によって、プライマリ DNS サーバーとの通信が失敗することがあります。

  • ローカルの TCP/IP 構成が正しい DNS サーバーを示していない。

  • ネットワーク障害やその他の原因により DNS サーバーが停止しているか、または DNS サーバーに到達できない。

この問題を解決するには、次の操作を行います。

  • ローカルの TCP/IP 構成が正しい DNS サーバーを示していることを確認します。

ローカルの TCP/IP 構成を確認するには、次の操作を行います。

  1. ローカルの TCP/IP 構成を見直します。

    詳細については、DNS を使用する場合の TCP/IP 構成についてのページ (http://go.microsoft.com/fwlink/?LinkId=68094) を参照してください (このサイトは英語の場合があります)。
  • DNS サーバーが稼働しており、接続可能なことを確認します。

DNS サーバーが稼働しており、接続可能なことを確認するには、次の操作を行います。

  1. 次の 1 つ以上のチェックを行うことにより、DNS サーバーが稼働していることを確認します。

    • DNS サーバー上の DNS 管理プログラムから、DNS サーバーの状態を調べます。

    • DNS サーバーを再起動します。

      詳細については、DNS サーバーの起動、停止、一時停止、または再起動についてのページ (http://go.microsoft.com/fwlink/?LinkId=62999) を参照してください (このサイトは英語の場合があります)。

    • nslookup コマンドを使用して、DNS サーバーが応答するかどうかを確認します。

      詳細については、nslookup コマンドを使用して DNS サーバーの応答を確認する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=63000) を参照してください (このサイトは英語の場合があります)。


パブリック フォルダ データベース ドライブの仕様が見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-15

このサーバーの以前のインストールで使用されたパブリック フォルダ データベース ドライブの仕様にアクセスできないため、Microsoft® Exchange Server 2007 障害回復セットアップ プログラムを続行できません。

Microsoft Exchange 障害回復セットアップ プログラムを実行するには、以前このサーバーに対して使用したものと同じパブリック フォルダ データベース ドライブの仕様が、復元時に使用できる必要があります。

この問題を解決するには、ドライブを元の論理ドライブ構成に一致するように構成した後、Microsoft Exchange 障害回復セットアップ プログラムを再実行します。

ドライブ文字の割り当てまたは変更

  1. [コンピュータの管理 (ローカル)] を開きます。

  2. コンソール ツリーで、[コンピュータの管理 (ローカル)] をクリックし、[記憶域] をクリックします。次に、[ディスクの管理] をクリックします。

  3. パーティション、論理ドライブ、またはボリュームを右クリックし、[ドライブ文字とパスの変更] をクリックします。

  4. 以下のいずれかの手順を使用します。

    • ドライブ文字を割り当てるには、[追加] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

    • ドライブ文字を変更するには、そのドライブ文字をクリックし、[変更] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

ドライブ文字を割り当てる方法の詳細については、ドライブ文字の割り当て、変更、または削除についてのページ (http://go.microsoft.com/fwlink/?LinkId=66764) を参照してください (このサイトは英語の場合があります)。


クラスタ ノードのレジストリにリモートからアクセスできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-13

クラスタ ノードのレジストリにアクセスできなかったため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、クラスタ内のすべてのノードのレジストリにアクセスして、さまざまな設定を取得する必要があります。

この問題に対処するには、次の操作を行います。

  • クラスタ内のすべてのノードでリモート レジストリ サービスが実行されていることを確認します。

  • ネットワーク アダプタで、バインド順序の一番上にある [Microsoft ネットワーク用ファイルとプリンタ共有] が有効であることを確認します。

  • クラスタ内のすべてのノードで、以下のレジストリ キーの値が同じであり、関連するグループ ポリシーに対して有効であることを確認します。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\parameters\RequireSecuritySignature

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature

レジストリの接続の問題をトラブルーシューティングする方法の詳細については、Microsoft Exchange Server ベスト プラクティス アナライザ ツールによる接続の問題のトラブルシューティングについてのページ (http://go.microsoft.com/fwlink/?linkid=56285) のレジストリの接続に関する問題のトラブルシューティングについてのセクションを参照してください (このサイトは英語の場合があります)。


サーバーの役割をアンインストールする前にエッジ サブスクリプションを削除する
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-21

サーバーの役割にエッジ サブスクリプションがあることが原因で、エッジまたはハブ トランスポート サーバーの役割のアンインストール処理に失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

エッジ トランスポート サーバーを Exchange 組織に関連付けるには、Active Directory サイトに対してエッジ トランスポート サーバーを購読します。購読済みのエッジ トランスポート サーバーには、Active Directory サイト属性がスタンプされます。特に、この関連付けによって、Exchange 組織内で作成された送信コネクタのソース サーバーとして、エッジ サブスクリプションを構成することができます。Exchange 組織内のハブ トランスポート サーバーは、暗黙的な組織内の送信コネクタを使用し、購読済みのエッジ トランスポート サーバーを介して電子メール メッセージをインターネットにルーティングします。Active Directory サイトの関連付けによって、ハブ トランスポート サーバーはルーティング用のエッジ トランスポート サーバーを特定することができます。

Exchange 2007 セットアップ プログラムでは、エッジまたはハブ トランスポート サーバーの役割をアンインストールする前に、対象のエッジ トランスポート サーバーの役割またはサイト内の最後のハブ トランスポート サーバー役割のすべてのエッジ サブスクリプションを削除する必要があります。

このエラーに対処するには、Get-EdgeSubscription コマンドレットを使用してエッジ サブスクリプションに関する情報を取得し、Remove-EdgeSubscription コマンドレットを使用して対象のサーバーからエッジ サブスクリプションを削除します。それから、Exchange 2007 セットアップ プログラムを再実行します。

エッジ サブスクリプションを特定し、削除するには、次の操作を行います。

  1. Get-EdgeSubscription (http://go.microsoft.com/fwlink/?LinkId=86320) コマンドレットのトピックの指示に従って、対象のサーバーのエッジ サブスクリプションを特定します (このサイトは英語の場合があります)。

  2. Remove-EdgeSubscription (http://go.microsoft.com/fwlink/?LinkId=86321) コマンドレットのトピックの指示に従って、対象のサーバーからエッジ サブスクリプションを削除します (このサイトは英語の場合があります)。


スキーマ FSMO が Windows Server 2003 Service Pack (SP1) 以上でない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービス フォレストを調べて、Active Directory ドメイン コントローラ スキーマ マスタで実行されているサーバー オペレーティング システムのバージョンを確認します。Flexible Single Master Operation (FSMO) とも呼ばれる Active Directory オペレーション マスタ ドメイン コントローラで Microsoft Windows Server™ 2003 Service Pack 1 (SP1) 以降のバージョンが実行されていないことが Exchange Server アナライザによって検出されると、エラーが表示されます。

このエラーは、Microsoft Exchange Server 2007 をインストールするには、Windows Server 2003 SP1 以降のバージョンが必要であることを表します。Exchange 2007 の新たなアクセス許可構造をサポートするには、Windows Server 2003 SP1 以降のバージョンが必要です。

Active Directory スキーマ FSMO ドメイン コントローラで Windows Server 2003 SP1 以降のバージョンが実行されていない場合、Exchange 2007 のインストールはセットアップ時にエラーになります。

このメッセージは、Exchange 2007 の展開前に行う前提条件チェックです。Exchange 2007 のインストールを予定している場合は、フォレスト全体の Active Directory ドメイン コントローラ スキーマ マスタで Windows Server 2003 SP1 以降のバージョンを実行するようにしてください。


スキーマ マスタで Windows 2000 Server が実行されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-08

FSMO (Flexible Single Master Operation) とも呼ばれる Active Directory® ディレクトリ サービス スキーマ マスタの役割が割り当てられたドメイン コントローラで Microsoft Windows® 2000 Server が実行されているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、スキーマ FSMO として機能するドメイン コントローラで Microsoft Windows Server™ 2003 Service Pack 1 (SP1) 以降のバージョンが実行されている必要があります。

FSMO は、Active Directory スキーマに対するすべての更新と変更を制御します。

この問題を解決するには、FSMO ドメイン コントローラを Windows Server 2003 SP1 以降のバージョンのサーバーにアップグレードまたは移行した後、Microsoft Exchange セットアップ プログラムを再実行します。

詳細については、Microsoft サポート技術情報の文書番号 325379「Windows 2000 ドメイン コントローラを Windows Server 2003 にアップグレードする方法」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=325379) を参照してください。

インフラストラクチャ マスタの役割をあるドメイン コントローラから別のドメイン コントローラに転送することに関する詳細については、以下の Microsoft サポート技術情報の文書を参照してください。

  • Microsoft Windows Server™ 2003 については、文書番号 324801「[HOWTO] Windows Server 2003 で FSMO の役割を確認して転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=324801) を参照してください。

  • Microsoft Windows 2000 Server については、文書番号 255690「グラフィカル ユーザー インターフェイスで FSMO 役割を表示し転送する方法」(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=255690) を参照してください。


スキーマ マスタが Windows Server 2003 Service Pack 1 以降を実行していない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

FSMO (Flexible Single Master Operation) とも呼ばれる、Active Directory ディレクトリ サービス スキーマ マスタの役割が割り当てられたドメイン コントローラで、Microsoft Windows Server 2003 Service Pack 1 (SP1) 以降のバージョンが実行されていないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、スキーマ FSMO として機能するドメイン コントローラで Windows Server 2003 SP1 以降のバージョンが実行されている必要があります。

FSMO は、Active Directory スキーマに対するすべての更新と変更を制御します。

この問題を解決するには、次のいずれかの操作を行います。

  • FSMO ドメイン コントローラを Windows Server 2003 SP1 以降のバージョンにアップグレードした後、Microsoft Exchange セットアップ プログラムを再実行します。

  • Microsoft Windows Server 2003 Service Pack 1 (SP1) 以降のバージョンを実行している FSMO ドメイン コントローラが Exchange 組織内にある場合は、その FSMO ドメイン コントローラを指す /domaincontroller パラメータを指定して Exchange 2007 セットアップ プログラムを実行します。

    [/DomainController、または /dc <ドメイン コントローラの FQDN>]

    /DomainController パラメータを使用して、セットアップ時に Active Directory との読み書きに使用するドメイン コントローラを指定します。NetBIOS 形式または完全修飾ドメイン名 (FQDN) 形式を使用できます。

Windows Server 2003 の最新の Service Pack の入手については、Windows Server TechCenter のページ (http://go.microsoft.com/fwlink/?LinkId=45315) を参照してください (このサイトは英語の場合があります)。

Exchange Server 2007 セットアップ プログラムのパラメータの詳細については、Exchange Server 2007 製品ドキュメントの、Exchange 2007 を無人インストールする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86476) を参照してください (このサイトは英語の場合があります)。


Setup Cannot Install Exchange to a Read-Only Domain Controller
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-07-23

Microsoft Exchange Server 2007 セットアップ プログラムは、インストール先のコンピュータが読み取り専用ドメイン コントローラ (RODC) であるため、インストールを続行できません。

読み取り専用ドメイン コントローラは、Windows Server 2008 Active Directory の機能です。RODC は、ドメイン コントローラ インストール オプションの 1 つの種類で、物理セキュリティのレベルが低い可能性があるリモート サイトにインストールできます。

Exchange セットアップ プログラムは、インストール先のコンピュータへの書き込みアクセスを必要とします。

この問題を解決するには、RODC として指定されていないコンピュータをインストール先として選択し、セットアップを再度実行します。


サーバーの役割のインストール中にセットアップ エラーが発生した
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-04-12

サーバーの役割のインストール中に以前のセットアップ エラーが検出されたため、Microsoft Exchange Server 2007 セットアッププログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、他のセットアップ作業を続行する前に、インストールに失敗したサーバーの役割が正しく再インストールされているか、セットアップ処理から削除されている必要があります。

この問題を解決するには、インストールに失敗したサーバーの役割を再インストールするか、サーバーの役割を削除します。

インストールに失敗したサーバーの役割をコマンド ラインから再インストールするには、次の操作を行います。

  1. コマンド プロンプト ウィンドウを開き、インストール ファイルに移動します。

  2. 次のコマンドを実行します。

    コードのコピー
    Setup /roles:<Failed Server Role>

    以下の役割から、1 つ以上の役割を選択します。複数の場合はコンマで区切ります。

    ClientAccess (CA または C)

    EdgeTransport (ET または E)

    注 :
    エッジ トランスポート サーバーの役割は、同じコンピュータ上で他のサーバーの役割と共存できません。
    注 :
    エッジ トランスポート サーバーの役割は、境界ネットワーク内および Active Directory フォレストの外側に展開する必要があります。

    HubTransport (HT または H)

    Mailbox (MB または M)

    UnifiedMessaging (UM または U)

    ManagementTools (MT または T)

    注 :
    ManagementTools を指定すると、Exchange 管理コンソール、Exchange 管理シェル用の Exchange コマンドレット、Exchange ヘルプ ファイル、Exchange ベスト プラクティス アナライザ ツール、および Exchange トラブルシューティング アシスタントがインストールされます。その他のサーバーの役割をインストールした場合、管理ツールは自動的にインストールされます。

    たとえば、既存のメールボックス サーバーにハブ トランスポート サーバーの役割を追加するには、次のように入力します。%LocalExchangeInstallationDir%\bin\Setup.com /role:HubTransport /Mode:Install

注 :
いずれかの Exchange Server 2007 サーバーの役割が以前に正しくインストールされている場合、セットアップ ウィザードは保守モードで実行されます。以前に正しくインストールされた Exchange 2007 サーバーの役割がない場合、セットアップ ウィザードは停止されたところから開始されます。
Exchange Server 2007 セットアップ ウィザードを保守モードで使用して、インストールに失敗したサーバーの役割を再インストールするには、次の操作を行います。

  1. サーバーの役割を再インストールするサーバーにログオンします。

  2. コントロール パネルを開き、[プログラムの追加と削除] をダブルクリックします。

  3. [プログラムの変更と削除] ページで、[Microsoft Exchange Server] を選択し、[変更] をクリックします。

  4. Exchange Server 2007 セットアップ ウィザードの [Exchange 保守モード] ページで、[次へ] をクリックします。

  5. [サーバーの役割の選択] ページで、インストールするサーバーの役割のチェック ボックスをオンにし、[次へ] をクリックします。

    注 :
    エッジ トランスポート サーバーの役割は、同じコンピュータ上で他のサーバーの役割と共存できません。
    注 :
    エッジ トランスポート サーバーの役割は、境界ネットワーク内および Active Directory フォレストの外側に展開する必要があります。
    注 :
    [管理ツール] を選択すると、Exchange 管理コンソール、Exchange 管理シェル用の Exchange コマンドレット、および Exchange ヘルプ ファイルがインストールされます。その他のサーバーの役割をインストールした場合、管理ツールは自動的にインストールされます。

  6. [ハブ トランスポートの役割] を選択し、既存の Exchange Server 2003 組織または Exchange 2000 Server 組織を含むフォレスト内に Exchange 2007 をインストールする場合は、[メール フローの設定] ページでルーティング グループ コネクタの作成対象となる Exchange 2003 または Exchange 2000 のルーティング グループのメンバである既存の組織内のブリッジヘッド サーバーを選択します。

  7. [インストールの前提条件の確認] ページで、状態を表示して、組織およびサーバーの役割の前提条件の確認が正しく完了したかどうかを確認します。正しく完了した場合は、[インストール] をクリックして Exchange 2007 をインストールします。

  8. [完了] ページで、[終了] をクリックします。
他のサーバーの役割が以前に正しくインストールされていない場合、Exchange Server 2007 セットアップ ウィザードを使用して、インストールに失敗したサーバーの役割を再インストールするには、次の操作を行います。

  1. Exchange Server 2007 製品ドキュメントの Exchange Server 2007 セットアップ プログラムを使用してカスタム インストールを実行する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86648) に記載されている指示に従ってください (このサイトは英語の場合があります)。
インストールに失敗したサーバーの役割を削除するには、次の操作を行います。

  1. Exchange Server 2007 製品ドキュメントの Exchange Server 2007 サーバーの役割を削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86649) に記載されている指示に従ってください (このサイトは英語の場合があります)。

詳細情報

Exchange 2007 を無人モードでインストールする方法の詳細については、Exchange 2007 を無人モードでインストールする方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86476) を参照してください (このサイトは英語の場合があります)。


このサーバーはルーティング グループ コネクタの接続元である
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

ハブ トランスポート サーバーの役割の削除が失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。このローカル コンピュータは、Exchange 組織内で 1 つまたは複数のルーティング グループ コネクタの接続元になっています。

ルーティング グループ コネクタは、Exchange 2007 ハブ トランスポート サーバーと、Exchange Server 2003 または Exchange 2000 Server のブリッジヘッド サーバーとの間でメッセージを送受信するために使用されます。Exchange Server 2007 を既存の Exchange Server 2003 および Exchange 2000 Server 組織内にインストールする場合、セットアップ時に必要なルーティング グループ コネクタが作成されます。

Exchange 2007 セットアップ プログラムでは、ハブ トランスポート サーバーの役割を削除する前に、ハブ トランスポート サーバーのコンピュータから Exchange 組織のすべてのルーティング グループ コネクタを移動するか、削除する必要があります。

この問題を解決するには、ローカル コンピュータからすべてのルーティング グループ コネクタを移動または削除し、セットアップ プログラムを再実行します。

Exchange 管理シェルを使用してルーティング グループ コネクタを移動するには、次の操作を行います。

  1. Set-RoutingGroupConnector コマンドレットを使用して、Microsoft Exchange Server 2007 ルーティング グループと Exchange Server 2003 または Exchange 2000 Server のルーティング グループとの間の既存のルーティング グループ コネクタのプロパティを変更します。

  2. この例では、Set-RoutingGroupConnector コマンドレットを使用してルーティング グループ コネクタの接続元を変更します。
コードのコピー
Set-RoutingGroupConnector -Identity "[[Administrative Group Name\]Routing Group Name]\Routing Group Connector Name" -SourceTransportServers [FQDN of desired Hub Transport Server]
 Exchange 管理シェルを使用してルーティング グループ コネクタを削除するには、次の操作を行います。

  1. Remove-RoutingGroupConnector コマンドレットを使用して、Microsoft Exchange Server 2007 ルーティング グループと Exchange Server 2003 または Exchange 2000 Server のルーティング グループとの間のルーティング グループ コネクタを削除します。

  2. 次の例は、Remove-RoutingGroupConnector コマンドレットを使用して、指定したルーティング グループ コネクタを削除する方法を示しています。
コードのコピー
Remove-RoutingGroupConnector -Identity"[[Administrative Group Name\]Routing Group Name]\Routing Group Connector Name"

ルーティング グループ コネクタの変更または削除の詳細については、Exchange Server 2007 製品ドキュメントの次のトピックを参照してください。

  • Set-RoutingGroupConnector (http://go.microsoft.com/fwlink/?LinkId=86659) (このサイトは英語の場合があります)

  • Remove-RoutingGroupConnector (http://go.microsoft.com/fwlink/?LinkId=86660) (このサイトは英語の場合があります)


このサーバーは送信コネクタのソースである
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

ハブ トランスポート サーバーの役割の削除が失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。このローカル コンピュータは、Exchange 組織内の 1 つ以上の送信コネクタのソースになっています。

送信コネクタは、そこを通過して送信メッセージが送信される論理ゲートウェイを表します。

Exchange 2007 セットアップ プログラムを実行するには、サーバーの役割を削除する前に、ハブ トランスポート サーバー コンピュータから Exchange 組織のすべての送信コネクタを移動または削除する必要があります。

この問題を解決するには、ローカル コンピュータからすべての送信コネクタを移動または削除してから、セットアップ プログラムを再実行します。

送信コネクタの変更や削除の詳細については、Exchange Server 2007 製品ドキュメントの次のトピックを参照してください。

  • 送信コネクタを削除する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86655) (このサイトは英語の場合があります)

  • 送信コネクタの構成を変更する方法についてのページ (http://go.microsoft.com/fwlink/?LinkId=86656) (このサイトは英語の場合があります)


単純な Exchange 組織モデルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-18

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、サーバー上にあるメールボックスの数を判断します。それぞれのメールボックス ストア オブジェクト (msExchPrivateMDB クラス) には、複数の値を持つ homeMDBBL 属性があり、ストア内に存在するすべてのメールボックスが値として列挙されます。Exhcange Server アナライザは、これらの値をカウントして、サーバー上にあるメールボックスの合計数を取得します。

また、Exchange Server アナライザは、Active Directory に対してクエリを実行し、Exhcange サーバーを含む Active Directory サイトの数を判断します。さらに、Exhcange Server アナライザは、Active Directory に対してクエリを実行し、Microsoft Exchange 2000 Server または Microsoft Exchange Server 2003 のいずれかを実行するサーバーの数を判断します。最後に、Exchange Server アナライザは Win32_Service Microsoft WMI (Windows® Management Instrumentation) オブジェクトに対してクエリを実行し、Windows クラスタ サービスが存在し、実行されているかどうかを判断します。

Exhcange Server アナライザは、以下の条件に当てはまる場合、Exchange 組織を単純な Exchange 組織として分類します。

  • 組織内のメールボックスの合計数は 1,000 未満である。

  • Exchange サーバーは、1 つの Active Directory サイトにのみインストールされる。

  • Exchange 2000 または Exchange 2003 のいずれかを実行するコンピュータは 3 台未満である。

  • クラスタ化された Exchange サーバーは展開されていない。

Microsoft Exchange Server 2007 の 4 つの定義済み組織モデルのうち、単純な Exchange 組織は Exchange 2007 が展開できる最も基本的なトポロジを表します。単純な Exchange 組織には、以下のいずれかが含まれています。

  • すべての Exchange サービスを提供し、組織全体のすべての Exchange データを格納する単一の Exchange サーバー。

  • 境界ネットワーク内に冗長ディレクトリ サーバーとエッジ トランスポート サーバーを含むトポロジの複数の Exchange サーバー。

単純な Exchange 組織を Exchange 2007 に移行するには

  1. Exchange 2007 オンライン製品ドキュメントに関するページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=69434) を参照します。

  2. 計画とアーキテクチャ、展開の計画に関する記述の順に展開して、単純な Exchange 組織の作成に関する記述をクリックします。


Simple Mail Transport Protocol が現在インストールされている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-22

コンピュータに Microsoft Windows Server™ 2003 の SMTP (Simple Mail Transfer Protocol) サービスがインストールされているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、Exchange 2007 に使用するサーバーに SMTP サービスをインストールしないようにする必要があります。

この問題を解決するには、SMTP サービスをアンインストールしてから Microsoft Exchange セットアップ プログラムを再実行します。

コントロール パネルの [Windows コンポーネントの追加と削除] を使用して SMTP サービスをアンインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をダブルクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにし、[詳細] をクリックします。

  5. [インターネット インフォメーション サービス マネージャ] を選択し、[詳細] をクリックします。

  6. [SMTP サービス] を選択し、チェック ボックスをオフにします。

  7. [OK] を 2 回クリックして [コンポーネント] ボックスの一覧に戻り、[次へ] をクリックします。

  8. SMTP サービスがアンインストールされたら、[完了] をクリックします。


サイトが Exchange 2007 サーバーをサポートできない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-11

Active Drectory ディレクトリ サービスに Microsoft Windows Server™ 2003 Service Pack 1 (SP1) 以降のバージョンで実行される少なくとも 1 台のグローバル カタログ サーバーがないサイトがあるため、Microsoft® Exchange Server アナライザ ツールがこの警告を表示しました。

Microsoft Exchange Server 2007 セットアップ プログラムでは、Windows Server 2003 SP1 以降のバージョンで実行される少なくとも 1 台のグローバル カタログ サーバーのある Exchange 2007 を実行するサーバーをホストする各 Active Directory サイトが必要になります。

この問題を修正するには、Windows Server 2003 SP1 以降のバージョンで実行される各 Active Directory サイトの少なくとも 1 台のグローバル カタログ サーバーをアップグレードします。

Windows Server 2003 にアップグレードする方法の詳細については、マイクロソフト サポート技術情報の文書番号 810613 の、Windows Server 2003 または Windows Small Business Server 2003 へのサポートされているアップグレード パスに関するページ (http://go.microsoft.com/fwlink/?linkid=3052&kbid=810613) を参照してください。

Windows Server 2003 の最新の Service Pack の入手については、Windows Server TechCenter のページ (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=45315) を参照してください。


標準 Exchange 組織モデルが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-08-10

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに対してクエリを実行し、次の値を判断します。

  • 組織内のメールボックスの数。

  • 組織内のルーティング グループの数。

  • 組織内の Active Directory サイトの数。

  • 組織内の Active Directory フォレストの数。

  • Microsoft Identity Integration Server (MIIS) がインストールされているかどうか。

各項目の大きさによって、Exchange 組織モデルが単純であるか、標準であるか、大規模であるか、複雑であるかが決まります。単純、大規模、または複雑な組織として分類されない組織は、自動的に標準 Exchange 組織に分類されます。

Microsoft Exchange Server 2007 の 4 つの定義済み組織モデルのうち、標準 Exchange 組織は Exchange 2007 に展開される最も一般的なトポロジを表します。メッセージング サービスが単一のコンピュータのリソースの限度を超えて拡大する必要が生じると、Exchange 2007 サービスを複数のコンピュータへ分離するために標準 Exchange 組織へのトポロジ分割が行われます。標準 Exchange 組織は、Exchange を実行する複数のコンピュータを展開することにより、単純な Exchange 組織に構築されます。

標準 Exchange 組織を Exchange 2007 に移行するには

  1. Exchange 2007 オンライン製品ドキュメント (英語ページの可能性があります) (http://go.microsoft.com/fwlink/?LinkId=69434) を参照します。

  2. 計画とアーキテクチャ、展開の計画に関する記述の順に展開して、標準 Exchange 組織の作成に関する記述をクリックします。


クラスタ内では静的 IP アドレスが推奨される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

1 つ以上のネットワーク インターフェイスが DHCP (Dynamic Host Configuration Protocol) を使用するように構成されているため、Microsoft® Exchange Server 2007 セットアップ プログラムによってこの警告が表示されます。

Microsoft Windows サーバー クラスタ内では、クライアント接続およびハートビート リンクを管理するネットワーク インターフェイスに静的 IP アドレスを使用することがベスト プラクティスとして推奨されます。DHCP による動的な構成を使用することは推奨されていません。これは、DHCP リースの更新が失敗したためにクラスタの動作が中断する場合があるためです。

この警告に対処するには、クライアント接続またはハートビート リンクを管理する各ネットワーク インターフェイスを、静的 IP アドレスを使用するように構成します。

ネットワーク接続のための静的 IP アドレスを構成するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[設定] をクリックします。次に、[ネットワーク設定] をクリックします。

  2. 構成する接続を右クリックし、[プロパティ] をクリックします。

  3. [全般] タブで、[この接続は次の項目を使用します] ボックスの一覧の [インターネット プロトコル (TCP/IP)] をクリックし、[プロパティ] をクリックします。

  4. [次の IP アドレスを使う] をクリックし、[IP アドレス] に IP アドレスを入力します。

  5. [OK] を 2 回クリックして完了します。

Windows サーバー クラスタの最適なネットワーク構成の詳細については、サーバー クラスタの Windows 2000 および Windows Server 2003 向けネットワーク構成ベスト プラクティスについてのページ (http://go.microsoft.com/fwlink/?linkid=34304) を参照してください (このサイトは英語の場合があります)。

クラスタの適切なハートビート構成の詳細については、Microsoft サポート技術情報の文書番号 258750「クラスタ サーバーでのプライベート "ハートビート" の推奨構成」(http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750) を参照してください。


シングル コピー クラスタの記憶域パスはクラスタ化されたディスクにする必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

シングル コピー クラスタの記憶域パスはクラスタ化されたディスクにする必要があるため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange Server 2007 で、シングル コピー クラスタ (SCC) は、クラスタ内のノード間で共有される記憶域で、ストレージ グループの 1 つのコピーを使用するクラスタ化されたソリューションです。

この問題を解決するには、クラスタ化されたドライブをデータ パスとして指定してから、Exchange 2007 セットアップ プログラムを再実行します。

シングル コピー クラスタの詳細については、Exchange Server 2007 製品ドキュメントのシングル コピー クラスタのインストールについてのページ (http://go.microsoft.com/fwlink/?LinkId=76162) を参照してください (このサイトは英語の場合があります)。


SMTP アドレス指定形式がサポートされていない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

指定された受信者ポリシーが、サポートされていない SMTP (Simple Mail Transfer Protocol) アドレス形式を使用しているため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、電子メール アドレス ポリシーに使用されるすべての SMTP アドレスに、<ユーザー>@[10.10.1.1] などの IP アドレス リテラルが含まれていないことが必要です。

この問題を解決するには、受信者ポリシー内の SMTP アドレスの値を、IP アドレス リテラルを含まないように変更します。IP アドレス リテラルの角かっこ ([]) と数字 (10.10.1.1) を、<ユーザー>@contoso.com のようなドメイン ネーム システム (DNS) の名前の形式に置き換えます。

Exchange Server 2007 における受信者ポリシーの管理の詳細については、電子メール アドレス ポリシーの管理についてのページ (http://go.microsoft.com/fwlink/?LinkId=86653) を参照してください (このサイトは英語の場合があります)。


SMTP サイト リンクが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-12-07

Microsoft® Exchange Server アナライザ ツールは、Active Directory® ディレクトリ サービスに SMTP (Simple Mail Transfer Protocol) ベースのサイト リンクを検出すると、この警告を表示します。

Microsoft Windows Server 2007 のルーティングは、SMTP サイト リンクによって接続された Active Directory サイトを無視します。SMTP サイト リンクによってのみ接続されたサイトに Exchange 2007 がインストールされている場合、ルーティング エラーが発生します。

この問題を修正するには、SMTP サイト リンクを IP ベースのサイト リンクに置き換えます。

Active Directory IP サイト リンクの詳細については、電子メールのルーティング用に Active Directory サイトを使用する計画に関するページ (http://go.microsoft.com/fwlink/?LinkId=71803) を参照してください。


ストレージ グループ ドライブの仕様が見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-05-15

このサーバーの以前のインストールで使用されたストレージ グループ データベース ドライブの仕様にアクセスできないため、Microsoft® Exchange Server 2007 障害回復セットアップ プログラムを続行できません。

Microsoft Exchange 障害回復セットアップ プログラムを実行するには、以前このサーバーに対して使用したものと同じストレージ グループ データベース ドライブの仕様が、復元時に使用できる必要があります。

この問題を解決するには、ドライブを元の論理ドライブ構成に一致するように構成した後、Microsoft Exchange 障害回復セットアップ プログラムを再実行します。

ドライブ文字の割り当てまたは変更

  1. [コンピュータの管理 (ローカル)] を開きます。

  2. コンソール ツリーで、[コンピュータの管理 (ローカル)] をクリックし、[記憶域] をクリックします。次に、[ディスクの管理] をクリックします。

  3. パーティション、論理ドライブ、またはボリュームを右クリックし、[ドライブ文字とパスの変更] をクリックします。

  4. 以下のいずれかの手順を使用します。

    • ドライブ文字を割り当てるには、[追加] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

    • ドライブ文字を変更するには、そのドライブ文字をクリックし、[変更] をクリックします。次に、使用するドライブ文字をクリックし、[OK] をクリックします。

ドライブ文字を割り当てる方法の詳細については、ドライブ文字の割り当て、変更、または削除についてのページ (http://go.microsoft.com/fwlink/?LinkId=66764) を参照してください (このサイトは英語の場合があります)。


対象のインストール パスが一致していない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

Exchange バイナリ ファイルのインストール先パスが、他のクラスタ ノード上の既存の Exchange インストール パスと一致しないため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange Server 2007 では、同じクラスタに属するノードの Exchange バイナリ ファイルのインストール先は、一貫したインストール パスにする必要があります。

この問題を解決するには、Exchange バイナリ ファイルのインストール先として、クラスタに属するすべてのノードで一貫性のあるインストール パスを使用します。

高可用性の Exchange Server 2007 インストールの詳細については、Exchange Server 2007 製品ドキュメントの高可用性についてのページ (http://go.microsoft.com/fwlink/?linkid=68190) を参照してください (このサイトは英語の場合があります)。


保存先のパスが圧縮されている
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-06

Microsoft Exchange インストールの保存先のパスが圧縮されているため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Microsoft Exchange セットアップ プログラムを実行するには、インストール用のパスの最初のフォルダは圧縮されていないフォルダである必要があります。既定では、保存先パスの最初のフォルダは C:\Program Files です。

この問題を解決するには、保存先パスの最初のフォルダの圧縮を解除し、Exchange 2007 セットアップ プログラムを再行します。

保存先のパスの圧縮を解除するには、次の操作を行います。

  1. [マイ コンピュータ] またはエクスプローラで、圧縮を解除するフォルダを右クリックします。

  2. [プロパティ] をクリックし、[プロパティ] ダイアログ ボックスを表示します。

  3. [全般] タブで、[詳細設定] をクリックします。

  4. [属性の詳細] ダイアログ ボックスで、[内容を圧縮してディスク領域を節約する] チェック ボックスをオフにし、[OK] をクリックします。

  5. [プロパティ] ダイアログ ボックスで、[OK] をクリックします。

  6. フォルダの圧縮状態が変更されたら、[属性変更の確認] ダイアログ ボックスで、[このフォルダ、サブフォルダおよびファイルに変更を適用] を選択します。

  7. 適用が完了したら、[OK] をクリックします。


クラスタ内には 2 つ以上のネットワーク インターフェイスが推奨される
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

Microsoft Windows クラスタ環境で現在定義されているネットワーク インターフェイスが 1 つのみであるため、Microsoft® Exchange Server 2007 セットアップ プログラムによってこの警告が表示されます。

単一障害点を回避するために、パブリック ネットワーク (クライアント接続) に対して少なくとも 1 つのネットワーク インターフェイスを、またプライベート ネットワーク (管理/ハートビート) に対して 1 つのネットワーク インターフェイスを実装することがベスト プラクティスとして推奨されます。

この警告に対処するには、Microsoft Windows クラスタに少なくとも 1 つの追加のネットワーク インターフェイスを実装します。

Windows サーバー クラスタの最適なネットワーク構成の詳細については、サーバー クラスタの Windows 2000 および Windows Server 2003 向けネットワーク構成ベスト プラクティスについてのページ (http://go.microsoft.com/fwlink/?linkid=34304) を参照してください (このサイトは英語の場合があります)。


リモート レジストリ サービスに接続できない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-01-23

ローカル コンピュータのレジストリにアクセスできなかったため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムは、ローカル レジストリにアクセスしてさまざまな設定を取得する必要があります。

Exchange セットアップ プログラムは、レジストリにアクセスするために、ドメイン ネーム システム (DNS) を使用してローカル コンピュータの完全修飾ドメイン名 (FQDN) を取得しようとします。

ネットワーク エラーが発生したためにセットアップ プログラムが DNS から FQDN を取得できなかったか、またはセットアップ プログラムがレジストリにアクセスできなかったかのいずれかです。

この問題を解決するには、リモート レジストリ サービスがローカル コンピュータで実行されていること、およびバインド順序の一番上にあるネットワーク アダプタでファイルとプリンタの共有が有効になっていることを確認してから、Exchange セットアップ プログラムを再度実行します。

リモート レジストリ サービスが実行されていることを確認するには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[設定]、[コントロール パネル]、[管理ツール] の順にポイントします。次に、[サービス] をダブルクリックします。

  2. [Remote Registry Service] の状態が [開始] になっていることを確認します。
プライマリ ネットワーク アダプタでファイルとプリンタの共有を有効にするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[設定]、[コントロール パネル]、[ネットワーク接続] の順にポイントし、[ローカル エリア接続] をダブルクリックします。

  2. [Microsoft ネットワーク用ファイルとプリンタ共有] が有効である、つまりチェック ボックスがオンになっていることを確認します。
注 :
クラスタ化されたサーバーの場合、クラスタのすべてのノードでリモート レジストリ サービスが実行中であること、およびバインド順序の一番上にあるネットワーク アダプタの [Microsoft ネットワーク用ファイルとプリンタ共有] が有効であることを確認する必要があります。


Windows Media オーディオ音声コーデックの更新が必要
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-07-13

Microsoft Windows Media オーディオ音声コーデックがインストールされていないか、より新しいバージョンの Windows Media オーディオ音声コーデックが提供されているため、Microsoft® Exchange Server 2007 のセットアップを続行できません。

Exchange 2007 をセットアップするには、サーバーに Windows Media オーディオ音声コーデックの最新バージョンをインストールする必要があります。Windows Media オーディオ音声コーデックは、Exchange Server 2007 のユニファイド メッセージング サーバーの役割のサポートに必要です。

この問題を解決するには、http://go.microsoft.com/fwlink/?LinkId=67407 から最新バージョンの Windows Media オーディオ音声コーデックをインストールし、Exchange 2007 のセットアップを再実行します。


Windows Media エンコーダを更新する必要がある
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-07-13

Microsoft Windows Media エンコーダがインストールされていないか、またはインストールされていても最新バージョンの Windows Media エンコーダでないため、Microsoft® Exchange Server 2007 のセットアップを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、最新バージョンの Windows Media エンコーダをサーバーにインストールする必要があります。Windows Media エンコーダは、Exchange Server 2007 のユニファイド メッセージング サーバーの役割をサポートするために必要です。

この問題を解決するには、最新バージョンの Windows Media エンコーダを http://go.microsoft.com/fwlink/?LinkId=67406 からダウンロードしてインストールした後、Exchange 2007 のセットアップを再実行します。


World Wide Web Publishing サービスが無効になっているかまたは見つからない
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-02-14

メールボックス サーバーの役割またはクライアント アクセスの役割をインストールしようとしたときに、このコンピュータで World Wide Web Publishing サービスが無効になっているかまたはインストールされていないことが検出されたため、Microsoft® Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange 2007 セットアップ プログラムを実行するには、Microsoft Exchange をインストールするコンピュータに World Wide Web Publishing サービスがインストールされ、無効以外の状態に設定されている必要があります。

この問題を解決するには、ローカル コンピュータに World Wide Web Publishing サービスがインストールされ、無効以外の状態になっていることを確認した後、Microsoft Exchange セットアップ プログラムを再実行します。

World Wide Web Publishing サービスがインストールされ、無効以外の状態になっていることを確認するには、次の操作を行います。

  1. デスクトップの [マイ コンピュータ] を右クリックし、[管理] をクリックします。

  2. [サービスとアプリケーション] ノードを展開し、[サービス] ノードをクリックします。

  3. 右側のペインで、[World Wide Web Publishing Service] を見つけます。

    インストールされているサービスの一覧に [World Wide Web Publishing Service] が表示されない場合は、以下の手順を実行してインストールします。

  4. [World Wide Web Publishing Service] が表示されても、状態が [開始] になっていない場合は、以下の手順を実行して開始します。

  5. [World Wide Web Publishing Service] を右クリックし、[プロパティ] をクリックします。

  6. [スタートアップの種類] が [自動] に設定され、[サービスの状態] が [開始] に設定されていることを確認します。

  7. [適用] をクリックし、[OK] をクリックします。
World Wide Web Publishing サービスをインストールするには、次の操作を行います。

  1. [スタート] ボタンをクリックし、[設定] をポイントします。次に、[コントロール パネル] をポイントし、[プログラムの追加と削除] をクリックします。

  2. [Windows コンポーネントの追加と削除] をクリックします。

  3. [コンポーネント] ボックスの一覧で、[アプリケーション サーバー] チェック ボックスをオンにし、[詳細] をクリックします。

  4. [インターネット インフォメーション サービス マネージャ] を選択し、[詳細] をクリックします。

  5. [WWW (World Wide Web) サービス] を選択し、チェック ボックスをオンにします。

  6. [OK] を 2 回クリックして [コンポーネント] ボックスの一覧に戻り、[次へ] をクリックします。

  7. IIS サービスがインストールされたら、[完了] をクリックします。


ユニファイド メッセージング言語パックのアンインストール
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-16

ユニファイド メッセージング サーバーの役割のアップグレードに失敗したため、Microsoft Exchange Server 2007 セットアップ プログラムを続行できません。

Exchange のセットアップ時には、ユニファイド メッセージング サーバーの役割の言語パックを、US 英語の言語パックを除いてすべてアンインストールしてから、ユニファイド メッセージング サーバーの役割のアップグレードを続行する必要があります。

Exchange 2007 に付属するユニファイド メッセージング (UM) 言語パックには、特定言語用の録音済みのプロンプトと、音声合成 (TTS) 変換サポートが含まれています。

Exchange 2007 UM 言語パックにより、発信者と Outlook Voice Access ユーザーは、複数の言語でユニファイド メッセージング システムと対話できます。

新しい言語パックをインストールできるように、既存の US 英語以外の言語パックをアンインストールする必要があります。

この問題を解決するには、ユニファイド メッセージング サーバーの役割の言語パックを、US 英語の言語パック以外はすべてアンインストールしてから、Exchange 2007 セットアップ プログラムを再実行します。

ユニファイド メッセージング サーバーの役割の言語パックをアンインストールすることの詳細については、Exchange 2007 製品ドキュメントの、ユニファイド メッセージング サーバーからユニファイド メッセージング言語パックを削除する方法についてのページを参照してください (このサイトは英語の場合があります)。


障害回復に必要な更新
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2007-03-27

このコンピュータに Exchange Server をインストールするために最初に使用された Exchange Server 2007 のバージョンの方が新しいため、Microsoft Exchange Server 2007 の障害回復を続行できません。

Microsoft Exchange の障害回復では、Exchange Server の回復を実行するために使用する Exchange Server 2007 のバージョンが、Exchange Server をインストールするために最初に使用されたバージョン以降であることが必要です。

この問題を解決するには、Exchange Server をインストールするために最初に使用されたバージョンと同じ、またはそれ以降の Exchange Server 2007 から、Exchange Server 2007 の障害回復を開始します。


トポロジに X400 コネクタが検出された
Microsoft Exchange Server アナライザ - 文書 > Exchange Server 2007 への対応性 >

トピックの最終更新日時 : 2006-06-05

Microsoft™ Exchange Server アナライザ ツールは、Active Directory™ ディレクトリ サービスに対して、X.400 コネクタに関するクエリを実行します。Exchange Server アナライザで Microsoft Exchange 組織に X.400 コネクタが存在することが検出されると、警告が表示されます。この警告は、以前のメッセージング システム間でのメッセージの伝送に使用されるプロトコルである X.400 コネクタが、Microsoft Exchange Server 2007 ではサポートされていないことを表します。

Microsoft Exchange 2000 Server と Microsoft Exchange Server 2003 では、SMTP (Simple Mail Transfer Protocol) が既定の伝送プロトコルでした。X.400 コネクタは Exchange 2000 と Exchange 2003 ではサポートされていますが、Exchange 2007 ではサポートされていません。その理由は、このコネクタの使用がここ何年かの間に減ってきているためです。X.400 のサポートが引き続き必要な場合は、Exchange 2000 または Exchange 2003 サーバーをこれまでどおり使用することをお勧めします。または X.400 コネクタを SMTP に変えてください。

Exchange 2003 での X.400 伝送アーキテクチャの詳細については、「Exchange Server 2003 Message Routing」(http://go.microsoft.com/fwlink/?LinkId=65578) を参照してください (このサイトは英語の場合があります)。

Exchange 2003 での X.400 コネクタの実装方法の詳細については、「Implementing the X.400 Connector - Is It Worth Using with Exchange Server 2003?」(http://www.msexchange.org/tutorials/X400-Connector-Exchange-Server-2003.html) を参照してください (このサイトは英語の場合があります)。

注 :
このトピックにあるサード パーティの Web サイト情報は、必要な技術情報の検索に役立つように提供されています。URL は通知なしに変更される場合があります。


法的情報

トピックの最終更新日時 : 2007-04-06

このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更されることがあります。別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係ありません。お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

© 2004-2006 Microsoft Corporation.All rights reserved.

Microsoft、Active Directory、ActiveSync、ActiveX、MSDN、Outlook、SharePoint、Visual C++、Win32、Windows、Windows NT、Windows Server、および Windows Server System は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

記載されている会社名、製品名には、各社の商標のものもあります。