Контролер домену розглядає це у загальнодоступній мережі

У нас є основний контролер домену Server 2008 R2, який, здається, має амнезію, коли справа доходить до розробки, яка саме мережа знаходиться. (Єдине) мережеве з'єднання ідентифікується при запуску як "Громадська мережа".

Однак, якщо я відключую та повторно включаю з'єднання, він із задоволенням з'ясовує, що він насправді є частиною доменної мережі.

Це тому, що AD Domain Services не запускається, коли мережеве розташування спочатку відпрацьоване?

Ця проблема спричиняє певні головні болі з правилами брандмауера Windows (що я більше, ніж знаю, можна вирішити іншими способами), тому мені здебільшого цікаво дізнатися, чи хтось знає, чому це відбувається.

У вас є шлюз за замовчуванням для цього з'єднання? Чи відповідає він на запити ping?

Windows використовує шлюзи для ідентифікації мереж; якщо у нього не налаштований шлюз або він не може успішно проконувати його, він не зможе визначити мережу, до якої підключений, і вважатиме, що це загальнодоступний.

Чи класифікується мережа контролера домену як доменна мережа , не залежить від конфігурації шлюзу.

Поведінка помилкової мережевої класифікації може бути викликана NLAслужбою (обізнаність про розташування мережі) starts before the domain is available. У цьому випадку вибирається державна або приватна мережа і не виправляється після цього.

Як перевірити, чи дана така ситуація несправності
Коли контролер домену після перезавантаження перебуває у загальнодоступній мережі, перезапустіть службу NLA або відключіть / повторно підключіть мережу. Після цього контролер домену повинен бути в доменній мережі.

Як її вирішити
Це може допомогти встановити службу NLA на затримку запуску . Краще перевірте, чому домен потрібно довго присутній. Здається, що домену потрібно довше запускатись, коли є кілька мережевих карт.

Коли це не допомагає
Коли ні прискорення завантаження домену, ні затримка допомоги NLA, а помилка викликана тривалим завантаженням домену (дивіться: "як перевірити ..."), то є деякі більше речей, які можна зробити.

• Напишіть сценарій для перезавантаження, запустіть його з планувальником (небезпечно)

• Перемістіть завантаження служби NLA до кінця служби, змінивши порядок завантаження в реєстрі (небезпечно)

  Наступна запис у реєстрі встановлює залежності NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS:

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
  "DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
  63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00
  

• Виконати "IPCONFIG / RENEW" з планувальника при запуску із запізненням на 1 або 2 хвилини (краще, ніж запуск служби NLA)

• Перезавантажте службу NLA вручну після кожного перезавантаження (але: слід віддавати перевагу "IPCONFIG / RENEW")!

Ще однією причиною може бути те, що в контролері домену встановлено два або більше IP-адрес (на тій же або на інших мережевих картах), а додаткові мережі не налаштовані в DNS.

Розмноження поведінки
на контролер домену тесту (один DC!) Я видалив запис шлюзу по замовчуванням і встановити DNS Serverв delayed start. Для цього домену потрібно було довго завантажуватися, і мережа була класифікована як public. Після відключення та підключення мережного кабелю мережа була класифікована правильно як domain network.

Редагувати

вдячно з коментарів Daniel Fisher lennybaconта Joshua Hanley:

Як додати залежність для NlaSvc до DNS та NTDS

запустіть sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSз CMD (використовуйте sc.exe, якщо ви запускаєте його в PowerShell). Якщо ви хочете двічі перевірити існуючі залежності перед додаванням DNS та NTDS, використовуйтеsc qc nlasvc

Я бачив подібну поведінку під час встановлення сервера R2 AD 2008 року. Мене дістало те, що було включено більше одного NIC, хоча він не використовувався. Після того, як я відключив невикористані NIC та перезавантажився, проблема пішла.

Точна функція Windows, проти якої ви зараз, називається NLA (Network Location Awareness). Я недостатньо знаю про це, щоб претендувати на експерта, але я знаю, що там є якась цікава інформація на інтертубах про те, як це все працює, чи передбачається, що це працює.

У моєму випадку сервер був DMZ, і багато правил брандмауера блокували сервер спілкуватися з контролерами домену. У цьому випадку вам потрібно буде відкрити брандмауери (апаратні FW), щоб сервери могли спілкуватися. Крім того, щоб виконати тест, підключіть сервер до мережі, де правила брандмауера дозволяють спілкуватися між клієнтом і серверами.

Встановивши новий контролер домену, ви можете виявити, що "WINDOWS FIREWALL" не встановлено належним чином на "DOMAIN: ON". Це результат поганих налаштувань встановлення, які надає Microsoft. Щоб виправити це, очистіть налаштування DNS IP6 на мережевому підключенні від ":: 0" назад до автоматичного. Також очистіть форвардерів IP6 від DNS-сервера.