Share via

Update for Russian Time Zone Changes 2014 and Exchange (How auto-adjustment works)

  • Article

Update from 17 of October 2014: Scripts to log and correct wrong or absent Time Zone deffinitions added.

 

As already, that is mentioned in https://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:
https://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 - https://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, 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 https://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 https://www.microsoft.com/en-us/download/details.aspx?id=17291 or https://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 https://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? 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.

BadAppointmentsWithCorrection.zip

Comments

  • Anonymous
    January 01, 2003
    Замечательная статья, Дмитрий!
  • Anonymous
    January 01, 2003
    Also you can request (open case in support) Interim Update for DST issue. For 2007 and 2010.
  • Anonymous
    January 01, 2003
    Attention!!! After Installing Windows DST patch you need to Restart Exchange Server!!! IIS restart not enought!!!
  • Anonymous
    January 01, 2003
    Михаил, какая у вас версия Exchange? Про мобилки: я часовой пояс Багдада использую у себя.
  • Anonymous
    January 01, 2003
    Time Zone Display Names will be changed in December Wave of Updates.
    For Exchange 2010 SP2+ and 2013 RTM+ - we take all information about Time Zone from registry. Only issue - we do not update Stings. So we have Moscow +04, but IT works as +03. If you look to screen shot you can see that IT is sorted as +03 TZ.http://blogs.technet.com/b/exchange/archive/2014/11/11/november-exchange-releases-delayed-until-december.aspx
  • Anonymous
    January 01, 2003
    Hi Dmitry, great post! I have the first case connected with iOS and new time zones ??
  • Anonymous
    January 01, 2003
    Вячеслав, перезагрузите, пожалуйста, сервер.
  • Anonymous
    January 01, 2003
    Дим, а есть какой-то шанс таки увидеть нормальные митинги или тулзу по их исправлению?
    p.s. как житуха? давно не списывались :)
  • Anonymous
    October 01, 2014
    I used appointments and envirement mentioned in Update for Russian Time Zone Changes 2014 and Exchange
  • Anonymous
    November 10, 2014
    We've just installed on our Exchange 2010 MBX & CAS servers (separate boxes).
    When connected via RDP to these machines we can see the updated TZ information with the new display name for Moscow etc,
    (UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
    --

    However, when connecting to me mailbox via OWA and trying to change to this new time zone it still shows the old TZ name of
    (UTC+04:00) Moscow, St. Petersburg, Volgograd

    We're about to open a case with Microsoft anyway, so not sure if it's purely a cosmetic thing.
  • Anonymous
    November 10, 2014
    Дмитрий,
    а в итоге то ожидать апдейта от майкрософт? или у них санкции против РФ? у нас печаль с календарями, то что с Outlook в Oulook, письма и задачи летают окей, как только приходит на OWA или на мобилу, всё сразу скачет. OWA +4. мобикли тоже +4 Москва, Сервера +3, Компы +3, Майкрософт что то делает с этим вообще?
  • Anonymous
    November 10, 2014
    Just realised your ECP/OWA screenshot above is exactly as we see in our environment.

    Why is the timezone not displayed as the new name of "(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)"?

    Having is displayed as "(UTC+04:00) Moscow, St. Petersburg, Volgograd" even if behind the scenes it is reading the +3 information from the registry is hugely misleading and confusing to users and server admins.

    Thanks,

    Conor.
  • Anonymous
    February 05, 2015
    Exchange 2007 SP3 UR15. OWA продолжает отображать все события с +4 . В настройках ящика стоит (GMT +03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
  • Anonymous
    February 13, 2015
    Дмитрий, действительно все решилось перезагрузкой.
    Спасибо
  • Anonymous
    July 07, 2015
    Dmitry, do you know if time zone name issue in OWA was ever fixed? I'm running Exchage 2010 SP3 with Update Rollup 8-v2 and 9 applied, but Moscow time zone in OWA is still show as "UTC+4".