ドメインコントローラ自身のネットワークがパブリックになってしまう

公開 | 更新 
図5.NLAサービスの依存関係を追加

ドメイン コントローラ であるはずのWindows Server機が、自身のネットワークプロファイルを パブリック と誤判断する現象に何度か遭遇したので、その原因である Network Location Awareness サービスの開始時期や 依存関係 を変更して、再起動後も正しく稼働するように改善しました。

NLAサービスを再起動すれば解消も

Windows Server 2012で運用しているドメインコントローラが、再起動後Pingには応答するもののリモート接続出来ないことから、ローカルログインしてネットワークプロファイルを確認すると、ドメインコントローラ自身にも関わらず「パブリック」になっていました。

図1.パブリックネットワーク

図1.パブリックネットワーク

これにより、パブリックネットワーク向けの厳しめのファイヤウォールプロファイルが適用され、リモートデスクトップもブロックされてしまったのでしょう。この現象はMMCコンソールからNetwork Location Awarenessサービス(以降、NLAと略称)を再起動させたり、ネットワークアダプタを無効・再有効化させるか、ネットワークケーブルを抜き差しすれば解消することが出来ます。

図2.ドメインネットワーク

図2.ドメインネットワーク

NLAサービスを遅延起動へ

調べてみると、この不具合と符合する現象が海外フォーラムサイトにスレッドが挙がっていました。

原因はNLAサービスが早く立ち上がり過ぎること。

つまり、ドメインネットワークに必要な関連サービスが立ち上がりきらないうちに、NLAサービスが開始されてしまい、挙げ句にドメインネットワークが使えないと誤判定から、パブリックネットワークとされてしまうもの。

かと言ってサーバ起動後、NLAサービスの再起動をタスクスケジューラに登録するなどして、やみくもにサービス再起動を自動化してしまうのは、やや短絡的でしょう。

そこでまずは、NLAサービスのスタートアップの種類を変更してみます。デフォルトでは単に「自動」となっているのを「自動(遅延開始)」へ変更して適用します。

図3.NLAサービスを遅延開始へ

図3.NLAサービスを遅延開始へ

これでサーバを再起動させてみたものの、これでもまだNLAサービスが起動するタイミングは早すぎるようです。

 

NLAサービスの依存サービスを追加

上述のフォーラムで次に提示されている解決策は、NLAサービスが依存するシステムコンポーネントを増やすというもの。まずはサービスのプロパティタブを確認したり、 sc コマンドでデフォルトの依存関係を確認します。

図4.NLAサービスのデフォルト依存関係

図4.NLAサービスのデフォルト依存関係

ここへ sc コマンドで次の2つのコンポーネントを追加します。

  • DNS Server (DNS)
  • Active Directory Domain Services (NTDS)

図5.NLAサービスの依存関係を追加

図5.NLAサービスの依存関係を追加

 

再びサーバを再起動させてコンソール画面の変化を見守ると、ネットワーク断絶しているアイコンのまま、5分程度待たされるようになるものの、ネットワークタイプを正しく認識するようになりました。

図6.NLAがまだ開始していない画面

図6.NLAがまだ開始していない画面

ドメインコントローラに求められるのは起動の速さよりも正しさ。普段はほぼヘッドレス運用なので、定期的に起こるWindows Update後の自動再起動の後も、正しい状態でオンラインで居続けるのが一番でしょう。

 

created by Rinker
¥2,495 (2024/03/29 16:05:14時点 Amazon調べ-詳細)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA