Windows Scripting Host : tutoriel pour débutants

Introduction à Windows Scripting Host

Qu'est-ce que Windows Scripting Host ?

Windows Scripting Host (WSH) est un environnement d'exécution pour scripts sur Windows. Il permet aux administrateurs et ingénieurs d'automatiser des tâches à l'aide de VBScript et JScript (implémentation Microsoft de JavaScript). WSH expose des objets COM (ex: WScript.Shell, Scripting.FileSystemObject, WbemScripting.SWbemLocator) pour interagir avec le système, le registre, WMI, et d'autres composants.

WSH est utile pour :

• Automatiser des tâches répétitives et plans de maintenance.
• Accéder aux objets COM pour contrôler des applications ou des services.
• Intégrer des scripts dans des outils de gestion (Task Scheduler, SCCM).

Exemple minimal en JScript (WSH) :

WScript.Echo('Bonjour, WSH!');

Ce code affiche un message à l'utilisateur via le moteur WSH.

Installation et Configuration de WSH

Étapes d'installation

WSH est inclus dans les versions modernes de Windows. Les vérifications recommandées pour une exécution fiable :

• Vérifier que l'exécution des scripts n'est pas restreinte par des stratégies de sécurité (GPO / AppLocker / Software Restriction Policies).
• Préférer l'exécution en mode console pour le débogage (utiliser cscript.exe).
• Contrôler les autorisations COM/WMI si vos scripts effectuent des actions élevées.

Basculer le moteur par défaut en mode console (ligne de commande) :

cscript //h:cscript

Exécuter vos scripts avec cscript.exe <script.vbs> facilite la sortie texte et l'intégration avec des journaux.

Création de Scripts Simples

Écriture d'un script de base

Un script WSH se crée avec un éditeur de texte. Sauvegardez avec l'extension .vbs (VBScript) ou .js (JScript). Exemple de script VBScript qui crée un fichier texte :

Set objFSO = CreateObject('Scripting.FileSystemObject')
Set objFile = objFSO.CreateTextFile('C:	est.txt', True)
objFile.WriteLine('Bonjour, ceci est un test.')
objFile.Close

Pour l'exécution : cscript.exe C:\chemin\vers\script.vbs. Testez d'abord sur une machine non critique et avec un compte disposant uniquement des droits nécessaires.

Gestion des erreurs dans WSH

La gestion d'erreurs dans les scripts WSH est essentielle pour la fiabilité et la sécurité. En VBScript, on utilise On Error Resume Next combiné à l'objet Err pour capturer et traiter les exceptions à chaque étape critique. En JScript (WSH), préférez les blocs try/catch pour un flux plus structuré.

Bonnes pratiques

• Ne laissez jamais On Error Resume Next actif sans vérifier Err.Number après les appels susceptibles d'échouer.
• Journalisez systématiquement les erreurs (fichier de log, Event Log) avec un code d'erreur et un message lisible.
• Libérez et mettez à Nothing tous les objets COM après usage pour éviter les fuites mémoire.
• Retournez des codes de sortie explicites (WScript.Quit) pour l'orchestration (Task Scheduler, SCCM) afin d'automatiser les réponses aux erreurs.
• Validez en lecture les opérations (ex: test d'existence d'un fichier) avant d'écrire/supprimer.

Exemple VBScript : pattern de gestion d'erreur et logging

On Error Resume Next
Set fso = CreateObject("Scripting.FileSystemObject")
Set log = fso.OpenTextFile("C:	emp\out.log", 8, True)

