Windows Cheat Sheet for essential Commands

Mastering a few key Windows commands can save you time, troubleshoot issues, and unlock hidden features. From speeding up tasks to fixing common problems, the Command Prompt and PowerShell are powerful tools to solve some of these issues.

In this post, I will explore interesting and useful Windows commands and update this post regularly.

About Active Directory commands you can also check my following post which I will also update regularly.

Determine if Computer is joined to an Domain (on-premise, Entra ID, Hybrid)

To quickly determine if a computer is joined to a domain (on-premise, Entra ID or hybrid) we can execute the following command in the PowerShell or CMD with elevated Administrator rights.

The dsregcmd.exe /status command is a useful diagnostic tool in Windows for checking the device’s Entra ID join status and related registration details. It provides information such as domain join type, user state, SSO (Single Sign-On) status, and other relevant Entra ID connectivity details. This command is particularly helpful for troubleshooting authentication, device registration, and hybrid join issues in enterprise environments. Running it displays a summary of the device’s Entra ID and domain registration state.

> dsregcmd.exe /status

Determine the Logon Server (Domain Controller) on a Windows Client

When a Windows computer joins a domain, it authenticates against a Domain Controller (DC), known as the logon server. There are several ways to find the Logon Server against the client authenticated.

By using the legacy CMD command set, just works when using the CMD (Command Prompt).

> set | findstr "LOGONSERVER"

The PowerShell equivalent is.

PS> Get-ChildItem Env:

PS> Get-ChildItem Env: | Where-Object { $_.Name -like "*LOGON*" -or $_.Name -like "*DOMAIN*" -or $_.Name -like "*USER*" }

By using the nltest command/utility used for testing and troubleshooting Active Directory (AD) domain relationships, trust configurations, and Domain Controller (DC) communications.

PS> nltest /dsgetdc:YOURDOMAIN.COM

Below the DC: \\MatrixDC-01.matrixpost-lab.net show the logon server which was used by the client.

PS> nltest /dsgetdc:$env:USERDOMAIN

Determine in which OU my Active Directory Domain Joined Computer is placed to

To determine directly on a Active Directory domain joined computer in which OU it is placed to, we can run the following PowerShell command.

PS> Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" | Select-Object Distinguished-Name

PS> Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" 

Determine in which OU my Active Directory User Account is placed to

We can run the following command which displays the user name in Fully Qualified
Distinguished Name (FQDN) format.

> whoami -fqdn

More you will find by display the help information for the whoami command.

> whoami /?

Force a Restart of the Explorer.exe

The explorer.exe (Windows Explorer) is a critical system process in Windows that provides the graphical user interface (GUI), including:

• The desktop (icons, wallpaper, and right-click menu)
• The taskbar (Start menu, system tray, and open apps)
• File Explorer (folders, drives, and file management)

In case the we can’t restart the explorer.exe directly on the machine by using for example the task manager, we can terminate and restart it by using the CMD or PowerShell shown below.

The following command forcefully closes Windows Explorer and then restarts it. This can be useful for refreshing the its controled components mentioned above if they frozen or misbehaving.

> taskkill /f /im explorer.exe && start explorer.exe

We can also fire up this command from remote by using for example the psexec utility from Sysinternals and shown in my following post.

Determine local Listening TCP Ports

Below for example we will list the local TCP listening ports for RDP and SMB.

By using the Get-NetTCPConnection cmdlet we will see all states of the TCP socket.

PS> Get-NetTCPConnection | Where-Object { $_.LocalPort -eq 3389 }
PS> Get-NetTCPConnection | Where-Object { $_.LocalPort -eq 445 }

We can also list all ports by using wildcards and the -like flag like shown below.

PS> Get-NetTCPConnection | Where-Object { $_.LocalPort -like "4967*" }

Or by using the good old netstat tool.

PS> netstat.exe -nao | findstr 3389 | findstr LISTENING
PS> netstat.exe -nao | findstr 445 | findstr LISTENING

-a – Displays all connections and listening ports (TCP & UDP)
-n – Show numerical addresses (no DNS resolution)
-o – Shows the Process ID (PID) associated with each connection.

