Powershell DSC: Troubleshooting et Debugging

Comme tout programme, il est nécessaire d’avoir quelques bases en Powershell DSC pour des séances de debugging et régler d’éventuels problèmes dans ses scripts, ou en tout cas comprendre le cheminement des configurations et savoir détecter si elles ne peuvent pas s’appliquer et pourquoi.

La première chose à faire pour vérifier une configuration c’est de la visualiser avec Get-DSCConfiguration. Si elle n’a pas pu s’appliquer, on verra une erreur de type : Get-DscConfiguration : Current configuration does not exist.

ConfigNotFound

Attention, on peut aussi voir une ancienne configuration établie, et la nouvelle n’est pas visible car elle ne peut s’appliquer.

Lorsque on voit ce cas, on doit regarder l’état du Local Configuration Manager avec la commande: Get-DscLocalConfigurationManager:

LCMPendingState

 

Et ici on voit une chose importante, l’état du LCM (LCMState) est en PendingConfiguration. Ça veut dire que le LCM est en attente d’une configuration et que celle-ci à du mal à s’appliquer.

 

Les valeurs de LCMState sont les suivantes (j’en ai vu 3, peut-être qu’il y en a d’autres):

  • Idle: Le LCM ne fait rien, il attend
  • Busy: Le LCM est en train d’appliquer une configuration.
  • PendingState: Le LCM est bloqué, il sait qu’une configuration est disponible, soit il attend la période de refresh, soit il ne peut pas l’appliquer à cause d’une erreur dans la configuration.

Direction, l’Event Log.

Le log qu’on veut voir se trouve dans:

  • Applications and Services Logs
    • Microsoft
      • Windows
        • Desired State Configuration
          • Operational

EventLogError

 

Et là on voit qu’une ressource de type script appelé TestPorts a un problème. TestPorts est le nom de la ressource Script que j’ai écrit, donc ça me parle, la voici:

Le message d’erreur est : Exception calling « Connect » with « 2 » argument(s): « Cannot access a disposed object.
Object name: ‘System.Net.Sockets.TcpClient’. »

Ça veut dire que j’utilise un objet mal initialisé. La command $socket.close() rend mon objet $socket non-disponible pour une nouvelle connexion.

Je vais modifier mon script pour qu’il n’utilise qu’une seule instance de System.Net.Sockets.TcpClient à chaque fois:

Après avoir réappliqué ma configuration, je vérifie le LCM avec la commande Get-DscConfigurationManager:

LCMIdle

Et on voit que le LCM est passé en mode Idle. Il a du appliquer la configuration, allons vérifier avec Get-DscConfiguration

configOKLa configuration est bien présente, et on voit qu’elle se base sur quatre ressources, dont deux de registre et deux de script.

Tout ça nous montre deux choses intéressantes:

  1. L’automatisation est fantastique, elle nous permet de gérer des centaines voire des milliers de machines comme s’il y en avait qu’une seule. Lorsque je déploie une configuration, je sais que toutes ces machines l’appliqueront et seront exactement les mêmes. Ça veut dire aussi que si je fais une erreur, je peux mettre en carafe toutes ces machines d’un coup. DSC n’est pas le seul à induire un tel risque, les applications telles que SCCM ou Altiris ou même des GPO peuvent avoir les mêmes conséquences.
    Donc il faut un processus de mise en production en béton. Il faut un environnement de Développement et d’Intégration le plus proche de la Production que possible. Voire même un environnement de Pré-Prod, qui sera le dernier rempart de test. Il faudra aussi des processus de test pour valider les configurations avant de les mettre en production.
  2. Les scripts de génération de configurations sont des programmes, et ces programmes ont un cycle de vie, ils peuvent évoluer, des variantes peuvent être créées. Les admins qui utiliseront Powershell DSC doivent se familiariser avec des logiciels de gestion de version tels que SVN ou GIT. Ainsi on pourra développer et distribuer des configurations tout en étant capables de revenir en arrière si besoin.

L’erreur no Runspace available

Lors de l’installation d’un serveur pull sur une nouvelle machine Windows 2012 R2, nous avons eu l’erreur suivante lorsque nous exécutons Get-DscConfiguration:

 

Nous avions pensé tout d’abord à un problème de certificat, car ce problème ne se produit que si nous configurons le PULL serveur avec HTTPS.

La solution à ce problème est de s’assurer que le hotfix KB3000850 est bien installé. On voit tout de suite si ce hotfix n’est pas installé car lors de l’exécution de Get-DscLocalConfigurationManager montre qu’il manque des informations relatives au LCM (LCMstate, LCMCompatibleVersions, LCMVersion).

Faire Get-Hotfix KB3000850 et voir si le KB est bien installé.

Ce KB3000850 en requiert d’autres, avec quelques essais j’ai trouvé que les KB nécéssaires au minimum sont les suivants (avoir une machine complètement à jour est bien mieux bien sur) :

Mise à jour Lien
KB2883200 https://www.microsoft.com/en-us/download/details.aspx?id=40774
KB2884846 https://www.microsoft.com/en-us/download/details.aspx?id=40771
KB2919442 https://www.microsoft.com/en-us/download/details.aspx?id=42153
KB2938439 https://www.microsoft.com/en-us/download/details.aspx?id=42334
KB2954879 https://www.microsoft.com/en-us/download/details.aspx?id=42380
KB2919355 https://www.microsoft.com/en-us/download/details.aspx?id=42334
KB3000850 https://www.microsoft.com/en-us/download/details.aspx?id=44975