' Exemple d'opération susceptible d'échouer
Set f = fso.OpenTextFile("C:
onexistent\file.txt", 1)
If Err.Number <> 0 Then
 log.WriteLine "[ERROR] " & Now & " - " & Err.Number & " - " & Err.Description
 Err.Clear
 ' Nettoyage si nécessaire
 On Error GoTo 0
 log.Close
 WScript.Quit 1
End If

log.WriteLine "[INFO] " & Now & " - Operation succeeded"
log.Close
On Error GoTo 0
WScript.Quit 0

Ce modèle permet de capturer l'erreur, d'écrire un log avec un timestamp et de renvoyer un code d'erreur exploitable par l'orchestrateur.

Débogage avancé pour WSH

Au-delà de WScript.Echo et des traces console, il existe plusieurs techniques et outils pratiques pour diagnostiquer des scripts WSH en production ou en développement:

Options de démarrage et flags utiles

• cscript //X — démarre le script et ouvre un débogueur JIT (utile pour attacher Visual Studio ou un débogueur compatible).
• cscript //D — active le mode débogage (permet d'autoriser des interruptions et des points d'arrêt si un débogueur est disponible).

Exemples :

cscript //X C:\scripts\myscript.vbs

Attacher un débogueur (Visual Studio / Script Debugger)

Vous pouvez attacher Visual Studio (versions récentes : 2019, 2022) au processus wscript.exe ou cscript.exe pour déboguer le code VBScript/JScript : utilisez Debug → Attach to Process et sélectionnez wscript.exe. Lancer cscript //X forcera l'arrêt au démarrage et facilitera l'investigation.

Journalisation vers l'Event Log et collecte centralisée

Plutôt que d'écrire uniquement des fichiers texte, utilisez WScript.Shell.LogEvent pour consigner des événements dans le journal Windows (Event Viewer). Ces événements peuvent ensuite être collectés par un SIEM (Splunk, Elastic, Azure Sentinel) pour corrélation et alerting.

Set WshShell = CreateObject("WScript.Shell")
' 1 = warning, 2 = error, 0 = informational (vérifiez la valeur selon votre environnement)
WshShell.LogEvent 0, "MonScript: opération démarrée"
On Error Resume Next
' ... opérations ...
If Err.Number <> 0 Then
 WshShell.LogEvent 2, "MonScript: erreur " & Err.Number & " - " & Err.Description
End If

Outils complémentaires

• Sysinternals DebugView (outil Sysinternals) — utile pour capturer des traces de débogage au niveau système lors de tests.
• Event Viewer / Winlogbeat (pour envoi vers Elastic) ou forwarders SIEM pour centraliser les logs.
• Si vous disposez d'un environnement contrôlé, activez l'audit et réglez la journalisation avancée via GPO pour tracer les exécutions de scripts.

Ces techniques permettent d'obtenir des traces structurées, d'émettre des événements exploitables et de réduire le temps moyen de résolution (MTTR).

Manipulation des Fichiers et Dossiers

Introduction aux Opérations de Fichiers

Le FileSystemObject (FSO) est l'API courante depuis WSH pour créer, lire, écrire et supprimer des fichiers. Gérez systématiquement les erreurs et les autorisations :

• Utilisez des chemins absolus pour éviter les erreurs de contexte.
• Vérifiez les droits d'accès avant d'écrire/supprimer.
• Loggez les actions (fichiers de log ou Event Log) pour audit et dépannage.

Exemple PowerShell (pour comparaison/opérations d'administration modernes) :

Set-Content -Path 'C:	emp\monfichier.txt' -Value 'Bonjour, monde!'

Remarque : PowerShell est souvent préférable pour les tâches modernes ; utilisez WSH quand vous devez maintenir des scripts hérités ou interagir avec hôtes qui n'ont pas PowerShell installé.

Automatisation des Tâches Courantes

Exemples pratiques

WSH peut automatiser : sauvegardes simples, nettoyage, rotations de logs, notifications et actions conditionnelles. Planifiez via le Planificateur de tâches Windows ou déployez via un outil de gestion.

Exemple PowerShell pour supprimer des fichiers modifiés il y a plus de 30 jours :

Get-ChildItem 'C:	emp' | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-30) } | Remove-Item

Pour les environnements d'entreprise, combinez WSH avec la planification et la journalisation centralisée :

