Exchange Queue & Aすべての質問にお答えします (質問を作った本人ですから)

KC Lemson and Paul Bowden

Exchange Queue and A の初回の記事へようこそ。私たちは、これから一連の質問に回答します。正直に言うと、質問は私たち自身で考えたものなので、これを Q&A コラムとして位置付けるのはフェアではないでしょう。

だれかが質問して、だれかが回答する、という状況でなければ、Q&A とは言えないからです。しかし、私たちはこれらの質問が Microsoft® Exchange Server のユーザーが抱く質問の代表的なものであることを確信しています。私たちが教訓を重視するのはそのためです。今後、皆様のご質問を心から歓迎します。ご質問は queuea@microsoft.com までお送りください。

現在のところ、このコラムは数人で交代して執筆する予定です (どの執筆者の記事が掲載されるかは見てのお楽しみです)。執筆者は全員、Exchange に長年かかわってきた者です。今月の回答 (質問もです) は、マイクロソフトの Exchange 製品チームのリード プログラム マネージャである KC Lemson と Paul Bowden が担当しました。私たちは二人とも Exchange の開発に長年携わっています。何度も異動しましたが、メッセージングから離れることはできませんでした。

KC は、この 6 年間 Exchange グループに所属し、Microsoft Outlook® Web Access (OWA) のプログラム マネージャ、Exchange のプレリリース カスタマ プログラムを担当するリード プログラム マネージャなど、さまざまな任務を果たしてきました。現在は Exchange のユーザー エクスペリエンス マネージャとして、製品デザインおよび顧客調査を担当しています。Exchange に加わる前の 3 年間は、Outlook のテスト担当者でした。電子メールに添付された実行可能ファイルをブロックすることがかなり悪いことと考えられていた時代に、添付ファイルのテストを実施していました。KC のブログは blogs.technet.com/kclemson (英語) にあります。

Paul がこの 3 年間取り組んできた Exchange Best Practices Analyzer (ExBPA) ツールはすばらしいものでした。実際、2 か月前に彼の成果に対して賞が与えられ、彼はビル・ゲイツと一緒に写真を撮りました。しかし、Exchange Server 2007 プロジェクトの終了と共に、次のことを始めるときが来ました。Paul は XML の夢からさめて、現実に戻らなければなりません。Exchange の次期バージョン (Exchange Server 2007 の出荷後すぐに作業が開始されます) のリリース マネージャに就任するのです。

ところで、このコラムのウィットに富んだネーミングをご覧いただけましたか? もちろん、私たちはこの名前を自分たちの手柄にすることはできません。KC のブログの読者に提案していただいた名前なのです (Tim、シャツは気に入りましたか?)。次点は、"Pushing the Envelope" および "When I'm X64" という名前でした。後者は KC がとても気に入ったので、www.whenimx64.com を登録し、そこから自分のブログにリンクするように設定しました。私たちが生活のすべてについて権限を持てたらいいのですが。

注記 : KC は、最初はこのコラムの名前として "The Monthly Queue and A" を提案しました。しかし、編集者に、私たちの実際の能力やスケジュールどおりに原稿を提出できるかどうかがわからないと指摘されました (編集者は私たちよりもていねいに、かつ遠慮がちに答えてくれましたが、私たちは彼の考えていることがわかりました)。同じように、私たちもこのコラムの読者からどのようなフィードバックが来るのか、そして繰り返す価値があるのかわかりません。そして、この名前に出会いました。ご意見を queuea@microsoft.com までお寄せください。

説明はこのくらいにして、質問に移りましょう。

Q なぜユーザーは Exchange Server 2007 に興奮するのでしょうか。

A 初回のコラムでマーケティングの質問を扱うのが危険であることはわかっています。しかし、私たちは Exchange Server 2007 にとても興奮しているので、皆さんとこの興奮を共有したいのです。ここでは "market-ecture" (マーケテクチャ) を制限して、Exchange の管理者やユーザーが Exchange 2007 に興奮する技術的な理由をいくつかお話しします。

スケーラビリティとパフォーマンスの向上

まず、明確なのが 64 ビットであることです。「それがどうかしたのか」と思われるかもしれません。32 ビット Windows® では、合計 4 GB (232 バイト) のメモリしかサポートできません。そのうち 2 GB は既定でカーネルが使用するため、アプリケーションで使用できるのは残りの 2 GB だけです。現行バージョンの Windows では、boot.ini で /3GB スイッチを使用することにより、最大 3 GB のメモリ ヘッドルームをアプリケーションに割り当てることができます。しかし、これを一度使用すると、Windows カーネルが多少不安定になり、やがてサーバーを再起動してリソースを解放しなければならなくなります。

