Exchange 2010

  • [アーティクル]

徹底解剖

Henrik Walther

最近リリースされた Microsoft Exchange Server 2010 の製品版 (RTM) には、これまでのバージョンと同様に、多数の新機能が導入され、既存の機能が強化されています。実は、Exchange Server 2010 は約 2,100 万行ものコードで構成されるようになりました。

Exchange Server の開発チームは、Exchange Server 2010 を開発するにあたり、これまでにない信頼性の実現、パフォーマンスの向上、管理の簡略化、コミュニケーション保護の強化、およびユーザーのビジネス モビリティ強化という 5 つの目標を掲げました。つまり、世界的な経済危機に留意して、Exchange Server 2010 インフラストラクチャの運用コストを削減できる、より柔軟で最適化された製品を生み出すことを目的としました。

2008 年 4 月以降、私はじっくり時間をかけて、ラボと 2 つの顧客企業の環境で Exchange Server 2010 のベータ版とリリース候補版のビルドをテストしてきました。この記事では、最新であるだけでなく、これまでで最高のバージョンでもある Exchange Server 2010 における特にすばらしい変更と機能強化を駆け足で紹介します。

管理アーキテクチャ

Exchange Server 2007 では、Windows PowerShell 1.0 と Microsoft .NET Framework 2.0 ランタイムを基盤とする管理アーキテクチャが導入されました。Exchange Server の管理者はシェルの使い方を習得するやいなや、運用効率を最適化する新しいチャンスを活かしました。もちろん、Exchange Server 2010 の管理アーキテクチャにも、Windows PowerShell 2.0 と .NET Framework 3.5 ランタイムが使用されています。Exchange Server 2010 で使用されている Windows PowerShell 2.0 の機能強化の 1 つは、PowerShell のリモート処理機能です。この機能では、WS-Management (WS-Man) という、組織内のサーバー、デバイス、およびアプリケーションを管理しやすくする Windows コンポーネントが使用されています。

Exchange Server 2007 では、Exchange 管理シェルを使用すると管理者がすべての Exchange Server 2007 サーバーを 1 台の管理サーバーで管理できました。この機能では、コマンドレットが管理サーバーのホストやプロセスで実行され、続いて管理サーバーでは、操作対象の Exchange Server へのリモート プロシージャ コール (RPC) 接続が確立されました。Windows PowerShell 2.0 のリモート処理機能を使用すると、管理はさらに簡略化されます。リモート処理では、ファイアウォール経由で Exchange Server 2010 サーバーを管理するための標準プロトコルが用意され、コマンドレットの処理ではクライアント側とサーバー側の処理が明確に分離されます。また、WS-Man によって、Windows PowerShell 1.0 のときよりも Windows OS とのシームレスな統合が実現されます。

ローカルの Exchange 管理ツールと専用の管理サーバーのどちらを使っている場合でも、Exchange 管理コンソールまたは Exchange 管理シェルを起動すると、リモート接続が確立されます。Exchange Server 2010 では、Exchange 2010 管理ツールがコンピューターにインストールされている場合、ローカルの Windows PowerShell の仮想ディレクトリ (IIS マネージャーの既定の Web サイト配下に作成) に接続されます (図 1 参照)。

 

図 1 IIS マネージャーにおける Windows PowerShell 2.0 の仮想ディレクトリ

Exchange 管理コンソールまたは Exchange 管理シェルが Windows PowerShell の仮想ディレクトリに接続されると、必要なコマンドレット (正確には、これらのコマンドレットへの参照) がサーバー側 (つまり、実行空間) からクライアント側のセッションにインポートされます。コマンドレットの参照がインポートされれば、Exchange Server 2007 と同様に Exchange Server 2010 を管理できます。

Exchange 管理シェルを使用すると、Windows PowerShell セッションを作成して、リモート Exchange Server 2010 サーバーへの新しい接続を確立できます。リモート サーバーへの接続を確立すると、ローカル サーバーのシェルで実行するすべてのコマンドが接続先のリモート Exchange Server 2010 サーバーで直接実行されます。

Exchange 管理コンソールは、管理シェルをベースに構築されており、Windows PowerShell コマンドがバックグラウンドで実行されるので、管理コンソールはシェルと同様に機能します。コンソールを使用して、別の Exchange フォレストの Exchange Server 2010 サーバーに接続してこのサーバーを管理することもできます (図 2 参照)。

しかも、コンソールに他の Exchange 組織を追加できるだけではなく、2 つの Exchange 組織間でメールボックスを移動することもできます (図 3 参照)。

 


図 2 Exchange 管理コンソールに表示された複数の Exchange フォレスト

 


