Welche PowerShell- und CMD-Befehle brauche ich im Alltag? Referenz mit Syntax, Parametern und Beispielen

CMD vs. PowerShell: Unterschiede in Syntax, Ausgabeformat, Berechtigungen und Kompatibilität

CMD (Eingabeaufforderung) und PowerShell bedienen ähnliche Aufgabenbereiche, folgen aber unterschiedlichen Paradigmen. CMD ist primär eine zeilenorientierte Shell mit Textausgabe und vergleichsweise einfacher Syntax. PowerShell kombiniert Shell und Skriptsprache auf Basis von .NET und arbeitet standardmäßig objektorientiert. Diese Unterschiede wirken sich direkt auf Parameterlogik, Pipeline-Verhalten, Fehlerbehandlung, Rechteausführung und die Kompatibilität zu klassischen Windows-Tools aus.

Syntax und Pipeline: Textketten vs. Objekte

In CMD wird die Ausgabe typischerweise als unstrukturierter Text weitergereicht. Dadurch basieren Auswertungen auf Zeichenkettenoperationen wie Filtern mit findstr oder Tokenisierung. PowerShell übergibt dagegen Objekte über die Pipeline, sodass Eigenschaften (z. B. Status, Name, Id) direkt selektiert, sortiert und gefiltert werden können. Das reduziert Fehler durch Sprach-/Formatänderungen und ermöglicht stabile Automatisierung.

Auch die Parameterkonventionen unterscheiden sich. CMD-Tools nutzen häufig /-Schalter (z. B. /all), während PowerShell-Cmdlets Parameter mit Bindestrich schreiben (z. B. -All). PowerShell akzeptiert zusätzlich benannte Parameter, Positionsparameter und Parameterbindung aus der Pipeline. Dadurch lassen sich Befehle präziser komponieren, gleichzeitig steigt die Notwendigkeit, Typen und erwartete Eingaben zu verstehen.

• Textorientiertes Filtern (CMD): ipconfig /all | findstr /i "DNS Gateway"
• Objektorientiertes Filtern (PowerShell): Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway -ne $null } | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway
• Abhängigkeit vom Ausgabeformat (Risiko): In CMD-Skripten können lokalisierte Ausgaben oder geänderte Spaltenbreiten Auswertungen brechen, etwa bei tasklist oder netstat in Kombination mit findstr.

Ausgabeformat, Encoding und Weiterverarbeitung

CMD arbeitet traditionell mit Codepages (z. B. per chcp) und gibt Text aus, der in Weiterverarbeitung, Protokollierung und Copy/Paste je nach Locale und Encoding variieren kann. PowerShell kann Objekte in verschiedene Formate serialisieren und strukturiert exportieren, etwa als CSV oder JSON. Für Automatisierung in heterogenen Umgebungen ist das konsistenter, allerdings sind Format-*-Cmdlets primär für Darstellung gedacht und sollten nicht als Datengrundlage in Pipelines dienen.

Berechtigungen, UAC und Ausführungskontext

Beide Umgebungen unterliegen UAC und den Rechten des gestarteten Prozesses. Unterschiede entstehen durch typische Nutzungsmuster: PowerShell wird häufiger für Administration und Remoting eingesetzt, wodurch der Kontext (lokal, erhöht, per Dienstkonto, per Remotesitzung) kritischer wird. In PowerShell beeinflussen zudem Sicherheitsmechanismen wie Ausführungsrichtlinien die Skriptausführung; sie sind kein Ersatz für Berechtigungen, können aber das unkontrollierte Starten lokaler Skripte reduzieren.

• Erhöhter Prozess (beide): Viele Aktionen (z. B. Dienständerungen, Treiber-/Netzwerk-Settings) erfordern „Als Administrator ausführen“; ohne Erhöhung schlagen Befehle oft mit „Zugriff verweigert“ fehl, etwa sc.exe config oder Set-NetFirewallProfile.
• PowerShell-Fehlerbehandlung (Risiko bei Automatisierung): Nicht-terminierende Fehler können Skripte weiterlaufen lassen; steuerbar über -ErrorAction Stop oder $ErrorActionPreference = "Stop", um Fehlzustände früh zu erzwingen.
• Ausführungsrichtlinie (PowerShell): Abhängig von Unternehmensvorgaben; Abfragen mit Get-ExecutionPolicy -List. Änderungen wie Set-ExecutionPolicy sollten nur im passenden Scope erfolgen (z. B. -Scope CurrentUser) und können Richtlinienkonflikte verursachen.

Kompatibilität: klassische EXE-Tools, Aliase und Parameterfallen

