Exchange Server 2003 の信頼性とクラスタ化に関する機能

 

ここでは、Microsoft® Exchange Server 2003 の信頼性とクラスタ化に関するいくつかの重要な更新情報について説明します。Exchange クラスタ化を実装した場合または実装しない場合の Exchange 2003 環境の信頼性を確保する方法の詳細については、『Planning an Exchange Server 2003 Messaging System』の「Planning for Reliability」(英語) を参照してください。

信頼性に関する機能

Exchange 2003 では、Exchange 組織の信頼性を強化するために以下の機能が強化もしくは追加されています。

• 仮想メモリ管理
  Exchange 2003 では、仮想メモリの強化によってメモリの断片化が減少し、サーバーの可用性が高くなっています。

• メールボックス回復センター
  新たに追加されたメールボックス回復センターを使用すると、接続を解除された複数のメールボックス上で同時に回復操作またはエクスポート操作を実行できます。

• 回復用ストレージ グループ
  新たに追加された回復用ストレージ グループは、Exchange の通常のストレージ グループと共存できる、特定の用途に使用するストレージ グループです。この機能を使用すると、主にメールボックスおよびメールボックス データベースを復元する際の柔軟性が高まります。

• エラー報告
  Exchange 2003 では、エラー報告コンポーネントも強化されています。Exchange のエラー報告機能を使用すると、発生する可能性があるすべての障害についての情報を Microsoft に送信することができます。Microsoft では、送信された情報を基に今後発売されるバージョンでの更新内容を判断し、その優先順位を決定します。

ここでは、以上の機能について詳しく説明します。

仮想メモリ管理機能の強化

Exchange 2003 では、仮想メモリ管理プロセスが強化されています。具体的には、仮想メモリのブロックを再利用する手法が大幅に効率化されています。これらの設計上の強化によって、断片化が減少し、多数のユーザーを処理するハイエンド サーバーとしての可用性が向上しています。

また、クラスタ化された Exchange サーバーの仮想メモリ管理機能も強化されています。Exchange の従来のバージョンでは、Microsoft Exchange Information Store (MSExchangeIS) サービスはパッシブ ノード上で引き続き実行されます。その結果、Exchange 仮想サーバーが障害の発生したノードへ手動で移動された場合や自動的にフェールバックされた場合、MSExchangeIS サービスは、断片化された仮想メモリを含むサーバー上で実行されることになります。

Exchange 2003 では、Exchange 仮想サーバーが別のノードに手動で移動された場合やフェールオーバーされた場合、そのノード上の MSExchangeIS サービスは停止されます。次に、Exchange 仮想サーバーがそのノードに移動またはフェールバックされると、新しい MSExchangeIS サービスが開始され、その結果、仮想メモリのフレッシュ ブロックが MSExchangeIS サービスに割り当てられます。

仮想メモリについてこれらの点が強化されましたが、これまでと同様に、仮想メモリのパフォーマンスを監視することは重要です。次の表は、仮想メモリのパフォーマンスの監視に使用できる MSExchangeIS カウンタの一覧です。

仮想メモリ用のパフォーマンス モニタ

カウンタ	説明
VM Largest Block Size	仮想メモリの最大空きブロックのサイズがバイト単位で表示されます。このカウンタは、仮想メモリが消費されるに従って下向きに傾斜する線で表されます。このカウンタの値が 32 MB 未満になると、Exchange 2003 によって警告 (イベント ID = 9582) がイベント ログに出力され、16 MB 未満になるとエラーがログ出力されます。このカウンタを監視し、値が常に 32 MB を上回っている状態にすることが重要です。
VM Total 16MB Free Blocks	16 MB 以上の空き仮想メモリ ブロックの総数が表示されます。モニタにはこの値はピラミッド形の線で表示されます。線は、16 MB を超える仮想メモリの 1 つのブロックから始まり、ブロックがいっぱいになるごとに下降を始めます。このカウンタの動作傾向を監視することにより、システム管理者は 16 MB のブロックの数が 3 つ未満になる可能性が高い時期を予測できます。予測された時期に、ノード上のすべてのサービスを再起動することをお勧めします。
VM Total Free Blocks	サイズにかかわりなく、空き仮想メモリ ブロックの総数が表示されます。モニタにはこの値はピラミッド形の線で表示されます。このカウンタから、利用可能な仮想メモリがどの程度断片化されているかを知ることができます。ブロック サイズの平均値は、Process\Virtual Bytes\STORE インスタンスを MSExchangeIS\VM Total Free Blocks で割った値です。
VM Total Large Free Block Bytes	16 MB 以上のすべての空き仮想メモリ ブロックの合計容量がバイト単位で表示されます。値を表す線は、メモリが消費されるに従って下向きに傾斜します。