図 3 Exchange Server 2010 における新しいリモートでの移動を要求するウィザード

クラウドの準備状況
最終的には、マイクロソフトの Software Plus Services ソリューションの 1 つである Exchange Online も、Exchange 管理コンソールと Exchange 管理シェルで管理できるようになります。この機能は、マイクロソフトが Exchange Online を Exchange Server 2010 用に更新すると使用できるようになります (現在 Exchange Online は Exchange Server 2007 ベースのサービスとなっています)。この機能により、組織では、組織内のソリューション、ホストされているサービス、または両方の組み合わせから選択でき、両方をシームレスに管理できるようになります。

マイクロソフトでは、Microsoft Live@edu プログラムに登録している教育機関を対象に、この機能を使用できるようにしています。また、Microsoft Outlook Live (これまでに 1,000 万個を超えるメールボックスをホスト) で個人ドメインをホストしているマイクロソフトの社員も使用できます。

アクセス許可モデル

Exchange Server 2010 では、Exchange Server 2007 のアクセス制御エントリ (ACE) ベースのアクセス許可モデルが拡張され、役割ベースのアクセス制御 (RBAC) を使用する新しい承認層が含まれています。RBAC を使用すると、管理者や特別なエンド ユーザーの役割に基づいて、幅広いアクセス許可や詳細なアクセス許可を定義できます。つまり、Exchange Server 2010 では、アクセス許可モデルを、これ以上複雑にすることなく、組織のモデルに合わせて定義できます。ほとんどの企業では Exchange Server 2010 の既定の役割グループで十分に対応できますが、必要に応じてカスタム役割グループを作成することもできます。

言い換えると、RBAC によって、運用管理タスクや特別なユーザーのタスク、およびユーザーが各自のメールボックス、配布ボックスなどを自己管理できる程度が制御されるようになりました。

中間層 のMAPI とディレクトリ アクセス

Exchange Server 2007 では、クライアント アクセス サーバーによって、Outlook (MAPI: Messaging Application Programming Interface) と Entourage (WebDAV: Web 分散オーサリングとバージョン管理) 以外のすべてのクライアント用の接続エンドポイントが提供されます。このため、Exchange Server 2007 以前のバージョンで対処する必要があった、バックエンド メールボックスで実行される処理量が大幅に削減されました。

Exchange Server 2010 では、RPC Client Access Service (RPC クライアント アクセス サービス)を導入し、この機能がさらに進化しました。このサービスでは、MAPI とディレクトリ アクセスの接続が中間層のクライアント アクセス サーバーに移動されます。このため、MAPI クライアントは、メールボックスを開くときにメールボックス サーバーに直接接続するのではなく、RPC Client Access Service (RPC クライアント アクセス サービス) に接続し、このサービスで Active Directory やメールボックス サーバーと通信します。ディレクトリ情報については、Outlook でクライアント アクセス サーバーの Name Service Provider Interface (NSPI) エンドポイントに接続し、NSPI によって Active Directory ドライバー経由で Active Directory と通信します。NSPI エンドポイントは、Exchange Server 2007 でおなじみの DSProxy コンポーネントの後継機能です。

このサービスが、Exchange Server 2007 のメールボックスに接続する Outlook Anywhere (RPC over HTTP) クライアントと異なるのは、Outlook Anywhere クライアントがクライアント アクセス サーバーの RPC プロキシ コンポーネントにリンクしている点です。また、Outlook Anywhere クライアントは RPC を介した MAPI 接続を使用して、直接メールボックス サーバーおよび Active Directory の NSPI エンドポイントと通信します。

RPC Client Access Service (RPC クライアント アクセス サービス) にはいくつかのメリットがあります。まず、MAPI とディレクトリ アクセスの接続が中間層のクライアント アクセス サーバーの役割に移動したので、Exchange Server では、すべてのデータ アクセスが行われる単一の共通パスが確保されます。このため、ビジネス ロジックをクライアントに適用する際の一貫性が向上するだけではなく、新しいデータベース可用性グループ (DAG) 機能を使用することで、切り替え時またはフェールオーバー時のクライアントのエクスペリエンスが大幅に強化されます (DAG 機能の詳細については、この記事の後半で説明します)。Outlook クライアントの接続が切断されるのは、30 秒ほどです。一方、Exchange Server 2007 のクラスター連続レプリケーション (CCR) クラスターが展開された複雑な Active Directory トポロジでは、数分から 30 分にもわたって接続が切断されることがありました。

