Après avoir définit les paramètres et le déploiement de l'OS de notre VM de référence dans les articles précédents, nous allons pouvoir créer un disque de différentiation.

1. Créer un disque de différentiation.

Dans la console Hyper-V Manager faites « New », « Virtual Hard Disk »

Choisissez le format du Disque (dans notre cas VHDX) et faites « Next »

Pour le type de disque nous choisirons donc « Differencing » avant de faire « Next »

Donnez un nom au disque et sélectionnez le répertoire dans lequel il sera créé

Dans configure Disk sélectionnez « Browse… »

Indiquez ensuite l’emplacement du disque de référence créé dans les étapes précédentes (Partie 1) et faites « Next »

Lisez le résumé puis faites « Finish »

Maintenant que le disuqe est créé nous pouvons passer à la VM.

2. Création d'une VM.

Sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».

Dans la fenêtre « Before you Begin » faites « Next »

Dans la fenêtre « Specify Name and Location » donnez un nom à votre VM (pour moi VM01) et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »

Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »

Faites « Next »

Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »

Assignez une quantité de RAM à la VM et faites « Next ».

Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».

Dans la configuration du disque dur choisissez « Use an existing virtual hard disk », puis faites « Browse... ».

Sélectionnez le disque créé pour la VM dans l'étape 1 puis « Open »

Faites « Next »

Faites « Finish »

Après avoir définit les paramètres de la VM dans le précédent article nous allons maintenant déployer l'OS de notre VM de référence.

1. Déploiement de l'OS.

1- Connectez vous à la VM et démarrez-la.

2- Sélectionnez la langue d’installation du système d’exploitation (s’il vous plait Anglais cela évitera les problèmes plus tard) puis le fuseau horaire et la langue du clavier (cette fois-ci vous pouvez mettre Français) et enfin faites « Next »

3- Cliquez sur « Install Now »

4- Sélectionnez la version de l’OS à installer (Core ou Graphique) et la version de licence correspondante (Standard ou Datacenter) et faites « Next »

5- Cochez « I accept the license term agreement” et faites « Next »

6- Sélectionnez « Custom: Install Windows only (advanced) »

7- Sélectionnez le disque et faites « Next »

8- Attendez la fin de l’installation

9- Entrez un mot de passe Admin local

Une fois l’installation terminé, identifiez vous sur la machine (je ne mets pas à jour l’OS car au moment où je rédige ces lignes Windows Server 2019 viens juste de sortir), nous allons donc directement passer au Sysprep.

2. Sysprep

Pour réaliser un sysprep de la machine, allez dans « C:\Windows\System32\Sysprep » et exécuter « Sysprep.exe ».

Lorsque la fenêtre apparait cochez la case « Generalize » et sélectionnez « Shutdown » et faites « OK »

