PI Services

Le blog des collaborateurs de PI Services

Recupération du code retour lors d'une exécution d'un script PoSh sous Orchestrator

INTRODUCTION

Orchestrator (SCO) est une solution d'automatisation de processus (Run Book Automation – RBA) pour l'orchestration. Un runbook contient plusieurs activités connectées sous forme d'un workflow. Pour bien définir le chemin d'un workflow, il faudra savoir récupérer le code retour d'une activité. Par défaut, le code retour d'une activité (Initialize Data) est définit comme dans l'exemple ci-dessous:

Pour afficher l'écran ci-dessus, double-cliquer sur le lien entre deux activités. On cochant la bonne case, nous pourrons définir le chemin du workflow en cas de "success","warning" ou "failed". Mais, cela devient plus compliqué si nous souhaitons récupérer un code retour d'une application ou d'un script PoSh. Dans l'exemple ci-dessous, nous allons récupérer le code retour d'un script PoSh lancé par Orchestrator. 

Exemple

Nous allons créer un runbook qui lancera un script PoSH avec deux codes retour possible  : 100 et 101. Les deux codes retour doivent emprunter deux chemins diférents. Le runbook resemble à:

L'activité "Run Program" lancera le script. L'activité "Return code" en PoSh récupérera le code retour et le mettra dans une variable qu'on traitera par la suite. Attention: dans l'exemple le script PoSh est lancé par un fichier .bat.

Le script powershell contient les codes suivants: 

$server = "127.0.0.1"
$ping = new-object System.Net.NetworkInformation.Ping
$ReponsePing = $ping.Send($server)


if ($ReponsePing.status –eq “Success”) 
{
     return 100
}
else 
{
     return 101
}

 

Le script .bat contient les codes suivants:

powershell .\ping.ps1

Paramétrage des activités

Dans l'activité "Run Program":

Sélectionner "Command execution" puis entrer le nom du serveur, le chemin du fichier .bat et le répertoire de travail. 

Après l'exécution de l'activité, le code retour (100 ou 101) sera publié dans une variable publiée automatiquement. Le nom de la variable est Pure Output et on constate bien à la fin le code retour 100. 

Nous allons récupérer ce code retour sans une autre variable qu'on nommera $pureOutput grâce à un script PoSh définit dans l'activité "Return code".

Assurez vous que la variable est bien publiée dans "Published Data". Grâce à cette variable nous pourrons définir correctement le chemin à prendre si le code retour est 100 ou 101. Pour le faire, double-cliquer sur le connecteur (link) et ajouter la variable "pureOutput" et son contenu.

Faire la même chose sur le connecteur (link) pour le code retour 101.

 

 

 

 

 

 

 

 

Orchestrator – Requête du dernier status de tout les runbooks

Cette requête SQL affiche le dernier status d’exécution de tout les runbooks d’une instance, triés par dernière date d’exécution.

--***REQUETES DES DERNIERS STATUS D'EXECUTION DE TOUT LES RUNBOOKS TRIES PAR DATE D'EXECUTION AVEC UN FILTRE SUR LE NOM DES RUNBOOKS ***/ --*** NB: Ajouter un critere sur RL.Name pour un job spécifique (ex: RL.Name = 'My_job') USE ORCHESTRATOR SELECT RL.Name as RunbookName, MAX(RI.CompletionTime)as dernieredate INTO TEMP_ALL_JOB_LAST_STATUS FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId WHERE ((RL.Name NOT LIKE '%OLD%') AND (RL.Name NOT LIKE '%TEST%')) GROUP BY RL.Name ORDER BY RL.Name; SELECT RunbookName, dernieredate as Derniere_date_Execution, RI.Status as Dernier_Status FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId INNER JOIN TEMP_ALL_JOB_LAST_STATUS ON TEMP_ALL_JOB_LAST_STATUS.RunbookName=RL.Name and dernieredate = RI.CompletionTime ORDER BY Derniere_date_Execution DESC GO DROP TABLE TEMP_ALL_JOB_LAST_STATUS

System Center Orchestrator 2012 R2 : Accéder à la console web via une VIP

Introduction

