WMIC und VBScript ablösen: die Abfragen nach PowerShell übersetzen
WMI bleibt, nur das Werkzeug davor verschwindet. Deshalb ist der Umbau in den meisten Fällen eine Übersetzung Zeile für Zeile und keine Neuentwicklung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Aufrufe stehen nicht im Code, sondern an fünfzehn Stellen daneben
Wenn jemand fragt, ob im Haus noch WMIC benutzt wird, lautet die Antwort fast immer nein, und fast immer stimmt sie nicht. WMIC steckt selten in einem Programm, das jemand betreut. Es steckt in der einen Zeile eines Anmeldeskripts, die die Seriennummer in eine Datei schreibt, in dem Aufruf einer Installationsroutine, der vorher prüft, ob ein Produkt schon vorhanden ist, in der Aufgabenplanung eines Servers, den vor sechs Jahren jemand aufgesetzt hat, und in einer Batchdatei, die ein Monitoringwerkzeug ausführt.
Bei VBScript ist es dasselbe Muster mit anderen Dateiendungen. Ein .vbs, das über die Gruppenrichtlinie beim Anmelden startet. Ein .wsf, das ein Drucker-Setup erledigt. Ein Codeschnipsel in einer Softwareverteilung, der mit GetObject und dem Namensraum winmgmts arbeitet. Keiner dieser Aufrufe ist groß, keiner ist dokumentiert, und alle zusammen sind der Grund, warum ein Serverwechsel drei Wochen nach dem Termin noch Nacharbeiten produziert.
Die Zeitfrage ist dabei entspannter, als sie klingt, und genau deshalb schiebt man das Thema. In Windows Server 2025 sind beide Werkzeuge noch verfügbar, WMIC muss nachinstalliert werden, VBScript ist vorhanden. Microsoft schreibt aber für beide, dass sie in einer späteren Fassung entfernt werden. Wer den Umbau erst dann angeht, macht ihn unter Zeitdruck und parallel zu einer Migration. Wer ihn jetzt macht, macht ihn auf laufenden Servern und kann jeden Aufruf einzeln vergleichen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ablauf in sechs Schritten
Die Reihenfolge ist so gewählt, dass ihr jederzeit anhalten könnt. Nach jedem Schritt ist die Umgebung in einem Zustand, in dem beide Wege funktionieren, und erst der letzte Schritt entfernt etwas.
- 1
Den Bestand finden, und zwar an allen fünf Orten
Such nicht nur in der Skriptablage. Betroffen sind erfahrungsgemäß fünf Orte: die Freigabe mit den Verwaltungsskripten, das SYSVOL mit den Anmelde- und Startskripten aus den Gruppenrichtlinien, die Aufgabenplanung auf den Servern, die Installationspakete und Antwortdateien der Softwareverteilung sowie die Autostart-Einträge in der Registrierung. Durchsuch die Dateiablagen mit Select-String nach den Zeichenfolgen wmic, cscript, wscript und winmgmts sowie nach den Endungen .vbs, .vbe, .wsf und .wsh. Auf den Servern selbst listet Get-ScheduledTask die geplanten Aufgaben samt der Programme, die sie starten. Halt jeden Fund mit Ort, Zweck und Zuständigkeit fest, denn diese Liste ist die eigentliche Arbeitsgrundlage.
Geschafft, wenn: Es gibt eine vollständige Liste der Aufrufe mit Fundort, statt einer Vermutung darüber, wo überall noch etwas steckt.
- 2
Nach Wirkung und Risiko sortieren
Teil die Liste in drei Gruppen. In die erste kommen reine Abfragen, die nur etwas auslesen und in eine Datei oder auf den Bildschirm schreiben. Sie machen meistens den größten Teil aus und sind gleichzeitig die einfachste Übung, weil ein Fehler dort nichts kaputt macht. In die zweite Gruppe kommen Aufrufe, die etwas verändern, also Dienste starten, Prozesse beenden, Software installieren oder deinstallieren, Einstellungen setzen. In die dritte kommt alles, was an einem Geschäftsablauf hängt oder an einem Termin, etwa ein nächtlicher Lauf, dessen Ergebnis am Morgen jemand erwartet. Arbeite die Gruppen in dieser Reihenfolge ab, dann sammelst du Sicherheit an den Fällen, bei denen sie nichts kostet.
Geschafft, wenn: Die Reihenfolge steht fest, und ihr fangt mit den Aufrufen an, bei denen ein Fehler folgenlos bleibt.
- 3
Die Abfragen Zeile für Zeile übersetzen
Der Kern des Umbaus ist eine Zuordnung: Der WMIC-Alias steht für eine WMI-Klasse, und diese Klasse gibst du bei Get-CimInstance an. Aus wmic bios get serialnumber wird Get-CimInstance -ClassName Win32_BIOS, aus wmic os get caption,version wird Get-CimInstance -ClassName Win32_OperatingSystem, aus wmic logicaldisk get deviceid,freespace wird Get-CimInstance -ClassName Win32_LogicalDisk, aus wmic qfe list wird Get-CimInstance -ClassName Win32_QuickFixEngineering, und aus wmic nicconfig list wird Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration. Eine Bedingung, die in WMIC hinter where stand, gehört entweder in den Parameter -Filter oder in ein nachgeschaltetes Where-Object. Und wenn in einem VBScript ohnehin eine Abfrage in der WMI-Abfragesprache steht, kannst du sie unverändert an Get-CimInstance -Query übergeben, was den ersten Umbau erheblich beschleunigt.
Geschafft, wenn: Alle reinen Abfragen laufen über die CIM-Cmdlets und liefern dieselben Werte wie vorher.
- 4
Methodenaufrufe umstellen und dabei aufräumen
Alles, was in WMIC hinter call stand, wird zu Invoke-CimMethod. Bevor du das eins zu eins übersetzt, prüf aber, ob es für die Aufgabe nicht längst ein eigenes Cmdlet gibt, denn das ist fast immer der kürzere und robustere Weg. Für Dienste gibt es Get-Service, Start-Service, Stop-Service und Restart-Service, für Prozesse Get-Process und Stop-Process, für den Neustart Restart-Computer, für lokale Konten und Gruppen eigene Cmdlets, für installierte Updates Get-HotFix. Eine Warnung gehört an diese Stelle: Die Klasse Win32_Product ist nicht abfrageoptimiert, und Microsoft weist ausdrücklich darauf hin, dass eine Abfrage darauf eine Konsistenzprüfung aller installierten Pakete anstößt, die Pakete überprüft und repariert. Für eine Softwareinventur ist sie deshalb die falsche Wahl.
Geschafft, wenn: Die verändernden Aufrufe laufen über die vorgesehenen Cmdlets, und die bekannten Fallen sind umgangen.
- 5
Remote-Aufrufe auf CIM-Sitzungen umstellen
WMIC hatte für mehrere Rechner den Schalter /node:, PowerShell hat dafür Sitzungen. Leg mit New-CimSession eine Verbindung an, gib dabei mit -Credential die passenden Anmeldedaten mit, und übergib die Sitzung anschließend mit -CimSession an jede Abfrage. Der Unterschied zum Rechnernamen an der Abfrage ist doppelt: Die Verbindung wird nur einmal aufgebaut, und du kannst abweichende Anmeldedaten benutzen, ohne die ganze PowerShell mit erhöhten Rechten zu starten. Get-CimInstance benutzt dabei standardmäßig WSMan, wofür das Gegenüber eine ausreichend aktuelle Verwaltungsschnittstelle braucht. Für ältere Systeme erzeugst du mit New-CimSessionOption -Protocol Dcom eine Sitzung über das alte Protokoll, und dann muss auf dem Ziel nicht einmal PowerShell installiert sein. Mit Get-CimSession siehst du, welche Sitzungen offen sind und über welches Protokoll sie laufen, mit Remove-CimSession räumst du sie wieder ab.
Geschafft, wenn: Abfragen über mehrere Server laufen über wiederverwendbare Sitzungen, auch gegen ältere Systeme.
- 6
Vergleichen, ablösen und die Nachinstallation verhindern
Lass beide Wege eine Weile parallel laufen und vergleich die Ergebnisse, denn WMIC liefert Text und PowerShell liefert Objekte, und alles, was die Ausgabe weiterverarbeitet, merkt den Unterschied. Erst wenn das passt, entfernst du den alten Aufruf, und zwar an der Stelle, an der du ihn gefunden hast, nicht nur in der Kopie in der Ablage. Zum Abschluss gehört eine Festlegung für die Zukunft: In Windows Server 2025 sind WMIC und VBScript Features on Demand, WMIC lässt sich mit dem Befehl DISM /Add-Capability nachinstallieren. Genau das sollte in eurer Umgebung nicht mehr passieren, weil damit ein abgelöster Aufruf wieder funktioniert und der nächste Server erneut mit ihm ausgeliefert wird. Nimm die Nachinstallation in die Vorgaben für neue Server auf und prüf sie bei der Abnahme.
Geschafft, wenn: Die alten Aufrufe sind entfernt, und auf neuen Servern werden die abgekündigten Werkzeuge nicht mehr nachgerüstet.
Fünf Schritte, und der alte Aufruf ist abgelöst
- 01 Alle Ablagen, Anmeldeskripte und geplanten Aufgaben nach wmic, cscript und .vbs durchsuchen.
- 02 Jeden Fund danach sortieren, ob er nur abfragt oder etwas verändert.
- 03 Abfragen auf Get-CimInstance mit derselben WMI-Klasse umschreiben.
- 04 Methodenaufrufe auf Invoke-CimMethod oder auf das passende Cmdlet umstellen.
- 05 Beide Wege eine Zeit lang vergleichen, dann den alten Aufruf entfernen.
Was den Umbau klein hält
Sechs Festlegungen, die den Unterschied zwischen einer Übersetzung und einer Neuentwicklung ausmachen. Der wichtigste Punkt zuerst: WMI selbst ist nicht betroffen, deshalb bleiben Klassennamen, Eigenschaften und Methoden dieselben.
WMI bleibt, nur das Werkzeug geht
Die Abkündigung betrifft ausdrücklich das Kommandozeilenwerkzeug WMIC und nicht Windows Management Instrumentation. Jede Klasse, die ihr heute abfragt, gibt es weiterhin, und die Eigenschaften heißen genauso. Aus wmic bios get serialnumber wird deshalb ein Get-CimInstance auf dieselbe Klasse und nicht eine neue Idee, wie man an die Seriennummer kommt.
Die CIM-Cmdlets nehmen, nicht die alten WMI-Cmdlets
In Windows PowerShell gibt es beide Familien nebeneinander. Get-WmiObject und seine Verwandten sind abgekündigt und in PowerShell 6 und höher gar nicht mehr enthalten. Wer heute umbaut und dabei auf Get-WmiObject landet, hat den Umbau in ein paar Jahren erneut vor sich. Nimm von Anfang an Get-CimInstance, Invoke-CimMethod und die übrigen Cmdlets aus dem Modul CimCmdlets.
Wo es ein spezialisiertes Cmdlet gibt, nimm das
Für viele Aufgaben braucht es gar keinen Umweg über WMI. Statt eine Dienstklasse abzufragen, nimmst du Get-Service, statt eine Methode für den Neustart aufzurufen, nimmst du Restart-Computer, statt Benutzerkonten über WMI zu lesen, nimmst du die Cmdlets für lokale Konten. Das ist kürzer, schneller und liefert Objekte, mit denen sich weiterarbeiten lässt.
Für Remote-Abfragen eine CIM-Sitzung aufbauen
Der Schalter /node: von WMIC hat kein direktes Gegenstück, und Get-CimInstance selbst kennt keinen Parameter für abweichende Anmeldedaten. Der vorgesehene Weg ist New-CimSession, danach übergibst du die Sitzung an die Abfragen. Das ist bei mehreren Abfragen gegen denselben Server auch die schnellere Variante, weil die Verbindung nur einmal aufgebaut wird.
Nur die Eigenschaften holen, die du brauchst
Eine WMI-Abfrage holt im Hintergrund eine Reihe von Eigenschaften mit, die niemand ansieht. Lokal fällt das nicht auf, über das Netz schon. Get-CimInstance hat dafür den Parameter -Property, und der begrenzt die Abfrage, bevor die Daten den anderen Server verlassen. Bei einem Lauf über hundert Systeme ist das der Unterschied zwischen Sekunden und Minuten.
Die Ausgabe vergleichen, bevor der alte Aufruf verschwindet
WMIC gibt Text aus, PowerShell gibt Objekte aus. Was danach in eine Datei geschrieben wird, sieht deshalb anders aus, auch wenn derselbe Wert dahintersteht. Lass beide Aufrufe eine Zeit lang nebeneinander laufen und vergleich die Ergebnisse, bevor du den alten entfernst, sonst fällt der Unterschied erst dem Werkzeug auf, das die Datei weiterverarbeitet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was genau abgekündigt ist, und was bleibt
Die Dokumentation von Microsoft trennt hier sauber, und das ist für die Planung wichtig. WMIC ist abgekündigt seit Windows 10 in der Fassung 21H1 und seit der entsprechenden Fassung im halbjährlichen Kanal von Windows Server. Ausdrücklich betrifft das nur das Kommandozeilenwerkzeug. Windows Management Instrumentation selbst ist davon nicht berührt, die Klassen bleiben, die Eigenschaften bleiben, die Methoden bleiben. Als Nachfolger nennt Microsoft PowerShell für WMI.
Für Windows Server 2025 steht es noch konkreter in der Liste der entfernten und nicht mehr weiterentwickelten Funktionen: WMIC ist dort ein Feature on Demand und lässt sich mit DISM /Add-Capability hinzufügen, wird aber in einer künftigen Fassung von Windows entfernt. VBScript ist ebenfalls als Feature on Demand geführt, in Windows Server 2025 allerdings vorinstalliert, ebenfalls vor der Entfernung in einer späteren Fassung. Als Ersatz nennt Microsoft in beiden Fällen PowerShell.
Zwei weitere Punkte aus derselben Liste gehören zur Planung, weil sie oft im selben Skript stecken. Windows PowerShell 2.0 ist mit dem Update vom September 2025 aus Windows Server 2025 entfernt worden, und wer es vorher installiert hatte, kann es danach nicht mehr benutzen. Und WinRM.vbs gilt bereits seit Windows Server 2016 als abgekündigt, mit dem Hinweis, stattdessen die entsprechenden Möglichkeiten in PowerShell zu benutzen. Wenn ihr also ein Altskript anfasst, lohnt es sich, gleich nach diesen beiden mitzusuchen.
Zwei Familien von Cmdlets, und nur eine hat Zukunft
In Windows PowerShell 5.1 gibt es zwei Wege zu WMI. Der ältere besteht aus Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject und Set-WmiInstance. Der neuere kam mit PowerShell 3.0 dazu und steckt im Modul CimCmdlets, dort finden sich unter anderem Get-CimInstance, Set-CimInstance, New-CimInstance, Remove-CimInstance, Invoke-CimMethod, Get-CimClass, Get-CimAssociatedInstance, New-CimSession, New-CimSessionOption, Get-CimSession, Remove-CimSession und Register-CimIndicationEvent.
Die Entscheidung zwischen beiden ist bereits gefallen. Die fünf alten Cmdlets sind abgekündigt und in PowerShell 6 und höher nicht mehr enthalten, weil sie zusammen mit einer Reihe anderer Befehle aus dem Modul Microsoft.PowerShell.Management entfernt wurden. Microsoft formuliert es in der Dokumentation eindeutig: Für neue Entwicklung sind die CIM-Cmdlets zu benutzen. Wer heute ein WMIC-Skript nach Get-WmiObject übersetzt, tauscht also ein abgekündigtes Werkzeug gegen ein zweites.
Der Unterschied liegt nicht nur im Namen. Die alten Cmdlets sprechen DCOM, und DCOM wird von der Firewall auf neueren Windows-Fassungen üblicherweise blockiert. Get-CimInstance benutzt standardmäßig WSMan, also denselben Weg, den auch die übrige Fernverwaltung von Windows geht. Das alte Protokoll steht weiterhin zur Verfügung, wenn ihr es braucht, aber es ist dann eine bewusste Entscheidung für einen bestimmten Zielserver und nicht mehr die Voreinstellung für alles.
Die Übersetzungstabelle, die den größten Teil abdeckt
In der Praxis decken ein gutes Dutzend Zuordnungen fast alles ab, was im Bestand steckt. Für Hardware und Firmware: wmic bios wird zu Win32_BIOS, wmic csproduct zu Win32_ComputerSystemProduct, wmic computersystem zu Win32_ComputerSystem, wmic cpu zu Win32_Processor, wmic memorychip zu Win32_PhysicalMemory, wmic diskdrive zu Win32_DiskDrive. Für das Betriebssystem: wmic os zu Win32_OperatingSystem, wmic qfe zu Win32_QuickFixEngineering, wmic logicaldisk zu Win32_LogicalDisk. Für Prozesse und Dienste: wmic process zu Win32_Process, wmic service zu Win32_Service. Für das Netz: wmic nic zu Win32_NetworkAdapter, wmic nicconfig zu Win32_NetworkAdapterConfiguration. Für Konten: wmic useraccount zu Win32_UserAccount.
Die Bedingungen übersetzen sich ähnlich mechanisch. Was in WMIC hinter where stand, kann bei Get-CimInstance in den Parameter -Filter, und dort gilt die Syntax der WMI-Abfragesprache, also etwa ein Vergleich mit einem einfachen Gleichheitszeichen und Zeichenketten in Anführungszeichen. Alternativ filterst du hinterher mit Where-Object, was bequemer zu schreiben ist, aber alle Objekte über die Leitung holt. Bei Abfragen über das Netz lohnt sich deshalb der Filter in der Abfrage, bei lokalen Abfragen ist es Geschmackssache.
Bei VBScript ist der Einstieg sogar noch einfacher, wenn im Skript eine ausformulierte Abfrage steht. Ein Aufruf in der Form ExecQuery mit einer Zeichenkette wie Select * from Win32_BIOS lässt sich unverändert an Get-CimInstance -Query übergeben, und ihr bekommt dasselbe Ergebnis als Objekt statt als Auflistung. Für den ersten Durchgang ist das die schnellste Variante, weil ihr die Logik nicht anfassen müsst. Im zweiten Durchgang schreibt ihr die Abfrage dann auf die kürzere Form mit -ClassName um, weil sie besser lesbar ist und sich mit -Property begrenzen lässt.
Was beim Umschreiben schiefgeht
Der häufigste Stolperstein ist die Ausgabe. WMIC schreibt Text, in Spalten ausgerichtet, mit Überschriften und je nach Schalter im HTML- oder CSV-Format. PowerShell gibt Objekte zurück, die auf dem Bildschirm formatiert werden. Wenn am Ende der Kette eine Datei steht, die ein anderes Werkzeug einliest, ändert sich damit das Dateiformat, auch wenn dieselben Werte darin stehen. Die saubere Antwort ist, die Ausgabe ausdrücklich zu erzeugen, also mit Select-Object die gewünschten Eigenschaften zu wählen und mit Export-Csv oder ConvertTo-Json ein definiertes Format zu schreiben, statt sich auf die Bildschirmdarstellung zu verlassen.
Der zweite betrifft Datumsangaben. WMI liefert Zeitpunkte in einem eigenen Format, und WMIC hat sie unverändert ausgegeben. Get-CimInstance wandelt sie in ein echtes Datumsobjekt um, mit dem sich rechnen lässt. Das ist ein Fortschritt und gleichzeitig eine Änderung im Ergebnis, die jedem auffällt, der die alte Zeichenkette weiterverarbeitet hat. Prüf deshalb bei jedem Feld, das ein Datum enthält, was am Ende in der Datei stehen soll, bevor du den alten Aufruf entfernst.
Der dritte ist die Klasse Win32_Product. Sie wirkt naheliegend für eine Softwareinventur, und die Dokumentation von Microsoft warnt ausdrücklich davor: Die Klasse ist nicht abfrageoptimiert, eine Abfrage mit einer Bedingung zwingt WMI dazu, alle installierten Produkte aufzuzählen und die Liste danach zu durchsuchen, und dieser Vorgang stößt zusätzlich eine Konsistenzprüfung der installierten Pakete an, bei der überprüft und repariert wird. Auf einem Server mit vielen Anwendungen ist das keine Abfrage mehr, sondern ein Eingriff. Für eine Inventur ist der übliche Weg deshalb ein Blick in die entsprechenden Einträge der Registrierung.
Was der Umbau nebenbei mitbringt
Der offensichtliche Gewinn ist, dass die Skripte einen Serverwechsel überstehen. Der weniger offensichtliche ist, dass sie danach zusammenarbeiten können. Ein WMIC-Aufruf endet mit Text, und alles, was danach kommt, ist Textverarbeitung mit den bekannten Problemen bei Umlauten, Trennzeichen und Spaltenbreiten. Eine CIM-Abfrage endet mit Objekten, und die lassen sich filtern, sortieren, gruppieren und in ein anderes Cmdlet stecken, ohne dass jemand eine Zeichenkette zerlegen muss.
Der zweite Gewinn ist die Fernverwaltung. Sobald die Abfragen über CIM-Sitzungen laufen, ist der Schritt von einem Server auf hundert nur noch eine Liste von Rechnernamen. Sitzungen lassen sich sammeln, gemeinsam abfragen und gemeinsam abräumen, und die Ergebnisse tragen den Namen des Servers als Eigenschaft mit, sodass am Ende eine auswertbare Tabelle steht statt hundert Textausgaben.
Der dritte Gewinn ist die Nachvollziehbarkeit. Wenn eure Abfragen in einem Modul liegen statt in verstreuten Batchdateien, gibt es eine Fassung, eine Hilfe und eine Stelle, an der jemand etwas ändert. Genau das ist der Grund, warum sich der Umbau lohnt, auch wenn WMIC in eurer Umgebung noch ein paar Jahre laufen würde: Ihr tauscht nicht nur ein Werkzeug, ihr räumt eine Ecke auf, die bisher niemandem gehört hat.
Dazu passende Kurse
Wenn im Bestand noch viele kleine Altskripte stecken, geben Kurse zur Ablösung gewachsener Verwaltungsskripte den Rahmen für den Umbau.
Weil die Abkündigungen zusammen mit dem Versionswechsel auflaufen, gehören Kurse zu den Änderungen in Windows Server 2025 in dieselbe Planung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Ist WMI jetzt abgekündigt?
Läuft WMIC in Windows Server 2025 noch?
Sollen wir auf Get-WmiObject oder auf Get-CimInstance umbauen?
Wie ersetzen wir den Schalter /node: für mehrere Rechner?
Was machen wir mit Servern, auf denen keine aktuelle PowerShell läuft?
Wie finden wir VBScript-Aufrufe, die über Gruppenrichtlinien starten?
Quellen
- Microsoft-Dokumentation zu WMIC mit dem Hinweis auf die Abkündigung
- Entfernte und nicht mehr weiterentwickelte Funktionen in Windows Server
- Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7
- PowerShell 101, Arbeiten mit WMI und den CIM-Cmdlets
- Klasse Win32_Product mit der Warnung zur Konsistenzprüfung
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Den Umbau an euren eigenen Altskripten üben
Bei cmt übersetzt du typische WMIC- und VBScript-Aufrufe in CIM-Abfragen, baust die Fernverwaltung über Sitzungen auf und siehst dabei, an welchen Stellen sich die Ausgabe ändert.