PI Services

L’exemple suivant montre l’utilisation du plugin check_nrpe avec un script vbs check_ad.vbs pour la supervision des principaux services Active Directory. (NB: Le script check_ad parse la sortie de dcdiag.exe pour déterminer des états)

Prérequis:

• Sur le serveur Nagios: Serveur NRPE actif
• Sur le contrôleur de domaine cible: utilitaire dcdiag.exe ; Agent NSCP actif ; NRPE Server activé dans le fichier nsclient.ini (NRPEServer = 1)
       
Le script utilisé est disponible sur le lien

https://exchange.nagios.org/components/com_mtree/attachment.php?link_id=2332&cf_id=241/

  on copie le script en tant que check_ad.vbs, dans le dossier des scripts de l’agent nscp (par défaut “C:\Program Files\NSClient++\scripts”

2/

on indique dans le fichier de configuration nsclient.ini l’alias et le chemin correspondant de la manière suivante

; A list of scripts available to run from the CheckExternalScripts module. Syntax is: <command>=<script> <arguments>
[/settings/external scripts/scripts]

check_ad=cscript.exe //Nologo scripts\\check_ad.vbs

3/ on redémarre le service NSClient++

4/ Sur le serveur Nagios depuis le répertoire des plugins contenant check_nrpe, on teste la commande:   ./check_nrpe -H 192.168.0.55 -c check_ad

5/ Définition de la commande dans le fichier command.cfg

#####################################
### COMMANDES VIA CHECK_NRPE #######

# 'check_ad' command definition
define command{
        command_name    check_ad
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_ad
        }

6/ Création du service correspondant dans le fichier contenant les definitions de services:

define service{
        use                             local-service
        host_name                       homeserv1
        service_description             AD DCDIAG Result
        check_command                   check_ad

7/ Le résultat après quelques secondes dans l’affichage d’état du contrôleur de domaine concerné:

Le script suivant:

- interroge l’AD pour récupérer une liste des machines serveurs à superviser

- Détermine si la machine est reconnu (DNS)

- Détermine si la machine répond au ping

- Détermine si la machine héberge le client NSClient++ (NSCP)

- Sur la base de ces infos, des fichiers de config d’hôtes sont construit, une archive du jour (tar.gz) des fichiers à remplacer est créé dans le même répertoire. Les fichiers de conf sont ensuite envoyés par FTP dans le répertoire « /usr/local/nagios/etc/objects/HOME/HOSTS/ » du serveur nagios.

Le demon nagios est redémarré à la suite.

Savision, éditeur spécialisé dans le développement de solution de maps et dashboard pour System Center et VMWare, fourni une version gratuite de Dashboard by Savision.

https://www.savision.com/scom-dashboards

L’idée est de regrouper sous forme de dashboard a la sauce HTML5 les infos d’état et de performance des objets scom et d’avoir une solution modulaire et extensible de dashboards.

De plus, l’affichage est compatible pour une utilisation sur mobile.

Bonjour,

je vais vous présenter un générateur de Windows Pre Environment (WinPE)

Dans cette application, vous pouvez :

générer un environnement de construction Windows PE

Ajouter les fonctionnalités suivantes :

WinPE-Scripting
WinPE-NetFx
WinPE-PowerShell
WinPE-DismCmdlets
WinPE-WMI
WinPE-StorageWMI
WinPE-Dot3Svc
WinPE-HTA

Mettre la langue du PE en français

Générer une image ISO.

Remarque:

L’outil fonctionne en One Shot : création + ajout de fonctionnalités.

La simple édition d’un PE déjà construit n’est pas pris en compte.

Pré requis

L’ADK doit être installé dans son emplacement par défaut.

Exemple : C:\Program Files (x86)\Windows Kits\xx

Ou xx est la version de l’ADK

Récupération de l’outil

L’exécutable peut être récupéré ici :

https://onedrive.live.com/redir?resid=B370CC46EA3AB572!137&authkey=!ANkLug_PPC-kh-8&ithint=folder%2cexe

Nom de l’exécutable : GeneratorWinpe_x.x.exe

Plateformes validée

L’outil GeneratorWinPe a été validé dans les contextes suivant :

Lancement de l’outil

Il est nécessaire de modifier la politique d’exécution PoweShell pour lancer l’outil GeneratorWinPE car celui ci a été écrit en PowerShell.

Lancer une fenêtre PowerShell en tant que Administrateur

Taper la commande

Set-ExecutionPolicy unrestricted

et valider avec Yes.

Lancer l’outil GeneratorWinPe en tant qu’administrateur

Présentation de l’interface

Vous devez ici saisir le répertoire ou sera créé votre PE.

Attention :

· le répertoire ne doit pas déjà exister.

· La création du répertoire ne peut s’effectuer qu’à la racine du lecteur

· Pas d’espace dans le nom de répertoire

Plusieurs options s’offrent à vous :

• Mount
• Fr
• Unmount
• ISO

En cochant l’option Mount, vous pouvez ajouter des fonctionnalités au PE qui sera généré.

Unmount permet de démonter l’image si celle-ci a été montée.

Fr permet d’appliquer la langue Française au PE (clavier Azerty)

Cette option vous permet de créer une image ISO de votre PE

Vous pouvez sélectionner votre version d’ADK à utiliser

Vous pouvez sélectionner si votre PE sera de type x86 ou x64

Lock permet de lancer des vérifications et débloque le bouton Lancement.

Lancement permet de procéder à la construction du PE.

Unlock permet de débloquer l’application suite à un Lancement.

Utilisation de l’application

Sélectionner le volume et taper le nom du répertoire qui sera créé pour l’environnement de votre PE

Sélectionner Mount puis cocher les fonctionnalités vous intéressant à intégrer à votre PE.

Sélectionner la version d’ADK à utiliser et l’architecture souhaité pour votre PE

Cliquer sur Unmount, Fr et ISO

Cliquer maintenant sur Lock

Le bouton Lancement est maintenant disponible.

Cliquer sur Lancement

L’image est montée.

En fonction de différentes fonctionnalités ajoutées, vous allez avoir plusieurs fenêtres Powershell qui vont se lancer.

La fonctionnalité Scripting a été ajoutée.

La fonctionnalité NetFx a été ajoutée.

La fonctionnalité Powershell a été ajoutée.

La fonctionnalité DismCmdlets a été ajoutée.

La fonctionnalité WMI a été ajoutée.

La fonctionnalité StorageWMI a été ajoutée.

La fonctionnalité Dot3Svc a été ajoutée.

La langue Fr a été appliquée

L’image a été démontée avec prise en compte des modifications apportées

L’Image ISO a été créée

Les opérations sont finies

Vous trouverez votre image ISO dans votre environnement de construction.

Si vous exécuter CopyPe.exe dans une fenêtre PowerShell, vous aurez comme résultat :

ERROR: The following processor architecture was not found: x86.

Une petite astuce :

Lorsque vous lancez l’environnement de déploiement de l’ADK

En réalité, vous lancez le script DandISetEnv.bat.

Ce script peut être trouvé dans le répertoire suivant :

"C:\Program Files (x86)\Windows Kits\xx\Assessment and Deployment Kit\Deployment Tools"

Nous allons donc ajouter à ce script la ligne de commande Copype nous intéressant. Ainsi, l’exécutable Copype sera lancé dans le contexte de l’environnement de déploiement de l’ADK.

Comment allons-nous procéder ?

Pour ne pas modifier le script DandISetEnv.bat original, nous allons récupérer son contenu, le copier dans un emplacement temporaire et modifier ce fichier.

get-content "C:\Program Files (x86)\Windows Kits\xx\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.bat" | Out-File "$env:temp\DandISetEnv.bat" -encoding ASCII

On ajoute la commande copype à la copie du fichier.

"" | Out-File -Append "$env:TEMP\DandISetEnv.bat" -Encoding ASCII

"copype x86 c:\MonPE_x86" | Out-File –Append "$env:TEMP\DandISetEnv.bat" -Encoding ASCII

Et on exécute le script

cd $env:TEMP

.\DandISetEnv.bat

Le répertoire de travail du PE est maintenant construit.

Vous utilisez les objets COM pour la manipulation de Excel en Powershell et vous souhaitez colorer une cellule sur votre Excel.

Voici un petit script qui va vous permettre d’identifier l’index associé à sa couleur pour la valeur de la commande .Interior.ColorIndex

$Excel = New-Object -ComObject excel.application

$Excel.visible = $true

$workbookHEBDO = $Excel.workbooks.add()

$serverInfoSheetHEBDO = $workbookHEBDO.Worksheets.Item(1)

$excel.cells.item(1,1) = "COLOR"

$excel.cells.item(1,1).Interior.ColorIndex =48

$excel.cells.item(1,1).Font.Bold=$True

$excel.cells.item(1,2) = "Number"

$excel.cells.item(1,2).Interior.ColorIndex =48

$excel.cells.item(1,2).Font.Bold=$True

for ($i=1; $i -le 56; $i++)

{

$excel.cells.Item($i+1, 1).Interior.ColorIndex = $i

$excel.cells.item($i+1,2) = $i

}

Résultat :

Pour créer notre package d’application virtualisée, vous devez installer une machine qui servira de référence.

Cette machine doit se rapprocher le plus possible en terme de configuration (registre, ..) de l’environnement sur lequel sera déployé votre application virtualisée.

Connectez-vous sur cette machine et installer le séquenceur App-V.

Les binaires sont disponibles dans la librairie VMM (Application Framework)

L’application permettant la capture est désormais installée.

Lancer l’application et cliquer sur Create a New Virtual Application Package

Cliquer sur Next

Sélectionner l’application à virtualiser. Dans notre exemple, nous allons installer Filezilla.

Cliquer sur Next

Donner un nom à votre Package et cliquer sur Next

L’installation démarre. Procéder à l’exécution de votre application avec les paramètres tel que vous désirez que ceux-ci soient capturés.

Une fois l’application installée, vous pouvez procéder à d’autres modifications sur la machine. Ceux-ci seront capturés.

Cliquer maintenant sur I am finished installing et cliquer sur Next

Cliquer sur Next

Cliquer sur Close

Vous avez maintenant fini de capturer votre application. Il faut maintenant sauvegarder votre projet.

Cliquer sur File et Save as

Le package est désormais créé. Il ne vous reste plus qu’à déplacer votre package dans la librairie VMM.

Dans ce blog, vous pourrez trouver un exemple d’une installation d’application virtualisée à travers un Update de service  de type In-Place dans VMM 2012

http://blog.piservices.fr/post/Mise-a-jour-de28099un-service-dans-SCVMM-2012.aspx

Il peut arriver que des scripts soient incapable d’appeler les cmdlet SCOM.

Dans mon cas, ce problème a été remarqué à cause du Management Pack Service Bus v1.1 et plus précisément à cause de la définition de son moniteur (UnitMonitorType) nommé Related Objects Health State, mais il aurait pu s’agir de n’importe quel script exécuté par un Management Pack ou non.

Il se traduisait ici par des évènements Error avec l’ID 4101 dans le journal d’évènements Operations Manager :

Managegement Group: xxx. Script: RelatedObjectsHealthStateMonitorScript\Main : Error occured during Related Objects Health State monitoring.

Computer:yyy

Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Voyons comment fonctionne ce Monitor Type. Il est basé sur un script powershell qui commence par les commandes suivantes :

param($objectId, $relationshipId, $relatedObjectClassId, $relatedObjectMonitorId, $ignoreUnavailable, $ignoreInMaintenanceMode)
#TODO: Discuss event id
$SCRIPT_EVENT_ID = 4101 
#Event Severity values
$INFORMATION_EVENT_TYPE = 0
$ERROR_EVENT_TYPE = 1 
function GetRelatedObjectsHealthState7Version
{
param
(
$objectId,
$relationshipId,
$relatedObjectClassId,
$relatedObjectMonitorId,
[bool]$ignoreUnavailable,
[bool]$ignoreInMaintenanceMode
)
Import-Module -Name "OperationsManager"
$constUnintializedHealthState = "Uninitialized"
$constSuccessHealthState = "Success"
$constWarningHealthState = "Warning"
$constErrorHealthState = "Error"
#
# Get Relationship
#
$relationship = Get-SCOMRelationship -Id $relationshipId
if($relationship -eq $null)
{
$exceptionMsg = "Relationship with Id {0} not found." -f $relationshipId
$argumentException = New-Object System.ArgumentException -ArgumentList $exceptionMsg 
throw $argumentException
}

Les premières cmdlet SCOM réellement exécutées sont celles surlignées en jaune , les autres lignes ne sont que des définitions de variables ou des appels indépendants de SCOM.

Or, l’évènement indique un échec dès l’appel du cmdlet Get-SCOMRelationship : Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program.

On peut donc supposer qu’en réalité, le script n’a pas été en mesure de charger le module OperationsManager et qu’il ne reconnait donc pas le cmdlet.

On constate également que l’import manuel du module OperationsManager dans un shell PowerShell échoue.

Vérifions donc qu’il est bien présent sur le serveur où remonte l’alerte. Il doit se trouver dans le dossier d’installation de SCOM, sous-dossier Powershell > OperationsManager :

Le module existe bien.

Vérifions maintenant qu’il est bien enregistré dans la variable d’environnement $env:PSModulePath :

Manifestement, il est bien enregistré… Mais pas au bon endroit !

En effet, la variable d’environnement pointe vers C:\Program Files\System Center 2012\Operations Manager\Powershell\ alors que le module se trouve en réalité dans C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager !

La solution est alors toute trouvée : rajouter le bon chemin à la variable d’environnement à l’aide des commandes suivantes :

$originalpaths = (Get-ItemProperty -Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath).PSModulePath

$newPath=$originalpaths+’;C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\’

Set-ItemProperty –Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath –Value $newPath

Il ne reste plus qu’à redémarrer le serveur pour que la modification soit prise en compte et le problème résolu !

Lors de l’envoi d’un email dans Orchestrator à l’aide de l’activité Send Email, il est possible de choisir entre de choisir entre le format texte brut et le format HTML pour le corps du mail, dans l’onglet Advanced :

Il devient alors tout naturel de vouloir y intégrer des images à l’aide de la balise HTML <img> , afin d’enrichir encore la mise en page.

Il est alors possible d’avoir recours à plusieurs méthodes : la plus classique consiste à stocker ces images à un endroit accessible par tous les destinataires du mail (site web, partage réseau…) ; mais cette technique présente différents inconvénients : les images sont inaccessibles si l’accès à la source n’est pas disponible au moment de la lecture du mail, la plupart des clients mail bloquent leur chargement par défaut…

Une autre solution consiste à intégrer directement ces images dans les pièces jointes, et à les appeler à l’aide d’un Content ID (CID) au lieu d’un lien réseau ou http, à l’aide de la syntaxe suivante : <img src=’’cid:nomdelimage.jpg’’ />

Et c’est tout, les images seront désormais visibles dans le corps du mail. Encore mieux : selon le client mail utilisé, elles n’apparaitront même pas dans les pièces jointes !

Assurez-vous toutefois bien que le serveur Orchestrator soit lui toujours en mesure d’accéder aux images, il les recharge à chaque appel de l’activité Send Email.

Introduction

Exchange bénéficie d'un grand nombre de cmdlet Powershell très abouties et permettant de configurer et d'administrer l'intégralité d'une infrastructure de messagerie. Aussi, celles-ci sont très utiles dans le cas de scripts de provisionning. J'ai rencontré une erreur lorsque je cherchais à créer et à configurer un grand nombre de boites aux lettres de ressources.

Contexte

L'environnement dans lequel j'ai découvert ce problème est une forêt mono domaine Active Directory avec une infrastructure Exchange 2010 SP3 dans laquelle il y avait plusieurs contrôleurs de domaine dans le même site Active Directory que la totalité des serveurs de messagerie.

Plus globalement, cette erreur pourra être rencontrée dès qu'un serveur Exchange pourra être amené à interroger plus d'un contrôleur de domaine.

Erreur rencontrée

Dans un script de provisionning de boîtes aux lettres, on cherche à les créer mais aussi à les configurer. Si l'on souhaite configurer une boite aux lettres tout de suite après sa création alors on obtient une erreur similaire à celle ci-dessous (“ObjectNotFoundException”) :

Cela peut se retrouver en exécutant l'exemple suivant :

Une ou plusieurs opérations de modification (de type Set-…) vont échouer avec le message d'erreur cité précédemment.

Explication

Suite à cette erreur, il est logique de penser que cela est dû à l'interrogation de différents contrôleurs de domaine qui n'ont pas encore répliqué entre eux (Une réplication intra site peut prendre quelques secondes).

Aussi, on peut se dire qu'il suffit alors de spécifier le paramètre DomainController pour corriger le problème en l'indiquant sur toutes les commandes et en définissant un contrôleur de domaine unique qui traitera toutes les opérations.

Cependant, cela ne corrigera pas le problème. Microsoft en donne l'explication dans les fiches Technet des cmdlets :http://technet.microsoft.com/en-us/library/dd335046.aspx.

Le paramètre DomainController ne concerne que le contrôleur de domaine qui va écrire les modifications dans Active Directory. Cependant, un autre contrôleur de domaine  peut être utilisé pour lire l'objet avant d'écrire les changements sur celui spécifié en paramètre.

Aussi, pour une cmdlet de type Get-… (lecture), le paramètre DomainController sera bien le contrôleur de domaine sur lequel l'objet sera lu (cela sera utile pour mettre en place l'une des solutions proposées).

Solution

Pour résoudre ce problème,  il faut donc attendre que la réplication ait eu lieu sur la totalité des contrôleurs de domaine du site Active Directory de l'infrastructure Exchange. Pour cela, nous avons trois solutions.

Solution 1 :

Il est possible de séparer la création des boîtes aux lettres et leurs configurations. Cette solution oblige donc a réaliser le provisioning en plusieurs phases.

Solution 2 :

On peut définir un délai entre l'opération de la cmdlet de création et la cmdlet de configuration via un Start-Sleep par exemple. Cependant, cette solution ne garantit pas que les opérations vont toutes se dérouler correctement. Il faudra sans doute que le délai soit important pour que le provisioning ait un taux de réussite élevé et donc augmenter considérablement le temps d'exécution du script.

Solution 3 :

La dernière solution est une combinaison des deux précédentes puisqu'elle permet de n'avoir qu'une seule phase de provisioning tout en ayant un temps d'exécution relativement rapide.

Cette solution consiste à implémenter une boucle de test de l'opération à réaliser sur le même contrôleur de domaine via la cmdlet de lecture (Get-…).

Exemple :

Il est possible d'ajouter une courte pause entre chaque test afin de ne pas surcharger le processus sans pour autant trop pénaliser le temps d'exécution du script. Le paramètre ErrorAction permet d'alléger l'affichage car on connait déjà l'erreur que l'on va rencontrer.

Il ne vous reste plus qu'à choisir la solution que vous préférez.