Attendez l’extinction de la VM puis dans « Hyper-V Manager » supprimez la, cette action vous évitera de rallumer la VM par inadvertance (ce qui poserait problème pour toutes les machines configurées à l'aide du disque de référence).

Maintenant que le disque de référence a été créé nous allons pouvoir créer les nouveaux disques et VMs, nous verrons cela dans la partie 3.

Un environnement homogène avec des OS installé en Anglais, c'est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l'opportunité d'avoir tous les OS dans la même version et pire encore dans la même langue d'installation.

Quel impact ?

Même si pour certain, installer un OS en Français est plus "Confortable / facile d'administration", en terme de "recherche / résolution" d'incident on est quand même nettement moins bien aidé (entre les messages d'erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l'anglais peut vous faire perdre quelques heures).

Des Exemples :

Prenons un exemple simple l'activation ou la désactivation du "SID Filtering" dans un "Trust" entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Vous l'avez ?

Et oui la commande est quasi identique puisqu'elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c'est que si vous passez la commande en Anglais avec les arguments en Anglais, l'OS vous dira que la commande s'est terminée avec succès même si ce n'est pas le cas; mais dans la pratique cette dernière aura échouée.

Alors de grâce ayez le réflex lors d'une installation serveur de sélectionner un Iso en Anglais et de l'installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

Bref rappel : Azure DNS est un service PaaS qui propose d’héberger vos zones DNS sans que vous n’ayez besoin de vous préoccuper de la gestion de l’infrastructure sous-jacente.

De plus, comme tout service « cloud », il est possible de gérer ces zones et leurs entrées à l’aide d’une API REST, ce qui apporte une flexibilité certaine face au fonctionnement encore un peu archaïque du service Windows DNS dont la gestion passe nécessairement par la MMC DNS ou par Powershell, voire par l’utilisation de dnscmd.exe pour ceux d’entre vous qui lisent cet article en 1992.

Microsoft a introduit il y a quelques mois un type de zone « Private » à ce service, permettant ainsi d’héberger des zones qui ne seraient pas résolvables depuis l’extérieur de votre environnement ; mais ce mode souffrait de lacunes sérieuses, qui le rendaient inexploitable dans un contexte réel :

• Il n’était disponible qu’en Powershell
• Seules les requêtes provenant d’un unique VNet avaient le droit de créer des entrées dans une zone donnée
• Seuls 10 VNet avaient le droit de lire les entrées d’une zone donnée
• Ces VNet devaient être déclarés manuellement
• Ces VNet ne devaient contenir aucune ressource au moment de leur déclaration (!!)
• Les enregistrements étaient invisibles via powershell ou l’API REST, mais étaient bel et bien resolvables
• … etc.

Une mise à jour majeure est apparue la semaine dernière, et elle corrige la majorité de ces défauts :

• On peut désormais créer les zones privées directement dans le portail Azure
• On peut lier jusqu’à 1000 VNet à une zone privée, même si ces VNet contiennent déjà des ressources ; et les notions de VNet « enregistreur » ou « requêteur » disparaissent
• On peut désormais accéder aux enregistrements via l’API ou Powershell

Bref, on peut maintenant raisonnablement utiliser ce service dans un environnement réel… mais attention tout de même, il est toujours en Public Preview et susceptible d’évoluer n’importe quand !

Notez également que la résolution dans une zone Private DNS ne fonctionne par défaut que si votre VNet est configuré pour utiliser la résolution DNS native d’Azure.

Si vous utilisez une résolution « Custom » (un contrôleur de domaine déployé dans votre tenant par exemple), il faudra créer un conditional forwarder pour votre zone Private DNS, pointant vers l’IP d’Azure DNS (unique pour tous les tenant et toutes les régions) : 168.63.129.16

Enfin, comme la résolution dans une zone Private DNS n’est possible que depuis un VNet, il faudra également prévoir un forwarder différent sur les serveurs DNS de votre Lan si vous souhaitez pouvoir résoudre depuis cet emplacement !

L’occasion idéale pour mettre en place une partition DNS à réplication limitée…

Les partitions DNS intégrées à Active Directory, permettant ainsi leur réplication et leur gestion sur tous les contrôleurs de domaine disposant du rôle DNS, sont depuis longtemps la norme dans un environnement Windows.

Il existe cependant une possibilité moins connue de ce mécanisme : la partition DNS « custom », qui permet de définir un scope de réplication limité à seulement un ou quelques contrôleurs de domaine de votre choix.

J’ai eu recours à cette possibilité afin de résoudre un problème lié à l’utilisation de Conditional Forwarders que vous pourriez bien rencontrer dans votre propre environnement sans même le savoir : les Conditional Fowarders sont répliqués dans toute votre forêt de la même façon que les zones DNS « classiques » (foward et reverse), mais si vous en utilisez il est fort possible que seuls certains de vos contrôleurs de domaine soient réellement en mesure de les atteindre en raison de contraintes réseaux propres à votre environnement.

Il devient alors nécessaire de limiter la réplication de ces Conditional Forwarders aux seuls serveurs DNS qui y ont accès !

La création d’une partition DNS se fait uniquement en powershell (en tant qu’administrateur) :

Add-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

Il est ensuite nécessaire d’y ajouter les contrôleurs de domaine qui répliqueront cette partition :

Register-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition" -ComputerName "DC01.cogip.com"

Répétez cette opération pour chaque contrôleur pour lequel vous souhaitez activer la réplication sans trop prêter attention aux possibles erreurs que vous pourriez obtenir : ca marche quand même (… normalement !) ; puis vérifiez justement que les serveurs sont bien ajoutés à la zone :

Get-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

Il est désormais possible de créer ou de déplacer un conditional forwarder dans cette partition, simplement à l’aide de la MMC DNS :

Attention : dans le cas du déplacement d’un forwarder existant déjà, assurez -vous qu’il n’est pas protégé contre la suppression ! Si c’est le cas, le déplacement échouera avec un message peu explicite, et toutes les tentatives successives échoueront également même si vous retirez la protection entre temps ! La seule solution sera ici d’utiliser ADSI Edit pour aller faire le ménage dans la partition DC=ConditionalForwardersPartition …

La création d’un conteneur Blob dans un compte Azure Storage est une opération devenue plutôt banale, mais qui peut toutefois encore donner lieu à des messages d’erreur assez cryptiques :

Failed to create blob container.

Details : This request is not authorized to perform this operation.

Le message d’erreur pourrait laisser penser à un manque de droits, mais l’utilisateur dispose bien de permissions suffisantes dans ce Storage Account.

Par contre, dans le cas qui nous intéresse ici, le filtrage par adresse IP est activé sur le Storage Account utilisé, et la VM qui tente d’accéder au Storage Account est déployée dans un tenant Azure différent ; le filtrage est donc réalisé à l’aide de l’IP publique de la VM :

Or, les connexions entrantes dans le storage account sont s-natées à l’intérieur d’un même Datacenter Azure, comme indiqué ici : https://github.com/MicrosoftDocs/azure-docs/issues/10359 . Ce n’est donc pas l’IP publique de la VM qui se présente en entrée du Storage Account, et cela explique le blocage rencontré…

Deux solutions sont toutefois disponibles :

• Déployer le Storage Account dans une région Azure différente de celle de la VM : ca sera alors bien l’IP publique de cette dernière qui se présentera en entrée du Storage Account
• Utiliser le filtrage par VNET à la place du filtrage par IP. Cette solution reste possible même si le VNET de la VM est dans un tenant différent de celui du Storage Account, mais il faudra que l’utilisateur qui réalise la configuration dispose de permissions spécifiques sur le VNET de la VM : https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security#grant-access-from-a-virtual-network

Le cas présenté ici, peut être indépendant de l'outil de monitoring. Il s'agit de devoir alerter et donc définir des seuil sur une donnée qui est présenté par défaut sous forme de texte.

Pour être un peu plus clair, dans le contexte, un équipement snmp renvoi l'information d'utilisation de son file system sous la forme suivante:

"/tmp=0, /var=26, /var/log=0, /=22"

il s'agit en effet de la valeur de l'OID atpDiskUsage dans la MIB ATP-SNMP-MIB (Symantec Advanced Threat Protection)

Pour pouvoir traiter les valeurs d'utilisation du file system comme des nombre, les expressions régulières sont d'un grand secours.

Supposons que l'on veuille alerter sur le fait que "/var" soit au dessus de 80.

Dans ce cas l'expression proposé est la suivante régulière sera la suivante:

^.*(\/var=)[8-9][0-9]|100,.*$

Explication --> ^ : début de chaine

                      .*(\/var=) : n caractère n fois, suivi de "/var="  (on doit échapper le caractère '/' avec '\')

                      [8-9][0-9] : le range de chiffre est de 80 a 99

                      |100 : ou bien sur 100.

                       ,.* : la virgule présente, suivi de n caractère n fois

                       $: fin de chaine

Ce qui, pour nos 4 points de montage du file system donnera:

^.*(\/var=)[8-9][0-9]|100,.*$

^.*(\/tmp=)[8-9][0-9]|100,.*$

^.*(\/var\/log=)[8-9][0-9]|100,.*$

^.*(\/=)[8-9][0-9]|100.*$

Dans le contexte de Zabbix, Les expressions régulières ci-dessus ont donc été intégrées chacune dans un trigger utilisant la fonction "regexp() - Regular expression matching last value in period (1- match, 0 - not match)".

Indépendamment de l'outil de supervision, n'hésitez pas a user et abuser d'un outil de construction de regex tel que https://regex101.com/

Le script ci-dessous intègre la requête SQL de récupération des instances d'une machine, sous forme de fonction.

All_InstancesForOneAgent_vSQLQuery.ps1

# SCRIPT THAT QUERY SCOM DATABASE TO GET ALL INSTANCES OF ALL CLASSES FOR A GIVEN COMPUTER ($TargetAgent)
# $TargetComputer must be Short name of computer because we look for this specific string in name, displayname and path of instances.

param(
#Short name of computer
$TargetComputer = "MyComputer"
)


# Function  Invoke-InstancesFromSQL

Function Invoke-InstancesFromSQL
                            {
                                param(
                                    [string]$dataSource = "MyScomSQLServer\OPSMGR",
                                    [string]$database = "OperationsManager",
                                    [string]$TargetComputer,
                                    [string]$sqlCommand = 
                                            $("Use $Database
                                                SELECT 
                                                   MTV.DisplayName as ClassName
	                                               ,MEGV.Path as Instance_Path
	                                               ,MEGV.Id as Instance_Id
	                                               ,MEGV.[DisplayName] as 'Entity_DisplayName'
	                                               ,MEGV.[Name] as 'Entity_Name'
	                                               ,MEGV.[FullName] as Entity_FullName
                                                   ,[IsManaged]
                                                   ,[IsDeleted]
                                                   ,HealthState = 
													CASE WHEN InMaintenanceMode = '0'
														  THEN 
															CASE [HealthState]
															WHEN '0' THEN 'Not Monitored'
															WHEN '1' THEN 'OK'
															WHEN '2' THEN 'Warning'
															WHEN '3' THEN 'Critical'
															END
														WHEN InMaintenanceMode = '1'
														THEN 
															CASE [HealthState]
															WHEN '0' THEN 'In Maintenance Mode'
															WHEN '1' THEN 'OK'
															WHEN '2' THEN 'Warning'
															WHEN '3' THEN 'Critical'
															END
													END
                                                  ,Is_Available = CASE [IsAvailable]
			                                            WHEN '1' THEN 'YES'
			                                            WHEN '2' THEN 'NO'
			                                            END
                                                  
                                                  ,In_MaintenanceMode = CASE [InMaintenanceMode]
			                                            WHEN '0' THEN 'NO'
			                                            WHEN '1' THEN 'YES'
			                                            END
                                                  
                                                  ,Start_Of_Maintenance = CASE WHEN InMaintenanceMode = '0' 
			                                            THEN null
			                                            ELSE MMV.StartTime
			                                            END
	                                              ,End_Of_Maintenance = CASE WHEN InMaintenanceMode = '0'
			                                            THEN null
			                                            ELSE MMV.ScheduledEndTime
			                                            END
                                                  	                                              
                                                  ,Maintenance_RootCause = 
														CASE WHEN InMaintenanceMode = '0'
														  THEN null
															ELSE 
																CASE MMV.ReasonCode
																WHEN '0' THEN 'Other (Planned)'
																WHEN '1' THEN 'Other (Unplanned)'
																  WHEN '2' THEN 'Hardware: Maintenance (Planned)'
																  WHEN '3' THEN 'Hardware: Maintenance (Unplanned)'
																  WHEN '4' THEN 'Hardware: Installation (Planned)'
																  WHEN '5' THEN 'Hardware: Installation (Unplanned)'
																  WHEN '6' THEN 'Operating System: Reconfiguration (Planned)'
																  WHEN '7' THEN 'Operating System: Reconfiguration (Unplanned)'
																  WHEN '8' THEN 'Application: Maintenance (Planned)'
																  WHEN '9' THEN 'Application: Maintenance (Unplanned)'
																  WHEN '10' THEN 'Application: Installation (Planned)'
																  WHEN '11' THEN 'Application: Unresponsive'
																  WHEN '12' THEN 'Application:  Unstable'
																  WHEN '13' THEN 'Security Issue'
																  WHEN '14' THEN 'Loss of network connectivity (Unplanned)'
																END
															END
                                                  
		                                            ,Maintenance_Reason =   
														CASE WHEN InMaintenanceMode = '0' 
														    THEN null
															    ELSE MMV.Comments
														END
	  
      
                                              FROM [OperationsManager].[dbo].[ManagedEntityGenericView] MEGV

                                              INNER JOIN [dbo].[ManagedTypeView] MTV on MEGV.MonitoringClassId = MTV.Id
                                              INNER JOIN [OperationsManager].[dbo].[MaintenanceModeView] MMV on MEGV.id = MMV.BaseManagedEntityId
                                              WHERE (MEGV.Name  like '%$TargetComputer%' OR MEGV.DisplayName  like '%$TargetComputer%' OR MEGV.Path  like '%$TargetComputer%')
                                              and MTV.LanguageCode = 'ENU'
                                              and MEGV.HealthState is not null
                                              and MEGV.IsDeleted <> '1'
                                              ORDER BY MTV.DisplayName
                                            ")
                                           )


                                    $connectionString = "Data Source=$dataSource; " +
                                    "Integrated Security=SSPI; " +
                                    "Initial Catalog=$database"

                                $connection = new-object system.data.SqlClient.SQLConnection($connectionString)
                                $command = new-object system.data.sqlclient.sqlcommand($sqlCommand,$connection)
                                
                                try
                                {
                                $connection.Open()
                                }
                                catch
                                {
                                write-host -F Red $("Error during sql connection - check the credentials used").ToUpper()
                                exit 1
                                }

                                $adapter = New-Object System.Data.sqlclient.sqlDataAdapter $command
                                $dataset = New-Object System.Data.DataSet
                                $adapter.Fill($dataSet) | Out-Null

                                $connection.Close()
                                $dataSet.Tables

                              }


[array]$table = Invoke-InstancesFromSQL -TargetComputer $TargetComputer


write-host "`nCOMPUTER: $TargetComputer"

Write-Host "`nNb Of Objects:"$table.count""

$table | ft -Property ClassName,Instance_Path,Entity_DisplayName,Entity_Name,Entity_FullName,HealthState,Is_Available,In_MaintenanceMode,Start_Of_Maintenance,End_Of_Maintenance,Maintenance_RootCause,Maintenance_Reason



# TO FILTER ON SPECIFIC CLASS
# $table | Where-Object {$_.CLASS_NAME -in ('Windows computer','Health Service Watcher','VMware vSphere Host','VMWare Virtual Machine','HPE ProLiant Server')} | ft -AutoSize



# SIMULATE START OF MAINTENANCE MODE FOR THE INSTANCES
#$table | foreach {Get-SCOMClassInstance -id $_.instance_id} | foreach {start-SCOMMaintenanceMode -instance $_ -WhatIf -EndTime $((Get-Date).AddHours(1))}

L'exemple ci-dessous utilise le module PowerShell PSBBIX qui encapsule les commandes de l'API Zabbix.

Parmi les nombreuses commandes, pour exemple, le script propose de désactiver ou activer les items (points de supervision) d'un host spécifique.

N'hésitez pas pour plus de détails a aller voir le github de PSBBIX (https://github.com/yubu/psbbix-zabbix-api)

ZabbixManageHostItems.ps1

#########################################################
### ENABLE/DISABLED ALL SPECIFIC ITEMS FOR A ZABBIX HOST
### Params:
### $ZabbixSrv: Target Zabbix Server
### $TargetHost: Target host to treat
### $ItemPattern: Pattern of Items to check
### $Action: Disable or Enable
#########################################################


Param(
[Parameter(Mandatory=$true)] $ZabbixSrv,
[Parameter(Mandatory=$true)] $TargetHost,
[Parameter(Mandatory=$true)] $ItemPattern,
[Parameter(Mandatory=$true)] $Action
)


if ($PSBoundParameters.Count -lt 4)
    {
    write-host -F Red "Too few arguments!"
    write-host -F Yellow "ZabbixSrv: Target Zabbix Server`nTargetHost: Target host to treat`nItemPattern: Pattern of Items to check`nAction: Disable or Enable"
    exit 1
    } 

switch($Action)
{
"disable" {$status = 1}
"enable" {$status = 0}
default {Write-Host -F Red "Possible value for Action is 'enable' or 'disable' - END OF SCRIPT" ; exit 0}
}



# Check if psbbix module is loaded
if (!(get-module psbbix))
    {
    write-host -F Yellow "psbbix module is not loaded...search module to load it..."
    $modulepath = $env:PSModulePath -split ‘;’ | foreach {Get-ChildItem -Recurse -Path $_ | Where-Object {$_.name -eq "psbbix.psm1"}}
    if (!$modulepath)
        {
        write-host -F Yellow "unable to find psbbix.psm1...get it on https://github.com/yubu/psbbix-zabbix-api"
        exit 1
        }
    Else
        {
            try
            {
            Import-Module $($modulepath | select -Unique).fullname
            }
            catch
            {
            write-host -F error "Error during import of psbbix module"
            exit 1
            }
        }
    Write-Host -F Green "...Module loaded"

    }


$cred = Get-Credential -Credential "myaccount"


# Connect to zabbix server
try
{
Connect-Zabbix $ZabbixSrv -PSCredential $cred
}
catch
{
Write-Host -F Red "Error during connection to $ZabbixSrv"
exit 1
}


# Get all items that we want to disable
$items = Get-ZabbixItem -hostid $(Get-ZabbixHost -HostName $TargetHost).hostid | Where-Object {$_.name -like $ItemPattern}

if ($items.Count -eq 0)
    {
    Write-Host -F Yellow "No items found with '$ItemPattern' pattern for $TargetHost host"
    }

Else
    {
        try
        {
        $items | foreach {Set-ZabbixItem -itemid $_.itemid -status $status}
        }
        catch
        {
        write-host -F Red "Error during modification of Items status"
        exit 1
        }

    }


Write-host "`nFollowing items have been treated for $TargetHost`:`n"
$items = Get-ZabbixItem -hostid $(Get-ZabbixHost -HostName $TargetHost).hostid | Where-Object {$_.name -like $ItemPattern}
$items | foreach {$_.name +" -- "+  $(switch($_.status){0{"enabled"}1{"disabled"}})}

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 !