最後に、すべてのデータ アクセスで単一の共通パスが確保されることで、メールボックス サーバー 1 台あたりの同時接続数とメールボックス数が増加します。Exchange Server 2007 では、1 台のメールボックス サーバーで処理できる接続数は 64,000 でした。これは、Exchange Server 2010 の RPC コンテキスト ハンドルの制限値である 250,000 の約 25% です。Exchange Server 2010 では、クライアント アクセス サーバーへの依存度合いが高まるので、クライアントは、予定されたまたは予定外のダウンタイムが発生したときには、あるクライアント アクセス サーバーから別のクライアント アクセス サーバーに迅速に再接続する必要があります。ここで役立つのが Exchange Server 2010 の新機能、クライアント アクセス アレイです。名前が示すとおり、これはクライアント アクセス サーバーのアレイです。具体的に説明すると、このアレイは、アレイが作成された Active Directory サイト内のすべてのクライアント アクセス サーバーで構成されています。Outlook クライアントでは、クライアント アクセス サーバーの完全修飾ドメイン名 (FQDN) に接続するのではなく、アレイに格納された FQDN (outlook.contoso.com など) に接続します。このため、RPC を介した MAPI 経由で接続する Outlook クライアントでは、クライアント アクセス サーバーへの常時接続が確立されます。アレイは、Active Directory サイトのメールボックス サーバー データベースに関する属性としても存在しています。この属性により、ユーザーが接続するメールボックス サーバーとデータベースがアレイで認識されます。新しい DAG 機能を使用してメールボックス データベースを保護しているときに、別の Active Directory サイトにある各データベースのコピーがアクティブなデータベースになると、クライアント アクセス サーバーでは RPC 経由で、データベース コピーが格納されているメールボックス サーバーと直接通信します。この詳細は把握しておく必要がある重要な情報です。

メールボックス サーバーの役割がサーバーにインストールされておらず、かつ DAG で保護されていない場合は、Windows ネットワーク負荷分散 (WNLB) とクライアント アクセス アレイを組み合わせて使用できます。もちろん、クライアント アクセス アレイと外部のハードウェア負荷分散装置を組み合わせて使用することもできます。ただし、アレイは Outlook RPC クライアントにしか対応していないので、Outlook Web Access、自動検出、Exchange ActiveSync、可用性サービスなどのサービスには、従来の WNLB や外部の負荷分散装置を使用します。

ストレージの最適化

64 アーキテクチャが採用され 1 秒あたりの I/O が削減 (最大 70%) されたことで、Exchange Server 2007 では、それまでのバージョンよりもはるかに効率的なストレージ環境が実現されました。マイクロソフトは、Exchange Server 2010 では、ストレージの最適化に関する作業のうち、低コストなストレージを利用しながらも大規模 (10 GB を超える) で高速なメールボックスを提供することに注力しました。

Extensible Storage Engine (ESE) の変更により、Exchange Server 2010 では、デスクトップ用の SATA ディスク (別名、ニアライン ディスク) など低パフォーマンスのディスクを使用できるようになりました。もちろん、これは皆さんのワークステーションのディスクとして使用している 7200 RPM の SATA ディスクのことです。可用性を高めるために DAG 機能を使用していて、データベースのコピーを 3 つ以上保持している場合は、たとえば、1 台の 7200 RPM ディスクにデータベースのコピー 1 つとそれに関連付けられたログ ストリームを格納することさえできます。つまり、RAID 構成の小容量で高速なディスクを使用する必要がなくなり、JBOD 構成の大容量で低速なディスクにデータベースを格納できるようになります。

マイクロソフトでは、主に既存のバージョンのストア スキーマを大幅に変更することで、ストレージのパフォーマンスをこのように大きく向上しました。基本的に、Exchange Server 2010 の開発チームは、多数のランダムで小規模な I/O を少数の順次アクセスされる大規模な I/O にすることを目標としていました。ランダムな I/O から順次 I/O に移行するには、ストア テーブルのアーキテクチャを劇的に変更する必要がありました。

Exchange Server 2007 以前では、各データベースには、メールボックスのテーブル (データベース内の全メールボックスを格納)、フォルダーのテーブル (データベース内の全メールボックスのメールボックス フォルダーを格納)、メッセージ テーブル (メッセージを格納)、添付ファイル テーブル (データベース内の全メールボックスの添付ファイルを格納)、およびメッセージ/フォルダー テーブル (データベース内の全メールボックスのフォルダー ビュー) がありました。このアーキテクチャは Exchange Server 4.0 からたいして変更されておらず、データベースにランダムな I/O を何度も実行する必要がありました。このアーキテクチャには、メッセージが 1 件ずつしか保持されない単一インスタンス ストレージ (SIS) が実現されるというメリットがありました。比較的容量の少ないディスクが当たり前だった当時、このアーキテクチャは、非常に重宝されていました。しかし、500 GB の SAS ディスクや 2 TB の SATA ディスクを自由に使用できるようになった現在、このアーキテクチャは意味がなくなりました。

