PI Services

Le blog des collaborateurs de PI Services

WMI : Reconstruction de la couche WMI

 

Nous allons traiter d’un sujet particulier , la reconstruction de la couche WMI sur Windows

 

RAPPEL :

 

WMI est un système de gestion interne de Windows qui prend en charge la surveillance et le contrôle de ressource système via un ensemble d’interfaces. Il fournit un modèle cohérent et organisé logiquement des états de Windows.

Il permet à des scripts PS1 (Powershell) par exemple de gérer Windows localement ou à distance. C'est grâce à WMI que le composant Propriétés système de Windows peut afficher les propriétés du système sur un ordinateur distant ou local.

WMI est préinstallé sur depuis Windows 2000 jusqu’à 2012 R2

 

PARTIE 1 : COMMANDE SOUS POWERSHELL

 

 

Il faut savoir qu’il se peut parfois qu’un objet de la classe de la couche WMI ne soit pas fonctionnel

 

Exemple sous Powershell :

image

Get-wmiobject –class win32_operatingsystem nous retourne les informations liés au system d’exploitation.

 

Mais lorsque le retour d’information de la classe Win32_operatingsystem retourne une erreur , cela veut dire que cette classe est manquante dans la couche WMI ce qui n’est pas normal car cette classe est par défaut intégré dans tout les systèmes d’exploitation Windows.

 

Pour cela nous pouvons taper la commande suivante sous powershell ou cmd

WBEMTEST

 

image

 image

image

image

 

 

PARTIE 2 : SOLUTION

1\ Recompiler les fichiers Microsoft Windows .MOF :

net stop winmgmt
c: 
cd %systemroot%\system32\wbem 
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll 
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof 
mofcomp cimwin32.mfl 
mofcomp rsop.mof 
mofcomp rsop.mfl 
for /f %s in ('dir /b /s *.dll') do regsvr32 /s %s 
for /f %s in ('dir /b *.mof') do mofcomp %s 
for /f %s in ('dir /b *.mfl') do mofcomp %s

 

N'oubliez pas de redémarrer le serveur ou le poste client sur lequel la couche WMI est défectueuse pour que les modifications soient pris en compte.

SMG : Mise à Jour Symantec Messaging Gateway 10.5.4-4 vers 10.6.0-3

 

Voici un retour d’expérience sur les mises à jour concernant les Appliances Symantec Messaging Gateway (ANTI-SPAM)

La mise à jour se décompose en 2 parties:

 

PARTIE 1 : Télécharger la mise à jour 10.6.0-3

 

image

PARTIE 2 : Mise à jour Version 10.5-4-4 vers 10.6.0-3

 

Conséquence lors du lancement de la mise à jour sur les services suivant:

Control Center => perte de la console envoie/réception de mail est ok

Scanner => perte envoie/réception de mail

ATTENTION pour la partie scanner il faut arrêter la réception de mails 30 minutes avant le passage de la mise à jour

clip_image001

Symantec indique entre 1 à 3 heures pour notre plateforme SMG a été entièrement mise à jour de la Version  10.5.4-4 vers la version 10.6.0-3 avec les temps ci-dessous:

Le Control center : Temps d’installation environ 45 minutes/1 heure

Le Scanner principal (MX1) : Temps d’installation environ 30 minutes

Le Scanner secondaire (MX10) : Temps d���installation environ 30 minutes

Notre PLATEFORME SMG est la suivante:

image

 

installation de la mise à jour mineure sur SMG (passage de la version 10.6.0-3 à la version 10.6.0-5). à pris environ 10 minutes par ApplianceAplliance

image

Nagios XI – Import de fichier de config via CCM

 

L’outil de configuration CCM (Core Configuration Manager) permet entre autre l’import de fichier de configuration contenant des définitions d’objets a prendre en compte.

!: L’import de nouveaux objets dans Nagios obéit bien sur aux dépendances possible entre objets en cas de reference a d’autres objets.

Dans cet exemple on va importer deux fichier de config; MyHosts.cfg et MyHostTemplates.cfg qui sont issu d’une version Core de Nagios.

MyHosts.cfg fait référence a des templates contenus dans MyHostTemplates.cfg.

MyHosts.cfg fait référence également a des groupes d’hote (hostgroups) définis dans le même fichier, a la suite.

Fichier MyHosts.cfg:

image

image 

 

Fichier MyHostTemplates.cfg:

image

 

1/ Sur le serveur nagiosxi on copie le fichier MyHosts.cfg sans modification dans le repertoire /usr/local/nagios/etc/hosts et le fichier MyHostTemplates.cfg dans le repertoire parent. /usr/local/nagios/etc (avec les autres fichiers de config natif)

image

image

 

2/ A présent on va sur l’interface NagiosXI puis a partir de la zone de menu, dans Configure – Core Config Manager.

image

 

On sélectionne dans la zone de gauche le lien Tools – Import Config Files

image

 

On voit dans la liste des fichiers de config disponible, nos 2 fichiers ajoutés au préalable

image

 

Selectionner ces 2 fichier et cliquer sur sur Import

image

image

Le message ci-dessous doit s’afficher:

image

En revenant dans un des vues de Monitoring on peut voir de nouveaux hotes avec un message precisant que la configuration n’a pas encore été appliquée.

image

image

 

Cliquer sur Apply Configuration

Si la configuration est OK le message ci-dessous doit s’afficher:

 

image

Apres quelques minutes les nouveaux hotes apparaissent UP dans les vues de monitoring comme Details – Host Detail.

image

image

SCOM – Utiliser un Run As dans un script

Dans un précédent billet, je décrivais comment Ajouter un Run-As profile à un moniteur ou à une règle, afin de les faire s’exécuter avec des credentials autres que Local System.

Je vous propose ici un complément sur le même sujet, qui vous permettra d’utiliser en paramètre d’un script un couple login/mot de passe stocké dans un Run-As account, vous permettant ainsi de ne pas coder ces credentials en dur dans le script pour plus de sécurité et de maintenabilité.

Tout le début de cette procédure est exactement identique à celle proposée dans le précédent billet, vous pouvez donc vous y référer si vous ne disposez pas encore d’un couple run as profile/run as account contenant vos credentials.
Notez toutefois qu’il faut ici créer un un run as account de type Simple Authentication et non pas un compte Windows.

Une fois ceci fait et en possession de l’ID du Run As profile, nous pouvons revenir à notre moniteur ou règle de type script.

Dans les paramètres passés au script, il est alors possible de faire appel à ce profil à l’aide la syntaxe

$RunAs[Name="Test.Monitors.RunAsProfile"]/Username$ pour le login et

$RunAs[Name="Test.Monitors.RunAsProfile"]/Password$ pour le mot de passe.

Le login et le mot de passe (automatiquement déchiffré et donc passé en clair au script) seront alors passés au script lors de son exécution.

clip_image002

Il ne reste alors plus qu’à les déclarer et les assigner à une variable dans le script, puis à les utiliser par exemple ici pour se connecter à un serveur SQL :

Dim Username, Password, sConnectString
Username = WScript.Arguments(0)
Password = WScript.Arguments(1)
[…]
sConnectString = "Driver={SQL Server}; Server=SQL\TEST; Database=TESTDB;uid=" & Username & ";password=" & Password
[…]

On le voit, le mot de passe n’est jamais codé en clair dans le script et pour le modifier, il suffit de modifier le Profil et non pas le script.