PowerShell kann nahezu alle klassischen Konsolenprogramme (ipconfig, ping, robocopy, netsh) starten, erhält dabei aber deren Textausgabe. Gleichzeitig existieren PowerShell-Cmdlets als modernere Gegenstücke (z. B. Get-NetIPAddress statt ipconfig). In gemischten Umgebungen entstehen Fehler häufig durch Namensgleichheiten und abweichende Parameterinterpretation.

Besonders relevant sind PowerShell-Aliase: In Windows PowerShell 5.1 ist curl typischerweise ein Alias für Invoke-WebRequest; in PowerShell 7 ist curl in der Regel kein Alias mehr und ruft meist curl.exe auf (abhängig von Profil/Modulen und der Umgebung). Wer die native curl.exe meint, sollte explizit curl.exe aufrufen. Ebenso kann sc in PowerShell als Alias für Set-Content kollidieren; für die Dienststeuerung ist sc.exe eindeutig. Solche Details entscheiden darüber, ob ein Befehl exakt das erwartete Tool startet.

• Eindeutiger Aufruf nativer Tools: sc.exe query
curl.exe -I https://example.com
• Argument-Parsing und Sonderzeichen: PowerShell interpretiert Anführungszeichen, Klammern und $ als Sprachsyntax; für native Programme sind korrektes Quoting und ggf. der Stopp-Parser-Operator --% relevant, wenn Zeichen sonst umgedeutet würden (z. B. bei komplexen netsh– oder msiexec-Argumenten). Hinweis: --% wirkt nur in Windows PowerShell 5.1 und PowerShell 7 unter Windows; in PowerShell 7 auf Nicht-Windows ist es nicht verfügbar.
• 32-/64-Bit-Umleitung (Kompatibilitätsrisiko): In 32-Bit-Prozessen können Zugriffe auf C:\Windows\System32 auf C:\Windows\SysWOW64 umgeleitet werden. Das betrifft sowohl CMD als auch PowerShell, wenn sie 32-bittig laufen; Diagnosen sollten den Prozesskontext berücksichtigen.

Praktische Entscheidungskriterien im Betrieb

CMD bleibt sinnvoll, wenn ein Hersteller-Tool exakt dort dokumentiert ist oder wenn sehr schlichte Einzeiler mit etablierten EXE-Werkzeugen gefragt sind. PowerShell ist die erste Wahl, sobald strukturiertes Auslesen, robuste Filterlogik, konsistentes Logging oder wiederholbare Administrationsabläufe im Vordergrund stehen. In der Praxis entstehen belastbare Skripte häufig als Hybrid: PowerShell übernimmt Steuerung und Auswertung, während einzelne Spezialaufgaben weiterhin über bewährte EXE-Kommandos laufen.

Netzwerkdiagnose, Systemprüfung und Dienststeuerung: Befehle, Parameter, Beispiele und Risiken

Für Netzwerkdiagnose, Integritätsprüfungen und Service-Operationen existieren in Windows parallel gewachsene Werkzeugketten: klassische Konsolenbefehle in cmd.exe und Cmdlets in PowerShell. Funktionsüberschneidungen sind üblich, die Ausgabeformate unterscheiden sich jedoch grundlegend: CMD liefert überwiegend Text, PowerShell standardisiert Objekte und erleichtert Filterung sowie Weiterverarbeitung per Pipeline. Für reproduzierbare Diagnosepfade zählt deshalb neben dem Befehl selbst auch das Format (Text vs. Objekt) und die erforderliche Berechtigung (Standardkontext vs. Administrator).

Netzwerkdiagnose: Konnektivität, DNS, Routing und Ports

Die zuverlässigste Einordnung eines Netzwerkproblems entsteht aus der Kombination mehrerer Perspektiven: Namensauflösung (nslookup, Resolve-DnsName), Pfad/Route (tracert, Test-NetConnection -TraceRoute), lokale Schnittstellenkonfiguration (ipconfig, Get-NetIPConfiguration) und Port-Erreichbarkeit (Test-NetConnection, netstat). In PowerShell sind Cmdlets oft detailreicher, während CMD-Befehle in Logs und in minimalen Rettungsumgebungen weiterhin verbreitet sind.

• Porttest mit Kontext: Test-NetConnection -ComputerName example.com -Port 443 liefert neben TcpTestSucceeded auch lokale Interface- und Routingdetails; für reine Erreichbarkeit genügt oft -InformationLevel Quiet.
• DNS-Fehler reproduzierbar eingrenzen: Resolve-DnsName -Name host.intern -Server 10.0.0.53 trennt Resolver-Probleme von Client-Caching und DHCP-Optionen.
• Verbindung einem Prozess zuordnen: netstat -ano plus tasklist /fi "PID eq 1234" oder in PowerShell Get-Process -Id 1234 reduziert Fehlinterpretationen bei „Port belegt“.
• ICMP bewusst bewerten: ping -4 bzw. ping -6 trennt IPv4/IPv6-Probleme; blockiertes ICMP ist kein Beweis für nicht erreichbare TCP-Dienste.

