In all versions of Windows Server (from Windows Server 2000 to the latest Windows Server 2019), multiple remote desktop connections are allowed. However, the number of simultaneous RDP sessions is limited with two. This means that only two administrators can simultaneously connect to the server via RDP under different accounts (in Windows Server 2003, another, the third one console rdp session was available, for which you had to use the mstsc /console or mstsc /admin command). To use a remote connection, an account must be a member of the local “Administrators” or “Remote Desktop Users” group. However, if a general administrative account is used for administration, under which several admins in a team perform technical tasks (on-duty administrators, domain administrator account, etc.), then when you connect the second RDP session user under the same account, the session of the first one ends with the message:
Remote Desktop Connection
Your Remote Desktop Services session has ended
Another user connected to the remote computer, so you connection was lost. Try connecting again, or contact your network administrator or technical support group.
To understand which user kicked out your remote session, open the Event Viewer console and go to the Windows Logs > Security section. Filter events by the Event ID 4624. You will find the events of the latest RDP logins on this computer with the user name and remote computer name (or an IP address).
You can enable two simultaneous RDP sessions on a Windows Server using special group policy setting or by modifying the registry.
Method 1: fSingleSessionPerUser Registry Key
- Connect to your Windows Server via RDP and run the Registry Editor (regedit.exe);
- Go to the registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server;
- Find the REG_DWORD parameter with the name fSingleSessionPerUser and change its value from 1 to 0 (if this parameter is missing, you can create it manually).
Or you can change the value of the fSingleSessionPerUser parameter with just one command in the cmd with administrator privileges:
REG ADD “HKLMSYSTEMCurrentControlSetControlTerminal Server” /v fSingleSessionPerUser /t REG_DWORD /d 0 /f
Method 2. Restrict Remote Desktop Services Users Policy
You can also change these settings using the domain (gpmc.msc) or local group policy (gpedit.msc) editor console.
- Launch the Local Group Policy Editor console: Win+R > gpedit.msc > Enter;
- Open the following GPO section: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections;
- Find a policy named Restrict Remote Desktop Services users to a single Remote Desktop Services;
- Edit this policy and change its value to Disabled.
In addition, there is another policy in the same GPO section – “Limit number of connections” that allows you to specify the maximum number of RDP connections to this server, but this doesn’t mean that when you specify 99999 connections here, almost 100,000 administrators can connect to this server. Without installing the RDSH role, the number of simultaneous RDP administrative connections will also be limited with two.
After that, you can create a separate RDP session for each remote logon. If you want to use more than 2 simultaneous RDP connections, you will have to install the Remote Desktop Session role on the server and buy RDS licenses to connect users or devices.
- About
- Latest Posts
I enjoy technology and developing websites. Since 2012 I’m running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.
KB ID 0000471
Problem
Server 2012/2008 R2 unlike their predecessors, comes with the multiple remote desktop session restriction enabled. If you are only connecting to a server for remote administration purposes that can get a bit annoying, especially if you have a generic administrative account that multiple techs are using, and you keep kicking each other off the server.
Just as with earlier versions of Windows server you CAN have two RDP sessions at any one time, the restriction is one logon for one account. Thankfully you can disable the restriction and there are a number of ways to do so.
Solution
Server 2008 R2 Option 1: Enable Multiple RDP sessions from TSCONFIG
Note: tsconfig.msc does not work on Windows Server 2012
1. On the server, click Start and in the search/run box type tsconfig.msc{enter}. Locate “Restrict each user to a single session” Right click > Properties.
2. Remove the tick from “Restrict each user to a single session” > Apply > OK.
Server 2012 and 2008 R2 Option 2: Enable Multiple RDP sessions via the registry
1. Start > in the search/run box type regedit {enter} > Navigate to:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server
Locate the fSingleSessionPerUser value > Set it to 0 (Multiple sessions allowed), or 1 (Multiple sessions NOT allowed).
Server 2012 and 2008 R2 Option 3: Enable Multiple RDP sessions via Local Policy
1. Start > in the search/run box type gpedit.msc {enter}.
2. Navigate to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
Locate the “Restrict Remote Desktop Services users to a single Remote Desktop Services session” setting.
3. To enable multiple sessions set the policy to disabled > Apply > OK.
Server 2012 and 2008 R2 Option 4: Enable Multiple RDP sessions via Group Policy
1. On a domain controller > Start > in the search/run box type gpmc.msc {enter}.
2. Either edit an existing GPO that’s linked to your COMPUTERS, or create a new one and give it a sensible name.
3. Navigate to:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
Locate the “Restrict Remote Desktop Services users to a single Remote Desktop Services session” setting.
4. To enable multiple sessions set the policy to disabled > Apply > OK.
5. Then either reboot the clients, wait a couple of hours, or manually run “gpupdate /force” on them.
Related Articles, References, Credits, or External Links
Original Article Written 27/06/11
How to Enable/Disable Multiple RDP Sessions in Windows 2008 or 2008 R2 By default, Windows 2008/2008R2 servers allow two simultaneous Remote Desktop sessions. You may choose to disable multiple RDP sessions if desired. If only one session is available and you take over another person’s live session, you may choose to enable multiple RDP sessions. This article describes the process for disabling and enabling multiple sessions.
Disable Multiple RDP Sessions
- Log into the server using Remote Desktop.
- In Windows 2008 R2
- Click Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.
- In Windows 2008
- Click Start > Administrative Tools > Terminal Services >Terminal Services Configuration.
- In Windows 2008 R2
- Double click Restrict Each User to a Single Session.
- Check Restrict each user to a single session.
Enable Multiple RDP Sessions
- Log into the server using Remote Desktop.
- In Windows 2008 R2
- Click Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.
- In Windows 2008
- Click Start > Administrative Tools > Terminal Services >Terminal Services Configuration.
- In Windows 2008 R2
- Double click Restrict Each User to a Single Session.
- Uncheck Restrict each user to a single session.
- Click OK.
Article ID: 419, Created: April 9, 2012 at 3:08 PM, Modified: August 28, 2014 at 10:10 AM
In Windows Server 2003 you could have multiple Remote Desktop session with the same user. In Windows Server 2008 this is not possible by default. If you login with the same user account the first session will be taken over by second session.
But you can allow multiple Remote Desktop sessions per user by changing a registry key.
- Start regedit
- Check out the follwoing registry key
HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminalServer - If the fSingleSessionPerUser value doesn’t exist, create a new DWORD value named fSingleSessionPerUser
- Open the fSingleSessionPerUser value. The possible values for this setting are as follows:
0x0 Allow multiple sessions per user
0x1 Force each user to a single session - save this
Found this on remotedesktoprdp.com
Tags: Microsoft, multiple session, mutliple, RDP, RDP Session, registry, Remotedesktop, Remotedesktop Session, second session, Session, Windows, Windows Server, windows server 2008, Windows Server 2008 R2 Last modified: January 7, 2019
About the Author / Thomas Maurer
Thomas works as a Senior Cloud Advocate at Microsoft. He engages with the community and customers around the world to share his knowledge and collect feedback to improve the Azure cloud platform. Prior joining the Azure engineering team, Thomas was a Lead Architect and Microsoft MVP, to help architect, implement and promote Microsoft cloud technology.
If you want to know more about Thomas, check out his blog: www.thomasmaurer.ch and Twitter: www.twitter.com/thomasmaurer
Windows Server 2008 r2, работа, служба терминалов, служба удаленных рабочих столов
Установка сервера удалённых рабочих столов
Входим на сервер с правами администратора.
Открывем «Дисппетчер сервера» -> Роли -> Добавить роль:
В списке доступных ролей сервера выбираем «Службы удалённых рабочих столов»:
В списке «Службы роли» отмечаем «Узел сеансов удалённых рабочих столов» и «Лицензирование удалённых рабочих столов». Этих служб достаточно для поддержания базовой функциональности.
Желательно устанавливать сервер терминалов до установки пользовательских приложений.
Метод проверки подлинности. «Требовать проверку подлинности на уровне сети» — эта опция обеспечивает повышенную безопасность, но в этом режиме к серверу не смогут подключаться пользователи с устаревшими клиентами (rdp 5.х и ниже), а также пользователи подключающиеся через Эксплорер (remote desktop web connection). Чтобы обеспечить поддержку клиентов всех версий, выбирайте опцию «Не требовать проверку подлинности на уровне сети».
Режим лицензирования. Желательно заранее определиться с режимом лицензирования: «на пользователя» или «на устройство». Лицензии «на пользователя» эффективны, если в организации большое количество мобильных пользователей, которым требуется доступ к серверу как из корпоративной сети, так и из удаленной (дом, другой офис). Лицензии «на устройство» эффективны, если пользователи жестко привязаны к своим рабочим местам.
Группы пользователей. Здесь вы можете сразу указать группы или отдельных пользователей, которым будет разрешен доступ к серверу терминалов. Это можно будет сделать и позднее, просто добавив нужных пользователей в группу «Пользователи удаленного рабочего стола».
Настройка сервера лицензий Windows Server 2008 r2. Если сервер не входит в домен, то вариантов особо нет:
Обзор выбранных опций перед установкой.
Далее нажимаем кнопку Установить. Система один раз перезагрузится, после чего установка будет продолжена. В итоге вы должны увидеть жизнеутверждающий экран «Установка прошла успешно»
Активация сервера терминалов
Открываем Пуск -> Администрирование -> Службы удалённых рабочих столов -> «Диспетчер лицензирования удалённых рабочих столов». В списке выбираем сервер лицензий. Делаем правый клик, и в меню выбираем пункт «Активировать сервер»:
Запускается мастер активации сервера Windows Server 2008 r2
На следующем шаге выбираем метод подключения. Можно смело выбирать «Автоподключение»:
Сведения об организации. Вводим имя, фамилию и название организации
Дополнительные сведения. Можно заполнить, а можно и проигнорировать
Через несколько секунд ваш сервер будет успешно активирован
Теперь можно преступить к установке лицензий. Следует отметить, что после активации сервера лицензий нет необходимости сразу покупать и устанавливать лицензии. При отсутствии полноценных лицензий сервер работает в демо-режиме. Пользователям выдаются временные лицензии на 120 дней.
Установка лицензий
Запускаем мастер установки лицензий. Это можно сделать сразу после активации сервера лицензий, выбрав соответствующую опцию
Далее выбираем тип соглашения. В моем случае это «Enterprise Agreement». Номер соглашения можно найти в поисковике по запросу «Enrollment Number». Например, работают: 4965437 (3325596;6565792;4526017;5296992)
Выбираем версию продукта, тип лицензии (должен совпадать с ранее выбранным типом лицензий сервера лицензий), количество лицензий
Нажимаем Далее. Если данные верны, лицензии будут успешно установлены.
Попутные вопросы:
Как разрешить новому пользователю доступ к удаленному рабочему столу?
Откройте Диспетчер сервера -> Конфигурация -> Локальные пользователи -> Пользователи. Откройте свойства пользователя, которому необходим доступ, закладка «Членство в группах». Добавьте группу «Пользователи удаленного рабочего стола»:
Можно ли под одним аккаунтом создать несколько независимых сеансов подключения?
Можно, но по умолчанию эта опция отключена (для экономии ресурсов). Откройте Диспетчер сервера -> Роли -> Конфигурация служб терминалов -> Изменить настройки (на той же странице). Двойной клик на опции открывает окно, где можно выполнить изменения:
Какой порт использует RDP по умолчанию и как его изменить?>
По умолчанию используется порт TCP 3389. Изменить его можно отредактировав реестр. Откройте ветку
HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminalServerWinStationsRDP-tcp
и измените параметр PortNumber.
Взято отсюда
- Remove From My Forums
-
Вопрос
-
Здравствуйте!
У меня Windows Server 2008 R2 Std, количество одновременных RDP-сессий сейчас равно 2 (значение по умолчанию). Стоит задача увеличить это кол-во до 5. Согласно листу вкладышу, который был вместе с диском в коробке, Number of CALs
= 5. Обязательно ли в данном случае нужно устанавливать на сервере Remote Desktop Sevices(TS) и Remote Desktop Licensing, чтобы по RDP могло работать до 5 пользователей? Или это можно побороть как-то иначе?
Для пробы установил Remote Desktop Services — Licensing mode: per user, в данном случае всё работает как нужно, но требует установить сервер терминальных лицензий, при установке которого, в свою очередь, запрашивается ключ активации. Опять же, где искать
этот ключ.
Ответы
-
2 сессии — это обычное административное подключение к Remote Desktop (по-моему, если есть третье, то он не будет прервано, а просто будет приостановлено без прерывания программ и проч.)
если нужно больше, то Remote Desktop Sevices. Вы в этом уже убедились
насчет ключа и лицензий — тут есть более компетентные люди, не буду «мутить» …
-
Помечено в качестве ответа
10 декабря 2010 г. 7:42
-
Помечено в качестве ответа
Обновлено 06.08.2016
Добрый день уважаемые читатели блога pyatilistnik.org, сегодня хочется рассказать в данной статье про установку сервер терминалов в Windows Server 2008R2. В windows server 2008R2 по умолчанию по rdp могут подключиться два человека и один консольный, MS хочет бобла за все сверх этого. Для того чтобы расширить количество подключений существует роль Терминальные службы. Суть ее в том что вы ставите или подключаетесь к серверу лицензирования и дальше получаете лицензии либо на пользователей либо на устройства. Благо в Инете бегают ключики лицензий, которые вам дадут до 9999 лицензий.
Итак начнем.
Установить сервер терминалов
Установка терминал сервера 2008 r2, как и любая серверная роль устанавливается, через централизованную оснастку Диспетчер сервер, хотя можно и командной строкой воспользоваться servermanagercmd или powershell, об этом я расскажу в будущих статьях. Для начала откроем Диспетчер сервера и выберем Добавить роль, вообще привыкайте туда почаще заходить 🙂
Откроется окно с бла бла блашной информацией, пропускаем ознакомительное окно и жмем Далее.
У вас появится список доступных ролей в данной версии Windows. Из списка выбираем Службы удаленных рабочих столов, эта роль и есть сервер терминалов и жмем далее
Открывается окно мастера установки службы удаленных рабочих столов. Жмем далее
Поставим базовый набор из двух служб: Узел сеансов удаленных рабочих столов, который отвечает за подключение к серверу, в прошлом она и называлась сервером терминалов в windows server 2003, и вторую службу Лицензирование удаленных рабочих столов, необходимую для раздачи лицензий.
Далее, тут тоже нет ничего интересного
В данном окне нас спросят про метод проверки подлинности, выбираем Требовать проверки подлинности на уровне сети (все что выше XP), тут имеется ввиду чтобы версия RDP клиента была выше 6, где поддерживается уже NLA, Network Level Access.
Тут вам нужно определиться под свои нужны, что вам необходимо, чаще всего лицензии ставят на пользователя, в данном примете так и поступим, но если вам выгодно, для устройств, то выберите их.
Выбираем группы пользователей, которым необходимо дать права, Жмем добавить. Хочу отметить, что добавить права на доступ по удаленному рабочему столу в windows server 2008/2008R2 можно легко и потом, примером может служить централизованные групповые политики, преимущество в том, что вы из одного места контролируете всех кто имеет такие права. Жмем далее.
терминал сервер 2008 r2
Жмем далее более тонко лучше настроить потом.
Если у вас домен, то выбираем либо лес либо домен, если нет, то эта рабочая группа и жмем далее.
терминал сервер 2008 r2
Установить. Начнется накатывание терминал сервера 2008 r2. По времени займет минут этак 5-7.
терминал сервер 2008 r2
После установки роли службы терминалов, жмем закрыть и начнется процесс перезагрузки.
терминал сервер 2008 r2
После перезагрузки, мастер установки еще доделает последние приготовления и выведет вам окно об успешной инсталляции.
терминал сервер 2008 r2
На этом первая часть статьи закончена, но сервер терминалов еще не до настроен. Смотрим продолжение Установка сервера терминалов в 2008/2008R2 2 часть.
Материал сайта Pyatilistnik.org
Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).
Описание задачи
Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.
По информации доступной из блога TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.
Среда исполнения
Три виртуальных сервера на базе Windows Server 2008 R2 Enterprise EN. Корпоративная редакция ОС потребуется нам из-за необходимости использования средств Windows Failover Clustering.
Каждый из серверов имеет по два сетевых интерфейса.
Серверам присвоены имена — KOM-AD01-RDS01 , KOM-AD01-RDS02 и KOM-AD01-RDS03.
Создаваемый в процессе описания кластерный экземпляр Windows Failover Clustering будет иметь имя KOM-AD01-RDSCL.
Кластеризованный экземпляр службы RD Connection Broker будет иметь имя KOM-AD01-RDCB
С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть так:
Настраиваем сетевые параметры
Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 – Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.
Выполним описанные ниже настройки на каждом из трёх серверов.
Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).
NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.
Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.
В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:
В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.
Здесь же, по кнопке Advanced откроем окно дополнительных настроек
В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS
Как было сказано ранее, указанные настройки сетевых интерфейсов нужно сделать по аналогии согласно нашей схемы на всех трёх серверах.
Устанавливаем роль Remote Desktop Services
На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles
В открывшемся окне мастера выбираем роль Remote Desktop Services
Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker
На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication
Значение этой настройки, как и всех других в этом мастере можно будет в изменить позже в любое время после установки роли с помощью оснасток управления RDS
На шаге выбора режима лицензирования выбираем опцию Configure later , так как для конфигурирования параметров режима лицензирования наших терминальных серверов мы в дальнейшем будем использовать возможности доменных групповых политик.
На шаге выбора групп добавим заранее созданную доменную группу безопасности, в которую будут включаться пользователи имеющие потребность в доступе к ресурсам расположенным на серверах создаваемой фермы RDS. После установки роли на сервере будет создана специальная локальная группа безопасности Remote Desktop Users в которую и будут включены выбранные нами на этом шаге группы
На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под Desktop Experience понимается установка дополнительных пользовательских компонент в составе:
- Windows Calendar
- Windows Mail
- Windows Media Player
- Desktop themes
- Video for Windows (AVI support)
- Windows Photo Gallery
- Windows SideShow
- Windows Defender
- Disk Cleanup
- Sync Center
- Sound Recorder
- Character Map
- Snipping Tool
В многопользовательской среде должен быть взят за правило принцип необходимого минимума приложений и поэтому, следуя этому принципу мы не будем устанавливать этот «винегрет».
Далее, после окончания процесса установки роли RDS потребуется перезагрузка сервера. После перезагрузки сервера войдём в систему и дождёмся автоматического открытия окна мастера добавления ролей, который должен будет сообщить нам об успешном окончании процесса.
Включаем поддержку кластеров — Failover Clustering
На каждом из серверов выполняем установку компоненты для возможности работы с кластером — Failover Clustering. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Features вызываем мастер добавления возможностей действием Add Features
В открывшемся окне мастера добавления возможностей выбираем Failover Clustering
Создаём кластер
На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster
В открывшемся мастере создания кластера добавляем все три сервера которые мы планируем включить в будущий кластер
На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.
Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов — Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх. Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI
В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.
Настраиваем кластерные ресурсы
После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.
Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application
В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker
Обратите внимание на то, что в официальной документации есть информация об ограничениях в ситуации когда вы хотите создать кластеризованный экземпляр службы RD Connection Broker в уже существующем кластере и при этом в этом кластере есть настроенные ранее службы типа Generic Service.
На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker
На этапе создания службы в кластере в домене также будет создана дополнительная учетная запись и будет произведена регистрация имени в DNS
После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.
Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети.
Включаем сервера в ферму RD Connection Broker
На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.
Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажимаем кнопку Change Settings.
В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name по рекомендации оставим схожим с именем кластерного экземпляра.
Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
Тип перенаправления оставим в значении по умолчанию — IP address redirection и отметим IP адрес интерфейса которым у нас будут обслуживаться пользовательские сессии на этом конкретном сервере.
В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.
Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…
… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker
После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host
Уже на этом этапе можно попробовать работу нашей фермы в действии подключившись RDP клиентом на адрес фермы. При отключении пользовательского сеанса и повторном подключении RDCB должен направлять нас в уже существующую сессию.
Настраиваем сертификаты серверов RDSH фермы RDCB
При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен
Если открыть свойства этого сертификата мы увидим что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным.
Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.
При создании запроса на сертификат необходимо использовать политику применения — Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
Если в перспективе на ваших терминальных серверах вы планируете использование технологии RemoteApp с использованием цифровой подписи распространяемых RDP-файлов, то возможно вам резонно будет в запрос включить так же и политику применения — Подписывание кода (1.3.6.1.5.5.7.3.3)
Также при создании запроса на сертификат нужно учесть то, что создаваемый сертификат желательно иметь с альтернативными именами объекта – Subject Alternative Name (SAN). В противном случае при подключении клиенты могут получать предупреждение безопасности RDP клиента о том, что имя которое мы используем для подключения не совпадает с именем сервера на который его перенаправляет RD Connection Broker
Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.
Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.
certutil -getreg PolicyEditFlags
Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:
certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:
- Windows Server TechCenter — How to Request a Certificate With a Custom Subject Alternative Name
- KB931351 — How to add a Subject Alternative Name to a secure LDAP certificate
- PowerShell Crypto Guy’s weblog > How to add FQDN to HP iLO request
Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf
Содержимое этого файла в нашем примере выглядит так:
[Version]
Signature=«$Windows NT$»
[NewRequest]
Subject = «CN=KOM-AD01-RDSCB.holding.com» ;
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1; Key Exchange – Required for encryption
KeyUsage = 0xA0; Digital Signature, Key Encipherment
MachineKeySet = TRUE
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.3 ; Code signing
[RequestAttributes]
SAN = «dns=KOM-AD01-RDSCB.holding.com&»
_continue_ = «dns=KOM-AD01-RDS01.holding.com&»
_continue_ = «dns=KOM-AD01-RDS02.holding.com&»
_continue_ = «dns=KOM-AD01-RDS03.holding.com&»
_continue_ = «dns=KOM-AD01-RDSCB&»
_continue_ = «dns=KOM-AD01-RDS01&»
_continue_ = «dns=KOM-AD01-RDS02&»
_continue_ = «dns=KOM-AD01-RDS03&»
_continue_ = «dns=10.160.0.39&»
_continue_ = «dns=10.160.0.41&»
_continue_ = «dns=10.160.0.42&»
_continue_ = «dns=10.160.0.43&»
С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:
cd /d C:Temp
CertReq –New RequestPolicy.inf RequestFile.req
Далее, на основании полученного файла запроса RequestFile.req в локальном центре сертификации можно получить сертификат. В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального изолированного ЦС Active Directory Certificate Services. Действия по запросу и получению сертификата нужно выполнять непосредственно с одного из тех серверов для которых будем создавать этот сертификат. В нашем примере мы выполним запрос и получения сертификата с сервера KOM-AD01-RDS01
Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:
Request a certificate >
advanced certificate request >
Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
и скопируем содержимое сгенерированного ранее запроса из файла RequestFile.req
После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:
View the status of a pending certificate request
Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b
Устанавливаем в систему полученный сертификат командой:
CertReq -accept certnew.p7b
После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС
Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.
В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат
В окне выбора сертификатов выбираем соответствующий сертификат…
После этого сохраняем настройки свойств подключения
Теперь нам нужно установить этот же сертификат на другие два сервера – KOM-AD01-RDS02 и KOM-AD01-RDS03. Для этого в консоли управления сертификатами на сервере KOM-AD01-RDS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.
В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key
На странице Export File Format выбран один возможный вариант формата выгрузки — Personal Information Exchange – PKCS #12 (.PFX)
Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03
Далее указываем имя файла в который будет экспортирован сертификат
Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата
В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом
Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.
На следующем шаге будет предложено выбрать хранилище сертификатов в которое производится импорт. Оставим значение Personal
После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.
По завершении всех манипуляций с сертификатами желательно не забыть удалить все временные копии экспортированного сертификата с закрытым ключом.
В конечном результате описанных действий подключение клиентов должно работать без предупреждений безопасности.
Дополнительные источники информации:
- Windows Server TechCenter — Deploying Remote Desktop Connection Broker with High Availability Step-by-Step Guide
- TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker
- ITBand.ru — Dmitry Rudykh — TS Session Broker