Microsoft での構造化された Active Directory スキーマ管理

Presentation on theme: "Microsoft での構造化された Active Directory スキーマ管理"— Presentation transcript:

1 Microsoft での構造化された Active Directory スキーマ管理
概要 カスタマ レディ。33 のスライドで構成されるこのプレゼンテーションでは、2005 年 10 月に公開された 30 ページのテクニカル ホワイト ペーパーを基に、Microsoft IT の Active Directory スキーマ変更管理プロセスについて説明します。Microsoft ではスキーマ変更が頻繁に行われます。スキーマ変更には、一貫性のある円滑な実装を成功させるための構造化されたワークフローが必要です。Microsoft IT が制度化した変更プロセスは、明確な標準、予測、およびタイムラインを設定します。同時に、リスクを軽減し、最高の結果を実現します。構造化されたワークフローによって、スキーマの変更が標準化されます。その結果、すべての関係者の責任を明確にし、プロセスの初期にスキーマ変更の問題を排除し、時宜を得た最高の結果が得られます。 はじめに Active Directory® ディレクトリ サービスは、グローバルな ID およびアクセス管理インフラストラクチャを提供します。また、Active Directory は、開発中のアプリケーションでディレクトリ機能が必要な場合にアプリケーション開発者が使用でき、また使用する必要のある一般的なディレクトリ機能と拡張性を備えています。Active Directory の機能を使用すると、ディレクトリ管理が集中化および簡略化されます。Active Directory により、開発コストが削減され、データの互換性も向上します。たとえば、Active Directory の認証および承認サービスを使用すると、アプリケーション内での相互運用性に関する 2 つの目標が実現されます。追加のセキュリティ データベースを作成する必要がなくなり、エンタープライズ セキュリティ管理が簡略化されます。 Active Directory 機能を使用してビジネス プロセスまたは新しいツールをサポートするために、アプリケーション開発者は Active Directory スキーマを拡張します。スキーマとは、ディレクトリ サービスでデータの格納に使用されるすべてのオブジェクトおよび属性を定義する Active Directory コンポーネントです。通常は、スキーマ管理者がスキーマ変更を個別に行うか、ソフトウェア インストール プロセスにより変更が自動化されます。Microsoft では、変更管理システムを規定して、最高のスキーマ変更結果を実現することをお勧めします。 このプレゼンテーションでは、Microsoft Information Technology (Microsoft IT) 部門が構造化ワークフローを通じて Active Directory スキーマ変更プロセスを管理するアプローチを示します。構造化ワークフローにより、各フォレストに展開される各変更のデザイン、実装、使用方法、所有権、およびセキュリティが適切であることが保証されます。Microsoft IT の経験によると、Microsoft Operations Framework (MOF) をベースとする堅牢で、慎重に計画された変更管理システムが、管理性の高いスキーマ基盤の構築につながります。MOF を使用して、Microsoft IT は、可否の判断、評価、テスト、ステージング、および実装のマイルストーンを含むプロセスを作成しました。スキーマ変更を慎重に計画およびステージングし、クライアントのやりとりと予測を管理することにより、Active Directory スキーマ変更プロセスを円滑に処理し、Active Directory に対するリスクを最小化します。一貫性のある予測可能なプロセスを提供することにより、関係者はビジネス目標の実現に集中できます。 構造化ワークフローを通じて各スキーマ変更の最高の結果を実現することに関心のある企業には、このプレゼンテーションが役立ちます。このプレゼンテーションは、Microsoft Windows® の機能、Active Directory、および ID 管理の考慮事項に精通している IT プロフェッショナル、アーキテクト、およびディレクトリ サービス プロフェッショナルを対象として記述されました。このプレゼンテーションでは、Microsoft IT のスキーマ変更管理ソリューションを詳細に説明しています。これには、ベスト プラクティス、推奨事項、および展開に関する考慮事項が含まれます。変更管理デザインの推奨事項、原理、および手法は、Microsoft 製品を使用しているほとんどのエンタープライズ規模の IT 環境に適用できます。ただし、エンタープライズ環境はそれぞれ固有であるため、採用する場合はこのプレゼンテーションを手順ガイドとして使用しないでください。各組織は、以下の情報を特定のニーズに適応させる必要があります。 公開日 : 2005 年 11 月 一貫性のある標準化された変更ワークフローを作成する

2 ソリューションの概要 状況 ソリューション 利点 Active Directory スキーマは頻繁に変更されます。 スキーマ変更管理プロセス
スキーマ変更を標準化することによりリスクを軽減します。 構造化ワークフローを作成します。 組織的な標準を適用します。 堅実な予測を行います。 必要な伝達を標準化します。 ソリューションの概要 状況 Microsoft では、Active Directory スキーマの変更が頻繁に行われます。 詳細な計画およびテストを行わずにスキーマ変更を実装すると、予期しない結果が生じることがあります。 このため、変更には、一貫性のある円滑なプロセスを成功させるための構造化されたワークフローが必要です。 ソリューション Microsoft は、一貫性のある構造化ワークフローを提供するスキーマ変更管理プロセスを規定しました。 このプロセスは、明確な標準、予測、およびタイムラインを設定します。 プロセスは、リスクを軽減し、最高のスキーマ変更結果を実現します。 利点 スキーマ変更を標準化することによりリスクを軽減します。 構造化ワークフローを作成します。 組織的な標準を適用します。 堅実な予測を行います。 必要な伝達を標準化します。

3 製品とテクノロジ Windows Server 2003 Active Directory MIIS 2003 SP1
SharePoint 2003 Exchange Server 2003 ターミナル サーバー 製品とテクノロジ Microsoft Windows Server™ 2003 Active Directory Microsoft Identity Integration Server (MIIS) 2003 Service Pack 1 (SP1) Microsoft SharePoint® 2003 Microsoft Exchange Server 2003 Windows Sever 2003 ターミナル サーバー

4 スキーマ変更の概要 Active Directory 機能が拡張されることがあります。
スキーマ変更が予想外の結果を引き起こさないようにします。 スキーマではデータを保存するためのオブジェクトと属性を定義します。 オブジェクト定義でデータの種類と構文を制御します。 スキーマ変更の概要 熟練した Windows アプリケーション開発者は、ディレクトリ機能を必要とするアプリケーションを作成する際に、既存の Active Directory 機能を使用または拡張します。これには、ID 管理、集中的な構成およびアクセス管理、または一般的なディレクトリ機能が含まれます。Active Directory 機能を拡張または使用することで、アプリケーションでは、既存のセキュリティ サブシステムに加えてグローバル ディレクトリ内の共有データを使用できます。これによりリソースの効率が最大化されるため、Microsoft では、Active Directory の外部に新しい ID データベースを作成する代わりに既存の Active Directory 機能を使用または拡張することをお勧めします。 注 : "スキーマの拡張" とはスキーマを変更または更新する処理をいいます。 Active Directory に影響する可能性があるため、スキーマ変更が予想外の結果を引き起こさないことを確認することが重要です。企業では、変更計画、テスト、およびクライアントの予測管理を通じてスキーマ変更を円滑に実行できます。 スキーマの基礎 スキーマとは、ディレクトリ サービスでデータの格納に使用されるすべてのオブジェクトおよび属性を定義する Active Directory コンポーネントです。ディレクトリ サービスは、オブジェクトを記憶単位として使用します。ディレクトリ サービスは、データを処理するたびに、スキーマに対して適切なオブジェクト定義をクエリします。スキーマ内のオブジェクト定義に基づいて、ディレクトリ サービスはオブジェクトを作成し、データを格納します。たとえば、管理者が新規ユーザー オブジェクトを作成すると、Active Directory はスキーマ定義を使用して既定のユーザー オブジェクトを作成および構成します。スキーマの物理的な構造は、ディレクトリ内の独自のスキーマ パーティションに格納されているオブジェクト定義から構成されます。フォレスト内のすべてのドメインが同じスキーマを共有します。 オブジェクト定義は、オブジェクトに格納できるデータの種類およびデータ構文を制御します。下位オブジェクトは、上位クラスの特性を継承します。この情報を使用して、スキーマはすべてのオブジェクトが標準定義に準拠していることを確認します。その結果、Active Directory は、データを生成するアプリケーションに関係なく、管理対象のデータを格納、取得、および検証できます。スキーマ内に既存のオブジェクト定義を持つデータのみをディレクトリに格納できます。新しい種類のデータをディレクトリに格納する必要がある場合は、最初にスキーマ管理者がスキーマ内に新しいデータ オブジェクト定義を作成する必要があります。

