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

Типичные симптомы и причины

«Экран приветствия висит минуту, потом ещё минута на "Применяются параметры групповой политики", потом рабочий стол загружается, но ещё 2-3 минуты ничего нельзя сделать.» — эту картину я лично видел сотни раз. И каждый второй сисадмин слышит её от пользователей минимум раз в неделю.

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

• Медленная обработка GPO — слишком много политик, циклическая обработка, скрипты входа с сетевыми запросами, которые ждут ответа от сервера
• Недоступный контроллер домена — DNS не резолвит имя DC, DC перегружен или сетевые задержки в десятки миллисекунд превращаются в минуты ожидания
• Повреждённый или перемещаемый профиль — Windows честно тянет с сервера каждый байт, а профиль весит 5 ГБ
• Скрипты входа — bat/ps1-скрипты, написанные когда-то «на скорую руку», которые теперь выполняют долгие операции при каждом логоне
• User Profile Service — ошибки при создании временного профиля, после которых пользователь работает в temp и теряет все настройки
• Много программ в автозапуске — десяток агентов, мессенджеров и корпоративного ПО стартуют одновременно и устраивают настоящую гонку за ресурсами диска

Вот 10 PowerShell-команд, которые в нашей практике закрывают 90% расследований. Конкретные команды, конкретные цифры — без воды.

Команды диагностики

Анализ применённых GPO

# Запустить от имени администратора
gpresult /h C:\Temp\GPO_Report.html /f
Start-Process C:\Temp\GPO_Report.html

Это не PowerShell в строгом смысле, но запускается из PS без проблем. Генерирует полный HTML-отчёт о применённых политиках. Откройте отчёт и ищите секцию «Computer Configuration» — там время применения каждой политики в миллисекундах. Если какое-то расширение CSE (Client-Side Extension) обрабатывалось 30–60 секунд — поздравляю, нашли виновника. Дальше уже понятно, что копать.

Время применения GPO через журнал событий

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
    Where-Object { $_.Id -eq 5312 } |
    Select-Object TimeCreated, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20 |
    Format-List

Event ID 5312 фиксирует завершение применения групповой политики. В поле Message — список CSE и время их обработки. Ищите строки вида Extension <name> took <N> milliseconds. Всё, что выше 5000 мс — уже подозрительно. Видел значения по 90 000 мс на скриптах, которые маппили сетевые диски через умерший сервер.

Что запускается при входе

# Автозапуск через реестр (текущий пользователь и машина)
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" |
    Select-Object * -ExcludeProperty PS*

Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" |
    Select-Object * -ExcludeProperty PS*

# Запущенные процессы с временем старта
Get-Process | Sort-Object StartTime -ErrorAction SilentlyContinue |
    Select-Object Name, Id, CPU, StartTime |
    Where-Object { $_.StartTime -ne $null } |
    Format-Table -AutoSize

Первые две команды покажут, что прописано в автозапуске. Третья покажет фактическое время старта каждого процесса — процессы, запущенные в первые секунды после логона, нередко и есть причина тормозов. Особенно если их там 20 штук.

Анализ профилей пользователей через WMI

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

Колонка Status — ключевая. Значения: 0 — нормально, 1 — временный профиль, 2 — перемещаемый профиль роуминга, 4 — мандатный профиль. Если Status содержит флаг 8 (0x8) — профиль повреждён, и это объясняет многое. Также смотрите на LocalPath: профили уволенных сотрудников годами копятся на рабочих станциях и реально замедляют загрузку.

События Winlogon

Get-WinEvent -LogName "Microsoft-Windows-Winlogon/Operational" |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 30 |
    Format-List

Winlogon/Operational фиксирует каждую фазу входа: начало сессии, загрузку профиля, выполнение скриптов. По временным меткам видно, сколько времени заняла каждая фаза. Разница между соседними событиями в несколько минут — прямой указатель на проблему. Никакой магии, просто читаем лог.

Проверка достижимости контроллера домена

# Найти контроллер домена
$domain = (Get-WmiObject Win32_ComputerSystem).Domain
nltest /dsgetdc:$domain

# Пинг DC
$dc = (nltest /dsgetdc:$domain | Select-String "DC:").ToString().Trim() -replace "DC: \\",""
Test-Connection -ComputerName $dc.Trim('\') -Count 4

Если nltest возвращает ошибку или задержки выше 50 мс — проблема в сети или DNS. Это критично: при логоне Windows обязательно обращается к DC за токеном Kerberos. Если DC недоступен, вход затягивается ровно на таймаут — обычно 30–45 секунд. Пользователь смотрит в экран и ждёт, а причина — один недоступный контроллер домена.

Проверка сетевых портов DC

$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

Все четыре порта должны отвечать TcpTestSucceeded: True. Если порт 445 закрыт — Windows не скачает содержимое SYSVOL, политики и скрипты входа либо не применятся вообще, либо применятся с задержкой из кэша. Порт 88 (Kerberos) — вообще без вариантов, без него аутентификация не пройдёт.

Временные метки профилей пользователей

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

Эта команда показывает размер каждого профиля. Профили больше 2–3 ГБ — потенциальная проблема, особенно перемещаемые: они загружаются с сервера при каждом входе целиком. Однажды мы нашли профиль на 18 ГБ — пользователь хранил рабочие видеозаписи прямо в Documents. Логон занимал 12 минут.

Скрипты входа через Shell-Core журнал

Get-WinEvent -LogName "Microsoft-Windows-Shell-Core/Operational" -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match "script|startup|logon" -and $_.TimeCreated -gt (Get-Date).AddDays(-1) } |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated |
    Format-List

Shell-Core/Operational записывает события выполнения программ из автозапуска (Run, RunOnce) и скриптов входа. Ищите большие временные разрывы между событиями — они точно укажут на долго выполняющийся скрипт или программу. Иногда это bat-файл из 2010 года, про который никто уже не помнит.

User Profile Service — ключевые ошибки

Get-WinEvent -LogName "Application" |
    Where-Object { $_.ProviderName -eq "Microsoft-Windows-User Profiles Service" } |
    Where-Object { $_.Id -in @(1500, 1502, 1509, 1511, 1521, 1530, 1534) } |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20 |
    Format-List

Расшифровка Event ID для журнала User Profile Service:

• 1500 — завершение входа в систему (норма, всё хорошо)
• 1502 — ошибка выхода пользователя, профиль мог не сохраниться
• 1509 — невозможно скопировать файл в профиль: проблема с правами или банально кончилось место на диске
• 1511 — создан временный профиль: серьёзная ошибка, пользователь работает в temp и потеряет все изменения после выхода
• 1521 — невозможно загрузить профиль, скорее всего повреждён реестровый куст ntuser.dat
• 1530 — профиль не выгружен при предыдущем выходе, что может привести к конфликтам при следующем входе

Таблица: симптом → причина → решение

Официальная документация: Microsoft Learn — Windows Server, Microsoft Learn — PowerShell