Sunday, December 11, 2005

Mind the Overlap –2006 Commonwealth Games timezone patch for Daylight Saving and how it affects Exchange and Outlook

This is one for the Aussie’s and anyone who is managing a server on the East coast of Australia. Because of the Commonwealth games next year the date daylight saving starts on is being brought forward 1 week. If anyone remembers back a similar thing was done for the Olympics in 2000. First thing first is what is the overlap period? this is the period between when the new daylight saving starts and the period where it usually starts. This is between the dates 26/03/2006 and 2/04/2006. The long and short of it is that if your users currently have appointments created within this period including recurring appointments (no patches applied) these appointments are going to be out by 1 hour during this overlap period. Microsoft has released a patch that adds a new timezone to the registry but this patch doesn’t retrospectively fix appointments that already exist only those created after the patch has been applied. Because Timezone information isn’t year specific you now run into the problem if your users create appointment in the overlap period in 2007 with the patch applied.

The current KB and Advice from Microsoft can be found at

Here’s my take on this which is absolutely unofficial based on my testing and knowledge, I strongly encourage you to do your own testing to test for yourself the affects of these patches and setting, Also any of the scripts mentioned in this post have had very little real testing. Because I’m a Sydney sider this affects me directly I’ll try to keep this page up to date with any corrections as I learn more.
Depending on your environment you have four areas you may need to worry about with this patch. Desktop, OWA, locally on Exchange Server and Handhelds. Additionally if your using WebDAV or CDOEX to do any appointment creation/modifications you need to apply a hotfix and check your code especially if you’re using hard coded CDO timezone enums.

Desktops- Getting all the desktops your users may be using to access Outlook and OWA updated with this patch (and then removing) it after provides the greatest logistical challenge. The desktop patch affects both Outlook and OWA.
How does the Desktop Patch effect OWA – This is an interesting one because you would think that OWA would only really be affected by the patches on the server well no. When a user tries to create an appointment in Exchange via OWA the browser uses a client side control that pulls information from the time zone on the local machine and the date and the time that is posted to the server is actually the UTC time for the appointment based on the time zone offset from the client. So this means although you may have everything in your company patched if a user walked up to a kiosk machine that isn’t patched and creates an appointment via OWA during the overlap period this appointment would be created 1 hour out no matter what the time zone settings where in OWA. The server-side patch’s for OWA is still equally important however because OWA still does a lot of server side actions that are going to require the right Timezone data. These include free-busy time calculation and also expansion of reoccurring appointments. One example of this is if you have patched your desktops and patched your servers and even applied the hot fix for CDO and OWA if you haven’t updated the timezone for the user in OWA options when OWA goes to expand a reoccurring appointment that has an occurrence in the overlap period it will expand 1 hour out. So to get OWA working properly in the Overlap period with Exchange 2003

1. Update any Desktops that are going to be used to connect to Outlook or OWA
2 Update the Server with the new timezone and enable
3. Apply the hotfix from;en-us;909933&sd=rss&spid=1773 . Note if you don’t apply the hotfix and try changing the Timezone in OWA my experience was that OWA would no longer create appointments at all so this hotfix is import.
4. Adjust the timezone in OWA – Options

Doing a Bulk Update of OWA Timezone Options
Once you have updated the timezone on the server and applied the hotfix another task that must be done is to update the user’s OWA options. The first time a user connect to OWA its sets the property. This is the timezone you see if you go into options in OWA. If you don’t want to rely on your users going in and manually changing this setting you might want to look at a script to do a bulk update of this property. The timezone property itself lives on the root mailbox folder I’ve come up with a ADSI / WebDAV script that will connect to every mailbox on a server and update the timezone setting if it is currently set to one of the 3 affected timezones. This script is written for 2003 so I’ve used the email address in the WebDAV connection string which I find the most reliable way for 2003. If you want to run the script on 2000 you could try using the mailnickname instead. This script takes the name of the server you want to run it against as a commandline parameter and then does a ADSI query to find all the users on that server (not hidden from the addresslist) and then constructs a URL to connect to each user's mailbox and does a propfind on the property to determine what the current timezone is and then does a proppatch with the new value if needed. The script needs to be run with a user that has full rights to all mailboxes on a server see;en-us;262054 for more details. I’ve included the script in the download for this post here

