Профили пользователей на терминальнике: UPD против FSLogix

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

Исторически первый вариант — перемещаемые профили. Профиль лежит в сетевой папке, при входе копируется на сервер целиком, при выходе копируется обратно.

Схема простая и понятная, но у неё три системных недостатка.

Время входа растёт вместе с профилем. Профиль бухгалтера с кэшем 1С, кэшем браузера и файлом Outlook легко достигает нескольких гигабайт. Копирование при каждом входе — минуты.

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

Не работают файлы, которые нельзя копировать на лету. В первую очередь OST-файл Outlook и поисковый индекс. Именно поэтому в схеме с перемещаемыми профилями Outlook приходится держать в онлайн-режиме, что медленнее и хуже.

Второй вариант — User Profile Disks (UPD), встроенный механизм RDS. Профиль хранится в файле VHDX, который монтируется к сеансу при входе. Копирования нет — есть монтирование.

Третий — FSLogix Profile Container. Идея та же, реализация лучше. Приобретён Microsoft и включён в лицензии RDS, отдельно платить не нужно.

Практический вывод, к которому мы пришли за несколько лет: для новых развёртываний берём FSLogix, для существующих на UPD — оставляем, пока не появится причина мигрировать.

UPD настраивается прямо в свойствах коллекции RDS, отдельного софта не требуется.

Set-RDSessionCollectionConfiguration -CollectionName "Office" `
  -EnableUserProfileDisk `
  -DiskPath "\\srv-file\UPD$" `
  -MaxUserProfileDiskSizeGB 20 `
  -ConnectionBroker rdcb.corp.local

Для каждого пользователя создаётся файл UVHD-{SID}.vhdx, который монтируется в C:\Users\username на время сеанса.

Сильные стороны: встроенность, отсутствие лицензионных вопросов, простота настройки.

Слабые, с которыми мы сталкивались:

Привязка к коллекции. Профиль принадлежит конкретной коллекции. Если пользователь работает в двух коллекциях, у него будет два независимых профиля.

Проблемы с одновременным подключением. Диск монтируется эксклюзивно. Попытка войти на второй хост, пока сеанс активен на первом, даёт временный профиль.

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

Лечится это принудительным размонтированием на хосте:

# посмотреть примонтированные UPD
Get-Disk | Where-Object { $_.Location -like '*UVHD*' } |
  Select-Object Number, Location, OperationalStatus
# размонтировать конкретный
Dismount-DiskImage -ImagePath "\\srv-file\UPD$\UVHD-S-1-5-21-....vhdx"

Мы держим этот сценарий отдельным скриптом: при жалобе «у меня всё пропало, рабочий стол пустой» первым делом проверяем именно залипшее монтирование, и в большинстве случаев этим всё и заканчивается.

FSLogix решает те же задачи, но с несколькими существенными улучшениями.

Не привязан к коллекции и к RDS вообще. Работает на любом Windows, включая обычные рабочие станции и VDI.

Умеет Office Container отдельно. Кэш Outlook, поисковый индекс и данные OneDrive можно вынести в отдельный контейнер. Практическая польза: профиль остаётся компактным, а тяжёлый почтовый кэш живёт отдельно и при необходимости пересоздаётся без потери настроек пользователя.

Гибкие правила исключений. Можно точечно исключать каталоги из контейнера — например, кэш браузера, который нет смысла хранить между сеансами.

Понятная диагностика. Пишет подробные логи в %ProgramData%\FSLogix\Logs с указанием, что и почему не смонтировалось.

Настраивается через реестр или групповую политику, шаблоны идут в комплекте.

$k = 'HKLM:\SOFTWARE\FSLogix\Profiles'
New-Item $k -Force | Out-Null
Set-ItemProperty $k -Name Enabled -Value 1 -Type DWord
Set-ItemProperty $k -Name VHDLocations -Value '\\srv-file\FSLogix$' -Type MultiString
Set-ItemProperty $k -Name SizeInMBs -Value 20480 -Type DWord
Set-ItemProperty $k -Name VolumeType -Value 'VHDX' -Type String
Set-ItemProperty $k -Name FlipFlopProfileDirectoryName -Value 1 -Type DWord
Set-ItemProperty $k -Name DeleteLocalProfileWhenVHDShouldApply -Value 1 -Type DWord

