PI Services

Orchestrator est livré d’origine avec un bon nombre d’activités pré-installées, qui permettent de mettre en place nativement un large panel de scénarios. Il est également possible d’étendre ces capacités à l’aide d’Integration Packs (appelés OIP), qui peuvent être disponibles au téléchargement auprès de Microsoft ou d’éditeurs tiers ou bien développés directement par les administrateurs en fonction de leurs besoin spécifiques.
Nous allons nous intéresser ici à ce dernier cas.

Dans un premier temps, il est nécessaire de télécharger et d’installer Orchestrator Integration Toolkit, le package qui contient les outils nécessaires à la création de ces OIP. Il est disponible ici : http://www.microsoft.com/en-us/download/details.aspx?id=28725 (System_Center_2012_Orchestrator_Integration_ToolKit.exe)

L’installer et importer l’OIP « integration toolkit » fourni avec dans votre infrastructure Orchestrator (management server et runbook designer, se référer à la fin de la partie 2 pour de l’aide à ce sujet).

Une fois ces pré-requis complétés, nous pouvons démarrer la création de l’Integration Pack à proprement parler. La première étape consiste à créer une « Assembly », qui est un fichier dll contenant le « moteur» de l’OIP. La seconde étape consistera à packager cette dll pour en faire un fichier OIP à proprement parler.

Nous étudierons ici l’exemple d’un OIP contenant une unique activité permettant d’ajouter des évènements au journal d’évènements (Event Viewer). Cette activité existe déjà d’origine via l’activité « Send Event Log Message », mais elle est très limité : elle ne permet pas de sélectionner le journal d’évènement cible, ni l’ID de l’évènement, ni sa source, ni sa criticité. L’OIP que nous allons développer ici offrira toutes ces possibilités.

Lancer l’outil Orchestrator Command-Line Activity Wizard.

Cliquer sur Next à l’écran d’accueil (ou sur Load existing assembly  pour reprendre un projet en cours).

Nommer le projet et indiquer le chemin où enregistrer l’assembly (le fichier dll source) puis cliquer sur Next

Il est également possible d’ajouter des détails sur le projet (description, nom de la compagnie, version… ) en cliquant sur Assembly Information

Cliquer sur Add

Dans l’onglet General, nommer l’activité et indiquer son mode de fonctionnement (Run Command, Run Windows PowerShell, Run Program ou Run SSH Command).
Dans notre cas, la création d’événement dans le journal d’événements se reposera sur une commande PowerShell ; nous choisissons donc Run Windows Powershell.
Cliquer sur l’onglet Arguments.

L’onglet Arguments est celui dans lequel nous déterminons les paramètres d’entrée de l’activité ainsi que le code PowerShell qui la fera fonctionner.

Dans Parameters, cliquer sur Add. Indiquer le nom du paramètre d’entrée, son mode de fonctionnement (dans notre cas Command Argument), son type (champs texte, champs mot de passe, liste déroulante, browse button…) et éventuellement une valeur par défaut. Ci-dessous deux exemples , un en type Text et l’autre en type Text with Selection (liste déroulante).

Pour réaliser notre exemple d’ajout d’événement dans le journal d’événements, les paramètres suivants sont nécessaires :

Une fois tous les paramètres ajoutés, cliquer sur Insert afin d’entrer le code PowerShell qui sera le « moteur » de notre activité :
Write-eventlog -logname "$(Log Name)" -ComputerName "$(Computer Name)" -Source "$(Source)" -Message "$(Content)" -id "$(Event ID)" -EntryType "$(Event Severity)"

L’onglet Published Data permet d’indiquer quelles informations seront republiées dans le Bus Orchestrator, afin d’être ensuite réutilisées par d’autres activités. Nous n’en rajouterons pas dans cet exemple, mais il est tout à fait possible d’imaginer publier l’ID et le contenu de l’évenement, par exemple.

Cliquer sur OK.

Cliquer sur Next

L’assembly compile…

Voilà, c’est compilé. L’assistant propose de passer directement au packaging de l’Integration Pack, mais il est préférable de commencer par tester notre assembly afin de s’assurer qu’elle fonctionne comme souhaité.

Cliquer sur Finish.

Lancer le Runbook Designer, créer un nouveau runbook et y ajouter les activités Initialize Data et Invoke .NET. Cette dernière est disponible grâce à l’Integration Toolkit importé en début d’article et permet d’exécuter une assembly au format dll comme s’il s’agissait d’un OIP finalisé et packagé, ce qui permet donc de la tester rapidement.

Ouvrir les propriétés de l’activité Invoke .NET. Dans le champ Assembly, sélectionner la dll de l’assembly préalablement crée. Dans Class, sélectionner la class correspondante (dans notre exemple il n’y en a qu’une). Laisser Setup vide (ce champ ne sert que pour les classes développées à l’aide du SDK).

Dans l’onglet Properties, remplir les paramètres de l’activité puis cliquer sur Finish.