Exchange Server 2010 では、メールボックスのすべてのデータが、データベース内の近接したテーブルに格納されるようになりました。事実、各メールボックス専用のフォルダー、メッセージ ヘッダー、本文、およびビュー用のテーブルがあります。そのため、SIS は、Exchange Server データベースから、その姿を消しました。Exchange Server で SIS が廃止された結果、データベースの大きさが約 20% 増加しました。この問題を解決するため、Exchange Server の開発チームはデータベース (具体的には、メッセージ ヘッダー、およびテキストや HTML 本文) を圧縮しました。各メールボックスに専用のテーブルが用意されているので、データベースに対する I/O の大半は順次実行されます。

他には、次のような興味深い変更が行われました。たとえば、データベース領域が連続して割り当てられ、データベースの連続性が長期間維持され、データベースのページ サイズが 8 KB から 32 KB に増加し、非同期的な読み取り機能が強化されました。また、Exchange Server 製品グループは、チェックポイントの深さを可用性の高い構成に適した 100 MB に変更し、キャッシュの圧縮とデータベース キャッシュの優先度を使用したことで、キャッシュの有効性を大きく向上しました。

Exchange Server 2010 で加えられた変更により、Exchange Server 2007 に比べて I/O を最大 70% 削減できると考えられます。これは、私が ESE の最適化と呼んでいるものです。

Exchange Server の連続レプリケーションの進化

Exchange Server 2007 以前のバージョンでは、非常に限られた高可用性機能と障害回復機能しか提供されていませんでした。IT マネージャーはハードウェア レベルの冗長性を実現するために Microsoft Cluster Server を使用できましたが、ストレージ サブシステムが単一障害点となっていました。ストレージ レベルの冗長性を実現するには、組織ではサードパーティ製のレプリケーション製品を購入する必要がありました。

Exchange Server 2007 では、大好評を博した CCR など、多数の高可用性機能と障害回復機能を提供することで、この状況を改善しました。このクラスター レプリケーション テクノロジでは、非同期レプリケーション テクノロジと Windows フェールオーバー クラスタリングを組み合わせて、ハードウェアとストレージの冗長性、および高可用性を実現し、単一障害点を解消しています。

マイクロソフトでは、Exchange Server 2007 SP1 でスタンバイ連続レプリケーション (SCR) 機能を導入することで、サイト全体を復元するニーズに応えました。SCR を使用すると、クラスター化メールボックス サーバーとクラスター化されていないメールボックス サーバーの間でログ ファイルを配布できます。SCR により、IT マネージャーはログ再生の遅延を最大で 7 日に指定できるので、データベースやストアに関するほとんどの問題を、問題が別のデータ センターの SCR ターゲットに影響を与える前に修正できます。

Exchange Server 2010 では、CCR と SCR がさらに強化され、この 2 つの機能が DAG (前述の連続的な可用性を実現する新機能) に統合されました。CCR と同様に、DAG でも、クラスター データベース、ファイル共有監視、ハートビート機能を中心に、限られた一部の Windows フェールオーバー クラスタリング コンポーネントに依存しています。DAG では、データベース、サーバー、サイトの各レベルで保護を提供するので、サイト レベルの高可用性ソリューションや障害回復ソリューションの展開が以前のバージョンの Exchange Server よりも大幅に容易になります。

DAG では、CCR や SCR と同様に非同期レプリケーションが使用されます。DAG の場合、メールボックス データベースのコピーを最大で 16 個作成できます。1 つのメールボックス データベースにつき、1 つのコピーがアクティブになります。このデータベースが使用できなくなると、Active Manager (アクティブ マネージャー) という DAG コンポーネントによって、他のコピーの 1 つが自動的にアクティブになります。Outlook クライアントがクライアント アクセス サーバーに (直接またはクライアント アクセス アレイ経由で) 接続するようになったので、DAG による他のデータベースへのフェールオーバーや切り替えをユーザーが意識することはほとんどありません。

保護されるようになった Exchange Server 2010 のデータベースは、組織レベルで配置されます (図 4 参照)。

 


図 4 DAG によって保護された組織レベルのデータベース

つまり、Exchange Server 2007 以前のバージョンにあったストレージ グループは、Exchange Server 2010 では廃止されました。ただし、Exchange Server 2010 でも、以前のバージョンと同様に原子性、一貫性、分離性、および持続性 (ACID) モデルが使用されているので、各データベースには、関連付けられた一連のログ ファイルがあります。

