次の方法で共有

Exchange 2010 のストアについて

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

Exchange ストアとは、複数の種類の情報を 1 つのインフラストラクチャで管理するための単一のリポジトリを提供するストレージ プラットフォームです。 Exchange ストア (Store.exe) は MicrosoftExchange Server 2010 のコア データ ストレージ リポジトリです。

目次

Exchange 2010 のエディションにおけるデータベース

Exchange ストアの論理コンポーネント

Exchange ストアのファイル構造

トランザクション ログについて

Extensible Storage Engine

ストアの状態

データベース ログまたはデータベース ドライブでディスクの空き領域が不足している

Exchange ストアの制限

Exchange 2010 のエディションにおけるデータベース

Exchange 2010 は、 Standard Edition と Enterprise Edition の 2 つのサーバーのエディションで使用できます。 Exchange 2010 Standard Edition は、小規模および中規模企業のメッセージングとコラボレーションのニーズを満たすように設計されています。また、特定のサーバーの役割または支店に適している場合もあります。 Exchange 2010 Enterprise Edition は大企業向けに設計されています。

Exchange 2010 Standard Edition では、最大 5 個のデータベースがサポートされます。 Exchange 2010 Enterprise Edition では、最大 100 個のデータベースがサポートされます。

Exchange ストアの論理コンポーネント

Exchange ストアの主要なコンポーネントは、メールボックス データベースおよびパブリック フォルダー データベースです。 これらのコンポーネントは、1 台のサーバーに配置したり、複数のサーバーに分散したりすることができます。

メールボックス データベースには、Exchange 2010 のメールボックスを構成するデータ、データ定義、インデックス、チェックサム、フラグ、およびその他の情報が格納されます。 メールボックス データベースには、各ユーザーの個人用のデータが格納されます。また、そのユーザーに対してメールボックスを作成するときに生成されるメールボックス フォルダーも格納されます。 メールボックス データベースは Exchange データベース (.edb) ファイルとして格納されます。

パブリック フォルダー データベースには、Exchange 組織内のすべてのパブリック フォルダーを構成するデータ、データ定義、インデックス、チェックサム、フラグ、およびその他の情報が格納されます。

Exchange 2010 では、Exchange 管理シェルを使用してパブリック フォルダーを管理します。 (Exchange 管理コンソールでも、限られた数のパブリック フォルダー データベース管理タスクを実行できます)。 パブリック フォルダーの管理の詳細については、「パブリック フォルダーの管理」および「パブリック フォルダーについて」を参照してください。

Exchange 2010 のエディションにおけるデータベース

Exchange ストアのファイル構造

Exchange ストアを管理するには、データベースなどの論理コンポーネントを使用します。 一方、Exchange 2010 は、Exchange データベース (.edb) ファイル、トランザクション ログ (.log) ファイル、およびチェックポイント (.chk) ファイルなどの、特別なデータ ファイルのセットにデータを格納します。 データをバックアップまたは復元する場合を除いて、これらのファイルを直接操作することはほとんどありません。 次の表は、これらのファイルについてそれぞれ詳しく説明したものです。

Exchange ストアのファイル構造

データ ファイル 説明

Exchange データベース (.edb)

これらのファイルはメールボックス データのリポジトリです。 ESE (Extensible Storage Engine) によって直接アクセスされ、高速アクセス用に設計された B ツリー構造を持っています。 これにより、ユーザーは 1 入出力 (I/O) サイクル以内にデータの任意のページにアクセスが可能で、これは Microsoft Exchange Server 2007 と比較して 4 倍の高速化です。Exchange データベースは複数の B ツリーと、メイン ツリーと共に使用され、インデックスとビューを保持する補助ツリーで構成されます。

トランザクション ログ (.log)

これらのファイルは、メッセージの作成や編集などのデータベースの操作に対するリポジトリです。 コミットされた操作は、後でデータベース本体 (.edb ファイル) に書き込まれます。 このようにすることで、完了したトランザクションと進行中のトランザクションは、サービスが中断した場合にデータの整合性を維持するために、すべて確実にログに記録されます。 各データベースには、独自のトランザクション ログのセットがあります。

チェックポイント (.chk)

