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 changes 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:
http://msdn.microsoft.com/en-us/library/ee160657(v=exchg.80).aspx)
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 trusts 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).
Servers:
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
Clients:
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"
"MUI_Display"="@tzres.dll,-1830"
"MUI_Dlt"="@tzres.dll,-1831"
"MUI_Std"="@tzres.dll,-1832"
"TZI"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,02,00,00,\
00,00,00,00,00,00,00,01,00,03,00,01,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Russian Standard Time\Dynamic DST]
"FirstEntry"=dword:000007da
"LastEntry"=dword:000007df
"2010"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,03,00,\
00,00,00,00,00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00
"2011"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,01,00,06,00,01,00,00,00,\
00,00,00,00,00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00
"2012"=hex:10,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"2013"=hex:10,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"2014"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,02,00,\
00,00,00,00,00,00,00,00,01,00,03,00,01,00,00,00,00,00,00,00,00,00
"2015"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
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, Exchange 2007 and Outlook 2007 do not have code to correct appointments if TZ definition changed.
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+ have code to 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.
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+ 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 (instructions how to rebase will be published bit later).
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
Instead of
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? I think script (will be posted bit later, after tests) can easily rewrite bad or missed (which is worst) attributes.