Exchange Server 2010 では、Exchange Server 2010 Enterprise Edition サーバーでホストできるデータベース数が 100 個に増加しました (Exchange Server 2007 では 50 個でした)。また、これも重要な情報ですが、DAG メンバーでは (Windows フェールオーバー クラスタリング機能の一部が依存しているため) Windows Server 2008 Enterprise が必要ですが、Exchange Server 2010 の Standard Edition と Enterprise Edition で DAG を使用できます。ただし、Standard Edition では、1 台のメールボックス サーバーでホストできるデータベースの数が 5 つに制限されることに注意してください。

DAG の展開と管理は、Exchange 管理コンソールと Exchange 管理シェルのどちらでも必要な手順をすべて実行できるので、CCR クラスターなどを展開および管理するよりもずっと簡単です。クラスタリングは Exchange Server に直接統合され、管理者が意識することはありません。そのため、Exchange Server の連続的な可用性ソリューションを管理する際にクラスタリングのスキルや個別の管理ツールを使用する必要がなくなります。複数サイトの DAG シナリオでも展開と管理が容易になり、CCR とは違って DAG メンバーのサーバーを異なる Active Directory サイトに配置できます。Exchange Server 2007 で複数サイトに CCR クラスターを配置するには、Active Directory サイトを複数の物理的に離れた場所に拡張する必要がありましたが、Exchange Server 2010 では、その必要がありません。

モビリティの機能強化

Exchange Server をアップグレードするたびに、マイクロソフトでは Exchange Server のモビリティ、具体的には Outlook Web App (OWA、旧称 Outlook Web Access) と Exchange ActiveSync を魅力的なものに変更してきました。Exchange Server 2010 も例外ではありません。

Outlook Web App
実際、マイクロソフトでは、OWA に関する記事を 1 本執筆できるほど多くの変更を OWA に加えました。次にいくつか例を示します。

  • プレゼンスが OWA に組み込まれました (図 5 参照)。つまり、Office Communications Server ソリューションを使用して (サードパーティ製のソリューションを統合することもできます)、自分のプレゼンス状態を表示して変更できるだけでなく、他のユーザーのプレゼンスを表示することもできます。ユーザーは OWA のインターフェイス内から IM を使用して通信することもできます。また、OWA では、各自の Office Communicator 連絡先リストを管理できます (リストは左のウィンドウに表示されます)。
  • Premium におけるブラウザーのサポートが、Mozilla Firefox 3 以降、および Safari 3 以降に拡大され、もちろん Internet Explorer (バージョン 7 以降) もサポートされます。
  • ユーザーはショート メッセージ サービス (SMS) メッセージを OWA (および Outlook 2010) で直接送受信できるので、モバイル デバイスでメッセージを入力する必要はありません。OWA では、モバイル デバイス経由で SMS を送信し、返信はモバイル デバイスで受信します。SMS メッセージをユーザーのメールボックスと同期して、一元的に保存およびバックアップすることもできます。
  • Exchange Server 2010 では、OWA (加えて Outlook 2010、および新バージョンの Outlook Mobile がインストールされた Windows Mobile) で新しいテーマ ビューが導入されました。テーマ ビューは、ユーザーの受信トレイで情報過多が発生するのを抑えることを目的としています。この機能により、テーマ スレッドのすべてのメッセージが簡潔で論理的なビューにまとめて表示され、ユーザーが未読メッセージをすばやく特定して、スレッド内で行われた一連の返信内容を理解できるようになります。テーマ ビューでは、メッセージが受信トレイから他のフォルダーに移動されていてもビュー内にメッセージが保持されます。ユーザーは、個々のメッセージではなく、テーマ全体を管理、無視、移動、および削除できます。
  • 以前のバージョンの OWA における [オプション] ページは、Exchange Control Panel (Exchange コントロール パネル) に置き換えられました (図 6 参照)。このコントロール パネルでは、ユーザーは従来からある OWA の設定を管理できるだけでなく、自分が送信したメッセージの追跡、必要な RBAC アクセス許可による配布の作成とモデレートなどを実行できます。また、ユーザーは名前、役職、部署、電話番号など個人に関する Active Directory 情報を更新できるようになりました。

図 5 OWA 2010 のユーザー インターフェイス

 


図 6 OWA 2010 の Exchange Control Panel (Exchange コントロール パネル)

