通过

How rebase appointments using Microsoft Office Outlook Tool: Time Zone Data Update Tool for Microsoft Office Outlook.

  • 项目

I used appointments and envirement mentioned in Update for Russian Time Zone Changes 2014 and Exchange (How auto-adjustment works)

As some of our colleagues still use legacy clients we can try to resolve this issue by using Microsoft Office Outlook Tool: Time Zone Data Update Tool for Microsoft Office Outlook 2010 64-bit I didn't find version for Outlook 2013 (for Outlook 2010 32bit and legacy versions and possiblu for 2013 32x)

First attempt: Try to move user to the new TZ:

Tool found 6 appointments

Here is log with details:

[Original Time Zone]

(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)

 

[New Time Zone]

(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2) (Update)

 

[Time Zone Update Log]

Type: Meeting

ID: 040000008200e00074c5b7101a82e00800000000f03d1461bbd0cf01000000000000000010000000aa51f5623a26174d859f60e320ad65fe

Subject: User2010@OWA2010 15:00

Old Start Time: Tuesday, December 2, 2014 11:00:00 AM

New Start Time: Tuesday, December 2, 2014 12:00:00 PM

Old End Time: Tuesday, December 2, 2014 12:00:00 PM

New End Time: Tuesday, December 2, 2014 1:00:00 PM

Recurring: Yes

Result: Success

 

Type: Meeting

ID: 040000008200e00074c5b7101a82e00800000000504a16dcdad0cf0100000000000000001000000057b25eceaa079d4d92eacebf16bd8f49

Subject: User2010@Outlook2010 12:00

Old Start Time: Tuesday, December 2, 2014 8:00:00 AM

New Start Time: Tuesday, December 2, 2014 9:00:00 AM

Old End Time: Tuesday, December 2, 2014 9:00:00 AM

New End Time: Tuesday, December 2, 2014 10:00:00 AM

Recurring: Yes

Result: Success

 

Type: Meeting

ID: 040000008200e00074c5b7101a82e00800000000ce35713bbbd0cf01000000000000000010000000095ddfdd19ccdb40bc0fa284fe2025f3

Subject: User2010@OWA2010 15:00

Old Start Time: Tuesday, November 4, 2014 11:00:00 AM

New Start Time: Tuesday, November 4, 2014 12:00:00 PM

Old End Time: Tuesday, November 4, 2014 12:00:00 PM

New End Time: Tuesday, November 4, 2014 1:00:00 PM

Recurring: No

Result: Success

 

Type: Meeting

ID: 040000008200e00074c5b7101a82e00800000000e086abb2d9d0cf0100000000000000001000000045f49c81cbae284e838ee937d3e6bddd

Subject: User2010@Outlook2010 12:00

Old Start Time: Tuesday, November 4, 2014 8:00:00 AM

New Start Time: Tuesday, November 4, 2014 9:00:00 AM

Old End Time: Tuesday, November 4, 2014 9:00:00 AM

New End Time: Tuesday, November 4, 2014 10:00:00 AM

Recurring: No

Result: Success

 

Type: Meeting

ID: 040000008200e00074c5b7101a82e008000000000dab4c7ebbd0cf010000000000000000100000000dfcacc47e1592478ebc26e8f31d36f8

Subject: User2010@OWA2010 15:00

Old Start Time: Tuesday, October 14, 2014 11:00:00 AM

New Start Time: Tuesday, October 14, 2014 11:00:00 AM

Old End Time: Tuesday, October 14, 2014 12:00:00 PM

New End Time: Tuesday, October 14, 2014 12:00:00 PM

Recurring: Yes

Result: Success

 

Type: Meeting

ID: 040000008200e00074c5b7101a82e0080000000080c7ffaedad0cf010000000000000000100000007af4d49f3ef2944887245843eccafd92

Subject: User2010@Outlook2010 12:00

Old Start Time: Tuesday, October 14, 2014 8:00:00 AM

New Start Time: Tuesday, October 14, 2014 8:00:00 AM

Old End Time: Tuesday, October 14, 2014 9:00:00 AM

New End Time: Tuesday, October 14, 2014 9:00:00 AM

Recurring: Yes

Result: Success

 

Result: Success

 

Okay, also we sent batch updates to other users:

In User2010’s calendar, everything is fine (BTW if we do same with Outlook 2010 for User2013 - same results in Outlook 2010 for User2010):

Single appointments

Recurrent appointments:

What did we do with appointment in organizer's mailbox?

Lets have a look

We changed PidLidAppointmentStartWhole and PidLidAppointmentEndWhole:

Also we updated PidLidAppointmentTimeZoneDefinitionStartDisplay and PidLidAppointmentTimeZoneDefinitionEnsDisplay (now it is insanely long)

Time Zone Definition:

bMajorVersion = 0x02 (2)

bMinorVersion = 0x01 (1)

cbHeader = 0x0030 (48)

wReserved = 0x0002 (2)

cchKeyName = 0x0015 (21)

szKeyName = Russian Standard Time

cRules = 0x0006 (6)

 

TZRule[0x0].bMajorVersion = 0x02 (2)

TZRule[0x0].bMinorVersion = 0x01 (1)

TZRule[0x0].wReserved = 0x003E (62)

TZRule[0x0].wTZRuleFlags = 0x0000 = 0x0

TZRule[0x0].wYear = 0x07DA (2010)

TZRule[0x0].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x0].lBias = 0xFFFFFF4C (-180)

TZRule[0x0].lStandardBias = 0x00000000 (0)

TZRule[0x0].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x0].stStandardDate.wYear = 0x0 (0)

TZRule[0x0].stStandardDate.wMonth = 0xA (10)

TZRule[0x0].stStandardDate.wDayOfWeek = 0x0 (0)

TZRule[0x0].stStandardDate.wDay = 0x5 (5)

TZRule[0x0].stStandardDate.wHour = 0x3 (3)

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 = 0x3 (3)

TZRule[0x0].stDaylightDate.wDayOfWeek = 0x0 (0)

TZRule[0x0].stDaylightDate.wDay = 0x5 (5)

TZRule[0x0].stDaylightDate.wHour = 0x2 (2)

TZRule[0x0].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x0].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x0].stDaylightDate.wMilliseconds = 0x0 (0)

 

TZRule[0x1].bMajorVersion = 0x02 (2)

TZRule[0x1].bMinorVersion = 0x01 (1)

TZRule[0x1].wReserved = 0x003E (62)

TZRule[0x1].wTZRuleFlags = 0x0000 = 0x0

TZRule[0x1].wYear = 0x07DB (2011)

TZRule[0x1].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x1].lBias = 0xFFFFFF4C (-180)

TZRule[0x1].lStandardBias = 0x00000000 (0)

TZRule[0x1].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x1].stStandardDate.wYear = 0x0 (0)

TZRule[0x1].stStandardDate.wMonth = 0x1 (1)

TZRule[0x1].stStandardDate.wDayOfWeek = 0x6 (6)

TZRule[0x1].stStandardDate.wDay = 0x1 (1)

TZRule[0x1].stStandardDate.wHour = 0x0 (0)

TZRule[0x1].stStandardDate.wMinute = 0x0 (0)

TZRule[0x1].stStandardDate.wSecond = 0x0 (0)

TZRule[0x1].stStandardDate.wMilliseconds = 0x0 (0)

 

TZRule[0x1].stDaylightDate.wYear = 0x0 (0)

TZRule[0x1].stDaylightDate.wMonth = 0x3 (3)

TZRule[0x1].stDaylightDate.wDayOfWeek = 0x0 (0)

TZRule[0x1].stDaylightDate.wDay = 0x5 (5)

TZRule[0x1].stDaylightDate.wHour = 0x2 (2)

TZRule[0x1].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x1].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x1].stDaylightDate.wMilliseconds = 0x0 (0)

 

TZRule[0x2].bMajorVersion = 0x02 (2)

TZRule[0x2].bMinorVersion = 0x01 (1)

TZRule[0x2].wReserved = 0x003E (62)

TZRule[0x2].wTZRuleFlags = 0x0000 = 0x0

TZRule[0x2].wYear = 0x07DC (2012)

TZRule[0x2].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x2].lBias = 0xFFFFFF10 (-240)

TZRule[0x2].lStandardBias = 0x00000000 (0)

TZRule[0x2].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x2].stStandardDate.wYear = 0x0 (0)

TZRule[0x2].stStandardDate.wMonth = 0x0 (0)

TZRule[0x2].stStandardDate.wDayOfWeek = 0x0 (0)

TZRule[0x2].stStandardDate.wDay = 0x0 (0)

TZRule[0x2].stStandardDate.wHour = 0x0 (0)

TZRule[0x2].stStandardDate.wMinute = 0x0 (0)

TZRule[0x2].stStandardDate.wSecond = 0x0 (0)

TZRule[0x2].stStandardDate.wMilliseconds = 0x0 (0)

 

TZRule[0x2].stDaylightDate.wYear = 0x0 (0)

TZRule[0x2].stDaylightDate.wMonth = 0x0 (0)