さいわい、64 ビットのサポートと、Exchange の基礎となるデータベース エンジン (JET) の大幅な変更により、この問題は解決されます。Exchange サーバーは、他のシステム リソース (CPU など) よりもはるかにディスク I/O に制約されます。したがって、メモリをシステムに追加すると、メモリに情報を格納することによってディスクを読み取る必要がなくなるため、ディスク I/O を大幅に減らすことができます。その結果、Exchange 2007 では、同サイズの物理ハードウェア上で Exchange 2003 よりもはるかに大きなメールボックスをサポートできます。たとえば、マイクロソフトのメール サーバーは、2 GB のメールボックス クォータが設定された 4,000 ユーザー、合計 6 テラバイト (TB) のデータをサポートします。Exchange 2007 はもっと多くのメモリを利用できますが、それだけ多くのメモリが必要であるという意味ではありません。私たちは 32 ビットの Windows Server® 2003 と Exchange 2003 を 4 GB 以下のメモリの環境で実行してメールボックスをテストし、64 ビットの Windows Server 2003 と Exchange 2007 をインストールしましたが、パフォーマンスは変わりませんでした。

また、Exchange 2007 では、クラスタ連続レプリケーション (CCR) およびローカル連続レプリケーション (LCR) という新しい 2 つの方法により可用性が向上します。これらのテクノロジを使用すると、ストレージ障害で重大な問題が発生する危険性が低くなります。LCR はデータベースのローカル コピーを同じコンピュータ上に保管しますが、それを別のストレージ メディアに保存することもできます。CCR を使用すると、ネットワーク上の 2 台のコンピュータで同じ処理を実行できます。CCR と、このコラムで既に説明したディスク I/O の機能強化により、ストレージ ハードウェアに関する選択肢が広がりました。SATA ドライブや SCSI ドライブなどの直接接続型のストレージ メディアを使用する場合は、大幅に費用効率が高まり、パフォーマンスが向上します。

管理

マイクロソフトは、Exchange 2007 で管理を行う場合の新しい操作性に多額の投資を行いました。たとえば、図 1 に示すコマンドライン インターフェイスです。このインターフェイスは Exchange 管理シェル (EMS) と呼ばれ、Windows PowerShell™ をベースにしています。コマンド ラインが好きでない場合は、Exchange 管理コンソール (EMC) という GUI も使用できます。この GUI は、以前のシステム マネージャよりも直観的でわかりやすいインターフェイスになっています (図 2 を参照)。コマンドライン インターフェイスを既に使用しているか、これから使用する場合は、Exchange 2007 で EMS について調べてみてください。

図 1 Exchange 管理シェルでのストレージ グループ ステータスの表示

図 1** Exchange 管理シェルでのストレージ グループ ステータスの表示 **(画像を拡大するには、ここをクリックします)

図 2 Exchange 管理コンソールでの同じステータスの表示

図 2** Exchange 管理コンソールでの同じステータスの表示 **(画像を拡大するには、ここをクリックします)

Exchange 2003 では、複雑な管理タスクを実行するのに Windows Management Instrumentation (WMI) スクリプトを使用する必要がありました。しかし、EMS では、"CD C:\TEMP" を見て新しいバンドのアルバムと思わないユーザーであれば、だれもがこれらのタスクを実行できます。私たちの 1 人は元 UNIX のシステム管理者です。そのために私たちの客観性についてここで疑問が出るかもしれません。しかし、これまでにコマンド ラインを使用したことがないユーザーにとってもシェルがとても直観的で使いやすいということを保証してくれる多くのサード パーティを紹介できます (詳細については、次回の Exchange Queue and A コラムを参照してください)。

Windows PowerShell の美しさの 1 つは、オブジェクトベースであることです。サーバーからメールボックスまたは SMTP コネクタのリストなどの情報を取得すると、その情報は自動的にオブジェクトや変数に格納され、簡単に読み取ることができるようにテキストとして stdout に出力されます。その後、そのオブジェクトを別のコマンドに直接渡したり、パイプラインで処理したりできます (この場合は、テキストではなくオブジェクトを渡すことにより、簡単にデータを変更したりその一部を処理したりできます)。ここに簡単な例を示します。

Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB

Get-Mailbox コマンドは、システム内のメールボックスのリストを取得します。| (パイプ記号) は、左側のコマンドの出力が右側のコマンドに渡されることを示します。次の "Set-Mailbox-ProhibitSendQuota 250MB" は、電子メールを 250 MB 以上送信できないように、すべてのメールボックスにクォータを設定することを意味します。値を 250000000、250000 KB、または .25 GB と設定することもできます。シェルは柔軟にデータを処理できます。

Exchange 2007 で管理を行う場合に役立つもう 1 つの機能強化は、トランスポート ルールを作成できるようになったことです。Outlook のウィザードによく似たルール ウィザードを使用して、システム内を流れるメッセージにビジネス ロジックを適用できます。本文に社会保障番号が含まれていると思われる電子メールを、正規表現に基づいてブロックしますか? チェックしてください。組織内の 2 つの部門間で電子メールをやり取りできないように、倫理的境界を設定しますか?チェックしてください。組織外に送信されるすべての電子メールに免責事項を追加しますか? チェックしてください。

私たちがとても興奮する管理機能の最後の 1 つは、カスタマイズ可能なシステム メッセージです。特別な構成を行わなくても、配信しないレポートや、ストレージ クォータを超えたときにユーザーに表示するメッセージに、独自のカスタム テキストを追加できるようになりました。

ヘルプ デスクの支援

