Remote Desktop Connection Broker (RDCB) – это один из компонентов роли терминального сервера (Remote Desktop Services, RDS) в Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между хостами в ферме RDS (при подключении к RDS ферме пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователям к VDI и RemoteApp, управляет конфигурацией RDS хостов в ферме. Также RDCB позволяет пользователям переподключаться к своим сессиям: при подключении к RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и перенаправляет его в старую сессию.
В этой статье мы рассмотрим процесс настройки отказоустойчивого высоко-доступного экземпляра RD Connection Broker, обеспечивающего свой функционал при выходе из строя одного из серверов с ролью RDCB. Для хранения данных RDCB используется БД на MS SQL Server 2019. В целях ухода от одной точки отказа, SQL базу данных RDCB также нужно развернуть в отказоустойчивой конфигурации. В этом примере мы будем использовать два SQL сервера с настроенной группой высокой доступности SQL Always On.
Содержание:
- Подготовка инфраструктуры для Remote Desktop Connection Broker
- Установка ролей Remote Desktop Services
- Настройка высокой доступности для RDS Connection Broker
- Настройка отказоустойчивой конфигурации SQL Server для RD Connection Broker HA
Требования для внедрения отказоустойчивого RDCB:
- Как минимум 2 сервера с ролью RDCB с Windows Server 2019/2022;
- Если вы хотите использовать высокую доступность для SQL базы RDCB, вам понадобится минимум 2 сервера с установленным SQL Server 2014 или выше (с редакцией Standard или Enterprise). В нашем примере на каждый из серверов мы установили standalone экземпляр MS SQL Server 2019 Enterprise. Если вы не планируете создать HA для SQL базы, достаточно одного сервера с SQL Express;
- На серверах с ролями RD Connection Broker нужно установить SQL Server Native Client;
- Предоставить полные права для серверов RD Connection Broker на БД SQL и каталог установки SQL;
- Минимум один сервер с ролью Remote Desktop Session Host в ферме;
Мы создадим отказоустойчивую конфигурацию RDCB их двух серверов. На каждом из них будет установлена роль RD Connection и SQL Server. Высокая доступность базы SQL Server будет достигаться за счет создания группы высокой доступности Always On.
Начиная с Windows Server 2012, RDS Connection Broker обеспечивает высокую доступность в режиме Active/Active. В этом режиме все сервера RDCB являются активным и могут обрабатывает входящие запросы. Это позволяет обеспечить высокую доступность и масштабируемость RDCB в больших фермах Remote Desktop.
Подготовка инфраструктуры для Remote Desktop Connection Broker
Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и добавить в домен Active Directory.
- Srv-rds1.winitpro.loc — 192.168.13.20
- Srv-rds2.winitpro.loc — 192.168.13.21
Создайте в Active Directory новую группу безопасности HQ RDS Connection Brokers, и добавьте в нее все сервера RDCB. Можно создать группу из оснастки ADUC (dsa.msc) или с помощью PowerShell:
New-ADGroup "HQ RDS Connection Brokers" -path 'OU=Groups,OU=SPB,OU=RU,DC=winitpro,DC=loc' -GroupScope Global -PassThru –Verbose
Добавьте в группу два сервера:
Add-AdGroupMember -Identity "HQ RDS Connection Brokers" -Members srv-rds1$,srv-rds2$
Создайте в DNS A записи для вашей кластерного имени RDS фермы (в нашем примере это HQRDCB). Все записи должны указывать на IP адреса всех серверов RDCB. Это необходимо для балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Я создал такие записи:
- A — HQRDCB.winitpro.loc 192.168.13.20 (ip адрес первого сервера RDCB — Srv-rds1.domain.ru)
- A — HQRDCB. winitpro.loc 192.168.13.21 (ip адрес второго сервера RDCB — Srv-rds2.domain.ru)
Можно создать A записи в DNS с помощью PowerShell:
Add-DnsServerResourceRecordA -Name HQRDCB -IPv4Address 192.168.13.20 -ZoneName winitpro.loc
Add-DnsServerResourceRecordA -Name HQRDCB -IPv4Address 192.168.13.21 -ZoneName winitpro.loc
Установите SQL Server Native Client на всех серверах, на которых будет работать роль RDCB. SQL Server Native Client для вашей версии SQL Server можно скачать с сайта Microsoft или скопировать из установочного образа SQL Server (
D:\1033_ENU_LP\x64\Setup\x64\sqlncli.msi
)
Теперь запустите SQL Server Management Studio и подключитесь к вашему первому SQL серверу, на котором будет создана общая база данных Connection Broker (позже мы перенесем ее в группу высокой доступности Always On).
Перейдите в раздел Security -> Logins и добавьте новый login. Нажмите на кнопку Search, в Locations выберите свой домен, установите Object Types = Groups и найдите доменную группу HQ RDS Connection Brokers.
Назначьте этой группе роли
dbcreator
и
sysadmin
.
Откройте необходимые порты в Windows Firewall (по умолчанию для подключения к SQL Server используется
TCP 1433
).
Установка ролей Remote Desktop Services
Теперь нам нужно установить RDS роли на ваших серверах. Запустите консоль Server Manager, выберите Manage -> Add roles and Features -> Remote Desktop Services Installation.
Выберите Standard deployment -> Session-based desktop deployment.
Выберите один сервер, на который вы хотите установить роль RD Connection Broker. Сейчас не нужно ставить роль RDCB на второй сервер.
Установите роль RD Web Access на тот же сервер, что и RDCB (если эта роль не нужна, ее потом можно удалить). Установите роль RD Session Host на оба сервера.
Дождитесь окончания установки ролей RDS.
После окончания установки ролей, добавьте в локальную группу RDS Management Servers на обоих серверах учетные записи хостов RDCB и ‘NT AUTHORITY\NETWORK SERVICE’.
При установке роли RD Connection Broker на первый сервер в ферме он создаст локальную база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге C:\Windows\rdcbDb\.
В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.
Настройка высокой доступности для RDS Connection Broker
Прежде чем добавить в ферму второй хост с ролью RD Connection Broker, нужно перенести локальную базу RDCB на внешний SQL сервер.
Для переноса БД Connection Broker из локальной базы на выделенный SQL Server нужно перейти в Server Manager -> Remote Desktop Services -> Overview. Чтобы запустить мастер создания отказоустойчивой конфигурации RD Connection Broker, щёлкните по изображению роли RD Connection Broker и выберите пункт Configure High Availability.
Выберите Dedicated Database Server. Затем нужно указать параметры подключения к SQL Server, на который будет перенесена локальная база RDCB.
Нужно заполнить три поля:
- DNS name for the RD Connection Broker Cluster: FQDN имя фермы RDCB, для которой мы создавали записи в DNS для Round Robin (в нашем примере это
HQRDCB.winitpro.loc
). Именно по этому адресу будут обращаться RDP клиенты при подключении к серверам RD Connection Broker; - Database Connection String – здесь нужно указать строку подключения с базе на SQL сервере. Формат строки такой:
DRIVER=SQL Server Native Client 11.0;SERVER=<SQL Server Name>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<DB Name>В данном примере SQL Server Name – имя SQL сервера, где нужно создать базу, а DB Name – имя новой базы данных:
DRIVER=SQL Server Native Client 11.0;SERVER=srv-rds2.resource.loc;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB
После этого нельзя переключить кластер RD Connection Broker на внутренюю базу Windows Internal Database без полного пересоздания фермы.
На следующем этапе нажмите Configure.
Затем подключитесь к SQL Server с помощью SQL Management Studio и проверьте, что была создана новая база данных RDCB_DB.
Вам нужно предоставить обоим серверам RD Connection Broker права на запись в эту базу. Перейдите в Database -> RDCB_DB -> Security -> Users -> New user.
Создайте двух новых пользователей
BUILTIN\RDS Management Servers
и
winitpro\HQ RDS Connection Brokers
. Предоставьте этим группам права db_owner и public.
Для обеспечения высокой доступности на случай выхода из строя первого сервера, необходимо в текущую конфигурацию добавить второй сервер RD Connection Broker.
Щелкните по иконке RD Connection Broker, и выберите пункт Add RD Connection Broker Server.
Укажите имя второго сервера, на котором нужно установить роль Connection Broker и нажмите Next. Теперь в списке хостов фермы RDS появится два сервера с ролью RDCB. Также появится надпись RD Connection Broker (High Available Mode).
На этом настройка High Availability конфигурации Connection Broker завершена.
Настройка отказоустойчивой конфигурации SQL Server для RD Connection Broker HA
Теперь нужно обеспечить отказоустойчивую конфигурацию для базы данных SQL. Пока она запущена только на одном сервере. Базу данных RD Connection Broker нужно разместить в кластере SQL. Это может быть, как классический Failover Cluster, так и группа высокой доступности SQL Always On.
Базовая настройка Always On в SQL Server 2019 рассмотрена в отдельной статье. Здесь мы только вкратце опишем основные особенности:
- Установите роль Failover Clustering и соберите кластер SQL-RDS из двух хостов RDCB со свидетелем с кворумом на любом файловом сервере (описано в статье про Always On кластер чуть выше);
- Включите опцию Enable Always On Availability Groups в настройках SQL Server Configuration Manage на обоих серверах;
- Запустите New Availability Group Wizard;
- Задайте имя Availability Group (SQL-RDS);
- Выберите базу, которую вы хотите поместить в группу высокой доступности (RDCB_DB);
- Добавьте второй сервер SQL в группу высокой доступности, включите опцию Automatic Failover;
- На вкладке Listener задайте имя и IP адрес, которое будет использоваться клиентами для подключения к базе данных в группе Always on (SQL-RDSDB-liste);
- Запустите консоль Failover Cluster Manager (
FailoverClusters.SnapInHelper.msc
) и проверьте, что в ролях появился новый ресурс.
Теперь нужно изменить строку подключения к SQL серверу с базой данных RDCB в настройках Connection Broker. Изменить строку подключения можно только из PowerShell.
Set-RDDatabaseConnectionString [-DatabaseConnectionString] <String> [[-ConnectionBroker] <String>] [ <CommonParameters>]
В нашем примере команда для переключения фермы RDCB на SQL базу данных в группе высокой доступности выглядит так:
Set-RDDatabaseConnectionString -ConnectionBroker srv-rds1.winitpro.loc -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=SQL-RDSDB-liste;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB"
Если команда не вернула ошибки, значит все OK. И теперь ваш кластер RDS Connection Broker настроен на использование SQL в группе высокой доступности Always On.
Откройте настройки ферму RDS и убедитесь, что теперь для HA используется новая строка подключения (Tasks -> Edit Deployment Properties).
Итак, мы создали высоко доступный сервис RDS Connection Broker на Windows Server 2022/2019. Вы можете протестировать доступность RDCB, отключив один из серверов фермы RDS. После этого вы можете продолжить настройку фермы RDS, создать сервер лицензирования RDS, добавить RDSH сервера, настроить коллекции, опубликовать приложения, HTML5 веб клиент RDS и т.д.
Installing the Remote Desktop Connection Broker (RD Connection Broker) is a key step in setting up a Remote Desktop Services (RDS) environment.
This server role helps you efficiently manage remote desktop connections, especially in an RDS server farm where multiple servers share the load. Whether you’re looking to scale your deployment, ensure redundancy, or provide seamless session reconnections, the RD Connection Broker is critical for a robust and reliable setup.
With various roles and prerequisites required for a fully functional RDS environment, a clear plan is essential to avoid costly mistakes or downtime. This guide will simplify the process, showing you step-by-step instructions on how to install the RD Connection Broker on a Windows Server.
IN THIS GUIDE
Overview of Remote Desktop Connection Broker
Key Tasks of Remote Desktop Connection Broker
Step-by-Step Installation Process for RD Connection Broker
Simplify RDS Deployment with V2 Cloud
WordPress Table of Contents by Topic
Overview of Remote Desktop Connection Broker
The Remote Desktop Connection Broker is a core component in any Remote Desktop Services environment. It acts as a central hub, managing how users connect to Remote Desktop Session Host (RD Session Host) servers in a server farm.
If you’re deploying an RDS setup with multiple session hosts, the RD Connection Broker ensures that incoming connections are directed to the appropriate server, optimizing performance and reliability.
Why Do You Need RD Connection Broker?
RD Connection Broker enables key functionalities that are crucial for an efficient RDS deployment:
- Redundancy: It ensures uninterrupted access by balancing connections across multiple servers, even if one server goes offline.
- Scalability: As your user base grows, the RD Connection Broker allows you to scale seamlessly by distributing sessions across additional servers.
- Efficiency: It reconnects users to disconnected sessions, providing a smooth user experience without losing data.
How It Works
Imagine a user initiating a remote desktop session:
- The connection request reaches the RD Connection Broker.
- The broker determines the best RD Session Host server based on load and availability.
- The connection is redirected to the selected server.
This process happens in real time, ensuring efficient resource utilization and maintaining an optimal user experience.
Additional Tasks of RD Connection Broker
Beyond managing connections, the RD Connection Broker performs other critical roles:
- Session Load Balancing: Ensures no single server is overwhelmed by distributing sessions evenly.
- Reconnection to Existing Sessions: Allows users to reconnect to previously disconnected sessions on the same server.
- Resource Assignment: Directs users to specific remote desktops, applications, or virtual desktops.
- Virtual Desktop Management: Provides access to virtual desktops within a collection, simplifying resource distribution in virtual environments.
The RD Connection Broker serves as the backbone of an RDS deployment, making it indispensable for organizations looking to deliver secure and scalable remote access solutions.
Key Tasks of Remote Desktop Connection Broker
The RD Connection Broker does more than just route incoming connections. It plays a critical role in ensuring the smooth operation of your RDS environment. Here’s a closer look at its key tasks:
1. Session Load Balancing
The RD Connection Broker ensures no single RD Session Host server is overwhelmed by user connections. It distributes sessions evenly across the server farm, optimizing server performance and maintaining a consistent user experience.
2. Reconnecting Disconnected Sessions
If a user gets disconnected from their session—whether due to network issues or a temporary logout—the RD Connection Broker allows them to reconnect seamlessly to their original session. This ensures continuity, reducing interruptions and preventing data loss.
3. Assigning Users to Resources
The RD Connection Broker matches users with the appropriate resources, including:
- Remote Desktops: Individual desktops hosted on RD Session Host servers.
- Remote Applications: Published apps accessible via RemoteApp.
- Web Access: Resources accessed through a web browser interface.
4. Virtual Desktop Access
For environments utilizing virtual desktops, the RD Connection Broker provides users access to virtual desktop collections. This simplifies resource allocation and improves the management of virtual environments.
5. Supporting High Availability
When deployed in a high-availability setup, the RD Connection Broker ensures reliability by working across multiple servers. It allows for redundancy, reducing the risk of downtime and improving overall system stability.
Step-by-Step Installation Process for RD Connection Broker
Installing the Remote Desktop Connection Broker (RD Connection Broker) role requires careful execution. Follow this detailed guide to ensure a smooth deployment on a Windows Server.
This example uses Windows Server 2016.
Step 1: Log in and Open Server Manager
- Log into the server where you want to install the RD Connection Broker using an account with administrative privileges.
- Once logged in, open Server Manager from the taskbar or Start menu.
Step 2: Initiate Role Installation
- In Server Manager, under Configure this local server, click on the Add roles and features link.
Step 3: Proceed Through the Wizard
- The Add Roles and Features Wizard will appear.
- Click Next on the Before You Begin page. This page provides an overview of prerequisites and guidelines for role installation.
Step 4: Select Installation Type
- On the Select installation type page, choose Role-based or feature-based installation.
- Click Next to proceed.
Step 5: Select the Destination Server
- On the Select destination server page:
- Choose Select a server from the server pool.
- Highlight the target server where you plan to install the RD Connection Broker by clicking on it.
- Click Next to continue.
Step 6: Select the RD Connection Broker Role
- On the Select server roles page:
- Expand Remote Desktop Services by clicking the drop-down arrow.
- Select the checkbox for Remote Desktop Connection Broker.
- A pop-up window will appear prompting you to add required features for this role.
Step 7: Add Required Features
Step 8: Review the Features Page
- On the Select Features page, simply click Next unless additional features are required for your deployment.
Step 9: Confirm Automatic Restart
Step 10: Install the RD Connection Broker Role
- After confirming your selections:
- Review the summary of roles, features, and settings to ensure everything is correct.
- Click Install to begin the installation process.
Step 11: Monitor the Installation Progress
- The installation process will start. A progress bar will indicate the status.
- Do not close the wizard while the installation is in progress.
Step 12: Complete the Installation
- Once the installation is complete, you will see a confirmation message stating that the RD Connection Broker role was successfully installed.
- Click Close to exit the wizard.
Post-Installation Checklist
After installation, verify the following:
- Role Verification:
- Go to Server Manager and ensure the RD Connection Broker role is listed under installed roles.
- Additional Roles for RDS:
- Install complementary roles like RD Session Host and RD Web Access if they haven’t been deployed yet.
- Configuration:
- Configure the RD Connection Broker to work with your RD Session Host servers for load balancing and reconnection features.
Simplify RDS Deployment with V2 Cloud
Deploying and managing Remote Desktop Services (RDS) can be complex, especially when setting up roles like the RD Connection Broker, RD Session Host, and RD Web Access. Ensuring proper configuration and maintaining scalability requires expertise and time.
For businesses or IT teams looking for a streamlined alternative, V2 Cloud offers an all-in-one solution that eliminates the challenges of traditional RDS setups.
- No Hidden Fees or Complicated Setup: Get started in minutes without worrying about configuring server roles or infrastructure.
- Scalability and Performance: Instantly scale your cloud environment as your team grows, ensuring smooth and consistent user experiences.
- Flat-Rate Pricing: Predictable costs with no surprise fees or long-term contracts.
- Security and Compliance: V2 Cloud prioritizes security, with built-in encryption, secure access controls, and compliance with industry standards.
- End-to-end Management: Forget about hardware maintenance or manual configuration—V2 Cloud handles it all for you.
Talk to a Cloud Expert Now and see how V2 Cloud can simplify your remote desktop and virtualization needs!
Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов 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 Policy\EditFlags
Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:
certutil -setreg policy\EditFlags +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
Remote Desktop Connection Broker (RDCB) is a component of the Remote Desktop Services (RDS) role in Windows Server. RD Connection Broker allows you to load-balance the RDS farm servers (when connecting to an RDS farm, the user is redirected to the least loaded RDS host), provides user access to VDI and RemoteApps, manages RDS host configuration in the farm. Also, RDCB allows users to reconnect to their sessions: when connecting to RDS, RDCB checks if there is any incomplete session on other servers of the farm and redirects them to their previous sessions.
In this article, we’ll show how to configure a fault-tolerant high availability RD Connection Broker instance maintaining its features in case one of the servers with the RDCB role fails. A database server running MS SQL Server 2019 will be used to store Remote Desktop Connection Broker data. To avoid a single point of failure, an RDCB SQL database should also be deployed in a fault-tolerant configuration. In this example, we will use two SQL Server nodes with the SQL Always On Availability Group configured.
Contents:
- Preparing Infrastructure for Remote Desktop Connection Broker
- Install Remote Desktop Services Roles on Windows Server
- Deploying RD Connection Broker High Availability
- Configuring SQL Server Failover Configuration for RD Connection Broker HA
RD Connection Broker High Availability requirements and supported configurations:
- At least 2 servers with the RD Connection Broker role running Windows Server 2022/2019;
- If you want to use high availability for an RDCB SQL database, you will need at least 2 hosts with SQL Server 2014 or newer (Standard or Enterprise edition). In this example, we have installed a standalone MS SQL Server 2019 Enterprise instance on each of the servers. If you are not going to have an HA SQL database, one server with SQL Express is enough;
- Install SQL Server Native Client on the servers with the RD Connection Broker role;
- Grant full control over your SQL database and SQL installation folder to RD Connection Broker servers;
- At least one server with the Remote Desktop Session Host role in the farm.
We will create a highly available RDCB configuration of two servers. Both of them will have the RD Connection role and SQL Server installed. High availability and disaster recovery of the SQL Server database will be provided by the SQL Server Always On Availability group.
In Windows Server 2012 and newer, RDS Connection Broker provides high availability in the Active/Active mode. In this mode, all RDCB servers are active and can process incoming connections. It allows providing high RDCB availability and scalability in large Remote Desktop environments.
Preparing Infrastructure for Remote Desktop Connection Broker
Assign static IP addresses to all servers with the RD Connection Broker role and join them to your Active Directory domain.
srv-rds1.woshub.com—192.168.13.20srv-rds2.woshub.com—192.168.13.21
Create a new security group in Active Directory (MUN_RD_Connection_Brokers) and add all RDCB servers to it. You can create the group with the ADUC snap-in (dsa.msc) or by using PowerShell:
New-ADGroup "MUN_RD_Connection_Brokers" -path 'OU=Groups,OU=Berlin,DC=woshub,DC=com' -GroupScope Global -PassThru –Verbose
Add two RDS hosts to the group:
Add-AdGroupMember -Identity "MUN_RD_Connection_Brokers" -Members srv-rds1$,srv-rds2$
Create A records for the cluster name of your RDS farm (in our example, it is MUNRDCB) in DNS. DNS records must contain the IP addresses of all RDCB servers. It enables load balancing (Round Robin) between RD Connection Broker servers. I have created the following entries:
- A —
MUNRDCB.woshub.com 192.168.13.20(IP address of the first RDCB server — srv-rds1.woshub.com) - A —
MUNRDCB.woshub.com 192.168.13.21( IP address of the second RDCB server — srv-rds2.woshub.com)
You can create A records in DNS using PowerShell:
Add-DnsServerResourceRecordA -Name MUNRDCB -IPv4Address 192.168.13.20 -ZoneName woshub.com
Add-DnsServerResourceRecordA -Name MUNRDCB -IPv4Address 192.168.13.21 -ZoneName woshub.com
Install the SQL Server Native Client on all servers with the RDCB role. You can download the SQL Server Native Client for your SQL Server version from the Microsoft website or copy it from the SQL Server install image (D:\1033_ENU_LP\x64\Setup\x64\sqlncli.msi).
Then run SQL Server Management Studio and connect to your first SQL server, on which a shared Connection Broker database will be created (later we will move it to the Always On high availability group).
Open Security -> Logins to add a new login. Click Search, select your domain in Locations, set Object Types = Groups, and find the domain group MUN_RD_Connection_Brokers.
Assign dbcreator and sysadmin roles to the group.
Open SQL Server ports in Windows Defender Firewall (by default, TCP 1433 port is used to connect to Microsoft SQL Server).
Install Remote Desktop Services Roles on Windows Server
Then you have to install RDS roles on your servers. Open the Server Manager console, select Manage -> Add roles and Features -> Remote Desktop Services Installation.
The installation of the RDS role on a standalone host is described in this article.
Select Standard deployment -> Session-based desktop deployment.
Choose one server you want to install the RD Connection Broker role on. You don’t need to install the RDCB role on the second server now.
Install the RD Web Access role on the same server. Install the RD Session Host role on both servers.
Wait for the installation of RDS roles to complete.
When you have finished installing the roles, add the RDCB hosts and ‘NT AUTHORITY\NETWORK SERVICE’ accounts to the local RDS Management Servers group on both servers.
During the installation of the RD Connection Broker role on the first server in the farm, a local SQL database will be created in C:\Windows\rdcbDb\rdcms.mdf on the local drive of the RD Connection Broker server.
This database keeps the information about the farm and terminal user sessions. Since it is located on the local computer, other RDCB servers will not be able to use it. To provide RDCB HA, you have to move it to a dedicated SQL server where other servers can access it.
Deploying RD Connection Broker High Availability
Before you add a second host with the RD Connection Broker role to the farm, you must migrate the local RDCB database to an external SQL Server.
To move the Connection Broker database from the local database to the dedicated SQL Server, open Server Manager -> Remote Desktop Services -> Overview. To run the Remote Desktop Connection Broker Failover Configuration Wizard, click the RD Connection Broker role image and select Configure High Availability.
Then select Dedicated Database Server. Specify SQL Server connection settings the local RDCB database will be moved.
Fill in two fields:
- DNS name for the RD Connection Broker Cluster: an FQDN name of your RDCB farm we have created Round Robin DNS records for (in our example, it is
MUNRDCB.woshub.com). This is the address that RDP clients will use when connecting to RD Connection Broker servers; - Database Connection String – specify the connection string to the SQL Server database. Here is the string format:
DRIVER=SQL Server Native Client 11.0;SERVER=<SQL Server Name>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<DB Name>In this example, SQL Server Name is the name of the SQL server you want to create a database on, and DB Name is the name of your new database:
DRIVER=SQL Server Native Client 11.0;SERVER=srv-rds2.woshub.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB
Once an RD Connection Broker HA configuration is enabled, you won’t be able to revert to the internal RDCB database without decommissioning the whole RDS farm configuration.
Click Configure in the next step.
Then connect to your SQL Server instance using SQL Management Studio and make sure that the new database RDCB_DB has been created.
Grant both RD Connection Broker servers write permissions to the database. Open Database -> RDCB_DB -> Security -> Users -> New user.
Create two new users: BUILTIN\RDS Management Servers and woshub\MUN_RD_Connection_Brokers. Grant both db_owner and public privileges.
To provide high availability in case the first server fails, add a second RD Connection Broker server to the current configuration.
Click the RD Connection Broker icon and select Add RD Connection Broker Server.
Enter the name of the second server you want to install the Connection Broker role on and click Next. Then two servers with the RDCB role will appear in the list of RDS farm hosts. You will also see the RD Connection Broker (High Available Mode) message.
This completes the High Availability configuration of the Remote Desktop Connection Broker.
Configuring SQL Server Failover Configuration for RD Connection Broker HA
Then set up a failover configuration of your SQL database. Meanwhile, it is running on one server only. Place your RD Connection Broker database in the SQL cluster. It may be either a classic Microsoft Failover Cluster or an SQL Server Always On high availability group.
Basic Always On configuration in SQL Server 2019 is described in this article. We will show only the main steps here:
- Install the Failover Clustering role and build an SQL-RDS cluster of two RDCB hosts with a witness and quorum on any file server (it is described in the article on Always On mentioned above);
- Enable the option Enable Always On Availability Groups in the SQL Server Configuration Manager settings on both servers;
- Run the New Availability Group Wizard;
- Enter the name of the Availability Group (SQL-RDS);
- Select a database you want to place in your high availability group (RDCB_DB);
- Add the second SQL server to the high availability group and check the Automatic Failover option;
- On the Listener tab, enter the name and IP address that clients will use to connect to the database in your Always On group (SQL-RDSDB-liste);
- Open the Failover Cluster Manager snap-in (
FailoverClusters.SnapInHelper.msc) and make sure that the new resource has appeared in the list of roles.
Then change the connection string for the SQL server with the RDCB database in the Connection Broker settings. You can only change the RDCB connection string via PowerShell:
Set-RDDatabaseConnectionString [-DatabaseConnectionString] <String> [[-ConnectionBroker] <String>] [ <CommonParameters>]
In my example, the command to switch the RDCB farm to the SQL database High Availability group looks like this:
Set-RDDatabaseConnectionString -ConnectionBroker srv-rds1.woshub.com -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=SQL-RDSDB-liste;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB"
If the command returns no error, then everything is OK. Now your RDS Connection Broker cluster is configured to use SQL Always On availability group.
Open your RDS farm settings and make sure that a new connection string is used for HA (Tasks -> Edit Deployment Properties).
So, we have created a high-availability RDS Connection Broker service on Windows Server 2022/2019. You can test RDCB’s high availability by shutting down one of the hosts in the RDS farm.
Then you can go on with the configuration of your RDS farm, deploy an RDS licensing server, add RDSH servers, set up RDS collections, publish RemoteApps, enable HTML5 web client for RDS, etc.
In Remote Desktop Commander 6.0, we introduced a new Top Level Deployment Dashboard which displays the health of all of your Remote Desktop Services deployment infrastructure in one main view. If you integrate the Remote Desktop Commander Suite with our Remote Desktop Canary solution, the results of your continuous synthetic RDP login tests will automatically update in this dashboard, so you can spot errors or lengthening login times that impact user experience.
In addition, this dashboard displays the trending health and load of all of your RDS gateway servers, your connection brokers, and session host collections.
Why Connection Broker Monitoring Is Important
Out of all of these roles, the Connection Broker is arguably the most important, as it truly is the “brains” of an RDS deployment. It is responsible for routing and load balancing users on to the correct servers in RDS collections, and also reconnecting disconnected sessions to the appropriate hosts. As such, the Remote Desktop Commander Suite monitors Connection Broker metrics like connection success rate, the recent number of connections processed, the response time of the SQL database server(s) the connection broker(s) are linked to, and the stored procedure success rate on that SQL database(s) that the connection brokers consult when routing users.
How To Monitor Connection Brokers
Our software collects and monitors these metrics because it has been our direct experience that connection brokers can seem “OK” in terms of CPU and memory use, but may NOT actually be OK when you start looking at things like database response times and stored procedure failure rates. Frankly, the internal mechanics of how connection brokers interact with their SQL databases are, erm, “complicated” and somewhat akin to watching sausage being made – it’s not pretty! When login storms arrive in the morning, after lunch, or after a temporary RD gateway or load balancer failure, the SQL DB typically gets overloaded, causing the connection broker to stop routing connections, etc. Consequently, proper connection broker monitoring must incorporate all of these metrics.
Furthermore, comprehensive RDS deployment monitoring, like what we provide in our Complete Monitoring and Management Bundle for RDS, monitors connection broker metrics ALONGSIDE critical gateway AND session host metrics, plus drives continuous testing into the farm with synthetic RDP login monitoring. The Top Level Deployment Status Dashboard is your entry point to all of this rich information, with drill down capabilities into active session management, shadowing sessions, user and process level performance troubleshooting, and over 100 reports on connection quality, user activity monitoring, licensing, and much more just a few mouse clicks away.
Connection Broker Error Reporting
While connection broker routing failures happen less frequently than Remote Desktop Gateway CAP and RAP failures, it’s still important to keep an eye on them. For instance, if you migrate your deployment to use new infrastructure servers, or if you recreate your RDS collections, you may have users trying to connect with older RDP files that hold invalid collection information. Running the “Connection Broker Connection Request Failures” report in the Remote Desktop Commander Suite will show you all of the user accounts that are using invalid RDP files, as well as other problems, such as connection broker(s) with insufficient system resources to route users appropriately.
Ready To Get Started?
Are you ready to add comprehensive monitoring and management to your RDS environment? Would you like to have that “single pane of glass” that can show you all the critical metrics related to your Remote Desktop Services deployment, with active session management/shadowing, deep dive performance troubleshooting, user activity monitoring, license tracking, connection quality, and more just a few mouse clicks away?
If so, start a very affordable subscription to our Complete Monitoring and Management Bundle for RDS with volume discounts available. Or, if you’re not ready to purchase just yet, contact us for a web demo and let us answer all of your pre-purchase questions.
Updated: January 2023.