これらのファイルは、操作が正常にハード ディスク上のデータベースに保存されたことを示すデータのリポジトリです。Exchange 2010 では, .chk ファイルを使用することによって、ESE のインスタンスがサービスの中断から回復するときに、不整合状態のデータベースに対して、書き込まれていない次の操作から自動的にログ ファイルを再生できるようにしています。 .chk ファイルは, .log ファイルと同じログの場所に作成されます。

Exchange 2010 のエディションにおけるデータベース

トランザクション ログについて

Exchange トランザクション ログは、データベースが突然停止した場合に Exchange データベースを確実に整合状態に復元するように設計された ESE の強力な回復機構です。 また、ログ機構はオンライン バックアップの復元時にも使用されます。 ここでは、Exchange 2010 におけるトランザクション ログの詳細について説明し、循環ログについても簡単に説明します。

Exchange トランザクション ログ

Exchange データベース ファイルに変更が加えられる前に、Exchange はトランザクション ログ ファイルにその変更を書き込みます。 変更が正常にログ出力されると、その変更はデータベース ファイルに書き込めるようになっています。 通常、変更をトランザクション ログに安全に記録した直後、データベース ファイルに書き込まれる前に、これらの変更がエンド ユーザーに対して有効になります。

Exchange では、高いパフォーマンスで機能し、数十ギガバイト (GB) のデータベース ページのキャッシュを効率よく管理できる洗練された内部メモリ管理システムを採用しています。 データベース ファイルに物理的に変更を書き込む処理は通常の運用では優先順位の低い作業です。

データベースが突然停止しても、メモリ キャッシュが破損しただけではキャッシュされた変更は失われません。 Exchange では、データベースの再起動時にログ ファイルをスキャンし、データベース ファイルにまだ書き込まれていない変更をすべて再構築し、適用します。 このプロセスを "ログ ファイルの再生" と呼びます。 データベースは、ログ ファイルに記録された処理のうち、データベースに適用済みであるか、データベースにこれから適用する必要があるか、またはそのデータベースに属していないかを Exchange が判断できるように構築されています。

すべてのログ情報を 1 つの大きなファイルに書き込むのではなく、Exchange では一連のログ ファイルを使用し、各ファイルのサイズはちょうど 1 メガバイト (MB)、つまり 1,024 キロバイト (KB) です。 1 つのログ ファイルがいっぱいになると、Exchange はそのファイルを閉じ、連続した番号に名前を変更します。 最初のファイルがいっぱいになると、Enn00000001.log という名前を付けます。 nn は、ベース名またはログ プレフィックスという 2 桁の数字です。

各データベースのログ ファイルは、E00、E01、E02、E03 などの番号の付いたプレフィックスのファイル名で識別されます。 データベースで現在開いているログ ファイルは、Enn.log という名前です。 ログ ファイルは、いっぱいになって閉じられるまでシーケンス番号は付けられません。

チェックポイント ファイル (Enn.chk) によって、Exchange はログ情報をデータベース ファイルのどこまで書き込んだかを追跡します。 各ログ ストリームに 1 つのチェックポイント ファイルがあり、各データベースには 1 つのログ ストリームがあります。

ログ ファイルは 16 進数方式で番号を付けられているため、E0000000009.log の次のログ ファイルは、E0000000010.log ではなく E000000000A.log になります。 Windows 電卓 (Calc.exe) アプリケーションを関数電卓モードで使用すると、ログ ファイルのシーケンス番号を 10 進数の値に変換できます。 これを行うには、Calc.exe を実行し、[表示] メニューの [関数電卓] をクリックします。

特定のログ ファイルのシーケンス番号を 10 進数で表示するには、Exchange Server データベース ユーティリティ (Eseutil.exe) ツールを使用してそのヘッダーを確認できます。 各ログ ファイルの最初の 4 KB に相当するページには、ログ ファイルとログ ファイルが属するデータベースを説明および識別するヘッダー情報が含まれています。 Eseutil /ml [log file name] コマンドにより、ヘッダー情報が表示されます。

たとえば、データベース ヘッダーに /ml ではなく /mh を使用し、ヘッダーを表示するために間違ったスイッチを使用すると、エラーが表示されたり、あるいは文字化けした、または間違ったヘッダー情報が表示されたりする可能性があります。

