PI Services

Le blog des collaborateurs de PI Services

SCOM – Alertes Failed to Access the Windows Event Log Veeam Vmware

 

Des alertes « Operations Manager Failed to Access the Windows Event Log” concernant des journaux d’événements Veeam Vmware (nWorks) et provenant de serveurs de management (MS) apparaissent :

clip_image002

Elles sont complétées par des événements 26604 récurrents (toutes les 12 minutes) dans les Event Log de ces serveurs :

clip_image004

The Windows Event Log Provider is still unable to open the Veeam VMware event log on computer 'SRV0'. The Provider has been unable to open the Veeam VMware event log for 1440 seconds.

Most recent error details: The specified channel could not be found. Check channel configuration.

One or more workflows were affected by this.

Workflow name: Veeam.Virt.Extensions.VMware.VMGUEST.CollectEvents

Veeam a publié une KB concernant ce problème : http://www.veeam.com/kb1496#/kb1496

Les causes indiquées dans cette dernière ne semblent pas correspondre au contexte rencontré dans mon cas (les alertes apparaissaient sur deux nouveau MS physiques fraichement ajoutés), mais la solution proposée fonctionne malgré tout :

Dans la console Veeam, exécuter une reconstruction de la topologie Rebuild Full Topology :

clip_image006

Rien n’indiquera que la reconstruction est terminée, mais cela peut prendre plusieurs dizaines de minutes voire plusieurs heures selon la taille de votre infrastructure, mais lorsque cela sera bon les événements 26004 ne doivent plus revenir dans l’Event Log.

Il restera enfin à réinitialiser manuellement les moniteurs en erreur :

clip_image008

Orchestrator 2012 – Récupérer le JobID du runbook en cours

 

D’origine, il est possible via les common Published Data de récupérer dans n’importe quel runbook Orchestrator l’ID d’une activité ou d’un process :

clip_image002

On peut même récupérer l’ID de l’instance en cours d’exécution (Job ID) d’un runbook enfant lorsqu’il est appelé via l’activité Invoke Runbook :

clip_image004

Par contre, il n’y a rien de prévu pour récupérer l’ID de l’instance en cours d’exécution du runbook courant.

Ce Job ID du runbook courant peut cependant avoir son utilité, par exemple à des fins de logging et debug. Dans mon cas, il s’agissait de récupérer le nom de la personne ayant démarré le runbook via le portail self-service EUPSCO.

Il est donc malgré tout possible de récupérer cet ID, en intégrant la requête SQL suivante dans une activité Query Database :

SELECT POLICYINSTANCES.JobID
FROM  POLICYINSTANCES INNER JOIN
ACTIONSERVERS ON POLICYINSTANCES.ActionServer = ACTIONSERVERS.UniqueID
WHERE     (POLICYINSTANCES.ProcessID = <Activity process ID from "Initialize Data">) AND (ACTIONSERVERS.Computer = '<Runbook Server name from "Initialize Data">') AND (POLICYINSTANCES.Status IS NULL)

clip_image006

Explication : cette requête interroge la base de données en lui fournissant l’Activity Process ID (qui est disponible nativement via les Common Published Data) afin de retrouver quel JobID contient cet Activity PRocess ID.

Il peut toutefois arriver que le Process ID soit présent plusieurs fois à l’identique dans la base, c’est pourquoi on filtre un peu plus en indiquant le nom du serveur qui exécute le runbook (Runbook Server Name dans les Common Published Data) et surtout en spécifiant le status « NULL », c’est-à-dire que l’on ne recherche que parmi les runbooks qui sont en cours d’exécution et qui n’ont donc pas encore un statut “success”, “warning” ou “failed”

Si tout s’est bien passé, le champ Full line as a string with fields separated by ‘ ;’ présent en sortie de l’activité Query Database devrait contenir le JobID de votre instance de runbook en cours d’exécution, à vous de le réutiliser à votre guise plus loin dans votre runbook !

SCOM 2012 – Erreur lors de l’installation du MP Lync/SFB 2015

 

