Auflistung aller NetTCPIP-Cmdlets

Die folgenden Cmdlets decken zahlreiche Aufgaben rund um die TCP/IP-Konfiguration ab, darunter das Auslesen und Verwalten von IP-Adressen, Routingtabellen, Netzwerkinterfaces, TCP- und UDP-Einstellungen sowie Diagnose- und Verbindungsprüfungen. Sie eignen sich für Administratoren im täglichen Betrieb als auch für Troubleshooting- und Automatisierungsaufgaben.

Zur besseren Orientierung sind alle Cmdlets alphabetisch nach dem jeweiligen Verb am Anfang des Befehls sortiert, beispielsweise Get, Set, New, Remove oder Test. Dadurch lassen sich passende Befehle schnell finden und logisch nach ihrer Funktion einordnen.

Vergleich PowerShell zu klassischer CMD

Bei der Durchsicht und Ausführung der Befehle ist mir dabei aufgefallen, dass viele PowerShell-Befehle ähnliche Informationen liefern wie die klassischen Netzwerkbefehle aus der Windows-Eingabeaufforderung CMD. Die folgende Tabelle liefert daher eine Gegenüberstellung zwischen klassischen Netzwerkbefehlen und den entsprechenden PowerShell-Cmdlets.

Quelle

• NetTCPIP Module | Microsoft Learn

Der Beitrag PowerShell – NetTCPIP-Cmdlets erschien zuerst auf Maximilian Krieg.

Gerade bei Remote-Analysen oder komplexeren Netzwerkproblemen ist die PowerShell oft deutlich praktischer als die grafische Oberfläche. In diesem Beitrag zeige ich, wie sich Get-NetAdapter sinnvoll einsetzen lässt und welche Informationen bei der Fehlersuche besonders hilfreich sind.

Abfrage der Netzwerkadapter

Zunächst beziehen wir die Interface-Informationen der vorhandenen Netzwerkadapter. Besonders interessant ist dabei der Interface-Index, da dieser von vielen weiteren PowerShell-Netzwerkbefehlen zur eindeutigen Identifikation des Adapters verwendet wird. In dem konkreten Fall haben wir jedoch mit dem Interface-Namen gearbeitet.

