How to Reboot a Remote Computer via WMI (No Extra Software Needed)

A monitored service has gone down. The server is still up, no crash, no alert storm, just one stubborn service that won't respond. Your fastest path back? A remote reboot, triggered automatically, using tools already built into Windows.

Windows Management Instrumentation (WMI) makes this possible without installing anything on the target machine. No agents, no third-party utilities, just a lightweight script and the right permissions.

In this guide you'll learn:

• What WMI reboots are and when to use them
• What you need before running your first remote reboot
• The exact VBS script to get it done
• How to automate reboots with PRTG when a service fails
• How to fix the most common errors

What Is a WMI Reboot and Why Does It Matter?

Windows Management Instrumentation (WMI) is a built-in Windows framework that lets administrators query and control system settings, services, and hardware, locally or across a network. It's been part of Windows since Windows 2000, so it's available on virtually every Windows machine you'll ever manage.

A WMI reboot uses this framework to send a restart command to a remote computer over the network. A few reasons it's worth knowing:

• No software installation required. WMI is native to Windows. Nothing needs to be deployed to the target machine.
• Works across your entire Windows environment. Any WMI-capable Windows machine is a valid target.
• Scriptable and automatable. Pair it with a monitoring tool like PRTG and reboots can trigger themselves.
• Faster than RDP. No need to open a remote desktop session just to click Restart.

Good use cases for a WMI reboot:

• A service has failed but the server is still online
• A process is hung and unresponsive
• You want to automate recovery without manual intervention
• You're managing servers without a remote desktop setup

Before You Start: What You'll Need

Before running a WMI reboot, make sure these conditions are met on both machines.

On the target machine:

• WMI service is running. Check via Services (services.msc) and confirm "Windows Management Instrumentation" is set to Automatic.
• Remote WMI access is enabled. Domain-joined machines usually have this on by default. Standalone machines may need it enabled manually.
• Firewall allows WMI traffic. Open TCP port 135 (RPC endpoint mapper) plus the dynamic RPC port range, or just enable the built-in "Windows Management Instrumentation (WMI)" firewall rule in Windows Defender Firewall.
• C:\temp folder exists on the target machine. The script writes a log file there. If the folder is missing, the script will fail — sometimes with a misleading "RPC Server unavailable" error. Create it manually before running the script.

On your machine (the one running the script):

• Admin credentials for the target. Local administrator or domain admin access is required. You'll need the username, password, and domain name to put into the script.
• Script execution environment. The VBS script runs natively via cscript.exe, no additional runtime needed.

If you're using PRTG:

• PRTG must already be monitoring the target device.
• The PRTG core server machine needs network access to the target and valid credentials. Note: PRTG always executes notifications from the core server, not from remote probes.

💡 If you're already using PRTG's WMI sensors to monitor Windows machines, your credentials and network access are probably already set up correctly.

The WMI Reboot Script (VBS)

The script below is the official Paessler-provided VBS script for remote WMI reboots. It connects to the target machine using explicit credentials, handles errors, and writes a log file to C:\temp\ScriptLog.txt so you can confirm it ran.

The script:

' *************************************************************************
' PRTG CUSTOM EXE Notification - reboots a remote computer via WMI
' *************************************************************************
' Created by Paessler Support Team - open source, no warranty
'
' Set your parameters below, then save as reboot.vbs

On Error Resume Next

strComputer  = "MyComputer"   ' hostname or IP of the machine to reboot
strDomain    = "MyDomain"     ' domain name; use "" if not domain-joined
strUser      = "MyName"       ' admin username on the target machine
strPassword  = "MyPassword"   ' password for the above account

' *************************************************************************
' Code section - no changes needed below this line
' *************************************************************************

Set objFSO  = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.CreateTextFile("C:\temp\ScriptLog.txt", True)

Set objSWbemLocator  = CreateObject("WbemScripting.SWbemLocator")
Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, _
                           "root\cimv2", _
                           strUser, _
                           strPassword, _
                           "", _
                           "ntlmdomain:" + strDomain, _
                           "128")

If Err.Number <> 0 Then
    objFile.WriteLine(Err.Description)
    WScript.Quit(Err.Number)
Else
    On Error GoTo 0
    Set colSwbemObjectSet = objSWbemServices.ExecQuery("Select * From Win32_OperatingSystem")
    For Each objSystem in colSwbemObjectSet
        objSystem.Reboot
    Next
    objFile.WriteLine("Success")
    WScript.Quit("0")
End If

What each part does:

• strComputer: Replace MyComputer with the hostname or IP of the machine you want to reboot.
• strDomain: Your Windows domain name. If the machine is not domain-joined, use an empty string "".
• strUser / strPassword: Admin credentials on the target machine. Same credentials you'd use in PRTG for WMI monitoring.
• ConnectServer: Establishes the authenticated WMI connection to the remote machine.
• Win32_OperatingSystem: The WMI class that represents the OS. Its Reboot method triggers the restart.
• Log file: Result (success or error) is written to C:\temp\ScriptLog.txt on the machine running the script.

To run it manually:

1. Fill in your strComputer, strDomain, strUser, and strPassword values
2. Save the file as reboot.vbs (when saving in Notepad, wrap the filename in quotes to avoid it saving as .vbs.txt)
3. Open a command prompt as Administrator
4. Run: cscript reboot.vbs
5. Check C:\temp\ScriptLog.txt to confirm the result

📌 For a modified version that reboots multiple servers with configurable delays, see the Paessler Knowledge Base article on WMI reboots.

How to Automate Reboots with PRTG

Running the script manually is useful. But the real value is automating it. PRTG Network Monitor can watch your services around the clock and trigger a reboot the moment something goes wrong, no manual intervention needed.

Step 1: Add the script to PRTG

• Place reboot.vbs in the PRTG notifications folder: C:\Program Files (x86)\PRTG Network Monitor\Notifications\EXE
• PRTG will now recognize it as an executable notification.

Step 2: Create an "Execute Program" notification

• In PRTG, go to Setup > Account Settings > Notifications
• Click Add new notification
• Give it a clear name, e.g. "Reboot MyComputer"
• Select Execute Program as the notification method
• Choose reboot.vbs from the dropdown
• You can leave the Parameter field empty, then click Save

Step 3: Set your trigger

• Navigate to the sensor you want to monitor (e.g., a Windows Service sensor)
• Click the Notifications tab, then Add State Trigger
• Set Condition to Down
• In the latency field, enter 900 (seconds) to wait 15 minutes before triggering. This gives the sensor a chance to recover on its own before a reboot fires
• Under "perform notification", select your "Reboot MyComputer" notification
• Click Save

What happens next:

• PRTG detects the service failure
• Waits 15 minutes to rule out a transient blip
• Fires the notification, which runs the VBS script from the PRTG core server
• The remote machine reboots and the service comes back online
• PRTG confirms recovery when the sensor returns to Up

💡 You can test the whole setup without waiting for a real failure. Right-click the sensor in the device tree and select Simulate Error Status. After the latency period, the reboot will fire.

💡 You can monitor Windows services directly with PRTG's built-in Windows Service sensor. If WMI is already set up, no extra configuration needed.

Note: PRTG always executes notifications from the core server, never from a remote probe. Make sure your core server has network access to the machine you want to reboot.

Common Issues and Quick Fixes

WMI reboots are reliable once configured. But a few things can trip you up on the first run.

• "RPC Server unavailable" or script fails silently. The most common cause is a missing C:\temp folder on the machine running the script. Create it manually and try again.
• "Access is denied" error. The account running the script doesn't have admin rights on the target machine. Verify you're using a local administrator or domain admin account. Also check DCOM permissions: open dcomcnfg, go to Component Services > Computers > My Computer > Properties > COM Security, and confirm remote access is allowed.
• WMI service not running. On the target machine, open services.msc and confirm "Windows Management Instrumentation" is running and set to Automatic. If it's stopped, start it manually.
• Firewall blocking the connection. WMI uses TCP port 135 plus a dynamic RPC port range. In Windows Defender Firewall, enable the built-in "Windows Management Instrumentation (WMI)" inbound rule. That handles all required ports automatically.
• Script runs but nothing happens. Double-check the computer name or IP in strComputer. Test basic WMI connectivity first by running wmic /node:"TARGET_NAME" os get caption from a command prompt. Also check C:\temp\ScriptLog.txt for error details.
• PRTG notification not firing. Confirm the script is in the correct PRTG notifications folder, the trigger threshold is set correctly, and that you're checking the core server (not a remote probe) for execution.

Set It Up Once, Let It Run

A WMI reboot is one of the more practical things you can add to a Windows monitoring setup. It's built into the OS, nothing to install on either end, and when you connect it to PRTG it turns a service failure into something that just fixes itself.

To recap:

• WMI is native to Windows, no agents or third-party tools needed
• The VBS script handles the reboot using explicit credentials and logs the result to C:\temp\ScriptLog.txt
• PRTG's "Execute Program" notification ties it all together with threshold-based automation
• Most errors come down to a missing C:\temp folder, permissions, or firewall rules — all straightforward to fix

If you want to monitor your Windows environment and set up automated recovery like this, PRTG has a 30-day free trial with no credit card required.