多くのお客様にとって、費用の最も大きな部分を占めるのが、Outlook で新しいプロファイルを構成するときにかかるヘルプ デスク コストです。Outlook 2007 の Autodiscover を使用すると、Outlook を起動するだけで、自動的に電子メール アドレスが検索され、サービス接続ポイントを使用して Active Directory® から Exchange サーバーの情報が取得されます。Active Directory に接続していない場合は、電子メール アドレスとパスワードを入力するだけで、RPC over HTTP (今回から Outlook Anywhere という名前になりました) に使用するサーバーなどの基本構成情報が格納された指定 Web サーバー (http://autodiscover.contoso.com (英語) など) から、Autodiscover によって XML ファイルをダウンロードできます。

他にヘルプ デスク コストがかかるのは、スパム対策フィルタによる、一見避けられないと思われる誤検知の管理です。ユーザーは Outlook に送信者のセーフ リストを保管して、それらの送信者のメッセージをコンテンツ フィルタリングの対象から除外できますが、Exchange 2007 以前は、そうしたリストで回避できるのは Outlook のフィルタだけでした。しかし、メッセージは Exchange のフィルタを通ってから Outlook で調べられるため、ユーザーは信頼している送信者からの電子メールを受け取ることができない場合がありました。

Exchange 2007 はここでも次のように役立ちます。Exchange 2007 のエッジ サーバーまたはハブ サーバーの役割でスパム対策のコンテンツ フィルタを使用する場合は、ユーザーの送信者セーフ リストをそのサーバーに適用するように構成できます。これにより、そのリスト内の送信者から送信されたメッセージはスパム コンテンツ フィルタの対象から除外されます。当然のことですが、あるユーザーにとってスパムである内容が、別のユーザーにとってはニュースレターであることもあります。したがって、送信者セーフ リストはユーザーごとに作成されます。

エンド ユーザーの喜び

Exchange 2007 のユニファイド メッセージング (UM) を使用すると、送られてきたボイスメールやファックスを受信トレイで受信できます (今までにこのような経験がない場合は、何が受信できないのかさえわかりません)。また、Exchange サーバーを呼び出して、午前 8 時の会議の参加者全員に自分が遅れることを知らせるように設定することもできます。小規模の組織でも、お客様から電話があったときにシステムで正しい転送先に電話を転送できるように、容易に自動応答に独自のカスタマイズができます。UM を使用するには、IP-based PBX (IP/PBX) を使用するか、従来の回路交換ベースの PBX を Voice over IP (VoIP) ゲートウェイに接続します。

リンク アクセスは OWA 2007 の新機能です。VPN クライアントがインストールされていない状況で、会社のネットワーク上のファイル共有または SharePoint® サイトにある Microsoft Word 文書を表示する必要がある場合は、どうすればよいでしょう。問題ありません。まず OWA 2007 を読み込んでドキュメント リンクに移動します。次に、ファイル共有または SharePoint サイトの名前 (http://mysharepointsite または \\server\share) を入力し、ファイルを探して開くだけです。もちろん、管理者がこのような操作をロックできるセキュリティ制御も多数あります。たとえば、特定のリストを除くすべてのサーバーを許可する、特定のリストを除くすべてのサーバーを拒否する、ユーザーが個人のコンピュータから OWA にログインした場合にのみドキュメントへのアクセスを許可する、などの制御です。

OWA には WebReady ドキュメント表示 (専門用語で "トランスコード") も組み込まれています。これにより、適切なアプリケーションがローカルにインストールされていない場合に、特定のファイルの種類を HTML に変換するように Exchange に指示できます。Exchange 2007 では、既定で DOC、DOT、RTF、WBK、WIZ、XLS、XLK、PPT、PPS、POT、PWS、および PDF のトランスコードのサポートが付属しています。トランスコード エンジンはプラグ可能なアーキテクチャを採用しているため、新しいファイルの種類のサポートをサービス パックで追加できます。また、ユーザーにトランスコードを許可するファイルの種類を指定したり、トランスコードをまったく許可しないように指定できる管理オプションもあります。

Exchange ActiveSync® を使用して Exchange と同期するモバイル デバイスがある場合は、電子メールに返信するか電子メールを転送するときに、メッセージがテキストに変換されなくなったことがわかるでしょう。テキストは一番上に追加されますが、残りのメッセージの HTML 本文はそのままです。これは、ActiveSync をサポートするデバイスで機能します。クライアントにこの機能は必要ありません。

Q Exchange 2007 は「実稼働環境には 64 ビットのみ」と聞きました。これはどういう意味でしょうか。

A Exchange 2007 には、32 ビット版と 64 ビット版があります。64 ビット版は、コア サーバーの役割 (メールボックス、ハブ トランスポート、エッジ トランスポート、クライアント アクセス、ユニファイド メッセージング) を実稼働環境で使用することを目的としています。32 ビット版は、Exchange 2007 の新機能を評価することを目的としています。管理ツールは 32 ビットの実稼働環境でも使用できるため、64 ビットの Exchange 2007 の運用サーバーを 32 ビットの Windows XP デスクトップ コンピュータから管理できます。また、Exchange 2007 のスキーマは、ルート ドメインのコンピュータからインストールする必要があります。Exchange そのものはルート ドメインにインストールする必要はありませんが、スキーマ マスタへのネットワーク接続を維持する方法として、スキーマ拡張をルート ドメインで行う必要があります。ルート ドメインに 64 ビット サーバーがない場合は、32 ビット版から setup.exe を使用してスキーマを拡張できます。

32 ビット サーバーに何か問題があるのでしょうか。1 台のサーバー上で数千のユーザーを管理したことがあれば、その問題はまさに、前に説明したようなメモリに制限がある状況でパフォーマンスと安定性のバランスをとることであることがおわかりいただけるでしょう。この 2 年以内に新しいコンピュータを購入した場合は、既に x64 拡張に対応している可能性があります。実際、最近は、64 ビット モードに対応していないコンピュータを新しく購入するのが難しいほどです。したがって、ご使用の環境で Exchange が既に実行されているコンピュータは、64 ビットに対応していながら、ただ 32 ビット オペレーティング システムを実行しているだけかもしれません。新しい 64 ビット対応のコンピュータを手に入れたら、忘れずに Windows Server 2003 SP1 の 64 ビット版をインストールしてください。

では、セットアップ時に、実稼働環境で 32 ビットのインストールを使用しないようにという警告が表示されるのはなぜでしょうか。Exchange を複数のバージョンでコンパイルすることはとても簡単ですが、各コンポーネントは 64 ビット用に完全に最適化され、調整されています (実際、64 ビット システムのディスク I/O を機能強化するために私たちが選択したコード パスの一部が原因で、32 ビット環境でパフォーマンスが低下します)。要するに、32 ビットで使用するときは、負荷のかかる状況 (シミュレーションなど) では実行しないでください。64 ビット システムでのパフォーマンスや、サーバー上で対応できるユーザー数を正しく推測できなくなります。

さて、疑問は解決しましたか。32 ビット版の Exchange 2007 を使用してできることは、次のとおりです。

  • 実際のユーザー メールボックスが存在しないテスト サーバーで新機能を評価する。
  • 新しい管理コンソール、シェル、または OWA インターフェイスを試す (キーボードによだれをたらさないように気を付けてください)。
  • Exchange 2007 サーバーを管理する。
  • Active Directory フォレストのスキーマを拡張する。

メールボックスを移行する準備が整ったら、サーバーを 64 ビットのオペレーティング システムで 64 ビットの Exchange 2007 と共に実行する必要があります。そうしなければ、セットアップと ExBPA を自分で愚痴を言いながら行うことになります (図 3 を参照)。Paul はこれを事実として知っています。彼はコードを書いたのですから。

図 3 64 ビットのみの環境に 32 ビット版をインストールしようとした場合

図 3** 64 ビットのみの環境に 32 ビット版をインストールしようとした場合 **(画像を拡大するには、ここをクリックします)

Q Exchange 2007 を実行するにはどのくらいのメモリが必要ですか。

基本インストールの場合は 1 GB 以上の物理 RAM が必要です。前に説明したように、一部のサーバーの役割はメモリを集中的に使用します。オールインワン サーバー (メールボックス、クライアント アクセス、ハブ トランスポート、ユニファイド メッセージングなど) をインストールする場合は、おそらくまず 2 GB の RAM を搭載し、メールボックスの数と使用状況に応じてメモリを拡張することになるでしょう。エッジ トランスポートの役割またはクラスタをインストールする場合は、別のコンピュータにインストールする必要があります。1 つのクラスタには、メールボックスの役割しかインストールできません。

Exchange サーバーについに 4 GB 以上の RAM を搭載できるようになったことを聞いたら驚くでしょう。現在の多くのコンピュータには標準で 6 GB または 8 GB の RAM が搭載されているので、DDR モジュールを外すか /BurnMemory を使用して RAM を 4 GB に下げるのは非常に残念なことです (残念ながら、Exchange 2003 は、4 GB 以上のメモリがある場合はパフォーマンスが低下し、不安定になります。詳細については、go.microsoft.com/fwlink/?LinkId=76537 (英語) を参照してください)。

インフラストラクチャ サーバー (ハブ、クライアント アクセスなど) の場合は、最も負荷の高い状態でも、4 GB 未満の RAM で十分です。お金をかけたくなるのはメールボックス サーバーです。新しく最適化された 64 ビットの JET のキャッシュでは、投入可能な限りのメモリを利用する必要があるでしょう。もちろん、Exchange 2003 とは違って、Exchange 2007 では最大 50 個のストレージ グループがサポートされています。

各ストレージ グループで複数のデータベースをサポートできますが、それで費用を節約できるわけではありません。特に LCR や CCR (前に説明した 2 つのデータベース レプリケーション形式) は、1 つのデータベースを持つストレージ グループでしか機能しません。一連のストレージ グループを作成するか、各ユーザーに 2 GB 以上のメールボックスを用意する場合は、RAM を追加する必要があります。RAM のサイズ決定の詳細については、「Exchange Team Blog」 (英語) が非常に参考になりますが、まずは図 4 と図 5 の表を参照してください。

Figure 5 RAM とストレージ グループ

物理 RAM 推奨する最大ストレージ グループ数
2 GB 2
4 GB 8
8 GB 24
12 GB 40
16 GB 以上 50

Figure 4 ユーザー タイプ別 RAM

ユーザー タイプ メールボックスの役割のための推奨メモリ
ライト 基本 2 GB + 2 MB/メールボックス
平均 基本 2 GB + 3.5 MB/メールボックス
ヘビー 基本 2 GB + 5 MB/メールボックス

ところで、Microsoft IT では多数のストレージ グループ (7 の倍数) を使用しています。これは、ストレージ グループにローテーションのバックアップ スケジュールを適用し、ある特定の曜日には一部のストレージ グループのみバックアップするからです。私たちはこのスケジュールを "candy cane backups (棒キャンディのバックアップ)" と呼んでいます。Excel スプレッドシートでバックアップ スケジュールを作成し、特定の曜日にバックアップするストレージ グループを赤の斜線で色付けしているからです。この情報がお役に立てたならさいわいです。次回は "本当の" 質問をお送りください。

KC LemsonExchange Server チームのリード プログラム マネージャです。彼女は、自由な時間を使ってナイジェリア王室の財産保護の手助けをしています。

Paul BowdenExchange Server チームのリード プログラム マネージャです。彼女は、自由な時間を使ってナイジェリア王室の財産保護の手助けをしています。Paul Bowden も Exchange Server チームのリード プログラム マネージャです。彼は、自由な時間のほとんどを、要求に応じて PayPal アカウント情報を再確認することに費やしています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.