Forte activité CPU dans le processus SVCHOST hébergeant le service WinRM sur un controleur de domaine

Dans ce post, je vais documenter un problème que j'ai rencontré de nombreuses fois avec des clients . Ce problème très facilement évitable peut avoir des conséquences sur les performances de vos DCs.

Description du problème:

Sur un DC, vous constatez une forte activité CPU dans le processus SVCHOST hébergeant le service WinRM (Windows Remote Management). Lorsque le problème survient, la seule solution est de redémarrer le DC. Sur des DCs ayant peu de CPUs alloués (1 ou 2 ), ce problème peut empêcher les requêtes clientes  liées à Active Directory de s'exécuter dans un délai acceptable.

Cause:

Lors d'une tentative de connection sur un serveur  via WinRM (exemples: session powershell distante, utilisation du server manager, accès à WMI via WinRM, "Event Forwarding",...), WinRM va vérifier si l'utilisateur appartient au groupe WinRMRemoteWMIusers__ .  Un appel est alors fait par le service WinRM pour vérifier l'existence de ce groupe.

Ce groupe a été introduit dans la version 3 du "Windows Management Framework". Il est créé automatiquement à l'installation d'un serveur. Si le serveur est promu "Contrôleur de domaine" dans un nouveau domaine, alors le groupe sera "transféré" dans le domaine.  Si le serveur est intégré dans un domaine existant créé par la promotion d'un serveur avec une version inférieure du Windows Management Framework, alors le groupe WinRMRemoteWMIusers__  n'existera pas dans "Active Directory". La résolution de ce nom ne pourra se faire sur le DC et nécessitera des accès réseaux (vers les autres domaines).

Si lors de cette résolution, une autre demande de connection arrive, celle-ci est bloquée en attente d'un  "spinlock détenu" par la requête précédente. Malheureusement l'attente sur un spinlock est une attente active qui consomme du CPU. Sur des DCs avec peu de processeurs, cette attente ralentit la résolution initiale (il y a compétition entre plusieurs threads pour obtenir le processeur!) .

Si d’autres demandes de connexion WinRM arrivent, les threads créés pour satisfaire ces demandes vont également rentrer en compétition pour obtenir ce « spinlock ». Ces nouvelles demandes vont ainsi accroire la charge CPU. Tous ces threads (traitant les demandes de connexion) vont rentrer en compétition pour obtenir le CPU et vont empêcher la requête initiale de résolution du groupe WinRemoteUsers__  de se terminer. Les autres tâches du système seront également fortement impactées. Le serveur peut ainsi rapidement devenir inutilisable .

Moralité:

Pro-activement, vérifiez l'existence du groupe WinRMRemoteWMIusers__  dans chaque domaine et créez le si nécessaire (il n'a aucun membre par défaut)!

Référence:    https://support.microsoft.com/en-us/kb/3118385 (Svchost.exe uses excessive CPU resources on a single-core Windows Server 2012 domain controller).

 Remarque: Mes dossiers concernaient des serveurs Windows 2012 R2. Sur un serveur Windows 2016, le groupe n'est plus créé à l'installation mais dans le code la vérification est toujours présente! Donc continuez à appliquer ce conseil.

Comments

• Anonymous
  January 11, 2017
  très interressant! Merci !