In questo articolo Indice dei contenuti 3 sezioni
Per quasi trent’anni slmgr.vbs è stato il coltellino svizzero di chiunque dovesse gestire l’attivazione di Windows su decine o centinaia di macchine, e adesso Microsoft ha deciso che quella stagione è finita. Il motivo è semplice: lo script poggia su VBScript, tecnologia nata nel 1996 e integrata nel sistema tramite Windows Script Host, che l’azienda ha messo in pensione. Al suo posto arriva OSLicense, un modulo PowerShell pensato per portare la gestione delle licenze dentro gli strumenti di automazione moderni.
L’accantonamento di VBScript era stato annunciato nel 2023, con una tabella di marcia più dettagliata arrivata a maggio 2024. Tre fasi: prima il componente resta installabile su richiesta e attivo di default, poi rimane installabile ma non più abilitato in automatico, infine sparisce del tutto da Windows. A settembre 2026 Microsoft ha affrontato uno dei nodi pratici lasciati aperti, cioè come sostituire slmgr.vbs nelle procedure automatiche che attivano PC e server aziendali.
Cosa faceva slmgr.vbs e perché tanti script aziendali ne dipendono
Il nome viene da Software Licensing Manager. Il file, che si trova normalmente in System32, è un front end amministrativo sopra l’infrastruttura Software Protection Platform di Windows: interroga e modifica le informazioni sulle licenze passando per Windows Script Host. Chi amministra parchi macchine conosce a memoria le opzioni più usate, da /ato per tentare l’attivazione a /ipk per installare una chiave, passando per /dlv che restituisce i dettagli della licenza e /xpr che mostra la scadenza. Ci sono poi i comandi per configurare gli host KMS, rimuovere chiavi e gestire situazioni più particolari.
Negli ambienti con licenze a volume il peso di questo strumento è ancora maggiore. Microsoft lo documenta da anni insieme a KMS, Multiple Activation Key e Volume Activation Management Tool. Molti script aziendali lavorano in silenzio, senza mostrare nulla a schermo: richiamano cscript.exe con slmgr.vbs, leggono il codice restituito e proseguono con il deployment. Quando il motore VBScript non ci sarà più, quei flussi si fermeranno, perché il file potrà anche restare nell’immagine ma non avrà l’ambiente per essere eseguito.
OSLicense e la differenza vera, che sta nell’automazione
Il punto non è riscrivere gli stessi comandi con una sintassi diversa. PowerShell lavora con oggetti e non con stringhe stampate a video, quindi uno script può leggere proprietà, controllare esiti, gestire eccezioni e passare i dati alla fase successiva senza dover interpretare messaggi testuali nati per un operatore umano. La corrispondenza proposta da Microsoft copre per ora i tre casi che ricorrono di continuo: slmgr.vbs /ato diventa Invoke-OSLicense con il parametro ActivateOnline, slmgr.vbs /ipk diventa Invoke-OSLicense con InstallProductKey, slmgr.vbs /dlv lascia spazio a Get-OSLicenseInfo.
Il comportamento resta quello noto. Con una licenza retail o MAK il sistema tenta l’attivazione online, mentre con una GVLK, la Generic Volume License Key usata nei deployment KMS, parte il tentativo verso il server KMS configurato. Cambia la leggibilità: il nome del parametro dice cosa sta succedendo, senza bisogno di ricordare una sigla abbreviata.
Immaginiamo una procedura che installa Windows, configura la rete, registra il dispositivo nel sistema di gestione e infine verifica la licenza. Con il vecchio approccio lo script lancia cscript.exe, attende la fine del processo e legge l’output. Con il modulo PowerShell tutta la logica resta nello stesso ambiente, con try e catch per gli errori, registrazione degli eventi e oggetti riutilizzabili più avanti. Diventa anche più facile costruire procedure idempotenti, che controllano lo stato prima di agire ed evitano di attivare una copia di Windows già regolarmente licenziata.
Attenzione alla disponibilità: non c’è su tutte le versioni
La disponibilità del modulo dipende da versione e SKU di Windows. Sui client Windows 11 serve l’aggiornamento facoltativo di agosto 2026 KB5120998 o uno successivo. Lato server la musica cambia: OSLicense è previsto nella prossima versione principale di Windows Server, e chi vuole provarlo prima può usare le build preview di Windows Server vNext, con Microsoft che cita esplicitamente la build 29651.
Sostituire tutti i richiami a slmgr.vbs dando per scontato che il modulo ci sia ovunque, quindi, non è una buona idea. Un controllo preliminare con Get-Module ListAvailable OSLicense costa pochi secondi, mentre Get-Command con il parametro Module mostra i comandi effettivamente esportati e Get-Help con l’opzione Full chiarisce sintassi e parametri di ogni singola cmdlet. Microsoft consiglia di inserire questa verifica già in fase di sviluppo degli script, visto che il modulo sta ancora raggiungendo le varie versioni di Windows.
