PI Services

Le blog des collaborateurs de PI Services

Installation de Windows (x64) sur une partition GPT

Depuis l’apparition de l’UEFI (Unified Extensible Firmware Interface) supposé à terme remplacer le BIOS, les disques MBR laissent peu à peu leurs place aux disques GPT qui permettent par disque physique la cohabitation de 128 partitions de 9,4 milliards de To ce qui laisse loin derrière le BIOS et ses 4 partitions de 2,2 To par disque…

Lorsque l’on tente de réinstaller Windows via une clé USB sur une partition de disque en GPT l’erreur suivante apparait :

“Windows cannot be installed on this disk. The selected disk is of the GPT partition style.”

Ce message d’erreur bien peu bavard ne dit rien sur la cause de l’échec, si ce n’est que la partition est de type GPT. L’erreur ici vient en fait de la clé USB, n’étant pas reconnue comme un périphérique compatible UEFI, c’est le BIOS qui prend la relève, et celui-ci voit les partitions GPT uniquement comme étant réservées au données, donc impossible d’y installer d’OS.

Cependant, en modifiant la structure des fichiers d’installation de Windows sur la clé USB, l’installation se déroule comme prévue.

Step 1 – Formater la clé en FAT32

Et oui FAT32 est le format utilisé par l’UEFI, inutile de s’inquiéter pour le moment les fichiers d’installation de Windows 7 et 8 ne dépassent pas les 4Go, de plus le mode de compatibilité permet d’utiliser le NTFS.

Step 2 – Copier les fichiers d’installations à la racine de la clé

 

Step 3 – Récuperer le fichier bootmgfw.efi

Depuis une version x64 de Windows installée sur un système UEFI, récupérer le fichier bootmgfw.efi disponible à cet emplacement : C:\Windows\Boot\EFI\bootmgfw.efi

Step 4 – Modifier l’emplacement du fichier boot

Modifier l’emplacement du fichier boot depuis G:\efi\microsoft vers G:\efi.

 

Step 5 – Renommer et déplacer bootmgfw.efi

Renommer bootmgfw.efi en bootx64.efi et le copier vers G:\efi\boot.

Maintenant que la clé est prête, l’erreur apparue plus tôt n’est plus là, et l’installation de Windows peut continuer normalement.

Powershell : Définir la liste d'adresse par défaut d'Outlook

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

3

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

1

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

2

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

Erreur d’exécution du rapport “EV FSAReporting Daily Job”

Introduction

Vous êtes dans la configuration suivante ?

  • Enterprise Vault 10.0.3 Anglais sur Windows 2008 R2 FR
  • Serveur SQL Server 2012 Français sur Windows 2008 R2 FR

Vous rencontrez des problèmes d’exécution de job SQL, notamment l’erreur 3621 sur le job « EV FSAReporting Daily Job » ? Voici un extrait de l’historique des jobs SQL :

Date                        24/05/2013 15:18:07

Journal                    Historique des travaux (EV FSAReporting Daily Job VSGFSAReport)

ID de l'étape           1

Serveur                   SRV-SQL

Nom du travail       EV FSAReporting Daily Job VSGFSAReport

Nom de l'étape      Start

Durée                      00:00:00

Gravité SQL            16

ID de message SQL 3621

Message

Exécuté en tant qu''utilisateur : Domain\EVSQLService. La conversion d'un type de données varchar en type de données datetime a créé une valeur hors limites. [SQLSTATE 22007] (erreur 242)  L'instruction a été arrêtée. [SQLSTATE 01000] (erreur 3621).  L'étape a échoué.

 

Solution

L’erreur SQL de conversion de type de données est dû à la langue de l’environnement. Enterprise Vault étant installé en anglais sur un serveur SQL en français, celui ci ne comprend pas les formats (date notamment) et retourne donc cette erreur de conversion.

Dans SQL Management Studio, Sécurité, Connexions, éditez les propriétés de l’utilisateur qui exécute le rapport (EVSQLService dans notre cas), changez la langue par défaut de French en English.

Vérification

Relancez le job « EV FSAReporting Daily Job » et observez le résultat dans l’historique des travaux SQL :

Date                        24/05/2013 15:52:10

Journal                    Historique des travaux (EV FSAReporting Daily Job VSGFSAReport)