Determine local Listening TCP Ports and its Binary

To show also the corresponding binary which is listening behind the TCP socket, we can also use the Get-NetTCPConnection command and pipe it for the owning process like shown below for TCP port 22 (SSH daemon).

PS> Get-NetTCPConnection -LocalPort 22 -State Listen | Select-Object LocalAddress,LocalPort,State,OwningProcess,@{n='ProcessName';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}},@{n='Path';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Path}} | Format-Table -Auto

Determine local Established TCP Ports

Below we will see that the remote computer with the IP 10.0.0.149 is connected to the local server per RDP on TCP port 3389.

By using the Get-NetTCPConnection cmdlet we will see all states of the TCP socket including the established states.

PS> Get-NetTCPConnection | Where-Object { $_.LocalPort -eq 3389 }
PS> Get-NetTCPConnection | Where-Object { $_.LocalPort -eq 445 }

By using the netstat tool.

PS> netstat.exe -nao | findstr 3389 | findstr ESTABLISHED

-a – Displays all connections and listening ports (TCP & UDP)
-n – Show numerical addresses (no DNS resolution)
-o – Shows the Process ID (PID) associated with each connection.

Determine local Listening (active) UDP Ports and Connections

To show all open UDP ports or as specific on a system we can use the Get-NetUDPEndpoint cmdlet.

PS> Get-NetUDPEndpoint | Where-Object { $_.LocalPort -eq 111 }

# or by using the -like flag to use wildcards
PS> Get-NetUDPEndpoint | Where-Object { $_.LocalPort -like "11*" }

By default, Get-NetUDPEndpoint doesn’t show all properties, it just formats a subset. To also see the OwningProcess property use the Select-Object command to select specific properties as shown below.

By default, Windows RDS server listens on TCP port 3389 and UDP port 3389.

PS> Get-NetUDPEndpoint | Where-Object { $_.LocalPort -eq 3389 } | Select-Object LocalAddress, LocalPort, OwningProcess

Or to see the process name as well run.

