Microsoft Outlook Web Access (OWA) は、Exchange 2000 と緊密に統合されたコンポーネントです。実際、Exchange 2000 のデフォルト設定の一部として組み込まれているため、OWA を実行するためにカスタマイズは必要ありません。しかし、組織が「すぐに使える」OWA ソリューションよりも高いパフォーマンス、信頼性、セキュリティを求めている場合は、フロントエンド サーバーがまさに最適なソリューションとなる可能性があります。ここでは、Exchange 2000 OWA の基本設定をさらに進め、フロントエンド/バックエンド (FE/BE) OWA アーキテクチャの主要なメリットを組織で活用する方法をご紹介します。
FE/BEトポロジの使用
組織内で既に複数のExchange 2000サーバーを運用されていますか？その場合、マイクロソフトはOWAの導入にFE/BEサーバーアーキテクチャの使用を推奨します。このトポロジでは、フロントエンドのExchange 2000サーバーが、OWAを実行しているバックエンドのExchange 2000サーバーにHTTP要求を送信します。フロントエンドサーバーはまずADを検索し、どのバックエンドサーバーが要求を受信するかを判断し、適切なサーバーに要求を中継します。
ここでの明らかな利点は、フロントエンドサーバーがユーザーに提供する単一の一貫性のある名前空間です。ユーザーは、メールボックスがどのサーバーにあるかを正確に示すURLを覚えておく必要がありません。さらに、単一の名前空間であれば、メールボックスをバックエンドサーバー間で移動しても、ユーザーは同じURLを使用できます。
もう1つの利点は、安全なファイアウォール接続またはDMZ経由でOWAアクセスを許可する場合に見られます。図Aに示すように、フロントエンドサーバーのみがポート80でインターネットに公開されます。このサーバーはユーザーのメールボックスやデータにアクセスしないため、セキュリティがさらに強化されます。
| 図A |
 |
| FE/BEトポロジ |
Exchange 2000 Enterprise Edition を実行しているサーバーであれば、どれでもフロントエンドサーバーになることができます。必要な変更は、サーバーのプロパティダイアログボックスで「これはフロントエンドサーバーです」チェックボックスをオンにすることだけです（図Bを参照） 。
| 図B |
 |
| フロントエンドサーバーの構成 |
変更後、Exchange サービスと IIS サービスを再起動するか、コンピュータを再起動する必要があります。この変更は基本的に、Exchange 2000 サーバーにすべての HTTP トラフィックをユーザーのメールボックスを含むバックエンドサーバーにリダイレクトするように指示するものです。
一般的なルールとして、バックエンドサーバー4台につきフロントエンドサーバー1台を推奨します。もちろん、これはあくまで目安です。実際に必要なフロントエンドサーバーの台数は、ユーザー数、ユーザーの種類（ライトユーザーとヘビーユーザー）、そしてセッションの平均時間によって異なります。フロントエンドサーバーには、大容量または特に高速なディスクストレージは必要ありませんが、高速CPUと十分なメモリなど、Webサーバーと同様のスペックが必要です。
サーバー間の通信のセキュリティ保護
フロントエンドサーバーは、2つの方法のいずれかで認証を処理します。サーバーがユーザーを認証するように構成されているか、リクエストを匿名でバックエンドのExchange 2000サーバーに転送するように設定されているかのいずれかです。推奨される構成は、フロントエンドサーバーでユーザーを認証することです。
Exchange 2000 フロントエンドサーバーは、クライアントコンピュータとフロントエンドサーバー間、およびフロントエンドサーバーとバックエンドサーバー間の認証において、HTTP 1.1 基本認証のみをサポートしています。基本認証では、ユーザー名とパスワードをネットワーク経由で送信する際に、弱い形式のエンコードしか使用できないため、SSL の使用を強くお勧めします。
ここで、FE/BEアーキテクチャのもう一つの利点が発揮されます。SSLを使用すると、フロントエンドサーバーがすべての暗号化と復号化の処理を処理できるため、バックエンドサーバーからSSL処理タスクが削除され、ネットワークパフォーマンスが向上します。セキュリティをさらに強化するために、図Cに示すように、フロントエンドサーバーへのSSL接続を必須にし、SSLなしのアクセスを無効化することをお勧めします。
| 図C |
 |
| フロントエンド サーバーで SSL を要求するのが最適です。 |
また、フロントエンドサーバーとバックエンドサーバー間のHTTP通信は暗号化されていないことにもご注意ください。フロントエンドサーバーはWindows統合セキュリティ（NTLM認証とKerberos認証の両方を含む）をサポートしていません。また、バックエンドサーバーとの通信にSSLを使用することもできません。これらの要因を考慮すると、フロントエンドサーバーでSSLを使用することが最適なソリューションであるという結論に至ります。
フロントエンドサーバーへのOWAログオン：通常、ユーザーはフロントエンドサーバーにログオンする際に、ドメイン名\ユーザー名
の形式でユーザー名を入力する必要があります。ただし、フロントエンドサーバーがデフォルトのドメインを想定するように設定することで、ユーザーがドメイン名を入力する必要がなくなります。図Dに示すように、Exchange仮想ディレクトリとPublic仮想ディレクトリを変更し、デフォルトのドメイン名を手動で入力するだけです。
| 図D |
 |
| ユーザーログオンのデフォルトドメイン名の入力 |
この変更を行った後、System Attendant サービスが実行されていることを確認してください。これにより、構成設定がディレクトリから IIS メタベースに複製されます。または、Exchange System Attendant を再起動して強制的に複製することもできます。複製が完了すると、ユーザーはユーザー名とパスワードだけでログオンできるようになります。ドメイン名は必要ありません。
認証の追加オプションとして、ユーザープリンシパル名（UPN）ログオンを設定できます。これにより、ユーザーはユーザー名としてメールアドレスを入力できるようになります。UPNを設定するには、図Dに示す「既定のドメイン」テキストボックスにバックスラッシュを入力します。すべてのフロントエンドサーバーとバックエンドサーバーの仮想ディレクトリのプロパティでこの設定を行うと、ユーザーはユーザー名として「[email protected]」を使用して認証できるようになります。（この機能を使用する場合は、Exchange SP1の使用をお勧めします。）
サービスパックのインストール順序
FE/BE OWA アーキテクチャでは、Exchange 2000 のサービスパックを適用する順序が重要です。組織内のすべてのフロントエンドサーバーをアップグレードしてから、バックエンドサーバーをアップグレードしてください。これは、OWA のテンプレートとコントロールの設計上の理由によるものです。サーバー間で異なるバージョンのサービスパックが実行されている場合、問題が発生します。
バックエンドサーバー上のテンプレートがフロントエンドサーバー上のコントロールを参照しており、フロントエンドサーバーが以前のサービスパックを実行している場合、バックエンドサーバーが参照しているコントロールが存在しない可能性があります。その結果、アップグレードされたバックエンドサーバー上にメールボックスがあるユーザーに対しては、OWA が機能しなくなります。ユーザーがバックエンドサーバーのテンプレートを参照できるように、まずすべてのフロントエンドサーバーをアップグレードしてください。これらのテンプレートは以前のバージョンのコントロールを参照しますが、ファイルはバージョン管理されており、アップグレードによって削除されないため、フロントエンドサーバー上には以前のバージョンのコントロールが残っています。
概要
フロントエンド/バックエンド アーキテクチャを使用する OWA ソリューションを適切に導入すると、Exchange 2000 でデフォルトで提供される一般的なセットアップよりも信頼性が高く、パフォーマンスが向上し、セキュリティが強化されます。このトポロジを使用して、OWA を次のレベルに引き上げます。