TZRule[0x2].stDaylightDate.wDayOfWeek = 0x0 (0)

TZRule[0x2].stDaylightDate.wDay = 0x0 (0)

TZRule[0x2].stDaylightDate.wHour = 0x0 (0)

TZRule[0x2].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x2].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x2].stDaylightDate.wMilliseconds = 0x0 (0)

 

TZRule[0x3].bMajorVersion = 0x02 (2)

TZRule[0x3].bMinorVersion = 0x01 (1)

TZRule[0x3].wReserved = 0x003E (62)

TZRule[0x3].wTZRuleFlags = 0x0000 = 0x0

TZRule[0x3].wYear = 0x07DD (2013)

TZRule[0x3].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x3].lBias = 0xFFFFFF10 (-240)

TZRule[0x3].lStandardBias = 0x00000000 (0)

TZRule[0x3].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x3].stStandardDate.wYear = 0x0 (0)

TZRule[0x3].stStandardDate.wMonth = 0x0 (0)

TZRule[0x3].stStandardDate.wDayOfWeek = 0x0 (0)

TZRule[0x3].stStandardDate.wDay = 0x0 (0)

TZRule[0x3].stStandardDate.wHour = 0x0 (0)

TZRule[0x3].stStandardDate.wMinute = 0x0 (0)

TZRule[0x3].stStandardDate.wSecond = 0x0 (0)

TZRule[0x3].stStandardDate.wMilliseconds = 0x0 (0)

 

TZRule[0x3].stDaylightDate.wYear = 0x0 (0)

TZRule[0x3].stDaylightDate.wMonth = 0x0 (0)

TZRule[0x3].stDaylightDate.wDayOfWeek = 0x0 (0)

TZRule[0x3].stDaylightDate.wDay = 0x0 (0)

TZRule[0x3].stDaylightDate.wHour = 0x0 (0)

TZRule[0x3].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x3].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x3].stDaylightDate.wMilliseconds = 0x0 (0)

 

TZRule[0x4].bMajorVersion = 0x02 (2)

TZRule[0x4].bMinorVersion = 0x01 (1)

TZRule[0x4].wReserved = 0x003E (62)

TZRule[0x4].wTZRuleFlags = 0x0002 = TZRULE_FLAG_EFFECTIVE_TZREG

TZRule[0x4].wYear = 0x07DE (2014)

TZRule[0x4].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x4].lBias = 0xFFFFFF4C (-180)

TZRule[0x4].lStandardBias = 0x00000000 (0)

TZRule[0x4].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x4].stStandardDate.wYear = 0x0 (0)

TZRule[0x4].stStandardDate.wMonth = 0xA (10)

TZRule[0x4].stStandardDate.wDayOfWeek = 0x0 (0)

TZRule[0x4].stStandardDate.wDay = 0x5 (5)

TZRule[0x4].stStandardDate.wHour = 0x2 (2)

TZRule[0x4].stStandardDate.wMinute = 0x0 (0)

TZRule[0x4].stStandardDate.wSecond = 0x0 (0)

TZRule[0x4].stStandardDate.wMilliseconds = 0x0 (0)

 

TZRule[0x4].stDaylightDate.wYear = 0x0 (0)

TZRule[0x4].stDaylightDate.wMonth = 0x1 (1)

TZRule[0x4].stDaylightDate.wDayOfWeek = 0x3 (3)

TZRule[0x4].stDaylightDate.wDay = 0x1 (1)

TZRule[0x4].stDaylightDate.wHour = 0x0 (0)

TZRule[0x4].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x4].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x4].stDaylightDate.wMilliseconds = 0x0 (0)

 

TZRule[0x5].bMajorVersion = 0x02 (2)

TZRule[0x5].bMinorVersion = 0x01 (1)

TZRule[0x5].wReserved = 0x003E (62)

TZRule[0x5].wTZRuleFlags = 0x0000 = 0x0

TZRule[0x5].wYear = 0x07DF (2015)

TZRule[0x5].X = cb: 14 lpb: 0100000001000000000000000000

TZRule[0x5].lBias = 0xFFFFFF4C (-180)

TZRule[0x5].lStandardBias = 0x00000000 (0)

TZRule[0x5].lDaylightBias = 0xFFFFFFC4 (-60)

 

TZRule[0x5].stStandardDate.wYear = 0x0 (0)

TZRule[0x5].stStandardDate.wMonth = 0x0 (0)

TZRule[0x5].stStandardDate.wDayOfWeek = 0x0 (0)

TZRule[0x5].stStandardDate.wDay = 0x0 (0)

TZRule[0x5].stStandardDate.wHour = 0x0 (0)

