RemoteApp для бухгалтерии: одна программа вместо полного рабочего стола на VPS

Представьте рабочее место бухгалтера по расчётам. Весь день у неё открыты три вещи: учётная программа, таблица с выверкой и почта. Ей совершенно не нужен ещё один рабочий стол с обоями, корзиной и панелью задач, спрятанный внутри её собственного рабочего стола. Он путает: два меню «Пуск», два окна с часами, и непонятно, в каком из миров сейчас лежит файл «Акт_сверки_финал2.xlsx». Ей нужна иллюзия, что программа просто стоит на её компьютере, а то, что она физически работает на Windows-сервере в дата-центре, остаётся деталью инфраструктуры.

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

От ярлыка до окна: как выглядит день пользователя

Для сотрудника путь короткий. У него на рабочем столе или в меню появляется ярлык с названием программы, например «Учёт». Он нажимает на него, система подключается к серверу, и через несколько секунд на экране открывается окно, которое выглядит как обычное окно Windows. Оно сворачивается в панель задач рядом с локальными программами, его можно перетащить на второй монитор, у него своя кнопка на Alt+Tab. Рамки удалённого рабочего стола нет.

За этим стоит простая схема. Когда пользователь запускает опубликованную программу, на сервере открывается обычный сеанс служб удалённых рабочих столов (RDS), но вместо всей оболочки Windows в нём стартует только указанный исполняемый файл. Картинка окна транслируется на клиентский компьютер. Сеанс при этом настоящий, полноценный: у пользователя есть профиль, процессы, переменные окружения. Просто «окно сервера» ему не показывают.

Теперь о том, как это настраивается. По документации Microsoft, коллекция RDS содержит доступные пользователям приложения и рабочие столы, а программы публикуются через пункт Publish RemoteApp programs после создания коллекции (Microsoft: коллекция и RemoteApp). Из этого следует важное практическое наблюдение: коллекция является единицей управления. Вы не публикуете «приложение вообще», вы публикуете его внутри коллекции, и пользователи, которым разрешён доступ к коллекции, видят этот набор программ.

Пример с одним приложением и одним документом

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

1. Анна запускает ярлык «Учёт». Программа открывается на сервере, но выглядит локальной.
2. В программе она выбирает «Загрузить выписку». Открывается стандартное окно выбора файла. И вот здесь проявляется главная особенность: это окно создано на сервере, и по умолчанию оно показывает диски сервера, а не диски Анны.
3. Если в настройках подключения включено перенаправление дисков, то локальные диски Анны в окне выбора появятся как дополнительные устройства, и выписку можно выбрать прямо из «Загрузок». Если перенаправление отключено политикой или самим клиентом, окно покажет только серверные папки, и Анне придётся сначала положить файл туда другим способом.
4. Программа читает файл, обрабатывает данные, и результат (например, выгрузка отчёта) сохраняется туда, куда укажет Анна: на сервер или на перенаправленный локальный диск.

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

Опубликовать программу не значит ограничить пользователя

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

Вот что это значит на практике. Допустим, вы опубликовали только учётную программу. Но в самой программе есть диалог открытия файла, а через него можно добраться до папок сервера, к которым у учётной записи есть доступ. Из некоторых программ можно запустить справку, а из неё браузер, а из браузера обозреватель файлов. Если программа умеет вызывать внешние приложения (например, открывать вложение в стандартной программе), пользователь получит доступ к ним, пока политики системы этого не запретят.

Поэтому разумно мыслить двумя независимыми слоями:

• Слой публикации. Что показано пользователю: какие программы входят в коллекцию, какие группы имеют к ней доступ. Это вопрос удобства и порядка.
• Слой прав внутри Windows. Что учётная запись реально может читать, изменять и запускать: права на папки, групповые политики, ограничения на запуск программ. Это вопрос безопасности.

Обычная ошибка администратора, который только знакомится с RemoteApp, состоит в том, чтобы считать первый слой заменой второго. Если папка с зарплатными ведомостями доступна группе «Пользователи домена» (или всем локальным пользователям сервера), её сможет открыть и бухгалтер из соседнего отдела, и замысел «каждому свою программу» ничего не изменит. Публикация лишь прячет ярлыки.

Группы как язык описания ролей

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

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

Где живут файлы, настройки и сеанс

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

Файлы

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

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

Настройки

Настройки программы (расположение окон, последние открытые базы, параметры печати) хранятся в профиле пользователя на сервере. Из этого следуют два практических вывода. Во-первых, если несколько человек работают под одной общей учётной записью (так делать не стоит, но так делают), они будут постоянно перетирать настройки друг друга. Во-вторых, при нескольких серверах в одной коллекции профиль нужно где-то хранить централизованно, иначе пользователь, попавший на другой сервер, обнаружит, что его настройки «пропали». Для небольшой бухгалтерии на одном VPS этой проблемы нет, но про неё стоит помнить, если планируете расти.

Сеанс

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

