Терминальный сервер RDS на Windows Server 2022 для 1С

Типичная ситуация: бухгалтерия и менеджеры работают в 1С с разных компьютеров, часть людей — из дома, а база лежит на одном сервере. Самый простой способ дать всем доступ к одной базе без пробросов общих папок через интернет — терминальный сервер на Windows Server 2022, к которому пользователи подключаются по RDP и запускают 1С уже на нём.

Коротко: на сервер ставятся две роли — узел сеансов (RD Session Host) и сервер лицензирования (RD Licensing). В домене удобнее полноценное развёртывание через мастер Server Manager с коллекцией сеансов; в рабочей группе ставятся только эти две роли, а настройки задаются локальной групповой политикой. Платформа 1С:Предприятие 8.3 устанавливается на сервер один раз для всех пользователей, базы лежат на локальном диске сервера или на сервере СУБД.

Какие роли нужны

Службы удалённых рабочих столов (Remote Desktop Services, RDS) состоят из нескольких служб. Для небольшого офиса с одним сервером нужны не все.

Роль	Зачем	Нужна ли для одного сервера с 1С
RD Session Host (узел сеансов)	Принимает подключения и запускает сеансы пользователей	Да, обязательно
RD Licensing (лицензирование)	Выдаёт клиентские лицензии RDS CAL	Да, можно на этом же сервере
RD Connection Broker (посредник подключений)	Управляет развёртыванием, коллекциями, балансировкой	Только в домене, ставится мастером
RD Web Access	Веб-страница с опубликованными приложениями RemoteApp	По желанию
RD Gateway (шлюз)	Подключение из интернета по HTTPS вместо открытого порта RDP	Желательно, если работают удалённо

Без сервера лицензирования терминальный сервер работает только в течение льготного периода — 120 дней, после чего подключения перестают приниматься. Поэтому роль RD Licensing и покупку (ввод лицензии) RDS CAL лучше сделать сразу, а не вспоминать о них через четыре месяца, когда сервер перестанет принимать подключения.

Домен или рабочая группа

Это главный выбор, от которого зависит порядок установки.

Параметр	Домен Active Directory	Рабочая группа
Установка	Мастер «Remote Desktop Services installation», стандартное развёртывание	Обычная установка ролей (role-based)
Коллекции сеансов, RemoteApp	Есть	Нет (нет Connection Broker)
Типы лицензий RDS CAL	На пользователя и на устройство	Только на устройство (Per Device)
Где настраиваются сеансы	Свойства коллекции и доменные GPO	Локальная политика `gpedit.msc`
User Profile Disks	Доступны в свойствах коллекции	Недоступны

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

Отдельный момент для рабочей группы: после обновления безопасности для CVE-2024-38099 сервер лицензирования требует, чтобы узел сеансов обращался к нему не анонимно. Если обе роли стоят на одной машине, это не важно. Если сервер лицензирования отдельный, Microsoft описывает настройку через отдельную локальную учётную запись и cmdkey, выполненный от имени NETWORK SERVICE.

Установка через Server Manager

В домене

Войдите на сервер под доменным администратором, откройте Server Manager и выберите Manage → Add Roles and Features.
Выберите Remote Desktop Services installation, затем Standard Deployment и Session-based desktop deployment.
Укажите серверы для ролей RD Connection Broker, RD Web Access и RD Session Host. Для одного сервера это одна и та же машина.
Отметьте автоматическую перезагрузку и нажмите Deploy.
После установки в разделе Remote Desktop Services → Overview добавьте роль RD Licensing, затем активируйте сервер лицензирования в RD Licensing Manager.
В Tasks → Edit Deployment Properties → RD Licensing выберите режим лицензирования и сервер лицензий.
Создайте коллекцию: Collections → Tasks → Create Session Collection, укажите узел сеансов и группу пользователей.

Полный вариант с шлюзом и сертификатами расписан в документации Microsoft по развёртыванию RDS.

В рабочей группе

В Server Manager выберите Add Roles and Features → Role-based or feature-based installation.
Отметьте роль Remote Desktop Services, а в ролевых службах — Remote Desktop Session Host и Remote Desktop Licensing.
Установите и перезагрузите сервер.
Активируйте сервер лицензирования и установите лицензии на устройство.
В gpedit.msc откройте Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Licensing и включите политики Use the specified Remote Desktop license servers (имя сервера лицензий) и Set the Remote Desktop licensing mode (Per Device).

Установка через PowerShell

Для рабочей группы достаточно поставить две роли:

Install-WindowsFeature -Name RDS-RD-Server, RDS-Licensing -IncludeManagementTools -Restart

В домене развёртывание создаётся командлетами модуля RemoteDesktop. Имена серверов указываются в формате FQDN:

New-RDSessionDeployment -ConnectionBroker "rds01.office.local" -WebAccessServer "rds01.office.local" -SessionHost "rds01.office.local"

New-RDSessionCollection -CollectionName "1C" -SessionHost "rds01.office.local" -ConnectionBroker "rds01.office.local"

Set-RDLicenseConfiguration -LicenseServer "rds01.office.local" -Mode PerUser -ConnectionBroker "rds01.office.local"

Проверить, сколько дней осталось от льготного периода и какой сервер лицензий видит узел сеансов, можно так:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.GetGracePeriodDays()
$obj.GetSpecifiedLicenseServerList()

Настройка сеансов

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

в домене — в свойствах коллекции на вкладке Session задать время завершения отключённого сеанса и лимит простоя;
в рабочей группе — политики в узле Remote Desktop Session Host → Session Time Limits: Set time limit for disconnected sessions и Set time limit for active but idle Remote Desktop Services sessions;
не снимать ограничение «один пользователь — один сеанс»: за него отвечает политика Restrict Remote Desktop Services users to a single Remote Desktop Services session в узле Connections. Если её выключить, один пользователь может открыть несколько сеансов, и в каждом будет свой экземпляр 1С.

Пользователи, которым разрешено подключаться, добавляются в локальную группу «Пользователи удалённого рабочего стола» (Remote Desktop Users) или в группу пользователей коллекции. Администраторов в рабочие группы пользователей не включайте.

Профили пользователей

У каждого пользователя на терминальном сервере свой профиль в C:Users. 1С хранит в профиле список баз (ibases.v8i в каталоге %APPDATA%1C1CEStart), настройки и кэш конфигураций, поэтому профили со временем растут. Варианты:

Локальные профили — самый простой вариант для одного сервера. Следите за свободным местом на системном диске.
User Profile Disks — включаются в свойствах коллекции (только в домене), профиль хранится в отдельном VHDX на сетевой папке.
FSLogix — контейнеры профилей от Microsoft, поддерживают Windows Server 2016–2025; право на использование даёт в том числе RDS CAL.

Что учесть для 1С

Установка платформы

Платформу 8.3 ставьте один раз на сервер, а не каждому пользователю. Начиная с версии 8.3.16 у установщика есть режим «Для всех» (в Program Files) и «Для текущего пользователя» — на терминальном сервере нужен первый. Перед установкой любых программ на узел сеансов переведите сервер в режим установки, а после — обратно:

change user /install
rem здесь запускаем установщик платформы
change user /execute

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

Где хранить базы и какие нужны права

Файловые базы кладите на локальный диск сервера, например D:1CBases, а не на сетевую папку другого компьютера — так работает быстрее и надёжнее.
Создайте группу, например 1C-Users, и дайте ей на каталог баз права NTFS «Изменение». Права на чтение недостаточно: 1С при работе создаёт в каталоге базы служебные файлы.
Пользователи не должны быть локальными администраторами сервера — права «Изменение» на каталог баз им хватает для работы.
Если пользователей много или база тяжёлая, переходите на клиент-серверный вариант с MS SQL Server или PostgreSQL; про настройку MS SQL под 1С у меня есть отдельная заметка.

Список баз и лицензии 1С

Чтобы не добавлять базы каждому пользователю вручную, в настройках окна запуска 1С можно указать общий файл списка баз (*.v8i) на сервере — тогда изменение в одном файле увидят все.

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

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

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

Можно ли поставить RD Session Host на контроллер домена?

Я так не делаю: пользователям пришлось бы давать право входа на контроллер домена, и любая их ошибка или вредоносная программа в сеансе окажется на машине с базой Active Directory. Если физический сервер один, лучше поднять на нём две виртуальные машины — контроллер домена и терминальный сервер.

Что будет, если не установить сервер лицензирования?

Первые 120 дней сервер работает без лицензий. После окончания льготного периода пользователи получат сообщение о том, что нет доступных серверов лицензирования, и подключиться не смогут. Администратор при этом может зайти через mstsc /admin, чтобы всё исправить.

Подойдут ли лицензии RDS CAL от Windows Server 2019?

Нет. Для узла сеансов на Windows Server 2022 нужны RDS CAL версии 2022 или 2025, а сам сервер лицензирования должен быть той же версии, что и лицензии, или новее.

Нужно ли открывать порт RDP в интернет?

Не рекомендую. Для удалённых сотрудников надёжнее RD Gateway с сертификатом или VPN до офиса, а прямой порт 3389 наружу — постоянная мишень для перебора паролей. Если настраивать это некому, можно привлечь специалистов по настройке серверов Windows.