Exchange web services in an Exchange 2013 coexistence | Part 1/2 | 6#23

Exchange web services?

Q1: What are the Exchange web services?

A1: The Exchange web services, as the name implies, are Exchange service that implemented as: “web-based services”. There are a couple of Exchange web services.

An example for Exchange web service could be:

• Availability service – these are the Exchange web services that enable Exchange client to view the Free\Busy time of other Exchange recipients.
• Automatic reply – know more as the Outlook of office service, which enables Exchange users to respond with an automatic mail message.
• Mail tips – a service which enables to display “tips” for Exchange recipients based on a particular scenario.

Who are the Exchange web service clients?

Technically speaking, each of the Exchange mail clients such as Outlook, OWA or ActiveSync considers is an “Exchange web service client” but the most “famous” client is the Outlook client. Outlook client heavily depends on upon the Exchange web services for the ability to create the Outlook mail profile and for providing Outlook user “standard” services such as Free\Busy time, Outlook of office, etc.

Who is the element that answers Exchange mail client’s requests for Exchange web services?

The “element” that answers the Exchange client’s requests is – Exchange server who holds the CAS role.

As we know, in an Exchange environment, Exchange clients communicate only with the Exchange CAS server.

Based on the Exchange client version, Exchange CAS 2013 will “decide” how to handle the Exchange web service request.

Exchange CAS 2013 and the architecture changes

Exchange 2013 architecture includes significantly changes that relate to the “responsibilities” of the Exchange CAS 2013 server\role regarding the Exchange web service component.

In former versions of Exchange (2010/2007), Exchange CAS server was responsible for:

1. Managing and providing Exchange web service
2. “Answering” Exchange client requests for Exchange web service

Exchange CAS 2013, is responsible only for “answering” Exchange client requests for Exchange web service, but, not for managing and providing Exchange web service.

Autodiscover infrastructure & Exchange web services

Exchange clients, access the Exchange web services by using a URL address.

The URL address that the Exchange client “needs”, is provided by the Exchange CAS server as part of the Autodiscover information.
In simple words, to be able to address to necessary Exchange web services, the first phase that the Exchange client will need to complete is -the Autodiscover step in which he gets the needed information about the existing Exchange web services (the URL address of the current Exchange web services). Only after the Exchange mail client gets this information, he can “directly” address the Exchange server which provides a particular Exchange web service.

A more metaphorical way views the relationships that exist between the Exchange web services, and the Autodiscover infrastructure is to view the Exchange web services as a component that “sit on” or relies on the Autodiscover infrastructure.

The Autodiscover infrastructure is the “map” that the Exchange clients use for locating a particular Exchange web service.

• When the Exchange 2013 client needs Exchange web service, the client addresses the Exchange CAS 2013 server and the Exchange CAS 2013 server “Proxy” the requests for information to an Exchange Mailbox 2013 server.
• When the Exchange 2010 client needs Exchange web service, the client addresses the Exchange CAS 2013 server and the Exchange CAS 2013 “Proxy” the requests for information to an Exchange 2010 CAS.
• When the Exchange 2007 client needs Exchange web service, the client will address the Exchange 2007 CAS server directly (without addressing the Exchange 2013 CAS).

The flow of Exchange web services

Before we start from the description of the Exchange web services in Exchange 2013 CAS and the different flow for each of the Exchange client types, let’s start with a description of a
“Basic Exchange web services flow.”

The client protocol connectivity flow of Exchange web services implemented as follows:

Phase 1 – Exchange client, address Exchange 2013 CAS requesting for Autodiscover information.

Phase 2 – Exchange CAS provides the required Autodiscover information that includes the URL address of the existing Exchange web services. The Exchange web service URL address contains the FQDN (Fully Qualified Domain Name) of the Exchange server who will provide the particular Exchange web service.

Phase 3 – Exchange client address the particular Exchange CAS server, who supposed to provide the required Exchange web services.

Exchange CAS 2013 and the client protocol connectivity flow of Exchange web service

The subject of Exchange CAS 2013 and his relationship with a different version of Exchange client could be quite interesting because the Exchange CAS 2013 behaves differently with each type of Exchange client version.

For example, when we say: ”Exchange 2007 client,” we mean – Exchange client that his mailbox is hosted at Exchange 2007 CAS when we use the term: Exchange 2010 client, we primary Exchange client, that his mailbox hosted at Exchange 2010 CAS, etc.

In the Exchange 2013 coexistence environment, the Exchange web service client protocol connectivity flow is implemented differently for each of the Exchange clients.

Exchange web service and native Exchange 2013 environment.

In a scenario of: ”native Exchange 2013 environment” when Exchange 2013 Exchange client address Exchange CAS 2013 and ask him to provide the required Exchange web services, Exchange CAS 2013 will proxy the request to the Exchange 2013 mailbox server.

In Exchange 2013, the responsibility of managing and providing Exchange web service “belong” to the Exchange 2013 mailbox server.

Exchange web service and legacy Exchange 2010 clients.

The client protocol connectivity flow in an Exchange 2013\2010 coexistence environment based on a simple logic that introduced in the former section, but the main difference is that the Exchange CAS 2013 will be Proxy Exchange web service request of Exchange 2010 client to the Exchange CAS 2010 server.

Exchange CAS 2010 will generate the required information, send the information to the Exchange CAS 2013 and the Exchange CAS 2013 will provide the “answer” the Exchange 2010 client request.

From the Exchange 2010 client point of view, the Exchange CAS 2013 is the “element” that provides the Exchange web service.

Exchange web service and legacy Exchange 2007 clients.

The implementation of Exchange web service in the Exchange 2013 coexistence environment is different because, in this scenario, Exchange CAS 2013 is not involved throughout the process of providing the Exchange web service to the Exchange 2007 client.

Exchange CAS 2007 will address Exchange CAS 2007 when they need to request for a particular Exchange web service.

When the Exchange 2007 client gets the Autodiscover information from the Exchange CAS 2013, the information will be “uniquely customized” to the “needs” of the Exchange 2007 client.

The information will include the URL address of the Exchange CAS 2007 (using the legacy namespace).

When the Exchange 2007 client needs to get a particular Exchange web service, the Exchange 2007 client will directly access the Exchange CAS 2007.