Préambule : cette manipulation n’est pas supportée par Microsoft, vous ne devriez pas vous en servir sur une infrastructure de production en dehors des instructions que vous fournirait le support.
Ceci étant dit, revenons-en au sujet.
Il peut arriver que certains Management Packs aient écrit tellement de données dans la base que leur suppression via la console ou via Powershell échoue après 30 minutes de travail :
Remove-SCOMManagementPack : The requested operation timed out
On entre alors dans un cercle vicieux : plus on attend pour les supprimer, plus il y aura de données à supprimer ; sans compter que ces management packs ont la facheuse tendance à noyer la base de données et à provoquer le redouté événement 2115 (mais c’est une autre histoire…).
Heureusement, il existe une procédure stockée qui permet de supprimer un Management Pack et toutes les données qu’il a enregistrées dans la base, sans craindre de timeout : p_ManagementPackRemove.
Afin de l’exécuter, il est d’abord nécessaire de récupérer l’id du management pack à supprimer :
SELECT ManagementPackId,MPName
FROM [OperationsManager].[dbo].[ManagementPack]
where MPName like ‘%MP à supprimer%’
Puis la procédure s’appelle simplement avec la requête suivante :
exec [dbo].[p_ManagementPackRemove] ‘ManagementPackId‘
go
Il ne vous reste alors plus qu’à patienter… à titre d’exemple, la suppression du MP Dell (Detailed) sur un environnement contenant plusieurs centaines de serveurs physiques a nécessité plus de 4h !
Au programme de cet article, une nouvelle astuce méconnue : comment utiliser une propriété issue du changement d’état d’un moniteur dans une tâche de remédiation (Recovery).
Prenons pour exemple un moniteur de service tout ce qu’il y a de plus classique :
Imaginons maintenant que nous ayons besoin de déclencher une Recovery lorsque ce moniteur repasse à l’état Healthy (oui, c’est parfaitement réalisable en XML même si impossible directement dans la console), par exemple pour aller écrire le Process ID de l’exécutable sous-jacent au service dans un fichier de log.
Le PID fait partie des informations contenues dans le PropertyBag qui entraine le passage du moniteur en Healthy :
Il faudrait donc pouvoir passer la valeur de cette propriété en entrée de notre Recovery.
On pense alors immédiatement à la notation couramment utilisée pour afficher ces valeurs dans les alertes :
$Data/Context/Property[@Name=’ProcessId’]$
Malheureusement, elle ne fonctionne pas dans le cadre d’une Recovery…
La syntaxe correcte, très peu utilisée et documentée, est en réalité la suivante :
$Data/StateChange/DataItem/Context/DataItem/Property[@Name=’ProcessId’]$
Elle résulte de la structure du MonitorTaskDataType qui encapsule un PropertyBag dans un autre lors de la circulation des données dans un workflow de moniteur, tel que le montre cet exemple sur MSDN : https://docs.microsoft.com/en-us/previous-versions/system-center/developer/ee533651(v=msdn.10)
Cette astuce ne vous servira probablement pas tous les jours, mais elle m’a déjà été bien utile… peut-être vous le sera-t-elle aussi !