通信

Exchange Server 2007 Service Pack 1 のスタンバイ連続レプリケーション

Scott Schnoll

概要:

• スタンバイ連続レプリケーションを構成する
• 冗長性を確保することの重要性
• SCR によってダウンタイムが短縮されるしくみ

Exchange 2007 Service Pack 1 では、いくつかの新機能と機能強化が提供されます。組織は、これらの新機能の 1 つであるスタンバイ連続レプリケーション (SCR) を使用して、データセンター内の冗長性とサイトの回復性を確保できるようになります。SCR は、その名のとおり

スタンバイ回復サーバーを使用するシナリオ向けに設計されています。

Exchange 2007 の製品 (RTM) 版についてよく知っている皆さんは、ログ配布機能と Windows® フェールオーバー クラスタのサポートを利用することで、データセンター内の冗長性とサイトの回復性を確保できることをご存知だと思います。RTM 版では、2 つの形式のログ配布機能 (正式には連続レプリケーションとして知られています) を利用できます。これらは、ローカル連続レプリケーション (LCR、図 1 参照) とクラスタ連続レプリケーション (CCR、図 2 参照) です。

図 1** ローカル連続レプリケーション **

Figure 2** CCR is log shipping to a second server in a Windows failover cluster **

管理者は、連続レプリケーションを使用すると、各メールボックス データベースのコピーをオンラインで作成して保守できるため、データの可用性と冗長性を確保できます。このデータベースのコピーは、運用データベースの障害、損失、または破損に対する防御の最前線として機能します。データを復元するためにバックアップ テープを探さなくても、データベースのコピーをアクティブにして、数分以内に運用データベースとして使用することができます。

SCR を使用すると、組織のデータとサービスの可用性が確保されるシナリオをさらに強化することができます。新しいシナリオでは、高可用性を重視したトポロジを、サイトの回復性を重視したトポロジから分離することができます。また、組織の各領域の要件に合った構成を展開できるようになります。

Exchange 2007 の RTM 版ではデータセンター内の冗長性とサイトの回復性が提供されますが、LCR と CCR では各データベースのコピーが 1 つ提供されるだけであるため、冗長性と回復性のどちらを取るかを選択する必要があります。たとえば、CCR によって提供されるデータとサービスの可用性機能について考えてみましょう。1 つのデータセンターにアクティブ ノードとパッシブ ノードの両方を展開した場合、データセンター内のサービスとデータの可用性は提供されますが、サイトの回復性は提供されません (どちらのノードも物理的には同じサイト内に配置されているためです)。また、1 つのデータセンターにアクティブ ノードを展開し、もう 1 つのデータセンターにパッシブ ノードを展開した場合、サイトの回復性は提供されますが、データセンター内の可用性は提供されません (この機能を提供するパッシブ ノードが別のデータセンター内に配置されているためです)。

Service Pack 1 の SCR では、各データベースのコピーを複数作成することで、可用性とサイトの回復性を (どちらか 1 つだけではなく) 両方確保することができます。たとえば、図 3 にあるように、SCR と CCR を組み合わせて使用できます。ローカルのプライマリ データセンターでストレージ グループをレプリケート (CCR を使用して高可用性を確保) し、リモートの別のバックアップ データセンターにも、それらのストレージ グループをレプリケート (SCR を使用してサイトの回復性を確保) します。サイトを回復するシナリオでは、バックアップ データセンターのクラスタ化された代替メールボックス サーバーを使用することによって、スタンバイ クラスタをアクティブにし、すばやく準備することができます。

図 3** レドモンド データセンターに展開された CCR とクインシー データセンターに展開された SCR **(画像を拡大するには、ここをクリックします)

図 3 は、ある企業がレドモンドとクインシーに展開した 2 つのデータセンターを示しています。データセンターごとに、独自の Active Directory® サイトがあります。レドモンド サイトはプライマリ (運用) データセンター内にあり、クインシー サイトはセカンダリ (バックアップ) データセンター内にあります。レドモンドでは、CCR を展開してデータセンター内の冗長性を確保しています。クインシーのスタンバイ クラスタでは、Exchange 2007 に必要なインフラストラクチャ要素だけでなく、SCR ターゲットを構成して、サイトの回復性を確保しています。クライアント アクセス サーバーとハブ トランスポート サーバー、Active Directory サーバーと DNS サーバー、インターネット アクセスなどを含む、これらの追加のインフラストラクチャ要素は、専用リソースまたは非専用リソースにすることができます。専用リソースは、特定のデータセンターのユーザーのみをサポートするように指定されたリソースです。非専用リソースは、ローカル データセンターだけでなく、他の場所のユーザーもサポートするリソースです。組織の要件に応じて、専用リソースと非専用リソースのどちらにするかを判断する必要があります。専用リソースと非専用リソースの詳細については、Exchange Server 2007 ヘルプの「サイトの回復性を確保するための構成」(technet.microsoft.com/bb201662.aspx) を参照してください。また、新しい種類のマジョリティ ノード セット (MNS) クォーラムの使用方法にも注意してください。Exchange Server 2007 の CCR は、従来の返信ノードの代わりに、MNS クォーラムとファイル共有監視を併用します (図 3 参照)。

回復性を重視して設計された、図 4 のような CCR と SCR を組み合わせた環境では、サーバー EXCLUS1 でホストされるメールボックスとサービスに複数層の冗長性が提供されるため、致命的な障害が発生した場合でも、その規模にかかわらずこれらのメールボックスを保護することができます。

図 4** SCR を使用して相互にストレージ グループをレプリケートするスタンドアロンの
メールボックス サーバー **(画像を拡大するには、ここをクリックします)

小規模から中規模の組織も SCR からメリットを得ることができます。たとえば、組織は図 4 のようにスタンドアロンのメールボックス サーバー (EXMBX1 と EXMBX2) を 2 台展開し、SCR を使用することによって、一部またはすべてのストレージ グループを一方のメールボックス サーバーからもう一方のメールボックス サーバーにレプリケートできます。

この例の EXMBX1 と EXMBX2 は、どちらも 5 つのアクティブなストレージ グループを持つ運用サーバーです。各ストレージ グループは、対応する SCR ターゲットをもう一方のサーバーに持つ SCR ソースです。ストレージの障害やその他の問題が発生し、SCR ソースとして構成されたアクティブなストレージ グループが使用できなくなった場合、Exchange 管理シェルでいくつかの管理タスクを使用すれば、SCR ターゲットのコピーをすぐにアクティブにすることができます。Microsoft® Office Outlook® 2007、および Exchange 2007 で提供されるデータベースの移植性と自動検出機能によって、いずれかのアクティブなストレージ グループ (さらに言えば、複数のアクティブなストレージ グループ) が失われた場合でも、たった数分のダウンタイムで回復できる可能性があります。

SCR ソースと SCR ターゲット

LCR および CCR と同様に、SCR でもストレージ グループのアクティブ コピーとパッシブ コピーという概念が使用されますが、これらのコピーはそれぞれ SCR ソースおよび SCR ターゲットと呼ばれます。とはいえ、SCR ソースと SCR ターゲットの実体はストレージ グループのコピーです (回復用ストレージ グループは SCR には使用できません)。

SCR にまず必要なもの (SCR ソース) は、シングル コピー クラスタまたは CCR 環境にあるスタンドアロンのメールボックス サーバーまたはクラスタ化されたメールボックス サーバー上の任意のストレージ グループです。ここで 1 つ重要なことがあります。SCR ソースにはクラスタ化されたメールボックス サーバーを使用できますが、SCR 自体はクラスタ ソリューションではないため、Windows クラスタ サービスは必要ありません。SCR のエンドポイント (SCR ターゲット) には、スタンドアロンのメールボックス サーバーか、メールボックスの役割がインストールされているが、クラスタ化されたメールボックス サーバーが構成されていないフェールオーバー クラスタ内のノードを使用できます。

ソースとターゲットの関係

