PI Services

Le blog des collaborateurs de PI Services

Mettre la langue du clavier Fr dans WinPe

Pour définir nativement la langue Française dans votre Windows PE, il est nécessaire de modifier le registre du PE.

Pour cela, nous allons monter notre image boot.wim correspondant à notre WinPe.

clip_image001

imagex64.exe /mountrw c:\winpe4_x86\media\sources\boot.wim 1 c:\winpe4_x86\mount

clip_image003

clip_image004

Une fois celui-ci monté, nous allons monter le fichier de ruche Default

clip_image005

clip_image006

clip_image007

clip_image008

Ensuite, il nous suffit de modifier la valeur de la sous clé 1 dans

HKEY_CURRENT_USER\WinPe\Keyboard Layout\Preload

clip_image010

Et de lui saisir la valeur correspondante au Français

clip_image011

clip_image012

clip_image001[5]

Décharger la ruche, démonter l’image et rebooter sur votre PE.

Le clavier sera désormais en Français.

Suppression d’un profil utilisateur sous Windows 7 manuellement

Sous Windows XP, beaucoup de personnes pour résoudre des problèmes de profils renomment les profils utilisateurs(.old) afin que celui-ci soit régénéré par le système lors de la connexion de l’utilisateur en question.

Cependant sous Windows 7, pour régénérer un profil utilisateur en utilisant la technique de renommage, celui-ci va générer un profil temporaire.

Exemple : je me logue avec un utilisateur.

image

On peut désormais constater le répertoire du profil utilisateur dans c:\users.

clip_image002

Maintenant, on se connecte en tant que administrateur sur la machine et on renomme le répertoire du profil utilisateur afin que celui-ci ne soit plus trouver par le système.

clip_image003

Maintenant, si notre utilisateur essaie de se reconnecter sur cette même machine, il va avoir la surprise d’utiliser un profil temporaire.

clip_image004

clip_image005

La méthode pour régénérer un profil utilisateur en renommant le répertoire doit également contenir la suppression du pointeur du profil dans le registre.

Pour cela, il suffit d’accéder à la clé ProfileList

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Et là on peut constater que notre répertoire utilisateur n’étant plus trouvé par le système, celui s’est renommé .bak

clip_image006

clip_image007

Il faut alors supprimer cette clé.

clip_image008

clip_image009

Dès lors ou l’utilisateur se reconnectera à sa machine celui-ci régénéra un profil et non plus un profil temporaire.

L’entrée de l’utilisateur dans la clé “ProfileList” est également régénéré.

 

clip_image010

SCOM : passer automatiquement les serveurs qui redémarrent en mode maintenance

Dans une grosse infrastructure composée de nombreux serveurs, les redémarrages peuvent s’avérer assez fréquents.

Malheureusement, un serveur qui redémarre peut entrainer la remontée de différentes alertes dans SCOM puisque ni son agent ni les services qu’il exécute ne répondent plus.

C’est pourquoi il est recommandé de basculer les serveurs à redémarrer dans mode « Maintenance » dans la console SCOM avant de les stopper : cela indique à SCOM qu’il doit arrêter de les superviser pendant un temps prédéfini, empêchant ainsi toute remontée d’alerte.

Dans le cadre de grosses infrastructures, réparties entre des services divers, il n’est toutefois pas toujours pratique de solliciter la bonne personne au bon moment pour procéder à cette mise en mode maintenance, d’où l’intérêt de pouvoir procéder à cette action automatiquement lorsqu’un redémarrage est détecté.

Cette automatisation sera réalisée à l’aide d’une règle qui détectera un événement 1074 (source USER32) dans le journal d’événement System et créera une alerte, qui sera interceptée à l’aide d’un Notification Channel, qui déclenchera enfin l’exécution d’un script PowerShell qui procèdera à la mise en mode maintenance.

Commençons donc par créer la règle de détection d’événement :
Indiquer un nom pour la règle, une description, une catégorie, la cibler sur la classe Windows Computer et sélectionner un management pack différent du Default pour l’enregistrer.

clip_image002

Les events 1074 sont créés dans le journal d’évènement System lorsqu’un redémarrage est initié.

clip_image004

Leur ID est 1074 et leur source est USER32

clip_image006

L’alerte n’est pas destinée à être lue par un opérateur humain, son nom et sa description importent donc peu tant qu’ils restent suffisamment spécifiques. De la même façon, la sévérité pourra être définie à Information.

clip_image008

 

Une fois la règle mise en place, nous allons créer un ensemble de règles de Notification (channel de notification, subscriber, subscription). Ce sont eux qui détecteront la création de l’alerte et commanderont le lancement du powershell de mise en mode maintenance. Une recovery task aurait également pu remplir le même rôle, mais son mode de fonctionnement induit une réaction plus lente qui pourrait ici être préjudiciable puisqu’il faut que la mise en maintenance soit faite avant que le serveur ne cesse de répondre.

Commençons donc par créer un nouveau Notification Channel.
Entrer un nom et une description :

clip_image010

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& '"D:\chemin\vers\script\scriptmaintenancemode.ps1"'" -alertid '$Data/Context/DataItem/AlertId$' -computerPrincipalName '$Data/Context/DataItem/ManagedEntityDisplayName$'

clip_image012

 

Passons ensuite au Subscriber.

Indiquer un nom

clip_image002[3]

Laisser la sélection par défaut pour la plage d’utilisation (Alwas send notifications)

clip_image004[3]

Cliquer sur Add. Indiquer à nouveau un nom (le même fera parfaitement l’affaire).

clip_image006[3]

Sélectionner le Channel Type nommé Command et le Notification Channel qui vient d’être créé, Mode Maintenance dans cet exemple.

clip_image008[3]

Ici aussi, laisser Always send notifications coché et cliquer sur Finish.

clip_image010[3]

De retour sur l’écran du Notification Subscriber Wizard, l’addresse qui vient d’être créée doit apparaitre. Cliquer sur Finish.
clip_image012[3]

 

Reste à paramétrer la Subscription.
Là aussi indiquer un nom (toujours le même…) et une description.

clip_image014[4]

En Critère de déclenchement , cocher Created by specific rules or monitors et indiquer la règle précédemment créée.

clip_image016[4]

Cliquer sur Add et sélectionner le Subscriber préalablement créé.

clip_image018[4]

De la même facon, cliquer sur Add et indiquer le Channel.

clip_image020[4]

Cliquer sur Finish.


Il ne reste plus qu’à créer le script powershell à proprement parler. Pensez à modifier la variable $RMS de façon à ce qu’elle indique le nom de votre RMS et la variable $minutes avec la durée de mise en mode maintenance que vous souhaitez utiliser, ainsi qu’a enregistrer le fichier .ps1 à l’endroit de votre choix correspondant à ce que vous avez indiqué lors de la création du Notification Channel:

#
# SCHEDULE MAINTENANCE MODE
# Version originale de base : http://lucamihailescu.blogspot.com/2010/01/operations-manager-maintenance-mode.html
#

Param($alertid, $computerPrincipalName, $minutes, $comment)

$RMS = "localhost"

if (!$minutes) {$minutes = 15}
if (!$comment) {$comment = "Mode Maintenance Automatique Suite a Detection de Redemarrage"}

function fixalert {
$alert = Get-Alert -Id $alertid
Resolve-Alert -Comment $args[0] -Alert $alert
}

