Deprecazione VBScript su Windows Server: roadmap, rischi e guida di migrazione

VBScript sarà ritirato da Windows Server: Microsoft ha definito una roadmap in tre fasi che impatta automazioni, siti Classic ASP e componenti MSI. Qui trovi una guida operativa completa con check‑list, script e strategie per migrare in sicurezza verso PowerShell e piattaforme moderne.

Indice

Panoramica operativa e timeline

Microsoft ha avviato un piano in tre fasi per eliminare in modo permanente VBScript dal sistema operativo. La funzione resta inizialmente disponibile come Feature on Demand (FOD) per garantire continuità operativa, poi viene disattivata di default e infine rimossa dai binari di sistema. La tabella seguente sintetizza cosa aspettarsi e come prepararsi.

Fase	Periodo indicativo	Stato di VBScript	Note operative
1	Windows 11 24H2 / Windows Server 2025	FOD preinstallata e attiva di default	Continuità garantita mentre si pianifica la migrazione. [ref. roadmap Microsoft]
2	~2027	FOD ancora presente ma disattivata di default	Gli amministratori dovranno abilitarla manualmente se necessario. [ref. roadmap Microsoft]
3	Release successive	Rimozione completa della libreria VBScript	Gli script `.vbs` non si eseguiranno più. [ref. roadmap Microsoft]

Messaggio chiave – Non esiste un “kill switch” immediato, ma è prudente trattare la migrazione come un progetto guidato da scadenze: pianifica ora, completa entro la finestra che precede la Fase 2 per evitare pressioni e rischi nella Fase 3.

Versioni di Windows Server interessate

Famiglia	Stato rispetto a VBScript
Windows Server 2025 (LTSC)	VBScript è già una FOD preinstallata e attiva; verrà rimossa in un rilascio successivo. [ref. note di prodotto]
Windows Server 2016 / 2019 / 2022	VBScript rimane incluso e supportato secondo il ciclo di vita LTSC; non riceverà nuove funzionalità. [ref. note di prodotto]
Windows Server 2008 / 2012 / 2012 R2	Fuori supporto o prossimi alla fine; nessuna modifica prevista, ma assenza di patch di sicurezza future. [ref. Q&A Microsoft]

Nota: le piattaforme client (Windows 11) seguono lo stesso schema. In ambito server, il punto di svolta pratico è l’adozione di Windows Server 2025.

Impatto tipico sui workload