ID de l'étape           1

Serveur                   SRV-SQL

Nom du travail       EV FSAReporting Daily Job VSGFSAReport

Nom de l'étape      Start

Durée                      00:00:00

Gravité SQL            0

ID de message SQL 0

Message

Exécuté en tant qu''utilisateur : Domain\EVSQLService. L'étape a réussi.

Les rapports vont pouvoir fonctionner correctement maintenant.

Archivage FSA avec Enterprise Vault

Introduction

Lors de l’archivage d’un serveur de fichier avec Enterprise Vault (v10.0.3), on peut rencontrer certains problèmes : Impossible de joindre le serveur, problème de package de sécurité, etc…

Les symptômes :

Sur le serveur EV (Win2008R2), lorsque vous essayez d’afficher les propriétés du serveur de fichiers (ex : Win2003), dans l’onglet version, impossible de récupérer la version de l’agent FSA :

clip_image002

Ou alors, impossible d’exécuter le FSA Reporting Scan manuellement :

clip_image003

Vérifications

Après avoir vérifié les fondamentaux :

  • les noms de serveurs peuvent être résolu des deux côtés et les adresses IP correspondent  à la configuration des serveurs
  • vérification du parefeu
  • le compte de service Enterprise Vault est bien administrateur local du serveur de fichiers

     

    Résolution

    La commande suivante peut vous aider, (à saisir dans une console avec les droits administrateur) sur le serveur EV:

    SETSPN –A RPC/<nom_du_serveur_de_fichiers> <domaine>\<compte_de_service_EV>

    Exemple : SETSPN –A RPC/fileserver mydomain\ev_svc

    Une fois la commande saisi, on récupère bien les informations de l’agent FSA et la communication avec le serveur se fait sans problème. L’incident est résolu.

    clip_image004

  • Contrôle à distance de Sharepoint via Powershell

    Introduction

    L'une des forces de Powershell est de pouvoir administrer des produits directement depuis un poste client sans avoir à installer des outils d'administration. Hormis dans certains cas particuliers comme Exchange Online, il n'est pas non plus nécessaire d'ajouter des modules ou snapin Powershell sur notre ordinateur. Ceux-ci sont déjà présents sur le serveur distant, il est donc possible de les réutiliser. Dans cet article nous verrons le cas de Sharepoint pour lequel j'ai rencontré une petite subtilité.

    Connexion à distance

    Tout d'abord nous allons initier une nouvelle PSSession. Pour rappel, ce sont elles qui nous permettent d'interagir avec un serveur à distance. Elles ont été introduites à partir de Powershell v2.0.

    On commence par stocker les paramètres d'authentification dans une variable.

    $Credential = Get-Credential

    On crée une variable avec le serveur sur lequel on souhaite se connecter

    $Server =  "XXXXXXXXXX"

    On génère une nouvelle PSSession en spécifiant les deux paramètres précédents. Celle-ci est stocké dans une variable car nous allons la réutiliser.

    $Session = New-PSSession –ComputerName $Server -Credential $Credential

    Ensuite, nous allons utiliser, la Cmdlet Invoke-Command afin d'exécuter une commande dans la session distante que nous venons de créer.

    Invoke-Command -ScriptBlock {$ver = $host | select version; if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}; Add-PSSnapin Microsoft.SharePoint.PowerShell;} -Session $Session

    Il est nécessaire de préciser la session sur lequel va être réalisé le bloc de commandes. Un scriptblock est exécuté. Si la version de Powershell est supérieur à 1 alors on positionne l'interpréteur pour réutilisé constamment le même thread. Ceci est une configuration obligatoire si l'on souhaite ajouter le snapin Sharepoint. Nous pouvons le retrouver dans le fichier “sharepoint.ps1” qui est lancé par le Sharepoint Management Shell.

    Enfin nous pouvons importer la session. Avec cette méthode l'intégralité des commandes sera utilisable directement depuis le poste client.

    Import-PSSession $Session -AllowClobber

    Erreur rencontrée

    Lorsque l'on effectue une connexion a distance il se peut que l'on obtienne l'erreur suivante :

    Import-PSSession : L’exécution de la commande Get-Command dans la session à distance a signalé l’erreur suivante: Le traitement de données pour une commande distante
    a échoué avec le message d'erreur suivant: <f:WSManFault xmlns:f="
    http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="3762507597"
    Machine="XXXXXXXXXXXXXXXXXXX"><f:Message><f:ProviderFault provider="microsoft.powershell"
    path="C:\Windows\system32\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> Pour plus d'informations, voir la rubrique d'aide
    about_Remote_Troubleshooting...

    Cette dernière signifie qu'il n'y a pas assez de mémoire disponible pour charger les commandes. En effet, les commandes Sharepoint sont très consommatrice en mémoire. Bien entendu, il existe un paramétrage pour pallier à ce problème.

    Paramétrage serveur

    Afin de corriger cette erreur, il faut augmenter la quantité de mémoire maximum allouée pour un shell distant. Il est recommandé pour Sharepoint de définir cette valeur à 1000 MB.

    Pour réaliser cette étape il suffit de modifier la valeur MaxMemoryPerShellMB via le provider WSMan permetant d'accéder à la configuration des connexions distantes. Par défaut la valeur est à 100 MB.

    Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000

    SCOM 2012 :Mise a jour MP Windows OS

     

    Un management pack majeur, celui des OS Windows serveur, est passé en version 6.0.7026.0.

    Cette mise a jour est disponible sur le lien http://www.microsoft.com/en-us/download/details.aspx?id=9296

    Au menu:

    • Correction d’un bug empêchant parfois la collecte des compteurs de performance Processeur.
    • Ajout des règles de collecte de performance suivante:
    •        - Cluster Shared Volume - Free space / MB           
            - Cluster Shared Volume - Total size / MB           
            - Cluster Shared Volume - Free space / %           
            - Cluster Disk - Total size / MB           
            - Cluster Disk - Free space / MB           
            - Cluster Disk - Free space / %

     

    • Correction d’un bug empêchant la découverte des disques de cluster Windows 2008.
    • Correction d’un bug affichant une mauvaise decription d’alerte pour les moniteurs “Cluster Disk Free Space Percent” et “Cluster Disk Free Space MB” quand le nom du volume du disque de cluster est vide.
    • Ajout d’une règle générant une alerte lorsque les requêtes NTLM vers un serveurs dépasse un certain seuil.
    •  

    SCOM – Erreur lors de l’Installation sur disques clusters

     

    Lors de l’installation du premier serveur de management SCOM et des bases SQL sur un cluster, le popup d’erreur générique suivant peut apparaitre…:

    “Setup is unable to create DB on SQL server_____. PLease make sure that the curret user has permissions to create DB on the SQL Server instance specified.”

    .…et le message d’erreur suivant est susceptible d’être enregistré dans le log OpsMgrSetupWizard.log:

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

    Cannot use file (…)\SCOMINSTALLTESTDB_635031752016683857.mdf' for clustered server. Only formatted files on which the cluster resource of the server has a dependency can be used. Either the disk resource containing the file is not present in the cluster group or the cluster resource of the Sql Server does not have a dependency on it.

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

    Ce message fait référence a un problème documenté dans la KB suivante:

    http://support.microsoft.com/kb/295732/en-us

    En effet il est nécessaire que le/les volumes devant accueillir les bases SQL soient enregistré comme dépendance de la ressource cluster.

    Vous pouvez vérifier les liens de dépendances de la ressource en effectuant un clic-droit sur la ressource SQL dans la console de gestion de cluster et en sélectionnant “Show Dependency Report

    Pour rajouter le/les disques cibles en tant que dépendance de la ressource de cluster:

      • Ouvrez la console de gestion du cluster, faites un clic-droit sur la ressource SQL et sélectionner …Bring this ressource Offline
      • faites un clic-droit sur la ressource SQL Server, puis cliquez sur Propriétés.
      • Cliquez sur l'onglet dépendances . .
      • Cliquez sur Modifier pour ajouter le disque à la liste de dépendances pour cette ressource.
      • faites un clic-droit sur la ressource SQL et sélectionner …Bring this ressource Online
      Relancer l’installation de SCOM.

    Performance Analysis of Logs (PAL) TOOL.

     

    L’analyse de problème de performance d’un serveur, de performance d’une application client/serveur se fait par la mise en place de compteurs de performance.

    L’analyse est souvent fastidieuse, quels compteurs mettre en place? interprétation des résultats? seuils d’alertes? etc..Bref souvent décourageant Fâché.

    CODEPLEX fournit un outil qui permet d’interpréter ces résultats et de fournir un rapport.

    Voici le lien pour le téléchargement et son installation:

    http://pal.codeplex.com/

    L’utilisation est assez simple.

    Mettez en place toute une batterie de compteurs à analyser et collectez les informations pendant un temps donné.

    Lancez l’outils:

    image

    image

    Cliquez sur Next.

    image

    Sélectionnez votre fichier de log, puis cliquez sur Next.

    image

    Dans le menu Déroulant Threshold file title, sélectionnez l’application que vous souhaitez analyser, puis cliquez sur Next.

    image

    Répondez au questionnaire, puis cliquez sur Next.

    image

    Choisissez le temps de l’intervalle d’analyse. Cochez éventuellement “Process all…..”, puis cliquez sur Next.

    image

    Configurez le format de sortie, puis cliquez sur Next.

    image

    Cliquez sur Next.

    image

    Vous pouvez modifier la valeur “Threading” si vous le souhaitez. Cliquez sur Finish.

    L’analyse est cours:

    image

    Et voilà:

    image

    image

    Dans cette analyse aucune “alerte” n’a été détectée, signe de bonne santé du serveur Pouce levé

    Bonne analyse.

    EXCHANGE 2013 – Configurer “AutoReseed'” pour un DAG

    AutoReseed est une fonction qui permet de restaurer rapidement la redondance des bases de données après une défaillance du disque. En cas de défaillance du disque, les copies de bases de données stockées sur celui-ci sont automatiquement réamorcées sur un disque de rechange sur le même serveur de banque d’information.

    La mise en place de cette fonctionnalité repose sur trois points de montage (mount point) ainsi que de disposer de trois disques dur par serveur.

    image

     

    La structure des points de montage permet au répertoire C:\EXDB\DB01 et au répertoire C:\EXVOLS\Volume de présenter les mêmes données.

    En cas de défaillance du disque E, le point de montage C:\EXDB\DB01 sera associé au disque F automatiquement.

    clip_image002

    La Configuration du D.A.G doit être adaptée.

    Les attributs ci-dessous sont à paramétrer:

    AutoDagDatabasesRootFolderPath : configure le chemin qui contient les bases à protéger. C:\EXDB dans notre cas.

    Set-DatabaseAvailabilityGroup DAG-2013 –AutoDagDatabasesRootFolderPath « C:\EXDB »

    AutoDagVolumesRootFolderPath : configure le chemin pour les points de montage des volumes des bases et du volume de « spare ». C:\EXVOLS dans notre cas.

    Set-DatabaseAvailabilityGroup DAG-2013 –AutoDagVolumesRootFolderPath « C:\EXVOLS »

    AutoDagDatabaseCopiesPerVolume: configure le nombre de copie de base par volume.

    Set-DatabaseAvailabilityGroup DAG-2013 –AutoDagDataBaseCopiesPerVolume 1

    clip_image004

    Dans le répertoire EXVOLS créez deux dossiers

    Volume1 sera le point de montage pour la base

    Volume2 sera le point de montage pour le disque de « spare »

    C:\EXVOLS\Volume1

    C:\EXVOLS\Volume2

    Ajoutez les points de montage

    clip_image006

    Cliquez sur Add

    clip_image008

    clip_image010

    Idem pour Volume2 (à réaliser sur le second disque)

    Ce qui donne

    clip_image012

    Mappez le dossier qui contiendra la base de données

    C:\EXDB\DB01 au volume1

    On peut utiliser MountVol.exe

    clip_image014

    Faire un point de montage sur le disque qui contient C:\EXVOLS\Volume1

    clip_image016

    clip_image018

    On voit ce résultat

    clip_image020

    Créez  la structure de la base

    clip_image022

    ATTENTION : la structure doit être rigoureuse, elle doit respecter le nommage de la base.

    Je l’ai subi à mes dépens…..

    clip_image024

    La création des dossiers dans EXDB\DB01 se reflète sur le point de montage EXVOLS\Volume1.

    Créez une base avec une copie passive sur le second serveur du DAG.

    Pour vérifier le mécanisme je vais simuler une défaillance du disque dur on le mettant “offline”

    clip_image026

    Lorsqu’on sélectionne “Volume1” l’accès est en échec.

    clip_image028

    La vérification de l’état de la base montre un statut “FailedAndSuspended”

    clip_image030

    Ne vous attentez pas à voir “AutoRessed” à réagir immédiatement comme la bascule qui a été quasiment immédiat du noeud actif vers le noeud passif, il faut attendre que le process MS Exchange Replication ait contrôlé le statut des bases, process qui s’effectue toutes les 15 mn.

    clip_image032

    On voit donc qu’après ce délai la banque sur le serveur revient en “Healthy”, puis le “ContentIndex” également. La défaillance est donc corrigée.

    clip_image034

    Regardons les évènements dans « Seeding »

    clip_image036

    Vous verrez de nombreux évènements liés au « seeding ».

    clip_image038

    Vérifiez les points de montages :

    Pour rappel, avant :

    clip_image039

    Après le disque « failure »:

    clip_image041

    On constate que le répertoire C:\EXVOLS\DB01 est maintenant monté sur le disque F

    Remplacez le disque défectueux.

    Remarque : le répertoire C:\EXVOLS\Volume1 n’existe plus.

    clip_image043

    Recréez ce dossier

    clip_image045

    Recréez le point de montage

    clip_image047

    clip_image049

    Vérifions avec MOUNTVOL

    clip_image051

    Le disque remplacé devient donc le disque de « SPARE »

    Volume1 reste vide.

    clip_image053

    L’avantage de cette technologie est de réduire les couts concernant la mise en œuvre de technologie RAID, et permet également de ne pas déployer un troisième serveurs pour supporter une troisième copies de base, le volume de « spare » jouant ce rôle.

    Certes dans cet exemple sachant qu’il faut trois disques et que l’on protège qu’une banque, l’intérêt est limité car on préfèrera sans doute mettre en œuvre du RAID.

    L’intérêt économique sera mis en évidence lorsqu’on protègera plusieurs banques.

    SCOM 2012 : impossible d’ajouter des Knowledge

    Si vous essayez de remplir des Knowledge (base de connaissance) dans SCOM 2012, il y a de fortes chances que vous rencontriez le message d’erreur suivant :

    clip_image002

    Failed to launch Microsoft Word. Please make sure Microsoft Word is installed. Here is the error message :
    Could not load file or assembly « Microsoft.Office.Interop.word, Version 11.0.0.0, Culture = Neutral, PublicKeyToken=71e9bce111e9429c or one of its dependencies. The system cannot find the file specified.

    Microsoft propose un contournement non officiel en attendant une mise à jour future qui résoudra ce bug.

    Il est dans un premier temps nécessaire de s’assurer que les prérequis sont précisément remplis, car cette fonctionnalité y est très sensible :

    1. Installer Word 2010 en version x86 uniquement

    2. Installer les VSTOR 2005 (Visual Studio 2005 Tools for Office Second Edition Runtime) (éventuellement en complément d’une version ultérieure, mais cette version 2005 SE est impérative !) http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20479

    3. Rebooter la machine sur laquelle Word et les VSTOR sont installés, même si l’installeur de VSTOR n’a rien demandé.

    Il est maintenant temps de mettre en place le contournement à proprement parler.

    Récupérer le fichier suivant : http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-52-52-89/KnowledgeEditingNewFiles.zip (mis à disposition par l’équipe SCOM sur son blog : http://blogs.technet.com/b/momteam/archive/2012/10/10/how-to-get-knowledge-editing-to-work-in-operations-manager-2012-with-office-2010.aspx ) et le décompresser dans le répertoire X:\Dossier dinstallation\System Center 2012\Operations Manager\Console à la place des fichiers knowledge.dot et Microsoft.EnterpriseManagement.Monitoring.Console.exe.config qui s’y trouvent déjà (vous pouvez renommer les anciens au lieu de les écraser pour conserver une trace des modifications).

    Comme le fichier knowledge.dot de remplacement contient des macro et provient d’internet, il est nécessaire de le déverrouiller (clic droit -> propriétés -> unblock):

    clip_image004

    Il devrait maintenant être possible d’ajouter des knowledge dans SCOM 2012 en utilisant la procédure habituelle.