Windows создаёт временный профиль пользователя: причины и восстановление

Вход с временным профилем значит, что Windows не смогла загрузить ваш профиль и выдала пустой, который удалится при выходе. Не выходите, пока не скопируете файлы. Причину ищите в журнале Application и в ключе SID.bak в ProfileList. Ниже: команды диагностики, ремонт реестра и разбор из практики.

Что значит «вход с временным профилем» и почему файлы пропадают

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

Определение у Microsoft короткое и точное: временный профиль выдаётся каждый раз, когда ошибка не даёт загрузить профиль пользователя; такие профили удаляются в конце каждого сеанса, а изменения рабочего стола и файлов теряются при выходе. Я привожу это почти дословно, потому что именно с потерей данных связана половина звонков в поддержку: человек полчаса работал, сохранил договор «на рабочий стол», вышел, и в следующий вход файла нет. На самом деле он лежал во временной папке, которую система стёрла.

Что видит пользователь. Рабочий стол пустой или «как у новой учётной записи», пропали ярлыки, панель задач в заводском виде, в Outlook и браузере нет настроек, а при входе появляется сообщение о том, что вы вошли с временным профилем и файлы будут удалены при выходе. Запомните эту картину: если стол пустой, но никакого сообщения нет, причина может быть другой, например не подключились перенаправленные папки или сменилась учётная запись. Это отдельная история, мы её не разбираем.

Чем эта статья отличается от разбора про терминальные серверы. Там проблема в контейнере профиля на хранилище, и я описывал её в статье про UPD и FSLogix для профилей на терминальном сервере. Здесь речь об обычной рабочей станции или ноутбуке с локальным профилем, в домене или без. Механика похожая, но причины и лечение другие, и в большинстве случаев всё упирается в реестр, права на папку или диск.

Как за пять минут понять причину: журнал, SID и статус профиля

Не начинайте с правок реестра. Сначала выясните, что именно сломалось, иначе вы вылечите симптом, и через неделю всё повторится. Мой порядок такой: убедиться, что пользователь действительно во временном профиле, найти его SID, прочитать журнал Application за время входа. Три шага занимают пять минут и заранее отсекают половину гипотез.

Откройте консоль в сеансе проблемного пользователя и посмотрите, куда указывает профиль и под каким SID вошла учётная запись. Команда whoami с ключом /user выводит домен, имя и SID, это описано в справке команды. Путь к папке у временного профиля обычно содержит TEMP, а не имя пользователя.

whoami /user
$env:USERPROFILE

Статус профиля можно прочитать через WMI. У класса Win32_UserProfile есть свойство Status, это битовая маска: значение 1 означает временный профиль, который будет удалён после выхода, значение 8 означает повреждённый профиль, который не используется и требует исправления. Запрос показывает все профили машины сразу и пригодится, когда вы разбираете не один компьютер, а целый отдел. Страница про этот класс у Microsoft лежит в архиве, так что на свежих сборках Windows проверьте результат глазами.

Get-CimInstance Win32_UserProfile |
  Select-Object LocalPath, SID, Status, Loaded, LastUseTime |
  Format-Table -AutoSize

Теперь журнал. Нужное событие пишет служба профилей пользователей в журнал Application. Это событие с кодом 1511 от источника User Profiles Service с текстом «Windows cannot find the local profile and is logging you on with a temporary profile». Его разбор есть в архивной статье TechNet Wiki на Microsoft Learn: среди причин там названы повреждённый профиль, нехватка прав на папки профиля, удалённая вручную папка при живой записи в реестре и антивирус, сканирующий профиль в момент входа. Рядом часто стоит событие 1515 о том, что Windows сделала резервную копию профиля, это прямая подсказка на историю с .bak. Отбираем события за неделю двумя способами, оба описаны в справке: через wevtutil с XPath-запросом или через Get-WinEvent с таблицей фильтра, где ключи LogName, Id и StartTime. Рядом с вашим событием посмотрите те, что произошли в ту же минуту: ошибки диска, антивируса и групповых политик часто называют настоящего виновника.

