Active Directory の障害回復

  • [アーティクル]

オペレーティング システム

概要
Windows® 2000 Server オペレーティング システムの中核部分は、Active Directory™ サービスとその正常な運用に必要となるシステムです。システム管理者は、これらのきわめて重要なシステムの機能をいかにして保ち、万一の場合にどのように対処したらよいのかについて、理解しておく必要があります。

ドメイン コントローラは、Active Directory インフラストラクチャの内部において、グローバル カタログ (GC)、操作マスタ (OM)、あるいはシンプルなドメイン コントローラといった、多数の役割を担うことができます。このホワイト ペーパーでは、障害が発生した後に Active Directory を復旧するための手順について説明します。また、サーバーを特別な役割に復元するために必要な具体的な条件についても説明します。

この文書で解説している手順は、Compaq QTEST Windows 2000 という組織で実施された復旧操作を通してすでに検証されたものです。QTEST は、世界規模で配置されている Windows 2000 ベースのサーバー群に対して、Compaq のコンサルタントがさまざまな配置シナリオの検証と試験に使用しています。

トピック

はじめに はじめに
Active Directory の概要 Active Directory の概要
Active Directory のバックアップ Active Directory のバックアップ
Active Directory の障害回復フローチャート Active Directory の障害回復フローチャート
Active Directory の復旧 Active Directory の復旧
グローバル カタログ サーバーの復旧 グローバル カタログ サーバーの復旧
操作マスタの復旧 操作マスタの復旧
まとめ まとめ
付録 I 付録 I
付録 II 付録 II
付録 III 付録 III
付録 IV 付録 IV

はじめに

このホワイト ペーパーでは、ハードウェアまたはソフトウェアの障害が原因となって起こるデータベースの機能異常などの障害からドメイン コントローラを復旧する手順について説明します。通常、この種の障害ではドメイン コントローラが使用不能になり、コンピュータを正常に起動できなくなります。また別の障害例としては人災があります。人災ではエラーが伴い、エラーを含むデータが企業のほかのドメイン コントローラに複製されます。

このホワイト ペーパーでは、Active Directory だけが動作していてほかのサービスが一切動作していないドメイン コントローラの復旧に関する情報を紹介しています。ドメイン ネーム システム (DNS) やインターネット インフォメーション サービス (IIS) などのほかのサービスがコンピュータにインストールされている場合は、さらに別の手順が必要になることがありますが、このホワイト ペーパーではそれらについては説明していません。

このホワイト ペーパーで紹介している例のほとんどは、Windows 2000 に付属している既定のバックアップ アプリケーションである Windows 2000 バックアップ ユーティリティ (ntbackup.exe) に基づくものです。このツールの詳細については付録 IV を参照してください。ユーザーによっては自分で使い慣れているバックアップ アプリケーションを使用する場合もありますが、その場合でもこのホワイト ペーパーの内容を適用し利用することができます。

このホワイト ペーパーでは、Active Directory に関する問題のトラブルシューティングについては触れていませんが、その代わりにすべてのトラブルシューティングに失敗して Active Directory が機能しなくなった場合の対処法について説明しています。このような場合、ユーザーはドメイン コントローラを正常なモードで起動できなくなることがあります。

このホワイト ペーパーでは、ユーザーが Active Directory とその関連コンポーネントについて若干の予備知識があることを前提としています。Active Directory の詳細については、Windows 2000 リソースキットの『分散システム ガイド』を参照してください。

システム管理者はこのホワイト ペーパーの情報を利用して障害回復計画を立てることができますが、このホワイト ペーパーの内容以外にも、組織の内部環境や既存の障害回復方針に関する具体的な情報を必ず参照してください。

ページのトップへ ページのトップへ

Active Directory の概要

Active Directory サービスは Windows 2000 のディレクトリ サービスです。このサービスはオペレーティング システムの中核となるコンポーネントであり、企業と OS 内部のコンポーネントに対して、必要不可欠なデータを提供します。

Active Directory は、管理者がネットワーク リソースの整理や、ユーザー、コンピュータ、およびアプリケーションの管理を行うための中心的なサービスを提供します。

Active Directory には次のような数多くのさまざまなオブジェクトを格納できます。

  • ユーザー

  • グループ

  • 証明書などのセキュリティ資格情報

  • コンピュータ (またはサーバー) やプリンタなどのシステム リソース

  • 複製コンポーネント (設定自体も Active Directory のオブジェクトになる)

  • COM コンポーネントの構成 (従来 Windows NT のレジストリに格納されていたもの。現在は Active Directory のクラス ストアに格納されている)

  • 作業環境を制御するためのルールおよびポリシー

下の図 1 は、Active Directory に格納され集中管理されている数多くのさまざまなオブジェクトを示しています。

adrecv01

図 1: Active Directory に格納できる多くのさまざまなオブジェクト

Active Directory データベース

Active Directory はトランザクションをベースとするデータベース システムであり、ログ ファイルを使用した役割バック セマンティクスをサポートし、トランザクションがデータベースにコミットされることを保証します。Active Directory に関連するファイルには次のものがあります。

  • Ntds.dit - データベース

  • Edbxxxxx.log - トランザクション ログ

  • Edb.chk - チェックポイント ファイル

  • Res1.log & Res2.log - 予約済みログ ファイル

Ntds.dit はデータベース格納量の増大とともに大きくなります。しかし、ログは固定サイズ (10 MB) です。データベースへの変更はすべて現在のログ ファイルにも追加され、そのディスク イメージは常に最新に保たれます。

Edb.log は現在のログ ファイルです。データベースに変更がなされると、その変更が Edb.log ファイルに書き込まれます。Edb.log ファイルがトランザクションでいっぱいになると、Edbxxxxx.log という名前に変更されます (00001 から始まりそれ以降は 16 進数表記を使用してカウントアップされます)。Active Directory は循環ログ機能を使用しているため、古いログ ファイルはいったんデータベースに書き込まれると継続的に削除されていきます。Edb.log ファイルは任意の時点において常に存在し、さらに Edbxxxxx.log ファイルが 1 つまたは複数存在する可能性があります。

Res1.log および Res2.log は "プレースホルダ" です。これらは (この場合には) このドライブ上の最後の 20 MB のディスク領域を予約するために置かれているもので、ほかの残りのディスク領域がいっぱいになった場合に安全なシャットダウンを行うための十分な領域をログ ファイルに確保しています。

Edb.chk ファイルはデータベースのチェックポイントを格納します。チェックポイントとは、データベース エンジンが一般に復旧や初期化の際にログを再生しなければならない場合のポイントを識別するものです。

パフォーマンス上の理由から、ディスクの競合を減らすためにログ ファイルはデータベースとは異なるディスク上に置くようにしてください。

バックアップを実行すると、その時点で新しいログ ファイルが作成されることがあります。このログ ファイルは既に説明した循環ログ機能のために (正規の古いログ ファイルと同様に) 後で削除されます。

Active Directory のサーバーと役割

ドメイン コントローラ (DC) はドメイン データベースのホストとなって認証サービスを実行するサーバーです。Windows 2000 Server では、ドメイン データベースは Active Directory データベースの一部です。Windows NT Server 4.0 ではオブジェクトの変更はプライマリ ドメイン コントローラ (PDC) 上だけで発生しますが、Windows 2000 では環境内にある任意の DC 上で発生する可能性があります。

DC は、環境内にあるすべての DC が必ずディレクトリの現在の状態を正確に反映するホストであることを保証するために、複製操作を起動し実行する必要があります。また、特定のフォレスト内にあるすべてのドメイン コントローラは、そのフォレストの構成コンテナおよびスキーマ コンテナのコピーのホストになります。

ドメイン コントローラはグローバル カタログにもなることができ、また後述する特別な役割を保持することもできます。障害が発生した場合は、適切な処置ができるように、特定の DC が GC または操作マスタ役割のホルダ (役割を保持しているサーバー) かどうかを知ることが重要になります。

グローバル カタログ
グローバル カタログの主な機能は、Active Directory フォレスト全体にわたって高速で効率的な検索を提供することです。GC は、それ自身がメンバとなっているドメイン内部にあるすべてのオブジェクトの読み書き可能で完全な複製物と、フォレスト内部のほかのすべてのドメインの読み取り専用の部分的な複製物 (すべてのオブジェクトについての部分的な属性セット) を保持しています。グローバル カタログのこのようなしくみにより、フォレスト内部のディレクトリ構造がエンド ユーザーに公開され、ディレクトリ内のオブジェクトの検索を簡単かつ効率的にする検索メカニズムが構築されます。

また、グローバル カタログはネイティブな Windows 2000 ドメイン内にあるユニバーサル グループ メンバシップおよびユーザー プリンシパル (UPN) を列挙するために必要なものでもあります。そのため、クライアントのログオン時に DC から GC にアクセスできなくなると、クライアントが受け取るものはすべてキャッシュされたローカル ログオン資格情報になり、リモート リソースへのアクセスが拒否されます。

メモ :
DC がグローバル カタログ サーバーかどうかを知るには、Active Directory サイトとサービス スナップイン内にある DC の ntdsDSA オブジェクトのプロパティを調べます (ドメイン コントローラの [Ntds 設定] を右クリックしてプロパティを選択します)。[グローバル カタログ サーバー] チェックボックスがオンにされていれば、その DC はグローバル カタログ サーバーです。このスナップインは稼動中の任意の DC で表示でき、障害を起こした DC が GC かどうかを調べることができます。

操作マスタ サーバー
Active Directory はマルチマスタ更新をサポートしています。各 DC は、そのディレクトリ パーティションの読み書き可能なホストになっています。したがって Active Directory では、異なる DC からディレクトリ内の同じオブジェクトを同時に変更するなど、競合の可能性のある変更操作を許可する必要があります。Active Directory は適切に定義された競合解決方法を使用し、最終的にすべての DC が同じ値を持つようにします。

この適切に定義された方法を使用する場合であっても、競合自体を防いだほうがイベント発生後に競合の問題を解決するよりも好ましい場合があります。Active Directory の操作マスタは、競合が適切に解決されないような場合に備えて更新の競合を防ぎます。

Active Directory では操作マスタに次の 5 つの役割が定義されています。

  • スキーマ マスタ

  • ドメイン名前付けマスタ

  • 相対識別子 (RID) マスタ

  • プライマリ ドメイン コントローラ エミュレータ (PDCE)

  • インフラストラクチャ マスタ

スキーマ マスタとドメイン名前付けマスタはフォレスト単位の役割です。つまり、フォレスト全体でスキーマ マスタとドメイン名前付けマスタがそれぞれ 1 つずつ存在します。その他の操作マスタ役割はドメイン単位の役割であり、フォレスト内の個々のドメインごとに独自の RID マスタ、PDCE、およびインフラストラクチャ マスタが存在します。

どの DC がドメイン名前付けマスタ役割を所有しているかを調べるには、[Active Directory ドメインと信頼関係] スナップインを開きます。スキーマ マスタを調べるには、[Active Directory スキーマ] スナップインを開きます。任意のドメイン単位の役割については、[Active Directory ユーザーとコンピュータ] スナップインを調べます。各スナップインの (左ペインにある) 一番最初のコンテナで、右クリックして操作マスタを選択します。

スキーマ スナップインは Windows 2000 Server に付属の既定の MMC スナップインの 1 つではありません。利用可能なスナップインの一覧に表示するためには、Windows 2000 Server CD から管理ツール パッケージ (Adminpak.msi) をインストールする必要があります。

スキーマ スナップインを登録するには、コマンド プロンプトまたは [スタート] メニューの [ファイル名を指定して実行] コマンドで、「Regsvr32 schmmgmt.dll」と入力します。

スキーマ マスタ
スキーマ マスタ役割を保持している DC は、ディレクトリ スキーマを更新できるただ 1 つの DC です。これらのスキーマ更新は、スキーマ マスタからフォレスト内のほかのすべてのドメイン コントローラに複製されます。

ドメイン名前付けマスタ
ドメイン名前付けマスタ役割を保持している DC は、次の処理を実行できるただ 1 つの DC です。

  • 新しいドメインをフォレストに追加する。

  • 既存のドメインをフォレストから除去する。

  • 外部ディレクトリを表現している相互参照オブジェクトを追加または除去する。

