skip to Main Content

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

The purpose of the current article is to enable us to understand better the concept of Exchange web services in an Exchange 2013 coexistence environment.
In the present article, we will review the logic and the characters of the Exchange web service in Exchange 2013 coexistence environment.

The article is the first of two, in which we will review the subject of Exchange web services in an Exchange 2013 coexistence environment. The next article is: Exchange web services in an Exchange 2013 coexistence environment | Part 2/2The detailed “step by step” review of the Exchange web services, in different Exchange 2013 coexistence environment appears in the following articles:

Exchange web services

Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

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.

What are the Exchange web services

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 are the real Exchange web service clients

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.

Who is the element which Exchange client mail address for getting Exchange web services

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.

answering Exchange client requests for 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.

Exchange web services and Autodiscover infrastructure

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.

The Exchange web services sit on the Exchange Autodisc

  • 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.

The flow of Exchange web services -01

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

The flow of Exchange web services -02

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.

Exchange CAS 2013 - Different relationship with different Exchange web service clients

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.

standard Exchange clients

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 services - Exchange 2013 -2010 client versus Exchange 2007 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 services infrastructure - Native Exchange 2013 environment

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 services infrastructure - Exchange 2013 - 2010 coexistence environment

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).

Exchange web services infrastructure -Exchange 2013 2007 coexistence environment -01

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

Exchange web services infrastructure -Exchange 2013 2007 coexistence environment -02

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *