PI Services

Le blog des collaborateurs de PI Services

SQL Server – Chiffrer les connexions Client/Serveur

Introduction

Afin d’améliorer la sécurité des connexions réalisées depuis les clients SQL vers une base, il est possible d’activer la fonction de chiffrement de SQL (Encryption) depuis SQL Server Configuration Manager.

Cette fonctionnalité permet de chiffrer la connexion entre le client et le serveur afin d’éviter l’interception et la lecture des commandes réalisées par le client.

Prérequis

  • Un certificat avec sa clé privée délivré pour l’authentification server d’installé sur le serveur SQL (le certificat doit avoir pour nom le même que celui utilisé dans la source de donnée du client, souvent il s’agit du FQDN du serveur),
  • Dans le cas d’une utilisation d’un cluster, le nom du certificat doit être correspondre au nom DNS utilisé par le cluster, le certificat devras être installé sur tous les nœuds du cluster,
  • Le compte de service utilisé par le service SQL Server doit avoir les droits Read sur la clé privée du certificat,
  • Le client doit être en mesure de valider et de faire confiance à l’autorité ayant délivré le certificat,
  • Une fenêtre d’interruption de l’instance SQL.

Réalisation

1. Depuis SQL Server Configuration Manager, faire un clic-droit sur l’instance souhaitée et sélectionner “Properties”

image

2. Depuis l’onglet certificate, sélectionner le certificat à utiliser pour le chiffrement des connexions,

image

3. Depuis l’onglet Flags, passer la valeur de “ForceEncryption” à ‘'Yes”,

image

4. Rebooter l’instance.

Verification

Un test réalisé à l’aide d’un outil de capture réseau, et d’un client SQL permet de prouver le chiffrement des connexions :

  • Avant

image

  • Après

image

SQL Server – Configuration de la base TempDB (Partie 1/2)

Introduction

Ce post est composé de deux parties :

  • Recommandations sur l’emplacement et la taille de TempDB (Partie 1)
  • Répartition de la base TempDB sur plusieurs fichiers (Partie 2)

Présentation de la base TempDB :

La base TempDB est une base temporaire régénérée à chaque démarrage du serveur SQL, cette base est accessible à tous les utilisateurs (il est possible de retirer l’accès à cette base aux utilisateurs, mais cela n’est pas conseillé car la base TempDB est utilisé dans des opérations de routines).

Cette base, de par sa nature temporaire, ne permet pas les actions d’administrations suivantes : Sauvegarde/Restauration, Changement du “Recovery Model”.

Dans cette première partie nous verrons comment déplacer la base TempDB vers un stockage dédié.

Recommandations sur l’emplacement et la taille de TempDB

Recommandations Générales relatives à l’emplacement des fichiers de bases de données

De manière générale, il est recommandé de séparer les fichiers Data, Logs et temp. L’objectif de cette séparation est de permettre une meilleure séparation de la charge à travers différents disques physiques.

Actuellement, avec l’augmentation des solutions de stockage virtuel, la séparation des fichiers n’est parfois plus nécessaire pour des raisons de performances, néanmoins, séparer les fichiers à travers différents disques logiques permet plus de souplesse dans l’administration.

Dans le cas d’une infrastructure SQL utilisant un stockage partagé, le déplacement de la base TempDB vers un stockage local peut apporter les bénéfices suivants :

  • Meilleure performances notamment lors de l’utilisation de disques rapides (SSD),
  • Certaines bases TempDB peuvent être très sollicitées entrainant une baisse de performance générale sur stockage partagé.

Certains administrateurs peuvent être tentés de déplacer la base TempDB vers un stockage local, attention toutefois à bien valider les points suivants pour une configuration cluster :

  • Utiliser une base TempDB locale dans une configuration Cluster n’est supporté que depuis SQL Server 2012 (les versions précédentes requièrent que toutes les bases soient présentes sur le stockage partagé),
  • Utiliser le même emplacement pour TempDB à travers tous les nœuds du cluster, le compte de service SQL Server doit avoir un droit Lecture/Ecriture sur chacun des dossiers.

Recommandations Générales relatives à la taille des fichiers de bases de données

Lors de la création d’une nouvelle base de données, il est possible de préciser les éléments suivants relatifs à la taille de la base de données :

  • Taille initiale de la base de données,

