Настройка терминального сервера windows 2012 r2, а также его установка

Проблемы лицензирования

В условиях использования свободнораспространяемого ПО (такого, как X Window System) проблема лицензирования не возникает. Для ПО, предусматривающего в лицензионном соглашении ограничение на количество копий/пользователей, возникают затруднения.

В условиях терминального сервера могут использоваться следующие модели лицензирования:

Per seat (per device — на рабочее место) — для каждого устройства (тонкого клиента или рабочей станции) требуется отдельная лицензия, вне зависимости от количества пользователей

Подобная схема используется при лицензировании Terminal Services в составе Windows Server.
Per user (на пользователя) — для каждого пользователя (вне зависимости от числа одновременно работающих пользователей) требуется отдельная лицензия.
Per connection (конкурентная лицензия) — для каждого соединения требуется отдельная лицензия, при этом количество пользователей/рабочих мест не играет роли — важно количество одновременно обслуживаемых пользователей. Такую систему лицензирования использует Citrix Metaframe. В этом случае существует пул лицензий, каждое новое соединение забирает одну лицензию из пула

Лицензия возвращается в пул при окончании соединения.

В этом случае существует пул лицензий, каждое новое соединение забирает одну лицензию из пула. Лицензия возвращается в пул при окончании соединения.

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

Виды терминальных серверов

Microsoft Windows Terminal Server (поставляется в Microsoft Windows Server)
Citrix Metaframe
X Window System
NX NoMachine
FreeNX
RX@Etersoft

См. также

Сервер приложений
Бездисковая станция
Тонкий клиент
Терминальный доступ
Терминальный режим работы
PXE
BOOTP
TFTP
Remote Installation Services (RIS)
RDP
SSH
Терминальная ферма

4)Теперь нам нужно активировать наш сервер лицензий и установить клиентские лицензии через графический интерфейс диспетчера лицензирования на сервере лицензий.

Я активировал сервер лицензий и установил клиентские лицензии PerUser.
Типы клиентских терминальных лицензий (RDS CAL)
Каждый пользователь или устройство, которое подключается к серверам Remote Desktop Session должно иметь клиентскую лицензию (CAL — client access license). Есть два типа терминальных CAL.На устройство (Per Device CAL) – это постоянный тип лицензии, назначающаяся компьютеру или устройству, которое подключается к RDS серверу более одного раза (при первом подключении устройства ему выдается временная лицензия). Данные лицензии не являются конкурентными, т.е. если у вас 10 лицензий Per Device, то к вашему RDS серверу смогут подключится всего 10 хостов.На пользователя (Per User CAL) – такой тип лицензии позволяет одному пользователю подключаться к серверу RDS с любого количества компьютеров/устройств. Данный тип лицензий привязывается к пользователю Active Directory, но выдается не навсегда, а на определенный период времени (90 дней по-умолчанию).
Давайте настроим наше развертывание для лицензирования. Для этого используется командлет ниже:

Set-RDLicenseConfiguration -LicenseServer MSK01-RDS.5house.win -Mode PerUser -ConnectionBroker MSK01-RDS.5house.win

Remote Desktop Services (RDS) Components Architecture

The RDS role in Windows Server includes the following components:

Remote Desktop Session Host (RDSH) – RDS session hosts. These are the main workhorses of an RDS farm on which user apps run;
Remote Desktop Connection Broker (RDCB) – an RDS connection broker. It is used to manage an RDS farm, distribute the workload, reconnect users to their sessions, store RDS collection settings, and published RemoteApps;
Remote Desktop Gateway (RDGW) – provides secure access to the RDS farm from the Internet;
RD Web Access (RDWA) – a web interface to access remote desktops and RemoteApps;
Remote Desktop Licensing (RD Licensing) — a licensing service for managing RDS licenses (CALs).

In our small RDS deployment, there are only three Windows Server hosts with the following roles:

— RDSH
– RDSH
– RDSH, RDWA, RDCB, and RD Licensing

In the simplest case, you can deploy a standalone server with the Remote Desktop Session Host (RDSH) role without the Connection Broker and RDS Web Access.

Prerequisites to create an RDS farm:

Install the same version of Windows Server on all RDS hosts, configure them, and join the AD domain;
Open the ADUC console (dsa.msc) and move all hosts with the RDSH role to the same Active Directory OU (Organizational Unit). Thus, it will be easier to apply RDS settings using GPO;
Create an Active Directory domain security group for RDSH servers (for example, mun-rdsh) and add all hosts to it;
If you want to use User Profile Disks (UPD) to store RDS user profiles (or roaming profiles), you must create a shared network folder on a file server (it is recommended to place the shared folder on a File Server Failover Cluster running Windows Serveer). Grant Full Control permissions on the shared folder for the mun-rdsh group.

