PI Services

Modifier la sévérité d’une alerte est une problématique qui peut sembler des plus basique dans le suivi d’une infrastructure SCOM, mais pour laquelle il est utile de préciser quelques subtilités lorsqu’il s’agit du management pack Exchange 2010 et de son correlation engine.

Comme vous ne l’ignorez probablement pas, le fonctionnement de ce management pack est particulier : la génération d’alertes repose sur un service externe, le correlation engine, qui s’occupe d’agréger toutes les remontées d’erreur afin d’en générer une seule alerte la plus pertinente possible.

Première subtilité : si pour créer votre override vous cliquez directement sur le champ Alert Rule contenant le nom de la règle KHI […], puis allez dans l’onglet Overrides et faites un Override > For all of Objects of Class […], cette dernière sera incorrecte.

Cette procédure est parfaitement valable en temps normal, mais pas ici. En effet, l’override doit être créée pour le serveur d’où provient réellement l’alarme, c'est-à-dire celui qui exécute le Correlation Engine, donc le RMS (ou RMS Emulator sous SCOM 2012). Or, par défaut la procédure mentionnée va cibler le rôle d’où l’alerte est supposée provenir, c'est-à-dire OWA dans notre exemple :

Il est donc ici nécessaire de créer l’override For all objects of another class, et de sélectionner la classe RMS (ou RMS Emulator sous SCOM 2012) :

Voilà déjà un écueil évité.

Seconde subtilité : une fois arrivé à l’écran de création de l’override à proprement parler, vous pouvez être surpris par la valeur par défaut du paramètre Severity, traditionnellement utilisé pour modifier la criticité d’une alerte. C’est là aussi dû au Correlation Engine.

Mais ne vous laissez pas impressionner par cette longue variable : il suffit d’indiquer en valeur d’override 0, 1 ou 2 selon la criticité souhaitée (info, warning, critical) !

N’oubliez pas d’enregistrer cet override dans un management pack dédié à Exchange.

Symptômes

Ce type d’erreur peut se rencontrer sur un serveur multi-rôles (Client Access et Mailbox) en version Exchange Server 2013 CU1 ou Exchange Server 2013 CU2.

Les symptômes sont les suivants :

• Les services Web Exchange (OWA, Outlook Anywhere…) dysfonctionnent
• L’erreur 503 (source WAS) est présente en boucle dans le journal d’évènement Système

Voici le détail de l’erreur concernée :

Journal : System
Source: Microsoft-Windows-WAS
Event ID : 5203
Level : Error
Description: A process serving application pool 'MSExchangeRpcProxyAppPool' reported a failure trying to read configuration during startup. The process id was '27620'.  Please check the Application Event Log for further event messages logged by the worker process on the specific error.  The data field contains the error number.

Explication

Cette erreur est généralement due à la présence d’un fichier de configuration IIS corrompu.

Cela peut être mis en évidence en lançant la console d’administration IIS Manager.

Dans notre exemple, la console fait très clairement référence à un fichier de configuration nommé applicationHost.config et stocké dans le répertoire C:\Windows\System32\Inetsrv\Config.

Lorsque l’on tente d’éditer le fichier, ce dernier peut apparaitre remplis d’espace blancs ou bien ma formaté (selon les cas de figure).

Résolution

Pour résoudre ce problème il suffit de recopier le fichier sur le serveur applicationHost.config à partir d’un autre serveur Exchange en même version ou bien à partir d’une sauvegarde.

Dès le fichier copié, il devient  possible de démarrer les services IIS et les services Web sont de nouveau opérationnels.

Le 11 Septembre, Varonis, société spécialisée dans la gouvernance des données, à annoncé la disponibilité de la version 5.9 béta de sa suite logiciels.

En quelques lignes, qui est Varonis ?

Varonis à été créé en 2005 par deux experts reconnus dans le monde du stockage et du réseau. La société a développé la suite logiciel que nous connaissons maintenant, qui permet de d’analyser et déterminer les bons niveaux de permissions associés aux données, de localiser les données critiques et d’identifier les propriétaires métiers des données. Le résultat s’est concrétisé via une interface interactive, simple et efficace pour l’utilisateur.

