Le logiciel Orchestrator 2012 proposé par Microsoft dans la gamme System Center, est un outil puissant et pourvu de nombreux atouts pour qui souhaite automatiser de nombreux processus au sein de l'entreprise et notamment au niveau de l'infrastructure informatique. Néanmoins un point faible de ce logiciel est l'absence (presque totale) de système de log. La journalisation interne se cantonne à conserver, dans la base de données du produit, et pendant un temps limité (quelques jours dans la configuration par défaut), des informations basiques comme par exemple quel utilisateur a modifié quel runbook ou les erreurs rencontrées lors de l'exécution des runbooks. Nativement il n'est pas possible d'indiquer au système de conserver une donnée particulière.

Un Integration Pack nommé "Standard Logging" est proposé par Charles Joy (Microsoft) sur codeplex : http://orchestrator.codeplex.com/releases/view/76097. Cet Integration Pack permet de combler en partie la lacune de Orchestrator en termes de possibilité de journalisation. Cependant cet Integration Pack est encore trop limité à mon goût car il a été pensé uniquement pour permettre de débugguer un runbook, et il ne propose que de conserver les dernieres données issues d'un runbook. C'est pourquoi j'ai décidé de développer un nouvel Integration Pack basé sur celui de Charles Joy en apportant une nouvelle logique de fonctionnement. Je l'ai baptisé "eXtended Logging".

Le principe de base reste le même, permettre à l'administrateur utilisant Orchestrator de rajouter au sein des runbooks des activités permettant d'écrire de la donnée diverse dans une bases de données SQL. La base de données SQL de destination est composée de deux tables qui représentent pour la première les différents journaux (une entrée par journal), et pour la seconde le contenu du journal divisé en étape (une ligne par étape). J'ai également introduit la notion de durée de rétention souhaitée qui permet, à l'aide d'une procédure stockée, de supprimer les différents jounaux et contenus associés, arrivés à péremption.

 

L'Integration Pack est disponible au téléchargement ici (version 64 bits pour System Center Orchestrator 2022) : OIPeXtendedLogging2.0.zip (664 ko)

 

