Cmdlets vs. „netsh“, „ipconfig“, „tracert“ & Co. Powershell statt Eingabeaufforderung & CLI
Für die meisten Windows- und Netzwerkadministratoren gehören Kommandos wie „netsh“ oder „ipconfig“ zu Arbeitswerkzeugen, die sie häufig schon unter „Windows XP“ oder einer noch früheren Betriebssystemversion verwendet haben. Doch auf modernen Windows-Systemen können Systemverwalter viele dieser Aufgaben auch wesentlich komfortabler über die Powershell lösen.
Anbieter zum Thema

Wer als System- und/oder Netzwerkadministrator arbeitet, wird sich zwangsläufig auch mit der Kommandozeile und den Befehlen, die dort eingesetzt werden können, auseinandersetzen. Auf den Windows-Systemen hieß diese Schnittstelle schon immer „Eingabeaufforderung“ und hatte bei vielen IT-Profis den Ruf, relativ unhandlich und auch umständlich zu sein. Trotzdem sind Kommandozeilenprogramme wie „ipconfig“ oder „netsh“ bei vielen Administratoren täglich im Einsatz – und wer hat nicht schon mal ein „ping“-Kommando aus der Eingabeaufforderung heraus aufgerufen, um die Erreichbarkeit eines anderen Systems zu testen?
Doch Microsoft hat den Windows-Systemen mit der Powershell in den vergangenen Jahren eine „richtige Shell“ mitgegeben, die sich vor den vielgepriesenen Unix/Linux-Kommandointerpretern sicher nicht verstecken muss. So kommen mit jeder neuen Windows-Version und bei vielen Updates der Betriebssysteme und Server wie „Exchange“ und „SQL Server“ neue Cmdlets hinzu. Gerade mit dem Erscheinen des Windows Servers 2012 R2 und Windows 8.1 hatte Microsoft eine ganze Reihe von neuen und erweiterten Cmdlets für die Arbeit rund um Netzwerke bereitgestellt.
So gibt Microsoft die Zahl der Netzwerk-Cmdlets bereits bei der damals eingeführten Version 3.0 der Powershell mit circa 250 an. Eine Entwicklung, die auch mit Windows 10 und auch mit dem kommenden Windows Server 2016 fortgesetzt wird. Wir möchten hier einige Cmdlets vorstellen, die Administratoren und Anwender nutzen können, um die bisherigen Kommandozeilen-Befehle im täglichen Einsatz zu ersetzen oder zu ergänzen.
Wir gehen im weiteren Verlauf des Artikels davon aus, dass unsere Leser mindestens die Version 3.0 der Powershell auf ihren Systemen einsetzen. Wenn Sie bereits Windows 10 verwenden, arbeiten Sie in der Regel schon mit der Version 5.0 dieses Interpreters. Für den Einstieg ist es sinnvoll, dass sich Anwender zunächst einmal einen Überblick über die aktuell vorhandenen Module und deren Cmdlets verschaffen – auch um festzustellen, welche in Hinblick auf die Arbeit mit dem Netzwerk interessant sind. Der folgende Aufruf bringt alle auf dem jeweiligen System zur Verfügung stehenden Module auf den Bildschirm:
Get-Module -ListAvailable
In der so erstellten Liste finden sich dann einige Module wie „NetAdapter“, „NetSecurity“ oder „NetTCPIP“, die entsprechend Zugriff auf die Netzwerkressourcen zur Verfügung stellen. Wer wissen will, welche Cmdlets diese Module im Einzelnen beinhalten, kann das natürlich auch über die Powershell herausbekommen:
Get-Command -Modul NetAdapter
listet beispielsweise Cmdlets auf, die im Modul „NetAdapter“ zur Verfügung stehen.
Informationen zu den Netzwerkschnittstellen anzeigen
Der Griff zum netsh- oder ipconfig-Kommando ist einer der üblichen Wege, wenn Administratoren an der Kommandozeile auf Netzwerkressourcen zugreifen wollen oder müssen. Diese Software ist sehr mächtig und besitzt mehre Untermenüs, durch die sich der Anwender zunächst einmal hindurcharbeiten muss, will er bestimmte Informationen, wie etwa alle auf dem System installierten Netzwerkschnittstellen anzeigen lassen. Die Powershell besitzt dafür das folgende Cmdlet:
Get- NetAdapter
Durch dessen Aufruf werden alle Schnittstellen angezeigt. Wer es weiter eingrenzen will, kann beispielsweise die folgende Form wählen:
Get-NetAdapter -Name "WLAN"
Diese zeigt dann nur die im System vorhandenen WLAN-Netzwerkschnittstellen auf. Die Flexibilität der Powershell und der Einsatz einer Pipe ermöglichen aber noch weitaus genauere Abfragen. So zeigt der folgende Aufruf alle IP-Adressen auf, die über DHCP vergeben wurden. Dazu kommt hier das Cmdlet „Get-NetIPAdress“ zum Einsatz. Durch die Weiterleitung an Select-Object werden dabei nur die IP-Adresse und die jeweilige Netzwerkschnittstelle der gefundenen Verbindung auf den Bildschirm gebracht:
Get-NetIPAddress |
Where-Object PrefixOrigin -eq dhcp |
Select-Object -Property IPAddress, InterFaceAlias
Wer wissen will, welche Hardware bei seinen Netzwerkadaptern zum Einsatz kommt, kann dazu den folgenden Aufruf verwenden:
Get-NetAdapterHardwareInfo
Da dieses Cmdlet auch den Slot ausgibt, in dem sich die Netzwerkkarte befindet, ist das Kommando für Administratoren bei der Fehlersuche und -beseitigung immer wieder nützlich. Es werden die Informationen zu IP- und DNS-Adresse für eine bestimmte Netzwerkschnittstelle benötigt? Dieser Aufruf bringt sie (mit vielen Informationen) auf den Bildschirm:
Get-Netadapter -Name "Ethernet" | Get-NetIPAddress
Auch das Umbenennen einer Netzwerkschnittstelle ist mit Hilfe der Powershell leicht möglich:
Rename-NetAdapter - Name "Ethernet" -NewName "LANintern"
Allerdings benötigen Administratoren für solche Aktionen die entsprechende Zugriffsberechtigung. Sie sollten deshalb Ihre Powershell für diese Art der Zugriffe immer mit Administratorrechten starten. Wer dann mal wieder auf die „netsh“ wechselt wird auch sehen, dass Microsoft das Tool zwar noch nicht direkt abkündigt, aber schon vage darauf hinweist, dass es diese Funktionalität in „künftigen Windows-Versionen möglicherweise nicht mehr unterstützt wird“.
Variationen von Ping, netstat und tracert inklusive
Zu den häufigsten Kommandos, die nach wie vor direkt von der Eingabeaufforderung aus eingegeben werden, gehört sicher das Programm „ping“. Die Powershell-Variante sieht dann so aus:
Test-Netconnection -Computername "www.redaktionsgemeinschaft.net"
Nun mag es zunächst wenig sinnvoll erscheinen, den einfachen Ping-Befehl durch dieses Cmdlet zu ersetzen. Aber dieser Powershell-Aufruf lässt sich nicht nur deutlich besser in Skripte einbinden (wo dann beispielsweise die Ausgabe weiterverarbeitet werden kann), sondern bietet auch weitere interessante Optionen:
Test-Netconnection -Computername "www.redaktionsgemeinschaft.net"
-DiagnoseRouting -Informationlevel Detailed
Auf diese Weise wird zugleich eine ausführliche Diagnose über die Verbindung zum Remote-System ausgeführt und angezeigt. Wer sich jetzt eher an den Befehl „tracert“ erinnert fühlt, soll natürlich auch dafür ein Powershell-Pendant präsentiert bekommen:
Test-Netconnection -Computername "www.redaktionsgemeinschaft.net" -TraceRoute
Aber das Cmdlet „Test-Netconnection“ kann noch mehr. So kann es beispielsweise dem Administrator auch die Suche nach offenen Ports oder einem bestimmten Port ermöglichen:
Test-NetConnection -Port 80 -InformationLevel "Detailed"
Wenn Administratoren wie hier in unserem Beispiel keinen Remote-Computer als Ziel angeben, verwendet das Cmdlet automatisch einen Default Microsoft-Server mit der Adresse „internetbeacon.msedge.net“. Geht es hingegen darum zu testen, ob die Verbindung auf einem Standard-Port offen ist, so stellt die Option „-CommonTCPPort“ die verschiedensten Möglichkeiten wie RDP, SMB oder HTTP zur Auswahl bereit:
Test-Netconnection -Computername 192.168.36 -CommonTCPPort SMB -InformationLevel "Detailed"
Abschließend soll in diesem Zusammenhang noch der „netstat“-Befehl erwähnt werden. Diese Aufgabe erledigt wiederum das Cmdlet „Get-TCPNetconnection“ mit Hilfe der Option „-State“.:
Get-NetTCPConnection -State Established
So werden alle TCP-Verbindungen aufgelistet, die den Status „aufgebaute, bestehende Verbindung“ (established) besitzen. Zwar unterscheidet sich die Form der Ausgabe etwas von der des „netstat“-Kommandos, stellt sich aber unserer Meinung nach weitaus übersichtlicher und anwenderfreundlicher auf dem Bildschirm dar.
(ID:44331518)