マウントされている間、データベースはヘッダーを表示できません。また、データベースがマウントされている間も現在のログ ファイル (Enn.log) のヘッダーを表示できません。Exchange では、1 つのデータベースで現在のログ ファイルを使用している限り、このログ ファイルは開いたままになります。 ただし、チェックポイント ファイルのヘッダーはデータベースがマウント中でも表示できます。Exchange では 30 秒ごとにチェックポイント ファイルを更新し、更新を実行している間以外はヘッダーを表示できます。

Exchange 管理者の方は、Exchange ファイル ヘッダーについて理解しておくと役立ちます。 ファイル ヘッダーについて理解しておくと、どのデータベースとログ ファイルが対応し、正常に回復させるにはどのファイルが必要なのかを判断できます。

次のログ ファイル ヘッダーの例で、最初の 4 行に注意してください。

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

ログ ファイル ヘッダーのこれらの行には、ログ ファイル名にシーケンス番号が含まれていないため、このログ ファイルは現在のログ ファイルであることを示します。 lGeneration 行は、このログがいっぱいになり閉じられるとシーケンス番号が 10 進数値の 11 に相当する B であることを示しています。 ベース名は e00 なので、最終的なログ ファイル名は E000000000B.log になります。

前のヘッダー例にある Checkpoint 値は実際にはログ ファイル ヘッダーから読み取られたのではありませんが、このように表示されます。 Eseutil.exe は Enn.chk から Checkpoint 値を直接読み取るため、チェックポイント ファイルの場所を調査するために別のコマンドを入力する必要はありません。 チェックポイント ファイルが破損している場合、Checkpoint 値は NOT AVAILABLE として読み取られます。 この例では、チェックポイントは現在のログ ファイル (0xB) にあり、数値 7DC および 6F はログ ファイルのどこにチェックポイントがあるかを示しています。 この情報が実際に必要になることはめったにありません。

チェックポイント ファイルが破損しても、Exchange はログ ファイルを適切に回復し、再生できます。 そのためには、Exchange はチェックポイント ログからではなく使用可能な最も古いログ ファイルからスキャンを開始します。Exchange では既にデータベースに適用されているデータはスキップされ、適用する必要のあるデータを検出するまでログを順次スキャンします。

通常、Exchange では既にデータベースに適用されたログ ファイルをスキャンするのに 1、2 秒しかかかりません。 データベースに書き込む必要のある処理がログ ファイル内にある場合は、それら実行するために 10 秒から数分かかります。 平均では、ログ ファイルの内容は 30 秒以内にデータベースに書き込まれます。

Exchange データベースが正常にシャットダウンすると、すべての未解決データはデータベース ファイルに書き込まれます。 正常にシャットダウンすると、データベース ファイル セットは整合状態にあると見なされ、Exchange のデータベース ファイル セットはログ ストリームから切断されます。 つまり、この時点でデータベース ファイルは独立した状態になり、最新の状態になります。 データベース ファイルを開始するためにトランザクション ログは必要ありません。

データベースが正常にシャットダウンしたかどうかは Eseutil /mh コマンドを実行し、ファイル ヘッダー確認するとわかります。

すべてのデータベースが切断され、クリーン シャットダウン状態にある場合は、データベースに影響を与えずにすべてのログ ファイルを安全に削除できます。 すべてのログ ファイルを削除すると、Exchange では Enn00000001.log から開始する新しい一連のログ ファイルが生成されます。 既存のログ ファイルを持つ他のサーバーにデータベース ファイルを移動できます。この場合、データベースは他のログ ストリームに接続されます。

注意

すべてのデータベースがシャットダウンされた後でログ ファイルを削除することもできますが、これによりさらに古いバックアップを復元したり、ロールフォワードしたりする機能に影響があります。 現在のデータベースが既存のログ ファイルを必要としなくなっても、さらに古いデータベースを復元する場合に必要になる可能性があります。

データベースがダーティ シャットダウン状態にある場合は、チェックポイント以前のすべての既存トランザクション ログが存在しないと、データベースを再マウントすることはできません。 これらのログを使用できない場合は、データベースを整合状態にして起動できるようにするために、Eseutil /p コマンドを実行し、データベースを修復する必要があります。

注意

データベースを修復する必要がある場合、一部のデータが失われます。 通常データ損失は最小限で済みますが、致命的な状態になる場合もあります。 データベースで Eseutil /p を実行した後、データベースを最適化するために Eseutil/ d を実行する必要があります。 この操作を行うと、すべてのデータベースのインデックスおよび領域ツリーが破棄されて再構築されます。

トランザクション ログは、データベースが予期せず停止した場合に Exchange でデータベースを正常に回復するためだけでなく、オンライン バックアップを作成および復元するためにも不可欠です。 オンライン バックアップを作成および復元する方法の詳細については、「バックアップ、復元、および障害復旧について」を参照してください。

Exchange 2010 のエディションにおけるデータベース

循環ログ

循環ログを有効にしてディスク領域を節約するように Exchange を構成することができます。 Exchange の循環ログでは、ログ ファイルに含まれるデータがデータベースにコミットされた後でトランザクション ログ ファイルを上書きできます。 ただし、循環ログを有効にした場合は、最後の完全バックアップまでのデータしか回復できません。 たとえば、Exchange のネイティブ データ保護を使用する場合は、バックアップを作成しないため循環ログを有効にできます。 ログの増加を防ぐには、循環ログを有効にします。

Exchange 2010 で使用される標準のトランザクション ログでは、各データベース トランザクションはログ ファイルに書き込まれてからデータベースに書き込まれます。 ログ ファイルのサイズが 1 MB に到達すると、そのログ ファイルの名前が変更され、新しいログ ファイルが作成されます。 時間の経過と共に、一連のログ ファイルが作成されます。 Exchange が予期せず停止した場合、これらのログ ファイル内のデータをデータベースに再生することで、トランザクションを回復できます。 循環ログは、ログに含まれるデータがデータベースに書き込まれた後、最初のログ ファイルを上書きして再利用します。

Exchange 2010 の循環ログは既定で無効になっています。 有効にすると、必要なドライブの記憶領域が減ります。 ただし、完全なトランザクション ログ ファイルのセットがないと、最後の完全バックアップより新しいデータは回復できません。 通常の運用環境で循環ログを使用することはお勧めしません。

循環ログを有効または無効にする方法については、「メールボックス データベースのプロパティの構成」を参照してください。

Exchange 2010 のエディションにおけるデータベース

Extensible Storage Engine

ハブ トランスポート サーバーおよびエッジ トランスポート サーバー上の Exchange メールボックス データベースとキューでは、ESE データベースを使用します。 ESE は、DML (データ操作言語) および DDL (データ定義言語) 機能を完全に備えたマルチユーザー ISAM (索引順次アクセス方式) テーブル マネージャーです。 ESE によって、アプリケーションはレコードを格納し、インデックスを作成してさまざまな方法でこれらのレコードにアクセスできるようになります。 ESE の詳細については、「Extensible Storage Engine アーキテクチャ」を参照してください。 Exchange 2010 ESE の機能強化の詳細については、「新しい Exchange コア ストア機能」を参照してください。

Exchange 2010 のエディションにおけるデータベース

ストアの状態

Exchange ストアは、ストアの異常を引き起こす複数のシナリオを検出して修正できます。 Exchange ストアは、有害なメールボックスとスレッドのタイムアウトを処理し、レポートおよび警告の機能を使用して異常な Exchange ストアの状態に対して通知し、メールボックス データベースおよびパブリック フォルダー データベースの問題を検出して修復します。

有害なメールボックスの検出と修正

破損したデータ (論理的または物理的) のある単一のメールボックスが場合によっては、Exchange ストアがエラーを起こす原因となり、サーバーによってホストされているすべてのメールボックスに対するサービスを拒否します。 同様に、有害なメールボックスはまた Exchange ストアが繰り返しエラーを起こす原因となります。 ここでは、Exchange ストアが有害なメールボックスを検出して遮断するために行う操作について説明します。

有害なメールボックスの隔離

Exchange ストアがメールボックスを潜在的な脅威としてタグ付けするイベントには複数の種類があります。

  • そのメールボックスに対して作業を行っているスレッドでエラーが発生した場合

  • そのメールボックスに 5 つを超えるスレッドがあり、長い時間進捗が無い場合