Le fichier ZIP contient plusieurs fichiers dont :

  • eXtendedLogging.oip (Integration Pack qui s'installe comme n'importe quel autre IP à l'aide de Orchestrator Deployment Manager)
  • 01 - CreateeXtendedLoggingDatabase.sql (script SQL de création de la base de données pour stocker les journaux)
  • 02 - CreateeXtendedLoggingTables.sql (script SQL de création des tables sur la base de données)
  • 03 - CreateeXtendedLoggingViews.sql (script SQL de création des vues sur la base de données)
  • 04 - CreateeXtendedLoggingSPs.sql (script SQL de création des procédures stockées sur la base de données)

 

Installation et configuration :

Les pré requis à l'utilisation de cet Integration Pack sont :

  • System Center Orchestrator 2012 RTM / SP1 / R2
  • SQL Server 2008 R2 et version ultérieure

La mise en oeuvre de cet Integration Pack consiste donc à déployer l'OIP, à créer la base de données SQL associée sur une instance SQL, et enfin à configurer l'IP afin de lui indiquer ou est hébergée la base de données que le système utilisera pour stocker les journaux. La création de la base de données et des éléments la consitituant doit être réalisé à l'aide des scripts SQL fournis dans le package. Il est nécessaire d'exécuter les scripts dans l'ordre (du 01 au 04).

Dans le script "01 - CreateeXtendedLoggingDatabase.sql" attention de bien modifier le chemin des fichiers qui composent la base de données (lignes surlignées en jaune ci dessous).

 

CREATE DATABASE [eXtendedLogging] ON   PRIMARY

( NAME = N'eXtendedLogging' , FILENAME = N'Z:\SGBDData\MSSQL11.SCOR\MSSQL\DATA\eXtendedLogging.mdf' , SIZE = 104448KB , MAXSIZE = UNLIMITED , FILEGROWTH = 102400KB )

LOG ON

( NAME = N'eXtendedLogging_log' , FILENAME = N'Z:\SGBDData\MSSQL11.SCOR\MSSQL\DATA\eXtendedLogging_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 64512KB )

GO

 

Une fois que l'OIP est déployé sur le ou les serveurs Orchestrator et que la base de données est créée il est nécessaire de procéder à la configuration de l'Integration Pack à l'aide de la console "Runbook Designer".

Dans le menu "Option" un élément nommé "eXtended Logging" devra être disponible (aprés le déploiement de l'OIP réalisé précedemment). Il suffit donc de cliquer sur "eXtended Logging" et d'ajouter un élément de configuration. Une fois le type de configuration "eXtended Logging Settings" choisit, il sera nécessaire de saisir plusieurs champs :

  • SQL Trusted Connection (le paramètre est de type booléen)
    • "true" indique que l'authentification à SQL est de type "Windows" et dans ce cas il sera nécessaire de donner le droit "db_owner" sur la base de données eXtended Logging au compte Windows exécutant le service "Orchestrator Runbook Service". De plus il ne sera pas nécessaire de remplir les champs  "SQL User ID" et "SQL Password"
    • "false" indique que l'authentification à SQL est de type SQL et dans ce cas il faudra indiquer dans les champs "SQL User ID" et "SQL Password" un utilisateur / mot de passe ayant le droit "db_owner" sur la base de données eXtended Logging
  • SQL Server Name (champs texte)
    • Indiquer le nom du serveur SQL sous la forme NOM_SERVEUR_SQL (si instance par défaut) NOM_SERVEUR_SQL\NOM_INSTANCE ou NOM_SERVEUR_SQL,NUMERO_PORT_INSTANCE (si instance nommée)
  • SQL Server Database (champs texte)
    • Indiquer le nom de la base de données (par défaut eXtendedLogging)
  • SQL User ID (champs texte)
    • Si SQL Trusted Connection est à "false", indiquer le nom de l'utilisateur SQL
  • SQL Password (champs texte)
    • Si SQL Trusted Connection est à "false", indiquer le mot de passe associé au l'utilisateur SQL

 

Utilisation :

L'Integration Pack eXtended Logging contient 4 activités :

  • Create Log
    • créer un nouveau journal dans la base de données qui est matérialisé par une nouvelle entrée dans la table eXtended_Logging_LOG)
  • Log Step
    • créer une nouvelle ligne pour un journal donné dans la base de données qui est matérialisé par une nouvelle entrée dans la table eXtended_Logging_STEP)
  • Get Log Data
    • récupère l'ensemble des lignes d'un journal donné (lecture dans la table eXtended_Logging_STEP)
  • Purge Log
    • supprime les journaux arrivés à péremption de la base de données (toutes les lignes de la table eXtended_Logging_STEP associées à un journal + la ligne correspondant au journal concernée dans la table eXtended_Logging_LOG)
    • un journal arrivé à péremption est un journal dont la différence entre la date actuelle et sa date de dernière mise à jour est supérieure ou égale à sa durée de rétention

Les activités "Log Step" et "Get Log Data" requièrent  le paramètre "LogID" en entrée. Ce paramètre peut être founit par l'intermédiaire du bus de données ("published data") depuis l'activité "Create Log" qui renvoit sur le bus de données le "LogID" qui a été généré lors de la création d'un nouveau journal dans la base de données.

 

Create Log :

L'activité "Create Log" propose de saisir plusieurs propriétés dont 3 optionnelles ("Description", "Custom Field 01" et "Custom Field 02").

  • Log Name
    • Champ texte libre sur lequel je recommande d'indiquer la donnée publiée système "Runbook Name" de l'activité précédente
  • Retention duration in month
    • Indiquer une durée de rétention exprimée en nombre de mois
  • Log Description
    • Champ texte libre optionnel
  • Custom Field 01/02
    • Champ texte libre optionnel

L'activité Create Log renvoit les données suivantes sur le bus de données :

  • Log ID
    • GUID créé par SQL et à fournir aux activités "Log Step" et "Get Log Data"
  • Log Name
  • Retention duration in month
  • Log Description
  • Custom Field 01 / 02
  • Last Update Date Time
  • SQL Server Database
  • SQL Server Name
  • SQL Trusted Connection
  • SQL User ID
  • Start Date Time

 

Log Step :

L'activité "Log Step" permet de créer une nouvelle entrée dans un journal créé auparavant. Cette activité propose de nombreuses propriétés dont 4 sont optionnelles ("Custom Field" de 01 à 04).

  • Log ID
    • Indiquer le GUID du journal auquel rajouter une nouvelle ligne
  • Runbook Name
    • Champ texte libre sur lequel de recommande d'indiquer la donnée publiée "Runbook Name"
  • Runbook Server Name
    • Champ texte libre sur lequel de recommande d'indiquer la donnée publiée "Runbook Server Name"
  • Activity Name
    • Champ texte libre sur lequel de recommande d'indiquer la donnée publiée "Activity name"
  • Activity Start DateTime
    • Champ texte libre sur lequel de recommande d'indiquer la donnée publiée "Activity start time"
  • Activity End DateTime
    • Champ texte libre sur lequel de recommande d'indiquer la donnée publiée "Activity end time"
  • Status
    • Choisir une valeur parmi "Information", "Success", "Failure", "Warning"
  • End Status Code
    • Champ texte libre sur lequel de recommande de choisir une donnée représentant l'éventuel code de retour de l'activité dont on souhaite garder les informations
  • End Status Description
    • Champ texte libre
  • Custom Field 01 / 04
    • Champ texte libre

Les données renvoyées sur le bus de données par cette activité sont les suivantes :

  • Activity End Date Time
  • Activity Name
  • Activity Start Date Time
  • Custom_Field 01 / 04
  • End Status Code
  • End Status Description
  • Log ID
  • Runbook Name
  • Runbook Server Name
  • SQL Server Database
  • SQL Server Name
  • SQL Trusted Connection
  • SQL User ID
  • Status
  • Step ID 

 

Get Log Data :

L'activité Get Log Data permet de lire un journal donné dans la base de données. La seule propriété à fournir à cette activité est le "Log ID" du journal à lire.

L'activité "Get Log Data" renvoit une collection contenant autant d'élements que de lignes dans le journal concerné. Cette activité renvoit les données suivantes sur le bus de données (Noter que tout ce qui est spécifique à la table eXtended_Logging_LOG est préfixé par "Log") :

  • Activity End Date Time
  • Activity Name
  • Activity Start Date Time
  • End Status Code
  • End Status Description
  • Log Count
  • Log Description
  • Log ID
  • Log Last Update Date Time
  • Log Name
  • Log Start Date Time
  • Log_Custom_Field 01 / 02
  • Retention Duration
  • Runbook Name
  • Runbook Server Name
  • SQL Server Database
  • SQL Server Name
  • SQL Trusted Connection
  • SQL User ID
  • Status
  • Step ID
  • Step_Custom_Field 01 / 04

 

Purge Log :

L'activité "Purge Log" a pour unique fonction de supprimer les logs périmés (ainsi que les steps associés) dans la base de données. Cette activité ne nécessite aucune propriété ; elle renvoit néanmoins les données suivantes sur le bus de données :

  • Number of Log Removed
    • Nombre de journaux supprimés par l'activité
  • SQL Server Database
  • SQL Server Name
  • SQL Trusted Connection
  • SQL User ID

 

Exemple d'utilisation :

 

La capture d'écran ci dessus montre un exemple de runbook simple mettant en oeuvre l'Integration Pack eXtended Logging. Il s'agit d'une suite de 3 activités (création d'un déploiement d'un groupe de mise à jour SCCM sur une collection donnée) dont les retours respectifs, qu'ils soient positifs ou négatifs (succès ou échec) sont enregistrés dans la base de données de journalisation. L'activité nommé "Log Get Deployment Success" dans l'exemple permet ici d'enregistrer en base de données le fait que l'activité "Get Deployment" s'est correctement déroulée, ainsi que certaines données comme ici l'ID de l'éventuel déploiement existant pour le groupe de mise à jour SCCM sur la collection donnée.

La requête SQL ci dessous montre le contenu d'un journal aprés l'exécution du runbook exemple :

SELECT FROM eXtended_Logging_STEP

WHERE LogID =(SELECT TOP(1) LogID FROM eXtended_Logging_LOG

WHERE Log_Name LIKE '%Create Deployment%'

ORDER BY LastUpdate_DateTime DESC)

ORDER BY Activity_End_DateTime

 

 

Le journal enregistré en base de données est donc composé des 3 steps ("Get SUG", "Get Deployment", et "Create Deployment On SUG"). Dans le champs "Custom_Field_02" j'ai choisi d'enregistrer l'ID (18056 dans l'exemple) du groupe de mise à jour SCCM (Software Update Group) que je récupère pendant l'exécution de l'activité "Get SUG".

 

Historique des versions :

1.0 (18/09/2014) - Première version publique
2.0 (22/03/2023) - Version 64 bits pour System Center Orchestrator 2022