Exchange Queue & A不可思議な添付ファイルのサイズ増加、パブリック フォルダのレプリケートなど
Henrik Walther
Q 私が所属している組織では Exchange Server 2007 ベースのメッセージング インフラストラクチャを使用しており、メッセージのサイズについて 12 MB という比較的厳しい制限が適用されています。
メッセージの添付ファイルのサイズに関して奇妙な現象が見受けられます。たとえば、外部ユーザーに 11 MB のファイルを添付した電子メール メッセージを送信すると、メッセージは期待どおり受信者に配信されます。しかし、同じメッセージ (添付ファイルを含む) を社内ネットワークにいる送信者に転送すると、送信者である外部ユーザーは、メッセージのサイズが現在のシステムに設定されている制限値よりも大きいか、または受信者のメッセージ ボックスがいっぱいであることを示す配信不能レポート (NDR) を受信します。
この問題を調査したところ、メッセージが外部に送信されるどこかの時点において、添付ファイルのサイズが約 30％ 増加することがわかりました。インターネット経由で電子メール メッセージを送受信すると、添付ファイルのサイズが増加する理由を教えてください。それと、これが想定されている動作であるのかどうかについても教えてください。
A ご質問に対して手短にお答えすると「ご指摘のとおりです」ということになります。この現象は、想定されているものです。Exchange Server 2007 だけでなく、それ以前のバージョンの Exchange Server や MIME (Multipurpose Internet Mail Extensions) をサポートし、添付ファイルのエンコードに Base64 アルゴリズムを使用している他のメッセージング システムについても同様です。Exchange 組織内のユーザーにメッセージを送信する場合、コンテンツを変換する必要はありません。つまり、配信後に、メッセージや添付ファイルのサイズが増加することはありません。一方、外部ユーザーにメッセージを送信する場合は、変換が必要になることがあります。
標準的な SMTP メッセージ (テキスト形式のメッセージ) は、メッセージ エンベロープとメッセージ コンテンツ (つまり、メッセージ ヘッダーとメッセージ本文) で構成されています。これらの要素は、7 ビットの US-ASCII テキスト ベースです。メッセージに US-ASCII テキスト以外の要素が含まれている場合、その要素はエンコードする必要があります。このようなテキスト以外のコンテンツ (添付ファイルなど) を処理する際には、エンコードに MIME が使用されます。Exchange Server 2007 と以前のバージョンの Exchange Server では、どちらも添付ファイルのエンコードに Base64 アルゴリズムを使用します。Base64 アルゴリズムの欠点は、添付ファイルのサイズが 33% 増加することです。
Exchange Server 2007 では、トランスポートに関連するコンテンツの変換のほとんどは、ハブ トランスポート サーバーで行われます (ただし、Outlook Web Access を使用している場合は異なります)。詳細については、「コンテンツ変換について」(technet.microsoft.com/library/bb232174) を参照してください。
Q Exchange Server 2003 から Exchange Server 2007 への移行を行っているところで、すべてのユーザーのメール ボックスを Exchange Server 2007 のメールボックス サーバーに移動しました (メールボックス サーバーは、すべてクラスタ連携レプリケーション (CCR) を使用して構成しています)。現在は、既存の Exchange Server 2003 パブリック フォルダ サーバーから CCR ベースのメールボックス サーバーに、すべてのパブリック フォルダをレプリケートしているところです。しかし、テストを実施したところ、CCR クラスタで損失を伴うフェールオーバーが発生したときに、もう一方のノードでパブリック フォルダのデータベースがオンラインにならないことが判明しました。また、フェールオーバーの発生後に、データベースを手動でマウントすることもできません。
運用環境の Exchange Server 2007 インフラストラクチャを再現したラボ環境がありますが、このラボ環境でも同じ問題が発生します。損失を伴うフェールオーバーが発生した CCR クラスタにあるメールボックス データベースでは、この問題は発生していません。そのため、この問題は、CCR クラスタにあるパブリック フォルダのデータベースと密接な関係があるのではないかと思っています。パブリック フォルダのデータベースを含め、Exchange Server 2007 環境では、すべてのデータベースで完全な冗長性を実現したいと考えているので、この現象の原因として考えられることがあれば教えてください。
A Exchange Server 2007 では、CCR とパブリック フォルダで使用されるレプリケーションの方法が大きく異なります。そのため、パブリック フォルダ データベースを CCR ベースのメールボックス サーバーに配置する場合は、Exchange 組織内の複数のパブリック フォルダ データベースを CCR ベースのメールボックス サーバーと組み合わせて使用することはお勧めしません。移行中には、このような構成にすることは可能で、Exchange Server 製品グループでは、CCR ベースのメールボックス サーバーと既存の Exchange Server 2003 サーバーなどにパブリック フォルダ データベースを配置することがサポートされています。しかし、パブリック フォルダのデータをレプリケートしたら、パブリック フォルダ データベースは、非 CCR ベースのメールボックス サーバーから削除することを強くお勧めします。
現在、Exchange Server メッセージング環境で発生している現象は想定されているものです。複数のパブリック フォルダ データベースがある場合に、その 1 つが CCR ベースのメールボックス サーバーに配置されていると、CCR ベースのメール ボックス サーバーは損失を伴うフェールオーバー (つまり、予定外のサービス停止) が発生したときにオンラインになりません。
実際のところ、パブリック フォルダ データベースは、以前にアクティブであったノードが再度オンラインになるまでオンラインにすることができません。また、パブリック フォルダ データベースがホストされているストレージ グループの全トランザクション ログ ファイルが利用できる必要もあります。
この条件を満たすのが難しい場合、最も確実な復旧方法は、最新の正常なバックアップからパブリック フォルダ ストアを復元し、利用できるログを再生して、復元したデータベースから他のノードを再シードすることです。パブリック フォルダ ストアはゼロから作成することもできます。この場合、元のアクティブ ノードを回復する必要があります。また、新しいパブリック フォルダ データベースを作成し、Exchange 組織内の他のパブリック フォルダ サーバーからパブリック フォルダのデータをレプリケートする必要があります。
不思議な現象だと思われるかもしれませんが、損失を伴わない (スケジュールされた) サービス停止が発生したときには、パブリック フォルダ データベースはオンラインになります。これは想定されている動作です。詳細については、「クラスタ連続レプリケーション」の「クラスタ連続レプリケーションの計画」を参照してください。
Q Exchange Server 2007 ベースのメッセージング インフラストラクチャにあるメールボックス サーバーは、すべて CCR を使用して構成しています。CCR の機能には非常に満足していますが、1 つ疑問があるので質問させてください。
毎晩実行しているオンライン保守の一連の処理の 1 つとして、オンラインでのディスクの最適化が行われています。CCR クラスタのパッシブ ノードにあるデータベースが、オンライン保守の実行時に最適化されるようにするには、どうしたらよいですか。
A オンラインでのディスクの最適化は、削除対象としてマークされたアイテムを削除し、このようなアイテムが占有していた領域を空白に変えるタスクで、この処理が行われると新しいトランザクション ログ ファイルが生成されます。アクティブな CCR ノードで生成されたトランザクション ログ ファイルは、パッシブ ノードにレプリケートされるので、パッシブ ノードにあるデータベースにも変更が加えられます。
オンライン保守の処理がバックアップ処理の時間帯と重複すると、オンラインでのディスクの最適化の処理が停止されてしまうので、これらの処理の時間帯が重複しないようにする必要があります。ですが、ディスクの最適化は、毎日、毎週、または 2 週間ごとに行わなければならない処理ではありません。以前、Exchange Server 製品グループが提供したガイドでは、少なくとも 2 週間に 1 回はオンラインでのディスクの最適化を行うことを推奨していました。しかし、環境は組織によって異なるため、Exchange Server 2007 SP1 では、この推奨事項を変更しました。この新しいガイドの詳細については、Microsoft Exchange Team Blog の記事を参照してください。
Q Exchange Server 2007 の CCR 機能を使用してメールボックス サーバーの完全な冗長性を実現することを計画しています。アクティブな CCR ノードからパッシブ ノードへの損失を伴うフェールオーバーが発生したときに、メッセージが失われることがないように、トランスポート収集コンポーネントを CCR と組み合わせて使用する方法を調査しています。トランスポート収集コンポーネントについて把握しておいた方が良いことがあれば教えてください。
A トランスポート収集コンポーネントは、CCR を使用している Exchange Server 2007 メールボックス サーバーのノード間で損失を伴うフェールオーバーが発生したときに、データの損失を最小限に抑えます。これは、最近、メールボックス サーバーに対して送信されたメッセージを再配信することで実現しています。損失を伴うフェールオーバーでは、一部のトランザクション ログ ファイルを失うことは十分にあり得るので、実データを失う可能性もあります。既に説明したように、トランスポート収集コンポーネントでは、最近、メールボックス サーバーに送信されたメッセージを再配信することで、損失を伴うフェールオーバー中に失われたデータを復元しています。しかし、トランスポート収集コンポーネントが配置されているハブ トランスポート サーバー経由で再配信されるのはメッセージだけなので、フェールオーバーが発生する直前に作成された仕事や予定表のアイテムは失われます。
Q 現在、Exchange Server 2003 から新しい Active Directory フォレストの Exchange Server 2007 へのフォレスト間の移行を行う計画を立てています。フォレスト間の移行について説明している「単一フォレストからフォレスト間のトポロジに移行する方法」は隅々まで読みました。このドキュメントには、フォレスト間では外部の信頼ではなくフォレストの信頼を使用する必要があると明記されていました。外部の信頼を使用できない理由を教えてください。
Aご指摘の TechNet で公開されている Exchange Server 2007 に関する資料には、外部の信頼ではなくフォレストの信頼を使用する必要があるという記載がありますが、外部の信頼を使用できないというわけではありません。実際、外部の信頼は、Exchange Server のフォレスト間の移行で問題なく機能します。ただし、1 つ欠点があります。その欠点とは、リンクされたメールボックスを作成する際に、信頼されているフォレストに配置されたドメイン コントローラに対して適切なアクセス許可を持っているアカウントを指定する必要があることです (図 1 参照)。これは、ログオン ユーザーの資格情報を使用できないことが原因で必要になる手順です (ログオン ユーザーに与えられているアクセス許可のレベルには関係ありません)。
図 1 リンクされたメールボックスを作成するときに [マスタ アカウント] ページでアカウントを指定する
Q 最近、私が所属している組織では Exchange Server 2007 ベースのメッセージング環境に移行しました。今のところ、この新しいバージョンには満足していますが、1 つだけ問題があります。Exchange Server 2003 SP2 を使用していたときは、送信メッセージの送信者のところにユーザー メールボックスの簡易表示名が表示されるように環境を構成することができました。残念ながら、Exchange Server 2007 では同様の機能を見つけることができません。この機能が Exchange Server 2007 で廃止されていないことを願っているのですが、真相を教えてください。
A 実は、この機能は Exchange Server 2007 RTM では提供されていませんでしたが、2008 年 10 月にリリースした Exchange Server 2007 SP1 の更新プログラムのロールアップ 4 (RU4) で提供されるようになりました。SP1 RU4 を適用すると、Exchange Server 2003 SP2 のときと同様に、送信メッセージに簡易表示名が表示されるように Exchange Server を構成できます。この処理は、Windows PowerShell の Set-RemoteDomain コマンドレットで –UseSimpleDisplayName パラメータを使用して実行できます。たとえば、contoso.com ドメイン宛に送信されるメッセージに簡易表示名が表示されるようにするには、図 2 に示すコマンドを使用します。
図 2 送信メッセージに簡易表示名が表示されるようにするためのコマンド
Q CCR を使用して構成した Exchange Server 2007 メールボックス サーバーのパッシブ ノードにあるデータベースを最適化するベスト プラクティスを教えてください。CCR クラスタの一方のノードにあるデータベースが最適化され、もう一方のノードにあるデータベースが最適化されないと、Exchange Server で混乱が生じることはありますか。
A オフラインでのディスクの最適化を実行する必要がある場合は、必ず CCR クラスタのアクティブ ノードで実行し、パッシブ ノードでは実行しないでください。アクティブ ノードにあるデータベースに対してオフラインでのディスクの最適化を実行した場合、最適化したデータベースについては、パッシブ ノードの完全再シードを実行する必要があります。
たとえば、200 GB のデータベースの最適化には、(経験則では、1 時間で最適化されるのは 2 ～ 4 GB なので) 数時間かかるということになります (CCR を使用しているときに 1 GB ネットワーク経由でデータベースをレプリケートする場合、データベースの推奨サイズは 200 GB です)。最適化の処理が完了したら、200 GB のデータをパッシブ ノードにレプリケートする必要があります。パブリック ネットワーク経由でログ ファイルを配布する場合は、エンド ユーザーのネットワーク パフォーマンス全般に影響することがあります。
多くの場合、オフラインでのディスクの最適化は、データベースの空白領域を削除して、データベースのサイズを縮小する目的で行われます。しかし、データベースのサイズがさらに増加する前に空白領域は再利用されるため、オフラインでのディスクの最適化を行う必要があることはまれです。実際、データベースやディスク自体に利用できる領域があれば、たいした問題ではないと思います。
データベースに数 GB もの空白領域があって、それを削除する必要がある場合、より適切なアプローチは、このような領域を削除するのではなく、すべてのメールボックスを新しいデータベースに移動することです。
Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 14 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。Interprise Consulting (デンマークを拠点とするマイクロソフト ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corporation (ドキュメント管理とローカライズ サービスを専門とする米国の企業) でテクニカル ライターを務めています。