Установим роли терминального сервера на Windows Server 2019 и лицензируем. Маленькая тонкость — сервер не в домене.
Подготовка Windows Server 2019
Для начала установим сам сервер. Всё необходимое вынесено в отдельную статью:
Установка Windows Server 2019 на виртуальную машину VMware
Не забываем про настройку:
Первоначальная настройка Windows Server 2019
Итак, операционная система установлена и настроена. Сервер в рабочей группе WORKGROUP.
Установка роли терминального сервера
Нам понадобится установить две роли, можно выполнить установку одновременно, я предлагаю инструкцию с минимальным количеством перезагрузок.
Роль Remote Desktop Licensing
Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.
Попадаем в раздел Before You Begin.
Это начальная страница, пропускаем. Next.
Попадаем в раздел Installation Type. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation, но нам не удастся его использовать, поскольку сервер не в домене. Выбираем Role-based or feature-based installation. Next.
Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.
Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Services. Next.
Попадаем в раздел Features. Здесь ничего дополнительно не выбираем. Next.
Попадаем в раздел Remote Desktop Services. Ненужное нам окошко. Next.
Попадаем в раздел Role Services. Первая роль, которую нам нужно установить, это Remote Desktop Licensing. Выделяем галкой.
Нам предлагают установить дополнительные фичи, которые требуются для данной роли. Соглашаемся, Add Features.
Remote Desktop Licensing выделено галкой, Next.
Попадаем в раздел Confirmation. Install.
Начинается установка роли.
Роль Remote Desktop Licensing успешно установлена. Примечательно, что перезагрузка не требуется.
Открываем Windows Administrative Tools.
Переходим в папку Remote Desktop Services.
Запускаем оснастку Remote Desktop Licensing Manager.
Выбираем наш сервер, правой кнопкой — активировать.
Открывается окно активации. Next.
Выбираем метод соединения Web Browser. Next.
Получаем код продукта который нам понадобится для активации (Product ID). Копируем.
В браузере открываем сайт https://activate.microsoft.com/
Выбираем «Activate a license server». Next.
Вводим Product ID полученный ранее, организацию и любую страну или регион. Next. Next.
Если все сделано правильно, то мы получим необходимый код сервера лицензирования. Копируем его. На вопрос «Do you wish to install client access licenses now on the license server with this product ID?» отвечаем «Yes» и пока возвращаемся к терминальному серверу, к текущему окну ещё вернёмся.
Вводим код в открытом мастере, жмём Next.
Устанавливаем галку «Start Install Licenses Wizard now». Next.
Открывается мастер установки лицензий. Next.
Нас просят ввести license key pack ID. Возвращаемся к браузеру.
Вставляем License Server ID, в качестве программы лицензирования, по идее он уже должен сюда переместиться из предыдущего окна. License Program выбираем Enterprise agreement. Указываем компанию и страну. Next.
Выбираем тип продукта: Windows Server 2019 Remote Desktop Services Per Device client access license. Указываем количество лицензий. Обязательно соглашение Enterprise agreement, или ищем в интернете который подойдет…
Настройка и лицензирование терминального сервера Windows Server 2016
Не стоит выбирать лицензии Per User, иначе потом вы получите такую ошибку:
Next.
Ну вот мы и получили нужные нам клиентские лицензии. Копируем.
Вводим ключ в мастер. Next.
Finish.
Возвращаемся к Remote Desktop Licensing Manager. Сервер активирован. Лицензии получены. Кстати, они начнут тратиться после окончания триального периода.
Роль Remote Desktop Session Host
Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.
Попадаем в раздел Before You Begin.
Это начальная страница, пропускаем. Next.
Попадаем в раздел Installation Type. Выбираем Role-based or feature-based installation. Next.
Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.
Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Session Host.
Нам предлагают установить дополнительные фичи, соглашаемся. Add Features.
Роль Remote Desktop Session Host выделена. Next.
Попадаем в раздел Features, ничего не выделяем. Next.
Попадаем в раздел Confirmation. Ставим галку Restart the destination server automatically if required. Отображается предупреждение, что сервер может быть перезагружен. Yes.
Install.
Начинается процесс установки роли.
Сервер перезагружается.
В процессе устанавливаются компоненты.
После перезагрузки автоматически продолжается установка роли. Триальный период работы терминального сервера — 119 дней.
Роль Remote Desktop Session Host успешно установлена. Close.
Открываем Windows Administrative Tools.
Переходим в папку Remote Desktop Services.
Запускаем оснастку Remote Desktop Licensing Diagnoser.
Видим ошибку.
The licensing mode for Remote Desktop Session Host server is not configured.
Выполняем gpedit.msc.
gpedit.msc
Откроется Local Group Policy Editor.
Раскрываем Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing.
Редактируем Use the specified Remote Desktop license servers.
Включаем — Enabled. В поле «License server to use» прописываем сервер, с которого получать лицензии, в моём случае «localhost». OK.
Редактируем Set the Remote Desktop licensing mode.
Включаем — Enabled. В поле «Specify the licensing mode for the RD Session Host server» устанавливаем значение Per Device. OK.
Снова запускаем оснастку Remote Desktop Licensing Diagnoser. Теперь всё зелёное, ошибок нет.
Практические испытания
Поскольку мы с вами системные администраторы 99 уровня, то нам нужно провести практические испытания терминального сервера.
На терминальном сервере создаём трёх локальных пользователей: user1, user2, user3.
Включаем их в группу Remote Desktop Users.
Коннектимся под этими пользователями к терминальному серверу по RDP.
Есть три активных сеанса.
Заключение
Мы с вами успешно создали терминальный сервер Windows Server 2019 в рабочей группе WORKGROUP без домена. 120 дней терминальный сервер будет работать в триальном режиме, затем начнёт использовать лицензии Per Device. Для подключения к терминальному серверу требуется создать локальную учётную запись и включить её в группу Remote Desktop Users.
В этой статье описано, как установить и настроить роль терминального сервера Remote Desktop Session Host на отдельностоящем Windows Server 2022/2019 в рабочей группе (без домена Active Directory) и без всех дополнительных ролей (Connection Broker, Remote Desktop Web Access, RDS Gateway).
Возможности отдельного RDS сервера в рабочей группе ограничены по сравнению с функционалом, доступном в домене AD. Вы не сможете масштабировать RDSH до полноценной RDS фермы Windows Server, нельзя создавать отдельные коллекции сессии или публиковать RemoteApp, отсутствует брокер подключений (RD Connection Broker), нельзя использовать User Profile Disks для хранения профилей пользователей, а при проведении операций обслуживания хоста RDP сервис будет полностью недоступен для пользователей.
Содержание:
- Установка роли Remote Desktop Services Host в Windows Server
- Установка Remote Desktop Licensing и RDS лицензий (CAL)
- Настройка роли Remote Desktop Session Host в рабочей группе
- Публикация приложения RemoteApp на RDS в рабочей группе (без домена)
- Настройка шлюза RD Gateway в рабочей группе
Установка роли Remote Desktop Services Host в Windows Server
Предполагаем, что вы уже установили сервер с Windows Server (2022, 2019 или 2016) и задали первоначальные настройки (задали сетевые параметры и статический IP адрес, имя сервера (hostname), время/дату/часовой пояс, установили последние обновления и т.д.). Теперь можно установить службу RDS через консоль Server Manager или из PowerShell:
При установке службы RDS через Server Manager нужно выбрать Role-based or feature-based installation -> Server roles -> Remote Desktop Services -> в компонентах RDS выберите службы Remote Desktop Session Host и Remote Desktop Licensing (согласитесь с установкой компонентов RSAT для управления ролями).
Если вы выбрали в Server Manager тип установки Remote Desktop Services installation, то в режиме Standard deployment и Quick Start установщик дополнительно установит роли RD Connection Broker и RD Web Access. В нашем случае все эти роли излишни, т.к. мы ставим стендалон RDS сервер.
Также вы можете установить указанные роли Windows Server с помощью PowerShell:
Install-WindowsFeature -Name RDS-Licensing, RDS-RD-Server –IncludeManagementTools
Проверьте, какие RDS роли установлены на сервере:
Get-WindowsFeature -Name RDS* | Where installed
Перезагрузите Windows командой:
Restart-Computer
Установка Remote Desktop Licensing и RDS лицензий (CAL)
Теперь нужно настроить роль Remote Desktop Licensing, которая обеспечивает лицензирование подключений пользователей к вашему RDS хосту. Допустимо установить и активировать роль Remote Desktop Licensing на этом же сервере (если он у вас один), либо можете разместить роль RDLicensing на отдельном сервере. Один сервер RDS Licensing можете выдавать лицензии неограниченному количеству RDSH хостов.
Если вы решили использовать локальный сервер RDLicensing, активируйте сервер лицензий RDS и установите клиентские лицензии (RDS CAL) согласно гайду по ссылке.
В рабочей группе можно использовать только RDS CAL типа Per Device. Если ваш сервер лицензирования выдает только Per User лицензии, то RDSH сервер будет каждые 60 минут принудительно завершать сеанс пользователей:
Remote Desktop License Issue There is a problem with your Remote Desktop license, and your session will be disconnected in 60 minutes.
Настройка роли Remote Desktop Session Host в рабочей группе
Откройте консоль управления Remote Desktop Licensing Diagnoser (
lsdiag.msc
). В данном случае сервер RDSH еще не настроен на получение RDS CAL лицензий с сервера лицензирования. Об этом свидетельствуют надписи:
- The licensing mode for the Remote Desktop Session Host server is not configured
- Number of licenses available for clients:
0
Если вы не нацелите ваш RDSH сервер на сервер лицензирования, ваш сервер будет находится в триальном grace режиме. Пользователи могут использовать его в течении 120 дней (при каждом подключении в трее будет появляться сообщение “
Служба удаленных рабочих столов перестанет работать через xxx дней
”). После окончания grace периода ваши пользователи не смогут подключится к RDS с ошибкой:
Remote session was disconnected because there are no Remote Desktop client access licenses available for this computer.
Чтобы задать адрес сервера лицензирования RDS и тип лицензии, воспользуйтесь консолью редактора локальной групповой политики Windows (
gpedit.msc
).
- Перейдите в раздел GPO Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing;
- Установите параметр Set the Remote Desktop licensing mode = Per Device;
- В Use the specified Remote Desktop license servers укажите адрес сервера, на котором установлен сервер RDLicensing. Если сервер лицензий установлен на этом же хосте, укажите
localhost
или
127.0.0.1
- Обновите локальные политики, и запустите RDesktop Licensing Diagnoser. Убедитесь, что он видит ваши RDS CAL.
Дополнительно в локальных GPO вы можете настроить лимиты (таймауты) на длительность RDP сессий и правила отключения пользователей при неактивности.
Если вам нужно создать отдельные групповые политики с настройками для локальных пользователей и администраторов, воспользуйтесь функционалом множественных GPO (MLGPO).
Теперь создайте для локальные учетные записи пользователей, который они будут использовать для входа на RDS. Можно создать пользователей с помощью оснастки
lusrmgr.msc
или через PowerShell:
$UserPassword = ConvertTo-SecureString "Pa$$dr0w!!" -AsPlainText -Force
New-LocalUser "AIvanov" -Password $UserPassword -FullName "Andrey Ivanov"
Чтобы разрешить пользователю подключаться к серверу через службы Remote Desktop Services, нужно добавить его учетную запись в локальную группу Remote Desktop Users. Добавьте пользователей вручную через консоль управления группами или через PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member AIvanov
Для данной группы пользователей разрешен вход в локальной политикие Allow logon through Remote Desktop Services (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment). Эта же политика позволяет обеспечить RDP вход пользователям даже на контроллер домена.
Теперь пользователи могут попробовать со своих компьютеров подключится к вашему RDS хосту с помощью клиента mstsc.exe (или любого другого RDS клиента). Проверьте, что к серверу одновременно может подключится более двух активных RDP сессий.
При подключении к RDSH серверу в рабочей группы нужно указывать имя в формате
srv1\username
(где srv1 – имя компьютера/hostname вашего RDS). Если указать имя пользователя с префиксам
.\
или без префикса, подразумевается что подключение выполняется под вашим локальным пользователем.
При первом входе устройству пользователя выдается временная лицензия (особенности RDS Per Device лицензирования). При втором входе выдается постоянная лицензия, которая появится в консоли Remote Desktop Licensing Manager. Лицензия выдается на срок от 52 до 89 дней (случайное число).
Информация об успешной выдаче лицензии есть в следующем событие Event Viewer (Applications and Services Logs -> Microsoft -> Windows -> TerminalServices—Licensing -> Operational).
Event ID: 82 The "Temporary" Windows Server 2022 : RDS Per Device CAL belonging to computer "ComputerName" has been upgraded to "Permanent" Windows Server 2022 : RDS Per Device CAL.
Если вам нужно подключиться в RDP сессию пользователя, вы можете воспользоваться режимом теневого подключения RDS (он работает и на RDSH в рабочей группе).
Публикация приложения RemoteApp на RDS в рабочей группе (без домена)
На RDS в рабочей группе недоступна консоль управления сеансами, и поэтому отсутствуют инструменты для публикации приложений RemoteApp. Но есть обходное решение позволяющее через реестр опубликовать любое приложение в RemoteApp без домена Active Directory.
Пример REG файла для публикации на RDS сервере AdobeReader в качестве RemoteApp:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\MyAdobeReaderApp] "CommandLineSetting"=dword:00000000 "RequiredCommandLine"="" "Name"="Adobe Reader" "Path"="C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "ShortPath"="C:\\PROGRA~1\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "IconPath"="C:\\PROGRA~1\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "IconIndex"=dword:00000000 "ShowInTSWA"=dword:00000001 "SecurityDescriptor"=""
Замените имена и пути в REG файле на ваши и импортируйте его в реестр RDSH.
Теперь вручную отредактируйте файл *.RDP ярлыка, чтобы при его запуске автоматически запускалось опубликованное приложение. Добавьте в RDP файл следующие строки:
remoteapplicationmode:i:1 alternate shell:s:||MyAdobeReaderApp remoteapplicationname:s:MyAdobeReaderApp remoteapplicationprogram:s:||MyAdobeReaderApp
Попробуйте запустить RemoteApp приложение на RDS с поммощью вашего RDP файла. Опубликованное на RDSH приложение должно успешно запуститься на вашем рабочем столе.
Решение проблемы с медленной работой RemoteApp в Windows Server 2019/2016 описано здесь.
Настройка шлюза RD Gateway в рабочей группе
Если вам нужно организовать безопасный доступ к вашему RDS северу через интернет, рекомендуется разместить его за VPN или опубликовать через шлюз RD Gateway.
Remote Desktop Gateway позволит открыть безопасный доступ из Интернета к RDS серверу интернета по защищенному SSL/TLS подключение по порту TCP:443 (вместо того, чтобы открывать стандартный RDP порт 3389, на котором будут постоянно фиксироваться попытки перебора паролей по RDP).
Вопреки распространённому заблуждению, RD Gateway можно развернуть без домена Active Directory. Подробная инструкция по настройке шлюза RD Gateway без домена доступна в статье Настройка шлюза Remote Desktop Gateway на Windows Server.
This article explains how to install and configure the Remote Desktop Session Host terminal server role on a standalone Windows Server 2022/2019 in a workgroup (without an Active Directory domain) and without any other additional roles (Connection Broker, Remote Desktop Web Access, RDS Gateway).
Compared to the functionality available in an AD domain, the capabilities of a single RDS server deployment in a workgroup are limited. It cannot be scaled to a full-featured RDS farm, you cannot create separate session collections or publish RemoteApps, there is no Connection Broker, you cannot use User Profile Disks, the RDS service won’t be available to users during maintenance operations when the host is in the drain mode.
Contents:
- How to Install the RD Session Host Role on Windows Server
- Install the RD Licensing Role and RDS Licenses (CALs)
- Configure the Remote Desktop Session Host in a Workgroup
- Publish RemoteApp on RDS Without Domain
- Configure the RD Gateway without a Domain (in a Workgroup)
How to Install the RD Session Host Role on Windows Server
It is assumed that you already have a host with Windows Server (2022, 2019, or 2016) in place and have configured the basic settings (set network parameters and static IP address, server name (hostname), time/date and time zone, install the latest updates, etc.). You can now install the RDS role from the Server Manager console or PowerShell
To install the RDS using Server Manager, select Remote Desktop Session Host and Remote Desktop Licensing in Role-based or Feature-based installation -> Server roles -> Remote Desktop Services in RDS components (agree to install RSAT features to manage the roles).
Note that if you have selected the Remote Desktop Services installation in the Server Manager, the wizard will automatically install the RD Connection Broker and Web Access roles in the Standard deployment or Quick Start modes. In our case, there is no need for all of these roles, as we are installing a standalone RDS host.
You can also install Windows Server roles using PowerShell:
Install-WindowsFeature -Name RDS-Licensing, RDS-RD-Server –IncludeManagementTools
Check which RDS roles are installed on your server:
Get-WindowsFeature -Name RDS* | Where installed
Restart Windows with the command:
Restart-Computer
Install the RD Licensing Role and RDS Licenses (CALs)
The next step is to configure the Remote Desktop Licensing role, which provides licensing for users’ RDP connections. You can install and activate Remote Desktop Licensing and RDS CALs on the same host (if you have only one host in your network) or can place the RD Licensing role on a different server. A server with the RDS Licensing role can issue licenses to any number of RDS Hosts.
In a workgroup, you should use only Per-Device RDS CALs. If your licensing server only issues per-user licenses, the RDSH server will force users to log out every 60 minutes:
Remote Desktop License Issue There is a problem with your Remote Desktop license, and your session will be disconnected in 60 minutes.
Configure the Remote Desktop Session Host in a Workgroup
Open the Remote Desktop Licensing Diagnoser console (lsdiag.msc). Note that your server is not yet configured to receive RDS CALs from the licensing server.
- The licensing mode for the Remote Desktop Session Host server is not configured
- Number of licenses available for clients: 0
If you do not point your RDSH to the licensing server, your server will be in trial grace mode. Users can only use it for 120 days ( a message will appear in the tray each time you connect: The Remote Desktop service will stop working in xxx days). Once the grace period has expired, your users will no longer be able to connect to the RDS with the error message:
Remote session was disconnected because there are no Remote Desktop client access licenses available for this computer.
Use the local Group Policy Editor console (gpedit.msc) to set the RDS licensing server address and license type.
- Expand to Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing;
- Enable the option Set the Remote Desktop licensing mode and change to Per Device;
- In Use the specified Remote Desktop license servers option, specify the IP address of the host on which the RD Licensing server is installed. If the RD licensing server is installed locally, enter
localhostor127.0.0.1;
- Update local Group Policy settings and run the Remote Desktop Licensing Diagnoser. Make sure that it sees your RDS CALs.
In addition, you can use local GPO settings to set limits (timeouts) on the duration of RDP sessions and rules for disconnecting users when they are inactive.
Use the Multiple GPO (MLGPO)feature if you need to set different Group Policy settings for local non-admin users and administrator groups.
Then create local user accounts on your RDS host. You can create users in lusrmgr.msc or with PowerShell:
$UserPassword = ConvertTo-SecureString "PaSS123!" -AsPlainText -Force
New-LocalUser a.brown -Password $UserPassword -FullName "Andi Brown"
To allow a user to connect through Remote Desktop Services, add the user account to the local Remote Desktop Users group. Add users manually using the computer management console or with PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member a.brown
This user group is allowed to log on remotely through the Allow logon through Remote Desktop Services GPO option (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment). This policy can also be used to allow non-admin users to access the domain controllers via RDP.
Now users can try to connect to your RDS host from their computers using the mstsc.exe client (or any other RDP client). Ensure that more than two active users can connect to the server simultaneously.
When connecting to a workgroup RDSH server, specify a name in the format rdssrv1\username where rdssrv1 is the computer name (hostname) of your RDS). If you specify a user name with or without the .\ prefix, it is assumed that you are connecting as your local user.
At the first login, a temporary license is issued for a user device (an RDS Per-Device licensing feature). The second time you log in, a permanent license is issued, which appears in the Remote Desktop Licensing Manager. Licenses are issued for 52-89 days (random number).
The following Event Viewer event provides information on the successful issuance of an RDS CAL (Applications and Services Logs -> Microsoft -> Windows -> TerminalServices—Licensing -> Operational).
Event ID: 82 The "Temporary" Windows Server 2022 : RDS Per Device CAL belonging to computer "ComputerName" has been upgraded to "Permanent" Windows Server 2022 : RDS Per Device CAL.
If you need to connect to a user’s RDP session, you can use the RDS shadow connection mode (it also works on an RDSH in a workgroup).
Publish RemoteApp on RDS Without Domain
On an RDS host in a workgroup, the session management console is not available, so there are no tools to publish RemoteApp. There is a workaround that allows you to publish any application as an RDS RemoteApp without an Active Directory domain.
Example REG file for publishing AdobeReader as a RemoteApp on the RDS session host:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\MyAdobeReaderApp] "CommandLineSetting"=dword:00000000 "RequiredCommandLine"="" "Name"="Adobe Reader" "Path"="C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "ShortPath"="C:\\PROGRA~1\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "IconPath"="C:\\PROGRA~1\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe" "IconIndex"=dword:00000000 "ShowInTSWA"=dword:00000001 "SecurityDescriptor"=""
Replace the app name and paths in the REG file with yours and import it into the RDSH registry.
To automatically launch the published RemtoteApp, manually edit the *.RDP file. Add the following lines to the RDP file:
remoteapplicationmode:i:1 alternate shell:s:||MyAdobeReaderApp remoteapplicationname:s:MyAdobeReaderApp remoteapplicationprogram:s:||MyAdobeReaderApp
Try to run a RemoteApp application on the RDS by using your RDP file. The application published on RDSH should launch successfully on your desktop.
Configure the RD Gateway without a Domain (in a Workgroup)
If you need to provide secure access to your RDS host over the Internet, it is recommended that you place it behind a VPN or publish it through the RD Gateway.
The Remote Desktop Gateway allows you to securely access an RDS from the Internet using a secure SSL/TLS connection on port TCP:443 (rather than opening default RDP port 3389, which constantly logs attempts to brute-force passwords over RDP)
Contrary to popular belief, RD Gateway can be deployed in a workgroup environment (without an Active Directory domain). Refer to this guide for detailed instructions on how to set up an RD Gateway without a domain.
What if you have a need for running Windows Server 2019 as a remote desktop services server but you are not running a domain? If your Windows Server 2019 server is in a workgroup in an edge environment possibly and you need to run remote desktop services, is this possible? Also, what about setting up Windows Server 2019 remote desktop gateway with a workgroup? Is that possible? Can you install both on the same server in a workgroup? In this post, we will take a look at the use case of running Windows Server 2019 remote desktop services without domain services running and answer these other questions regarding the workgroup configuration with RDS and Windows Server 2019.
First of all, before you know how to do something, it is good to know why you would want to do it. Especially in production, we don’t simply want to do something just because we can without a good reason.
We all know that Windows Server in an Active Directory domain has access to many more powerful ways of doing things, centralized management, and security model.
However, there are use cases when you may want to configure Windows Server 2016 or Windows Server 2019 in a workgroup and utilize remote desktop services.
One of the strongest use cases I can think of is in an edge environment where you may not have the infrastructure setup to run a full Active Directory environment, yet still need to provide more than two connections to an application server, perhaps running a legacy application.
Another use case may be for a simple jumpbox that is used to monitor hardware or perform other low-level duties that do not require the server to be joined to an Active Directory domain.
While AD is more powerful, it is also more to maintain and takes more resources to spin up. It also requires the technical expertise to configure, manage, and troubleshoot.
Workgroup configurations by contrast, are fairly simple. Everything is contained on the same box, including the user accounts you authenticate with. So, as mentioned for certain environments, I can see this as a potential use case for this type of configuration.
Windows Remote Desktop Services and Licensing in a Workgroup
First, let’s setup the basics to connect to a single Windows Server 2019 server that is running Remote Desktop Services (RDS) for user connectivity. Launch Server Manager and install the Remote Desktop Services role.
Select the Role Services that will be installed with the role installation. For a simple Windows Server 2019 remote desktop services without domain installation, you simply need to add the Remote Desktop Licensing and Remote Desktop Session Host role services.
After installation, you will need to reboot your server to finish the role installation.
After reboot, you can activate your Remote Desktop Licensing. Launch the RD Licensing Manager console and right-click on your server and select Activate Server.
After you go through the wizard to install your licensing, you should see your server activated. Note, below, I haven’t added any additional licensing for the demo.
Now, create your local user(s) that will be used to connect to the Windows Server 2019 Workgroup remote desktop services server.
Add this user or multiple users you have created into the Remote Desktop Users group which allows the local user to remote desktop into the Windows Server 2019 remote desktop services server.
At this point, you will have a functional remote desktop session host that multiple remote users will be able to remote into to run applications or use as a jump host.
Remote Desktop Services Gateway without Domain
We all know that placing an RDP server in the DMZ or forward facing to the Internet is a dangerous thing to do. Microsoft’s RDP implementation has been historically riddled with security vulnerabilities. If not properly patched it can easily lead to data breach or ransomware infection in your environment.
Using a Remote Desktop Gateway server strengthens your security since it allows a secure tunnel over SSL 443 to your RDP endpoint. This allows one of your remote workers coming across the Internet to securely tunnel to their RDP server over port 443 without exposing RDP to the outside world.
Can this be setup on a workgroup server? Yes. Also, you can do this on the same workgroup server, pretty cool! By installing on the same server as is the target of the RDP connections, you can simply open up port 443 to the outside and use the same address for the gateway as you do for the target of the RDP connection.
Simply go back on the same server and Add Role services. Add the Remote Desktop Gateway role service to your installation. It does not require a reboot.
After installing the role service, launch the RD Gateway Manager console and create both the Connection Authorization Policy and the Resource Authorization Policy.
You can easily use the wizard to create both at the same time. Basically, in a workgroup configuration, you can simply add the BUILTINRemote Desktop Users group to the RD CAP and the RD RAP.
Adding the group in the RAP as well.
Now, configure your self-signed certificate for your Windows Server 2019 remote desktop services without domain box. Right-click on the server. Under SSL Certificate, use the Create a self-signed certificate button.
If this is just going to be a standalone server that only a couple or more users will be connecting to, you can get away with the self-signed certificate. However, keep in mind, you will have to import the certificate on the client workstations that will be connecting to the RD Gateway Server.
Thoughts
There are several use cases that may call for using a Windows Server 2019 remote desktop services no domain configuration where the server is in a workgroup and not domain joined.
This can help to simply a configuration to some degree in a remote location or edge environment that may lack a connection back to a central Active Directory database.
Using the workgroup configuration you can setup a remote desktop services box and a remote desktop gateway server all on the same server. By doing this, you will be able to expose only SSL 443 to the outside world for end users to make connections.
В данной инструкции у нас уже установлена операционная система Windows Server 2019 на виртуальной машине.
Минимальные требования:
- 64-разрядный процессор с тактовой частотой 1,4 ГГц;
- ОЗУ 512 МБ (2 ГБ для варианта установки “Сервер с рабочим столом”);
- диск 32 ГБ;
- доступ к интернету.
Бесплатный сервер 1С для подписчиков нашего telegram-канала !
Для того чтобы подключить сертификат с помощью Let’s Encrypt требуется прямые пробросы портов TCP 443, 80 до машины, а также доменное имя, на которое будет вешаться сертификат.
Активация Windows Server 2019 проходит тоже на этом этапе.
Установка ролей на Windows Server 2019
После подготовки Windows Server 2019, мы приступаем к установке ролей для настройки терминального сервера и шлюза удаленных рабочих столов.
Заходим в Диспетчер серверов – Управление – Добавить роли и компоненты.
Открывается “Мастер добавления ролей и компонентов”:
Рисунок 1 – Мастер добавления ролей и компонентов
Добавление ролей на сервере:
- Тип установки – Установка ролей или компонентов.
- Выбор сервера – Выбираем наш текущий сервер.
- Роли сервера – Службы удаленных рабочих столов.
- Службы ролей – Лицензирование удаленных рабочих столов, шлюз удаленных.
Подтверждаем установку компонентов и проводим установку. После установки всех нужных нам ролей – перезагружаем сервер.
У нас вы можете взять готовый терминальный сервер 1С в аренду.
Настройка сервера лицензирования
Заходим в Диспетчер серверов – Средства – Remote Desktop Services – Диспетчер лицензирования удаленных рабочих столов.
В диспетчере нажимаем ПКМ на наш сервер и выбираем “Активировать сервер”.
Попадаем в “Мастер активации сервера”, вводим свои данные и нажимаем “Далее”.
Рисунок 2 – Мастер активации сервера
В следующем пункте вводим “Сведения об организации” и нажимаем “Далее”.
Завершение работы мастера активации сервера выполняется с поставленной галочкой “Запустить мастер установки лицензий” чтобы попасть в оснастку установки лицензий.
Рисунок 3 – Завершение работы мастера активации сервера
В мастере установки лицензий мы видим параметры сервера лицензирования и нажимаем “Далее”.
В следующем окне мы выбираем лицензию в зависимости от приобретенной вами лицензии.
Имеется несколько типов лицензии:
- Пакет лицензий (в розницу).
- Соглашение “Open License”.
- Соглашение “Select License”.
- Соглашение “Enterprise Agreement”.
- Соглашение “Campus Agreement”.
- Соглашение “School Agreement”.
- Лицензионное соглашение постановщика услуг.
- Другое соглашение.
- Лицензия Select Plus.
В нашем случае мы выбираем “Соглашение “Enterprise Agreement”” и нажимаем “Далее”.
- Версию продукта ставим “Windows Server 2019”.
- Тип лицензии “Клиентская лицензия служб удаленных рабочих столов “на устройство”.
- Количество в зависимости от приобретенной вами. В нашем случае мы активируем на 10 устройств.
Завершаем работу мастера установки лицензий.
Для завершение установки лицензий осталось выполнить пункт по добавление групповых политик, для этого нажимаем ПКМ по меню “Пуск” и выбираем “Выполнить”.
В окне “Выполнить” вводим gpedit.msc и нажимаем “ОК”.
Попадаем в “Редактор локальной групповой политики”
В данной настройке требуется править две записи. Для того чтобы указать сервер лицензирования мы переходим в пункт:
Конфигурация компьютера – Административные шаблоны – Компоненты Windows – Служба удаленных рабочих столов – Узел сеансов удаленных рабочих столов – Лицензирование – Использовать указанные серверы лицензирования удаленных рабочих столов.
Включаем данную политику и вводим требуемый сервер лицензирования. В нашем случае мы будем ссылаться на свой локальный сервер “localhost” и применяем настройку.
Рисунок 4 – Использование серверов лицензирования
Для второго пункта мы переходи по следующему пути:
Конфигурация компьютера – Административные шаблоны – Компоненты Windows – Служба удаленных рабочих столов – Узел сеансов удаленных рабочих столов – Лицензирование – Задать режим лицензирования удаленных рабочих столов.
Включаем политику и указываем режим лицензирования, в нашем случае мы активируем “на устройство” и применяем настройку.
Рисунок 5 – Задаем режим лицензирования
Настройка по установки лицензий прошла успешно, далее мы настраиваем шлюз удаленных рабочих столов.
Настройка шлюза удаленных рабочих столов
Шлюз удаленных рабочих столов является сервисом посредником между клиентами из внешней сети и сеансов внутренней сети, обеспечивает безопасный обмен данными между ними.
Заходим в Диспетчер серверов – Средства – Remote Desktop Services – Диспетчер шлюза удаленных рабочих столов.
Нажимаем ПКМ по папке “Политики” и выбираем “Создание новых политик авторизации”.
Мы попадаем в “Мастер создания новых политик авторизации”.
Рисунок 6 – Создание политик авторизации для шлюза удаленных рабочих столов
По пунктам выбираем следующее:
- Политики авторизации – Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов.
- Политика авторизации подключений – пишем наименование политики (в нашем случае Users).
- Требования – выбираем членство в группе для пользователей или компьютеров, которые смогут подключаться к серверу (в нашем случае, мы добавили группу пользователей “Пользователи удаленного рабочего стола” и “Администраторы”).
- Перенаправление устройств – выбираем, что требуется перенаправить (мы выбрали “Включить перенаправление устройств для всех клиентских устройств”).
- Время ожидания сеанса – по умолчанию.
- Сводка по политике авторизации подключений к RD – параметры которые будут созданы в данной политике.
- Политика авторизации ресурсов – пишем наименование политики (в нашем случае TS).
- Группы пользователей – выбираем членство в группе для пользователей или компьютеров, которые смогут подключаться к серверу (в нашем случае, мы добавили группу пользователей “Пользователи удаленного рабочего стола” и “Администраторы”).
- Сетевой ресурс – можем настроить группу терминальных серверов, куда можно подключиться, выберем “Разрешить подключение пользователей к любому ресурсу (компьютеру)”.
- Разрешенные порты – если настроен нестандартный порт, то в этом пункте можно это указать, выбираем “Разрешить подключение только к порту 3389”.
- Сводка по политике авторизации ресурсов RD – параметры которые будут созданы в данной политике.
На данном этапе мы завершили настройку шлюза удаленных рабочих столов, за исключением установки сертификата.
Рисунок 7 – Оснастка диспетчера шлюза удаленных рабочих столов без сертификата
Для того, чтобы установить сертификат на шлюз удаленных рабочих столов, мы воспользуемся утилитой win-acme.
Установка сертификата на шлюз удаленных рабочих столов через Let’s Encrypt
Скачиваем программу по ссылке:
https://github.com/win-acme/win-acme/releases/download/v2.1.14.1/win-acme.v2.1.14.996.x64.trimmed.zip
Копируем в папку C:Scriptswin-acme
Создаем 3 bat-файла:
- Файл “C:Scriptswin-acmeRegister.bat”
Файл “C:Scriptswin-acmeRegister.bat”
@echo off
rem powershell.exe
:: Ввод данных:
set /p commonname_Data="Enter Domain name(exampe : v0162.esit.info) : "
powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Get-WebBinding | Remove-WebBinding"
powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "New-WebBinding -Name 'Default Web Site' -Port 443 -Protocol https -SslFlags 0 -IPAddress "*" -HostHeader "*" "
powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "New-WebBinding -Name 'Default Web Site' -Port 80 -Protocol http -IPAddress "*" -HostHeader "*" "
powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Set-WebBinding -Name 'Default Web Site' -BindingInformation "*:443:*" -PropertyName HostHeader -Value '%commonname_Data%'"
powershell -ExecutionPolicy Bypass -NoLogo -NoProfile -Command "Set-WebBinding -Name 'Default Web Site' -BindingInformation "*:80:*" -PropertyName HostHeader -Value '%commonname_Data%'"
@echo on
"C:Scriptswin-acmewacs.exe" --installation script --target iissite --siteid 1 --commonname %commonname_Data% --emailaddress admin@admin --accepttos --script "./scripts/PSScript.bat" --scriptparameters "./scripts/ImportRDGateway.ps1 {5}"
- Файл “C:Scriptswin-acmeScriptsPSScript.bat”
Листинг:
powershell.exe -ExecutionPolicy RemoteSigned -File %*
- После этого запускаем “C:Scriptswin-acmeRegister.bat”.
- Вводим домен на котором находится наш шлюз удаленных рабочих столов.
- Если всё получилось, то в оснастке шлюза удаленных рабочих столов должен появится созданный сертификат, а в консоли – готовый результат.
- Элемент маркированного списка
Рисунок 8 – Сертификат успешно установлен
Подключение пользователей
Следующем этапом мы создаем пользователей для подключение к удаленному рабочему столу через шлюз удаленных рабочих столов.
- В окне “Выполнить” вводим команду “control userpasswords2”.
- Нажимаем “Дополнительно”.
- Выбираем папку “Пользователи” переходим в “Дополнительные действия” и нажимаем “Новый пользователь”.
- Вводим требуемые поля.
Рисунок 9 – Добавление нового пользователя
Создаем нового пользователя и добавляем его в группу “Пользователи удаленного рабочего стола”, для этого заходим в Панель управления – Система – Настройка удаленного рабочего стола – Выбрать пользователей – Добавить.
Добавляем созданных пользователей, после чего подключаемся к серверу.
Подключение к серверу терминалов
На машине, с которой будем подключаться к серверу, ищем утилиту “Подключение к удаленному рабочему столу” на Windows 10 она находится по следующему расположению: Пуск – Стандартные – Windows – Подключение к удаленному рабочему столу.
В открытом окне вводим имя нашего сервера или локальный ip-адрес. В нашему случае имя сервера “EFSOL-TS”
Пользователя указываем, которого создали (EFSOL-TSefsol_it).
Далее, чтобы указать адрес шлюза удаленных рабочих столов, переходим во вкладку “Дополнительно” нажимаем “Параметры” вводим в окне Имя сервера наше доменное – “gorbach.esit.info”.
Рисунок 10 – Подключение к шлюзу удаленных рабочих столов
Нажимаем “ОК” и “Подключить”.
При подключении к удаленному рабочему столу – может появится сообщение о сертификате, мы на него соглашаемся.
Установка терминального сервера произведена и шлюз удаленных рабочих столов успешно настроен.
Также мы готовы предложить готовый терминальный сервер в аренду. Конфигурации подобраны для комфортной работы в 1С, офисных приложениях и другом ПО.