PowerShell Command to Restart Remote Computers

In today's interconnected IT environments, the ability to manage and maintain remote systems efficiently can mean the difference between minimal downtime and hours of frustration. When computers across your network need to be restarted—whether for applying updates, resolving performance issues, or implementing configuration changes—traveling physically to each machine simply isn't practical or scalable. This is where PowerShell's remote management capabilities become not just useful, but essential for modern IT operations.

PowerShell remote restart functionality represents a powerful administrative tool that allows IT professionals to execute restart commands on one or multiple computers across a network from a single location. This capability leverages Windows Management Instrumentation (WMI) and Windows Remote Management (WinRM) protocols to establish secure connections and execute commands as if you were sitting directly at the remote machine. The technology bridges the gap between physical presence and effective system administration, enabling responsive IT support regardless of geographic constraints.

Throughout this comprehensive guide, you'll discover multiple methods for restarting remote computers using PowerShell, from basic single-computer restarts to advanced bulk operations affecting entire organizational units. We'll explore the necessary prerequisites, security considerations, troubleshooting techniques, and real-world scenarios that demonstrate how these commands integrate into daily IT workflows. Whether you're managing a small office network or an enterprise infrastructure spanning multiple locations, you'll gain practical knowledge that translates directly into more efficient system administration.

Prerequisites and Environment Preparation

Before executing any remote restart commands, your environment must meet specific technical requirements. The remote computers need to be accessible over the network, and several Windows features must be properly configured. PowerShell remoting relies on WinRM, which uses HTTP or HTTPS for communication, typically over ports 5985 and 5986 respectively.

On the remote computers, WinRM must be enabled and configured to accept remote commands. For Windows Server operating systems, this is often enabled by default, but workstation versions of Windows typically require manual activation. The simplest way to enable WinRM is by running the command Enable-PSRemoting -Force in an elevated PowerShell session on each target computer. This single command configures the WinRM service, creates necessary firewall exceptions, and sets up listener configurations.

"The foundation of successful remote management isn't just technical configuration—it's understanding that every security layer you implement protects both your network integrity and the systems you're responsible for maintaining."

Network connectivity represents another critical prerequisite. Firewalls between your administrative workstation and target computers must allow WinRM traffic. In domain environments, Group Policy can streamline this configuration across multiple machines simultaneously. For workgroup environments, additional configuration steps are necessary, including adding remote computers to the TrustedHosts list or implementing certificate-based authentication.

Administrative privileges are non-negotiable for restart operations. Your user account must have local administrator rights on the remote computers you intend to restart. In domain environments, this typically means being a member of the Domain Admins group or having delegated permissions through Group Policy. For workgroup scenarios, you'll need credentials for an account with local administrator privileges on each target machine.

Verifying Remote Connectivity

Before attempting a restart, it's prudent to verify that PowerShell remoting is functioning correctly. The Test-WSMan cmdlet provides a quick connectivity check without executing any administrative commands. Running Test-WSMan -ComputerName RemotePC will return XML data if the connection succeeds, or an error message detailing what went wrong if it fails.

