Archives de catégorie : SCSM 2012 SP1

Le POC SCSM en prod, pas glop comme idée

Faire un POC en prod, voila une fausse bonne idée. On se dit qu’avec la version d’évaluation et ses 180 jours, on a tout le temps. Si le POC se transforme en production, faudra juste saisir le numéro de licence. Mais que se passe t’il si on dépasse la période d’évaluation avec SCSM?

Coté console SCSM, c’est pas très parlant.

0

 

Même la vue avancée ne nous avance pas plus “Unknow exception”.

1

 

La il faut parcourir le log “Operation Manager” pour découvrir la raison :

2

 

Cela semble clair. Petite recherche rapide chez Microsoft et on trouve l’information ci-dessous :

image

 

Conclusion, le POC en prod pour SCSM, est une véritable fausse bonne idée. Paie ta licence.

 

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

SCSM 2012 support des solution accelerators

Avec SCSM 2012, Microsoft avait mis à disposition un certain nombre de solution accelerators pour répondre à des scénarios d’usage bien particuliers de SCSM :

 

Cependant, le temps passe vite, très vite. Avec l’arrivée de la génération R2 de la gamme System Center et celle de Windows Azure Pack, beaucoup d’entre nous se sont posés des question sur la roadmap et le support de ces solutions. L’équipe produit SCSM vient de donner la réponse sur son blog.

image

 

En même temps, ce n’est pas une surprise pour le CSSP. Avec l’arrivée de Windows Azure Pack, on voyait mal comment les deux solutions pouvaient cohabiter. De plus, si on compare les deux solutions, le services de machines virtuelles disponible dans le Windows Azure Pack est bien plus riche que son ancêtre.

 

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

Service Manager 2012 et SharePoint 2010, peut mieux faire

Pour ceux qui ont mis en œuvre Service Manager 2012, on est toujours surpris de devoir installer SharePoint 2010 sur une plateforme Windows 2008 R2. Avec SCSM 2012 R2, la situation n’avait pas évoluée. Récemment le Service Pack 2 de SharePoint 2012 autorisait l’installation sur les plateformes Windows 2012/ 2012 R2. Heureusement, la situation vient de changer.

image

 

Prochaine étape SharePoint 2013?

 

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

Un portail SCSM alternatif

Avec l’arrivée de Windows Azure Pack, on peut dire que le portail SCSM a pris un coup de vieux. Ca fait quelques temps que même Microsoft Azure a abandonné Silverlight pour une interface plus au gout du jour. C’est le problème de la majorité des solutions d’ITSM. C’est conçu pour les IT donc l’esthétique n’est pas le premier critère . Par contre, le premier utilisateur c’est bien l’utilisateur final.

 

En lisant le billet Windows Azure Pack: GridPro – Installation and Overview, j’y ait vu une solution “temporaire”. GridPro est une extension proposée depuis le portail WAP. Autant dire tout de suite que ça a un autre look maintenant :

View1

C’est une approche intéressante car on peut utiliser le portail WAP comme nouveau portail pour une infrastructure Service Manager existante et les services qu’elle propose. L’intéressant, c’est qu’on peut rapidement tester presque toutes les fonctionnalités avec la version gratuite.

Comparaison

 

Je dis bien que c’est une solution “temporaire” car il y a bien des domaines dans lesquels le portail SCSM reste loin devant. Rien que l’aspect multi-langue, ça pèse lourd.

 

Voila une alternative intéressante à mettre en face des produits de substitution tels que ceux proposés par Cireson qui sont fortement intégrés à SCSM.

 

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

Update Rollup 4 for System Center 2012 Service Pack 1

J’ai un peu de retard mais le Rollup 4 pour la gamme System Center 2012 SP1 est sorti la semaine dernière. Cela concerne donc tous les produits de la gamme System center 2012. Avant de se lancer dans l’installation, attention à bien lire les remarques de la KB. C’est pas toujours aussi simple pour tous les produits (SCVMM) ainsi que l’ordre d’installation.

 

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

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

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