La taille initiale de la base de donnée doit correspondre à la taille que la base va occuper à terme, ce afin d’éviter des actions d’expansion de la base (Autogrowth) qui en plus d’être lourdes entraînent une fragmentation des fichiers ainsi qu’une indisponibilité de ceux-ci durant l’expansion.

  • Taille maximum de la base de données,

A moins de parfaitement maitriser la taille maximum que la base de données doit avoir, il est préférable de conserver à “Unlimited” la taille maximum d’une base.

  • Autogrowth de la base de données

La fonction Autogrowth permet d’automatiquement augmenter la taille des fichiers de la base de données, ce qui permet une administration plus simple. L’opération d’autogrowth est généralement lourde (à moins d’utiliser l’IFI, Instant File Initialization) et comprends plusieurs contraintes.

Il est donc préférable d’éviter qui doit être considéré comme une solution de fortune. L’idéal en l’absence d’informations précises concernant la taille de la base est d’analyser l’évolution de la base en paramétrant un autogrowth fixe en MB, puis après une période d’analyse suffisante, de paramétrer la taille des fichiers utilisés par la base à une valeur légèrement supérieure à celle constatée (cette préconisation s’applique d’autant plus à la base TempDB, celle-ci étant recréée à chaque démarrage de l’instance SQL).

Afin d’estimer la taille à positionner pour l’Autogrowth, il est possible de visualiser la fréquence d’autogrowth d’une base depuis le rapport Disk de celle-ci :

clip_image001

Réalisation

Afin de déplacer la base TempDB, voici les actions à réaliser :

1. Récupérer l’emplacement actuel de la base

Use master
GO
SELECT
name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

clip_image002[5]

2. Déplacer les fichiers utilisés par TempDB (attention à veiller à ce que le compte du service SQL Server y ait un droit de Lecture/Ecriture)

USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'T:\MSSQL\DATA\tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'T:\MSSQL\DATA\templog.ldf');
GO

3. Redémarrer le service SQL Server

Verification

Vérifier le nouvel emplacement des fichiers TempDB :

Use master
GO
SELECT
name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

SQL Server – Configuration de la base TempDB (Partie 2/2)

Introduction

Ce post est composé de deux parties :

  • Recommandations sur l’emplacement et la taille de TempDB (Partie 1)
  • Répartition de la base TempDB sur plusieurs fichiers (Partie 2)

Dans cette seconde partie nous verrons comment repartir la base TempDB à travers plusieurs fichiers comme Microsoft le recommande.

Recommendation

Bien que Microsoft recommande de répartie la base TempDB à travers autant de fichiers que de processeurs logiques présents sur le serveur et ce jusqu’à 8 fichiers, dans le cas d’un serveur avec plus de 8 CPU, si malgré l’utilisation de 8 fichiers la base TempDB souffre toujours de lenteurs, Microsoft préconise d’augmenter le nombre de fichiers par un multiple de 4.

Différents membres de la communauté SQL s’accordent à penser qu’au-delà de 8 fichiers, le gain en performance seras négligeable par rapport à l’effort d’administration.

Réalisation

1. Récupérer le nombre de CPU logique du serveur SQL

clip_image001

2. Ajouter trois fichiers TempDB sur trois disques différents (attention à veiller à ce que le compte du service SQL server y ait un droit de Lecture/Ecriture), il est préférable d’avoir des options de tailles et d’Autogrowth identiques

ALTER DATABASE tempdb

ADD FILE (NAME = tempdev2, FILENAME = 'W:\tempdb2.mdf', SIZE = 1024);

ALTER DATABASE tempdb

ADD FILE (NAME = tempdev3, FILENAME = 'X:\tempdb3.mdf', SIZE = 1024);

ALTER DATABASE tempdb

ADD FILE (NAME = tempdev4, FILENAME = 'Y:\tempdb4.mdf', SIZE = 1024);

GO

SCOM – Les Management Packs HP

Si vous disposez de matériel Hewlette Packard/HPE (Proliant, BladeSystem) dans votre parc, vous avez probablement déployé le Management Pack qui va avec… ou peut-être avez-vous abandonné au vu de la difficulté pour trouver les bonnes versions, les bons liens, la bonne documentation etc.

Voici donc un résumé qui devrait vous simplifier la tâche !

Télécharger les Management Packs

Première étape de votre quête : télécharger les management packs ! Entre les liens corrompus, les fichiers sans rapport, les différentes versions… difficile de s’y retrouver.

Ne cherchez plus, les fichiers contenant les derniers management packs se trouvent ici : https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=Z7500-63235

Une fois enregistré et connecté, téléchargez le fichier HP OneView for Microsoft System Center 8.0 ZIP - October 2015. Il contient beaucoup de choses inutiles pour ce qui nous intéresse, mais aussi et surtout le fichier hpscomkit-x64-3.2.1.exe avec tous les management packs et les consoles nécessaires (à exécuter en tant qu’administrateur pour éviter toute mauvaise surprise !)

clip_image002

Tableau de synthèse

Commençons par un tableau synthétique de ce qui est supporté à travers quel management pack, nous détaillerons par la suite les différentes possibilités :

clip_image003

Supervision Agentless

La supervision sans agent du matériel HP est distincte de la supervision sans agent au sens SCOM du terme : il s’agit ici de déployer le service Device Management Service (DMS) et sa console Device Management Console (DMC), puis d’y renseigner tous les matériels HP que vous souhaitez superviser sans agent.

Cette console DMC permet d’ajouter trois types de matériel :

- Le mode BladeSystem pour les chassis, via leur Onboard Administrator (v4.01 et supérieures)

- Le mode Linux (RHEL5-6-7, SLES10-11-12)/ESX 4.x (mais pas ESX 5.x et supérieurs !)

- Le mode Agentless Server, par défaut en quelque sorte, qui supporte tous les serveurs Gen8 et supérieurs via leur iLO quel que soit le système d’exploitation (Windows, Linux, ESX…).

clip_image005

Notez également qu’il est vivement recommandé d’installer le DMS sur un serveur qui n’est pas un serveur SCOM, ou au moins un serveur SCOM n’effectuant pas de supervision réseau car le service peut utiliser SNMP pour communiquer avec les différents matériels !

Il faut toutefois que le serveur qui héberge DMS dispose d’un agent SCOM.

clip_image006

Agentless Management Service

L’AMS est un module complémentaire qui permet d’obtenir plus d’informations en cas de supervision Agentless.

Son installation est détaillée dans le document suivant (pages 113 et suivantes) : http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c03334051

clip_image008

Cas particulier

Supervision ESX4 via le mode Linux/ESX, supervision tous OS à partir des Gen8 pour le mode Agentless Server… Mais alors, qu’en est-il des serveurs Gen6 ou 7 sous ESX5.x, que l’on retrouve parfois ?

Eh bien, ils ne sont tout simplement pas supportés, comme le confirme Stephan Roth qui a posé la question à HP Suisse : https://stefanroth.net/2012/11/04/scom-2012-hp-hardware-monitoring-on-vmware-esxi-servers/

Supervision de serveurs sous Windows :

La solution la plus simple pour superviser les serveurs (toutes générations) sous Windows est de d’abord déployer l’agent HP Insight, puis d’utiliser les MP Proliant SNMP et WBEM : la découverte se fera alors automatiquement, à la façon « SCOM » habituelle en quelque sorte.

Il n’est donc plus nécessaire dans ce cas d’ajouter chaque serveur dans la console DMC, ce qui simplifie grandement la gestion. De plus, ce mode permet de superviser toutes les générations de serveurs HP et pas uniquement les Gen8 et supérieurs.

Il s’agit donc clairement de la solution à préférer pour les serveurs Windows !

Pour aller plus loin

Les documents à jour concernant la supervision du matériel HP sont eux aussi assez compliqués à trouver.

En voici deux qui vous permettront de mieux cerner la problématique :

Managing Mixed Environnements with HPE SCOM MP : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04347838&docLocale=en_US

HPE SCOM Integration kit : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04605146&docLocale=en_US

Skype for Business – Accès à la messagerie vocale depuis un téléphone

Contexte

Lors de l’installation d’un téléphone Skype (type Polycom VVX400 ou AudioCodes 440HD) l’appel vers la messagerie vocale de l’utilisateur ne fonctionne pas.