Exchange ActiveSync
Exchange ActiveSync は、モバイル デバイスとメールボックスの同期方法を指定する事実上の標準と考えられています。Exchange Server 2010 では、ActiveSync ベースのクライアントにいくつかの魅力的な新機能が導入されました。

  • Exchange Server の管理者は、デバイスを種類やユーザーごとに承認したり、サポートされていない電話をブロックしたり、不明な電話を検疫できます。ブロックされた電話はメールボックスと同期できませんが、検疫された電話は管理者の承認によって同期できる場合があります。ユーザーは、Windows Mobile 6.5 付属の新バージョンの Outlook Mobile を使用して、空き時間情報を確認できます。連絡先のプロパティ ページを開くと、OWA 2007 と同様のスケジュールが表示されます。スケジュールは色分けすることもできます。
  • Exchange Server 2010 では、キャッシュがユーザーのメールボックスに一元的に保存されるようになったので、Windows Mobile デバイスのニックネーム キャッシュもサポートされます。
  • 優れた変更点としては、Windows Mobile 6.1 以降を実行している Windows Mobile に、新しい Outlook Mobile クライアント (Windows Mobile 6.5 に付属のクライアント) を .CAB ファイル形式でダウンロードできるようになりました。ユーザーが初めて Windows Mobile 6.1 デバイスとメールボックスを同期すると、新しいバージョンの Outlook Mobile へのリンクが記載された電子メール メッセージを受信します。このため、ユーザーは、新しい Windows Mobile 6.5 デバイスを購入しなくても、Exchange Server 2010 で導入された Exchange Server と Outlook Mobile の新機能を使用できます。

ユニファイド メッセージング

アーキテクチャは同じですが、Exchange Server 2010 では、ユニファイド メッセージングが改善および強化されています。このような強化点には、voicemail preview (ボイスメール プレビュー)、protected voicemail (ボイスメールの保護)、Message Waiting Indicator 、呼び出し応答ルール、他の言語パックのサポートなどがあります。

  • Voicemail Preview (ボイスメール プレビュー) を使用すると、ユーザーは Outlook と OWA で音声をテキストに直接変換できます。この機能により、多くのユーザーがわずらわしいと感じていた、従来のボイスメール メッセージを聞く必要がなくなり、電子メール クライアントでボイスメールをテキスト メッセージとして読むことができます。Outlook 2010 を使用すると、ボイス メッセージのテキストから作業を開始できる (つまり、名前、連絡先、および電話番号が認識されてクリックできる) ようにもなります。この機能は、Windows Mobile デバイスを使用している場合にも使用できます。また、Exchange Server 2010 のリリース時には、米国英語、カナダ英語、フランス語、ポルトガル語、イタリア語、およびポーランド語がサポートされます。来年の Exchange Server 2010 SP1 のリリース時には、他の言語のサポートが追加される予定です。
  • Protected Voicemail (ボイスメールの保護) では、Active Directory Rights Management サービスを使用してボイスメールが保護されます。たとえば、ユーザーはボイスメールの秘密度を親展に設定して、他の受信者への転送を禁止できます。この設定は、ユーザが指定できるものですが、管理ポリシーを使用して制御することもできます。
  • Message Waiting Indicator では、電話でユーザーに新着または未読ボイスメールがあるかどうかと、ある場合はその件数を通知します。この機能を使用すると、ユーザーは Voicemail Preview (ボイスメール プレビュー) を SMS メッセージとして受信することもできます。
  • Exchange Server 2010 の新機能の 1 つである呼び出し応答ルールは、従来の受信トレイの電子メール メッセージ ルールと同様に機能しますが、ユーザーの着信呼び出しにも適用されます。ユーザーは、着信呼び出しのフロー制御メニューを含む個人用自動応答のようなものを作成できます。たとえば、ユーザーは、時刻、呼び出し ID、ユーザー個人のスケジュールなどの条件に基づいて、通話への対応に関するルールを設定できます。また、呼び出し応答ルールを使用すると、ユーザーは独自の着信呼び出し用のメニューを作成できます。
  • Exchange Server 2010 RTM 版では 16 言語の言語パックがサポートされていますが、近日中にさらに 10 言語がサポートされる予定です。

アーカイブと保持

近年、ビジネスに関する記録を効率的に保存する機能はますます重要になっています。ほとんどの企業では、電子メールは法的証拠開示やその他の法令遵守に関する調査の主な情報源となっているので、特に電子メールを効率的に保存する機能が重要視されています。

Exchange Server 2007 でメッセージング レコード管理 (MRM)、トランスポート ルール、ジャーナル ルールなど保護や法令順守に関連する機能がいくつか追加されましたが、法令順守を目的とする電子メールの管理は長年企業の悩みの種でした。Exchange Server 2010 では、アイテム保持ポリシーという概念が導入されています。アイテム保持ポリシーは Exchange Server 2010 で提供される MRM 機能の一部であり、管理フォルダーの後継機能です。

以前のバージョンでは、メールボックス サイズの制限により、ユーザーが電子メール メッセージをローカルの .PST ファイルに移動してアーカイブする必要があり、管理者が法令順守管理を実施するのが難しくなっていましたが、Exchange Server 2010 では、メールボックス サイズの制限が解消されました。

