FSLogix на терминальном сервере: где хранить профили и как проверить права по лицензии

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

Звучит заманчиво, но между желанием и запуском стоят три вопроса: имеете ли вы право использовать технологию, что именно происходит при входе и выходе, и как восстановить одного пострадавшего человека, не трогая остальных. Разберём их по порядку.

Сначала право, потом установка

Технически поставить компоненты FSLogix на Windows Server можно, не задавая лишних вопросов. Это ловушка: возможность установки не равна праву использования. Согласно требованиям Microsoft к FSLogix, технологию разрешено применять и в публичном, и в частном дата-центре, но при наличии подходящей пользовательской лицензии. В перечне такие лицензии есть: часть планов Microsoft 365 и RDS CAL/SAL. Важная оговорка в том же источнике: не любая лицензия Windows автоматически подходит.

Из этого следуют практические вещи, которые стоит сделать до первого пилота:

• Выписать, какие лицензии у вас фактически есть на каждого пользователя будущего терминального сервера: подписка Microsoft 365, RDS CAL, RDS SAL — или ничего из перечисленного.
• Сверить эти лицензии с актуальным перечнем в документации Microsoft, а не с памятью коллег и не со старыми форумными ответами.
• Отдельно отметить, что лицензия на сам Windows Server и лицензия доступа пользователя к терминальным службам — разные сущности. Одно не заменяет другое.
• Если Windows на VPS арендован у провайдера, уточнить, какие лицензионные права входят в аренду и что остаётся на вашей стороне. Считать, что FSLogix «включён в любой Windows VPS», нельзя: это зависит от того, какие именно лицензии покрывают ваших пользователей.

Полезно записать результат в виде короткой таблицы: пользователь или группа, какая лицензия, где подтверждение. Такая табличка скучна, зато через год, когда придёт новый администратор или проверка, она избавит от неприятного разговора.

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

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

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

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

Важно различать два типа контейнеров. Первый — контейнер профиля: он содержит пользовательский профиль целиком. Второй — ODFC, контейнер данных Office, куда выносятся данные офисных приложений. Это разные объекты с разным назначением, и их можно рассматривать как два отдельных предмета резервирования. Если вы планируете оба, то у каждого пользователя будет не один «чемодан», а два, и считать место и восстановление придётся для обоих.

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

Путь пользователя: от пароля до выхода

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

1. Аутентификация. Система узнаёт, кто пришёл. Без этого шага непонятно, чей контейнер искать.
2. Поиск контейнера. Служба определяет, где должен лежать контейнер Ольги по настроенному расположению. Если контейнера нет, он создаётся при первом входе; если есть, берётся существующий.
3. Подключение. Виртуальный диск контейнера подключается к сессии, и профиль «появляется» на привычном месте для приложений.
4. Работа. Всё, что Ольга меняет — документы на рабочем столе, настройки, кэш, — пишется внутрь контейнера, то есть по сети на хранилище.
5. Выход. Диск отключается, контейнер освобождается, и в следующий раз его сможет подключить любой сервер фермы.

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

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

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

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

Права на хранилище: тонкое место входа

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

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

Место на диске: контейнер не равен его содержимому

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

FSLogix умеет сжимать такие диски и, как сказано в материале Microsoft о диагностике сжатия VHD, фиксирует результат в журнале профиля и событиях. Там же есть два ограничения, которые полезно держать в голове при планировании:

• Фиксированный VHD этим механизмом не сжимается. Выбрав фиксированный тип ради предсказуемости, вы получаете предсказуемый размер, но отказываетесь от возврата места.
• Если освобождаемого места недостаточно, операция пропускается — и это отдельная причина, а не сбой.

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

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

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

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

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

Какой ресурс сервера за что отвечает

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

Конфигурации VPS MAATRIX на NVMe с AMD EPYC и root-доступом начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идут через Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) до Djed (16 vCPU, 32 ГБ, 320 ГБ). Это отправная точка для пробы, а не обещание, что на таком-то тарифе поместится столько-то человек. Сколько одновременных сессий выдержит конкретный набор приложений, покажет только замер с вашей нагрузкой. А вот логика выбора помогает: если контейнеры предполагается держать на том же сервере, диск становится ограничивающим ресурсом раньше процессора, и стоит смотреть на объём NVMe в первую очередь; если хранилище отдельное, на первый план выходят память и ядра для сессий. Заказ оформляется в форме на сайте, оплата возможна картой РФ или через СБП, а VPS создаётся автоматически через пару минут после оплаты; доступные локации и образы лучше проверить в самой форме заказа. Условия лицензирования Windows и FSLogix при этом остаются вашей обязанностью проверить отдельно — аренда мощностей сама по себе их не решает.

Когда ломается не сервер, а один профиль

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

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

Восстановить одного, не трогая остальных

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

1. Убедиться, что у пользователя нет активной сессии, при которой контейнер подключён. Подменять файл под работающей сессией не стоит.
2. Не удалять текущий контейнер, а переименовать или отложить его в сторону: он нужен как улика и как запасной вариант, если копия окажется хуже.
3. Поместить копию на место контейнера, сохранив имя и права, которые ожидает система.
4. Попросить пользователя войти и проверить результат по конкретным признакам: открывается ли почта, на месте ли нужные файлы.
5. Только после подтверждения убрать отложенный в сторону повреждённый контейнер — или оставить на разбор причины.

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

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

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

Учебная репетиция вместо надежды

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

1. Создайте тестового пользователя и войдите под ним. Положите на рабочий стол несколько узнаваемых файлов и измените пару настроек приложения.
2. Выйдите и убедитесь, что контейнер появился на хранилище. Запишите, где именно он лежит и какого он размера.
3. Сделайте копию этого контейнера так, как это предусмотрено вашей схемой резервирования.
4. Снова войдите, удалите часть файлов и испортите настройки — имитируя ошибку пользователя.
5. Выйдите и выполните восстановление по описанной выше последовательности.
6. Войдите снова и сверьте результат: вернулись ли файлы и настройки так, как были на момент копии.
7. Запишите, сколько времени заняла операция и какие шаги вызвали вопросы. Эта запись и есть главный итог репетиции.

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

Что резервировать теперь

Прежде резервировали содержимое папок профилей и, возможно, образ сервера. Теперь у профиля есть собственное физическое воплощение — файл контейнера, и именно он становится самостоятельным объектом резервирования. Есть нюансы, которые стоит обдумать: копировать файл подключённого, то есть используемого, контейнера не то же самое, что копировать закрытый; частота копий должна соответствовать тому, сколько работы пользователя вы готовы потерять; хранилище копий лучше держать отдельно от хранилища контейнеров, чтобы одна авария не забрала оба. Автоматические резервные копии не следует считать данностью любого VPS: наличие и порядок их работы нужно проверять отдельно, а не предполагать.

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