Vous pensez que nous avons fait le plus dur. C’est presque vrai. Nous sommes encore à 60 mètres sous la surface, il faut remonter mais dans SCSM cette fois. Les paliers seront les suivants :

  • Synchronisation du connecteur Orchestrator
  • Création des Runbook templates
  • Création des Services Request
  • Création des Request Offering
  • Création du service Offering

A la fin, pensez à recommencer à respirer, on sera enfin de retour à la surface d’un service.

 

Palier synchronisation du connecteurs Orchestrator

SCSM s’articule autour d’une CMDB (Configuration Management Database), il raisonne donc par rapport aux données dont il a connaissance, que celles-ci soient générés au sein de la solution ou importées au travers de connecteurs. Dans le cas qui nous occupe, nous allons avoir des besoins de données en provenance de deux sources :

  • Orchestrator : pour récupérer les informations relatives aux runbook que nous allons utiliser
  • Active Directory : pour récupérer les comptes ordinateurs pour lesquels le service sera proposé et le groupe de sécurité que nous allons utiliser.

 

Commençons avec un peu de Powershell (on va pas changer les bonnes habitudes) pour identifier les connecteurs. Celui qui m’intéresse, c’est Orchestrator. Avoir des Runbook, c’est bien, les voir dans SCSM, c’est mieux. Pour cela il faut forcer le connecteur SCSM à interroger le Web Service d’orchestrator pour extraire les informations et références mes nouveaux Runbooks.

clip_image002

Si tout se passe bien et qu’on a pas oublié qu’il faut que les Runbook soit bien en état « Checkin », on les retrouve dans la console SCSM.

clip_image004

Justement, allons voir à quoi ressemble mon objet Runbook dans SCSM. Visiblement, il a compris qu’il y avait un paramètre nommé « ActivityID » en entrée et qu’il ne retournait aucune information.

clip_image006

A ce stade, cela devient intéressant car on découvre de nouveaux objets SCSM : « Runbook Activity template » et « Request Offering». Pas si vite, on a encore pas mal de temps à passer au palier.

clip_image008

Palier Runbook templates

Nous avons des Runbook, très bien, il nous faut maintenant pouvoir les utiliser dans des activités. On va donc créer des objets « Runbook Automation Activity » pour chaque objet « Runbook ».

clip_image010

Lorsqu’on regarde de plus près, on constate que c’est bien un objet « Runbook Automation Activity » et que nous allons le stocker dans le « Management Pack ».

clip_image012

Premier élément essentiel, un Runbook doit être référencé comme une activité bien particulière. Pour cela, la case d’option « Is ready for Automation » doit être cochée.

clip_image014

Dans mon billet précédent, mon Runbook faisait référence à un paramètre nommé « ActivityID ». Maintenant, on sait d’où cela vient. Plus tard, lorsque ce template sera utilisé par le « Request template », l’objet « Runbook Automation Activity » va juste passer son identifiant d’objet SCSM comme paramètre.

clip_image016

Concrètement, allons voir ce que cela donne sur un objet « Runbook Automation Activity » qui a déjà exécuté un Runbook. On constate tout de suite que le paramètre ActivityID est bien renseigné.

clip_image018

En allant faire un tour dans l’onglet « Configuration Items », on va même trouver le serveur qui a été passé en paramètre. C’est l’objet « Windows Server » que nous avons utilisé dans le Runbook.

clip_image020

Même principe pour le « Business Service ».

clip_image022

Revenons dans notre « Runbook Activity Template ». On retrouve bien le « Business Service » que j’ai indiqué mais aucune trace de l’objet « Windows Server » passé en paramètre. On verra plus tard que le paramètre est injecté lors de l’exécution. Ce serait trop facile après tout.

clip_image024

Palier Service request

Notre « Runbook Automation Activity », il faut l’utiliser dans une séquence d’activités. Dans notre cas, la séquence, ce n’est qu’une seule activité. J’ai donc une « Service request » pour activer mon service et une seconde pour le désactiver.

clip_image026

Allons-y, créons notre « Service request ».

clip_image028

Notre service présente un certain nombre de caractéristiques tout à fait classique. Ce qui va nous intéresser, c’est son onglet « Activity ».

clip_image030

Celui-ci référence l’activité que nous allons exécuter. Pour simplifier les choses, je n’ai volontairement référencé qu’une seule activité. Il aurait tout à fait été possible d’ajouter une activité de validation avec des conditions. Restons simples.

clip_image032

Nous venons de sélectionner le « Runbook Automation Activity ». On a une base de travail, il faut passer à l’interface graphique. Ce sera l’objet de la « request Offering ».

 

Palier Request Offering

On se rapproche de la surface mais on n’y est pas encore. On a un nouveau palier pendant lequel on va s’attarder sur la notion de « Request Offefing ». C’est la demande de service qui sera publié dans le portail SCSM. C’est ce qu’on voit dans la rubrique « List View ».

clip_image034

On peut donc en déduire que c’est la liste des services proposés aux utilisateurs sans distinction. Dans mon cas, j’ai donc deux « Request Offering » :

  • Enable ISATAP Service (V3)
  • Disable ISATAP Service (V3)

Une Service « request offering » fait office d’interface graphique. On spécifie le « Request template » que l’on veut utiliser, quels paramètres sont attendus en entrée et comment on les passe au « Request template ». Dans le cas qui nous occupe, mon runbook a besoin d’un seul paramètre : l’ordinateur sur lequel on désire utiliser le service. Pour la création d’une « Request Offering », c’est par là que cela se passe :

clip_image036

Déjà on distingue deux grandes catégories « Draft » et « Published ». C’est intéressant car cela permet d’introduire la gestion des changements. L’assistant rappelle les deux grands usages, on passe, ce n’est pas là qu’on va passer notre palier.

clip_image037

La première caractéristique de ma « Request « Offering », c’est d’avoir un nom, une description et un « Request Template » qu’on va passer en lui indiquant des paramètres.

clip_image038

Justement, passons un peu de temps sur le paramètre attendu. Du point de vue de l’interface graphique, on demande à l’utilisateur de désigner un objet ordinateur. Le paramètre est indiqué comme obligatoire. Dans mon cas, je voulais que l’interface graphique affiche une liste de serveurs. C’est donc un « Query Result ».

clip_image039

Voilà pour l’interface. Maintenant, il faut l’alimenter. Plus précisément fournir une requête pour alimenter le « Query result » pour notre paramètre en entrée. Allons y et cliquons sur « Configure ».

clip_image040

C’est là qu’on reparle de la CMDB. Je veux afficher la liste des serveurs. La classe d’objets se rapprochant le plus de cela c’est « Windows Server ». Maintenant, faut affiner la requête aussi bien en termes de sélection que d’attributs retournés.

clip_image042

Ça se passe dans le second onglet avec le critère de filtrage. Je veux pouvoir afficher la liste des serveurs pour lesquels le service n’est pas encore activé. Si on se souvient du précédent post, après que le service ait été activé, j’actualisais un attribut de la classe Windows Server. Donc, si le service n’est pas encore activé, la valeur de cet attribut est censée être à « False ».

clip_image044

Note : A ceux qui se demandent à quoi sert le « Set Token », c’est pour exploiter l’identité de l’utilisateur connecté au portail. C’est très utile pour filtrer les machines virtuelles de SCVMM en fonction sur le critère du propriétaire.

Maintenant qu’on a identifié le sous-ensemble qui nous intéresse, il faut alimenter le « Query Result » avec de la matière pour l’affichage, c’est le troisième onglet.

clip_image046

Résolvons maintenant un grand mystère. Comment un ordinateur sélectionné dans le portail fini comme paramètre d’un Runbook.

clip_image048

Donc, on peut positionner l’objet sélectionné par l’utilisateur (ou les objets, après, c’est une question de traitement dans le Runbook Orchestrator) comme paramètre de la « Service Request ». Tout de suite, on ne comprend pas l’intérêt. Allons en voir une.

En première page d’une « Service Request », on peut retrouver les paramètres renseignés par l’utilisateur. Sauf que ce n’est pas parlant. On sait qu’on a un objet en paramètre, son GUID et son displayname. Pour l’équipe qui va gérer les incidents, c’est pas réellement exploitable.

clip_image050

