Outils de collecte SYDI améliorés et collecteur awdit

Le projet SYDI est un projet Open Source destiné à aider les administrateurs réseau à documenter leur réseau. Il utilise une série de fichiers VBScript pour collecter les données système, capturées en XML puis transcodées dans divers autres formats. La page d’accueil du projet contient bien plus d’informations. Nous avons travaillé avec SYDI pour collecter des données pour notre outil de gestion informatique, awdit (actuellement en bêta), et, ce faisant, nous avons rencontré et résolu quelques problèmes dans les scripts SYDI d’origine. Pour rester dans l’esprit de l’ouverture, nous avons réintégré nos modifications dans un fork de SYDI sur GitHub et diffusons librement notre client natif pour un usage personnel et interne en entreprise.

Script de collecte serveur SYDI mis à jour

Les utilisateurs peuvent télécharger le script de collecte serveur SYDI mis à jour ici. Nous avons pris la version 2.3 et y avons intégré une meilleure gestion des dates, ainsi qu’une fonction de téléversement pour envoyer les données à awdit. Nous avons toutefois trouvé une option qui nous convient bien mieux…

Scripts de collecte awdit compatibles SYDI pour x86 et x64

L’outil de collecte awdit pour Windows collecte des données et peut les enregistrer ou les téléverser au format XML de SYDI, un peu comme le script SYDI d’origine. Nos versions binaires natives présentent toutefois les avantages suivants par rapport au VBScript d’origine :

• Collecte de données bien plus rapide et multithread
• Format .exe natif, sécurisé et signé numériquement, plus léger et plus simple à exécuter, avec un binaire x64 facultatif pour un fonctionnement encore plus rapide sur les machines récentes
• Les dates des logiciels installés sont mieux normalisées dans des formats faciles à lire (même si l’on trouve encore beaucoup de variations dans le registre)
• Lorsque le registre ne contient pas de date, nous fournissons une date approximative tirée du fichier installé et faisons précéder la valeur d’un tilde (~) pour indiquer qu’elle est approximative
• La sortie XML est joliment mise en forme
• Plusieurs bizarreries sur les systèmes virtualisés ont été corrigées
• L’architecture de l’application est indiquée dans un nouvel attribut architecture des balises regapplication ou msiapplication
• Les paramètres régionaux et de langue de l’installation sont indiqués dans un nouvel attribut language
• Les clés de produit sont collectées de façon plus fiable
• Arguments simplifiés, qui s’affichent aussi lorsque vous double-cliquez sur le fichier dans l’Explorateur
• Nouveau mode TSR (terminate and stay resident), dans lequel le collecteur peut rester actif et générer automatiquement un nouveau XML à quelques jours d’intervalle, selon la configuration
• Pas de vilains logiciels espions, de malware, de connexions en douce vers nos serveurs, etc.

Aucune des modifications apportées n’a rompu la compatibilité avec les scripts ou le XSLT d’origine ; le nouveau client peut donc être utilisé dans des environnements qui exécutaient auparavant la version VBScript. Dans sa forme la plus simple, vous pouvez utiliser le collecteur awdit pour exporter du XML sur votre machine ainsi :

$ awdit-collector-win-x86.exe --file=my-machine.xml

Téléchargements

N’hésitez pas à nous envoyer vos retours sur ce script – nous serions ravis de les lire !

• Collecteur awdit pour Windows (x86, x64 version 0.61)

Exécuter le collecteur sur un réseau

Il existe plusieurs approches pour exécuter les scripts de collecte awdit ou SYDI sur un réseau. Le mode TSR peut bien fonctionner sur les serveurs, et les utilisateurs avancés peuvent recourir aux stratégies de groupe pour planifier des lancements périodiques de l’outil. Nous partagerons bientôt quelques bonnes pratiques que nous avons apprises. En attendant, nous détaillons ci-dessous ce qui est peut-être l’approche la plus simple. L’outil « Group Policy Editor » peut être utilisé sur un domaine pour forcer tous les clients du domaine à exécuter le fichier de script voulu lors de l’ouverture de session.

1. Ouvrez l’outil « Group Policy Editor » sur votre contrôleur de domaine et chargez votre stratégie de domaine par défaut (ou créez une nouvelle stratégie de domaine si c’est plus approprié)
2. Développez « User Configuration | Windows Settings | Scripts (logon/logoff) » et double-cliquez sur l’option « Logon » dans le volet de droite.
3. Cliquez sur le bouton Add et accédez au fichier run-sydi-network.vbs (ou collez son chemin) dans la zone « Script Name ».