Systemprüfung: Integrität, Datenträger und Ereignisse

Systemprüfungen reichen von Dateisystemkonsistenz bis zur Integrität geschützter Systemdateien. sfc und DISM ergänzen sich: sfc validiert und repariert Systemdateien, während DISM den Component Store (WinSxS) prüft und als Reparaturquelle dient. Für Datenträgerdiagnosen bleibt chkdsk relevant, sollte jedoch mit Blick auf Ausfallzeiten und mögliche Datenbewegungen geplant werden.

Dienststeuerung: Status, Starttypen, Abhängigkeiten

Für Services existiert eine klare Trennlinie: sc.exe und net start/net stop sind textorientierte Werkzeuge, während PowerShell mit Get-Service, Start-Service und Stop-Service objektbasierte Ausgaben liefert. Für Starttyp-Änderungen und detailreiche Konfiguration eignet sich PowerShell mit den CIM/WMI-Klassen; bei sc.exe fallen Syntaxdetails wie Leerzeichen nach start= besonders ins Gewicht.

• Status prüfen (PowerShell): Get-Service -Name "wuauserv" zeigt Status und StartType; für Abhängigkeiten ergänzt (Get-Service -Name "wuauserv").ServicesDependedOn.
• Starttyp setzen (CMD): sc.exe config "wuauserv" start= demand erfordert das Leerzeichen nach start=; falsche Syntax führt zu Fehlannahmen, wenn nur die Rückgabe nicht geprüft wird.
• Starttyp setzen (PowerShell): Set-Service -Name "wuauserv" -StartupType Manual ist für Standardfälle ausreichend; für tiefergehende Eigenschaften (z. B. Dienstkonto, Pfad, DelayedAutoStart) ist Get-CimInstance -ClassName Win32_Service -Filter "Name='wuauserv'" der passende Einstieg.
• Erzwungenes Stoppen mit Nebenwirkungen: Stop-Service -Name "Spooler" -Force kann abhängige Dienste mitreißen; in Produktionsumgebungen sollten Abhängigkeiten vorab geprüft und Wartungsfenster eingeplant werden.
• Remote-Operationen bewusst absichern: Get-Service -ComputerName "SERVER01" nutzt in der Regel RPC/Service Control Manager und scheitert häufig an Firewall-/RPC-Restriktionen oder fehlenden Rechten; PowerShell-Remoting über Invoke-Command -ComputerName "SERVER01" -ScriptBlock { Get-Service } erfordert konfigurierte WinRM-Policies (HTTP/HTTPS, Authentifizierung, TrustedHosts/Kerberos je nach Szenario).

Bei Dienstproblemen liefert die Kombination aus Ereignisanzeige und Dienstkonfiguration meist die schnellste Ursachenklärung: Startfehler mit Code (Service Control Manager) lassen sich über Get-WinEvent -LogName System zeitlich mit Änderungen an Abhängigkeiten oder Kontorechten korrelieren. Unbedachte Maßnahmen wie das Deaktivieren zentraler Dienste (beispielsweise Netzwerk- oder Update-Komponenten) erzeugen Folgeschäden, die erst später sichtbar werden, etwa durch fehlende Sicherheitsupdates oder unterbrochene Namensauflösung.

Dateiverwaltung sowie Benutzer- und Gruppenverwaltung: Befehle, Parameter, Beispiele und typische Stolperfallen

Dateiverwaltung und Identitätsverwaltung zählen zu den Bereichen, in denen Konsolenbefehle besonders schnell Wirkung entfalten – im positiven wie im destruktiven Sinn. Während die klassische Eingabeaufforderung viele Aufgaben über eigenständige EXE-Tools abdeckt, setzt PowerShell häufig auf Cmdlets mit objektbasiertem Output und konsistenten Parametern. In der Praxis entsteht ein Mischbetrieb: Altskripte nutzen cmd.exe-Syntax, moderne Automatisierung arbeitet mit Get-ChildItem, Copy-Item oder New-LocalUser. Entscheidend sind korrekte Quoting-Regeln, Rechtekontexte (UAC) sowie ein klares Verständnis darüber, ob Text oder Objekte verarbeitet werden.

Dateiverwaltung (CMD): Kopieren, Verschieben, Löschen und Attribute

CMD-Befehle sind bei Dateiarbeiten oft schnell und vorhersehbar, geben jedoch überwiegend Text zurück. Viele Stolperfallen entstehen durch Wildcards, fehlende Anführungszeichen bei Pfaden mit Leerzeichen und Parameter, die rekursiv oder ohne Rückfrage löschen. Zusätzlich ist zu beachten, dass einige Befehle (etwa robocopy) eigene Exitcodes verwenden, die in Batch-Logik leicht falsch interpretiert werden können.