Печать и обмен документами: самое капризное место

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

Microsoft описывает перенаправление принтеров как схему, где требуется разрешение на стороне клиента и подходящие политики сервера, причём Easy Print и legacy print имеют разные требования (Microsoft: перенаправление принтеров). Практический вывод: если принтер не появился в сеансе, виноватым может быть любой конец цепочки. Там же указано, что в клиенте mstsc нужно проверить флажок Printers на вкладке Local Resources, а политика может запретить перенаправление независимо от того, исправен ли локальный принтер.

Отсюда удобный порядок диагностики, который родился не из документации, а из здравого смысла: двигаться от пользователя к серверу.

1. Принтер печатает локально, из обычной программы на компьютере пользователя? Если нет, при чём тут сервер.
2. Разрешено ли клиенту передавать принтеры в сеанс? Это настройка подключения.
3. Не запрещает ли перенаправление политика на сервере? Это настройка администратора.
4. Какой механизм печати используется и подходит ли он конкретной модели принтера?

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

Обмен документами в обе стороны

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

Сколько памяти нужно под один опубликованный сеанс

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

Условный пример для понимания логики. Допустим, вы измерили, что один сеанс с учётной программой и открытой таблицей занимает около 1,2 ГБ в рабочий момент (цифра придумана для иллюстрации, вам придётся измерить свою). Система Windows и службы сервера занимают собственную долю, пусть 2 ГБ. Пять одновременных сеансов дадут 5 × 1,2 = 6 ГБ плюс 2 ГБ системы, то есть 8 ГБ только на постоянную часть. Добавим запас на пики и кэш, и получится, что для пяти человек комфортнее смотреть в сторону конфигурации с 16 ГБ, а не с 8 ГБ.

Мораль не в цифрах, а в методе. Запустите одну сессию, дайте реальному бухгалтеру поработать с типовыми задачами и посмотрите, сколько памяти и процессорного времени она использует в диспетчере задач. Умножьте на число одновременных пользователей, добавьте запас, и у вас будет отправная точка для выбора плана. Уровни MAATRIX по ресурсам такие: 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, который указан в публичном предложении, здесь уместен: открытие базы и сохранение больших файлов упираются именно в дисковые операции. А вот о резервных копиях в тарифах MAATRIX ничего не заявлено, поэтому бэкап для бухгалтерской базы вам придётся продумывать самостоятельно, вне зависимости от выбранного плана.

Что требуется от Windows Server и лицензирования

Тема лицензий неприятна, но от неё не уйти. Работа нескольких пользователей через RemoteApp означает использование служб RDS, а значит, возникает вопрос о правах на подключение.

По документации Microsoft, подключения к RDS Session Host лицензируются по пользователям или по устройствам, а сервер лицензирования выдаёт и отслеживает клиентские лицензии доступа, то есть RDS CAL (Microsoft: RDS CAL). Выбор между режимами «на пользователя» и «на устройство» влияет на бюджет. Для бухгалтерии, где один сотрудник может заходить с рабочего ноутбука и домашнего компьютера, режим «на пользователя» обычно логичнее, а режим «на устройство» подходит там, где одним компьютером пользуются несколько человек по сменам. Это рассуждение авторское, окончательное решение зависит от условий вашего лицензионного соглашения.

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

Для читателя, выбирающего VPS, из этого вытекают несколько практических вопросов, которые надо решить до заказа, а не после:

• Откуда будет лицензия на Windows Server и каким образом она связана с этим сервером.
• Какие RDS CAL нужны, по пользователям или по устройствам, и сколько.
• Совпадает ли версия CAL с версией сервера, которую вы планируете.
• Кто будет администрировать сервер лицензирования и где он будет размещён.

Стоимость VPS MAATRIX не включает RDS-лицензии и лицензии на прикладные программы вроде 1С, и в публичном предложении такого обещания нет. Конкретное наличие образов Windows и условия их использования стоит уточнять в форме заказа. Платформа даёт root-доступ, NVMe, процессоры AMD EPYC и локации UK, US, RU и FR, а оформление лицензий остаётся на стороне заказчика. Если вы пытаетесь сэкономить на лицензиях, то создаёте юридический и операционный риск, и ничего хорошего из этого не выйдет: обходить лицензирование не стоит.

Когда RemoteApp, а когда полный рабочий стол

Наконец, главный вопрос: как выбрать. Ответ в том, что выбор делается по работе сотрудника, а не по тому, какой вариант выглядит аккуратнее.

RemoteApp подходит, когда:

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

Полный рабочий стол лучше, когда:

• сотрудник использует много разных программ, и список всё время меняется;
• ему нужны системные инструменты: проводник, настройки, консоли;
• работа предполагает установку или обновление программ на стороне пользователя (чего в бухгалтерии обычно не должно быть);
• вы хотите, чтобы пользователь точно понимал, что он на сервере, чтобы не путал локальные и удалённые файлы.

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

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

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