• [アーティクル]

事後分析Exchange 5.5 からの移行

Whitney Roberts

プロジェクト

ケンタッキー州教育省では、既存の Microsoft® Exchange Server 5.5 実装から Exchange Server 2003 に移行する必要がありました。このシステムは、1 年度に約 600,000 名の教職員と生徒をサポートします。

担当者

プロジェクトは、KiZAN Technologies のコンサルタントによる支援を受け、ケンタッキー州教育省の教育テクノロジ局 (OET) が推進しました。既存の Exchange 5.5 実装の管理は OET 局員が監督していました。Exchange サーバーの日常的な運営は、各学区の職員が担当していました。

課題

教育省は、ケンタッキー州内の全 178 学区に、技術的な指示を出します。各学区は WAN で相互に接続されていましたが、学区ごと独自に管理している Exchange 5.5 サーバーをホストしており、それらのサーバーを個別にアップグレードする必要がありました。このアップグレードの成果として、Outlook® 2003 キャッシュ モード クライアントのサポート、Outlook Web Access (OWA) のエクスペリエンスの向上、電子メール アドレス体系の標準化などが期待されました。

新しい電子メール サーバー クライアント インフラストラクチャを展開する以外に、多くの学区が生徒への電子メール サポートを導入しました。州と連邦双方の政策により、生徒の情報を保護し、各学区の外部には非公開にする必要がありました。

計画

Active Directory® コネクタ (ADC) を使用できなかったので、新しい Exchange 組織を作成して、その組織に移行しました。電子メール アドレスの標準化とは、各学区を識別する新しいサブドメインと、400 個を超える新しい受信者ポリシーの両方を作成することでした。生徒のアドレスを保護するため、グローバル アドレス一覧 (GAL) と学区別のカスタム アドレス一覧から構成されるシステムを構築する必要がありました。

実際の移行には、ユーザーが適切なアドレス一覧に表示されるようにするため、新しいハードウェアのステージング、学区のメンバシップとユーザーの種類に基づくメールボックスの作成と構成、および学区のメンバシップとユーザーの種類に基づく拡張属性の設定が必要でした。

構成を誤っているアカウント属性やグループ メンバシップを検出して訂正し、新しいメールボックスが公開要件を満たして適切に提供されるようにするため、Visual Basic® ベースのアプリケーションを作成しました。このアプリケーションを全 178 学区に展開し、学区のサーバーから定期的に実行します。

背景

外見上、この移行は努力が必要で、技術的に困難な作業だとは思われないかもしれません。しかし、私が思い起こす限り、ビジネス要件のルールと、このプロジェクトのビジネス要件は驚きと発見の連続でした。

何年にもわたって、管理が分散して標準が乱立した結果、サポートの連携が取れなくなり、OET が主にその収拾に当たっていました。また、Exchange 5.5 実装が学区と教育省の要件を同時に満たすようにする責任が OET にはありました。これは、生徒の電子メールを利用している学区では、州と連邦のガイドラインに従い、生徒の情報を学区の外部に公開しないで保護することを意味します (ed.gov/policy/gen/guid/fpco/ferpa/index.html (英語) を参照してください)。

これらのガイドラインがあるために、Exchange 5.5 では GAL データを共有する他の学区や他の州機関に学区内の生徒の情報をレプリケートできませんでした。というのは、178 個の Exchange 5.5 サイトすべてで、生徒を非表示にし、一覧をレプリケートして、生徒の非表示を解除して、最後にアドレス一覧にインポートするエクスポート/インポートを手作業で行う必要があったからです。この方法を行えば、他学区には職員のデータしか公開されず、情報を持つ学区では自学区のすべてのデータと他学区の職員のデータのみが公開されます。

既存のシステムの強みと弱みを踏まえて、メッセージ インフラストラクチャのアップグレードはいくつかの条件を満たす必要がありました。まず、ケンタッキー州教育省は、このシステム全体で使用する共通でわかりやすい SMTP 命名体系の標準化を目指しました。この体系では、教員と生徒に個別の SMTP アドレス空間を提供する必要がありました。

新しいシステムでは、メッセージ管理と可用性維持の責任から学区を解放するための、一括管理サービスを提供する必要がありました。これは、災害復旧、メール フロー、およびヘルプデスクの電話サポートの管理を一元化することを意味します。したがって新しいシステムには、任意のユーザーの地理的な場所や帰属する学区にとらわれず、すべての学区のユーザー構成を標準化するための一元的な方法が必要でした。