wevtutil qe Application /q:"*[System[(EventID=1511)]]" /c:5 /rd:true /f:text

Get-WinEvent -FilterHashtable @{
  LogName='Application'; Id=1511; StartTime=(Get-Date).AddDays(-7)
} | Format-List TimeCreated, Message

Если нужен общий подход к чтению событий входа, у меня есть отдельный материал про диагностику входа в Windows через PowerShell. Там разобраны события входа и выхода, которые я здесь не повторяю.

Самая частая причина: в реестре остался ключ SID с суффиксом .bak

Из всех причин, которые я видел на рабочих станциях в малых офисах, чаще всего встречается одна: рассинхронизация записи профиля в реестре. Список профилей хранится в ветке HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, где у каждого пользователя свой подраздел с именем в виде SID. В нём есть параметр ProfileImagePath с путём к папке профиля, а также State и RefCount. После аварийного выключения или сбоя при выходе подраздел может оказаться переименованным в SID с добавлением .bak, и система при следующем входе создаёт второй, новый подраздел с тем же SID и выдаёт временный профиль.

Подчеркну: способ описан в многочисленных разборах сообщества, а не в одной официальной инструкции Microsoft, поэтому я всегда делаю резервную копию ветки до правок. Это одна команда, и она спасала меня не раз. Затем смотрим на все подразделы: имя профиля в ProfileImagePath и наличие пар «SID» и «SID.bak».

reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" C:\Temp\ProfileList.reg

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList' |
  ForEach-Object {
    $p = Get-ItemProperty $_.PSPath
    [pscustomobject]@{ Key=$_.PSChildName; Path=$p.ProfileImagePath; State=$p.State; RefCount=$p.RefCount }
  } | Format-Table -AutoSize

Дальше действуем по схеме. Если есть пара SID и SID.bak, подраздел без .bak, который указывает на TEMP, переименовываем в SID.old, а не удаляем: это страховка, чтобы можно было вернуться. Подраздел с .bak переименовываем, убирая суффикс. В восстановленном подразделе проверяем, что ProfileImagePath указывает на реальную папку C:\Users\<имя>, и обнуляем State и RefCount, так как в «залипших» подразделах там остаются ненулевые значения. Всё это делается под локальным администратором, пока пользователь не вошёл. SID в примере условный.

$k = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList'
$sid = 'S-1-5-21-1111111111-2222222222-3333333333-1105'
Rename-Item "$k\$sid" "$sid.old"
Rename-Item "$k\$sid.bak" $sid
Set-ItemProperty "$k\$sid" -Name State -Value 0
Set-ItemProperty "$k\$sid" -Name RefCount -Value 0

Если подраздела с .bak нет вовсе, а временный профиль есть, значит, запись о профиле либо отсутствует, либо указывает на несуществующую папку. Тогда сверьте ProfileImagePath с реальным содержимым C:\Users и поправьте путь. Если папки пользователя на диске нет или внутри нет файла NTUSER.dat, это уже не правка реестра, а пересоздание профиля, о нём ниже. Если ветка в порядке, а проблема остаётся, переходим к правам и диску.

Права на папку, место на диске и антивирус: когда реестр ни при чём

Вторая по частоте причина: служба профилей не может открыть файл NTUSER.dat или записать в папку профиля. Здесь три типовых виновника. Первый: права на C:\Users\<имя> нарушены после неудачного переноса, ручного копирования профиля или «чистки» через takeown. Второй: на системном диске кончилось место, и профиль не загрузился или не создался. Третий: антивирус или система резервного копирования держит файл открытым.