Le MP Skype For Business (Lync) 2015 est sorti récemment, mais il ne dispose d’aucune documentation.

Son installation coté SCOM reste des plus classique (import de deux fichiers .mp, activation du mode proxy sur tous les agents de l’infrastructure SFB), mais un problème peut survenir sur les serveurs Edge :

image

[Skype] An internal exception has occurred during discovery.

Ce qui correspond à l’événement suivant :

image

An exception occurred during discovery script, Exception : Could not connect to SQL server : [Exception=System.Data.SqlClient.SqlException (0x80131904): Cannot open database "xds" requested by the login. The login failed.

Login failed for user 'NT AUTHORITY\NETWORK SERVICE'.

Cette erreur induit quelque peu en erreur car elle laisse à penser qu’il s’agit de permissions SQL à rajouter.

En réalité, pour résoudre ce problème, rajoutez simplement le compte Network Service aux groupes locaux RTC Component Local Group et RTC Local Administrators (vous pouvez d’ailleurs constater qu’il est normalement bien présent dans ces groupes sur les serveurs du réseau interne).

clip_image006

Enfin, redémarrez l’agent SCOM sur ces serveurs (service Microsoft Monitoring Agent).

SCOM – Des scripts n’arrivent pas à accéder aux cmdlet powershell SCOM

 

Il peut arriver que des scripts soient incapable d’appeler les cmdlet SCOM.

Dans mon cas, ce problème a été remarqué à cause du Management Pack Service Bus v1.1 et plus précisément à cause de la définition de son moniteur (UnitMonitorType) nommé Related Objects Health State, mais il aurait pu s’agir de n’importe quel script exécuté par un Management Pack ou non.

Il se traduisait ici par des évènements Error avec l’ID 4101 dans le journal d’évènements Operations Manager :

clip_image002

Managegement Group: xxx. Script: RelatedObjectsHealthStateMonitorScript\Main : Error occured during Related Objects Health State monitoring.

Computer:yyy

Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Voyons comment fonctionne ce Monitor Type. Il est basé sur un script powershell qui commence par les commandes suivantes :

param($objectId, $relationshipId, $relatedObjectClassId, $relatedObjectMonitorId, $ignoreUnavailable, $ignoreInMaintenanceMode)
#TODO: Discuss event id
$SCRIPT_EVENT_ID = 4101 
#Event Severity values
$INFORMATION_EVENT_TYPE = 0
$ERROR_EVENT_TYPE = 1 
function GetRelatedObjectsHealthState7Version
{
param
(
$objectId,
$relationshipId,
$relatedObjectClassId,
$relatedObjectMonitorId,
[bool]$ignoreUnavailable,
[bool]$ignoreInMaintenanceMode
)
Import-Module -Name "OperationsManager"
$constUnintializedHealthState = "Uninitialized"
$constSuccessHealthState = "Success"
$constWarningHealthState = "Warning"
$constErrorHealthState = "Error"
#
# Get Relationship
#
$relationship = Get-SCOMRelationship -Id $relationshipId
if($relationship -eq $null)
{
$exceptionMsg = "Relationship with Id {0} not found." -f $relationshipId
$argumentException = New-Object System.ArgumentException -ArgumentList $exceptionMsg 
throw $argumentException
}

Les premières cmdlet SCOM réellement exécutées sont celles surlignées en jaune , les autres lignes ne sont que des définitions de variables ou des appels indépendants de SCOM.

Or, l’évènement indique un échec dès l’appel du cmdlet Get-SCOMRelationship : Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program.

On peut donc supposer qu’en réalité, le script n’a pas été en mesure de charger le module OperationsManager et qu’il ne reconnait donc pas le cmdlet.

On constate également que l’import manuel du module OperationsManager dans un shell PowerShell échoue.

Vérifions donc qu’il est bien présent sur le serveur où remonte l’alerte. Il doit se trouver dans le dossier d’installation de SCOM, sous-dossier Powershell > OperationsManager :

clip_image004

Le module existe bien.

Vérifions maintenant qu’il est bien enregistré dans la variable d’environnement $env:PSModulePath :

clip_image006

Manifestement, il est bien enregistré… Mais pas au bon endroit !

En effet, la variable d’environnement pointe vers C:\Program Files\System Center 2012\Operations Manager\Powershell\ alors que le module se trouve en réalité dans C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager !

La solution est alors toute trouvée : rajouter le bon chemin à la variable d’environnement à l’aide des commandes suivantes :

$originalpaths = (Get-ItemProperty -Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath).PSModulePath

$newPath=$originalpaths+’;C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\’

Set-ItemProperty –Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath –Value $newPath

Il ne reste plus qu’à redémarrer le serveur pour que la modification soit prise en compte et le problème résolu !

Orchestrator – Ajouter des images au corps du mail

 

Lors de l’envoi d’un email dans Orchestrator à l’aide de l’activité Send Email, il est possible de choisir entre de choisir entre le format texte brut et le format HTML pour le corps du mail, dans l’onglet Advanced :

clip_image002

Il devient alors tout naturel de vouloir y intégrer des images à l’aide de la balise HTML <img> , afin d’enrichir encore la mise en page.

Il est alors possible d’avoir recours à plusieurs méthodes : la plus classique consiste à stocker ces images à un endroit accessible par tous les destinataires du mail (site web, partage réseau…) ; mais cette technique présente différents inconvénients : les images sont inaccessibles si l’accès à la source n’est pas disponible au moment de la lecture du mail, la plupart des clients mail bloquent leur chargement par défaut…

Une autre solution consiste à intégrer directement ces images dans les pièces jointes, et à les appeler à l’aide d’un Content ID (CID) au lieu d’un lien réseau ou http, à l’aide de la syntaxe suivante : <img src=’’cid:nomdelimage.jpg’’ />

clip_image003

clip_image005

Et c’est tout, les images seront désormais visibles dans le corps du mail. Encore mieux : selon le client mail utilisé, elles n’apparaitront même pas dans les pièces jointes !

Assurez-vous toutefois bien que le serveur Orchestrator soit lui toujours en mesure d’accéder aux images, il les recharge à chaque appel de l’activité Send Email.

SCOM - Créer une vue avec un filtre « NOT »

 

Tout administrateur SCOM qui se respecte a déjà été amené à créer des vues d’alerte ou d’état spécifiques, ciblées sur une classe et filtrées en fonction d‘un niveau de résolution (resolution state), d’une criticité…

clip_image001

clip_image002

Une problématique revient cependant de temps en temps : comment créer une vue qui exclue spécifiquement certaines alertes en fonction de leur nom ?
Autrement dit, comment afficher toutes les alertes SAUF celles correspondant à un certain nom ?

Le filtre « with a specific name » ne permet à première vue pas de réaliser cette exclusion ; il semble plutôt prévu pour fonctionner en mode « inclusif » : seules les alertes répondant à la chaine de caractères entrée seront affichées :

clip_image004

Mais il est en réalité possible d’utiliser une expression d’exclusion dans ce champ, en plus des wildcards « SQL », à l’aide de la syntaxe suivante :

[^AlerteAExclure]

clip_image006

Voici le résultat obtenu :

clip_image008

Il est également possible de combiner plusieures exclusions à l’aide du symbole « pipe » :

[^(AlerteAExclure)|(TestAlert2)]

Attention toutefois, cette astuce exclut en réalité un groupe de caractères et ne supporte donc pas l’utilisation d’espaces.

SCOM - Création et peuplement dynamique de groupes à partir d’une clé de registre

 

Note : cet article est inspiré et enrichi de la solution proposée par Jan Van Meirvenne sur son blog.

Une pratique assez courante en entreprise consiste à publier des informations sur les serveurs (rôle, site géographique…) dans des clés de registre « fiches d’identité » créées à cette fin.

Il est alors pertinent de créer des groupes SCOM correspondant à ces clés, afin de pouvoir créer des overrides, de cibler des rôles… en fonction de l’organisation logique déjà en place.

La solution la plus évidente, supportée nativement et réalisable aisément via la console SCOM consiste à étendre la classe Windows Computer à l’aide d’attributs personnalisés, peuplés à partir des clés de registre ; puis à créer des groupes contenant des instances de cette nouvelle classe étendue en filtrant en fonction du contenu de l’attribut étendu.

Cette solution reste cependant fastidieuse : dans le cas d’un grand nombre d’informations différentes (nombreux sites géographiques ou rôles serveur), créer puis maintenir à jour des dizaines de groupes s’avère complexe et peu fiable.

C’est pourquoi il est très intéressant de créer et peupler ces groupes automatiquement.

Commençons par revenir sur ce qu’est un groupe « normal » dans le modèle SCOM : contrairement à la plupart des objets qui sont des instances de classe créées automatiquement par des règles de découverte et hébergées au niveau de l’agent exécuté sur le serveur où se trouve l’objet (par ex une instance de la classe serveur windows, site IIS etc. ), les groupes sont créés de manière unique lorsque vous utilisez l’assistant correspondant et sont hébergés par les Management Servers : ils ne sont pas découverts, ils « commencent à exister » une fois l’assistant terminé.

Ce fonctionnement est propre aux classes qui possèdent l’attribut « singleton », ce qui en fait des classes qui sont également des objets.

Revenons maintenant à notre problème : nous souhaitons créer des groupes basés sur une règle de découverte classique, avec de multiples instances découvertes : il s’agit donc simplement de créer une classe qui dérive de la classe Microsoft.SystemCenter.InstanceGroup (comme tous les groupes), mais qui n’aurait cette fois pas l’attribut singleton.

Il est également nécessaire d’ajouter une propriété clé (key property) à notre classe : cela permet de ne créer qu’une seule instance de la classe même si la propriété est découverte à l’identique sur plusieurs agents ; autrement dit dans notre cas de ne créer qu’un seul groupe correspondant à un attribut géographique même si cet attribut géographique est retrouvé sur de multiples serveurs.

<ClassType ID="TEST.DynamicGroups.Group" Accessibility="Public" Abstract="false" Base="GroupLib!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="false" Extension="false">

<Property ID="Territory" Type="string" AutoIncrement="false" Key="true" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />

</ClassType>

Maintenant que la classe est définie, nous allons pouvoir nous pencher sur la découverte qui découvrira ses instances. Et tant qu’à faire, nous en profiterons pour découvrir également les objets Windows.Computer qui peupleront ces groupes ainsi que la relation qui liera les groupes aux ordinateurs.

La découverte se fera à l’aide d’un script VBS, la seule possibilité pour découvrir à la fois le groupe, l’ordinateur et la relation : évitez donc de définir un intervalle d’exécution trop court pour ne pas surcharger vos agents!

Notez que pour que cette découverte fonctionne, il sera nécessaire d’activer le mode proxy pour tous les serveurs qui seront concernés.

Pensez à modifier la partie en jaune, elle concerne la clé de registre à interroger pour récupérer la valeur qui déterminera le nom du groupe.

<Discovery ID="TEST.DynamicGroups.Group.Discovery" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

<Category>Discovery</Category>

<DiscoveryTypes>

<DiscoveryClass TypeID="TEST.DynamicGroups.Group" />

</DiscoveryTypes>

<DataSource ID="GroupDiscoveryDS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">

<IntervalSeconds>86400</IntervalSeconds>

<SyncTime />

<ScriptName>discoverdynamicgroups.vbs</ScriptName>

<Arguments>$MPElement$ $Target/Id$ $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments>

<ScriptBody>

SetLocale("en-us")

Dim oAPI
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim oArgs
Set oArgs = WScript.Arguments

if oArgs.Count &lt; 3 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",101,1,"Script was called with fewer than three arguments and was not executed.")

Wscript.Quit -1

End If

Dim SourceID, ManagedEntityId, TargetComputer

SourceId = oArgs(0)

ManagedEntityId = oArgs(1)

TargetComputer = oArgs(2)

Dim oDiscoveryData, oInstManagedServer,oInstServerGroup,Territory,arrSubKeys

'Lecture de la clef d’identification dans la base de registre

Const HKEY_LOCAL_MACHINE = &amp;H80000002

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\localhost\root\default:StdRegProv")

oReg.GetStringValue HKEY_LOCAL_MACHINE,"SOFTWARE\TEST\ID_CARD","Territory",Territory

'Construction du nom du groupe et attribution d’une valeur par defaut si clef vide

If IsNull (Territory) Then Territory = "NA"

GroupName = "TEST - TERRITORY - " &amp; Territory

'Ajout de l’instance de l’objet Computer au propertybag

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceID, ManagedEntityID)

set oInstManagedServer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstManagedServer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstManagedServer)

