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


Create Windows Update Status Sensor on workgroup servers

Votes:

0

Your Vote:

Up

Down

I've tried to install the new Windows Update Status sensor on a few Terminal Servers that are not on domains, but I get this error:

Acknowledged at 11/10/2013 5:37:38 PM by PRTG System Administrator : Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Kerberos authentication cannot be used if the client computer or the destination computer are not joined to a domain. Specify a different authentication mechanism than Kerberos. For more information, see the about_Remote_Troubleshooting Help topic."

I've checked and Basic & negotiate auth are set:

C:\Windows\system32>winrm set winrm/config/client/auth @{Negotiate="True"}
Auth
    Basic = true
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

and I believe TrustedHosts is set correctly:

C:\Windows\system32>winrm set winrm/config/client @{TrustedHosts="Localhost, 127
.0.0.1, SRV-RIAS01, 10.1.1.100"}
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = Localhost, 127.0.0.1, SRV-RIAS01, 10.1.1.100

I've set the Windows Credentials, and the probe is on the same host as the target.

Any assistance would be appreciated.

Regards,

Scott

kerberos windows-update-status winrm

Created on Oct 11, 2013 7:55:18 AM by  Slaziar (0) 1

Last change on Aug 5, 2016 8:19:57 AM by  Luciano Lingnau [Paessler Support]



14 Replies

Votes:

0

Your Vote:

Up

Down

If you have set the Remote Probe software up on this host, did you create this sensor on the host directly? When we have tested this out here, if you create the sensor on the probe device, the powershell runs directly on there and the permissions shouldn't be an issue.

Created on Oct 14, 2013 1:02:12 PM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi, yes the sensor is installed on the same host as the probe (and the server too!). I have tried it on one of my customers servers (where the probe is installed) and get exactly the same problem. Is there any special configuration required on either Windows 2008 R2 SP1 (with powershell & security) or PRTG to have it work correctly? I have set set-executionpolicy unrestricted on both 32 and 64 bit powershells.

Thanks,

Scott

Created on Oct 14, 2013 11:32:56 PM by  Slaziar (0) 1



Votes:

0

Your Vote:

Up

Down

It seems that there is in fact a bug with this sensor in the newest version. We need to test and repair it and I will update this article as soon as I have more information.

Created on Oct 15, 2013 8:00:10 AM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Our developer found the bug today and the fix should be in the next stable release. Once the new release comes out, you should be able to download and install it over the current version you are running and it will take care of the issue. Let me know if you have any issues with this.

Created on Oct 17, 2013 8:44:03 PM by  Greg Campion [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Is this problem solved?It is possible to connect to workgroup server (or server in another domain without trust) trough setting Trusted host?

Created on Aug 5, 2016 5:02:22 AM by  Jiri Hadamek (0)



Votes:

0

Your Vote:

Up

Down

@Jiri: We haven't had much luck getting it to work with the Powershell-based sensor, just tried it again not long ago in our test environment to see if it can be done somehow but with no luck.

See also "No Logon Servers Available" when Using PowerShell Sensors.

Kind regards.

Created on Aug 5, 2016 11:52:11 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

this is still an issue, after 3 years since the original post. Trying to monitor windows updates on my HyperV hosts which obviously aren't joined in the domain.

Created on Apr 8, 2017 7:36:15 PM by  LunAds (10)



Votes:

0

Your Vote:

Up

Down

Hello LunAds,

The thing is that all Powershell-based sensors in PRTG rely on something called "mutual authentication", which is primarily available inside domains. We have a ticket open at development for this topic, but so far no progress I'm afraid. Depending on how many HyperV hosts you have running, you might consider installing a remote probe on them for monitoring Windows updates status and you could offload some other sensors to those remote probes too, while you're at it.

Kind regards,

Erhard

Created on Apr 10, 2017 7:10:00 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi Paessler Team, is there still no solution to monitor windows updates on trusted computers without domain? Any third party script or the like?

Thank you! Michael

Created on May 3, 2019 7:24:39 AM by  Michael Schneider (22) 2



Votes:

0

Your Vote:

Up

Down

Hello Michael,

The issue is still on development's backlog next to tons of other stuff, currently no ETA has been set for it, I'm afraid.

Kind regards,

Erhard

Created on May 6, 2019 12:33:21 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi all, does anyone else have an idea for a possible workaround? Is there any other way to monitor the days since last update on server that are not in a domain?? Thirdparty maybe?

Thank you! Michael

Created on May 8, 2019 6:04:23 AM by  Michael Schneider (22) 2



Votes:

0

Your Vote:

Up

Down

Hi Michael,

If you're interested I can provide with the executable from the old Windows Update sensor, it can be run as a custom sensor, but I cannot guarantee that it works as it used Remote Registry to get the data, which might not work anymore these days.

Let me know if you're interested, then I will send you the details by email. I can send you the instructions in German then if you like.

Kind regards,

Erhard

Created on May 8, 2019 3:08:34 PM by  Erhard Mikulik [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Hello,

I have found/created a way to monitor days since last Windows Update. Maybe not the easiest way, but it works.

I created a script that reads the date of the last installed Update via PS and subtracts the date from todays date to get the days since last update. This is written in a text file:

  • I created a user "user_prtg_local" with a complex 30 char password on the server I want to monitor. The user needs no special rights.
  • I created a folder C:WU and create a share WU$ with read permission for the "user_prtg_local"
  • I copy the following script "wudiffday.ps1" to C:\WU
#get date of last windows update
$WinUpTime = Get-WinEvent -MaxEvents 1 -FilterHashtable @{id=19;ProviderName='Microsoft-Windows-ndowsUpdateClient'}

#get current time
$TimeNow = Get-Date -format G

#calculate difference between current date and date of last windows update
$TimeDiff = NEW-TIMESPAN -Start $WinUpTime.TimeCreated -End $TimeNow

#(over-)write days (last windows updates) to C:\WU\WU.txt
set-content -path "C:\WU\WU.txt" -value $TimeDiff.Days -force -nonewline

#Insert -1 if file is equal or smaller 0KB 
$file = "C:\WU\WU.txt"
if ((Get-Item $file).length -le 0kb) 
{
Add-Content -Path $file -Value "-1"
}
  • I created a scheduled task to run the script (no credentials necessary) once a day at 00:00:01
  • "-1" means any kind of error, so the WU.txt file has not been written correctly.

At our PRTG I implemented a script that copies this text file temporary to the server (this was necessary to avoid difficulties with authentification) and reads the number.

  • I created a "EXE/Script Advanced" sensor that executes the following script "wu.ps1" with the parameter "-server %host" once every 24h.
# definition of paramters
param(
[string]$server)

# build sourcepath
$sourcepath = "\\$server\WU$"

# build sourceuser
$sourceuser = "$server\user_prtg_local"

# connect netdrive with credentials
net use $sourcepath /User:$sourceuser '9XApm$27$Yn4uA!oQ2X6zJpebo!!wS'

# build destpath
$destpath = "C:\MR_WU-Sensor\wu_$server.txt"

# copy file locally
copy "$sourcepath\WU.txt" $destpath

# delete temp netdrive
net use t: /delete

# read content of file
$data = Get-Content -Path $destpath -raw

# Formating XML for PRTG 
$XMLOutput = "<prtg>`n"
$XMLOutput += "<result>`n"
$XMLOutput += "<channel>days since last Windows Update (days)</channel>`n"
$XMLOutput += "<value>$data</value>`n"
$XMLOutput += "<unit>custom</unit>`n"
$XMLOutput += "<customunit>days</customunit>`n"
$XMLOutput += "</result>`n"
$XMLOutput += "<text>Last Windows Update was $data days ago</text>`n"
$XMLOutput += "</prtg>"
$XMLOutput

This works fine for me on a PRTG server on Windows Server 2016 and non-domain target servers on Windows Server2016/ 2012/2008R2.

For distributing this script to a number of computers we used Ansible.

Known Issues:

  • Sometimes Powershell reported an error that the parameter "-nonewline" is not valid. Then I updated to the lates PS Version and the problem was solved. (Script will give back "-1" in this case)
  • I sometimes got the message that no event could be found in the event log. This is because the log is flooded with other messages and when it is full it is overwritten. The solution is to enlarge the size of the system event log. (Script will give back "-1" in this case)

Maybe not the best way, but at least a kind of solution for servers without domain… I am looking forward to you comments and improvements…

Michael

Created on May 27, 2019 6:25:36 AM by  Michael Schneider (22) 2

Last change on May 27, 2019 2:49:13 PM by  Birk Guttmann [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Michael,

Thank you very much for your contribution.
I was not able to check the approach myself yet, but I value your input. Very well done :)

Best,
Sebastian

Created on May 27, 2019 7:59:54 PM by  Sebastian Kniege [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.