Le parc informatique d'une organisation

Le parc informatique d'une organisation est un assemblage, parfois hétéroclite de matériels et de logiciels accumulés tout au long des années. On y trouve des :

• matériels différents (téléphones, portables, pc, imprimantes, éléments d'interconnexions, etc.) qui peuvent être de plusieurs générations ;

• logiciels et systèmes d'exploitation variés (Linux, Windows, Mac OS, etc.) ;

• applications utilisées dans différentes versions ;

• niveaux de sécurité disparates.1

De plus, la quantité de matériels et de logiciels à gérer, leur éclatement au sein de l'organisation souvent très étendue dans l'espace, les exigences de performance et de réactivité font que la gestion de parc est devenue un processus global, complet et indispensable. Cette activité de gestion de parc informatique est décrite dans le processus ITIL1 Gestion des configurations.

La gestion du parc informatique recouvre non seulement la fonction d'inventaire de ces éléments mais aussi celles concernant le suivi et l'évolution :

• Gestion de l'emplacement du matériel

• Gestion des partenaires (fabricants, fournisseurs, transporteurs, prestataires...) et des contacts associés

• Gestion des contrats (prêt, location, leasing, assurance, maintenance et prestation)

• Gestion des licences logicielles

• Le télé-déploiement de logiciels

• Gestion financière des éléments d'inventaire (matériel loué ou acheté, amortissement)

• Gestion du cycle de vie de chaque élément

• Gestion des incidents

• Gestion de la documentation informatique (base de connaissance, FAQ, etc.)

• Gestion statistique (nombres d'intervention, coût des consommables, etc.)

• Prévision des besoins (aussi bien matériel, logiciel que de formation en exploitant notamment les résultats statistiques de la gestion de parc)

Cette gestion de parc permet, d'une part, de répondre aux multiples questions quotidiennes posées à l'administrateur réseau (quelles sont les versions de Windows installées et sur quels postes ? Y a t-il des disques durs proches de la saturation ?, Tel matériel est-il bien connecté au commutateur ? A quel endroit se trouve tel élément ? Quelle est la valeur actuelle de tel autre composant ? Quels sont les postes encore sous garantie ?, etc.).

Elle permet, d'autre part, une administration plus globale et à long terme (combien de machines y aura- t-il à renouveler dans 2 ans ? Quels sont les nouveaux besoins ? Quelles formations doit-on planifier ? Quel est le retour sur tel investissement ?, Quel est le coût total de possession – ou TCO – d'un poste ?, etc.).

Le système informatique tisse les liens entre les activités de l'organisation, il importe donc d'en connaître la composition à tout moment.

Actuellement, la tendance des DSI (Direction des Systèmes d'Information) est à l'adoption d'un

référentiel commun de bonnes pratiques quant à ses processus métier.

1ITIL : Information Technology Infrastructure Library - Bibliothèque pour l'infrastructure des technologies de l'information ; ensemble de documents de référence énonçant les bonnes pratiques en matière de gestion des services informatiques. www.itilfrance.com

ITIL (Information Technology Infrastructure Library) est le référentiel de "bonnes pratiques" majoritairement adopté par les DSI ; il couvre essentiellement les métiers de la production informatique et du support.

Un logiciel de gestion de parc incluant notamment une gestion des configurations et l'assistance aux utilisateurs représente l'élément central pour appliquer les recommandations ITIL.

L'objectif de ce TP est de simuler, dans la salle laboratoire réseau, la gestion d'un parc informatique depuis la collecte automatisée d'éléments en passant par la gestion de ces éléments pour terminer par l'assistance aux utilisateurs.

Chaque étudiant dispose d'au minimum :

• un poste physique,

• de serveurs et d'ordinateurs virtuels,

• de logiciels, d'applications et de systèmes d'exploitation variés.

Dans un premier temps, nous allons installer l'application OCSInventory-NG 1 (Open Computer and Software Inventory Next Generation) qui est un outil de collecte automatisée d'éléments d'un parc informatique puis l'application GLPI 2 (gestion Libre de Parc Informatique) qui va nous permettre de gérer le-dit parc.

1 http://www.ocsinventory-ng.org/fr/

2 http://www.glpi-project.org/

Il permet notamment :

• d'automatiser les inventaires des PC connectés sur le réseau ainsi que leurs composants matériels et logiciels ;

• de connaître l'ensemble des équipements du parc informatique (matériels et logiciels) avec mise à jour automatique des éléments inventoriés ;

• de procéder à une gestion minimale du parc ;

• de télé-distribuer des fichiers et des applications (ce que nous ferons plus tard dans l'année dans le cadre du déploiement du contexte Spécibike dans les établissements scolaires).

1. Installation et configuration d'OCSinventory (aide en Annexe 1)

• Vérifiez que le serveur de base de données ainsi que le client MySQL sont installés et opérationnels.

• Vérifiez que le moteur innoDB soit bien actif dans MySQL. Rappeler un des intérêts de ce moteur.

• Vérifiez que le serveur web Apache et php sont installés et opérationnels.

• Expliquez quel est le type d'architecture client/serveur mis en œuvre.

• Installez les services d'OCSinventory nécessaires et procédez à une première configuration assistée.

• Vérifiez sur le serveur MySQL que la base de données a bien été créée ainsi que l'utilisateur "ocs". Quels sont les droits donnés à cet utilisateur ?

• Poursuivez la configuration avec la console d'administration (admin, admin).

• Faîtes en sorte que les remontées d'inventaire aient lieu toutes les heures.

• Créez 2 autres utilisateurs :

o un utilisateur normal ;

o un "utilisateur local" : vous lui affecterez des machines selon le système d'exploitation

: par exemple cet utilisateur ne pourra visualiser que les postes sur lesquels Windows est installé.

Vous testerez une connexion avec chacun de ces nouveaux utilisateurs.

2. Installation et configuration de l'agent (aide en Annexe 2)

• Installez dans un premier temps l'agent sur le serveur ocsinventory-agent pour la collecte d'information propre au serveur lui-même.

• Forcez le premier inventaire (n'hésitez pas à consulter les log en cas de problèmes)

• Installez ensuite les agents sur chaque poste client en forçant le premier inventaire. Pour chaque poste sous Windows, précisez :

o quelle est la valeur de votre variable TTO_WAIT à l'installation et donc dans combien de temps aura lieu le second inventaire ?

o quelle est la valeur de la variable PROLOG_FREQ ?

Redémarrez le service OcsInventory de manière à ce que la variable s'ajuste en fonction de PROLOG_FREQ et précisez la nouvelle valeur de la variable TTO_WAIT.

3. Travail sur l'inventaire (aide en Annexe 3)

• Visualisez l'ensemble des postes inventoriés et le détail de chaque machine.

• Recherchez les postes ayant Microsoft Office et mettez-les dans un groupe dynamique.

• Remontez de la base de registre au moins une clé d'un des applicatifs installé sur un poste Windows et la clé indiquant l'ensemble des processus lancés automatiquement au démarrage de la machine : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

Quel peut être l'intérêt de connaître ces informations ?

• Ajoutez trois informations administratives : date d'achat, date de fin de garantie et la fonction de la machine (client ou serveur).

• Recherchez les machines clientes ayant Windows comme système d'exploitation.

• Dans un environnement professionnel, il est primordial de connaître la localisation du matériel

; même si, dans le cadre de ce TP, cela n'a que peu d'intérêt puisque les postes sont localisés au même endroit, vous allez utiliser le "tag" pour référencer chacune de vos machines dans votre salle de cours (par exemple B316)

OCSInventory travaille dans un environnement web qui fait appel à des scripts php, perl et au SGBD MySQL pour le stockage des informations d'inventaire ; Il est donc nécessaire de disposer d'un serveur Apache2 et du SGBD MySQL 5 avec moteur innoDB opérationnels.

Debian étant installée.

Mise à jour du serveur

# apt-get update

# apt-get upgrade

Installation du serveur Web Apache

# apt-get install apache2

Installation de PHP 5

# apt-get install php5

Installation du serveur de base de données MySQL 5

# apt-get install mysql-server

(lors de l'installation le PWD du compte root est donné au compte administrateur de MySQL).

Installation de PHPMyAdmin

# apt-get install phpmyadmin

Relancer Apache

# /etc/init.d/apache2 reload

Accès à distance au serveur

# apt-get install openssh-server

Installation d'OCS Inventory - NG

# apt-get install ocsinventory-server ocsinventory-reports -t testing

ocsinventory-reports étant l'application d'administration web d'ocsinventory.

Selon ce que vous avez déjà sur votre système, d'autres paquetages seront nécessairement installés.

Tout ce qui suit est basé sur la version 1.02.2-1 du serveur ; si vous installez une version ultérieure, les répertoires et noms de fichier seront peut-être différents ; il faudra dans ce cas adapter certaines commandes.

Les fichiers de configuration de chacune des applications se trouvent dans /etc/ocsinventory

• Le fichier de conf issu du dbconf : /etc/dbconfig-common/ocsinventory-server.conf

• Un répertoire "ocsinventory-server" est créé dans /usr/share et dans /var/lib/

• Un répertoire "ocsreports" est créé dans /usr/share/ocsinventory-server/

• La documentation de chacune des applications se trouve dans /usr/share/doc/

Les logs iront dans le répertoire : /var/log/ocsinventory-server/ mais il faut au préalable les activer en positionnant à "on" la variable "LOGLEVEL" (voir en fin d'annexe).

La configuration pour le serveur WEB : /etc/apache2/conf.d/ocsinventory.conf

Le système debconf de debian propose une aide à la configuration des éléments indispensables à la partie serveur d'OCS. Mais rien ne sera irrémédiable, il est toujours possible de revenir à la configuration assistée par la commande dpkg-reconfigure ocsinventory-reports et dpkg-reconfigure ocsinventory-server comme il sera possible de modifier directement les fichiers de configuration créés.

En fait un utilisateur ocs pour MySQL a été créé.

À l'écran suivant, vous acceptez bien évidemment l'assistance pour configurer la base de données.

À l'écran suivant, on vous demande de saisir le mot de passe de l'utilisateur "root" qui a le privilège de pouvoir créer une base de données dans mysql :

La base de données "ocsweb" avec 51 tables sera créée.

Si tout se passe bien, vous devriez avoir les dernières lignes suivantes en sortie : Creating config file /etc/dbconfig-common/ocsinventory-server.conf with new version

Creating config file /etc/ocsinventory/ocsinventory.conf with new version

granting access to database ocsweb for ocs@localhost: success. verifying access for ocs@localhost: success.

creating database ocsweb: success. verifying database ocsweb exists: success. populating database via sql... done.

dbconfig-common: flushing administrative password

LA CONSOLE D'ADMINISTRATION

La gestion du parc se réalise via la console web d'administration. On accède à cette console avec l'URL suivante : http://nom_serveur/ocsreports/. Par défaut le compte administrateur est admin et le mot de passe admin.

La page d'accueil de l'administration est la suivante :

• Un "clic" sur chaque onglet et sur chaque icône devrait déjà vous donner un aperçu des fonctionnalités.

• Le module "configuration" va permettre, entre autres, de gérer le rythme des remontées d'inventaire.

Le but étant de ne pas trop charger le réseau, il faut éviter :

• de faire des remontées constamment ;

• de faire des remontées systématiques lors de chaque lancement du client ;

• de faire les remontées de tous les clients en même temps

Ce sont les paramètres PROLOG_FREQ (onglet serveur) et FREQUENCY (onglet Inventaire) qui gèrent le rythme des inventaires.

PROLOG_FREQ définit en nombre d’heure la période max entre 2 lancements d'un agent. Cette notion de “période max” permet d'éviter les surcharges si tous les postes remontaient leur inventaire simultanément ; l’agent choisit un temps de manière aléatoire pouvant aller jusqu'à cette période max pour demander au serveur quoi faire – pas nécessairement remonter l’inventaire.

C'est la valeur de la variable FREQUENCY qui va réellement permettre le lancement de l'inventaire.

Toujours inventorié (always) : la remontée sera réalisée sans condition dès que l'agent sollicite le serveur (c'est la valeur par défaut)

Jamais inventorié (never) : aucune remontée ne sera réalisée.

Personnalisé (custom) : définit une fréquence de remontée d'inventaire en nombre de jours : la remontée sera réalisée lors de la sollicitation du client si l'inventaire est plus vieux que le nombre de jours spécifiés dans FREQUENCY.

Exemples :

FREQUENCY = toujours inventorié et PROLOG_FREQ = 24 : toutes les 24 heures au max, je force une remontée qui sera faite à chaque fois

FREQUENCY = 1 et PROLOG_FREQ= 12 : toutes les 12 heures au max, l'agent demande au serveur s'il n'est pas temps de réaliser un inventaire. Celui-ci acceptera si l’inventaire actuel a plus d'un jour.

Pour approfondir les différentes possibilités de configuration : http://wiki.ocsinventory-ng.org/index.php/Documentation:Administration/fr

La collecte automatisée d'informations passe par l'installation sur les postes clients de l'agent ocs ; Il existe un (ou plusieurs) agent(s) pour chaque système d'exploitation.

Nous ne développerons pas la problématique de l'installation automatique de l'agent mais il est évident qu'en production lorsque l'agent doit être installé sur des centaines de postes, la question se pose (voir compléments proposés).

Installation de l'agent sous Linux Debian

#apt-get install ocsinventory-agent

Le système propose une configuration d'ocsinventory-agent. Choisir la méthode "HTTP" qui permet de remonter les informations à un serveur OCS, puis saisir lorsque cela est demandé le nom d'hôte du serveur :

La méthode locale permet la récupération des informations dans un fichier XML (intéressant si le poste ne peut pas se connecter au réseau) puis l'incorporation manuelle dans OCS. "HTTP" est, ici, la méthode qui convient puisque tous les postes peuvent accéder au serveur OCS via le réseau.

Il suffit ensuite de saisir le nom d'hôte du serveur d'inventaire ou son adresse IP.

Un répertoire /var/log/ocsinventory-client destiné à accueillir le fichier de log est également créé.

3 fichiers sont créés :

• Un fichier de configuration "/etc/ocsinventory/ocsinventory-agent.cfg" dans lequel vous trouverez notamment le nom d'hôte (ou l'adresse IP) précisé précédemment.

Exemple de fichier ocsinventory-agent.cfg :

Le "TAG" représente une rapide description de la machine (et permettra des recherches par catégorie) : s'il n'a pas été précisé lors de la configuration de l'agent, il peut être ajouté ou modifié via la console d'administration du serveur.

• Le fichier de rotation des logs : /etc/logrotate.d/ocsinventory-client qui configure la rotation quotidienne des logs de l'agent OCS Inventory NG

• Un script pour l'agent (une tâche cron) : /etc/cron.daily/ocsinventory-agent ; ce script s'exécutera chaque jour à l'heure précisée dans /etc/crontab (6 heures 25 dans l'exemple ci-dessous) :

25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

La première remontée d'inventaire ne se fera qu'à l'heure indiquée et ensuite le rythme des remontées dépendra des valeurs des variables PROLOG_FREQ et FREQUENCY définies dans l'annexe 1.

Pour forcer la remontée d'inventaire une première fois sans attendre le premier déclenchement du cron, il suffit d'exécuter la commande ocsinventory-agent.

En cas de problème (l'inventaire n'apparaît pas par exemple) ou si vous voulez en savoir plus sur la communication entre l'agent et le serveur, la documentation propose la commande suivante : ocsinventory-agent -debug

Théoriquement, cela a pour objectif de forcer l'agent à produire plus de détails dans le fichier log, montrant les échanges XML avec le serveur de communication mais j'ai pour ma part une sortie écran (canal standard) et aucun fichier log créé ou lorsqu'il est créé qui se "remplit".

En attendant mieux, une solution pour conserver la sortie du debug dans un fichier : ocsinventory-agent --debug &> /var/log/ocsinventory-client/ocsinventory-agent.log

Dès lors qu'un premier contact a été établi, des fichiers XML sont créés sur le poste dont :

• root@kubuntuMarie:/var/lib/ocsinventory-agent/http: 172.31.0.3_ocsinventory# ls - al

• total 24

• drwxr-xr-x 3 root root 4096 2012-07-08 01:21 .

• drwxr-xr-x 3 root root 4096 2012-07-08 01:21 ..

• drwxr-xr-x 2 root root 4096 2012-07-08 01:28 download

• -rw-r--r-- 1 root root 835 2012-07-08 01:28 last_state

• -rw-r--r-- 1 root root 0 2012-07-08 02:28 next_timefile

• -rw-r--r-- 1 root root 112 2012-07-08 01:28 ocsinv.adm

• -rw-r--r-- 1 root root 102 2012-07-08 01:21 ocsinv.conf

last_state décrit le dernier inventaire réalisé.

Dans ocsinv.conf, on trouvera les paramètres de configuration générale comme la valeur de la variable PROLOG_FREQ (ce qui veut dire que si cette variable est modifiée sur le serveur OCS, elle ne sera prise en compte par le client qu'après le prochain inventaire). Il est toujours possible de la modifier directement dans le fichier.

ocsinv.adm enregistre les valeurs TAG et autres valeurs administratives Exemple ocsinv.conf :

Exemple ocsinv.adm :

Un clic sur le nom d'une machine permet d'afficher, dans un autre onglet, les détails inventoriés du poste.

Remarque : au niveau du client Linux intégré par défaut sous Debian, il n'y a pas en fait de gestion du PROLOG_FREQ ce qui fait que la fréquence d'inventaire est la fréquence quotidienne défini par le "cron" du départ.

Installation de l'agent sous Windows

Sous Windows, trois agents OCSinventory sont disponibles :

• OcsLogon.exe : cet agent peut être utilisé uniquement sur un domaine Active Directory ou sur Linux via Samba. Il peut être déployé à travers le contrôleur de domaine et par des scripts d'ouverture de session.

• OcsAgent.exe : c'est un fichier exécutable qui permet de générer un fichier *.ocs qu'il faudra par la suite importer manuellement grâce à l'interface d'administration

d'OCSinventory. Cet agent trouve surtout son utilité sur un poste non connecté au réseau.

• OcsAgentSetup.exe : cet agent s'installe sur chaque poste et permet la transmission d'inventaire et également le déploiement d'applications à distance. Une fois installé, le service OCSinventory se lance à chaque démarrage du poste.

Dans le cadre de notre TP, c'est celui que nous utiliserons.

Il est nécessaire de récupérer sur le site d'OCS (http://www.ocsinventory-ng.org/) l'agent Ocs Inventory (onglet "download").

Il suffit ensuite d'extraire l'archive et d'exécuter OcsAgentSetup.exe. Un fichier de log (OcsAgentSetup) rendant compte de l'installation (à consulter en cas de problème ou par curiosité) est créé dans le répertoire où se trouve l'exécutable OcsAgentSetup.exe que l'on vient de lancer.

Après validation de la licence, vous arriverez à l'écran suivant :

Server Adress : adresse IP du serveur de Communication OCS Inventory

Server Port : port du serveur de Communication OCS Inventory (/PNUM:80)

No IE Proxy : pour ne pas utiliser les paramètres du proxy de Microsoft Internet Explorer (/NP)

Enable log file : un fichier de log au nom de la machine est créé dans le répertoire d'installation à chaque remontée d'inventaire (/DEBUG)

Immediatly lauch inventory (=/NOW) : lance une première fois OCS inventory (le premier inventaire est réalisé)

No Ocs_Contact shortcut : n’installe pas la partie ‘Contact’

Miscellaneous : permet de passer, à l'agent, d'autres arguments en ligne de commande. Vous trouverez la liste des arguments et leur signification ici : http://wiki.ocsinventory- ng.org/index.php/Documentation:Agent/fr au paragraphe "L'agent et ses arguments en ligne de commande".

Le répertoire d'installation est, par défaut, "C:\Program Files\OCS Inventory Agent\".

Une fois l'agent installé sur le client, le service OCSinventory est configuré pour être lancé automatiquement en tant que service au démarrage.

Les paramètres de configuration se trouvent dans le fichier C:\Documents and Settings\All Users\Application Data\OCS Inventory NG\Agent\ocsInventory.ini.

La variable TTO_WAIT représente en secondes le nombre d'heures d'attente ; elle est décrémentée de "1" à chaque seconde par le service (le fichier service.ini est ré-écrit toutes les minutes). Lorsqu'elle arrive à "0", l'agent exécute la commande OCSinventory.exe suivi des options contenues dans la variable Miscellaneous : OCSinventory.exe

/server:172.31.0.3/pnum:80 /np /debug qui va générer un fichier "ocsinventory.log" et transmettre la remontée d'inventaire au serveur si l'inventaire est plus vieux que le nombre de jours spécifiés dans la variable FREQUENCY.

Une fois que le service a lancé l'agent, il recalcule de manière aléatoire le TTO_WAIT compris entre 1 et la valeur de PROLOG_FREQ (convertie en secondes) synchronisée avec la variable correspondante sur le serveur OCSinventory.

À chaque installation, le contenu de la variable TTO_WAIT est différent mais inférieur à 36 000 secondes (correspondant à 10 h qui est le contenu par défaut de la variable PROLOG_FREQ).

Pour forcer l'inventaire d'une machine immédiatement, il suffit d'exécuter la commande :

OCSinventory.exe /server:172.31.0.3 /pnum:80 /np /debug Pour forcer l'inventaire d'une machine dans un temps défini :

• Arrêt du service OCS INVENTORY SERVICE

• Édition du fichier ocsinventory.ini

• Affectation d'une faible valeur à TTO_WAIT (30 par exemple).

• Redémarrage du service OCS INVENTORY SERVICE

Ainsi, après 30 secondes le client doit être mis à jour dans l'inventaire.

Une fois les inventaires transmis au serveur par les agents et intégrés à la base de données, l'ensemble des machines peut être visionné.

Des requêtes de restrictions pourront également être effectuées permettant ainsi d'avoir une vue précise et ciblée des éléments informatiques présents dans l'entreprise.

Pour plus de détails sur les éléments inventoriés, vous pouvez consulter la page suivante : http://www.ocsinventory-ng.org/index.php?page=Fonctionnalites

Il suffit de passer la souris sur les icônes de la barre d'outil pour avoir une explication générale.

Les différents menus sont très intuitifs, il est inutile de les détailler ; vous pouvez consulter la documentation ici : http://wiki.ocsinventory-ng.org/index.php/Documentation:Results/fr

ou pour une version plus à jour (mais en anglais) : http://wiki.ocsinventory-ng.org/index.php/Documentation:Results

À noter qu'il est notamment possible de (liste non exhaustive) :

o personnaliser la vue en ajoutant ou supprimant des colonnes, en changeant le nombre de lignes par page à afficher ;

o rechercher selon de multiples critères

o créer des groupes statiques ou dynamiques de machines, le groupe dynamique se mettant à jour automatiquement ; aussi il n'est possible de créer un groupe dynamique que sur la base d'une recherche par critère(s) et toutes les machines trouvées actuelles et futures intègrent automatiquement le groupe. L'intérêt est multiple :

 cela permet d'avoir une vue permanente des machines répondant à un ou plusieurs critères sans avoir à chaque fois à refaire la même recherche (par exemple pour repérer les machines ayant Microsoft Office alors qu'il n'existe pas de licence, rassembler les machines qui vont faire l'objet d'un déploiement, etc) ;

 cela permet d'appliquer une configuration différente à un groupe de machine (par exemple une valeur de PROLOG_FREQ plus forte ou plus faible) ;

Vous trouverez la documentation (en anglais) ici : http://wiki.ocsinventory- ng.org/index.php/Documentation:Groups#Create_a_dynamic_group

o visualiser et "catégoriser" les logiciels présents sur les machines :

cette dernière icône (Dictionnaire) servant notamment pour la gestion des logiciels avec GLPI

o visualiser et gérer les doublons

o ajouter des informations administratives (date de fin de garantie, etc)

o réaliser des requêtes sur le registre ;

Récupération des clés de registre

Une des fonctionnalités intéressantes de la gestion d'un parc est de permettre la gestion des licences logicielles ; pour cela certaines clés de registres (sur les systèmes Windows uniquement) doivent être récupérées.

Par défaut, aucune clef de registre est récupérée par les agents OCSinventory. C'est donc à l'administrateur du service d'inventaire de définir celles qui doivent l'être. Pour ce faire :

• Activer l'option dans la configuration générale (menu configuration, onglet registre, mettre le paramètre à "on").

• Définir les clés avec le menu "registre" dans la barre d'outils en cliquant sur le bouton "Ajouter" :

Soit la clé pour récupérer les instances SQl server installées : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Nom de la clef : InstalledInstances

et celles pour retrouver les processus lancés au démarrage de la machine :

Attention: Vous devez doubler les antislashes dans le chemin de la base de registre pour que votre requête fonctionne (sauf devant SOFTWARE).

...