Windows 11: slmgr.vbs wird durch das PowerShell-Modul OSLicense ersetzt

Microsoft löst das Aktivierungsskript slmgr.vbs ab. An seine Stelle tritt das PowerShell-Modul OSLicense, das laut offizieller Microsoft-Dokumentation elf Cmdlets für Windows-Lizenzierung, KMS, Active-Directory-basierte Aktivierung und Subscription-Lizenzen mitbringt. Das Modul ist in Windows 11 25H2 vorhanden und wurde für 24H2 mit dem Preview-Update KB5120998 vom 27. August 2026 nachgeliefert. Es gibt heute nichts zu patchen und keine Sicherheitslücke zu schließen, aber es gibt etwas zu inventarisieren.

Betroffen sind Umgebungen, in denen Skripte, Softwareverteilung, Betriebssystem-Images, geplante Aufgaben, MDM-Skripte oder Runbooks den Aufruf slmgr.vbs enthalten. Nicht betroffen sind Endanwender, die Windows 11 über die Einstellungen-Seite mit Produktschlüssel aktivieren. Ebenfalls nicht umstellbar sind derzeit Windows-Server-Systeme, denn dort steht das Modul noch gar nicht zur Verfügung. Wer gemischte Umgebungen betreibt, kann also nicht pauschal umstellen, sondern braucht übergangsweise beide Wege parallel. Ein konkretes Abschaltdatum für VBScript hat Microsoft bislang nicht genannt, die Umstellung gehört daher in die Jahresplanung und nicht in das nächste Notfallfenster.

Was ist passiert?

Günter Born hat am 21. September 2026 in seinem Blog darauf hingewiesen, dass Administratoren mittelfristig von slmgr.vbs auf ein PowerShell-Modul namens OSLicense wechseln müssen. Er bezieht sich dabei auf einen Beitrag von Wolfgang Sommergut vom 14. September 2026, wonach Microsoft das Skript durch elf Cmdlets des Moduls OSLicense ersetzt.

Die Datei slmgr.vbs ist ein fest in Windows integriertes Skript zur Verwaltung der Softwarelizenzierung und zur Aktivierung des Betriebssystems über die Befehlszeile. Sie unterstützt unter anderem das Verlängern der Aktivierungs-Karenzzeit und die Problembehandlung bei Aktivierungsproblemen. Die Befehlszeilenoptionen sind seit Jahren in einem Microsoft-Support-Beitrag dokumentiert und in vielen Admin-Werkzeugkästen fest verankert.

Der Auslöser für die Ablösung ist nicht die Lizenzierung selbst, sondern VBScript. Microsoft hat die Unterstützung für VBScript in Windows bereits 2024 aus Sicherheitsgründen abgekündigt. Im Techcommunity-Beitrag VBScript deprecation: Timelines and next steps vom 22. Mai 2024 hat das Unternehmen einen dreistufigen Plan skizziert. In Phase 1 sind die VBScript-Features on Demand in Windows 11 24H2 vorinstalliert und standardmäßig aktiv. Phase 2 beginnt laut Microsoft etwa im Jahr 2027, ab dann sind diese Features on Demand nicht mehr standardmäßig aktiviert und müssen bei Bedarf manuell nachinstalliert werden. In Phase 3 werden die VBScript-Bibliotheken vollständig aus Windows entfernt, danach funktionieren Projekte mit VBScript-Abhängigkeit nicht mehr. Born schätzt, dass Phase 2 mit Windows 11 27H2 greifen wird. Das ist ausdrücklich seine Einschätzung und keine Ankündigung von Microsoft.

Den Ersatz hat Microsoft inzwischen dokumentiert. Das Modul OSLicense stellt Befehle bereit, um Windows-Lizenzinformationen abzurufen, die Aktivierung zu konfigurieren und Lizenzierung für Betriebssystem, Active-Directory-basierte Aktivierung, Key Management Service und Subscription-Lizenzen zu verwalten. Die Dokumentation nennt Windows PowerShell 5.1 als Voraussetzung und listet folgende elf Cmdlets: Get-ADLicenseInfo, Get-KmsLicenseInfo, Get-OSLicenseInfo, Get-SubscriptionLicenseInfo, Invoke-ADLicense, Invoke-KmsLicense, Invoke-OSLicense, Invoke-SubscriptionLicense, Set-KmsLicenseInfo, Set-OSLicenseInfo und Set-SubscriptionLicenseInfo. Wer sich den Bestand auf einem konkreten System ansehen will, kann ihn ohne Vorwissen über die Namen abfragen:

Get-Command -Module OSLicense

Für wen ist das relevant?

Der Kreis ist enger, als die Meldung zunächst klingt, dafür trifft es die Betroffenen an einer unangenehmen Stelle, nämlich in der Automatisierung.

• Unternehmen mit eigenen Aktivierungs- oder KMS-Skripten. Überall dort, wo Aktivierung, Karenzzeit-Verlängerung oder KMS-Konfiguration skriptgesteuert läuft, steht mittelfristig eine Umstellung an.
• Image-Bau und Betriebssystem-Bereitstellung. Referenz-Images, Antwortdateien, Nachbereitungsskripte und Deployment-Task-Sequenzen rufen häufig slmgr.vbs auf, oft an einer Stelle, die seit Jahren niemand angefasst hat.
• Onboarding-Automatisierung und MDM. Geräteprovisionierung über Intune-Skripte, Anmeldeskripte oder geplante Aufgaben kann denselben Aufruf enthalten.
• Dokumentation und Runbooks. Auch Handbücher, Wiki-Seiten und Support-Anleitungen, die Kollegen im Störungsfall abarbeiten, gehören zum Bestand.
• Nicht betroffen: Endanwender. Wer Windows 11 über Einstellungen und Produktschlüssel aktiviert, merkt von der Umstellung voraussichtlich nichts.
• Vorerst nicht umstellbar: Windows Server. Das Modul soll auf Windows Server erst mit dem nächsten Major Release ankommen, vermutlich 2028. Bis dahin bleibt dort der bisherige Weg der einzige.

Die Verfügbarkeit ist ebenfalls eine Bedingung, die sich prüfen lässt: Windows 11 25H2 bringt das Modul mit, Windows 11 24H2 bekommt es seit dem Preview-Update KB5120998 vom 27. August 2026. Auf älteren Ständen ist es schlicht nicht vorhanden, ein umgestelltes Skript liefe dort ins Leere.

Wie kritisch ist das?

Das ist keine Schwachstelle und kein Vorfall. Es gibt kein Update, das heute eingespielt werden müsste, und keinen Angriffsweg, der durch Abwarten offen bliebe. Die Dringlichkeit ergibt sich allein aus der Vorlaufzeit: Wenn Phase 2 der VBScript-Abkündigung wie von Microsoft skizziert etwa 2027 beginnt, fällt slmgr.vbs nicht abrupt aus, sondern hängt ab diesem Zeitpunkt an einem Feature on Demand, das nicht mehr von selbst aktiv ist. Erst in Phase 3 verschwindet VBScript vollständig, und dafür nennt Microsoft bislang kein Datum.

Praktisch heißt das: mittlere Dringlichkeit, planbar, aber nicht ignorierbar. Unangenehm wird es nicht am Tag der Umstellung, sondern dann, wenn ein Deployment-Skript in einem neuen Windows-Build stillschweigend nichts mehr tut und die Aktivierung erst beim Ablauf der Karenzzeit auffällt. Fehler dieser Art zeigen sich spät und an der falschen Stelle. Wer den Bestand jetzt kennt, hat später nur noch eine überschaubare Änderungsliste statt einer Suche unter Zeitdruck.

Was sollten Admins jetzt tun?