相対識別子 (RID) マスタ
この操作マスタは、ほかの DC への RID プールの割り当てを管理します。この作業を実行するのはただ 1 台のサーバーだけです。ユーザー、グループ、またはコンピュータなどのセキュリティ プリンシパルを作成するときは、ドメイン全体で有効な識別子を RID と組み合わせ、一意セキュリティ識別子 (SID) を作成する必要があります。

すべての Windows 2000 DC は、オブジェクトの作成に使用できる RID (既定は 512) のプールを受け取ります。RID マスタにより、異なるプールを割り当てることでこれらの ID がすべての DC 上で必ず一意になり続けます。同じフォレスト内にあるドメイン間でのオブジェクトの移動はすべて RID マスタを通して処理されます。

PDCE
プライマリ ドメイン コントローラ エミュレータは次に示す重要な機能を提供します。

  • 下位レベルのクライアントおよびサーバーに対する下位互換性。これにより、Windows NT4.0 バックアップ ドメイン コントローラ (BDC) が新しい Windows 2000 環境に参加できるようになります。

  • ネイティブの Windows 2000 環境から PDCE へのパスワード変更の通知。DC はパスワードの認証に失敗するたびに PDCE にアクセスし、そのパスワードが PDCE で認証可能かどうかを確かめます。これは認証を実行している DC に変更がまだ複製されていない場合に対処するためです。

  • 時間の同期。フォレスト内部にあるドメインの PDCE は、そのフォレストのルート ドメインにある PDCE と同期をとります。

インフラストラクチャ マスタ
インフラストラクチャ マスタは、ドメイン間のすべての操作に対してオブジェクトの一貫性を保証するものです。別のドメインからのオブジェクトが参照されるとき、この参照にはそのオブジェクトのグローバル一意識別子 (GUID)、セキュリティ識別子 (SID)、そして区別名 (DN) が含まれています。参照先のオブジェクトが移動した場合、ドメイン内でインフラストラクチャ マスタ役割を保持している DC は、そのドメイン内でのドメイン間オブジェクト参照について SID と DN を更新する役割を負います。

Active Directory の複製

Windows 2000 の各 DC は、個々のドメインに所属しているすべてのオブジェクトの複製物を保持し、それらのオブジェクトへの完全な読み書き可能なアクセス権を持っています。そのため、ドメインの管理はそのドメインに参加している任意の DC を通して実行できます。これらのドメイン管理操作はオブジェクトの状態に影響を与えるため、ほかの DC に複製する必要があります。

複製とは、オブジェクトの更新を DC 間に伝播させる処理のことです。

変更されたオブジェクトの複製はすぐには起こりません。複製は、ある一定の時間が経過した後に起動し、すべての変更を収集した後、それらの変更をほかの DC にまとめて提供します。その結果、任意の DC 上における Active Directory の通常の操作は、常に緩やかな一貫性の状態にあるとみなすことができます。つまり、複製の変更が途中でほかの DC から伝わってきたり、あるいは起動されるまで待っていたりするために、Windows 2000 環境内にあるすべての DC の情報が異なる可能性がある、ということです。最終的には変更が DC に到達し、DC 相互の間で同期がとられます。

複製、および "緩やかな一貫性" という概念は、Active Directory の復旧手段を検討する上で重要な概念です。

ページのトップへ ページのトップへ

Active Directory のバックアップ

Active Directory の障害回復計画における重要な要素の 1 つに、Active Directory のバックアップに伴う暗黙事項や検討事項を理解する、ということがらがあります。

システム状態

Active Directory はシステム状態の一部としてバックアップされます。システム状態とは、互いに依存関係を持つシステム コンポーネントの集合のことで、これらのコンポーネントもいっしょにバックアップ (および復元) する必要があります。

ドメイン コントローラ上のシステム状態を構成するコンポーネントには次のものがあります。

システム スタートアップ ファイル ( 起動ファイル ) : Windows 2000 の起動に必要なファイルです。これらはシステム状態の一部として自動的にバックアップされます。

システム レジストリ : レジストリの内容は、システム状態データのバックアップ時に自動的にバックアップされます。また、レジストリ ファイルのコピーが %SystemRoot%\Repair\Regback というフォルダに保存され、これによりシステム状態を完全に復元しなくてもレジストリを復元できます。

COM+ のクラス登録データベース : コンポーネント オブジェクト モデル (COM) は、分散システム環境においてコンポーネント ソフトウェアを記述するためのバイナリ標準です。コンポーネント サービス クラス登録データベースがシステム状態データとともにバックアップおよび復元されます。

SYSVOL : システム ボリュームは、ドメイン全体を通じた共通アクセスのために共有する必要のあるファイルの、Active Directory における既定の格納場所です。ドメイン コントローラ上の SYSVOL フォルダには次のものが収められています。

  • ネット ログオン共有。通常、これらの共有は Windows 2000 以外をベースとするネットワーク クライアント用のログオン スクリプトおよびポリシー オブジェクトのホストになっています。

  • ファイル システム結合。

  • Windows 2000 Professional ベースのクライアント、および Windows 95、Windows 98、または Windows NT 4.0 が動作しているクライアントのための、ユーザー ログオン スクリプト。

  • Windows 2000 グループ ポリシー。

  • ファイル複製サービス (FRS) のステージング ディレクトリおよびファイル。これらはドメイン コントローラを使用可能にし、ドメイン コントローラ間で同期をとるために必要とされます。

Active Directory : 次のものがあります。

  • Ntds.dit - Active Directory データベース。

  • Edb.chk - チェックポイント ファイル。

  • Edb*.log - トランザクション ログ。それぞれのサイズは 10 MB。

  • Res1.log および Res2.log - 予約済みトランザクション ログ。

メモ :
Active Directory 統合型 DNS を使用している場合、ゾーン データは Active Directory データベースの一部としてバックアップされます。Active Directory 統合型 DNS を使用していない場合は、ゾーン ファイルを明示的にバックアップする必要があります。しかし、システム ディスクをシステム状態といっしょにバックアップすれば、このデータはシステム ディスクの一部としてバックアップされます。

クラスタ サービスまたは証明書サービスをドメイン コントローラにインストールしている場合、それらはシステム状態の一部としてバックアップされます。これらのコンポーネントの詳細についてはこのホワイト ペーパーでは説明しません。

バックアップの種類

Windows 2000 のバックアップ ツールは次に示すいくつかの種類のバックアップをサポートしています。

  • 通常

  • コピー

  • 増分

  • 差分

  • 毎日

しかし、Active Directory はシステム状態の一部としてバックアップされるため、Active Directory で利用できるバックアップの種類は通常だけです。通常バックアップでは、ドメイン コントローラがオンラインでいる間にシステム状態全体のバックアップが作成されます。また、各ファイルがバックアップ済みとしてマークされ、ファイルのアーカイブ属性がクリアされます。

適切なバックアップとは

バックアップからの正常な復元を確実にできるようにするためには、"適切なバックアップ" の定義について理解することが重要です。Active Directory においては次の 2 つのことがらについて検討する必要があります。

  • 内容

  • 期限

内容
バックアップで最初に重要となる観点は、その内容です。適切なバックアップには、少なくともシステム状態、システム ディスクの中身、および SYSVOL フォルダ (システム ディスク上にない場合) が含まれます。既に説明したように、システム状態にはドメイン コントローラを復元するための重要なファイルや設定が多数含まれています。システム ディスクと SYSVOL フォルダ構造をバックアップすることで、正常な復元を開始するための準備として必要なすべてのシステム ファイルおよびフォルダが、適切な場所に置かれたことになります。

メモ :
最適なパフォーマンスを実現するためには、Active Directory のログおよびデータベース ファイルを異なるスピンドル (ディスク) 上に配置するのが良いとされています。既にこの方式で DC を設定しているのであれば、Active Directory のコンポーネントは、たとえばログ用に D:\Winnt\NTDS、データベース用に E:\Winnt\NTDS、というように、複数のドライブに分散して配置されています。

Active Directory のログ ファイルおよびデータベースはシステム状態の一部としてバックアップされるため、このような分散インストールの状況であっても、システム ディスクとシステム状態だけをバックアップすることで適切なバックアップが保証されます。

期限
バックアップの有効期間が Active Directory 内で設定されている廃棄 (Tombstone) 期限よりも長い (古い) と、適切なバックアップであるとはみなされません。

Windows 2000 でオブジェクトが削除されると、オブジェクトが削除された DC は環境内にあるほかの DC に対して、削除標識 (Tombstone) と呼ばれるものを複製することで削除について通知します。

削除標識とは、ディレクトリから削除はされたもののまだ完全には除去されていないオブジェクトを表現するものです。削除標識は廃棄期限の設定に基づいて最終的に除去されます。廃棄期限は既定で 60 日に設定されています。DC がオブジェクトの削除前の状態に復元され、そのオブジェクトの削除標識が復元された DC に複製されていない場合、廃棄期限が切れると、そのオブジェクトは復元された DC 上にだけ存在し続けることになり、結果として矛盾を生じます。したがって、DC を廃棄期限が切れる前に復元すること、および、その削除標識のある DC から復元された DC への入力方向の複製を廃棄期限が切れる前に完了することが、重要になります。

Active Directory は、廃棄期限よりも古いデータについて、その復元を禁止することによって自分自身を保護しています。その結果、バックアップの有効な期限は企業で設定されている "廃棄期限" に等しくなります。

このことから、バックアップの間隔は廃棄期限の範囲内で少なくとも 1 回設けるようにします。これとは別に、管理者はシステム状態とシステム ディスクを頻繁にバックアップし、最新版のデータを保持しているバックアップがいつの時点でも確実に利用できるようにしてください。

重要
DC からのバックアップ データはその DC の復元のためにだけ使用できます。ある DC のバックアップを使用して別の DC を復元することはできません。環境を完全にバックアップするためにはすべてのドメイン コントローラについてバックアップをとる必要があり、バックアップ方針を検討する際はこのことを常に念頭においてください。最低でも、OM 役割を保持しているすべてのサーバーおよび GC をバックアップすることが必要です。また、ルート ドメイン内にある 1 番目のドメイン コントローラも常にバックアップしてください。

必要な権限

Windows 2000 では、バックアップ権限と復元権限は互いに独立しています。Active Directory をバックアップするには、Backup Operators グループまたは Administrators グループのどちらかのメンバである必要があります。

バックアップのパフォーマンス

アクティブな DC のバックアップに要する時間を理解することは、ビジネスの最適なバックアップ方針を決定する上で重要なことがらです。参考として、次の図 2 のグラフでは、さまざまなサイズの Active Directory データベースのをバックアップについて、いくつかの指標となる所要時間の例を紹介しています。

ドメイン コントローラのバックアップは DC がオンラインである間に実行されるため、この時間については大きな問題ではありません。しかし、バックアップのスケジュールをピーク時に計画することは、ドメイン コントローラのほかの活動に対するパフォーマンスに影響を与える可能性があり、好ましくありません。

次に示しているテストでは、バックアップされたデータはシステム状態だけを対象としたものです。適切なバックアップの定義にはシステム ディスクおよび SYSVOL のバックアップも含まれるため、追加されるファイルの量に応じて、適切なバックアップに要する時間が若干長くなります。また、テープ ドライブの速度やシステム構成によってその結果が異なります。

adrecv02

図 2: さまざまなサイズの Active Directory データベースの所要バックアップ時間を示すグラフ

ページのトップへ ページのトップへ

Active Directory の障害回復フローチャート

以降このホワイト ペーパーでは、Active Directory の障害回復計画に伴う概念を具体化するために必要となる手順や検討事項について、詳しく説明します。図 3、4、5、および 6 の各フローチャートはこれらの手順を図示したものです。各手順についてはこの後のページで詳しく説明します。

メモ :
以下のフローチャートはすべてのあらゆる障害状況を示すものではなく、利用可能な選択肢とその適切な利用について理解を助けるものです。

障害の種類

障害に直面した場合、まず障害の種類を特定する必要があります。このホワイト ペーパーでは、起こりうる次の 2 種類の障害について、そのトラブルシューティングを中心に説明します。

  • データベースの損傷。次のいずれか 1 つが発生した状況を指します。

    • ディスクが損傷した。電源障害やバッテリーの異常のためにライトバック キャッシュが保存されないなど。

    • ドメイン コントローラに深刻なハードウェア障害が発生し、交換の必要が生じた。

    • ソフトウェア障害のため、コンピュータを標準モードで起動できなくなった。

  • データの損傷。管理者または適切な権限を持つ第三者が誤ってオブジェクトを削除してしまい、その削除が環境内部のほかの DC に複製されてしまった場合など。