En appelant la messagerie depuis le client Skype for Business l’appel fonctionne.

Solution

La connexion des téléphones au compte Skype de l’utilisateur se fait via les serveurs Skype for Business mais la messagerie vocale se trouve sur les serveurs Exchange (rôle UM) et non pas sur les serveurs Skype for Business.

Pour faire fonctionner les appels vers la messagerie vocale il faut donc ouvrir certains ports des téléphones vers les serveurs Exchange :

Source Destination Ports
VLAN VOIP IP Exchange Server (rôle UM) TCP : 5060, 5061, 5062, 5063, 5065, 5066, 5067, 5068
VLAN VOIP IP Exchange Server (rôle UM) UDP : 1024 à 65535

Affichage du Body d’un mail en PowerShell via l’utilisation des Web Services API Exchange

 

Lorsque vous récupérez un mail en PowerShell au travers des API Web Services Exchange, le corps du mail semble vide.

 

image

 

Pour afficher le contenu du body, il faut appeler la fonction .load().

Le body du mail s’affiche.

image

 

Cependant celle ci s’affiche formaté en HTML.

SI vous souhaitez l’afficher sous un format texte, il faut indexer une variable avec la propriété Text.

Exemple :

$psPropertySet= New-Object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$psPropertySet.RequestedBodyType = [Microsoft.Exchange.WebServices.Data.BodyType]::Text

$mail.load($psPropertySet)

$mail.body.text

 

Résultat:

image

Renommage des ressources d’une VM suite à un déploiement par SCVMM

 

Lorsque vous déployez une machine virtuelle par VMM, celle ci est préfixé au niveau du nom par SCVMM. La ressource Virtual Machine Configuration est également préfixée.

Voici un script qui va se charger de renommé les ressources comme ci celle ci avaient été déployé depuis Hyper-V /Failover Clusters et non VMM.

image

 

 

Code:

Param ([string]$VM, [string]$MonCluster)

if (($VM -eq $NULL) -or ($MonCluster -eq $NULL))
{
    write-host "Il manque un argument" -f yellow
}
else
{
    $VM=$VM.ToUpper()
    get-cluster $MonCluster
    if ($?)
    {
        get-cluster $MonCluster | Get-ClusterGroup -Name "SCVMM $VM Resources"
        if ($?)
        {
            (get-cluster $MonCluster | Get-ClusterGroup -Name "SCVMM $VM Resources").name=$VM
            if ($?)
            {
                sleep -s 2
                ((get-cluster $MonCluster | Get-ClusterGroup -Name "$VM" | Get-ClusterResource) |?{$_.resourcetype -eq "Virtual Machine"}).name="Virtual Machine $VM"
                ((get-cluster $MonCluster | Get-ClusterGroup -Name "$VM" | Get-ClusterResource) |?{$_.resourcetype -eq "Virtual Machine Configuration"}).name="Virtual Machine Configuration $VM"
            }
            else
            {
                write-host "Renommage du Groupe de Ressource echouer" -f yellow
            }
        }
        else
        {
            write-host "Groupe de Ressources pas trouver" -f yellow
        }
    }
    else
    {
        write-host "Cluster pas trouver" -f yellow
    }
}

Configuration du DSC en mode Pull Server

 

Installation du module xPSDesiredStateConfiguration

Récupérer le module xPSDesiredStateConfiguration sur le site suivant :

https://gallery.technet.microsoft.com/xPSDesiredStateConfiguratio-417dc71d

Ce module contient la ressource suivante xDSCWebService qui va nous permettre de configurer notre Serveur DSC Pull.

Vous devez maintenant extraire le contenu de l’archive dans :

C:\Program Files\WindowsPowerShell\Modules

clip_image001

Installation de la Feature DSC

Ouvrer un Prompt PowerShell puis lancer la commande :

Add-WindowsFeature -Name DSC-Service -IncludeManagementTools

image

Redémarrer votre serveur

Ouvrer un prompt PowerShell et lancer la commande suivante :

Get-DSCResource

Vérifier que vous avez bien la ressource xDSCWebService qui s’affiche

(cette ressource est disponible suivante au module que vous avez copier précédemment).

image

Lancer un Prompt PowerShell