Собираем консоль управления RDS фермой

Для управления настройками Remote Desktop Services вам потребуется клиентская операционная система Windows 8.1 или Windows 10, либо это могут быть Windows Server 2012 R2 и выше. Там нам потребуется оснастка «Диспетчер серверов».

Если вы знаете всех участников RDS фермы, то это хорошо, вы немного себе выиграете времени, если нет, то придется слегка пописать команды и помучить DNS-сервер.

Откройте командную строку или запустите PowerShell оболочку. Предположим у вас виртуальное имя для подключения к удаленному рабочему столу TERM. Тут у вас два варианта:

Воспользоваться утилитой nslookup
Воспользоваться утилитой Resolve-DnsName

И та и другая выдали вам ip-адреса, в которое разрешается ваше виртуальное имя RDS фермы. В моем примере их два. Эти адреса принадлежат посредникам по подключению (Connection Broker), делаем так же запрос:

Стрелками я выделил полученные DNS имена, самое главное мы получили.

Теперь открывает оснастку «Диспетчер серверов» от имени той учетной записи у которой есть права на администрирование RDS фермы. В открывшейся оснастке выберите пункт «Добавить другие серверы для управления»

У вас откроется окно «Добавление серверов», перейдите на вкладку DNS и в поисковой строке укажите нужное имя брокера и нажмите кнопку с изображением лупы. У вас будет осуществлен поиск по базе Active Directory, если такой сервер есть, то он будет отображен в списке. Переносим его в поле выбрано.

Точно так же поступаем и с остальными посредниками подключений к Remote Desktop Services ферме.

У вас начнется процесс добавление в вашу оснастку дополнительных серверов

Когда закончится добавление, то вы увидите, что у вас появились серверные роли, в нашем случае «Службы удаленных рабочих столов» и обратите внимание на иконку «Все серверы», тут стало их уже два

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

В итоге у меня добавились все мои хосты подключения и сервера лицензирования. Как видите стало 20 серверов.

Переходим в «Службы удаленных рабочих столов», в этот раз у вас уже откроется полноценное управление коллекциями RDS. Вы увидите схему работы, вам будет представлен список всех ваших серверов и кто за какую роль отвечает. Переходим в саму коллекцию.

Попав в коллекцию удаленных рабочих столов, у вас будет несколько областей:

Свойства — тут вы зададите права доступа, лимиты и многое другое
Подключения — тут будут отображены все ваши сеансы пользователей, в моем примере, это всего 338 человек, так как уже не рабочий день, а вечер пятницы, в пиковое время, эта цифра в районе 950 подключений.
Удаленные приложения RemoteApp
Серверы узлов — тут вы сможете запрещать или разрешать новые подключения

Так же для удобства администрирования серверов, я вам советую создавать отдельные группы по нужным вам признакам и управлять ими, но об этом уже в другой раз. Либо же вы можете создать группу серверов в Remote Desktop Connection Manager.

Позволяет пользователям переподключаться к своим текущим сессиям в ферме серверов RD Session Host (терминальные сервера Windows). Тем самым предотвращается создание новых пользовательских подключений на других серверах фермы при наличии подключения в состоянии «disconnected».
Позволяет равномерно распределить нагрузку между серверами терминальной фермы RD.

RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008 R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.

В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.

Варианты загрузки клиента WTware

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

Жесткий диск
CD-Rom
Флешка
Дискета
Сетевая карта с BootROM

В большинстве случаев предпочтительно использовать сетевую загрузку, т.к. это значительно облегчает разворачивание и централизованное управление клиентами. Именно такой вариант загрузки мы будем рассматривать.

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

Также отметим, что на сайте производителя указывается возможность загрузки терминалов по HTTP, которая должна уменьшить нагрузку на TFTP при большом количестве клиентов (более 300) и улучшить загрузку на медленных и ненадежных каналах связи.

Процесс загрузки WTware

Чтобы запустить клиент WTware на компьютере пользователя, нужно:

Загрузить бинарные файлы дистрибутива с сервера (по TFTP) или локального носителя
Получить сетевые настройки с DHCP сервера или из локальных конфигурационных файлов
Получить конфигурационный файл с сервера (по TFTP) или загрузить его с диска

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

Установите роль RD Connection Broker на сервере (это может быть выделенный сервер, или один из членов будущей фермы).
Добавьте все терминальные сервера в локальную группу безопасности «Session Broker Computers» на сервере с ролью RD Connection Broker.
Настройте всех членов фермы на использование сервера RD Connection Broker
Настройте записи DNS для реализация механизма «DNS round robin»

Шаг 1 : Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

Разверните роль Remote Desktop Services.
Нажмите кнопку Add Role Services.
На странице служб роли выберите Remote Desktop Connection Broker и нажмите Next

В моем стенде 2 сервера, настроенных следующим образом:

RDS01

RDS02

Шаг 2 : Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker

Нажмите Start -> Administrative Tools -> Computer Management.
В левой панели разверните узел Local Users and Groups, и выберите Groups.
Найдите локальную группу Session Broker Computers , и выберите пункт Properties.
На вкладке General, нажмите Add.
В окне выбора нажмите кнопку Object Types.
Отметьте пункт Computers, и нажмите OK.
Последовательно укажите и добавьте имена всех серверов, которые будут участвовать в терминальной ферме
Нажмите OK.

На RDS01

На каждом из терминальных серверов RD Session Host выполните следующее:

На сервер RD Session Host откройте консоль Remote Desktop Session Host Configuration (Start ->Administrative Tools->Remote Desktop Services -> Remote Desktop Session Host Configuration).
В разделе Edit settings, щелкните по полю Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажмите кнопку Change Settings.
В окне RD Connection Broker Settings выберите Farm member.
Введите имя сервера с ролью RD Connection Broker.
В окне Farm name, укажите имя создаваемой фермы.
Чтобы активировать балансировку нагрузки в ферме RD Connection Broker отметьте опцию Participate in Connection Broker Load-Balancing.
В случае необходимости можно настроить относительный вес каждого из серверов в ферме (Server weight). Значение по умолчанию — 100. В том случае, если вы зададите вес одного сервера 100, а другого 50, это будет означать, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
По умолчанию используется перенаправление по IP адресу (IP address redirection), также можно использовать перенаправление по токену (Use token redirection).

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02

Task 4 : Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

Откройте оснастку DNS (Start->Administrative Tools-> DNS).
Разверните сервер, и в зонах прямого просмотра (Forward Lookup Zones), разверните ветку с именем вашего домена.
Щелкните по зоне и выберите New Host (A or AAAA).
В поле Name укажите имя фермы (именно фермы, а не конкретного сервера в ней), а в поле IP address укажите ip адрес первого сервера в ферме.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.winitpro.ru)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

Добавление ролей и компонентов

Установка самой оси Microsoft Windows Server 2016 в рамках данной статьи рассматриваться не будет, только отдельно сама установка терминального сервера.
На будущем терминальном сервере открываем диспетчер сервера через Панель управления (Win + R Control) — Администрирование — Диспетчер серверов (Server Manager)
или через команду «Выполнить» (Win + R ServerManager). После чего переходим по вкладке Локальный сервер (Local Server)

Открываем мастер добавления ролей и компонентов, жмём далее, в типе установки отмечаем радиокнопкой пункт Установка ролей или компонентов (Role-based or feature-based installation),
выбираем сервер, жмём далее, чекбоксом отмечаем Службы удаленных рабочих столов. В службах ролей отмечаем для установки две службы: Лицензирование удаленных рабочих столов (Remote Desktop Licensing) и Узел сеансов удаленных рабочих столов (Remote Desktop Session Host),
жмём далее и потом установить. Дожидаемся конца установки и перезагружаем сервер, если это не было сделано автоматически по завершению установки.

Publishing a RemoteApp to Remote Desktop Services.

RemoteApps are applications published to users on RDS servers. Thanks to RemoteApp, you can use applications installed on the RDSH terminal server as if it were running directly on the user’s computer. The user does not see the entire Windows Server RDS desktop and only works with programs that an administrator has published for them. Only the window of the program running on RDS will be displayed on the user’s computer.

RemoteApp applications are created in the RDS Collections settings. Select Tasks -> Publish RemoteApp Programs in the REMOTEAPP PROGRAMS section.

Windows will display all applications installed on the current server. You can choose one of them. If your application is not listed but is installed on other RDS hosts, click the Add button and specify the full path to the application’s executable (exe, bat, cmd, etc.).

Publish the RemoteApp application.

You can then specify additional application options in the RemoteApp settings.

Whether to show the published RemoteApp application in the RD Web Access web interface;
Set the launch parameters (arguments) of the application (Command-line Parameters -> Always use the following command-line parameters);
On the User Assignment tab , you can further restrict which user groups are allowed to run the application.