Attention ! Il est nécessaire que le journal d’événement ainsi que la source indiqués soient déjà enregistrés sur l’ordinateur cible ! Au besoin, il est possible de les créer à l’aide du PowerShell suivant :
New-EventLog -logname $JournalDevenement -Source $Source -ComputerName $ComputerName -ErrorVariable Err

Dans l’exemple ci-dessus, le journal utilisé est Application (présent par défaut) et la source est TestOIP (n’existe pas d’origine). Nous la créons donc ainsi :
New-EventLog -LogName "Application" -ComputerName "localhost" -source "TestOIP" -ErrorVariable Err

Lancer le Runbook Tester et cliquer sur Run.

Si tout s’est bien passé, voilà ce qui doit apparaitre dans l’Event Viewer :

Voilà, le « moteur » de notre Integration Pack fonctionne. Il ne reste plus qu’à le packager pour pouvoir le déployer sous forme d’OIP à notre infrastructure Orchestrator, ce que nous aborderons dans la seconde partie.

Vous avez ce message d’erreur lorsque vous ouvrez Outlook.

Cela peut être dû à une mauvaise désinstallation de logiciels qui avait ajouté une extension dans Outlook.

Pour résoudre le problème, vous devez aller dans votre profil dans les données applicatives locales de Outlook : %userprofile%\appdata\local\Microsoft\Outlook et de supprimer ou renommer le fichier extend.dat en extend.dat.bak

Relancez Outlook.

L’erreur n’apparaitra plus.

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.

Après avoir créé une liste de distribution vous souhaitez l’ajouter sur une autorisation de

partage d’un dossier public:

Vous constatez que la liste ne peut être ajoutée et est marquée du “panneau accès interdit”.

Cela est dû au fait que la liste est du type Mail Universal Distribution group.

On doit donc la convertir via la console ADUC ou par une commande powershell

Active Directory :

Le groupe de distribution est maintenant de type “sécurité”.

Patientons quelques minutes (réplication AD) puis ajoutons l’autorisation

sur le dossier public:

Oups, le problème est toujours présent

Vérifions le RecipientTypeDetails

Celui-ci est bien du type MailUniversalSecuritygroup !!!

Regardons l’attribut msExchRecipientDisplayType. Celui-ci à la valeur 1.

Ce qui correspond à un “mail universal distribution group”.

La modification réalisée dans l’interface graphique n’a donc pas été prise en compte.

Pour corriger le problème il faut utiliser la commande PowerShell Set-DistributionGroup

Vous pouvez rencontrer ce type d’erreur, pas de panique , rajoutez l’option

-MemberDepartRestriction Closed

Regardons de nouveau l’attribut msExchRecipientDisplayType:

La valeur est maintenant 1073741833 ce qui correspond à un “mail universal security group”.

                                                  **************

                                          *********************

Essayons de nouveau d’ajouter ce groupe sur les droits du dossier public:

Et voilà, mon groupe de distribution est disponible.

A ce jour ce disfonctionnement n’est pas considéré comme “bug” chez Microsoft .

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 déploiement de l’agent SCCM dans une infrastructure peut générer des messages d’erreur dans les journaux d’évènements clients.

En effet, on peut rapidement saturer les journaux SYSTEM des clients et serveurs par des erreurs DCOM 10016.

Ces erreurs sont gênantes vu quelles sont inscrites chaque minute.

Elles sont généralement dues à des permissions insuffisantes sur des composants DCOM.

La procédure de résolution est la suivante :

1. Identifier l’application DCOM qui génère l’erreur, pour cela il faut recherche dans le registre l’ID .

2. Après avoir identifier l’application ID :

3. Ouvrir la console Component Services en tapant dans la Dcomcnfg.exe :

4. Dans la console Component Services, cliquer sur DCOMConfig :

5. Rechercher dans la liste l’APP ID (étape 2)

6. Faire ensuite un clic droit sur SMS Agent et cliquer sur Propriétés :

Cliquer ensuite sur Security

7. Cliquer ensuite sur Edit

8. Vérifier que l’autorisation « Local Launch » est autorisé pour le compte System

Dans notre cas, l’autorisation est refusée. Ce qui explique l’erreur DCOM.

Pour corriger le problème, il faut cocher la case « Local Launch » est sur Allow.

En conclusion, cette erreur peut être résolue manuellement via la procédure ci-dessus ou elle peut être automatisée via la création d’une GPO .

Celle-ci pourra se baser sur un script d’ouverture de session qui va importer une clé de registre .Cette clé de registre va mettre à jour les permissions DCOM.

A très bientôt

Khalil Bezneiguia

L’accès à l’OAB est devenu crucial dans une infrastructure Exchange et plus précisément dans des configurations spécifiques où :

· Outlook est utilisé avec le mode cache activé.

· Outlook est en mode déconnecté.

Dans ces deux cas de figures, Outlook utilisera le carnet en mode hors connexion. Celui-ci sera mis à jour chaque 24 heures via un téléchargement différentiel, à noter que c’est le client Outlook qui initie la connexion.

Avec Exchange 2007, Microsoft a introduit le mécanisme de distribution Web, le client Outlook 2007 & 2010 peuvent télécharger l’OAB en se connectant directement sur les serveurs CAS en utilisant du le protocole http ou https.