Par contre indiquer que l’objet passé en paramètre est en relation avec la « request Offering», c’est tout de suite plus compréhensible. Si un incident survient lors du déroulement de la « request Offering », on sait tout de suite quels objets en relation sont concernés.

clip_image052

Si vous vous souvenez bien, ma « Request Template » référence une « Runbook Automation Activity » pour exécuter mon Runbook. C’est là qu’on passe le paramètre au runbook. Grâce à l’identifiant de l’objet « Runbook Automation Activity » passé en paramètre, le Runbook est capable de remonter dans la CMDB jusqu’à l’objet appelant et les paramètres qui y sont associés.

clip_image054

Maintenant que ce mystère est levé, revenons à notre « Request Offering ». Tous les paramètres obligatoires sont renseignés. Passons à la suite.

clip_image055

La phase de mappage des paramètres permet par exemple de stocker des commentaires optionnels renseignés par l’utilisateur sur le portail. On peut stocker ces informations dans l’objet « Service Request » ou dans l’objet « Runbook Automation Activity ».

clip_image056

Le savoir ne vaut que s’il est partagé. Autant afficher dans le portail le ou les articles de la base de connaissance qui concernent ce service.

clip_image057

Enfin la publication. S’il est publié, c’est que ce sera visible dans la vue « List View ».

clip_image058

A ce stade, le service est opérationnel et visible dans le portail. C’est bien mais on peut faire mieux. On est encore au dernier palier et au-dessus de 50 bars de pression (Ne jamais oublier que la pression est aussi dans les bars mais après la plongée).

clip_image059

Palier Service Offering

C’est le dernier palier, avant la surface, un peu plus de 60 bars de pression, on est bon mais on ne va pas perdre de temps. Dans SCSM, un « Service Offering » permet de regroupe des « Request Offering » dans un sous-ensemble. L’intérêt est de pouvoir filtrer la liste des services offerts aux utilisateurs en fonction de l’appartenance à un groupe. Dans la console, ça se trouve là.

clip_image061

Rien à rajouter à ce niveau. Ca présente très bien ce qu’est un « Service Offering ». Passons immédiatement à la suite.

clip_image062

Là, j’avoue que j’ai passé un peu de temps à comprendre. SCSM est un produit international. Il s’adapte donc à la langue de l’utilisateur. Mon poste client étant en langue US, j’ai intérêt à indiquer cette langue dans les caractéristiques de ma « Service Offering » si je veux la voir dans mon portail.

clip_image063

C’est toujours plus pratique d’avoir une relation entre le « Service « Offering » et le « Business Service ». Si mon service de routage ISATAP devait être défaillant, ce serait bien de savoir quels services sont impactés dans mon portail.

clip_image064

Fournir des explications sur mon service, c’est tout aussi important. Autant avoir des articles dans la base de connaissances sur le sujet. On facilite ainsi la vue de l’utilisateur.

clip_image065

Voilà tout l’intérêt des « Services Offering », regrouper les « Request Offering » traitant du même sujet.

clip_image066

Ca y est, c’est la surface. Notre service est enfin opérationnel et visible dans le portail en tant que tel. Il apparait dans la vue « category View ».

clip_image068

La boucle est enfin bouclée, je vous renvoie au premier billet de la série pour revivre l’expérience utilisateur. C’est la fin de cette plongée au cœur d’un service cloud mis en œuvre dans un cloud privé. A ceux qui sont arrivé au bout de la lecture de ce billet, chapeau, vous n’êtes pas si nombreux que cela.

 

Pour finir, ce n’est que la surface des choses. Ce n’est qu’un simple service technique qu’on propose à l’utilisateur d’activer. Le véritable chalenge après, c’est d’être capable de savoir qui consomme ce service pour être capable de lui en refacturer l’usage. Mais là c’est une autre histoire.

 

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

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

le premier runbook vous a plu? Et bien on continue et cette fois sans une seule ligne de Powershell. On prend une grande inspiration et on va plonger vers le runbook de la mort.