• Bestand aufnehmen. Dateifreigaben, Skript-Repositorys, MDM- und Intune-Skripte, Image-Bau-Verzeichnisse, geplante Aufgaben und die eigene Dokumentation nach der Zeichenfolge slmgr durchsuchen. Das ist der erste und wichtigste Schritt, alles Weitere hängt vom Ergebnis ab.
• Versionsstand prüfen. Feststellen, auf welchen Clients Windows 11 25H2 läuft oder 24H2 mit installiertem KB5120998. Nur dort ist das Modul überhaupt vorhanden.
• Auf einem Testsystem verifizieren. Mit Get-Command -Module OSLicense prüfen, ob das Modul geladen wird und welche Cmdlets die jeweilige Build-Version tatsächlich mitbringt, statt sich auf die Dokumentation allein zu verlassen.
• Umstellung planen, Server ausklammern. Die Migration der eigenen Skripte terminieren, dabei Windows-Server-Systeme ausdrücklich ausnehmen. Wo Skripte gegen Clients und Server gleichzeitig laufen, einen Zweig für beide Wege vorsehen, statt eine der beiden Plattformen zu brechen.
• Weitere VBScript-Abhängigkeiten miterfassen. Die Abkündigung betrifft nicht nur slmgr.vbs. Nach .vbs-Dateien, cscript- und wscript-Aufrufen suchen und die Treffer auf dieselbe Liste setzen.
• Dokumentation und Runbooks nachziehen. Anleitungen, die Kollegen im Störungsfall abarbeiten, müssen den neuen Weg enthalten, sobald er produktiv ist. Ein Runbook mit einem Befehl, den es nicht mehr gibt, kostet im Ernstfall genau die Zeit, die nicht da ist.
• Keine hektische Umstellung. Solange Phase 2 nicht begonnen hat, funktioniert der bisherige Weg unverändert. Ein Umbau ohne Test im laufenden Betrieb bringt mehr Risiko als Nutzen.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist das vor allem eine Aufgabe der Bestandspflege. Wer Windows über die Einstellungen aktiviert und keine eigene Automatisierung betreibt, muss nichts tun. Wer dagegen über die Jahre eine gewachsene Skriptsammlung für Bereitstellung und Aktivierung angelegt hat, sollte sie jetzt einmal durchsehen, solange der alte Weg noch funktioniert und ein Vergleich zwischen beiden Varianten problemlos möglich ist.

Der Fall reiht sich in ein Muster ein, das Administratoren aus den vergangenen Jahren kennen: Microsoft ersetzt ältere Befehlszeilenwerkzeuge schrittweise durch PowerShell. Wer bereits eine Migration dieser Art hinter sich hat, kann dasselbe Vorgehen anwenden, nämlich Bestand suchen, Ersatz auf einem Testsystem prüfen, Skripte umbauen, Dokumentation nachziehen. Neu ist hier vor allem die Besonderheit, dass Client und Server über längere Zeit auseinanderlaufen. Diese Lücke von voraussichtlich mehreren Jahren ist der Punkt, an dem eine zu früh angesetzte pauschale Umstellung tatsächlich Schaden anrichten kann.

Offen bleibt, wann VBScript endgültig verschwindet. Microsoft nennt für Phase 3 kein Datum, und auch die Zuordnung von Phase 2 zu einer konkreten Windows-Version ist bislang eine Einschätzung aus der Fachpresse, keine Herstellerangabe. Beides spricht dafür, die Umstellung zu planen, aber nicht zu überstürzen.

Passende Anleitungen auf S-EDV

• WMIC verschwindet aus Windows 11: So migrieren Admins ihre Skripte beschreibt denselben Ablauf für ein anderes abgekündigtes Werkzeug und eignet sich als Vorlage für die Bestandsaufnahme.
• PowerShell-Grundlagen für Windows-Admins hilft beim Umbau der bisherigen Befehlszeilenaufrufe auf Cmdlets und beim Umgang mit Modulen.
• Windows Server 2025 Lizenzierung: Cores und CALs erklärt ordnet die Lizenzseite für die Server-Umgebungen ein, die vorerst beim bisherigen Weg bleiben.

Quellen

• Borns IT- und Windows-Blog: Windows 11: slmgr.vbs wird künftig durch OSLicense PS-Modul ersetzt, 21. September 2026
• Microsoft Learn: OSLicense Module, offizielle Dokumentation der elf Cmdlets
• Microsoft Techcommunity: VBScript deprecation: Timelines and next steps, 22. Mai 2024
• Microsoft Learn: Slmgr.vbs Options for Obtaining Volume Activation Information