Archives mensuelles : août 2013

Ne présumez pas de la version de Powershell avec Orchestrator

Note importante : je regarde des épisodes de Docteur Who en écrivant cet article, ce n’est pas sans conséquence.

Depuis quelques temps, Orchestrator est devenue ma grande passion pour tout industrialiser (le tout en Remote Powershell et des workflow pour faire bonne mesure). Dans un de mes développements en cours, j’avais un chalenge simple sur lequel je ne comptais pas passer plus de 10 minutes : Redémarrer un serveur à distance et attendre que celui-ci rendre la main en Powershell que je puisse exécuter la suite de mon Runbook.

La première réponse bête aurait été d’utiliser l’activité “Restart System” proposé en standard. Manque de bol, l’activité ne prose pas d’attendre que le système soit de nouveau opérationnel pour poursuivre. Qu’à cela ne tienne, on peut Exécuter du Powershell dans Orchestrator. Ni une ni deux, recherche rapide dans l’aide :

SCORCH0

 

A première vue, rien de bien sorcier. 10 minutes, j’ai même le temps d’aller chercher un café. Par sécurité on va quand même tester. Ci-dessous la commande redémarrage exécutée depuis mon serveur Orchestrator :

SCORCH1

 

je vois bien mon serveur redémarrer. On passe tout cela dans un Runbook Orchestrator avec des beaux paramètres passés en entée et la création d’un PSCredential pour s’authentifier et cela donne cela :

SCORCH2

Ben finalement, il va attendre mon café, il va même finir froid. A l’exécution du Runbook, je découvre qu’il y a eu une erreur lors de l’exécution du script Powershell :

SCORCH3

 

Par reflexe, j’active toujours les logs dans mes Runbook, donc réflexe, je parse les logs et oh surprise :

SCORCH4

 

il m’est indiqué que la syntaxe de ma commande Restart-Computer est invalide. Pourtant, exécutée dans une console Powershell sur le même serveur elle fonctionne. A ce stade, je pars me refaire un café, je pressens que ça va être plus long que prévu. Une rapide analyse de la situation s’impose :

  1. Read The Fucking Manual : J’ai commencé par ça, l’aide de Powershell me dit que j’ai la bonne syntaxe
  2. Bug interface homme machine : Ben non j’ai testé ma commande, elle fonctionne. En plus, c’est du Copier/Coller.
  3. Code erreur 40 : Voir 1 & 2 et celui qui est à 40cm commence à s’énerver, son café est encore froid
  4. Redémarrer : Essayé, non plus
  5. Désinstaller la beta de Powershell v4/v5/v6 : Même pas installée (le niveau geek baisse grave avec l’âge)
  6. Créer un nouveau Runbook : Aussi essayé, aucun résultat. En plus, on peut pas dire que le mien soit d’une complexité qui puisse dépasser les capacités d’Orchestrator
  7. Appeler David tenant ou (autre David ça marche aussi)?

 

Docteur à l’aide!

Bien évidemment le docteur n’a pas répondu, il est trop occupé à voyager dans le TARDIS. Après avoir épuiser les solutions logiques, je fini par me rendre compte que ce que me dit Orchestrator, c’est qu’il ne reconnait pas les paramètres de ma commande “restart-Computer”. Pourtant, l’aide de la commande m’indique bien que les paramètres sont documentés, la commande à même fonctionné.

Pourtant j’ai un doute. Et si Orchestrator n’utilisait pas la version 3.0 de Powershell mais une version antérieure? Un moyen très rapide de vérifier cette théorie :  Créer un Runbook qui exécute un script Powershell qui me retourne le contenu de l’expression suivante : “($psversiontable).psversion”. Plus simple comme script tu meurt!

SCORCH5

Y a plus de doute possible. Le Runbook Orchestrator rend son verdict. C’est du PowerShell 2.0. C’est donc normal que des commandes dépendantes de Powershell 3.0 ne fonctionnent pas.

SCORCH6

 

Docteur passez moi votre tournevis sonique