Il fait référence à des activités qui sont issues de SCSM. Mon précédent Runbook ne faisait qu’exécuter l’opération. Il faut faire le lien entre SCSM et notre premier Runbook qui a besoin de paramètres en entrée. D’un autre côté, il aurait été possible d’utiliser mon premier Runbook tel qu’il est, cependant :

  • On aurait passé les paramètres en dur. Si le nombre de paramètre doit changer, il faut tout reprendre
  • On ne peut pas récupérer des informations depuis SCSM si on ne les passe pas en paramètres
  • On ne peut pas remonter d’information vers SCSM (bonne exécution ou erreur à telle étape)
  • Sauf si mon Runbook plante, il indiquera toujours qu’il s’est bien terminé

Pour ces raisons, j’ai pris l’habitude de toujours avoir un Runbook intermédiaire. La première fonction de mon nouveau Runbook, récupérer les informations depuis SCSM. Sa seconde fonction, c’est de gérer les erreurs d’exécution de mon premier Runbook. C’est une gestion « Minimaliste », il n’y a pas de notion d’incident au sens SCSM. Enfin, mon Runbook va créer une relation entre mon ordinateur pour lequel le service a été activé et la représentation du service ISATAP qui sont tous les deux des objets dans SCSM.

Amis de la CMDB, bonsoir. Le grand chalenge de l’intégration SCSM avec Orchestrator, c’est :

  • Comment indiquer au Runbook ou récupérer tous ses paramètres
  • Comment le Runbook indique s’il a réussi son exécution ou non
  • Comment s’est terminée la requête de l’utilisateur
  • Comment indiquer que le service a été activé/désactivé pour l’objet sélectionné
  • Comment gérer les erreurs

Ca fait beaucoup de choses à voir dans un seul billet. Attention les yeux, ça pire et mérite pas mal d’explications.

clip_image002

Commençons par la première activité et première bizarrerie : Un seul paramètre en entrée.

clip_image003

Techniquement, cela correspond à l’identifiant unique de l’activité qui a été réalisée lors de la « Service request » de l’utilisateur. Petit flashback vers le premier billet de la série :

clip_image005

C’est la représentation de mon objet « Runbook Automation Activity » créé lors de l’exécution de la « Service Request » initialisé par l’utilisateur. La « Service Request » a été créé par rapport à un modèle qui lui référence une seule activité. Dans l’illustration ci-dessous, on retrouve la fameuse activité qui a été générée lors de l’exécution mon runbook avec son paramètre :

clip_image007

Maintenant que nous avons l’identifiant unique de l’activité qui a été créé pour exécuter mon Runbook, on va l’utiliser. Il désigne un objet de classe « Runbook Automation Activity ». Mon premier usage sera de retrouver le lien qui uni cet objet et un objet de la classe « Windows Server ». C’est l’ordinateur que l’utilisateur a sélectionné dans le premier billet. Seulement, ce n’est pas un objet Active Directory mais un objet dans la CMDB dont les attributs ont été enrichis par tous les connecteurs. J’ai perdu personne?

clip_image008

A ce stade, on peut avoir un ou plusieurs éléments retournés (la Request Offering aurait pu autoriser la sélection multiple). En sortie nous avons donc une seule instance d’objet « Windows Server ». Plus précisément nous avons l’identifiant unique de l’objet dans la CMDB, son « SC Object Guid ». Nous n’avons plus qu’à interroger SCSM pour nous extraire les informations de cet objet de classe « Windows Server » en précisant l’identifiant unique comme critère de filtrage.

clip_image009

A ce stade, deux possibilités. Soit on a bien identifié l’objet, soit il y a eu un problème. Si vous reprenez la vue générale du Runbook, vous verrez qu’il y a une un lien rouge. Lorsqu’on clique dessus, on retrouve le critère qui fait que le Runbook empruntera ce chemin :

  • Erreur d’exécution
  • ou nombre d’objets retournés par l’activité présente égal à 0

clip_image011

Pour la suite de ce billet, on va considérer que tout se passe pour le mieux. Prochaine étape, déterminer quel routeur ISATAP doit être configuré pour l’objet ordinateur que nous venons d’identifier. C’est encore une activité « Get Relationship », toujours concernant notre « Runbook Automation Activity » mais cette fois, c’est un objet de classe « Business Service » que nous recherchons. C’est dans cet objet que j’ai indiqué le nom de mon routeur ISATAP.