Права проверяем командой icacls: без ключей она печатает текущий список доступа. У профиля должны быть записи для самого пользователя, SYSTEM и группы администраторов. Перед любой правкой сохраните ACL: ключи /save и /restore в документации описаны именно для этого. А вот ключ /reset на корне профиля я не применяю: он заменяет ACL наследуемыми от C:\Users, а у папки профиля наследование обычно отключено и права пользователя заданы явно, так что после сброса владелец может остаться только с чтением. Вместо этого явно выдаю полный доступ пользователю, SYSTEM (*S-1-5-18) и локальным администраторам (*S-1-5-32-544) с наследованием на всё дерево. SID со звёздочкой работают в любой локализации Windows.

icacls C:\Users\ivanov
icacls C:\Users\ivanov\* /save C:\Temp\ivanov-acl.txt /t /c
icacls C:\Users\ivanov /grant "EXAMPLE\ivanov:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "*S-1-5-32-544:(OI)(CI)F" /t /c

Диск проверяем в два захода. Сначала свободное место: если на C: его почти нет, чистим кэш обновлений и временные файлы, у меня на эту тему есть разбор про очистку диска и кэша обновлений Windows. Потом файловую систему: chkdsk с ключом /scan запускает онлайн-проверку тома NTFS без остановки, а ключ /f исправляет ошибки и, если том занят, предложит выполнить проверку при следующей перезагрузке. После перезагрузки смотрим результат в журнале Application по источникам Chkdsk и Wininit, как в справке Microsoft.

chkdsk C: /scan
chkdsk C: /f

Антивирус и бэкап проверяются просто: на время теста добавьте C:\Users в исключения или временно остановите сканирование, перезагрузите компьютер и войдите. Если профиль загрузился, причина найдена, а дальше нужно донастраивать исключения у вендора, а не отключать защиту совсем. Отдельно обратите внимание на клиентов облачной синхронизации и агентов копирования, которые могут держать NTUSER.dat после некорректного выхода. Если после всех проверок профиль не подхватывается, в ход идёт пересоздание, но только после сохранения данных.

Как вынуть данные и пересоздать профиль без потерь

Если пользователь прямо сейчас сидит во временном профиле, работайте так. Не давайте выходить. Подключите внешний диск или сетевую папку и скопируйте всё, что пользователь успел создать за сеанс: рабочий стол, документы, загрузки. Это ничего не изменит в настоящем профиле. Затем перезагрузите компьютер и пока ничего не чините, просто посмотрите, исчезла ли проблема: иногда одной перезагрузки достаточно, если профиль был занят службой или антивирусом.

Настоящие файлы лежат в C:\Users\<имя>, и их можно скопировать, войдя под другой учётной записью администратора. Копируйте проводником или robocopy с ключом /E: так вы заберёте и папки с файлами, и пустые каталоги. Отдельно сохраните почтовые данные и закладки браузера, если они хранятся в профиле локально. Целиком каталог AppData переносить не нужно, берите только данные приложений, которые вы знаете.

Пересоздание профиля делаем, только когда остальные варианты исчерпаны или файл NTUSER.dat повреждён. Порядок такой: сохраняем данные, удаляем профиль штатно и даём пользователю войти заново. Удалять надо через свойства системы или через CIM, а не руками папкой, иначе в реестре останется хвост, и мы вернёмся к проблеме с .bak. Сначала выведите список и убедитесь, что профиль выгружен (Loaded равно False); команду проверьте на тестовой машине в своей версии Windows.

Get-CimInstance Win32_UserProfile |
  Where-Object { $_.LocalPath -like '*\ivanov' -and -not $_.Loaded } |
  Remove-CimInstance

После первого входа в новый профиль верните данные из копии выборочно: документы, закладки, подписи почты. Не копируйте обратно всю старую папку целиком вместе с NTUSER.dat и AppData: вы перенесёте то самое повреждение, из-за которого всё сломалось. Для небольших организаций лучше один раз настроить перенаправление папок, чтобы «Рабочий стол» и «Документы» жили на файловом сервере, и такая история перестала быть потерей данных.

Разбор из практики: отель на 27 рабочих мест после отключения электричества