各 SCR ソース ストレージ グループの SCR ターゲットとして使用できるコンピュータの数に制限はありません。たとえば、ソースと同じデータセンター内にあるメールボックス サーバーと、別のデータセンター内にあるメールボックス サーバーをターゲットとして使用できます。ただし、1 つのソースにつき 4 つ以下のターゲットを使用することをお勧めします。4 つを超えるターゲットを使用する場合は、SCR ソース サーバーのリソース (メモリ、CPU、ディスクなど) に与える可能性がある影響を評価し、それに応じて計画を行う必要があります。各 SCR ターゲット コンピュータは、複数のソース サーバーのターゲットとして使用できます。ソース コンピュータとターゲット コンピュータでは、Exchange 2007 Service Pack 1 が実行されている必要があります。また、Exchange 2007 Service Pack 1 でサポートされているオペレーティング システム (Windows Server® 2008 や Windows Server 2003 SP2 など) が実行されている必要があります。ただし、使用するオペレーティング システムにかかわらず、SCR では異なるバージョンのオペレーティング システム間でのレプリケーションはサポートされていません。つまり、SCR ソースのオペレーティング システムと、そのコンピュータをソースとするすべての SCR ターゲットのオペレーティング システムが一致している必要があります。したがって、SCR ソースで Windows Server 2003 が実行されている場合、そのコンピュータをソースとするすべての SCR ターゲットで Windows Server 2003 が実行されている必要があります。

SCR は、Exchange 2007 Standard Edition で使用できます。SCC または CCR 環境内のクラスタ化されたメールボックス サーバーを SCR ソースとして使用する場合は、Exchange 2007 Enterprise Edition が必要です。Enterprise Edition を使用した場合、各 SCR ターゲットでは最大 50 個のインスタンス (50 個のレプリケートされたストレージ グループ) がサポートされます。Standard Edition を使用した場合は、最大 5 個のインスタンスがサポートされます。

SCR ターゲットの要件は他にもあります。まず、ソース コンピュータとターゲット コンピュータは同じ Active Directory ドメインに属している必要があります。属している Active Directory サイトは異なってもかまいません。また、ソースとそのコンピュータをソースとするすべてのターゲットのデータベース ファイルとログ ファイルのパスが、SCR によってレプリケートされる各ストレージ グループ内で一致している必要があります。さらに、あるノードまたはサーバーを SCR ターゲットとして構成した場合、その SCR ターゲット コンピュータ上のストレージ グループで LCR を有効にしたり、そのコンピュータが含まれているスタンバイ フェールオーバー クラスタに、クラスタ化されたメールボックス サーバーを追加したりすることはできません。

SCR を CCR および LCR と比較する

SCR は、LCR と CCR で使用されているものと同じログ配布テクノロジと再生テクノロジを使用して、今までにない展開の選択肢と構成を提供します (図 5 参照)。LCR および CCR と同様、SCR を有効にしたストレージ グループに複数のデータベースを含めることはできません。また、Exchange 組織に複数のパブリック フォルダ データベースが存在する場合、パブリック フォルダ データベースに SCR を使用することはできません。

図 5** 別のサーバーまたはフェールオーバー クラスタ内のパッシブ ノードに
ログを配布する SCR **

SCR と CCR および LCR の重要な違いは、SCR では 1 つのストレージ グループにつき複数のターゲットがサポートされるが、LCR と CCR では 1 つのターゲット (パッシブ コピー) しかサポートされないということです。もう 1 つの重要な違いは、CCR および LCR とは異なり、SCR のコピーはバックアップできないということです。SCR の場合、サポートされているバックアップを SCR ソース ストレージ グループに対して作成すると (CCR と LCR の場合は、SCR ソース ストレージ グループのアクティブ コピーまたはパッシブ コピーに対してバックアップを作成すると)、SCR ターゲットのデータベース ヘッダーが更新され、ログ ファイルが切り詰められます。

LCR および CCR と同様に、SCR のログ配布も連続的であり、プル モデルを使用します。新しいログ ファイルが閉じられ、次の世代シーケンス番号を使用して名前が付けられたら、SCR ターゲット コンピュータ上で実行されている Microsoft Exchange Replication Service は、閉じられたトランザクション ログ ファイルを SCR ソース コンピュータからプルします。その後、それらのファイルを検査および検証し、SCR ターゲット コンピュータ上にある、対応するストレージ グループ ログ ファイル フォルダに移動します。

