Restart Remote Computer with PowerShell

You push a new build to a remote workstation, the user clicks something they should not have, and File Explorer hangs. Task Manager will not respond. The box is hours away by car — nobody on site can power-cycle it. The fastest fix is a remote restart from PowerShell, and the cmdlet you reach for is Restart-Computer.

This article walks the basic Restart-Computer -ComputerName invocation, the common failure when a user is still logged in, the -Force override that handles it, and the ping -t trick that confirms the box went down and came back. There is also a longer appendix at the bottom on PowerShell Remoting (Enter-PSSession, Invoke-Command) for cases where you want to run other commands on the remote box, not just restart it.

Restart a Remote Computer with PowerShell

Open PowerShell as administrator on your machine. The cmdlet is Restart-Computer -ComputerName <name>. Replace PC01 with the actual hostname or IP of the remote computer:

Restart-Computer -ComputerName "PC01"

If no users are logged on, the cmdlet returns immediately and the box reboots. If anyone is logged on — even a locked session — you get a friendly refusal:

Restart-Computer : Failed to restart the computer PC01 with the following error message:
The system shutdown cannot be initiated because there are other users logged on to the computer.
At line:1 char:1
+ Restart-Computer -ComputerName PC01
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (PC01:String) [Restart-Computer], InvalidOperationException
    + FullyQualifiedErrorId : RestartcomputerFailed,Microsoft.PowerShell.Commands.RestartComputerCommand

The default refuses to kick logged-on users. That is a sensible safety; in the lab-in-a-box scenario above, it is also exactly what you need to override.

Force a Restart with -Force

The -Force switch tells Restart-Computer to ignore logged-on sessions and restart immediately:

Restart-Computer -ComputerName "PC01" -Force

This is roughly equivalent to running shutdown /r /f /t 0 /m \\PC01 from a Command Prompt — an immediate restart with no countdown and no opportunity for an interactive user to cancel. Anyone with an open session loses unsaved work; the OS sends them a brief warning before the restart kicks in.

Use it when:

• The box is unresponsive and there is no way to reach the user interactively.
• The box is in a lab or test environment and a forced restart is acceptable.
• You have already messaged the user via another channel that the restart is coming.

Do not use it on production servers or end-user workstations during business hours unless you have already cleared the disruption with whoever owns the device. Forced restarts on a live workload are how you turn a small problem into a much bigger one.

Verify the Restart with ping

Once the cmdlet returns, you have no easy interactive feedback that the box went down and came back. The simplest check is a continuous ping:

ping PC01 -t

The output walks through three states:

Reply from 192.168.1.100: bytes=32 time=9ms TTL=120
Reply from 192.168.1.100: bytes=32 time=9ms TTL=120
Reply from 192.168.1.100: bytes=32 time=10ms TTL=120
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.100: bytes=32 time=9ms TTL=120
Reply from 192.168.1.100: bytes=32 time=9ms TTL=120

1. Replies, then timeouts. The first few pings reply because the OS is still up; then the network stack goes down as the OS shuts down.
2. Continuous timeouts. The box is offline. This phase is typically 30 to 90 seconds depending on shutdown speed and POST time.
3. Replies resume. The OS is back up. Service availability follows by another few seconds — PowerShell Remoting (Enter-PSSession, Invoke-Command) usually responds about 10 to 20 seconds after the first ping reply.

Press Ctrl+C to stop the ping. The box is back online and you can RDP in or run further PowerShell against it.

For a more PowerShell-native check, use Test-Connection instead:

# Single attempt
Test-Connection -ComputerName PC01 -Count 1 -Quiet

# Loop until it comes back online
while (-not (Test-Connection -ComputerName PC01 -Count 1 -Quiet)) {
    Write-Host "$(Get-Date -Format HH:mm:ss)  PC01 still offline" -ForegroundColor Yellow
    Start-Sleep -Seconds 5
}
Write-Host "$(Get-Date -Format HH:mm:ss)  PC01 is back online" -ForegroundColor Green

How to Access the PowerShell of a Remote Computer

Restart-Computer -ComputerName works because Restart-Computer happens to know how to use legacy DCOM/RPC under the hood. For everything else — running scripts, reading event logs, fixing services on the remote box — you want PowerShell Remoting, which is the modern, supported, secure path.

Enable PSRemoting on the Target Computer

PSRemoting is a one-time setup. From an administrative PowerShell session on the remote computer:

Enable-PSRemoting -Force