さらに、全学区で共通の統一された名前空間を使用して、モバイル デバイスから Web ベースで安全に電子メールにアクセスできるようにする必要がありました。

これらの要件の多くが既存の Exchange 5.5 システムに実装されていなかったこともあり、Exchange 2003 へのアップグレードは前途多難に見えました。

ソリューションの構成

上記のビジネス要件を満たすため、展開に当たり Exchange 固有のオプションを決定しました。

標準化が行われていないこと、および純粋な Exchange 5.5 環境だったことから、ADC は使用しませんでした。代わりに、新しい Exchange 組織を作成し、その組織に移行しました。

各学区で職員と生徒の電子メールを整理、標準化したところ、400 個を超える新しい受信者ポリシーができあがりました。各学区を一意に識別するサブドメインを使用し、さらに学区内で生徒を識別できることが要件に盛り込まれました。たとえば、Shelby 郡の場合、プライマリ サブドメインが shelby.kyschools.us になります。各学区の生徒には、stu. というサブドメインを与えました。Shelby 郡の生徒のアドレスは stu.shelby.kyschools.us となります。

生徒のアドレスは所属する学区内のみで公開して、職員のアドレスは他学区にも公開するという制限もありました。そのため、図 1 および図 2 で示すような、GAL とカスタム アドレス一覧から構成される込み入ったシステムを構築する必要がありました。Exchange 2003 に移行するメリットは、アクセス許可を使用してアドレス一覧をセキュリティで保護できること、およびグループ メンバシップを使用して各アドレス一覧へのアクセスを制御できることです。この機能を活用し、学区レベルのセキュリティ グループを 2 つ作成しました (職員用と生徒用)。続けて、それぞれのグループに対応する学区の職員と生徒の GAL とアドレス一覧をセキュリティで保護し、特定の学区のユーザー アカウントのみが特定のアドレス一覧にアクセスできるようにしました。既定の GAL とアドレス一覧を削除し、各アドレス一覧のアクセス制御リスト (ACL) から Everyone グループおよび Authenticated Users グループを除外したことで、特定の学区の特定の種類のユーザーが参照できるアドレス一覧を事前に選択できるようになりました。

図 1 役割に基づくカスタム アドレス一覧

図 1** 役割に基づくカスタム アドレス一覧 **(画像を拡大するには、ここをクリックします)

しかし、アクセス許可で解決できたのは、公開/非公開の問題の一部のみでした。どのアドレス一覧にだれを公開するかを制御する方法を考案する必要がありました。基本となるライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを作成し、そのクエリで職員と生徒の公開/非公開をクエリできるようにしました。次に、アドレス一覧および GAL ごとにこのクエリを少しずつカスタマイズしました。たとえば、Shelby の職員の GAL に使用する LDAP クエリは、Shelby の職員と生徒、および州内のすべての他学区の全職員のみを表示します (他学区の生徒は表示されません)。Shelby の生徒の GAL には、Shelby の職員と生徒のみが公開され、州内の他学区の職員や生徒は公開されません。このクエリを、組織内のすべての学区について繰り返しました。図 3 に、この複雑な移行で使用した LDAP クエリの例を示します。

Figure 3 アドレス一覧の LDAP クエリ

職員用 GAL の LDAP クエリ

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

学区のアドレス一覧の LDAP クエリ

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))

学区の生徒のアドレス一覧の LDAP クエリ

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))

学区の職員のオフライン アドレス一覧の LDAP クエリ

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

図 2 職員と生徒を分離したグローバル アドレス一覧

図 2** 職員と生徒を分離したグローバル アドレス一覧 **(画像を拡大するには、ここをクリックします)

Exchange ユーザー プロパティ extensionAttribute14 (カスタム属性 14) および extensionAttribute15 (カスタム属性 15) のカスタム値は、LDAP クエリの背後にある識別メカニズムです。州内のすべての職員と生徒は、ユーザーの種類を示す特定の値を extensionAttribute14 で、学区の帰属を示す一意の値を extensionAttribute15 で使用します。学区別の一意の値と、ユーザーの種類を示す共通の値を使用することで、各学区の各ユーザーに必要な情報が的確に公開されます。