Отель «Отель Полярная звезда», 27 рабочих мест, один сервер с общими папками, всё в домене. В понедельник утром после ночного отключения электричества мне позвонили с ресепшена: на трёх компьютерах администраторов и одном в бухгалтерии пользователи вошли с временным профилем, рабочие столы пустые. ИБП на стойке в тот вечер не было, ресепшен сидел на обычных розетках.

Я подключился удалённо к первому компьютеру и сначала сделал то, о чём говорил выше: не дал выйти. Администратор уже успела сохранить два счёта на рабочий стол, мы скопировали их в сетевую папку. В журнале Application было событие 1511 за время входа. В реестре у двух компьютеров из трёх нашлись пары «SID» и «SID.bak», у третьего .bak не было. На двух я выполнил переименование, обнулил State и RefCount, пользователь вошёл, и профиль встал на место. На каждую машину ушло около десяти минут, включая резервную копию ветки.

Третий компьютер оказался интереснее. Подраздел был на месте, но вход всё равно шёл во временный профиль, а chkdsk /scan показал ошибки тома после аварийного выключения. Я запланировал chkdsk /f на перезагрузку, он отработал около двадцати пяти минут. NTUSER.dat остался повреждённым. Скопировав документы и закладки администратора, я удалил профиль через CIM и позволил Windows создать новый. Вместе с настройкой принтера и подписей почты весь процесс занял около сорока минут. Четвёртый компьютер, в бухгалтерии, лечился так же, как первые два.

Выводы мы сделали такие. На ресепшен и в бухгалтерию поставили ИБП, чтобы выключение было штатным и без обрыва записи. Рабочий стол и «Документы» для 27 пользователей перенаправили на файловый сервер, остальной локальный профиль теперь можно пересоздать за пять минут без потерь. Событие 1511 вывели в оповещение мониторинга, чтобы узнавать о временном профиле до звонка пользователя. За полгода после этого повторов не было, а до этого такие случаи происходили трижды за квартал. Работы по ИБП и перенаправлению заняли два дня.

Как не допустить повтора: чек-лист, который я выдаю клиентам

Главное в профилактике: временный профиль почти всегда рождается из некорректного завершения. Электропитание, зависшее обновление, принудительное выключение кнопкой, антивирус, который держит файлы в момент выхода. Поэтому первые пункты в моём списке про железо и процессы, а уже потом про реестр. На практике достаточно закрыть три-четыре пункта, и количество обращений падает кратно.

Групповая политика «Не выполнять вход пользователей с временными профилями» (Do not log users on with temporary profiles) в разделе Computer Configuration, Administrative Templates, System, User Profiles полезна не везде. В реестре она соответствует параметру ProfileErrorAction типа DWORD со значением 1 в ветке HKLM\SOFTWARE\Policies\Microsoft\Windows\System. Если её включить, то при невозможности загрузить профиль Windows просто завершит сеанс, а не пустит пользователя во временный. Для рабочих станций офиса это честнее: человек сразу видит ошибку и звонит, а не работает полдня впустую. Но на ресепшене, где без входа вообще нельзя работать, решение за вами. Русское название политики в разных сборках может немного отличаться, ориентируйтесь на английское и на раздел User Profiles. Про базовые политики малого офиса есть материал про групповые политики для малого офиса.

Мониторинг события 1511 в журнале Application позволяет узнать о проблеме первым. Для разбора причин пригодится практика чтения журнала, о ней я писал в статье про журнал событий Windows для системного администратора. И обязательно храните резервную копию данных, которая не зависит от профиля: перенаправление папок и регулярный бэкап файлового сервера. Тогда временный профиль превращается из аварии в двадцатиминутную рутину.

• ИБП на рабочих местах, где нельзя терять питание: ресепшен, касса, бухгалтерия
• Перенаправление «Рабочего стола» и «Документов» на файловый сервер
• Исключения антивируса и бэкапа для каталога профилей, настроенные у вендора
• Оповещение на событие 1511 в журнале Application
• Резервная копия ветки ProfileList перед любыми правками реестра
• Запас свободного места на системном диске, который вы определили заранее

Частые вопросы