adrecv03

図 3: 障害回復の選択肢

adrecv04

図 4: ディスク損傷に対する障害回復手順
拡大表示する

adrecv05

図 5: ドメイン コントローラのハードウェア障害に対する障害回復手順
拡大表示する

adrecv06

図 6: データ損傷に対する障害回復手順
拡大表示する

ページのトップへ ページのトップへ

Active Directory の復旧

Windows 2000 DC の復元には主に次の 2 つの方法があります。

  • 再インストールによる復元

  • バックアップからの復元

この節では、これらの操作を実行するための手順と関連する検討事項について詳しく説明します。

再インストールによる復元

この方法は、Active Directory の複製を全面的に利用して DC を正常な動作状態に復元するもので、同じドメイン内に別の正常な DC が存在している場合にだけ有効です。Windows 2000 オペレーティング システムを再インストールすると、そのコンピュータは障害発生前に存在していたドメイン内で再び DC に昇格されます。この処理の間、標準の (昇格処理) DCPROMO オペレーションの間に発生する複製によって、その DC が Active Directory データベースの最新かつ正確なコピーを持つことが保証されます。この方法は、ドメイン コントローラの適切なバックアップが利用できないときだけに推奨されます。

再インストールによる DC の復元に関する検討事項

帯域幅に関する検討事項
複製を通して DC を復旧する際は、帯域幅が主な検討事項になります。複製を通して DC を復旧するのに要する帯域幅は、Active Directory データベースのサイズと、DC が正常機能の状態になるまでに要する時間に、比例したものとなります。

下の図 7 は、さまざまなネットワーク速度で新しい DC を既存のドメインに複製するのに要する時間を示しています。テストに使用した Active Directory データベース ntds.dit のサイズは 2 GB です。

メモ :
データ収集に使用したシステムは Compaq Proliant 1600 で、Pentium II 266 MHz のデュアル プロセッサ、256 MB の RAM、および 1 台のハード ディスク ドライブを搭載したものです。違うシステムを使用すれば結果が異なる場合もありますが、全体の傾向は一致すると考えられます。

adrecv07

図 7: さまざまなネットワーク帯域幅で 2 GB のデータベースを複製した場合の所要時間を示すグラフ

再インストールによる DC の復元に必要な手順
再インストールによる復旧は、新しい DC の作成と同じ処理になります。再インストールによる復元のためには、正常に機能している DC が対象ドメイン内に少なくとも 1 台存在することが必要です。理想的には、この方法に伴うネットワークへの影響および復元時間を減らすために、この DC が複製しようとしている DC (新しい DC) と同じ Active Directory サイトにあることが望ましいといえます。この方式の復元に関する帯域幅の効果の詳細については、上の図 7 を参照してください。

この処理では次の手順が必要になります。

  1. 障害を起こした DC オブジェクトを Active Directory から除去するなどのクリーンアップ操作を行います。

  2. Windows 2000 Server の新規コピーをインストールします。

  3. DCpromo.exe (AD インストール ツール) を実行し、このコンピュータをドメイン コントローラの役割に昇格させます。

クリーンアップ操作を次に説明します。手順 2 と手順 3 はこのホワイト ペーパーでは前提知識としています。昇格処理の詳細については、Windows 2000 Server リソースキットの『分散システム ガイド』を参照してください。クリーンアップ操作は、障害を起こしたコンピュータと同じ名前を新しい DC に付けるかどうかによって異なります。

新しい DC が障害を起こした DC と同じ名前を継承する場合は、障害を起こした DC の ntdsDSA オブジェクトを削除する必要があります。

  1. コマンドラインで「ntdsutil」と入力します。

  2. プロンプト ntdsutil: で「metadata cleanup」と入力してから Enter キーを押します。

  3. ここで、障害を起こした DC の ntdsDSA オブジェクトを削除しようとしている既存のドメイン コントローラに接続する必要があります。

  4. metadata cleanup プロンプトで「connections」と入力してから Enter キーを押します。

  5. 「connect to server <servername>」と入力してから Enter キーを押します。ここで、<servername> はメタデータのクリーンアップに使用する DC (同じドメイン内で正常に機能している任意の DC) です。

  6. 「quit」と入力してから Enter キーを押します。これで、メタデータ クリーンアップ メニューに戻ります。

  7. 「select operation target」と入力してから Enter キーを押します。

  8. 「list domains」と入力してから Enter キーを押します。これで、フォレスト内のすべてのドメインが個々に関連付けられている番号とともに一覧表示されます。

  9. 「select domain <number>」と入力してから Enter キーを押します。ここで、<number> は障害を起こしたサーバーのあったドメインに対応する番号です。

  10. 「list sites」と入力してから Enter キーを押します。

  11. 「select site <number>」と入力してから Enter キーを押します。ここで、<number> は DC がメンバとなっていたサイトの番号です。

  12. 「list servers in site」と入力してから Enter キーを押します。これで、そのサイト内のすべてのサーバーが対応する番号とともに一覧表示されます。

  13. 「select server <number>」と入力してから Enter キーを押します。ここで、<number> は削除する DC の番号です。

  14. 「quit」と入力してから Enter キーを押します。メタデータ クリーンアップ メニューが表示されます。

  15. 「remove selected server」と入力してから Enter キーを押します。

    この時点で、DC が正常に削除されたという確認を受け取ります。オブジェクトが見つからなかったというエラーを受け取った場合は、オブジェクトがすでに Active Directory から削除されている可能性があります。

  16. 「quit」と入力し、コマンド プロンプトに戻るまで繰り返し Enter キーを押します。

メモ :
この手順では構成名前付けコンテキストを変更する必要があるため、Enterprise Administrator の権限が必要です。

新しい DC に障害を起こした DC と異なる名前を与える場合には、さらに次の手順を実行します。

  • 障害を起こしたサーバー オブジェクトを [Active Directory サイトとサービス] スナップインから削除するには、次のようにします。

    1. [Active Directory サイトとサービス] スナップインを開きます。

    2. 該当するサイトを選択します。

    3. 障害を起こした DC に関連付けられているサーバー オブジェクトを削除します。

  • 障害を起こしたコンピュータ アカウントを [Active Directory ユーザーとコンピュータ] スナップインから削除するには、次のようにします。

    1. [Active Directory ユーザーとコンピュータ] スナップインを開きます。

    2. ドメイン コントローラ コンテナを選択します。

    3. 障害を起こした DC に関連付けられているコンピュータ オブジェクトを削除します。

注意 :
新しいコンピュータに障害を起こしたコンピュータと同じ名前を持たせる場合には、上の追加手順は実行しないでください。また、ハードウェア障害が問題の原因ではないことを確かめてください。障害のあるハードウェアを交換せずに再インストールを行うと、作業がむだになる恐れがあります。

バックアップからの復元

この方法は、主に障害発生前になされた最後の適切なバックアップを全面的に利用するものです。復元処理は、Windows 2000 バックアップ ユーティリティ、またはサポートされているサード パーティ製ユーティリティ (組織で選択したもの) のどちらかを使用して開始できます。この復元処理により、DC はバックアップ時点の状態に戻ります。その後、DC は自身の複製パートナー (1 つまたは複数) に対してバックアップ時以降発生した更新がないかを問い合わせます。変更がある場合はそれらが複製され、それによって DC が Active Directory データベースの最新で正確なコピーを持つことが保証されます。

また、バックアップから Active Directory を復元する場合、さらに 2 つの選択肢があります。

  • 権限のない復元 (Non-Authoritative Restore)

  • 権限のある復元 (Authoritative Restore)

これら 2 つの方法により、復元処理の間、システム状態のうちの 2 つの重要なコンポーネントである Active Directory および SYSVOL について操作できるようになります。これらのコンポーネントはいっしょに復元されますが、ここでは別々に説明します。

権限のない復元

Active Directory
権限のない復元は Active Directory 復元のための既定の方法であり、復元操作を行うたいていの場合にこれを使用します。この方法では、ドメイン、スキーマ、構成、およびオプションでグローバル カタログの各名前付けコンテキスト内にある設定およびエントリについて、バックアップ時点でのバージョン番号が維持されます。

権限のない復元の実行後は標準の複製手段、つまり、ある属性バージョン番号がその複製パートナー データベースに格納されている属性のバージョン番号よりも小さい (オブジェクトが最後のバックアップ以降変更されたことを示している) かどうか、という方法を使用して DC が更新されます。復元されるサーバー上のオブジェクトは、最後のバックアップ時点以降そのオブジェクトになされた変更によって更新されます。このため、データベースが最新であることが保証されます。

SYSVOL
SYSVOL に権限のない復元を実行すると、復元される DC に保持されているローカル コピーが、その複製パートナーのものと比較されます (MD5 チェックサム使用)。DC が再起動すると、その複製パートナー (1 つまたは複数) にアクセスし、SYSVOL 情報を比較して必要な変更を複製し、ドメイン内のほかの DC とともに SYSVOL を最新の状態にします。

この方法は、正常に機能している DC がドメイン内に少なくとも 1 台存在するときに使用してください。この方法は既定の SYSVOL 復元方法であり、Active Directory の権限のない復元が実行される場合に自動的に実行されます。

正常に機能しているほかの DC がドメイン内にない場合は、SYSVOL の "プライマリ" 復元を実行してください。プライマリ復元では、ローカル DC 上の SYSVOL のフォルダにあるデータをロードすることで、新しい ntfrs (Windows NT ファイル複製サービス) データベースが構築されます。この方法は SYSVOL が "プライマリ" としてマークされる点以外は権限のない復元と同じです。

権限のある復元

Active Directory
権限のある復元は、本質的には権限のない復元処理が拡張されたものです。権限のある復元ではその開始前に権限のない復元のすべての手順が必要になります。両者の主な違いは、権限のある復元ではディレクトリ全体のすべてのオブジェクト、サブツリー内のすべてのオブジェクト、または個々のオブジェクト (リーフ オブジェクトであると仮定) について、それらの属性のバージョン番号のカウントを増やしていき、それによってオブジェクトをディレクトリ内で権限のある (有効な) ものにする、という点です。

権限のない復元と同様に、いったんオンラインに戻された DC はその複製パートナーにアクセスし、最後のバックアップ時点以降発生した変更を調べます。しかし、有効にしようとしているオブジェクト属性のバージョン番号は、複製パートナーに保持されている属性の既存のインスタンスよりも大きくなるため、復元される DC 上のオブジェクトのほうが最新であるとみなされ、したがって環境内のその他の DC に複製されます。

権限のある復元は権限のない復元と異なり、別のツール (ntdsutil.exe) を使用する必要があります。これ以外のバックアップ ユーティリティは、ネイティブな Windows 2000 ユーティリティを含めてどれも権限のある復元を実行することはできません。

権限のある復元は、管理者が誤って多数のオブジェクトを削除してしまったときなど、人為的なエラーが関与している場合に使用してください。変更は既にすべての DC に複製されてしまっており、これらのオブジェクトはドメインから削除されています。そのため管理者はこれらのオブジェクトを簡単に再作成することはできません。

権限のある復元では、バックアップの実行後に作成された新しいオブジェクトが上書きされることはありません。権限のある復元は、構成コンテキストおよびドメイン コンテキストからオブジェクトに対してのみ実行できます。スキーマ名前付けコンテキストの権限のある復元はサポートされていません。

SYSVOL
SYSVOL に権限のある復元を実行すると、バックアップから復元された SYSVOL のコピーがそのドメインで有効であることを指定することになります。必要な構成が行われると、ローカルの SYSVOL が有効なものとしてマークされ、ドメイン内のほかの DC に複製されます。

Active Directory の権限のある復元と同様に、この方法は通常、人為的なエラーが関与していてそのエラーがほかのドメイン コントローラに伝播してしまったときに使用します。たとえば、管理者が SYSVOL 内に常駐しているグループ ポリシー オブジェクトなどのオブジェクトを誤って削除してしまったときなどに使用します。

SYSVOL の権限のある復元は Active Directory の権限のある復元の後に自動的に実行されるものではなく、追加の手順が必要になります。

これらすべての復元方法の詳細な手順については、この後このホワイト ペーパーの中で説明します。

Active Directory の復元に必要な権限
システム状態データを復元するには、その手順を実行する人物がローカル管理者である必要があります。

