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


Windows Update Sensor

Votes:

0

Your Vote:

Up

Down

I have a problem with the Windows Update sensor. On the system the remote registry is enabled and running. Windows update is set automatic but I get an error: Protocol error (code: PE023)

What can be the problem? .Net Framework is installed on the server.

prtg reghack windows-2008-r2-sp1 windows-update

Created on Sep 12, 2012 12:43:11 PM by  lesleyvandriessen (0) 1

Last change on Feb 21, 2013 9:14:08 AM by  Daniel Zobel [Paessler Support]



Best Answer

Accepted Answer

Votes:

1

Your Vote:

Up

Down

Important note: The Windows Last Update (Remote Registry) sensor is deprecated as of PRTG version 16.1.23.

Please see the following article for more details and possible alternatives:


This article applies to PRTG Network Monitor 12 through 15

Fixing a Protocol Error Appearing With Windows Last Update Sensor

Sometimes PRTG cannot query updates anymore after a Windows update and a corresponding restart of the server. The Windows Last Update sensor returns the following error message in this case:

Protocol error: Could not determine the last time Windows Update has updated computer XYZ (Code: PE023)

The Windows Update service sometimes does not create the queried registry key automatically, so you might have to create the specific key manually.

Caution: Please back up your system before manipulating the Windows registry!

Steps to Go

  1. Open the registry editor and check if the following key exists: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install
  2. If this key does not exist, create it manually: on the last existing path node from the path above, do right-click > New > Key. Respectively, enter the successive key as indicated above. Do this until the key Install is created.
  3. For the Install key, add the parameter LastSuccessTime from the type REG_SZ: right-click on Install > New >String Value. Enter LastSuccessTime.
  4. Restart the Windows Update service.

Now the Windows Last Update sensor’s queries are successful again.

Created on Jan 24, 2013 10:46:24 AM by  Gerald Schoch [Paessler Support]

Last change on Mar 21, 2016 4:53:47 PM by  Gerald Schoch [Paessler Support]



29 Replies

Votes:

0

Your Vote:

Up

Down

Hi, please try running the sensor manually in the command line. The executable can be found here:

<PRTG Install Directory>\Sensor System\LastWinUpdate.exe

The executable has to run with the following parameters

\LastWinUpdate.exe -c=TARGET_IP -u=USERNAME -p=PASSWORD

where the uppercase parts have to be replaced to fit your environment. What is the result on the commandline?

Created on Sep 14, 2012 9:37:11 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Impersonation of \administrator failed! [1326] Logon failure. unknown user name or bad password.

It's an domain account so don't know the parameter for the domain? Is this also an WMI sensor? Because all other WMI sensors are working on the system.

Created on Sep 14, 2012 10:10:23 AM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

Hi,
no, this sensor is not based on WMI. Please try using it with a local Administrator Account of the target machine. Does it work then?

Created on Sep 14, 2012 10:37:52 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

With local administrator I get the same message

Created on Sep 14, 2012 11:09:36 AM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

Hi,
please try using

DOMAINNAME\USERNAME

when using a Domain Admin Account,

Created on Sep 14, 2012 11:26:58 AM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

It's also saying that I have a bad username and password. If I try it on an other domain and server it's working.

I only know for sure that my domain and username and password from the first server are correct. Can't find out why it's not working.

Created on Sep 14, 2012 1:45:42 PM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

Hi,
please download and run this tool (Sorry, the website is in German) on the target machine. Then retry adding the sensor in PRTG.
Best regards

Created on Sep 14, 2012 2:14:48 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi,

Thanks but it's not working. If I look in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install\LastSuccessTime) on the remote target machine I can see the last windows update date "2012-09-13 01:13:54"

So I thought to read out the registry on the remote machine but I see the same message that I can't connect with "Access Denied, Check your windows credentials. (code: PE095)

If I try to connect from the PRTG Core server with regedit to the remote target computer I can connect to it with specified credentials.

Created on Sep 17, 2012 7:49:03 AM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

Hi,

I have a similar problem with the monitor on some machines, however, I get a reply of "1:9/16/2012 2.04.50 AM" when I run the query. What could the problem be?

Would you prefer me to open a new question instead?

Created on Sep 17, 2012 3:56:05 PM by  lundholmster (0)



Votes:

0

Your Vote:

Up

Down

