This article applies as of PRTG 21
I use the Windows Update Status (PowerShell) sensor to be up to date on available and installed Windows updates on my machines. However, the sensor is recently throwing errors when it used to work fine in the past. Can you explain why this happens and help me solve the issues?
Important note:
As of PRTG 21.x.66, the Windows Update Status (PowerShell) sensor supports Negotiate authentication, with which you can use this sensor outside of domains. Find configuration instructions in section 2.2.
As of PRTG 18.4.47, the Windows Update Status (PowerShell) sensor only shows the default channel Time since last update after creating the sensor. Other channels are created as needed when respective data arrives. If the sensor does not receive any other data, it does not create additional channels.
As of PRTG 17.4.36, the Windows Update Status (PowerShell) sensor requires at least PowerShell 3.0, which must be installed on both the probe machine and the target system. For more information, see Windows Update Status (PowerShell) sensor: Detailed Requirements.
Potential issues with the Windows Update Status (PowerShell) sensor and how to resolve them
You may encounter issues when you use the Windows Update Status (PowerShell) sensor. This article lists the most common issues and how to resolve them.
1. Potentials issues and solutions
| Problem | The sensor shows a timeout error and PE018. |
|---|---|
| Solution | There are two possible reasons for that - either the sensor simply could not connect to the target host or the PowerShell command probably takes too long to execute. Try to manually run the commands as shown above via a remote PowerShell session and see how long they take. If the command executes within the given time span of 20 minutes, run Windows Update and install all updates available for the system. If the remote PowerShell session fails to connect, configure WinRM on the target host: https://technet.microsoft.com/en-us/library/ff700227.aspx It might also be possible that the Windows Desktop Experience is installed on the server. If so, remove it because it will cause the update search to inevitably fail. |
| Problem | The sensor shows a Kerberos authentication error and something about missing login servers. |
|---|---|
| Solution | If the server you are checking is located in a workgroup, that is the problem as the sensor currently does not work with workgroups. There is currently nothing you can do about it. We are looking into this, but cannot promise anything. The sensor relies on Kerberos authentication, which is only available within a domain. |
| Problem | The sensor shows an Exception from HRESULT: 0x80072EFD error. |
|---|---|
| Solution | The error is rather ambiguous and can have multiple reasons. Either there is a problem with the internet connection of the target host or the sensor cannot connect to the WSUS server. Try to manually install updates to see if that solves the issue. |
| Problem | The sensor shows an Exception from HRESULT: 0x8024402F error. |
|---|---|
| Solution | 1. Remove the contents of C:\ProgramData\Microsoft\Windows\Caches. 2. Rename Caches to Cache. 3. Start Windows Update. The error will occur again. 4. Rename Cache back to Caches and start Windows Update again. The sensor should work properly now. Also, you need to manually install any available updates on the target host to rebuild the update database. |
| Problem | The command basically works, but takes rather long. |
|---|---|
| Solution | According to one of our customers, it helps to clean out old updates in the WSUS to improve performance. This should increase the search speed as less updates are indexed. |
| Problem | The sensor shows a PowerShell version not supported. Current PowerShell major version: 2. Please install PowerShell 3.0 or later error. |
|---|---|
| Solution | Install PowerShell 3.0 or Windows Management Framework 3.0 or later on the target machine you want to monitor. |
| Problem | The sensor shows a This sensor requires that PowerShell 2.0 or higher is installed on the probe system ( Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Management.Automation, Version=3.0.0.0(...) (code: PE181) error. |
|---|---|
| Solution | This error message is wrong and has been adjusted. Install PowerShell 3.0 or Windows Management Framework 3.0 or later on the probe system. |
Issues on Windows 10, Windows Server 2016, or later
The following issues only occur on target machines running Windows 10, Windows Server 2016, or later:
| Problem | The sensor shows a We could not identify a successful update in the last 10,000 history entries of Windows Update error. |
|---|---|
| Solution | PRTG searched 10,000 entries of the history and was not able to find a successfully installed update. Run Windows Update and try to manually install an update. Contact support for further assistance. |
| Problem | The sensor shows an Update history does not contain any entries. Please enable the sensor debug options and contact support for further help error. |
|---|---|
| Solution | This error occurred when there were some serious issues on the target device. Contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem. |
2. Additional Topics
2.1 Functionality of the sensor
Here are the (simplified) steps that the sensor takes:
1. Use Windows credentials to open a remote PowerShell session to the target.
2. Execute the following command on the target host:
Note: For systems that run Windows versions as of Windows 10 or Windows Server 2016, a remote scheduled task executes this step.$searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").UpdatesThis command basically gets all the updates available for this system.
Note: The sensor works in environments that use the normal update routine and in networks that have their own WSUS server.
2.1.1 Potential issues
While it may seem trivial, Windows updates can easily accumulate over time, resulting in hundreds of objects that have to be analyzed. The most crucial step is the second one. Depending on the amount of available updates and the bandwidth of the host (or the local WSUS), it can easily take minutes or even hours until the command is executed.
And that is the actual problem. If the sensor takes 20 minutes or more to execute the command, the child process is terminated. This is hard-coded and cannot be changed. You can discern if this is what happens to the Windows Update Status (PowerShell) sensor on your system by benchmarking the above-mentioned command via Measure-Command:Measure-Command { $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates}
This command will result in something like this (example values):
Days : 0 Hours : 0 Minutes : 0 Seconds : 43 Milliseconds : 980 Ticks : 9807034 TotalDays : 1.13507337962963E-05 TotalHours : 0.000272417611111111 TotalMinutes : 0.439807034 TotalSeconds : 43.9807034 TotalMilliseconds : 43.980.7034
This type of output is fine but your command execution time may vary depending on the actual updates you have installed.
2.2 How to use the Windows Update Status (PowerShell) sensor with Negotiate authentication
In some scenarios it is necessary to configure the probe and the target system.
- You have to add a new trusted host on the probe system and update the firewall settings on the target system.
Add a new trusted host (for example, if you use Negotiate authentication with an IP address)
1. Open PowerShell with administrator privileges on the probe system.
2. Run the following commands:
- Get a list of trusted hosts:
Get-Item WSMan:\localhost\Client\TrustedHosts
- Add a new trusted host:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]
- Patch the trusted hosts:
Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value Server02
Update the firewall settings on the target system (for example, if you use Negotiate authentication with workgroups or across domains without trust)
- Open PowerShell with administrator privileges on the target system.
- Run the following command to update the firewall rules:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress <ip adress of the probe>
More
- For a list of sensors that PRTG offers, see the PRTG Manual: List of Available Sensor Types, and discover, for example, the WSUS Statistics sensor.
- For more sensors written by Paessler and PRTG users, see the PRTG Sensor Hub or the Paessler Knowledge Base.
- Which sensor types will you remove from PRTG and what are the alternatives?
Disclaimer:
The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.