Dateiverwaltung (PowerShell): Objektpipeline, Filter und Berechtigungen

PowerShell-Cmdlets liefern Objekte statt reiner Textzeilen. Dadurch lassen sich Dateien sicher nach Eigenschaften filtern, sortieren und weiterverarbeiten, ohne fragile String-Operationen. Gleichzeitig erfordern rekursive Operationen und das Arbeiten mit ACLs ein sauberes Scoping: Parameter wie -Recurse oder -Force entfalten schnell eine größere Reichweite als beabsichtigt, insbesondere in Kombination mit Platzhaltern.

• Auflisten und Filtern: Get-ChildItem -Path "C:\Logs" -File -Filter "*.log" -Recurse
• Kopieren mit Ausschlüssen: Copy-Item -Path "C:\Data\*" -Destination "D:\Backup" -Recurse -Exclude "*.tmp","*.bak"
• Verschieben und Umbenennen: Move-Item -Path "C:\In\report.csv" -Destination "C:\Archive\"
Rename-Item -Path "C:\Archive\report.csv" -NewName "report_2025-12.csv"
• Löschen mit Kontrolle: Remove-Item -Path "C:\Temp\*" -Recurse -Force -WhatIf
• NTFS-Rechte prüfen (ACL): (Get-Acl -Path "C:\Data").Access | Select-Object IdentityReference,FileSystemRights,AccessControlType,IsInherited

Die größte Fehlerquelle ist das Zusammenspiel aus Wildcards und Provider-Logik. Remove-Item "C:\Data\*" unterscheidet sich im Ergebnis von Remove-Item "C:\Data" mit -Recurse je nach Inhalt und Attributen; zusätzlich übergeht -Force versteckte und schreibgeschützte Elemente. Für produktive Lösch- und Migrationsjobs haben sich -WhatIf und ggf. -Confirm bewährt, bevor dieselben Befehle ohne Simulation laufen.

Lokale Benutzer- und Gruppenverwaltung (CMD): net.exe und lokale Konten

Für lokale Konten und Gruppen wird in CMD häufig net user und net localgroup verwendet. Die Befehle sind schnell, aber textorientiert; Kennwörter werden auf der Kommandozeile leicht in Verlauf oder Logfiles sichtbar, wenn sie als Klartext übergeben werden. In Domänenumgebungen greifen die Befehle weiterhin, sind aber nicht als vollständiger Ersatz für Verzeichnisdienste-Tools zu verstehen.

Lokale Benutzer- und Gruppenverwaltung (PowerShell): LocalAccounts-Modul und sichere Parameter

In PowerShell stehen für lokale Konten auf aktuellen Windows-Client- und Serverversionen Cmdlets aus dem Modul Microsoft.PowerShell.LocalAccounts zur Verfügung. Sie arbeiten objektbasiert und unterstützen eine sauberere Fehlerbehandlung als textbasierte net-Aufrufe. Für Kennwörter ist die Übergabe als SecureString üblich; trotz verbesserter Handhabung bleibt die sichere Erzeugung und Aufbewahrung der Geheimnisse ein separates Thema.

• Benutzer anlegen (mit SecureString): $pw = Read-Host -AsSecureString
New-LocalUser -Name "svc_app" -Password $pw -AccountNeverExpires
• Benutzer deaktivieren und Eigenschaften prüfen: Disable-LocalUser -Name "svc_app"
Get-LocalUser -Name "svc_app" | Select-Object Name,Enabled,LastLogon
• Gruppe erstellen und Mitgliedschaft setzen: New-LocalGroup -Name "AppOperators"
Add-LocalGroupMember -Group "AppOperators" -Member "svc_app"
• Mitglieder auflisten (robuster als lokalisierte Gruppennamen in Skripten): Get-LocalGroupMember -Group "Administrators"

Typische Fehler entstehen durch den Ausführungskontext: Ohne erhöhte Rechte schlagen Konto- und Gruppenänderungen häufig fehl. Außerdem sind Gruppennamen lokalisiert; in heterogenen Umgebungen reduziert die Verwendung von SIDs oder eine vorgelagerte Auflösung (z. B. über Get-LocalGroup) das Risiko, die falsche Gruppe zu adressieren. Bei Dateiverwaltung und Identitäten überlappt das Risiko häufig: Kopierjobs mit robocopy und /copyall übertragen ACLs und Besitzinformationen, was bei Wiederherstellungen oder Migrationen zu unerwarteten Berechtigungsketten führen kann.