Configuration du Serveur DSC

Executer le Script Sample_XDscWebService.PS1 présent dans le répertoire c:\programfiles\WindowsPowerShell\Modules\xPSDesiredStateConfiguration\Examples

image

Lancer maintenant la commande Sample_xDscWebService -certificateThumbPrint AllowUnencryptedTraffic

image

Un répertoire du meme nom est créé contenant le fichier mof contenant la configuration du server Pull.

(Le répertoire est créé la ou votre prompt est situé)

image

Le fichier mof va être utilisé par une commande DSC pour la configuration du serveur.

Apercu du fichier mof

clip_image012

lancer la commande suivante :

Start-DscConfiguration -Wait -Path .\Sample_xDscWebService -Force -Verbose

Le serveur Pull est maintenant configuré

image

Vérification du serveur DSC

La commande Get-DSCConfiguration permet de voir la configuration du serveur DSC

image

Dans votre navigateur internet, taper l’adresse suivante :

http://NOMSERVER:8080/PSDSCPullServer.svc

On peut constater que le service IIS est fonctionnel.

clip_image018

SCOM 2012 – Lister toutes les alertes provenant des serveurs d’un groupe

Selon le mode de fonctionnement de votre service informatique, il est possible que vous n’ayez pas une équipe de supervision dédiée mais plutôt que cette tâche incombe à chaque équipe pour son périmètre de serveurs donné.

Si en plus vous utilisez un Resolution State différent pour attribuer les alertes à chaque équipe, l’idée peut vite vous venir de scripter cette tâche !

A priori, rien de bien compliqué.

Commençons par récupérer le groupe :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

Puis les instances présentes dans ce groupe. Cette fois-ci, pas de cmdlet natif, il faut utiliser la méthode GetRelatedMonitoringObjects du groupe :

$groupinstances = $group.GetRelatedMonitoringObjects('Recursive')

Et enfin les alertes non attribuées (Resolution State 0) provenant de ces instances :

$alerts = Get-SCOMAlert -instance $groupinstances -ResolutionState 0

Hélas, si le groupe visé est un minimum conséquent, on obtient l’erreur suivante :

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.

