Dans ce tutoriel, je vais vous expliquer comment configurer une stratégie de groupe (GPO) afin de fermer les sessions RDP déconnectées automatiquement des serveurs membres d’un domaine Active Directory.
Aujourd’hui l’administration des serveurs Windows se fait quasiment uniquement à l’aide du Bureau à distance (RDP). Il n’est pas rare de voir sur les serveurs dans la liste des utilisateurs des sessions « déconnectées », cela signifie que l’utilisateur (administrateur du serveur) ne s’est pas déconnecté quand il a terminé son opération, il a simplement fermer la fenêtre de connexion de à distance
Personnellement cela à tendance à m’énerver ….
Le fait de fermer la session permet de consommer moins de ressource, surtout si un navigateur a été lancé, également pour des raisons de sécurité, il est important de fermer les sessions, cela évite le transite de demande d’authentification sur le réseau pour l’accès à diverse ressource.
Pour pallier à ce problème, on peut mettre en place une stratégie de groupe, qui va fermer automatiquement les sessions déconnectées depuis X temps.
Pour les serveurs qui serait hors domaine, il est possible de le faire avec la console
gpedit.msc.
Sommaire
Créer la stratégie de groupe
Depuis la console Gestion de stratégie de groupe, aller sur le conteneur (dossier) Objets de stratégie de groupe.
Dans la zone centrale, faire un clic droit et cliquer sur Nouveau 1.
Nommer la stratégie de groupe 1 puis cliquer sur OK 2 pour créer l’objet.
Configurer la stratégie de groupe pour fermer les sessions Bureau à distance déconnectées
Faire un clic droit sur l’objet GPO que l’on vient de créer et cliquer sur Modifier 1.
Depuis l’éditeur, aller à l’emplacement suivant pour accéder aux paramètres : Configuration ordinateur / Stratégie / Modèles d'administration / Composant Windows / Services de Bureau à distance / Hôte de la session Bureau à distance / Délais d'expiration des sessions. Ici nous allons configurer le paramètre Définir le délai d’expiration des sessions déconnectés 1, faire un double clic dessus pour l’ouvrir.
Passer le paramètre a Activé 1, définir le délai 2 puis cliquer sur les boutons Appliquer 3 et OK 4.
Le paramètre Définir le délai d’expiration des sessions déconnectés est activé 1.
La stratégie de groupe est prête, il faut maintenant lier la GPO à l’emplacement où l’on souhaite l’appliquer. Dans ce tutoriel, je vais la lier à l’OU Servers.
Lier l’objet stratégie de groupe pour son application sur les serveurs
Faire un clic droit sur l’emplacement où vous souhaitez lier la stratégie groupe et cliquer sur Lier un objet de stratégie de groupe existant … 1.
Sélectionner l’Objet de stratégie de groupe 1 que l’on vient de créer et cliquer sur OK 2.
La stratégie de groupe est liée, elle va maintenant s’appliquer aux ordinateurs qui se trouve l’Unité d’Organisation Server.
Pour appliquer la stratégie de groupe, il est possible de forcer la mise à jour depuis la console Gestion de stratégue de groupe.
Vous savez maintenant comment faire pour ne plus avoir de session non déconnectée sur vos serveurs Windows.
« Personnellement cela à tendance à m’énerver …. »
on dirait moi ! j’arrête pas de râler auprès de mes équipes pour qu’ils se déco correctement!
J’applique les maj la nuit et le reboot doit se faire s’il n’y pas de session ouverte, autant dire que les maj ne se font pas !
Donc un grand merci !
Bonjour Romain
Comme toujours un article intéressant.
Moi aussi ça me fait rager les sessions inactives … et particulièrement quand je dois en tuer une pour me connecter. La première fois je contacte le concerné, j’explique et je tue sa session. Les fois suivantes, je tue la session sans avertissement. Cependant, quelquefois, cela a pu causer quelques effets de bord indésirables que tu peux avoir également via l’application par GPO : la session est bien déconnectée, mais il y a quelque chose qui tourne vraiment (un script à exécution longue par exemple).
Afin d’éviter cela, il faut impérativement informer les équipes d’admin (les seuls qui se connectent en RDP sur les serveurs) et leur fournir un moyen de contournement pour ce type de cas (par exemple exécuter les longs scripts en tant que tâche planifiée). Faute de faire ceci, cela risque d’entrainer quelques soucis d’ordre humain au sein des équipes.
Pour les postes, il n’y a pas de pb. Généralement, les utilisateurs n’ont pas les privilèges suffisants pour faire du RDP sur ceux-ci.
A noter que pour les serveurs de session RDS (les Remote Desktop Session Host), cela se règle directement dans la console d’admin RDS.