PS> Get-NetUDPEndpoint |
  Where-Object { $_.LocalPort -eq 3389 } |
  ForEach-Object {
      [PSCustomObject]@{
          LocalAddress = $_.LocalAddress
          LocalPort    = $_.LocalPort
          PID          = $_.OwningProcess
          ProcessName  = (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName
      }
  }

The following command will show all open UPD ports and connections.

PS> netstat -anp UDP

-a – Show all connections and listening ports
-n – Show numerical addresses (no DNS resolution)
-p UDP – Filter for UDP only

Determine Domain Account Password Expiration

To check when a domain users password expires, you can use the following command.

PS> net user <username> /domain

Set WinHTTP Proxy

WinHTTP is more suited for non-interactive usage, such as windows services or background tasks that need to communicate over HTTP where no user-interaction is required. It is a lot faster than the WinINET library. WinHTTP is also easily accessed from .NET based applications making it a popular library for .NET Applications. WinHTTP by default does not use the proxy settings from WinINET.

Typical examples for applications and services using WinHTTP are:

• Adding/Removing features and roles in Windows 8.
• Windows Update
• Certificate validation of code
• Signed binaries / .NET applications that validate the certificate during application launch.
• Exchange Server

To show WinHTTP proxy settings on the client.

> netsh winhttp show proxy

To set new WinHTTP proxy settings on the client.

> netsh winhttp set proxy proxy-server="proxyserver:port" bypass-list="localhost; 127.0.0.1; ::1"

To reset WinHTTP proxy settings on the client.

> netsh winhttp reset proxy

Import the IE proxy settings of the current user.

> netsh winhttp import proxy source=ie

Determine last Restart Date and Time

To determine the last restart date and time on a Windows system, you have several easy options.

By using PowerShell or CMD. This shows when the system last booted, which effectively tells you the last restart time.

PS> systeminfo | find "System Boot Time"

By using PowerShell. This returns the exact date and time when Windows was last started.

PS> (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime

By using PowerShell. This tells you how long the system has been running (uptime).

PS> (get-date) - (gcim Win32_OperatingSystem).LastBootUpTime

gpupdate vs. gpupdate /force

The /force flag forces a reapplication of all Group Policy settings, even if they haven’t changed.

This means that any assigned GPOs will be reapplied.

When just running gpupdate without the /force flag, it only applies policies that have changed since the last update.

If no changes were made to the GPOs, nothing will be reapplied to the hosts or users.

Terminate Windows Services they stuck Stopping/Starting

By using the taskkill command (CMD)

Run the following command (just works by using the CMD) to determine the PID of the stucking service. Below for example the Windows Update Service (wuauserv).

> sc queryex wuauserv

To finally terminate the stuck process run the taskkill command below .

> taskkill /PID 9132 /F

By using the Stop-Process cmdlet (PowerShell)

We can also use the PowerShell to force the service stop. We can first determine all services they are in state ‘stop pending’ by running the following command.

PS> Get-WmiObject -Class win32_service | Where-Object {$_.state -eq 'stop pending'}

To list all services in state ‘start pending’ run.

PS> Get-WmiObject -Class win32_service | Where-Object {$_.state -eq 'start pending'}

We can use the Stop-Process cmdlet to terminate all processes found by pending state.

$Services = Get-WmiObject -Class win32_service -Filter "state = 'stop pending'"
if ($Services) {
foreach ($service in $Services) {
try {
Stop-Process -Id $service.processid -Force -PassThru -ErrorAction Stop
}
catch {
Write-Warning -Message "Error. Error details: $_.Exception.Message"
}
}
}
else {
Write-Output "No services with 'Stopping'.status"
}

Using the Resource Monitor to analyze Services they stuck (Analyze Wait Chain)

In Windows Resource Monitor, analyzing the wait chain of a process helps identify which other process or thread is blocking it, which is especially useful when troubleshooting performance issues or hung applications.

Launch the Resource Monitor.

Right-click on the process you suspect is not responding or is stuck. Select “Analyze Wait Chain”.

A wait chain tree will pop up.

If the process is not waiting, you’ll see something like below “….. is running normally.“

If it is waiting, you’ll see a chain like:

process.exe (PID)  
 ↳ anotherprocess.exe (PID)

This means process.exe is waiting on anotherprocess.exe, and so on.

A wait chain shows the chain of threads/processes that are waiting on a resource, like:

• A mutex (lock) that another thread holds
• A disk or network operation
• A hung child process

If the last process in the chain is stuck, the entire chain is stuck.

If the bottom process is clearly hung and you don’t need it → you can kill it. If you find circular dependencies (processes waiting on each other), that can signal a deadlock.

Use tools like Process Explorer or Procmon for deeper inspection.

In Process Explorer, the Threads tab is a powerful diagnostic tool that allows you to inspect the individual threads running within a process.

A thread is the smallest unit of execution within a process. Each process has at least one thread, but can have many, each handling different tasks concurrently (e.g., UI, networking, file I/O).

You can click “Stack” to view the call stack, showing what code the thread is executing.

Enable Remote Desktop using PowerShell

fDenyTSConnections = 0 → RDP enabled.
UserAuthentication = 1 → Only allows connections with Network Level Authentication.

# Enable RDP
PS> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0

# Optional: Enable Network Level Authentication (recommended)
PS> Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

To check if RDP is already enabled we can run.

0 ==> RDP is enabled
1 ==> RDP is disabled

PS> (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server").fDenyTSConnections

Enable/Disable Firewall by using Powershell

You can manage the Windows Firewall for all profiles (Domain, Private, Public) by using the PowerShell.

# Enable Firewall for All Profiles
PS> Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

# Disable Firewall for All Profiles
PS> Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled False

To just check the current firewall status for all profiles run.

PS> Get-NetFirewallProfile | Select-Object Name, Enabled

To allow RDP through the firewall if enabled run.

# --- Allow RDP through the firewall ---
PS> Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Check and allow specific Traffic

For example to check if there is already a rule configured which allows inbound UDP port 8080 traffic.

PS> Get-NetFirewallRule | Get-NetFirewallPortFilter |  Where-Object { $_.Protocol -eq "UDP" -and $_.LocalPort -eq 8080 } 

So far there is no rule configured (as no output returns above), which allows inbound UDP port 8080 traffic, so in case the local firewall is enabled, traffic will be denied.

To allow inbound UDP port 8080 traffic in case the local firewall is enabled, we need to run.

PS> New-NetFirewallRule -DisplayName "Allow UDP 8080" -Direction Inbound -Protocol UDP -LocalPort 8080 -Action Allow

Enable Logging

The Windows Defender Firewall can log allowed and dropped packets, but it does not log them “per rule.” Instead, it logs them at the profile level (Domain, Private, Public).

The log is stored under C:\Windows\System32\LogFiles\Firewall\pfirewall.log.

Here we can see for example some dropped Pings (ICMP Echo request packets), some dropped SMB (TCP 445) packets and one dropped UDP 9595 packet.

Just dropped because I previously enabled logging just for dropped packets, how to shown below.

To enable logging we can use the following commands. By default they are disabled, to disable them after enabling just set them to False again.

Logs show packet drops (or allows if enabled), not which specific rule caused them.
Events appear in Event Viewer → Security log with Event IDs like 5152 (drop) or 5157 (block by rule).

# View current logging settings
PS> Get-NetFirewallProfile | Select-Object Name, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes

# Enable logging of blocked packets for all profiles
PS> Set-NetFirewallProfile -Profile Domain,Private,Public -LogBlocked True

# (Optional) enable logging of allowed packets too
PS> Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed True

Determine Windows Server Version and Edition by using PowerShell

In PowerShell you can get the Windows Server version and edition in a few different ways.

PS> systeminfo | Select-String "^OS Name","^OS Version"

PS> Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, OSArchitecture

PS> Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

PS> (Get-CimInstance Win32_OperatingSystem).Caption

Download Files by using PowerShell

Below e.g. to download files from the Microsoft Update Catalog.

Start-BitsTransfer

Start-BitsTransfer is a PowerShell cmdlet that uses BITS (Background Intelligent Transfer Service) to download or upload files.

It’s especially useful for large files (e.g. cumulative updates) because it can pause, resume, and handle network interruptions gracefully.

# e.g. 2025-09 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5065428)
PS> $source = "https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2025/09/windows10.0-kb5065428-x64_3c83399a5ec7b56767218da3a1823e6349ceafb1.msu"

PS> $Destination = "C:\Users\<username>\Downloads\windows10.0-kb5065428-x64_3c83399a5ec7b56767218da3a1823e6349ceafb1.msu"

PS> Start-BitsTransfer $Source $Destination

Invoke-WebRequest

On newer Windows 10/11 and Server 2022 builds, Microsoft recommends Invoke-WebRequest or Invoke-RestMethod for simple downloads, but Start-BitsTransfer is still preferred for large, resilient transfers (like .msu updates).

Invoke-WebRequest → better for downloading files (it handles binary streams easily).

# e.g. 2025-09 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5065432)
PS> Invoke-WebRequest -Uri "https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2025/09/windows10.0-kb5065432-x64_a714744bd7eedbcc58a38130e1307fb4c7fa020b.msu" -OutFile "C:\Users\<username>\Downloads\windows10.0-kb5065432-x64_a714744bd7eedbcc58a38130e1307fb4c7fa020b.msu"

Invoke-RestMethod

Invoke-RestMethod → better for working with APIs (it parses JSON/XML into objects).

PS> Invoke-RestMethod -Uri "https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2025/09/windows10.0-kb5065432-x64_a714744bd7eedbcc58a38130e1307fb4c7fa020b.msu" -OutFile "C:\Users\<username>\Downloads\windows10.0-kb5065432-x64_a714744bd7eedbcc58a38130e1307fb4c7fa020b.msu"

The URL we can pick from the Microsoft Update Catalog https://www.catalog.update.microsoft.com/.

Links

Windows Start button or the taskbar is not working – ideapad, ideacentre
https://support.lenovo.com/mn/en/solutions/ht503047-taskbarstart-button-does-not-respond-windows-10-ideapad-ideacentre