Dans le cadre d'une infrastructure Orchestrator 2012 R2 en haute disponibilité, il est nécessaire de créer une ou plusieurs VIP pour les services web de ce produit. Pour rappel, ils sont au nombre de deux :

  • Le web service, accessible via le port 81 avec une url du type : http://nom_du_server:81/Orchestrator2012/Orchestrator.svc 
  • La console web (en silverlight), accessible via le port 82 avec une url du type : http://nom_du_serveur:82/

Le sujet de la haute disponibilité n'est détaillé que pour le rôle runbook server d'Orchestrator. Concernant les services Web, il n'y a aucune documentation proposée par Microsoft à l'heure actuelle (20/11/2014).

Dans cet article, je ne détaillerai pas la création de la VIP qui n'a rien de particulier. Il s'agit plutôt de voir la configuration à réaliser sur les serveurs Orchestrator portant les services web.

Au niveau des pré requis, il est donc nécessaire d'avoir au moins deux serveurs Orchestrator répondant aux services web cités précédemment.

Erreur rencontrée

Après avoir configurée une VIP, lorsque l'on essaie d'accéder au web service, cela ne pose aucun problème. Cependant ce n'est pas le cas de la console web.

En effet, la page web n'affichera que le squelette de la page web et tentera de vous afficher du contenu pendant un certain temps avant que vous n'obteniez le message d'erreur suivant :
Popup Arg SecurityException
Cette première erreur, [Arg_SecurityException], ne nous donne pas d'information concrète et il n'y a rien dans les logs IIS. Après avoir validé ce message, vous obtiendrez une seconde popup :
Popup web services error
Ce message est plus concret puisqu'il nous informe qu'il y a une erreur avec le web service (service arrêté, URL du service non valide ou accès refusé). Cela nous confirme que l'IHM est basée sur le web service. Elle l'utilise afin de récupérer les données de l'infrastructure Orchestrator.
 

Configuration

Afin de rendre opérationnelle notre VIP pour la console web Orchestrator, il faut réaliser une série d’opération sur IIS qu’il conviendra d’exécuter une ou plusieurs fois. En voici une liste récapitulative :

  • Configuration du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
  • Ajout de SPN sur le compte de service Orchestrator : A réaliser une fois (via une invite de commande).
  • Configuration des sites web pour l’utilisation des informations d’authentification du compte de service du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
  • Implémentation de l’url utilisée par la console web pour accéder aux web services : A réaliser sur le site console web Orchestrator sur tous les serveurs (nœuds) le proposant (via IIS Manager).
  • Redémarrage des sites web Orchestrator : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).

Configuration du pool d’application :

Tout d’abord, il faut se rendre dans la console IIS Manager. Par défaut, Orchestrator utilise le pool d’application par défaut alors qu’il en crée un nommé System Center 2012 Orchestrator Web Features qui est défini avec le compte de service Orchestrator. Les deux sites web doivent donc être configurés pour utiliser ce pool d’application. Pour ce faire, on sélectionne le site web Microsoft System center 2012 Orchestrator Web Service, on clique sur Advanced Settings puis on parcours la liste des pools d’application disponibles,

updateapppool

Il suffit ensuite de sélectionner le pool System Center 2012 Orchestrator Web Features et de valider.

chooseapppool

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Ajout des SPNs nécessaires :

La seconde étape est l’ajout des SPN liés aux URLs utilisés pour accéder à la console web et aux web services Orchestrator au compte de service Orchestrator. Voici la liste des commandes à lancer pour ajouter les SPNs nécessaires (à noter vipihm et vipwebsvc peuvent être identiques si vous n’utilisez qu’une seule VIP pour la console web et pour les web services) :

SetSPN.exe –A HTTP/sco1 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco1.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc DOMAIN\SERVICE_ACCOUNT

Attention : N’oublier de remplacer sco1, sco2, vipihm et vipwebsvc par les valeurs de vos noeuds Orchestrator et de vos VIPs. DOMAIN\SERVICE_ACCOUNT doit être remplacé par votre compte de service.

NB : Cette opération n’est à réaliser qu’une seule fois.

Utilisation des informations d’authentification du compte de service du pool d’application :

Nous devons ensuite définir l’utilisation des informations d’authentification du compte de service du pool d’application sur les différents sites web. On sélectionne l’un des sites web Orchestrator dans IIS Manager puis on choisit Configuration Editor :configurationeditor Il faut parcourir l’arborescence jusqu’au niveau : system.webServer, security, authentication, windowsAuthentication.

updatewindowsauthent Enfin, la propriété useAppPoolCredentials doit être défini à la valeur True.

useapppoolcred

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des noeuds Orchestrator portant ces sites.

Définir l’url utilisée par la console web pour accéder aux web services :

La dernière étape consiste à définir l’url utilisée par la console Orchestrator pour accéder aux web services. Dans IIS Manager, il faut sélectionner le site web Microsoft System center 2012 Orchestrator Orchestration console et cliquer sur Application Settings.

applicationsettingsLa valeur de l’attribut ScoServiceUri doit être changée avec la valeur de la vip : http://nom_vip:81/Orchestrator2012/Orchestrator.svc

scoserviceuri
Attention, si comme moi, vous décider d'effectuer un transfert de port (81 vers 80), alors il faudra supprimer ce dernier de l'URL : http://nom_vip/Orchestrator2012/Orchestrator.svc"

NB : L’opération ci-dessus est à réaliser pour le site Microsoft System center 2012 Orchestrator Orchestration console sur la totalité des nœuds Orchestrator portant ces sites.

Redémarrage des sites web :

Il ne vous reste plus qu'à redémarrer les site web sur tout les nœuds Orchestrator via l'interface de IIS :
 restart

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Une fois l'opération effectuée, la VIP est opérationnelle.

A titre informatif, l'environnement sur lequel la configuration a été testée était composé d'un HLB F5 possédant une VIP avec transfert de port 81 vers 80 pour le web services et une autre VIP pour la console Silverlight (port 82 vers 80). Cependant, cette configuration est valable quelque soit l'environnement.

Orchestrator– Scom: Correlation et “Nettoyage” d’alertes

 

L’interaction Orchestrator-Scom est intéressante sous réserve d’introduire dans les runbooks concernés un peu de corrélation afin de ne pas générer trop d’alerte et de pouvoir les clôturer automatiquement.

L’exemple ci-dessous est un peu limité. En effet:

1/ Le runbook ne détecte pas si une alerte précédente est présente.

2/ Il ne prévoit pas de cas OK associé a une fermeture automatique de l’alerte potentiellement générée avant. (sous réserve que l’on veuille cette clôture automatique) Clignement d'œil

image

 

Ajoutons a ce runbook quelques éléments:

 

image

Si le programme sort OK (Exit = 0) , le nœud “Get Not Closed Alert” cherche les alertes précédemment générées et toujours dans un état autre que Closed, puis si une plusieurs alerte sont trouvées, le nœud Close Alert les clôtures.

Si le programme sort KO (Exit <> 0), le nœud “Get Not Closed Alert” cherche les alertes précédemment générées. Si une alerte est présente, inutile d’en générer une autre pour le même problème, sinon elle est crée par le nœud Create Alerte.

L’idéal, serait dans le second cas d’incrémenter le champ Repeat count de l’alerte existante mais on attends que l’Integration Pack de SCOM intègre cette possibilité dans une prochaine version  Clignement d'œil.

Orchestrator – Script: Ressources utilisées par un runbook

 

Il n’est pas possible directement dans la console Orchestrator de faire le lien entre une instance de runbook et son process policymodule.exe.

Pour cela il faut faire le lien entre le PID du job effectivement en cours d’exécution, dans la base Orchestrator et le PID du process apparent dans le gestionnaire de tache.

Le script suivant prend en paramètre le nom du runbook.

Il est nécessaire de modifier le nom de l’instance SQL ($SQLServer)

Le script renvoi la mémoire (Private Working Set (Ko)) car cette info est particulièrement intéressante mais d’autre compteur peuvent bien sur être récupérés.

 

 

