ADのドメインコントローラーの正常性を確認する代表的な方法
2019/08/20
本エントリーの目次
Windows Serverを購入し、Active Directoryの構築・管理を行っていると、こんな風に思うことがあると思います。
ドメインコントローラーの正常性を確認するにはどうしたら良いの?
Active Directory ドメイン サービスをはじめとしたActive Directory(以降ADと表記)の各種機能を利用する環境(AD環境)では、中核となる多くの機能を提供するドメインコントローラーはとても重要です。
そのためいずれかのドメインコントローラーに障害が起きてもドメインの機能が完全に停止しないように、ドメインコントローラーは必ず複数台構成にすることが強く推奨されています。
(テスト時など、AD環境が破損しても大きな影響がない場合には、単一のドメインコントローラーで運用することもあるでしょうけれど。)
こういった情報については、ADやドメインコントローラーの構築の際にネットで調べ物をすると、必ず目にする内容であると言っても過言ではないほどに、多くのサイトに書かれています。
そのため運用開始後に、現在ドメインコントローラーは正常に動作しているのか、ドメインコントローラーの正常性を確認したい!
なんて思われる方もいらっしゃると思います。
そこで今回は、ADのドメインコントローラーの正常性を確認する代表的な方法をいくつかご紹介します!
はじめに
本エントリーで紹介する確認方法では、一部管理者権限が必要となります。
そのためコマンドを実行する際は、管理者権限でコマンドプロンプトやPowerShellを起動してください。
また一部のコマンドでは、別のドメインコントローラーに接続してのテストが実行されます。
この時、テスト対象のドメインコントローラーのファイアウォールが適切に構成されていないと、ファイアウォールに通信が遮断されてしまい、テストの際にエラーとなってしまうことがありますのでご注意ください。
本エントリーで紹介している内容は、2016年9月現在最新のサーバーOSであるWindows Server 2012 R2で正常に動作することを確認しています。
ですがWindows Server 2012 R2より前のサーバーOSでは利用できない機能やコマンドがあるかもしれないこと、今後発売されるサーバーOSでは利用不可となってしまう可能性があること、あらかじめご了承ください。
先ほど、ドメインコントローラーは障害に備えて複数台構成にするよう強く推奨されている、と書きました。
そして複数台のドメインコントローラーは、ドメインコントローラーとしての機能を提供するための特別な情報を互いに複製しあい、常にお互いの情報を最新に保つようにしています。(この仕組みはマルチマスターレプリケーションと呼ばれています。)
このような仕組みから、複数台のドメインコントローラーは互いに正常に複製しあえていないといけません。
たとえば2台のドメインコントローラー、dc1とdc2が存在した場合、dc1で更新された内容がdc2に正常に複製されていない状況でdc1が破損した場合、dc2の情報の一部は古いままであるため、問題が起こる可能性があります。
そのため、この複製すべき情報が正常に複製されているかを確認する必要があります。
この複製すべき情報が正常に複製されているかを確認する方法の一つに、net shareコマンドによる共有の確認が挙げられます。
これを実行するには、コマンドプロンプトやPowerShellを起動し、以下のコマンドを実行します。
1 | net share |
すると以下のような内容が表示されるので、『SYSVOL』と『NETLOGON』フォルダーが共有されていることを確認してください。
1 2 3 4 5 6 7 8 9 10 | 共有名 リソース 注釈 ------------------------------------------------------------------------------- C$ C:\ Default share IPC$ Remote IPC ADMIN$ C:\Windows Remote Admin NETLOGON C:\Windows\SYSVOL\sysvol\haruru29.local\SCRIPTS Logon server share SYSVOL C:\Windows\SYSVOL\sysvol Logon server share コマンドは正常に終了しました。 |
これら『SYSVOL』と『NETLOGON』フォルダーが共有されていなければ、何らかの理由で複製すべき情報が正常に複製されておらず、ドメインコントローラーに何らかの問題が起きています。
ちなみにこの『SYSVOL』と『NETLOGON』フォルダーですが、前者はグループポリシーやログオンスクリプトなどに関する情報を格納。
そして後者は下位互換のために用意されているもので、上記結果のリソースを見ると分かるとおり、実態はSYSVOLフォルダー内のSCRIPTS(scripts)フォルダーです。
また先ほどドメインコントローラーは、ドメインコントローラーとしての機能を提供するための特別な情報を互いに複製しあい、常にお互いの情報を最新に保つ、と書きました。
こう言われるとすべてのドメインコントローラーは同等であるような印象を受けます。
ですがドメインコントローラーの機能の中には、特定の1台のドメインコントローラーのみが持つ特別な機能も存在し、FSMO = Flexible Single Master Operationと呼ばれています。
そのためFSMOの役割をもったドメインコントローラーに障害が起きた場合、他のドメインコントローラーに障害が起きた場合に比べ、対処が複雑となります。
尚、FSMOには大きく5つの機能があり、フォレスト内で単一のドメインコントローラーのみが受け持つ機能(スキーマ・マスター、ドメイン名前付けマスター)と、ドメイン内で単一のドメインコントローラーのみが受け持つ機能(PDCエミュレータ、RIDマスター、インフラストラクチャ・マスター)が存在します。
DFSの診断レポートによるSYSVOLフォルダーの複製状態の確認
Windows Server 2008以降のサーバーOSでは、DFSの管理という機能を使用することで、SYSVOLフォルダーの複製状態の確認を行うことが可能です。
この機能を利用する場合、役割と機能の追加で『DFSの管理ツール』機能を追加する必要があります。
追加の際に階層が深いために見つけにくいですが、以下のように『リモート サーバー管理ツール』-『役割管理ツール』-『ファイル サービス ツール』-『DFS 管理ツール』と展開してください。
そしてDFSの管理を起動すると以下のように『Domain System Volume』という名称で、SYSVOLフォルダーの情報が表示されます。
そして『Domain System Volume』を選択した状態で『診断レポートの作成…』をクリックし、『診断レポート』を選択。
さらに出力先フォルダーとレポート名を指定し、すべてのドメインコントローラーを『含めるメンバー』とし、後はそのままウィザードを進めます。
すると以下のような診断レポートが出力されるので、エラーや警告の有無・内容を確認して必要な対処を行ってください。
repadmin /showreplコマンドによる複製結果の確認
ドメインコントローラーが複製する情報は、『SYSVOL』と『NETLOGON』フォルダー以外にもあります。
そのためrepadmin /showreplコマンドを使用して複製状況を確認します。
コマンドプロンプトやPowerShellを起動し、以下のコマンドを実行します。
1 | repadmin /showrepl |
このコマンドをドメインコントローラー、dc1で実行した場合、以下のような結果が表示されます。(他にdc2、dc3というドメインコントローラーが存在する例)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | Repadmin: フル DC localhost に対してコマンド /showrepl を実行しています Default-First-Site-Name\DC1 DSA オプション: IS_GC サイト オプション: (none) DSA オブジェクト GUID: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY DSA 起動 ID: ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ ==== 入力方向の近隣サーバー====================================== DC=haruru29,DC=local Default-First-Site-Name\DC3 (RPC 経由) DSA オブジェクト GUID: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXXX 2016-09-01 20:53:08 の最後の試行は成功しました。 Default-First-Site-Name\DC2 (RPC 経由) DSA オブジェクト GUID: AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 2016-09-01 20:59:48 の最後の試行は成功しました。 中略 DC=ForestDnsZones,DC=haruru29,DC=local Default-First-Site-Name\DC2 (RPC 経由) DSA オブジェクト GUID: AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 2016-09-01 20:53:08 の最後の試行は成功しました。 Default-First-Site-Name\DC3 (RPC 経由) DSA オブジェクト GUID: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXXX 2016-09-01 20:53:08 の最後の試行は成功しました。 |
実行結果を見て、『…の最後の試行は成功しました。』となっており、複製が成功していることを確認します。
さらにコマンドを実行したドメインコントローラーがグローバル カタログを保持している場合には『DSA オプション: IS_GC』または『DSA OPTIONS: IS_GC』 という項目があることを確認します。
本コマンドはすべてのドメインコントローラーで実行し、結果確認を行います。
尚、複製が失敗している場合には、以下のように表示されます。
1 2 3 4 5 6 7 | 2016-09-01 14:57:39 の最後の試行は、失敗しました。結果は 1722 (0x6ba): RPC サーバーを利用できません。 1 回連続で失敗しました。 最後に成功したのは 2016-09-01 14:47:44 です。 |
repadmin /syncallコマンドによる複製実行結果の確認
repadmin /showreplコマンドでは、他のドメインコントローラーとの複製を直近ではいつ実行し、その結果がどうだったかを調べています。
次は、ドメインコントローラーの情報の複製・同期を手動で実行し、その結果を確認します。
この確認を行うには、コマンドプロンプトやPowerShellを起動して以下のコマンドを実行します。
1 | repadmin /syncall |
以下のような結果が表示されるので、エラーが起きていないことを確認してください。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | コールバック メッセージ: 次のレプリケーションが進行中です: レプリケーション元: AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA._msdcs.haruru29.local レプリケーション先: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY._msdcs.haruru29.local コールバック メッセージ: 次のレプリケーションが完了しました: レプリケーション元: AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA._msdcs.haruru29.local レプリケーション先: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY._msdcs.haruru29.local コールバック メッセージ: 次のレプリケーションが進行中です: レプリケーション元: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXXX._msdcs.haruru29.local レプリケーション先: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY._msdcs.haruru29.local コールバック メッセージ: 次のレプリケーションが完了しました: レプリケーション元: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXXX._msdcs.haruru29.local レプリケーション先: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY._msdcs.haruru29.local コールバック メッセージ: SyncAll が完了しました。 SyncAll はエラーなしで終了しました。-------------- |
たとえば別のドメインコントローラーがシャットダウンしていたために、正常に複製を完了できなかった場合、以下のメッセージが表示されます。
1 2 3 4 5 | SyncAll が次のエラーを報告しました: サーバー AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA._msdcs.haruru29.local へのアクセス中にエラーが発生しました (ネットワーク エラー): 1722 (0x6ba): RPC サーバーを利用できません。 |
repadmin /syncallコマンドは、他のドメインコントローラーから情報を受信するプル型の動作となります。
そのため本コマンドによる複製が正常に実行できているかの確認は、すべてのドメインコントローラーで実行し、結果確認を行う必要があります。
ちなみに他のドメインコントローラーへ情報を送信するプッシュ型の複製をしたい場合には、repadmin /syncall /Pコマンドを実行します。
gpo toolによるグループポリシーの整合性確認
AD環境での便利な機能の一つに、グループポリシーによるクライアントPCの制御が挙げられます。
これがやりたくてADを導入した、という会社さんも多いと思います。
このグループポリシーに関する情報は『SYSVOL』フォルダーの複製によって、ドメインコントローラー間で複製されている、というのは先ほど書いたとおり。
そしてこのグループポリシーについて、データベースと『SYSVOL』フォルダーの内容の整合性を確認するには、マイクロソフトさんが無償で配布しているgpo toolを使用します。
まずはマイクロソフトさんのWindows Server 2003 Resource Kit Toolsのページから、gpo toolをダウンロードします。
Windows Server 2003 Resource Kit ToolsはWindows Server 2003用というわけではなく、Windows Server 2008以降のOSでも動作可能です。
実際に手元にあったWindows Server 2012 R2でも正常に動作することを確認しています。
gpo toolのダウンロードが完了したら、PowerShellを起動してSet-Locationコマンドを実行し、gpo toolが配置してあるディレクトリーをカレントディレクトリーに変更します。
1 | Set-Location [gpo toolが配置してあるディレクトリーのパス] |
その後以下のコマンドを実行し、gpo toolによる整合性の確認を行います。
1 | .\gpotool.exe /dc:localhost /verbose |
実行結果は定義しているグループポリシーすべてについて、以下のような内容が出力されます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | ============================================================ Policy {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} Friendly name: GPO_Test Policy OK Details: ------------------------------------------------------------ DC: localhost Friendly name: GPO_Test Created: 2016/09/01 5:53:32 Changed: 2016/09/01 8:29:23 DS version: 0(user) 8(machine) Sysvol version: 0(user) 8(machine) Flags: 0 (user side enabled; machine side enabled) User extensions: not found Machine extensions: [{YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY}{ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ}] Functionality version: 2 ------------------------------------------------------------ |
そのため多数のポリシーを定義している場合は、以下のコマンドを使用してファイル出力を行うと確認がしやすいでしょう。
1 | .\gpotool.exe /dc:localhost /verbose > gpotool-result.txt |
そして各ポリシーについて、『Policies OK』と表示されていれば正常です。
もし何らかの問題が起きていた場合には、『Errors found』と表示されます。
この確認はパラメーターで『/dc:localhost』と指定しているように、localhostのみを対象としています。
そのためすべてのドメインコントローラーでこの確認を行うことで、各ドメインコントローラーが保持しているグループポリシーに関する情報の整合性に問題がないことを確認します。
dcdiag /a、dcdiag /vコマンドによるドメインコントローラーの状態分析
Windows Server 2008以降のサーバーOSでは、Active Directory ドメイン サービス (AD DS) または Active Directory ライトウェイト ディレクトリ サービス (AD LDS) サーバーの役割がインストールされている場合、ドメインコントローラーの状況分析を行うdcdiagコマンドを使用可能です。(以前はサポートツールに同梱。)
このdcdiagコマンドを使用することで、ドメインコントローラーの状態をかなり詳しく調べることが可能です。
具体的には、コマンドプロンプトやPowerShellを起動し、以下のコマンドを実行します。
1 | dcdiag /a |
または以下のコマンドを実行します。
1 | dcdiag /v |
dcdiag /aコマンドでは、実行したコンピューターが所属するサイト内に存在するすべてのドメインコントローラーの状況を分析・表示します。
それに対してdcdiag /vコマンドは、コマンドを実行したドメインコントローラーの状況をdcdiag /aコマンドよりも詳細に分析します。
コマンドを実行したコンピューターとは別のドメインコントローラーに対してdcdiag /vコマンドを実行する場合は、/s: <DomainController名>パラメーターを追加してください。
コマンドを実行した結果は、以下のような形式で出力されます。(実際の実行結果は数百行以上にわたることもあるため、そのほとんどを省略しています。)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | ディレクトリ サーバー診断 初期セットアップを実行しています: ホーム サーバーの検索を試みています... * ローカル コンピューター dc1 がディレクトリ サーバーであることを確認しています。 ホーム サーバー = dc1 中略 必須の初期テストを実行しています サーバーをテストしています: Default-First-Site-Name\DC1 テストを開始しています: Connectivity * Active Directory LDAP Services Check Determining IP4 connectivity * Active Directory RPC Services Check ......................... DC1 はテスト Connectivity に合格しました プライマリ テストを実行しています サーバーをテストしています: Default-First-Site-Name\DC1 テストを開始しています: Advertising The DC DC1 is advertising itself as a DC and having a DS. The DC DC1 is advertising as an LDAP server The DC DC1 is advertising as having a writeable directory The DC DC1 is advertising as a Key Distribution Center The DC DC1 is advertising as a time server The DS DC1 is advertising as a GC. ......................... DC1 はテスト Advertising に合格しました 中略 ......................... haruru29.local はテスト Intersite に合格しました |
結果を一通り確認し、各テストでエラーが発生しておらず、『合格しました』や『passed』と表示されていれば問題はありません。
エラーが発生していた場合には、その項目について調査を行い、エラーの内容を改善する必要があります。
ただ一部のエラーについては、エラーが発生していても一時的な問題であるなど、大きな問題ではないケースもあるので、エラーの内容を見て対処すべきかどうかを見極める必要があります。
尚、以下のような『RPC サーバーを利用できません。』というエラーが表示される場合、ファイアウォールに通信を遮断されている可能性があります。
1 2 3 4 5 | サーバー dc1.haruru29.local のイベント ログ DFS Replication を照会できませんでした。エラー 0x6ba "RPC サーバーを利用できません。" ......................... DC3 はテスト DFSREvent に失敗しました |
この場合には、エラーが起きているドメインコントローラー(※)のファイアウォールで『リモート イベントのログ管理 (RPC)』を遮断しないように設定を変更し、改善するか確認してみてください。
※テストを実行したコンピューターではありません。
イベントログを確認する
Windows Serverでは、ドメインコントローラーに何らかの問題が起こった場合、または問題の前兆を検出した際に、イベントログに警告やエラーログを出力します。
そのため、イベントビューアーのフィルター機能を使用して警告やエラーログを抽出して確認すると良いでしょう。
確認すべきログにはたとえば以下のようなものが挙げられます。
- Application
- システム
- Active Directory Web Services
- DFS Replication
- Directory Service
- DNS Server
ただこれらのログを定期的に確認するのは手間がかかり、とても面倒な作業です。
そこでイベントログを監視して警告やエラーのイベントが検出されたら、メールで管理者に内容を送信するようなPowerShellスクリプトを作成し、タスクスケジューラでシステム起動時に実行するようにしておくことをおすすめします。
また、こういったイベントログのメール監視機能を含む有償のソリューションも販売されていたと思うので、そういった製品を利用するのも手でしょう。
環境や運用状況にあわせた確認手順の作成を!
今回ご紹介したドメインコントローラーの正常性の確認方法は代表的なもので、この他にもたくさんの確認方法や確認項目があります。
そのため環境や運用状況にあわせた確認手順を調査・作成し、定期的に正常性を監視・確認しておくと安心です。
しっかりとした監視・確認体制をとっておけば、障害の前兆を早期に発見し、大きなトラブルを未然に防ぐことができるかもしれないので、ぜひ検討してみてくださーい!