バックアップからの DC 復元に関する検討事項
複製からではなくバックアップから DC を復元することには、復元時間がより速くなるという明らかな利点があります。これを説明したのが下の図 8 のグラフで、500 MB から 2 GB までのさまざまなサイズのデータベースを持つバックアップから DC を復元するのに要した時間が示されています。テストに使用したコンピュータは Compaq Proliant 800 で、400 MHz のプロセッサ、256 MB の RAM、および 4/8 GB の DAT ドライブを搭載したものです。

adrecv08

図 8: さまざまなサイズの DIT ファイルをバックアップから復元した場合の所要時間を表すグラフ

メモ :
このグラフはシステム状態の復元に要した時間だけを表しています。既に定義したような適切なバックアップの復元を行うためには、システム ディスクのサイズに応じてさらに長い時間がかかります。

Active Directory バックアップの有効期限
復元しようとしているバックアップが廃棄期限の間にとられたことを確認してください。廃棄期限は既定で 60 日に設定されています。Active Directory バックアップの有効期限の詳細については、このホワイト ペーパーの「適切なバックアップとは」の節を参照してください。

異なるハードウェアへのバックアップの復元
DC は異なるハードウェアに復元することが可能です。ただし、このためにはいくつかの問題について検討しておく必要があります。

  • 異なる HAL — 既定では、Hal.dll はシステム状態の一部としてバックアップされませんが、Kernel32.dll はバックアップされます。したがって、たとえばマルチプロセッサ環境をサポートするなどの目的で、異なる HAL を必要とするコンピュータにバックアップを復元しようとすると、新しい HAL および元の Kernel32.dll に関する互換性の問題に直面します。この問題を回避するためには、Hal.dll を元のコンピュータから明示的にコピーして新しいコンピュータにインストールする方法しかありません。また、新しいコンピュータはシングルプロセッサだけの使用に制限されることになります。

  • 互換性のない Boot.ini ファイル — Boot.ini ファイルのバックアップおよび復元を行った場合、新しいハードウェア構成との非互換性のために、起動に失敗することがあります。復元の前に、Boot.ini ファイルが新しいハードウェア環境に合わせて正しくなっていることを確認してください。

  • 異なるネットワーク カードまたはビデオ カード — 新しいハードウェアに異なるビデオ アダプタまたは複数のネットワーク アダプタがある場合は、それらをアンインストールしてからデータを復元します。コンピュータを再起動すると、標準のプラグ アンド プレイ機能によって必要な変更が行われます。

ディスク容量とパーティション構成
DC を異なるハードウェアに復元する問題のほかに、新しいコンピュータ上のパーティションが元のコンピュータ上のものと同じかどうか、ということも重要になります。特に、すべてのドライブ マッピングが必ず同一であること、および、パーティションのサイズが元のコンピュータのサイズと少なくとも同じであることが必要です。

権限のある復元に関するその他の検討事項
バックアップからの DC の復元では、特に権限のある復元を実行する際に、上記のような検討事項のほかにも次の点について検討が必要です。

グループ メンバシップへの影響
障害回復において権限のある復元方法から発生する最も重大な問題となるのが、グループ メンバシップへの影響、つまりグループ メンバシップの情報が失われる危険性を負うことです。

グループ メンバシップは多値属性です。また、一方向リンクであるために逆リンクや削除は Active Directory 内で処理されます。そのため、グループ メンバシップの表現に関して権限のある復元の結果はさまざまに異なります。このような違いは、権限のある復元の後にユーザー オブジェクトまたはグループ オブジェクトのどちらのオブジェクトが最初に複製されるかによって決まります。

ユーザーの削除取り消しが最初に複製された場合は、グループ (その中のメンバ) およびユーザー (ユーザーが所属しているグループ) の両方のグループ メンバシップ情報が正しく表現されます。

グループの削除取り消しが最初に複製された場合、複製パートナーでは (ローカルに) 削除されたユーザーの追加がグループ メンバシップから除外されます。ただし、ユーザーのプライマリ グループは唯一の例外であり、プライマリ グループはユーザーおよびグループの両方の参照から常に正しく表現されます。

残念ながら、権限のある復元の実行完了後にどちらのオブジェクトが最初に複製されるのかを特定する手段はありません。この状況によって環境に影響が出る場合は、権限のある復元を実行した DC 上にあって影響を受けるグループについて、それらのグループ メンバシップ属性を修正する方法しかありません。

この問題は、復元したデータの整合性に起因するものではなく、データの複製方法に起因するものです。この DC を調べることで、管理者はディレクトリの本来のあるべき姿を確認し、正確なディレクトリ情報をドメイン内のほかの DC に複製するための手順を実行できます。

このための最適な方法は、権限のある復元に関係する各グループに対して、ダミーのユーザーを追加してから同じダミー ユーザーを削除する、という方法です。

上の文章で "関係" という言葉は、それ自身が権限のある復元が行われたグループ、または、そのグループを自分の "プライマリ グループ" として定義しなかったメンバが復元された各グループの、どちらかを意味しています。

この方法を実行することで、正しいグループ メンバシップ情報がソース DC (元の権限のある復元が実行された DC) から強制的に複製され、その複製パートナー上でグループ メンバシップ情報が更新されるようになります。更新されたこれらのオブジェクトによって、正しいメンバシップが反映され、復元されたユーザー オブジェクトの [所属するグループ] タブで正しく表現された情報を確認することができます。

環境内のほかのすべての DC については、それらの (影響を受けたグループおよびユーザーの) グループ メンバシップに対して絶対に修正を加えないでください。

このことを厳密に守らないと、(復元を行った DC 上に保持されている) ディレクトリの正確なバージョンが不正なメンバシップ情報によって損なわれる危険性があります。この問題が起きた場合は、グループ メンバシップを手作業で更新しなければならないか、あるいは、別に verinc オプションを使用してオブジェクトの権限のある復元を実行し、上に示した処理を再度実行する必要が生じます。

信頼関係およびコンピュータ アカウントへの影響
Windows 2000 では、信頼関係およびコンピュータ アカウントのパスワードは指定されたインターバルでネゴシエートされます。既定では、それらについて 30 日のインターバルが指定されています。

権限のある復元の方法を使用したとき、信頼関係およびコンピュータ アカウントを保持している Active Directory 内のオブジェクトで、以前に使用したパスワードが復元されることがあります。

信頼関係の場合、これによってほかのドメイン コントローラからのほかのドメインへの通信に影響が出ることがあり、ドメイン境界を超えてリソースにアクセスしようとするときに権限エラーが起こります。この問題を修正するには、Windows 2000 または下位レベルのドメインへの NTLM 信頼関係を削除してから再作成する必要があります。

コンピュータ アカウント パスワードの場合、これによってメンバのワークステーションまたはサーバーと、そのドメインの DC との間における通信に影響が出る可能性があります。通常この影響は、Windows NT または Windows 2000 コンピュータのユーザーが無効なコンピュータ アカウントのために認証に問題が生じる、というかたちで現れます。

信頼関係の再作成、およびコンピュータ アカウント パスワードの再設定の両方の作業を支援するために、Windows 2000 CD のサポート ツールに付属の NETDOM ユーティリティを使用することができます。

メモ :
Windows NT 4.0 コンピュータではパスワードが 7 日ごとに変更されます。

SYSVOL 複製の帯域幅に関する検討事項
Active Directory の権限のある復元を実行するときは、SYSVOL の権限のある復元も実行する必要があります。これにより、復元される DC 上の SYSVOL 情報が有効であることをドメイン内のほかの DC に伝えることになります。その結果、復元される DC 上にある SYSVOL 全体がドメイン内のほかのすべての DC に (複製パートナーを経由して) 複製されます。

このような複製に伴う帯域幅については、大規模なグループ ポリシーおよびスクリプトを広範囲に使用しているようなドメインにおいてのみ、検討すべき事項です。また、Active Directory の複製とは異なり、FRS の複製はサイト間で圧縮されません。

権限のない復元に必要な手順
Windows 2000 のネイティブのバックアップ ユーティリティを使用して権限のない復元を実行するには、この節で説明する手順に従ってください。

注意 :
オペレーティング システムを再インストールする場合は、コンピュータをドメインに参加させるかどうかは自由であり、オペレーティング システムのセットアップ時にコンピュータに任意の名前を付けることができます。**コンピュータをドメインコントローラに昇格させることは絶対にしないでください。**オペレーティング システムを再インストールしたら、下の手順 4 に進んでください。

  1. 対象システムを再起動し、スタートアップ時に F8 キーを押して、ディレクトリ サービス復元モードにします。

  2. [ディレクトリ サービス復元モード (Windows 2000 DC のみ)] を選択します。

  3. 復元モードで起動したいオペレーティング システムを選択します。

  4. 管理者としてログオンします (ローカル システム アカウント、ドメインは選択できません)。

  5. Windows 2000 バックアップ ユーティリティを実行し、[復元ウィザード] ボタンを選択します。

  6. 適切なバックアップ場所を選択し、少なくともシステム ディスクとシステム状態の各コンテナのチェックボックスがオンにされていることを確認します。

  7. [詳細設定] ボタンをクリックし、接続点 (手順 9 を参照) を復元しようとしていることを確認します。詳細設定メニューを通して作業を続けないと復元処理が正常に完了しません。

  8. [ファイルの復元先] ドロップダウン ボックスで [元の場所] を選択します。

  9. [詳細な復元オプション] ウィンドウで、[セキュリティを復元する]、[接続点を復元し、接続点の以下のファイルやフォルダのデータを元の場所に復元する]、[結合ポイント配下にあるファイルおよびフォルダのデータを元の場所に復元する]、[既存のボリュームのマウント ポイントを保持する] の各チェックボックスをオンにします。下の図 9 を参照してください。

    adrecv09

    図 9

  10. [OK] ボタンをクリックします。

  11. 作業が完了したら [はい] をクリックしてコンピュータを再起動します。

これでシステムが再起動し、最後のバックアップ以来発生した新しい情報をその複製パートナーを使用して複製します。

Active Directory に対して権限のない復元を実行することで、SYSVOL の権限のない復元が自動的に実行されるため、これ以上の手順は必要ありません。SYSVOL のプライマリ復元に対しては、[詳細な復元オプション] ダイアログで次の表示の横にある 4 番目のボックスがオンにされていることを確認します。

[複製されたデータ セットを復元するとき、復元されたデータの複製物をプライマリ データとしてマークする]

プライマリ復元は、復元しようとしている DC がドメイン内でただ 1 つの DC である場合にだけ必要です。

権限のある復元に必要な手順
権限のある復元は、ディレクトリ全体、サブツリー、またはディレクトリ内の個々のオブジェクト (リーフ オブジェクトであると仮定) に対して実行できます。以下に示す例では、ディレクトリ全体とディレクトリのサブツリーの両方を復元する方法について詳しく説明します。

権限のある復元 - ディレクトリ全体
ディレクトリ全体の権限のある復元は重要な操作であるため、Microsoft のサポート担当者によるコンサルティングを受けた場合にだけ実施してください。DC がドメイン内でただ 1 つの DC である場合には、ディレクトリ全体の権限のある復元は実行しないでください。

権限のない復元における最初の 10 の手順を実行します。コンピュータの再起動をたずねられた時点で、それを拒否します。これは、システム状態を代わりの場所に再度復元しなければならなくなるためです。次の手順に従って作業を続けます。

  1. [復元] タブをクリックします。

  2. [ファイルの復元先] ドロップダウン リストで [場所の指定] を必ず選択します。

    [場所の指定] を選択すると、システム状態が代わりの場所に復元されます。システム ディスクを代わりの場所に復元する必要はないため、このボックスはシステム状態に対してだけオンにしてください。システム状態を代わりの場所に復元すると、SYSVOL、起動ファイル、およびレジストリだけが代わりの場所に復元されます (Active Directory はここには復元されません)。この処理は SYSVOL の権限のある復元を有効にするために行います。ディレクトリ全体が復元されたら、代わりの場所にあるファイルを削除してもかまいません。

  3. 復元処理が完了したら、バックアップ アプリケーションを閉じます。

  4. コマンド プロンプトを開き、「ntdsutil」と入力して Enter キーを押します。

  5. 次のプロンプトで、「authoritative restore」と入力して Enter キーを押します。

  6. 次のプロンプトで、「restore database」と入力します。

  7. [Authoritative Restore の確認ダイアログ] ボックスで、[OK] をクリックします。

  8. アプリケーションを終了するまで 「Quit」と繰り返し入力します。

  9. サーバーを再起動します。

    これで、サーバーがドメインの有効な DC になり、変更情報が環境内のほかの DC に複製されます。

  10. システムの再起動が完了したら、SYSVOL 共有が公開された &quot 後 &quot に (SYSVOL 共有とそのサブ フォルダがドメイン コントローラに表示されるまでに数分間かかることがあります)、代わりの場所にコピーした必要なファイルおよびフォルダを、SYSVOL ディレクトリから元の場所にコピーします。これにより、上書きされたファイルがほかのドメイン コントローラに複製され、その結果 SYSVOL がバックアップ時点の状態と同じになります。