今までにタグ付けされた回数と共に、潜在的な脅威がタグ付けされたメールボックス。 この情報は、レジストリに格納されます。 Exchange はまた、メールボックスが潜在的な脅威として認識されたタイムスタンプの情報も保持します。

データベースのマウント中に、Exchange ストアはメールボックスが潜在的な脅威として認識された時刻を読み込みます。 2 時間を超える時間が経過している場合、そのメールボックスのレジストリ キーは削除されます。 この情報をレジストリに保持することの利点は、高可用性環境において、それがクラスター データベースによってレプリケートされることです。 Exchange ストアがフェールオーバー中であっても、他のコンピューターがこの情報を保持します。 有害メールボックスを分離するために使われているレジストリのサブキーは HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid} です。 このパスのキーは、CrashCount および LastCrashTime です。

メールボックスの検疫につながる失敗の量の設定と、メールボックスを検疫し、保存する時間の設定は、**HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}**のサブキーにある MailboxQuarantineCrashThreshold と MailboxQuarantineDurationInSeconds キーです。

これらのキーの既定値は、MailboxQuarantineCrashThreshold が 3 回のエラーで、MailboxQuarantineDurationInSeconds が 21,600 秒 (6 時間) です。

有害なメールボックスの処理

既定では、メールボックスが 2 時間以内に 3 回エラーまたはデッドロックを起こしていると識別されると、Exchange はそのメールボックスを検疫済みとしてレジストリにタグを保存します。 OPEN_AS_ADMIN フラグが渡されない限り、メールボックスに対するアクセスは許可されません。 Exchange プロセス (たとえば、コンテンツのインデックス処理またはメールボックス アシスタント) はログオンできません。 QuarantineState および QuarantineTime レジストリ キーは、メールボックスが検疫されているかどうかを追跡します。 メールボックスが過去 2 時間以内にエラーの原因となっていない場合で、検疫されていない場合は、そのメールボックスのレジストリ パスは Exchange ストアによってクリーン アップされます。 メールボックスが LastCrashTime の値以降、MailboxQuarantineDurationInSeconds の値よりも長い時間検疫されている場合は、自動的に検疫から解放されます。

検疫メールボックスのリセット

有害なメールボックスの原因が識別され修正された場合、検疫メールボックスのレジストリ キーを手動でリセットして削除する必要があります。 ただし、この手動による手順が忘れられると、Exchange ストアは、検疫フラグが設定されて 6 時間後に、自動的に検疫メールボックスをリセットします。 この時間内に問題がデバッグされ修正されない場合、メールボックスまたはメッセージが再度検疫される前に、別の一連のエラーが引き起こされる可能性があります。

注意

検疫メールボックスのリセットを有効にするには、メールボックスをホストしているデータベースの再マウント、または Exchange ストアの再起動を行う必要があります。

検疫メールボックスをリセットする期間は、レジストリ キー HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<サーバー名>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds で制御できます。

レポートと警告

Get-MailboxStatistics コマンドレットを使用して、メールボックスの検疫状態をレポートすることができます。 Exchange ストアには、検疫メールボックスの数に対するパフォーマンス モニターのカウンターがあります。 カウンター名は、MSExchangeIS Mailbox\Quarantined Mailbox Count です。

Exchange ストアはまた、メールボックスを検疫する際に、メールボックス名と時刻の詳細と共にイベントを書き込みます。 イベント 10018 は検疫メールボックスを識別します。

Exchange 2010 のエディションにおけるデータベース

データベースの修復

Exchange 2010 Service Pack 1 (SP1) では、New-MailboxRepairRequest コマンドレットを使用して、メールボックスの破損の検出と修復ができます。 このコマンドレットは特定のメールボックスまたはメールボックス データベースに対して実行できます。 このタスクの実行中は、メールボックスのアクセスは修復のために中断されます。 メールボックス データベースに対してこのコマンドレットを実行している場合、修復中のメールボックスへのアクセスのみが中断されます。 データベースのその他すべてのメールボックスは通常通り動作します。 詳細については、「メールボックスの修復要求を作成する」を参照してください。

