Управление профилями пользователей на терминальном сервере

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

Ниже - что выбрать из механизмов Windows, какие права выставить на папку, где физически искать профиль и что делать, когда всё сломалось.

Локальный, перемещаемый или обязательный: какой профиль вам нужен

На практике выбирают между пятью механизмами. Три из них встроены в Windows, ещё два - надстройки: контейнеры FSLogix и User Profile Disks из состава служб удалённых рабочих столов. Разница сводится к тому, где лежит профиль и что происходит с изменениями после выхода.

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

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

Перемещаемые профили в Windows Server 2025 никуда не делись и работают, но Microsoft называет технологию устаревшей и обозначил намерение когда-нибудь её убрать. Планировать новую ферму на roaming-профилях в 2026 году - решение на короткую дистанцию.

Перемещаемые профили: почему вход тормозит

Механика простая и в ней же вся проблема. При входе служба профилей копирует сетевую папку на локальный диск сервера, при выходе - обратно. Копируется всё, что лежит в профиле и не попало в список исключений: настройки приложений, содержимое AppData\Roaming с его кэшами, документы и рабочий стол, если их не перенаправили на сетевой диск.

Сетевая папка профиля получает суффикс версии. Для Windows 10, 11 и Server 2016 и новее это .V6: профиль пользователя ivanov ляжет в \\server\profiles$\ivanov.V6. Версии между собой не смешиваются, и это защита: профиль от Windows 7 не поедет на Server 2022.

Что реально ускоряет вход:

• Перенаправление папок (Folder Redirection) через групповую политику. Документы, Рабочий стол, Загрузки, Избранное уезжают на сетевой диск и перестают копироваться при каждом входе. Профиль худеет сразу и заметно.
• Исключение тяжёлых папок из AppData\Roaming. Частый совет «исключите AppData\Local» устарел: эта папка вместе с AppData\LocalLow не роумится по умолчанию - список зашит в параметре ExcludeProfileDirs ветки HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Смотреть надо в AppData\Roaming, где оседают кэши Teams и почтового клиента. Добавляют папки политикой «Исключить каталоги из перемещаемого профиля» (Конфигурация пользователя → Административные шаблоны → Система → Профили пользователей); вернуть в профиль исключённые по умолчанию каталоги ею нельзя.
• Квота на размер профиля. Лимит в 2-3 ГБ дисциплинирует: архив проектов за три года перестаёт жить в профиле.
• Удаление локальных копий при выходе. Иначе на сервере через полгода лежат сто профилей уволившихся сотрудников.

Чего перенаправление папок не лечит - конфликта при одновременной работе. Если пользователь зашёл на два сервера фермы, выигрывает тот, кто вышел последним, а изменения первой сессии затираются. Штатное решение для roaming-профилей одно: запретить несколько одновременных сеансов через групповую политику.

Где физически лежат профили и как их правильно удалять

Локальные профили лежат в C:\Users\<логин>. Сетевые - там, куда указывает атрибут профиля в свойствах пользователя Active Directory, с суффиксом версии.

Но папка - только половина профиля. Вторая половина - запись в реестре: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Внутри - подразделы по SID пользователей, в каждом параметр ProfileImagePath с путём к папке. Именно оттуда Windows узнаёт, где искать профиль.

Отсюда главное правило: удалять профиль просто удалением папки нельзя. Запись в ProfileList останется, и при следующем входе пользователь получит либо временный профиль, либо папку с суффиксом вида ivanov.DOMAIN.001. Правильный путь - «Свойства системы» → «Дополнительно» → «Профили пользователей» → «Удалить»: Windows снесёт и папку, и запись в реестре.

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

Права на папку с профилями

Это место, где спотыкаются чаще всего: папку создали, политику настроили, а профили не создаются или создаются у одного пользователя из десяти. Причина почти всегда в правах.

На уровне общего доступа (Share) ставят полный доступ для группы пользователей профилей, а реальное ограничение делают через NTFS. Держать сложные правила в двух местах сразу - верный способ потом полдня искать, где именно закрыт доступ.

Права NTFS на корневой папке выглядят так:

Логика такая. Пользователю нужно право создать свою папку внутри корневой - и больше ничего: списка чужих папок он видеть не должен, поэтому права даются «только к этой папке» и не наследуются вниз. А когда он свою папку создал, он становится её владельцем, и права ему выдаёт запись CREATOR OWNER.

Наследование от родительской папки на корне профилей отключают и права задают явно. Если корневая папка лежит внутри общей файловой шары с наследованием от вышестоящих каталогов, пользователи начнут видеть чужие профили. Как настраивается сама шара - в отдельном разборе сетевой папки Windows Server через SMB.

FSLogix: что это, кому положен и где подводные камни

FSLogix - технология контейнеров профилей. Microsoft купил компанию-разработчика 19 ноября 2018 года и с тех пор развивает решение как основной механизм профилей для терминальных сред. Профиль упаковывается в виртуальный диск VHDX в сетевой папке; при входе диск монтируется, при выходе отключается. Копирования не происходит вообще, поэтому время входа перестаёт зависеть от размера профиля.

