Wenn Sie schon länger Windows administrieren, kennen Sie slmgr.vbs im Schlaf. Aktivierungsstatus prüfen, Produkt-Keys installieren, online aktivieren, vor Ablauf der Toleranzperiode ein Rearm hinterherschieben: Für all das war das kleine Skript aus C:\Windows\System32 jahrzehntelang das Mittel der Wahl. Genau dieses Skript verliert nun seine Grundlage, denn es ist ein VBScript, und VBScript verabschiedet sich aus Windows.
Die gute Nachricht vorweg: Microsoft lässt Administratoren diesmal nicht im Regen stehen. Als offiziellen Nachfolger gibt es das PowerShell-Modul OSLicense, das dieselben Aufgaben übernimmt, aber mit richtigen Cmdlets und strukturierten Objekten statt Dialogfenstern und geparstem Text. Dieser Beitrag ordnet ein, was genau passiert, bis wann Sie Zeit haben und wie die Migration konkret abläuft. Alle Kernaussagen sind gegen Microsoft-eigene Quellen geprüft.
Wird slmgr.vbs wirklich abgekündigt? Nicht direkt
Ein verbreitetes Missverständnis gleich zu Beginn: Microsoft kündigt slmgr.vbs nicht als Werkzeug ab. Die Datei bleibt vorerst da, wo sie ist. Abgekündigt wird die Laufzeitumgebung darunter, nämlich VBScript. slmgr.vbs ist nichts anderes als ein VBScript-basiertes Verwaltungswerkzeug für die Software-Lizenzierung. Fehlt irgendwann die VBScript-Engine, fehlt dem Skript schlicht die Umgebung, in der es laufen kann.
Praktisch heißt das: Jeder Aufruf von slmgr.vbs, egal ob in einem Startskript, einer MDT-Tasksequenz, einem RMM-Job oder einem PowerShell-Wrapper, der auf cscript ausweicht, wird eines Tages ins Leere laufen. Und das oft lautlos, weil unbeaufsichtigte Automatisierung selten jemand beim Scheitern zusieht. Deshalb lohnt es sich, das Thema jetzt zu verstehen, auch wenn noch kein akuter Zeitdruck herrscht.
Der Zeitplan: VBScript-Deprecation in drei Phasen
Microsoft hat die Abkündigung von VBScript bereits im Oktober 2023 angekündigt und in drei Phasen gegliedert. Der genaue Ablauf ist maßgeblich, denn nicht ein einzelnes Datum entscheidet, sondern die Reihenfolge der Phasen.
In Phase 1, in der wir uns aktuell befinden, ist VBScript als Feature on Demand (FOD) vorinstalliert und standardmäßig aktiv. Das gilt für Windows 11 ab Version 24H2 und auch für Windows Server 2025, wo VBScript ebenfalls vorinstalliert ist. slmgr.vbs funktioniert in dieser Phase ganz normal. Nach Microsofts eigener Formulierung reicht diese Phase bis etwa 2026 oder 2027.
In Phase 2, die Microsoft „ungefähr 2026 oder 2027″ verortet, wird das VBScript-FOD standardmäßig deaktiviert. Manuell lässt es sich pro Gerät weiter aktivieren, doch ohne diesen Schritt scheitert slmgr.vbs. Genau hier trifft es unbeaufsichtigte Automatisierung: MDT-Tasksequenzen, Startskripte und RMM-Jobs brechen, sofern das Feature nicht vorher auf jeder Maschine reaktiviert wird.
In Phase 3, für die noch kein festes Datum veröffentlicht ist, wird VBScript vollständig aus Windows entfernt. Dann gibt es keine Reaktivierung mehr und keinen Fallback. slmgr.vbs ist damit endgültig Geschichte. In Insider-Diskussionen kursiert als Zielmarke der Herbst 2027, verbindlich ist das aber nicht.
Kein Grund zur Panik also, wohl aber ein guter Anlass, die Weichen zu stellen, solange Phase 1 noch läuft.
Der Nachfolger: das OSLicense-PowerShell-Modul
Als Ersatz stellt Microsoft das OSLicense-Modul bereit. Es deckt die Windows-Lizenzierung und -Aktivierung vollständig ab, und zwar breiter als der reine slmgr-Ersatz vermuten lässt: neben der klassischen OS-Aktivierung auch KMS (Key Management Service), die Active-Directory-basierte Aktivierung und die Abonnement-Aktivierung (Subscription). Laut Microsofts eigener Leitlinie „Keep Windows activation automation working with PowerShell“ ist OSLicense inzwischen der empfohlene Weg für die gängigen Aktivierungsaufgaben.
Der eigentliche Fortschritt liegt im Verhalten. slmgr.vbs gab menschenlesbaren Text aus, entweder in einem Popup oder über cscript auf die Konsole. Wer das in Skripten auswerten wollte, war auf fragiles String-Parsing angewiesen. Jedes OSLicense-Cmdlet gibt stattdessen ein strukturiertes Objekt (PSCustomObject) zurück. Ob eine Operation erfolgreich war, steht in einer Success-Eigenschaft, Fehlerdetails kommen als ErrorCode (ein Windows-HRESULT) und ErrorMessage zurück. Damit lässt sich endlich saubere Fehlerbehandlung schreiben.
Technische Rahmenbedingungen: Das Modul setzt Windows PowerShell 5.1 voraus und wird auf unterstützten Systemen mit Windows ausgeliefert. Es lädt automatisch, sobald Sie eines seiner Cmdlets aufrufen, ein explizites Importieren ist nicht nötig. Für alle Operationen, die den Lizenzstatus verändern, brauchen Sie eine als Administrator gestartete Sitzung.
Verfügbarkeit: Wo das Modul schon vorhanden ist
Hier liegt der wichtigste Praxishinweis, denn die Verfügbarkeit unterscheidet sich je nach Windows-Version deutlich. Microsofts Cmdlet-Dokumentation nennt die beiden Quellen ausdrücklich: Das Modul ist in Windows Server vNext Preview Build 29651 sowie im Sicherheitsupdate 2026-09 für Windows 11 (KB5124008) enthalten.
Für Windows 11 heißt das: Wer den September-2026-Patchstand (KB5124008) installiert hat, verfügt bereits über das Modul. Aktuelle Clients sind also startklar.
Für Windows Server gilt Geduld. Das Modul steckt bisher nur in der Insider-Vorschau (Server vNext Preview Build 29651 oder neuer), nicht in Windows Server 2025 oder älteren Server-Versionen. Auf Server 2025 bleibt slmgr.vbs vorerst der reguläre Weg, denn dort ist VBScript vorinstalliert. Serverseitige Aktivierungsautomatisierung sollten Sie deshalb erst umstellen, wenn die nächste Server-Version in Ihrer Umgebung angekommen ist.
Ob eine Maschine das Modul hat, prüfen Sie mit einem Einzeiler:
powershell
Get-Module -ListAvailable -Name "OSLicense*"Kommt nichts zurück, fehlt das erforderliche Update. Auf Windows 11 spielen Sie dann KB5124008 oder das aktuelle kumulative Update ein und prüfen erneut. Ein Wermutstropfen für Imaging-Prozesse: In WinPE und der Windows-Wiederherstellungsumgebung (WinRE) steht OSLicense nicht zur Verfügung.
Die Vorgehensweise: Migration Schritt für Schritt
Die eigentliche Umstellung ist überwiegend mechanisch. Der Aufwand steckt weniger in der neuen Syntax als darin, alle Stellen zu finden, an denen sich slmgr.vbs über die Jahre eingenistet hat. Ein bewährtes Vorgehen in fünf Schritten:
Schritt 1: Bestandsaufnahme
Bevor Sie irgendetwas umschreiben, finden Sie heraus, was überhaupt migriert werden muss. slmgr.vbs-Aufrufe verstecken sich erfahrungsgemäß an vielen Stellen: in MDT-Tasksequenzen, SCCM- oder Intune-Skripten, RMM-Automatisierung, Gruppenrichtlinien-Startskripten, PowerShell-Wrappern und WDS-Imaging-Skripten. Ein rekursiver Suchlauf über Ihre Skriptablagen liefert eine erste Landkarte:
powershell
Get-ChildItem -Path 'C:\Scripts' -Recurse -Include '*.ps1','*.cmd','*.bat','*.vbs','*.wsf' |
Select-String -Pattern 'slmgr' |
Select-Object Path, LineNumber, Line |
Export-Csv -Path .\slmgr-referenzen.csv -NoTypeInformation -Encoding UTF8Passen Sie den Pfad an Ihre Umgebung an. Die CSV dient anschließend als Checkliste, welches Skript bereits umgestellt und getestet ist. Für das größere Bild, also VBScript-Abhängigkeiten über slmgr hinaus, empfiehlt Microsoft in seinem Beitrag zu den Erkennungsstrategien unter anderem, per Sysmon die Ladevorgänge von vbscript.dll unternehmensweit zu protokollieren.
Schritt 2: Modul-Verfügbarkeit sicherstellen
Prüfen Sie mit dem obigen Get-Module-Aufruf, ob OSLicense auf den Zielsystemen vorhanden ist, und bringen Sie Ihre Windows-11-Clients bei Bedarf auf den Patchstand KB5124008. Für Server planen Sie die Umstellung erst mit der nächsten Server-Version ein.
Schritt 3: Befehle umstellen
Für die meisten Skripte ist die Migration eine direkte Ersetzung anhand der Zuordnungstabelle weiter unten. Ein einfacher Statusabruf sieht dann zum Beispiel so aus:
powershell
Get-OSLicenseInfo | Select-Object Name, LicenseStatus, PartialProductKey, GracePeriodRemainingDie Eigenschaft LicenseStatus sagt Ihnen, ob die Maschine lizenziert ist (auf einem aktivierten System steht dort Licensed). GracePeriodRemaining wird in Minuten angegeben und ist auf aktivierten Geräten 0. Für das Äquivalent zu /xpr betrachten Sie LicenseStatus und GracePeriodRemaining zusammen.
Schritt 4: Echte Fehlerbehandlung nutzen
Der größte Gewinn gegenüber dem alten String-Parsing ist die saubere Fehlerauswertung. Statt Exit-Codes und Textschnipseln prüfen Sie einfach die Eigenschaften des Ergebnisobjekts:
powershell
$result = Invoke-OSLicense -ActivateOnline
if (-not $result.Success) {
Write-Warning "Aktivierung fehlgeschlagen: $($result.ErrorMessage) (HRESULT: $($result.ErrorCode))"
}Auch Zustände wie ein nötiger Neustart kommen als richtiger Wert zurück, etwa nach einem Rearm:
powershell
$result = Invoke-OSLicense -Rearm
if ($result.RestartRequired) {
Write-Host "Rearm erfolgreich. Neustart erforderlich." -ForegroundColor Yellow
}Schritt 5: Testen und schrittweise ausrollen
Stellen Sie zuerst in einer Entwicklungs- oder Nicht-Produktionsumgebung um, bevor Sie in die Fläche gehen. Aktualisieren Sie dabei nicht nur Skripte, sondern auch MDT-Tasksequenzen, RMM-Jobs, Runbooks und nicht zuletzt Ihre Helpdesk- und Onboarding-Dokumentation. Alles, was heute „führen Sie slmgr.vbs aus“ sagt, gehört überarbeitet. Das Ziel: Vor Beginn von Phase 2 laufen keine slmgr.vbs-Aufrufe mehr in der produktiven Automatisierung.
Referenz: slmgr.vbs auf OSLicense abgebildet
Die folgende Tabelle stellt die gängigen Aufgaben gegenüber. Sie deckt den Großteil dessen ab, was in der Praxis mit slmgr.vbs erledigt wurde.
| Aufgabe | slmgr.vbs | OSLicense |
|---|---|---|
| Lizenz-/Aktivierungsstatus anzeigen | /dlv | Get-OSLicenseInfo |
| Status aller Produkte | /dlv all | Get-OSLicenseInfo -All |
| Ablauf/Toleranzperiode prüfen | /xpr | Get-OSLicenseInfo (LicenseStatus + GracePeriodRemaining) |
| Online aktivieren | /ato | Invoke-OSLicense -ActivateOnline |
| Produkt-Key installieren | /ipk <Key> | Invoke-OSLicense -InstallProductKey '<Key>' |
| Produkt-Key deinstallieren | /upk | Invoke-OSLicense -UninstallProductKey |
| Key aus Registry entfernen | /cpky | Invoke-OSLicense -ClearProductKeyFromRegistry |
| Rearm (Toleranzperiode zurücksetzen) | /rearm | Invoke-OSLicense -Rearm |
| Systemlizenzen neu installieren | /rilc | Invoke-OSLicense -ReinstallSystemLicenses |
| KMS-Host setzen | /skms host:1688 | Set-KmsLicenseInfo -ServerName 'host' -Port 1688 |
| KMS-Serverüberschreibung löschen | /ckms | Invoke-KmsLicense -ClearServer |
| KMS-Infos anzeigen | /dlv (teilweise) | Get-KmsLicenseInfo |
| Offline-Installations-ID | /dti | (Get-OSLicenseInfo).OfflineInstallationId |
| Offline aktivieren | /atp <CID> | Invoke-OSLicense -ActivateOffline <ID> -ConfirmationID <CID> |
Darüber hinaus deckt das Modul Szenarien ab, für die slmgr.vbs nie zuständig war oder nur umständlich taugte: Get-ADLicenseInfo und Invoke-ADLicense für die Active-Directory-basierte Aktivierung, Get-SubscriptionLicenseInfo, Invoke-SubscriptionLicense und Set-SubscriptionLicenseInfo für die Abonnement-Aktivierung sowie Set-OSLicenseInfo zum Setzen des Volumenaktivierungstyps.
Ein Beispiel für die KMS-Konfiguration, die früher über /skms und /ckms lief:
powershell
# Aktuelle KMS-Konfiguration ansehen
Get-KmsLicenseInfo
# Auf einen bestimmten KMS-Host festlegen
Set-KmsLicenseInfo -ServerName 'kms.example.com' -Port 1688
# Server-Überschreibung wieder löschen (Äquivalent zu /ckms)
Invoke-KmsLicense -ClearServerAnders als das kombinierte /ckms nimmt Invoke-KmsLicense für jede Einstellung einen eigenen Schalter: -ClearServer, -ClearPort, -ClearDomain und -ClearListeningPort. Beachten Sie, dass diese Cmdlets keine Sicherheitsabfrage stellen und weder -WhatIf noch -Confirm unterstützen. Prüfen Sie den Ist-Zustand daher vorher mit Get-KmsLicenseInfo.
Grenzen und Stolperfallen
Ein paar Punkte, an denen die Umstellung in der Praxis hakt:
In WinPE und WinRE ist OSLicense nicht verfügbar. Wenn Ihr Imaging-Prozess Windows während der PE-Phase aktiviert, verlagern Sie diesen Schritt in eine Phase nach dem Deployment, in der das vollständige Betriebssystem läuft.
Auf Windows Server 2025 und älter fehlt das Modul noch. Dort läuft slmgr.vbs weiter, es besteht also kein Handlungsdruck, aber eben auch keine Migrationsmöglichkeit.
Beim Remoting hat OSLicense keine eingebauten Parameter für die Ausführung auf entfernten Rechnern. Das war bei slmgr.vbs \\rechnername schon immer unschön und lieferte keine strukturierte Ausgabe. Nutzen Sie stattdessen Invoke-Command über eine PSRemoting-Sitzung.
Und ein Sicherheitshinweis: Manche Ergebnisobjekte enthalten den Produkt-Key in einer eigenen Eigenschaft. Schreiben Sie diesen niemals in Logs oder Transkripte.
Fazit
Die Abkündigung von VBScript ist einer der seltenen Fälle, in denen der erzwungene Umstieg tatsächlich ein Gewinn ist. Das OSLicense-Modul liefert strukturierte Ausgaben, echte Fehlerbehandlung und Cmdlets, die sich sauber in PowerShell-Automatisierung einfügen. So hätte Aktivierungs-Scripting eigentlich schon vor Jahren funktionieren sollen.
Akuten Zeitdruck gibt es dank Phase 1 nicht, doch mit dem Modul auf Windows 11 ist jetzt der richtige Moment, die Bestandsaufnahme zu starten und in der Nicht-Produktion umzustellen. Die Syntax ist schnell gelernt. Die eigentliche Arbeit ist das Aufspüren aller Stellen, an denen slmgr.vbs über die Jahre in Skripte und Tasksequenzen gewandert ist. Wer damit vor Phase 2 durch ist, erspart sich das böse Erwachen, wenn die unbeaufsichtigten Jobs eines Tages still ihren Dienst quittieren.