Scenario	Rischio	Mitigazione consigliata
Automazione di sistema (`.vbs` in logon‑scripts, Task Scheduler, Group Policy)	Errore di esecuzione in Fase 3	PowerShell come alternativa supportata; usare linee guida e script di conversione.
Siti Classic ASP con VBScript lato server	Funzionano finché la FOD è presente; a rischio dopo la rimozione	Migrare a .NET moderno (ASP.NET Core/C#) o riscrivere la logica in JavaScript lato server.
Custom actions MSI basate su VBScript	Impossibili in Fase 3; PowerShell non supporta il session‑handle MSI	Valutare WiX con DLL native o azioni gestite .NET (DTF). Considerare MSIX ove applicabile.
VBA che usa la libreria `VBScript.RegExp`	Compilazione/Runtime error dopo la rimozione	Passare alla classe RegExp integrata in VBA (release recente) o ad alternative senza dipendere da VBScript.
Packaging e distribuzione SCCM/Intune che richiede `wscript.exe`/`cscript.exe`	Installazioni bloccate o parziali	Riconfezionare le logiche in PowerShell e usare detection rule moderne.
Strumenti terzi che istanziano `CreateObject("VBScript.*")` via COM	Funzionalità interrotte alla rimozione dei binari	Chiedere roadmap ai vendor, sostituire i componenti o isolare fino alla dismissione.

Strategia di transizione consigliata

Un approccio in cinque mosse riduce al minimo i rischi e ottimizza i tempi.

Inventario completo

Discovery file‑based: ricerca ricorsiva di .vbs, .wsf, .asp e stringhe chiave (“VBScript.RegExp”, “CreateObject”).
Discovery service‑based: enumerazione Scheduled Tasks, criteri di logon script GPO, cartelle di logon Netlogon/SYSVOL, pacchetti di distribuzione.
Discovery runtime: telemetria su processi wscript.exe/cscript.exe, moduli COM caricati, chiamate a vbscript.dll.

Script PowerShell per inventario su file server e profili utente

# Esempio: scansione ricorsiva con metadati minimi
$roots = @("C:\","D:\","\\fileserver\share1","\\fileserver\share2")
$patterns = @(".vbs",".wsf","*.asp")
$result = foreach ($root in $roots) {
  foreach ($p in $patterns) {
    Get-ChildItem -Path $root -Include $p -Recurse -ErrorAction SilentlyContinue |
      Select-Object FullName, Length, LastWriteTime
  }
}
$result | Export-Csv ".\inventario-vbscript.csv" -NoTypeInformation -Encoding UTF8
Write-Host "Trovati $($result.Count) file potenzialmente critici."

Ricerca di riferimenti VBScript all’interno del codice

# Cerca pattern in script e pagine ASP
$patterns = @("VBScript.RegExp","CreateObject\(""VBScript\.","WScript\.","Server\.CreateObject")
$files = Get-ChildItem -Path . -Include .vbs,.wsf,*.asp -Recurse
foreach ($f in $files) {
  $content = Get-Content $f.FullName -Raw
  foreach ($pat in $patterns) {
    if ($content -match $pat) {
      [PSCustomObject]@{File=$f.FullName; Pattern=$pat} 
    }
  }
} | Export-Csv .\riferimenti-vbscript.csv -NoTypeInformation

Valutazione e priorità

Classifica ogni dipendenza in base a criticità, complessità di riscrittura e fattore di rischio operativo. Un semplice modello di scoring aiuta a ordinare il backlog:

Parametro	Domanda guida	Punteggio
Impatto	Blocca ambienti di produzione o processi core?	1 basso – 5 altissimo
Frequenza	Con quale cadenza gira?	1 sporadico – 5 orario
Complessità	Quante integrazioni esterne e logiche complesse contiene?	1 semplice – 5 complesso
Rischio sicurezza	Espone superfici di attacco o privilegia esecuzioni in chiaro?	1 basso – 5 elevato

Conversione tecnica

Automazione: converti in PowerShell 7+ con moduli ufficiali; prediligi Invoke-RestMethod, Microsoft.Graph, ActiveDirectory, CimCmdlets.
Web: migra Classic ASP verso ASP.NET Core o logiche JavaScript lato server; separa business logic e presentazione; usa test end‑to‑end.
VBA: sostituisci le dipendenze da VBScript.RegExp con la nuova classe Regex in VBA o alternative compatibili.

Testing continuo

Allestisci un lab con Windows Server 2025.
Simula la Fase 2 disattivando la FOD VBScript e verifica impatti.
Automatizza test di non regressione per script, job schedulati e flussi web.

Simulazione della disattivazione e gestione FOD

I nomi effettivi della funzionalità possono variare. Individua la capability e abilita/disabilita in modo controllato.

# Individua la capability installata o disponibile
Get-WindowsCapability -Online | Where-Object Name -match "VBScript"

Disattiva/attiva in lab (verifica il nome esatto)

Disable-WindowsOptionalFeature -Online -FeatureName VBScript -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName VBScript -All -NoRestart

In alternativa, gestione come capability (se esposta come FOD Capabilities)

Rimuovi/aggiungi capability (usa il nome trovato dal comando di discovery)

Remove-WindowsCapability -Online -Name Microsoft.Windows.VBScript~~~~0.0.1.0
Add-WindowsCapability -Online -Name Microsoft.Windows.VBScript~~~~0.0.1.0

Governance

Policy: vieta nuovo codice VBScript, definisci una data limite interna precedente al 2027.
Processo: integra la verifica “no VBScript” nelle revisioni di codice, nei pacchetti di rilascio e nelle pipeline CI/CD.
Comunicazione: informa i team applicativi, i vendor e gli stakeholder; pubblica linee guida e modelli di migrazione.

Conversione pratica da VBScript a PowerShell

Di seguito una mappa concettuale con esempi concreti per le trasformazioni più comuni.

Operazione	VBScript	PowerShell	Note
File system	`Set fso = CreateObject("Scripting.FileSystemObject") If Not fso.FolderExists("C:\Logs") Then fso.CreateFolder "C:\Logs" End If`	`if (-not (Test-Path "C:\Logs")) { New-Item -ItemType Directory -Path "C:\Logs" \| Out-Null }`	Preferisci cmdlet nativi; evita COM FSO.
Registro	`Set sh = CreateObject("WScript.Shell") sh.RegWrite "HKLM\SOFTWARE\Contoso\Key","Val","REG_SZ"`	`New-Item -Path "HKLM:\SOFTWARE\Contoso" -Force \| Out-Null New-ItemProperty -Path "HKLM:\SOFTWARE\Contoso" -Name "Key" -Value "Val" -PropertyType String -Force`	Usa il provider del registro PSDrive.
WMI/CIM	`Set svc = GetObject("winmgmts:root\cimv2") Set os = svc.ExecQuery("Select * from Win32_OperatingSystem")`	`Get-CimInstance -ClassName Win32_OperatingSystem`	Preferisci CIM e sessioni remoting sicure.
Messaggi	`WScript.Echo "Operazione completata"`	`Write-Host "Operazione completata"`	In produzione logga su file/event log.
ADSI/Directory	`Set usr = GetObject("LDAP://cn=Mario,ou=Utenti,dc=contoso,dc=local")`	`Get-ADUser -Identity "Mario" -Properties *`	Usa moduli ActiveDirectory, non ADSI crudo.

Template PowerShell per migrazioni strutturate

[CmdletBinding()]
param(
  [Parameter(Mandatory)]
  [string]$InputPath,

[Parameter()]
[string]$LogPath = "C:\Logs\ScriptMigrazione.log"
)

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

function Write-Log {
param([string]$Message,[string]$Level="INFO")
$ts = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
"$ts [$Level] $Message" | Add-Content -Path $LogPath
}

try {
Write-Log "Inizio elaborazione per $InputPath"

...logica...

Write-Log "Completato"
} catch {
Write-Log "Errore: $($_.Exception.Message)" "ERROR"
throw
}

Migrazione di Classic ASP

Per i siti Classic ASP che impiegano VBScript lato server, una migrazione graduale riduce il rischio:

Assessment: mappa le pagine con business logic, oggetti COM, ADO e le dipendenze “Server.CreateObject”.
Strangling: affianca un’app ASP.NET Core dietro IIS in modalità reverse proxy; instrada gradualmente rotte specifiche al nuovo stack.
Rifattorizzazione: sposta logiche in servizi C# con DI; usa EF Core/Dapper per l’accesso ai dati; adotta test automatizzati.
Decommissioning: elimina gli endpoint Classic ASP residui e rimuovi la FOD VBScript.

Componente Classic ASP	Contropartita moderna	Note di porting
`Response.Write`	Razor/Minimal API	Separare output HTML da logica; adottare view model.
ADO con recordset	EF Core/Dapper	Parametrizzare query, evitare SQL in linea.
COM personalizzati	Servizi .NET/Worker	Esporre via DI o gRPC; evitare COM interop.

Pacchetti MSI e installazioni

Evita script VBScript come custom action. In alternativa usa Deferred Custom Action in DLL native o Managed Custom Action tramite DTF (WiX Toolset).
Session‑handle MSI: non esiste equivalente PowerShell supportato; per logiche complesse scegli DLL o riprogetta il pacchetto.
Valuta MSIX per nuovi deployment: supporta modern containerization e riduce la necessità di azioni personalizzate.

VBA e dipendenza da RegExp

Molti macro‑progetti Office usano CreateObject("VBScript.RegExp"). Con la rimozione di VBScript la creazione COM fallirà. Le opzioni:

Nuova classe RegExp in VBA (disponibilità recente): non dipende da vbscript.dll e assicura compatibilità futura.
Pattern matching alternativo: quando possibile, sfrutta funzioni native dei fogli o librerie pure‑VBA.

Esempio di sostituzione in VBA

' Prima (dipende da VBScript)
Dim rx As Object: Set rx = CreateObject("VBScript.RegExp")
rx.Pattern = "(\d{2})/(\d{2})/(\d{4})"
rx.Global = False

' Dopo (classe integrata in VBA, esempio concettuale)
Dim rx2 As VBA.RegExp
Set rx2 = New VBA.RegExp
rx2.Pattern = "(\d{2})/(\d{2})/(\d{4})"

Controlli di sicurezza e hardening

Oltre alla migrazione applicativa, implementa controlli difensivi che anticipano la rimozione.

AppLocker/WDAC: blocca o limita wscript.exe e cscript.exe dove non strettamente necessari.
Attack Surface Reduction: abilita le regole pertinenti, in particolare “Block execution of potentially obfuscated scripts” (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC) e “Block JavaScript or VBScript from launching downloaded executable content” (D3E037E1-3EB8-44C8-A917-57927947596D).
Monitoring: traccia esecuzioni e origini dei file script per individuare dipendenze residue.

Abilitazione rapida regole ASR via PowerShell

# Richiede privilegi elevati
$ids = @(
  "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC", # Obfuscated scripts
  "D3E037E1-3EB8-44C8-A917-57927947596D"  # JS/VBS launching downloaded executables
)
Set-MpPreference -AttackSurfaceReductionRulesIds $ids -AttackSurfaceReductionRulesActions Enabled

Regole Sysmon per tracciare esecuzioni VBS

&lt;EventFiltering&gt;
  &lt;ProcessCreate onmatch="include"&gt;
    &lt;Image condition="end with"&gt;\wscript.exe&lt;/Image&gt;
    &lt;Image condition="end with"&gt;\cscript.exe&lt;/Image&gt;
    &lt;CommandLine condition="contains"&gt;.vbs&lt;/CommandLine&gt;
  &lt;/ProcessCreate&gt;
&lt;/EventFiltering&gt;

Testing e convalida

Lab realistico: crea una golden image di Windows Server 2025; disabilita manualmente la FOD per simulare le fasi successive.
Test funzionali: orchestra esecuzioni automatizzate di job, logon e pagine web; usa container o ambienti isolati per test smoke.
Test di performance: misurazioni prima/dopo per script ricritti (es. PowerShell remoting vs. WMI DCOM).
Rollback: definisci criteri e runbook di ripristino in caso di regressioni.

Domande frequenti

VBScript continuerà a funzionare su Windows Server 2025?
Sì, inizialmente come FOD attiva di default. Tuttavia, dipendere da questa modalità espone al rischio di interruzione quando la FOD verrà disattivata o rimossa.

Posso “riattivare” VBScript nella Fase 2?
Sì, l’amministratore potrà abilitarlo manualmente per compatibilità temporanea. È sconsigliato come soluzione definitiva.

Esistono strumenti automatici di conversione?
Non c’è un convertitore universale affidabile. La conversione va guidata: riscrittura a blocchi, test granulari e revisione del design.

Che cosa succede ai siti Classic ASP?
Finché la FOD resta disponibile, continueranno a funzionare. Per resilienza a lungo termine è necessario migrare verso .NET o ristrutturare la logica server‑side.

Come gestisco i fornitori terzi?
Richiedi dichiarazioni di conformità e piani di eliminazione di VBScript; considera contratti con clausole di compatibilità o piani di uscita.

Checklist esecutiva

Completa l’inventario di .vbs/.wsf/.asp e riferimenti VBScript.*.
Classifica rischi e priorità; definisci una roadmap per applicazione/processo.
Stabilisci la piattaforma target (PowerShell, ASP.NET Core, logiche server‑side moderne).
Implementa controlli di sicurezza (ASR, AppLocker/WDAC) per ridurre la dipendenza operativa.
Costruisci un lab che simula Fase 2/3; esegui test di regressione e performance.
Comunica scadenze interne, ferma nuovo codice VBScript e aggiorna le linee guida di sviluppo.
Pianifica la dismissione definitiva della FOD prima della rimozione di sistema.

Esempi pronti all’uso

Inventario organizzativo con output normalizzato

# Richiede diritti di lettura su condivisioni e host
$targets = Get-Content .\server-list.txt
$ext = @(".vbs",".wsf","*.asp")
$all = foreach ($t in $targets) {
  foreach ($e in $ext) {
    try {
      Get-ChildItem -Path "\\$t\c$" -Include $e -Recurse -ErrorAction Stop |
        Select-Object @{N="Server";E={$t}}, FullName, Length, LastWriteTime
    } catch {
      [PSCustomObject]@{Server=$t; FullName="&lt;errore&gt;"; Length=0; LastWriteTime=$null}
    }
  }
}
$all | Sort-Object Server, FullName |
  Export-Csv .\org-inventario-vbscript.csv -NoTypeInformation -Encoding UTF8

Rilevazione rapida di esecuzioni a runtime

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-Sysmon/Operational';
  Id=1
} | Where-Object {
  $.Properties[4].Value -match "wscript\.exe|cscript\.exe" -or $.Message -match "\.vbs"
} | Select-Object TimeCreated, Id, Message | Format-Table -AutoSize

Abilitazione FOD in fase di deployment

# Esegui nel task sequence post-OS (Esempio, verifica nome capability)
$cap = (Get-WindowsCapability -Online | ? Name -match "VBScript").Name
if ($cap) {
  Add-WindowsCapability -Online -Name $cap -ErrorAction Stop
}

Riscrittura di un logon script d’esempio

Prima (VBScript):

Set sh = CreateObject("WScript.Shell")
sh.RegWrite "HKCU\Software\Contoso\Dept","Sales","REG_SZ"
WScript.Quit 0

Dopo (PowerShell):

$path = "HKCU:\Software\Contoso"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
New-ItemProperty -Path $path -Name "Dept" -Value "Sales" -PropertyType String -Force | Out-Null
exit 0

Conclusioni

La deprecazione di VBScript su Windows Server è un cambiamento annunciato e governabile. Chi si muove ora può sfruttare la Fase 1 per mappare, riscrivere e testare, attivando controlli che riducono i rischi. La destinazione naturale è PowerShell per l’automazione e .NET/JavaScript per il web: tecnologie supportate, sicure e sostenibili. Con un inventario rigoroso, una migrazione per priorità e un lab che simula le fasi future, l’uscita di scena di VBScript diventa un progetto ordinato, non un incidente operativo.

Risorse utili (senza collegamenti esterni)

Windows IT Pro Blog – “VBScript deprecation: Timelines and next steps”.
Microsoft Learn – “Features Removed or No Longer Developed in Windows Server”.
Windows Message Center – comunicazioni e note di rilascio.
Guide di conversione VBScript‑to‑PowerShell con esempi e best practice.

In pratica

Hai tempo fino a circa il 2027 per migrare, ma conviene iniziare subito per evitare sorprese.
Se devi mantenere VBScript nel breve periodo, prevedi procedure per abilitare la FOD su Windows Server 2025 e monitora le policy che potrebbero disattivarla.
Per il lungo periodo, PowerShell (automazione) e JavaScript/.NET (web) sono le strade supportate e raccomandate.