PI Services

Dans certains cas un message d’erreur est renvoyé lors de l’exécution de rapports sous SQL Reporting Services faisant état d’un lien invalide:

Si vous ouvrez le même rapport directement depuis le site web de votre instance Reporting Services (Dans cet exemple un rapport sur les performances mémoire de Sharepoint), le message est effectivement le même.

Pour corriger cela, ouvrez les propriétés du rapport, toujours sur le même site (Pas le fichier .rdpl, mais le fichier du même nom, qui n’a pas d’extension affiché) et sélectionnez Gérer.

A présent il faut cliquer sur Changer le lien. Vous pouvez vous referez a un environnement de test, de preprod, pour voir quel est le lien vers la définition du rapport (Dans cet exemple il s’agit d’un rapport issu de System Center Operations Manager. La majorité des rapports de performance sont rattaché a Microsoft.SystemCenter.Datawarehouse.Report.Performance).

Cliquez sur Changer le lien, sélectionnez la définition du rapport et cliquez OK

Le rapport a récupéré son lien. Cliquez Sur Appliquer.

Et il est a nouveau disponible a l’exécution:

Une des actions récurrentes pour régler certains problèmes d’exécution des règles/moniteurs de supervision consiste en le vidage du cache de données de l’agent SCOM.

Voici un exemple d’implémentation dans un runbook Orchestrator:

Au passage veillez a ranger vos runbook par thèmes et a les nommer de manière explicite

le runbook débute avec une activité “Initialize Data” mais cela pourrait être en réponse, par exemple a un évènement dans l’eventlog OperationsManager.”

“Initialize Data” permet de débuter un runbook en lui passant des paramètres de départ. Dans cet exemple, on ne passe aucun paramètre.

On arrête le service de l’agent Scom sur une machine:

On vide le cache de l’agent (dossier …\System Center Operations Manager\Agent\Health Service State\Health Service Store) avec une activité de type Delete File dans l’integration Pack File Management

La suite du workflow dépend des retours faits par l’activité de vidage du cache

Si le vidage retourne en état Failed (propriétés du lien vers “Vidage cache KO”) on affiche une erreur d’exécution dans la console Orchestrator

Si le vidage retourne en état Success on affiche un message d’information dans la console Orchestrator

Et dans tout les cas on redémarre a la suite le service de l’agent Scom:

Introduction

L’une des forces de Powershell est la gestion à distance de serveurs, de postes clients et d’applications (comme Exchange, Sharepoint,…). Communément appelée Remote Powershell, elle est apparue avec Powershell 2.0 et donc disponible à partir de Windows Server 2003 (R2) SP2. Cette fonctionnalité n’est pas activée par défaut sur les systèmes d’exploitation Windows hors Windows 2012 (R2). Pour réaliser cette opération il faut lancer la commande suivante en mode administrateur :

Cette commande permet de démarrer le service WinRM et d’ouvrir les règles de firewall adéquates si celui-ci est activé (port 5985).

Dans cet article, nous verrons comment se connecter à une machine (qu’elle soit dans le même domaine ou dans un workgroup) ou à une application comme Exchange, comment donner la possibilité à un utilisateur de se connecter via Remote Powershell et enfin l’accès WMI distant.

Entre deux ordinateurs du domaine

Il s’agit du cas le plus simple. Pour se connecter à une machine du même domaine, il suffit d’utiliser la commande suivante :

Il est possible de spécifier l’utilisateur avec lequel on souhaite se connecter via le paramètre Credential :

Ainsi, un prompt demandant le mot de passe apparaîtra.

Depuis un ordinateur d’un workgroup vers un ordinateur en domaine (et vice versa)

Pour se connecter à une machine appartenant à un domaine différent ou à un workgroup, il est nécessaire que le poste source contienne l’ordinateur distant dans sa liste de client de confiance. Pour ajouter une nouvelle machine, il faut utiliser la commande suivante en mode administrateur :

Le paramètre Value peut prendre les valeurs suivantes :

• un nom explicit d’une machine (SERV01)
• * : pour accepter toutes les machines (Ceci n’est pas recommandé)
• *.myenterprise.com : pour accepter toutes les machines possédant le suffixe DNS myenterprise.com

Connexion à distance à une application (Exchange)

Via le couple de commande New-PSSession / Import-PSSession, il est possible de se connecter à une infrastructure Exchange et importer les commandes relatives à la messagerie de Microsoft sur son poste sans avoir à installer le snapin. De plus, seul les commandes accessibles à l’utilisateur seront chargées sur le poste utilisateur (grâce aux mécanismes de RBAC).

La première ligne de commande crée une session qui se connecte à l’infrastructure Exchange (Attention il faut modifier la valeur MYSERVER et le nom d’utilisateur avec vos valeurs) tandis que la seconde importe les commandes sur l’ordinateur initialisant la connexion.

Sessions distantes et permissions

Afin de se connecter à distance, il est nécessaire de faire partie du groupe Administrators (ou Remote Management Users pour Windows 2012 et supérieur) soit en étant connecté directement avec le bon compte (par exemple via un utilisateur administrateur du domaine) soit en s’authentifiant en tant qu’administrateur via le paramètre Credential vu précédemment. Il est aussi possible de donner l’accès à d’autres utilisateurs via la commande suivante :

Une fenêtre s’affiche et il est possible d’ajouter un utilisateur ou un groupe (via le bouton Add) ainsi que des permissions associées. La permission Execute est suffisante  pour se connecter à distance.

NB : Sur Windows 2012 et supérieur, il est nécessaire d’ajouter une clé de registre sur l’ordinateur distant pour que les groupes Administrators et Remote Management Users aient le droit de se connecter via Remote Powershell :

Dans le noeud : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system

Il faut ajouter la clé DWord : LocalAccountTokenFilterPolicy avec la valeur 1.

Cette clé de registre s’applique aussi au chapitre suivant.

Gestion WMI à distance

Pour gérer le WMI à distance (via la commande Set-WmiInstance par exemple). Il faut réunir les 3 conditions suivantes sur le serveur auquel on souhaite se connecter :

• Faire partie du groupe Administrators ou Remote Management Users ou WinRMRemoteWMIUsers__.
• Avoir les permissions suffisantes sur la classe WMI.
• Autoriser l’utilisateur dans la configuration DCOM du serveur.

Les deux dernières conditions sont seulement utiles dans le cas d’un utilisateur qui ne fait pas partie du groupe Administrators (ce dernier possède déjà toutes les permissions nécessaires).

Gestion des permissions via WMI Control :

On ajoute l’utilisateur ou le groupe avec au minimum les permissions Enable Account et Remote Enable. Il sera surement nécessaire d’ajouter d’autres droits suivants l’action que l’on souhaite réaliser.

Autorisation de l’utilisateur dans la configuration DCOM :

En lançant la console dcomcnfg, aller dans Component Services, Computers, My Computer et effectuer un clic droit et choisir Properties.

Dans l’onglet COM Security, choisir Edit Limits dans la section Launch and Activation Permissions. Ajoutez l’utilisateur ou le groupe souhaité et activez l’ensemble des permissions pour avoir accès en local et à distance en WMI via Powershell.

Il y’a quelques jours Symantec à sorti un nouveau service pack pour son logiciel d’archivage, Enterprise Vault, qui passe maintenant en version 10.0.4.

Voyons quelles sont les nouveautés de cette version :

- Enterprise Vault Extensions
Cette fonctionnalité apporte la possibilité aux développeurs membres du STEP, Symantec Technology Enabled Program, de programmer des extensions pour du contenu non géré nativement par Enterprise Vault. Ces extensions seront visibles depuis la console d’administration du logiciel.

- Amélioration de la migration des PST
Ajout des notifications mails pour l’utilisateur lors de l’archivage d’un de ses PST, ajout d’un bouton d’import de PST dans la barre d’outils EV dans Outlook ou encore définir des priorités dans le processus d’import de PST.

- Mise à jour des options pour les catégories de rétentions
Les catégories de rétentions SharePoint sont également mises à jours.

- Possibilité d’ajouter des exclusions pour l’indexation
Par exemple, il est inutile d’indexer le disclaimer ou la signature mails des collaborateurs.

- Domino 9.0 est maintenant supporté pour l’archivage

- Support de Windows Server 2012
Grosse nouveauté ! Enterprise Vault supporte Windows Server 2012, à condition d’installer un hotfix Microsoft. Pour information, Windows Server 2012R2 est en cours de validation.

Ce service pack corrige bien sûr plusieurs problèmes connu des versions précédentes. On retrouve notamment un meilleur support pour Exchange 2013, la taille maximum des archives est maintenant de 200Gb, et pleins d’autres corrections.

Prenez contact avec nous dès maintenant, nous pouvons vous aider à planifier et installer cette nouvelle version.

Bon archivage !

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}