CDOEX /Exoledb and WebDAV

Because CDO maintains an internal table to track time zone information you need a hotfix (for 2003 see) to make sure that any of your CDOEX applications will handle date and times correctly during the overlap period. The CdoTimeZoneId Enum id is stored with any appointments created via OWA and CDO and used by CDO to render the time correctly. What that hotfix does is creates some new CdoTimeZoneId Enum values (and supporting code) to cater for the overlap period. For example the CdoTimeZoneId Enum for Sydney normally is 57 the CdoTimeZoneId Enum the hotfix introduces for Sydney during this period is 78. Again having the correct CdoTimeZoneid Enum set is going to be important if you do an expansion query on a reoccurring appointment with Exoledb or when you go to display an appointment use CDOEX during the overlap period.

Auditing currently affected Appointments

What about appointments that have already been created without that patch being applied in the overlap period. Currently Microsoft recommends that you do an export and import for any affected appointments. Before you do this you might want to identify which users are affected eg those that have appointments created in the Overlap period. For this some Exoldb or WebDAV code can come in handy. I’ve wrote a script that takes the servername or the server you want to analyze as a command-line parameter then uses Exoledb to query that server for any appointments in the overlap period. Because this script uses Exoledb it must be run locally on a Exchange server and must be run with an account that has rights to the users calendar see kb . This script produces a CSV file that lists all the users that have appointments in the overlap period and the details of those appointments. To use the script there is one change you must make before using it which is you must add your primary SMTP domain name in the domainname variable in the script this is used for the Exoledb Connection string. I’ve included a copy of the script in the download for this post here.

Can you identify if an appointment has been created with the patch? Yes and no if the appointment is created with Outlook you can check the following Mapi property{00062002-0000-0000-C000-000000000046}/0x8234 to see what timezone the appointment was created with. If the appointment was created with OWA then it’s a little more difficult. If the timezone patch and hotfix has been applied to the server and the OWA timezone is set then you can use the urn:schemas:calendar:timezoneid property. For example if your using the new Sydney 2006 timezone when the patch is applied the timezoneid property should be set to 78. The problem is if you have the desktop patch applied but the server unpatched an appointment may be created okay in the overlap period but the CdoTimeZoneId will still be set to 57. Also expanded reoccurring appointments may show nothing depending on the method that has been use to expand them.

Can you update the appointment in the overlap period programmatically? I haven’t quite got to that yet as I’m still in the detection and update period. But in theory it should be possible you’d want to make sure that you where only going to affect appointments created in the overlap period. For example if you wanted to adjust reoccurring appointments that may have been expanded wrong in the overlap period you would need to update the timezone information and them make a change that would cause the appointment to be re-expanded.

15 comments: said...

I am looking to resolve a similar issue that we have with our Exchange organisation and was wondering if you had or know of any way to bulk update the appointments for a given period.

Glen said...

If it was me i would write a Script a do this. Updating appoitments with CDOEX is realativly simple. You want to make sure you really test all the senerios before you go out and do a bulk update

Anonymous said...

is there a patch for NT workstation and NT server

Glen said...

I don't belive i've seen a patch released for NT4 i suspect this is because of the support cycle its in. I recommend that you contact Microsoft Support there probably is a patch that hasn't been released (you may have to pay for this im not sure). I've only got 1 NT4 box still functioning in a non critical timezone role.