• Planifier via Task Scheduler (déclencheurs, comptes de service dédiés).
• Déployer des scripts via SCCM ou équivalent (voir section d'intégration).
• Notifier via e-mail ou API REST après exécution.

PowerShell vs WSH : Quand choisir ?

Au-delà de la simple remarque que "PowerShell est souvent préférable", voici des critères pratiques pour choisir :

• Manipulation d'objets complexes — PowerShell expose et manipule des objets .NET et des commandes modulaires (cmdlets) : idéal pour AD avancé, configuration système et pipelines d'objets.
• APIs REST et JSON — PowerShell (Invoke-RestMethod / Invoke-WebRequest) gère nativement JSON et HTTP, avec gestion d'erreurs plus robuste et options d'authentification modernes.
• Remoting et orchestration — PowerShell Remoting, DSC et modules (ex: Microsoft.Graph, ActiveDirectory) facilitent les tâches à grande échelle.
• Écosystème et cross-platform — PowerShell 7+ est cross-platform et dispose d'une galerie de modules pour étendre les fonctionnalités.
• Gestion des erreurs — try/catch/finally en PowerShell offre un contrôle d'erreur plus fin que le modèle VBScript historique.
• Interopérabilité — pour interagir avec des composants COM simples ou pour maintenir des scripts hérités, WSH reste valide et léger.

Scénarios concrets :

• Continuez à utiliser WSH pour des scripts très légers déployés sur des hôtes anciens où PowerShell n'est pas disponible.
• Choisissez PowerShell pour des workflows modernes : intégration cloud, API REST, gestion d'objets, et déploiement à grande échelle.

Exemple PowerShell : appel API avec gestion d'erreur

try {
 $body = @{ short_description = 'Script alert'; description = 'Automated notification from script' }
 $response = Invoke-RestMethod -Uri "https://example.com/api" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json" -ErrorAction Stop
 Write-Output "OK: $($response)"
} catch {
 Write-Error "API call failed: $($_.Exception.Message)"
 exit 1
}

En pratique, pour de nouveaux développements, privilégiez PowerShell (version 7+) ; pour la maintenance d'artefacts historiques et l'interop avec certains environnements, WSH reste pertinent.

Bonnes pratiques de sécurité pour WSH

Les scripts sont un vecteur d'attaque potentiel s'ils sont mal gérés. Voici des pratiques techniques et concrètes pour renforcer la sécurité de vos scripts WSH en production.

Principes clés

• Principe du moindre privilège : exécutez les scripts avec des comptes de service limités et attribuez uniquement les droits nécessaires (pas d'élévation globale).
• Stockage des secrets : ne stockez jamais de mots de passe en clair dans les scripts. Utilisez le Windows Credential Manager, un coffre sécurisé (ex: Azure Key Vault) ou un gestionnaire de secrets d'entreprise. Préférez des comptes de service avec tokens rotatifs.
• Contrôle d'exécution : utilisez AppLocker ou Software Restriction Policies pour autoriser uniquement les scripts signés ou provenant d'emplacements approuvés.
• Signature et intégrité : signez vos éléments déployés (utilisez Signtool fourni par le Windows SDK) et vérifiez la signature côté client avant exécution si possible.
• Audit et traçabilité : journalisez who/when/what pour chaque action modifiant l'infrastructure. Envoyez les logs vers un collecteur central (SIEM) et conservez les traces d'exécution.
• Revue et test : soumettez les scripts à revue de sécurité et tests d'acceptation en environnement isolé avant déploiement.

Mesures opérationnelles concrètes

• Utilisez des comptes de service gérés (gMSA) pour automatisation AD/SCCM — cela évite la gestion de mots de passe en clair.
• Préférez les jetons à durée limitée et les identités managées pour accéder aux coffres (Azure Managed Identity) lorsque vous interagissez avec des API cloud.
• Chiffrez les fichiers contenant des données sensibles (EFS ou outils de chiffrement) et limitez l'accès aux répertoires de scripts via ACLs.
• Limitez l'utilisation d'objets COM sensibles et contrôlez les permissions WMI/COM via GPO et ACLs.
• Mettez en place des alertes SIEM pour exécutions inhabituelles (scripts lancés en dehors des plages horaires attendues, exécutions par des comptes non autorisés).

Exemples rapides

Signature numérique (processus général) :

• Générez un certificat d'entreprise (CA interne) ou achetez un certificat Code Signing.
• Utilisez signtool sign /fd SHA256 /a /f MyCert.pfx <script_or_package> pour signer vos artefacts avant distribution.
• Appliquez une politique AppLocker pour n'autoriser que les scripts signés par le certificat approuvé.

Accès aux secrets : préférez un coffre (ex: KeyVault) et récupérez au runtime via une identité managée plutôt que d'inclure un token dans le script.

Intégration SCCM & Systèmes de ticketing

Déploiement et intégration

WSH peut être intégré dans des chaînes d'outils d'exploitation : SCCM (Configuration Manager) pour le déploiement, ou un système de tickets (Service Desk) pour créer des incidents/notifications. Les scénarios courants :

• Déclencher un paquet ou une application via SCCM (WMI / SMS Provider).
• Créer automatiquement un ticket via une API REST quand une condition critique est détectée.
• Orchestrer des actions (nettoyage puis envoi d'un rapport dans le ticket).

Exemple : lecture d'objets SCCM via WMI (VBScript)

Remplacez SITE_CODE par votre code de site SCCM. Testez uniquement avec un compte ayant accès au fournisseur SMS.

Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objSWbemServices = objSWbemLocator.ConnectServer(".", "root\\SMS\\site_SITE_CODE")
Set colCollections = objSWbemServices.ExecQuery("SELECT Name, CollectionID FROM SMS_Collection")
For Each objCol in colCollections
 WScript.Echo objCol.CollectionID & " - " & objCol.Name
Next

Exemple : créer un ticket via REST (JScript / WSH)

Modifiez l'URL et les en-têtes selon votre plateforme ticketing. Utilisez un compte API/token stocké dans un coffre sécurisé (ne pas embarquer les identifiants directement dans le script).

var http = new ActiveXObject("MSXML2.ServerXMLHTTP");
var url = "https://YOUR_TICKETING_ENDPOINT/api/tickets";
http.open("POST", url, false);
http.setRequestHeader("Content-Type", "application/json");
http.setRequestHeader("Authorization", "Bearer YOUR_API_TOKEN");
var body = JSON.stringify({ short_description: "Script alert", description: "Automated notification from WSH script." });
http.send(body);
WScript.Echo("Status: " + http.status);

Sécurité : stockez les jetons de façon sécurisée (Vault/KeyVault) et n'exposez pas d'identifiants en clair. Limitez le scope des comptes utilisés pour ces intégrations.

Cas réels & Études de cas

Pour mieux appréhender l'utilisation de WSH en entreprise, voici deux études de cas réelles, décrites pas à pas, avec les outils et recommandations opérationnelles.

Cas 1 — Processus d'offboarding automatisé (utilisateur)

Objectif : lorsqu'un employé quitte l'organisation, automatiser les étapes suivantes : désactiver le compte AD, archiver le répertoire personnel, révoquer les accès aux applications et créer un ticket dans l'ITSM.

Composants techniques : WSH (VBScript) exécuté via Task Scheduler déclenché par SCCM, utilisation de gMSA pour les droits AD, stockage temporaire des artefacts sur un partage sécurisé, création de ticket via API (ex: ServiceNow) avec token stocké dans Azure Key Vault.

1. Étape 1 — Vérification en lecture seule : le script ADSI vérifie l'existence du compte et récupère les groupes.
2. Étape 2 — Archivage : copie du home directory vers un archive share chiffré (EFS ou stockage chiffré côté serveur).
3. Étape 3 — Désactivation AD : modification d'attributs (AccountDisabled, expiration) en utilisant un compte gMSA.
4. Étape 4 — Notifier et créer un ticket via l'API ITSM — token récupéré au runtime depuis Key Vault via une identité managée.
5. Étape 5 — Journalisation : tous les pas consignés dans l'Event Log et forwardés au SIEM pour audit.

Avantages : reproductibilité, traçabilité (who/when/what), suppression des étapes manuelles. Tests recommandés : simulation en lecture seule, tests sur OU de pré-production, revue de sécurité.

Cas 2 — Rotation et centralisation des logs pour conformité

Objectif : faire tourner les fichiers logs sur des serveurs legacy, compresser, chiffrer et pousser vers un collector central.

Composants techniques : WSH pour la collecte locale, tâche planifiée Windows, usage de 7-Zip en ligne de commande (si installé) pour compaction, signature et envoi via API REST ou SMB vers un collector, et notification en cas d'échec.

• Étapes clés : checklist de pré-vérifications, rotation (fichiers > X Mo), compression + chiffrement, transfert sécurisé, suppression locale conforme à la politique.
• Recommandation : vérifier les dépendances (outil de compression, droits écriture), journaliser chaque étape et utiliser des codes de retour explicites pour l'orchestrateur.

Ces cas montrent comment WSH peut jouer le rôle d'"intégrateur" léger entre composants hérités et plateformes modernes (SIEM, Vault, ITSM) — idéal lorsque PowerShell ou agents modernes ne sont pas possibles.

Exemples Avancés Active Directory

Ajouter un utilisateur via ADSI (VBScript)

Exemple pour créer un compte utilisateur dans l'OU spécifiée. Testez dans un environnement de pré-production avant tout déploiement.

Set objOU = GetObject("LDAP://OU=Users,DC=example,DC=local")
Set objUser = objOU.Create("user", "CN=jsmith")
objUser.Put "sAMAccountName", "jsmith"
objUser.SetInfo
WScript.Echo "Utilisateur créé : jsmith"

Ajouter un utilisateur à un groupe

Set objGroup = GetObject("LDAP://CN=Domain Users,CN=Users,DC=example,DC=local")
objGroup.Add "LDAP://CN=jsmith,OU=Users,DC=example,DC=local"
WScript.Echo "Ajouté au groupe"

Désactiver un compte utilisateur

Set objUser = GetObject("LDAP://CN=jsmith,OU=Users,DC=example,DC=local")
objUser.AccountDisabled = True
objUser.SetInfo
WScript.Echo "Compte désactivé"

Bonnes pratiques AD :

• Exécuter les scripts AD avec un compte de service minimal et enregistré.
• Valider toutes les actions en lecture avant d'écrire (simuler en lecture seule).
• Journaliser les modifications (who/when/what) pour audit et traçabilité.

Diagramme d'Architecture

Dépannage et Ressources Utiles

Résolution des Problèmes Courants

Erreurs fréquentes et actions de dépannage :

• Permission denied — Vérifiez les droits du compte exécutant le script ; exécutez en tant qu'administrateur uniquement si nécessaire.
• Fichier introuvable — Utilisez des chemins absolus et vérifiez l'existence des répertoires.
• Erreur WMI / WSH — Exécutez une requête WMI simple et vérifiez la connectivité réseau/permissions.
• Problèmes AD — Testez les opérations ADSI en lecture avant écriture et journalisez chaque étape.

Exemple PowerShell de vérification d'existence d'un fichier (diagnostic) :

If (Test-Path "C:\chemin\vers\fichier.txt") { Write-Host "Le fichier existe." } Else { Write-Host "Le fichier n'existe pas." }

Ressources recommandées

• Microsoft Docs — documentation officielle et guides (recherchez "Windows Scripting Host").
• Stack Overflow — questions et solutions communautaires.
• LinkedIn — groupes professionnels et partages d'expérience.