clip_image012

Dans SCSM, un Business service est un objet de la CMDB. Il représente un service composé de composants supervisés qui ont un lien entre eux. L’indisponibilité de l’un des composants de mon service aura nécessairement des répercutions sur mon service. Dans mon cas, ce « Business Service » est issu du service décrit dans SCOM. Ce qui a été déclaré dans SCOM a été utilisé pour alimenter l’objet équivalent dans la CMDB de SCSM. Si on va voir mon « Business Service », on constate que dans l’onglet « Extension », on trouve son identifiant unique mais aussi un champ « Service FQDN ».

clip_image014

On se doute tout de suite que ce n’est pas un champ standard. Effectivement, c’est une extension que j’ai intégré à la classe d’objet « Business Service » via un Management Pack. Pour ceux que cela intéresse, voilà une très bonne explication vidéo de l’équipe produit. Pour faire simple, nous utilisons le « Service Manager Authoring Tool » pour créer un Management pack qui va réaliser une extension de la classe d’objet « Business Service ». J’ai donc créé un attribut pour stocker une chaine de caractère.

clip_image016

Si j’ai créé un attribut, c’est pour l’utiliser. Je vais donc stocker le nom pleinement qualifié du routeur ISATAP que nous allons configurer.

clip_image018

C’est cette information dont mon Runbook a besoin. En sortie de l’activité « Get Business Relationship », on est censé avoir la référence de mon Business Service. L’activité « Get Business Service » est tout à fait classique, on filtre juste sur l’identifiant unique que nous avons récupéré de l’activité précédente.

clip_image019

A ce stade, on a accès aux objets nous permettant d’extraire les informations nécessaires à l’exécution de notre premier « Runbook ». On va donc appeler une activité « Invoke Runbook » qui se charge d’exécuter notre premier Runbook et lui passer nos deux arguments. Pour chaque argument, c’est juste un attribut d’un objet que nous avons préalablement identifié par des activités de type « Get Object ». On va juste s’assurer que nous ne continuerons l’exécution de notre Runbook après qu’il nous ait rendu la main.

clip_image020

Si vous souvenez, en fin d’exécution, notre premier Runbook retourne une valeur. Nous allons l’exploiter. C’est très simple si tout se passe bien. Pour suivre, ces liens sont en vert dans mon Runbook.

clip_image022

Par contre, notre Runbook peut avoir planté ou retourné un code erreur. Il faut bien traiter les deux cas. Pour suivre, ces liens sont en rouge dans mon Runbook.

clip_image024

Comme tout s’est bien passé, mon serveur est maintenant un client ISATAP. Du point de vue de la CMDB, ce serait bien d’avoir une relation entre le routeur ISATAP et ses clients. En cas d’indisponibilité du service ISATAP, les premiers impactés, c’est bien les clients. C’est ce que nous allons faire avec l’activité « Create Relationship ».

clip_image025

Pour expliquer, allons voir ce que cela a donné au niveau de l’objet « Business Service » correspondant à mon service « Service réseau ISATAP ». D’une part, on constate la présence d’un lien entre mon objet « Runbook Automation Activity » et mon « Business Service ». Normal, c’était un paramètre passé lors de la création de l’activité à partir du modèle. D’autre part, l’activité « Create-Relationship » a créé un lien entre mon « Windows Server » et mon « Business Service ».

clip_image027

On approche de la fin. Notre activité s’est bien déroulée. On peut considérer que le service est activé. Ce serait bien que ce soit indiqué dans la CMDB. Ce sera super utile pour ne proposer à l’utilisateur final de n’activer le service que pour les systèmes pour lequel il ne l’est pas (prochain billet). Sur ce point, j’ai beaucoup cherché avant de revenir à des fondamentaux, donc la simplicité. Si on avait un attribut dans la CMDB dans lequel indiquer que le service ISATAP a été activé sur cet ordinateur? Rien de plus simple, il suffit d’étendre la CMDB, tout comme pour le « Business Service », nous allons utiliser le « Service Manager Authoring Tool » pour créer une nouvelle classe d’objet nommée MyWindowsComputer » qui héritera ses caractéristiques de la classe « Windows Server ». J’ai juste ajouté une propriété nommé « ISATAPEnabledService » dont le contenu sera de type « Booléen ». J’avais prévenu : Simple!

