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?

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.

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?

With local administrator I get the same message

Hi,
please try using

DOMAINNAME\USERNAME

when using a Domain Admin Account,

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.

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

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.

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?

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.

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

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+

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.

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?

Is this across different domains?

all in the same domain

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

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.

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)".

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

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.

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

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.

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.

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

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.

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

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.