Aujourd’hui, Varonis est le principal innovateur et fournisseur de solutions de gouvernance de données non structurées et semi structurées, avec plus de 4500 installations dans le monde dans tous secteurs d’activités confondus. Reposant sur des technologies brevetées, les solutions Varonis fournissent aux organisations une visibilité et un contrôle total sur leurs données en s’assurant à tout moment que les utilisateurs ont accès aux seules données dont ils ont besoin.

Varonis est présent dans le monde entier avec des bureaux en Europe, Russie et Amérique du nord.

Présentation de Varonis Data Governance Suite

La suite logiciel Data Governance Suite comprend les composants suivant :

• Varonis DatAdvantage pour Windows
• Varonis DatAdvantage pour SharePoint
• Varonis DatAdvantage pour Exchange
• Varonis DatAdvantage pour les Services d’Annuaires
• Varonis DatAdvantage pour UNIX/Linux
• Varonis DataPrivilege
• Varonis IDU Classification Framework

Avec cette suite, vous pouvez avoir une visibilité complète sur toutes les autorisations accordées aux utilisateurs/groupes et ce, quel que soit la nature du stockage (SharePoint, Exchange, NAS, Windows,…). Des audits et des recommandations viennent compléter les rapports fournis par les différents composants.

Nouveautés de la version 5.9

Voici une liste des nouvelles fonctionnalités de cette version :

• Détection automatique de partages
• Support de Microsoft Windows server 2012
• Support de Microsoft Windows 8 pour la console DatAdvantage
• Nouveau rôles utilisateurs pour une meilleur délégation
• Mise à jour des règles de classification prédéfinies
  
  Mais la nouveauté majeur de cette version reste l’ajout d’un nouveau logiciel dans la suite : DatAlert. Voici ses fonctionnalités :
  
  Alertes en temps réel :
• sur l’accès, la modification, la suppression des données
• Modification des groupes, GPO dans Active Directory
• Modification des ACLs

Types d’alertes gérées :

• Trap SNMP, journaux d’évènements, Syslog, Email
• Exécution de ligne de commande

A titre de comparaison, avec les versions antérieures à la 5.9, les alertes ne sont générées qu’une fois par jour, le soir, lors de la consolidation des données recueillis à travers les différentes sondes.

Avec cette nouvelle version de la suite logiciel, vous avez la garantie de savoir exactement ce qui se passe sur votre réseau et en temps réel !

Vous savez (et regrettez !) probablement déjà que la console Authoring présente dans SCOM 2007 n’existe plus dans SCOM 2012.

Il est toujours possible d’utiliser l’ancienne version pour créer un management pack, puis d’importer ce dernier dans SCOM 2012 : ca fonctionne, ca SCOM 2012 sait lire et convertir le format de MP 2007.

L’inverse n’est par contre malheureusement pas vrai : il est impossible d’ouvrir dans la console Authoring un MP exporté depuis SCOM 2012.

Voici ce que vous obtiendrez en boucle si vous vous y risquez :

“Referenced management pack not found”

Et vous aurez beau vous acharner et indiquer le MP demandé, rien n’y fera.

Mais pire encore, malheur à vous si vous avez essayé de référencer les MP de base de SCOM 2012 dans les options de la console Authoring en espérant que cela permette de les utiliser !

En effet, ce genre de réglage provoquera l’apparition en boucle du message précédent réclamant le MP System.Library Management Pack, sans possibilité de le sélectionner ni de revenir en arrière sur ce réglage !

Pour y remédier, rendez vous dans l’éditeur de registre (regedit) et ouvrez la clé HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Authoring\Settings\References

Supprimez le contenu de la ligne Value Data et cliquez sur OK.

La console Authoring est désormais à nouveau accessible.

Il peut arriver d’avoir besoin de créer une règle ou un moniteur qui s’exécute avec un RunAs Profile (lié à un runas account) spécifique, par exemple dans le cas d’un moniteur de type script qui interroge une base de données SQL pour laquelle un login particulier est requis.