以下は、SYSVOL を代わりの場所から元の場所にコピーする例です。ドライブやフォルダの情報はシステムによって異なります。

スクリプト ディレクトリの内容を次の場所からコピーして、

c:\< 代わりの Sysvol 場所 >\sysvol\c_\winnt\Sysvol\Domain\scripts\

次の場所に追加します。

c:\Winnt\SYSVOL\Sysvol\domain\scripts\

ポリシー ディレクトリの内容を次の場所からコピーして、

c:\< 代わりの Sysvol 場所 >\sysvol\c_\winnt\Sysvol\Domain\policies\

次の場所に追加します。

c:\Winnt\SYSVOL\Sysvol\domain\policies\

SYSVOL の権限のある復元を行うことにより、復元される DC 上のファイルがドメインに対して有効になり、ほかの DC に複製されます。バックアップ後にポリシーに加えられた変更はすべて失われます。

たとえば、最後のバックアップの時点で "財務ポリシー" という名前のグループ ポリシーが存在していて、SYSVOL ディレクトリ内のフォルダから、次のように参照されていたとします。

C:\WINNT\SYSVOL\Sysvol\Domain.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

しかし、最後のバックアップの直後に管理者が財務ポリシーを編集し、ポリシーのプロパティが変更されたにもかかわらず、GPO の GUID は同じままでした。この結果、このポリシーは依然として同じディレクトリ名 {31B2F340-016D-11D2-945F-00C04FB984F9} として参照されます。

ディレクトリの権限のある復元を行った時点で、フォルダ {31B2F340-016D-11D2-945F-00C04FB984F9} は代わりの SYSVOL 場所から元の SYSVOL 場所にコピーされます。これにより古いフォルダが置き換えられ、管理者がバックアップ後に加えた変更は失われます。ただし、この手順は Active Directory と SYSVOL との同期を維持するために必要なものです。

権限のある復元 - サブツリー
この権限のある復元の方法では、Active Directory の特定のコンポーネントを復元し、それらをディレクトリに対して有効にします。ディレクトリ全体を復元しなければならない状況はほとんどないため、この方法が権限のある復元における最も標準的なものといえます。

サブツリーの権限のある復元を実行するには、このホワイト ペーパーの「権限のある復元 - ディレクトリ全体」の節に示した手順に従いますが、そのうちの手順 6 を次の手順に置き換えてください。

  1. 「RESTORE SUBTREE <path> 」と入力します。たとえば、「RESTORE SUBTREE OU=Sales,OU=Sydney,DC=Whitepaper,DC=com」というように入力します。

これで、このサーバーは指定したパスに対して有効な Active Directory ドメイン コントローラになります。変更情報はドメイン内のほかの DC に複製されます。

ここでは Active Directory の一部だけを復元しようとしているため、SYSVOL の権限のある復元を実行する必要はありません。しかし、権限のある復元を行ったサブツリーまたはオブジェクトにグループ ポリシーなど SYSVOL からの要素が含まれていた場合には、SYSVOL のその部分についても権限のある復元を行ってください。

この作業が必要な場合は、このホワイト ペーパーの「権限のある復元 - ディレクトリ全体」の手順 10 を必ず完了してください。

メモ :
個々のオブジェクトの権限のある復元は、そのオブジェクトがリーフ オブジェクトである場合にだけ実行できます。オブジェクトとその子オブジェクトがいっしょに復元され有効になります。

ディレクトリのサブツリーの権限のある復元を行った場合でも、そのサブツリーを ntdsutil ツールを使用して有効としてマークする前に、権限のない復元方法を使用してディレクトリ全体の完全な復元を実行する必要があります。

復元の成否の確認
ドメイン コントローラが復元後に正常に機能しているかどうかを調べるためのテストにはいくつかの方法が考えられますが、復元の成否を確認するために実行すべきテストとしては次の 2 つの基本的なテストが挙げられます。

標準モードでの再起動
ドメイン コントローラが正常に標準モードで起動できれば、ディレクトリが正常に初期化できています。特に、DC が復元前に標準モードに起動できなかった場合にはこの判断が正しいといえます。

ディレクトリ サービスのイベント ログにエラー メッセージがないか調べる方法
復元処理に関するエラー メッセージがないか、ディレクトリおよびシステムの各イベント ログで調べます。

ドメイン コントローラがその近接ドメイン コントローラと認証できているかどうか調べる方法
これには repadmin ツールを使用します。このツールは主として、復元されたドメイン コントローラがほかのドメイン コントローラとともに認証でき、変更情報を複製してそのディレクトリのコピーを更新できるかどうかを調べるために使用します。このような動作ができることは、ドメイン コントローラの処理にとってきわめて重要なことです。

最初の確認は、復元されたドメイン コントローラの入力方向パートナーを取得することです。以下の各オプションを使用します。

D:\>repadmin /showreps 
testlab\test-machine3 
DSA Options : (none) 
objectGuid  : a07b44e6-76ba-4f03-80c9-5a4a256347bb 
invocationID: 6037d0c3-2194-4f27-95ed-578b38861414 

==== INBOUND NEIGHBORS ====================================== 

CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microsoft,DC=com 
    testlab\test-machine1 via RPC 
        objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 
        Last attempt @ 2000-09-08 14:10.16 was successful. 

CN=Configuration,DC=testdom,DC=nttest,DC=microsoft,DC=com 
    testlab\test-machine1 via RPC 
        objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 
        Last attempt @ 2000-09-08 14:10.16 was successful. 

DC=testdom,DC=nttest,DC=microsoft,DC=com 
    testlab\test-machine1 via RPC 
        objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 
        Last attempt @ 2000-09-08 14:10.16 was successful.

上の例の場合、復元された DC は test-machine 3 です。テストは復元されたコンピュータで実行したものですが、ツールはどのドメイン コントローラからでも使用できます。上の例では test-machine 1 が入力方向のパートナーです。

次のコマンドは、復元されたドメイン コントローラ上のスキーマ名前付けコンテキストについて、その入力方向の近接 DC からの変更情報との同期 (sync) を試みます。

D:\>repadmin /sync <naming context> <destination DSA> <source DSA GUID> 

D:\>repadmin /sync "CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microso 
ft,DC=com" test-machine3 465848f9-5446-4176-a504-59629c7a8fd8 
Sync from 465848f9-5446-4176-a504-59629c7a8fd8 to test-machine3 completed successfully.

この後、内方向隣接 DC と復元されたドメイン コントローラとの同期を試みるために同じコマンドを実行し、出力方向の複製が機能しているかどうかを確かめることもできます。

D:\>repadmin /sync "CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microso 
ft,DC=com" test-machine1 a07b44e6-76ba-4f03-80c9-5a4a256347bb 
Sync from a07b44e6-76ba-4f03-80c9-5a4a256347bb to test-machine1 completed successfully.

同期が正常に終了すれば、ドメイン コントローラは近接のドメイン コントローラと認証ができており、そこから変更情報を受け取ります。同期が正常に終了しなかった場合には、復元されたドメイン コントローラのコンピュータ アカウント パスワードが古く、入力方向のパートナーが復元されたドメイン コントローラを認証できないという可能性があります。この場合は netdom ツールを使用し、入力方向複製物のドメイン コントローラのパスワードと復元されたドメイン コントローラのパスワードとを同じに設定してください。netdom ツールの詳細については、Windows 2000 CD の Windows 2000 サポート ツールを参照してください。

権限のある復元を確認するその他の方法
以上の手順のほかにも、権限のある復元を行ったオブジェクトがディレクトリに表示されることを確認することが必要です。

また、Repadmin コマンドライン ツールを使用し、ディレクトリまたはサブツリーのバージョン番号カウントの増分を調べることで権限のある復元の成否を確認することもできます。これには /showmeta コマンドを実行し、権限のある復元を実行したオブジェクトまたはサブツリーの正確な識別名を指定します。

ページのトップへ ページのトップへ

グローバル カタログ サーバーの復旧

グローバル カタログ サーバーを復旧するには、バックアップから復元するか、または新しい GC を割り当てて元の GC の損失を補うかの、どちらかを実行できます。

グローバル カタログ サーバーの復元に必要な手順

詳細はこのホワイト ペーパーの「バックアップからの復元」の節を参照してください。DC (バックアップの時点で GC として機能していた DC) を GC の役割に自動的に復元できるのは、バックアップからの復元による方法だけです。再インストールによる復元方法を使用して DC を復元する場合は、GC の役割が自動的に復活することはありません。GC をバックアップから復元する際は、マルチドメイン環境において通常のドメイン コントローラの復元に比べて時間がかかることに注意してください。

新しい GC の割り当てに必要な手順

GC を複数構成することで実際に悪い影響が出ることはないので、障害を起こした GC の非稼動時間が長くなることが予想される場合には、新しい GC を環境内に作成することもできます。特に、元の GC からのサービスを受けていたユーザー コミュニティが GC にアクセスできなくなった場合、あるいは Exchange 2000 を実行していた場合などで環境内で GC サービスの必要性が高かった場合には、この方法が適切といえるでしょう。

新しい GC を有効にするには、Windows 2000 Server ヘルプの「グローバル カタログを有効または無効にするには」の節で説明されている手順に従ってください。

メモ :
フォレスト内で複数の GC を構成すると、システムの可用性は高まりますが、同時に複製トラフィックとデータベース サイズの増大という犠牲が伴います。障害を起こした DC をあえて再インストールし、その役割を GC として管理する場合は、その DC が存在しない間に構成した可能性のある追加の GC をすべて削除することもできます。

ページのトップへ ページのトップへ

操作マスタの復旧

操作マスタ (OM) が利用できなくなった場合、その役割を復活させるには次のどちらか 1 つを実行する方法しかありません。

  • 障害を起こした操作マスタをバックアップから復元する。

  • 役割を強制し、環境内のほかの DC に付与する。この方法は元の役割のホルダがバックアップから復元されないときだけ実行します。

メモ :
再インストールによる OM サーバーの復元では、その元の役割の状態は復元されません。しかし、再インストール後に、役割を保持しているほかの DC から役割を安全に転送し直すことは可能です。

OM は FSMO (Flexible Single Master オペレーション) 役割のホルダとも呼ばれます。

操作マスタ役割の強制

強制は強制転送とも呼ばれ、元の役割ホルダと協調することなく実行される処理です。つまり、元の役割ホルダが障害を受けたときに役割を強制し、ドメイン内またはフォレスト内の別の DC に強制的に移動することができます。

OM 役割の強制に必要な処理は 5 つの役割すべてについて同様ですが、強制に伴う検討事項については役割ごとに異なります。これらについてはこのホワイト ペーパーの後で説明します。

メモ :
このホワイト ペーパーでは OM 役割の安全な転送については説明しません。この処理が実行できる場合、元の役割ホルダはアクティブであり障害回復の状況に関与していないことになります。

操作マスタの強制に必要な手順

役割を強制しようとする DC は、以前の役割ホルダ上で実行された更新に関して完全に同期がとれている必要があります。この理由から、環境内で指定された予備の役割ホルダを極力既存の役割ホルダと同じサイト内に設置し、直接の複製パートナーにすることを推奨します。

環境において選択した予備の OM が最適であることを確認するには、Windows 2000 CD のサポート ツールの一部として付属している Repadmin ツールを使用して、その状態を確かめます。

例として、Whitepaper.com.au というドメインの操作マスタを SYD01 というサーバーと仮定し、SYD02 を指定された予備 OM とします。そして、これら以外にドメイン Whitepaper.com.au に存在するただ 1 つの DC として MEL01 を仮定します。

次の 2 つのコマンドを入力します。

C:\>repadmin /showvector dc=whitepaper,dc=com,dc=au SYD02.whitepaper.com.au

Sydney\SYD01 @ USN 4023
Melbourne\MEL01 @ USN 4087
C:\>repadmin /showvector dc=whitepaper,dc=com,dc=au MEL01.whitepaper.com.au
Sydney\ SYD01 @ USN 4018
Sydney\SYD02 @ USN 5017

