Comment configurer la haute disponibilité pour le serveur de connexion RDS sur Windows Server

Configurer un serveur de connexion Bureau à distance (RDCB) tolérant aux pannes peut sembler fastidieux, mais c’est quasiment indispensable pour garantir une disponibilité maximale. En particulier, si vous ne voulez pas qu’une simple panne de serveur paralyse toute votre ferme RDS. Ce guide explique comment rendre le serveur de connexion Bureau à distance hautement disponible, comment rediriger la base de données vers SQL Server Always On et, de manière générale, comment éliminer ce point de défaillance unique. Comme toujours avec Windows, la complexité est de mise : préparez-vous à quelques configurations SQL et à une certaine maîtrise du DNS. L’idée principale : installer votre serveur RDCB sur deux serveurs, les connecter à une base de données SQL partagée et garantir leur disponibilité en toutes circonstances. Il vous faudra un peu de patience et utiliser la ligne de commande, mais au final, vous éviterez toute interruption de service pour vos utilisateurs en cas de problème sur un serveur.

Comment corriger un point de défaillance unique RDCB avec une configuration à haute disponibilité

Préparation de l’infrastructure pour le courtier de connexion de bureau à distance

Assurez-vous que chaque serveur ayant le rôle RDCB possède une adresse IP statique et est joint à votre domaine AD. Par exemple :
- srv-rds1.woshub.com— 192.168.13.20
- srv-rds2.woshub.com— 192.168.13.21
Il est préférable de créer un groupe de sécurité AD dédié appelé MUN_RD_Connection_Brokers. Vous pouvez le faire via PowerShell :
```
New-ADGroup "MUN_RD_Connection_Brokers" -path 'OU=Groups, OU=Berlin, DC=woshub, DC=com' -GroupScope Global -PassThru -Verbose
```

Ajoutez vos serveurs RDCB à ce groupe :

Add-AdGroupMember -Identity "MUN_RD_Connection_Brokers" -Members srv-rds1$, srv-rds2$

Créez des enregistrements DNS de type A pour le nom de votre ferme à charge équilibrée, par exemple MUNRDCB.woshub.com, pointant vers les deux serveurs. Ceci permet d’assurer le bon fonctionnement de la répartition de charge DNS. Vous pouvez le faire via 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

N’oubliez pas d’attribuer des adresses IP statiques et de configurer ces enregistrements DNS ; sinon, l’équilibrage de charge devient rapidement instable.

Côté SQL, installez SQL Server Native Client sur tous les serveurs hébergeant le rôle RDCB, car il est indispensable à la connectivité. Téléchargez-le depuis le site de Microsoft ou copiez le fichier MSI si vous préférez (vérifiez le chemin d’accès : D:\1033_ENU_LP\x64\Setup\sqlncli.msi).

Ouvrez SQL Server Management Studio et connectez-vous à votre serveur SQL Server. Vous devrez créer une base de données dédiée pour RDCB ; nommez-la par exemple RDCB_DB. Ensuite, attribuez-lui les autorisations appropriées :

Dans SSMS, accédez à Sécurité > Connexions. Ajoutez le groupe de domaine MUN_RD_Connection_Brokers.
Attribuez à ce groupe les rôles de créateur de base de données et d’administrateur système — un accès temporaire pour la configuration initiale, mais restreignez-le ensuite de manière stricte.

Assurez-vous d’ouvrir le port TCP 1433 (port SQL par défaut) dans le pare-feu Windows Defender sur ces serveurs, par précaution.

Installation des rôles RDS sur un serveur Windows

Démarrez le Gestionnaire de serveur, puis accédez à Gérer > Ajouter des rôles et des fonctionnalités. Choisissez Installation des services Bureau à distance.
Choisissez le déploiement standard avec déploiement de bureau basé sur les sessions. Sélectionnez ensuite un serveur pour héberger le rôle RDCB. N’installez pas encore le second.
Installez les autres rôles nécessaires, tels que l’accès Web aux services Bureau à distance, sur le même serveur et l’hôte de session Bureau à distance sur les *deux* serveurs concernés.
Une fois l’opération terminée, ajoutez les hôtes RDCB au groupe Serveurs d’administration RDS localement sur chaque serveur. Cette option se trouve généralement dans Services Bureau à distance > Serveurs.
Remarque importante : lors de l’installation du rôle RDCB sur le premier serveur, une rdcbDbbase de données locale C:\Windows\rdcbDb\rdcms.mdfest créée. Celle-ci est inutile en haute disponibilité, car les autres serveurs ne peuvent pas y accéder. Il est donc recommandé de la migrer ultérieurement vers SQL Server.