これらのカウンタを監視する際は、VM Total Large Free Block Bytes の値が常に 32 MB 以上に維持されるように注意してください。クラスタ化されていないサーバーで VM Total Large Free Block Bytes の値が 32 MB 未満になった場合は、そのサーバー上のサービスを再起動してください。クラスタ化されたサーバーでクラスタ内のノードが 32 MB 未満になった場合は、Exchange 仮想サーバーをフェールオーバーし、ノード上のすべてのサービスを再起動してからその Exchange 仮想サーバーをフェールバックします。

Exchange 2003 サーバーの仮想メモリの断片化が著しい場合は、MSExchangeIS サービスによって以下のイベントがログ出力されます (例 1 および例 2)。

例 1   最大空きブロックが 32 MB 未満になった場合にログ出力される警告

EventID=9582

Severity=Warning

Facility=Perfmon

Language=English

The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.

例 2   最大空きブロックが 16 MB 未満になった場合にログ出力されるエラー

EventID=9582

Severity=Error

Facility=Perfmon

Language=English

The virtual memory necessary to run your Exchange server is fragmented in such a way that normal operation may begin to fail. It is highly recommended that you restart all Exchange services to correct this issue.

システム モニタおよびイベント ビューアの詳細については、Microsoft Windows Server™ 2003 のオンライン ドキュメントを参照してください。

メールボックス回復センター

新たに追加されたメールボックス回復センターを使用すると、接続を解除された複数のメールボックス上で同時に回復操作またはエクスポート操作を実行できます。Exchange 2000 では、このような操作は切断されたメールボックスごとに個別に行う必要があったため、これは画期的な機能強化です。この新機能を使用すれば Exchange メールボックスを速やかに復元できるため、ダウンタイムを短縮することができます。

回復用ストレージ グループ

Exchange 2003 には回復用ストレージ グループが追加されたため、メールボックスおよびストレージ グループを復元する際の柔軟性が強化されています。この新機能を使用すれば Exchange データを速やかに復元できるため、ダウンタイムを短縮することができます。回復用ストレージ グループ機能の使用の詳細については、「Exchange Server 2003 のストレージに関する機能」の「回復用ストレージ グループ」を参照してください。

エラー報告機能の強化

エラー報告機能は Exchange 2000 SP2 および SP3 でも提供されていましたが、Exchange 2003 では実装が強化されています。

エラー報告は、サーバーの管理者が Microsoft にエラーを簡単に報告できるようにするための機能です。Microsoft はエラー報告を収集し、その情報を製品の機能強化に使用します。既定では、Exchange システム マネージャまたは Active Directory ユーザーとコンピュータ スナップインを使用して Exchange 関連の操作を行っているときに致命的なアプリケーション エラーが発生すると、エラーが発生したことを警告メッセージを使用して管理者に通知します。このメッセージには、アプリケーションを終了する必要があるという内容が含まれ、エラー報告を Microsoft に送信するかどうかを確認するメッセージも含まれています。

同様に、Exchange に関するサービス関連の致命的なエラーが発生した場合も、Microsoft に報告を送信するかどうかを確認するダイアログ ボックスが表示されます。

注 :
既定では、サービス関連の致命的なエラーが発生した場合に、エラー報告を送信するかどうかを確認するダイアログ ボックスが直ちに表示されることはありません。代わりに、管理者が次回サーバーにログオンする際に、サービス関連のエラーを報告するかどうかを確認するダイアログ ボックスが表示されます。

エラー報告は、セキュリティで保護された HTTPS 接続を介して、通常は 10 ～ 50 KB の圧縮ファイルとして Microsoft に送信されます。エラー報告はミニダンプ ファイルとも呼ばれます。ミニダンプ ファイル内の情報の収集方法と送信方法に関する詳しい技術情報については、「ワトソン博士を使用する」を参照してください。エラー報告に関する一般的な情報については、「Should I send Microsoft an error report when my program crashes?」(英語) を参照してください。

Exchange 2000 SP2 および SP3 では、管理者が Microsoft にエラー報告を送信するかどうかを選択できる標準のエラー報告ダイアログ ボックスがサポートされていました。Exchange 2003 では、Exchange 2000 SP3 と同じエラー報告機能に加え、次の新機能もサポートされています。

• 短時間の間に発生する Exchange サービス関連のエラーはキューに格納され、管理者に一括で表示されます。

  注 :
  エラー報告ダイアログ ボックスを使用せず、サービス関連のエラーが Microsoft へ自動的に送信されるように Exchange を構成する方法については、後の「サービス関連のエラー報告が自動的に送信されるように Exchange を構成する方法」を参照してください。

• 企業エラー報告 (CER) 機能がサポートされるようになりました。CER は管理者向けに開発されたツールで、Microsoft Windows エラー報告クライアント、およびアプリケーションに付属しているエラー報告クライアントによって作成されるエラー報告を管理するために使用されます。CER のインストールと使用については、Corporate Error Reporting Web サイト (英語) を参照してください。

• Exchange のセットアップ エラーに関するサポート機能 (セットアップ エラーをキューに格納し、セットアップ完了後にすべてを一覧表示する機能など) が追加されました。

• 受信者更新サービス (RUS) に関連するエラーのサポートが強化されました。Exchange 2003 では、RUS に関連する重大なエラー (RUS による受信者オブジェクトの更新時に発生するアクセス違反など) が発生すると、エラーに関する情報を Microsoft に送信できるよう、Microsoft エラー報告エラー メッセージが直ちに生成されます。これは重要な機能です。RUS 関連のエラーが発生すると、システム アテンダントが不安定な状態になるためです。
  RUS 関連のこれらのエラー報告機能は、Exchange 2000 に比べて大幅に強化されています。Exchange 2000 では、RUS 関連のエラーが発生しても、イベント ログにイベントが書き込まれるだけでした。そのため、管理者にはそれらのエラーが直ちに通知されませんでした。

サービス関連のエラーが自動的に送信されるように Exchange を構成する方法の詳細については、「サービス関連のエラーの自動報告を有効にする方法」を参照してください。

クラスタ化に関する機能

ここでは、Exchange 2003 のクラスタ化に関する重要な更新について説明します。Exchange 2003 のクラスタ化の詳細については、以下の資料を参照してください。

• 計画に関する情報については、『Exchange Server 2003 メッセージング システムの計画』の「サーバーのクラスタ化の使用」を参照してください。
• 展開に関する情報については、『Exchange Server 2003 デプロイメント ガイド』の「クラスタへの Exchange 2003 の展開」を参照してください。
• 管理に関する情報については、『Exchange Server 2003 Administration Guide』の「Managing Exchange Server Clusters」(英語) を参照してください。

Exchange 2003 では、クラスタ化に関する以下の機能が強化もしくは追加されています。

• 最大 8 ノードのクラスタのサポート
  Windows Server 2003 Enterprise Edition または Windows Server 2003 Datacenter Edition を使用する場合、最大 8 ノードのアクティブ/パッシブ クラスタのサポートが追加されました。

• ボリュームのマウント ポイントのサポート
  Windows Server 2003 Enterprise Edition または Windows Server 2003 Datacenter Edition を使用する場合、ボリュームのマウント ポイントのサポートが追加されました。

• フェールオーバーのパフォーマンスの向上
  新しいノードへのサーバーのフェールオーバーに必要な時間を短縮することによって、クラスタ化のパフォーマンスが向上しています。

