PI Services

Le blog des collaborateurs de PI Services

Création de tableaux dynamique en Powershell

Nous disposons d’une variable de type tableau avec comme informations des utilisateurs et leurs villes.

Nous allons ici créer dynamiquement une variable pour chaque site présent dans la variable $users et y affecter les utilisateurs.

 

image

Nous allons créer une variable de type tableau dans lesquels nous allons récupérer tous les sites disponibles dans notre variable $users.

$sites=@()

Nous alimentons maintenant la variable $sites.

 

foreach ($user in $users)

{

$sites+=$user.extensionAttribute8

}

$sites=$sites |sort | Get-Unique

 

Résultats :

image

 

Maintenant nous allons créer pour chacun des sites récupérés une variable avec pour nom la valeur récupéré dans la variable $sites

$sites | %{New-Variable -Name $_ -value @() -ErrorAction SilentlyContinue; if ($? -eq $true){write-host "variable créé : $_"}}

Résultats :

image

 

 

Maintenant nous allons alimenter dans les variables créés précédemment dynamiquement les utilisateurs présents dans les sites

foreach ($user in $users)

{

$VariableValue = $Null

$user.extensionAttribute8 |%{$VariableValue = @(((Get-Variable $_).Value)+$user);Set-Variable -name $_ -value $VariableValue}

}

Résultats :

image

image

image

image

image

image

image

 

 

 

Audit de droits administrateurs manquant sur une liste de fichiers

Nous allons pour l’exemple créer un fichier n’ayant pas le droit administrateurs.

 

image

 

Les autres fichiers ont bien le droit administrateurs dans leurs ACL.

Maintenant à l’aide d’un script, nous allons détecter le/les fichiers n’ayant pas l’identité “administrateurs”

Positionnons nous dans le répertoire nous intéressant et récupérons les différents éléments


cd "C:\Users\ato\Dropbox\Divers"
dirs=get-item *

 

maintenant on créer un tableau ou seront ajoutés les différents éléments n’ayant pas le droits administrateurs

Ensuite à l’aide du code ci dessous, nous allons être capable de récupérer dans le tableau $acl les éléments de notre recherche:

foreach ($d in $dirs)
{
    $ID=(get-acl $d).access | %{$_.identityreference}
    if ($ID -match "administrateurs"){}  #c’est ici que l’on définit l’acl manquant que l’on recherche
    else
    {
        $d.fullname
        $acl=$d.fullname
    }
}

 

Apres exécution du script, on peut voir que la variable $acl a bien été définis avec le fichier n’ayant pas le droit administrateur

image

Suppression d’items antérieurs à X jours en Powershell

Imaginons que vous devez supprimer à un emplacement donné des répertoires et/ou fichiers n’ayant pas été modifiés depuis 30 jours.

Ce petit script va permettre d’identifier les éléments correspondant à notre critère de recherche.

Positionnons nous dans le répertoire nous intéressant

cd "C:\Users\ato\Google Drive"

 

On obtient tous les items à notre emplacement

$items= get-item *

Un petit compteur pour identifier le nbre d’éléments qui nous sera retourné

$i=0

Nous allons maintenant récupérer le chemin absolu des items n’ayant pas été modifié depuis au moins 30 jours.

foreach ($item in $items)

{

$days=($item |New-TimeSpan).days

if ($days -ge 30) # c’est ici que nous définissons le nbre de jours

{

$i++

$item.fullname

}

}

echo "Nbres item $i"

Il y a donc 83 items n’ayant pas été modifié depuis au moins 30 jours.

 

image

 

Sur un total de 114 items

 

image

 

Il ne vous reste plus qu’à ajouter un remove-item dans la boucle de traitement si vous souhaitez supprimer les items renvoyés.

Réplication DFS-R & contraintes d’utilisation

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

image

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

image

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

image

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.

Maintenance d’un DAG – Les bonnes pratiques

Introduction

Un groupe de disponibilité dans Exchange permet de répliquer les bases entre plusieurs serveurs Mailbox. L’idée générale est qu’il y ai toujours une base de montée (base active) pendant qu’une ou plusieurs bases passives – situées sur d’autres serveurs du DAG - répliquent les derniers changement afin d’être prêtes à prendre le relais si le serveur hébergeant la base active ne répondrait plus.

