Windows dice addio a slmgr.vbs: Microsoft sposta l'attivazione su PowerShell

Per quasi trent’anni VBScript ha rappresentato uno degli strumenti più semplici per automatizzare attività amministrative in Windows. Nato nel 1996 e integrato nel sistema operativo tramite Windows Script Host, ha finito per sostenere anche operazioni piuttosto delicate: tra queste c’è la gestione dell’attivazione di Windows attraverso il celebre script slmgr.vbs. Microsoft sta però preparando la rimozione definitiva di VBScript e ora invita esplicitamente gli amministratori IT a spostare l’automazione delle licenze verso PowerShell. Gli script aziendali basati su slmgr.vbs rischiano, a un certo punto, di smettere di funzionare.

Microsoft ha annunciato l’accantonamento di VBScript nel 2023 e a maggio 2024 ha condiviso una tabella di marcia articolata in più fasi. Inizialmente il componente rimane disponibile come caratteristica installabile su richiesta e attivo per impostazione predefinita; successivamente resterà installabile ma non più abilitato automaticamente. L’ultima fase prevede la sua eliminazione completa da Windows. A settembre 2026 Microsoft ha quindi affrontato uno dei problemi pratici lasciati aperti da questa transizione: come sostituire slmgr.vbs nelle procedure automatiche utilizzate per attivare PC e server.

La risposta prende la forma di OSLicense, un nuovo modulo PowerShell destinato a fornire un’interfaccia moderna per molte delle operazioni finora delegate allo script VBScript.

Perché slmgr.vbs è ancora così importante in Windows

Il nome deriva da Software Licensing Manager. Il file slmgr.vbs, normalmente disponibile nella directory System32, è in realtà un front-end amministrativo sopra l’infrastruttura Software Protection Platform (SPP) di Windows. Attraverso Windows Script Host interroga e modifica le informazioni relative alle licenze del sistema operativo.

Chi amministra Windows conosce bene comandi come slmgr.vbs /ato, utilizzato per tentare l’attivazione, oppure slmgr.vbs /ipk PRODUCT-KEY, che installa una chiave.

Con /dlv si ottengono informazioni dettagliate sulla licenza; /xpr consente invece di controllare la scadenza dell’attivazione. Esistono poi opzioni per configurare host KMS, rimuovere chiavi e gestire scenari più particolari.

Proprio negli ambienti in cui gli amministratori sono chiamati a gestire licenze a volume, l’utilità slmgr.vbs ha avuto un ruolo ancora più importante. Microsoft documenta da anni il suo impiego insieme a KMS, Multiple Activation Key e Volume Activation Management Tool. Molti script aziendali non mostrano neppure una finestra: richiamano cscript.exe con slmgr.vbs, interpretano il codice restituito e continuano il deployment.

OSLicense porta l’attivazione di Windows dentro PowerShell

Qui nasce il problema: slmgr.vbs dipende dal motore VBScript; quando quest’ultimo non sarà più presente, il file potrà anche rimanere formalmente nell’immagine o in qualche procedura storica, ma non avrà più l’ambiente necessario per essere eseguito.

Microsoft propone quindi di spostare i flussi più importanti sul modulo PowerShell OSLicense. L’obiettivo non consiste semplicemente nel riscrivere slmgr.vbs utilizzando una sintassi diversa: l’azienda vuole offrire comandi PowerShell utilizzabili direttamente negli strumenti di automazione moderni, senza dipendere da Windows Script Host.

PowerShell lavora con oggetti anziché affidarsi prevalentemente a stringhe stampate sullo standard output; uno script può quindi acquisire proprietà, controllare risultati, gestire eccezioni e passare i dati ad altre funzioni senza dover analizzare messaggi testuali pensati originariamente per un operatore umano.

Con slmgr.vbs, per esempio, molte automazioni richiamano cscript.exe, sopprimono le finestre di Windows Script Host e analizzano l’esito dell’esecuzione. Una cmdlet PowerShell può invece restituire informazioni strutturate e inserirsi molto meglio in procedure di gestione, logging e controllo remoto.

OSLicense non è ancora disponibile su ogni versione di Windows

C’è però una limitazione importante. Microsoft avverte che la disponibilità del modulo dipende OSLicense dalla versione e dalla SKU di Windows. Sui client Windows 11, OSLicense richiede l’aggiornamento facoltativo di agosto 2026 KB5120998 oppure un aggiornamento successivo.