5 スキーマ変更の概要 承認されたユーザーのみがスキーマを変更できます。 管理者は特定の理由がある場合に限り、スキーマを変更します。
スキーマの拡張は、慎重な計画とテストが必要です。 一般に、スキーマ変更を元に戻すことはできません。 スキーマ変更の概要 (続き) スキーマ変更 通常、ユーザーはスキーマと毎日直接には対話しません。Active Directory は、スキーマを使用して、ディレクトリに格納されるオブジェクトを作成します。ユーザーは、スキーマではなくこれらのオブジェクトと対話します。管理者は、定義の追加または既存の定義の変更によりスキーマ変更を行う際に、スキーマと直接対話します。アクセス制御リスト (ACL) によってスキーマ オブジェクトが保護されるため、承認されたユーザーのみがスキーマを変更できます。 スキーマ拡張 既定のスキーマは、Active Directory フォレストで提供されているクラスと属性の基本セットです。スキーマ内の既存のクラスおよび属性定義が組織のニーズを満たしていない場合、組織はスキーマ オブジェクトを追加または変更してスキーマを拡張できます。熟練した開発者および管理者は、新規クラス、および既存のクラスの新規属性を定義して新しい種類の情報をディレクトリに格納することにより、スキーマを拡張できます。通常、スキーマ管理者がスキーマを変更する理由は次のとおりです。 Active Directory 機能を使用するパッケージ アプリケーション : Active Directory 機能を使用するアプリケーションをインストールすると、カスタマイズされたオブジェクト定義を追加して情報をディレクトリに格納することにより、スキーマが変更されることがあります。たとえば、Microsoft Office Live Communications Server 2003 は、新しいオブジェクト クラスと追加属性をスキーマに追加して、存在検知を処理します。 内部的な Active Directory 機能の使用 : Active Directory 機能を使用するカスタム アプリケーションのインストールでは、スキーマ変更が必要な場合があります。 スキーマ変更スコープ スキーマの拡張は、慎重な計画とテストを必要とする高度な操作です。スキーマは、フォレスト内の Active Directory の使用と操作両方の基盤です。したがって企業では、システムにより提供されているベース スキーマの拡張または変更について慎重に検討し、問題を回避する必要があります。スキーマ変更は、ディレクトリ データベースのインデックス作成、グローバル カタログ データの可用性、Active Directory データベースのサイズと整合性などの重要な設定に影響する場合があります。 一般に、スキーマ変更を元に戻すことはできません。変更を検討する場合は、考慮する必要のある 3 つの重要ポイントがあります。 スキーマの拡張はグローバルです。 スキーマ マスタは、スキーマに対する変更をフォレスト内のすべてのドメイン コントローラ (DC) にレプリケートします。 システムに関連するスキーマ クラスは変更できません。システム管理者は、Active Directory スキーマ内の既定のシステム クラスを変更できません。ただし、自身が追加したオプションのシステム クラスを変更することはできます。 スキーマ クラスと属性は削除できません。新規クラスまたは属性をスキーマに追加した後で、管理者はクラスまたは属性を無効なものとしてマークすることにより非アクティブにできます。管理者は、クラスまたは属性を完全には削除できませんが、一部の属性またはクラスのプロパティは作成後に変更できます。 クライアントのやりとりと予測の管理に加えてスキーマ変更の計画とステージングを慎重に行うことにより、管理者は、Active Directory に対するリスクを最小化して Active Directory スキーマ変更プロセスを円滑に処理できます。

6 スキーマ変更の概要 スキーマの拡張には、スキーマ変更管理プロセスが必要です。
プロセスでは、ワークフロー全体を通した詳細な指示を提供する必要があります。 Microsoft では、スキーマ変更が通常の企業よりも頻繁です。 Microsoft IT は、広範な経験に基づいて、変更管理を行います。 スキーマ変更の概要 (続き) スキーマ変更管理 スキーマの拡張は強力かつ簡単です。適切にデザインされた変更管理システムは、組織がスキーマ変更を一貫して予想どおりに適用するのに役立ちます。これにより、組織はビジネス目標または運用目標に集中できます。組織では、スキーマを拡張する前に正式なスキーマ変更管理プロセスを確立することが非常に重要です。 プロセス デザイン 適切にデザインされた変更管理プロセスにより、最高の結果を実現する標準ワークフローが提供されます。適切なプロセスがあると、責任と予測が明確になります。プロセスでは、ワークフロー全体に関する詳細な指示を提供する必要があります。その範囲は、初期変更要求の配信から、プロセスが正常に完了したことをすべての関係者に伝達する人物の決定までです。 Microsoft IT のプロセス Active Directory ディレクトリ サービスを Microsoft Windows 2000 Server の一部として展開して以来、Microsoft では、Active Directory と、Active Directory 機能を使用したソフトウェアの開発を支援してきました。Microsoft はソフトウェア開発会社であるため、Microsoft では、Active Directory のスキーマ変更が通常のエンタープライズ顧客サイトよりも頻繁に行われています。Microsoft で開発されたソフトウェアは、一般に Active Directory 機能を使用します。その結果、Microsoft IT 内部でのソフトウェアのインストールとテストには、多くの場合にスキーマ変更が伴います。さらに、Microsoft IT では開発プロセスの一環として独自のベータ ソフトウェアを実稼働環境で使用するため、各プログラムの複数のプレリリース中間バージョンをインストールする必要があり、そのたびにスキーマ更新が必要になる可能性があります。 Microsoft IT は過去 5 年間に少なくとも 25 回の固有のスキーマ変更を実行し、その大部分を複数のフォレストに展開しました。その間に、作成したワークフローは、時間の経過と共に標準化された変更プロセスへと進化しました。この広範な経験に基づいて、Microsoft IT は、ワークフローを Microsoft 内でのすべてのスキーマ変更の正式な変更管理システムに標準化しました。Microsoft IT のスキーマ変更管理プロセスは、スキーマ変更を標準化し、以下の主要なソフトウェアを最高の状態で発表する上で役立ちました。 Exchange Server 2003: Microsoft IT は、テストの目的で Exchange の 6 つのプレリリース中間バージョンをインストールし、毎回 4 ～ 6 の実稼働環境でスキーマを変更しました。この変更は、ネットワークを中断せずに行われました。 Data Protection Manager (DPM): Microsoft IT は、DPM のプレリリース バージョンを 4 つの実稼働環境にインストールしました。スキーマ変更により、ファイル サーバーの共有ディレクトリに保持されたエンド ユーザーのファイルを本人が復旧できる機能が実現されました。 Avaya Unified Messaging: Microsoft IT は、Avaya の拡張を 3 つの実稼働環境に問題なく展開しました。

7 Microsoft の Active Directory 環境
Microsoft の ID およびアクセス管理インフラストラクチャは不可欠なサービスを提供します。 複数のフォレストの集中管理がこのインフラストラクチャの特徴です。 Microsoft が全世界に配置する DC は 215 台です。 Microsoft IT は、1 時間おきにレプリケーションを行うフォレストを構成しました。 Microsoft の Active Directory 環境 Microsoft でのスキーマ変更プロセスを理解するには、Active Directory 環境、その環境でサポートされる ID およびアクセス管理インフラストラクチャ、および Active Directory をサポートするチームについて理解することが重要です。 インフラストラクチャの概要 Microsoft の ID およびアクセス管理インフラストラクチャは、他の大規模エンタープライズ組織の環境と同様です。このインフラストラクチャには、Microsoft コンピューティング環境に不可欠なサービスのコレクションが用意されています。Active Directory は、各フォレスト内の ID インフラストラクチャの基盤です。Active Directory は、リソースの可用性と安全性を保つための集中 ID 管理を提供します。インフラストラクチャは、Microsoft が開発したプレリリース ID 管理ソフトウェアの実証基盤として機能します。 複数フォレスト構成 複数のフォレストの集中管理が Microsoft ID インフラストラクチャの特徴です。Microsoft IT は、これらのフォレストのいくつかを完全に管理します。その他のフォレストは、各フォレストのテクノロジ チームと連携して管理します。各フォレストは、社内フォレストと一方向または双方向の信頼関係を共有します。Microsoft で使用されるアプリケーションの 70% は社内フォレストに存在します。これらのフォレスト内には 35 を超える ID ストアがあります。ID ストアには、Active Directory、SAP、Siebel、グループ メンバシップ マネージャ、アカウント マネージャ アプリケーション、およびその他のアソートメントが含まれます。Microsoft IT Identity Management (IdM) チームは、SP1 を適用した MIIS 2003 を使用して、複数の ID ストア間で ID データを同期します。 いくつかの理由から、Microsoft には複数のフォレストが必要です。Exchange のプレリリース バージョンなどの開発中のソフトウェア アプリケーションには、早期プレリリースの展開およびテスト中に社内フォレストへの干渉を防ぐために独自のフォレストが必要です。エクストラネットを通じて外部パートナーと作業する際には、セキュリティ上の理由からもフォレストが存在します。また、MSNBC ジョイント ベンチャに関連する法的要件により、MSNBC は独立したフォレストを保守します。最後に、Microsoft IT は、Microsoft MSN® 部門など、社内の事業部用のフォレストをいくつか作成します。 ネットワーク構成 Microsoft には、Microsoft IT が管理している 5 つのフォレスト内に 215 の DC が世界各地にあります。これには、16 個を超えるドメイン、138 個のフォレスト DC、および 30 個のエクストラネット DC が含まれます。1 日に 60,000 の固有のフォレスト ログオンを処理する 184 の Active Directory サイトがあり、63 のサイトには DC があります。社内フォレストには 9 つのドメインがあり、そのドメインのオブジェクトは合計 100 万個を超え、グローバル カタログ ファイルの平均サイズは 9.0 ギガバイト (GB) です。ネットワークは、平均で 1 秒あたり 1.5 メガバイト (MB)、最小で 1 秒あたり 256 キロバイト (KBps) の帯域幅を提供します。 レプリケーション トポロジ Microsoft IT は、エンドツーエンド レイテンシが最大 5 時間であるサイト間で 5 つのホップで 1 時間おきにレプリケーションを行うようにフォレストを構成しました。Microsoft IT は、世界中に 300 を超えるサイトを持つネットワーク トポロジに相当する複雑なサイト トポロジを保守します。すべてのスキーマ変更を含む管理変更の大半は、米国ワシントン州 Redmond で行われます。Redmond は、他のすべてのサイトへの最大レイテンシが 3 時間である中間地点です。