このアドレス一覧は、非キャッシュ モードの Outlook または OWA を使用して電子メールにアクセスするユーザーに対して適切に機能しました (msExchQueryBaseDN 属性を使用して、各ユーザーが OWA で正しいアドレス一覧にアクセスできるようにしました)。しかし、キャッシュ モードで Outlook を実行しているユーザーに、別の問題が発生しました。カスタマイズした GAL は指定のオフライン アドレス帳 (OAB) として認識されないので、GAL と重複するアドレス一覧を別に作成する必要がありました。キャッシュ モードのユーザーのため、各学区のメールボックス ストアを適切な OAB アドレス一覧で構成しました。すべてを考慮すると、全 178 学区のさまざまな種類のユーザーに完全な機能を提供するには、1,500 個を超えるアドレス一覧が必要でした。

準拠の確認

配置する構造が適切に機能するには、新しく確立した標準に従うことが最も重要でした。組織内のすべての Exchange ユーザーに対して、高度な作業を行う必要がありました。各ユーザーが、すべての学区の Exchange サーバーで正しい場所に配置され、正しいアドレス一覧に公開される必要があるためです。

適切なアドレス一覧を開くためのアクセス許可はセキュリティ グループによって与えられるため、ユーザーは学区のドメイン内の適切なセキュリティ グループに属す必要がありました。また、学区と組織単位 (OU) のメンバシップに基づき、msExchQuerybaseDN 属性を正しく設定する必要がありました。ユーザーの種類はユーザーの OU で判断します。

次に、学区のメンバシップとユーザーの種類に基づき、適切なサーバーの適切なストアにユーザーのメールボックスを作成しました。その結果、Outlook キャッシュ モードを正しく機能させるため、サービス レベル、メールボックスのサイズ制限、およびオフライン アドレス帳のアドレス一覧に影響が及びました。ユーザーが適切なアドレス一覧に表示され、それ以外のアドレス一覧に表示されないようにするため、学区のメンバシップとユーザーの種類に基づいて拡張属性を設定しました。

最後に、アカウントの属性またはグループ メンバシップが、不適切な値に誤って構成 (または変更) された場合に自動修正するための方法が必要でした。ユーザーをある OU から学区ドメイン内の別の OU に移動すると、ユーザーの分類が変わることになるので、メールボックスの場所、GAL の選択、アドレス一覧の表示/非表示を更新する必要があります。

以上の作業を完遂し、Active Directory の整合性と正確性が保証されるプロビジョニング システムが必要でした。私たちは、学区の Exchange 2003 サーバーから定期的に実行する Visual Basic ベースのコンソール アプリケーションを作成しました。このアプリケーションは、ポリシーと標準に従っているかどうかをチェックすると共に、新しいオブジェクトの作成と、プロビジョニングを行います。全 178 学区にこのアプリケーションを展開しました。

当面の作業は、スクリプトを実行して短時間で信頼できる結果を得るには複雑すぎると感じていました。そこで、効率の良さ、エラーと例外の処理のサポートが構造化されていること、将来的に最小限の書き直しのみで内部コードを Microsoft Identity Integration Server (MIIS) 拡張コードに簡単に対応させられることから、Visual Basic ベースのアプリケーションが適切なソリューションだと判断しました。

新しい組織に移行する途中だったので、共存の方法を模索する必要がありました。新しい環境でサポートする既存の SMTP ドメインは 178 個を超えていました。生徒用の電子メール ドメインがある学区とそうでない学区があったためです。しかし、私たちは、学区を一度に 1 つずつ移行して、他の学区に影響を及ぼすことなく、既存のメッセージとアドレスを新しいシステムに移行する余裕がありました。ただし、Exchange 5.5 から Exchange 2003 に学区を移行するときに、電子メール フローを中断することは避ける必要がありました。つまり、Exchange 2003 Active Directory と既存の Exchange 5.5 ディレクトリを何かしらの方法で同期する必要がありました。マイクロソフトはケンタッキー州教育省による MIIS の使用を移行期間中のみに制限しました。そのため、移行の前、期間中、後に MIIS 経由で 2 つの Exchange 組織を同期するカスタム拡張コードを開発して使用しました。

