Мне сложно диагностировать периодические медленные входы в систему на компьютерах домена.
Немного информации о сети, в которой возникла эта проблема:
По большей части логины работают нормально и быстро для людей, которые уже использовали машину раньше. Первый вход на новый компьютер всегда выполняется медленно, но этого ожидаемо.
Проблема в основном в ноутбуках. Если они используются дома с подключением к сети вне домена или перемещены в другое место (все еще в доменной сети, но на другом сайте AD и, похоже, не имеет значения проводной или беспроводной), вход в систему может занять до трех минут с момента ввода пароля пользователем до момента фактического отображения рабочего стола. Наш терминальный сервер также периодически испытывает медленный вход в систему.
К сожалению, это временная проблема, и я не нашел надежного способа ее воспроизвести. Я подозреваю, что это связано с предпочтениями групповой политики, но у меня нет никаких доказательств этого. Я видел статью в базе знаний Microsoft, в которой обвиняли определенные типы таргетинга на уровне элементов в медленном входе в систему, но она не дает никаких указаний для определения, действительно ли это является причиной.
Какие журналы и инструменты я могу использовать, чтобы выяснить, что вызывает медленный вход в систему?
Какие параметры групповой политики следует использовать или избегать, если возможно, для ускорения входа в систему?
По сути, я иду в том же направлении, что и joeqwerty
Я испытал симптомы, которые вы описываете, в нескольких компаниях. По моему опыту, это обычно происходит, когда существует более одного сайта. Один из способов устранения потенциальной проблемы с сайтами и службами заключается в следующем. На компьютере, на котором только что произошел медленный вход в систему, перейдите в командную строку и введите echo% logonserver%. Если ответ не относится к серверу на том же сайте, что и ноутбук или рабочая станция, то, по моему опыту, подсети не настроены и не назначены правильный сайт в активном каталоге сайтов и служб.
Другой способ устранения неполадок - просмотреть этот файл журнала на контроллерах домена% SystemRoot% \ debug \ netlogon.log
Если вы видите такие записи, необходимо указать конкретную подсеть для сайтов и служб и назначить сайт.
16.05, 22:57:31 [4068] AD: NO_CLIENT_SITE: конкретное имя хоста 172.16.10.104
Рабочие станции и контроллеры домена Microsoft могут гарантировать, что они обращаются к правильным контроллерам домена для проверки подлинности и политик из-за сайтов и служб.
Если это так, и это приводит к корректировке сайтов и служб, имейте в виду, что репликация изменений на / с контроллеров домена может занять некоторое время. Кроме того, конечным рабочим станциям потребуется еще больше времени, чтобы увидеть новые изменения. Время репликации по умолчанию устанавливается на сайтах и сервисах на 1 час между контроллерами домена. В зависимости от географического расстояния и размера вашего леса AD я обычно устанавливаю 15 минут или около того.
Ответ, который может подходить к вопросу, или просто примечание для меня на потом:
У нас возникли экстремальные задержки при входе в некоторые из наших подсетей. Оказалось, что в этих подсетях отсутствовали зоны обратного DNS на сервере AD. Мы добавили обратные зоны, AD добавила записи PTR автоматически, и с тех пор задержки не было. Может быть, тоже совпадение.