8 Microsoft の Active Directory 環境
Microsoft IT は、全世界の Microsoft の情報システムの実行と保守に関連するすべてのアクティビティを指導します。 Microsoft IT は、グローバルな運用の推進および Microsoft 組織全体への IT サービスの提供を行います。 Microsoft IT は Microsoft ソフトウェアのテストと展開を行います。 Microsoft の Active Directory 環境 (続き) スキーマ変更サポート環境 Microsoft IT は、全世界の Microsoft 情報システムの実行と保守に関連するすべてのアクティビティの指導を担当しています。Microsoft IT 組織内では、IdM チームおよび Infrastructure Engineering (IEng) チームが Active Directory を担当します。IdM チームは、フォレスト間 ID 管理、特に Active Directory スキーマ管理を担当します。IEng チームは、DC およびレプリケーションを管理します。 Microsoft IT 組織 Microsoft IT は、グローバルな運用の推進および Microsoft 組織全体への IT サービスの提供を担当しています。Microsoft IT は、全世界の情報システムの実行と保守に関連するすべてのアクティビティを指導します。企業およびマーケティング情報システムに加えて、テクノロジ インフラストラクチャを保守します。これには、実稼働システム、分散システム、およびその他の重要な社内システムが含まれます。Microsoft IT は、世界規模の優れたユーティリティおよびビジネス オペレーションを提供するために作業を行っています。この作業は、企業の戦略、プロセス、およびアーキテクチャのデザインと統合におけるリーダーシップを通じて行われます。 Microsoft IT は、サーバーおよびエンド ユーザー サポート、通信管理、ネットワーク運用、情報セキュリティなどの広範なサービスを提供します。この役割には、300,000 台を超える世界中のパーソナル コンピュータの接続管理が含まれます。Microsoft IT では、90 か国以上、400 以上の拠点で、63,000 人を超える人員と 35,000 人を超える請負業者およびベンダが、毎日 24 時間いつでも社内ネットワーク サービスおよびリソースにアクセスできるようにしています。 Microsoft の主な業務はソフトウェア デザインであるため、IT にはグローバル プロバイダの間では特有な第 2 の任務があります。Microsoft IT は会社のテクノロジを早期に採用し、SharePoint、Windows Server 2003、MIIS 2003、Exchange Server 2003 などの Microsoft 製品を顧客にリリースする前にテストおよび展開する必要があります。このプレリリース展開プロセスを、Microsoft では "eating our own dog food" (愛犬の餌を食べる)、または単純に "dogfooding" (ドッグフード) と呼んでいます。 Microsoft エンタープライズ環境でプレリリース製品を使用することにより、Microsoft IT は、製品の徹底的なフィールド テストを行い、そのビジネス価値を評価します。これは、最終製品構成を形作り、顧客の製品展開をガイドするベスト プラクティスを識別するのに役立ちます。ドッグフードの厳格なエンタープライズ テスト環境は、Microsoft に品質の高い製品をリリースする自信を与えます。プロセス中に得た教訓から、製品グループは製品デザインを改良し、最終バージョンに価値を付加できます。

9 Microsoft の Active Directory 環境
IdM チームは、Microsoft ID 管理インフラストラクチャ、すべてのユーザー アカウント、および Active Directory スキーマを管理します。 IEng チームは、中核のインフラストラクチャ サーバー (DC 含む) とデータ レプリケーション トポロジを管理します。 Microsoft の Active Directory 環境 (続き) スキーマ変更サポート環境 (続き) Microsoft IT Identity Management チーム IdM チームは、Microsoft ID 管理インフラストラクチャを管理します。このチームは、すべての関連アプリケーションまたはツール、アカウントとグループ、および追加または変更のワークフローを管理します。 IdM チームは、すべてのユーザー アカウントを管理します。これらには、通常ユーザー、特権アクセス ユーザー、サービス アカウント、および組み込みアカウントが含まれます。また、管理グループを含むグループおよび関連社内アプリケーションも管理します。また、IdM チームは、組織単位、グループ ポリシー オブジェクト、および信頼関係も管理します。MIIS 2003 SP1 を使用してフォレスト間の同期を管理し、ユーザーとグループ、サイトとサブネット、およびプリンタ キューを含むさまざまな種類のオブジェクトを同期します。これにより、ユーザーがさまざまなフォレスト間を移動する際に、一貫したアプリケーション機能とリソース使用が実現されます。 IdM チームの職務には、Active Directory スキーマ管理も含まれます。IdM チームはディレクトリの内容を所有するため、ディレクトリ内のデータを単一の論理インスタンスとして管理します。フォレスト間の一貫性を維持するために、IdM チームは、1 つのフォレスト内のスキーマを変更する際に、一般に他のすべてのフォレスト内でもそのスキーマを変更します。IdM チームはスキーマ変更プロセスを担当しますが、プロセスのすべての側面を管理するわけではありません。たとえば、DC、レプリケーション トポロジ、またはアプリケーションの物理的な管理は行いません。IEng チームと特定のアプリケーションの所有者がこれらの側面を扱います。 Infrastructure Engineering チーム IEng チームは、Microsoft IT の中核となるインフラストラクチャ サーバーを担当しています。これには、Active Directory が存在する DC が含まれます。チームは、サーバーのパフォーマンス調整、管理、および構成を担当します。また、IEng チームは、アプリケーション依存性とネットワーク接続性に基づいて、ネットワーク上での DC の配置場所を決定します。IEng チームは、データ レプリケーション トポロジを管理します。スキーマ変更プロセスへの関与は、データ レプリケーション トポロジに対する責任から発生します。IEng チームは IdM チームと協調して、管理する各フォレスト全体のスキーマ変更のレプリケーションを成功させます。

10 Microsoft の Active Directory 環境
スキーマ変更プロセスを内部 Web サイトで管理者に案内します。 拡張、変更、非アクティブ化を変更管理システムで処理します。 使用されていない定義は Active Directory のパフォーマンスに影響を与えません。 Microsoft の Active Directory 環境 (続き) Microsoft スキーマの管理 ソフトウェア開発は、Microsoft でのスキーマ変更の主要な誘因です。ビジネス ユニットは、Active Directory 機能を使用しスキーマを変更するソフトウェアをインストールまたは更新するたびに、スキーマ変更管理プロセスを完了する必要があります。Microsoft IT は、Microsoft 実稼働環境でベータ ソフトウェアのテストを行い、各製品チームの開発作業をサポートします。Microsoft IT は開発プロセス中に複数の中間ビルドをインストールすることが多く、それによってスキーマ変更の数が増加することがあるため、テストによってスキーマ管理はさらに複雑になります。 変更管理システム IdM チームは、スキーマ変更を要求するユーザーにプロセスを案内する内部 Web サイトを作成しました。このサイトには、プロセスの概要、関連情報へのリンク、およびオンライン スキーマ変更フォームが用意されています。依頼者はフォームに入力し、IdM チームがそのフォームをレビューします。IdM チームは、依頼者がフォームに正しく入力し、すべての問題が解決されていると判断した後で、業務上の可否を評価します。業務の観点から許容される場合、IdM チームは要求を変更キューに入れます。要求フォームを承認した後で、変更を開始から終了まで追跡するスキーマ パッケージ ドキュメントを作成します。IdM チームは、プロセスの各ステップですべての追加データと承認を入力します。IdM チームがスキーマの変更を行うと、IEng チームはフォレストへのレプリケーションを追跡し、正確であることを確認します。最後に、IdM チームがフォーム、スクリプト、およびすべての関連情報をフォルダに入れ、バックアップのために安全な場所に保管します。 スキーマ変更 IdM スキーマ変更管理システムは、次のことを処理します。 拡張 : Microsoft では、最も一般的なスキーマ変更は拡張です。3 つのスキーマ管理オプションのうち、拡張は比較的簡単で、影響を与える可能性は低めです。既存の定義を変更するのではなく新しい定義を追加することにより、既存のアプリケーションに影響する可能性をなくします。 修正 : スキーマ修正は、拡張よりもはるかにまれです。既存のオブジェクトが変更された場合、そのオブジェクトに依存するアプリケーションに悪影響を与える可能性があります。このため、IdM チームは既存のスキーマ オブジェクトへの変更を慎重に調査し、その結果を完全に理解した場合にのみ処理を進めます。さらに、Windows Server System に用意されている属性にはすべて目的があるため、Microsoft ではこれらの属性を使用されていないものとは見なしません。したがって、使用されていない定義の修正はカスタム属性にのみ適用されます。 非アクティブ化 : Microsoft IT が、使用されていない定義を非アクティブにすることはほとんどありません。代わりに、属性またはオブジェクト データが不要になった場合、Microsoft IT は属性値またはオブジェクト インスタンスを削除します。なぜなら、使用されていないスキーマ オブジェクトが大量のリソースを消費することはないからです。実際に、Microsoft は、少量のデータしか含まないように Active Directory をデザインしました。さらに、スキーマ管理者は、既定の Windows スキーマ オブジェクトを非アクティブにできません。カスタム スキーマ オブジェクトのみ非アクティブにできます。 Active Directory のパフォーマンス Active Directory スキーマ内の使用されていない定義は、Active Directory のパフォーマンスに悪影響を与えません。データベースへの列の追加と同様に、スキーマ定義はテーブル サイズのみ増やします。さらに、スキーマ定義はファイル サイズを大幅には増やしません。極端な例では、一部のスキーマ管理ツールの初期化がわずかに低速になることが最も顕著なパフォーマンスの問題です。

