Updating Exchange Server 2007 Exchange Web Service Clients to SP1

Exchange Server 2007 Service Pack 1 is coming soon! The service pack includes some Exchange Web Services–related changes that we think you should know about. In fact, you will want to become familiar with these changes so that you can update your client applications to use the new functionality.

For starters, we’ve added enhanced delegate access, delegate management, folder-level permissions, public folder access, and identifier translation. For more information about these features, check out the What's New in Exchange Server 2007 SP1 Extensibility article. Consider adding this functionality to your EWS client applications. We’ve also added a new version SOAP header that is used to distinguish client applications, and the schemas they use, between the initial release and SP1 versions of Exchange 2007.

Overall, we encourage you to update your EWS applications to use proxy classes that are generated against the schemas that are included in Exchange 2007 SP1. Use the SP1 version header to distinguish the request as coming from an SP1-compliant client application. Client applications that send requests to Exchange 2007 SP1 servers that use the SP1 release version of the Web service schemas must specify the Exchange2007_SP1 enumeration value as the version header. Otherwise, requests that are sent to a Client Access server are assumed to be from Exchange 2007 client applications. These requests are validated against the initial release version of the EWS schemas. Therefore, any clients that use autogenerated proxy classes that are created from the SP1 schemas should use the version headers to distinguish the request version. Any client application that has been upgraded to send requests and receive responses based on the SP1 schemas should also use the version header.

Here is an example of how to set the version on the ExchangeServiceBinding to represent an Exchange 2007 SP1 request:

ExchangeServiceBinding esb = new ExchangeServiceBinding();
esb.RequestServerVersionValue = new RequestServerVersion();
esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1;

Here is the XML that describes the SOAP header that represents an SP1 request. This is the same XML that is created by the RequestServerVersionValue property of the ExchangeServiceBinding object:

<soap:Header>
  <t:RequestServerVersion Version="Exchange2007_SP1"/>
</soap:Header>

Another important change in Exchange 2007 SP1 is the use of a new identifier format. The identifier format that was included in the initial release version of Exchange 2007 was partially based on SMTP addresses. However, SMTP addresses can change. Therefore, if a client is caching identifier information and an SMTP address changes, any attempts to use those cached identifiers in subsequent requests will fail because the identifier was formed using an outdated SMTP address. This requires a client to resynchronize with the Exchange server any time the primary SMTP address changes. In Exchange 2007 SP1, the identifier is partially based on a unique mailbox identifier that does not change. By default, in both Exchange 2007 and Exchange 2007 SP1, requests are validated against the Exchange 2007 version of the schema, which is the schema that is included in build 685.024.

The following table lists the possible identifier scenarios and how requests are handled for each.

Scenarios for requests against Exchange 2007 SP1 target servers

Identifier Version	Version Header	Outcome
E2K7 SP1	Not set	Schema validation error
E2K7 SP1	Exchange2007	Schema validation error
E2K7 SP1	Exchange2007_SP1	Successful request
E2K7	Not set	Successful request; same behavior as request sent against the initial release of E2K7
E2K7	Exchange2007	Successful request; same behavior as request sent against the initial release of E2K7
E2K7	Exchange2007_SP1	Schema validation error

But wait! There are other reasons to migrate to Exchange 2007 SP1. The SP1 version of Exchange Web Services also includes the following improvements:

1. Better time zone support. See Working with Time Zones in the Exchange Web Services GetUserAvailability Operation for more information.
2. Improved error responses.
3. The Proxy to Best CAS feature. Client Access servers now proxy requests to the most appropriate Client Access server to service a mailbox. This functionality is independent of the version header in the SOAP request.
4. Other updates that might affect product behavior. Be sure to retest your client applications after you install Exchange 2007 SP1.

You now have some compelling reasons to install Exchange Server 2007 SP1. So join the Beta fun and download SP1 Beta 2 to learn more about these exciting new features. And while you’re at it, provide us with some feedback through the Exchange Development forum.

Comments

• Anonymous
  December 10, 2007
  How can we check the availability of a room resource for a recurring meeting? I am using Exchange Web Services.

• Anonymous
  June 18, 2009
  If you are using Exchange Web Services (EWS) against Exchange 2007 SP1, you may run into an issue where

• Anonymous
  July 08, 2009
  I am getting the error code as follows when i m using GetFolder web service request. ResponseCode ErrorNoPublicFolderServerAvailable Using VS .NET 2005. Ve set esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1; so no issues with it. Ve added the enumeration value ErrorNoPublicFolderServerAvailable to the ResponseCodeType enumeration in the messages.xsd file to get rid off "Instance validation error: 'ErrorNoPublicFolderServerAvailable' is not a valid value for ResponseCodeType.", but now i m getting ResponseCode = ErrorNoPublicFolderServerAvailable