clip_image029

Dans la console SCSM, on pourra retrouver cet attribut dans l’onglet « Extensions ». Ci-dessous l’attribut en question pour mon ordinateur sélectionné par l’utilisateur dans sa demande de service.

clip_image031

Maintenant, revenons à notre Runbook. Ce qu’on veut, c’est indiquer la valeur « True » pour l’attribut « ISATAPEnabledService » pour l’objet « MyWindowsComputer ». Ça tombe bien car l’activité « Get Computer Object » de notre Runbook désigne déjà cet objet avec la propriété « SC Object GUID ».

clip_image032

Etant donné que notre Runbook s’est bien déroulé. Autant l’indiquer dans SCSM (cela nous donne la date de réalisation de l’opération. C’est utile pour savoir si on respecte ses engagements en terme de SLA). Au niveau de l’objet « Runbook Automation Activity », c’est l’attribut « Status » qu’il faut mettre à jour à l’aide de l’activité « Update Activity ». A ceux qui se demandent pourquoi j’indique « Terminéé » comme valeur et non « Completed », je les renvoie vers ce billet (Ca m’apprendra à ne pas mettre à jour mes maquettes).

clip_image033

C’est la dernière ligne droite. Notre « Service Request » n’ayant qu’une seule « Activité », le travail est donc terminé. Autant remonter cette information à l’utilisateur final. ce qui l’intéresse, c’est pas le résultat des activités intermédiaires qui ont été nécessaire pour réaliser sa demande, lui, il veut juste savoir si c’est terminé. Pour cela, j’ai créé un dernier Runbook nommé « SCSM-ISATAP-SUCCESS-RESULT » qui sera le plus simple possible. On va lui passer deux paramètres :

  • Notre fameux « ActivityID » qui nous permet de remonter à l’activité « Runbook Automation Activity »
  • Le résultat que l’on désire indiquer dans l’objet « Service Request »

clip_image034

Je ne présente plus l’activité « Initialize data »,elle est des plus banales maintenant. Ce qui va nous intéresser, c’est la suivante.

clip_image035

Ce qu’il nous faut, c’est le moyen de remonter depuis l’objet « Runbook Automation Activity » jusqu’à l’objet « Service Request ». Ça tombe bien, c’est cette dernière qui a créé la première, il y a donc une relation entre eux. Avec l’activité « Get Relationship », on peut donc retrouver l’objet « Service request » qui lui est lié.

clip_image036

Je ne présente plus l’activité « Update Object », nous l’avons déjà utilisé pour mettre à jour l’objet « Runbook Automation Activity », cette fois, on va l’utiliser pour mettre à jour des attributs de l’objet « Service Request » que l’on vient de trouver.

clip_image037

Dans les faits, voilà où cela va inscrire ces informations.

clip_image039

 

Si vous êtes arrivés au terme de ce billet, dites vous bien que vous êtes maintenant bien loin de la surface et qu’il va falloir remonter. Problème, on va avoir plusieurs paliers à réaliser dans SCSM. J’espère que vous avez encore de l’air dans la bouteille car la remontée va être longue pour le dernier billet.

 

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

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

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

On parle souvent de Cloud mais on voit rarement comment cela fonctionne. Pour mieux comprendre, j’ai monté une « petite infrastructure ». Pour faire simple, je me suis basé sur les spécifications du Private Cloud Fast Track program. C’est simple, avec un peu de tuning, ça tiens en 32Go de mémoire vive. Prévoir quelques longues heures d’installation .

Tout au long de ce billet (et quelques autres), on va se balader entre System Center Service Manager 2012 et System Center Orchestrator 2012. Mais avant de rentrer dans des choses compliquées voyons à quoi ressemble un service du point de vue de l’utilisateur qui le consomme. Dans mon Cloud (aucun jeu de mot avec la plateforme qui m’héberge), j’ai un une machine virtuelle qui assure le rôle de routeur ISATAP (Non, il n’y aura pas de DirectAccess dans ce billet). C’est le service qui sera consommé par les machines virtuelles dépendantes de mon Cloud.

