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 :
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
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.
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
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
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:
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
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:
Fichier MyHostTemplates.cfg:
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)
2/ A présent on va sur l’interface NagiosXI puis a partir de la zone de menu, dans Configure – Core Config Manager.
On sélectionne dans la zone de gauche le lien Tools – Import Config Files
On voit dans la liste des fichiers de config disponible, nos 2 fichiers ajoutés au préalable
Selectionner ces 2 fichier et cliquer sur sur Import
Le message ci-dessous doit s’afficher:
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.
Cliquer sur Apply Configuration
Si la configuration est OK le message ci-dessous doit s’afficher:
Apres quelques minutes les nouveaux hotes apparaissent UP dans les vues de monitoring comme Details – Host Detail.
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.
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.