L’url de téléchargement de l’OAB est fournie par le service Autodiscover aux clients Outlook.

Quant à la génération de L’OAB, celle-ci est gérée par un serveur Mailbox qui est désigné comme serveur de génération.

Qu’est ce qui a changé avec Exchange 2013?

Sur les versions précédentes Exchange, on pouvait désigner qu’un seul serveur de génération par OAB, ce qui représente un SPOF (Single point of failure).

Imaginer que le serveur Mailbox est en erreur, cela implique la non génération de l’OAB et ainsi que la non distribution de celui-ci aux clients Outlook.

L’impact de ce disfonctionnement peut être important, on peut citer deux phénomènes :

· Messages d’erreurs lors du téléchargement de l’OAB.

· Utilisation d’une version obsolète de l’OAB par les clients Outlook (les nouveaux contacts et les nouveaux utisateurs n’apparaissent pas sur l’OAB)

Avec Exchange 2013, l’OAB est généré par plusieurs serveurs Mailbox Exchange 2013 qui hébergent des boites aux lettres systèmes nommées « Organization Mailbox ».

Dans cette configuration, la génération de l’OAB est effectuée par plusieurs serveurs Mailbox ce qui permet d’assurer une résilience du processus de génération de l’OAB.

Quel Composant génère l’OAB ?

Le processus « Microsoft Exchange Mailbox Assistants/ OABGeneratorAssistant» est responsable de la génération de l’OAB dans Exchange 2013.

Ou sont stockés les fichiers OAB ?

Les fichiers OAB sont stockés en premier dans la Organization Mailbox et sont ensuite copiés dans le dossier %ExchangeInstallPath%\ClientAccess\OAB\

Méthode de distribution OAB :

Dans Exchange 2013, seule la distribution Web est supportée. Plus besoin de dossiers publics ! J

Le processus est le suivant :

1. Outlook reçoit l’URL de téléchargement OAB depuis le service Autodiscover.

2. Outlook s’authentifie auprès du serveur CAS pour télécharger l’OAB.

3. Le serveur CAS interroge un DC/GC pour :

a. Déterminer l’emplacement de l’Organization Mailbox la plus proche.

b. Déterminer quelle est la base de données qui herberge l’Organization Mailbox.

4. Le serveur CAS interroge ensuite l’Active Manager pour déterminer la copie Active de la base de données (Seulement si la base de données fait partie d’un DAG)

5. Le serveur CAS proxie ensuite la demande de téléchargement vers le serveur Mailbox identifié dans les étapes précédentes.

6. Le serveur Mailbox renvoie les fichiers OAB au serveur CAS qui les renvoie à son tour au Client Outllok.

Avec Exchange 2013, il a vraisemblablement une avancée importante du processus OAB,cette avancée permet de garantir une tolérance de panne mais implique aussi un troubleshooting plus compliqué en cas d’anomalie de génération de l’OAB.

Pour plus d’informations :

http://blogs.technet.com/b/exchange/archive/2012/10/26/oab-in-exchange-server-2013.aspx

À Très bientôt

Khalil Ben Zneiguia

Vérification de l’application d’une GPO (Heure de la dernière application de la stratégie de groupe)

Il est possible de vérifier la dernière fois que les stratégies de groupe ont été appliquées avec la commande Gpresult

Pour cela, il suffit de lancer une fenêtre de commande cmd, exécuter ensuite la commande GPresult :

Le résultat de la commande est composé de deux parties :

· Paramètre de l'ordinateur : liste les GPO appliquées au compte ordinateur.

· Paramètre Utilisateur : liste les GPO appliquées au compte utilisateur.

L’utilisation de cette commande nous permet de valider la liste des GPO’s liées aux compte ordinateur et utilisateur et nous permet aussi de valider l’heure de la dernière application de celles-ci.

Pour cela, il suffit de vérifier la ligne «Heure de la dernière application de la stratégie de groupe » :

· Capture écran Paramètre ordinateur :

· Capture écran paramètre utilisateur :

A bientôt

Khalil Bezneiguia

Pour vérifier la santé de l’Active Directory on utilise habituellement un outil

en ligne de commande tel que  REPADMIN.

Microsoft met à disposition un outil graphique, Active Directory Replication Status Tool.

Cet outil s’installe sur plusieurs version d’OS Windows (prérequis .Net Framework 4.0).

Après installation de l’outil, lancez la console.

Cliquez sur Refresh Replication Status

Ce type de résultat est retourné:

Dans ce cas il n’y a pas d’erreur.

En fonction des erreurs liées au “Tombstone LifeTime”, les informations prendront une couleur diffèrente.

Pour rappel le “Tombstone LifeTime” est de 180 jours depuis Windows 2003 SP1.

On peut modifier les colonnes à afficher par un clique droit dans l’une des colonnes :

Le rapport peut être exporté:

N’hésitez pas à installer cet outil que vous pourrez télécharger depuis ce lien:

http://www.microsoft.com/en-us/download/details.aspx?id=30005.