image
Exchange 2013 permet jusqu’à 50 bases (actives et passives) par serveur et limite à 16 le nombre de serveurs Mailbox par DAG.

Le schéma à gauche présente un DAG composé de trois serveurs se partageant trois bases différentes.

Les bases en vertes sont les bases actives, celles en gris les passives. On remarque qu’il n’y a toujours qu’une seule base d’active parmi les trois présentes.

Lorsqu’une base n’est plus disponible, le composant “Active Manager” détecte l’indisponibilité et sélectionne parmi les bases passives candidates la plus apte à prendre le relai (Best Copy Selection).

Utilité

Lors d’une maintenance sur un membre d’un DAG Exchange (Database Availability Group), quelques précautions sont à prendre.

Or pourquoi prendre la peine d’exécuter les scripts de maintenance lorsque le rôle du DAG est justement de permettre la perte d’un ou plusieurs serveurs sans que les bases hébergées ne soient impactées ?

Bien que le DAG prévoit tout pour éviter la perte de données, la perte de données n’est pas impossible. En cas de problème, l’administrateur peut se voir obligé d’accepter une perte de données pour remonter les bases en échec…

Scripts & Explications

Après avoir vu les dangers d’une bascule ratée, comment préparer une maintenance sur un membre du DAG et comment faire face à une mauvaise réplication.

Etape 1 :

Sur le serveur à redémarrer exécuter la commande Powershell suivante :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\StartDagServerMaintenance.ps1 –serverName MAIL01

Le serveur MAIL01 n’héberge plus de base active et peut maintenant être redémarré.

Etape 2 :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\StopDagServerMaintenance.ps1 -serverName MAIL01

Cette commande va réactiver ce nœud du DAG le rendant “apte” à héberger des bases actives.

Etape 3 :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RedistributeActiveDatabases.ps1 –DagName DAG -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false

Ce dernier script à appliquer permet d’équilibrer les bases actives sur les membres du DAG.

Lync Server 2013 – Mise en place de statuts personnalisés

Contexte

Lync Server 2013 propose différents statuts par défaut pour son client (disponible, occupé(e), de retour dans quelques minutes…). Afin d’améliorer l’expérience utilisateur, il est possible d’ajouter des statuts personnalisés.

Ces statuts se basent sur un fichier XML. Il est possible d’ajouter au maximum quatre statuts personnalisés, d’une longueur maximale de 64 caractères.

Création et syntaxe du fichier XML

Le fichier XML doit se trouver à l’emplacement : https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Ce chemin correspond à deux dossiers (site interne et externe) qui sont par défaut :

C:\Program Files\Microsoft Lync Server 2013\Web Components\Internal Website\ClientConfigFolder

C:\Program Files\Microsoft Lync Server 2013\Web Components\External Website\ClientConfigFolder

Le fichier se présente ainsi :

   1: <?xml version="1.0"?>
   2: <customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">
   3: <customState ID="1" availability="online">
   4: <activity LCID="1036">En client&#232;le</activity>
   5: </customState>
   6: <customState ID="2" availability="busy">
   7: <activity LCID="1036">En conversation t&#233;l&#233;phonique</activity>
   8: </customState>
   9: <customState ID="3" availability="do-not-disturb">
  10: <activity LCID="1036">En r&#233;union</activity>
  11: </customState>
  12: </customStates>

Les trois indicateurs de présence possible sont online (Disponible), busy (Occupé(e)) et do-not-disturb (Ne pas déranger).

Le code LCID correspond à la localisation du pays et donc à sa langue. Le code 1336 correspond à la France. Tous les codes sont disponibles sur le site de Microsoft http://msdn.microsoft.com/fr-fr/goglobal/bb964664.aspx.

Les caractères spéciaux doivent être spécifiés selon la norme ISO-8859-1.La liste des différents caractères est disponible via le lien http://www.w3schools.com/tags/ref_entities.asp.

Ajout des statuts à une règle utilisateur

Pour que le client Lync prenne en compte les statuts personnalisés, il faut ajouter le paramètre CustomStateURL à une règle utilisateur. Pour cela utiliser la commande suivante :

Set-CsClientPolicy –Identity <Nom de la règle> –CustomStateURL https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Remarque : Il est possible de faire deux fichiers XML afin d’avoir des statuts personnalisés différents en fonction de la connexion (réseau interne ou réseau externe).

