Exchange server version "V2_22" returned for Office 365 breaks pattern - consequences?

Question

I just notice that talking to Office365 Exchange Web Services at https://outlook.office365.com/ews/exchange.asmx I get this in my SOAP response header:

<Envelope>
  <Header>
    <ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1049" MinorBuildNumber="23" Version="V2_22"/>
  </Header>

This means that the Version 'schema version' property now breaks the pattern of versions that we had earlier:
Exchange2007, Exchange2007_SP1, Exchange2010, Exchange2010_SP1, Exchange2010_SP2, Exchange2013

In the schema files I found through Google (searching for <xs:simpleType name="ExchangeVersionType">) I could not find anything later than <xs:enumeration value="Exchange2013"/> (e.g. at http://msdn.microsoft.com/en-us/library/ee237685%28v=exchg.80%29.aspx)

If I do a SOAP request with this "V2_22" string, I still get valid answers.

<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:typ="http://schemas.microsoft.com/exchange/services/2006/types" 
  xmlns:mes="http://schemas.microsoft.com/exchange/services/2006/messages">
   <soapenv:Header>
      <typ:RequestServerVersion Version="V2_22"/>
   </soapenv:Header>

But it now looks as if the returned Version is no longer a reliable way to determine the Exchange server version. If V2_22 is not documented anywhere, who says it will not suddenly change to V2_23 tomorrow?

Question: Does this mean I will now have to change my version detection code to look at MajorVersion and then maintain a cross reference between MajorVersion and ExchangeVersionType myself? That is horrible: another dependency to maintain is another potential code break.

[Edited to add]
This is the actual call that gives the result mentioned in the first paragraph, including the HTTP exchange:

>> "POST /ews/exchange.asmx HTTP/1.1[\r][\n]"
>> "Accept-Encoding: gzip,deflate[\r][\n]"
>> "SOAPAction: "http://schemas.microsoft.com/exchange/services/2006/messages/ResolveNames"[\r][\n]"
>> "Content-Type: text/xml; charset=utf-8[\r][\n]"
>> "Content-Length: 610[\r][\n]"
>> "Host: outlook.office365.com[\r][\n]"
>> "Connection: Keep-Alive[\r][\n]"
>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> "[\r][\n]"
>> "<soapenv:Envelope [\n]"
>> "  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" [\n]"
>> "  xmlns:typ="http://schemas.microsoft.com/exchange/services/2006/types" [\n]"
>> "  xmlns:mes="http://schemas.microsoft.com/exchange/services/2006/messages">[\n]"
>> "   <soapenv:Header>[\n]"
>> "      <typ:RequestServerVersion Version="Exchange2007_SP1"/>[\n]"       OR: Exchange2013_SP1
>> "   </soapenv:Header>[\n]"
>> "   <soapenv:Body>[\n]"
>> "    <!-- mes:ResolveNames ReturnFullContactData="1" SearchScope="ActiveDirectoryContacts"-->[\n]"
>> "    <mes:ResolveNames ReturnFullContactData="1">[\n]"
>> "         <mes:UnresolvedEntry>be</mes:UnresolvedEntry>[\n]"
>> "      </mes:ResolveNames>[\n]"
>> "   </soapenv:Body>[\n]"
>> "</soapenv:Envelope>"

<< "HTTP/1.1 401 Anonymous Request Disallowed[\r][\n]"
<< "Server: Microsoft-IIS/8.0[\r][\n]"
<< "request-id: 535f1eb3-294b-4036-a61a-6176ae87a60e[\r][\n]"
<< "Set-Cookie: ClientId=LZLKG0VGKSZMUMEBPSDQ; expires=Fri, 16-Oct-2015 14:42:02 GMT; path=/; HttpOnly[\r][\n]"
<< "X-Powered-By: ASP.NET[\r][\n]"
<< "X-FEServer: DB3PR01CA0057[\r][\n]"
<< "WWW-Authenticate: Basic Realm=""[\r][\n]"
<< "Date: Thu, 16 Oct 2014 14:42:02 GMT[\r][\n]"
<< "Content-Length: 0[\r][\n]"
<< "[\r][\n]"

>> "POST /ews/exchange.asmx HTTP/1.1[\r][\n]"
>> "Accept-Encoding: gzip,deflate[\r][\n]"
>> "SOAPAction: "http://schemas.microsoft.com/exchange/services/2006/messages/ResolveNames"[\r][\n]"
>> "Content-Type: text/xml; charset=utf-8[\r][\n]"
>> "Content-Length: 610[\r][\n]"
>> "Host: outlook.office365.com[\r][\n]"
>> "Connection: Keep-Alive[\r][\n]"
>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> "Cookie: ClientId=LZLKG0VGKSZMUMEBPSDQ[\r][\n]"
>> "Cookie2: $Version=1[\r][\n]"
>> "Authorization: Basic am[snip]Q==[\r][\n]"
>> "[\r][\n]"
>> "<soapenv:Envelope [\n]"
>> "  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" [\n]"
>> "  xmlns:typ="http://schemas.microsoft.com/exchange/services/2006/types" [\n]"
>> "  xmlns:mes="http://schemas.microsoft.com/exchange/services/2006/messages">[\n]"
>> "   <soapenv:Header>[\n]"
>> "      <typ:RequestServerVersion Version="Exchange2013_SP1"/>[\n]"
>> "   </soapenv:Header>[\n]"
>> "   <soapenv:Body>[\n]"
>> "    <!-- mes:ResolveNames ReturnFullContactData="1" SearchScope="ActiveDirectoryContacts"-->[\n]"
>> "    <mes:ResolveNames ReturnFullContactData="1">[\n]"
>> "         <mes:UnresolvedEntry>be</mes:UnresolvedEntry>[\n]"
>> "      </mes:ResolveNames>[\n]"
>> "   </soapenv:Body>[\n]"
>> "</soapenv:Envelope>"

<< "HTTP/1.1 200 OK[\r][\n]"
<< "Cache-Control: private[\r][\n]"
<< "Transfer-Encoding: chunked[\r][\n]"
<< "Content-Type: text/xml; charset=utf-8[\r][\n]"
<< "Content-Encoding: gzip[\r][\n]"
<< "Vary: Accept-Encoding[\r][\n]"
<< "Server: Microsoft-IIS/8.0[\r][\n]"
<< "request-id: b1ce960a-e0d1-4545-9fe7-6711fc34f7ad[\r][\n]"
<< "X-CalculatedBETarget: db3pr02mb203.eurprd02.prod.outlook.com[\r][\n]"
<< "X-DiagInfo: DB3PR02MB203[\r][\n]"
<< "X-BEServer: DB3PR02MB203[\r][\n]"
<< "X-AspNet-Version: 4.0.30319[\r][\n]"
<< "Set-Cookie: exchangecookie=e1[snip]d01; expires=Fri, 16-Oct-2015 14:42:02 GMT; path=/; HttpOnly[\r][\n]"
<< "Set-Cookie: X-BackEndCookie2=jan@[snip].onmicrosoft.com=u56[snip]g==; expires=Sat, 15-Nov-2014 14:42:02 GMT; path=/ews; secure; HttpOnly[\r][\n]"
<< "Set-Cookie: X-BackEndCookie=jan@[snip].onmicrosoft.com=u56[snip]0=; expires=Sat, 15-Nov-2014 14:42:02 GMT; path=/ews; secure; HttpOnly[\r][\n]"
<< "X-Powered-By: ASP.NET[\r][\n]"
<< "X-FEServer: DB3PR01CA0057[\r][\n]"
<< "Date: Thu, 16 Oct 2014 14:42:02 GMT[\r][\n]"
<< "[\r][\n]"
<< "38c[\r][\n]"
<< "[0x1f][0x8b][snip][0xfc][\n]"
<< "[0xac][0x8f][snip][0x85][\n]"
<< "E{}W>[0xcb][0xda][snip][0xbc]"
<< "[\r][\n]"
<< "a[\r][\n]"
<< "t[0x4][0x13][0x3][0xc3][0xc2][0xb6][0xc6][0xb8][0x5]"
<< "[\r][\n]"
<< "b[\r][\n]"
<< "G[0xff][0xf]6'>[0x1c]I[0x8][0x0][0x0]"
<< "[\r][\n]"
<< "0[\r][\n]"
<< "[\r][\n]"

score 1 · Answer 1 · answered Oct 20 '16 at 15:22

Note also that a given server supports a given contract at a point in time. The most up to date schema at this point has the following for ExchangeVersionType:

<!-- Enumeration of Exchange Server versions -->
<xs:simpleType name="ExchangeVersionType">
<xs:restriction base="xs:string">
  <xs:enumeration value="Exchange2007" />
  <xs:enumeration value="Exchange2007_SP1" />
  <xs:enumeration value="Exchange2009" />
  <xs:enumeration value="Exchange2010" />
  <xs:enumeration value="Exchange2010_SP1" />
  <xs:enumeration value="Exchange2010_SP2" />
  <xs:enumeration value="Exchange2012" />
  <xs:enumeration value="Exchange2013" />
  <xs:enumeration value="Exchange2013_SP1" />
  <xs:enumeration value="Exchange2015" />
  <xs:enumeration value="Exchange2016" />
  <xs:enumeration value="V2015_10_05" />
  <xs:enumeration value="V2016_01_06" />
  <xs:enumeration value="V2016_04_13" />
  <xs:enumeration value="V2016_07_13" />
  <xs:enumeration value="V2016_10_10" />
  </xs:restriction>
</xs:simpleType>

Venkat Ayyadevara - MSFT · Accepted Answer · 2014-10-23T21:05:59.050

0

The schema version pattern hasn't changed for Office 365 EWS. The schema version now returned is "Exchange2013_SP1" and I just verified it by going to https://outlook.office365.com/ews/messages.xsd referenced by the WSDL (see below for the line I am referring to).

xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" version="Exchange2013_SP1" elementFormDefault="qualified" id="messages">

I believe we have always returned the ServerVersionInfo as additional diagnostics to help with debugging cases where a specific build may have an issue. But you should continue to use the schema version e.g. Exchange2013_SP1 as the SOAP API version.

UPDATE: We have identified a bug that is causing us to return V2_* as the Version. When an app requests a server version such as Exchange2013_SP1, that same version should be included as the value for "Version" in the response. We are working to fix this. Thanks for reporting this issue!

Please let me know if you have any questions or need more info.

Thanks,

Venkat

edited Oct 23 '14 at 21:05

answered Oct 16 '14 at 14:18

Venkat Ayyadevara - MSFT

2,850
1
14
11

But then why do I get the V2_22 returned? I have added the actual call that I'm doing to EWS, specifying either Exchange2007_SP1 or Exchange2013_SP1. [Here is someone who got a "V2_6"](http://stackoverflow.com/questions/19824792/ews-serverversioninfo-version-attribute-in-responses) (no resolution), which [seems to occur more often](https://www.google.com/search?q=exchange+web+services+ServerVersionInfo+Version+V2_6) – Jan Doggen Oct 16 '14 at 14:58
Thanks for the info. This may be a bug and we are looking into it. There is no planned change to the way we communicate schema version for EWS. Thanks. – Venkat Ayyadevara - MSFT Oct 16 '14 at 21:07
Hi Jan, I updated my answer based on our investigation. This is a bug and we are working to fix it. Thanks. – Venkat Ayyadevara - MSFT Oct 23 '14 at 21:06
"that same version should be included.. " Note that this would be a deviation from former behaviour. I can *request* anything that is supported, e.g. Exchange2007_SP1, but the server would report what version it *is*. Or is this different for the online version? – Jan Doggen Oct 24 '14 at 06:15
Hi Jan, the behavior would be same as before. If you request Exchange2007_SP1, we would return a response with that schema, and set the "version" property to Exchange2007_SP1 as well. Hope that helps. Thanks. – Venkat Ayyadevara - MSFT Oct 24 '14 at 11:41
Huh? Are we misunderstanding each other? My point is (just verified): I do a request with `` to my Exchange 2010 SP2 Server and I get a response ``, so `Exchange2010_SP2` <> `Exchange2007_SP1`. **That** is 'same as before', not returning the requested version as you write. – Jan Doggen Oct 24 '14 at 11:58
Ah, got it. I misunderstood your point and current behavior :) Let me check with the team and get back to you. – Venkat Ayyadevara - MSFT Oct 24 '14 at 12:42