新しい Exchange 組織への移行は、必然的に MAPI クライアント構成に影響します。移行の際に再構成が必要な MAPI ユーザー プロファイルが、学区レベルで数万件あるという事実に直面しました。マイクロソフトが Exchange プロファイル更新ツール (ExProfRe.exe) をリリースしていたので、それを使用して学区のプロファイルを移行しました。学区レベルのプロファイル移行を自動的に実行するため、あらかじめ読み込んだ値で ExProfRe.exe を実行するパッケージ インストーラを作成しました。このインストーラをグループ ポリシー経由で呼び出しました。組織間のプロファイル自動移行の成功率は、ほぼ 100% でした。

ハードウェアのアップグレード

新しい Exchange 2003 サーバーは、地理的に分散していた Exchange 5.5 サーバーの後継になるので、このソリューションは、Exchange 5.5 展開と同数のユーザーに加え、追加される生徒用アカウントの負荷をハードウェア面でサポートできる必要がありました。学区間のすべてのトラフィック (インターネットおよび内部ネットワーク) が専用の T1 回線 (学区によっては複数の T1 回線を持ちます) を流れるように WAN トポロジをデザインしたので、サーバーを学区内でローカルにホストする必要がありました。

予算、管理、設備の都合により、Exchange サーバーには記憶域ネットワーク (SAN) で接続したストレージがありません。すべてのストレージを内部ネットワーク経由か、または直接接続する必要がありました。ほとんどの学区にはサーバー ラックと集中冷房が整ったデータセンターの設備がないので、できる限り自己完結型のサーバーを構成する必要がありました。ほとんどの学区はユーザーが 5,000 名未満なので、サーバーを 1 台のみ展開しました。ユーザーが 5,000 名以上の学区では、高性能の (または複数の) サーバーを使用したり、ストレージを増設したりしました。また、生徒と職員のトラフィックを分離するため、独立したフロントエンド サーバーを設置する場合もありました。

ほとんどの学区で、最大 15,000 RPM の Ultra320 SCSI ドライブ、複数の RAID コントローラ、および 4GB の RAM を搭載したデュアルプロセッサ サーバーを展開しました。大規模な学区には、1 台以上のクワッドプロセッサ サーバーと、必要に応じて簡易フロントエンド サーバーを設置しました。展開前のベンチマークおよびパフォーマンスのテストでは、使用率と負荷に問題はありませんでした。ただし、各学区での使用度合いの違いにより、サーバー全体のパフォーマンスを実際に決まります。

実証テスト

運用環境は 178 個のドメインを含む Active Directory フォレストですが、実証試験 (POC) 環境は 13 個の学区ドメインと空のルート ドメインに規模を縮小しました。テスト ドメインは、すべて運用ドメインからエクスポートしたデータを使用しました。Exchange 5.5 の仮想サーバーを構築し、選抜した学区のデータベースのコピーで構成して、移行プロセスと計画環境からの構築をテストできるようにしました。POC テスト環境全体は、ベースラインを設け、固定し、必要に応じて展開し直せるように、仮想マシンで構成しました。

スクリプト (VBScript を使用)、Systems Management Server (SMS) インストーラ パッケージ、およびコンソール アプリケーションのさまざまな組み合わせを考案、コーディング、およびテストして最終的に承認しました。最後に、受信ポリシー、GAL、カスタム アドレス一覧、アクセス許可を含めた Exchange 2003 の最初のセットアップと構成を行うスクリプトを用意しました。さらに、管理者グループの構成、学区ドメインの構成 (セキュリティ グループの作成とアクセス許可の委任)、および展開後の移行のための構成もスクリプトで行います。

Exchange 2003 サーバーのステージングには、大きな課題がありました。全 178 ドメインで、移行の他の部分に悪影響を与えないようにして、すべての Exchange サーバーを正常にインストールする必要がありました。Exchange 2003 は Exchange 2000 と異なり、ドメインの最初の Exchange 2003 サーバーがインストールされるまでドメイン固有の Exchange Domain Servers グループが組織の ACL に追加されません (Exchange 2000 では、DomainPrep プロセスを実行すると追加されます)。必要なセキュリティ グループがすべて Active Directory の組織オブジェクトに列挙されるようにするため、あるドメインでインストールを行い、そのドメインから Active Directory レプリケーション ハブ サイトに Active Directory を手動でレプリケートして、次にインストールする学区にそのレプリケーションをプルする必要がありました。前の学区の Exchange Domain Servers グループが組織オブジェクトの ACL に追加されたことを確認しないと、次の学区を安全にインストールできませんでした。1 つのドメインでもこのプロセスの手順を誤ると、(最低でも) その学区を再インストールする必要がありました。再インストールを怠ると、組織オブジェクトの ACL に他のすべての学区が正しく列挙されないことが原因で、他の学区が学区間で通信できなくなります。

