Update from 17 of October 2014: Scripts to log and correct wrong or absent Time Zone deffinitions added.
As already, that is mentioned in http://blogs.technet.com/b/dst2007/archive/2014/08/22/announcement-update-for-russian-time-zone-changes.aspx Russia will change its existing time zones on October 26, 2014.
What Exchange may offer here to reduce pain for end users (as there are appointments shifted in time)?
For our case, we are interested in PidLidAppointmentTimeZoneDefinitionStartDisplay and PidLidAppointmentTimeZoneDefinitionEndDisplay (attribute description can be found here:
Here it is:
What do we have in Smart View?
Time Zone Definition:
bMajorVersion = 0x02 (2)
bMinorVersion = 0x01 (1)
cbHeader = 0x0030 (48)
wReserved = 0x0002 (2)
cchKeyName = 0x0015 (21)
szKeyName = Russian Standard Time <- We use it to link appointment time zone definition with local registry definition
cRules = 0x0001 (1)
TZRule[0x0].bMajorVersion = 0x02 (2)
TZRule[0x0].bMinorVersion = 0x01 (1)
TZRule[0x0].wReserved = 0x003E (62)
TZRule[0x0].wTZRuleFlags = 0x0002 = TZRULE_FLAG_EFFECTIVE_TZREG
TZRule[0x0].wYear = 0x07DC (2012)
TZRule[0x0].X = cb: 14 lpb: 0100000001000000000000000000
TZRule[0x0].lBias = 0xFFFFFF10 (-240)
TZRule[0x0].lStandardBias = 0x00000000 (0)
TZRule[0x0].lDaylightBias = 0xFFFFFFC4 (-60)
TZRule[0x0].stStandardDate.wYear = 0x0 (0)
TZRule[0x0].stStandardDate.wMonth = 0x0 (0)
TZRule[0x0].stStandardDate.wDayOfWeek = 0x0 (0)
TZRule[0x0].stStandardDate.wDay = 0x0 (0)
TZRule[0x0].stStandardDate.wHour = 0x0 (0)
TZRule[0x0].stStandardDate.wMinute = 0x0 (0)
TZRule[0x0].stStandardDate.wSecond = 0x0 (0)
TZRule[0x0].stStandardDate.wMilliseconds = 0x0 (0)
TZRule[0x0].stDaylightDate.wYear = 0x0 (0)
TZRule[0x0].stDaylightDate.wMonth = 0x0 (0)
TZRule[0x0].stDaylightDate.wDayOfWeek = 0x0 (0)
TZRule[0x0].stDaylightDate.wDay = 0x0 (0)
TZRule[0x0].stDaylightDate.wHour = 0x0 (0)
TZRule[0x0].stDaylightDate.wMinute = 0x0 (0)
TZRule[0x0].stDaylightDate.wSecond = 0x0 (0)
TZRule[0x0].stDaylightDate.wMilliseconds = 0x0 (0)
Now let’s explain how it works (it will also explain why I did not use other combinations of Outlooks and Exchanges).
Clients (Outlook; OWA, EAS application pools) 2010+ when meeting is shown (sent to mobile device), compare TimeZone description (PidLidAppointmentTimeZoneDefinitionStartDisplay and PidLidAppointmentTimeZoneDefinitionEndDisplay ) in meeting with TZ description for the same Time Zone in local registry (2007-2010 CAS, 2013 MBX) on server for OWA, EAS protocols and on workstation for Outlook. Then if “client” understands, that TZ descriptions are different, it trust local TZ definition (as it should be recent) and correct Named Property: id: 0x820D=33293 = PidLidAppointmentStartWhole, dispidApptStartWhole and Named Property: id: 0x820E=33294 = PidLidAppointmentEndWhole to shift appointment on the right time. Some details about how we store appointments here – http://blogs.technet.com/b/dkhrebin/archive/2012/12/07/ios-quot-quot-aka-exchange.aspx
In other words, we do not change anything in store. Appointments are stored untouched. Only clients correct them “on the fly”.
Now some test results.
Environment (all servers and clients updated with all recent updates from Windows Update).
DC001 – 2012 Windows Server
Exch1 – 2007 SP3 RU14 MultiRole @ 2008 R2 SP1
Exch2 – 2010 SP3 RU7 MultiRole @ 2008 R2 SP1
Exch3 – 2013 CU6 CAFE @ 2012
Exch4 & Exch5– 2013 CU6 MBX @ 2012
Client-Win7 – Windows 7 SP1 with Outlook 2007 (12.0.6691.5000) SP3 MSO (12.0.6683.5000)
Client-Win8-1 – Windows 8.1 with Outlook 2010 SP2 (14.0.7015.1000)
Client – Windows 8 with Outlook 2013 (15.0.4569.1503) MSO (15.0.4569.1506)
The following meetings were created:
Next, every other week meetings are created:
Next, every week meetings are created:
Now it is time to update our servers and workstations with new TZ definition.
I used this one for Moscow (hope we will have it in final release):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Russian Standard Time]
"Display"="(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)"
"Dlt"="Russia TZ 2 Daylight Time"
"Std"="Russia TZ 2 Standard Time"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Russian Standard Time\Dynamic DST]
All clients (Outlooks 2007-2013 and OWA 2007-2013) show first single appointment at right time (not surprise as nothing changed)
Single appointments in Outlook 2007 after TZ changes:
Same for OWA 2007
Recurrent appointments also shifted.
Therefore, Outlook 2007 do not have code to correct appointments if TZ definition changed. Exchange 2007 need to be updated with SP3 RU15 to handle this issue KB3004235.
If you do not have 2010 or 2013 Exchange servers, you can follow http://blogs.technet.com/b/exchange/archive/2008/08/15/3406094.aspx
Outlook 2010, 2013 corrected meetings time for single and recurrence meetings
Same for OWA 2010 & 2013
Therefore, Exchange 2010+ and Outlook 2010+ can imidiatly correct appointments if TZ definition is changed.
Only fly in the ointment:
We need DST update for all Exchange servers to show correct Display names for TZs (expected in next RU/CU for all supported servers). Be aware: October 26 2014 Russian time zone changes and Exchange
Good news is that new TZs appears in ECP list immediately after server restart and are available to users:
In addition, pay attention, that Moscow is between Nairobi +03:00 and Tehran (+03:30), so it is sorted in a right way. You can use it to check if TZ was updated or not 😉
Thus if you use Outlook 2010 and legacy Exchange Outlook will shift appointment, but Exchange OWA and EAS not and vice versa.
Okay, if your users use only Outlook & OWA 2010+ (or already updated Exchange 2007 with SP3RU15) and none of them are in new TZs – lucky you.
Update your servers and users’ workstations with TZ patch.
In all other cases, we need some manual work: How rebase appointments using Microsoft Office Outlook Tool: Time Zone Data Update Tool for Microsoft Office Outlook.
Here we need to use Time Zone Data Update Tool for Microsoft Office http://www.microsoft.com/en-us/download/details.aspx?id=17291 or http://www.microsoft.com/en-us/download/details.aspx?id=16271 for x64 clients. Pay attention – for all appointments in your organization.
Other issue I found is bad TZ's stamps done by mobile devices!
If your users use EAS you can find the following issue for meetings created at 10:00 5/11 from iPhone and 12:00 4/11 from Nokia 920:
My 2013 clients Outlook and OWA cannot correct them.
Nokia 920 did not fill TZ description (PidLidAppointmentTimeZoneDefinitionStartDisplay and PidLidAppointmentTimeZoneDefinitionEndDisplay ) at all. Just wrote UTC for PidLidTimeZoneDescription http://msdn.microsoft.com/en-us/library/office/cc815321(v=office.15).aspx
Nokia 1520 wrote everything fine except szKeyName:
Hello! Who are you?
szKeyName = ?????????? ????? (????)
In hex: 003F003F003F003F003F003F003F003F003F003F0020003F003F003F003F003F00200028003F003F003F003F0029
Oh, yes. How we suppose to process it?
iPhone filled it (not sure why Europe/Moscow is (UTC) Monrovia, Reykjavik in PidLidTimeZoneDescription), may be it auto-filled if empty.
Here is TZ name
szKeyName = Europe/Moscow
szKeyName = Russian Standard Time
Of cause, Apple better knows TZs in attributes hidden from users and used only by Exchange and Outlook.
Big problem, as Exchange and Outlook cannot link Europe/Moscow to Russian Standard Time and cannot correct these shifted meetings.
How can we manage it? Exsample of scripts (personal and server versions) which can find and if needed rewrite bad or missed attributes are on the bottom.
Please pay attention it is not offically supported solution from Microsoft!!!
It is just exsample how this kind of scripts can be written.
First of all I strongly reccomend use Test users/pilot groups without any corrections. Just logging what is issue scale, if there is.
Don't foget backup mailboxes if you decide to make corrections. Also expect metting update message storm!!!
Special thanks to Anna Chudova for co-authoring.