Два параметра из этого набора стоит пояснить.

FlipFlopProfileDirectoryName меняет формат имени каталога с «SID_username» на «username_SID». Мелочь, но при сотне пользователей искать по имени удобнее, чем по идентификатору.

DeleteLocalProfileWhenVHDShouldApply удаляет локальный профиль, если он мешает монтированию контейнера. Это лечит целый класс проблем при миграции с других схем, когда на хосте остались локальные профили пользователей.

И UPD, и FSLogix превращают файловый сервер в критичный компонент фермы. Недоступно хранилище — никто не может войти.

Требования к нему жёстче, чем к обычной файловой шаре.

Задержка. Профиль монтируется как диск, и все обращения к нему идут по сети. Высокая задержка означает медленную работу всего внутри профиля, включая открытие документов и работу почты.

Пропускная способность в пиковые моменты. Утренний вход сорока человек за десять минут — это одновременное монтирование сорока VHDX.

Отказоустойчивость. Одиночный файловый сервер — единственная точка отказа фермы.

Что мы делаем на практике для офиса до 50 мест:

• отдельный том на быстрых дисках, не тот же, где общие файлы;
• SMB 3 с включённым шифрованием только если требуется — оно стоит процессорного времени;
• резервное копирование контейнеров, но с осторожностью: бэкап примонтированного VHDX может быть неконсистентным, поэтому либо теневые копии, либо ночное окно;
• мониторинг свободного места с порогом 20 % — заполненное хранилище профилей мгновенно останавливает работу всех.

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

icacls "D:\FSLogix" /grant "CORP\Domain Users:(OI)(CI)M"
icacls "D:\FSLogix" /grant "CREATOR OWNER:(OI)(CI)(IO)F"
icacls "D:\FSLogix" /grant "CORP\RDS-Hosts:(OI)(CI)F"
# наследование от родителя убрать, чтобы пользователи не видели чужие профили

Группа с хостами нужна потому, что монтирование выполняется от имени машины, а не пользователя.

Два приложения, которые определяют размер профиля в российском офисе.

1С. Кэш платформы живёт в %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8. Первый каталог — метаданные и временные данные, он может занимать сотни мегабайт и легко пересоздаётся. Второй содержит настройки и список баз, его терять нельзя.

Правильная схема: первый исключаем из контейнера, второй оставляем.

# redirections.xml для FSLogix
<FrxProfileFolderRedirection ExcludeCommonFolders="0">
  <Excludes>
    <Exclude Copy="0">AppData\Local\1C\1cv8\Cache</Exclude>
    <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Cache</Exclude>
    <Exclude Copy="0">AppData\Local\Temp</Exclude>
  </Excludes>
</FrxProfileFolderRedirection>

Оговорка: исключение кэша 1С означает, что при каждом входе платформа будет его перестраивать. На первом запуске это добавит несколько секунд. Компромисс между размером профиля и скоростью запуска решается по факту — если кэш небольшой, проще его оставить.

Outlook. OST-файл — главный пожиратель места. При почтовом ящике в 20 ГБ и кэшировании за всё время профиль будет соответствующим.

Два решения. Первое — Office Container в FSLogix, выносящий почтовый кэш в отдельный VHDX. Второе, и часто более практичное, — ограничить период кэширования групповой политикой.

Три месяца кэша покрывают потребности большинства сотрудников и сокращают OST в разы. Всё, что старше, остаётся доступным на сервере и открывается по запросу.

Мы почти всегда начинаем со второго: оно проще, не требует дополнительных контейнеров и даёт основной эффект. Office Container добавляем, если этого оказалось мало.

Переход с одной схемы на другую — отдельная задача, которую нельзя сделать «в один вечер для всех».

Порядок, которым мы пользуемся при переходе с UPD на FSLogix:

1. Разворачиваем FSLogix на всех хостах, но не включаем.
2. Готовим хранилище с правами.
3. Включаем для тестовой группы из двух-трёх человек. Наблюдаем неделю.
4. Мигрируем по отделам, а не всех разом. Содержимое переносится либо утилитой миграции, либо просто заново — для многих пользователей проще один раз настроить рабочий стол, чем разбираться с конвертацией.
5. Старые UPD не удаляем минимум месяц.

Типовые аварии, с которыми сталкивались, и их причины:

Первая строка покрывает процентов семьдесят обращений. Диагностика начинается с логов FSLogix — они прямо пишут причину отказа монтирования, и гадать не приходится.

Отдельно про повреждённые VHDX: восстанавливаются они плохо, поэтому бэкап хранилища профилей — не формальность. Потеря контейнера означает потерю всех настроек пользователя: подписи в почте, списка баз 1С, избранного, сохранённых паролей. Формально это не производственные данные, фактически — день восстановления рабочего места.

Клиент — юридическая фирма, 34 рабочих места, ферма из двух узлов сеансов, профили на UPD.

Жалоба была на утренний вход. По словам сотрудников, с девяти до полдесятого «компьютер думает». Кто-то успевал сходить за кофе.

Замер подтвердил: вход занимал от 2 минут 40 секунд до 4 минут 15 секунд в интервале с 08:50 до 09:30. В обеденное время тот же пользователь входил за 22 секунды.

Зависимость от времени сразу указывала на конкуренцию, а не на конфигурацию.

Проверили размеры контейнеров. Медиана — 11 ГБ, максимум — 34 ГБ. Для юридической фирмы, где основной инструмент — почта и документы, это много.

Разбор содержимого дал ответ. У каждого пользователя внутри профиля лежал OST-файл Outlook на 6–20 ГБ: почта кэшировалась за всё время, а у части сотрудников ящики велись с 2019 года. Плюс кэш браузера, плюс каталог загрузок, куда годами складывались присланные документы.

Само по себе это не было бы проблемой — контейнер монтируется, а не копируется. Проблема возникала на хранилище: тридцать четыре человека одновременно монтировали тридцать четыре VHDX суммарным объёмом под 400 ГБ на файловом сервере с обычными SAS-дисками и гигабитным подключением.

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

Что сделали, в порядке применения:

• ограничили кэширование почты Outlook тремя месяцами через групповую политику — суммарный объём контейнеров упал с 390 ГБ до 96 ГБ примерно за неделю, по мере переподключения людей;
• перенастроили перенаправление каталога загрузок и документов на файловый сервер, убрав их из профиля;
• перенесли хранилище профилей на отдельный том из SSD;
• исключили кэш браузера из контейнера.

Первый пункт дал основной эффект и не стоил ничего. Третий добавил остаток.

Итог: вход в утренний пик — 31 секунда, вне пика — 14 секунд. Очередь к дискам хранилища в пике не превышает трёх.

Что показательно: изначально нас просили посчитать стоимость перехода на FSLogix, потому что «UPD медленный». UPD был ни при чём. Медленным было то, что через него таскали. Схему профилей не меняли вообще — она работает у клиента до сих пор.

Что выбрать для новой фермы — UPD или FSLogix?

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

Почему пользователь получает временный профиль?

Контейнер не смонтировался. Самые частые причины: залипшее монтирование после аварийного завершения предыдущего сеанса, нехватка прав на каталог хранилища, отсутствие свободного места. Логи FSLogix прямо указывают причину.

Можно ли работать одновременно на двух хостах фермы?

С контейнерными профилями — нет, диск монтируется эксклюзивно, и вторая сессия получит временный профиль. Это штатное поведение, а не сбой. Возвращать пользователя в его единственный сеанс — задача Connection Broker.

Как уменьшить размер профиля с 1С и Outlook?

Исключите из контейнера каталог кэша платформы 1С в LOCALAPPDATA, оставив каталог настроек в APPDATA. Для Outlook проще всего ограничить период кэширования почты групповой политикой — трёх месяцев обычно достаточно, а OST сокращается в разы.