再生待ち時間

ログ ファイルを SCR ターゲット コンピュータにコピーした後、SCR は LCR と CCR では実行されない処理を実行します。SCR は、ログ ファイルをすぐにデータベースのコピーに再生するのではなく、50 個のログ ファイルと 24 時間という組み込みの再生待ち時間を適用します。また、SCR では、これらの組み込みのものよりもさらに長い待ち時間を指定することもできます。再生操作が実行されるまでに待ち時間があることは、さまざまなシナリオで役立ちます。たとえば、アクティブなデータベースが論理的に破損した場合、待ち時間があることによって、SCR ターゲット データベースの論理的な破損を防ぐことができる可能性があります。

再生待ち時間は、管理者が ReplayLagTime というパラメータを使用して制御します。このパラメータには、Exchange レプリケーション サービスが SCR ターゲット コンピュータにコピーされたログ ファイルを再生するまでの待ち時間を指定します。値の形式は "日.時:分:秒" で、既定値は 24 時間です。指定可能な最大値は 7 日です。また、指定可能な最小値は 0 秒です。この値に 0 秒を指定した場合、50 個のログ ファイルという既定の待ち時間の後に、それ以上待ち時間が発生しないことになります。

ReplayLagTime だけでなく、Exchange には 50 個のログ ファイルという組み込みのハードコーディングされた待ち時間が (ReplayLagTime の値にかかわらず) あります。Exchange は、ログ ファイルを再生するタイミングを決定する際、ReplayLagTime と x 個のログ ファイル (x は 50) のうち長い方の時間を使用します。この動作により、連続レプリケーションを使用する SCR ソース (CCR 環境のクラスタ化されたメールボックス サーバーなど) でフェールオーバーが発生し、Restore-StorageGroupCopy コマンドレットを使用して 1 つ以上のストレージ グループをオンラインにする必要が生じたときに、ストレージ グループの再シードを実行する必要性がさらに低下します (シードとは、Extensible Storage Engine (ESE) ストリーミング バックアップ API を使用して、SCR ソース データベースのオンライン コピーを SCR ターゲット コンピュータ上に作成する処理です)。SCR ターゲット上で再生操作を実行するまでに待ち時間があることによって、SCR ソースで損失を伴うフェールオーバーが発生したときに、SCR のコピーの再シードを実行する必要性を最小限に抑えることができます。これは、SCR ソースでデータの損失が発生しても、しばらくすると 2 つのコピーが同じ状態に戻るためです。

切り詰め待ち時間

Exchange 2007 の RTM 版を使用した連続レプリケーション環境では、ログ ファイルがバックアップされ、データベースのコピーに再生されるまで、そのログ ファイルを削除しないというルールが適用されます。SCR を使用した場合、異なるルールが適用されます。(複数のデータベースのコピーという概念を導入している) SCR では、SCR ソース コンピュータ上のログ ファイルがすべての SCR ターゲット コンピュータによって検査されたら、それらのログ ファイルを切り詰めることができます。SCR ソース サーバーでは、すべての SCR ターゲットにすべてのログが再生されていない場合でも、それ以上待機せずにログの切り詰めを実行します。これは、SCR ターゲットのコピーに構成されているログの再生の待ち時間が非常に長い可能性があるためです。

また、TruncationLagTime という新しいパラメータを使用すると、ログを切り詰めるまでの待ち時間をさらに長く設定することができます。このパラメータには、SCR ターゲット コンピュータにコピーされ、データベースのコピーに再生されたログ ファイルを切り詰めるまでの Exchange レプリケーション サービスの待ち時間 ("日.時:分:秒" 形式) を指定します。この待ち時間のカウントは、ログ ファイルがデータベースのコピーに正しく再生された直後に開始されます。指定可能な最大値は 7 日です。また、指定可能な最小値は 0 秒です。0 秒を指定した場合、待ち時間なしでログ ファイルが切り詰められることになります。