SYD01 は本来の操作マスタであるため、ここで問題になるのはこれらの更新シーケンス番号 (USN) だけです。SYD02 の USN (4023) は MEL01 の USN (4018) よりも大きいため、SYD02 のほうが MEL01 よりも新しく、役割を想定する候補としてより適切であるといえます。

OM 役割を強制する最適な候補が決定したので、次の手順で OM 役割を強制します。

  1. コマンド プロンプトを開きます。

  2. 「NTDSUTIL」と入力します。

  3. ntdsutil のプロンプトで「roles」と入力します。

  4. FSMO maintenance プロンプトで「connections」と入力します。

  5. server connections プロンプトで「connect to server < サーバーの FQDN>」と入力します。たとえば、「connect to server syd02.whitepaper.com.au」というように入力します。

  6. server connections プロンプトで「quit」と入力します。

  7. FSMO maintenance プロンプトで「seize < 操作マスタ >」と入力します。たとえば、「seize schema master」というように入力します。

  8. ポップアップ ウィンドウで「Yes」をクリックし、強制を確認します。

  9. FSMO maintenance プロンプトで「quit」と入力します。

  10. ntdsutil のプロンプトで「quit」と入力します。

スキーマ マスタの復旧

スキーマ マスタ役割を強制するかどうかを決める際には、あらかじめ次のことについて検討してください。

環境への影響
最初に理解しなければならないことは、障害を起こしたスキーマ マスタが環境に与える影響です。主に次の問題に直面します。

スキーマに変更を加えることができない
スキーマ マスタが利用できなくなると、スキーマに変更を加えることが不可能になります。スキーマを変更しようとすると下の図 10 に示すようなメッセージが表示されます。

adrecv10

図 10

メモ :
表示されるメッセージの正確な内容は変更を加える際に使用する方法によって異なります。上のメッセージは、スキーマ マスタが利用できなくなった状態で Exchange 2000 をインストールしようとしたときに表示されたものです。

ほとんどの実稼動環境では、スキーマに変更を加える機会は少なく、またスキーマはあらかじめ適切に計画されているはずです。そのため、スキーマ マスタの停止状態が直ちに問題となることはまずありません。

スキーマ マスタに対して強制を実行する際の検討事項
スキーマ マスタ役割の強制を決定する際の主な検討事項は、その停止状態の期間と永続性です。スキーマ変更の重複が環境全体にわたって伝播する可能性があるため、スキーマ マスタ役割の強制は障害を起こした役割ホルダを "決してオンラインに戻さない" 場合にだけ、実行してください。

大部分の環境では、スキーマ マスタ役割の必要性も強制による影響もほとんどないことから、役割を保持している DC を復元する間は停止状態のままにしておくのがふつうです。しかし、何らかの理由でスキーマ マスタ役割を直ちに使用しなければならない場合や、元の役割ホルダが Windows 2000 環境にどうしても復帰しない場合には、強制を実行できます。

ドメイン名前付けマスタの復旧

ドメイン名前付けマスタ役割を強制するかどうかを決める際には、あらかじめ次のことについて検討してください。

環境への影響
最初に理解しなければならないことは、障害を起こしたドメイン名前付けマスタが環境に与える影響です。主に次の問題に直面します。

ドメインをフォレストに追加できない
このマスタが利用できなくなると、ドメインを Active Directory に追加できなくなります。下の図 11 は、ドメイン名前付けマスタ (Syd01.Whitepaper.com) が利用できない状態で DCPROMO を実行してドメインを追加しようとしたときに表示されるエラー メッセージです。

adrecv11

図 11

安定した実稼動環境では、このことが重大な問題になることはまずありません。しかし、開発中、試験中、または規模拡張中の環境においては、このマスタの障害によって復元または強制が行われるまで、規模の拡張が停止されることがあります。

ドメインをフォレストから削除できない
同様のメッセージは、ドメイン名前付けマスタ (Syd01.Whitepaper.com) が利用できない状態で DCPROMO を実行してドメインを削除しようとしたときにも表示されます。この場合、たとえば "指定された資格情報でサーバー syd01.Whitepaper.com に結合できませんでした。RPC サーバーが使用不可能な状態です。" といったメッセージが表示されます。繰り返しますが、このような問題は大多数の環境においては限定的な問題です。

ドメイン名前付けマスタに対して強制を実行する際の検討事項
ドメイン名前付けマスタ役割の強制を決定する際の主な検討事項は、その停止状態の期間と永続性です。ドメイン変更の重複が環境全体にわたって伝播する可能性があるため、ドメイン名前付けマスタ役割の強制は障害を起こした役割ホルダを "決してオンラインに戻さない" 場合にだけ、実行してください。

大部分の環境では、ドメイン名前付けマスタ役割の必要性も強制による影響もほとんどないことから、役割を保持している DC を復元する間は停止状態のままにしておくのがふつうです。しかし、何らかの理由でドメイン名前付けマスタ役割を直ちに使用しなければならない場合や、元の役割ホルダが Windows 2000 環境にどうしても復帰しない場合には、強制を実行できます。

RID マスタの復旧

RID マスタ役割を強制するかどうかを決める際は、あらかじめ次のことについて検討してください。

環境への影響
最初に理解しなければならないことは、障害を起こした RID マスタが環境に与える影響です。主に次の問題に直面します。

セキュリティ オブジェクトを作成できない
この状況で直面する主な問題は、ユーザー、グループ、コンピュータなどの新しいセキュリティ オブジェクトをドメインに追加できないことで、その結果 "Windows はオブジェクトを作成できません。理由 : ディレクトリ サービスは、相対識別子のプールを使い切りました。" といったエラー メッセージが表示されます。

このほか、オブジェクトを作成しようとした DC 上で、16645 というイベント ID を持つエラーがイベント ログに書き込まれます。このエラーは、このドメイン コントローラに割り当てられたアカウント識別子の最大数が既に割り当てられていることを示します。

この問題は、ドメイン内にある各ドメイン コントローラ上の RID プール (1 つのプールに個別の 512 個の RID) が使い切られたときにだけ表面化します (オブジェクトはドメイン内の任意の DC 上に作成できるため)。

したがって、残りの DC が 5 つのドメインで RID マスタに障害が起きた場合でも、理論的には 2,560 (5 × 512) 個の RID が利用できます。このため通常の環境では、既に説明した方法を使用して RID マスタを修復または復元するまで、セキュリティ原則を作成するために十分すぎるほどの RID が提供されることになります。ただし、セキュリティ オブジェクトを大量に作成している最中であったり、またはドメイン間でオブジェクトを移動中で既存のプールにある数よりも多くの RID を必要とする場合には、役割の強制を実行できます。

ドメイン間でのセキュリティ プリンシパルの移動に失敗する
対象ドメイン内の RID マスタが稼動状態でなくなると、セキュリティ プリンシパルを新しいドメインに移動できなくなります。上の問題とは異なり、RID マスタが利用できなくなるためにドメイン間の移動はすべて直ちに失敗することになります。

RID マスタに対して強制を実行する際の検討事項
RID マスタに対する強制の実行は、十分な検討を行ったうえでなければ実行すべきではありません。ネットワーク上での RID の重複による危険性のため、強制を実行する場合は、本来 RID マスタ役割のホストになっているサーバーを "決してオンラインに戻さないで" ください。その代わりに、元の役割ホルダを完全に再構築した後に、Windows 2000 の実稼動環境に導入し直してください。

RID マスタの強制に関するすべての影響を理解した後も、アクティブな RID マスタを直ちに準備しなければならないという状況の場合には、既に説明した手順に従って操作マスタ 役割を強制してください。

PDC エミュレータの復旧

PDC エミュレータ 役割を強制するかどうかを決める際には、あらかじめ次のことについて検討してください。

環境への影響
最初に理解しなければならないことは、障害を起こした PDCE が環境に与える影響です。主に次の問題に直面します。

混合モード環境
Windows NT Server 4.0 バックアップ ドメイン コントローラがアクティブであるような混合モード環境において PDCE 役割が障害を受けると、Windows NT Server 4.0 においてネイティブの PDC が利用できなくなったときに遭遇する場合と同じ問題に直面します。たとえば、NT 4.0 ドメインをネイティブの NT 4.0 ドメインユーザーマネージャ ツールを使用して管理しようとすると、"このドメインのドメイン コントローラが見つかりません。" というエラー メッセージが表示されます。

Windows NT Server 4.0 ドメインをネイティブのサーバーマネージャ ツールを使用して管理しようとした場合には、"MYDOMAIN のプライマリ DC が見つかりません。このドメインを管理することはできますが、ドメイン全体にわたる操作の一部が使用できなくなります。" というエラー メッセージが表示されます。

ネイティブ モード環境
ネイティブ モード環境で発生する問題は、混合モード環境においても (Windows 2000 側で) 存在します。Windows 2000 環境で PDCE が障害に見舞われると、主に次の問題に直面します。

**ログオン失敗の頻度が増える可能性。**たとえば、ユーザーがパスワードを忘れて管理者が DC 上でそのパスワードをリセットするなどしてユーザー パスワードがリセットされた際に、リセットした DC が認証 DC ではない場合、そのユーザーはパスワードが認証 DC に複製されるまで待つ必要があり、その間はログオンできません。

ユーザーのローカル認証 DC は、パスワードが最後の複製以後変更されたかどうかを確かめるために PDCE へのアクセスを試みますが、PDCE はオフラインであるためその試みは失敗します。したがって、認証 DC は最後の手段として Active Directory にある PDCE のローカル コピーを使用しますが、このコピーには元の忘れられたパスワードがまだ残っています。

このような状況では、クライアント側からも認証 DC からも外見上ははっきりとしたエラーが現れません。

このことは確かに問題になる可能性がありますが、ユーザーの認証 DC 上でパスワード変更を行うことによって簡単に解決できます。

グループ ポリシー **オブジェクト編集時のエラー。**GPO の編集中にデータの損失が起こらないようにするため、GPO への変更情報を扱う既定の DC は PDCE 役割を保持している DC になります。このため、PDCE が利用できなくなると、ドメイン内で GPO を編集しようとしたときに下の図 12 に示すメッセージが表示されます。

adrecv12

図 12

この問題は小さな問題であり、指示されるオプションのうちいずれか 1 つを選択することで直ちに修正できます。これらのオプションの簡単な説明を次に示します。

  • PDC エミュレータの操作マスタ トークンがある方を使用する

    役割が利用できないときはこのオプションは明らかに使用できません。

  • Active Directory スナップインで指定されているものを使用する

    このオプションでは、Active Directory の管理スナップインが使用しているドメイン コントローラを使用します。PDCE が利用できないときに推奨されるオプションです。

  • 利用可能なドメイン コントローラを使用する

    この 3 番目のオプションは最も望ましくないオプションですが、これによりグループ ポリシー スナップインが、利用可能な任意のドメイン コントローラを選択できるようになります。このオプションを選択した場合には、ローカル サイト内のドメイン コントローラが選択されるのがふつうです。

メモ :
ここで加える変更は 1 回の編集に対するものです。つまり、PDCE マスタが利用できない状態で GPO を編集しようとするたびに、この質問をたずねられることになります。

PDC エミュレータ マスタに対して強制を実行する際の検討事項
PDCE マスタの役割は既に言及した役割ほど重要なものではありません。そのため、この役割の強制操作にはほかの役割のような細かい条件はありません。PDCE 役割の強制を選択する場合でも、元の役割ホルダを完全に再構築してから再度 Windows 2000 環境に参加させるという必要はありません。

結果として、PDCE 役割の強制の決定において配慮すべき環境への影響はほとんどなく、特に混合モード環境において、一般に PDCE 役割の強制の決定は PDCE の障害に備えた標準の対処法とみなされます。

PDCE 役割を強制する際に考慮すべきただ 1 つの問題は、Windows NT Server 4.0 BDC のある混合モード環境で作業をしているかどうか、ということです。BDC が自ら実行しようとしている変更に対応できるためには、組み込みグループと新しい PDCE との完全な同期が必要になります。

メモ :
PDCE 役割の強制に伴う問題が環境に与える影響は少ないですが、この役割を強制できる手段として Microsoft では Active Directory ユーザーおよびコンピュータ スナップインを提供しています。このスナップインを使用するには、役割転送で通常実行する手順を実行します。詳細については Windows 2000 リソースキットの『分散システム ガイド』を参照してください。元の PDCE が利用できなくなると、下の図 13 に示すダイアログが表示されます。

