New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Facing issues with the Windows Update Status (PowerShell) sensor - can you help me?

Votes:

6

Your Vote:

Up

Down

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?

cleanup error-messages powershell prtg update windows windows-update-sensor

Created on Oct 31, 2016 8:11:01 PM by  Stephan Linke [Paessler Support]

Last change on Sep 13, 2019 4:53:52 AM by  Maike Behnsen [Paessler Support]



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down


Important note:

As of version 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. See section 6 for more information.

As of version 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.


This article applies to PRTG Network Monitor 19 or later

A New Era of the Windows Update Status (PowerShell) Sensor

The Windows operating system changed quite a bit and as a consequence, the Windows Update Status (PowerShell) sensor had to change, too. See here what exactly changed and what you can do to stay up to date on Windows updates again.

1. Introduction

With PRTG 16.4.27, we finished the sensor cleanup and finally removed some deprecated sensors. While this worked fine for most sensors, the Windows Update Status (PowerShell) sensor is more "sensitive". This article will explain what the sensor actually does, how it works, and why it does not work in some environments.

2. Why Was the Old Sensor Removed?

The old sensor used the Windows registry to get updates from the target host. This is why it worked with hosts in domains and workgroups. However, this method of querying updates from a host is deprecated because the queried keys simply do not exist anymore on recent and future Windows versions.

3. How the Windows Update Status (PowerShell) Sensor Works

3.1 Environment

The sensor works in both environments:

  1. Networks that have their own WSUS server
  2. Environments that simply use the normal update routine

3.2 Processes

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:
$searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates This command basically gets all the updates available for this system.

3. Count all the updates depending on their state and severity and put them into corresponding channels.

3.3 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.

4. Is There a Workaround?

  1. Navigate to %programfiles(x86)%\PRTG Network Monitor\Sensor System\. For more information, see the article How and where does PRTG store its data?
  2. Copy LastWinUpdateXML.exe to %programfiles(x86)%\PRTG Network Monitor\Custom Sensors\EXEXML.
  3. Create a new EXE/Script Advanced sensor on the target host and select the LastWinUpdateXML.exe file above.
  4. Set the timeout to 900 seconds.
  5. Use the following parameters:
    -c=%host -u='%windowsdomain\%windowsuser' -p='%windowspassword' -ex
  6. Click Continue.
  7. Do not forget to configure the limits for each channel accordingly.
    Otherwise, the sensor will always show an Up status.
  8. Click Save.

You may want to add the -ex parameter to see if it gives you advanced metrics. However, the output will probably look different in comparison to the previous sensor.
If you get any errors, try to replace the single quotes (') in the parameter field with double quotes (").

5. First Aid

ProblemThe sensor shows a timeout error and PE018.
SolutionThere 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.
ProblemThe sensor shows a Kerberos authentication error and something about missing login servers.
SolutionIf 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.
ProblemThe sensor shows an Exception from HRESULT: 0x80072EFD error.
SolutionThe 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.
ProblemThe sensor shows an Exception from HRESULT: 0x8024402F error.
Solution1. 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.
ProblemThe command basically works, but takes rather long.
SolutionAccording 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.
ProblemThe sensor shows a PowerShell version not supported. Current PowerShell major version: 2. Please install PowerShell 3.0 or later error.
SolutionInstall PowerShell 3.0 or Windows Management Framework 3.0 or later on the target machine you want to monitor.
ProblemThe 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.
SolutionThis 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.

Note: With the release of version 18.4.47, we changed the approach of how to handle errors. As there is only one default channel, PRTG can just show the smallest information set if there are errors.

Errors after version 18.4.47

ProblemThe sensor shows a We could not identify a successful update in the last 10,000 history entries of Windows Update error.
SolutionPRTG 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.
ProblemThe sensor shows an Update history does not contain any entries. Please enable the sensor debug options and contact support for further help error.
SolutionThis 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.

Errors before version 18.4.47

ProblemThe sensor shows an Couldn't deserialize output from remote error.
SolutionThis error occurs when PRTG cannot deserialize the output to an object. Contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.
ProblemThe sensor shows an Couldn't deserialize output from remote. Exception from HRESULT: 0x80244022 error.
Solution0x80244022 WU_E_PT_HTTP_STATUS_SERVICE_UNAVAIL (same as HTTP status 503) - the service is temporarily overloaded (see https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list). This issue may resolve itself. The error should not only occur in PRTG, but you should be able to reproduce it on the target machine.
See also the article https://www.kjctech.net/fixing-windows-updates-failed-with-error-0x80244022/
ProblemThe sensor shows an Unable to cast object of type 'System.Management.Automation.PSCustomObject' to type 'System.Collections.ArrayList' error.
SolutionYou are running PRTG version 18.1.37 or earlier. Update your system to the latest stable PRTG version and you will receive a more meaningful error message.
ProblemThe sensor shows an The target machine HOST did not report any updates error.
SolutionPRTG searched for updates on your target machine HOST and Windows did not report any found updates. As this is unusual, the sensor changes to a Down status. A sensor in an Up status would indicate that everything is normal, which might not be the case.

Note: We changed this behavior with PRTG version 18.4.47. Update to version 18.4.47 or later.
ProblemThe following error with error code 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred.
SolutionThis might be related to the SPN configuration of the target host. See https://kb.paessler.com/en/topic/71899-facing-issues-with-the-windows-update-status-sensor-can-you-help-me#reply-297318 for details.


Regards,
Stephan Linke, Paessler Technical Support


More

Created on Aug 31, 2017 1:03:54 PM by  Martina Wittmann [Paessler Support]

Last change on Nov 29, 2019 11:50:33 AM by  Maike Behnsen [Paessler Support]



30 Replies

Votes:

0

Your Vote:

Up

Down

Hi Paessler Support, I keep getting Error PE018 on SOME of my Windows Update (Powershell) Sensors. When I run this script:

Invoke-Command -ComputerName XXX -ScriptBlock { Measure-Command { $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates | Sort-Object -Property Dates -Descending | ft -autosize IsInstalled, MsrcSeverity } }

from my PRTG Server, I get a result of just a minute runtime for the script.

What can I check next?

Created on Aug 30, 2017 12:04:06 PM by  Bernd (0)



Votes:

0

Your Vote:

Up

Down

Hi Bernd,

Most recent PRTG version (17.3.33.2686) already installed?


Kind regards,
Stephan Linke, Tech Support Team

Created on Aug 30, 2017 8:41:51 PM by  Stephan Linke [Paessler Support]



Accepted Answer

Votes:

0

Your Vote:

Up

Down


Important note:

As of version 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. See section 6 for more information.

As of version 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.


This article applies to PRTG Network Monitor 19 or later

A New Era of the Windows Update Status (PowerShell) Sensor

The Windows operating system changed quite a bit and as a consequence, the Windows Update Status (PowerShell) sensor had to change, too. See here what exactly changed and what you can do to stay up to date on Windows updates again.

1. Introduction

With PRTG 16.4.27, we finished the sensor cleanup and finally removed some deprecated sensors. While this worked fine for most sensors, the Windows Update Status (PowerShell) sensor is more "sensitive". This article will explain what the sensor actually does, how it works, and why it does not work in some environments.

2. Why Was the Old Sensor Removed?

The old sensor used the Windows registry to get updates from the target host. This is why it worked with hosts in domains and workgroups. However, this method of querying updates from a host is deprecated because the queried keys simply do not exist anymore on recent and future Windows versions.

3. How the Windows Update Status (PowerShell) Sensor Works

3.1 Environment

The sensor works in both environments:

  1. Networks that have their own WSUS server
  2. Environments that simply use the normal update routine

3.2 Processes

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:
$searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates This command basically gets all the updates available for this system.

3. Count all the updates depending on their state and severity and put them into corresponding channels.

3.3 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.

4. Is There a Workaround?

  1. Navigate to %programfiles(x86)%\PRTG Network Monitor\Sensor System\. For more information, see the article How and where does PRTG store its data?
  2. Copy LastWinUpdateXML.exe to %programfiles(x86)%\PRTG Network Monitor\Custom Sensors\EXEXML.
  3. Create a new EXE/Script Advanced sensor on the target host and select the LastWinUpdateXML.exe file above.
  4. Set the timeout to 900 seconds.
  5. Use the following parameters:
    -c=%host -u='%windowsdomain\%windowsuser' -p='%windowspassword' -ex
  6. Click Continue.
  7. Do not forget to configure the limits for each channel accordingly.
    Otherwise, the sensor will always show an Up status.
  8. Click Save.

You may want to add the -ex parameter to see if it gives you advanced metrics. However, the output will probably look different in comparison to the previous sensor.
If you get any errors, try to replace the single quotes (') in the parameter field with double quotes (").

5. First Aid

ProblemThe sensor shows a timeout error and PE018.
SolutionThere 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.
ProblemThe sensor shows a Kerberos authentication error and something about missing login servers.
SolutionIf 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.
ProblemThe sensor shows an Exception from HRESULT: 0x80072EFD error.
SolutionThe 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.
ProblemThe sensor shows an Exception from HRESULT: 0x8024402F error.
Solution1. 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.
ProblemThe command basically works, but takes rather long.
SolutionAccording 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.
ProblemThe sensor shows a PowerShell version not supported. Current PowerShell major version: 2. Please install PowerShell 3.0 or later error.
SolutionInstall PowerShell 3.0 or Windows Management Framework 3.0 or later on the target machine you want to monitor.
ProblemThe 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.
SolutionThis 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.

Note: With the release of version 18.4.47, we changed the approach of how to handle errors. As there is only one default channel, PRTG can just show the smallest information set if there are errors.

Errors after version 18.4.47

ProblemThe sensor shows a We could not identify a successful update in the last 10,000 history entries of Windows Update error.
SolutionPRTG 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.
ProblemThe sensor shows an Update history does not contain any entries. Please enable the sensor debug options and contact support for further help error.
SolutionThis 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.

Errors before version 18.4.47

ProblemThe sensor shows an Couldn't deserialize output from remote error.
SolutionThis error occurs when PRTG cannot deserialize the output to an object. Contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.
ProblemThe sensor shows an Couldn't deserialize output from remote. Exception from HRESULT: 0x80244022 error.
Solution0x80244022 WU_E_PT_HTTP_STATUS_SERVICE_UNAVAIL (same as HTTP status 503) - the service is temporarily overloaded (see https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list). This issue may resolve itself. The error should not only occur in PRTG, but you should be able to reproduce it on the target machine.
See also the article https://www.kjctech.net/fixing-windows-updates-failed-with-error-0x80244022/
ProblemThe sensor shows an Unable to cast object of type 'System.Management.Automation.PSCustomObject' to type 'System.Collections.ArrayList' error.
SolutionYou are running PRTG version 18.1.37 or earlier. Update your system to the latest stable PRTG version and you will receive a more meaningful error message.
ProblemThe sensor shows an The target machine HOST did not report any updates error.
SolutionPRTG searched for updates on your target machine HOST and Windows did not report any found updates. As this is unusual, the sensor changes to a Down status. A sensor in an Up status would indicate that everything is normal, which might not be the case.

Note: We changed this behavior with PRTG version 18.4.47. Update to version 18.4.47 or later.
ProblemThe following error with error code 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred.
SolutionThis might be related to the SPN configuration of the target host. See https://kb.paessler.com/en/topic/71899-facing-issues-with-the-windows-update-status-sensor-can-you-help-me#reply-297318 for details.


Regards,
Stephan Linke, Paessler Technical Support


More

Created on Aug 31, 2017 1:03:54 PM by  Martina Wittmann [Paessler Support]

Last change on Nov 29, 2019 11:50:33 AM by  Maike Behnsen [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Support -

I have two probes, one local & one remote, running Windows 2008 R2 and each has the Windows Update Status Sensor installed. Both were working fine with v17.1.28.1032. Yesterday I installed v17.3.33.2753 and when the Servers rebooted each Sensor reported a PE018 Timeout error. I deleted both Sensors and re-added them and still have the same PE018 error. I ran the Measure-Command above on the local probe and it reports 28 seconds.

Is there something I need to change because of the upgrade to v17.3.33.2753?

Created on Sep 7, 2017 1:24:47 AM by  MCQ (0)



Votes:

0

Your Vote:

Up

Down

Hello MCQ,

There are currently a few issues with the Windows Update Status sensor in this version, a hotfix release should be coming out soon after internal testing has been finished.

Kind regards,

Erhard

Created on Sep 7, 2017 8:34:28 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

We get a 'No result returned from remote host' with 'Windows Updates Status' on a server which previously could be monitored just fine. We rebooted the server, error remains. All other sensors work just fine.

What could be the cause of this?

Created on Apr 23, 2018 7:41:32 AM by  Bastiaan (181) 1



Votes:

0

Your Vote:

Up

Down

bvanhaastrecht, to allow us a better overview of what is going with this Windows Update Sensor on, please send us the following screenshots of the affected sensor (out of the PRTG AJAX Webinterface):
- the "Overview" tab,
- the "Log" tab,
- the "Settings" tab (multiple screenshots if necessary to cover all options).

Please make sure the screenshots show the entire user interface, and aren't cropped.

To debug this, we would like to look into the sensor debug log for the sensor. To activate this debug log, please enable the "Write Result to Disk" Option in the settings of the sensor. And then forward us the logfile. You will find it in the "Logs (Sensors)"-Subfolder of the data directory of the according PRTG Probe running this sensor.

Please send everything with an email to [email protected] with a reference to this KB-Post.

Created on Apr 23, 2018 12:54:36 PM by  Torsten Lindner [Paessler Support]

Last change on Apr 23, 2018 12:55:03 PM by  Torsten Lindner [Paessler Support]



Votes:

1

Your Vote:

Up

Down

I have missed this reply. Thank you, and i've send support the requested information. PAEXXXX597

Created on May 2, 2018 12:00:41 PM by  Bastiaan (181) 1

Last change on May 3, 2018 10:43:14 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I have a bunch of Server 2016 machines, which I point to a WSUS server not hosting updates for the OS to cirumvent nasty unwanted reboots, which happened in the past on those systems. These are updated manually each month via online updates, so they should not cause PRTG to raise the error flag, which they seem to do according to the last item in the list. Is there a way around this?

Best greetings from Germany Olaf

Created on Jun 13, 2018 9:12:13 PM by  OlafE (0)



Votes:

0

Your Vote:

Up

Down

Olaf, may I ask, which exact error do those particular sensors then show? Can you share a screenshot showing it please?

Created on Jun 14, 2018 8:24:14 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I do not think, that I can share a screenshot displaying a customers machine status hosted on a 3rd party website. But the text shown is not that hard to type: Sensor: Windows Update Status Probe device: XXX Status: Error Message: The target machine YYY did not report any updates.

Best greetings from Germany Olaf

Created on Jun 27, 2018 11:59:11 AM by  OlafE (0)



Votes:

0

Your Vote:

Up

Down

It looks though, as if this isn't really a sensor error to be honest, but the target simply reporting no updates. To confirm this, we would like to look into the sensor debug log for the sensor. To activate this debug log, please enable the "Write Result to Disk" Option in the settings of the sensor. And then forward us the logfile. You will find it in the "Logs (Sensors)"-Subfolder of the data directory of the according PRTG Probe running this sensor (https://kb.paessler.com/en/topic/463-how-and-where-does-prtg-store-its-data). You can send us the debug log via email in responds to this KB-Thread.

Created on Jun 27, 2018 2:11:32 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Sorry, kept busy enough to see this answer just now. Thanks for the reply. Since this is a customer system, I cannot send the logs currently.

I go with you, that this is not necessarly a sensor error: The answer to "The sensor errors with The target machine HOST did not report any updates.?" explains, that this is intended.

But why make this the reason for error status? There was this other depreciated sensor https://blog.paessler.com/prtg-windows-last-update-sensor This in combination with the newer one could help to determine, if the system is in a critical stage update wise or not. (If the last updates have been installed within the last xx days PRTG could assume the system is not a forgotten one.

It might also help not to rely solely on WSUS since there is no warranty, that all required updates are approved on the WSUS server.

Created on Jul 10, 2018 10:19:06 AM by  OlafE (0)



Votes:

0

Your Vote:

Up

Down

I do understand the point. Nevertheless, with the reality that hardly any up-to-date windows machines have no updates installed, we see it reasonably to have this as an error.

Created on Jul 10, 2018 1:24:01 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

The link for the PwrShell 2.0 sensor is broken. http://download3.paessler.com/support/LastWindowsUpdateSensor_17.4.35.zip

Created on Aug 3, 2018 9:55:56 AM by  Ringo77 (0) 1



Votes:

0

Your Vote:

Up

Down

Hi Ringo,

Thanks for the hint, it's fixed now and should be available in a few minutes :)


Kind regards,
Stephan Linke, Tech Support Team

Created on Aug 3, 2018 12:56:27 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

i have a few Windows2016 Server which wont report any Updates: "The target machine XXX did not report any updates."

If i get on Powershell and run: $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates $searcher | Select-Object -Property * I get:

CanAutomaticallyUpgradeService      : False
ClientApplicationID                 : 
IncludePotentiallySupersededUpdates : False
ServerSelection                     : 0
Online                              : True
ServiceID                           : 00000000-0000-0000-0000-000000000000
IgnoreDownloadPriority              : False
SearchScope                         : 0

On older Servers like 2012 i get all the information and the Sensor is up.

It looks like that Servers who directly connect to a WSUS Server are working. But we have also Microsoft SystemCenter with a second WSUS in use, all new Servers are controlled by the SystemCenter. Those arent working.

Any ideas?

Kind regards, Sebastian

Created on Sep 18, 2018 9:09:25 AM by  SebastianSchmitt (0)



Votes:

0

Your Vote:

Up

Down

Hi Sebastian,

In this case, we can't properly discern if there are indeed no updates or if we didn't get any information from the host. In this case, please acknowledge the error for the time being. It will go green again once new updates are installed.


Kind regards,
Stephan Linke, Tech Support Team

Created on Sep 18, 2018 9:22:20 AM by  Stephan Linke [Paessler Support]

Last change on Sep 18, 2018 9:22:25 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Created on Mar 25, 2019 10:51:52 AM by  EDS (0)



Votes:

0

Your Vote:

Up

Down

What exact issues are you encountering with the Sensor?


More

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 25, 2019 3:11:29 PM by  Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:18:07 AM by  Maike Behnsen [Paessler Support]



Votes:

0

Your Vote:

Up

Down

i get this error on one of my servers, i did powerschell remote session from the probe device to the target server (that one with this error) and ran the windows update sensor script perfect in 4-5 min (Connecting to remote server ** failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.)

Created on Mar 25, 2019 3:37:42 PM by  EDS (0)



Votes:

0

Your Vote:

Up

Down

This is most likely something with WinRM being unable to connect. The old version won't do the trick here either. Is this a host within the same domain? FQDN used for the device address?


More

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 26, 2019 1:52:49 PM by  Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:52 AM by  Maike Behnsen [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I receive no error, but this sensor only report "Elapsed time since the last windows update" (translated) for each Windows Server 2016 machine. There is no WSUS roles on any of those servers. A windows 10 virtual machine report this channel and several others for different type of updates.

WinRM works for each of them as I use "Windows Admin Center" from my personal PC and access Windows Update functions with success on each of them and this function of WAC uses powershell and WinRM. Framework 4.8 (who includes 4.7) as been installed on the probe server. The goal is to have all the channels for each Windows Server machine.

WAC provides the powershell scripts they use. Here is what they use concerning Windows Updates : https://medium.com/@RealNetwork/the-windows-admin-center-1809-powershell-scripts-f2923c70fb8f

Created on May 2, 2019 10:18:03 AM by  sbeaudoin (0) 1

Last change on May 2, 2019 10:31:49 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I took the freedom to remove the actual script for the sake of readability, thanks for sharing that one! Much appreciated. The issue is known to us and we're working on a fix; however, it will likely take some time as the way we transport results between target host and PRTG is what's causing the issue (the base64 object is getting too large).

I hope that this will be fixed eventually in a future PRTG version :)


More

Kind regards,
Stephan Linke, Tech Support Team

Created on May 2, 2019 10:34:39 AM by  Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:44 AM by  Maike Behnsen [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Regarding the error: "WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred"... I just ran into that myself.

In my case, the issue stemmed from the server/device being queried already having a SPN created for HTTP/myserver.mydomain.com, which an application on the machine was using. That SPN was tied to a specific service account which causes WinRM to not work when invoked over Kerberos since from a Kerberos perspective the WinRM service runs under the domain machine account. Google for "winrm kerberos existing SPN" and you'll see a variety of hits on this topic.

Ultimately it would be nice if the PRTG Windows Update Sensor app (LastWindowsUpdateSensor.exe) was able to/had an option to query for the SPN and include the port number. That's an option when invoking WinRM over PowerShell directly (-EncodePortInServicePrincipalName) that would cause it to query for HTTP/myserver.mydomain.com:<win rm port> which would not conflict with any existing SPNs.

I did find a possible workaround. On the PRTG sensor server, I was able to add a string registry value under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Client\spn_prefix = "WSMAN". That seems to force PRTG to use the SPN WSMAN/myserver.mydomain.com instead of HTTP/myserver.mydomain.com. I could not find any documentation on the spn_prefix value. I saw that while watching the PRTG Windows Update sensor execute with MS Process Monitor.

Ultimately whatever SPN is being requested from the PRTG sensor (you can watch network traffic with Wireshark on the PRTG sensor server and see the SPN service name) must tie back to the domain machine account in order for Kerberos credentials to transmit correctly.

Created on May 3, 2019 12:05:31 AM by  coh_jeff (10)



Votes:

0

Your Vote:

Up

Down

Thanks! I've updated our solution guide with a link to your post :)


More

Kind regards,
Stephan Linke, Tech Support Team

Created on May 3, 2019 7:45:46 AM by  Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:31 AM by  Maike Behnsen [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi, the link for 2.0 version isnt working, could you update it?

http://download3.paessler.com/support/LastWindowsUpdateSensor_17.4.35.zip

Created on May 21, 2019 10:42:01 AM by  D_JColeman (0)



Votes:

0

Your Vote:

Up

Down

What exact issue are you running into and what version of PRTG are you running?

Created on May 21, 2019 12:49:34 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hey, following problem: Probe is AD-Joined and the server we want to monitor windows updates is standalone Workgroup. I´ve already set the FQDN as trused host and getting the list back: Get-Item WSMan:\localhost\Client\TrustedHosts

Since i´ve done this, PS-Remoting is working fine from probe to standalone server. But if i use following command to test the sensor or script: S C:\Program Files (x86)\PRTG Network Monitor\Sensor System> .\LastWindowsUpdateSensor.exe -host='HOSTNAME' -user='HOSTNAME\Administrator' -pass='localadminpassword'

i´ll get following Error Message back: <prtg> <error>1</error> <text>Connecting to remote server SRBBACK01.bgz.glasmarte.at failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.</text>

I´ve already done the PSRemoting, PS Execution Policy and either Windows Firewall but nothing helped. Thanks for the help!

Created on Aug 28, 2019 8:45:20 AM by  Dominic Dreier (0) 1

Last change on Aug 29, 2019 2:24:17 PM by  Dominic Dreier (0) 1



Votes:

0

Your Vote:

Up

Down

Please check out this one to see if any of the proposed approaches under Conclusion helps.

Created on Aug 28, 2019 12:42:37 PM by  Stephan Linke [Paessler Support]



Please log in or register to enter your reply.


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.