La disparition progressive de VBScript arrive dans Windows Server et Windows 11. Voici un guide concret pour comprendre le calendrier, mesurer l’impact sur vos fermes et bâtir un plan de migration robuste vers PowerShell, JavaScript et .NET, sans interruption de service.
Contexte et versions concernées
VBScript (Visual Basic Scripting Edition) est en fin de vie sur l’écosystème Windows. Microsoft a confirmé une trajectoire en plusieurs étapes : le moteur reste présent tant que les versions actuelles de Windows Client et Windows Server demeurent sous support, mais il n’y aura plus d’évolutions fonctionnelles. Avec Windows 11 24H2 et Windows Server 2025, VBScript bascule dans le modèle Feature on Demand (FOD) : la fonctionnalité est pré‑installée et encore activée par défaut au lancement de cette phase. À terme, la FOD sera désactivée par défaut, puis le moteur sera retiré des nouvelles versions du système.
Concrètement, cela signifie que vos scripts .vbs, pages Classic ASP utilisant VBScript et automatisations WSH continueront à fonctionner sur les versions sous support tant que la FOD reste active. En revanche, dès que la FOD sera livrée désactivée par défaut, puis surtout lorsque le moteur sera supprimé, toute dépendance non migrée deviendra un point de défaillance à la mise à niveau (OS upgrade, renouvellement d’image, re‑déploiement en IaaS, etc.).
| Famille / version | Statut VBScript | Remarques |
|---|---|---|
| Windows Server 2008/2008 R2 | Présent tant que l’OS est sous support étendu | Pas d’évolutions. Éviter tout nouvel investissement sur VBScript. |
| Windows Server 2012/2012 R2 | Présent tant que l’OS est sous support | Préparer une sortie accélérée compte tenu des calendriers de fin de support. |
| Windows Server 2016 | Présent | Stabilité à court terme, mais planifier la migration dès maintenant. |
| Windows Server 2019 | Présent | Risque de régression à l’upgrade si la FOD est désactivée par défaut. |
| Windows Server 2022 | Présent | Étape idéale pour assainir et migrer avant Windows Server 2025+. |
| Windows 11 24H2 / Windows Server 2025 | VBScript en FOD activée par défaut (début de la phase 1) | Fenêtre de transition : inventorier, tester la désactivation, réécrire. |
Calendrier officiel de retrait
Microsoft met en œuvre la dépréciation de VBScript en trois phases. Les fenêtres temporelles ci‑dessous sont estimées ; les jalons précis seront annoncés via les canaux officiels (Windows IT Pro Blog, Microsoft Learn).
| Phase | Fenêtre estimée | Comportement du système | Actions recommandées IT |
|---|---|---|---|
| Phase 1 | 2ᵉ semestre 2024 → ~2026‑2027 | VBScript devient une FOD, activée par défaut (pré‑installée). | Inventorier les dépendances ; créer un labo ; tester la désactivation pour mesurer l’impact ; commencer les réécritures. |
| Phase 2 | ~2026‑2027 | La FOD est désactivée par défaut (l’admin peut la réactiver). | Bloquer l’arrivée d’images où la FOD est off ; documenter l’exception ; finaliser les migrations applicatives. |
| Phase 3 | Après 2027 (date à confirmer) | Le moteur VBScript (DLL) est supprimé des nouvelles versions. | Proscrire VBScript ; valider que tout le parc est PowerShell/JS/.NET ; supprimer les reliquats techniques. |
Conséquences pratiques pour les serveurs
- Compatibilité à court terme : tant que la FOD reste activée, les scripts
.vbs, les pages Classic ASP basées sur VBScript et les automatisations WSH (viawscript.exe/cscript.exe) continuent de s’exécuter. - Risque à l’upgrade : en phase 2, les nouvelles images ou mises à jour de fonctionnalités peuvent casser silencieusement les dépendances si la FOD n’est pas réactivée explicitement dans vos pipelines (MDT/SCCM/Intune/Golden Image).
- Rupture nette à long terme : en phase 3, toute application reposant sur VBScript cessera de fonctionner sur les nouveaux OS. Les régressions seront immédiates (erreurs 500 IIS côté Classic ASP, tâches planifiées en échec, outils d’admin personnalisés figés).
- Postes et RDS : le même calendrier affecte les environnements VDI/RDS. Les fermes Remote Desktop hébergeant des applications Classic ASP ou des scripts admins devront être assainies.
- Navigateur : le mode IE d’Edge n’exécute pas VBScript côté client ; les éventuels restes de scripts VBScript en front doivent être réécrits en JavaScript.
Cartographie des risques par typologie
| Typologie | Symptômes typiques | Impact | Mesure mitigatrice |
|---|---|---|---|
Scripts d’exploitation (.vbs) | Tâches planifiées qui appellent cscript.exe / wscript.exe | Échec silencieux ou codes retour non traités | Réécriture PowerShell ; enveloppe de compatibilité temporaire |
| Classic ASP (IIS) | 500/500.100 sur pages .asp, erreurs d’Active Scripting | Indisponibilité service | Passage à JScript (temporaire) ou à ASP.NET /.NET 8+ |
| VBA appelant VBScript (COM) | Appels CreateObject("VBScript.RegExp") qui échouent | Macros Office en panne | Substitution par librairies natives .NET/JS/PowerShell |
| Installateurs MSI | Custom Actions de type VBScript | Install/repair cassés | Repackaging MSI ; refonte des CA en DLL ou PowerShell |
Plan de migration recommandé
Inventaire — trouver ce qui casse avant que ça casse
Votre objectif est double : recenser les artefacts VBScript et qualifier leur criticité. Combinez recherche de fichiers, analyse de code et inspection de la configuration système.
- Recherche de fichiers : repérer
*.vbs,*.aspdans les partages, répertoires d’applications, répertoires NETLOGON et profils itinérants. - Recherche dans le code : scanner les patterns
CreateObject("…"),GetObject("…"),RegExp,FileSystemObject. - Tâches planifiées : identifier les actions invoquant
wscript.exe/cscript.exeou des fichiers.vbs. - IIS : lister les sites/virtual dirs
.asp(Classic ASP) et le langage script configuré. - GPO & logon scripts : analyser les rapports GPO pour détecter les scripts de connexion/déconnexion/ordinateur au format VBScript.
- Installateurs : identifier les MSI qui utilisent des Custom Actions VBScript.
Exemples de scripts PowerShell d’inventaire
Lister les fichiers :
$roots = @("C:\Apps", "D:\Data", "\\serveur\partage")
$patterns = @("*.vbs","*.asp")
$files = foreach ($root in $roots) {
foreach ($pattern in $patterns) {
Get-ChildItem -Path $root -Filter $pattern -Recurse -File -ErrorAction SilentlyContinue |
Select-Object FullName, Length, LastWriteTime
}
}
$files | Sort-Object FullName | Export-Csv .\inventaire-vbscript.csv -NoTypeInformation -Encoding UTF8
Extraire les ProgID COM utilisés :
$codeFiles = $files | Where-Object { $_.FullName -match '\.(vbs|asp)$' } | Select-Object -ExpandProperty FullName
$matches = Select-String -Path $codeFiles -Pattern 'CreateObject\("([^"]+)"\)' -AllMatches -Encoding Default
$usage = foreach ($m in $matches) {
foreach ($mm in $m.Matches) {
[PSCustomObject]@{ Path = $m.Path; ProgID = $mm.Groups[1].Value }
}
}
$usage | Group-Object ProgID | Sort-Object Count -Descending |
Select-Object Name, Count | Export-Csv .\progids-vbscript.csv -NoTypeInformation -Encoding UTF8
Repérer les tâches planifiées qui appellent VBScript :
Get-ScheduledTask | ForEach-Object {
$a = $_.Actions
if ($a) {
$hit = $false
foreach ($act in $a) {
if ($act.Execute -match '(?i)\\(wscript|cscript)\.exe' -or $act.Arguments -match '(?i)\.vbs') { $hit = $true }
}
if ($hit) { $_ }
}
} | Select-Object TaskName, TaskPath | Format-Table -Auto
Analyser les GPO (rapport XML) :
Import-Module GroupPolicy
$report = ".\gpo-report.xml"
Get-GPOReport -All -ReportType Xml -Path $report
[xml]$xml = Get-Content $report
$nodes = $xml.GPOList.GPO | Where-Object { $_.InnerXml -match '(?i)(\.vbs|wscript\.exe|cscript\.exe)' }
$nodes | Select-Object DisplayName, Id | Format-Table -Auto
Tests rapides — désactiver pour apprendre
Dans un environnement de labo cloné de la prod, désactivez la FOD VBScript puis exécutez votre campagne de tests réels : démarrage de services, jobs planifiés, scénarios utilisateurs, parcours IIS, tâches de maintenance, pipelines de déploiement.
- But : mesurer la casse réelle, collecter les logs d’erreurs, établir une matrice de criticité (SLA, volumétrie, fenêtres de batch, conformité).
- Garde‑fous : take snapshot ; journaliser les erreurs ; rétablir la FOD si la prod est impactée.
Indications d’automatisation (à adapter selon le nom effectif de la FOD VBScript) :
# Vérifier la capacité/feature côté OS
Get-WindowsCapability -Online | Where-Object Name -match 'VBScript'
# Exemple de désinstallation (ajustez le nom exact si nécessaire)
# Remove-WindowsCapability -Online -Name 'VBScript~~~~0.0.1.0'
En complément, un test de sanity peut tenter d’instancier un objet COM connu :
try {
$null = New-Object -ComObject 'VBScript.RegExp'
Write-Host 'VBScript: présent et activé'
} catch {
Write-Warning 'VBScript indisponible (désactivé ou retiré)'
}
Réécriture / remplacement — orientations concrètes
Automatisation d’administration : réécrire en PowerShell (idéalement PowerShell 7 Core pour la portabilité). Les opérations système classiques (fichiers, registre, WMI/CIM, réseau, WinRM) disposent d’équivalents natifs.
Classic ASP : deux voies : (1) basculer le langage des pages vers JScript/JavaScript comme mesure transitoire ; (2) refondre vers ASP.NET / .NET 8+ (IIS, Kestrel + reverse proxy). La voie (2) est la cible recommandée pour la maintenabilité, la sécurité et les performances.
Front web / scripts IE hérités : migrer en JavaScript moderne ; Edge IE mode n’exécute pas VBScript côté client.
VBA : remplacer CreateObject("VBScript.RegExp") et autres dépendances par des bibliothèques natives ou des API modernes (Expressions régulières .NET, appels HTTP via WinHTTP/Graph/REST, etc.).
Gouvernance & sécurité — figer la ligne
- Interdire VBScript dans les nouveaux développements (critères d’acceptation, revues de code, modèles de projet).
- Conformité : ajouter un contrôle continu sur la FOD VBScript (présence/état) dans vos rapports de conformité (CIS, ISO 27001, ITGC).
- Durcissement : si possible, bloquer
wscript.exe/cscript.exevia AppLocker/WDAC en dehors d’OU contrôlées ; suivre les exceptions. - Formation : accélérer la montée en compétence PowerShell et .NET, mettre à disposition des squelettes de scripts et des modules communs.
Veille — où surveiller
Suivre les annonces officielles : Windows IT Pro Blog (chronologie de la dépréciation et prochaines étapes), contenus Microsoft Learn (liste des fonctionnalités supprimées/dépréciées), et billets Microsoft 365 Dev sur la préparation des projets VBA à la disparition de VBScript.
Tableaux d’équivalences VBScript → PowerShell/.NET
Automatisation et COM
| Dépendance VBScript | Usage courant | Remplacement PowerShell / .NET | Notes |
|---|---|---|---|
Scripting.FileSystemObject | Parcours/lecture/écriture de fichiers | Cmdlets PowerShell (Get-ChildItem, Get-Content, Set-Content, New-Item) | Gérer l’encodage (UTF‑8) et les chemins UNC à grande profondeur. |
WScript.Shell | Lancer des processus, manipuler le registre | Start-Process, Get-ItemProperty/Set-ItemProperty, New-Item | Capturer les codes retour et redirections de flux. |
VBScript.RegExp | Expressions régulières | .NET [regex], méthodes Match/Replace | Attention aux différences d’options (multilignes, culture). |
ADODB.Connection | Accès base de données (OLE DB/ODBC) | .NET System.Data.Odbc/OleDb, orms .NET | Centraliser les chaînes de connexion ; éviter le SQL inline. |
CDO.Message | Envoi d’e‑mails | .NET System.Net.Mail ou API Graph/SMTP authentifié | Éviter les relais anonymes ; journaliser les envois. |
WMI via GetObject("winmgmts:") | Inventaire/ops machines | Cmdlets CIM (Get-CimInstance, Invoke-CimMethod) | Privilégier WS‑Man et schémas CIM. |
Classic ASP
| Pattern VBScript | Migration transitoire | Cible recommandée | Conseils |
|---|---|---|---|
<% Dim obj:Set obj=Server.CreateObject("ADODB.Connection") %> | JScript avec ADO (temporaire) | ASP.NET Core + ORM (.NET 8+) | Isoler la DAL, tests d’intégration, gestion des pools. |
| RegExp, FSO, CDO | JScript natif | Services .NET et API REST | Externaliser la logique métier hors des pages. |
Templates .asp denses | Refactorisation par modules | MVC/Razor Pages/Minimal APIs | Strangler pattern pour migrer par périmètre. |
Exemples de réécriture
De VBScript (FSO) à PowerShell
VBScript d’origine (liste des fichiers et écriture d’un log) :
' list.vbs
Dim fso, log, folder, file
Set fso = CreateObject("Scripting.FileSystemObject")
Set log = fso.CreateTextFile("C:\temp\files.txt", True)
Set folder = fso.GetFolder("C:\Data")
For Each file In folder.Files
log.WriteLine file.Path & ";" & file.Size
Next
log.Close
PowerShell équivalent (UTF‑8, plus robuste) :
$items = Get-ChildItem -Path 'C:\Data' -File -Recurse -ErrorAction SilentlyContinue |
Select-Object FullName, Length
$csv = $items | ConvertTo-Csv -NoTypeInformation
[IO.File]::WriteAllLines('C:\temp\files.csv', $csv, [Text.UTF8Encoding]::new($false))
Expressions régulières
VBScript :
Dim re: Set re = CreateObject("VBScript.RegExp")
re.Global = True: re.Pattern = "\bSRV-\d+\b"
WScript.Echo re.Replace("SRV-123 et SRV-456", "SERVER")
PowerShell/.NET :
[regex]::Replace("SRV-123 et SRV-456", '\bSRV-\d+\b', 'SERVER')
Contrôles d’état et pipelines CI/CD
Intégrez des gates dans vos chaînes de build/patching :
- Détection FOD : un job PowerShell échoue si VBScript est requis par une application marquée « legacy ».
- Rapports : export CSV/JSON des dépendances vers votre CMDB (nom du serveur, application, fichier, propriétaire, criticité).
- Tests E2E : Pester pour vos scripts et parcours IIS (statuts HTTP, chaînes attendues).
# Exemple de test Pester minimal
Describe "Compatibilité VBScript" {
It "Ne dépend pas de vbscript.dll" {
$req = Get-Content .\dependencies.json | ConvertFrom-Json
($req.UsesVBScript -eq $false) | Should -BeTrue
}
}
Gestion des exceptions et trajectoire de sortie
Il arrive qu’une application métier ne puisse pas être réécrite immédiatement. Dans ce cas :
- Documenter l’exception (portée, durée, risques, plan de sortie).
- Isoler l’exécution sur des hôtes dédiés/segmentés (VDI, RDS) avec contrôle d’accès strict.
- Surveiller les indicateurs (tentatives d’exécution VBScript, erreurs IIS Classic ASP, taux d’échec de jobs).
- Planifier la migration incrémentale (strangler pattern, façade REST, réécriture par modules).
Checklist opérationnelle
- Vous avez inventorié tous les
.vbs/.aspet référencementsCreateObject(code, GPO, MSI, tâches, scripts de logon) ? - Vous avez testé un build d’image serveur avec la FOD VBScript désactivée ?
- Vous avez classé les dépendances par criticité (SLA, compliance, sécurité) ?
- Vous avez planifié la réécriture (PowerShell, JS, .NET) et défini des jalons ?
- Vous avez outillé vos pipelines pour empêcher le déploiement d’hôtes non conformes ?
- Vous avez formé les équipes à PowerShell/DevOps et mis à disposition des modèles ?
- Vous avez défini une politique de sécurité pour
wscript.exe/cscript.exe(AppLocker/WDAC) ?
Questions fréquentes
Peut‑on « re‑cocher » la FOD quand elle sera désactivée par défaut ?
Oui, dans la phase 2 la FOD peut être réactivée par les administrateurs si Microsoft maintient ce mécanisme. Mais cela doit rester temporaire : la phase 3 supprimera le moteur, rendant la réactivation impossible.
Quid des composants COM écrits en VB6 ?
VB6 et VBScript sont distincts : un composant COM compilé en VB6 peut rester exploitable s’il est compatible avec l’OS cible. En revanche, tout script VBScript lancé via WSH/IIS est concerné par la trajectoire de retrait.
Classic ASP survivra‑t‑il ?
Classic ASP en tant que technologie IIS peut continuer à fonctionner, mais éviter VBScript est impératif ; la pérennité passe par la migration vers ASP.NET/.NET. Les migrations partielles via JScript doivent être vues comme transitoires.
Existe‑t‑il un « mode compatibilité » pérenne ?
Non. La phase 3 implique une suppression du moteur. Les workarounds (réactiver la FOD) ne valent que pendant la phase 2 et ne dispensent pas de réécrire.
Étapes détaillées de la migration
| Étape | Objectif | Livrables | Responsables |
|---|---|---|---|
| Inventaire | Visibilité exhaustive des dépendances | Liste des scripts/pages, carte des ProgID COM, matrice de risques | Équipe plateforme + applicative |
| Tests rapides | Mesurer l’impact de la désactivation FOD | Journal d’erreurs, backlog de corrections | Intégration/Qualité |
| Réécriture / remplacement | Sortir de VBScript | Scripts PowerShell, services .NET, pages ASP.NET/JS | Dév + DevOps |
| Gouvernance & sécurité | Éviter les régressions | Politique AppLocker/WDAC, contrôles de conformité FOD | Sécurité + Exploitation |
| Veille | Anticiper les jalons officiels | Notes de version surveillées, plan d’upgrade ajusté | Architecture |
Bonnes pratiques pour une migration sans douleur
- Découper : privilégiez des incréments livrables (par lot fonctionnel, par répertoire IIS, par type de job).
- Encapsuler : exposez la logique métier via des API internes ; remplacez les appels late‑binding par des SDK stables.
- Automatiser : uniformisez vos scripts de déploiement et de configuration (Desired State Configuration, Bicep/Terraform, pipelines YAML).
- Mesurer : suivez les KPI (nombre de scripts restant, % sites refondus, incidents liés à VBScript, temps moyen de correction).
- Sécuriser : évitez les subshells inutiles ; contrôlez les privilèges d’exécution ; journalisez les accès et erreurs.
Ressources utiles
- Windows IT Pro Blog — « VBScript deprecation: timelines and next steps »
- Microsoft 365 Dev — « Prepare your VBA projects for VBScript deprecation »
- Microsoft Learn — « VBScript‑to‑PowerShell Conversion Guide »
- Microsoft Learn — « Features removed or deprecated in Windows Server 2025 »
- Outils de packaging — « VBScript Is Getting Deprecated : How To Prepare For It »
En résumé : la dépréciation de VBScript suit une approche en trois étapes (FOD activée → FOD désactivée → retrait). Les administrateurs doivent inventorier dès maintenant toutes les dépendances, tester en labo la désactivation de la FOD et planifier la migration vers PowerShell, JavaScript et .NET. Ce travail diminue le risque de panne lors des futures mises à niveau (Windows Server 2025+), renforce la sécurité et modernise vos stacks applicatives.