Certains contextes peuvent nécessiter l’utilisation de cmdlet SCOM depuis un ordinateur ne permettant pas l’installation de la console, et donc ne permettant pas d’exécuter ces cmdlet localement ; par exemple en cas de centralisation des scripts de l’entreprise sur un serveur Windows 2003.
Dans ce cas, une des solutions les plus évidentes est le recours aux Remote Sessions Powershell : les cmdlet sont bien appelés par le serveur ne bénéficiant pas de la console SCOM, mais ils sont en réalité exécutés par un serveur où elle est cette fois installée.
Le but de ce billet n’est pas de détailler ce fonctionnement, qui n’a d’ailleurs rien de spécifique à SCOM ; mais ce dernier peut par contre être responsable de certains dysfonctionnements des Remote Sessions.
C’est notamment le cas lors de l’exécution de scripts nécessitant des traitements coûteux en mémoire, qui peuvent provoquer l’erreur suivante :
Processing data for a remote command failed with the following error message: The WSMan provider host process did not return a proper response. A provider in the host process may have behaved improperly. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OperationStopped: (System.Manageme…pressionSyncJob:PSInvokeExpressionSyncJob) [], PSRemotingTransportException
+ FullyQualifiedErrorId : JobFailure
Ce message, assez peu explicite, indique en réalité que la session powershell distante utilise trop de mémoire par rapport à ce qui est alloué : en effet, cette allocation est limitée par défaut à 150Mo, comme le confirme le Powershell suivant (à exécuter sur le serveur où se trouve la console SCOM) :
winrm get winrm/config
En partant de ce constant, deux solutions s’offrent à nous : optimiser le script pour qu’il utilise moins de mémoire, ou augmenter la mémoire allouée à chaque Remote Session Powershell.
Libre à vous de choisir la quantité de mémoire allouée qui vous semblera en adéquation avec les besoins de votre script, en gardant en tête qu’une valeur excessive peut entraîner la saturation du serveur et compromettre sa stabilité.
winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"1024`"`}
Le problème devrait désormais être corrigé.