Hi,
@all: we are testing the sensor again at the moment but this might take a bit.
@lundholmster: The response you are getting looks pretty ok to me.

Created on Sep 18, 2012 1:31:00 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

@konstantin: Thanks, Im also looking on my servers if there is an difference between te configuration.

I have 10 servers in an domain which can't readout the last windows update date. And in an other domain it's working great. If I find out how to fix I will also post this.

Created on Sep 18, 2012 1:42:34 PM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

I still get those messages on a lot of servers. There's no difference in configuration. We have Windows 2003 and 2008 servers. Local administrator account or domain account both doesn't work with this sensor.

Do you guys know how to fix this already? I'm running PRTG Network Monitor 12.4.5.3165+

Created on Nov 12, 2012 1:44:10 PM by  lesleyvandriessen (0) 1



Votes:

0

Your Vote:

Up

Down

Are these machines in different domains? I'm afraid the sensor will only properly work within one domain. Or directly on the machine if it's a work-group machine.

Created on Nov 12, 2012 5:24:03 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I have the same problem with the windows update sensor. I'm trying on W2003 and W2008 servers, the prtg version is 12.4.6.3230, and this is the sensor message: "protocol Error: impersonation of ... failed! [1326] Logon failure. unknown user name or bad password. (code: PE023)"

Any solution for this problem?

Created on Dec 11, 2012 10:20:14 AM by  Rafael Palou (0)



Votes:

0

Your Vote:

Up

Down

Is this across different domains?

Created on Dec 11, 2012 2:13:51 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

all in the same domain

Created on Dec 11, 2012 4:12:40 PM by  Rafael Palou (0)



Votes:

0

Your Vote:

Up

Down

So what happens then if you run the sensor as exe-file from CMD as outlined in the first response here?

Created on Dec 11, 2012 4:16:46 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi there. I have the same problem. On some of servers I could solve the problem using the probe server name instead of domain name: LastWinUpdate.exe -c=destserver -u=probeserver\prtguser -p=password. I hope it will help someone.

Created on Jan 4, 2013 2:18:39 PM by  Seth van der Maas (0)



Accepted Answer

Votes:

1

Your Vote:

Up

Down

Important note: The Windows Last Update (Remote Registry) sensor is deprecated as of PRTG version 16.1.23.

Please see the following article for more details and possible alternatives:


This article applies to PRTG Network Monitor 12 through 15

Fixing a Protocol Error Appearing With Windows Last Update Sensor

Sometimes PRTG cannot query updates anymore after a Windows update and a corresponding restart of the server. The Windows Last Update sensor returns the following error message in this case:

Protocol error: Could not determine the last time Windows Update has updated computer XYZ (Code: PE023)

The Windows Update service sometimes does not create the queried registry key automatically, so you might have to create the specific key manually.

Caution: Please back up your system before manipulating the Windows registry!

Steps to Go

  1. Open the registry editor and check if the following key exists: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install
  2. If this key does not exist, create it manually: on the last existing path node from the path above, do right-click > New > Key. Respectively, enter the successive key as indicated above. Do this until the key Install is created.
  3. For the Install key, add the parameter LastSuccessTime from the type REG_SZ: right-click on Install > New >String Value. Enter LastSuccessTime.
  4. Restart the Windows Update service.

Now the Windows Last Update sensor’s queries are successful again.

Created on Jan 24, 2013 10:46:24 AM by  Gerald Schoch [Paessler Support]

Last change on Mar 21, 2016 4:53:47 PM by  Gerald Schoch [Paessler Support]



Votes:

0

Your Vote:

Up

Down

After having done this steps on Hyper-V Server R2 the protocol error message changes to "Conversion from string "" to type 'Date' is not valid. (Code: PE023)".

Created on Mar 20, 2013 9:13:00 AM by  Steffen Reinhardt (0) 1



Votes:

0

Your Vote:

Up

Down

What is the value of the LastSuccessTime-REG_SZ entry then in the registry of the target?

Created on Mar 20, 2013 3:22:13 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

The value remains empty even after restarting the windows update service (net stop wuauserv && net stop wuauserv). The behavior is repeatable on all Hyper-V Servers here.

Created on Mar 20, 2013 3:36:10 PM by  Steffen Reinhardt (0) 1



Votes:

0

Your Vote:

Up

Down

