La nouvelle version du Service Level Dashboard (version 2.0), qui rappelons-le sert à effectuer des mesures de qualité de service (SLA), s’appuie désormais sur Sharepoint!

Voici quelques une des subtilités liées à son installation:

Installation des pré-requis

Installation de Windows Sharepoint Services

Si vous en êtes au stade ci-dessous, arrêtez-vous tout de suite!

En effet, le SLD 2.0 nécessite en pré-requis la version 3.0 de Windows Sharepoint Services.

Il ne s’agit donc pas de la version 2.0 intégrée à Windows Server 2003 (comme le montre la description de la capture ci-dessous) mais d’une version à télécharger ici, ou avec SP2 intégré ici.

Pour information: La version 3.0 n’est pas intégrée dans les services pack de Windows Server 2003.

Après avoir téléchargé Windows Sharepoint Services 3.0, lancer l’exécutable:

C’est mieux :-)

Suivre alors les instructions d’installation de Windows Sharepoint Services. Dans mon cas, il s’agit d’une installation en mode “Advanced” pour un serveur autonome (Stand Alone).

Une fois l’installation terminée, installer le “Service Level Dashboard 2.0”

Installation du Service Level Dashboard 2.0

Le “Service Level Dashboard 2.0” est téléchargeable ici. (ServiceLevelDashboard_x86.msi pour la version 32 bits ou x64 pour la version 64 bits)

Renseigner les informations de connexion au Data Warehouse de SCOM:

Spécifier les informations nécessaires à Sharepoint (propriétaire du site qui sera créé, nom de la base de données et serveur…)

NB: Nous allons conserver le port d’écoute par défaut: 51918

Cliquer sur “Next” puis patienter pendant la création du site web sharepoint dédié au “reporting”:

=> Cette partie de l’installation peut prendre quelques minutes.

IMPORTANT:
Lors de ma première tentative d’installation du SLD 2.0, je me suis retrouvé sans site Web dédié au SLD de créé!
Après un nouveau test, je me suis aperçu que le site était créé au moment de l’apparition de la fenêtre MS-DOS ci-dessus, mais qu’il était supprimé en fin d’installation!

Un dernier test m’a permis de découvrir que la cause du problème venait d’Internet Explorer 8! Il m’a donc fallu le désinstaller (et revenir à IE6. IE7 devrait également fonctionner) pour que l’installation se déroule sans problème (et que le site reste).

Donc si vous avez installé les dernières mises à jours Windows update sur votre serveur, vous savez ce qu’il vous reste à faire. (du moins en attendant une compatibilité du SLD 2.0 avec IE8).

Import du management pack dans SCOM

Ouvrir la console d’administration de SCOM 2007 R2

Importer le Management Pack du Service Level Dashboard présent dans les sources d’installation:

Utilisation

Création d’un Service Level Tracking

Aller ensuite dans la vue Authoring de la console d’administration:

Faire un clic droit dans la section droite, puis “Create”

Saisir un nom pour ce niveau de service

Spécifier ensuite quel est l’objet mesurer pour ce SLA

En cliquant sur Select, on obtient la liste des objets. Dans mon exemple, je sélectionne Active Directory Topology Root:

Cliquer sur Ok

Sélectionner dans quel management pack mémoriser ce Service Level et cliquer sur Next

Il faut maintenant définir le(s) seuil(s) correspondant aux engagements:

Cliquer sur Add, puis “Monitor state SLO”

Saisir un nom pour cet objectif, ainsi que l’objectif fixé et les critères de disponibilité. Exemple: 99% de disponibilité

Cliquer sur OK

Cliquer sur Next

et sur Finish

Fermer la fenêtre.

Le “Service Level” apparait dans la console d’administration:

Après quelques instant, se rendre sur le site Web du “Service Level Dashboard 2.0”:

Affichage du résultat