PS C:\Windows\System32> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
WLAN                      Intel(R) Wi-Fi 6 AX203                       11 Up           XX-XX-XX-A5-A8-XX       1.2 Gbps
Bluetooth-Netzwerkverb... Bluetooth Device (Personal Area Netw...      10 Disconnected XX-XX-XX-XX-XX-XX         3 Mbps
Ethernet                  Realtek PCIe GbE Family Controller            3 Disconnected XX-XX-XX-XX-XX-X          0 bps

Abfrage-Skript mit Variable

Das Interface, welches wir uns genauer anschauen möchten, trägt in diesem Beispiel den Namen WLAN. Daher setzen wir den entsprechenden Interface-Namen in der PowerShell-Variable ein und führen anschließend die folgenden Befehle aus. Damit lassen sich unter anderem Adapterstatus, IP-Konfiguration, DNS-Server, erweiterte Adaptereigenschaften sowie aktive Netzwerkbindungen auslesen.

PS C:\Windows\System32> 

$if = "WLAN"

Get-NetAdapter -Name $if
Get-NetIPConfiguration -InterfaceAlias $if
Get-NetIPAddress -InterfaceAlias $if
Get-NetAdapterAdvancedProperty -Name $if
Get-DnsClientServerAddress -InterfaceAlias $if
Get-NetAdapterBinding -Name $if
Get-NetConnectionProfile -InterfaceAlias $if
Get-NetAdapterStatistics -Name $if
Get-NetIPInterface -InterfaceAlias $if
Get-NetRoute -InterfaceAlias $if
Get-NetNeighbor -InterfaceAlias $if

Remove-Variable if

Durch die Verwendung einer gemeinsamen Interface-Variable lassen sich die Befehle außerdem einfach wiederverwenden und flexibel auf andere Netzwerkadapter anwenden.

Beschreibung der Cmdlets

Die folgende Tabelle beschreibt nochmals, welche Informationen die jeweiligen Befehle liefern. Dabei überschneiden sich einige Ausgaben bewusst, da bestimmte Informationen von mehreren Cmdlets bereitgestellt werden oder unterschiedlich detailliert dargestellt sind.

Viele der gezeigten Befehle liefern bereits ohne zusätzliche Tools wertvolle Informationen für die Fehlersuche und ermöglichen eine schnelle erste Einschätzung der Netzwerksituation.

Der Beitrag PowerShell – NIC-Konfiguration auslesen erschien zuerst auf Maximilian Krieg.

Skript

Der folgende Code zeigt einen Ausschnitt eines komplexeren Skripts:

$targetPath = "C:\Users\myUser\Desktop"

$directoryList = Get-ChildItem -Path $targetPath -Directory

$dirName = "Test"

foreach ($dir in $directoryList){

    if ($dirName -eq ($dir.ToString())){
        echo "Treffer!"
        echo $dir.FullName.ToString();
        ## Hier kommen weitere Operationen, um das Objekt $dir zu manipulieren ##
        break
    }
    else
    {
        # echo "Bin ich nicht!"
    }

}

Die Suche nach dem Verzeichnis ist theoretisch auch ohne Schleife möglich, war aber eine Voraussetzung der ursprünglichen Aufgabenstellung.

Rückgabewert

Führt man das Skript in PowerShell aus, so liefert es den folgenden Rückgabewert:

PS C:\Users\myUser\Desktop> C:\Users\myUser\Desktop\myScript.ps1
Treffer!
C:\Users\myUser\Desktop\Test

Der Beitrag Nichtrekursive Suche nach Verzeichnissen mit PowerShell erschien zuerst auf Maximilian Krieg.

Symptom

Ich möchte eine Datei ausführen, die in einem Pfad liegt, der Leerzeichen enthält. Als Beispiel hierfür habe ich die putty.exe in einem solchen Pfad abgelegt und versuche sie mit C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe auszuführen.

> C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe

C:\Users\putty\Downloads\Achtung : Die Benennung "C:\Users\putty\Downloads\Achtung" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\putty\Downloads\Achtung:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Problem

Pfade sollten immer mit Anführungszeichen versehen werden. Korrigieren wir also unseren Aufruf zu "C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe"

> "C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe"

C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe

Wir haben also ein Echo unserer Eingabe erzeugt. Das ist schon mal besser als vorher. Verwenden wir nun noch den Call-Operator „&“, dann sollte es nun klappen. Wir geben also & "C:\Users\putty\Downloads\Achtung Leerzeichen\putty.exe" ein und sehen, dass sich das Programm öffnet.

Lösungstrategie

Wenn wir eine Datei ausführen wollen geben wir die Pfade in Anführungszeichen an und setzen ein & davor.

Der Beitrag Powershell – Ausführen von Dateien mit Leerzeichen im Pfad erschien zuerst auf Maximilian Krieg.

Symptom

Obwohl WinRM korrekt konfiguriert wurde, der Dienst auf dem Zielsystem läuft und ein Ping mit dem System erfolgreich ist, schlägt der Verbindungsaufbau mit dem Dienst über test-wsman server-1 fehl.

>test-wsman server-1

test-wsman : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
At line:1 char:1
+ test-wsman server-1
+ ~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (server-1:String) [Test-WSMan], InvalidOperationException
+ FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.TestWSManCommand

Problem

Nachdem sichergestellt ist, dass beide Systeme miteinander kommunizieren können und die Firewall korrekt konfiguriert wurde, kann man noch prüfen, ob die eingehenden Pakete überhaupt an den richtigen Port adressiert werden. Die Überprüfung mit winrm e winrm/config/listener ergibt, dass der WinRM-Dienst auf Port 80 gebunden ist. Die Anfragen gehen jedoch standardmäßig auf Port 5985 ein.

>winrm e winrm/config/listener

Listener
	Adress = *
	Transport = HTTP
	Port = 80
	Hostname
	Enabled = true
	URLPrefix = wsman
	CertificateThumbrint
	ListeningOn = 127.0.0.1, 192.168.1.50, [..]
	
Listener [Source="Compatibility"]
	Adress = *
	Transport = HTTP
	Port = 80
	Hostname
	Enabled = true
	URLPrefix = wsman
	CertificateThumbrint
	ListeningOn = 127.0.0.1, 192.168.1.50, [..]

Lösungstrategie

Die Korrektur des Listeners auf Port 5985 löst das Problem, wir verwenden dafür den Befehl winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="5985"}.

Der Beitrag Verbindung zum Windows Remote Management schlägt fehl erschien zuerst auf Maximilian Krieg.