adrecv13

図 13

[OK] をクリックすると役割が強制されます。

メモ :
制転送と強制は等価な操作です。

このほか、ntdsutil を使用した役割の強制も可能です。これには、このホワイト ペーパーの「操作マスタの強制に必要な手順」の節で説明した手順に従います。ただし手順 7 を次の手順に置き換えてください。

7. FSMO maintenance プロンプトで「seize pdc」と入力します。

インフラストラクチャ マスタの復旧

インフラストラクチャ マスタ役割を強制するかどうかを決める際には、あらかじめ次のことについて検討してください。

環境への影響
最初に理解しなければならないことは、障害を起こしたインフラストラクチャ マスタが環境に与える影響です。

インフラストラクチャ マスタの障害が環境に与える影響は限られています。障害の影響はエンド ユーザーにはわからず、相当量のグループ操作が発生している場合に管理者が影響を受けるにすぎません。通常、このようなグループ操作はユーザーの追加またはユーザー名の変更という形式になります。このような状況でインフラストラクチャ マスタがダウンしても、それらの変更を Active Directory 管理スナップインを通じて参照する際に遅れが生じる、という影響が出るだけです。

元のインフラストラクチャ マスタを修復または復旧するまでの間インフラストラクチャ マスタがなく環境の運用を継続できない、という状況になることは非常にまれです。ただし、非常に長期間の停止状態が予測される場合には、この役割の強制を推奨します。

インフラストラクチャ マスタに対して強制を実行する際の検討事項
インフラストラクチャ マスタ役割の強制に伴う主な検討事項は、新しい DC が必ず GC サーバーでないようにすること、ただし、GC と良好な接続状態に保つことです。新しい DC は GC と同じサイト内にあることが理想です。

ページのトップへ ページのトップへ

まとめ

このホワイト ペーパーは Active Directory のバックアップおよび復元に関する情報をまとめて提供することで、管理者がこれらに関連する問題についてより深く理解できるよう支援することを目的としたものです。管理者はこのホワイト ペーパーを活用することで、自らが管理する Windows 2000 環境のための障害回復計画を立てることができます。

参考情報

