Sysadmins verwenden WMI schon seit Jahren, und mit der Einführung von PowerShell v3.0 hat Microsoft uns den Datenzugriff über CIM ermöglicht. Was ist der Unterschied zwischen diesen Verwaltungsschnittstellen? Welche sollten Sie verwenden, und warum?
Eine Geschichtsstunde über WMI und CMI
Windows Management Interface (WMI) ist eine bekannte Verwaltungsschnittstelle, die auf Daten über einen Computer zugreifen kann. Weniger bekannt ist, dass WMI auf dem "Common Information Model"-Standard basiert, mit dem verwaltete Daten in einem leicht lesbaren Format angezeigt werden können. Wenn Sie genau hinschauen, werden Sie sehen, dass die Abkürzung für Common Information Model CIM lautet. Warten Sie. Was ist das? Sind CIM und WMI nicht verschieden? Eigentlich haben sie mehr gemeinsam als nicht. Schauen wir uns das Ganze einmal genauer an.
Automatisieren mit PowerShell. E-Book jetzt herunterladen >>
WMI & CIM: Netzwerkanforderungen
Es ist leicht zu erkennen, dass WMI und CIM auf denselben Datensatz zugreifen. Hier frage ich den Win32_operatingsystem Datenspeicher mit jedem Cmdlet ab und Sie werden feststellen, dass die Ausgabe identisch ist:
PS C:\> Get-WmiObject-win32_operatingsystem | Format-Liste
Systemverzeichnis : C:\WINDOWS\system32
Organisation:
BuildNummer : 17763
RegistriertBenutzer : Windows-Benutzer
Seriennummer : 00331-60000-00000-AA085
Ausführung : 10.0.17763
PS C:\> Get-CimInstance Win32_OperatingSystem | Format-Liste
Systemverzeichnis : C:\WINDOWS\system32
Organisation:
BuildNummer : 17763
RegistriertBenutzer : Windows-Benutzer
Seriennummer : 00331-60000-00000-AA085
Ausführung : 10.0.17763
Denken Sie daran, in diesem Beispiel; Ich habe Daten von meinem lokalen PC abgefragt. Beim Zugriff auf lokale Daten sind WMI und CIM bis auf geringfügige kosmetische Unterschiede in der Ausgabe nahezu identisch. Der Zugriff von einem Remote-PC aus unterscheidet sich jedoch auf Netzwerkebene zwischen den beiden. Damit eine WMI-Verbindung erfolgreich ist, muss der Remotecomputer eingehenden Netzwerkverkehr an den TCP-Ports 135, 445 und zusätzlichen dynamisch zugewiesenen Ports zwischen 1024 und 1034 zulassen. Der dynamische Bereich der Ports und die Anzahl der Ports, die für eine erfolgreiche Verbindung erforderlich sind, machen Sicherheitsexperten nervös bei der Verwendung von WMI in einem Unternehmensnetzwerk.
Im Jahr 2012 hat Microsoft diese Bedenken durch die Veröffentlichung einer neuen Version von WMI namens Windows Remote Management (WinRM) oder häufiger als PSRemoting bezeichnet. Es verwendet das Web Services for Management-Protokoll (WS-Man) für die Datenübertragung zwischen Computern anstelle von DCOM und benötigt nur zwei Ports, um eine sichere Verbindung herzustellen.
Aus Sicherheitsgründen ist die Standardkonfiguration für PSRemoting standardmäßig sicher. Die Windows-Remoteverwaltung (Windows Remote Management, WinRM) ist der Dienst auf einem Windows-Computer, der die Verbindung zu einem anderen Computer in einem Windows-Netzwerk herstellt und aufrechterhält. WinRM verwendet das WSMan-Protokoll, um Daten sicher zwischen Computern zu übertragen. Das WSMan-Protokoll verwendet die Ports 5985 und 5986, und diese Ports werden über HTTP und HTTPS verbunden. Der gesamte Datenverkehr wird standardmäßig verschlüsselt, auch wenn ein unsicheres Protokoll wie HTTP verwendet wird. Außerdem nutzt PSRemoting Active Directory für die Authentifizierung. Standardmäßig verwendet PSRemoting Kerberos, um Benutzer zu authentifizieren und zu bestimmen, welche Zugriffsebene sie auf dem Remotecomputer haben sollten. WMI verfügt über ähnliche Steuerelemente, die Sie einrichten können, aber sie sind viel schwieriger zu konfigurieren und standardmäßig nicht sicher.
Was steckt in einem Namen?
In PowerShell v3.0 wurden neue Cmdlets erstellt, um WinRM zu nutzen. Diese neuen Cmdlets werden als "CIM-basierte" Cmdlets bezeichnet, d. h. sie funktionieren mit dem CIM-Standard. CIM ist im Namen fast aller Cmdlets angegeben. Die einzige Ausnahme ist Invoke-Command:
PS C:\> Get-Command -noun cimsession
CommandType Name Versionsquelle
----------- ---- ------- ------
Cmdlet Get-CimSession 1.0.0.0 CimCmdlets
Cmdlet New-CimSession 1.0.0.0 CimCmdlets
Cmdlet Remove-CimSession 1.0.0.0 CimCmdlets
PS C:\> Get-Command -noun ciminstance
CommandType Name Versionsquelle
----------- ---- ------- ------
Cmdlet Get-CimInstance 1.0.0.0 CimCmdlets
Cmdlet New-CimInstance 1.0.0.0 CimCmdlets
Cmdlet Remove-CimInstance 1.0.0.0 CimCmdlets
Cmdlet Set-CimInstance 1.0.0.0 CimCmdlets
Jedes Mal, wenn Sie diese Cmdlets verwenden, verwenden Sie die sicherere Methode der Datenübertragung, die als PSRemoting bezeichnet wird. Die Verwirrung kommt von Microsoft, das den Namen CIM in den Cmdlets verwendet. Das ist eine etwas falsche Bezeichnung, da die älteren WMI-Cmdlets UND die neuen CIM-Cmdlets alle CIM-basiert sind. Der Unterschied zwischen WMI- und CIM-Cmdlets besteht in den Protokollen und der Sicherheit, die beim Zugriff auf einen Remotecomputer verwendet werden. Sobald sie zum Remotecomputer gelangen und sich authentifizieren, greifen WMI und CIM auf dieselben Daten zu.
Welches sollten Sie verwenden?
Zweifellos ist WMI veraltet. PowerShell verlässt sich heute stark auf PSRemoting und die enthaltenen Sicherheitsfunktionen. Microsoft hat die CIM-basierten Cmdlets und PSRemoting mit PowerShell v3.0 eingeführt. Jeder Computer unter Windows 7 oder höher und Server 2008 SP2 und höher kann UND sollte PSRemoting anstelle von WMI verwenden. Wenn Sie einen modernen Computer haben, können UND sollten Sie PSRemoting verwenden. Der Wechsel von WMI zu CIM ist in der Regel so einfach wie das Austauschen des Cmdlets Get-WMIObject durch Get-CIMInstance. Wenn Sie den Wechsel vornehmen, erhöhen Sie Ihre Sicherheit erheblich.
Es ist bedauerlich, dass Microsoft das Wort CIM in ihren neueren Cmdlets verwendet hat. CIM wurde schon immer verwendet, aber die neuen Cmdlets lassen es so aussehen, als wäre CIM etwas Neues. Nachdem Sie nun den Verlauf und die Unterschiede zwischen WMI und CIM kennen, empfehle ich Ihnen, WMI nach Möglichkeit nicht mehr zu verwenden und durch PSRemoting- und CIm-basierte Cmdlets zu ersetzen.