Voici les grandes étapes de mise en place de la supervision d’une application .NET a travers la fonctionnalité APM de SCOM 2012.
L’application pris en exemple, DotNetNuke, peut etre installée facilement a travers WPI (Web Platform Installer), outil de déploiement de toutes les application web gratuite fournies par Microsoft.
- Import des management pack IIS 7
Fichier Microsoft.Windows.InternetInformationServices.CommonLibrary.mp
Fichier Microsoft.Windows.InternetInformationServices.2008.mp
- Import des management pack APM IIS 7
Fichier Microsoft.SystemCenter.Apm.Web.IIS7.mp
- Deploiement d’un agent SCOM sur le serveur IIS hebergeant l’application
Le pool d’application DotNetNuke est découvert a la suite de l’installation de l’agent.
- Creation d’un groupe dédié
- Ajout a ce groupe de l’objet “Windows Computer” correspondant au serveur DotNetNuke
- Execution du template .NET Application Performance Monitoring
- Ajout de l’application DotNetNuke, Sélection du type d’environnement et ciblage vers le groupe crée précédemment.
- Configuration des réglages spécifiques
- Fin de création du moniteur - L’assistant averti qu’il peut être nécessaire de redémarrer le service IIS pour permettre au moniteur crée de fonctionner.
- L’assistant a crée une arborescence spécifique a l’application, au sein du groupe de vues Application Monitoring.
Management pack pour Remote Access 2012
Supervision du nouveau service d’acces distant de Windows (Unification de Direct Access et Routing and Remote Acces Server).
Management Pack for Windows Server Hyper-V 2012
Supervision de Hyper-V v3.
Global Service Management Packs
Ce management pack, couplé a l’abonnement au Global Service Monitor de la plate-forme Azure implemente la possibilité d’avoir une prespective de disponibilité d’une application depuis un site externe a l’entreprise. (Notion de “agent in the cloud”)
Monitoring Pack for Windows Server Backup
Supervision des services de sauvegarde de Windows.
Les événements supervisés sont notamment:
· Backup cancelled
· Backup failed
· Backup failed due to snapshot
· Backup partially succeeded
· Backup succeeded with skipped files
· Recovery failed
· Recovery succeeded with warnings
Microsoft Dynamics NAV 2013 Management Pack
Supervision de Microsoft Dynamics NAV 2013 , progiciel de gestion pour les petites et moyennes organisations qui automatise et simplifie les processus métier.
http://pinpoint.microsoft.com/en-US/applications/microsoft-dynamics-nav-2013-management-pack-for-system-center-12884952897
Security Monitoring for Endpoint Protection
Supervision des clients anti-virus EndPoint Protection
Monitoring Pack for UNIX and Linux Operating Systems
Supervision des systemes Unix/Linux suivants:
AIX 5.3, 6.1 et 7
HPUX 11 V2 et V3
RHEL 4, 5 et 6
Suse Linux ES 9,10 et 11
Solaris 9,10 et 11
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:
Cliquez en haut a gauche sur Add Flow
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
Faites un clic-droit sur la simulation générée afin de la demarrer.
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:
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.
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.
Le script suivant:
- envoi un mail a un responder (ping@oleane.net)
- attends et récupère la réponse du responder dans Outlook
- retourne un état en cas d’echec
- retourne un état et le message en cas de succes, et supprime le message.
Prerequis: client outlook installé avec le composant “Visual Basic for application” et présence de l’assembly .net Microsoft.Office.Interop.Outlook (cette assembly est présente dans le dossier C:\Windows\assembly).
Dans le menu Outil/Macro/Sécurité , cochez l’option ci-dessous
Paramètre de script a modifier:
$smtpServer: le nom du serveur smtp
$From: l’emeteur du mail
$ReplyTo: l’adresse de réponse
$Dest: le destinataire du mail
$Subject: le sujet du mail
$Body: le corp du mail
$SecondToWait: le temps d’attente de la réponse du responder
[System.Reflection.Assembly]::Load("Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
[string]$smtpServer=”mon_serveur_smtp@home.fr”
[string]$From="test@home.fr"
[string]$ReplyTo="test@home.fr"
[string]$Dest="ping@oleane.net"
[string]$Subject="Test envoi mail"
[string]$Body="Test envoi mail"
[string]$SecondToWait =90
function sendMail
{
Write-Host "Sending Email"
#Creating a Mail object
$msg = new-object Net.Mail.MailMessage
#Creating SMTP server object
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
#Email structure
$msg.From = "$From"
$msg.ReplyTo = "$ReplyTo"
$msg.To.Add("$Dest")
$msg.subject = "$Subject"
$msg.body = "$Body"
#Sending email
$smtp.Send($msg)
}
Function Get-MessageInBox
{
Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null
$olFolders = "Microsoft.Office.Interop.Outlook.olDefaultFolders" -as [type]
$outlook = new-object -comobject outlook.application
$namespace = $outlook.GetNameSpace("MAPI")
write-host "waiting for the response from Oleane..."
$namespace.SendAndReceive($false)
sleep -Seconds $SecondToWait
$folder = $namespace.getDefaultFolder($olFolders::olFolderInBox)
$folder.items |
Select-Object -Property * -Last 1 | where-object {$_.subject -eq "[echo] Votre message a $Dest"}
}
Function Delete-mail
{
Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null
$olFolders = "Microsoft.Office.Interop.Outlook.olDefaultFolders" -as [type]
$outlook = new-object -comobject outlook.application
$namespace = $outlook.GetNameSpace("MAPI")
$folder = $namespace.getDefaultFolder($olFolders::olFolderInBox)
$folder.items | Select-Object -Property * -Last 1 | where-object {$_.subject -eq "[echo] Votre message a $Dest"} | tee-object -Variable MessageToDelete
$folder.Items.Remove(1)
}
#Calling function sendmail
sendMail
#Retrieve message to oleane in inbox
Get-MessageInBox | Tee-Object -Variable Message | out-null
if ($Message -eq $null)
{
write-host -ForegroundColor Darkred "---PAS ENCORE DE REPONSE DE $Dest---"
}
else
{
write-host -ForegroundColor Darkgreen "---REPONSE OK DE $Dest---"
Write-Host -ForegroundColor Darkgreen "----MESSAGE----:"
Write-Host "SUJET:" $Message.Subject
Write-Host "ENVOYE LE:" $Message.SentOn
Write-Host "RECU LE:" $Message.ReceivedTime
Write-Host "CORP DU MESSAGE:" $Message.Body
Clear-Variable -Name Message
Write-Host -ForegroundColor Yellow "SUPPRESSION DU MESSAGE..."
Delete-mail | Out-Null
}
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}
}
}
Independemment de la portabilité des variable dans un script, un problème se pose lorsque vous souhaitez, dans un script, accéder des variable locales depuis des commandes executées sur une machine distante.
Exemple:
$vmmserver="monserveurvmm.home.com"
$VmToStop="c:\BackupAdmin\VMToStop.txt"
if (!(test-path $VmToStop))
{
write-host "le fichier des VM $VmToStop a eteindre introuvable. le script va s'arreter"
Exit
}
else
{
$VmToStop= Get-Content $VmToStop
foreach ($vm in $VmToStop)
{
Invoke-Command -ComputerName $vmmserver -ScriptBlock {
param($vm,$vmmserver)
Add-PSSnapin microsoft.systemcenter.virtualmachinemanager
$vmstatus= (get-vm -Name $vm -VMMServer $vmmserver | Select-Object -Property status)
if ($vmstatus.status -eq "running")
{
write-host "La VM $vm est démarré et va etre arretée"
Shutdown-VM -VM $vm
}
elseif ($vmstatus.status -eq "PowerOff")
{
write-host "La VM $vm est déja arrétée"
Exit
}
} -Argumentlist $vm,$vmmserver
}
}
##################################
Dans ce script qui recherche dans un fichier “VMToStop.txt” une liste de machine virtuelles a arrêter, un bloc de commande est executé a distance (Invoke-Command -ComputerName $vmmserver -ScriptBlock { } ) sur un serveur scvmm. Comment faire en sorte que les commandes executées a distance connaissent les variables locales $vm et $vmmserver ?
param($vm,$vmmserver) va permettre de declarer une liste de variable dans le ScriptBlock
-Argumentlist $vm,$vmmserver va permettre de faire la liaison entre le contenu de param et les variables locales.
A noter que le nom des variables déclarées par param est arbitraire, mais il est nécéssaire que ces variables soit dans le meme ordre que celles de –Argumentlist .
Le script suivant prends en paramètre un nom de machine et un nom d’application (apparaissant dans Ajout-suppression de programme), desinstalle l’application si elle est trouvée, affiche les resultats et les inscris dans un fichier de log.
Param(
[Parameter(Mandatory = $true)][string]$computername=(read-host -Prompt "entrez le nom de la machine"),
[Parameter(Mandatory = $true)][string]$application=(read-host -Prompt "entrez le nom exact de l'application"),
[string]$credential="administrator"
)
$logfile="c:\result.txt"
$now=(get-date).ToString()
$appuninstall=Get-WmiObject -ComputerName $computername -Class win32_product -Credential $credential | where-object {$_.name -eq $application}
if ($appuninstall -eq $null)
{
write-host "Application $application non trouvée" -ForegroundColor yellow -BackgroundColor black
write-host "Resultat inscris dans $logfile" -ForegroundColor yellow -BackgroundColor black
Out-file $logfile -Append -InputObject "$now -- Application $application non trouvée sur $computername"
exit
}
foreach ($app in $appuninstall)
{
write-host "...debut desinstallation..." -ForegroundColor yellow -BackgroundColor black
$app.uninstall()| Tee-Object -Variable uninstallresult
if ($uninstallresult.ReturnValue -eq 0)
{
write-host "Desinstallation OK pour $computername" -ForegroundColor green -BackgroundColor black
write-host "Resultat inscris dans $logfile" -ForegroundColor green -BackgroundColor black
Out-file $logfile -Append -InputObject "$now -- Desinstallation OK pour $computername"
}
else
{
write-host "Desinstallation KO pour $computername" -ForegroundColor red -BackgroundColor black
Out-file $logfile -Append -InputObject "$now -- Desinstallation KO pour $computername"
write-host "Resultat inscris dans $logfile" -ForegroundColor red -BackgroundColor black
}
}
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.