Exchange Queue & Aクラスタ化メール ボックス サーバーの回復、オフライン アドレス帳の問題など
Henrik Walther
Q Exchange Server 2007 SP1 ベースのメッセージング インフラストラクチャを使用しています。Exchange Server 2007 SP1 は、すべて Windows Server 2008 コンピュータにインストールしており、2 つのデータセンターがあります。プライマリ データセンターで障害が発生したときには、バックアップ データセンターにフェールオーバーします。プライマリ データセンターでは、ローカルで高可用性ソリューションを提供するため、クラスタ連続レプリケーション (CCR) ベースのメールボックス サーバーを使用しています。プライマリ データセンターからバックアップ データセンターへのメールボックス サーバーのフェールオーバーには、スタンバイ連続レプリケーション (SCR) を使用します。つまり、プライマリ データセンターに設置されている CCR ベースのクラスタ化メールボックス サーバー (CMS) は、すべて SCR ソースとしても機能します。各 SCR ソースには、バックアップ データセンターに対応する SCR ターゲットがあります。この SCR ターゲットは、パッシブ クラスタ化メールボックスの役割のみがインストールされたスタンバイ クラスタで構成されています。
最近、この 2 つのデータセンター間でサイト レベルのフェールオーバーのテストを実施したところ、困ったことに、CMS をスタンバイ クラスタに回復しようとしたときに問題が発生しました。/RecoverCMS スイッチを指定して Setup.com を実行すると、図 1 に示すようなエラー メッセージが表示されました。
図 1 CMS をスタンバイ クラスタに回復しようとしたときに発生したセットアップ エラー
CMS をスタンバイ クラスタに回復しようとしたときに同じエラー メッセージに遭遇したことがあるのではないか、それから、その解決策をご存じではないかと思い質問させていただきました。
A 私も、CMS をスタンバイ クラスタに回復するときに、同じ問題に直面しました。それも、サイト レベルのフェールオーバーのテストを実施しているときでした (フェールオーバー ソリューションのテストを実施する重要性については、ご存じだと思いますので、説明は割愛します)。
同じ設定で何度もテストを実施しており、以前は何の問題もなくテストが完了していたのに問題が発生した点について不思議に思っていました。しかし、以前に実施した回復テストは、Exchange Server 2007 SP1 を Windows Server 2003 コンピュータにインストールした環境で行っており、この問題が発生したのは、同製品を Windows Server 2008 コンピュータにインストールした環境でした。
このことから、Windows Server 2008 のフェールオーバー クラスタが Windows Server 2003 ベースのクラスタと異なる動作をすることが判明しました。Windows Server 2003 では、クラスタ専用のクラスタ サービス アカウントを作成しますが、Windows Server 2008 では、フェールオーバー クラスタは、Local System アカウントで実行されるので、この作業は不要になりました。CMS を回復しようとしたスタンバイ クラスタでアプリケーション ログとシステム ログを検証すると、図 2 のエラーが記録されていることがわかりました。
図 2 アクセス許可の不足により発生した回復エラー
このイベント ID のエラー メッセージでは、Active Directory の CMS コンピュータ アカウントを更新するのに必要なアクセス許可が Windows フェールオーバー クラスタにないことが示されています。また、考えられる 3 つの原因も示されています。ここでは、スタンバイ クラスタに既存の CMS を回復しているので 1 つ目は関係ないと見なすことができます。また、コンピュータ オブジェクト数のクォータにも達してないので、2 つ目も関係ないと見なすことができます。ただし、3 つ目は、とても興味深いものです。CMS を回復する Windows フェールオーバー クラスタが CMS コンピュータ アカウント オブジェクトに対してフル コントロールのアクセス許可を持っているかどうかを確認することを推奨しています。
Active Directory ユーザーとコンピュータで CMS コンピュータ オブジェクトのプロパティ ダイアログ ボックスで [セキュリティ] タブの設定を確認すると、スタンバイ クラスタにフル コントロールのアクセス許可が付与されていないことがわかりました (図 3 参照)。
図 3 スタンバイ クラスタにフル コントロールのアクセス許可がない
スタンバイ クラスタに CMS コンピュータ オブジェクトに対するフル コントロールのアクセス許可を付与すると、問題が解決したので、この場合も同様に問題を解決できると思います。
このコラムの執筆時点 (2 月末) では、この問題に関する情報は、TechNet やサポート技術情報の記事などで公開されていません。しかし、Microsoft カスタマ サポート サービスの Tim McMichael が、このトピックについて、(このコラムよりも) 詳しく説明している記事をブログで公開しています。詳細については、Tim のブログ記事「Permissions recommended for the CNO (Cluster Name Object) in Windows 2008 for Exchange 2007 SP1 setup operations」(Windows Server 2008 と Exchange Server 2007 SP1 環境における CNO (クラスタ名オブジェクト) の推奨アクセス許可) を参照してください。
Q サイト レベルのフェールオーバー ソリューションを構築しているところです。Exchange Server 2007 SP1 ベースのメッセージング インフラストラクチャでは、プライマリ データセンターとバックアップ データセンター間の障害回復ソリューションとしてスタンバイ連続レプリケーション (SCR) を使用するつもりです。一部のユーザーは Outlook 2007 にアップグレードしていますが、大半のユーザーは依然として Outlook 2003 を使用しているため、質問があります。Exchange Server 2007 SP1 サーバーのプライマリ データセンターからバックアップ データセンターへのフェールオーバーが発生した場合、必要な SCR サイト フェールオーバーの手順を実行した後には、どちらのバージョンの Outlook にも変更が反映されますか。
A 非常に良い質問ですね。これは、メールボックス サーバーをバックアップ データセンターにフェールオーバーさせるのに /RecoverCMS スイッチとデータベースの移植性のどちらを使用しているのかで回答が異なります。一方、プライマリ データセンターのスタンドアロン メールボックス サーバーをバックアップ データセンターのスタンドアロン メールボックス サーバーにレプリケートするのに SCR を使用している場合、メールボックス データベースのフェールオーバーには、データベースの移植性を使用することになります。プライマリ データセンターでシングル コピー クラスタ (SCC) または CCR ベースのメールボックス サーバーを使用し、バックアップ データ センターでスタンバイ クラスタを使用している場合は、CMS 全体をバックアップ データセンターに回復するのには /RecoverCMS スイッチを使用することになります。フェールオーバー メカニズムとして /RecoverCMS スイッチを使用する場合は、通常、フェールオーバー発生後に Outlook クライアントの接続について心配する必要はありません。ただし、CMS の IP アドレスが変更されることについては注意してください。DNS の Time to Live (TTL) を推奨値である 5 分に設定している場合は、Outlook クライアントが CMS に再接続できるようになるまで少し時間がかかりますが、それ以外については問題ありません。
フェールオーバー メカニズムとしてデータベースの移植性を使用している場合は、Outlook クライアントのバージョンによって状況が異なります。Outlook 2007 クライアントでは、クライアント アクセス サーバーで実行されている自動検出サービスによって変更が自動的に反映されます。そのため、Outlook 2007 については手動で変更を行う必要はありません。ただし、Outlook 2003 クライアントの場合は状況が異なります。メールボックスが別のサーバーで回復されると、当然、メールボックス データベースを格納しているサーバーの名前は違うものになります。
フェールオーバーの発生後に、–ConfigurationOnly スイッチを指定して Move-Mailbox コマンドレットを使用した場合にも、このことが問題になるのか疑問に思っている方もいらっしゃるでしょうが、Outlook 2003 では、自動検出サービスがサポートされていないので、この場合も同じです。つまり、Outlook MAPI プロファイルのサーバー名を更新できるように、フェールオーバーが発生する以前にメールボックスが格納されていたサーバーはオンラインになっている必要があります。このサーバーがオフラインの場合、サーバー名を自動更新することはできません。
プライマリ データセンターの全サーバーがオフラインとなるような障害が発生した場合には、Microsoft Exchange Server プロファイル リダイレクタ (ExProfre.exe) などのツールをログイン スクリプトと組み合わせて使用し、Outlook 2003 MAPI プロファイルを再設定して、変更を反映する必要があります。ご参考までに、すべてのクライアントでプライマリ データセンターのサーバーを使用している場合に、このような障害が発生すると、クライアントの再構築が必要になることも併せてお知らせしておきます。
Q Exchange Server 2007 SP1 ベースのメッセージング インフラストラクチャでは、すべてのメールボックス サーバーがクラスタ連続レプリケーション (CCR) に対応しています。各クラスタ ノードには、4 枚のネットワーク インターフェイス カード (NIC) を搭載しています。このうち 2 枚の NIC は、チーム化してパブリック ネットワークに接続し、Outlook クライアントからの要求などを受け付けています。3 枚目の NIC は、CCR の 2 つのクラスタ ノード間のハートビート ネットワークに接続しています。4 枚目の NIC は、ログ配布専用ネットワークに使用しています。Exchange Server 2007 SP1 で導入された Enable-ContinuousReplicationHostName コマンドレットを使用して、(ログ配布の冗長性を実現するために) アクティブ ノードからパッシブ ノードにログ ファイルを配布する際に、ハートビート ネットワークとログ配布専用ネットワークの両方を使用できるように指定しました。これは非常にうまく機能しており、パブリック ネットワークのトラフィック軽減に役立っています。(めったに発生しない事象ですが) 1 つ以上のメールボックス データベースの再シードが必要な場合は、特に有効です。
また、CCR ベースのメールボックス サーバーとバックアップ データセンターにある複数の SCR ターゲット間では、SCR を有効にしています。そこで質問があるのですが、SCR と Enable-ContinuousReplicationHostName コマンドレットを併用することはできますか。
A Enable-ContinuousReplicationName コマンドレットがお役に立っているとのこと、たいへん嬉しく思っています。残念ですが、このコマンドレットは CCR ソリューション専用に作成されたもので、現時点では、SCR ソリューションではサポートされていません。
Q Exchange Server 2003 から Exchange Server 2007 SP1 への移行したばかりです。Exchange Server 2007 SP1 は、すべて Windows Server 2008 コンピュータで実行されており、Exchange Server 2007 メールボックス サーバーは CCR ベースです。
今のところ非常にうまく機能していますが、オフライン アドレス帳 (OAB) について 1 つ問題が発生しました。OAB を新しいメール オブジェクトに更新したときに、Outlook 2007 ユーザーに変更が反映されないという事象が発生しました。この問題のトラブルシューティングを行い、クライアント アクセス サーバーのアプリケーション ログに、イベント ID 1021 のエラーが記録されており、次のような説明が記載されていることを確認しました。
プロセス MSExchangeFDS.exe (PID: xxxx)。ディレクトリ <OAB share location> が見つかりませんでした。
ディレクトリが生成されていない場合、これは問題ではありません。ディレクトリが生成されている場合は、
ディレクトリと共有に "Exchange Servers" グループの読み取りアクセス許可が与えられていることを確認してください。
OAB がホストされている CCR ベースのメールボックス サーバーからクライアント アクセス サーバーに OAB を手動でコピーしたところ、Outlook で情報が更新されました。ですが、この問題を完全に解決したいと思っています。何か解決策はありませんか。
A 私も同じ問題に直面しました。これは、Windows Server 2008 のフェールオーバー クラスタの動作に起因する問題です。Windows Server 2008 のフェールオーバー クラスタでは、共有スコープという新しい概念が導入されました。共有スコープの基本的な概念は、ファイル共有が、共有をホストしているノード名またはクラスタ名オブジェクトのどちらかに固有であるというものです。ノード名を使用して共有した共有には、クラスタ化メールボックス サーバー (CMS) 名を使用してアクセスできません。ファイル共有のスコープの詳細については、Ask the Core Team ブログの記事「File Share 'Scoping' in Windows Server 2008 Failover Clusters」(Windows Server 2008 のフェールオーバー クラスタにおけるファイル共有のスコープ) を参照してください。
この問題を解決するには、Exchange Server 2007 SP1 の更新プログラムのロールアップ 5 以降をインストールする必要があります (このロールアップには、この問題を解決するのに必要な修正プログラムが含まれています)。詳細については、「Exchange Server 2007 CAS で Windows Server 2008 ベースの Exchange Server 2007 CCR クラスタの OAB 共有から OAB をコピーできない」を参照してください。更新プログラムのロールアップのインストールによって発生する問題があるので、このソリューションを使用する前に、更新プログラムのロールアップ 5 についての KB 資料をよくお読みください。
Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 15 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。Trifork Infrastructure Consulting (デンマークを拠点とするマイクロソフト ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corporation (ドキュメント管理とローカライズ サービス専門とする米国の企業) でテクニカル ライターを務めています。