Windows 2000 Server の最新情報については、弊社 Web サイト (https://www.microsoft.com/japan/windows2000/) を参照してください。

ページのトップへ ページのトップへ

付録 I

データベースの整合性テスト

ESE (拡張可能ストレージ エンジン) レイヤおよび DB レイヤの両方において、データベースに対して限られた量の整合性テストを実行できます。下の図 14 はこれらのレイヤを示したものです。

adrecv14

図 14: Active Directory の機能レイヤ

これらのテストは長時間かかる可能性があります。状況の緊急度に応じて、テストを実行するのか、またはバックアップからの復元に移行するのかを決めることができます。テストを実行する際の検討事項のいくつかを次に示します。

  1. 起動後、ディレクトリサービス復元モードに移行できない場合には、これらのテストを実行できないためこの節は無視してもかまいません。

  2. イベント ログ内のエラー メッセージや対応する KB (ナレッジベース) の記事から、問題の特徴に関する詳細や、整合性チェックによって問題が解決するかどうかを説明している内容を見つけます。

  3. この処理は長時間かかる可能性があります。データベースのサイズにもよりますが、1 GB 以上の大規模なものでは数時間に及ぶこともあります。

これらのテストの長所として、テストの実行を原因としてデータを失うことがない、という点が挙げられます (この点は付録 II で説明する修復とは異なります)。これらのテストは次の順序で実行してください。

  1. ログ ファイルのソフト回復

  2. ファイルの整合性

  3. Semantic 分析

作業を続けるにはディレクトリ サービス復元モードに入る必要があります。

ログ ファイルのソフト回復の実行
電源の突然の停止に備えて、ログ ファイルの "ソフト" 回復を実行できます。トランザクション データはログ ファイルに書き込まれてからデータ ファイルに書き込まれます。このため、ログ ファイルを再実行することで、トランザクションによる書き込みがデータ ファイルになされたと仮定して、トランザクションが及ぼしたと思われる効果を再現できます。この "ソフト" 回復を実行するには Ntdsutil コマンドライン ツールの Recover コマンドを使用します。ログ ファイルはすべてスキャンされ、コミット済みのトランザクションがすべてデータベース ファイルに確実に書き込まれます。ソフト回復は、前回のシャットダウンに問題があった場合に、ドメイン コントローラの起動時に自動的に実行されます。

Recover コマンドを実行したときの出力例を次に示します。

C:\>ntdsutil 
ntdsutil: files 
File maintenance: Recover 
コマンドを実行しています : C:\WINNT\System32\esentutl.exe /r /8 /o /l"C:\WINNT\NTDS" /s" 
C:\WINNT\NTDS" /!10240 

Initiating RECOVERY mode... 
Log files: C:\WINNT\NTDS 
System files: C:\WINNT\NTDS 

Performing soft recovery... 

operation completed successfully in 4.717 seconds. 

Spawned Process Exit code 0x0(0) 

回復に成功した場合は、 
 semantic データベース分析を実行して 
 semantic データベースの整合性も確認することを推奨します。

ファイルの整合性の確認
integrity コマンドを使用すると、データベースの低レベル (バイナリ レベル) の損傷を検出できます。integrity コマンドはデータ ファイルのすべてのバイト データを読み取ります。したがって、データベースのサイズによってはかなりの処理時間がかかることもあります。

また、integrity コマンドは、正しいヘッダーがデータベース自身に存在することと、すべてのテーブルが正常に機能していて一貫性があることを確認します。この機能はディレクトリ サービス復元モードにおいて使用します。検出されたエラーはログ ファイルに記録されます。

integrity コマンドの実行時間は使用しているハードウェアの種類とディレクトリ データベースのサイズによって異なります (テスト環境では 1 時間当たり 2 GB の処理速度が標準とみなされました)。しかし、コマンドを実行するとオンライン グラフによって完了の割合が表示されます。

ntdsutil ツールを使用した整合性チェックの実行例を次に示します。

C:\>ntdsutil 
ntdsutil: files 
file maintenance: Integrity 
データベースを開いています。 
コマンドを実行しています : C:\WINNT\System32\esentutl.exe /g "C:\WINNT\NTDS\ntds.dit" /! 
10240 /8 /v /x /o 
Initiating INTEGRITY mode... 
Database: C:\WINNT\NTDS\ntds.dit 
Temp. Database: INTEG.EDB 
failed to get 515126 buffers 
checking database header 
checking database integrity 
Scanning Status  ( % complete ) 
0    10   20   30   40   50   60   70   80   90  100 
|----|----|----|----|----|----|----|----|----|----| 
checking SystemRoot 
SystemRoot (OE) 
SystemRoot (AE) 
checking system table 
MSysObjectsShadow 
MSysObjects 
.Name 
RootObjects 
rebuilding and comparing indexes 
checking table "datatable" (6) 
checking data 
.......................checking long value tree (24) 
...checking index "PhantomIndex" (125) 
.checking index "INDEX_000901FD" (122) 
checking index "INDEX_000900DE" (121) 
checking index "INDEX_00090089" (120) 
checking index "INDEX_00090573" (119) 
checking index "INDEX_00090073" (118) 
checking index "INDEX_00090571" (117) 
checking index "INDEX_0009056C" (116) 
checking index "INDEX_00090553" (115) 
checking index "INDEX_0009013A" (114) 
checking index "INDEX_00090138" (113) 
checking index "INDEX_00090330" (112) 
checking index "INDEX_00090030" (111) 
checking index "INDEX_00090013" (110) 
checking index "INDEX_00000013" (109) 
checking index "INDEX_0000000B" (108) 
checking index "INDEX_00000007" (107) 
checking index "INDEX_00000003" (106) 
.checking index "INDEX_00150003" (105) 
checking index "LCL_ABVIEW_index00000409" (104) 
checking index "INDEX_00090363" (103) 
checking index "INDEX_00090303" (102) 
checking index "INDEX_00090290" (101) 
checking index "INDEX_000901FF" (100) 
checking index "INDEX_000900DD" (99) 
checking index "INDEX_00090085" (98) 
checking index "INDEX_00090057" (97) 
checking index "INDEX_0009001C" (96) 
.checking index "INDEX_000201CC" (95) 
checking index "INDEX_0002000D" (93) 
checking index "INDEX_0000002A" (92) 
checking index "INDEX_00000004" (91) 
checking index "NC_Acc_Type_Name" (90) 
checking index "PDNT_index" (89) 
..checking index "INDEX_00090001" (88) 
.checking index "INDEX_000901F6" (85) 
checking index "INDEX_000902EE" (84) 
checking index "INDEX_000904E1" (83) 
checking index "INDEX_000201D5" (80) 
checking index "INDEX_000902BB" (77) 
checking index "INDEX_000903B4" (76) 
checking index "INDEX_000200A9" (75) 
checking index "INDEX_0009039D" (74) 
checking index "INDEX_0009039A" (73) 
checking index "INDEX_00090098" (72) 
checking index "INDEX_00090395" (71) 
checking index "INDEX_0009028F" (69) 
checking index "INDEX_00090582" (66) 
checking index "INDEX_00020078" (65) 
.checking index "INDEX_00020073" (62) 
checking index "INDEX_00090171" (60) 
checking index "INDEX_00090167" (58) 
checking index "INDEX_00090062" (56) 
checking index "INDEX_00090261" (55) 
checking index "INDEX_0009014E" (52) 
checking index "INDEX_0009014D" (51) 
checking index "INDEX_0009014C" (50) 
checking index "INDEX_00090147" (49) 
checking index "INDEX_00090141" (48) 
checking index "INDEX_00090140" (47) 
checking index "INDEX_0009012E" (42) 
checking index "INDEX_00020013" (39) 
.checking index "INDEX_0009030E" (36) 
checking index "INDEX_00090008" (32) 
checking index "INDEX_00090202" (25) 
checking index "Ancestors_index" (13) 
.checking index "DRA_USN_CREATED_index" (12) 
checking index "DRA_USN_index" (11) 
.checking index "del_index" (10) 
checking index "INDEX_00090002" (9) 
..checking index "NC_Acc_Type_Sid" (8) 
checking index "INDEX_00090092" (7) 
rebuilding and comparing indexes 
checking table "hiddentable" (16) 
checking data 
rebuilding and comparing indexes 
checking table "link_table" (14) 
checking data 
checking index "backlink_index" (15) 
rebuilding and comparing indexes 
checking table "MSysDefrag1" (123) 
checking data 
checking index "TablesToDefrag" (124) 
rebuilding and comparing indexes 
checking table "sdproptable" (17) 
checking data 
checking index "clientid_index" (19) 
checking index "trim_index" (18) 
rebuilding and comparing indexes 

integrity check completed. 
operation completed successfully in 13.640 seconds. 
作り出された処理終了コード 0x0(0) 

統合に成功した場合は、 
 semantic データベース分析を実行して 
 semantic データベースの整合性も確認することを推奨します。

データベースの整合性の確認
Ntdsutil ツールには、Semantic データベース分析オプションを選択して起動できる Semantics Checker が含まれています。このツールの役割は Active Directory データベースの内容の整合性をチェックすることです。

このツールはディレクトリ サービス復元モードにおいて実行します。エラーは dsdit.dmp .xx というログ ファイルに書き込まれます。チェックの状況は進捗インジケータによって示されます。

実行可能な機能の例を次に示します。

  • **参照カウントのチェック。**データ テーブルおよびリンク テーブルからのすべての参照の個数を数え、それらがレコードに列挙されているカウント数に一致することを確認します (データ テーブルおよびリンク テーブルの詳細については、Windows 2000 リソースキットの『分散システム ガイド』の「Active Directory データ記憶域」の節を参照)。また、各オブジェクトが GUID、識別名、および 0 でない参照カウントを持っていることも確認します。削除済みオブジェクトについては、そのオブジェクトが削除時刻および削除日付を持っているが、GUID や識別名は持っていないことを確認します。

  • **削除済みオブジェクトのチェック。**オブジェクトが削除時刻および削除日付、そして特殊な相対識別名を持っていることを確認します。

  • **先祖のチェック。**現在の識別名タグ (DNT) が、現在の DNT 自身およびその親の先祖リストに等しいかどうかを判断します。

  • **セキュリティ記述子のチェック。**有効な記述子かどうかをチェックし、記述子が制御フィールドを持っていることと、随意アクセス制御リストが空でないことを確認します。随意アクセス制御リストを持たない削除済みオブジェクトがある場合は警告が表示されます。

  • **複製のチェック。**ディレクトリ パーティション ヘッド内の UpToDate ベクトルをチェックし、正しい数のカーソルが存在することを確認します。また、すべてのオブジェクトがプロパティ メタデータ ベクトルを持っているかどうかも確認します。オブジェクトのインスタンス型の場合には、メタデータ、up-to-dateness vector、下位参照、および部分属性をチェックします。

Semantic データベース分析の実行

  1. Active Directory をバックアップします。Windows 2000 バックアップは Active Directory のオンライン中でのバックアップをネイティブでサポートしています。この処理は、バックアップ ウィザードにおいてコンピュータ上のすべてのデータをバックアップするオプションを選択したとき、またはそれとは別にウィザードでシステム状態のバックアップを選択したときに、自動的に実行されます。

  2. ドメイン コントローラを再起動し、スタートアップ メニューから適切なインストールを選択して、F8 キーを押します。すると、[Windows 2000 詳細オプション メニュー] が表示されます。

  3. [ディレクトリ サービス復元モード] を選択して Enter キーを押します。再び起動処理を開始するため、Enter キーを押します。

  4. オフラインの SAM で、ローカル管理者アカウントに対して定義した管理者アカウントおよびパスワードを使用して、ログオンします。

  5. [スタート] メニューで、[プログラム]、[アクセサリ] の順にポイントしてから [コマンド プロンプト] をクリックします。

  6. コマンド プロンプトで、「ntdsutil」と入力して Enter キーを押します。

  7. 「Semantic database analysis」と入力して Enter キーを押します。

  8. 「Verbose on」と入力して Enter キーを押します。これで Semantics Checker が表示されます。

  9. 「go」と入力して Enter キーを押します。 Semantics Checker が起動しますが、検出したエラーは修復しません。検出したエラーを修復するには、[Go Fixup] オプションをオンにします。

  10. 「quit」と入力して Enter キーを押します。もう一度「quit」と入力するとコマンド プロンプトに戻ります。

Semantic データベース分析オプションで詳細モードをオンにして実行した例を次に示します。

C:\>ntdsutil 
ntdsutil: Semantic database analysis 
semantic checker: Verbose on 
詳細モードが有効になります。 
semantic checker:  Go 
データベースを開いています。.... 完了 

レコード数を取得しています ...2371 レコード 
ログ ファイル dsdit.dmp.0 に概要を書き込んでいます 
スキャンされたレコード :       2300 
レコードを処理しています . 完了

ページのトップへ ページのトップへ

付録 II

データベースの修復

Active Directory の修復は最後の手段とするようにしてください。有効なバックアップが利用できる場合は常にそのバックアップを復元してください。修復中の Active Directory が正常に動作するという保証はありません。実際、この処理の結果さらにデータが失われる危険性があります。また、この処理には非常に長い時間がかかることもあります。

修復を実行した後、付録 I で説明した Semantic データベース整合性チェックを必ず実行してください。

Active Directory の修復を実行するには、ntdsutil ツールの修復オプションを使用します。

C:\>ntdsutil 
ntdsutil: files 
ntdsutil: repair

ページのトップへ ページのトップへ

付録 III

データベース : 場所の特定、移動、およびオフライン デフラグ

データベース ファイルおよびログ ファイルの場所の特定
ntdsutil コマンドライン ツールの一部である info コマンドを使用すると、データ ファイル、ログ ファイル、および作業ディレクトリの場所を探し出すことができます。このコマンドは次の処理を実行します。

  • コンピュータにインストールされているすべてのディスクについてそれらの空き領域を分析して報告する。

  • Active Directory ファイルの場所を参照しているレジストリ キーを読み取り、その値を報告する。

  • データ ファイル、作業ディレクトリ、およびログ ファイルの各サイズを報告する。

info コマンドの実行出力例を次に示します。

C:\>ntdsutil 
ntdsutil: files 
file maintenance: Info 

ドライブの情報 : 

C:\ NTFS (固定ドライブ  ) 空き (2.9 Gb) 合計 (3.9 Gb) 

DS パスの情報 : 

データベース   : C:\WINNT\NTDS\ntds.dit - 12.1 Mb 
バックアップ ディレクトリ : C:\WINNT\NTDS\dsadata.bak 
作業ディレクトリ : C:\WINNT\NTDS 
Log dir    : C:\WINNT\NTDS - 40.0 Mb total 
res2.log - 10.0 Mb 
res1.log - 10.0 Mb 
REPAIR.TXT - 0.0 Kb 
edb00001.log - 10.0 Mb 
edb.log - 10.0 Mb

データベースの移動
データベースをディスク上のある場所から別の場所に移動するときに、Ntdsutil コマンドライン ツールをディレクトリ サービス復元モードで使用できます。たとえば、以前に割り当てていたドライブやディレクトリでデータの破損が起きた場合に、ログ ファイルや Ntds.dit ファイルを別のドライブに移動しなければならないことがあります。具体的には、move db to %s コマンドにより、Ntds.dit データ ファイルが "%s" で指定した新しいディレクトリに移動され、ディレクトリ サービスが新しい場所を使用して再起動するようにレジストリ キーが更新されます。このとき、移動操作の前後に極力バックアップをとっておくようにしてください。新しいファイル場所は復元操作によって保持されません。

同様に、ログ ファイルをある場所から別の場所に移動することもできます。具体的には、Move logs to %s コマンドにより、ディレクトリ サービス ログ ファイルが %s で指定した新しいディレクトリに移動され、ディレクトリ サービスが新しい場所を使用して再起動するようにレジストリ キーが更新されます。

オフライン デフラグ
Active Directory は、ガーベジ コレクション処理の中で、特定のインターバル (既定では 12 時間) ごとにデータベースのオンライン デフラグを自動的に実行します。オンライン デフラグによってデータベース ファイル (Ntds.dit) のサイズが小さくなるわけではありませんが、データベース内のデータ記憶域が最適化され、新しいオブジェクトを収めるディレクトリ内の領域が修正されます。また、オンライン デフラグはデータ記憶域に関する問題も防ぎます。"オフライン" デフラグを実行すると新しい圧縮されたデータベース ファイルが作成されますが、元のデータベース ファイルの断片化の程度によりこの新しいファイルのほうがかなり小さくなることがあります。オフライン デフラグを実行するには次のようにします。

  1. Active Directory をバックアップします。

  2. ドメイン コントローラを再起動し、スタートアップ メニューから適切なインストールを選択して、F8 キーを押します。すると、[Windows 2000 拡張オプション メニュー] が表示されます。

  3. [ディレクトリ サービス復元モード] を選択して Enter キーを押します。再び起動処理を開始するため、Enter キーを押します。

  4. ローカル管理者アカウントを使用してログオンします。

  5. [スタート] メニューで、[プログラム]、[アクセサリ] の順にポイントしてから [コマンド プロンプト] をクリックします。

  6. コマンド プロンプトで、「ntdsutil」と入力して Enter キーを押します。

  7. 「files」と入力して Enter キーを押します。

  8. 「info」と入力して Enter キーを押します。これで、Active Directory データベースのパス、サイズ、およびそのログ ファイルに関する現在の情報が表示されます。パスを控えておきます。

  9. コンパクト版データベースを十分に格納できるだけのドライブ領域のある場所を準備します。

  10. 次のように入力します。ここで、<drive> および <directory> は前の手順で準備した場所へのパスです。そして Enter キーを押します。

    「compact to <drive>:\<directory>」

    メモ :
    必ずディレクトリ パスを指定してください。パスに空白文字が含まれている場合は、パス全体を必ず引用符で囲んでください。たとえば "c:\new folder" というようにします。

    Ntds.dit という名前の新しいデータベースが、指定したパスに作成されます。

  11. 「quit」と入力して Enter キーを押します。もう一度「quit」と入力するとコマンド プロンプトに戻ります。

  12. 手順 8 で控えておいた現在の Active Directory データベース パスにある古い Ntds.dit ファイルに、新しい Ntds.dit ファイルをコピーして上書きします。

  13. 通常どおりコンピュータを再起動します。

ページのトップへ ページのトップへ

付録 IV

Active Directory の障害回復に役立つツール

障害発生時に役立つものとして推奨されるツール セットを次にまとめて紹介します。

メモ :
サポート ツールを入手するには次のどちらかを実行してください。

  • Windows 2000 Server CD の \support\tools フォルダを参照し、そこにあるインストーラ プログラムを実行します。

または

  1. [スタート] メニューで、[プログラム]、[管理ツール] の順にポイントしてから [サーバーの構成] をクリックします。

  2. [Windows 2000 サーバーの構成] ウィザードで、[拡張コンポーネント] をクリックしてから [サポート ツール] をクリックし、指示に従います。

Windows 2000 ドメイン マネージャ (NetDom.exe)
このツールを使用すると、管理者は Windows 2000 のドメインと信頼関係をコマンド ラインから管理できます。このツールは Windows 2000 CD のサポート ツールに付属しています。

複製診断ツール (Repadmin.exe)
このツールを使用すると、管理者は複製トポロジーを各ドメイン コントローラの視点から眺めるかたちで表示できます。また、ドメイン コントローラ間で複製イベントを強制し、複製メタデータと up-to-dateness vector の両方を表示する際にも、RepAdmin を使用できます。このツールは Windows 2000 CD のサポート ツールに付属しています。

Active Directory 診断ツール (Ntdsutil.exe)
このツールは Windows 2000 Server に付属しており、コマンド ラインから「ntdsutil」と入力することでアクセスできます。このツールの使用方法についてはこのホワイト ペーパー全体で説明しています。

Windows 2000 バックアップ ユーティリティ (Ntbackup.exe)
このユーティリティは Windows 2000 で利用できる既定のバックアップ アプリケーションです。このツールを使用して、システム状態およびシステム ドライブの定期的なバックアップを実行できます。ツールの使用方法の詳細についてはこのホワイト ペーパーで説明しています。

  • Windows 2000 では、[バックアップ] は [アクセサリ] メニューの [システム ツール] の中にあります。システム ツールの項目を開くには、[スタート] メニューをクリックし、[プログラム]、[アクセサリ]、[システム ツール] の順にポイントしてから、該当するアイコンをクリックします。

ADSI Edit
ADSI Edit は、Active Directory の低レベルなエディタとして機能する Microsoft 管理コンソール (MMC) スナップインです。Active Directory Service Interfaces (ADSI) を使用することで、ディレクトリ サービス内部でオブジェクトの追加、削除、および移動を行うための手段が提供されます。各オブジェクトの属性は表示、変更、および削除できます。このツールは Windows 2000 CD のサポート ツールに付属しています。

この文書の内容は、執筆時点で取り上げた問題に対する Microsoft Corporation の現在の見解を示したものです。Microsoft では市場の状況の変化に追随しなければならないため、この文書を Microsoft Corporation の正式な見解の一部と解釈しないようご留意ください。Microsoft Corporation はこの文書で提供されている情報について、文書発行後もその正確さを保証いたしません。

このホワイト ペーパーは情報提供だけを目的とするものです。Microsoft Corporation ではこの文書の内容について明示的または暗黙的ないかなる保証もいたしません。

お客様は適用されるすべての著作権法を遵守する責任があります。著作権に基づいて権限が制限される場合を除き、この文書の一部でも電子的、機械的、光学的、磁気的またはその他の手段によって、複製、検索システムへの格納または導入、あるいは転載を行うことは、Microsoft Corporation の書面による明確な許可がないかぎり、その目的の如何を問わず一切できません。

Microsoft は、この文書に記載されている対象物の特許、特許アプリケーション、商標、著作権その他の知的財産権を有します。Microsoft Corporation から書面により明記された使用許諾契約書の提供がないかぎり、この記事の提供によってこれらの特許、特許アプリケーション、商標、著作権などの知的財産権の使用許諾がお客様に与えられることはありません。

© 2000 Microsoft Corporation. All rights reserved.

Microsoft、BackOffice、Windows、および Windows NT は、米国 Microsoft Corporation の米国その他の国における登録商標または商標です。

その他、記載されている会社名、製品名は、各社の商標および登録商標です。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

2000 年 7 月

ページのトップへ ページのトップへ