10 команд PowerShell для диагностики медленного входа в домен Windows

«Почему у нас так долго грузится Windows?» — этот вопрос я слышу от клиентов регулярно. Сотрудник нажимает Ctrl+Alt+Del, смотрит на ползущую полосу профиля и ждёт — 30 секунд, минуту, а иногда и все три. За 15 лет в IT я видел самые разные причины: GPO, раздувшиеся до неприличия, повреждённые профили, перегруженный контроллер домена, скрипты логона, которые молча съедают время. В этом руководстве — 10 конкретных PowerShell-команд, которые на практике позволяют за 10–15 минут найти виновника торможения входа в Windows-домен.

Фото: Unsplash — диагностика Windows-инфраструктуры через PowerShell

Почему логон «зависает»: коротко о механизме

Вход в домен — это не одно действие, а цепочка: аутентификация у контроллера домена, загрузка и применение групповых политик, инициализация профиля, выполнение скриптов логона и только потом — рабочий стол. Затык на любом из этих этапов даёт ту самую «замороженную» заставку, которая раздражает пользователей.

Искать узкое место методом исключения — занятие на несколько часов. PowerShell и встроенные журналы Windows сужают поиск до конкретного виновника за минуты. Дальше — 10 команд: от быстрой первичной проверки к глубокому анализу.

Команды 1–3: Групповые политики

gpresult /h C:\Temp\GPO_Report.html

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational';ID=5312} |
    Select-Object TimeCreated, Message |
    Format-List

Get-Process | Sort-Object StartTime -Descending |
    Select-Object -First 20 Name, Id, StartTime, CPU |
    Format-Table -AutoSize

Команды 4–6: Профили пользователей и Winlogon

Get-WmiObject Win32_UserProfile |
    Select-Object LocalPath, LastUseTime, Special, Status |
    Sort-Object LastUseTime -Descending |
    Format-Table -AutoSize

Get-WinEvent -LogName 'Microsoft-Windows-Winlogon/Operational' |
    Select-Object TimeCreated, Id, Message -First 20 |
    Format-List

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' |
    Select-Object TimeCreated, Id, LevelDisplayName, Message -First 20 |
    Format-List

wevtutil sl Microsoft-Windows-Winlogon/Operational /e:true

Команды 7–10: Сеть, контроллер домена и скрипты

nltest /dsgetdc:НАЗВАНИЕ_ДОМЕНА

Test-NetConnection -ComputerName ИМЯ_DC -Port 389 -InformationLevel Detailed

Get-ChildItem "C:\Users" |
    Sort-Object LastWriteTime -Descending |
    Select-Object Name, LastWriteTime,
        @{N="SizeMB"; E={(Get-ChildItem $_.FullName -Recurse -ErrorAction SilentlyContinue |
        Measure-Object -Property Length -Sum).Sum / 1MB -as [int]}} |
    Format-Table -AutoSize

Get-WinEvent -LogName 'Microsoft-Windows-Shell-Core/Operational' |
    Where-Object { $_.Message -like "*Logon Script*" -or $_.Message -like "*скрипт*" } |
    Select-Object TimeCreated, Id, Message -First 10 |
    Format-List

$dc = "DC01"  # замените на имя вашего DC

# LDAP
Test-NetConnection $dc -Port 389

# SMB (для SYSVOL с GPO)
Test-NetConnection $dc -Port 445

# Kerberos
Test-NetConnection $dc -Port 88

# Global Catalog
Test-NetConnection $dc -Port 3268

Практический алгоритм диагностики

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

1. Проверьте сеть первой. Команды 7 и 8 выполняются за секунды. LDAP-порт недоступен или задержка зашкаливает — остальное можно не смотреть, начинайте с сети.
2. Запустите gpresult. Откройте HTML-отчёт и честно посчитайте применённые политики. Больше 20–30 с кучей расширений CSE — в нашей практике это почти всегда источник задержек.
3. Проверьте журнал Winlogon. Команда 5 даёт временну́ю карту входа — видно конкретный шаг, на котором всё «провалилось».
4. Проверьте профили. Команды 4, 6 и 9 помогут поймать повреждённый или раздутый профиль.
5. Скрипты — в последнюю очередь. Только если предыдущие шаги не дали ответа.

Типичные решения по итогам диагностики

Когда виновник найден, лечение, как правило, сводится к одному из нескольких сценариев. Ниже — то, с чем мы чаще всего сталкиваемся на практике.

• Много GPO: идём в GPMC, смотрим, какие политики реально применяются, а какие просто висят мёртвым грузом. WMI-фильтры — отдельная боль: они выполняются последовательно и могут съедать по несколько секунд каждый. Заменяем их на фильтрацию по группам безопасности — разница ощутима сразу.
• Повреждённый профиль: переименовываем папку профиля, удаляем запись из реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID> — и Windows при следующем входе создаёт чистый профиль. Радикально, но работает в 9 случаях из 10.
• Медленный DC: сначала смотрим, что вообще происходит с контроллером — nltest /dclist:ДОМЕН покажет список и поможет понять, не гоняет ли клиент трафик на DC в другом городе. Дальше — site-topology и, если нужно, добавляем ближний контроллер домена.
• Тяжёлые скрипты: включаем асинхронное выполнение в GPO — пользователь не должен смотреть в чёрный экран, пока отрабатывает скрипт на 40 секунд. Либо выносим логику в Scheduled Task с задержкой после входа.
• Большой роуминговый профиль: включаем Folder Redirection для Documents, Desktop и AppData\Roaming — профиль перестаёт копироваться целиком при каждом входе. Квоту на размер профиля тоже ставим сразу, иначе через полгода вернёмся к той же проблеме.

Итог

Медленный логон в Windows-домен — это не мистика и не «так устроена Windows». Это диагностируемая проблема с конкретными причинами. Десять команд из этой статьи закрывают всё основное: групповые политики, профили, сетевые соединения с DC, скрипты входа. На практике 15 минут прогона этих команд дают достаточно данных, чтобы поставить точный диагноз — без гаданий и бесконечных «а давайте попробуем ещё вот это».