If they cant help you on a NT4 workstation you could use the patch for Windows 2000/XP. What you need to do is expand the the patch and you'll see a reg file. Convert this reg file to a NT4 format and import the changes. I think the timezone information will work okay because the formats they have used between versions hasn't changed since NT4. If you have got Exchange 5.5 then the only way to get an update for this would be to contact MS and see if they have go a updated DLL. Again im not sure considering the support cycles wether they have done this. (OWA for on Exchange 5.5 uses CDO so this would be effected)


Anonymous said...

What kind of $!%@# government changes the timezone on its people without proactively contacting Microsoft and linux distribution companies and ensuring timezone changes are provided at least a year or two ahead??

Glen said...

Considering the Games actually finished yesterday i don't really understand the point of the change. I guess there's an old Australian saying that's appropriate here

"she'll be right mate"

Daniel said...

We have the same problem here in Israel, only for us it's every year, not just here and then... Crappy politics.


Anonymous said...


I have tons of users who who work in EST, PST and mountain time zone. when I try to extract time zone shows lot of users hace no time zone information to update there calendar items.
I tried using your script to update users OWA time failed

Can I request you to create a script to update EST, PST and mountain time zones users..This would be of great help for DST

Anonymous said...

Hi Glen,

I was wondering if the script you have posted for bulk update of users OWA timezone can also be done for a user who has never logged on using OWA.


Glen said...

>I tried using your script to update >users OWA time failed

Most properly it either permission related eg you need to have full rights on the store to run the script which no account has by default. Also this script wouldn't work if you where using Form Based Authentication in OWA. A better method would be to go via the admin virtual root which gets around any FBA issue and also mean s you can run it with a account that has delegate admin rights and be able to modify every user.

With the other stuff im not quite sure your trying to do. I don't live in those timezones it you can provide a little more info maybe i can help.


Glen said...

Hi Sunil

Should work okay if the user hasn't logged onto OWA. Basically all its doing is modifying properties in the root of the mailbox if the properties don't exist they will be created. Its pretty easy to test.


Anonymous said...

Hi Glen,

Thank you for your reply. However i am not able to get the script to run in my test environment. I am not very good in programming so am unable to comprehend the data in those file. I have 2 files mbxdtupdate.vbs and gapauditex.vbs. In all these i change to my Server FQDN, then i run the mbxdtupdate.vbs in the command prompt adding the netbios name of the server. Is this correct?

Thanks Sunil

Anonymous said...


Here is my requirements..
I have 50-60 servers in EST and PST time zone and users are hell lot of them.
When I try to get there mailbox time zone is just null.
So I need to update all the mailbox times either to PST, or EST to modify there affected calendar items.
I guees a script which could give me an option to update users time zone to PST/EST/mountain time would be of great help.

Thank you
may be

Glen said...

Hi Sunil,

No you shouldn't change the property these are the actually properties name. The only thing you need is to use your servername as the 1 first commandline parameter.

But maybe more importantly this script was only designed for one specific purpose and location which was the commonwealth games update in 2006. This was because at that time they create a new timezone setting for Australia. With the recent timezone update in the US they have used a different method bascially the existing timezone has been modified so there should be no need to do this type of thing (i think honestly i haven't looked into it a great deal because it doesn't affect me).

What are you trying to do what timezones are you trying to change?

Glen said...

>Here is my requirements..
>I have 50-60 servers in EST and >PST time zone and users are hell >lot of them.
>When I try to get there mailbox >time zone is just >null.

What method have you tried to use to retrieve the timezone information. The OWA timezone information only affects OWA unless you are adding additional timezones there not much point in changing or setting it. By default the first time a user logs on to OWA it will set itself (based on the timezone of the local Machine). Unless you want to mod the default for a large subset of users you shouldn't need to set this.

>So I need to update all the >mailbox times either to PST, or >EST to modify there affected >calendar items.
>I guees a script which could give >me an option to update users time >zone to PST/EST/mountain time >would be of great help.

I think you maybe going a along the wrong track here (sorry if this post mislead you). Microsoft have release a rebysing tool to do DST time modification which would be the best way to do this have a look at for more information.