Назад | Перейти на главную страницу

Основной контроллер домена работает медленно?

Кажется, у меня проблема с виртуализированным Windows 2008 контроллер домена. Мы запускаем Hyper-V на мощном сервере (двухъядерный четырехъядерный Nehalem Xeon, 48 ГБ оперативной памяти), и все виртуальные машины в основном простаивают. У нас есть только группа пользователей для тестирования и менее 6 машин, подключенных к домену.

Что происходит, так это то, что любой тип доступа к другому серверу кажется навсегда во время первоначального согласования входа в систему. Симптомы:

  1. Доступ к чему-то вроде \\ someserver \ c $ занимает около минуты. После этого передача файлов происходит быстро, с устойчивой скоростью передачи 1 гигабит, так что это не проблема сети.
  2. Если я открою вкладку «Безопасность», чтобы увидеть, какие пользователи имеют доступ к папке, я могу увидеть неразрешенные идентификаторы безопасности (S-1234 -...) в течение долгого времени, прежде чем они в конечном итоге будут разрешены.
  3. На некоторых клиентских компьютерах в журнале событий отображается следующее:

Предупреждение Winlogon 6005:

The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (Logon).

Предупреждение Winlogon 6006:

The winlogon notification subscriber <GPClient> took 89 second(s) to handle the notification event (Logon).

На основном контроллере домена также установлен RRAS, и он является сервером VPN, если это имеет значение. Среднее использование процессора составляет 0%, и насколько я могу судить, конфликта за ресурсы нет.

Настроены две виртуальные сетевые адаптеры, одна из которых выходит в общедоступный Интернет, а вторая - во внутреннюю локальную сеть.

Есть идеи, что я могу попробовать?

Решено:

Благодаря Farseeker и Zypher я решил проблему. На основном контроллере домена было настроено два сетевых адаптера. Один для Интернета и один для локальной сети.

Интернет-сетевая карта имела общедоступный IP-адрес, который регистрировался для нее в DNS (проверялся с помощью nslookup с гостевого компьютера). Все остальные компьютеры, на которых возникла проблема, НЕ имели доступа к общедоступной IP-подсети, поэтому они не могли попасть на общедоступный IP-адрес DNS. Я предполагаю, что они будут ждать тайм-аута на общедоступном IP-адресе, прежде чем пробовать частный IP-адрес локальной сети, к которому они могут получить доступ.

Снятие флажка «Зарегистрировать это соединение в DNS» на общедоступном интерфейсе PDC решило проблему, теперь в nslookup отображаются только частные IP-адреса. Спасибо, Зайфер.

Также пришлось сделать ipconfig /flushdns на клиентских компьютерах после смены на PDC.

Я видел похожие симптомы, но в «реальной» среде, а не в виртуализированной. В конечном итоге наша проблема заключалась в том, что DNS был настроен неправильно, и машины целую вечность выполняли какой-то сумасшедший циклический перебор, прежде чем он ответил. Это было очень давно, поэтому точное разрешение не помню ...

По моему опыту, подобные задержки больше связаны с несоответствием протоколов, чем с виртуальной машиной. Проверьте уровни аутентификации LanManager на контроллерах домена и на сервере. Может случиться так, что серверу требуется тайм-аут согласования, прежде чем он сможет подключиться или найти SID.

Это определенно звучит как проблема с DNS, но у нас никогда не было ошибок или проблем с производительностью, связанных с автоматической регистрацией, как у Zypher.