Le “Service Level” apparait dans le site (http://<nomDuServeur>:<Port d’écoute>):

Il peut arriver de devoir passer par un script de résolution d’alertes pour pouvoir nettoyer régulièrement certaines alertes de la console tel que les alertes d’échec de script. Le script suivant est fait pour cela.

Remplacez le nom FQDN_DU_SERVEUR_SCOM  par le fqdn de votre serveur SCOM

Créez une tache planifiée et faites exécuter la commande toutes les heures par exemple en fonction de la fréquence de ces alertes:

“powershell.exe –noninteractive –file chemin_du _script”

#ce script est executé par tache planifiée tout les jours a 00:00 et clos les

#alertes de nommées 'Script or Executable Failed to run'

#ou 'Discovery Probe Module Failed Execution'dont la date de #modification est superieur a #maintenant moins 24 heures.

#Initialisation du provider Ops Mgr 2007 

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin;

set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;

new-managementGroupConnection -ConnectionString:FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

set-location FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

#Checks to see if it failed or succedded in loading the provider

if ($errSnapin.count -eq 0)

{

Write-host "`nOpsMgr 2007 PSSnapin initialized!";

}

else

{

Write-host "OpsMgr 2007 PSSnapin failed initialize! Please verify you are running this script on a OpsMgr 2007 Management Server";

}

$alerttoclose = get-alert | where-object {$_.Name -eq "Script or Executable Failed to run" -or $_.Name -match "^.*Discovery Probe Module Failed Execution"} | where-object {$_.resolutionstate -ne '255'} | where-object {$_.LastModified -gt [DateTime]::Now.Addhours(-24) }

foreach ($alert in $alerttoclose)

{

$alert | resolve-alert

}

Microsoft vient de publier de nouveau agent pour les systèmes d’exploitations Unix/Linux.

Ces agents ajoutent le support de Suse Entreprise 11, Solaris Zone et corrigent un problème de charge CPU.

Attention: cette mise à jour est relativement conséquente puisqu’elle pèse tout de même 250Mo!

Le téléchargement se fait ici.

Une nouvelle version du fichier Excel d’aide au dimensionnement de “System Center Operation Manager” (compatible avec SCOM 2007 R2) est sorti.

Le fichier est en version 1.1 et nécessite l’utilisation des macros pour fonctionner.

Le téléchargement se fait ici.

A quoi ressemble l’installation d’un agent SCOM sur une version Core de Windows 2008 R2?

Et bien, pas de différence au niveau de l’installation de l’agent (du moins à distance):

1) Découverte

2) Installation

La spécificité du système d’exploitation (version Core) n’est pas indiquée dans le nom du système d’exploitation détecté (Microsoft Windows Server 2008 R2 Enterprise):

mais un nouveau type d’objet permet de les distinguer:

Notons au passage qu’il en est de même pour les Windows 2008 et que les Windows 2008 R2 sont également inclus dans la catégorie Windows Server 2008 Operating System (ce qui paraît logique)

ça y est, le management pack Windows Server Operating System compatible Windows 2008 R2 est disponible.

Il est téléchargeable en cliquant ici

avant:

après:

Un petit exemple de compteur de performance avec un Windows 2008 R2:

et un autre exemple sur un nouveau type de moniteur: le niveau de fragmentation d’un disque:

Attention cependant aux upgrades vers Windows 2008 R2: http://support.microsoft.com/kb/974722/en-us

Pour superviser un service nous utilisons habituellement un modèle  packs d'administration, malheureusement il est impossible de le redémarrer automatiquement car ce modèle  est stocké dans un pack d’administration scellé.

Pour cela nous allons suivre la procédure suivante :

• Créer un pack d’administration personnalisé pour y stocker l’analyse
• Créer un groupe sur lequel va être appliquée l’analyse
• Créer une analyse pour surveiller le service
• Appliquer l’analyse au groupe via un « override »
• Créer la tache de récupération

Création d’un pack d’administration

Dans la console, dans la partie Administration,  faire un clic droit sur Management Packs et choisir “Create Management Pack”.

Nommer le MP.

Cliquer sur Next

Cliquer sur Create

Créer le Group

Dans “Authoring” Faire un clic droit et choisir “create new group”

Nommer le groupe et stocker-le dans le MP créé précédemment.

Cliquer sur Next

Cliquer sur Add/remove objects dans le Explicit Group Members

Entrer le nom d’un serveur et cliquer sur search. Selectionner le “computer object” et cliquer sur ok.

Cliquer sur Next

Laisser les options par défaut et cliquer sur Next

Cliquer sur Create

Créer le Monitor 

Dans Authoring faire un clic droit sur monitors, choisir Create a monitor, Unit Monitor.

Dans Windows Services choisir “Basic Service Monitor”. Utiliser le MP créé précédemment

Entrer un nom pour le monitor, Cliquer sur Select…

Sélectionner la cible en tapant le nom du groupe visé .

Cliquer sur OK

Cliquer sur Next

Cliquer sur “…”

Cliquer sur “…”

Entrer le nom du serveur où le service à superviser est actif.

Sélectionner le service à surveiller (ici XRT LAD server) puis cliquer sur OK

Cliquer sur Next

Cliquer sur Next

Ne pas cocher la case “Generate alerts for this monitor:” pour le moment. 

Créer la Recovery Task

Dans Authoring choisir le monitor créé précédemment, faire un clic droit et sélectionner properties.

Cliquer sur l’onglet Diagnostic and Recovery 

