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 in Exchange 2013/2007 coexistence environment:
ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2007 coexistence environment | 4/4 - Exchange web services in Exchange 2013/2010 coexistence environment:
ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Article Table of content – Exchange web services in an Exchange 2013 coexistence environment | Part 1/2
Table of content
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
- Exchange Autodiscover infrastructure – Introduction | Part 01#36
- The old Exchange environment versus “modern” Exchange environment | Part 02#36
- Who are the Exchange Autodiscover clients? | Part 03#36
- The Autodiscover information | Part 04#36
- The Autodiscover algorithm for locating the “source of information” | Part 05#36
- Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36
- Exchange CAS server as information + Web service provider | Part 07#36
- The dual identity of the Exchange server | Part 08#36
Autodiscover infrastructure | FQDN and URL address
- The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36
- Exchange Web services | Manage the Internal and external URL address | Part 10#36
Exchange Autodiscover flow in different environments
- The content of the Autodiscover server response | Part 11#36
- Outlook client protocol connectivity flow in an internal network environment | Part 12#36
- Exchange clients and their Public facing Exchange server | Part 13#36
- Outlook Autodiscover decision process | Choosing the right Autodiscover method | Part 14#36
- Autodiscover flow in Active Directory based environment | Part 15#36
- Autodiscover scenarios in enterprise environment | Part 16#36
Autodiscover infrastructure | Exchange infrastructure and namespace convention
- Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36
- Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
- Public SAN certificate | Deprecated support in the internal server name | Part 19#36
Exchange, Autodiscover and security infrastructure
Autodiscover Troubleshooting tools
- Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools | Part 1#4 | Part 21#36
- Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36
- Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools | Part 3#4 | Part 23#36
- Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part 24#36
Autodiscover major flow scenarios
Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 2#3 | Part 27#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
Autodiscover flow in an Office 365 based environment
- Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Autodiscover flow in an Exchange Hybrid environment
- Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36
- Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36
- Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
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.
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:
- Managing and providing Exchange web service
- “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.
Exchange 2013 coexistence | Article series index
It is important for us to know your opinion on this article

Excellent commentary . Speaking of which , if anyone is requiring a IRS 1099-C , my assistant edited a blank document here
http://goo.gl/nhVmhn
.