De mémoire, il est effectivement possible d’appeler Powershell en spécifiant la version qu’on désire utiliser. Un bon développeur Powershell doit même s’assurer de la version Powershell disponible avant de commencer (Mérite sa claque derrière la tête sur le coup).

SNAGHTML20fe91b1

 

Le problème est maintenant identifié, reste plus qu’à le corriger avec un coup de tournevis sonique du Docteur. Légère correction du Runbook pour créer une nouvelle instance de Powershell pour exécuter ma commande. Si on ne précise pas la version, il utilise automatiquement la version la plus élevée disponible.

SCORCH7

Cette fois, c’est bien une version 3.0 de Powershell qui est utilisée.

SCORCH8

faut fêter cela. Café! Et nouvel épisode de docteur WHO

 

Donc entre les lignes, ce qu’il faut comprendre, c’est qu’Orchestrator 2012 SP1 exécute nos scripts en Powershell v2 en douce, même si la version 3.0 est disponible. C’est moche. Mais, il y a une explication : By Design.

image

 

Conclusions

  • Ne présumez jamais de la version de Powershell, surtout lorsque vous développer avec des Invoke-command. On sait jamais, peut y avoir un Windows 2008 dans la liste des serveurs passés en paramètres
  • Imposez une version minimale de Powershell, sinon, c’est un cauchemar à gérer
  • Avec le Read The Fucking Manual, ne pas oublier le Read The Fucking Blogs
  • Le docteur ne répond pas, il est trop occupé
  • le café froid, c’est pas bon

 

Docteur, je vous rend votre tournevis sonique.

 

BenoîtS – Simple and Secure by Design but Doctor WHO addict

Réfléchissez bien avant de customiser SCSM dans tous les sens

Suite à ma série d’article « A la surface d’un service dans SCSM », je me suis rendu compte d’un dysfonctionnement de ma plateforme. J’ai constaté que les machines virtuelles déployées depuis mon portail SCCM n’apparaissaient pas dans les objets importés dans SCSM. Première analyse, y a un truc qui cloque avec le connecteur AD. A voir l’état du connecteur « AD », je suis sur la bonne piste.

clip_image002

On est donc sur la piste d’un problème SCSM, pas la peine d’aller chercher plus loin. Plongeons dans les logs de SCSM. Aussi étrange que cela puisse paraitre, on trouvera les informations concernant les SCSM dans le journal « Operation Manager ». Histoire d’aller à l’essentiel, j’ai filtré sur les évènements en provenance de la source « Data Connectors » :

clip_image004

C’est une erreur relative au connecteur « AD ». Allons voir cela de plus près.

clip_image006

La maintenant cela me parle. Le connecteur n’a pas de problème pour se connecter auprès de l’annuaire Active Directory et récupérer les données mais pour les intégrer à la CMDB. Ce qui pose problème, c’est mon extension de classe « MyWindowsComputer » et plus précisément mon attribut « ISATAPEnabledService ». Ce qui est reproché à cet attribut, c’est l’impossibilité de lui définir une valeur lors de la création des nouveaux objets en provenance de l’AD dans la CMDB.

Maintenant qu’on a la cause, allons corriger le problème dans la console SCSM Authoring Tool.

clip_image008

La correction consiste à désactiver l’exigence d’avoir une valeur pour l’attribut « ISATAPEnabledService ».  Une fois le Management Pack sauvegardé, il ne reste plus qu’à l’importer dans SCSM.

image

 

Et oh magie, le connecteur SCSM se synchronise de nouveau.

image

 

Tout ça pour rappeler quelques règles sur les extensions de classes par défaut :

  • Attention à bien documenter vos Management Pack pour savoir ce qui a été fait et quand
  • Conservez des précédentes versions de vos Management pack
  • N’exigez pas de valeur pour un attribut qui n’existe pas à la source
  • Ne supprimez pas le connecteur pour le recréer ensuite, c’est l’erreur la plus bête

Ces quelques conseils devraient vous aider à ne pas faire la même erreur que moi.

 

BenoîtS – Simple and Secure by design but Business compliant