Then PRTG can't read a date from an "empty" string I'm afraid. Please consult with Microsoft why this string is empty.

Created on Mar 20, 2013 5:21:22 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I opened a case with Microsoft and they said there is nothing to fix. Hyper-V-Server (and apparently all core servers) does not maintain the described keys. Microsoft told me to validate that PRTG respectively the Windows Update Sensor supports Hyper-V-Server and/or core servers. They said Paessler should be able to contact Microsoft if they should think the handling of the keys was not correct.

Created on May 15, 2013 10:13:09 AM by  Steffen Reinhardt (0) 1



Votes:

0

Your Vote:

Up

Down

This key does exist on all our testing devices, both Hyper-V and hardware systems. The answer you have gotten from Microsoft is obviously wrong. We're sorry, but we can't be of any more help here.

Created on May 15, 2013 1:13:55 PM by  Johannes Herrmann [Paessler Support] (1,320) 2 2



Votes:

0

Your Vote:

Up

Down

Maybe I did not specify enough, I refer to the Mirosoft Hyper-V Server 2008 R8 (which is always on hardware) and not to Microsoft Server 2008 R2 with Hyper-V role.

I checked all our installation (Mirosoft Hyper-V Server 2008 R8) and no one maintains this key...

Created on Jun 7, 2013 6:32:43 AM by  Steffen Reinhardt (0) 1



Votes:

0

Your Vote:

Up

Down

It's a little embarrassing but we have to admit, we didn't even know that there was something like a Hyper-V core server. I'm very sorry for the bad information, I gave you. As far as we know, it is not possible to monitor the last update time for windows any other way then via this registry key.

Created on Jun 7, 2013 10:29:43 AM by  Johannes Herrmann [Paessler Support] (1,320) 2 2



Votes:

0

Your Vote:

Up

Down

If you have enabled RemotePowershell on your Server you can retrieve the Information via PowerShell, too. Create a new .ps1-file as Custom-Exe Sensor at '<PRTG-Folder>\Custom Sensors\EXE' with the following Content:

param([Parameter(Mandatory=$true)][string] $Computer,
      [Parameter(Mandatory=$true)][string] $User,
      [Parameter(Mandatory=$true)][string] $Password,
      [switch] $PSRemoting
     )

#############################
# this 'sensor' is a proof of concept to retrieve information about the last windows-update via PowerShell
# it is based on the work of http://www.powershelladmin.com/wiki/Check_when_servers_were_last_patched_with_Windows_Update_via_COM_or_WSUS
# the only adoption is to 
# - authenticate to the remote-machine with given credentials (to be able to run from within PRTG as it is started in the scope of the service-user)
# - scan only one server instead of a list of servers
# - return no html but a PRTG-readable result to be used as a 'custom exe'-sensor
#
# Parameters are '-computer <ip or fqdn> -user <username as domain\username> -password <the SECRET password> -PSRemoting'
# In PRTG set '-computer %host -user %windowsdomain\%windowsuser -password %windowspassword -PSRemoting' to use the settings from the device without making the password public
#
# Result is '<days since last update> : <last update datetime> -> <name of the update last installed>'
#############################

# create a credential-object for authenticating with the given credentials
$secpasswd = ConvertTo-SecureString $password -AsPlainText -Force
$myCred    = New-Object System.Management.Automation.PSCredential ($user, $secpasswd)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

function ql { $args }

$LastUpdates = @{}
$Errors      = @{}

$script:ContinueFlag = $false
    
if ( -not (Test-Connection -Quiet -Count 1 -ComputerName $Computer) ) {
        
    $Errors.$Computer = 'Error: No ping reply'
}
    