展開、構成、サーバーのステージング、および移行を全体的に何度もテストした後で、POC 環境でこのプロセスが有効に機能すると判断しました。

移行と肥大化の問題

プロジェクト チームが POC の手順と結果を承認して、移行の開始準備が整いました。OET は、プロセスと結果を直接把握できるように、最初は自分たちで移行を行いました。移行の際、すべてのサーバーは既にステージングを終え、初期環境の検証が済んでいました。すべてのフロントエンド プロトコル サーバーおよびメールボックス サーバーは正しく配置され、ユーザーによる運用に入る準備が整っていました。

移行計画は順調に実行されました。21 時間後、別のサーバーに内容を転送して OET の作業は終了し、Exchange 2003 が稼動しました。さいわい、Outlook プロファイルを Exchange 5.5 から Exchange 2003 に移行するときは、大きな問題が発生しませんでした。私たちは単純なロジックを基に、さまざまな構成で ExProfRe.exe を呼び出すバッチ ファイルのパッケージを作成しました。このバッチ ファイルと ExProfRe.exe を各学区のドメイン コントローラ (DC) の Netlogon 共有に配布しておき、グループ ポリシーを使用して移行の最後にすべてのクライアントにバッチを実行しました。OET でこの方法がうまく機能したので、私たちはプロセスを先に進める自信を持ちました。

この時点で、OET の展開に対する経験を基に、移行計画の再レビューと再承認を行いました。移行を進めるため、最初の運用サイトにする 6 個の学区を選定しました。各学区で移行を行う前に、Exchange 5.5 から学区のメールボックスについての最新情報を MIIS で読み取って、学区ドメインの対応ユーザーを更新します。組織間でのメールボックスのデータ移動には、Exchange 移行ウィザード (Mailmig.exe) を使用しました。メールボックスのデータを移動する間、MIIS が最初に Active Directory にエクスポートしたプロキシ アドレスが収集され更新されました。移行のときは、フロントエンドの SMTP サーバーのキューにメールが入り、移行、移行後のサーバー構成、およびユーザー テストが完了した後で解放されます。この段階で、その学区は ExProfRe.exe を使用して広範囲にクライアントを移行できる準備が整います。

RUS についての論争

Outlook クライアントが正常に機能するには、最終的にプロビジョニング ソリューションで属性値を設定する必要がありました。アカウントを設定する作業を完了するには受信者更新サービス (RUS) も必要ですが、RUS はプロビジョニングの完了後にのみ実行するべきです。そのため、学区の RUS インスタンス (全 178 個) のスケジュールを実行されないように設定して、プロビジョニングの完了後に RUS を起動するコードを使用しました。

ほとんどの学区はユーザーが 5,000 名未満で、1 日に発生する更新はユーザー数に比べわずかです。プロビジョニング システムが 1 日の実行の最後で再構築ではなく更新を行うことで、RUS は短時間で完了しました。しかし、ユーザーが 10,000 名を超える学区もあります。このような環境での更新は時間がかかりました。このように大きなドメインで RUS の再構築を完全に行うと、1 週間以上かかります。RUS は実行時にすべてのオブジェクトの種類を評価するので、大きなドメインでの再構築は負荷が高すぎます。

移行の戦略は考案できませんでした (Exchange 製品グループのメンバと協力して解決策を考案してみました) が、プロビジョニング コードを拡張して、通常なら RUS が行う動作の大部分をこのコードで行うようにしました。RUS が作業を完了するまで待つことなく、すぐにログインできるようにするため、最初のプロビジョニングのときに showInAddressBook 属性と proxyAddresses 属性に値を設定します。フロントエンドの Exchange 2003 プロトコル サーバーの 1 台で実行する手動のタスクも作成しました。これは、環境に誤って受信者ポリシーが適用された場合に、システムのすべての RUS のタスク一覧に列挙されないようにするため、LDIFDE でのインポートを定期的に行い RUS の gatewayProxy アドレスを消去するタスクです。

カテゴライザの問題

生徒のデータを学区外に出さないようにするため、生徒が学区外のユーザーやシステム外部のインターネット アドレスに電子メールを送信できないようにするコントロールを実装しました。コネクタと関連アイテムを複雑に組み合わせたシステムを構築するのではなく、Exchange 2003 のあまり知られていないある機能を実装し、学区からフロントエンド プロトコル サーバーのある中央ハブを結ぶ既存のルーティング グループ コネクタで、コネクタの制限を使用しました。各ドメインに、職員用と生徒用の 2 つのセキュリティ グループを作成し、これらのグループをコネクタの制限に追加しました。

レジストリでコネクタの制限をチェックするようにしたところ、パフォーマンスが低下する問題が見られました。メッセージが、同じサーバーの受信者宛てであっても、カテゴライザとローカルの配信キューに数時間スタックするのです。この問題は、移行する学区が増えるにつれ悪化しました。短期的な解決策としてコネクタの制限のチェックを無効にすると、メール配信のパフォーマンスが改善しました。調査を進めた結果、メッセージを送信するときに、カテゴライザが自身のドメインの 2 つのグループのメンバシップだけでなく、他の 177 個のドメインにあるその 2 つのグループのメンバシップをチェックしていたことがわかりました。このチェックは、サーバーに着信または送信されるすべてのメッセージに行われていました。

この後、マイクロソフトとサポート ケースを開きました。評価を終えて、マイクロソフトは現在、カテゴライザを単純なトポロジ モードで動作することで、問題を改善する修正プログラムを作成しています。この記事の公開時点で、修正プログラムに関する詳細は公開されていませんが、目標は、カテゴライザでルーティング トポロジについて仮定を行い、すべてのコネクタのグループ メンバシップをチェックしないようにする設定を実現することです。

得られた教訓

このプロジェクトから改めて学んだことがあるとすれば、ビジネス要件によってコンサルタントのすべての業務が決定されることです。ビジネス要件の妥当性とソリューションの複雑さをはかりにかけることが何度もありました。このコラムに書いた判断や選択は、今回の環境 (時間がなくてここで説明できなかった要因も含む)、リソース、およびビジネス要件に最も適合していると考えたものです。プロジェクトが異なれば、別の判断が下されるかもしれませんが、このコラムが皆さんの検討材料になればと思っています。今回のプロジェクトでは、Exchange 2003 と Active Directory を使用したことで、この複雑な移行のすべての要件を満たす柔軟性を得ることができました。ケンタッキー州教育省での展開の規模は相当でしたが、実際のソリューションはむしろ単純であり、Active Directory と Exchange 2003 のあまり活用されていないと思われる機能を使用して構築されています。

また、トラブルシューティングやリスクおよび問題の管理にスムーズに対処する方法を訓練する経験にも恵まれました。現地に赴いてのトラブルシューティングが適切な場合と、マイクロソフト製品サポート サービスの知識のあるスタッフに電話連絡する必要がある場合があります。

今後の展望

ケンタッキー州教育省の環境は独特です。展開を進める間、教育省の要件を満たすために Exchange のほぼすべての機能を使用またはカスタマイズしました。現在は、すべての環境全体の展開と移行が無事完了し、追加機能を実装する段階です。各学区が Windows Mobile® プラットフォームに関心を寄せていることが既にわかっています。モバイル デバイス導入の動きは今後も継続すると見られます。

サーバー統合により、大きな価値を得ることができます。ケンタッキー州教育省は、現在、Active Directory 環境の一部の仮想化を目指しています。さらに、Exchange 2007 のリリースを控え、メッセージ システムのアップグレードの要件を調べ始めました。

同省は、Live Communication Server、Live Meeting Server などでコラボレーションを提供する検討を進めています。Exchange サーバーと Active Directory サーバーを管理および監視するため、Microsoft Operations Manager 2005 も現在展開中です。

成果

この実装の良し悪しや普及の度合いは、ケンタッキー州の公立学校システムを利用するすべての子供に影響します。私自身の子供や、このプロジェクトで共に働いた仲間の子供も例外ではありません。ケンタッキー州教育省は、この実装を導入したことで、今までになく短時間に、安全で標準化されたテクノロジを採用しました。このようなプロジェクトの一員になれたことを誇りに思っています。

Whitney Roberts は KiZAN Technologies (www.kizan.com (英語)) のプリンシパル コンサルタントであり、Exchange 4.0 のリリース以来、Exchange の業務を行っています。

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