SCR 環境では、3 分ごとにバックグラウンド スレッドが実行され、切り詰める必要があるログ ファイルがあるかどうかが確認されます。ログ ファイルの世代シーケンスがストレージ グループのログ ファイルのチェックポイントよりも小さく、ログ ファイルが ReplayLagTime と TruncationLagTime を加算した時間よりも古い場合、SCR ターゲット上のログ ファイルは切り詰められます。

SCR によって拡張された LCR または CCR 環境では、4 つの条件が満たされたときに、SCR ターゲット上のログ ファイルが切り詰められます。これらの条件とは、ログ ファイルがバックアップされていること、ログ ファイルの世代シーケンスがストレージ グループのログ ファイルのチェックポイントよりも小さいこと、ストレージ グループのパッシブ コピーがログ ファイルの切り詰めが可能な状態になっていること、およびすべての SCR ターゲットによってログ ファイルが検査されていることです。

SCR を有効にして管理する

SCR を有効にするには、Exchange 管理シェルで Enable-StorageGroupCopy コマンドレットを使用します。SP1 では、Exchange 管理シェルにいくつかのパラメータが追加されています。既に説明したように、ReplayLagTime と TruncationLagTime を使用すると、SCR ターゲットの一部の動作を制御できます。もう 1 つ、SeedingPostponed パラメータを使用すると、SCR ターゲットの初期シードを省略できます。シードを延期することは、さまざまな状況で役立ちます。たとえば、SCR を有効にするストレージ グループ内のデータベースのサイズが 100 GB であるとします。運用サーバーの稼働率が高いときには、100 GB ものデータをネットワーク上に送信したくないと思います。SeedingPostponed パラメータを使用すると、SCR をすぐに有効にして、シード タスクを後で実行することができます。シードを実行しても問題ない時間になったら、Update-StorageGroupCopy コマンドレットを使用して、手動で SCR ターゲットのシードを実行できます。

SCR の場合、上記で説明したパラメータは Enable-StorageGroupCopy に指定しなくてもかまいませんが、StandbyMachine は必ず指定する必要があります。StandbyMachine には、SCR ターゲットとして構成するコンピュータの名前を指定します。このパラメータの値は、SCR を有効にするストレージ グループの msExchStandbyCopyMachines 属性の値の一部として設定されます。msExchStandbyCopyMachines 属性は、複数の値を持つ Unicode 文字列で、Exchange 組織に Exchange 2007 SP1 を導入したときに Active Directory スキーマに追加されます。SP1 で Active Directory スキーマの更新が必要になるのはこのためです。

StandbyMachine は SCR で中心的な役割を果たすパラメータです。また、SP1 では、このパラメータを使用して SCR ターゲットを有効にしたり管理したりできるように、いくつかのコマンドレットが更新されています。図 6 には、更新されたコマンドレットの説明が記載されています。

Figure 6 StandbyMachine パラメータを使用するコマンドレット

SCR ターゲットをアクティブにする

SCR では、元のデータが失われたり使用できなくなった場合に使用できる、データの最新のコピーが 1 つ以上提供されます。SCR ターゲットのコピーを運用データベースとして再準備する処理をアクティブ化といいます。アクティブ化は、データベースの移植性や、2 つの Setup 回復オプション (スタンドアロン サーバー用の /m:RecoverServer とクラスタ化されたメールボックス サーバー用の /RecoverCMS) のいずれかなどの回復処理の一環として実行されます。

SCR の使用例

ここでは、SCR とデータベースの移植性を使用して、どのようにメールボックス データベースの障害から回復するかについて、架空の企業を例に説明します。管理者は、運用データベースが破損していることがわかったら、データベースの移植性を使用して SCR ターゲット データベースをアクティブにします。

この組織では、Exchange 2007 SP1 を展開しており、SCR を使用してストレージ グループのコピーをリモート メールボックス サーバー上に作成することにしました。ソース メールボックス サーバーとターゲット メールボックス サーバーは同じ Active Directory サイト内にあり、Active Directory に統合された DNS サーバーを使用するように構成されています。また、Active Directory のレプリケーションの間隔は 15 分に構成されています。

SCR を有効にして回復のステージングを行う