For a more comprehensive test, the Test-Connection cmdlet (PowerShell's equivalent to ping) confirms basic network connectivity. This command sends ICMP packets to the target computer and reports whether responses are received. While a successful ping doesn't guarantee PowerShell remoting will work—since different protocols and ports are involved—a failed ping almost certainly indicates that remote commands will also fail.

Basic Remote Restart Commands

The most straightforward method for restarting a remote computer uses the Restart-Computer cmdlet with the -ComputerName parameter. This native PowerShell command provides a clean, intuitive syntax that clearly communicates its purpose. The basic structure looks like this:

Restart-Computer -ComputerName "RemotePC01" -Force

The -Force parameter is particularly important in production environments. Without it, the restart command will fail if any users are logged in or if applications are preventing shutdown. The force parameter overrides these conditions, closing applications and logging off users before initiating the restart. While this ensures the command completes successfully, it should be used judiciously—especially during business hours when users might lose unsaved work.

For scenarios where you want to provide users with advance warning, the -Timeout parameter specifies a delay in seconds before the restart executes. Combined with the -Message parameter, this allows you to notify users about the impending restart:

Restart-Computer -ComputerName "RemotePC01" -Timeout 300 -Message "System will restart in 5 minutes for updates"

"The difference between a disruptive restart and a managed maintenance window often comes down to communication—both with your users and with the systems themselves through properly configured timeout parameters."

Using Alternative Authentication

When working across different domains or in workgroup environments, you'll frequently need to specify alternative credentials. The -Credential parameter accepts a PSCredential object, which securely stores username and password information. PowerShell provides the Get-Credential cmdlet to prompt for these credentials interactively:

$cred = Get-Credential
Restart-Computer -ComputerName "RemotePC01" -Credential $cred -Force

This approach opens a credential prompt where you can enter the appropriate username and password. The credentials are stored in the $cred variable as a secure object, protecting the password from being exposed in plain text in your script or command history. This method is particularly useful when managing computers in different security contexts or when your current logged-in credentials don't have administrative rights on the target system.

Advanced Multi-Computer Restart Techniques

Real-world IT environments rarely involve restarting a single computer. More commonly, you'll need to restart multiple systems simultaneously—perhaps an entire department's workstations after hours, or a group of servers in a maintenance window. PowerShell accommodates this through several approaches, each with distinct advantages depending on your specific scenario.

The simplest multi-computer approach involves providing an array of computer names directly to the -ComputerName parameter:

Restart-Computer -ComputerName "PC01", "PC02", "PC03", "PC04" -Force

This method works well for small, ad-hoc groups of computers. However, it becomes unwieldy when dealing with dozens or hundreds of systems. For larger deployments, reading computer names from a text file provides better maintainability and reusability:

$computers = Get-Content -Path "C:\Scripts\computers.txt"
Restart-Computer -ComputerName $computers -Force

Active Directory Integration

In domain environments, Active Directory provides a dynamic source for computer lists. Rather than maintaining static text files that quickly become outdated as computers are added, removed, or renamed, you can query AD directly for current information. The Active Directory PowerShell module includes cmdlets specifically designed for this purpose:

Import-Module ActiveDirectory
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows 10*"} -SearchBase "OU=Workstations,DC=company,DC=com" | Select-Object -ExpandProperty Name
Restart-Computer -ComputerName $computers -Force

This approach queries Active Directory for all computers running Windows 10 within a specific organizational unit, then restarts them. The flexibility of the -Filter parameter allows you to target computers based on virtually any AD attribute—operating system, location, description, or custom attributes your organization has implemented.

"Dynamic computer targeting through Active Directory transforms restart operations from static maintenance tasks into responsive, context-aware administrative actions that adapt automatically to your changing infrastructure."

Parallel Execution with Workflows

When restarting numerous computers, sequential execution can be time-consuming. Each computer must complete its restart before the next begins, potentially extending maintenance windows unnecessarily. PowerShell workflows and the ForEach-Object -Parallel parameter (in PowerShell 7+) enable simultaneous restart operations:

$computers = Get-Content -Path "C:\Scripts\computers.txt"
$computers | ForEach-Object -Parallel {
    Restart-Computer -ComputerName $_ -Force -ErrorAction SilentlyContinue
} -ThrottleLimit 10

The -ThrottleLimit parameter controls how many simultaneous operations execute. Setting this too high can overwhelm network resources or your administrative workstation, while setting it too low negates the benefits of parallel execution. A value between 10 and 50 typically provides good balance for most networks.

Error Handling and Logging

Production environments demand robust error handling. Networks are unpredictable—computers may be offline, WinRM might be disabled, credentials could be incorrect, or any number of other issues might prevent a successful restart. Scripts that don't account for these possibilities will fail silently or produce confusing error messages that obscure the actual problem.

PowerShell's error handling mechanisms center around the Try-Catch-Finally construct. This structure attempts to execute commands in the Try block, catches any errors that occur, and optionally executes cleanup code in the Finally block regardless of success or failure:

$computers = Get-Content -Path "C:\Scripts\computers.txt"
$results = @()

foreach ($computer in $computers) {
    try {
        Restart-Computer -ComputerName $computer -Force -ErrorAction Stop
        $results += [PSCustomObject]@{
            ComputerName = $computer
            Status = "Success"
            Timestamp = Get-Date
            Error = $null
        }
    }
    catch {
        $results += [PSCustomObject]@{
            ComputerName = $computer
            Status = "Failed"
            Timestamp = Get-Date
            Error = $_.Exception.Message
        }
    }
}

$results | Export-Csv -Path "C:\Logs\RestartLog_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv" -NoTypeInformation

This script attempts to restart each computer in the list, capturing the outcome—success or failure—along with timestamps and any error messages. The results are compiled into a CSV file, creating an audit trail that documents exactly what happened during the maintenance operation. This logging is invaluable for troubleshooting, compliance requirements, and post-maintenance review.

Common Error Scenarios

Understanding typical error conditions helps you design better error handling and more quickly diagnose problems when they occur. Network connectivity issues are the most frequent culprit—the target computer might be powered off, disconnected from the network, or behind a firewall that blocks WinRM traffic. These errors typically manifest as timeout messages or "RPC server unavailable" errors.

Permission-related errors are equally common, especially in complex enterprise environments with multiple domains or forests. These errors usually contain phrases like "access denied" or "logon failure." They indicate that the credentials being used lack sufficient privileges on the target system, or that authentication itself failed due to trust relationship issues between domains.

"Every error message is a diagnostic clue. The difference between a frustrated administrator and an effective troubleshooter is the willingness to read error messages carefully and understand what they're actually communicating about your environment."

Alternative Methods and Legacy Approaches

While Restart-Computer is the modern, recommended approach for remote restarts, several alternative methods exist that may be necessary in specific scenarios. Understanding these alternatives provides flexibility when working with older systems, dealing with specific security configurations, or troubleshooting issues with the primary method.

Windows Management Instrumentation (WMI) predates PowerShell remoting and remains functional on even very old Windows systems. The Invoke-WmiMethod cmdlet can trigger restarts through the Win32_OperatingSystem class:

Invoke-WmiMethod -Class Win32_OperatingSystem -ComputerName "RemotePC01" -Name Reboot

This method uses DCOM (Distributed Component Object Model) rather than WinRM, which means it operates over different network ports and may succeed when PowerShell remoting fails due to WinRM configuration issues. However, WMI commands lack some of the user-friendly features of modern PowerShell cmdlets, such as timeout warnings and custom messages.

Shutdown Command Line Utility

The traditional shutdown.exe command-line utility remains available and can be invoked from PowerShell. While this might seem archaic compared to native PowerShell cmdlets, it offers unique capabilities, particularly around timing and user notification:

shutdown /r /m \\RemotePC01 /t 300 /c "System will restart in 5 minutes for maintenance"

The shutdown utility's /r parameter specifies restart (rather than shutdown), /m targets a remote computer, /t sets a timeout in seconds, and /c provides a comment that displays to logged-in users. One advantage of this approach is that it's been consistent across Windows versions for decades, making it reliable even on legacy systems.

"Sometimes the oldest tools in your toolkit are the most reliable—not because they're better designed, but because they've been tested against every edge case and configuration anomaly that two decades of Windows deployments can produce."

PowerShell Remoting with Invoke-Command

For scenarios requiring more control or additional pre-restart actions, Invoke-Command establishes a remote PowerShell session and executes commands within that context. This approach allows you to run complex scripts on the remote computer before initiating the restart:

Invoke-Command -ComputerName "RemotePC01" -ScriptBlock {
    # Stop specific services
    Stop-Service -Name "MyCustomService" -Force
    
    # Clear temporary files
    Remove-Item -Path "C:\Temp\*" -Recurse -Force -ErrorAction SilentlyContinue
    
    # Restart the computer
    Restart-Computer -Force
}

This method is particularly valuable for maintenance operations that involve more than just a simple restart. You can perform cleanup tasks, verify that certain conditions are met, log information locally on the remote computer, or execute any other PowerShell commands before triggering the restart.

Scheduled and Conditional Restarts

Many IT scenarios require restarts to occur at specific times rather than immediately. Perhaps you need to restart servers during a designated maintenance window at 2 AM on Sunday, or you want to restart workstations only when they've been running for more than 30 days without a reboot. PowerShell's integration with Windows Task Scheduler and its conditional logic capabilities make these scenarios straightforward to implement.

For scheduled restarts, Windows Task Scheduler provides a robust, native solution. You can create a scheduled task that executes a PowerShell script at a specific time or in response to particular triggers. The script itself might be as simple as a single Restart-Computer command, or it might include complex logic to determine which computers to restart based on current conditions.

Creating Scheduled Restart Tasks

PowerShell can programmatically create scheduled tasks, allowing you to deploy restart schedules across multiple computers or document your maintenance automation in version-controlled scripts:

$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-NoProfile -WindowStyle Hidden -Command Restart-Computer -Force"
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 2am
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries

Register-ScheduledTask -TaskName "WeeklyRestart" -Action $action -Trigger $trigger -Principal $principal -Settings $settings

This script creates a scheduled task that runs every Sunday at 2 AM under the SYSTEM account, which has full administrative privileges. The task executes PowerShell in a hidden window to restart the computer. The settings ensure the task runs even if the computer is on battery power, which is relevant for laptops that might be docked during the maintenance window.

Conditional Restart Logic

Conditional restarts execute only when specific criteria are met. Common conditions include uptime thresholds, pending Windows updates, available memory, or the presence of specific processes. This approach prevents unnecessary restarts while ensuring systems are rebooted when needed:

$computers = Get-Content -Path "C:\Scripts\computers.txt"

foreach ($computer in $computers) {
    try {
        $os = Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName $computer -ErrorAction Stop
        $uptime = (Get-Date) - $os.LastBootUpTime
        
        if ($uptime.Days -gt 30) {
            Write-Host "🔄 $computer has been up for $($uptime.Days) days - restarting" -ForegroundColor Yellow
            Restart-Computer -ComputerName $computer -Force -ErrorAction Stop
            Write-Host "✅ $computer restart initiated successfully" -ForegroundColor Green
        }
        else {
            Write-Host "⏭️ $computer uptime is only $($uptime.Days) days - skipping" -ForegroundColor Cyan
        }
    }
    catch {
        Write-Host "❌ Failed to process $computer : $($_.Exception.Message)" -ForegroundColor Red
    }
}

This script queries each computer's last boot time, calculates how long it's been running, and only initiates a restart if the uptime exceeds 30 days. The emoji symbols and color-coded output make the script's progress easy to follow, while the error handling ensures that problems with individual computers don't halt processing of the entire list.

"Conditional restarts represent the evolution from reactive maintenance to proactive system management—you're not just responding to problems, you're preventing them based on observable system metrics and organizational policies."

Security Considerations and Best Practices

The ability to remotely restart computers represents significant administrative power, which necessarily comes with security responsibilities. Improperly secured remote restart capabilities could allow unauthorized individuals to disrupt operations, while overly restrictive security might prevent legitimate administrators from performing necessary maintenance. Striking the right balance requires understanding both the technical security mechanisms and the organizational policies that govern their use.

Credential management stands as the first line of defense. Never hard-code credentials directly in scripts, as this creates multiple security vulnerabilities—the passwords are visible to anyone with access to the script file, they're difficult to update when password policies require changes, and they may be inadvertently exposed through version control systems or backup procedures. Instead, use secure credential storage mechanisms like the Windows Credential Manager, encrypted credential files, or enterprise secrets management solutions.

Implementing Least Privilege Access

The principle of least privilege dictates that accounts should have only the minimum permissions necessary to perform their intended functions. For remote restart operations, this means carefully considering who needs restart permissions and on which computers. In many organizations, help desk staff might need restart permissions on workstations but not servers, while server administrators need the opposite.

Active Directory Group Policy provides granular control over remote management permissions. Rather than granting broad Domain Admins membership, create specific security groups with delegated permissions for restart operations on defined computer groups. This approach creates an audit trail—you can see exactly which accounts have restart permissions—and limits the potential damage if credentials are compromised.

Audit Logging and Compliance

Many industries and organizations have compliance requirements that mandate logging of administrative actions, including system restarts. PowerShell's transcript logging feature captures all commands executed in a session, creating a detailed record that can be reviewed during audits or investigations:

Start-Transcript -Path "C:\Logs\RestartSession_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"

# Your restart commands here
$computers = Get-Content -Path "C:\Scripts\computers.txt"
Restart-Computer -ComputerName $computers -Force

Stop-Transcript

This transcript includes not just the commands executed, but also their output, any error messages, and timestamps for each action. Combined with Windows Event Log entries generated by the restart operations themselves, this creates a comprehensive audit trail. For enhanced security, configure PowerShell to automatically enable transcript logging for all sessions through Group Policy, ensuring that even administrators who don't explicitly start transcripts are still logged.

"Security isn't about preventing all access—it's about ensuring that the right people have the right access at the right time, and that you can prove it when auditors come asking questions."

Troubleshooting Common Issues

Even with proper configuration, remote restart operations occasionally fail. Systematic troubleshooting methodologies help you quickly identify and resolve issues, minimizing downtime and maintaining user confidence in IT services. The key is breaking down the problem into discrete components—network connectivity, authentication, WinRM configuration, and permissions—then testing each systematically.

Begin troubleshooting with the most basic test: can you reach the remote computer at all? The Test-Connection cmdlet verifies basic network connectivity. If this fails, the problem lies in network infrastructure—the computer might be powered off, disconnected from the network, or separated by a firewall that blocks ICMP traffic. Resolve these fundamental connectivity issues before investigating more complex PowerShell-specific problems.

WinRM Configuration Verification

If basic network connectivity succeeds but PowerShell remoting fails, WinRM configuration is the likely culprit. The Test-WSMan cmdlet specifically tests WinRM connectivity and returns detailed information about the remote computer's WinRM configuration:

Test-WSMan -ComputerName "RemotePC01"

Successful output includes XML data showing the protocol version, product vendor, and product version. Errors typically indicate that WinRM isn't running, isn't configured to accept remote connections, or is blocked by a firewall. On the remote computer, verify that the WinRM service is running with Get-Service WinRM, and ensure that firewall rules allow traffic on ports 5985 (HTTP) and 5986 (HTTPS).

Credential and Permission Issues

Authentication and authorization problems produce distinctive error messages, usually containing phrases like "access denied," "logon failure," or "invalid credentials." These errors require careful attention to several factors: Are you using the correct username and password? Does the account have local administrator privileges on the target computer? In domain environments, are there trust relationship issues between domains?

For workgroup environments, the TrustedHosts configuration often causes authentication problems. By default, WinRM only accepts connections from computers in the same domain. To manage workgroup computers or computers in different domains, add them to the TrustedHosts list:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "RemotePC01,RemotePC02" -Concatenate -Force

The -Concatenate parameter adds to the existing list rather than replacing it, and -Force suppresses confirmation prompts. Be aware that TrustedHosts bypasses certain security checks, so use it judiciously and document which computers you've added and why.

Diagnostic Script for Comprehensive Testing

A diagnostic script that tests multiple aspects of remote connectivity can save significant troubleshooting time. This script verifies network connectivity, WinRM availability, and authentication, providing clear feedback about what's working and what's not:

function Test-RemoteRestartCapability {
    param(
        [Parameter(Mandatory=$true)]
        [string]$ComputerName,
        [PSCredential]$Credential
    )
    
    Write-Host "`n🔍 Testing remote restart capability for $ComputerName" -ForegroundColor Cyan
    
    # Test 1: Basic network connectivity
    Write-Host "`n📡 Testing network connectivity..." -NoNewline
    if (Test-Connection -ComputerName $ComputerName -Count 2 -Quiet) {
        Write-Host " ✅ Success" -ForegroundColor Green
    } else {
        Write-Host " ❌ Failed - Computer unreachable" -ForegroundColor Red
        return
    }
    
    # Test 2: WinRM availability
    Write-Host "🔌 Testing WinRM connectivity..." -NoNewline
    try {
        $null = Test-WSMan -ComputerName $ComputerName -ErrorAction Stop
        Write-Host " ✅ Success" -ForegroundColor Green
    } catch {
        Write-Host " ❌ Failed - WinRM not responding" -ForegroundColor Red
        Write-Host "   Error: $($_.Exception.Message)" -ForegroundColor Yellow
        return
    }
    
    # Test 3: Authentication and permissions
    Write-Host "🔐 Testing authentication and permissions..." -NoNewline
    try {
        $params = @{
            ComputerName = $ComputerName
            ScriptBlock = { Get-Service WinRM }
            ErrorAction = "Stop"
        }
        if ($Credential) { $params.Credential = $Credential }
        
        $null = Invoke-Command @params
        Write-Host " ✅ Success" -ForegroundColor Green
    } catch {
        Write-Host " ❌ Failed - Authentication or permission issue" -ForegroundColor Red
        Write-Host "   Error: $($_.Exception.Message)" -ForegroundColor Yellow
        return
    }
    
    Write-Host "`n✅ All tests passed - remote restart should work on $ComputerName" -ForegroundColor Green
}

# Usage example
Test-RemoteRestartCapability -ComputerName "RemotePC01"

This diagnostic function performs three progressive tests, each building on the success of the previous one. The emoji symbols and color coding make the output easy to scan visually, while the detailed error messages help pinpoint exactly what needs to be fixed.

Integration with Monitoring and Alerting Systems

Remote restart capabilities become even more powerful when integrated with monitoring systems that detect conditions requiring restarts. Rather than manually checking systems and deciding when to restart them, automated monitoring can identify problems—high memory usage, service failures, application hangs—and trigger restarts as part of self-healing infrastructure.

Most enterprise monitoring solutions provide mechanisms to execute PowerShell scripts in response to alerts. When a monitor detects a problem condition, it can call a PowerShell script that attempts remediation steps, including restarting the affected computer if other measures fail. This creates a tiered response system: first attempt to restart the failed service, then restart the application, and finally restart the entire computer if the problem persists.

Email Notifications for Restart Operations

Automated restart operations should generate notifications so administrators are aware of what actions the automation has taken. PowerShell's Send-MailMessage cmdlet integrates email notification directly into restart scripts:

$computers = Get-Content -Path "C:\Scripts\computers.txt"
$results = @()

foreach ($computer in $computers) {
    try {
        Restart-Computer -ComputerName $computer -Force -ErrorAction Stop
        $results += "✅ Successfully restarted $computer"
    }
    catch {
        $results += "❌ Failed to restart $computer : $($_.Exception.Message)"
    }
}

$emailParams = @{
    From = "automation@company.com"
    To = "itadmins@company.com"
    Subject = "Automated Restart Report - $(Get-Date -Format 'yyyy-MM-dd')"
    Body = $results -join "`n"
    SmtpServer = "smtp.company.com"
}

Send-MailMessage @emailParams

This script compiles results from multiple restart operations and sends a single summary email. For production use, consider using HTML formatting for the email body, which allows for more readable formatting, color coding of success and failure states, and inclusion of additional metadata like timestamps and duration.

Performance Optimization for Large-Scale Operations

When managing hundreds or thousands of computers, performance optimization becomes critical. Sequential processing of large computer lists can take hours, extending maintenance windows unnecessarily and potentially causing some computers to miss their maintenance window entirely if processing runs long. Several optimization strategies can dramatically reduce execution time for large-scale restart operations.

Parallel processing represents the most impactful optimization. Rather than restarting one computer at a time, process multiple computers simultaneously. PowerShell 7 introduced the ForEach-Object -Parallel parameter, which provides a straightforward way to parallelize operations. For earlier PowerShell versions, PowerShell workflows or runspaces provide similar capabilities with more complex syntax.

Batch Processing Strategies

Even with parallel execution, attempting to restart thousands of computers simultaneously can overwhelm network infrastructure, domain controllers handling authentication, or the administrative workstation running the script. Batch processing divides the total computer list into manageable chunks that are processed in waves:

$allComputers = Get-Content -Path "C:\Scripts\computers.txt"
$batchSize = 50
$delayBetweenBatches = 300  # 5 minutes

for ($i = 0; $i -lt $allComputers.Count; $i += $batchSize) {
    $batch = $allComputers[$i..([Math]::Min($i + $batchSize - 1, $allComputers.Count - 1))]
    
    Write-Host "🔄 Processing batch $([Math]::Floor($i / $batchSize) + 1) - $($batch.Count) computers" -ForegroundColor Cyan
    
    $batch | ForEach-Object -Parallel {
        try {
            Restart-Computer -ComputerName $_ -Force -ErrorAction Stop
            Write-Host "✅ Restarted $_" -ForegroundColor Green
        }
        catch {
            Write-Host "❌ Failed to restart $_ : $($_.Exception.Message)" -ForegroundColor Red
        }
    } -ThrottleLimit 10
    
    if ($i + $batchSize -lt $allComputers.Count) {
        Write-Host "⏸️ Waiting $($delayBetweenBatches / 60) minutes before next batch..." -ForegroundColor Yellow
        Start-Sleep -Seconds $delayBetweenBatches
    }
}

Write-Host "`n✅ All batches completed" -ForegroundColor Green

This script processes 50 computers at a time with a 5-minute delay between batches. The delay allows network infrastructure to recover and ensures that not all computers in your environment restart simultaneously, which could cause other problems like overwhelming your software update servers when they all check for updates after restarting.

Progress Tracking for Long-Running Operations

When processing large computer lists, progress tracking helps you estimate completion time and identify if processing has stalled. PowerShell's Write-Progress cmdlet displays a progress bar with percentage completion and estimated time remaining:

$computers = Get-Content -Path "C:\Scripts\computers.txt"
$totalComputers = $computers.Count
$currentComputer = 0

foreach ($computer in $computers) {
    $currentComputer++
    $percentComplete = ($currentComputer / $totalComputers) * 100
    
    Write-Progress -Activity "Restarting Computers" -Status "Processing $computer ($currentComputer of $totalComputers)" -PercentComplete $percentComplete
    
    try {
        Restart-Computer -ComputerName $computer -Force -ErrorAction Stop
    }
    catch {
        Write-Warning "Failed to restart $computer : $($_.Exception.Message)"
    }
}

Write-Progress -Activity "Restarting Computers" -Completed

The progress bar provides visual feedback about script execution, which is particularly valuable for operations that might run for hours. The -Completed parameter at the end removes the progress bar once processing finishes.

Documentation and Knowledge Management

Effective IT operations require more than just functional scripts—they require documentation that enables other team members to understand, maintain, and improve your automation. Well-documented restart procedures ensure continuity when team members are unavailable, facilitate knowledge transfer to new staff, and provide reference material for troubleshooting when things go wrong.

Script comments represent the first level of documentation. PowerShell supports both inline comments (preceded by #) and comment-based help blocks that provide structured documentation following specific keywords. Comment-based help makes your scripts self-documenting, as the help information can be accessed using the standard Get-Help cmdlet:

<#
.SYNOPSIS
    Restarts remote computers based on uptime threshold.

.DESCRIPTION
    This script queries a list of computers, checks their uptime, and restarts
    those that have been running longer than the specified threshold. Useful
    for ensuring regular restarts to apply updates and clear memory leaks.

.PARAMETER ComputerListPath
    Path to text file containing one computer name per line.

.PARAMETER UptimeDays
    Computers running longer than this many days will be restarted.

.PARAMETER LogPath
    Path where execution logs will be written.

.EXAMPLE
    .\Restart-ByUptime.ps1 -ComputerListPath "C:\Scripts\computers.txt" -UptimeDays 30

.NOTES
    Author: IT Operations Team
    Last Modified: 2024-01-15
    Requires: PowerShell 5.1 or later, WinRM enabled on target computers
#>

param(
    [Parameter(Mandatory=$true)]
    [string]$ComputerListPath,
    
    [Parameter(Mandatory=$false)]
    [int]$UptimeDays = 30,
    
    [Parameter(Mandatory=$false)]
    [string]$LogPath = "C:\Logs\RestartLog_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"
)

# Script implementation follows...

This comment-based help block provides comprehensive information about what the script does, what parameters it accepts, usage examples, and important notes about requirements. Users can access this information by running Get-Help .\Restart-ByUptime.ps1 -Full, which displays the documentation in the same format as built-in PowerShell cmdlet help.

Operational Runbooks

Beyond individual script documentation, operational runbooks document complete procedures including when to use specific scripts, what to verify before execution, what to monitor during execution, and how to validate success afterward. Runbooks transform isolated scripts into documented operational procedures that anyone on the team can follow:

• 📋 Procedure Name: Monthly Workstation Restart Maintenance
• 📅 Schedule: First Sunday of each month, 2:00 AM
• ⏱️ Expected Duration: 2-3 hours for 500 workstations
• 🎯 Objective: Restart workstations to apply Windows updates and clear memory leaks
• ✅ Prerequisites: Verify backup completion, ensure no critical business processes running
• 🔧 Execution Steps: Run restart script with uptime threshold, monitor progress, verify completion
• 🔍 Validation: Check log files for failures, verify computers are online post-restart
• 🚨 Rollback: No rollback needed—computers that failed to restart remain in previous state
• 📞 Escalation: Contact senior administrator if more than 10% of computers fail

Runbooks bridge the gap between technical scripts and operational procedures, ensuring that automation serves business objectives rather than existing in isolation. They provide context that scripts alone cannot convey—why this automation exists, when it should run, what constitutes success, and what to do when things go wrong.

How do I restart a remote computer using PowerShell?

Use the Restart-Computer -ComputerName "RemotePC" -Force command. The -Force parameter ensures the restart completes even if users are logged in or applications are running. Ensure WinRM is enabled on the remote computer and you have administrative privileges.

What should I do if remote restart commands fail with "Access Denied" errors?

Verify that your user account has local administrator privileges on the target computer. In domain environments, check that you're using domain credentials with appropriate permissions. For workgroup computers, you may need to add them to the TrustedHosts list and specify credentials explicitly using the -Credential parameter.

Can I restart multiple computers at once with PowerShell?

Yes, provide multiple computer names to the -ComputerName parameter as an array: Restart-Computer -ComputerName "PC01","PC02","PC03" -Force. For larger lists, read computer names from a text file using Get-Content and pass the result to the -ComputerName parameter.

How can I schedule automatic restarts for specific times?

Create a Windows Scheduled Task that executes a PowerShell restart command at your desired time. Use the Register-ScheduledTask cmdlet to create the task programmatically, or use Task Scheduler GUI to create it manually. Ensure the task runs with appropriate privileges (typically SYSTEM account) and configure it to run whether users are logged in or not.

Is there a way to restart computers only if they've been running for a certain period?

Yes, query the Win32_OperatingSystem class to get the last boot time, calculate uptime, and conditionally restart based on your threshold. Use Get-CimInstance -ClassName Win32_OperatingSystem to retrieve the LastBootUpTime property, then compare it to the current date to determine uptime in days.

What's the difference between Restart-Computer and using shutdown.exe?

Restart-Computer is a native PowerShell cmdlet with better integration into PowerShell scripts, error handling, and object-oriented output. The shutdown.exe command-line utility is older but works on legacy systems and offers some unique parameters. For modern environments, Restart-Computer is generally preferred for its consistency and PowerShell-native features.