Exchange Queue & Aディスク パーティションの配置、SCR の計画など
Henrik Walther
Q 現在、Exchange Server 2003 から新しい Exchange Server 2007 組織への移行を計画しています。パブリック フォルダを新しい組織にレプリケートするため、Microsoft® 組織間のレプリケーション (IORepl) ツールの使用を予定しています。しかし、移行先の Exchange 2007 サーバーでは IORepl がサポートされないため、Exchange 2003 サーバーを移行先の Exchange 組織に加える必要があると聞きました。
A Exchange 2003 組織と Exchange 2007 のみの組織との間での空き時間情報データやパブリック フォルダのレプリケートはサポートされないという噂がありますが、そんなことはありません。事実、Exchange 2007 の他のサーバーの役割を指定しないで Exchange 2007 管理ツールをインストールしたサーバー上では IORepl の使用が完全にサポートされます。ただし、製品の基本インストールの一環として Microsoft Exchange Server Messaging Application Programming Interface (MAPI) クライアントと Collaboration Data Objects (CDO) がインストールされなくなったため、これらをインストールする必要があることに注意してください。
Q 150,000 の接続クライアントで構成される大規模組織向けに Exchange Server 2007 の設計を行っていて、Exchange 2007 メッセージング インフラストラクチャに必要なグローバル カタログ サーバーの数を計算する必要があります。どうすればよいでしょうか。
A わかりました。そもそも、こうした疑問にお答えするためにこのコラムがあるのですから。まず、グローバル カタログ サーバーの数 (さらに具体的に言えばコアの数、ただしここではプロセッサのことを話題にしているのではありません) を計算する際、Exchange 2007 メールボックス サーバーの使用予定合計コア数を基にする必要があることを理解してください。グローバル カタログ サーバーのコア数はメールボックス サーバーの数のみを基に計算します。クライアント アクセス、ハブ トランスポート、ユニファイド メッセージング、エッジ トランスポートなど、Exchange 2007 の他のサーバーの役割は含めません。Exchange 2007 の他のサーバーの役割も、必要なグローバル サーバーの数に影響しますが、こうした Exchange 2007 の他のサーバーの役割は、展開されるメールボックス サーバーの数に影響されるため、グローバル カタログ サーバーの必要数はメールボックス サーバーの数を基に計算できます。
また、グローバル カタログのコア数は、Active Directory® インフラストラクチャ内で 32 ビットベースのドメイン コントローラを使用しているか、64 ビットベースのドメイン コントローラを使用しているかによっても異なります。32 ビット ドメイン コントローラの場合、4 対 1 の比率を使用します。つまり、メールボックス サーバーのコア 4 つにつき 1 つのグローバル カタログ コアを計画します。64 ビット ドメイン コントローラの場合、8 対 1 の比率を使用します。したがって、たとえば、8 コアがインストールされた Exchange 2007 メールボックス サーバーを展開していて、64 ビット ドメイン コントローラを使用しているとすると、Exchange 2007 メールボックス サーバー 1 つにつき 1 つのグローバル カタログ サーバーが必要になります。最後に、64 ビット ドメイン コントローラを使用している場合は、Active Directory データベース (NTDS.DIT ファイル) 全体をメモリ内にキャッシュできるように、十分なメモリを組み込んでいることを確認してください。
Q 前の回答の中で、Exchange 2007 メールボックス サーバーあたりのグローバル カタログ サーバーの数に関する推奨事項が説明されています。では、展開する必要のある Exchange 2007 ハブ トランスポート サーバーの役割の数とクライアント アクセス サーバーの役割の数はどのように考えればよいでしょうか。
A 前の回答では、展開する必要のある Exchange 2007 クライアント アクセス サーバーとハブ トランスポート サーバーの数 (さらに具体的に言えばサーバー コアの数) はメールボックス サーバーのコア数に密接に関係していることを示しています。明確な規則はありませんが、経験則ではメールボックス サーバーのコア数 4 つにつき 1 つのクライアント アクセス サーバー コア (4 対 1 の比率)、メールボックス サーバーのコア数 7 つにつき 1 つのハブ トランスポート サーバー コア (7 対 1) が必要です。このハブトランスポート サーバーの数は、ウイルス対策スキャンがインストールされていないハブトランスポート サーバーの場合です。Forefront Security for Exchange のようなウイルス対策スキャン製品をインストールしている場合、一般にこの比率は、メールボックス サーバーのコア数 5 つにつき 1 つのハブ トランスポート サーバー コア (5 対 1 の比率) に近くなります。
Q Exchange 2007 サーバーに 8 プロセッサ コア以上をインストールすることは推奨されないと聞きました。これは本当ですか。本当ならその理由を教えてください。
A はい、本当です。Exchange Server 2007 にマルチコア プロセッサをインストールすると大きなメリットが得られますが、Exchange 2007 にインストールする最大コア数は 8 です。具体的には、追加のコア (最大 8) から実際にメリットを得られる Exchange 2007 サーバーの役割はハブ トランスポート サーバーの役割とメールボックス サーバーの役割の 2 つだけです。また、こうしたメリットが得られるのは、何百万ものメッセージを処理し、何千ものメールボックスを格納する、きわめて使用頻度の高い Exchange 2007 サーバーのみです。
Exchange 製品グループでは、Exchange 2007 メールボックス サーバーに 12 プロセッサ コアをインストールして実際にテストを行いましたが、ストアのパフォーマンスとスケーラビリティに悪影響が見受けられました。また、コア数を 8 から 16 に増やすと、リモート プロシージャ コール (RPC) の平均待機時間が倍になることがわかりました。
きわめて使用頻度の高いメールボックス サーバーを想定する場合を除いて、通常は 4 プロセッサ コアで十分です。Exchange 2007 サーバーの役割に関する詳細情報とプロセッサの考慮事項については、technet.microsoft.com/aa998874 を参照してください。
Q 現在、Exchange 2000 および Exchange 2003 組織から新しい Exchange 2007 組織へのフォレスト間の移行を行っています。しかし、Move-Mailbox コマンドレットに -SourceMailboxCleanupOptions DeleteSourceMailbox パラメータを指定して、移動元フォレストから移動先フォレストにメールボックスを移動しようとすると、以下のエラーが表示されます。
"メールボックスは移動先の Exchange サーバーに移動され、移動元の Exchange サーバーから削除されましたが、移動元のメールボックス ユーザーからメールボックス属性を削除しているときにエラーが発生しました。ドメイン コントローラ 'file01' のオペレーティング システムのバージョンは 5.0 (2195) Service Pack 4 です。5.2 (3790) Service Pack 1 以降のバージョンが必要です。"
Windows Server® 2003 ベースのドメイン コントローラ (兼グローバル カタログ サーバー) が移動元のフォレスト内に存在しますが、–DomainController パラメータは移動先のフォレスト内のドメイン コントローラまたはグローバル カタログ サーバーのみを指定でき、移動元フォレスト内のどのドメイン コントローラを使用すべきかを指定できないように思えます。これは正しいですか。正しいとすると、回避策はありますか。
A 正しいです。Move-Mailbox コマンドレットの一部として、移動元フォレスト内のドメイン コントローラまたはグローバル カタログ サーバーを指定することはできません。ドメイン コントローラ (グローバル カタログ サーバー) はランダムに選択されます。回避策は 2 つありますが、どちらも特にすばらしいとは言えません。最初の回避策は移動元のフォレスト内の Windows® 2000 ベースのドメイン コントローラをすべて使用中止にすることですが、多くの場合、これを選択できないことはわかっています。2 つ目の回避策は、ご質問の状況に役に立つ可能性があります。Move-Mailbox コマンドレットは、グローバル カタログ サーバーとしても動作するドメイン コントローラを使用する必要があります。つまり、移動元のフォレスト内のすべての Windows 2000 サーバーからグローバル カタログ サーバーの役割を削除することで問題を解決できる可能性があります。この手法を 2 ～ 3 の移行シナリオで使用したことがあるので、一度試してみる価値はあります。
Q Exchange 2007 のクライアント アクセス サーバー、ハブ トランスポート サーバー、またはメールボックス サーバーを 1 つの Active Directory サイト (米国など) にインストールし、このサーバーを別の Active Directory サイト (デンマークなど) にそのまま移動することはできますか。この方法がサポートされるとしたら、Exchange 2007 サーバーは新しい Active Directory サイトのメンバシップを自動的に検出しますか、それとも手動で操作する必要がありますか。
A はい、このシナリオは完全にサポートされ、手動の操作は必要ありません。Net Logon (NetLogon) サービスと Microsoft Exchange Active Directory トポロジ (MSExchangeADTopology) サービスによって、Exchange 2007 サーバーのサイト メンバシップが処理されます。サーバーによりサイトのメンバシップが変更されると、MSExchangeADTopology サービスによってサーバーのサイト属性 (msExchServerSite 属性) が自動的に更新されます。図 1 に示すように、ADSIEdit のようなツールを使用して、msExchServerSite 属性を確認できます。
図 1 msExchServerSite 属性の使用 (画像をクリックすると拡大表示されます)
Exchange 2007 サイトと Active Directory サイトがどのように相互関連するかを詳しく理解したい場合は、Exchange 2007 ドキュメントの「Active Directory サイトベースのルーティングについて」(technet.microsoft.com/aa998825) をご覧になることをお勧めします。
Q メールボックス データベースに対してローカル連続レプリケーション (LCR) を有効にした Exchange 2007 メールボックス サーバーで、Microsoft Data Protection Manager 2007 (DPM 2007) を使用して、メールボックス データベースのパッシブ コピーによるメールボックス データのバックアップは可能ですか。
A DPM 2007 を使用して、Exchange 2007 クラスタ連続レプリケーション (CCR) 環境のパッシブ ノード経由でメールボックス データベースをバックアップできますが、Exchange 2007 LCR 環境でメールボックス データベースのコピーを扱うときは、こうしたバックアップはサポートされません。
Q Exchange Server 2007 クラスタ化メールボックス サーバー (CMS) データベースをスタンドアロンのメールボックス サーバーに移植できますが、CCR ベースまたはシングル コピー クラスタ (SCC) ベースの Exchange 2007 CMS 上のクラスタ化されていないデータベースはマウントできますか。
A Exchange Server 2007 インフォメーション ストアは、ストアが存在するサーバーの種類を認識しないため、CCR ベースまたは SCC ベースの CMS 上のクラスタ化されていないデータベースのマウントは完全にサポートされます。
Q technet.microsoft.com/bb508861 の資料によると、クラスタ化された Exchange 2003 サーバーでは Exchange Server Quota Message Service (QMS) がサポートされません。このサービスは今後 Exchange 2003 向けまたは Exchange 2007 のクラスタ環境向けにサポートされますか。
A Exchange Server QMS ツールは、Exchange 2003 CMS では今後もサポートされないでしょう。さらに、Exchange 2007 のクラスタ化された (ついでに言えば、クラスタ化されていない) メールボックス サーバーでも QMS ツールはサポートされません。ただし、Exchange 2007 を使用している場合、実際には QMS ツールをインストールする理由はありません。同等の機能が Exchange にネイティブに含まれています。Exchange 2007 でクォータ メッセージを管理する方法の詳細については、technet.microsoft.com/bb232089 を参照してください。
Q Active Directory のユーザー オブジェクトとグループ オブジェクトにそれぞれメールボックスまたはメールが有効になっているときに、これらのオブジェクトに設定できる属性を一覧した参照ドキュメントはありますか。
A Exchange 2007 ドキュメントの「分割型アクセス許可モデル リファレンス」にこれらの属性が一覧されています。この資料は technet.microsoft.com/bb430782 にあります。
Q Exchange 2007 メッセージング インフラストラクチャの社内メッセージ フローのため、Exchange 2007 ハブ トランスポート サーバーをブリッジヘッド サーバーとして指定する方法はありますか。たとえば、Active Directory サイト 1 から Active Directory サイト 2 に送られるすべてのメールをハブ トランスポート サーバー A (Active Directory サイト 1 に所在) からハブ トランスポート サーバー B (Active Directory サイト 2 に所在) へルーティングしたり、またその逆を行うような考え方です。これは機能しますか。
A いいえ、機能しません。これが機能するためには、Active Directory サイトのメールボックス サーバーで、受信者が別の Active Directory サイトに所在するかどうかを把握する必要があります。Exchange 2007 メールボックス サーバーの役割にはこのようなメカニズムは組み込まれていません。
ハブ トランスポート サーバーがメールボックス サーバーにローカルにインストールされている場合を除き、メールボックス サーバーは、常に、同じ Active Directory サイト内の複数のハブ トランスポート サーバー間の接続の負荷分散を行います (ハブ トランスポート サーバーの役割がメールボックス サーバーにインストールされている場合は、常に、同じ物理コンピュータ上のハブ トランスポート サーバーがメールボックス サーバーとして選択されます)。
Exchange 2007 は分類を行った後のみ、受信者のメールボックスがある場所を認識します。ご質問の目標実現に最も近い方法は、図 2 に示すように、SubmissionServerOverrideList パラメータを指定した Set-MailboxServer コマンドレットを使用して、メールボックス サーバーが使用するハブ トランスポート サーバーの静的一覧を作成することです (technet.microsoft.com/bb232193 参照)。
図 2 メールボックス サーバーの設定 (クリックすると拡大画像が表示されます)
つまり、ハブ トランスポート サーバー A または B を指定すると、メールボックス サーバーでは、指定したサイトの受信者に送信されるメッセージだけでなく、ローカル メッセージの配信に加え、すべての Active Directory サイトの受信者に送信されるメッセージにそのハブ トランスポート サーバーが使用されることになります。これは、理論上、単一点障害を生み出すことになるため、このアプローチの使用はお勧めしません。
Q Windows Server 2008 に Exchange Server 2007 SP1 メールボックス サーバーをインストールすることを計画していますが、ディスクの配置について疑問があります。Windows Server 2003 を実行するサーバーに Exchange Server 2003 または Exchange Server 2007 をインストールする場合、全体的なパフォーマンスを向上するために、diskpart ツールを使用してトランザクション ログ ファイルとメールボックス ストアを保持するパーティションを作成することが推奨されていたと認識しています。ベンダの推奨事項でも記憶域のパーティションを揃えることが勧められていました。記憶域のベンダからの推奨がなかった場合、マイクロソフトが提示したベスト プラクティスは 64 KB 値を使用することでした。
Windows Server 2008 に Exchange 2007 メールボックス サーバーをインストールするとき、ディスクの配置をどのように構成すればよろしいですか。これまでと同じ規則が当てはまりますか。
A ご存知ですか。Windows Server 2008 では、diskpart ツールを使用して、Exchange Server 2007 SP1 トランザクション ログ ファイルとメールボックス データベースを格納するディスク パーティションが揃っていることを追跡する必要がなくなりました。Windows Server 2003 では、パーティションが必ず 64 番目のセクタから始まるため、Windows ディスク管理ツールを使用するとパーティション全体が不揃いになるというディスク パーティション配置の問題がありましたが、Windows Server 2008 ではこの問題が解決されています。
配置追跡の問題の詳細については、Exchange チームのブログ (msexchangeteam.com/archive/2005/08/10/408950.aspx) を参照してください。さらに、Windows Server 2008 では、1024 KB の境界を使用してディスク パーティションが配置されます。この点については TechNet の Exchange Server 2007 ドキュメント (technet.microsoft.com/bb738145) を参照してください。
Q 現在、Exchange Server 2007 SP1 ベースのメッセージング環境にスタンバイ連続レプリケーション (SCR) を実装する計画をたてている段階です。当社は比較的小さな企業ですので、Exchange 2007 サーバーをインストールしたコンピュータを複数台展開して、2 番目のサイトで SCR ターゲットとして動作させる余裕はありません。
SCR ターゲットでメールボックス サーバーの役割以外の役割がサポートされるかどうかがちょっと不安です。
A はい、ソースとターゲットの両方の SCR Exchange サーバーで、Exchange 2007 SP1 の他の役割を実行できます。つまり、たとえば、クライアント アクセス、ハブ トランスポート、およびメールボックスの各サーバーの役割をインストールした Exchange 2007 SP1 サーバーを展開して、これらを SCR ターゲットとして使用することが完全にサポートされます。
Q 当組織では、Windows Server 2003 Active Directory フォレストと Exchange 2007 メッセージング インフラストラクチャを基盤としていますが、まもなく、最近買収した組織をマージする必要があります。2 つの組織をマージする際の要件の 1 つは、各組織のユーザーがそれぞれの組織のユーザーを含むアドレス一覧だけに表示されるように、Exchange 2007 のアドレス一覧を分離することです。
Exchange 2003 環境でこれを実現する方法を手順に従って指示する資料がマイクロソフト サポート技術情報でいくつか公開されていたと記憶しています。Exchange 2007 ベースのメッセージング環境でアドレス一覧を分離することになった場合、どのようなアプローチがありますか。
A 必要な手順をすべて説明するには、このコラムに与えられているスペースでは足りません。さいわい、Exchange 2007 での仮想組織とアドレス一覧分離の構成方法について説明する技術ホワイト ペーパー (technet.microsoft.com/bb936719) が最近マイクロソフトから公開されました。また、少し時間を使って、Dave Goldman のブログ (go.microsoft.com/fwlink/?LinkId=115499 参照) でこのホワイト ペーパーに関するコメントを含む投稿をお読みください。
Q Exchange Server 2007 が正しく機能するために Windows インターネット ネーム サービス (WINS) は必要ですか。
A Exchange Server 2007 製品自体は、WINS を必要としません。ただし、Exchange Server 2007 メッセージング環境で使用する Microsoft Office Outlook® のバージョンによっては WINS が必要になることがあります。Exchange 2007 サーバーと Outlook 2007 クライアントまたは Outlook 2003 クライアントに限定してメッセージング環境を構成すれば、WINS は必要ありません。
めったにはないことですが、Outlook 2007 で WINS が必要になることがあります。メールボックスを新しい Exchange フォレストに移行しているとき、RTM 版の Outlook 2007 は予想どおり完全修飾ドメイン名 (FQDN) ではなく、NetBIOS 名を使用して Exchange メールボックス サーバーへの接続を試みます。しかし、この問題は 2008 年 1 月にリリースされた Outlook 2007 SP1 後の修正プログラム パッケージで解決されています (support.microsoft.com/?id=941275)。
エンド ユーザーが Outlook 2002 を使用している場合、このクライアントが NetBIOS の名前解決に依存しているため、WINS が常に必要になります。Outlook 2002 以前の Outlook クライアントは Exchange 2007 ではサポートされないため、ここでは特に触れていませんが、これと同じ状況が当てはまります。
Henrik Walther は、メッセージングに関するマイクロソフト認定アーキテクトの実習生 (apprentice 段階) および Exchange MVP で、IT ビジネスの分野において 14 年以上の経験があります。また、Interprise Consulting 社のテクノロジ アーキテクト、および Biblioso Corporation のテクニカル ライターも務めています。