# Use "local COM" (well, local, but remote via PS) and Invoke-Command if PSRemoting is specified.
if ($PSRemoting) {
        
    try {
        $PSSession = New-PSSession -ComputerName $Computer -Authentication Kerberos -Credential $myCred
        $Result = Invoke-Command -Session $PSSession -ScriptBlock {
            [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.Update.Session') | Out-Null
            $Session = New-Object -ComObject Microsoft.Update.Session
                
            try {
                $UpdateSearcher   = $Session.CreateUpdateSearcher()
                $NumUpdates       = $UpdateSearcher.GetTotalHistoryCount()
                $InstalledUpdates = $UpdateSearcher.QueryHistory(1, $NumUpdates)
                    
                if ($?) {
                        
                    $LastInstalledUpdate = $InstalledUpdates | Select-Object Title, Date | Sort-Object -Property Date -Descending | Select-Object -first 1
                    # Return a collection/array. Later it is assumed that an array type indicates success.
                    # Errors are of the class [System.String]. -- Well, that didn't work so well in retrospect.
                    $LastInstalledUpdate.Title, $LastInstalledUpdate.Date
                }
                else {
                    "Error. Win update search query failed: $($Error[0] -replace '[\r\n]+')"
                }
            } # end of inner try block
            catch {
                $Errors.$Computer = "Error (terminating): $($Error[0] -replace '[\r\n]+')"
                continue
            }
        } # end of Invoke-Command
    } # end of outer try block
        
    # Catch the Invoke-Command errors here
    catch {
        $Errors.$Computer = "Error with Invoke-Command: $($Error[0] -replace '[\r\n]+')"
    }
        
    # $Result here is what's returned from the invoke-command call.
    # I can't populate the data hashes inside the Invoke-Command due to variable scoping.
    if (-not $Result -is [array]) {
        $Errors.$Computer = $Result
    }
    else {
        $Title, $Date = $Result[0,1]
        $LastUpdates.$Computer = New-Object PSObject -Property @{
            'Title' = $Title
            'Date'  = $Date
        }
    }
}
    
# If -PSRemoting isn't provided as an argument, try remote COM.
else {
    try {
        [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.Update.Session')
        $Session = [activator]::CreateInstance([type]::GetTypeFromProgID("Microsoft.Update.Session", $Computer))
        
        $UpdateSearcher   = $Session.CreateUpdateSearcher()
        $NumUpdates       = $UpdateSearcher.GetTotalHistoryCount()
        $InstalledUpdates = $UpdateSearcher.QueryHistory(1, $NumUpdates)
            
        if ($?) {
            $LastInstalledUpdate   = $InstalledUpdates | Select-Object Title, Date | Sort-Object -Property Date -Descending | Select-Object -first 1
            $LastUpdates.$Computer = New-Object PSObject -Property @{
                'Title' = $LastInstalledUpdate.Title
                'Date'  = $LastInstalledUpdate.Date
            }
        }
        else {
            $Errors.$Computer = "Error. Win update search query failed: $($Error[0].ToString())"
        }
    }
    catch {
        $Errors.$Computer = "Terminating error: $($Error[0].ToString())"
    }
}

# exit PSSession as per default there are only 5 concurrent logins per users allowed that will time out after 15 minutes...
Exit-PSSession
Remove-PSSession -session $PSsession 

if ( $Errors.Keys.count -ne 0 ) {
    # replacing ':' in the error-message to avoid 'Response not wellformed'-message in PRTG...
    write-host 0:$Errors.$Computer -replace ":", "."
    exit 1
} else {
    $resultValue = $([int]$($(get-date) - $LastUpdates.$Computer.Date).TotalDays) 
	# replacing ':' in the time-string as well as in the Title of the update to avoid 'Response not wellformed'-message in PRTG...
    $resultText = "$($LastUpdates.$Computer.Date.toString()) -> $($LastUpdates.$Computer.Title)" -replace ":", "."
    write-host $resultValue":" $resultText
    exit 0
}

See comment inside the script for using the parameter-settings in PRTG.

Kind Regards

Created on Jun 13, 2013 12:56:00 PM by  Dieter Loskarn [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello, we have had the same issue on several different OS-es (w2k3,w2k8,w2k12). All have been tried to repair by your suggested REG fix and then we have got "Conversion from string "" to type 'Date' is not valid. " or "Conversion from string " " error messages like Steffen Reinhardt said above. As it was visibly caused by "no data in registry", we have performed the real Windows patching on those servers. Now we can see the "LastSuccessTime" attribute is filled up by the current timestamp and PRTG returns real/OK value again. The root cause of this issue was that we have performed a common (safe) recall of the AU service on those machines some time ago. I mean to stop AU service then cleanup DB (DataStore) and content (Download) subfolders under the \Windows\SoftwareDistribution folder and then started AU again to get fresh re-created DB and downloaded content back. Just the "LastSuccessTime" is visibly lost by that action until the next patch action is made there.

Created on Jul 9, 2014 12:07:00 PM by  jlouzil (0)



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.