Avec la console Authoring présente dans SCOM 2007, cette possibilité était accessible graphiquement : il suffisait de sélectionner un profil dans une liste déroulante dans les propriétés du moniteur.

Malheureusement, la console Authoring n’existe plus dans SCOM 2012, et la console Operations ne permet pas de sélectionner un RunAs profile lors de la création d’un moniteur… nous voilà donc réduits à modifier le management pack contenant ce moniteur directement en XML.

Si le RunAs Profile et son Account associé ne sont pas encore créés, il est cependant possible de les ajouter au management pack voulu à l’aide la console Operations :

Rendez-vous dans l’onglet Administration et faites un clic-droit sur Run-As Configuration –> Profiles. Sélectionnez Create Run As Profile

Cliquez sur Next

Choisissez un nom pour le run-as profile et enregistrez le dans un management pack (important : si le moniteur ou la règle qui qui doit être associé à ce profil est contenu dans management pack non scellé, il est obligatoire d’enregistrer le run-as profile dans le même management pack !), puis cliquez sur Next.

Cliquez sur Add pour ajouter un run-as account puis sélectionnez le Run-As account à associer avec ce profil (ou créez-en un nouveau) et sélectionnez l’étendue qui vous convient le mieux puis cliquez sur OK. Cliquez sur Next.

Pensez à distribuer le run-as account sur les serveurs où il sera utilisé s’il est configuré en more secure, puis cliquez sur Close.

Une fois le run-as profile créé et configuré dans le bon management pack, il faut exporter ce management pack pour travailler dessus.

Allez dans Administration -> Management Packs, recherchez le MP qui contient les moniteurs et règles à modifier et cliquez sur Export Management Pack. Choisiseez un dossier de destination pour le fichier XML enregistrez le.

Ouvrez ce fichier XML dans un éditeur de texte et localisez le bloc SecureReferences. Il contient un champ SecureReference (au singulier), qui indique l’ID de votre RunAs profile (si vous l’avez créé dans la console comme expliqué précédemment, il aurait un ID généré automatiquement beaucoup plus long) :

<SecureReferences>
<SecureReference ID="Test.Monitors.RunAsProfile" Accessibility="Internal" Context="System!System.Entity" />
</SecureReferences>

Notez cet ID, il va nous servir juste ensuite.

Il y a maintenant deux possibilités, selon que vous souhaitiez ajouter ce RunAs profile à un moniteur ou à une règle.

Cas du moniteur :

Localisez la ligne UnitMonitor correspondant au moniteur auquel vous souhaitez ajouter le RunAs Profile, par exemple :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Il suffit maintenant d’ajouter à cette ligne le paramètre RunAs="Test.Monitors.RunAsProfile", et le tour est joué :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" RunAs="Test.Monitors.RunAsProfile " TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Cas de la règle :

Là aussi, c’est très simple, à une subtilité près : il ne faut pas ajouter le paramètre RunAs="Test.Monitors.RunAsProfile " à la règle elle-même (ligne Rule), mais à sa DataSource.

Commencez donc par localiser la ligne Rule correspondant à la règle à modifier, par exemple

<Rule ID="MomUIGeneratedRule7fbfb108d804460e9b8e13deb1ea1b0c" Enabled="true" Target="Test.Class" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100" >

Quelques lignes plus bas doit se trouver la ligne DataSource correspondante :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider">

Il suffit d’ajouter à cette dernière notre paramètre RunAs :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider" RunAs="Test.Monitors.RunAsProfile ">

Une fois la modification apportée à tous les moniteurs et règles souhaités, sauvegardez le fichier XML (en pensant à incrémenter son champ Version !) et réimportez le dans SCOM.

Le RunAs profile s’applique désormais aux moniteurs et règles désirés :)

Il existe une méthode de l’objet powershell scom get-scomagent permettant de positionnez la failover management server vers lequel basculera vos agent en cas de crash de leur Primary Management Server.

Les commandes suivantes présentent la logique d’execution de ce positionnement:

On attribue a deux variables le Primary Management Server et le Failover Management Server

$primaryms=Get-SCOMManagementServer -Name "MyPrimaryServer1.home.com"

$failoverms=Get-SCOMManagementServer -Name "MyFailoverServer1.home.com"

On attribue a une variable tout les agents qui ont comme Primary Management Server le serveur "MyPrimaryServer1.home.com”

$agentstomove=Get-SCOMAgent | where-object {$_.primarymanagementservername -eq "MyPrimaryServer1.home.com”}

Vous pouvez vous assurez qu’aucun des agents ne possede un failover server érroné avec la commande suivante qui positionne cette valeur a Null

$agentstomove | foreach {Set-SCOMParentManagementServer -agent $_ -Failoverserver $null}

Enfin pour positionner le Failover Management Server.  Je vous conseille dans ce cas la de mettre l’option Verbose, surtout si le nombre d’agent a traiter est important afin de voir le résultat

$agentstomove | foreach {Set-SCOMParentManagementServer -agent $_ -Failoverserver $failoverms –verbose}

Les alertes “Workflow Runtime: Failed to run a process or script” ou “Workflow Runtime: Failed to run a WMI query” révèle un problème d’exécution d’une règle ou d’un moniteur.

1er cas: ce problème est ponctuel. Le champ repeat count de l’alerte est peu élevé et la dernière occurrence (champ Last Modified) n’est pas très récent:

Dans la plupart de ces cas, le workflow exécuté a l’origine de cette erreur n’a pas pu aboutir pour des problèmes ponctuels de performance ou de disponibilité de la machine cible. Vous pouvez essayez de faire le parallèle entre l’heure de l’alerte et les éventements présent dans les eventlog Application et Systeme de la machine cible.

2nd cas: Ce problème est récurrent. Le champ repeat count de l’alerte est élevé et la dernière occurrence (champ Last Modified) est récente: Cela signifie que le workflow concerné échoue systématiquement pour cette la machine cible.

Action:

Il est important de lire le champ Description de l'alerte pour voir plus de détail sur la commande ou la requête exécutée, le workflow impacté et la machine cible.

Exemples:

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

Command executed: "C:\Windows\system32\cscript.exe" /nologo "IsHostingMSCS.vbs" {1C0CCF64-D32D-B64C-A66A-792E7F0934D6} {6E52A2D1-E55F-7E00-A150-D4CFAB747EFE} (…) (…)

Working Directory: C:\Program Files\System Center Operations Manager\Agent\Health Service State\Monitoring Host Temporary Files 2960\58276\

One or more workflows were affected by this.

Workflow name: System.Mom.BackwardCompatibility.Computer.IsHostingMSCS.Discovery

Instance name: Machine1.home.com

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

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

Object enumeration failed

Query: 'SELECT ServiceName, StartName, DisplayName FROM SqlService WHERE ServiceName="SQLAgent$REC_FR_CI_AS"'

HRESULT: 0x800706be

Details: The remote procedure call failed.

One or more workflows were affected by this.

Workflow name: Microsoft.SQLServer.2008.AgentDiscovery

Instance name: MSSQLSERVER

Instance ID: {6AD519E3-D3C0-7B1B-EE4A-92367A4CDCEC}

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

Connectez vous sur la machine concernée par l’alerte

Pour les alertes concernant une erreur d’exécution d’un script, tentez d’exécutez dans une fenêtre de commande le script et les argument associés tel que la commande apparait dans le champ Description de l’alerte (Command Executed:…)

Les scripts de supervision des règles/moniteurs retourne dans la plupart des cas leurs données au format XML, ce qui signifie que le script a abouti a une transmission des données récoltées. Dans la cas contraire, le retour affiché par l’exécution de ce script peut être une erreur vbscript ou powershell lié au contenu du script lui-même.

Pour les alertes concernant une erreur d’exécution d’une requête wmi, vérifiez sur la machine que la requête wmi précisée dans le champ description de l'alerte (Query:…) peut être effectuée.

=> Utilisez wbemtest.exe présent nativement sur tout les OS Windows pour exécutez la requête wmi.

De plus le code situé apres “HRESULT” dans la description de l’alerte indique le type d’erreur wmi. ces types sont disponible sur le lien http://msdn.microsoft.com/en-us/library/aa394559%28v=vs.85%29.aspx

Introduction

Lorsque l'on développe des scripts Powershell, il y a un certain nombres de commandes génériques que l'on réutilise très souvent. Nous verrons aussi quelques astuces qui peuvent être utiles dans de nombreux scripts.

Astuces

Retrouver le dossier d'exécution du script :

Souvent, il arrive que l'on crée une bibliothèque de scripts. Un script peut en appeler un autre parce qu'il contient des fonctions. On peut aussi vouloir faire appel à un fichier de configuration. Beaucoup de scripts contiennent alors le chemin d'exécution via une variable qu'il convient de changer manuellement dès que le répertoire est modifié. Cela n'est cependant pas très portatif. Il est nettement plus intéressant de retrouver ce chemin dynamiquement.

La commande ci-dessous permet de retourner le dossier où se situe le script qui est en train de s'exécuter.

On peut ensuite retrouver nos fichiers additionnels via des chemins relatifs calculés depuis celui que l'on vient de récupérer.

"$MyInvocation.MyCommand.Path" retourne le chemin du fichier.
A partir de ce dernier la commande "Split-Path" nous retourne uniquement le dossier dans lequel est contenu le script.

Connaître le contexte d'exécution (32 ou 64 bits) :

Il peut arriver que l'on souhaite lancer un exécutable spécifiquement depuis une instance Powershell x86 ou x64 car celui-ci n'existe pas dans un autre contexte.

Pour cela, il existe une astuce permettant de savoir quelle édition de Powershell (x86 ou x64) est lancée :

Cette commande nous donne la taille d'un pointeur sous la forme d'un entier. Lorsque l'invite de commande Powershell est en x64, cette valeur vaut 8. Dans le cas contraire il s'agit de 4. On peut facilement imaginer une structure conditionnel permettant de relancer un script automatiquement en Powershell x86 qui intègre un exécutable ne tournant que sur cette version.

Le script est-il exécuté en mode administrateur :

Dans le même esprit, il est possible de savoir si un script a été lancé en mode administrateur. En effet, certaines opérations peuvent exiger ce mode de fonctionnement :

Bien évidemment il n'existe pas de commande pour relancer le script dans ce mode. On peut cependant inviter l'utilisateur à le faire.

Tester son script pour une autre version de Powershell :

Il peut arriver que l'on développe son script Powershell sur son poste client qui est en version 3 alors que le serveur qui le lance est lui en version 2. Afin d'être certain que ce script est compatible, il est possible d'indiquer la version de Powershell à utiliser. En voici un exemple ci-dessous :

En version 3 il n'est plus nécessaire de faire d'Import-Module pour utiliser les cmdlets Active Directory, ce qui n'est pas le cas en Powershell 2. Nous voyons donc clairement la différence entre les 2 exécutions.

Appeler une librairie .NET :

Il existe de nombreuses méthodes pour charger une librairie .NET (sous forme de dll ou directement de code C# par exemple). Ici, nous en verrons une qui utilise la commande Powershell Add-Type :

Pour utiliser les Windows forms pour les interfaces graphiques.

Pour administrer IIS, on charge une dll depuis son emplacement sur le disque

Intégrer directement du code C# (il est aussi possible de le faire avec du code VBScript)

Toutefois lorsque la commande Add-Type sera exécutée il n'est pas possible de recharger une librairie qui aurait été modifiée (Cela est dû à .NET). En effet une librairie ne peut être déchargée. Il faut alors changer de session Powershell (c'est à dire lancer une nouvelle instance de Powershell).

Lors de la création d’un meeting Lync (via Outlook), le contenu de la demande peut paraitre très simpliste. Surtout quand l’intégration à la téléphonie n’est pas réalisée:

Dans lync 2013, de nouvelles options sont disponibles pour rendre la demande de meeting plus personnalisé et adapté via des “meeting configuration” particulière. Voici les 4 nouveaux paramètres:

• Logo URL
• Help URL
• Legal Text URL
• Custom Footer Text

Pour configurer ses élément il suffit d’éditer la configuration des meeting par default ou encore de certaines politiques appliquer a un partie des utilisateurs:


Il est aussi possible d’utiliser le Lync Management Shell via la commande:

set-CsmeetingConfiguration avec les paramètres –LogoURL –Legalurl –helpURL –CustomFooterText.
Une fois la configuration réaliser, les champs sont appliquer et les demandes de meeting prennent en compte les paramètres fixés:
Vous pouvez stocker les images directement sur le server FrontEnd Lync Server.

Introduction

Avec Exchange 2010, pour certains besoins bien spécifiques, il se peut que les cmdlets Powershell soit limitées. Cependant, il existe aussi les Exchanges Web Services. Bien entendu, quand on parle des Exchange Web Services, on pense au C# et à un développement complexe. Cependant, on n'oublie souvent que Powershell permet d'exécuter du C#.
Il sera donc question d'accéder aux EWS via Powershell. Il s'agit surtout d'une introduction car les possibilités de scripting sont infinies. L'exemple mis en œuvre dans cet article montrera comment accéder à un dossier bien spécifique pour le purger suivant les dates de réception des emails. Cela permettra entre autres de voir le langage AQS permettant la recherche d'objets dans une boîte aux lettres Exchange.

Prérequis

Avant toute chose, pour manipuler l'API Exchange Web Services, il est nécessaire d'installer le package correspondant sur le poste qui exécutera le script. Il est trouvable en suivant ce lien : http://www.microsoft.com/en-us/download/details.aspx?id=28952

Attention si vous utilisez, Exchange 2013, il faut prendre cette version :
http://www.microsoft.com/en-us/download/details.aspx?id=35371

Il sera ensuite nécessaire d'ajouter dans chacun des scripts qui sera réalisé la dll permettant d'interagir avec les Web Services. Pour rappel, cela se réalise via la commande Powershell Add-Type :

AQS ou Advanced Query Syntax:

Le langage AQS permet de réaliser des recherches dans les objets d'une boîte aux lettres Exchange. Il est très simple à prendre en main.

Pour comprendre toutes les possibilités de ce langage voici le lien MSDN dédié :
http://msdn.microsoft.com/en-us/library/ee693615.aspx

Grâce à ce langage il va être possible de rechercher des éléments :
- par type (emails, réunions, notes, contacts, ...)
- par date (réception ou envoi)
- par propriété d'un email (champ from, to, cc, subject, body, ...)

L'exemple suivant permet de rechercher des emails ayant été reçu le 3 Septembre 2013 :
"Kind:email AND Received:03/09/2013"

On remarque l'opérateur AND qui permet de prendre en compte 2 propositions. Il en existe d'autres comme le OU (l'une ou l'autre des propositions) et le NOT (l'inverse d'une proposition).

Script commenté

Il s'agit ici d'un script où l'utilisateur se connecte à une boîte aux lettres sur laquelle il possède des droits et dont les messages du dossier nommé Personnel seront supprimées s'ils datent de plus de 30 jours. Aussi, pour chaque dossier, il affiche la taille de celui-ci en Ko. Cette dernière opération est aussi faisable via la commande EMS Get-MailboxFolderStatistics mais avec cette exemple nous n'aurons pas besoin d'installer ces outils mais seulement l'API EWS beaucoup plus légère.

On remarque l’opérateur “<” (inférieur à) dans la requête AQS qui permet de spécifier tout ce qui se trouve avant cette date.

On peut accéder aux dossiers publics, modifier, supprimer, créer, tout type d'objet y compris des dossiers. Il est aussi possible de récupérer différentes informations comme la taille d'un dossier. Il est aussi possible d'analyser les pièces jointes pour supprimer celle dont l'extension est d'un certain type. Il est donc possible d'imaginer plein de scripts comme des tâches planifiées effectuant des traitement sur des boîtes aux lettres.