Création d’un cluster RDCB à haute disponibilité

Avant d’ajouter le deuxième serveur RDCB, migrez la base de données locale vers votre serveur SQL partagé. Dans le Gestionnaire de serveur, accédez à Services Bureau à distance > Vue d’ensemble. Lancez l’ Assistant Configuration de la haute disponibilité via l’icône correspondante sur votre premier serveur RDCB.
Sélectionnez Serveur de base de données dédié. Saisissez le nom DNS de votre batterie de serveurs, par exemple MUNRDCB.woshub.com. Ensuite, indiquez la chaîne de connexion, qui ressemble à ceci :
```
DRIVER=SQL Server Native Client 11.0;SERVER=srv-rds2.woshub.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB
```
Après la configuration, vérifiez dans SQL Management Studio que la base de données RDCB_DB existe et que la connexion SQL dispose des droits appropriés (généralement db_owneret public).
Ajoutez les deux serveurs RDCB à la batterie de serveurs via l’assistant (vous verrez l’option « Ajouter un serveur Broker de connexion Bureau à distance » ).L’objectif : configurer les deux serveurs en haute disponibilité, l’un servant de serveur secondaire en cas de panne du premier. C’est tout. Une fois la haute disponibilité activée, il est impossible de revenir en arrière ; vérifiez donc attentivement tous les paramètres.

Configuration du basculement SQL Server — Le cœur de la haute disponibilité

Maintenant, configurez concrètement votre serveur SQL Server dans un cluster de basculement ou, plus moderne, dans un groupe de disponibilité Always On. Installez le rôle Clustering de basculement, créez le cluster et activez les groupes de disponibilité Always On dans le Gestionnaire de configuration SQL Server.
Exécutez l’assistant pour créer un groupe de disponibilité, incluez la base de données RDCB_DB et configurez le basculement automatique. Assurez-vous que votre écouteur possède un nom DNS (par exemple, SQL-RDSDB-liste ) afin que votre RDCB puisse se connecter à une adresse IP virtuelle en cas de basculement.

Mettez à jour votre chaîne de connexion avec PowerShell pour indiquer à la batterie de serveurs RDCB de pointer vers cet écouteur :

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"

Remarque : Cette configuration n’est pas simple et le dépannage du basculement SQL nécessite de la patience. Assurez-vous que vos écouteurs et votre cluster fonctionnent correctement avant de poursuivre.

Une fois la configuration terminée, testez votre installation en arrêtant un serveur RDCB ou en forçant un basculement SQL : vérifiez que la ferme continue de fonctionner correctement. C’est toute la magie de la haute disponibilité.

Maintenant que tout cela est fait, vous pouvez déployer le reste de votre environnement RDS : serveurs de licences, RDSH, publication des RemoteApps, etc. L’essentiel est de s’assurer que votre serveur RDCB continue de gérer les connexions, même en cas de défaillance d’un nœud.

Résumé

Utilisez des adresses IP statiques et la répartition de charge DNS (round-robin).
Créez une base de données SQL dédiée avec les autorisations appropriées pour RDCB.
Installez les rôles RDS, puis migrez la base de données RDCB vers SQL.
Configurez la haute disponibilité sur SQL avec Always On ou le clustering.
Ajoutez des serveurs à la batterie de serveurs RDS avec la haute disponibilité activée.

Conclure

Assurer une haute disponibilité pour RDCB n’est pas chose simple, mais cela en vaut largement la peine si la disponibilité est cruciale. Une fois la configuration et les tests terminés, la restauration du service après une panne est grandement facilitée : aucune intervention manuelle n’est nécessaire. Ces étapes simples contribuent à la résilience de l’ensemble de la ferme, ce qui est essentiel lorsque les utilisateurs dépendent quotidiennement des bureaux à distance. Espérons que cela permettra à certains de réduire les problèmes liés aux interruptions de service ; cela a très bien fonctionné sur plusieurs configurations que nous avons testées.