'Ajout de l’instance de l’objet Group au propertybag

set oInstServerGroup = oDiscoveryData.CreateClassInstance("$MPElement[Name='TEST.DynamicGroups.Group']$")

call oInstServerGroup.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", GroupName)

call oInstServerGroup.AddProperty("$MPElement[Name='TEST.DynamicGroups.Group']/Territory$", Territory)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oDiscoveryData.AddInstance(oInstServerGroup)

'Ajout de la relation entre l’objet Computer et l’objet Group

Dim oInstWindowsComputer

set oInstWindowsComputer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstWindowsComputer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstWindowsComputer)

Set oRelationship = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='GroupLib!Microsoft.SystemCenter.InstanceGroupContainsEntities']$")

oRelationship.Source = oInstServerGroup

oRelationship.Target = oInstWindowsComputer

Call oDiscoveryData.AddInstance(oRelationship)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup to Computer relationship (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oAPI.Return(oDiscoveryData)

</ScriptBody>

<TimeoutSeconds>600</TimeoutSeconds>

</DataSource>

</Discovery>

Le gros de la problématique est maintenant couvert, il ne vous reste plus qu’à intégrer cela à vos propres management packs !

Une dernière note : vu l’utilisation qui sera en général faite de ce MP (overrides, délégations, ciblage pour des vues spécifiques…), il peut s’avérer judicieux de le sceller afin d’être en mesure d’y faire référence depuis d’autres MP.

SCOM - L’import d’un MP échoue avec une erreur vide

Lorsque l’on développe ses propres Management Packs, il arrive fréquemment que l’importe échoue pour des raisons diverses (bout de code oublié, mal placé, mauvaise référence…).

Dans ces cas, l’assistant d’importation des MP retourne normalement une erreur plus ou moins explicite qui permet, après un peu de déchiffrage et avec l’habitude, de localiser assez efficacement la cause du problème.

J’ai par contre été confronté aujourd’hui à un cas inhabituel : après l’ajout manuel (en modifiant le code XML directement à l’aide d’un éditeur de texte) d’une règle à un MP pré-existant, l’assistant a refusé l’import avec une erreur “vide” (ou pour ainsi dire sans erreur ) :

image

 

Après quelques heures de questionnements existentiels, de relecture de mon code, de tests en recréant la règle dans un autre MP (là, ca fonctionnait!), j’ai fini par mettre le doigt sur le problème :

La règle que j’avais ajouté contenait un Consolidator (d’où la création manuelle et pas via la console de SCOM), qui était appelé via la ligne

<ConditionDetection ID=”CD” TypeID=”System!System.ConsolidatorCondition”>

Alors que dans mes déclarations de références, le MP System.Library était déclaré avec l’alias SystemLibrary7585010 et non pas System.

Visiblement, l’assistant d’import de MP n’a pas su me signaler cette simple erreur de référence dans ce contexte précis, alors qu’il en est normalement parfaitement capable…

Une erreur bête qui m’aura tout de même fait perdre plusieurs heures!

Orchestrator 2012 - Récupérer la sortie brute d’une activité Run .NET Script

Dans Orchestrator, l’activité Run .NET Script permet d’exécuter des scripts dans différents langages (Powershell, VB .NET, JScript…) ce qui se révèle très utiles dans les nombreux cas où les activités apportées par les différents Integration Pack se révèlent insuffisantes pour effectuer les tâches dont vous avez besoin.

Cependant, il peut vite devenir compliqué de débugger ces scripts puisque l’activité Run .NET Script ne publie pas le résultat brut de leur exécution dans le databus : impossible alors de savoir où le script a échoué!

En revanche, ce que cette activité peut publier à l’aide de sa fonctionnalité Published Data, c’est le contenu de n’importe quelle variable que contient le script exécuté.

Il ne reste donc plus qu’à utiliser ce fonctionnement afin de stocker le résultat d’exécution du script dans une variable et de la publier via les Published Data.

Prenons l’exemple de ce script Powershell, un simple compteur qui ne présente pas d’intérêt autre que de produire une sortie sur plusieurs lignes :

for ($i=0; $i -le 10; $i++) {write-host $i}

image

 

Il suffit de l’encapsuler comme suit pour récupérer cette sortie dans Orchestrator :

$result = Powershell { for ($i=0; $i -le 10; $i++) {write-host $i} }

image

Puis de publier la variable result dans les Published Data :

image

 

La sortie du script est donc désormais publiée dans le databus.

On peut ensuite la récupérer dans un fichier texte à l’aide de l’activité Append Line, dans un évènement avec Send Event Log Message etc. Attention car dans ce second cas, un évènement sera créé pour chaque ligne si le mode Run Behavior > Flatten n’est pas utilisé!

Prenons l’exemple du fichier texte :

image

On voit bien que l’activité Append Line est appelée une fois par ligne contenue dans la variable result car le flatten n’est pas activé :

image

Et le résultat final :

image

Evidemment, cette astuce sera beaucoup plus utile pour des scripts réels!

SCOM 2012 - Erreur lors de la découverte d’un serveur CentOS 7

A l’occasion du déploiement d’agents Linux à partir d’une infrastructure SCOM 2012 R2 UR4, un client a rencontré le problème suivant pour les serveurs exécutant la distribution CentOS 7 :

image

Failed during SSH discovery. Exit code: 2
Standard Output:
Standard Error: /etc/centos-release: line 1: syntax error near unexpected token `(‘
/etc/centos-release: line 1: `CentOS Linux release 7.0.1406 (Core) ‘
Exception Message:

Il reste possible de procéder à une installation manuelle de l’agent, mais cette solution est beaucoup moins pratique et plus longue.

Pour comprendre d’où provient cette erreur, il est nécessaire de comprendre au préalable que le processus de découverte d’un serveur Linux est réalisé par le script GetOSVersion.sh, disponible dans le dossier d’installation de SCOM : C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents

Lors de la découverte, ce script est copié et exécuté sur les serveurs à découvrir et tente principalement d’identifier la version de Linux exécutée par le serveur afin d’y déployer l’agent approprié.
Pour ce faire, il cherche à récupérer le contenu du fichier standardisé os-release qui contient des informations sur le système, à l’aide des lignes suivantes dans le cas d’un CentOS :

image

Le souci, c’est que la variable . $ReleaseFile pointe vers un fichier nommé centos-release qui contient, ô surprise, la ligne CentOS Linux release 7.0.1406 (Core) à la place des informations attendues au format TAG=VALUE.

Informations qui se trouvent par contre bien dans le fichier os-release… il ne reste alors qu’à corriger le script afin qu’il pointe vers le bon fichier, en remplaçant la ligne
. $ ReleaseFile
Par la ligne
. ${EtcPath}/os-release
Ce qui donne ce résultat :

image

 

Répétez cette opération sur tous les serveurs du Management Pool Linux et votre découverte ne devrait désormais plus poser de problème!

Attention! Cette modification n’est pas supportée par Microsoft et n’a pas été testée en profondeur, elle pourrait donc provoquer d’autres problèmes dans  des contextes différents! 
Par ailleurs, il y a de fortes chances que le fichier GetOSVersion.sh soit écrasé lors de l’installation de mises à jour futures. Il serait alors nécessaire de réappliquer la modification détaillée ici, si Microsoft n’apporte pas de correction.

Merci à Stéphane J. pour son implication sur cette problématique Linux assez spécifique!