.PST の問題を解決するために、Exchange Server 2010 には新しい個人用アーカイブ機能が用意されています。Exchange Server の管理者は、ユーザーのオンライン アーカイブ メールボックスを有効にして、オフラインの .PST ファイルを使用する必要性を排除できます。新しいオンライン アーカイブは Outlook 2010 と OWA 2010 で表示することが可能で、Outlook 2010 ではオンライン アーカイブに .PST コンテンツをドラッグ アンド ドロップする操作もサポートされています。また、Exchange Server の管理者は、自動的にメッセージ (1 年以上経過したメールなど) をオンライン アーカイブに移動するアイテム保持ポリシーを構成することもできます。

Exchange Server 2010 には、法務部門や法令順守部門に所属するユーザーがマルチメールボックス検索を実行したり保管時の改ざん防止をすぐに実行できる新しい機能も含まれています。

これらの新機能により、従来の Exchange Server の実装よりも簡単かつ柔軟に企業内の情報を制御できます。

組織の新しいフェデレーション モデル

Exchange Server 2007 以前では、同じ組織内または異なる組織内の複数の Exchange フォレスト間におけるフェデレーションはかなり不便で、場合によっては複雑な作業でした。Exchange 2000 Server または Exchange Server 2003 の組織間で空き時間情報を共有するには、まず、Forefront Identity Manager (FIM: 旧称 Microsoft Identity Integration Server および ILM) に付属する GALSync 管理エージェントを使用して、すべての必要なメール ユーザーを一方の組織からもう一方の組織に連絡先オブジェクトとしてレプリケートする必要がありました。その後は、Inter-Organization Replication (IOREPL: 組織間のレプリケーション) などのツールを使用して、パブリック フォルダー経由で空き時間情報をレプリケートする必要がありました。Exchange Server 2007 では、問題が多少改善され、新しい可用性サービスを使用して、Exchange Server 2007 の組織間で空き時間情報を共有できるようになりました。具体的に言うと、Add-AvailabilityAddressSpace コマンドレットを使用して、組織間の空き時間の共有を設定していました。ただし、残念ながら、関係する組織間に信頼関係が確立されていない場合、フォレスト間での空き時間情報の共有は制限されていました。

Exchange Server 2010 に用意されている新しいフェデレーション機能を使用すると、フォレスト間で空き時間、ユーザーの予定表、および連絡先を共有できます。ただし、Exchange Server 2010 のフェデレーション機能では、関係するすべての組織に Exchange Server 2010 が展開されている必要があることに注意してください。ただし、組織のすべてのサーバーで Exchange Server 2010 を使用する必要はありません。Exchange Server 2007 SP2 で下位レベルのプロキシが強化されたので、少なくとも 1 台の Exchange Server 2010 クライアント アクセス サーバーが展開された Exchange Server 2010 と Exchange Server 2007 SP2 を使用する組織間では、新しいフェデレーション機能を使用できます。

Exchange Server 2010 のフェデレーション機能では、Microsoft Federation Gateway (MFG) と呼ばれる新しい Windows Live ベースのサービスを使用します。MFG はクラウドにあり、基本的に、データを共有する Exchange Server 2010 組織間の信頼の仲介として機能します (図 7 参照)。ただし、マイクロソフトのゲートウェイを使用して Exchange Server 2010 の組織間でフェデレーション信頼を確立しても、関係するいずれの Exchange Server 組織のデータがマイクロソフトと共有されることはありません。組織では、ドメインに関する情報を公開してドメインからデータへのアクセスを有効にする際のセキュリティを確保するために MFG を使用します。

 


図 7 Exchange Server 2010 管理コンソールの New Federation Trust Wizard (新しいフェデレーション信頼ウィザード)

新しいフェデレーションの機能には、関係する組織間の信頼関係とデータ レプリケーションのどちらも不要です。Outlook 2010 または OWA 2010 を使用して、他の組織に所属するユーザーの空き時間情報を確認するのに必要な作業は、そのユーザーの電子メール アドレスをスケジュール アシスタントに入力するだけです (Outlook 2007 を使用している場合は、別の組織に所属するメール ユーザーをレプリケートして、ローカルのグローバル アドレス一覧に表示する必要があります)。予定表と連絡先の共有機能のどちらを使用する場合も、OWA 2010 または Outlook 2010 が必要です。

共有ポリシーを使用して共有するデータ、および共有するデータのレベルを明確に設定できます。また、組織の共有ポリシーを使用して共有ポリシーを作成することもできます。たとえば、次のように、ユーザーが共有できる情報の量と共有するドメインを指定できます (図 8 参照)。

 