La situazione lato server è ancora diversa: Microsoft prevede OSLicense nella prossima versione principale di Windows Server; gli amministratori interessati a provarlo in anticipo possono utilizzare le build preview di Windows Server vNext, con Microsoft che cita esplicitamente la build 29651.

Non conviene sostituire “domani mattina” ogni richiamo a slmgr.vbs dando per scontato che OSLicense esista ovunque. Un controllo PowerShell molto semplice può partire da Get-Module -ListAvailable OSLicense.

Da slmgr.vbs a PowerShell: la vera differenza è nell’automazione

La questione interessante non riguarda soltanto la sostituzione di un comando con un altro. Storicamente slmgr.vbs ha fornito un’interfaccia abbastanza uniforme per attività diverse: installazione della chiave, attivazione, informazioni sulla licenza e configurazione dei servizi di Volume Activation. OSLicense porta quelle operazioni nel modello PowerShell e consente di integrarle meglio con script complessi.

Immaginiamo una procedura aziendale che installi Windows, configuri la rete, registri il dispositivo nel sistema di gestione e infine verifichi la licenza. Con il vecchio approccio lo script potrebbe avviare cscript.exe slmgr.vbs /ato, attendere la conclusione del processo e leggere l’output. Con un modulo PowerShell l’intera logica può restare nello stesso ambiente di esecuzione, con gestione degli errori tramite try e catch, registrazione degli eventi e restituzione di oggetti utilizzabili dalle fasi successive.

È anche più facile costruire procedure idempotenti, cioè capaci di verificare lo stato corrente prima di modificare il sistema. Prima di tentare un’attivazione, per esempio, uno script può controllare se Windows risulta già dotato di regolare licenza ed evitare operazioni inutili.

I comandi da conoscere

La parte più concreta della migrazione riguarda i comandi. Microsoft propone una corrispondenza diretta tra alcune delle operazioni più comuni eseguite con slmgr.vbs e le nuove funzioni offerte dal modulo OSLicense. L’obiettivo è permettere agli amministratori di riscrivere gradualmente gli script senza cambiare la logica delle procedure.

Tre casi ricorrono continuamente negli ambienti gestiti: forzare l’attivazione di Windows, installare un product key e controllare lo stato della licenza. Con lo strumento storico si usano rispettivamente /ato, /ipk e /dlv. Nel nuovo modello le stesse attività passano a cmdlet PowerShell.

Operazione	Comando slmgr.vbs	Equivalente PowerShell OSLicense
Attivare Windows	slmgr.vbs /ato	Invoke-OSLicense -ActivateOnline
Installare un product key	slmgr.vbs /ipk <key>	Invoke-OSLicense -InstallProductKey <key>
Visualizzare lo stato della licenza	slmgr.vbs /dlv	Get-OSLicenseInfo

Il primo esempio è probabilmente il più immediato. slmgr.vbs /ato chiede al sistema di tentare l’attivazione della copia installata di Windows. Il comportamento concreto dipende dal tipo di chiave presente: con una licenza retail o MAK Windows tenta normalmente l’attivazione online; con una GVLK, cioè una Generic Volume License Key utilizzata nei deployment KMS, il comando avvia invece il tentativo di attivazione verso il server KMS configurato. Microsoft documenta lo stesso principio da anni per /ato.

Con OSLicense la stessa operazione assume una forma molto più leggibile: Invoke-OSLicense -ActivateOnline. Non serve più ricordare un’opzione abbreviata come /ato; il nome del parametro esprime chiaramente l’azione richiesta.

Come verificare quali comandi sono disponibili con OSLicense

Prima di eseguire qualsiasi automazione conviene quindi controllare che il modulo sia effettivamente presente:

Get-Module -ListAvailable OSLicense

Una volta disponibile, PowerShell permette di scoprire direttamente i comandi esportati:

Get-Command -Module OSLicense

Per esaminare sintassi e parametri di una singola cmdlet si può invece ricorrere al normale sistema di help:

Get-Help Invoke-OSLicense -Full

oppure:

Get-Help Get-OSLicenseInfo -Full

È una verifica che Microsoft consiglia di inserire anche durante lo sviluppo degli script. Affidarsi soltanto a un esempio pubblicato mesi prima sarebbe rischioso, soprattutto in una fase in cui OSLicense sta ancora raggiungendo le varie versioni di Windows.