Article technique : Terminal Server
Un article sur les diverses raisons qui font qu’un serveur TS ne redémarre pas après une mise à jour. Auteur : Philippe Dieulafait de l'équipe Support Windows (Core), Microsoft France Problématique Traitée :Il arrive qu’un serveur paraisse figé suite au redémarrage consécutif à l’installation d’un « hotfix » ou d’un « patch » de sécurité. Le plus souvent, les mises à jour ont été installées par un administrateur se connectant au serveur via une session RDP (Remote Desktop) sans utiliser les paramètres /console ou /admin et en utilisant soit « Windows update web site » soit « Automatique Update » pour la mise à jour des patches. Les deux méthodes pour les mises à jour font la même chose et utilisent le même processus. Lorsque la ou les mises à jour sont terminées, l’administrateur est invité à redémarrer le serveur en cliquant sur « Redémarrer maintenant » pour terminer l’installation. La session Remote Desktop se termine et l’administrateur pense que le serveur est en cours de redémarrage. Toutefois le problème est que le serveur n’est pas en train de redémarrer le système. Lorsque l’administrateur, au bout d’un certain temps (pensant que le système est de nouveau disponible) essaie de se reconnecter au serveur via Remote Desktop, il constate que cela ne fonctionne pas. Il se connecte directement sur la console du serveur et s’assure que le RDP listener est bien à l’écoute sur le port 3389, toutefois personne ne peut s’y connecter via RDP. Pour résoudre ce problème, il doit à partir de la console redémarrer le serveur. La question serait donc pourquoi, dans ce cas, je dois redémarrer le serveur une nouvelle fois pour me connecter en RDP ? Explications :La première chose à faire est de consulter les journaux de logs concernant les mises à jour qui se trouvent dans le répertoire %SYSTEMROOT%. Vous en trouverez plusieurs concernant les différents patches installés.
Lorsque vous ouvrez un de ces fichiers, vous pouvez savoir, entre autres :
Si des erreurs se sont produites, dans notre scénario, est crucial. L'un des messages les plus courants dans ce scénario est le suivant :
Le problème le plus probable ici est qu'il y a une variable globale pour Terminal Services qui a été fixée en amont. Cette limite a été fixée au début du processus d'arrêt. Puisque nous ne sommes pas dans une session console, nous ne pouvons pas répondre à d’éventuelles demandes d’autres processus si nous sommes d’accord pour qu’ils soient fermés, en opposition à la possibilité de forcer la fermeture d’un processus. Si un processus ne permet pas le redémarrage alors le redémarrage du système est annulé. Nous avons vu dans notre cas que l’acceptation de la demande de redémarrage a provoqué la fin de la session RDP, mais le système n’a pas redémarré ! Nous nous retrouvons dans une situation où notre système est dans un état « intermédiaire ». Le processus Terminal Services a redémarré le RDP listener sur le port 3389 mais depuis la variable globale a été fixée et toute tentative de se connecter à RDP est infructueuse ! Remarquez qu’un redémarrage du système réinitialise l’ensemble et tout apparaît de nouveau normal une fois de plus. Solutions :Il y a deux façons de remédier à cela :
Une autre possibilité :Si vous rencontrez ce phénomène aléatoire sans avoir apporté de modification à votre serveur (Update ou autre …), il se peut que votre problème soit dû au fait qu’aléatoirement le service TermService démarre avant que TermDD soit démarré. Cela explique le fait que le port 3389 soit bien à l’écoute mais que vous ne puissiez pas vous y connecter via Mstsc. Afin de résoudre ce problème, vous pouvez tester cette action :
Fig.1
Ressource complémentaire : |
.jpg)
.jpg)
.jpg)
.jpg)