-Force bypasses every interactive prompt and configures the WinRM service plus the Windows Firewall rule in one shot. On a domain-joined machine the firewall rule is scoped to the Domain profile by default; on a workgroup machine you may need to widen the scope to Private as well, depending on which network category the box thinks it is on.

TrustedHosts (Workgroup-Only Caveat)

In a domain, Kerberos handles authentication automatically. In a workgroup, you have to tell your computer that the remote computer’s name is one you trust:

# Run on YOUR computer (not the remote)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Force

# Or, if you have several you trust
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01,PC02,SRV03" -Force

Avoid setting TrustedHosts to * — that defeats the purpose of the trust list. Stick to specific names, and prefer Kerberos in a domain whenever possible.

Interactive Session with Enter-PSSession

The interactive equivalent of SSHing into a Linux box is Enter-PSSession:

Enter-PSSession -ComputerName "PC01"

# Or with explicit credentials
Enter-PSSession -ComputerName "PC01" -Credential (Get-Credential)

Your prompt changes to indicate the session is now executing on the remote computer:

[PC01]: PS C:\Users\admin\Documents>

Run any cmdlet from here. exit to close the session and return to your local prompt.

Single-Shot Commands with Invoke-Command

Invoke-Command is the right tool when you do not need an interactive shell — you just want to run one command (or one script block) on the remote box and get the output back:

# Restart the remote box via Remoting (more flexible than Restart-Computer -ComputerName)
Invoke-Command -ComputerName "PC01" -ScriptBlock { Restart-Computer -Force }

# Read recent system events from a fleet of computers
$computers = "PC01","PC02","PC03"
Invoke-Command -ComputerName $computers -ScriptBlock {
    Get-WinEvent -LogName System -MaxEvents 5 |
        Select-Object MachineName, TimeCreated, Id, LevelDisplayName
}

Invoke-Command with multiple -ComputerName targets runs in parallel and returns objects from each computer with a PSComputerName property attached — ideal for fleet operations.

Full Worked Example

Putting all of it together for a single remote box FILESERVER01 on the same domain:

# 1) On FILESERVER01, one-time setup as Administrator
Enable-PSRemoting -Force

# 2) On your computer, open an interactive session
Enter-PSSession -ComputerName "FILESERVER01"

# 3) Run any commands; the prompt now starts with [FILESERVER01]
[FILESERVER01]: PS C:\Users\admin> Get-Service Spooler
[FILESERVER01]: PS C:\Users\admin> Restart-Computer -Force

# 4) The session ends when the box reboots; run exit if it is still up
[FILESERVER01]: PS C:\Users\admin> exit

Common Pitfalls

• Forgetting -Force on a logged-on box. The default refuses to kick users; -Force is the override. If you need a soft restart that warns the user first, use shutdown /r /m \\PC01 /t 60 /c "IT will reboot this PC in 60s" instead — that gives the user a notification window.
• Trying PSRemoting from a workgroup with no TrustedHosts. Workgroup boxes need a TrustedHosts entry on the client side. Domain boxes do not. Configure the workgroup case once and remember it.
• Pinging during the timeout window and assuming the box is dead. A normal Windows shutdown plus POST plus startup is 30 to 90 seconds. If ping -t shows timeouts for two minutes, the box is genuinely stuck — check console / iDRAC / iLO / ESXi for the underlying state.
• Using Restart-Computer -ComputerName on a hardened endpoint. Some Server Core / hardened environments disable the legacy DCOM path that Restart-Computer -ComputerName uses. Switch to Invoke-Command -ScriptBlock { Restart-Computer -Force } — that goes through PSRemoting / WinRM and works wherever Remoting is enabled.
• Restarting domain controllers without checking replication. A DC reboot is fine in isolation, but if it is the only DC in a site or it is the FSMO holder during an active operation, the impact is bigger. Confirm with Get-ADDomainController and repadmin /replsummary before forcing a restart on a DC.

Conclusion

The two-line answer to “how do I reboot a remote Windows box from PowerShell” is:

Restart-Computer -ComputerName "PC01" -Force
ping PC01 -t

The first line restarts the box, the second confirms it went down and came back. For everything beyond a simple reboot — running scripts, reading logs, fixing services — reach for PowerShell Remoting (Enter-PSSession, Invoke-Command) instead of Restart-Computer -ComputerName. Bake the restart and the verification ping into your standard runbook for unresponsive endpoints, and the next time something hangs, the recovery is two commands and a thirty-second wait.