A la surface d’un service dans System Center Service Manager (2/4)

Après une approche très en surface des choses, passons sous la surface et commençons par ce qu’il y a de plus simple, à savoir développer le Runbook qui assurera la mise en place du service ISATAP sur le système sélectionné. Dans Orchestrator, voilà à quoi ressemble notre Runbook.

clip_image002

Chaque icône représente une activité au sein du Runbook. Ces activités sont reliées entre elles par des liaisons. On comprend qu’à la sortie de l’activité « Remote », on peut avoir un « succès » ou un « échec ». J’ai volontairement isolé le service dans un Runbook dédié. Il y aura un autre Runbook qui sera chargé de l’interaction avec System Center Service manager. Attaquons par le début avec l’activité « Initialize data ». Dans celle-ci on va référencer les deux paramètres attendus par notre Runbook :

  • Le nom pleinement qualifié du système qui doit être configuré (via Remote Management)
  • Le nom du routeur ISATAP qui devra être référencé (FQDN)

clip_image004

C’est l’activité « Remote » qui va nous occuper dans ce billet. On comprend tout de suite qu’elle va exécuter du code « Powershell ».

clip_image006

On voit tout de suite que manipuler du code Powershell dans une fenêtre d’édition aussi petite va être un chalenge. Autant dire tout de suite que les longues commandes avec enchainement de « pipes » et arguments à gogo sont à proscrire pour la lisibilité du code.

Ce qui interpelle en premier lieu, c’est la mise en page de certains éléments. Sur la première ligne on constate la présence de “{ComputerFQDN from « Initialize Data »}” Cela fait tout simplement référence au premier paramètre récupéré de l’activité précédente « Initialize data ». Pour la seconde, c’est tout simplement le second paramètre correspondant au nom pleinement qualifié de mon routeur ISATAP. Jusque-là je n’ai perdu personne.

C’est à la troisième ligne que cela se corse. Pour mon service, je dois configurer un système à distance (Powershell remoting), ce qui implique de disposer d’un contexte d’exécution. Il aurait été très simple de conserver le contexte d’exécution standard mais, je voulais pouvoir adapter mon contexte en fonction de mon environnement (mon service se doit d’être évolutif quand même). Qui sait, peut-être que demain, mon service devra fonctionner dans un cloud communautaire, qui sait?

Pour cela, j’ai créé les variables « ACTIONACCOUNT » et « ACTIONPASSWORD » pour stocker les comptes et mots de passe.

clip_image008

Avantage de cette approche, le mot de passe est stocké de manière cryptée dans la base SQL d’Orchestrator. Cette troisième ligne génère donc un objet de type « System.Security.SecureString » que nous allons utiliser sur la ligne suivante. La syntaxe complète de la ligne est :

$ServicePassword = ConvertTo-Securestring –String “mot de passe” -asPlaintext – Force

Jusque-là, on reste dans du Powershell tout à fait basique, on est toujours dans le « Simple by Design ». La quatrième ligne va permettre d’assembler le compte et le mot de passe en une identité. Nous allons créer un objet de type « System.Management.Automation.PSCredential en combinant les deux paramètres.

Pour la cinquième ligne, on est toujours dans du classique, à savoir la création d’un objet de type « PSSession » pour joindre notre système à configurer. Par sécurité, on va faire cela en SSL.

Si l’objet « $ServerSession » n’est pas « null », c’est que la connexion a été établie. Il ne reste donc plus qu’à réaliser la configuration du client ISATAP à l’aide de la commande « Invoke-Command » auquel on associe un ensemble de commandes regroupées dans un « ScriptBlock ». Mon « ScriptBlock » utilise un paramètre extérieur, à savoir le nom pleinement qualifié du routeur ISATAP. Afin de rester dans les choses basiques, j’ai considéré qu’à ce stade, tout s’est bien passé, qu’on ne gère pas les erreurs à ce niveau. Un puriste aurait :

  • Traité l’éventuel code erreur retourné par la commande « Invoke-Command »
  • Généré un incident dans SCSM en cas d’erreur et l’aurait assigné à un groupe de support
  • Généré des codes retours différents selon la nature de l’erreur

Oui, mais pour ma démonstration, cela ne tenait pas dans l’interface. De plus, le Runbook Orchestrator qui pique les yeux, ce n’est pas encore celui-là.

Si tout se passe bien, on l’indique dans la variable « $Result ». Cette variable est particulière car elle est référencée dans la section « Published data » de l’activité « Remote ». C’est cette information que nous allons exploiter dans l’activité suivante.

clip_image010

La dernière activité est destinée à reporter le code retour de notre runbook au Runbook appelant (nous allons jouer aux poupées russes). Notre Runbook retourne une variable nommée « Result ».

clip_image012

Voilà pour le plus simple des deux Runbook. Pour le suivant, un billet lui sera intégralement dédié. En plus, il y aura de quoi faire car on va jouer avec les activités de SCSM cette fois. Faites des provisions d’aspirine et de mouchoirs car celui-là :

clip_image014

Mais pourquoi tant de haine dit-il face à son PC? Spéciale dédicace à Laurent, William et Jérôme pour m’avoir ouvert les portes de cet univers.

 

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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.