SCR は、1 つのデータベース MBX1 を含む 1 つのストレージ グループ SG1 のトランザクション ログ ファイルをレプリケートするように構成されています。ストレージ グループ ファイルとデータベース ファイルのパスは、C:\SG1 と C:\SG1\MBX1.EDB です。この例では、EXMBX1 が SCR ソース、EXMBX2 が SCR ターゲットです。この構成は、次のコマンドレットを使用して行いました。

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

SCR を有効にした後、次のように Get-StorageGroupCopyStatus コマンドレットを使用して、SG1 の SCR の状態を確認しました。

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

SCR ターゲットのアクティブ化処理にかかる時間を短縮するために、ストレージ グループ SG1PORT とデータベース MBX1PORT を使用して、EXMBX2 をあらかじめ構成します。このストレージ グループとデータベースは、後で実行されるデータベースの移植操作の一環として使用されます。SG1PORT と MBX1PORT は、SCR ターゲットのストレージ グループとデータベース ファイルとは異なります。このため、SG1PORT と MBX1PORT のパスは、SCR ターゲットのパスと競合しない一時的なパスを使用して構成されます。SG1PORT と MBX1PORT は、データベースの移植性オブジェクトとしてのみ使用されます。SG1PORT の実際のストレージ グループとデータベース ファイルは必要ありません。このため、管理者は MBX1PORT のマウントを解除し、ストレージ グループ内のすべてのファイルを削除します。このストレージ グループ オブジェクトとデータベース オブジェクトは、後で実行される回復処理でデータベースの移植に使用されるため、Active Directory 内に残ります。

アクティブ化と回復

アプリケーション イベント ログのエントリに、SCR ソース データベースが物理的に破損していることが記録されています。SCR は SG1 で有効になっているため、SG1 の SCR ターゲット データベースを手動でアクティブにし、データベースの移植性を使用してデータの可用性を回復させることにします。SCR ターゲットのコピーをアクティブにするには、まず次のコマンド レットを使用して、SG1 の MBX1 のマウントを解除します。

Dismount-Database EXMBX1\SG1\MBX1

これにより、SCR ターゲット データベースがマウント可能な状態になり、MBX1 にあったメールボックスが MBX1PORT に移動します。

SCR を無効にし、SCR ターゲット データベースをマウント可能な状態にするには、Restore-StorageGroupCopy コマンドレットも実行する必要があります。このタスクを実行すると、ストレージ グループのデータベースがマウント可能なデータベースとしてマークされます。また、そのストレージ グループのデータベースをマウントしたことによってデータが失われた場合、そのことに関するレポートが提供されます。さらに、ストレージ グループのアクティブ コピーによって生成されたすべてのログ ファイルが、パッシブ コピーのストレージ グループ ファイルと同じ場所にあるかどうかも確認されます。見つからないログ ファイルがある場合は、それらのコピーを試行します。SCR ターゲット データベースをマウント可能な状態にするには、次のコマンドレットを使用します。

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

この例では、SCR ソース ストレージ グループからログ ファイルをコピーできます。これらのファイルをコピーできない場合 (SCR ソース コンピュータがダウンしている場合など) は、Restore-StorageGroupCopy タスクに Force パラメータを追加する必要があります。追加しなかった場合、Restore-StorageGroupCopy は常に SCR ソースに接続して、見つからないログ ファイルをコピーしようとします。SCR ソースが利用できない場合、Restore-StorageGroupCopy タスクは失敗するため、データベースをマウントできる状態にはなりません。Force パラメータを追加すると、ソース ファイルが利用できないことを Restore-StorageGroupCopy タスクが認識してソース ファイルへの接続を省略し、SCR ターゲット データベースをマウント可能な状態にします。

管理者は、Restore-StorageGroupCopy コマンドが完了した後、データベースがクリーン シャットダウン状態であるかどうかを確認する必要があります。データベースがダーティ シャットダウン状態 (technet.microsoft.com/aa996757.aspx を参照してください) である場合は、クリーン シャットダウン状態にする必要があります。データベースの移植 (EXMBX2\SG1PORT) に使用されるストレージ グループのログ ファイル プレフィックス (E00 や E01 など) が、SCR ソース (EXMBX1\SG1) と、SCR ターゲット上のストレージ グループ (SG1PORT) との間で等しい場合、Eseutil を回復モードで実行する必要はありません。レプリケートされたすべてのログ ファイルが再生された後に実行される最後のデータベース マウント操作によって、データベースはクリーン シャットダウン状態になります。データベースがクリーン シャットダウン状態になっていない場合は、データベースに対して Exchange Server データベース ユーティリティ (Eseutil) を回復モード (Eseutil /r) で実行する必要があります。

