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:
2/ Creation d’un groupe qui sera la cible de tout les overrides crée plus bas.
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)
Soit de maniere dynamique (onglet “dynamic members” avec la formule d’inclusion suivante:
Apres avoir validé, au bout de quelques minutes, le serveur cible n’héritera de plus aucune règle et moniteur Exchange 2010.
Voici un script de resolution d’alertes indésirables qui utilise:
1- une expression reguliere pour filtrer certains champs d’alertes
2 – une declaration switch pour prendre en charge des filtres de maniere plus pratique qu’avec if…else.
#Fermeture de certaines alertes#>
<#modifiez et/ou Incrementez les variables alertes pour prendre en charge d’autres noms d’alertes#>
$Alert1="The previous system shutdown (le dernier arret systeme n'etait pas prévu)"
$Alert2="Redemarrage Propre du serveur"
$Alert3="Database Backup Failed To Complete"
$Alert4="Network interface failed."
<#modifier $MachinePattern avec une autre expression reguliere. Ici par defaut
on recherche les alertes générées par une machine dont le nom contiens la chaine “TEST”#>
$MachinePattern="^.*(TEST).*$"
#Initialisation du provider SCOM
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin -erroraction silentlycontinue;
set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;
new-managementGroupConnection -ConnectionString:monserveurscom.home -ErrorVariable errSnapin;
set-location monserveurscom.home -ErrorVariable errSnapin;
#Verification du chargement du provider SCOM
if ($errSnapin.count -eq 0){
Write-host "`nOpsMgr 2007 PSSnapin initialized!`n";
}
else{
Write-host "`nOpsMgr 2007 PSSnapin failed initialize!`nPlease verify you are running this script on a OpsMgr 2007 Management Server";
}
$AllOpenAlert=get-alert | where-object {$_.ResolutionState -eq "0"}
Foreach ($alert in $AllOpenAlert)
{
switch($alert)
{
{$_.Name -eq $Alert1 -OR $_.Name -eq $Alert2 -AND $_.MonitoringObjectName -match $MachinePattern -AND $_.LastModified -lt [DateTime]::Now.Adddays(-1)} {resolve-alert -Alert $_ ; write-host -NoNewline $_.Name "SUR" $_.MonitoringObjectName " -- "}
{$_.Name -eq $Alert3 -OR $_.Name -eq $Alert4 -AND $_.MonitoringObjectPath -match $MachinePattern -AND $_.LastModified -lt [DateTime]::Now.Adddays(-1)} {resolve-alert -Alert $_ ; write-host -NoNewline $_.Name "SUR" $_.MonitoringObjectPath " -- "}
default {break}
}
}
En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.
Network Summary, Network Node, Network Interfaces et Vicinity view.
- La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)
Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.
- La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :
- la vue des liens connectés à l’équipement sélectionné
- des jauges sur la disponibilité de l’équipement dans le temps
- la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.
- La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.
- La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.
Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.
La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.
En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.
La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».
Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.
A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.
Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:
l’execution d’une GPO a échoué pour ce compte.
Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.
Cette mise a jour du management pack disponible a l’adresse ci-dessous, prend en charge les apports du Service Pack 1 d’Exchange 2010.
Au meme titre que les autres applications Microsoft, les management pack utilisés pour la supervision de SCOM sont mis a jour régulierement. En temoigne cette nouvelle mis a jour disponible sur:
Au menu entre autres:
Un nouveau rapport “Agents by Health State” affichant l’etat de tout les agents, RMS, MS et Gateway server, regroupé par états.
Une nouvelle alerte “An alert subscription has been automatically disabled due to invalid configuration” alertant dans le cas de l’echec d’une notification du a une mauvaise configuration de cette derniere.
Un agregat de moniteurs dédié a la supervision de l’etat de WMI et de son service NT lié: winmgmt.
Ce qui avait été annoncé comme non supporté fait finalement l’objet d’une procédure particulière utilisant l’outil de création des bases SCOM, DBCreateWizard.exe inclu dans les sources de SCOM.
Pour plus de détails rendez vous sur http://support.microsoft.com/kb/2425714
Un type d’alerte dont la répétition est particulièrement indésirable est celui des erreur liés a des requêtes WMI en échec du a des problèmes de ressources système:
HRESULT: 0x800700a4
Details: No more threads can be created in the system.
HRESULT: 0x80041001
Details: Generic failure
HRESULT: 0x80041006
Details: Out of memory
En effet, la gestion de la mémoire dans WMI est assez spécifique et ces erreurs sont susceptibles d’intervenir même sur des systèmes bien dimensionnés
Cette alerte qui peut être récurrente a donc une source externe a SCOM.
Ces alertes et erreurs associées peuvent être évitées en modifiant un des paramètres WMI correspondant a la mémoire.
Pour cela, sur la machine concernée par l’erreur:
- Executez la commande wbemtest (en mode administrateur)
- Connectez vous a l’espace de nom "root" (pas "root\default", juste "root")
- Selectionnez Ouvrir une instance (ou Open an instance)
- Tapez __ProviderHostQuotaConfiguration=@ et cliquez OK
- Cochez la case “Locales seulement" (Local Only), selectionnez la propriété MemoryPerHost ou ThreadsPerHost selon la source de l’erreur (voir plus haut)
Modifiez ces valeurs de manière raisonnable (valeur double pour commencer)
- Cliquez sur Enregistrer la propriété (Save Property) puis sur Enregistrer l’objet (Save Object)
- Redémarrer le service Windows Management Instrumentation
La version R2 de Xian Network Manager IO viens de sortir !
Au menu de la plus facile a intégrer et a configurer des solutions de supervision complémentaire de SCOM:
- La possibilité d’ajouter vos propres règles de supervision SNMP si elles ne sont pas fournis nativement dans les smart management pack de Jalasoft.
- Une interaction avec Savision liveMaps (solution de cartographie proposé en bundle avec Xian) permet désormais de découvrir automatiquement la topologie réseau et de la cartographier a partir des informations fournis par Xian.
- Calcul de seuil de performance automatique dans le même esprit que les self-tunning threshold ce SCOM
- Gestion plus intelligente des informations envoyés a SCOM afin de limiter les alertes
- Système de filtrage des composants issus des équipements réseaux afin de n’afficher dans SCOM que les objets réellement supervisés