This was an extremely strange / rare issue, so I figured I would share it.
In this customers environment, they are using XenApp 6.5 on Server 2008 R2 for published desktops, this environment is a hosted desktop environment for a number of countries in Europe.
Infrequently an issue could be observed where the users timezones would shift out by one or two hours within the Lotus Notes application. This would case SameTime conversations and Calendar times to display out by the aforementioned value above.
When this issue occurred, it happened to all users on the server. A restart of the server did not fix the issue.
Interestingly, a “TZUtil /g” was reporting the client was in the correct time zone:
If you ran “TZUtil /s GMT Standard Time“, then closed and opened Lotus Notes… The problem was resolved for that user, in that session until they logged off.
It’s worth pointing out, that this issue was only seen in Lotus Notes, not in any other application, java or otherwise.
When comparing the TimeZone settings from a problematic server to a working server, I found the following difference:
These keys are stored under:
And the working server looked as follows:
Now that is weird! So we copied the correct keys from the server to server and the issue was resolved. On all servers once users closed and opened Lotus Notes again.
But what caused this?
With a work around in place, I began to dig deeper into what caused the timezone to change on the servers despite the fact that no users have the ability to do so.
Analysing the logins to the servers, I spotted an administrator account logging into each of the servers as the day went by. This user didn’t log into the correctly working servers so this was the first clue.
Now if you’ve used Lotus Notes combined with XenApp and timezones before, you’ll know its a complete nightmare, interestingly the administrator in question (me, shamefully), was logging onto a XenApp session with a linux timezone to replicate an issue.
More embarrassingly, I then decided to Remote Desktop inside of the XenApp session to the affected servers, and with my admin account being who it was… inadvertently changed the timezone for the servers it seems.
That doesn’t sound right? You rdp’d from a client in a different time zone and it changed the server timezone?
I agree, but I have since been able to replicate this in a test environment. As with Server 2008 Microsoft now handle the timezone redirection themselves as part of group policy and administrative accounts will change the timezone of the server intermittently.
Now most customers probably wouldn’t even notice this, unless they are using lotus notes, as all other applications behaved correctly.
How do you work around this issue?
Ensure that the Group Policy you use to configure timezone redirection is configured to “not apply” to any local administrator on the XenApp server that may log in.