imageimage8

Config Mgr 2012 R2 - Erreur de connexion au portail d’application

Contexte

Dans le produit System Center Configuration Manager 2012 R2 il est possible de mettre à disposition un catalogue d’applications pour les utilisateurs finaux. L'implémentation de ce portail « Self-Service » repose sur un service web et nécessite la mise en place des rôles Config Mgr suivants :

  • Application Catalog web service point
  • Application Catalog website point

L’ajout des deux rôles ne pose aucun problème, cependant il est possible que vous rencontriez le problème ci-dessous lors de l’accès à votre catalogue d’application.

2013-12-06_155211_3

Explication

Bien que l’assistant d’installation des rôles ne vous ait pas remonté de problème, il est possible que les choses ne se soient pas passées comme prévu. Si vous rencontrer le message d’erreur « Cannot connect to the application server », c’est qu’il manque très certainement un composant pour rentre votre portail d’application disponible.

Résolution

Pour identifier la source du problème je vous invite à vous rendre dans le répertoire contenant les logs de Config Mgr 2012 R2. Par défaut les logs se trouvent dans le chemin suivant :
[Program Files]\Microsoft Configuration Manager\Logs

Le fichier qui nous intéresse est nommé SMSAWEBSVCSetup.log. Celui-ci est dédié à l’installation du Web-Service du catalogue d’application.

2013-12-06_155255_2

Lors de l’installation du rôle, une analyse de l’ensemble des éléments prérequis pour la mise en service du Web Services est réalisée. En parcourant le fichier, je découvre que composant Windows Communication Foundation (WCF) n’est pas activé : « WCF is not activated ».

Pour remédier à ce problème, je vous invite à prendre connaissance aux prérequis spécifiques à l’implémentation du rôle « Application Catalog web service point ». http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs.

Rendez-vous dans votre console Server Manager pour installer la ou les fonctionnalités manquantes pour l’installation du rôle. Il est probable que l’option HTTP Activation ne soit pas activée et qu’elle soit à l’origine de l’erreur. Vous trouverez ci-dessous une capture du lien Technet proposé plus haut et qui détaille les éléments nécessaires pour le bon fonctionnement du portail d’application.

2013-12-10_164313

2013-12-10_165700

Après avoir ajouté les composants manquants, réinstaller le rôle « Application Catalog web service point ».

L’accès à votre portail d’application devrait être à présent fonctionnel.

2013-12-06_163851_3

Desired State Configuration (Partie 2) : LocalConfigurationManager et Mode Push

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

  • Push
  • Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

001
Get-DscLocalConfigurationManager

 

Le résultat par défaut est le suivant :image Les attributs intéressants pour le mode Push sont :

  • RefreshMode : La valeur doit être à PUSH.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
  • RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

    Voici un exemple de script configurant la ressource LocalConfigurationManager :

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    Configuration SetPushMode
    {
        Node WEBSRV01 {
           
            LocalConfigurationManager {
                ConfigurationMode = "ApplyandMonitor" 
                RefreshMode = "Push"
                RefreshFrequencyMins = 30
            }
        }
    }

    On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

    001
    002
    SetPushMode -OutputPath C:\DSCConfig
    Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

    Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

    Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

001
Start-DscConfiguration -ComputerName WEBSRV01 -Path C:\dscconfig -Verbose -Wait

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.

SCOM et alertes WMI: Script de redémarrage du service wmi et de ses dépendances

 

