De nombreux Management Pack SCOM créent des évènements dans la base SCOM (visibles dans la console SCOM via les vues Events).

C’est notamment le cas du MP de collecte  et de formatage d’évènements Syslog que je vous ai proposé dans un billet précédent.

Ces évènements n’ont bien sur que peu d’utilité s’ils ne sont pas traités pour obtenir des alertes ou des courbes de performance…

Je vais ici expliquer comment exploiter ces informations à l’aide d’une règle d’alerte qui exécute un script powershell.

Contexte : il a été demandé de générer une alerte lorsqu’un évènement syslog provenant d’un device réseau n’est pas recu un certain nombre de fois dans un laps de temps donné…. J’ai retourné le problème dans tous les sens mais il n’est à ma connaissance pas possible d’y répondre à l’aide d’un workflow utilisant des datasource et des conditions des librairies “standard”.

La solution la plus simple est alors de stocker tous les évènements syslog proprement formatés dans la base SCOM, et de les traiter à l’aide d’un script.

Voyons d’abord comment il est constitué dans son ensemble, je détaillerai chaque partie ensuite :

                <ScriptBody>
param($IPAddress)

$api = new-object -comObject 'MOM.ScriptAPI'
$bag = $api.CreatePropertyBag()

$SQLServer = (Get-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\').databaseservername
$SQLDBName = (Get-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\').databasename
$SqlQuery = "SELECT TOP 2 * FROM [OperationsManager].[dbo].[EventView] where channel like 'syslog' AND LoggingComputer = '" +  $ipaddress + "'  AND EventData like '%Sophos pattern update failed: File transfer failed%' ORDER BY TimeGenerated DESC"
$sqlquery

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server = $SQLServer; Database = $SQLDBName; Integrated Security = True"

$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection

$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd

$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)

$SqlConnection.Close()

$referencedate = (get-date).addhours(-4).touniversaltime()

$result = ($DataSet.Tables[0] | where {$_.timegenerated -gt $referencedate} | measure).count

if ($result -ge "2")
{
$status = "KO"
$api.LogScriptEvent('Mirapoint CheckSophosTransferFailed Result : KO ',20,4,$ipaddress)
}

else {$status = "OK"
$api.LogScriptEvent('Mirapoint CheckSophosTransferFailed Result : OK ',20,4,$ipaddress)
}

if ($status -eq "KO") { $bag.AddValue('Status','Bad') }
else { $bag.AddValue('Status','Good') }

$bag

</ScriptBody>

Passons aux explications détaillées :

param($IPAddress) permet juste de récupérer l’adresse IP, passée en paramètre du script. C’est elle qui nous permet d’identifier les évènements correspondant au bon device réseau supervisé.

$SQLServer et $SQLDBName sont des variables qui récupèrent le nom du serveur et de la base SQL de SCOM dans la base de registre du serveur MS sur lequel s’execute le script (comme la règle est ciblée sur des device réseau, le script s’execute sur le MS qui gère le périphérique et non pas sur l’agent)

$SqlQuery est la requête SQL sur laquelle va s’appuyer le traitement du script. La partie “FROM [OperationsManager].[dbo].[EventView]” est obligatoire car il faut requêter la vue EventView pour accéder aux évènements SCOM. Pour le reste, libre à vous d’adapter à votre besoin!

Tout le bloc entre $SqlConnection et $SqlConnection.close() peut être recopiée tel quel, il contient les cmdlet permettant d’effectuer la connexion à la base SQL, d’exécuter la requête et de récupérer son résultat dans la variable $DataSet.Tables[0] .

Le reste du code contient la logique du script et dépend donc de vos besoins, rappelez vous simplement de finir votre script en peuplant puis en retournant le propertybag :

if ($status -eq "KO") { $bag.AddValue('Status','Bad') }
else { $bag.AddValue('Status','Good') }

$bag

Je ne saurais trop vous recommander de tester votre script “en dehors” du management pack avant de l’y intégrer car il peut vite devenir complexe… une fois satisfait, créez votre règle basée sur une probe Microsoft.Windows.PowerShellPropertyBagProbe par exemple comme le décrit Microsoft : https://social.technet.microsoft.com/wiki/contents/articles/16752.management-pack-composition-exercise-2-creating-a-monitor-based-on-a-windows-powershell-script.aspx

Comme vous le savez probablement déjà, SCOM permet de créer des règles d’alerte basées sur la collecte d’événements syslog.

Ces événements collectés ont malheureusement le gros défaut d’être « bruts », sans aucun formatage ni filtrage des champs : ils sont stockés comme un gros bloc de texte dans la base de donnée.

Ce n’est pas idéal si votre objectif est de leur appliquer un traitement complexe, par exemple à l’aide d’un script (plus de détails à ce sujet dans un prochain billet).

Il est cependant simple d’y remédier, à condition d’accepter de mettre la main à la pâte, car la DataSource utilisée n’est disponible dans aucune template prédéfini… on n’a rien sans rien.

Avant de débuter, un petit rappel : une règle utilisant une datasource Syslog doit être ciblée sur la classe « Agent » et elle va activer l’écoute de l’agent SCOM sur le port syslog pour tous les serveurs ciblés : il est donc fortement recommandé de la désactiver par défaut, et de créer un override d’activation ciblé sur un groupe contenant le ou les agents responsables de la collecte d’évènements syslog.

Voyons maintenant la structure logique de notre Management Pack :

- Classe pour le groupe qui contient les agents responsables de la collecte
- Découverte qui peuple le groupe
- Règle de collecte
- DisplayStrings

C’est bien évidement la règle de collecte qui nous intéresse le plus. Détaillons son contenu :

<Rules>
      <Rule ID="Test.Syslog.CollectionRule" Enabled="false" Target="SC!Microsoft.SystemCenter.Agent" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="SyslogDS" TypeID="ApplicationLog!System.ApplicationLog.SysLog.EventProvider">
            <Port>514</Port>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="GenericDataMapperCD" TypeID="System!System.Event.GenericDataMapper">
          <EventOriginId>$Target/Id$</EventOriginId>
          <PublisherId>$MPElement$</PublisherId>
          <PublisherName>$Data/EventData/DataItem/PriorityName$</PublisherName>
          <Channel>Syslog</Channel>
          <LoggingComputer>$Data/EventData/DataItem/HostName$</LoggingComputer>
          <EventNumber>54321</EventNumber>
          <EventCategory>0</EventCategory>
          <EventLevel>0</EventLevel>
          <UserName />
          <Description>$Data/EventData/DataItem/Message$</Description>
          <Params />
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
         
        </WriteActions>
      </Rule>
    </Rules>

Cette règle est, comme vu plus haut, ciblée sur la classe Microsoft.SystemCenter.Agent et désactivée par défaut (enabled=false).

Son workflow est constitué de trois éléments principaux :

- une DataSource de type System.ApplicationLog.SysLog.EventProvider, qui permet d’activer l’écoute de message syslog sur le port spécifié (attention, on ne peut pas avoir deux règles syslog qui s’exécutent sur le même serveur avec le même port!)
- un GenericDataMapper : c’est lui qui va faire la correspondance entre les champs d’un évènement SCOM (EventOrigin, PublisherId, PublisherName, Logging Computer, Description…) et les champs issus du message Syslog. J’utilise aussi des champs aux valeurs hardcodées dans cet exemple (EventNumber, EventLevel…)
- Une WriteAction, qui écrit l’évènements formaté dans la base de donnée.

Simple, non?

Une fois le MP importé et l’override d’activation défini, les évènements devraient apparaitre dans la base de donnée. Attention, la DB de SCOM contient 20 tables pour les évènements, utilisés en roulement. Il est donc bien plus pratique et efficace de passer par la vue EventView qui les regroupe!

Pour une vue plus globale, voici un exemple de MP de collecte Syslog complet (il ne reste plus qu’à peupler le groupe et à créer l’override d’activation sur la règle de collecte) :

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <Manifest>
    <Identity>
      <ID>Test.Syslog</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>Test.Syslog</Name>
    <References>
      <Reference Alias="ApplicationLog">
        <ID>System.ApplicationLog.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SCDW">
        <ID>Microsoft.SystemCenter.DataWarehouse.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="MicrosoftSystemCenterInstanceGroupLibrary7585010">
        <ID>Microsoft.SystemCenter.InstanceGroup.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SC">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Health">
        <ID>System.Health.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Test.Syslog.Collector.Group" Accessibility="Public" Abstract="false" Base="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" Extension="false" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Discoveries>
      <Discovery ID="Test.Syslog.Collector.Group.DiscoveryRule" Enabled="true" Target="Test.Syslog.Collector.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPopulationDataSource" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="Test.Syslog.Collector.Group"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule Comment="EMPTY_RULE_8eadaced-59c8-4ebc-a4e4-b8428a374442">
              <MonitoringClass>$MPElement[Name="System!System.Entity"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <Value>True</Value>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>False</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
    <Rules>
      <Rule ID="Test.Syslog.CollectionRule" Enabled="false" Target="SC!Microsoft.SystemCenter.Agent" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="SyslogDS" TypeID="ApplicationLog!System.ApplicationLog.SysLog.EventProvider">
            <Port>514</Port>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="GenericDataMapperCD" TypeID="System!System.Event.GenericDataMapper">
          <EventOriginId>$Target/Id$</EventOriginId>
          <PublisherId>$MPElement$</PublisherId>
          <PublisherName>$Data/EventData/DataItem/PriorityName$</PublisherName>
          <Channel>Syslog</Channel>
          <LoggingComputer>$Data/EventData/DataItem/HostName$</LoggingComputer>
          <EventNumber>54321</EventNumber>
          <EventCategory>0</EventCategory>
          <EventLevel>0</EventLevel>
          <UserName />
          <Description>$Data/EventData/DataItem/Message$</Description>
          <Params />
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
        </WriteActions>
      </Rule>
    </Rules>

  </Monitoring>
  <LanguagePacks>

    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Test.Syslog">
          <Name>Test.Syslog</Name>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.CollectionRule">
          <Name>Syslog - Collection Rule</Name>
          <Description>Cette regle est en charge de la collecte de tous les evenements syslog, quel que soit l'emmeteur.
Chaque agent en charge de la reception des messages syslog doit etre ajoute au groupe Test.Syslog.Collector</Description>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.Collector.Group">
          <Name>Test.Syslog.Collector</Name>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.Collector.Group.DiscoveryRule">
          <Name>Populate Test.Syslog.Collector</Name>
          <Description>This discovery rule populates the group 'Test.Syslog.Collector'</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

SQL Server 2012 cache quelques petites nouveautés qui peuvent bien vous surprendre.

J’ai découvert récemment qu’il est désormais possible de reconstruction un index en ligne sur SQL Server 2012 de tables qui contiennent des types VARCHAR(MAX) et NVARCHAR(MAX).

Démonstration :

Commencez par exécuter le script sous SQL Server 2008 R2 puis sur SQL Server 2012.

USE [tempdb]
GO
CREATE TABLE T1
(ID INT, C1 NVARCHAR(10), C2 NVARCHAR(MAX))
GO
CREATE CLUSTERED INDEX [IX_T1]
ON T1
(ID)
GO
CREATE NONCLUSTERED INDEX [IX_T1_Cols]
ON T1
(C1)
INCLUDE (C2)
GO
USE [tempdb]
GO
ALTER INDEX [IX_T1_Cols] ON [dbo].[T1]
REBUILD WITH (ONLINE = ON)
GO
DROP TABLE T1
GO

Résultat :

Sur le serveur SQL Server 2008 R2, on a un message d’erreur du type

Msg 2725, Level 16, State 2, Line 1
An online operation cannot be performed for index ‘IX_T1_Cols’ because the index contains column ‘C2’ of data type text, ntext, image, varchar(max), nvarchar(max), varbinary(max), xml, or large CLR type. For a non-clustered index, the column could be an include column of the index. For a clustered index, the column could be any column of the table. If DROP_EXISTING is used, the column could be part of a new or old index. The operation must be performed offline.

Tandis que sur le serveur SQL Server 2012

Command(s) completed successfully.

Lors d’une mission d’installation de SQL Server chez un client, j’ai rencontré un problème d’installation du service SQL Server Reporting suite à une réinstallation du serveur.

L’erreur en question mentionne que le service SQL Server Reporting ne peut pas etre installé car il existe une instance du même nom sur le serveur.

An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

Pour résoudre ce problème :

1. Commencez par désinstaller tous les binaires de SQL Server 2005

2. Supprimez le dossier correspondant à C:\Program Files\Microsoft SQL Server\, ou spécifiquement le dossier C:\Program Files\Microsoft SQL Server\MSSQL.1.

3. Puis ouvrez l’éditeur du registre recherchez les clés suivantes pour les supprimer :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.1

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Services\SQL Server

4. Puis redémarrer votre serveur et relancez votre installation.

Si vous êtes administrateur de longue date d’une supervision SCOM, vous regrettez très probablement la disparition de la console Authoring présente dans SCOM 2007.

Elle permettait le développement rapide et (en partie) graphique de Management Packs relativement complexes avec une création assez visuelle des workflow de supervision.

L’arrivée de SCOM 2012 a malheureusement signé l’arrêt de son support : il est toujours possible de créer un MP avec la console Authoring et de l’importer sur une plateforme SCOM 2012, mais il n’est par la suite plus possible de le rouvrir pour le modifier. Il n’est évidemment pas possible non plus de tirer profit des nouvelles fonctionnalités propres à SCOM 2012 (nouveaux Dashboard, nouvelles fonctionnalités de supervision réseau…).

La préconisation de Microsoft était alors de se rabattre sur Visual Studio avec les extensions VSAE (Visual Studio Authoring Extensions), ou sur Visio à l’aide de VMPD (Visio Management Pack Designer) pour les management pack les plus simples.
Nous avions donc le choix entre une solution peu pertinente et très limitée (Visio) et la solution la plus complète qui soit, mais également la moins accessible aussi bien en terme de complexité de mise en œuvre que de coût.

MP Author

Heureusement, après presque 2 ans de disette, les développeurs de Silect (une filiale de Bridgeways, un éditeur de Management Pack) ont entendu notre appel et ont publié l’outil gratuit MP Author (http://www.silect.com/mp-author ), qui rappelle la console Authoring par bien des aspects.

Reprenons par exemple l’exemple classique de la création d’un MP contenant une classe et une découverte à l’aide d’une clé de registre :

L’installation est assez directe (suivant -> suivant -> ok), notez cependant qu’il est nécessaire que la console SCOM 2012 (R2) soit présente.

On crée ensuite un nouveau MP :

On indique un ID, un nom et une description

Dossier d’export

MPs à référencer

Il est préférable de sélectionner Empty Management Pack car le template Single Server Application crée des objets inutiles à une supervision basique

Nous arrivons maintenant à l’écran principal de l’outil, d’une apparence plutôt familière si on a l’habitude de la console Authoring.

Cliquer sur Target > New > Create New Registry Target :

Il est possible de se connecter à un serveur distant pour parcourir sa base de registre à la recherche de la clé appropriée, ou bien d’entrer à la main les informations :

Sélectionner la clé de registre sur laquelle se basera la découverte :

Donner un ID et un nom à la classe :

De même pour la découverte :

Définir une expression pour la découverte :

Définir un intervalle de découverte :

A l’aide d’un assistant très similaire, on ajoute un moniteur qui supervisera le service DHCP :

Il ne reste plus qu’à exporter votre management pack, soit directement vers SCOM à l’aide d’un clic droit sur la racine de l’arborescence à gauche > Import Management Pack :

Soit en sauvegardant le MP sous forme de fichier XML et en l’important via la console SCOM.

Certes, cet outil est moins complet que l’ancienne console Authoring et perfectible sur bien des points, mais il devrait permettre de gagner un temps précieux et remplace avantageusement la solution Visio proposée par Microsoft!

Visual Studio

Le but ici n’est pas de vous proposer une introduction complète à l’utilisation de Visual Studio pour le développement de Management Pack, mais plutôt de vous révéler une astuce : en effet, le titre de ce billet est « deux outils de développement gratuits »…

Et il n’est effectivement pas nécessaire de débourser le moindre centime, ni même de se lancer dans le téléchargement fastidieux d’un iso de plusieurs Go pour obtenir un Visual Studio exécutant les Authoring Extensions de manière parfaitement fonctionnelle !

Voici ce dont vous aurez besoin :

Microsoft Visual Studio 2012 Shell (Isolated) Redistributable Package (220 mo) : www.microsoft.com/en-us/download/details.aspx?id=30670

Microsoft Visual Studio 2012 Shell (Integrated) Redistributable Package (1,5 mo) : http://www.microsoft.com/en-us/download/details.aspx?id=30663

System Center 2012 Visual Studio Authoring Extensions (32 mo) : http://www.microsoft.com/en-us/download/details.aspx?id=30169

Et… c’est tout ! L’installation est des plus classique (suivant -> suivant -> OK) et vous permet d’obtenir un Visual Studio en bonne et due forme, avec les templates nécessaires au développement de Management Packs :

Bon développement !

Je vous propose de faire un tour d’horizon de l’outil Application Compatibility Toolkit 6.1. Cet article se décompose en trois parties :

Partie 1 : Introduction et installation

Partie 2 : Création et déploiement de l’outil d’inventaire

Partie 3 : Analyse et exploitation des données colletées

Introduction

Application Compatibility Toolkit 6.1 permet d’aider les équipes IT dans le processus de migration vers un nouveau système d’exploitation. L’objectif de l’outil est de fournir des informations sur la compatibilité des applications présentes dans votre parc.

Sur quels systèmes d’exploitation peut-on collecter des informations sur les applications ?

L’inventory Collection Package peut être exécuté pour collecter des informations sur les applications installées sur les systèmes suivants :

• Windows 8.1, 8, 7, Vista, XP et 2000
• Windows Server 2012R2, 2012, 2008 R2, 2008, 2003 R2 et 2003

Fonctionnement

Depuis la console Application Compatibility Toolkit, on génère un package qui sera chargé d’inventorier les applications des postes de travail. Après exécution du package, les données collectées seront stockées sur un partage réseau dédié.

ACT s’appuie sur un service nommé « ACT Log Processing Service ». Celui-ci analyse les informations contenues dans les fichiers déposés sur le partage réseau. Puis, les données du poste de travail sont ajoutées dans la base de données.

Enfin depuis la console ACT, vous exploitez les informations sur la compatibilité des applications depuis la base de données.

Mise en place

Dans un premier temps, il faut tout d’abord installer l’outil Application Compatibility Toolkit. Il est disponible dans le Kit de déploiement et d’évaluation Windows 8.1 (ADK 8.1). À télécharger gratuitement ici.

Depuis l’assistant d’installation ADK 8.1, vous devez ajouter les composants suivants :

• Application Compatibility Toolkit (ACT)
• Microsoft SQL Server 2012 Express

Préparation

Système d’exploitation

Application Compatibility Toolkit doit être installé sur l’une des plateformes suivantes :

• Windows 8, 7, Vista (SP2) et XP(SP3)
• Windows Server 2012, 2008 R2, 2008 (SP2)

Base de données

Application Compatibility Toolkit a besoin d’une base de données pour fonctionner. Voici la liste des versions SQL Server supportées :

• Microsoft SQL Server 2012
• Microsoft SQL Server 2008 R2
• Microsoft SQL Server 2008
• Microsoft SQL Server 2005

Quelles sont les versions de SQL Server supportées ?

Si vous disposez déjà d’un serveur SQL, vous pouvez choisir de:

• Créer une nouvelle base de données sur une nouvelle instance SQL
• Créer une nouvelle base de données sur une instance SQL déjà existante

Si vous n’avez pas de serveur SQL, installer une version SQL Server Express disponible gratuitement avec ADK.

.Net Framework

ACT 6.1 nécessite le composant .Net Framework 4.

Configuration

Après l’installation d’ACT 6.1 et SQL Express 2012, vous devez configurer l’application.

Lancer Application Compatibility Toolkit

L’assistant vous propose d’installer le service « ACT Log Processing Service ». Ce service permet de traiter les données des postes de travail puis de les intégrer dans la base de données SQL. Sans ce service, votre base de données ne sera pas alimentée. Sélectionnez « Yes » puis cliquez sur « Next »

L’étape suivante configure la base de données SQL. Sélectionner votre serveur SQL et la base de données à utiliser.

La prochaine étape détermine le répertoire où seront stockées les données collectées sur les postes. Indiquez un chemin local et le nom du partage réseau à créer. Comme l’indique l’assistant, vérifiez que les postes clients disposent des droits en écriture dans ce répertoire.

La prochaine étape vous propose de renseigner le compte à utiliser pour exécuter le service « ACT Log Processing Service ». Deux options s’offrent à vous :

• Utiliser le compte local System (par défaut)
• Utiliser un compte de service.
  Si vous retenez cette dernière option, vérifier les points ci-dessous. Le compte doit :
• Être autorisé à ouvrir une session en tant que service.
• Disposer des droits en écriture sur le répertoire contenant les fichiers collectés
• Disposer des droits en écriture sur la base de données

La configuration de l’outil touche à sa fin. Cliquez sur Finish

L’outil Application Compatibility Toolkit est maintenant installé et configuré. Je vous propose maintenant de passer à la partie 2 : Création et déploiement de l’outil d’inventaire

Collecte

La console Application Compatibility Toolkit s’oriente autour de deux axes.

1. La collecte d’informations sur le parc

2. L’analyse et l’exploitation des informations

Ce second article présente le processus de collecte des applications.

Le menu collecte vous permet de gérer vos packages. Il est possible de créer deux types de package.

• « Inventory Collection Package » Ce package permet de faire un recensement des applications installées sur un poste de travail. Son utilisation est transparente pour l’utilisateur final, car l’outil s’exécute en tâche de fond. Les données issues de la collecte sont traitées et ajoutées dans ACT.

• « Runtime Collection Package » Propose d’analyser les applications installées sur un poste pour vérifier la compatibilité de celle-ci.

Processus d’inventaire

Les paragraphes suivants montrent la marche à suivre pour collecter les applications installées sur un parc informatique.

Création d’un package d’inventaire

La première étape pour obtenir les applications installées est la création d’un package qui va analyser et exporter les logs sur un partage réseau dédié.

Pour créer un package d’inventaire, placez-vous dans l’onglet « Collect »

Puis, cliquez sur « Create new data collection package »

Une première fenêtre s’ouvre, cliquez sur « Inventory Collection Package »

La seconde fenêtre de l’assistant paramètre votre package d’inventaire. Vous devrez remplir les trois champs suivants :

• Choisir le nom du package
• Indiquer le chemin du répertoire partagé sur lequel seront déposés les résultats des collectes.
• Déterminer un Label. Celui-ci permet d’ajouter une indication sur la cible. En pratique grâce à l’utilisation des labels, l’exploitation des résultats sera simplifiée. Par exemple via l’utilisation des filtres (que nous verrons plus tard) vous pourrez construire des rapports ayant pour cible un service ou département spécifique.

Lorsque vous cliquez sur « Create », l’assistant vous propose d’exporter le package. Sélectionner un chemin, puis cliquez sur « Save »

Le package est prêt à être utiliser. Notez que le compte sera utilisé pour exécuter le package doit avoir les droits en écriture sur le partage réseau contenant les logs.

Déploiement du package

La seconde étape consiste à déployer le package sur les postes cibles. Différentes méthodes de déploiements sont disponibles, à savoir :

• Stratégies de groupe
• Script d’ouverture de session
• Par l’intermédiaire du produit System Center Configuration Manager

Manuel
• Exécution d’un script personnalisé
• Mise à disposition sur un répertoire partagé

Attention : L’outil a besoin des droits administrateurs sur les postes pour s’exécuter correctement.

Exécution du package

L’exécution du package est totalement silencieuse. Les utilisateurs ne seront ni avertis ni gênés par l’exécution du scan. En arrière-plan, le package dépose quelques fichiers dans le répertoire "Program Files (x86)\Inventory Collection Package". Le processus de collecte démarre automatiquement. Vous pourrez vérifier l'exécution de la collecte via le gestionnaire de tâche Windows. Le nom du processus est : bucketizer.exe

À la fin de l’opération de collecte, les résultats sont envoyés sur le chemin réseau (déterminé au cours de la création via l’assistant). De plus, le répertoire temporaire Inventory Collection Package sera supprimé.

Périodiquement, le service « ACT Log Processing Service » vérifie la présence de nouveau fichier de collecte dans le partage réseau. Dès que le service détecte un nouveau fichier, celui-ci est analysé, traité et intégré dans la base de données ACT. Enfin, vous trouverez dans la console ACT les résultats de la collecte.

Le dernier article est dédié à l’analyse des informations : Partie 3 : Analyse et exploitation des données colletées

Ce troisième article sur Application Compatibility Toolkit traite la phase d’analyse de données récoltées.

Avec ACT il est possible de faire une synchronisation de la liste de vos applications sur une plateforme Microsoft. Celle-ci permet d’obtenir les informations officielles publiées par les éditeurs de logiciel. L’accès à ces informations permet de gagner du temps pour la validation de vos applications. De plus, la plateforme héberge les résultats de compatibilité d’une communauté d’utilisateur d’ACT. Celle-ci s’avère utile pour faire le point sur une application dont l’éditeur n’a pas communiqué d’information officielle. Dans les options, il est possible de choisir si l'on souhaite ou non envoyer les résultats de compatibilité sur la plateforme Microsoft

Le menu analyse vous permet de visualiser le résultat de la collecte. Les rapports sont regroupés par système d’exploitation : Windows 7, Windows 8 et Windows 8.1.

Information : Vous pouvez choisir d’afficher uniquement les rapports qui correspondent au système d’exploitation cible. Pour ce faire, cliquez sur « Customize this view » et décochez les systèmes inutiles.

Rapport général

Pour chaque système d’exploitation, ACT fournit un rapport général.

Informations sur l’inventaire

Les premières informations portent sur le processus d’inventaire lui-même :

• Le nombre de postes de travail analysé
• Le nombre d’applications recensé
• Le nombre de périphériques détecté

Informations sur les applications

Ensuite, vous trouvez un tableau de synthèse concernant la compatibilité des applications. Vous pourrez ainsi identifier le nombre d'applications:

• Incompatibles
• Compatibles
• Compatibles, mais qui risque de présenter quelques problèmes mineurs à l’utilisation
• Sans informations sur la compatibilité

Dans la page sont ensuite présentées les informations sur la compatibilité des applications par rapport :

• Aux informations concernant le support officiel de l’éditeur « Vendor Assessment »
• À votre résultat sur la compatibilité « My Assessment »

Notez que pour chaque application ACT distingue les architectures 32 et 64 bits.

Informations sur les périphériques

Le tableau dédié aux résultats sur la compatibilité des périphériques est similaire à celui des applications. On retrouve le nombre de périphériques :

• Incompatibles
• Compatibles
• Compatibles, mais qui risque de présenter des problèmes mineurs
• Sans informations sur la compatibilité

Rapport détaillé

Pour chaque système d’exploitation, ACT fournit des rapports détaillés pour:

• Les applications
• Les postes de travail
• Les périphériques
• Les Add-On Internet Explorer
• Un Feedback global

Notez que tous les rapports sont exportables dans les formats suivants : Excel, CSV et XLM.

Rapport sur les applications

L’onglet application recense l’ensemble des informations sur la compatibilité des applications.

Vous trouverez les trois premières colonnes qui identifient l’application :

• Le nom de l’application
• La version
• L’éditeur

Évaluation de la compatibilité

• Votre évaluation sur la compatibilité « My Assessment »
• L’état de la synchronisation avec la communauté « Send and Receive Status »
• Les informations sur la compatibilité officielle « Vendor Assessment »
• Les retours sur la compatibilité de la communauté « Community Assessment »

Autres colonnes

• La colonne « Versions » affiche le nombre de versions mineur de l’application détectée sur les postes.
• Le nombre de postes sur lesquels l’application a été détectée est inscrit dans la colonne « Computer ».
• Vous avez la possibilité de choisir une priorité pour chaque application. Celle-ci est affichée dans l’onglet « Priority ». 4 Niveaux de priorité sont disponibles :
  o Priorité 1 – Business Critical
  o Priorité 2 – Important
  o Priorité 3 – Nice to Have
  o Priorité 4 – Unimportant
  o Unspecified
• La dernière colonne est intitulée « Deployment Status ». Comme pour la colonne précédente, ACT vous propose de choisir le statut du déploiement de l’application :
  o Not Reviewed
  o Testing
  o Mitigating
  o Ready to Deploy
  o Will not Deploy
• La colonne « Active Issues » est intéressante dans le cas où une application est incompatible.

Via la plateforme Microsoft, l’éditeur du logiciel peut publier des informations pour résoudre les problèmes de compatibilité (MAJ de l’application de la plupart des cas).

Exemple d’une solution proposée pour l’application Adobe Flash Player 10 Plugin :

De plus, sachez qu’il existe une autre information (non visible dans le tableau) pour vous aider à organiser votre parc applicatif : les catégories.
La liste de catégories est personnalisable et vous permet d'assigner à une application une ou plusieurs catégories. L'utilisation de celle-ci vous sera fort utile si vous souhaitez utiliser des filtres dans vos rapports.

L’interface est personnalisable et vous pouvez choisir les colonnes à afficher et celle à masquer (via un clic droit sur la ligne d’en tête du tableau)

Rapport sur les postes de travail

Dans cet onglet dédié au poste de travail, on retrouve les colonnes suivantes :

• Le nom du poste
• Le nombre d’applications ayant un problème de compatibilité
• Le nombre de périphériques ayant un problème de compatibilité
• Le système d’exploitation
• Le domaine Active Directory
• Le nombre d’applications
• Le nombre de périphériques

Information : Les postes de travail équipés de Windows XP SP3 sont identifiés en SP2. En réalité, le SP3 est bien détecté, mais ACT le répertorie comme une application nommée « Windows XP Service Pack 3 ».

Rapport personnalisé : Filtrage

ACT intègre une fonction de filtrage sur les différents rapports (applications, poste de travail, etc.). Le filtre est accessible depuis la barre d’outils principale.

Via cette fonctionnalité de filtrage, vous pourrez construire un rapport personnalisé basé sur des conditions.

Par exemple, vous pourrez générer un rapport contenant :

• Les applications de priorité 1 Business Critical
• Les applications détectées sur les postes de travail nommées avec une syntaxe précise (ex. : INFO, ACHAT…)
• Les applications qui font partie de la catégorie nommée « Drivers »

Vous trouverez ci-dessous une capture d’écran des différents champs disponibles :

Sachez qu’il est possible de créer des requêtes avancées en ajoutant plusieurs conditions. Notez également que l’outil permet de sauvegarder vos requêtes personnalisées pour une utilisation ultérieure de celle-ci.

Dans certains contexte, nous avons besoin qu’un script Powershell ne soit exécuté que si la fenêtre Powershell n’a été lancée qu’en tant qu’administrateur.

Pour effectuer ce contrôle et lancer l’exécution du script :

$currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
if (($currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) -eq $false)
{
    write-host "Merci de relancer le script avec élévation de privilèges" -f red -b yellow
}

    Saisissez votre code

    ###############################################
}

Maintenant si vous lancez votre script Powershell sans exécuter d’élévation, voici le résultat :

Imaginons maintenant que nous voulons exécuter un script uniquement si le compte utilisé dispose du droit domain admin :

Tout d’abord vous devez identifier le SID du groupe domain admin.

Une fois identifié voici un exemple d’intégration pour appliquer cette condition:

    $currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
    $DroitDomainAdmin=0;$currentUser.Identities.groups | %{if($_.value -eq "S-1-5-21-XXXXXXXXXXXXXXXXXXXX"){$DroitDomainAdmin=1}}

     ### S-1-5-21-XXXXXXXXXXXXXXXXXXXX correspond à votre SID du groupe domain admin

    if ($DroitDomainAdmin -eq "0")
    {
        write-host "Vous ne disposez pas du jeton Domain\Domain Admins" -f red -b yellow
        write-host "Merci de vous l'attribuer et de relancer le script" -f red -b yellow
    }
    else

        Saisissez votre code

        ###############################################
    }

(Ce script est exécuté sous Powershell en version 3)

Vous disposez d’un plan de câblage identique pour plusieurs serveurs sur un même modèle. Chaque cartes réseaux sur les différents serveurs doivent être configurés de façon identique : même nom d’interfaces, mêmes protocoles, etc..

Afin d’identifier de manière automatiser les interfaces, vous pouvez vous baser sur le paramètre de localisation des interfaces (sur un même modèle de serveur).

Exemple :

Nous allons ici chercher à récupérer le nom de l’interface (pouvant varier d’une installation à l’autre en fonction de l’ordre de détection des interfaces réseaux)

Ici, nous allons identifier les différentes cartes réseaux et leurs emplacement :

Get-WMIObject Win32_PnPSignedDriver | ? {$_.deviceclass -match "NET"} |select description, location

Nous avons pu identifier la valeur correspondante à notre carte réseau.

Nous allons maintenant récupérer son nom d’interface présent dans le gestionnaire des connexions réseaux (ncpa.cpl)

$location=”PCI bus 3, device 0, function 0”

#### deviceclass retourne les résultats des périphériques PnP de type réseaux

Get-WMIObject Win32_PnPSignedDriver |? {$_.location -match $location -and $_.deviceclass -match "NET"} |%{$_.friendlyname} | %{Get-NetAdapter -InterfaceDescription $_} | %{$_.name}

Exemple pour l’inteface Wifi :