Exchange Queue & A:DAG に移行する
データベース可用性グループを使用するのは名案です。特に、データベース可用性グループは複数の場所にコピーおよび格納できるという点で優れています。ですが、アドレスの問題に注意してください。
Henrik Walther
厄介な問題に対処する
Q. Exchange Server 2010 を展開し、データベース可用性グループ (DAG) を使用して、すべてのメールボックス サーバーの可用性を高めました。すべてうまくいって予想どおりに機能していますが、1 つだけ小さな問題があります。
DAG でホストされているメールボックスが割り当てられている従業員から送信されたメッセージを受け取った後に、別の組織の従業員や受信者にメッセージを送信すると、受信したメッセージのインターネット メッセージ ヘッダーには、メールボックス サーバーが 169.254.5.133 などの APIPA アドレスを使用して構成されていることが示されています。Exchange Server 2010 をインストールしているサーバーにはすべて静的 IP アドレスを使用しているので、APIPA アドレスが表示される理由がわかりません (図 1 参照)。教えていただけませんか。
A. これは興味深い質問です。簡潔に答えると、1 つ以上の DAG を使用して Exchange Server 2010 メールボックス サーバーの可用性を高めていて、DAG の機能が Windows フェールオーバー クラスター (WFC) コンポーネントに基づいている場合にのみ、このような現象が発生します。DAG に含まれないメールボックス サーバーでは、このような動作が発生することはありません。
では、何が起こっているのか詳しく見ていきましょう。Windows Server 2008 R2 の WFC コンポーネントでは、WFC を使用して、クラスター リソースを特定の方法で検索するアプリケーション (SQL Server、Exchange Server、ファイル サーバーなど) を想定しています。このようなアプリケーションは、DNS サーバーを使用して適切な情報を確認することで、クラスター リソースに接続する必要があります。
これはクライアント アクセス ポイント (CAP) と呼ばれます。CAP は NetBIOS 名と 1 つ以上の IP アドレス リソースで構成されます。Windows Server 2008 R2 では、サーバーで動的更新をサポートしている場合、CAP が WFC でオンラインになると、DNS に CAP 情報が登録されます。
残念ながら、DNS の手順をスキップし、バインドの一覧の先頭にあるネットワーク アダプターを使用して、クラスター ノードに直接接続するアプリケーションがあります。既定では、バインドの一覧の先頭に表示されるネットワーク アダプターは、Microsoft Failover Cluster Virtual Adapter です (図 2 参照)。このアダプターは APIPA アドレスで構成されています。
図 1 APIPA アドレスが表示されているインターネット ヘッダー
図 2 Microsoft Failover Cluster Virtual Adapter
クラスター リソースを検索して接続するのに、DNS を使用しないアプリケーションを当ててみてください。ご推察のとおりです。Exchange Server 2010 です (それから、Exchange Server 2007 もです)。
このちょっとした問題を解決するにはどうすれば良いのでしょうか。さいわい、nvspbind と呼ばれる小さなツールを使用すれば簡単に解決できます。このツールは、MSDN コード ギャラリー (code.msdn.microsoft.com/nvspbind、英語) からダウンロードできます。nvspbind は、コマンド ラインからネットワーク バインドを変更することを主な目的として開発されました。
それでは、サーバーのアダプターのバインド順序を確認してみましょう。nvspbind.exe /o ms_tcpip というコマンドを実行します。図 3 からわかるように、Local Area Connection* 9 (つまり、Microsoft Failover Cluster Virtual Adapter) が一覧の先頭に表示されます。
図 3 nvspbind を使用してバインド順序の一覧を表示する
次に、Local Area Connection* 9 を一覧で下方向へ移動する必要があります。そのためには、次のコマンドを実行します。
nvspbind.exe /- “Local Area Connection* 9” ms_tcpip
図 4 バインド順序の一覧で Local Area Connection* 9 を下方向へ移動する
図 4 からわかるように、Local Area Connection* 9 はバインド順序の一覧で 1 つ下に移動しました。この状態で、新しい電子メールを送信してみてください。今度は、インターネット ヘッダーに、サーバーの実際の IP アドレスが表示されます (図 5 参照)。
図 5 メールボックス サーバーの実際の IP アドレスが表示されているインターネット ヘッダー
手動のコピー
Q. Exchange Server 2010 を展開しました。DAG を使用して、メールボックス データベースの可用性を高めることを検討しています。各メールボックス データベースのコピーを 8 つ作成する計画を立てています。各メールボックス データベースのコピーを、3 つの物理的な場所に配置し、各データベースのサイズは約 500 GB にします。そのうち 1 つの物理的な場所では帯域幅が制限されるため、シード時間が長くなることが想定されます。そこで、代わりに、USB ドライブを使用して、なんらかの方法でデータベース ファイルを遠隔地に手動でコピーできないかと考えています。これは実現可能でしょうか。
A. はい、その方法やサポートされている方法を使用して手動でデータベース ファイルをコピーすることは可能です。オフライン データベースを手動でコピーするには、各データベースの循環ログを無効にします。これを行うには次のコードを実行します。
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false
続いて、次のコードを実行して、データベースのマウントを解除します。
Dismount-Database MDB01 -Confirm $false
それから、データベースとすべてのログ ファイルを、別の場所 (USB ドライブなど) にコピーします。
コピーが終わったら、次のコマンドを使用して、アクティブなデータベースのコピーを再びマウントします。
Mount-Database MDB01
ここで、データベースをホストするサーバーに USB ディスクを接続します。ファイルのコピー元サーバーで使用されていたパスと同じパスにデータベースとログ ファイルをコピーします。
今度は、Add-MailboxDatabaseCopy -SeedingPostponed パラメーターを使用して、データベースのコピーを追加します。正確なコマンドは次のとおりです。
Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed
EDB ファイルと関連するログ ファイルが既に配置されているので、シード処理は行われないことに注目してください。最後に、次のコマンドを使用して、再び循環ログを有効にします。
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true
移動が多いユーザー
Q. Exchange Server 2010 を運用しており、Outlook Web App (OWA) が欠かせない "移動が多いユーザー" がたくさんいます (Outlook Web App は、以前は Outlook Web Access と呼ばれていました)。このようなユーザーは、パスワードの有効期限が切れると、OWA にログオンできなくなります。ユーザー アカウントの作成時に、[ユーザーは次回のログオン時にパスワード変更が必要] チェック ボックス (図 6 参照) がオンになっていたアカウントを使用している新しい従業員は、他のメカニズムを使用してパスワードを変更するまで、OWA にログオンできないことが判明しました。
図 6 [ユーザーは次回のログオン時にパスワード変更が必要] チェック ボックスがオンになっている状態
何年も前に、Lotus Domino から Exchange Server 2003 に移行して以来、この不便さに耐えてきました。ですが、この問題を解決する方法を教えていただけませんか。
A. 良いタイミングでこの質問をされましたね。Exchange チームは、Exchange Server 2007 SP3 と Exchange Server 2010 SP1 の計画を立て始めたとき、ユーザーのパスワードの有効期限が切れた場合やユーザー アカウントの設定時に [ユーザーは次回のログオン時にパスワード変更が必要] チェック ボックスがオンになっている場合に、OWA にログオンできないという問題を解決することにしました。チームは、OWA のパスワード リセット ツールを考案しました。これは、有効期限の切れたパスワードを検出して、ユーザーを新しいパスワードの変更ページにリダイレクトする IIS 7 モジュールです。
図 7 Outlook Web App 2010 フォーム ベース認証ログオン ページ
この操作を実行してみましょう。ユーザーは、フォーム ベース認証 (FBA) ログオン ページを使用して、OWA 2007 または OWA 2010 にログオンします (図 7 参照)。ユーザーは、新しいパスワードを変更するページにリダイレクトされます (図 8 参照)。ここで、現在のパスワードと新しいパスワードを入力して、[Submit] (送信) をクリックする必要があります。
図 8 Outlook Web App 2010 のパスワード変更のページ
これでパスワードは変更され、ユーザーは新しいパスワードを使用してログオンできます。簡単で使いやすいですね。
このパスワードを変更するページは、Exchange Server 2007 SP3 または Exchange Server 2010 SP1 をインストールしても、既定では有効になっていないことに注意してください。レジストリ キーを操作して有効にする必要があります。具体的に説明すると、Exchange Server 2007 または Exchange Server 2010 の各クライアント アクセス サーバー (CAS) にログオンして、レジストリ エディターを起動します。
レジストリ エディターで、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA に移動して、ChangeExpiredPasswordEnabled という名前の新しい REG_DWORD キーを作成する必要があります。データの値を "1" に設定すると、このページが有効になります (図 9 参照)。
図 9 OWA のパスワードの変更ページを有効にするために必要なレジストリ キー
これで、移動が多いユーザーは、パスワードの有効期限が切れていたり、パスワードを変更する必要があったりしても、OWA にログオンすることができます。
Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 15 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。TimengoConsulting (デンマークを拠点とするマイクロソフト認定ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corp. (ドキュメント管理とローカライズ サービスを専門とする米国の企業) でテクニカル ライターを務めています。連絡先は、v-henwal@microsoft.com (英語のみ) です。