Cliquer sur Add… et choisir “Recovery for Critical Health State”

Sélectionner Run Command et cliquer sur Next

Entrer un nom pour la recovery task, une description et cocher les cases “run recovery automatically” and “recalculate monitor state.”

Cliquer sur Next.

Dans le Full path to file, entrer

C:\WINDOWS\system32\net.exe

Dans les paramètres mettre :

start "XRT LAD SERVER"

Puis cliquer sur Create

Cliquer sur OK

Etapes principales de mise en place de certificats pour les agents SCOM en workgroup et pour le serveur SCOM sans utiliser de gateway server.

1) Installer une authorité de certification de type « stand alone server » sur une machine (cette machine peut etre physique ou virtuelle)

2) Exporter le certificat racine de l’authorité (nom par defaut : certnew.p7b) vers un dossier partagé

3) Depuis le serveur en workgroup ou le serveur SCOM, lancer une mmc et ajouter le composant enfichable « Certificates »
Dans la console « Certificates » faites un clic droit sur le dossier « Authorite de certification racine de confiance » (en anglais : Trusted Root Certification Authorities) et selectionner Importer. Allez Rechercher le fichier certnew.p7b crée plus haut. Laissez l’assistant placer le fichier dans le magasin « Authorite de certification racine de confiance ».

4) Toujours depuis le serveur en workgroup ou le serveur SCOM, ouvrez votre navigateur et allez a l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv


Cliquez sur "Request a certificate" (Demander un certificat)



Cliquez sur "advanced certificate request"



Cliquez sur Create and submit a request to this CA

Renseignez le formulaire de creation de certificate de la manière ci-dessus, c’est a dire:
Name : le nom de votre serveur en workgroup (Doit etre identique au champ Friendly Name au bas du formulaire)
Company : le nom de la société
Type of certificate needed : selectionnez Other... et renseignez les OID suivant:
1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2   (pas d’espace autour de la virgule!)

Cochez les cases “Mark Key as Exportable” et “Store certificate in the local computer certificate store”

Renseignez le friendly name (I.E : Doit etre identique au champ Name)

Cliquez Submit

Cliquez Yes si le message ci-dessus apparait

5) Depuis le serveur hébergeant l’autorité de certification, ouvrez la console mmc « Autorité de certification »

Ouvrez le dossier «　Pending Request　». le certificat demandé plus haut doit apparaitre. Il est en attente d’approbation

Cliquez droit dessus et selectionnez « Issue »



Le certificat doit apparaitre désormais dans le dossier Issued Certificates

6) Depuis le serveur en workgroup ou le serveur SCOM, retournez sur l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv

Selectionnez Afficher le statut d’une requete de certificat en attente

Selectionnez le certificat

Installez le certificat



Il apparait désormais dans le dossier Personal/Certificates de la console mmc «　Certificates　» du serveur en workgroup ou du serveur SCOM

7) Depuis la console « Certificates » du serveur en workgroup, faites un clic droit sur le fichier de certificat present sous le dossier Personal et selectionnez « Export ». Exportez le vers le dossier partagé crée en etape 2.








Selectionnez Yes Export the private key



Laissez les options par défaut



Renseignez un mot de passe pour le certificat

Renseignez le dossier partagé vers lequel exporter le certificat

8) Sur le serveur en workgroup si l’agent SCOM est déjà installé passez a l’étape 9, sinon effectuez une installation manuelle de l’agent SCOM

9) Sur le serveur en workgroup ou sur le serveur SCOM, ouvrez une ligne de commande vers l’outil MOMCertimport.exe
Tapez la ligne de commande suivante :

Momcertimport.exe <chemin_du_certificat_exporté> /password <password_du_certificat>

Cette commande ajoute une valeur dans le registre de SCOM  représentant le certificat :

10) Redémarrez le service de l’agent sur le serveur en workgroup.

Le nouvel agent doit à présent apparaitre dans la vue Pending de la console SCOM.

Il ne reste plus qu’a l’approuver.

Très important changement de comportement dans la R2 de SCOM :

http://support.microsoft.com/kb/967537

l’état de l’agrégat de moniteur le plus élevé (top level monitor) d’une machine (availability, performance etc..) se répercute sur le groupe contenant la machine.
Ceci était désactivé par défaut dans la SP1.
Le lien donne des infos pour tracer d’éventuels changement trop fréquent et désactiver ce rollup.

Parmis les nouveautés de la version 2007 R2 de SCOM, nous pouvons noter la possibilité de s'abonner directement à une alerte depuis la vue des alertes!

On se retrouve alors directement dans l'assistant d'abonnement aux notifications: