EWS Schema Versions – Why can’t I pick versions for 2007 SP2/SP3 or 2010 SP3?


I see confusion on how the EWS Schema Version (RequestServerVersion) is used from time to time.  So, I would like to clear up how its used.

The EWS Schema Version is not the patch level of the Exchange server. Its something different - its the schema version of EWS that tells the server what the minimal version of EWS your code is written for.  EWS is a web service and it has a schema and schemas have versions. Schema versions generally change with each service RTM or service pack - however, they don't always.

For Exchange 2007 there were no further EWS schema changes after SP1 - so there is no SP2 or SP2 schema for it.  For Exchange 2010 there is no SP3 schema for it - so you have to pick Exchagne2010_SP2 as the highest schema version.

The way it works is that you pick the lowest EWS schema version your application is coded to and the lowest schema version relative to the Exchange servers the code goes against. For Exchange 2007 Exchange2007 or Exchange2007_SP1 could be used, however only SP3 is supported for 2007 now, so any supported server should be past SP1 anyway.

So, if you code needs to go against Exchange 2010 SP2 or later then Exchage2010_SP2 will work. Exchage2013 will not work against any 2010 or 2007 server. When there are mixed versions of servers involved like a 2010 CAS and 2007 mailbox server then the code needs to specify the Exchange2007_SP1 Schema version otherwise they will get an error. Exchange2007_SP1 is the highest EWS schema version for Exchange 2007 though there is an SP3 for it.

Please review this:

EWS schema versions in Exchange
http://msdn.microsoft.com/en-us/library/office/dn741586(v=exchg.150).aspx

 

Comments (5)

  1. Webdav101 says:

    Here is something to keep in mind: The default schema version in the EWS Managed API is different in different versions of the EWS Managed API. You should always set the EWS Schema version instead of going off of the default.

  2. A quick question on the RequestServerVersion element. In the XSD, it defines the value as fixed while it is valid to pass in any ExchangeVersionType value. I bring this up as I’ve been hitting hurdles whereby some Web Application Firewalls are performing a literal validation on the WSDL and Schemas and don’t seem to grok the fact the version can any one of those values. Any suggestions or recommendations for getting around that?

    1. To be more specific: why is the RequestServerVersion value set to fixed rather than default?

      1. Webdav101 says:

        You can set it per call if you wish. However, most will code it to the lowest version of Exchange their code will support. Generally MSDN EWS samples will have the EWS Schema version set to the lowest version of EWS the call will support. The EWS Managed API generally people only set this version setting one time – however, you can do what you want in your code.

    2. Webdav101 says:

      I’ve not heard of firewalls doing such validations themselves. It sounds like they are interfering with the client talking to Exchange. Exchange is not tested for third party firewalls doing their own tests on traffic.

Skip to main content