Cette erreur provient directement de SQL et n’est pas propre à SCOM (cf. https://blogs.msdn.microsoft.com/emeadaxsupport/2009/09/01/how-to-fix-sql-error-too-many-parameters-were-provided-in-this-rpc-request/ )

De plus, le cmdlet Get-SCOMAlert est très lent à exécuter et il n’est donc pas envisageable de l’utiliser dans un script qui aurait vocation à s’exécuter régulièrement.

Heureusement, une autre méthode de $group existe :

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

De cette façon, on n’a même plus besoin de récupérer les instances du groupe, on prend les alertes directement… et cette méthode est particulièrement véloce !

Attention toutefois, elle récupère toutes les alertes, y compris les alertes déjà attribuées ou déjà fermées. Il est donc nécessaire de les filtrer dans la dernière étape, celle de l’affectation de l’alerte à la bonne équipe à l’aide d’un ResolutionState :

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

On résume ? La solution n’était pas si évidente, mais au final 3 lignes suffisent :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

A vous maintenant de les intégrer à vos scripts en fonction de vos besoins !

HPOneView – Script Powershell

Le script ci-dessous utilise le module powershell pour HP OneView afin de requêter des alertes sur les appliances HP OneView avec la possibilité de changer leur état en Cleared.

Pour rappel, HP OneView est l’outil de management et de centralisation de la configuration des des systèmes convergés HP. Il utilise des appliances dédiés a la gestion des materiels.

Au passage, Un management pack HP OneView pour SCOM est fourni afin de superviser les appliances et les materiels gérés.

En surcouche des API REST fourni par HP, il existe un projet d’API pour Powershell et Python permettant de manipuler plus facilement les fonctionnalités de l’interface OneView.

Le site pour l’API Powershell est disponible via https://github.com/HewlettPackard/POSH-HPOneView

Le script est un exemple de connexion et de récupération multi-critère.

 

############################################################################## # SCRIPT DE RECUPERATION DES ALERTES D'UNE APPLIANCE HPONEVIEW ET MISE EN ETAT CLEARED # author: cjourdan # PARAMETRES: # $ApplianceName: Nom de l'appliance # $RessourceName: Nom de la ressource (Server,Enclosure ...). # $DomainName: Domaine AD. # $AlertSeverity: Critical, Warning, OK, Unknown, Disabled # $AlertState: Active, Locked, Cleared, Pending, Running, Completed, Interrupted, Error, Warning, Terminated, Killed. # $DescInclude: Chaine de caractère dans la champ Description a inclure dans la recherche. # $DescExclude: Chaine de caractère dans la champ Description a exclure de la recherche. # $DayOffset = Recuperer les alertes plus recente que J-DayOffset. # Apres Recuperation des alertes, le script demande validation pour mettre les alertes en état Cleared Param( [Parameter(Mandatory=$false)] $ApplianceName = "MyAppliance", [Parameter(Mandatory=$false)] # Server,Enclosure ... $RessourceName = "MyResource", [Parameter(Mandatory=$false)] $DomainName = "MyDomain", [Parameter(Mandatory=$false)] $AlertSeverity = "Critical", [Parameter(Mandatory=$false)] $AlertState = "Cleared", $DescInclude = "*", $DescExclude = "azerty", $DayOffset = 2 ) $user = Read-Host -Prompt "Enter MyDomain Credential without Domain" $passwd = Read-Host -Prompt "Password" -AsSecureString if (-not (get-module HPOneview.200)) { Import-Module HPOneView.200 } # Connexion a l'appliance OneView if (-not($global:ConnectedSessions)) { Connect-HPOVMgmt -Hostname $ApplianceName -UserName $user -Password $passwd -AuthLoginDomain $DomainName } write-host -BackgroundColor White -ForegroundColor Blue "APPLIANCE ONEVIEW: $ApplianceName"`n # NB: Preciser au minimum un filtre de recherche avant le '|' afin de reduire le temps de recuperation des alertes Try { $Alerts = Get-HPOVAlert -ApplianceConnection $ApplianceName -Severity $AlertSeverity | Where-Object {$_.AlertState -eq $AlertState ` -AND $_.associatedresource -like "*$RessourceName*" ` -AND $_.description -like "*$DescInclude*" ` -AND $_.description -notlike "*$DescExclude*"` -AND $([datetime]$_.created) -gt $(get-date).AddDays(-$DayOffset) } $FormAlerts = foreach ($alert in $Alerts) { Write-output "DESCRIPTION: "$alert.description"" ; Write-Output "SEVERITY: "$alert.severity"" ; Write-Output "STATE: "$alert.alertState"" ; Write-Output "CREATED: "(get-date -format G $alert.Created)"" ; Write-Output "CLEARED: "(get-date -format G $alert.clearedtime)"" ; Write-Output "RESSOURCE_NAME: "$alert.associatedresource.resourcename"" ; Write-Output "APPLIANCE: "$alert.ApplianceConnection.Name"" ; Write-Output "" ; Write-Output "*******************" ; Write-Output "" } write-host -BackgroundColor White -ForegroundColor Blue "CRITERES DE RECHERCHE: Resource: $RessourceName / Severity: $AlertSeverity / Status: $AlertState / a inclure: $DescInclude / a exclure: $DescExclude / Plus recentes que: J-$DayOffset"`n $count=$Alerts | Measure-Object | select count -ExpandProperty count write-host -BackgroundColor White -ForegroundColor Blue "NOMBRE D ALERTES: $count" `n $FormAlerts } Catch { Write-Error -ErrorRecord $_ -ErrorAction Stop } $answer = Read-Host -Prompt "VOULEZ VOUS MODIFIER L'ETAT DES CES ALERTES EN ETAT 'CLEARED' ?: Y/N" switch($answer) { "Y" {"MISE EN ETAT CLEARED"} "N" {"AUCUNE ACTION" ; exit} default {"MAUVAISE REPONSE - AUCUNE ACTION" ; exit} } # Clear Alerts Try { $updatedAlert = $Alerts | set-HPOVAlert -Cleared } Catch { Write-Error -ErrorRecord $_ -ErrorAction Stop } $updatedAlert Write-Host -ForegroundColor Green "MISE EN ETAT CLEARED TERMINEE SANS ERREUR !"