DCDIAG-1つのユーティリティを使用したAD Health Diagnostics

著者注：この記事は主に初心者のシステム管理者向けに書かれています;経験豊富な人はここで自分自身にとって新しく有用なものを学ぶことはまずありません。 GPUPDATE / forceに関する記事に触発されました（ mrHobbYに感謝） 。



Active Directoryは（2つのドメインコントローラーと1つのサイトで構成されている場合でも）大きくて複雑な生物であり、システム管理者にとっては、この生物の仕事を分析するためにいつでも診断を実行することが非常に重要です。

まあ、歩き回ってスナップインを見るのは効果的ではないので、システムのログによって何が起こっているのかを常に理解しているわけではないので、さまざまなユーティリティが助けになります。 それらの1つは、Microsoftのdcdiagです。

それを注意深く見てみましょう-このユーティリティのユーティリティは過大評価するのが難しいためです。 このコマンドの多数のキーは引用しません-必要に応じてヘルプでそれらについて読むことができます-しかし、私は実際に診断で使用するものにのみ焦点を当てます。







このユーティリティを使用するために最初に行う必要があるのは、ワークステーションまたはサーバー自体にインストールすることです（ここでは、誰でも自由に選択できますが、dcdiagの最新バージョンでは、サーバー自体でチェックを実行する必要があることは既に書かれています）。ドメインコントローラー（dcPromoおよびRegisterInDNSテストを除く）。 Windows 2003の場合、Windows 7および8の場合、オペレーティングシステムディストリビューションからサポートツールパッケージをインストールする必要があります-リモートシステム管理ツールパッケージをインストールする必要があります（win7、win7sp1、win8で異なります-ダウンロード時には注意してください）。 ところで、RSATはそれ自体が便利な製品です。ドメイン管理者の日常生活に必要なユーティリティは数多くあります。

パッケージをインストールした後、コマンドはコマンドラインから既に利用可能です。

ただし、すぐに起動しないでください。接続先のドメインコントローラを指定しないと、ワークステーションで何も機能しません。 ユーティリティは警告を発行します。





注：Windows 7以降、dcdiagメッセージはロシア語に翻訳されています。 それ以前は、すべてが英語のみでした。 たぶんそれは誰かに役立つでしょう。 古いバージョンは非常にシンプルでわかりやすい英語ですが。





/ s：スイッチまたは名前付けコンテキスト- / n：を使用してドメインコントローラーを指定することをお勧めします。 どのサーバーを指定するか-確認するドメインコントローラー-を指定しますが、ドメインの名前付けコンテキストを指定した場合（つまり、ドメイン名-Netbios、DNSまたはDN形式で指定できます）、最も近い（サイト内）コントローラーが見つかりますドメイン（以下、CDと呼びます）。

最も簡単なチェックを行いましょう：dcdiag / s：dc01-local

再び何か問題がありますが、既に何かが見えています：





ご覧のとおり、テストの一部は合格しましたが、アクセスの一部は拒否されています。 これは、管理者権限のない通常のドメインアカウントでdcdiagを起動したためです。 その下を通過するチェックの一部が単に不可能であることは明らかです。 したがって、正しい診断を得るには、管理者権限でユーティリティを実行する必要があります-コマンドラインを管理者として実行するか、キー/ u：ドメイン名\ユーザー名 / / p：パスワードを使用します 。 試してみましょう：

dcdiag / s：dc01-local / u：ローカル\ user19 / p：パスワード





ご覧のとおり、サービスチェックを除くほとんどすべてがチェックに合格しています。 しかし、ここには非常に論理的な説明があります-Windows 2003のパッケージにある新しいユーティリティを使用して、win2003に基づいてドメインコントローラーをチェックしようとしています-そして、おそらくサービスの名前が異なる場合があります。

---

叙情的な余談数1。 記事の準備中に、私は壮大な失敗の面白い現象に遭遇しました、コメントで議論できますか？ :)。 通常、別のドメインの通常のアカウント（調査中のローカルドメインの信頼に関連付けられている）からdcdiagを実行し、パラメーター/ uおよび/ pを設定します-（ローカルドメイン管理アカウントのユーザー名とパスワード）-ユーティリティはチェックに関するエラーを生成しました-例：sysvolchek（dcdiag 2003、frssysvol）。 ローカルドメインの管理者権限を持つアカウントでワークステーションにアクセスすると、チェックは正常に終了します。 したがって、おそらく、結局のところ、サーバー自体のチェックを行うことは不必要ではないでしょう。 叙情的脱線数1の終わりまで 。

---

チームの結果を完全に説明しますが、ポイントはわかりません。 これは、ユーティリティのヘルプ（ dcdiag / h ）で完全に説明されています。 主なことは明らかです-このドメインコントローラーに問題はなく、すべてのテストに合格しています。 しかし、1台のサーバーをチェックするだけでは、ADがチョコレートで現在健全な状態にあるという事実はわかりません。 そしてここで、エンタープライズのすべてのサーバーをチェックするためのキーが提供されます。

これは/ eスイッチです。 このキーにより、ユーティリティはドメイン内のすべてのCDをバイパスし、各サーバーですべてのテストを起動します。 / v-これと一緒に各テストの拡張情報の出力を使用すると便利です。 さて、これをすべて分析するために-データをファイルに出力すると便利です-ログを個別に、エラーメッセージを-個別に。 キー/ f：log_file_nameおよびferr：/ error_log_file_nameはこれに役立ちます（ / ferrスイッチは新しいバージョンで削除されました）。 間違ったドメインをチェックしたい場合は、あなたが今いる-コンテキストの名前を示すキーを追加/ n:。



コマンド全体は次のようになります。

dcdiag / n：ローカル/ e / v /f:c:\logs\adtest.log /ferr:c:\logs\aderrors.log / u：ローカル\ user19 / p：パスワード



注意！ Windows 2008以降のdcdiagのバージョンでは、 / ferr：スイッチはサポートされているものから削除されています（特別に繰り返されました:)）。

複雑なフォレスト構造があり、通信チャネルが遅い場合でも、待つ準備をしてください。 はい、たとえ簡単な場合でも-たとえば、10枚のCD、5つのサイト、256 kbit / sのチャネルという1つの実際のフォレストにいるとします。 このコマンドは平均で最大20分かかります。

問題を注意深く調べるために、実行結果を強くお勧めします。 まあ、このユーティリティを定期的に実行してADの健全性を診断することをお勧めします。

筋金入りの場合は、 / fixキーを追加することもできます-安全な修正を行いますが、これを行うべきではありません。



今日私が伝えたかったのはそれだけです。 また、このユーティリティを本番環境で使用する頻度はどれくらいですか？ どのような選択肢を知っていますか？



更新1 ：個人的な経験から、何かが記憶されました：低速（衛星など）の通信チャネルで接続された大規模なドメインがある場合、ユーティリティは存在しないと多くのエラーを生成します-ほとんどの場合、RPCは利用できません。 これは正常な動作であり、それについて知る必要があります。 ほとんどのテストが同様のメッセージで終了する場合、接続は存在しないため、障害を排除するための対策を講じる必要があります。 2番目の一般的な問題はDNSのエラーですが、これは別の記事のトピックです。

ps更新1 -dcdiag / fix-netlogonサービスのdnsの新しいエントリによるロギングを含む-これも知っておくと便利です！