Last report time of PC is different from server time

Reporting
1

(imported topic written by Braian)

HI All,

I have notice when extracting report that last report time of PC is different from server time, the time settings is the same timezone is the same. Any suggestion to fix the issue?

Thanks,

Braian

2

I’ve recently noticed this myself, and the IBM L2 tech can’t even offer an explanation to why the time differs from the report view and PC details page. I invited resident expert JGStew to contribute if possible.

3

I’m not exactly sure what this means. Can you provide more details, examples, screenshots?

4

Hi James,

Sure.

So when I look at the report on a device I see:

Yet when I drill down to the details I see:

I emailed my contact at IBM, and he said he’d have to look in to why this is so different. I orignally thought maybe this was just a time difference between the client and the server, but the variation doesn’t match the time zones.

So I need to explain:

  1. Where are these times being retrieved from?
  2. What causes the variance in the same field in 2 different views?

Thanks for any clarity you can provide!

5

Is this in the console or webreports?

I think part of the discrepancy is time zone related, but not all of it. The one value that is +0000 appears to be UTC time, while the other appears to be local time.

One thing is that webreports does not have a live data feed from the root server. It syncs periodically, but even that doesn’t explain why it would have 2 different results in the same system.

1 Like
6

Hi James,

This is from Web Reports. It seems to be a time zone conversion issue somewhere. So I called IBM support to get clarification on:

  • Where specifically is the Last Report Time being retrieved from?

  • What can explain the variance between LIST and DETAIL views?

The technician that called me back confidently said “The Last Report Time is coming from the client on the local device”. So I showed him that the DETAIL field didn’t support that explanation.

I then showed him the relevance for that property from the console, which is:

apparent registration server time as universal string

I said, let’s break this down. First “Apparent” is definitely accurate if you consider it means “seeming real or true, but not necessarily so”, but what is the Registration Server? His first told me that was the DB Server, so I showed him that’s not accurate, then he said it must be the Web-Reports Server, again demonstrated this wasn’t accurate either.

After over an hour he finally admitted he doesn’t know where it’s coming from, or even what the “Registration Server” is.

So I am hoping someone knows the answer out here.

Thanks James!

7

Oh, well now I know exactly what the issue is.

last report time is the last time that the root server received any kind of report / communication from the client, including heartbeats and applicability reports. This is an indicator of how recently the client has communicated with BigFix.

apparent registration server time is what the client thinks it’s parent relay’s clock is set to, but I think only at the time that it last reported it. It is not the correct value to use for last report time I believe.

Actually, now that I think about this more. I could be wrong about that. apparent registration server time might be the equivalent option using session relevance, in which case, this may indicate that the client’s local clock is off.

What is the other properties session relevance? do you know?

####References:

1 Like
8

Thank you for clarifying what the relevance would reference. As far as “What is the other properties session relevance? do you know?” it’s the same property, that’s 1/2 the issue. Relevance should report the same in LIST view as it would DETAIL view, correct?

In WebReports I simply click Explore Computers, look for a device in say China or Moscow and the last report time in this view appears as this first image, when I clicked on the device name to see the detail view the Last Report Time was the 2nd image.

9

SOLVED:

Okay, so REGISTRATION server refers to the RELAY of the client. When you view the data in the list view the WebReports view will display the time converted to the local time zone from the browser. When you look at the DETAIL view of a device the property is displayed in UTC.

Now, if your relays are in other time zones this could be dicey. IBM recommended you could have another property with the relevance of:

NOW as universal time

or simply

NOW

set to Every Report for an interval

10

Actually the “registration server” is the root server and “apparent registration server time” is what the client thinks the server time is with clock skews included.

When the client registers it gets the server time in the response so it knows what the time is on the server. There is a fixlet in BES Support that indicates if the time on the client is significantly different than the time on the server (in UTC of course) and will become relevant to help know if clocks are going off time.

1 Like
11

Hi Alan,

I actually got a call back from the BigFix development team on this. They’re the ones who said the registration server is the Relay. They explained that most information is stored in UTC, the WebReports site code translates it to local time based on the browser’s local time zone, but when viewing the detailed view (click on a computer name) and it will show the literal value.

Now I do know that the local report time is not anywhere close to the time (with correction) of my enterprise server. So I need to do some testing to validate what I have found so far.

Can you provide the Fixlet ID for this action that syncs the time? I’d like to go in to my development area and run it on a endpoint client, document the time, and then manually set the relay for the client to a relay in another time zone. I would assume the following 2 possible outcomes:

  1. The UTC offset value will not change - this means your statement is 100% accurate, and IBM developers needs to start taking classes from you and James.

  2. The UTC offset value will change to the value of the new relay. - this means that the registration server really is the relay.

I’ll follow up here.

Thanks Alan!

12

Does anyone have any updates on this? We are having the same issue where the live web report shows the accurate time but the one that gets automatically generated and emailed is in UTC time.

We want the emailed report to match the time zone of the web report if possible. Could this just simply match what the server time zone is?

13

HI JGallas,

IBM Closed the issue explaining how BigFix manages time/date and how WebReports translates that value.

What I would recommend is to run a few small tests with mock data. If you don’t add custom relevance for the report to determine the time zone, you’ll likely need to create a separate instance of each report with the local time (where you are) translated to the local client time zone.

My organization is global in over 60 countries, so time zones are a constant challenge.

I hope this helps.