Le script suivant récupère les alertes ouvertes pour une machine, qui correspondent a des erreurs de requetage wmi. Si il en trouve au moins une dont le repeatcount est supérieur a une valeur donnée en variable, il redémarre le service wmi et ses dépendances et clos les alertes correspondantes.

   1:  
   2: $scomms="scom2k12sp1srv1"
   3: $targetcomputer="scom2k12sp1dc1"
   4: $repeatcountthreshold="1"
   5: $wmi="WinMgmt"
   6:  
   7: $scomcred=Get-Credential -Credential "scom2k12sp1maq1\administrator"
   8: $arrwmialerts=@(“Operations Manager failed to run a WMI query","Workflow Initialization: Failed to start a workflow that queries WMI for performance data","Workflow Initialization: Failed to start a workflow that queries WMI for WMI events","Operations Manager failed to run a WMI query for WMI events",
   9: "Operations Manager failed to run a performance data WMI query","Workflow Initialization: Failed to start a workflow that queries WMI","Script Based Test Failed to Complete")
  10:  
  11: Import-Module operationsmanager
  12:  
  13: New-SCOMManagementGroupConnection -ComputerName $scomms -Credential $scomcred
  14:  
  15: $arrcomputernewalertnames=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false } | Select-Object -Property name -ExpandProperty name
  16: $arrcomputernewalerts=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false }
  17:  
  18:  
  19:  
  20: $matchingalerts=0
  21: foreach ($wmialert in $arrwmialerts)
  22: {
  23:   if ($arrcomputernewalertnames -contains $wmialert)
  24:     {
  25:     Write-Host -ForegroundColor Red -BackgroundColor White "L'alerte "$wmialert.ToUpper()" a été répétée plus de $repeatcountthreshold fois sur $targetcomputer"
  26:     Write-Host -ForegroundColor Yellow "Fermeture de l'alerte "$wmialert.ToUpper()" avant redemarrage du service $wmi et de ses dependances"
  27:     $matchingalerts= ($matchingalerts + 1)
  28:     $arrcomputernewalerts | Where-Object {$_.Name -like "$wmialert*"} | foreach {Set-SCOMAlert -ResolutionState 255 -Alert $_ }
  29:     }
  30: }
  31:  
  32:  
  33: ###FUNCTIONS###
  34: Function Restart-Wmi ($targetcomputer)
  35: {
  36: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  37: $winmgmt=Get-Service -Name Winmgmt
  38: $winmgmtrundep=$winmgmt.DependentServices | Where-Object {$_.Status -eq "Running"}
  39: Stop-Service -Name Winmgmt -Force -ErrorAction SilentlyContinue
  40: Start-Sleep -Seconds 5
  41: Start-Service -Name Winmgmt -ErrorAction silentlycontinue
  42: Start-Sleep -Seconds 5
  43:  
  44: foreach ($dep in $winmgmtrundep) 
  45:     {
  46:     if (Get-WmiObject win32_service | Where-Object {$_.Name -eq $dep.Name -AND $_.state -ne "running" -AND $_.startmode -eq "Auto"}) 
  47:         {
  48:         write-host -ForegroundColor Green "demarrage de la dependance "$dep.Name.ToUpper()""
  49:         Start-Service -Name $dep.Name -erroraction SilentlyContinue -ErrorVariable ("start_"+$dep.Name+"_error").ToString()
  50:         }
  51:     }
  52:  
  53: }
  54: }
  55:  
  56:  
  57: Function NewEventSource
  58: {
  59:     if(!(Test-Path 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\RestartWMIScript'))
  60:     {
  61:     New-EventLog -LogName "Operations Manager" -Source RestartWMIScript
  62:     }
  63: }
  64: ###FUNCTIONS###
  65:  
  66:  
  67:  
  68:  
  69:  
  70:  
  71: if ($matchingalerts -gt 0)
  72: {
  73: write-host -ForegroundColor Yellow "Redemarrage du service WinMgmt et de ses dependances"
  74: Restart-Wmi $targetcomputer
  75: }
  76: else
  77: {
  78: write-host -ForegroundColor Green "Pas d'alertes correspondantes trouvées"
  79: Write-Host -ForegroundColor Green "Pas de redemarrage du service WinMgmt et de ses dependances"
  80: exit
  81: }
  82:  
  83:  
  84:  
  85:  
  86:  
  87: ###VERIFICATION ET LOG D'ERREURS
  88:  
  89:  
  90: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  91: param($targetcomputer)
  92: $wmi=Get-Service -Name WinMgmt -ComputerName $targetcomputer
  93: if ($wmi.Status -ne "Running")
  94: {
  95: $function:NewEventSource
  96: Write-EventLog -LogName 'Operations Manager' -Source RestartWMIScript -EntryType Error -EventId 1002 -Message "erreur de demarrage du service winmgmt"
  97: }
  98:  
  99: } -Argumentlist $targetcomputer
 100:  
 101: ###VERIFICATION ET LOG D'ERREURS
 102:  
 103:  
 104: