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 Sensor - can you help me?

Votes:

6

Your Vote:

Up

Down

I use the Windows Update Status sensor to be up to date on available and installed Windows updates on my machines. However, the sensor recently throws errors whereas 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 Aug 31, 2017 12:12:49 PM by  Martina Wittmann [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. Please see section 6 for more information.


This article applies to PRTG Network Monitor 17.3.33 and later

A New Era of the Windows Update Status Sensor

The Windows operating system changed quite a bit and as a consequence the Windows Update Status 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 sensor is more "sensitive". This article will explain what the sensor actually does, how it works and why it doesn't 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 don't exist anymore on recent and future Windows versions.

3. How The Windows Update Status Sensor Works

3.1 Environment

The sensor works in both environments:

  1. networks sporting their own WSUS server, and,
  2. those who simply use the normal update route.

3.2 Processes

Here are the (simplified) steps the sensor takes:

1. Use Windows credentials to open up 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 killed. This is hard-coded and cannot be changed. You can discern if this is what happens to the Windows Update Status sensor on your system by bench marking 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\. (More about how and where PRTG stores 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. Don't forget to configure the Limits for each channel accordingly.
    Otherwise, the sensor will always stay green (Okay status).
  8. Then save it.

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, please try to replace the single quotes (') in the parameter field with double quotes (").

5. First Aid

ProblemThe sensor fails with a timeout error and PE018
SolutionThere are two possible reasons for that - either the sensor simply couldn't connect to the target host or the PowerShell command probably takes too long to execute. Please try to run the commands manually as shown above via a remote PowerShell session and see how long they take. If the command executes within the given timespan of 20 minutes, please 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's also possible that the Windows Desktop Experience was installed on the server. If so, please remove it because it will cause the update search to fail inevitably.
ProblemThe sensor errors with a Kerberos authentication problem and something about missing login servers.
SolutionIs the server you're checking located in a workgroup? If yes, that's the problem. There's currently nothing you can do about it, the sensor currently doesn't work with workgroups; we're looking into this, but can't promise anything. The sensor relies on Kerberos authentication, which is only available within a domain.
ProblemThe sensor errors with Exception from HRESULT: 0x80072EFD
SolutionThe error is rather ambiguous and can have multiple causes. Either it's a problem with the internet connection of the target host or it cannot connect to the WSUS server. Please try to install updates manually to see if that solves the issue.
ProblemThe sensor errors with Exception from HRESULT: 0x8024402F
Solution1. Remove contents of C:\ProgramData\Microsoft\Windows\Caches.
2. Rename Caches to Cache.
3. Start Windows Update; the error will come up again.
4. Rename Cache back to Caches and start Windows Update again.

The sensor should work properly then. Also, please install any available updates on the target host manually to rebuild the update database.
ProblemThe command basically works, but takes rather long. Any suggestion to improve performance?
SolutionAccording to one of our customers, it helps to clean out old updates in the WSUS. This should increase the search speed as less updates are indexed for it.
ProblemThe sensor errors with Powershell version not supported. Current Powershell major version: 2. Please install Powershell 3.0 or later.
SolutionPlease install PowerShell 3.0 or Windows Management Framework 3.0 or later on the target machine you want to monitor.
ProblemThe sensor errors with This sensor requires the PowerShell 2.0 (or higher) to be 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)?
SolutionThis error message is sadly wrong and will be adjusted in the upcoming stable release. Please install PowerShell 3.0 or Windows Management Framework 3.0 or later on the probe system.

The following issues only occur on target machines running Windows 10 or Windows Server 2016 or later

ProblemThe sensor errors with Couldn't deserialize output from remote.?
SolutionThis error occurs when PRTG cannot deserialize the output to an object. Please contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.
ProblemThe sensor errors with Couldn't deserialize output from remote. Exception from HRESULT: 0x80244022?
Solution0x80244022 WU_E_PT_HTTP_STATUS_SERVICE_UNAVAIL (same as HTTP status 503) - the service is temporarily overloaded (https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list). This may resolve itself. This error should not only occur in PRTG, but should be reproducible on the target machine.
See also: https://www.kjctech.net/fixing-windows-updates-failed-with-error-0x80244022/
ProblemThe sensor errors with Unable to cast object of type 'System.Management.Automation.PSCustomObject' to type 'System.Collections.ArrayList'.?
SolutionYou are running the PRTG version 18.1.37 or earlier. Please update your system to the latest stable PRTG version and you will receive a more meaningful error message.
ProblemThe sensor errors with The target machine HOST did not report any updates.?
SolutionWe 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 Up status would indicate that everything is normal, which might not be the case.
ProblemThe following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred
SolutionThis might be related to the SPN configuration of the target host. Please see https://kb.paessler.com/en/topic/71899-facing-issues-with-the-windows-update-status-sensor-can-you-help-me#reply-297318 for details.

6. I cannot install PowerShell 3.0 on my target machines. Can you help me with that?

The following workaround is only a temporary solution. We highly recommend that you update to PowerShell 3.0 as soon as possible.

If you need some time to upgrade your systems, we can offer you a temporary workaround. You can download the sensor for version 17.4.35 here. This sensor doesn't force the PowerShell 3.0 requirement yet.

Note: Please keep in mind that updating to newer PRTG versions will overwrite the EXE. The use of this sensor is also not covered by our support.


Regards,
Stephan Linke, Paessler Technical Support


More

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

Last change on May 3, 2019 7:45:25 AM by  Stephan Linke [Paessler Support]



28 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. Please see section 6 for more information.


This article applies to PRTG Network Monitor 17.3.33 and later

A New Era of the Windows Update Status Sensor

The Windows operating system changed quite a bit and as a consequence the Windows Update Status 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 sensor is more "sensitive". This article will explain what the sensor actually does, how it works and why it doesn't 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 don't exist anymore on recent and future Windows versions.

3. How The Windows Update Status Sensor Works

3.1 Environment

The sensor works in both environments:

  1. networks sporting their own WSUS server, and,
  2. those who simply use the normal update route.

3.2 Processes

Here are the (simplified) steps the sensor takes:

1. Use Windows credentials to open up 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 killed. This is hard-coded and cannot be changed. You can discern if this is what happens to the Windows Update Status sensor on your system by bench marking 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\. (More about how and where PRTG stores 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. Don't forget to configure the Limits for each channel accordingly.
    Otherwise, the sensor will always stay green (Okay status).
  8. Then save it.

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, please try to replace the single quotes (') in the parameter field with double quotes (").

5. First Aid

ProblemThe sensor fails with a timeout error and PE018
SolutionThere are two possible reasons for that - either the sensor simply couldn't connect to the target host or the PowerShell command probably takes too long to execute. Please try to run the commands manually as shown above via a remote PowerShell session and see how long they take. If the command executes within the given timespan of 20 minutes, please 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's also possible that the Windows Desktop Experience was installed on the server. If so, please remove it because it will cause the update search to fail inevitably.
ProblemThe sensor errors with a Kerberos authentication problem and something about missing login servers.
SolutionIs the server you're checking located in a workgroup? If yes, that's the problem. There's currently nothing you can do about it, the sensor currently doesn't work with workgroups; we're looking into this, but can't promise anything. The sensor relies on Kerberos authentication, which is only available within a domain.
ProblemThe sensor errors with Exception from HRESULT: 0x80072EFD
SolutionThe error is rather ambiguous and can have multiple causes. Either it's a problem with the internet connection of the target host or it cannot connect to the WSUS server. Please try to install updates manually to see if that solves the issue.
ProblemThe sensor errors with Exception from HRESULT: 0x8024402F
Solution1. Remove contents of C:\ProgramData\Microsoft\Windows\Caches.
2. Rename Caches to Cache.
3. Start Windows Update; the error will come up again.
4. Rename Cache back to Caches and start Windows Update again.

The sensor should work properly then. Also, please install any available updates on the target host manually to rebuild the update database.
ProblemThe command basically works, but takes rather long. Any suggestion to improve performance?
SolutionAccording to one of our customers, it helps to clean out old updates in the WSUS. This should increase the search speed as less updates are indexed for it.
ProblemThe sensor errors with Powershell version not supported. Current Powershell major version: 2. Please install Powershell 3.0 or later.
SolutionPlease install PowerShell 3.0 or Windows Management Framework 3.0 or later on the target machine you want to monitor.
ProblemThe sensor errors with This sensor requires the PowerShell 2.0 (or higher) to be 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)?
SolutionThis error message is sadly wrong and will be adjusted in the upcoming stable release. Please install PowerShell 3.0 or Windows Management Framework 3.0 or later on the probe system.

The following issues only occur on target machines running Windows 10 or Windows Server 2016 or later

ProblemThe sensor errors with Couldn't deserialize output from remote.?
SolutionThis error occurs when PRTG cannot deserialize the output to an object. Please contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.
ProblemThe sensor errors with Couldn't deserialize output from remote. Exception from HRESULT: 0x80244022?
Solution0x80244022 WU_E_PT_HTTP_STATUS_SERVICE_UNAVAIL (same as HTTP status 503) - the service is temporarily overloaded (https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list). This may resolve itself. This error should not only occur in PRTG, but should be reproducible on the target machine.
See also: https://www.kjctech.net/fixing-windows-updates-failed-with-error-0x80244022/
ProblemThe sensor errors with Unable to cast object of type 'System.Management.Automation.PSCustomObject' to type 'System.Collections.ArrayList'.?
SolutionYou are running the PRTG version 18.1.37 or earlier. Please update your system to the latest stable PRTG version and you will receive a more meaningful error message.
ProblemThe sensor errors with The target machine HOST did not report any updates.?
SolutionWe 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 Up status would indicate that everything is normal, which might not be the case.
ProblemThe following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred
SolutionThis might be related to the SPN configuration of the target host. Please see https://kb.paessler.com/en/topic/71899-facing-issues-with-the-windows-update-status-sensor-can-you-help-me#reply-297318 for details.

6. I cannot install PowerShell 3.0 on my target machines. Can you help me with that?

The following workaround is only a temporary solution. We highly recommend that you update to PowerShell 3.0 as soon as possible.

If you need some time to upgrade your systems, we can offer you a temporary workaround. You can download the sensor for version 17.4.35 here. This sensor doesn't force the PowerShell 3.0 requirement yet.

Note: Please keep in mind that updating to newer PRTG versions will overwrite the EXE. The use of this sensor is also not covered by our support.


Regards,
Stephan Linke, Paessler Technical Support


More

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

Last change on May 3, 2019 7:45:25 AM by  Stephan Linke [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 (31) 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 support@paessler.com 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 (31) 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?


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 25, 2019 3:11:29 PM by  Stephan Linke [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?


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 26, 2019 1:52:49 PM by  Stephan Linke [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 :)


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on May 2, 2019 10:34:39 AM by  Stephan Linke [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 :)


PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on May 3, 2019 7:45:46 AM by  Stephan Linke [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]



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.