Работает на Windows Server 2016, 2019, 2022 и 2025, а также на клиентских Windows 10 и 11.

Про лицензии - главный вопрос, который обычно задают первым. Сам агент скачивается бесплатно, но право на использование даёт лицензия. Подходит любая из списка: Microsoft 365 E3/E5, A3/A5, F1/F3, Microsoft 365 Business, Windows 10/11 Enterprise E3/E5, Windows Education A3/A5, RDS CAL, RDS SAL, лицензия доступа Azure Virtual Desktop. Для типичной российской компании с обычной терминальной фермой важна строчка про RDS CAL: если вы уже купили клиентские лицензии на службы удалённых рабочих столов, право на FSLogix у вас есть.

Теперь про ограничение, о котором пишут реже. По умолчанию контейнер рассчитан на одну сессию. Параметр ProfileType в ветке HKLM\SOFTWARE\FSLogix\Profiles управляет поведением, и значение по умолчанию - 0, то есть обычный режим одной сессии. Чтобы пользователь мог войти на два хоста одновременно, на всех хостах выставляют ProfileType = 3 («попробовать чтение-запись, при неудаче - только чтение»).

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

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

User Profile Disks: почему это тупик

UPD - встроенный в службы удалённых рабочих столов механизм: тот же VHDX, но управляется средствами RDS и живёт в пределах одной коллекции сеансов. Настраивается действительно проще FSLogix - галочка в свойствах коллекции.

Проблема в том, что Microsoft технологию больше не развивает: UPD - legacy, а рекомендуемая замена - FSLogix. Сосуществовать они не могут, поэтому переход с UPD на FSLogix - это миграция с переносом данных, а не переключение флажка.

Отсюда простая развилка. Ферма уже работает на UPD и вас всё устраивает - можно не трогать, оно не сломается завтра. Разворачиваете новую ферму или планируете переезд на Windows Server 2025 - берите сразу FSLogix, чтобы не делать миграцию дважды.

Кому что можно: права и запуск программ

Профили решают вопрос «где лежат мои настройки», а не «что мне разрешено». Разграничение доступа на терминальном сервере строится отдельно и в три слоя.

Первый слой - Active Directory: она решает, кто вообще может войти на сервер. Управляется через группу «Пользователи удалённого рабочего стола» и политики входа. Второй - NTFS-разрешения, они определяют, до каких файлов и папок пользователь дотянется. Здесь работает принцип минимальных привилегий: права выдаются под задачу, а не «чтобы точно всё работало».

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

Шифрование профилей на терминальном сервере - тема, где легко перестараться. BitLocker защищает диск целиком и на сервере с постоянным доступом к данным помогает мало: пока сервер работает, том расшифрован. Смысл он имеет против выноса дисков. EFS шифрует отдельные файлы, но требует аккуратной работы с сертификатами и ключами восстановления, иначе первая же переустановка профиля превращается в потерю данных. Подробнее про защиту терминальной среды - в статье про безопасность данных на терминальном сервере.

Бэкап и типовые аварии

Централизованное хранение упрощает задачу: если профили лежат в одной сетевой папке, они попадают в общее расписание резервного копирования файлового сервера. Дедупликация на хранилище заметно сокращает объём - профили разных пользователей содержат много одинакового.

С контейнерами FSLogix есть нюанс: VHDX - один большой файл, и файловый бэкап заберёт его целиком даже при изменении пары килобайт. Решения с блочным копированием справляются лучше, но снимать копию всё равно разумнее в окно, когда пользователи вышли и контейнеры отмонтированы.

Аварии на профилях повторяются из года в год, и диагностика у них короткая:

Что делать российской компании в 2026

Прежняя рекомендация «смотрите в сторону Azure Virtual Desktop» для нас больше не работает: корпоративные облачные подписки Microsoft для российских организаций отключены, и строить на них планы бессмысленно.

Реальных дорог две.

Остаться на Windows Server и RDS. Тогда FSLogix - то, что нужно, и право на него у вас с большой вероятностью уже есть по RDS CAL. Сама схема живёт полностью на своём железе и от облачных подписок не зависит. Вопрос только в том, на чём эта ферма работает: под терминальную нагрузку железо подбирают по числу одновременных сессий и объёму памяти на пользователя, об этом - в разборе как выбрать терминальный сервер для бизнеса и в статье про настройку RDP-сервера на Windows.

Смотреть в отечественный контур. Termidesk от «Группы Астра» есть в двух вариантах - VDI и терминальный, работает на базе Astra Linux и умеет подключать в том числе Windows-серверы. Профили там устроены иначе, и переносить привычки из мира roaming-профилей не получится. Что выбрать из российских серверных ОС под такую задачу, разбирается в сравнении Astra Linux, Alt Server и РЕД ОС. Если рассматриваете полноценный VDI вместо терминального доступа, требования к железу там другие - см. VDI-сервер: требования и настройка.

Выбор между ними - вопрос не технологий, а горизонта планирования и требований регулятора к вашей отрасли.

И да, прежде чем закупать диски под разросшиеся профили, потратьте час на кэш браузера у пользователей. Иногда после этого закупка отменяется.