• セキュリティの強化
  Exchange クラスタ サーバーでは、セキュリティが強化されています。たとえば、Exchange 2003 のアクセス許可モデルが変更されています。

• 前提条件の確認処理の強化
  Exchange では、クラスタ サーバーの展開と構成が適切に行われるように、前提条件について従来よりも多くの確認処理が実行されるようになりました。

ここでは、以上の機能について詳しく説明します。

最大 8 ノードのクラスタのサポート

Exchange 2003 では、8 ノードの Exchange クラスタをサポートすることにより、クラスタ機能が拡張されています。8 ノードのクラスタは、Windows Server 2003 Enterprise Edition または Windows Server 2003 Datacenter Edition を実行している場合にのみサポートされています。8 ノード クラスタに関するその他の要件として、パッシブ ノードが少なくとも 1 つ存在する必要があります。

注 :
Exchange 2003 クラスタ化に関する推奨事項は、すべてアクティブ/パッシブ クラスタ構成に関連するものです。アクティブ/アクティブ クラスタ化は、引き続き 2 つのノード上でサポートされます。

必要な Windows および Exchange のバージョン

Exchange クラスタを作成するためには、Windows Server と Exchange Server の特定のバージョンが必要になります。次の表は、これらの要件の一覧です。

必要な Windows および Exchange のバージョン

Windows のバージョン	Exchange のバージョン	使用できるクラスタ ノードの数
Windows® 2000 Server または Windows Server 2003 ファミリの任意のサーバー	Exchange Server 2003, Standard Edition	なし
Windows 2000 Server または Windows Server 2003, Standard Edition	Exchange Server 2003, Standard Edition または Exchange Server 2003, Enterprise Edition	なし
Windows 2000 Advanced Server	Exchange Server 2003, Enterprise Edition	2 つまで
Windows 2000 Datacenter Server	Exchange Server 2003, Enterprise Edition	4 つまで
Windows Server 2003, Enterprise Edition	Exchange Server 2003, Enterprise Edition	8 つまで
Windows Server 2003, Datacenter Edition	Exchange Server 2003, Enterprise Edition	8 つまで

ボリューム マウント ポイントのサポート

Exchange 2003 では、使用しているクラスタのノードが 4 つ以上で、各ノードが Windows Server 2003 Enterprise Edition または Datacenter Edition を実行している場合に、共有ディスク上のボリューム マウント ポイントがサポートされるようになりました。ボリューム マウント ポイントは、指定されたディスク ボリュームを永続的にポイントするディレクトリです。たとえば、C:\Data があるディスク ボリュームをポイントするように構成することができます。マウント ポイントを使用すると、個々のディスク ボリュームをドライブ文字に関連付ける必要がなくなり、26 のアルファベット文字数に制限されることなくディスク ボリュームを割り当てることができます。

マウントされたドライブの詳細については、Windows Server 2003 のドキュメントを参照してください。

フェールオーバー時間の短縮

Exchange 2003 のクラスタ化に関しては、別のノードへのフェールオーバーに必要な時間が短縮され、その結果全体的なパフォーマンスが向上しました。ここでは、フェールオーバー時間に関して強化された点について説明します。

Exchange サービスの依存関係の階層の機能強化

サーバーのフェールオーバーに必要な時間を短縮するため、Exchange 2003 では Exchange サービスの依存関係の階層が機能強化されています。具体的には、以前は Microsoft Exchange Information Store サービスに依存していた Exchange のプロトコル サービスが、Microsoft Exchange System Attendant サービスに依存するようになりました。

注 :
Exchange 2003 では、新しい Exchange 仮想サーバーを作成する際に、IMAP4 リソースおよび POP3 リソースは自動的に作成されません。

このように依存関係の階層が機能強化されたため、フェールオーバーが発生した場合には、Exchange メールボックス ストア、パブリック フォルダ ストア、および Exchange プロトコルの各サービスを同時にオンラインにすることができます。その結果、システム アテンダント サービスを除くすべての Exchange リソースを同時に開始および停止できるようになり、それに伴いフェールオーバー時間が短縮されました。さらに、Exchange ストアは、停止した場合でも他のサービスに依存することなく再開できるようになりました。

その他の利点として、Exchange 仮想サーバーのフェールオーバーに伴うシステム ダウン時間の短縮を挙げることができます。ダウンタイムが短縮されるのは数分ですが、Windows 2000 上で実行される Exchange 仮想サーバーの平均のフェールオーバー時間がわずか 3 ～ 8 分 (Exchange 仮想サーバーがホストするユーザーの数によって異なります) であることを考えると、大いに意義があります。

使用可能なノードの検出機能の強化

Windows Server 2003 上で Exchange 2003 を実行する場合に、使用可能なノードを検出してそのノードへフェールオーバーする時間が短縮されました。したがって、計画的なフェールオーバーと予定外のフェールオーバーのいずれの場合においても、システム ダウン時間が短縮されます。

セキュリティの強化

Exchange 2003 のクラスタ化には、次のセキュリティ機能が含まれています。

• アクセス許可が強化されます。
• Kerberos が既定で有効になります。
• フロントエンド サーバーおよびバックエンド サーバーのための IPSec がサポートされます。
• Exchange 仮想サーバーの作成時に IMAP4 サービスおよび POP3 サービスは作成されません。

ここでは、以上の機能について詳しく説明します。

クラスタ化に関するアクセス許可モデルの変更

Exchange 2003 では、Exchange 仮想サーバーの作成、削除、または変更に必要なアクセス許可が変更されました。それらの変更点を理解する最適な方法は、Exchange 2000 のアクセス許可モデルを Exchange 2003 の新しいアクセス許可モデルと比較することです。

Exchange 2000 のアクセス許可モデル

Exchange 2000 でクラスタの管理者が Exchange 仮想サーバーを作成、削除、または変更する場合、クラスタ管理者とクラスタ サービスのアカウントには以下のアクセス許可が必要です。

• その Exchange 仮想サーバーが、Exchange 組織で最初の Exchange 仮想サーバーの場合は、クラスタ管理者のアカウントとクラスタ サービスのアカウントがそれぞれ、組織レベルで適用された Exchange 管理者 (完全) 役割を持つグループのメンバである必要があります。
• その Exchange 仮想サーバーが、組織で最初の Exchange 仮想サーバーでない場合は、クラスタ管理者のアカウントとクラスタ サービスのアカウントがそれぞれ、管理グループ レベルで適用された Exchange 管理者 (完全) 役割を持つグループのメンバである必要があります。

Exchange 2003 のアクセス許可モデル

Exchange 2003 ではアクセス許可モデルが変更されました。Windows クラスタ サービス アカウントは、Exchange 組織レベルまたは管理グループ レベルのいずれについても、Exchange 管理者 (完全) 役割が適用されている必要がありません。Windows クラスタ サービス アカウントは、Exchange 固有のアクセス許可を必要としません。フォレスト内での既定のアクセス許可のみで、Exchange 2003 での機能を実行できます。Exchange 仮想サーバーの作成、変更、および削除に必要なのは、クラスタ管理者のログオン アクセス許可のみです。

Exchange 2000 の場合と同様に、クラスタ管理者には以下のアクセス許可が必要です。

• 対象の Exchange 仮想サーバーが組織内の最初の Exchange 仮想サーバーである場合、クラスタ管理者は、組織レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要があります。
• 対象の Exchange 仮想サーバーが組織内の最初の Exchange 仮想サーバーでない場合は、管理グループ レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバであるアカウントを使用する必要があります。

ただし、Exchange 組織の運用モード (ネイティブ モードまたは混在モード) とトポロジの構成に応じて、クラスタ管理者には次のアクセス許可も必要となります

• Exchange 組織がネイティブ モードで実行され、Exchange 仮想サーバーが複数の管理グループにまたがるルーティング グループに属している場合、クラスタ管理者は、ルーティング グループのすべての管理グループ レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要があります。たとえば、Exchange 仮想サーバーが 1 番目の管理グループと 2 番目の管理グループにまたがるルーティング グループに属している場合、クラスタ管理者は、1 番目の管理グループで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバであるアカウントを使用する必要があり、さらに 2 番目の管理グループで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要もあります。

  注 :
  Exchange ネイティブ モード組織内のルーティング グループは、複数の管理グループにまたがることができます。Exchange 混在モード組織内のルーティング グループは、複数の管理グループにまたがることができません。