以下の種類のメールボックスの破損を検出して修復するには、New-MailboxRepairRequest コマンドレットを使用します。

  • フォルダーの破損を検索する (CorruptionType パラメーターの SearchFolder の値を使用)

  • 正しい値を反映していないフォルダーの数を集計する (CorruptionType パラメーターの AggregateCounts の値を使用)

  • 正しい内容を返さないフォルダーを表示する (CorruptionType パラメーターの FolderView の値を使用)

  • 準備されていない親フォルダーを誤って指し示している、準備されたフォルダー (CorruptionType パラメーターの ProvisionedFolder の値を使用)

New-MailboxRepairRequest コマンドレットを実行した後、イベント ビューアーを使用して要求の詳細を表示できます。 詳細については、「イベント ビューアーでメールボックス修復要求のエントリを表示する」を参照してください。

パブリック フォルダー データベース内のレプリケーションに関する問題を検出して修正するには、New-PublicFolderDatabaseRepairRequest コマンドレットを使用します。 パブリック フォルダー データベース上のパブリック フォルダーには、要求の実行中にもそのままアクセスできます。 ただし、現在修復されているパブリック フォルダーにはアクセスはできません。 詳細については、「パブリック フォルダー データベースの修理要求の作成」を参照してください。

Exchange 2010 のエディションにおけるデータベース

タイムアウトの検出とレポート

Exchange ストアの異常は、スレッドの処理がデッドロックまたはその他の理由で進捗しないことによっても示されます。 1 分間進行していないスレッドが 1 つのメールボックスに 6 以上ある場合、1 つのデータベースに 11 以上ある場合、または 1 つのサーバーに 21 以上ある場合、サーバーでタイムアウトが報告されます。 タイムアウトが検出されたことを示すパフォーマンス カウンターは、MSExchangeIS\ RPC Request Timeout Detected です。

また、Exchange ストアによって、サーバーに次のイベントが書き込まれます。

  • 10025 は、Exchange サーバーのタイムアウトを報告します。

  • 10026 は、データベースのタイムアウトを報告します。

  • 10027 は、個々のメールボックスのタイムアウトを報告します。

1 つのメールボックスでタイムアウトが検出されると、そのメールボックスは有害な可能性があると見なされ、CrashCount キーの増加によるエラーと同様の処理が行われます。 これにより、メールボックスが検疫の影響を受けやすくなります。

Exchange 2010 のエディションにおけるデータベース

データベース ログまたはデータベース ドライブでディスクの空き領域が不足している

Exchange ストアが、ログまたはデータベース ドライブの空き領域が 1 GB 未満であると検出すると、そのデータベースに対するトランスポート配信をすべて遮断します。 これにより、ディスクの空き領域が不足してしまうことを回避します。 ディスク領域が不足すると、データベースはマウントまたはデバッグできません。 データベースの空き領域は再利用もできません。 これは、インフラストラクチャの監視からの空き領域の問題の警告に対して何も対応しなかった場合にのみ起こる、自身を保護するためのメカニズムです。

ディスクの空き領域が 1.5 GB を超えると、Exchange ストアは配信の続行を許可します。 以下のパフォーマンス カウンターがこの動作を示します。

  • MSExchangeIS Mailbox\ Delivery Blocked: Low Database Space

  • MSExchangeIS Mailbox\ Delivery Blocked: Low Log Space

また、Exchange ストアによって、サーバーに次のイベントが書き込まれます。

  • 10014 は、ログのディスク空き領域が不足していることを示します

  • 10015 は、データベースのディスク空き領域が不足していることを示します

ディスク空き領域の不足の問題が発生した場合、問題を修正するために以下の操作を実行できます。

Exchange 2010 のエディションにおけるデータベース

Exchange ストアの制限

Exchange 2010 では、接続と使用率の制限は Exchange ストアに配置され、単一のアプリケーションまたは 1 人のユーザーが Exchange ストアに対して利用可能な接続をすべて使用してしまうのを防ぎます。 1 人のユーザーまたは単一のアプリケーションがすべての接続を使用してしまうと、他のユーザーまたはアプリケーションは Exchange ストアにアクセスできなくなり、その結果ダウンタイムとなります。

詳細については、「Exchange ストアの制限」を参照してください。

Exchange 2010 のエディションにおけるデータベース

 © 2010 Microsoft Corporation.All rights reserved.