When a certain time zone does not work with the EWS Managed API…

When using EWS with some time zones you might run into issues with getting to work.  As an example, you might run into issues with Russian Standard Time or calling GetUserAvailabilty.  You might even see the "The specified time zone isn't valid" error. There are usually work-arounds for such issues.

The need to keep Windows time zone information updated:

At times there may be issues with time zones due to countries changing their and sometimes there very little notice – I've heard as little as a month.  Some countries change their timezones very often – even a couple times a year. A while back Russia dropped time zones and created many new ones. Exchange and other Microsoft products are overall built on Microsoft APIs and those APIs go to the Windows registry in order to get time zone information.  EWS uses and the EWS Managed API use .NET and .NET uses the Windows registry. So, it's critical that computers are kept up to date. This goes for both client and server machines.

Use the EWS Managed API from GitHub:

The EWS Managed API 2.2 from MSDN is many years old. The current version is checked-into GitHub and has fixes not in the MSDN release. One of these fixes is for GetUserAvailability in dealing with time zones. So, it's best to download and build the latest version this API for your usage.

Update .NET:

As mentioned earlier .NET is used by many applications involved with EWS and it should be kept up to date with .NET patches they may resolve issues with time zones.

Keep Exchange updated:

Bugs in Exchange EWS server side can and have happened, so be sure you are fully patched.

Consider using the Exchange2007_SP1 for the schema version:

The EWS Managed API will send just the time zone identifier name in an EWS request if you set the schema version to Exchange2007_SP1. If you set the schema version to something later then it will instead add a full definition of a time zone information and if the definition of the time zone does not match Exchange, then you will get an error thrown. The schema version tells Exchange that the call your making needs an Exchange server which is of at least that version and if it's not then Exchange will reply with an error. So, as long as the specific call you are making works with Exchange2007_SP1 then its fine to use that version. You can set the schema version to Exchange2007_SP1 for a specific call then change it for other calls which require a higher EWS Schema version.

Note: This methodology helps to work around many time zone issues.

There is not currently an override in the EWS Managed API to cause it to only emit the time zone identifier name instead of the full block of time zone definition information. However, you could download the source and add such code.

Checking Timezone processing behavior with.NET code.

If you want to see if an issue is likely with .NET time zone handling and the time zones in the registry, then you could write .NET code to check. However, you don't need to do go to the extent of writing such code. In EWS Editor on the Tools menu there is a "Timezone Helper" window which does such processing. Look for the TimeZonesForm" form. It has calls to .NET for pulling the user's time zone settings, enumerating time zones in the registry and doing time zone time conversions. I wrote this code a few years ago when I was troubleshooting EWS time zones issues and was verifying that some issues were with .NET and not specifically in Exchange code or the EWS Managed API code.

An option – Use a raw EWS POST:

Instead of using the EWS Managed API you could use a raw SOAP POST for the EWS request which would only include the time zone identifier name. Also, you could try pulling the time zone information for the time zone from the Exchange server and using it in your EWS Request - the problem with this is it's a lot of work and the time zone identifier name by itself usually works.

Watch out for custom time zones:

It's possible to build a custom time zone definition and it be used an EWS call. Sometimes third-party software will construct such a time zone definition; however, Exchange and other products and APIs will throw errors if it's not correctly constructed. If your code tries to parse or reuse a bad time zone, then you may get errors. Exchange and other Microsoft products and APIs expect time zones to be built correctly.


Exchange Server meetings in Russian time zones as well as names of time zones are incorrect after October 26, 2014


EWS Managed API... open source? YES! It's now Open Source!!!