図 8 Exchange Server 2010 管理コンソールの New Organizational Relationship Wizard (新しい組織間の関係ウィザード)

その他の優れた機能

このセクションでは、Exchange Server 2010 で提供されるその他の優れた機能を簡単に紹介します。

オンラインでのメールボックスの移動: Exchange Server 2010 では、メールボックスの移動ウィザードの代わりに Local Move Request Wizard (ローカルでの移動要求ウィザード) と Remote Move Request Wizard (リモートでの移動要求ウィザード) が導入され、いくつものメリットを得られます。たとえば、移動するメールボックスが移動中にオフラインにならないので、管理者は勤務時間中にメールボックスを移動できるようになりました。実際、メールボックスの移動中にも、ユーザーは電子メールの送受信、GAL へのアクセス、会議のスケジュール設定などを実行できます。また、Exchange 管理コンソールを使用して、Exchange フォレスト間でメールボックスを移動できます。

メール ヒント: メール ヒントを使用すると、Outlook 2010 と OWA 2010 のいずれかでメールを作成する際に、電子メールの送信者に役立つメッセージを表示できます。既定のメール ヒントが用意されていますが、独自のヒントを作成することもできます。既定のメール ヒントには、無効な組織内の受信者 (宛先または CC フィールドに入力したユーザーまたはグループが Active Directory に存在しない場合)、いっぱいになっているメールボックス (受信者のメールボックスがいっぱいになっている)、自動返信 (不在などの自動返信を表示)、制限されている受信者 (ポリシーに基づく)、大きすぎるメッセージ (送信サイズ、受信サイズ、メッセージ サイズ、または要求の長さの設定を超えるメッセージ)、大規模な宛先 (メンバー数が 25 名を超えるグループにメッセージを送信する場合) などがあります。

トランスポート回復力: シャドウ冗長とも呼ばれるこの新機能は、受信側ハブ トランスポート サーバーでメッセージの配信が確認されるまで、メッセージが送信側ハブ トランスポート サーバーから削除されないようにします。Exchange Server 2007 では、メッセージ キュー データベースが失われると、データベース内のメッセージが失われていました。Exchange Server 2010 には冗長性を確保する機能があるので、このような問題が発生することはありません。そのため、障害が発生したハブ トランスポート サーバーを運用環境から削除するだけで、キューを空にせずに簡単に交換できます。また、ストレージ ハードウェアの冗長性を確保する (コストに直接影響を与える手法を使用する) 必要もなくなります。

動的な署名: HTML、特定のフォント、会社のロゴ (アニメーション GIF も含む) などが含まれた個人や会社の署名または免責事項を (トランスポート ルールを使用して) 配置できます。また、署名や免責事項の作成時には Active Directory のユーザーに関する DisplayName、FirstName、LastName、Department、および Company の各値を使用できるようになりました。

配布グループのモデレート: メッセージをグループ メンバーに送信する前にモデレーターが同意する必要がある、モデレートされた配布グループを構成できるようになりました。また、新しい OWA 2010 の Exchange Control Panel (ECP: Exchange コントロール パネル) でグループのメンバーシップを管理できます。ユーザーが ECP で独自の配布グループを作成できるよう、ユーザーにアクセス許可を付与することもできます。

Exchange 管理コンソールでの一括受信者管理: 一括受信者管理を Exchange 管理コンソールで実行できるようになりました。たとえば、複数のユーザーのメールボックスを一括で移動、削除、無効化、および有効化できます。また、同じ種類の受信者を選択していれば、受信者のプロパティを編集することもできます。

メールの送信: Outlook が Exchange 管理ツールと同じコンピューターにインストールされている場合は、ユーザーのメールボックス、メール連絡先、メール ユーザー、または配布グループにメールを送信できます。

フォルダーのアクセス許可の管理: Exchange Server 2010 では、新しい Add-MailboxFolderPermission コマンドレット、Get-MailboxFolderPermission コマンドレット、および Remove-MailboxFolderPermission コマンドレットを使用して Outlook フォルダーのアクセス許可を管理できます。

Exchange Server 2010 では、多数のすばらしい新機能が導入され、既存のバージョンの機能が強化されています。Exchange Server 2010 を使用すれば、この製品があらゆる規模の企業に適した包括的で柔軟な統合メッセージング ソリューションだと実感していだだけると思います。

関連コンテンツ

Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 15 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。Timengo Consulting (デンマークを拠点とするマイクロソフト認定ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corporation (ドキュメント管理とローカライズ サービス専門とする米国の企業) でテクニカル ライターを務めています。連絡先は exqa@microsoft.com (英語のみ) です。