Exchange Queue & AOutlook Anywhere と IPv6、リモート接続アナライザなど
Henrik Walther
Q つい最近、組織内の Windows Server 2008 ベースのサーバーに Exchange 2007 を展開しました。非常にうまく機能しているのですが、1 つ例外があります。Microsoft TechNet で公開されている Exchange 2007 ドキュメントのガイダンスに従って Outlook Anywhere (旧称 : RPC over HTTP) を構成していますが、どのようにしてもインターネット上の Outlook 2007 クライアントから Exchange 2007 クライアント アクセス サーバーに接続できません。SAN 証明書がクライアントによって信頼されていること、およびクライアント アクセス サーバーに接続しているファイアウォール上で TCP ポート 443 を開いていることは確認しています。これまでにこのような問題はあったでしょうか。
A 実際、この問題に遭遇したことがあります。Exchange 2007 を Windows Server 2008 ベースのサーバーにインストールしているということですね。クライアント アクセス サーバーを Windows Server 2008 サーバーにインストールしている場合、そのサーバー上で IPv6 が有効になっていると、Outlook Anywhere が適切に機能しないことに注意してください。IPv6 は、Exchange 2007 SP1 を Windows Server 2008 にインストールすると既定で有効になるため、必ず無効にする必要があります。これによって、この問題が解決された場面を何度か目撃しています。
Windows Server 2008 上で Outlook Anywhere と IPv6 を併用すると問題が発生する理由と、Windows 2008 サーバー上で Exchange 2007 に影響することなく IPv6 を無効にする方法の詳細については、マイクロソフトの Exchange チームによるブログ記事 (msexchangeteam.com/archive/2008/06/20/449053.aspx) を参照してください。この問題は、Exchange 2007 SP1 のロールアップ 4 で修正される見込みです。
Q 現在 Outlook Anywhere と Exchange ActiveSync を Exchange 2007 ベースのメッセージング環境に実装しています。境界ネットワークの反対側で Outlook Anywhere が予期したとおりに機能するかどうかをなんらかの方法でテストすることはできるでしょうか。また、この環境で自動検出サービスが適切に構成されていることも確認したいと考えています。アドバイスをお願いします。
A はい。Outlook Anywhere が適切に機能しているかどうかをテストすることは可能です。マイクロソフトの社員 (Exchange 製品グループの Shawn McGrath、製品サポート サービスの Brad Hughes) により、Exchange Server リモート接続アナライザ (ExRCA) という Web ベースのツールが作成されています。このツール (図 1) は、まだプロトタイプと見なす必要がありますが、個人的にはバグやおかしな動作を経験したことはまったくありません。このツールでは、Outlook 2007 自動検出と RPC/HTTP 接続のテストを実行できます。また、Exchange ActiveSync と着信 SMTP メール フローが予期したとおりに機能するかどうかについてもテストできます。現時点では、ExRCA はマイクロソフトのサポートを受けられませんが、Exchange 2007 に対するどのようなリモート接続テストにもこれを強くお勧めします。
図 1 Exchange Server リモート接続アナライザのスタート ページ(画像をクリックすると拡大表示されます)
Q Exchange Server 2007 を使用していて、現在スタンバイ連続レプリケーション (SCR) を展開する計画を立てている段階にあります。別のサイトにあるクラスタ化されていない Exchange 2007 SP1 メールボックス サーバー上に作成されている各メールボックス データベースのデータ セットの複製を作成したいと考えています。Microsoft TechNet で公開されている Exchange 2007 のドキュメントで SCR ついてはかなりの情報を読みましたが、どうしても答えを見つけられないでいる質問があります。SCR ターゲットをアクティブにした場合、これは、特定のメールボックス データベース内の全ユーザー メールボックスに対して –ConfigurationOnly パラメータを指定して Move-Mailbox を実行した場合と同じ結果になるのでしょうか。つまり、Active Directory 内の Exchange サーバーの場所だけが変更されますか。
A ソースの SCR サーバーとしてクラスタ化されていないメールボックス サーバー (別称 : スタンドアロン メールボックス サーバー) を使用されているので、ご理解のとおりです。SCR コピーを別のサーバー上でアクティブにするため、データベースの移植性が使用されます。つまり、各メールボックス データベース内のユーザー メールボックスに対応する Active Directory 内の Exchange サーバーの場所が変更されます。
Exchange 2007 環境内のソース SCR サーバーが、クラスタ連続レプリケーション (CCR) またはシングル コピー クラスタ (SCC) ベースであり、SCR ターゲットとしてフェールオーバー クラスタ内のパッシブ ノードを使用し、同じ名前で SCR ターゲットをアクティブにした場合、Active Directory 内の Exchange Server の場所は変化しません。
Q つい最近、エンタープライズ環境への Exchange Server 2007 の展開を完了しました。Exchange 2007 のインストール中にフォレストとドメインを準備した場合、Exchange 2007 セットアップによって作成された 6 つの Exchange 2007 セキュリティ グループを、Microsoft Exchange Security Groups OU ではなく、ルート ドメインに作成されている別の組織単位に移動することはサポートされているでしょうか。
A フォレスト内の別の OU に Exchange グループを移動できなかった Exchange 2000 または 2003 とは異なり、Exchange 2007 ではこれをサポートしています。Exchange 2007 のフォレストの準備中に作成された 6 つの Exchange 2007 セキュリティ グループ (図 2 参照) は、1 つは既知の GUID、2 つ目は変更が可能な識別名という 2 種類の一意プロパティによって識別されています。
図 2 Exchange Server 2007 セキュリティ グループ (画像をクリックすると拡大表示されます)
この 2 つのプロパティを使用し、セットアップの実行時にそれぞれに対応するフォレストの OtherWellKnownObjects 属性にこれらが追加されるようにすることで、フォレスト内のどこからでもセキュリティ グループを Exchange が見つけられるようにしています。したがって、フォレスト内の別のドメインであっても、任意の場所にグループを移動することができます。詳細については、Microsoft TechNet で公開されている Exchange 2007 ドキュメントの Ross Smith によるすばらしい記事「Exchange 2007 のアクセス許可 : よく寄せられる質問」(technet.microsoft.com/bb310792) を参照してください。
Q Exchange 2007 ベースのメッセージング環境のいくつかの制限のため、各 Exchange 2007 CCR メールボックス サーバーのファイル共有監視を別のハブ トランスポート サーバーに移動したいと考えています。サポートを受けられる形式でこれを実現する方法について、アドバイスをお願いします。
A Exchange 2007 ハブ トランスポート サーバー間でファイル共有監視を移動することは、非常に簡単です。クラスタ化されたメールボックス サーバー用にファイル共有監視を最初に構成したときに実行した手順を使用するだけです。ただし、サーバーに指定するパスのみを変更します。適切な手順については、Microsoft TechNet で公開されている Exchange 2007 ドキュメントの「ファイル共有監視を構成する方法」(technet.microsoft.com/bb124922) を参照してください。
なお、ファイル共有監視の構成時にハブ トランスポート サーバーを指す CNAME レコードを使用している場合は、ターゲット ホストの完全修飾ドメイン名 (FQDN) を、対応する CNAME レコード内のエイリアスが指すものに変更するだけで、この処理を行うことができます (図 3 参照)。
図 3 ファイル共有監視のターゲット ホストを指す CNAME レコード (画像をクリックすると拡大表示されます)
ただし、別のサイトにクラスタ ノードがある場合、Exchange 製品グループによるサイトの回復性についてのガイダンスが変更されていることに注意してください (msexchangeteam.com/archive/2008/04/03/448615.aspx 参照)。基本的に、Exchange 製品グループでは、Exchange 2007 ジオクラスタ環境での CNAME レコードの使用を推奨しなくなりました。
Q Exchange 2007 メッセージング サーバーのセキュリティ設定の強化を計画しています。このセキュリティの最適化計画には、Exchange データベースが配置されているボリュームの暗号化も含まれています。暗号化ファイルシステム (EFS) による暗号化を使用して暗号化されたボリュームに Exchange データベース ファイルを格納することは推奨されていますか。そもそもこれはサポートされているでしょうか。
A いいえ。マイクロソフトでは、Exchange 2007 データベースを EFS により暗号化されたボリュームに配置することをサポートしていません。実は、.edb、.log、.stm (Exchange 2000 または 2003)、.dat、.eml、.chk ファイルについても、サポートしていません。最大の理由は、このような暗号化のためにオーバーヘッドが増大し、大幅にパフォーマンスが低下するためです。
Exchange 2007 データ ファイルのセキュリティを強化するのであれば、Exchange コンピュータへの不正アクセスを防止し、S/MIME メッセージ形式を使用してメッセージ データを暗号化してください。また、Exchange 2007 を Windows Server 2008 にインストールしている場合は、BitLocker を使用してボリュームを保護することも検討してください。
Q つい最近、Exchange 2007 SP1 をドメイン コントローラでもある Windows Server 2008 サーバーにインストールしました。この環境では IPv6 を使用していないので、Exchange 2007 SP1 のインストール完了後に [ネットワーク接続] でこれを無効にし、サーバーを再起動しました。オンラインに戻ったところ、Exchange 2007 サービスが開始されなくなりました。アプリケーション ログには次のような内容のエラー 214 が記録されています。
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
A この動作についてはいくつか報告を受けています。Exchange 2007 サーバーの役割をドメイン コントローラでもある Windows Server 2008 サーバーにインストールすることは推奨される構成ではありませんが、1 つ以上の Exchange 2007 サーバーの役割を IPv6 を無効にしたドメイン コントローラ上で実行しても、特にこれはテスト環境などでは一般的な構成なので機能します。現時点での解決策は、サーバー上で IPv6 を再度有効にすることです。この問題は、Exchange 2007 SP1 のロールアップ 4 で修正されるという噂があります。
Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 14 年以上の経験がある、Exchange 2007 および Exchange MVP です。Interprise Consulting (デンマークを拠点とするマイクロソフト インフラストラクチャ ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corporation (ドキュメント管理とローカライズ サービス専門とする米国の企業) でテクニカル ライターを務めています。