• 親ドメインと子ドメインを持つトポロジにおいて、クラスタ サーバーが子ドメイン内の最初の Exchange サーバーとなっている場合、子ドメインで受信者更新サービスを担当するサーバーを指定するには、クラスタ管理者が組織レベルで Exchange 管理者以上の役割が割り当てられているグループのメンバである必要があります。

Exchange 仮想サーバーにおける既定での Kerberos の有効化

Kerberos 認証プロトコルは、ユーザーとネットワークの両方が安全であることを確認するためにデータを検証するセキュリティ プロトコルです。Exchange 2000 では、Exchange 仮想サーバーの既定の認証方法として NTLM プロトコルが使用されていました。これは、Windows 2000 Service Pack 3 (SP3) が提供されるまで、Windows クラスタ サービスでクラスタ グループの Kerberos の有効化がサポートされなかったためです。

Exchange 2003 では、Windows Server 2003 または Windows 2000 SP3 を実行するサーバー上で Exchange 仮想サーバーを作成すると、Kerberos 認証プロトコルが既定で有効になります。

フロントエンド/バックエンド クラスタ構成のための IPSec のサポート

フロントエンド クラスタ サーバーとバックエンド クラスタ サーバーの間にセキュリティで保護されたチャネルが必要な場合は、インターネット プロトコル セキュリティ (IPSec) を使用できます。この構成は、フロントエンド サーバーとバックエンド サーバーの両方が Windows Server 2003 上で Exchange 2003 を実行している場合に完全にサポートされます。

既定では追加されない IMAP4 リソースおよび POP3 リソース

IMAP4 プロトコルと POP3 プロトコルを必要としない Exchange サーバーもあるため、Exchange 仮想サーバーの作成時に IMAP4 プロトコル リソースと POP3 プロトコル リソースは作成されなくなりました。

クラスタ化の前提条件の確認

Exchange 2003 では、以前のバージョンの Exchange に比べ、クラスタに関する前提条件の確認がより詳細に行われます。たとえば、Exchange がクラスタ ノードに正しくインストールされるように、クラスタのノードに対するインストール前の確認をより詳細に行います。同様に、Exchange 仮想サーバーが適切に構成されるように、Exchange 仮想サーバーを作成および削除するときにもより多くの項目を確認します。

Exchange 2003 クラスタに関する要件

Windows 2000 Server クラスタまたは Windows Server 2003 クラスタ上の Exchange 2003 のアップグレード、またはこれらの環境への Exchange 2003 のインストールを計画する場合は、考慮する必要がある重要な要件がいくつかあります。重要な要件は次のとおりです。

• DNS (ドメイン ネーム システム) の構成を定義するシステム全体の要件
• 特定のクラスタ展開でサポートする Windows オペレーティング システムを定義するサーバー固有の要件
• クラスタのノード間で適切な通信を行うためのネットワーク構成の要件

これらの要件の詳細については、『Exchange Server 2003 デプロイメント ガイド』の「クラスタの要件」を参照してください。

Exchange Server 2003 のセットアップに関する要件

Windows 2000 Server または Windows Server 2003 上の Exchange 2003 のアップグレード、またはこれらの環境への Exchange 2003 のインストールを行う前に、満たしておく必要がある要件が多数あります。ほとんどの要件は、Exchange 2003 をスタンドアロン (クラスタ化されていない) サーバーにインストールする場合の要件と同じです。たとえば、クラスタのノードで Exchange Server 2003 のセットアップを実行する前に、インターネット インフォメーション サービスおよびその他の Windows サービスを起動しておく必要があります。同様に、Exchange 2003 用に Active Directory を準備しておく必要があります。

クラスタのノードで Exchange Server 2003 のセットアップを実行する場合は、その他にも考慮が必要な要件があります。たとえば、最初に Microsoft 分散トランザクション コーディネータ (MSDTC) をクラスタにインストールしておく必要があります。

