How exactly works the WMI UTC-Time Sensor

Hello,

The WMI UTC Time sensor monitors the UTC time of a target device using Windows Management Instrumentation (WMI). It shows the UTC time of the target device, and the time difference between the PRTG Core Server system time and the target device, in seconds, from: PRTG Manual: WMI UTC Time Sensor.
Can you please use our WMI Tester and scan against this particular target with the following query:

SELECT Day,Month,Year,Hour, Minute, Second FROM Win32_UTCTime

Please then compare this to scans from your python script around nearly the same time.

best regards.

ok. the difference between the "PRTG system time and the target device". Where "PRGT system" probably is the probe executing the wmi. got it.

makes sense if you can rely on the probe...

my python uses a timserver (like ptbtime1.ptb.de) as reference because I don't trust the probe either.

thank you

one additional comment: may it be that the 12-14sek offset currently beeing logged to PRTG come from not regarding the processing time of the wmi requests?

The WMI UTC sensor works like this:

It retrieves the remote UTC Time via WQL (i.e. SELECT Day,Month,Year,Hour, Minute, Second FROM Win32_UTCTime)

After the query has returned its values it immediately retrieves the Local UTC Time of the Core Server (not via WMI). In theory there may be a delay, depending on how fast the WMI System works, but twelve seconds seem to me an awful long time between two measurements.

I recommend crosschecking this sensor type across several of your computers to find out if this delay is WMi specific or can be explained otherwise.

Hello,

Please could you add an option/setting to specify a source for the the UTC time, such as 0.pool.ntp.org, rather than using the internal time from the PRTG server?

The reason this would be helpful is in my case all servers were configured to get their time from the DC's. The DC's were getting their time from the PDC-role holder. The PDC-role holder was getting its time from the Hyper-V host. The host, being a member server, was getting its time from a DC.

The PRTG sensor never picked up an issue as it was set to monitor time difference, which was never more than 1s out. I only picked up on this because my own PC was a minute behind my wrist watch. It would be more valuable to compare the monitoring system's time against a known accurate source, such as a specified external source.

Thanks.

PS: Is there a better method of providing feedback other than the forums??

Hello miyo360,
thank you for your feedback.

There are no plans to change the sensor's behavior/operation at the moment. The sensor is indeed intended to monitor the Time difference in comparison to the local system time.

But I agree that your request makes sense. For now I can only suggest that you use a Custom-Script sensor to do it instead. It appears to be possible to poll the current time from an NTP Server using NTP:

• Get Network NTP Time with PowerShell

One could poll the NTP Server using this approach and at the same time poll the target system using the above mentioned WMI query. Then, subtract the query delay from both results and calculate the difference between them. That should give you the desired output/result.

To get started with Custom-Script sensors I encourage you to have a look here:

• Customer Powershell Script Returns no response

Also worth looking into:

• Guide For PowerShell Based Custom Sensors
• PRTG Manual: EXE/Script Advanced Sensor

As for the best way of providing feedback. You can either share your toughs/comments publicly here on the KB or contact us directly via a support case.

Best Regards,
Luciano Lingnau [Paessler Support]

Can this sensor show server local time? We want to make request to remote server and want to return what the time is now on it.

Time could only be displayed within the message field of the Sensor. Using PowerShell for this:

invoke-command -ComputerName dc1 -ScriptBlock {get-date}

You'll need to work with credentials, most likely, and enable Remote PowerShell on the Target host.