if ((Get-PSSnapin | Where {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null) {

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"

}

New-ManagementGroupConnection $RMS
Set-Location "OperationsManagerMonitoring::"
Set-Location $RMS
$agent = Get-Agent | Where {$_.PrincipalName –eq $computerPrincipalName}
$computer = $agent.HostComputer

if (!$agent) { fixalert "Alerte cloturee par le Script MaintenanceMode. Le Mode Mainenance n’a pas pu etre active (le serveur en cours de redemarrage est un RMS ou MS)"; Exit }

$startTime = [DateTime]::Now

$endTime = $startTime.AddMinutes($Minutes)

New-MaintenanceWindow -StartTime $startTime -EndTime $endTime -MonitoringObject $computer -Comment $comment

fixalert "Alerte cloturee par le Script MaintenanceMode. Mode Maintenance actif!"

Voilà, c’est terminé… vous pouvez maintenant redémarrer un de vos serveur supervisé pour vérifier qu’il passe bien automatiquement en mode maintenance!

 

Orchestrator : créer son propre Integration Pack (partie 2 : compiler et importer l’oip)

 

Dans le billet précédent, nous avons vu comment créer une Assembly, c'est-à-dire le fichier dll contenant la « mécanique » de l’Integration Pack. Cependant, pour obtenir un Integration Pack finalisé et prêt à être déployé sur une infrastructure Orchestrator, il est nécessaire de packager cette Assembly pour en faire un fichier .oip.

Lancer l’outil Orchestrator Integration Pack Wizard

image

Cliquer sur Next ou sur Import Integration Pack pour reprendre un OIP préexistant

image

Remplir les champs obligatoires (marqués par une étoile).

image

Product Name correspond au nom qui apparaitra dans le Deployment Manager.

image

 

Category Name correspond au nom de la catégorie d’activité qui apparaitra dans le Runbook Designer :

image

Resource File est le fichier qui contient les icones et d’autres ressources. Dans cet exemple on conserve celui par défaut.

Une fois les champs remplis, cliquer sur Next.

Dans le champ Library, sélectionner la dll de l’assembly créée dans la première partie ainsi que la classe correspondante. Indiquer un Display Name (nom qui apparaitra dans le Runbook Designer). Sélectionner une icône pour l’activité, et cliquer sur OK

image

Au besoin, sélectionner les fichiers nécessaires au bon fonctionnement de l’activité (par exemple un exécutable si l’activité repose dessus) en cliquant sur Add. Dans notre exemple, il n’y a rien à ajouter puisque le fonctionnement de l’activité repose sur du code PowerShell directement intégré dedans. Cliquer sur Next.

image

Indiquer le chemin où enregistrer fichier OIP final puis cliquer sur Next.

image

L’assistant compile l’OIP…

image

Une fois terminé, cliquer sur Finish.

Il reste maintenant à déployer notre OIP au Management Server, Runbook Server et/ou Runbook Designer. Cette procédure est identique quel que soit l’OIP à déployer, mais un rappel pourra toujours servir :

Lancer la console Deployment Manager et faire un clic-droit sur Integration Packs. Cliquer sur Register IP with the Orchestrator Management Server.

image

Cliquer sur Next.

image

Cliquer sur Add et sélectionner l’OIP à déployer.

image

Cliquer sur Finish.

image

Une fois enregistré avec le Management Server, l’OIP apparait dans la liste des Integration Packs. Faire un clic-droit sur son nom et cliquer sur Deploy IP to Runbook Server or Runbook Designer.

image

Cliquer sur Next.

image

Sélectionner l’OIP à déployer et cliquer sur Next.

image

Indiquer le ou les serveurs cible(s) via le champ Computer et le bouton Add puis cliquer sur Next

image

 

Indiquer si vous souhaitez procéder au déploiement à une heure précise ainsi que si vous préférer arrêter tous les runbooks avant de procéder au déploiement. Cela peut s’avérer nécessaire pour certains OIP, ou pour le déploiement d’un hotfix, mais pas dans le cas de notre exemple. Cocher Install the Integration Packs […] et cliquer sur Next.

image

Cliquer sur Finish.

image

 

Relancer la console Runbook Designer pour en rafraichir le contenu. L’activité doit maintenant être présente et il ne reste plus qu’à l’utiliser comme n’importe quelle autre dans vos runbooks :

image

Orchestrator : créer son propre Integration Pack (partie 1 : créer l’assembly)

 

Orchestrator est livré d’origine avec un bon nombre d’activités pré-installées, qui permettent de mettre en place nativement un large panel de scénarios. Il est également possible d’étendre ces capacités à l’aide d’Integration Packs (appelés OIP), qui peuvent être disponibles au téléchargement auprès de Microsoft ou d’éditeurs tiers ou bien développés directement par les administrateurs en fonction de leurs besoin spécifiques.
Nous allons nous intéresser ici à ce dernier cas.

Dans un premier temps, il est nécessaire de télécharger et d’installer Orchestrator Integration Toolkit, le package qui contient les outils nécessaires à la création de ces OIP. Il est disponible ici : http://www.microsoft.com/en-us/download/details.aspx?id=28725 (System_Center_2012_Orchestrator_Integration_ToolKit.exe)

L’installer et importer l’OIP « integration toolkit » fourni avec dans votre infrastructure Orchestrator (management server et runbook designer, se référer à la fin de la partie 2 pour de l’aide à ce sujet).

Une fois ces pré-requis complétés, nous pouvons démarrer la création de l’Integration Pack à proprement parler. La première étape consiste à créer une « Assembly », qui est un fichier dll contenant le « moteur» de l’OIP. La seconde étape consistera à packager cette dll pour en faire un fichier OIP à proprement parler.

Nous étudierons ici l’exemple d’un OIP contenant une unique activité permettant d’ajouter des évènements au journal d’évènements (Event Viewer). Cette activité existe déjà d’origine via l’activité « Send Event Log Message », mais elle est très limité : elle ne permet pas de sélectionner le journal d’évènement cible, ni l’ID de l’évènement, ni sa source, ni sa criticité. L’OIP que nous allons développer ici offrira toutes ces possibilités.

Lancer l’outil Orchestrator Command-Line Activity Wizard.

clip_image002

Cliquer sur Next à l’écran d’accueil (ou sur Load existing assembly  pour reprendre un projet en cours).

clip_image004

Nommer le projet et indiquer le chemin où enregistrer l’assembly (le fichier dll source) puis cliquer sur Next

clip_image006

Il est également possible d’ajouter des détails sur le projet (description, nom de la compagnie, version… ) en cliquant sur Assembly Information

clip_image008

Cliquer sur Add

clip_image010

Dans l’onglet General, nommer l’activité et indiquer son mode de fonctionnement (Run Command, Run Windows PowerShell, Run Program ou Run SSH Command).
Dans notre cas, la création d’événement dans le journal d’événements se reposera sur une commande PowerShell ; nous choisissons donc Run Windows Powershell.
Cliquer sur l’onglet Arguments.

clip_image012

L’onglet Arguments est celui dans lequel nous déterminons les paramètres d’entrée de l’activité ainsi que le code PowerShell qui la fera fonctionner.

clip_image014

Dans Parameters, cliquer sur Add. Indiquer le nom du paramètre d’entrée, son mode de fonctionnement (dans notre cas Command Argument), son type (champs texte, champs mot de passe, liste déroulante, browse button…) et éventuellement une valeur par défaut. Ci-dessous deux exemples , un en type Text et l’autre en type Text with Selection (liste déroulante).

clip_image016

clip_image018

Pour réaliser notre exemple d’ajout d’événement dans le journal d’événements, les paramètres suivants sont nécessaires :

Name

Usage mode

Display Style

Options

Log Name

Command Argument

Text

-

Source

Command Argument

Text

-

Content

Command Argument

Text

-

Event ID

Command Argument

Text

-

Event Severity

Command Argument

Text with Selection

Verbose|Information|Warning|Error|Critical

Computer Name

Command Argument

Text

-

Une fois tous les paramètres ajoutés, cliquer sur Insert afin d’entrer le code PowerShell qui sera le « moteur » de notre activité :
Write-eventlog -logname "$(Log Name)" -ComputerName "$(Computer Name)" -Source "$(Source)" -Message "$(Content)" -id "$(Event ID)" -EntryType "$(Event Severity)"

L’onglet Published Data permet d’indiquer quelles informations seront republiées dans le Bus Orchestrator, afin d’être ensuite réutilisées par d’autres activités. Nous n’en rajouterons pas dans cet exemple, mais il est tout à fait possible d’imaginer publier l’ID et le contenu de l’évenement, par exemple.

Cliquer sur OK.

clip_image020

Cliquer sur Next

clip_image022

L’assembly compile…

clip_image024

Voilà, c’est compilé. L’assistant propose de passer directement au packaging de l’Integration Pack, mais il est préférable de commencer par tester notre assembly afin de s’assurer qu’elle fonctionne comme souhaité.

Cliquer sur Finish.

clip_image026

Lancer le Runbook Designer, créer un nouveau runbook et y ajouter les activités Initialize Data et Invoke .NET. Cette dernière est disponible grâce à l’Integration Toolkit importé en début d’article et permet d’exécuter une assembly au format dll comme s’il s’agissait d’un OIP finalisé et packagé, ce qui permet donc de la tester rapidement.

clip_image028

Ouvrir les propriétés de l’activité Invoke .NET. Dans le champ Assembly, sélectionner la dll de l’assembly préalablement crée. Dans Class, sélectionner la class correspondante (dans notre exemple il n’y en a qu’une). Laisser Setup vide (ce champ ne sert que pour les classes développées à l’aide du SDK).

clip_image030

Dans l’onglet Properties, remplir les paramètres de l’activité puis cliquer sur Finish.

clip_image032

Attention ! Il est nécessaire que le journal d’événement ainsi que la source indiqués soient déjà enregistrés sur l’ordinateur cible ! Au besoin, il est possible de les créer à l’aide du PowerShell suivant :
New-EventLog -logname $JournalDevenement -Source $Source -ComputerName $ComputerName -ErrorVariable Err

Dans l’exemple ci-dessus, le journal utilisé est Application (présent par défaut) et la source est TestOIP (n’existe pas d’origine). Nous la créons donc ainsi :
New-EventLog -LogName "Application" -ComputerName "localhost" -source "TestOIP" -ErrorVariable Err

clip_image034

 

Lancer le Runbook Tester et cliquer sur Run.

clip_image036

Si tout s’est bien passé, voilà ce qui doit apparaitre dans l’Event Viewer :

clip_image038

Voilà, le « moteur » de notre Integration Pack fonctionne. Il ne reste plus qu’à le packager pour pouvoir le déployer sous forme d’OIP à notre infrastructure Orchestrator, ce que nous aborderons dans la seconde partie.

Erreur de démarrage du client Outlook à cause du complément Symantec Antivirus

Vous avez ce message d’erreur lorsque vous ouvrez Outlook.

clip_image002

Cela peut être dû à une mauvaise désinstallation de logiciels qui avait ajouté une extension dans Outlook.

Pour résoudre le problème, vous devez aller dans votre profil dans les données applicatives locales de Outlook : %userprofile%\appdata\local\Microsoft\Outlook et de supprimer ou renommer le fichier extend.dat en extend.dat.bak

Relancez Outlook.

L’erreur n’apparaitra plus.

Outil de simulation Netflow: Jalasoft Xian Netflow Simulator.

 

Après avoir proposé un outil de simulation d’equipement SNMP, Jalasoft propose un outil permettant de générer du traffic Netflow.

Pour rappel, NetFlow est une architecture de surveillance des réseaux développée par Cisco Systems qui permet de collecter des informations sur les flux IP.

Ainsi, en terme de supervision reseau, l’analyse de ces flux est un vrai complement a la supervision des équipements source et destination des ces flux.

L’outil de Jalasoft permet de generer du traffic netflow entre plusieurs equipements réseaux.

L’outil est disponible sur le lien:

http://www.jalasoft.com/xian/xiannetflowsimulator/try

Apres avoir installé l’outil, executez-le:

image

Cliquez en haut a gauche sur Add Flow

image

 

image

 

image

Dans l’onglet Simulation settings, definissez l’adresse de destination du traffic (l’adresse source etant l’interface locale)

Definissez:

- Le port local et le port distant

- Laissez les autres options par defaut.

 

Dans l’onglet Flow records settings definissez les adresses sources et destination a simuler,

les protocoles, ainsi que les ports sources et distant a simuler.

- Laissez les autres options par defaut.

Cliquez Finish

image

 

image

Faites un clic-droit sur la simulation générée afin de la demarrer.

Utilisation des cmdlets Exchange 2010 dans System Center Orchestrator.

 

Si vous avez déjà utiliser le module "Exécuter. NET Script" dans System Center Orchestrator, vous avez pu voir que nativement, Orchestrator étant lui même une application 32-bit, il exécute la version 32 bits de PowerShell.

Cela pose problème, si vous voulez utiliser par exemple les comandlets Exchange 2010.

En effet le  snap-in "Microsoft.Exchange.Management.PowerShell.E2010", qui est chargé d'exécuter les cmdlets Exchange, est uniquement disponible en version 64-bit. Donc, le fait d’utiliser le module Orchestrator "Exécuter. NET Script" ne fonctionne pas.

Une des solutions possibles à ce problème consiste a exécuter une version 64-bit de PowerShell.exe à l'intérieur du script. Comme ceci:

OrchestratorPowerShell

Le dossier "Sysnative” n'est en fait pas vraiment un dossier, mais un alias:

Dans les systèmes x64 Windows, les fichiers système sont stockés dans "% WINDIR%\ System32". Dans les systèmes 32 bits les fichiers sont sous "%WINDIR%\SysWOW64". Ainsi, afin d'exécuter la version 64 bits de PowerShell.exe, il nous faut exécuter PowerShell.exe depuis "C:\Windows\system32\WindowsPowerShell\v1.0".

Mais cela ne fonctionne pas en raison de la redirectionWoW64  du système de fichiers. Pour remedier a cela "Sysnative" est l'alias spécial reconnus par WoW64 (responsable de la gestion applications 32 bits), qui indique que le système de fichiers ne doit pas rediriger l'accès à SysWOW64.

Bien sur dans cet exemple, le composant Exchange Management Tools doit être installé sur le runbook server Orchestrator, afin de pouvoir utiliser le snap-in Exchange PowerShell . Conseil supplémentaire: Vous devez définir la variable "$ ErrorActionPreference" à "Stop", comme indiqué ci-dessus, ainsi Orchestrator reconnaitra le runbook comme ayant échoué, si des exceptions se produisent.

runbook tester

Exchange 2010 - Liste de distribution

Après avoir créé une liste de distribution vous souhaitez l’ajouter sur une autorisation de

partage d’un dossier public:

image

Vous constatez que la liste ne peut être ajoutée et est marquée du “panneau accès interdit”.

Cela est dû au fait que la liste est du type Mail Universal Distribution group.

image

On doit donc la convertir via la console ADUC ou par une commande powershell

Active Directory :

image

image

Le groupe de distribution est maintenant de type “sécurité”.

Patientons quelques minutes (réplication AD) puis ajoutons l’autorisation

sur le dossier public:

image

Oups, le problème est toujours présent Triste

Vérifions le RecipientTypeDetails

image

Celui-ci est bien du type MailUniversalSecuritygroup !!!

Regardons l’attribut msExchRecipientDisplayType. Celui-ci à la valeur 1.

Ce qui correspond à un “mail universal distribution group”.

La modification réalisée dans l’interface graphique n’a donc pas été prise en compte.

image

Pour corriger le problème il faut utiliser la commande PowerShell Set-DistributionGroup

image

Vous pouvez rencontrer ce type d’erreur, pas de panique Sourire, rajoutez l’option

-MemberDepartRestriction Closed

 

image

Regardons de nouveau l’attribut msExchRecipientDisplayType:

image

La valeur est maintenant 1073741833 ce qui correspond à un “mail universal security group”.

                                                  **************

image

                                          *********************

Essayons de nouveau d’ajouter ce groupe sur les droits du dossier public:

image

Et voilà, mon groupe de distribution est disponible.

A ce jour ce disfonctionnement n’est pas considéré comme “bug” chez Microsoft .

SCOM – Principes de désactivation totale d’un management pack pour une machine sans le mode maintenance.

 

Pour des raisons autres que la maintenance ponctuelle d’une machine, il peut être intéressant de facilement désactiver la supervision liée a tout un management pack et ceci pour une ou plusieurs machine.

En effet, le mode maintenance de SCOM répond a un besoin plus ponctuel de mise en pause de la supervision. De plus il est conçu pour agir sur une classe d’objet et non pour des groupes de moniteur en particulier.

L’exemple suivant consiste a vouloir désactiver la supervision de Exchange 2010 pour une machine.

Le principe:

1/ Creer un management pack vide qui accueillera les modifications ainsi qu’un groupe:

image

2/ Creation d’un groupe qui sera la cible de tout les overrides crée plus bas.

image

3/ Création de tout les overrides sur tout les objets de monitoring (règles et moniteur) activés par défaut dans le management pack natif Exchange 2010, avec comme cible le groupe CUSTO_Group_CUSTO-Exchange2K10_Monitoring.

IMPORTANT: Cette création (assez fastidieuse surtout pour le MP Exchange !) n’est en fait a realiser qu’une seule fois. A partir du moment ou les overrides sont crées, on agit sur le groupe crée.

4/ Dans l’exemple d’exchange 2010 il suffit d’ajouter a notre groupe les 2 classes/groupes suivants:

- Microsoft Exchange 2010 All Entities Group

- Organization

(en effet l’ajout de ces 2 classes permettent de desactiver toute la supervision Exchange 2010)

Soit de maniere explicite (Add-remove Object)

image

Soit de maniere dynamique (onglet “dynamic members” avec la formule d’inclusion suivante:

image

image

 

Apres avoir validé, au bout de quelques minutes, le serveur cible n’héritera de plus aucune règle et moniteur Exchange 2010.