CDA IP Mappings time stamp not in correct time zone

keithsauer507 · ‎02-06-2016

Hello,

In the CDA i did set the clock timezone to EST, ensured it was syncing from our DC and even a show clock indicated the correct time. The IP to user name mappings still show an incorrect time stamp so I rebooted the CDA. Upon coming back into this screen after the reboot, the time stamps still are wrong. For instance, if I search for my AD username it shows a timestamp of 2016-02-06T13:55 when in reality it is right now 8:59 AM.

I'm just trying to ensure this is right because what were seeing is a periodic once a night lockout of AD user CDAService, which is the user that we use for CDA to talk to the DC's. I see this log:

account lockout "domain\cdaservice" at 2016-02-06 08:55:58.0 from jcifs1_68_ea on DC dc1.domain.com

I of course manually unlock the AD account until the next time the CDA is restarted or the next day (maybe the veeam backup causes a slight disconnect once the nfs snapshot consolidates).

Anyway I just went through and pasted in the CDAService password again in all 4 DC's, and the status comes up with a green check, so I would think we are good there.

So just want to make sure the time displayed in the logs is not attributing to this (like a kerberos ticket issue with time way off).

Handy Putra · ‎02-07-2016

Hi,

Does the timestamp shows in the CDA has "Z" at the back such as 2016-02-06T13:55Z ? if yes,

The timestamps shown in the IP Mapping section of CDA are hard-coded to be GMT (Zulu time) and we do have a defect for this - CSCuc54428 (IP mapping timestamp format to follow CDA CARs setup)

Regards

Handy Putra

keithsauer507 · ‎02-08-2016

Yes if I expand the column I see a Z at the end. This is definitely not what we want. We specified EST time zone on purpose so we could get accurate logs, down to the second.

Because there is a bug for this, (you say CSCuc54428) I hope this will be corrected in a future patch update for CDA.

Handy Putra · ‎02-08-2016

I definitely agree with you, this defect will make challenging to debug or track issues when comparing the records to the local time-zone. and will need to change this timestamp so that it is configurable by the user or matches the timezone configured in CDA.

Unfortunately there is no timeline on when the fix will be, however we are seeing more and more sighting to this issue (which is good) therefore the development team will get more pressure to provide with the fix :-)