世界のブログから - Hyper-Vとドメイン コントローラーに関してもう一つ
「世界のブログから」シリーズ第二弾です。
今回も"Virtual PC Guy's Blog"から、Hyper-V and Domain Controllers – Demo Tips and Tricks の「勝手訳」です。
原文の意図をなるべく正しく伝えたいとは思っていますが、私(ksasaki)なりの解釈と意見をバリバリ加えたりしますので「英語版の忠実な翻訳」ではありません。あしからずご了承ください。
なお、「ドメイン コントローラーどうしよう」と関連する内容ですので合わせてご参照ください。
では、
Hyper-Vとドメイン コントローラー - デモ環境構築のコツ
先日、「ドメイン コントローラーどうしよう」のエントリで
「Hyper-Vホストが、自分自身のゲストとして動いているドメイン コントローラーに接続して、ドメインにログオンする」
というシステム構成をご紹介しました。私(元記事のBen)はお客様向けのデモ環境を構築する際にこの方式をよく使います。なんとならば、
- デモ機が運送中に故障してしまうことがあります。そのため、デモ環境はできるだけ手荷物として持ち運べるノートPC1台で完結させたいのです。
- デモ会場のネットワーク環境は場合によっては不安定です。その意味でも、デモ環境はできるだけ1台で完結させたいのです。
- しかしながら多くの場合、デモ環境にはドメイン コントローラーが必要です。
[ksasaki] 私もセミナー用のHyper-V 4ノード クラスターがセミナー当日に1ノード死んでしまい、かなり焦ったことがあります。運搬時の問題か、会場内での設置時の問題かわかりませんが、ディスク障害で起動不能になってしまったのでした。クラスタ化VMの高可用性を図らずも実証する結果になったのは怪我の功名？でしたが・・・ また、ネットワークに関してはハブとケーブル持参で自前LANを組んだ事も何度かありますが荷物が大きくなって大変です。
というわけで、私(Ben)はノートPCにWindows Server 2008 R2をインストールして、その上のVMとしてドメイン コントローラーはじめデモ環境一式を詰め込んでしまう「一台完結型」の構成をよく使います。
今日はこの、「ノートPC上にドメイン コントローラーVMを配置する一台完結型構成」で多くのデモを実施した結果得られた、いくつかのコツをご紹介したいと思います。
出先でのノートPCによるデモ環境では、システムが素早く確実に起動することが重要です。セミナーなどでは自分の出番の直前10分間ぐらいしかデモ機の準備をする時間がなかったりしますので、その10分の間にシステム全体が起動して、しっかりとデモができる状態になっている必要があります。場合によっては、プレゼン用のPowerPointも同じノートPC上で動かします。そんなときはデモ環境起動のために許される時間はさらに短くなります。
そこで、
コツ その1 － 資格情報のキャッシュはOFF！
何らかの原因でドメイン コントローラーへ接続できない時でも、たいていの場合、ドメインに参加したコンピューターへのログオンは可能です。これは、Windowsがドメイン ユーザーの資格情報をローカルにキャッシュする仕組みを持っているからです。
しかし残念ながら、デモ環境ではこのキャッシュが問題になる(というかキャッシュのために問題に気付くのが遅れる)事があります。こんな状況を考えてみてください。
デモの準備を万全に整え、出発の準備ができました！愛用のノートPCをカバンに入れてプレゼンを行う会場へと向かいます。
PCを起動してログオンし、プレゼンを始めて20分後、いよいよデモを披露する時が来ました。パワポからデモ画面へ切り替えてデモを開始すると、なんと肝心の仮想マシン達で認証エラーが多発！きまりの悪い思いをしながら環境をチェックすると、ドメイン コントローラーが起動されていないではありませんか！せっかくのデモは台無しです・・・
実際にこういう経験をして以来、私(Ben)は資格情報のキャッシュを無効にしています。こうしておけば、ドメイン環境に何か問題があればログオンに失敗するのですぐに気付きますし、ログオンが成功すれば、ドメイン コントローラーが正しく稼働しているということが確信できて安心です。
ただし、これを行う場合はドメイン ユーザーではないローカルの管理者アカウントでちゃんとログオンできる(パスワードを忘れたりしていない)ことをあらかじめしっかり確かめておく必要があります。何か問題が発生した場合に面倒なことになりますので。。。
資格情報のキャッシュを無効化するには、クライアント コンピューター(この場合、デモ環境一式を詰め込んであるノートPCのペアレント パーティション)で"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"というレジストリ エントリの"cachedlogonscount"に0をセットしてください。
コツ その2－ ドメイン コントローラー起動時の長ーい待ち時間を回避する設定
この記事でご紹介しているような「一台完結型」デモ環境では、ドメイン コントローラーを起動してから認証の処理を行えるようになるまでに長い時間がかかることがあります。私(Ben)が自分の標準的なデモ環境で測定したみたところ、PCを起動してから実際にドメインへログオンできるまでに、10分以上かかることもありました。
迅速に起動することが必要なデモ環境にとって、これは明らかに大きな問題です。また、実は我が家のサーバー環境にも同じ問題があって、たびたびイラッとさせられているのです。。
さんざんこの問題と格闘した結果、この遅延はクライアントがドメイン コントローラーを発見するための情報(SRVレコード)が、DNSに正しく登録されていないために発生することを発見しました。
ドメイン コントローラーの起動時、ドメイン コントローラー内のNetlogonサービスが、SRVレコードをDNSサーバに対して登録しようとします。そしてDNSサーバはどこにいるかというと、今回のようなデモ環境では一台の仮想マシンにドメイン コントローラーとDNSの役割を詰め込んでしまう事がほとんどです。この場合、ドメイン コントローラーのプライマリ DNSサーバーは自分自身を指すことになりますが、サービスの起動のタイミングによっては、Netlogonサービスが動き出した時点ではまだDNSサービスが立ち上がっていないことがあります。
こうなるとSRVレコードの登録ができません。これによって、クライアントがドメイン コントローラーを発見できず、ドメインにログオンできないという問題が発生します。 Netlogonサービスは、DNSへのSRVレコード登録が失敗した場合、再試行まで5分程度待機しますので、その間はログオンできない状態が続いてしまいます。
[ksasaki] これはKB259277に記述のある現象です。元記事にはKB259277に対する言及がありませんが、KB化されている既知の現象であればKBの記述を尊重するのが妥当だと思うので、、以降はKB259277にフォーカスして大幅に原文を書き換えます。また、クライアントがドメイン コントローラーを発見する方法については、Windows でのドメイン コントローラの検索方法をご参照ください。
対策としてはKB259277にもある通り、DNSサービスが起動してからNetlogonサービスが起動するように、Netlogon→DNSという依存関係を設定するのが簡単です。KBにはregeditでレジストリをいじる男らしい方法が紹介されていますが、ここはスマートにscコマンドを使う方法をご紹介します。
ドメイン コントローラーに管理者でログオンしてコマンドプロンプトを開きます。Vista以降のWindowsであれば「管理者として実行」で開いてください。
まずは、netlogonサービスの依存関係を調査します。
コマンドラインで、“sc qc netlogon”を実行します。
私(ksasaki)の環境ではnetlogonサービスはLanmanWorkstation(「Workstation」サービス)に依存していました。
この依存関係に、新たにDNSサービスを追加します。DNSサービスの正式名は"DNS"(表示名と同じ)なので、コマンドラインで、"sc config netlogon depend= LanmanWorkstation /DNS"を実行します。依存先サービスを複数指定する場合はスラッシュ"/"で区切ります。
再度確認してみましょう。コマンドラインで、“sc qc netlogon”を実行します。
"DEPENDENCIES"欄に"DNS"が加わりました。
これで、DNSサービスが起動してから、Netlogonサービスが動き出すようになり、SRVレコードの登録に失敗する心配もなくなります。
元記事では、"nltest /dsregdns"コマンドを使ってSRVレコードを強制的に登録するバッチファイルをタスクスケジューラに登録し、システム起動時のタスクとして実行するという方法が紹介されていますが、KB259277に載っているこちらの方法(サービスの依存関係を設定する方法)の方がいくらかスマートかな、と個人的には思います。
関連情報
SRV Records Of Domain Controller In DNS Domain Zone
Netlogon イベント 5774、5775、5781 のトラブルシューティング
__END__