TZRule[0x5].stStandardDate.wMinute = 0x0 (0)

TZRule[0x5].stStandardDate.wSecond = 0x0 (0)

TZRule[0x5].stStandardDate.wMilliseconds = 0x0 (0)

 

TZRule[0x5].stDaylightDate.wYear = 0x0 (0)

TZRule[0x5].stDaylightDate.wMonth = 0x0 (0)

TZRule[0x5].stDaylightDate.wDayOfWeek = 0x0 (0)

TZRule[0x5].stDaylightDate.wDay = 0x0 (0)

TZRule[0x5].stDaylightDate.wHour = 0x0 (0)

TZRule[0x5].stDaylightDate.wMinute = 0x0 (0)

TZRule[0x5].stDaylightDate.wSecond = 0x0 (0)

TZRule[0x5].stDaylightDate.wMilliseconds = 0x0 (0)

 

In other words: for Organizer we rewrote all necessary attributes like if we recreated meeting with correct configuration. Cool!

On attendee's side:

We received a message with meeting update information:

However, single appointment updates do not contain TZ definition.

 

For recurrent appointments, we have TZ definition in update.

Also pay attention that it is 448 bytes long.

From user2007's client perspective everything is fine

Single appointments

Recurrent appointments

Cool!

Okay, next patient – User2013

Same updates (no surprise). However, a bit different user's experience.

Single appointments shifted (as we changed appointment start/end time in UTC, but didn't change TZ definition).

Recurrent appointment is fine (as we updated start end time and TZ definition).

Let’s try Daylight Saving Update Mode

Same update and same issue for single appointments

Okay, our problem is that if we update single appointments we do not update TZ definition. How can we manage it? Let’s check what happens if we try move from one zone to absolutely another one.

I'll move my User2010 to Atlantis (for whom else do we have -02:00 UTC TZ?)

Unfortunately, again we did not send TZ definition

Instead of recurrent meeting

And of cause no update for PidLidAppointmentTimeZoneDefinitionStartDisplay and PidLidAppointmentTimeZoneDefinitionEnsDisplay.

Time to return home

Issue is still here:

Conclusion:

Time Zone Data Update Tool for Microsoft Office Outlook works fine if all clients are legacy (2007). For clients 2010 and 2013 we see issue with single appointments (they «corrected» twice). In addition, it works fine for recurrent appointments. Unfortunately it not so careful for single appointments. On the other hand, single appointments will end eventually (instead of endless recurrent appointments).

Comments

  • Anonymous
    January 01, 2003
    Mikhail Stepanov, change your system time to year 2015. Issue will gone.
  • Anonymous
    January 01, 2003
    Meetings created OWA displayed with a shift in Outlook.
    Factually single appointment created in OWA 2010/2013 while server has 2014 year will affected.
    Workarounds:
    1 Use same Time Zone but from other region (Nairobi for Moscow, etc.)
    2 When 2015 comes, restart CAS (2010) or MBX (2013) server and NEW appointments will be created in a right way.
    I filled bug for it. Currently targeted to SP3 RU9 / CU8 (can be changed).
  • Anonymous
    January 01, 2003
    Hello, Dmitry.

    What I should do if KB2998527 installed on 26 sept, but user calendars not fixed yet?
    I start tool on user PC and can't find anything (only recurring appointments that is not was changed in this interval)
    Strange situation, I open recurrent appointment and see in options that TZ is UTC+3, but if open via MFCMAPI I see GMT +0400 (cb 54).
  • Anonymous
    January 01, 2003
    Valery, what Outlook and Exchange versions used?
    Can you please provide information about Named prop name your are mentioned?
    PidLidTimeZoneDescription - just a string with some user friendly TZ name
    PidLidAppointmentTimeZoneDefinitionStartDisplay stores TimeZone Definition
  • Anonymous
    October 09, 2014
    As already, that is mentioned in http://blogs.technet.com/b/dst2007/archive/2014/08/22/announcement-update
  • Anonymous
    November 07, 2014
    Dmitry, are you aware of the 2104 Russia DST update not working with BES and GOOD? We have OL 2k10 and E2k10 SP3 +, OL looks fine but appointments are wrong on the BES and Good platforms?
  • Anonymous
    November 09, 2014
    Also, check what happen with meeting after 7th of January 2015 - you'll be surprised =)
  • Anonymous
    November 27, 2014
    Khrebin Dmitry, tested changing the system time to year 2015 but issue remains in Outlook 2013 with RTZ
    Exchange 2010 SP3 RU 6
    Outlook 2013 (15.0.4641.1001) 32 bit