クラスタに Exchange 2003 をインストールする場合の手順と要件については、『Exchange Server 2003 デプロイメント ガイド』の「新しい Exchange 2003 クラスタの展開」または「Exchange 2000 クラスタから Exchange 2003 へのアップグレード」を参照してください。

Exchange 2000 のクラスタおよび Exchange 仮想サーバーの Exchange 2003 へのアップグレード

クラスタを Exchange 2000 から Exchange 2003 にアップグレードするには、まず Exchange Server 2003 のセットアップを実行して、クラスタのノードをアップグレードします。次に、クラスタ アドミニストレータを使用して、Exchange 仮想サーバーをアップグレードします。一度に 1 つずつ Exchange クラスタ ノードをアップグレードすることをお勧めします。

各ノードをアップグレードするときに、Exchange 仮想サーバーを、アップグレードするノードから別のノードに移動することをお勧めします。この処理を行うことで、Exchange 2003 のアップグレード処理中でも、ユーザーは再配置された Exchange 仮想サーバーを通じて自分の電子メール メッセージにアクセスできます。

次の表は、Exchange 2000 クラスタ ノードと Exchange 仮想サーバーを Exchange 2003 にアップグレードするための要件を示しています。

注 :
Exchange 2000 クラスタを Exchange 2003 にアップグレードする方法については、『Exchange Server 2003 デプロイメント ガイド』の「Exchange 2000 クラスタから Exchange 2003 へのアップグレード」を参照してください。

クラスタ ノードをアップグレードするための要件

項目	要件
アクセス許可	アカウントは、管理グループ レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要があります。
クラスタ リソース	Exchange のセットアップではクラスタ サービスを再利用する必要があるため、アップグレードするノードではクラスタ リソースを実行することができません。ノードが 1 つだけのクラスタは例外です。 クラスタのいずれかのノードで MSDTC リソースを実行している必要があります。
その他	Exchange 2003 にアップグレードできるのは、Exchange 2000 SP3 以降を実行しているサーバーだけです。それ以前のバージョンの Exchange を実行しているサーバーについては、まず Exchange 2000 SP3 以降にアップグレードする必要があります。 クラスタ ノードは一度に 1 つずつアップグレードする必要があります。 クラスタ サービスが初期化され、実行されている必要があります。 3 つ以上のノードがある場合は、クラスタをアクティブ/パッシブにする必要があります。ノードが 2 つ以下の場合は、アクティブ/アクティブでもかまいません。
Windows 2000 を実行している場合	Windows 2000 SP4 または修正プログラム 329938 を適用した Windows 2000 SP3 が必要です。 Windows 2000 SP4 は、Windows 2000 Service Pack Web サイトから入手できます。 Windows 2000 SP3 修正プログラムを入手するには、マイクロソフト サポート技術情報の文書番号 329938「Windows 2000 クラスタ ノードにインストールされた Exchange Server のアクセスに Outlook Web Access を使用できない」を参照してください。

Exchange 仮想サーバーをアップグレードするための要件

項目	前提条件
アクセス許可	Exchange 仮想サーバーが組織内でアップグレードする最初のサーバーである場合、またはドメイン内でアップグレードする最初のサーバーである場合、アカウントは、組織レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要があります。 Exchange 仮想サーバーが組織内でアップグレードする最初のサーバーでない場合、またはドメイン内でアップグレードする最初の Exchange サーバーでない場合、アカウントは、管理 グループ レベルで Exchange 管理者 (完全) の役割が割り当てられたグループのメンバである必要があります。
クラスタ リソース	ネットワーク名リソースがオンラインである必要があります。 物理ディスク リソースがオンラインである必要があります。 System Attendant リソースはオフラインである必要があります。
その他	クラスタ アドミニストレータを実行しているコンピュータの Exchange のバージョンが、Exchange 仮想サーバーのあるノードと同じバージョンである必要があります。 Exchange 仮想サーバーは一度に 1 つずつアップグレードする必要があります。