David Sterling - MSFT · Answer 3 · 2016-02-22T23:03:26.147

0

The previous behavior and what should be the current behavior is that the ServerVersionInfo returns both the build number as well as max supported ExchangeVersionType of the server. That value does not reflect the version that the SOAP response body was returned in. It is more of a capabilities kind of thing. As for these new strange and wonderful version tags that are being returned, we are circling back as a team to discuss these - yes, they are real, but obviously as some above have pointed out there could be a disconnect between the schema they refer to and other such stuff. We will be back :)

FYI - I fixed this at the end of 2015, so you should no longer be seeing those funny versions returned. Let me know if that isn't the case...

edited Feb 22 '16 at 23:03

answered Jan 20 '15 at 16:56

David Sterling - MSFT

580
2
6

It is currently (March 2016) returning: V2016_01_06 when I call it. That looks as it can change at any moment again, and I should in no way rely on it anymore (in my program code, to report on the server we are connecting to). – Jan Doggen Mar 29 '16 at 08:56
Update to previous comment in question http://stackoverflow.com/questions/36279717/name-of-version-property-in-serverversioninfo-element-for-exchange-server-2016/39895202#39895202 – Jan Doggen Oct 06 '16 at 12:06
Yep. As of Jan, we started used build dates for versions. We rev the public schema quarterly, so you will notice a rough 3 month addition for the next schema version, etc... In fact, I am due to check one in next week for October. Basically the "newest" version is the beta version and can contain breaking changes until the next version is introduced. So right now, V2016_07_13 is considered beta, and we are still adding to it. Once next week rolls around and I introduce V2016_10_XX, V2016_07_13 will be locked and no additional functionality will be added to it. – David Sterling - MSFT Oct 06 '16 at 23:59
Note also that a given server supports a given contract at a point in time. The most up to date schema at this point has the following for ExchangeVersionType: – David Sterling - MSFT Oct 20 '16 at 15:19

Exchange server version "V2_22" returned for Office 365 breaks pattern - consequences?

3 Answers3

Linked