11 変更管理システムのアーキテクチャ Microsoft IT では、中核となる管理プロセスのベースとして MOF を使用しています。
スキーマ変更システムは、正式なプロセス、内部 Web サイト、および変更管理ドキュメントから構成されます。 IdM チームは Microsoft でのすべてのスキーマ変更を管理します。 変更管理システムのアーキテクチャ Microsoft では大量のスキーマ変更が発生するため、これらの変更を管理する適切なプロセスの実装が不可欠でした。Microsoft IT では、中核となる管理プロセスのベースとして MOF を使用しています。IdM チームは、スキーマの変更要求、テスト、および実装を管理する手段として、MOF で定義された変更管理プロセスを採用しました。MOF Web サイト ( には、多数の MOF ドキュメントが用意されています。 IdM チームのスキーマ変更管理システムは、正式なプロセス、内部 Web サイト、および変更管理ドキュメントから構成されます。プロセスでは、Microsoft でのすべてのスキーマ変更の管理を定義します。変更要求の開始から、変更の正常完了の通知まで、すべてのアクティビティを詳細に定義します。IdM チームは、内部 Web サイトをすべてのスキーマ変更の管理の開始点として使用することにより、この正式なプロセスを実施します。Web サイトは、予測を行い、よく寄せられる質問 (FAQ) に対処し、オンライン変更要求フォームへのアクセスを可能にします。この手順説明ドキュメントは、標準化されたワークフローの構造を示し、正式なプロセスを強調します。 スキーマの所有権 スキーマの管理および変更により影響が発生する可能性があるため、IdM チームは Microsoft でのすべてのスキーマ変更を管理します。チームでは、スキーマを単一エンティティとして管理し、すべてのスキーマ変更を累積します。これにより、スキーマに現在含まれているすべてのスキーマ要素および追加変更の影響を完全に理解できます。 この理解には、次のものが含まれます。 デザイン : IdM チームは、各スキーマ要素のデザインを分析して、定義済みのスキーマ手順に従っているかどうかを判断します。 実装と使用 : デザインおよび所有権に密接に関連していますが、これには、管理者がスキーマ拡張を実施する方法と、ディレクトリ内での要素インスタンスの挿入方法が含まれます。 所有権 : IdM チームは、カスタム スキーマ要素の所有権を追跡して、その要素に影響する可能性のある将来の変更についての連絡先を明確にします。 セキュリティ : スキーマ要素のセキュリティを判断、追跡、および管理する必要があります。各要素は、所有権、オブジェクト権利の委任、およびより大きな企業セキュリティ目標をサポートする必要があります。 このレベルの理解を維持するために、Microsoft IT は、スキーマ変更を行う権限を IdM チームに限定しています。ゲートキーパーとして、IdM チームはすべてのスキーマ変更を積極的に管理することにより、Active Directory スキーマを正常に保ちます。

12 変更管理システムのアーキテクチャ スキーマ変更の制限を適用するため、Microsoft IT はスキーマ管理グループのメンバシップを限定しています。 スキーマ変更には次のものが必要です。 IdM 承認 スキーマ変更管理システムの使用 事前テスト 適切な文書化 変更管理システムのアーキテクチャ (続き) 変更ポリシー スキーマ変更の制限を適用するために、Microsoft IT では、スキーマ管理グループのメンバシップを IdM チームのメンバに限定しています。また、IdM チームは、スキーマ管理グループへのメンバシップを、承認された変更を行うのに十分な時間だけ一時的に付与します。それ以外の場合、既定のスキーマ管理グループは空のままです。 IdM チームは、スキーマ変更管理システムが使用されていること、適切な標準に従っていること、および予測が設定されていることを確認するためのポリシーを設定する権限を与えられています。スキーマ変更には次のものが必要です。 IdM 承認 : すべてのスキーマ変更には、IdM チームによる承認が必要です。 スキーマ変更管理システムの使用 : すべてのスキーマ変更では、IdM チームの Active Directory スキーマ プロセスおよび承認サービスを実施する必要があります。 事前テスト : キーマ変更の依頼者には、スキーマ変更の機能をテストする責任があります。これには、実装方法も含まれます。IdM チームでは、適切なテストを行っていない要求は検討しません。 適切な文書化 : IdM チームに作業を依頼する前提条件は、実装方法を含め、スキーマ機能とテスト プロセスを文書化することです。IdM チームが最初のレビューをスケジュールする前に、依頼者は、これらの情報および必要なその他すべての情報をスキーマ要求フォームに文書化する必要があります。

13 変更管理システムのアーキテクチャ 内部 Web サイトは、IdM チームとスキーマ変更を要求するユーザー間にインターフェイスを提供します。
変更管理システムのアーキテクチャ (続き) 変更のインフラストラクチャ スキーマ変更管理システムの管理に必要なインフラストラクチャは最小限です。インフラストラクチャは、Web サイト、IdM チーム、および適切なテスト環境から構成されます。 内部 Web サイト IdM チームは、SharePoint 2003 の社内 Web サイトを作成しました。このサイトは、IdM チームとスキーマ変更を要求するユーザー間に協調インターフェイスを提供します。このサイトは、変更管理システムの開始点です。プロセスは、依頼者がオンライン フォームを通じて必要な情報を提供したときに開始します。IdM チームは、オンライン フォームを単純な SharePoint アンケートとして実装します。アンケートは、要求履歴を格納し、リビジョンを有効にし、SharePoint アラート メカニズムを使用して変更発生時にチームにアラートを送信します。IdM チームは、フォーム データをキャプチャしてスキーマ パッケージ ドキュメントを作成します。チームはスキーマ パッケージ ドキュメントを現在のドキュメントとして保守し、スキーマ変更プロセスの各ステップでこのドキュメントに内容を追加します。チームは、フォームとスキーマ パッケージ ドキュメントの両方を SharePoint サイト ドキュメント ライブラリ内のプロジェクト フォルダで保守します。 IdM チーム IdM チームは、要求を受信して処理し、要求された変更をレビューし、独自のテストを実行し、適切な伝達を行い、変更を実装します。これには、IdM 内部 Web サイトとターミナル サーバーへのアクセスと、スキーマ マスタの Flexible Single-Master Operation (FSMO) をホスティングしている DC へのアクセスが必要です。スキーマ管理権のあるアカウントと、必要なテスト環境へのアクセスも必要です。シニア テクノロジストがすべてのスキーマ変更を実行します。 テスト環境 依頼者は、IdM チームにスキーマ変更要求を提出する前に、その変更要求をテストする必要があります。IdM チームは、各スキーマ変更について 2 レベルのテストを要求します。テストは段階的で、前のステップの完了後にのみ次のステップに進みます。テスト フェーズには、実装テストと機能テストが含まれます。 IdM チームは、実装テストを実行します。最初にスキーマ変更を仮想環境に読み込んでから、ラボ環境に移動します。これらの環境でテストすることにより、実装の問題と名前の競合が明らかになります。IdM チームは、常に Windows Server 2003 を新規インストールした仮想環境を構成して、システム競合をテストします。この初期テストにより、スキーマ変更の有効性を検証します。ラボ環境には、Microsoft で行われたすべてのスキーマ拡張が含まれ、カスタムまたはサードパーティ拡張との競合テストを行うことができます。この第 2 の実装テスト ステップにより、機能テストに進むかどうかが判断されます。 スキーマ変更を要求するチームは、スキーマ変更をパイロット環境に読み込むことで機能テストを実行します。これにより、アプリケーション所有者は、変更に関連するアプリケーション機能をテストできます。パイロット環境は、限定された実稼働フォレストであり、実際のユーザーはこの環境に依存してプライマリ ネットワーク アクセスを行います。これにより、限定された実稼働環境でライブ アプリケーション テストを行うことができます。アプリケーション所有者は、パイロット環境を管理し、その成否を判断します。

14 変更管理システムのアーキテクチャ 変更管理プロセスで、さまざまな予測を調整します。
3 つのチームが協力して作業するには、明確な標準と手順が必要です。 依頼者は、目標が妥当かつ実現可能である根拠を示す必要があります。 IdM チームはアドバイスを行う立場です。 変更管理システムのアーキテクチャ (続き) 予測管理 スキーマ変更を管理する場合、スキーマ変更プロセスには、依頼元、IdM チーム、および IEng チームの三者が関係します。それぞれが独自の要件と責任、およびさまざまな予測を持ちます。これらの予測には、タイミング、結果、責任、および標準が含まれますが、これらに限定されません。最高の結果を得るために、変更管理プロセスは、これらのさまざまな予測を調整して混乱を最小化します。IdM チームは、各関係者が最初からプロジェクトを理解していることを確認することでこれを実現します。伝統的に、初期の文書化をより明確で完全なものにすると、プロセスが効率化され、結果が向上します。Microsoft では、予測を調整し、最高の結果を得るために、変更管理システムで、より明確な標準と手順、適切な根拠のある予測、および明確に伝達されたタイムラインを提供する必要があると判断しました。 明確な標準と手順 3 つのチームが協力して作業するためには、明確な標準と手順を事前に設定する必要があります。これらの標準は、予想外のことを排除し、プロセスを円滑に進めるのに役立ちます。IdM チームは、内部 Web サイトでスキーマ変更標準を詳細に説明します。Web サイトは、プロセスの開始点の提供に加えて、完全な手順、ポリシー、および標準を提供します。依頼者は、スキーマ変更を通じて処理する標準を完全に理解した後で、要求を文書化および提出する準備を行います。 適切な根拠のある予測 依頼者は、必要なドキュメントを完成し、その目標が妥当かつ実現可能である根拠を示す必要があります。また、IdM ポリシーおよび標準からの逸脱を詳細に説明し、その正当性を示す必要があります。フォームには、ビジネスと技術両方からの根拠を示す必要があります。 通常、IdM チームは、ビジネスまたは技術的な根拠に乏しいことを理由に要求を拒否することはありません。アドバイザとして、この情報を使用して、目標が達成可能かどうか、またソリューションが最適かどうかを判断します。達成可能でないか最適でない場合、IdM チームは結果を改善する変更を提案します。これにより、不要なスキーマ変更や、不正な変更の要求が排除されます。

15 変更管理システムのアーキテクチャ 標準的な変更は要求から実装までに 7 週間以上を要します。
いくつかの要因が、7 週間というタイムラインに影響します。 スキーマ変更プロセスには、5 つのフェーズがあります。 変更管理システムのアーキテクチャ (続き) 予測管理 (続き) 明確に伝達されたタイムライン IdM チームは、すべての標準変更が要求から実装までに 7 週間以上を要するという予想を設定し、Web サイトにプロセスを概説します。7 週間には、検出およびレビューのための 3 週間と、テストおよび展開のための 4 週間が含まれます。複雑な変更ではさらに時間を要することがあります。 いくつかの要因が、標準の 7 週間のタイムラインに影響することがあります。ただし、これらの要因のいずれも、これらの変更が従う必要のある高い標準を変更しません。これらの要因は、次のとおりです。 緊急事態基準 : IdM チームは、優先順位ステータスを自動的に付与し、設定済みの緊急事態基準に適合する要求のスケジュールを加速します。IdM チームは、この基準をスキーマ変更 Web サイトに公開しています。 緊急度 : スキーマ変更が設定済みの緊急事態基準に適合しない場合でも、状況の緊急度によりスケジュールの加速が保証されることがあります。たとえば、スキーマ依頼者が、特定の Active Directory ユーザー属性を機能しないように設定する必要があるとします。これにより、新しいグローバル ビジネス アプリケーションの他の属性の使用が実施されます。この状況では、依頼者はスケジュールの加速を要求できます。IdM チームは、複雑さ、使用可能なリソース、およびその他の優先順位要求に応じて要求を承諾することがあります。 その他の優先スキーマ変更 : 通常は、IT 環境の最も上級のチーム メンバがスキーマ変更を処理します。これらのメンバは、常に多忙です。緊急事態基準を満たす要求を除き、依頼者は、新しいスキーマ変更要求を既存のキューの最後に追加する必要があります。非常に多忙な期間中は、完了までにより長い時間がかかることがあります。 注 : IdM チームは、すべてのスキーマ変更を、複雑さやスケジュールの逼迫度に関係なく、同一の高水準に保持します。 変更プロセスのフェーズ スキーマ変更プロセスには、次の 5 つのフェーズがあります。 検出 レビュー 実装テスト アプリケーション機能をテストする 実稼働環境に展開する 次に、各フェーズのアクティビティを詳細に説明します。

16 変更プロセスの詳細 変更プロセスの詳細 スライド内に、スキーマ変更管理プロセス中のアクティビティのフローを示します。
スキーマ 要求フォーム送信 送信通知; 受信承認; 優先スケジュール 緊急用画面 はい 変更プロセスの詳細 スライド内に、スキーマ変更管理プロセス中のアクティビティのフローを示します。 一般に、変更管理システムは、IT の複数の領域内の複数の関連する変更を伝達および追跡します。このため、MOF での定義に従ってスキーマ変更プロセスを Microsoft IT 変更管理システムに統合し、スキーマ変更が IT の他の領域と競合しないようにすることが重要です。これは、図に示したように、スキーマ変更プロセスの一部として変更管理通知を送信することにより行います。これにより、同時プロセスが提供されます。IdM チームは、スキーマ変更の展開を承認した後で、スキーマ変更を変更諮問委員 (CAB) に通知するため、CAB は、スキーマ変更プロセスの他の部分で発生する IT 競合を管理できます。CAB は、仲介者としてさまざまなグループ間に助言を与えます。 スキーマ レビューと 実装テスト いいえ CAB (変更諮問委員) への 通知、および SLA の ITIL/MOF KCTL (既知の 変更の種類の一覧) の使用と承認者の ID を特定 展開の承認 はい 変更諮問委員に通知 並行する 変更制御 処理 CAB、緊急 CAB、 機能領域承認者 のいずれかによる レビュー、変更通知ツール への承認の記録 機能テスト いいえ 実稼動 への展開 保留中の変更通知の電子 メールによる配布と、 変更番号およびサービス 要求番号による追跡 文書の アーカイブ化 拒否通知送信 変更完了

17 変更プロセスの詳細 スキーマ変更の依頼者は、通常は製品グループ、ビジネス ユニット、または IT インフラストラクチャ グループの代表者です。 サードパーティ製アプリケーションのスキーマ変更は、実装がより困難です。 IdM Web サイトの説明に従い予測を立てます。 緊急のスキーマ変更要求は、ビジネス ユニット責任者が送信します。 変更プロセスの詳細 (続き) 依頼者の知識を評価する 新製品を開発している製品グループ、ビジネス ユニット、または新しいアプリケーションをサポートするためにスキーマ拡張を必要とする IT インフラストラクチャ グループの代表者が、通常はスキーマ変更の依頼者になります。これまで、Microsoft でのスキーマ変更数は、Exchange および Windows 製品グループからのものが最多でした。IdM チームは、スキーマ変更および提案される実装オプションに関する貴重なフィードバックを製品グループに提供します。 たとえば、Exchange Server 2003 をインストールすると、スキーマの自動的な更新と拡張、新規オブジェクトの作成、および新規オブジェクトの権限の設定を行う forestprep.exe が提供されます。IdM チームは、インストール ファイルがオブジェクトを追加し、データを Active Directory に挿入する前に、スキーマを個別に拡張することを希望していました。IdM チームは、LDIF ファイル オプションの提供を製品グループに要求し、このオプションが最終製品の一部となりました。 サードパーティ製アプリケーションのスキーマ変更は、多くのアプリケーションに隠されたスキーマ変更要件があるため、実装がより困難です。サードパーティ製アプリケーションは .EXE ファイルを使用してスキーマを拡張できるため、変更の抽出が困難になります。さらに、.EXE ファイルは、インストール プロセス中のみ LDIF ファイルをインポートできます。これにより、テストのために LDIF ファイルを取得することが難しくなります。 たとえば、Microsoft では、Avaya の統一メッセージング システムをサポートするためにサードパーティ スキーマの拡張が必要でした。これにより、ボイス メールと Exchange を統合することで、Microsoft での統一メッセージングが可能になりました。インストール ファイルには隠されたスキーマ変更が含まれており、不十分な権限によるインストールの失敗を引き起こします。 スキーマ変更要求を提出する すべてのスキーマ変更は、IdM Web サイトから開始します。サイトは、すべての Microsoft 人員が内部的に使用できます。説明は、オンライン要求フォームおよび追加情報にリンクしています。 説明 説明は、検出およびレビューのための 3 週間の最小リードタイムに関する予測を設定します。IdM チームにより承認された場合、テストおよび実装の最小リードタイムは 4 週間です。チームは、緊急事態基準を満たすスキーマ変更に対して 7 週間のタイムラインの例外を設ける場合があります。 要求フォームは、スキーマ変更の実装に必要な知識レベルに関して IdM チームがユーザーの期待を効果的に設定するのに役立ちます。たとえば、依頼者は、テスト結果および機能テスト計画の前に適切な一意のオブジェクト ID (OID) を提供する必要があります。また、依頼者は、LDIF テキスト ファイルの形式でスキーマ変更要求を提供する必要があります。LDIF 形式は、各変更を明確に示し、その信頼できるソースを含みます。 緊急事態要求 緊急のスキーマ変更が必要な場合、ビジネス ユニット責任者は、要求を提出し、それが一定の基準を満たすことを証明する必要があります。基準には、作業の中断、業務の中断、セキュリティの問題などがあります。IdM チームは、IdM 責任者に推奨を行います。IdM 責任者は、展開の前にすべての緊急事態スキーマを承認する必要があります。プロセスのタイムラインは短縮されます。

18 変更プロセスの詳細 IdM チーム メンバは、変更要求を完了まで追跡します。
変更プロセスの詳細 (続き) 明らかにする スキーマ要求フォームを提出した後で、IdM チーム メンバは、変更要求を完了まで追跡します。最初のタスクは、ビジネスおよび技術的な根拠と要求の詳細のレビューです。長時間かかる可能性のあるレビューの間、IdM チーム メンバは変更ドキュメントに何度も戻り、追加情報の取得や誤りの修正を行うことができます。要求が IdM 標準を満たすと、その要求が承認されて次のステップに進みます。 ビジネスおよび技術的な根拠の判断 不要なスキーマ変更または不正な変更の要求を排除するために、IdM チームは依頼者に対してビジネスおよび技術的な根拠の提示を要求します。 ビジネス上の根拠では、ビジネス ユニットに対する変更の価値を説明します。これにより、依頼者が変更を希望する理由と、変更が行われる必要のある期日に関する認識が IdM チームに提示されます。たとえば、ある製品グループが、Active Directory 機能を使用するアプリケーションについて、製造工程に入る前に Microsoft の実稼動環境に展開してフィードバックを受け取るという要件を設けている場合があります。 技術的な根拠では、提案されるスキーマ変更によって何が実現されるかという想定を具体的に定義します。IdM チームは、要求された変更を技術目標に照らしてレビューし、その目標が達成可能かどうか、またソリューションが最適かどうかを確認します。 製品グループは、機能の追加と製品の保全に集中し、アプリケーションが作業環境にどのように影響するかのテストについては Microsoft IT に依存します。IdM チームは、アプリケーション デザインの重要な問題を検出することがあります。たとえば、IdM チームは、製品グループが Active Directory を使用して頻繁に変更されるデータを取得していることを発見する場合があります。このデータは頻繁に変更されるため、データがフォレスト全体にレプリケートされる前に再び変更される可能性があります。このため、無効なデータがフォレスト内の一部の DC に絶えず存在する可能性があり、スキーマ変更の価値が否定されます。

19 変更プロセスの詳細 IdM チームは、スキーマ変更関連の LDIF ファイルを徹底的にレビューします。
一般的な情報収集の大部分を自動化するスクリプトを使用します。 IdM チームは実装テストを行うために変更をキューに入れます。 プロセスの結果、LDIF ファイルが正しくインストールされる必要があります。 変更プロセスの詳細 (続き) スキーマ変更要求をレビューする IdM チームは、ビジネスおよび技術的な根拠を理解し、同意した後で、LDIF ファイルを徹底的にレビューします。チームは、エラーを探し、デザインを分析し、作成者にフィードバックを提供します。問題がある場合、このフィードバック ループは、作成者がソリューションを最適化し、承認される要求を再デザインするのに役立ちます。 スキーマ ファイルをレビューする場合、レビューアは次のことを行います。 スキーマ変更により要求される新しい属性およびオブジェクト クラスをメモして、テストに役立てます。 既定のセキュリティ記述子の変更について過剰な権限および委任をレビューします。 インデックス付けされた属性、部分属性セット (PAS) の再構築、SDProp など、システム作業負荷を増やすオブジェクトを探します。 潜在的な変更の範囲を評価し、そのすべてが Active Directory スキーマのベスト プラクティスおよび IdM 標準に準拠していることを確認します。 各 OID をチェックして、一意かつ登録済みであることを確認します。このチェックは、 (英語) で行うことができます。 スキーマ要素をチェックして、適切な定義、一貫した値、および有意義な説明が存在することを確認します。 Microsoft 標準に準拠する一貫した名前付け規則をチェックします。Microsoft Web サイトで (英語) を参照してください。 IdM チームは、一般的な情報収集の大部分を自動化するスクリプトを使用します。提出された情報に満足したら、レビューアは変更要求を承認し、タイムラインを設定し、実装テストに移ります。 実装をテストする スキーマ変更要求が承認されると、IdM チームは実装テストを行うために変更をキューに入れます。仕様により、フォレスト スキーマは Microsoft 内のフォレスト間である程度異なります。たとえば、フォレストは、レガシ サポートおよび開発のために Microsoft ソフトウェアのさまざまなバージョンを保守します。各フォレストに対してテストを個別に実行するのではなく、IdM チームはすべてのフォレストからのすべてのスキーマ拡張を含む累積スキーマのあるラボ環境を保守します。したがって、この環境で正常な実装テストを行うことにより、IdM チームは展開の前に任意のフォレスト内の競合を識別できます。 LDIF ファイルをラボに読み込むことにより、IdM チームは、OID または名前の競合がないこと、また LDIF ファイルが明確に読み込まれることを検証できます。実装中にロギング オプションをオンにし、ログでエラーをチェックすることにより、この検証を行います。IdM チームは、すべてのエラーを調査し、ファイルに改訂が必要な場合は LDIF ファイルを依頼者に返すことができます。最終的な LDIF ファイルが正しくインストールされることに疑いがあってはなりません。

20 変更プロセスの詳細 IdM チームは、実装テストの後で、展開を承認または拒否します。 承認された要求は、CAB 通知と機能テストに移ります。
変更プロセスの詳細 (続き) 展開を承認する IdM チームは、変更要求をレビューし、実装をテストした後で、展開を承認または拒否します。承認された場合、IdM チームは CAB に通知し、変更要求を機能テストに移します。拒否された場合、IdM チームは拒否の詳細な説明を添えて変更要求を依頼者に返します。 変更諮問委員に通知する CAB は、MOF に従って設けられた Microsoft IT の部門です。CAB は IdM チームから独立しています。CAB は、すべての Microsoft IT 変更要求のビジネス ニーズ、優先順位、費用対効果、および他のシステムやプロセスに対する潜在的な影響を評価するために組織された部門間グループです。一般に、CAB は実装、詳細な分析、延期、または取り消しに関する推奨を行います。 IdM チームが CAB に変更管理通知を提出すると、CAB は IdM チームと同時にプロセスを実行します。CAB は、Microsoft IT の一般的な変更管理チケット システムとの統合点です。 IT 環境は非常に複雑であり、グローバルな規模で多くの相互依存性を含んでいることがあります。CAB は、相互に依存するシステムおよび部門に対する変更の影響を判断し、部門間で変更を調整します。Microsoft IT の変更管理システムをスキーマ変更管理システムと同時に使用することにより、変更を調整します。CAB は、変更要求をレビューして、次のことを決定します。 承認 : 変更を行う関係者の権限。 相互依存性 : 変更は、多くの異なるグループおよびそのサービス レベル契約 (SLA) に影響することがあります。 競合 : Microsoft IT をグローバルな観点から見ることで、CAB は、変更およびそのタイミングを修正して競合を回避する必要があるかどうかを判断できます。 変更要求をレビューした後で、CAB は変更要求を承認するか、変更の推奨を添付して返します。承認された場合、CAB は要求にチケット番号を付けるために一般変更管理システムに追加し、電子メールですべての相互依存グループに通知します。通知することで、これらのグループは競合の回避と変更の調整に必要な手順を実行できます。

21 変更プロセスの詳細 パイロットにより、依頼者は機能テストを実行できます。
レビューとテストが終了すると、LDIF ファイルを展開する準備ができます。 スクリプトを使用して、各フォレストに同一の変更を適用します。 IEng チームはスキーマのレプリケートに問題がないことを確認します。 変更プロセスの詳細 (続き) アプリケーション機能をテストする LDIF ファイルがラボ環境に適切に読み込まれる場合、次の手順は最初のパイロットの開始です。パイロットにより、依頼者は機能テスト計画に提示された機能テストを実行できます。IdM チームは通常、Windows 開発フォレストを使用して最初のパイロットを開始します。このフォレストは、この環境を使用してドッグフードを促進するユーザーを含む限定された実稼働フォレストです。通常、依頼者には、機能をテストし、スキーマ変更が予想どおりに動作するかどうかを判断するために 1 週間が与えられます。依頼者に、テストする追加フォレストがある場合、IdM チームは第 2 のパイロットの機会を提供します。各パイロット フェーズの終わりに、依頼者は機能テストの正常な完了を確認します。依頼者は、機能テスト中に小さな問題を修正するために小さな変更改訂を試行できます。ただし、依頼者が大きな問題を発見した場合は、プロセスを停止し、依頼者はスキーマ変更を再作業する必要があります。 実稼働環境に展開する 実装と機能テストが正常に完了すると、完全にレビューおよびテストされた LDIF ファイルを展開する準備ができます。IdM チームは、スキーマ変更展開スケジュールを進めます。変更が展開される日時は、タイムライン要件、変更の規模、レプリケーションの影響、および IdM チームと IEng チーム双方の既存の作業負荷によって決まります。IEng チームは、レプリケーション プロセスを監視する必要があります。適切なテストが行われると、IdM チームは小さな変更を同じ日に連続して読み込みますが、大きなスキーマ変更は可能であれば分離して読み込みます。IdM チームは、金曜日の夜 (太平洋標準時) をスキーマ変更のために予約して、アジア時間の月曜日朝までにレプリケーションが完了し、Active Directory 負荷が正常に戻るようにします。 プロセスをスクリプト化することにより、IdM チームは手動操作を行わずに同じ変更を各フォレストに適用できます。IdM チームは、すべてのスキーマ拡張について変更を各フォレストに連続して適用します。変更プロセスの正常な完了を確認するために、IdM チームはログ ファイルの一番下に記録されている正常な変更の数を、他のフォレストでのその後の変更と比較します。一致しない場合、IdM チームはログ レコードを確認します。Active Directory の安定性に影響する重大なエラーが発生している場合、IdM チームは IEng チームと協力して復旧計画を開始することが必要な場合があります。 展開が正常に完了した後で、IdM チームはスクリプト、LDIF ファイル、および各フォレストのログ ファイル、また存在する場合はエラー ファイルを圧縮します。次に、すべてのスキーマ変更を記録する変更履歴ファイルにレコードを追加します。 IdM チームが変更を対象のフォレストに展開した後で、IEng チームはレプリケーション プロセスを監視して、各フォレストへのスキーマのレプリケートに関する問題がないことを確認します。IEng チームは、重大な問題がある場合の復旧も担当します。スキーマ変更が各フォレストにレプリケートされ、IEng チームが結果に満足すると、正常なスキーマ変更のレプリケーションを確認する最終電子メールが関係者全員に送信されます。

22 リスクを軽減する 影響と発生可能性からリスクを判断します。 レプリケーションの影響 : 小さな影響、中程度のリスク リスクを軽減する
リスクを測定する Microsoft IT は、不都合なイベントの発生の影響と可能性の両方を使用して、そのイベントのリスクを判断します。システム障害など、最も大きな損害を発生させる可能性のあるイベントは、通常は Microsoft IT で安全対策と冗長性によって最初に防御されるイベントです。これにより、リスクの高いイベントと影響の大きいイベントの間に反比例関係が生じ、最も損害の大きいイベントが発生する可能性が最も低くなります。影響の大きいイベントに備えることも重要ですが、ある程度の発生リスクのあるイベントを管理する方がより生産的です。Microsoft では、次に説明する各リスクについて検討することをお勧めします。 レプリケーションの影響 : 小さな影響、中程度のリスク Active Directory レプリケーションでは、データを変更する前にスキーマ変更をレプリケートする優先順位体系を使用します。これにより、さまざまな DC 間でデータを集めるために必要な時間が長くなります。その後、大規模なスキーマ変更が、Active Directory 依存アプリケーションに必要なデータ変更のボトルネックとなり、データを使用するユーザーに影響を与えることがあります。たとえば、フォレスト全体でのグループ メンバシップ変更のレプリケートは、スキーマ変更中の通常の 5 時間のレプリケーション レイテンシよりも時間がかかることがあります。その理由は、スキーマ拡張の完了後にグループ メンバシップがレプリケートされるためです。 Exchange Server 2003 などの Active Directory 機能を使用する重要アプリケーションの実装では、フォレスト サイト トポロジに応じてスキーマ変更をレプリケートするためにホップあたり複数のレプリケーション サイクルを必要とする可能性のある多数のスキーマ変更が生成されます。IdM チームは、通常、金曜日の夜にこれらの種類の変更を実装して、生産性に対する影響を最小化します。追加のレプリケーション作業負荷を生成するその他の属性として、インデックス付けされた属性、PAS の再構築、または継承されたセキュリティ記述子 (SDProp) があります。これらの変更は一定のシステム機能を実現するために必要な場合があり、管理者は変更を回避できませんが、適切にデザインされた実装によってマイナスの影響を最小化できます。

23 リスクを軽減する アプリケーション障害 : 中程度の影響、中程度のリスク システム障害 : 大きな影響、低いリスク
リスクを軽減する (続き) リスクを測定する (続き) アプリケーション障害 : 中程度の影響、中程度のリスク Active Directory は、セキュリティやグローバル カタログへのアクセスなど、フォレスト内に一定のアプリケーション機能を提供します。また、Active Directory スキーマを拡張するアプリケーションには、Active Directory とその拡張へのアクセスに依存するカスタム機能があります。スキーマ拡張は、アプリケーションが機能するために必要なオブジェクトの作成に使用する定義を提供します。Active Directory へのアクセスが失われると、アプリケーションが特定の機能を失ったり、完全に失敗したりすることがあります。 適切にデザインされていないスキーマ変更により、依存アプリケーションに必要な既存の要素が無効になり、問題が発生することがあります。また、適切に実装されていないスキーマ拡張では、部分的な変更のみ行われてアプリケーション エラーの原因となることや、新しいアプリケーションが完全には機能しないことがあります。 システム障害 : 大きな影響、低いリスク Active Directory は、ネットワーク リソース アクセスと、Active Directory 機能を使用するアプリケーションの機能を管理します。したがって、Active Directory が使用不能になった場合、フォレスト内のユーザーは、これらのリソースおよび特定のアプリケーション機能へのアクセスを失います。ただし、ドメイン内のすべての DC で障害が発生しない限り、Active Directory が使用不能になることはありません。単一の DC の障害は、フォレスト全体の Active Directory には影響しません。DC 障害はめったに発生しないため、これはリスクの小さいイベントです。 ハードウェアまたはソフトウェア障害は DC 障害の原因となることがあります。DC 障害を解決するには、ハードウェア障害を解決するか、ソフトウェアを再インストールします。管理者が複数の DC を展開して冗長性を提供する場合、DC 障害は Active Directory 障害を意味しません。ただし、スキーマ マスタがスキーマ変更中に失敗した場合、管理者はサーバーをオンラインに戻すときに注意して、一貫した状態を保証する必要があります。 データ障害を原因とする、レプリケートされた Active Directory の破損も非常にまれです。レプリケートされた Active Directory の破損を解決するには、障害時復旧計画を実装します。

24 リスクを軽減する スキーマ変更の問題の主要原因 : 不適切なデザインと不適切な実装
変更管理システムは、次の機能を実行することによりデザイン リスクを管理します。 ドキュメント管理 デザイン分析 標準の確立 サードパーティ ベンダの責務 リスクを軽減する (続き) リスクを管理する リスクを理解することにより、重要なスキーマ変更の問題の 2 つの主要原因が不適切なデザインと不適切な実装であることが明らかになります。デザインの問題により、レプリケーション レイテンシまたは DC システム負荷が増加し、アプリケーションの不整合や停止を引き起こすことがあります。実装の問題には、機能を妨げる部分実装や、レプリケーション レイテンシを通常のしきい値以上にする劣悪なタイミングが含まれます。レプリケーション レイテンシは、レイテンシに敏感なアプリケーションに影響することがあります。このため、リスクを最小化または排除するには、スキーマ変更デザインおよび実装を管理することが重要です。これを実現するために、IdM チームは、Microsoft IT 管理フォレスト内のすべてのスキーマ変更を行う排他的な権限を持ちます。 デザイン リスクを管理する IdM スキーマ変更管理システムでは、スキーマ変更の依頼者が変更承認に関する特定のガイドラインに従う必要があります。IdM チームは、デザインに疑問のあるスキーマ変更を、再作業された技術詳細をレビューできるまで延期します。変更管理システムは、次の機能を実行することによりデザイン リスクを管理します。 ドキュメント管理 : ドキュメントが不適切であると、実装が難しくなることがあります。この問題を排除するために、依頼者は、標準化されたドキュメントをレビューの開始前に提出する必要があります。 デザイン分析 : IdM チームは、IdM 標準に基づいてスキーマ デザインを分析し、不適切にデザインされた変更要求にコメントおよび提案を添えて作成者に返します。 標準の確立 : IdM チームは、許容されるスキーマ変更を定義する高い標準とベスト プラクティスのセットを適用します。これらの標準によって、既存のスキーマ オブジェクトとの競合リスクが最小化されます。これらの標準は、レプリケーション作業負荷が急増する原因となる属性の使用に特に注目します。 サードパーティ ベンダの責務 : ベンダは、デザインまたはセキュリティを評価するために LDIF ファイルまたはスキーマ セキュリティ記述子を常に提供するとは限りません。遵守の問題により、管理者がサードパーティ スキーマのセキュリティ記述子を徹底的にレビューし、文書化されたスキーマ変更を入手して検証することが重要です。

25 リスクを軽減する 実装リスクを管理する手順の内容は以下のとおりです。 プロセスのスクリプト化 実装テスト 機能テスト 実装標準
リスクを軽減する (続き) リスクを管理する (続き) 実装リスクを管理する スキーマ変更が承認されてデザインされると、実装および機能テストが開始します。手順は次のとおりです。 プロセスのスクリプト化 : IdM チームは、標準スクリプトを使用して、LDIF ファイルをすべてのフォレストに実装し、企業全体で正しく一貫性のあるパラメータが使用されることを保証します。これにより、部分的なスキーマ変更の原因となる実装プロセス中の一般的な人的エラーが排除されます。 実装テスト : LDIF ファイル実装をラボ環境でテストすることにより、ファイルを実稼働環境に展開する前に、エラーと競合を検出し、修正できます。 機能テスト : 限定された環境でスキーマ変更をパイロット運用することにより、アプリケーション機能を依頼者が判断できます。パイロットの結果により、IdM チームがスキーマ変更を実装するかどうかが決定されます。これにより、不適切に機能しているスキーマ デザインを実装するリスクが排除されます。 実装標準 : IdM チームは、リスクを最小化する実装標準およびベスト プラクティスを考案しました。これは、次のとおりです。 直接スキーマ マスタ実装 : IdM チームは、ターミナル サーバーを使用して、スキーマ マスタにスキーマ変更をローカルに実装するため、実装は、ワークステーションの問題やネットワーク接続性に影響しません。これにより、これらの問題により生成される部分的なスキーマ変更の実装のリスクが排除されます。 レプリケーションの影響の考慮 : IdM チームは通常、金曜日の夜にスキーマ変更を実装して、レプリケーションが週末に行われるようにします。これにより、他のレプリケーション トラフィックへの影響が最小化されます。 正常なレプリケーションの検証 : IEng チームは、フォレスト全体でのスキーマ変更の正常なレプリケーションを検証します。これにより、スキーマ変更が完全にはレプリケートされていない場合に実稼働環境で予期しないアプリケーション動作が発生する可能性が軽減されます。

26 リスクを軽減する スキーマを変更したときに、場合によりドメインまたはフォレストを復元する必要があります。
障害時復旧プロセスの内容は次のとおりです。 バックアップと復元 スキーマ マスタのオフライン化 リスクを軽減する (続き) リスクを管理する (続き) 障害時復旧を計画する スキーマ変更により、簡単には修正できない問題が発生することがあります。優先される復旧方法は、スキーマの変更です。ただし、スキーマの変更が実際的な選択肢ではない場合があります。このような場合は、管理者がドメインまたはフォレストを復元する必要があります。 IEng チームは、障害時復旧に責任を持ち、スキーマ変更をロールバックするための複数のプロセスを持っています。これは、次のとおりです。 バックアップと復元 : この方法を機能させるには、企業が DC システム状態のバックアップを定期的に実行し、バックアップが良好であることを確認し、復元プロセスを定期的に行う必要があります。IEng チームは、非公式な復元を毎月実行してプロセスをテストし、公式な復元を 3 ～ 4 か月ごとに実行してデータを失ったユーザーを支援することにより、復元プロセスを定期的に実行します。スキーマ変更の場合は、フォレストの復元が必要です。これは、バックアップおよび復元シナリオの拡張バージョンです。IEng チームは、ラボでのフォレスト復元を毎年実行して、プロセスをテストします。2 つのオプションのうち、バックアップおよび復元は、実行が簡単なため IEng チームが優先的に採用する方法です。 スキーマ マスタのオフライン化 : スキーマ変更を直接行っている間、スキーマ マスタをネットワークから切断することにより、IdM チームはスキーマ マスタをオンラインに戻す前に実装の成功を検証できます。このため、スキーマ変更を元に戻す必要がある場合は、スキーマ マスタを単一の DC として復旧できます。この方法では、アプリケーションを検証する機会は与えられません。ただし、適切なスキーマ インストールは保証されます。

27 ベスト プラクティス 変更管理プロセスを標準化します。 アプリケーションのインストールから独立してスキーマを拡張します。
実装前に徹底的にテストします。 Active Directory に対するすべてのスキーマ変更の影響を理解します。 ベスト プラクティス IdM チームは、何年にもわたるスキーマ変更の展開から多くのことを学習しました。大量のスキーマ変更により、IdM チームはプロセスを絶えず改訂できました。これらの改訂により、一連のベスト プラクティスと標準を考案して、プロセスを強化し、最高の結果を実現しました。 Microsoft IT が推奨するベスト プラクティスは次のとおりです。 変更管理プロセスを標準化します。適切にデザインされた変更管理プロセスにより、最高の結果を実現する標準化されたワークフローが組織にもたらされます。適切なプロセスがあると、責任と予測が明確になります。プロセスには、許容される形式での最初の変更要求の配信から、プロセスが正常に完了したことをすべての関係者に伝達する人物の決定まで、完全なワークフローが含まれている必要があります。 アプリケーションのインストールから独立してスキーマを拡張します。スキーマ変更を必要とするアプリケーションをインストールする場合は、スキーマをアプリケーションのインストールから独立して拡張します。変更の詳細情報が大量に提供されるため、LDIF ファイルを使用したスキーマの拡張は優先される方法です。IdM チームは、社内の製品グループと社外のベンダの両方に LDIF オプションの提供を要求します。IdM チームは、スキーマの個別の拡張に成功した後にのみ、オブジェクトの作成、権限の設定、およびデータの挿入のためにインストールを許可します。 実装前に徹底的にテストします。すべてのスキーマ変更を、実稼働環境に実装する前に徹底的にテストします。これには、実装テストと機能テストが含まれます。社内で開発されたすべてのアプリケーションに対して機能テストを実行します。既製の製品の機能テストは不要な場合があります。 Active Directory に対するすべてのスキーマ変更の影響を理解します。スキーマ変更の影響は広範であり、オブジェクトのセキュリティ、ディレクトリに公開されるデータの種類、ディレクトリ データベースのインデックス作成、ディレクトリへの更新のコスト、グローバル カタログでの可用性、および Active Directory データベースのサイズに影響することがあります。したがって、実稼働環境でスキーマを拡張する前に、変更が Active Directory のセキュリティ、データ使用状況、インフラストラクチャ要件、レプリケーション、依存アプリケーションなどの側面にどのように影響するかを判断することが重要です。

28 ベスト プラクティス プロセスをスクリプト化します。 フォレストの名前付けの自動化 適切なコマンド ライン スイッチの使用
フォレストの一貫性 プロセスの一貫性 ベスト プラクティス (続き) プロセスをスクリプト化します。標準化されたスクリプトを使用してすべてのスキーマ変更を実行し、プロセスの一貫性を維持します。スクリプトは、必要な ldifde.exe コマンド ライン スイッチを使用して LDIF ファイル変更を実行し、そのファイル内の変数を処理します。これにより、遺漏が排除され、すべてのスキーマ変更が標準の手順に従い、一貫した結果を返すことが保証されます。標準化されたスクリプトには、以下の内容が含まれます。 フォレストの名前付けを自動化します。LDIF ファイルでは、追加または変更された各オブジェクトの識別名 (DN) を指定します。この DN には、フォレストのルート ドメイン コンポーネントが含まれているため、これらの DN は対象のフォレストの特定の DC 要素で変更する必要があります。LDIF ファイルの事実上の標準では、DC=X を DC 要素のプレースホルダとして使用します。LDIF ファイル内で DC=X を使用することにより、スクリプトは現在のドメイン名コンテキストを判断し、意味のある値で置換します。これにより、LDIF ファイルの移植性が非常に高くなり、LDIF ファイルを手動で変更しなくても、同じスクリプトを各フォレストで実行できます。これにより、バージョン管理の問題も排除されます。 適切なコマンド ライン スイッチを使用します。スクリプトは、標準のパラメータ セットを使用して LDIFDE.exe コマンド ライン ツールを操作します。コマンド パラメータ J を使用してテキスト ログ ファイルを生成します。スクリプトでは、コマンド パラメータ C を使用し、検索および置換を使用してフォレスト名の変更を自動化します。コマンド パラメータの K オプションを使用することにより、スキーマ変更プロセスにエラーが発生した場合でも、スクリプトが続行し、欠落要素は作成されません。管理者は簡略化のために元のスキーマ変更の一番下に追加のスキーマ変更を追加することが多いため、このことは重要です。スクリプトを実行すると、スクリプトは失敗せずに、重複したスキーマ変更がエラーとして表示されます。検証テストを実行する場合、コマンド パラメータ K は制約違反エラー後も続行するため、ログを確認する際に注意することが重要です。ログに記録されたエラーは、些細なことでも役立ちます。 フォレストの一貫性を維持します。手動変更を行わずにすべてのフォレストに同じスクリプトを使用すると、フォレスト間のスキーマの一貫性が向上します。LDIF ファイルを手動で変更すると、部分的なスキーマ変更の原因となるエラーが発生することがあります。 プロセスの一貫性を維持します。プロセスがスクリプト化されていない場合、オペレータは適切なパラメータを毎回入力する必要があります。これにより、人的エラーのリスクが生じます。たとえば、オペレータは、パラメータ J を指定せずにプロセスが実行された後でログ ファイルを作成することはできません。また、パラメータ K の使用を忘れると、部分的なスキーマ変更が作成され、ログの調査が必要になることがあります。

29 ベスト プラクティス スキーマ マスタをローカルに変更します。 スキーマ変更の履歴を保持します。 順次スキーマ変更を同時テストします。
不要なスキーマ オブジェクトから古いデータを削除します。 ベスト プラクティス (続き) スキーマ マスタをローカルに変更します。スキーマを変更する場合は、ターミナル サーバー セッションを使用してスキーマ マスタにログインします。ターミナル サーバーはスキーマ マスタをローカルに変更するため、部分的なスキーマ変更の問題を生成する可能性のある潜在的なネットワークおよびクライアントの問題が軽減されます。 スキーマ変更の履歴を保持します。各スキーマ変更に関係するすべてのレコードのコピーを保持します。これにより、必要に応じて調査できる変更履歴と結果の要約が作成されます。また、ファイルを保持することにより、管理者は、LDIF ファイルの最後に変更を追加して、将来の変更を簡略化できます。各スキーマ変更で、Microsoft IT は、スクリプト、LDIF、ログ、および各フォレストのエラー ファイルを圧縮します。 順次スキーマ変更を同時テストします。管理者には、順次スキーマ変更を展開する前に特定の順次テストを実行することを強くお勧めします。スキーマ変更を個別に実行して、それぞれに一意のスクリプトを保守します。 不要なスキーマ オブジェクトから古いデータを削除します。Active Directory 内に使用されていないデータがある場合は、単純なスクリプトを作成することにより、データを削除し、リソースを解放することが最善です。これにより、ファイル領域が解放されるだけでなく、インデックス作成とレプリケーション中のサーバー負荷も削減されます。最後に、古いデータを消去すると、機密データが意図せず残されたり公開されたりする可能性を下げることができます。

30 IdM 標準 スキーマ デザイン スキーマの所有権 スキーマ実装と使用 スキーマのセキュリティ 複数フォレストのステージング IdM 標準
すべてのスキーマ要素に有効な OID が必要です。 Microsoft が推奨する名前付け規則に従います。 管理者は、一意で広範に設定される要素にのみインデックスを作成する必要があります。 部分的な属性セットへの追加は必要な場合にのみ行います。 カスタム プロパティ セットの所有者が、そのセットに対する変更を承認する必要があります。 Active Directory 内の単一オブジェクトは 1 MB 以下である必要があります。 スキーマの所有権 スキーマ要素の所有者は、常勤の従業員である必要があります。 社内で開発されたアプリケーションの場合は、拡張実装の前に各スキーマ要素の所有権を定義します。 所有者は、使用されていないスキーマ要素に関する IdM チームへの通知とそれらの無効化を担当します。 スキーマ実装と使用 同一の目的を持つスキーマ要素が存在していない必要があります。 LDIF スクリプトを使用してすべてのスキーマ変更を行います。サードパーティ製品で実行可能ファイルまたはインストール ラッパーを使用する場合は、LDIF ファイルの検証、手動インストール、またはその両方ができるようにします。 後で参照できるようにすべての LDIF ファイルをアーカイブします。 IdM チームのみが、Microsoft IT により管理されるフォレストのスキーマに変更を実装します。 提案されたスキーマ拡張で行ったテストのレベルを文書化します。 LDIF スクリプト、プログラム実行可能ファイル、インストール ラッパーなどを使用するスキーマ変更を実装するための実装手順を提供します。 スキーマのセキュリティ IdM チームは、スキーマ要素の既定のセキュリティ記述子の変更がネットワーク セキュリティに影響する場合に注意を払う必要があります。 複数フォレストのステージング 一貫性を維持するための作業が実際的である必要もあります。IdM は、スキーマ変更をさまざまなフォレストにステージングして、実装方法の検証、互換性の競合の識別、およびフォレスト間の一貫性の確認を行います。

31 まとめ スキーマ変更プロセスは構造化と一貫性が必要です。
Microsoft ではスキーマの変更と標準の実施を 1 つのグループが担当しています。 スキーマ変更には積極的な管理と協力が必要です。 構造化されたワークフローによって、タイムリーで最適化された結果が実現します。 まとめ Microsoft IT では、可否の判断、評価、テスト、ステージング、および実装のマイルストーンを含む一貫した Active Directory スキーマ変更プロセスを規定することをお勧めします。また、既存の変更管理システムにスキーマ変更プロセスを統合して、競合とリスクを軽減することもお勧めします。 Microsoft IT は、すべてのスキーマ変更を処理し、標準を適用する権限を特定のグループに付与します。標準は、明示的に定義され、適用可能です。スキーマ変更プロセスは、標準と手順を適用し、予想を適切に作成して管理し、タイムラインを明確に伝達します。 スキーマ変更には積極的な管理が必要であり、関係する複数のチーム間の協力を必要とすることがあります。Microsoft スキーマ変更プロセスは、責任を割り当て、関係者間にチェックとバランスを提供します。標準の段階的なプロセスに従うことで、混乱が排除され、すべての要件が満たされます。 スキーマ変更プロセスを確立することにより、Microsoft IT は、組織的な標準を適用し、堅実な予想を立てる構造化ワークフローでスキーマ変更を標準化しました。現在、ワークフローはプロセスの初期にスキーマ変更の問題を排除し、各関係者に対して責任を明確にしています。これにより、すべての関係者間の協調が向上し、タイムリーで最適化された結果が実現されます。

32 詳細情報 Microsoft IT の展開およびベスト プラクティスに関する追加のコンテンツについては、以下のページを参照してください。 Microsoft TechNet Microsoft ケース スタディ リソース 詳細情報 Microsoft IT の展開およびベスト プラクティスに関する追加のコンテンツについては、以下のページを参照してください。 TechNet: ケース スタディ リソース : Microsoft IT ショウケースについて Microsoft IT ショウケースは、Microsoft IT 組織の主要な業務アプリケーション、展開戦略、早期導入者の経験、ベスト プラクティス、および最新の取り組みを集めたものです。 IT ショウケースには、Microsoft 社内で実装されている業務アプリケーション、製品展開の経験、およびその他の主要な IT の取り組みを示すケース スタディ、ホワイト ペーパー、プレゼンテーション、およびマルチメディア プレゼンテーションが用意されています。 Microsoft IT の経験 早期導入者 : 多くの場合、Microsoft IT は、実稼動環境に新しい Microsoft 製品を最初に実装します。また、Microsoft テクノロジに基づいて、基幹業務アプリケーションを開発します。Microsoft IT が直面している課題およびその対処方法を把握することで、同様のプロジェクトを計画して実行するときに役立ちます。 大規模な展開 : Microsoft IT では、世界中の展開 (Microsoft の製品および他のベンダの製品) を見ています。Microsoft IT が対処する問題や学んだ内容は、独自の大規模なロールアウトの準備をするときに役立ちます。

33 このドキュメントに記載された内容は情報提供のみを目的としており、
© 2005 Microsoft Corporation. All rights reserved. このプレゼンテーションに記載された内容は情報提供のみを目的としており、明示または黙示にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。Microsoft、Active Directory、MSN、SharePoint、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。記載されている会社名、製品名には、各社の商標のものもあります。 このドキュメントに記載された内容は情報提供のみを目的としており、 明示または黙示にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。 © 2005 Microsoft Corporation. All rights reserved. このプレゼンテーションに記載された内容は情報提供のみを目的としており、明示または黙示にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。Microsoft、Active Directory、MSN、SharePoint、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。記載されている会社名、製品名には、各社の商標のものもあります。