D’un point de vue purement technique, activer ISATAP sur un système, cela revient à exécuter quelques commandes Powershell. Comme je veux bien faire les choses, on va les exécuter via une session distante. Mais avant de rentrer dans le « dur », voyons à quoi cela ressemble du point de vue de l’utilisateur final. Commençons par la surface des choses.

Dans son portail SCSM, je lui présente un catalogue de service. Au sens SCSM du terme, c’est un regroupement de services qui ont été regroupés dans un « Service Offering ». L’idée est de pouvoir regrouper les demandes ayant trait à un même domaine mais aussi d’en autoriser l’accès à certaines populations. Dans mon cloud, mon utilisateur se voit présenter les services qui lui sont accessibles.

clip_image002

Au sein du « Service Offering », l’utilisateur peut constater la présence de deux « Request Offering ». Dans SCSM, une « Request Offering » fait en quelque sorte le lien entre le portail et tout ce qui se trouve sous le capot de SCSM.

clip_image004

En cliquant sur la « Request Offering », le portail SCSM affiche un certain nombre d’informations qui y sont liés dont le contenu de la base de connaissance qui y est associé.

clip_image006

Un peu plus tôt, j’avais indiqué qu’une « Request Offering » faisait le lien entre le portail et ce qui se trouve caché dans SCSM. C’est le cas. Pour notre demande de service ISATAP, il faut bien sélectionner un compte ordinateur pour lequel on va activer le service. Plus tard on découvrira que ces informations ne sont pas issues directement de l’annuaire Active Directory mais de la CMDB qui a elle-même récupérer ces informations de l’AD. Mais ça ce sera pour plus tard.

clip_image008

Toutes les informations pour traiter la demande de service ont été renseignées, il ne reste plus qu’à valider cette demande.

clip_image010

C’est maintenant que la magie de SCSM commence. Notre « Request Offering » n’était que l’interface graphique. En fait, elle a passé ses paramètres à une « Request Template » dans SCSM. Une « Request template » regroupe en ensemble d’activité qui va permettre de traiter la demande de l’utilisateur. On peut avoir différents type d’activités. Dans mon cas, ma « Request Template » ne contient qu’une seule activité qui se contente d’appeler un Runbook Orchestrator. Lorsque l’utilisateur a initialisé sa demande de service, SCSM a créé un objet « Request Template » SR1298 et l’activité qui y est liée RB1299.

clip_image012

Après une phase d’initialisation, la mécanique SCSM ne met en œuvre. Dans le cas qui nous occupe, elle appelle un Runbook dont on peut constater que l’exécution suit son cours.

clip_image014

Lorsque tout se passe bien dans le Runbook Orchestrator le statut de la requête est considéré comme terminé.

clip_image016

Voilà un service vu de l’utilisateur. C’est la partie visible de l’iceberg. Allons voir de l’autre côté dans la console SCSM. C’est là que ça commence à se compliquer. Dans l’illustration ci-dessous, on retrouve bien la « Service Request » initialisée par l’utilisateur. Dans l’état actuel des choses, elle est considérée comme active car l’activité qui y est associé n’est pas encore terminée.

clip_image018

Si on regarde le détail de la « Request « Template », on retrouve bien le compte ordinateur sélectionné, mais aussi un GUID. C’est la référence de l’objet Active Directory dans la CMDB de SCSM. C’est l’objet « Active Directory » dans la CMDB qui nous intéresse dans SCSM.

clip_image020

Notre « Service Request » ne contient qu’une seule activité. C’est le « Runbook template » qui est référencé.

clip_image022

Au final, dans l’onglet résultat, on retrouvera le résultat final de la demande de service.

clip_image024

Voilà pour la surface des choses. Dans le prochain billet, on va rentrer dans le “dur” des choses et comprendre comment tout cela a été assemblé dans SCSM pour en arriver là. Dans la prochaine étape, on va rester des choses assez simples avec notre premier Runbook Orchestrator. Prenez votre inspiration, on plonge.

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