How to Check for Windows Updates via PowerShell?

TL;DR

• PowerShell gives Windows administrators several ways to check and install updates, including the native Windows Update COM API, the PSWindowsUpdate module, legacy wuauclt commands, and built-in Windows Update scheduled tasks.
• The native COM API is best for quick, dependency-free update checks, while PSWindowsUpdate is the most practical choice for full automation, including scanning, filtering, downloading, installing, and rebooting after updates.
• PSWindowsUpdate can target specific updates or KBs, install only security updates, include Microsoft product updates, and run jobs across multiple endpoints using Invoke-WUJob.
• Standard users can trigger an update detection scan without administrator rights by invoking Windows’ existing Windows Update or UpdateOrchestrator scheduled tasks, although actual update installation still requires elevated or SYSTEM-level privileges.
• Legacy wuauclt /detectnow still appears in older guidance, but it is deprecated on modern Windows and may not reliably trigger scans, making COM-based or scheduled-task approaches better choices.
• Error 1053 can block Windows Update automation when wuauserv fails to start in time; possible remediation includes checking Windows Update components and, where appropriate, increasing ServicesPipeTimeout before rebooting.
• RMM platforms such as ScreenConnect, Atera, and NinjaOne can execute update scripts as SYSTEM, making them suitable for remotely automating patch scans and installations across distributed Windows fleets.
• Action1 provides a centralized alternative for large environments, continuously identifying missing Windows and supported third-party updates across endpoints without requiring administrators to run PowerShell commands on each device individually.
• With Action1, administrators can use Missing Updates, Update Approval, and built-in patch reports to identify affected endpoints, prioritize missing patches, deploy updates, and verify results from one console.
• For a single computer, PowerShell is flexible and efficient; for hundreds or thousands of endpoints, centralized patch management provides better visibility, reporting, automation, and operational scalability.

The Windows Update GUI works fine for one machine. But it’s an impractical option when you have to manage Windows updates for twenty, two hundred, or two thousand endpoints. You can’t click through Settings on every machine in a domain, and you can’t wait for users to notice the little red dot on the Start menu. It gets worse when the machines aren’t domain-joined and there’s no local WSUS server. Using Group Policy isn’t an option either.

When you search for a way to handle Windows updates through PowerShell, you land on scattered forum posts, incomplete scripts, and Reddit comments that solve only part of the problem. None of them work well as a reference that you can follow or add to a runbook.

This guide walks you through the main methods for checking, triggering, and installing Windows updates with PowerShell:

• The built-in COM API
• The PSWindowsUpdate module
• The legacy wuauclt command
• A no-admin-rights workaround

It also discusses how to resolve the Error 1053 service failure that blocks these methods from working, and shows how these methods fit into an RMM-driven MSP workflow.

Method 1 — Native Windows Update COM API

Windows ships with a Windows Update Agent COM API that PowerShell can call directly. This is the fastest way to check for available Windows updates. It does not require extra modules or downloads. Simply run:

(New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher().Search(“IsHidden=0 and IsInstalled=0”).Updates | Select-Object Title

Here’s what each piece does:

Microsoft.Update.Session	Creates a session with the Windows Update Agent (WUA), the Windows component that is responsible for scanning, downloading, and installing updates.
CreateUpdateSearcher()	Creates an update searcher that can query Windows Update using WUA search criteria.
Search(“IsHidden=0 and IsInstalled=0”)	Searches for updates that are not hidden and not already installed, i.e., your list of pending updates.
.Updates	Returns the collection of updates that match the search criteria.
Select-Object Title	Displays only the update titles instead of the full update objects.

 

The command returns one object per available update with only the Title property displayed. An example output looks like:

Title

—–

2026-07 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5061234)

Security Intelligence Update for Microsoft Defender Antivirus – KB2267602

2026-07 .NET 9.0 Cumulative Update for x64 Client (KB5065678)

If no updates are available, nothing is returned.

This approach only checks for available updates. To download and install updates using the COM API, you need to write several lines of code to create the UpdateDownloader and UpdateInstaller objects, accept license agreements, and manage reboots manually.

ℹ️ When to use this method:

• If you only need a quick, dependency-free update check, this method is ideal.
• If you want a single command to scan, download, install, and reboot, use the PSWindowsUpdate

Method 2 — PSWindowsUpdate Module

PSWindowsUpdate is a community PowerShell module that wraps the Windows Update COM API in cmdlets that feel like native PowerShell. But you’ll need to install it first because it isn’t installed by default on Windows.

Install the PSWindowsUpdate Module

Run the following from an elevated PowerShell session:

Install-Module -Name PSWindowsUpdate -Force
Import-Module PSWindowsUpdate

The first command downloads the module from the PowerShell Gallery, so the machine needs internet access and TLS 1.2 support, which is enabled by default on all currently supported versions of Windows.

If your environment blocks access to the PowerShell Gallery, download and package the module on another machine. Then deploy it using your software distribution tool.

💡 Tip: To see every cmdlet and alias that the PSWindowsUpdate module provides, run:

Get-Command -Module PSWindowsUpdate

Check for Updates Without Installing

Run the following cmdlet to get a list of pending Windows updates:

Get-WindowsUpdate

The cmdlet does not download or install anything. This makes it a safe choice for audit scripts, health checks, and scheduled compliance scans.

Install all Available Updates and Reboot Automatically

Get-WindowsUpdate -AcceptAll -Install -AutoReboot

Here’s what each parameter does:

-Install	Downloads and installs the updates that Get-WindowsUpdate found.
-AcceptAll	Automatically accepts all updates and skips the interactive confirmation prompt for each update.
-AutoReboot	Restarts the computer automatically after the installation is completed, in case a reboot is required. Drop it if you want to schedule the restart separately, such as on a production server.

 

Install Specific Updates

If you don’t want to install all available updates, use the PowerShell pipeline to filter the list first:

Get-WindowsUpdate |
Where-Object Title -like “*Security*” |
Install-WindowsUpdate -AcceptAll

The pipeline lets you filter the updates before installing them. In this example, only updates whose title contains “Security” are passed to Install-WindowsUpdate, and all other available updates are skipped.

If you know the KB number of the update you want to install, use the -KBArticleID parameter to target that update directly.

Get-WindowsUpdate -KBArticleID KB5061234 -Install -AcceptAll

Replace KB5061234 with the KB number of the update you want to install.

Pull in Non-OS Microsoft Updates

By default, Get-WindowsUpdate scans for Windows OS updates. Add -MicrosoftUpdate to also include updates for other Microsoft products, such as Microsoft Office, that are delivered through the Microsoft Update service.

Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install -AutoReboot

Install Updates on Multiple Computers

When you have to install updates on multiple computers, Invoke-WUJob lets you create and run a scheduled update task on each target machine, such as all machines in an organizational unit (OU). This is a better approach than a live remote session, since Windows Update work can run long and remote sessions time out.

Invoke-WUJob -ComputerName (Get-ADComputer -Filter * -SearchBase “OU=Workstations,DC=corp,DC=local”).Name `
-Script “Import-Module PSWindowsUpdate; Get-WindowsUpdate -AcceptAll -Install -AutoReboot | Out-File C:\WU-Log.txt” `
-RunNow -Confirm:$false

Invoke-WUJob creates a scheduled task on each target computer that runs the update job locally and writes the command output to C:\WU-Log.txt. Because the work happens on the endpoint itself, it scales much better than keeping a separate remote PowerShell session open for every machine.

📌 Important: Before using Invoke-WUJob, make sure the PSWindowsUpdate module is installed on every target computer. Deploy the module once through your software deployment or endpoint management tool and then use Invoke-WUJob for update jobs.

Method 3 — wuauclt and the No-Admin-Rights Path

One question that is usually asked on forums is, how do you trigger a Windows Update check as a standard user, without elevation or local administrator rights. The answer has two parts. Installing updates requires administrative or SYSTEM-level privileges because Windows Update modifies drivers and protected system files that a standard user account can’t change. Triggering a Windows Update detection scan, however, does not require that level of access, which makes a no-admin workflow possible.

wuauclt /detectnow: What it Does

wuauclt is a legacy Windows command-line utility, not a PowerShell cmdlet. It’s still frequently mentioned in older documentation and forum posts, so it’s worth a mention. You can run it from PowerShell, Command Prompt, or the Run dialog.

wuauclt /detectnow

When you run it, Windows Update Agent starts an update detection scan. It checks whether new updates are available. It does not download or install updates, and it does not override the update policies configured on the machine.

⚠️ Caution: On current versions of Windows, wuauclt is a deprecated utility that hands off most of its work to the newer Update Orchestrator service. As a result, it may not reliably trigger an update scan, especially when run as a standard user, even if the command completes without an error.

PowerShell Alternative

If you prefer PowerShell, this command requests an update detection scan through the Windows Update Agent:

