The current article focused on the two primary responsibilities of the Exchange CAS server:
- Exchange CAS server as an information provider (Autodiscover information).
- Exchange CAS server as Exchange web service provider.
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
The current article is the continuation of the previous article –xx. In the former article, we have reviewed the Exchange CAS server responsibilities that described as “providing Exchange client’s access to their mailbox”.
Exchange CAS server as an information (Autodiscover information) provider
In the following section, we will focus on the aspect of the Exchange CAS server as an “information provider.”
Two main categories of Autodiscover information
We can classify the type information, which the Exchange CAS server provides to Exchange clients into two broad categories:
1. Configuration settings for Exchange mail client
The Exchange CAS server provides the required configuration settings for three types of the mail client -Outlook, Mobile mail clients, and webmail client.
The configuration parameter is used by Outlook and Mobile mail clients for creating a mail profile automatically.
Regarding the subject of a webmail client such as – OWA, this Exchange client is not configured using a mail profile and, to be honest; I don’t know when and where the OWA web client will use Autodiscover information.
2. Information about Exchange web services
The second type of information that the Exchange CAS server provides to his Autodiscover client is a list of available Exchange web bases services.
This “list”, includes a description of the particular Exchange web service that provided and the URL address of the specific web services (the URL address includes the host name of the Exchange CAS server who provides the specific web service).
The Exchange CAS server provides the information about the existing web services by using “different formats”.
One type of “format” for external mail clients that includes the public name of the Exchange CAS server who provide the particular web service. An additional types of “URL format” which include the internal\private name of the Exchange CAS server which provides the web service ( the internal \ private name is not accessible or published for external mail clients).
1. Information needed by Exchange clients, for creating a new mail profile.
Exchange clients such as Outlook and mobile devices, need to create a mail profile for connecting their Exchange mailbox.
We can relate to a “mail profile” as a “collection of configuration settings and user details” that needed for creating the communication channel with the Exchange CAS server.
In theory, the required configuration settings could be configured manually, but in practice, the task of manual configuration of mail profile is not so simple because it requires prior knowledge of the parameters and setting needed for the mail profile and this task, is unsuitable for “standard user.”
Additionally, in case that the destination server is Exchange 2013, the option of creating a manual mail profile becomes almost impossible, because the Outlook mail profile is not configured using the Exchange CAS server name but instead, using a session ID or GUID ID that is provided by the Exchange CAS server.
Given that the Exchange client provides his E-mail address and the user credentials, all the rest of the required technical details will be given to the mail client such as Outlook and will be used for the automatic creation of the new mail profile.
2. Information about available Exchange web services.
Exchange CAS server, serve as a “focal point” or “information center” for his Exchange clients. We can say that mail client such as Outlook relates to the Exchange CAS server a “Bulletin board.”
The Exchange CAS server has all the information about “who is doing what” and how to get there.
If we want to be more technical, the Exchange client (the Autodiscover client) submits a request for information, by asking a file named – autodiscover.xml or autodiscover.csv file.
The Exchange CAS server “answer,” meaning the information that is provided by the Exchange CAS server to the Exchange client such as Outlook, is “packed” and delivered to the client as an – Autodiscover responds.
The Autodiscover.xml includes valuable information about all the available Exchange web services in the existing Exchange infrastructure.
The information that the Exchange CAS server provides includes a detailed description of:
- The names of the available Exchange web services.
- The URL address of each of the web services – the URL address included the name of the Exchange CAS server which provides the particular web service.
- Different type of URL address for external and internal mail clients – Exchange CAS server have two “identities” – internal identity that is “exposed” only to the internal mail client and external identity that exposed to external mail clients.
The information that the Exchange CAS server provides is provided based on the “type of the Exchange client.” In case that Exchange CAS server recognize that the mail client is “internal mail client,” the information will include the URL address with the “private names” of the Exchange CAS server\s.
Exchange CAS server, is responsible for generating the required information.
We use the term ”generating” because, the information is not a static, but instead, “dynamic”. The meaning that the Exchange CAS server will need to “re-create” the information for each Autodiscover client request.
Exchange CAS server “pack” the information into an XML format and send the data to the Exchange, mail client.
The “Exchange web services,” could be provided by a single Exchange CAS server or could be distributed among many Exchange CAS servers.
Outlook client, use the information that he got from the Exchange CAS server (the Autodiscover response) when he needs to get a particular Exchange web service. For example – the Availability Service (Free\Busy time), Automatic reply (Out of office), Mail tips and so on, by addressing the Exchange server which provides the particular web service.
In the following diagram, we can see the process in which the Exchange client request for the information and the Exchange CAS server responds with an “answer.”
The Exchange client, “use” the information that includes the URL address of a particular Exchange web service for – addressing or connecting, the Exchange CAS server which provides the required web service.
Providing Exchange web services \ access to the Exchange web service.
An Exchange CAS server serves as the element that provides Autodiscover information about the available Exchange web services and, at the same time, plays the role of the “service provider” by providing Exchange web services.
This “mixture” of services is relevant only for Exchange Server versions 2007 and 2010.
In Exchange 2013 architecture, the responsibility for providing Exchange web service was allocated to the Exchange mailbox server.
The Exchange 2013 CAS server will forward Exchange client requests to for Exchange web service to the Exchange mailbox server, but he is not the “element” to provide the Exchange web service by himself.
The Autodiscover information that the Exchange CAS server provides to his Exchange clients can contain the URL address that point “to himself” or URL address of other or additional Exchange CAS servers\s that provides a particular web service.
Exchange web service example | The Exchange Availability Service (Free\Busy time) service.
The Exchange Availability Service (Free\Busy time) service is a very popular service that is used daily, by many Exchange clients.
Every standard Outlook user is familiar with the simple task of creating a new meeting and using the scheduling assistant for inviting additional participants and view the information about the Free\Busy time of these Exchange recipients.
At first sight, this task seems to be very ordinary and straightforward. In reality, the “final result” in which user A can see the Free\Busy time of user B can be considered as a compound task that requires many steps by the Exchange CAS server\s for providing the necessary result.
The “mechanism” that enables these Exchange services is the Exchange Availability Service (Free\Busy time) service.
To be able to demonstrate the way that the Exchange Availability Service (Free\Busy time) service “works” let’s use the following scenario.
On organization have two physical Active Directory and Exchange sites – New York site and Los Angel’s site.
Alice is a recipient from the New York site, and Bob is a recipient from Los Angel’s site.
In our scenario, Alice needs to invite Bob to a meeting is a particular date and, Alice needs to get information about the availability status of Bob on that specific date.
Alice navigates to her Outlook calendar and, use the scheduling assistant to add Bob’s name to the meeting.
In the following screenshot, we can see an example of the Free/Busy time information that is present when inviting a particular organization user to a meeting.
Let’s assume that everything works correctly and, after a few second; Alice can see that Bob is available on the specific date.
Now let’s take a second look and check what happened “Under the hood” of the Exchange infrastructure.
- Alice, send a request for information about the “Bob Free/Busy time” to her Exchange CAS server (Alice Exchange CAS server located at the New York site).
- The New York Exchange CAS server accesses the local Active Directory to get information about the Exchange mailbox server who host Bob’s mailbox.
- When the New York Exchange CAS server gets the information from the Active Directory, he “understands” that Bob’s mailbox located at another site – the Los Angel’s site.
- The New York Exchange CAS server accesses the local Active Directory to get information, about – who (and if) there is an Exchange CAS server which represents the Los Angel’s site.
- When the New York Exchange CAS server gets the information from the Active Directory, he tries to connect the Los Angel’s site Exchange CAS server.
- The Los Angeles Exchange CAS server accesses the local Active Directory to get information about the Exchange mailbox server which hosts Bob’s mailbox.
- The Los Angeles Exchange CAS server the Exchange mailbox server, which host Bob’s mailbox and ask him for information about the Availability (Free\Busy time) of Bob.
- When the Exchange CAS server of the Los Angel’s site gets the required information, he “forward” the information to the New York Exchange CAS server.
- When the Exchange CAS server at the New York site gets the required information, he “forward” the information to the user (Alice) mailbox.
- Alice sees the information about Bob Free\Busy time in her calendar.
It is important for us to know your opinion on this article