データベースがクリーン シャットダウン状態になったら、次の 2 つのコマンドを実行して、Active Directory に登録されているストレージ グループ ファイルとデータベース ファイルの場所を更新できます。これらのコマンドによって、SG1PORT と MBX1 のパスが元のパスからステージング ストレージ グループとステージング データベース (SG1PORT と MBX1PORT) のパスに変更されます。

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

上記のコマンドには、これらのオブジェクトの構成設定のみが Active Directory で更新されるように、–ConfigurationOnly パラメータを指定する必要があります。移動されるデータやファイルはなく、その必要もありません。データは既に SCR によって EXMBX2 の C:\SG1 にレプリケートされています。

次は、データベース (MBX1PORT) を復元操作時に上書きできるように構成します。これを行うには、Exchange 管理コンソールでデータベース オブジェクトのプロパティの [復元時はこのデータベースを上書きする] チェック ボックスをオンにするか、Exchange 管理シェルで次のコマンドを実行します。

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

データベースを上書きできるように構成したら、次のコマンドを実行してデータベースをマウントします。

Mount-Database EXMBX2\SG1PORT\MBX1PORT

データベースをマウントしたら、SCR ソース データベース (SG1\MBX1) 上にあるメールボックスを EXMBX2 の MBX1PORT に移動する必要があります。これを行うには、Get-Mailbox コマンドレットを実行し、出力を Move-Mailbox コマンドレットに渡すだけです。この処理では、Move-Mailbox コマンドレットに渡される Get-Mailbox コマンドレットの出力に Exchange System Attendant とシステム メールボックスが含まれないことに注意する必要があります。これらのメールボックスを移動する必要はなく、移動するべきでもありません。システム メールボックスを除くすべてのユーザー メールボックスを移動するには、次のコマンドを実行します。

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

これで、クライアントが MBX1PORT にアクセスできるようになりました。ただし、ユーザー メールボックスが EXMBX1\SG1\MBX1 から EXMBX2\SG1PORT\MBX1PORT に移動された後に、ユーザーが各自のメールボックスにアクセスできるかどうかは、Active Directory のレプリケーションの待ち時間によって決まります。つまり、ディレクトリ サーバーの数によっては、環境全体に変更が反映されるまでに時間がかかる場合があるということです。また、クライアントのアクセス方法も重要です。Outlook 2007 を実行しているメッセージング クライアントと Outlook 以外を実行しているクライアントは、ユーザーのクライアント アクセス サーバーによって使用されるディレクトリ サーバーのパスが新しいものに更新されたら、各ユーザー メールボックスにアクセスできるようになります。Outlook 2003 またはそれ以前のバージョンを実行しているメッセージング クライアントは、ユーザーのデスクトップのメッセージング プロファイルに指定されているサーバー名を新しいものに更新する必要があります。

最後の手順

クライアントが各自のメールボックスとメールボックス内のデータにアクセスできるようになったら、最後に SCR を再有効化して冗長性を確保します。これを行うには、EXMBX1 に残っているストレージ グループとデータベース ファイルをすべて削除します。これらのファイルを削除したら、EXMBX1\SG1\MBX1 のパスを一時的な場所に移動し、EXMBX1 を EXMBX2 の SCR ターゲットにすることができます。

Scott Schnoll は、マイクロソフトの Exchange Server チームで、プリンシパル テクニカル ライターとして Exchange Server 2007 向けのコンテンツを執筆しています。マイクロソフトに勤務する前、彼は『Exchange Server 2003 Distilled』(Addison-Wesley Professional、2004 年) を執筆しました。また、『Exchange 2000 Server: The Complete Reference』(McGraw-Hill/OsborneMedia、2001 年) の主執筆者も務めました。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.