If you want to change the icon of the published RemoteApp, you need to open the following folder on the server with the RDS Connection Broker role:

Replace the application icon with another ico file.

Now the user can launch the RemoteApp application from RD Web Access (https://msk-rdsman.site.io/RDWeb) or using a special RDP file.

To run the published RemoteApp application, you need to add the following lines to the RDP file:

A few useful little things for convenient operation of the RDS farm:

The RDWeb role can be configured to support HTML5, this will allow users to connect to RDS servers from any browser and OS, even without an RDP client;
On the RD Web Access web server , you can publish a link to change an expired user password (by default, with NLA enabled, you will not be able to authenticate to RDSH with an expired Active Directory user password);
Instructions for users to change the password in the RDP session;
An administrator can use RD Session Shadow connections to connect/view the desktop of a user session on the RDS server;
To quickly find which RDS servers have sessions for a particular user, you can use PowerShell:

You can use PowerShell scripts to view and analyze RDP logs of user connections to RDS servers;
For additional protection, you can set up two-factor authentication (2FA) for users on Windows RDS servers using third-party tools.

Blog of Khlebalin Dmitriy

Terminal Server на Windows 2016. RemoteApp (часть 4).

В целом, терминальный сервер настроен, на нем благополучно крутится 1С и работают пользователи.

Но настроить RemoteApp пришлось не просто так. У нас на сервере крутятся 2 платформы: 1с83 и 1с82. В 1с83 проблем нет, а вот в 1с82, люди жалуются на невозможность изменения масштаба в 1с и мелкий шрифт в ней же. Именно по этому было принято решение прокинуть 1с через RemoteApp.

Еще раз коротко о ролях терминального сервера:

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

2. Роль, которая обеспечивает веб-доступ к удаленным рабочим столам. Ее задача – предоставление ресурсов через веб-браузер.

3. Узел сеансов удаленных рабочих столов – данная роль позволяет размещать на сервере удаленные приложения, или основанные на сеансах рабочие столы.

4. Узел виртуализации удаленных рабочих столов. На данном узле, это у нас сервер Hyper-V, на котором у нас разворачиваются все виртуальные машины, доступ к которым получат все пользователи, что использую технологию VDI.

5. Шлюз удаленных рабочих столов, это посредник между клиентами из внешней сети и коллекции сеансов во внутренней сети и приложений. Шлюз – это безопасность, сервис у нас абсолютно безопасный. И благодаря тому, что RDS в 2012/2016 и 2012R2/201 становится более гибким, проработаны абсолютно все недочеты, которые были раньше. Сейчас этот сервис легко реализуем для огромных, масштабных проектов, для больших корпораций. Раньше возникали некоторые вопросы.

Преимущества «RemoteApp» над обычным «Сервером терминалов» :

Пользователь не путается между удаленным рабочим столом и своим локальным.
Программа 1С запускается сразу при клике по ярлыку, и выглядит как локально установленная.
Пользователь не видит всего рабочего стола и работает лишь с теми программами, которые назначил администратор.
Безопасность выше, чем на обычном сервере терминалов.
Скорость передачи изображения с сервера, выше, чем в сравнении с обычным сервером терминалов. (Оптимизация за счет, передачи не всей картинки, а лишь нужной программы).

Для начала необходимо создать коллекции, ранее мы их уже создали, я об этом уже писал, поэтому здесь пропущу.

Далее публикуем сами приложения RemoteApp (Публикация удаленных приложений).

Выбираем необходимое нам приложение (в моем случае это соответственно 1С):

Вроде благополучно все опубликовалось.

Теперь со своего компьютера набираю в браузере: https://your_server_ip/RDWeb/Pages/ru-RU/login.aspx (ругнется на сертификат, так как его нет, но это не страшно)

Далее предлагается локально скачать файлик:

Здесь сразу запускается 1С.

Все достаточно быстро и без проблем. Но, к сожалению, нашу текущую проблему с масштабированием 1С82 RemoteApp не решает. Но все работает.

На этом настройка закончена.

Всем хорошей работы.

P.S.

Думали опубликовать еще 1с82 через IIS WEB, но с платформой 1с82 это оказалось достаточно проблематично.

По публикации платформы 1с83 почитать можно здесь:

Обновление от 01.10.2020.

Ранее никогда не сталкивался с развертыванием терминального сервера без домена. И тут столкнулся, оказалось, что поставить его можно, а вот управлять через GUI не получится, только через PS.

Или вариант управлять через GUI с другого компа, описан здесь.

Простая инструкция по установке, настройке, активации терминального сервера в windows 2012 r2