(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()

Like wuauclt /detectnow, it does not download or install updates. The scan follows the update policies configured on the computer.

The No-Admin Workaround: Trigger the Built-in Scheduled Task

Windows already includes scheduled tasks that handle update scans. You can find them under Task Scheduler Library > Microsoft > Windows > WindowsUpdate (or UpdateOrchestrator on newer versions of Windows). These tasks are configured to run under the SYSTEM account, so instead of trying to elevate PowerShell, a standard user can trigger the existing task:

schtasks /run /tn “\Microsoft\Windows\WindowsUpdate\Scheduled Start”

On newer versions of Windows, use:

schtasks /run /tn “\Microsoft\Windows\UpdateOrchestrator\Scheduled Start”

You’re not gaining admin rights here. You’re invoking a task that Windows already configured to run elevated, much like what happens when a standard user clicks ‘Check for updates’ in the Settings app.

ℹ️ Note: Task names vary in different Windows versions and builds. If the commands above don’t work on your system, open Task Scheduler, navigate to Task Scheduler Library > Microsoft > Windows, and click WindowsUpdate or UpdateOrchestrator. Then verify the name of the appropriate task and replace Scheduled Start with that name.

Run the Update Check Automatically at Logon

If you want to trigger an update check every time a user logs in, add a ‘Run’ registry entry under the current user’s profile. This starts the existing Windows Update scheduled task automatically at logon without requiring administrator rights. Run the following commands in PowerShell to create the Run registry entry:

New-Item -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Run’ -Name Dummy -Force | Out-Null
Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Run’ `
-Name ‘CheckWU’ `
-Value ‘powershell.exe -WindowStyle Hidden -Command “schtasks /run /tn \”\Microsoft\Windows\WindowsUpdate\Scheduled Start\””‘

Because the entry is created under HKEY_CURRENT_USER, you do not need administrator privileges to create it. Now whenever that user signs in, Windows launches the command, which triggers the existing SYSTEM-context scheduled task to check for updates. Remember that this only starts an update detection scan. It doesn’t download or install updates, so you’ll still need your normal patch management process to handle those steps.

Fixing “Windows Update Service Won’t Start” (Error 1053)

If every method above fails with Error 1053 (“The service did not respond to the start or control request in a timely fashion”) and the Windows Update service refuses to start, the problem may not be Windows Update itself. In some cases, It’s the Service Control Manager timing out before wuauserv finishes initializing, particularly on systems with many services starting at the same time.

A common fix is to increase the amount of time the Service Control Manager waits before timing out a service. To make the change manually:

1. Open Registry Editor (regedit).
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.
3. Create a new DWORD (32-bit) value named ServicesPipeTimeout.
4. Set its value to 180000 (decimal), which is 180 seconds (three minutes).
5. Restart the computer. This new timeout takes effect after a reboot.

You can also use PowerShell to create the registry value:

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control’ `
-Name ‘ServicesPipeTimeout’ -Value 180000 -PropertyType DWord -Force
Restart-Computer -Force

💡 Tip: Before changing the registry on production systems, check whether ServicesPipeTimeout already exists with a different value and back up the registry key. Some applications and server workloads increase this timeout when they are installed, so you don’t want to overwrite an existing configuration unintentionally.

ℹ️ Note: Error 1053 on wuauserv can also stem from corrupted update cache files (like C:\Windows\SoftwareDistribution) or broken system files. Reset Windows Update components if modifying the registry timeout doesn’t resolve it.

Running Windows Updates at Scale Through an RMM Platform

If you manage computers through an RMM platform such as ScreenConnect, Atera, or NinjaOne, the update process is quite the same, with one important difference: scripts usually run as the SYSTEM account rather than the currently signed-in user. This is an advantage because SYSTEM already has the permissions needed to use both the PSWindowsUpdate module and the Windows Update COM API. In most cases, you can run Get-WindowsUpdate -AcceptAll -Install -AutoReboot as a scheduled or on-demand script without worrying about elevation prompts.

When deploying update scripts through an RMM platform:

• Make sure the PSWindowsUpdate module is available on target endpoints. If it isn’t already installed, deploy it first or include the installation step in the script, provided the machine can access the PowerShell Gallery.
• Write the output to a log file. Many RMM consoles don’t reliably display Write-Host output from scripts running as SYSTEM, so the log file can help in troubleshooting.
• Avoid -AutoReboot on scripts that run during business hours. Schedule the reboot separately so that active users are not disrupted. If your version of PSWindowsUpdate supports -ScheduleReboot, then that’s a better option.
• If a computer is affected by the wuauserv startup timeout described earlier (Error 1053), you can include the ServicesPipeTimeout registry change in the same remediation script because it’s a one-time configuration change followed by a reboot.

Comparing Windows Update Methods

The following table summarizes when to use each method and what it can do.

Method	Admin Rights Required	Works Remotely / RMM Friendly	Installs or Check-Only	External Module Needed
Native COM API	No (check only)	Limited (requires PowerShell Remoting or similar)	Check-only	No
PSWindowsUpdate	Yes (for installation)	Yes	Both	Yes (PSWindowsUpdate)
wuauclt / scheduled task trigger	No (trigger only)	Limited (per-machine trigger)	Check-only (triggers detection)	No
Settings / GUI	Yes (for installation)	No	Both	No

 

In a nutshell:

• For a quick update check on a single computer, use the native COM API.
• For routine administration, automation, or when managing multiple computers, PSWindowsUpdate is the most practical choice.
• If you have to trigger an update detection scan without administrator rights, use the existing Windows Update scheduled task.

How to Check for Missing Windows Updates with Action1?

PowerShell works well when you need to check an individual machine or incorporate update detection into a script. When you manage dozens, hundreds, or thousands of endpoints, however, Action1 provides a centralized way to see which Windows updates are missing across the entire environment without running update-check commands manually on each computer.

Action1 continuously refreshes endpoint information, including missing patches, so administrators don’t have to schedule a separate periodic assessment just to identify missing updates.

Make Sure the Windows Endpoint Is Connected to Action1

The Windows computer must first have the Action1 agent installed and be connected to the Action1 Cloud.

In the Action1 console:

1. Navigate to Endpoints.
2. Confirm that the Windows device appears in the endpoint list.
3. Verify that the endpoint is connected.

If the machine hasn’t been added yet, click Install Agent, download the Windows agent package configured for your organization, and install it on the endpoint. Once connected, Action1 begins collecting endpoint information, including missing updates.

Open the Endpoint You Want to Check

Go to Endpoints and click the name of the Windows computer you want to inspect.

This opens the endpoint details page, where Action1 provides information about the device’s software, hardware, operating system, and update status.

Open the Missing Updates Tab

Select the Missing Updates tab for the endpoint.

Action1 displays the updates currently applicable to that computer but not yet installed. The same view can contain both Windows and supported third-party application updates.

You can review details such as:

• Update name
• Windows KB
• Severity
• Version
• Release date
• Vendor
• Status

Action1 can also display the vulnerabilities associated with individual missing updates, helping administrators understand which security issues would be remediated by installing a particular patch.

Filter the Results to Find Important Windows Updates

Use the available filters to narrow the missing-update list.

For example, you can filter according to Severity or Status to focus on updates that require the most immediate attention.

If you’re performing a security review, this makes it easier to identify missing Critical or High-severity Windows patches rather than manually comparing installed KB numbers against Microsoft’s update catalog.

Check Missing Updates Across All Windows Endpoints

You don’t have to inspect computers individually.

Open Update Approval from the Action1 navigation pane to see pending updates across your managed environment.

For each update, Action1 shows information including its severity, version, release date, vendor, and the number of endpoints that are missing it. Clicking an update lets you see which computers are affected.

For example, instead of running:

Get-WindowsUpdate

on 200 computers and collecting the output, you can use the Update Approval view to identify a Windows cumulative update and immediately see all managed endpoints that still require it.

Run a Missing Windows Updates Report

For a Windows-specific fleet-wide audit, navigate to:

Real-Time Reports & Alerts → Built-in Reports → Patch Management

Action1 provides several reports specifically for this purpose, including:

• Missing Windows Updates
• Missing Windows Critical Updates
• Missing Third-Party & Windows Updates

The Missing Windows Updates report focuses specifically on Windows patches that are still required across managed endpoints, while Missing Windows Critical Updates helps narrow the results to the highest-priority Windows patches.

You can also use Windows Update History to examine successful and failed Windows Update operations, and Windows Update Statistic to determine when managed endpoints were last updated.

Deploy the Missing Updates if Required

After identifying the missing patches, you can remediate them directly from Action1 rather than switching to another tool.

Select the required updates and use Install Now to deploy them to the affected endpoints. Alternatively, you can configure patch management automations to deploy updates according to your organization’s schedule and approval policy.

This turns the workflow from:

check endpoint → identify missing KB → manually install update

into:

detect → prioritize → deploy → verify

from the same management console.

Action1 vs. PowerShell for Checking Missing Windows Updates

The PowerShell methods described above remain useful for troubleshooting and individual machines. For example, the Windows Update COM API provides a dependency-free way to query pending updates, while PSWindowsUpdate provides more convenient cmdlets for checking and installing them.

Action1 is better suited to situations where the same check needs to be performed across an entire fleet. Instead of executing a command on every endpoint and aggregating the results yourself, administrators can use the Missing Updates view, Update Approval, and built-in reports to see which Windows patches are missing and which computers are affected from one console.