cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1329
Views
0
Helpful
3
Replies

Cisco ISE logging timestamps after upgrade to 3.1 from 2.7

joeharb
Level 5
Level 5

We upgraded our ISE deployment over the weekend and timestamp of logging events are in UTC instead of CST.  I logged into the CLI and notice that the TZ is set to UTC, is this a known issue?  From what I have read, changing the Timezone requires a restart of the ISE application, is this correct?  Is there a specific order that is should be done on the nodes?  I have another issue with the guest portal that I am working with TAC on and can see if I can get some insight into the TZ change or will open another case if needed.  I just didn't know if anyone else has ran into this issue.

Thanks,

Joe

1 Accepted Solution

Accepted Solutions

It needs to be done on both nodes. Regarding the order, it won't change much as both of them need to go through the restart process, so as long as you don't do them at the same time either one should be ok. I would presonally try first with the secondary PAN, and I would recommend taking a full configuration backup ahead of the change. During the restart process no new authentication and authorization sessions would be served, portals would be affected as well, and obv when the restart happens on the primary PAN you won't be able to access the management console, depending on your environment you might want to do this OOH.

View solution in original post

3 Replies 3

UTC is the default time zone on ISE but I wouldn't expect it to change the previous time zone that was configured. I've done a few ISE 3.1 upgrades and I don't remember running into any issue like this. You can change the time zone from config t with the command "clock timezone ...", and yes ISE will restart on the back of this change.

This is a 2 node cluster do I need to do it on all nodes and is there a specific order?

It needs to be done on both nodes. Regarding the order, it won't change much as both of them need to go through the restart process, so as long as you don't do them at the same time either one should be ok. I would presonally try first with the secondary PAN, and I would recommend taking a full configuration backup ahead of the change. During the restart process no new authentication and authorization sessions would be served, portals would be affected as well, and obv when the restart happens on the primary PAN you won't be able to access the management console, depending on your environment you might want to do this OOH.