Param( #[parameter(Mandatory=$true)] [string]$Runbook ) $Global:Runbook = $args[0] $Scriptname = "getRunbookJobPid" $SQLServer = "" $SQLDBName = "Orchestrator" $SQLTempDB= "Temp_$Runbook"+"_$Scriptname" #FUNCTIONS function GetProcessInfoById { param ([int]$processId) Get-WmiObject -class Win32_PerfFormattedData_PerfProc_Process | where-object {$_.idprocess -eq $processId} | select ` @{Name="Process Id"; Expression = {$_.idprocess}},` @{Name="Private Working Set (Ko)"; Expression = {$_.workingSetPrivate / 1kb}} } #END_FUNCTIONS $SqlQuery = " SELECT MAX(DATEADD(HOUR,2,TimeStarted)) as TimeStart ,ProcessID as ProcessId ,Name as Name ,j.Status as Jstatus ,RI.status as RIStatus INTO $SQLTempDB FROM [Orchestrator].[dbo].[POLICYINSTANCES] as p WITH (NOLOCK) inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].[Jobs] as j on j.id=p.JobId inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator].[Runbooks] as R on R.Id=j.RunbookId inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI on RI.RunbookId=R.Id WHERE RI.status = 'InProgress' AND j.Status = 'Running' AND R.Name = '$Runbook' GROUP BY TimeStarted ,ProcessID ,Name ,j.Status ,RI.status DECLARE @MaxDate DateTime SET @MaxDate = (SELECT MAX(TimeStart) FROM $SQLTempDB) SELECT ProcessId from $SQLTempDB WHERE TimeStart = @MaxDate DROP TABLE $SQLTempDB" if (-not($Runbook)) { throw "Nom du runbook requis" } $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionString = "Server = $SQLServer; Database = $SQLDBName; Integrated Security = True" $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlCmd.CommandText = $SqlQuery $SqlCmd.Connection = $SqlConnection $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $SqlAdapter.SelectCommand = $SqlCmd $DataSet = New-Object System.Data.DataSet $SqlAdapter.Fill($DataSet) $SqlConnection.Close() #clear $ProcessId= $DataSet.Tables[0] | Select-Object -Property ProcessId -ExpandProperty ProcessId write-host "RUNBOOK: $Runbook" GetProcessInfoById $ProcessId | fl

Orchestrator – Problème d’affichage de runbook

 

Dans certains cas un runbook nouvellement crée peux ne pas apparaitre dans la console Web ou dans les applications tierces recevant le nom du runbook (SCOM – SCSM).

Pour débuguer ce problème:

- Ouvrez SQL Management Studio et connectez vous a l’instance de la base Orchestrator.

- Exécutez la requête suivante:

Use Orchestrator

TRUNCATE TABLE
[Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

- Rafraichissez l’affichage de la console Web pour faire apparaitre le runbook

 

Pour automatiser la réponse a ce problème, vous pouvez automatiser via un job sql l’exécution de la requête suivante afin de forcer un vidage du cache des autorisations:

Use Orchestrator

EXEC [Microsoft.SystemCenter.Orchestrator.Maintenance].EnqueueRecurrentTask ‘ClearAuthorizationCache’

Orchestrator : Requête de l’état des dernières instances de job.

 

Voici une requête a exécuter sur l’instance SQL de votre serveur orchestrator pour récupérer l’état de la dernière exécution d’une liste de runbooks

Vous pouvez de-commenter (—) la clause WHERE pour exclure certain nom de runbook ou encore choisir une des clauses ORDER BY pour choisir un critère de tri.

USE ORCHESTRATOR SELECT RL.Name as RunbookName, MAX(RI.CompletionTime)as dernieredate INTO MyTableau FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId --WHERE RL.Name NOT LIKE '%TEST%' GROUP BY RL.Name ORDER BY RL.Name; --ORDER BY MAX(RI.CompletionTime) DESC, RL.Name --ORDER BY LastStatus DESC SELECT RunbookName, dernieredate as Derniere_date_Execution, RI.Status FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId INNER JOIN MyTableau ON MyTableau.RunbookName=RL.Name and dernieredate = RI.CompletionTime; GO DROP TABLE MyTableau