the importance of exchange 2013 cas in exchange 2013 coexistence | part 1/2 | 2#23

of 35 | Part 02#23 | The importance of Exchange 2013 CAS in Exchange 2013

coexistence environment | Part 1/2

Written by Eyal Doron | o365info.com | Copyright © 2012-2015

THE IMPORTANCE OF EXCHANGE 2013 CAS

IN EXCHANGE 2013 COEXISTENCE

ENVIRONMENT | PART 1/2 | 2#23

The essence of the protocol connectivity flow in Exchange environment is the

Exchange CAS server. We can relate to the Exchange CAS server is the Gatekeeper

http://o365info.com/the-importance-of-exchange-2013-cas-in-exchange-2013-coexistence-environment-part-12


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/




that stand between Exchange client and all the rest of the Exchange infrastructure.

For this reason, it is very important that we get a better understanding of the “what

is the Exchange CAS server”, what does the Exchange CAS server “do” and what how

the Exchange CAS 2013 operate in Exchange 2013 coexistence environment.

The current article and the next article (The importance of Exchange 2013 CAS in

Exchange 2013 coexistence environment | Part 2/2 ) will be dedicated to the

description of Exchange 2013 CAS role in Exchange 2013 coexistence environment.

Exchange 2013 CAS server as a “Smart Router”

The simplest term that I can use for describing the essence of the role of the

Exchange 2013 CAS server, in an Exchange 2013 coexistence environment is: Smart

Router.

I use the term “smart”, because viruses a standard router, which is responsible for

routing a packet from network A to network B, Exchange 2013 CAS needs to handle

much more complicated routing decisions.

The main responsibility of Exchange 2013 CAS in Exchange 2013 coexistence

environment is “direct” Exchange legacy clients (Exchange 2007/2010) to their







http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-CAS-2013-as-a-Gatekeeper.jpg




destination.

The responsibility of “redirecting the Exchange legacy client” doesn’t mean that the

Exchange 2013 CAS will provide the information or the services by himself but

instead,

1. Get the information from “other resources” such Exchange 2013 Mailbox server

or legacy Exchange CAS servers (Exchange 2007/2010 CAS)

2. Redirect legacy Exchange clients to the “right place”. For example, redirect

Exchange 2007 OWA client to the Exchange 2007 CAS.

Note – In a former version of Exchange such as: Exchange 2007 and Exchange 2010

the Exchange CAS server role includes additional responsibilities such as: rendering

the protocol data, manage Exchange web services, manage the Autodiscover

service and more.

So now, a couple of questions could appear in our mind:





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-CAS-server-as-a-Smart-Router.jpg




Q1. When we relate to Exchange 2013 CAS is a “Smart Router”, what is the “thing”

that he need to write?

Q2: What is the “source of information” that enables Exchange 2013 CAS to get the

“right routing decision” or the “appropriate response” that he needs to provide to

his Exchange clients?

Q3. What does the “information” that is provided to Exchange 2013 CAS includes?

Q4. What is so “smart” in the process that is implemented by the Exchange 2013

CAS?

A1: the “things” the Exchange 2013 CAS needs to route are:

Exchange client’s requests for: access the data stored in their mailbox.

Exchange client’s requests for: Autodiscover information

Exchange client’s requests for: Exchange web services

Note – In Exchange environment, Exchange client will never have a direct access to

his mailbox, the only way that Exchange client can use to “get their mailbox

content” is via the Exchange CAS server.








A2: The “secret source of information” that provides the Exchange 2013 CAS the

required “data” is the Active Directory. The Active Directory stores information

about all the Exchange infrastructure.

The “information” about the Exchange infrastructure creates a very clear map

that describes each of the existing Exchange server and very detailed information

about each of this Exchange server, such as article series: the Exchange role,

vision, physical location (Active Directory site), information about an optional

public availability (external URL) and much more.

The other part of the information related to the Exchange client’s meaning, what

is the exact location of each of the Exchange user mailboxes or in other words?

Who is the Exchange Mailbox server who hosts an active copy of the user

mailbox and what is the Exchange Mailbox server version?

Based on this information, Exchange 2013 CAS can implement the “correct

decision” when he accepts request form Exchange mail clients.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/the-thing-that-the-Exchange-CAS-server-need-to-route.jpg




In the following diagram, we can see the “flow” that is implemented in Exchange

environments.

Exchange mail client addresses the Exchange 2013 CAS (Number 1).

Exchange 2013 CAS queries the Active Directory looking for information

(Number 1).

The Active Directory reply with the required information (Number 3).

Based on the information that he got from the Active Directory, Exchange 2013

CAS can decide about the “next step” (Number 4).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-CAS-server-Decision-Making-Process.png




A3: in an Exchange 2013 coexistence environment, when the Exchange legacy client

addresses the Exchange 2013 CAS, the most important information that Exchange

2013 CAS needs to get from the Active Directory is the version of the Exchange

legacy client.

The information about the Exchange legacy version is mandatory because based on

this information Exchange 2013 CAS will know how to handle the request or what

“root path” he should use.

The “order” in which the Exchange 2013 CAS “process” the information that he got

from the Active Directory, could be described as “reverse engineering”.

The first “information item” that Exchange 2013 CAS needs are:





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-Exchange-2013-CAS-secret-spring-of-information.png




The name of the Exchange database that host the specific user mailbox.

The name of the Exchange Mailbox server who is “connected” to the specific

database.

The version of the Exchange Mailbox server, such as: Exchange version 2007,

2010 or 2013.

The Active Directory site name in which the Exchange Mailbox server is located.

Exchange 2013 CAS needs to know what the Exchange Mailbox server version

because, based upon this information, the Exchange CAS server will choose the

“correct” routing path. For example: in case that the Exchange CAS server who

queries the Active Directory is Exchange 2013 CAS server and the Exchange Mailbox

server who hosts the user mailbox is Exchange 2010 Mailbox server, the Exchange

2013 CAS server will need to “find” an available Exchange 2010 CAS server and

proxy for him the Exchange client communication request.

The Exchange CAS server needs to know what is the Active Directory site name in

which the Exchange Mailbox server is located because, based upon this information

he will know if he needs to proxy the communication request to local Exchange CAS

server, proxy the request to “remote Exchange CAS server (Exchange CAS server on

the “other Active Directory site”) or maybe, redirect the Exchange client to his

destination Exchange server.








A4. The answer to the question: “why I use the term “smart”, for describing the

process that is implemented by the Exchange 2013 CAS” is: that I really think that

the process that is implemented by the Exchange 2013 CAS “smart”.

The Exchange CAS server needs to be able to get the required information, draws a

picture or a map, which includes the full path from the source to the destination

and decides what is the most appropriate “routing decision” for a specific scenario.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-information-details-that-are-required-for-the-Exchange-CAS-server.png




Configuring Exchange CAS 2013 server as a

“Focal Point”

One of the most unclear concepts and at the same time, the most essential concept

for Exchange 2013 coexistence environment is the concept that I described as:

Exchange 2013 as a focal point.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-coexistence-environment-client-protocol-connectivity-flow-.png




In Exchange 2013 coexistence environment, we are redirecting the “spotlight” from

the existing Exchange infrastructure that now becomes the “legacy Exchange

infrastructure” and aims the “spotlight” to the Exchange 2013 infrastructure, or if





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-as-a-focal-point.jpg




we want to be more accurate to the Exchange CAS 2013 server.

The term: Exchange 2013 CAS should be configured article series a focal point is

“translated” into two meanings:

1. The Exchange 2013 CAS is becoming the focal point for the Exchange

Autodiscover infrastructure. Every Exchange client (native and legacy Exchange

clients), will “relate” to the Exchange 2013 CAS is the Autodiscover Endpoint.

Exchange 2013 CAS will serve as an Autodiscover Endpoint for internal + external

Exchange clients.

2. Exchange client that needs access to their mailboxes – native Exchange clients

(Exchange 2013) and legacy Exchange clients (Exchange 2007/2010), will need to

connect to the Exchange 2013 CAS when they need to access their mailbox data.

In most of the scenarios, the Exchange 2013 CAS serves will Proxy the requests

to the appropriate Exchange server, such as Exchange 2013 Mailbox server in a

scenario of Exchange 2013 client or legacy Exchange CAS server (Exchange CAS

server 2007/2010) in a scenario of Exchange legacy clients.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Switching-the-spotlight-from-existing-legacy-Exchange-infrastructure-.jpg




Switching the primary namespace to Exchange CAS 2013

infrastructure

When we say that “Exchange clients connect Exchange 2013 CAS”, Exchange clients

address the Exchange 2013 CAS by using a “name” (FQDN, if we want to be more

precise).

The naming convention, which we use for “publishing” the Exchange infrastructure

for internal and external Exchange client can be described as the: primary

namespace.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-scenarios-in-which-Exchange-2013-CAS-server-considered-as-a-focal-point.png




Technically speaking, the Exchange internal primary namespace can be different

from the external primary namespace or identified and the mechanism that we use

for “publishing” the primary namespace in the internal network is different from the

mechanism that we use for publishing the primary namespace in the public

network.

The main “idea” is that all the Exchange clients (native and legacy) should be able to

locate + connect the Exchange 2013 CAS using the primary namespace.

When we add Exchange CAS 2013 into existing Exchange infrastructure, the primary

namespace will need to point to the “new Exchange 2013 infrastructure” instead of

the existing Exchange infrastructure such as: Exchange 2007, 2010 CAS servers.

In other words, we will need to “un-plug” all the existing pointers to the Exchange

legacy infrastructure and update existing pointers to point to the “new Exchange

2013 infrastructure”.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Pointers-to-the-new-Exchange-2013-infrastructure.jpg




In the following diagram, we can see a representation of this concept. In the

following scenario, the primary namespace

is: mail.o365info.com and autodiscover.o365info.com

Before we add the Exchange 2013 CAS to the existing Exchange infrastructure,

the primary namespace was pointing to the Exchange 2010 CAS server.

After we add the “new Exchange CAS 2013 server” to the existing Exchange

infrastructure (this is the actual meaning of the Exchange 2013 coexistence

environment), we will need to “repent” the primary namespace of the Exchange

CAS 2013 server.








Exchange mail client requests for accessing mailbox content

In an Exchange environment, Exchange clients cannot access directly their mailbox,

but instead, they need to address the Exchange CAS server who will proxy their

request to the appropriate Exchange Mailbox server or redirect them to the

appropriate Exchange CAS server (such as the scenario of Exchange 2007 OWA

clients).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-2010-coexistence-environment-switching-the-pointers-to-Exchange-2013-CAS.png




A reasonable, logical assumption could be that each of the Exchange client versions

should connect with the Exchange CAS server from the same version.

For example, Exchange 2010 client will need to address Exchange 2010 CAS, etc.

Theoretically, this assumption could seem to write but, in an Exchange 2013

coexistence environment, this assumption is not correct!

All the Exchange clients: Exchange 2013 native client + Exchange legacy clients

should “know” and communicate only with the Exchange 2013 CAS server.

In case that the Exchange client is: “Exchange 2013 client”, the Exchange 2013

CAS will “route” (Proxy) the request to the Exchange 2013 Mailbox server.

In case that the Exchange client is: “legacy client” (Exchange 207\2010 clients), the

Exchange 2013 CAS will “route” (Proxy) the request, to the legacy Exchange CAS

server infrastructure (Exchange 2007\2010 CAS server) or other routing decision

such as: proxy the request to Exchange 2013 Mailbox server in a scenario of

Exchange 2007 client that requests Autodiscover information.








Reflections, questions & Answers about

Exchange 2013 coexistence

Q1: Does the requirement for: “configuring Exchange 2013 CAS as a focal point” is

mandatory?

Q2: Why do I need to implement the configuration of: “Exchange 2013 as a focal

point”?

Q3: In the current article, the term “pointers” mention a couple of times, what is the

meaning of these “pointers”?

There are a couple of optional answers for this question:





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-clients-and-legacy-Exchange-clients-address-the-Exchange-2013-CAS.png




A1: the answer is “Yes”

A2: There are a couple of optional answers for this question:

1. Legacy Exchange infrastructure as a temporary infrastructure

The most important thing that we need to remember regarding the Exchange 2013

coexistence environment, is that the basic assumption is that “someday” (in the

near or far future), we will completely remove the legacy Exchange infrastructure

after we successfully have migrated all the legacy mailboxes to the “new Exchange

infrastructure” (Exchange 2013 infrastructure in our scenario).

For this reason, we are implementing a configuration in which everything will be

“pointed” or “redirected” to the Exchange 2013 infrastructure.

Exchange 2013 CAS is the element that “decide” what to do with the legacy

Exchange client communication request (proxy or redirect these requests to the

legacy Exchange infrastructure) and, in the day that we will complete the migration

process to the “new Exchange 2013 environment”, there will be no “left overs” that

point or direct Exchange client to the “old\Legacy Exchange infrastructure”








2. Exchange 2013 and the backward compatibility

The concept of “backward compatibility” in Exchange environment is very simple to

understand: new Exchange version “knows how to talk” to be former\legacy

Exchange versions but not vice versa.

For example: Exchange 2013 knows how to accept requests from a variety of

Exchange clients such as: Exchange 2007, 2010 and Exchange 2013 and know how

to “reply” to this request or what to do with the Exchange client communication

requests.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Legacy-Exchange-infrastructure-as-a-temporary-infrastructure.png




Contrary the backward compatibility concept, older versions of Exchange CAS

servers are not fully compatible with a “new Exchange client”

For example: theoretically, Exchange 2007 server can provide Autodiscover services

to the Exchange 2013 clients (an Exchange client that their mailbox is hosted on

Exchange 2013 Mailbox server) but the information will be partial and will not

include additional information that can provide only by Exchange 2013 CAS server.

Update existing pointers to point to the “new

Exchange 2013 infrastructure”

The implementation of the concept which I described as: Using the Exchange 2013

as a focal point is done by “removing the pointer” that exist in the legacy Exchange

infrastructure and update these pointers to the “new Exchange 2013 infrastructure”

or we want to be more accurate: to the new Exchange 2013 CAS server.

There are a couple of “translations” to the term pointers:





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-and-the-backward-compatibility.jpg




1. Autodiscover infrastructure

When we implement Exchange 2013 coexistence environment, we need to “re-

paint” the internal and the external Autodiscover infrastructure to the “Exchange

2013 CAS server” (the existing Exchange infrastructure includes “pointers” to the

Exchange 2010 or Exchange 2007 infrastructure).

In the following diagram, we can see an example of the process which I describe as:

“Removing the pointer” that exist in the legacy Exchange infrastructure.

In our scenario, the organization uses an Exchange 2010 infrastructure. The “focal

point” of this infrastructure is the Exchange 2010 CAS server. The Autodiscover

services for external and internal Exchange clients will be provided by the Exchange

2010 CAS server.

2. Outlook infrastructure

The Exchange 2010 CAS server will serve as a focal point for additional services

such as for Outlook mail client. Each of the Exchange clients that use Outlook, will

relate to the Exchange 2010 CAS server as an: RPC Endpoint.

When we use Exchange 2013 coexistence environment, we add to the existing

Exchange environment the Exchange 2013 infrastructure. Now we have two types

of Exchange clients: Exchange 2010 clients and Exchange 2013 clients.

Note – the term Exchange 2010 clients relate to users whom their mailbox is hosted

on Exchange 2010 Mailbox server.

Exchange 2013 coexistence environment, we define the Exchange 2013 CAS server

as a focal point for the 2010 clients and Exchange 2013 clients. Each of the

“standard Exchange services” such as: Autodiscover, Outlook, will point to the

Exchange 2013 CAS server.

When the Exchange 2013 CAS server gets a communication request from Exchange

clients, he will decide “what to do” with the request based upon the Exchange

client’s version.








The term: “Exchange CAS 2013” server

In the following article series, will we mention the term: “Exchange CAS 2013 server”

hundreds of times. For this reason, it’s important to clarify this term.

Q1: When we say: Exchange CAS 2013 server, what do we mean?

Do we mean Exchange Mailbox server or Exchange CAS 2013 server?

A1: Technically, the term: “Exchange CAS 2013 server” relate to the booth of the

Exchange server roles, and Exchange 2013 architecture is based on the basic

assumption that each of Exchange CAS 2013 server is holding both roles: Exchange

Mailbox server + Exchange CAS server).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Verify-that-the-pointers-are-set-to-the-Exchange-2013-infrastructure.png




Most of the time, when we use the term: “Exchange 2013 server”, the meaning is

“Exchange CAS 2013 server”. In the Exchange 2013 coexistence environment, the

“hero” or the element that makes the noise is the Exchange 2013 CAS server.

In the Exchange 2013 architecture, the Exchange 2013 Mailbox server has very

important and crucial responsibilities, but most of the time, he remained in the

background.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-meaning-of-Exchange-CAS-2013-server.png




Exchange 2013 CAS | Physical versus logic

implementation

An additional important concept that I would like to emphasize is the concept of the

Physical versus logic implementation of the Exchange 2013 CAS.

We will not get into a detailed description of the history of Exchange CAS server

Architecture and the specific charters of the “legacy Exchange CAS server

infrastructure” but briefly mention that in former versions of Exchange server, such

as: Exchange 2007 and Exchange 2010 the Architecture of “Exchange server role”

was based on the following concepts”:





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-Mailbox-server-remained-in-the-background.jpg




1. A very clear separation of Exchange roles. Each of the Exchange “role” is

dedicated to a very specific task or set of task

2. The best practice or the recommendation was to implement a physical Exchange

role separation. The simple meaning is: allocate a dedicated physical server for

each of the Exchange roles and in case of multiple Active Directory sites, a

dedicated Exchange server in each of the sites.

Regarding the “Exchange 2013 CAS Architecture” we can see that the Architecture

logic is almost the opposite to the Architecture concepts of Exchange CAS legacy.

Exchange 2013 CAS Architecture is based on the following concept:

1. Minimize significantly the number of Exchange server roles – in the Exchange

2013 architecture, there are only two Exchange server roles versus five server

role in the Exchange CAS legacy architecture.

2. The best practice or the general recommendation is not to use a separated

physical server for each of the Exchange server roles, but instead to “bind” or

“attach” the two different Exchange 2013 server roles (Exchange CAS server +





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-CAS-server-legacy-Architecture.jpg




Exchange Mailbox server) in one physical server.

My point is that in an Exchange 2013 environment and in the Exchange 2013

coexistence environment, we try to explain the logic of a specific client protocol

connectivity flow or a specific process flow, I relate to the two Exchange 2013 server

role separately. For example: the Exchange CAS server proxy the request to the

Exchange 2013 Mailbox server.

Logically, this is the exact description of what Happens in a specific client protocol

connectivity flow, but technically or physics, the basic assumption is that one

Exchange server holds the two different Exchange roles.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-Architecture.jpg




Exchange CAS server single server or an array?

The term: “Exchange CAS server” is used for representing the specific Exchange role

and his part in the client protocol connectivity flow.

The implementation of Exchange CAS server can be implemented as a single

Exchange CAS server or as an array of Exchange CAS servers.

Despite the fact that the physical implemented of the “Exchange CAS server” can be

implemented in different ways, in our scope the physical implementation is not

important or not related because when we describe the client protocol connectivity

flow we describe the “logic flow” of the communication channel. When we say that

Exchange mail client address Exchange CAS server, it doesn’t matter of the

Exchange CAS server = single server or an array of Exchange CAS servers that are

“represented” by load balancing.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-CAS-Physical-implementation-versus-logic-implementation.png




The same logic is implemented when using the term Exchange 2010 CAS server.

The “translation” of this term, can be: a single Exchange 2010 CAS or an array of

Exchange 2010 CAS that is represented by the load balancer.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-meaning-of-Exchange-CAS-2010-server-01.png




Exchange 2013 coexistence project | Phases

and Life cycle

Along this article seriously, we will mention the term: Exchange 2013 coexistence

environment, tens and perhaps hundreds of times, so it looks like we should spend

some time for a brief description of this term and of the “Exchange 2013

coexistence environment – Life cycle”

Technically, the term “Exchange 2013 coexistence” can be implemented in many

ways. The specific “way” that the Exchange 2013 coexistence environment will be

implemented depends on the organization physical infrastructure, the specific

organization needs, etc.

Although we can “build” the Exchange 2013 coexistence environment in many ways,

there are a couple of basic concepts that will always be implemented regardless the

specific implementation that was selected.

In the following diagram, we can see the workflow logic that will be implemented on

an Exchange 2013 coexistence environment project.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/The-meaning-of-Exchange-CAS-2010-server-02.png




To be able to demonstrate the implementation of Exchange 2013 coexistence

environment, let’s based on the following scenario:

An international organization that has three sites.

The “headquarters site” – New York site, include a “mixture” of Exchange server

version: Exchange 2007 + Exchange 2010.

Additional company sites are: Madrid site and Los Angles site.

Madrid site – include Exchange 2007 infrastructure.

Los Angles – include Exchange 2010 infrastructure.

The result of the Exchange 2013 coexistence project is: complete the migration

process to the Exchange 2013 environment and decommission all the Exchange

legacy environments.

Step 1: Add the Exchange 2013 infrastructure in the main corporate site

In this step, we add the “new Exchange 2013 infrastructure” to the main corporate

site and + update the primary namespace to “point” to the Exchange 2013

infrastructure (Exchange 2013 CAS).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-coexistence-environment-project-The-basic-flow.png




The additional site (Madrid site and Los Angles site) will continue to use the “legacy

Exchange infrastructure” (Exchange 2007 and Exchange 2010).

Exchange clients from all the company sites: the main corporate site (New York site)

and Exchange client from the rest of the company site (Madrid site and Los Angles

site) will address the Exchange 2013 CAS in the main corporate site as their

Autodiscover Endpoint.

After we complete all the required configuration setting that relate to the “new

Exchange 2013 infrastructure”, the next step will be: migrating all of the user’s

mailboxes in the main corporate site from the Exchange legacy infrastructure to the

Exchange 2013 infrastructure.

Step 2: Adding the Exchange 2013 infrastructure to the reset of the Active

Directory sites

In this step, we continue the process of “distributing” the Exchange 2013

infrastructure in the rest of the company site (Madrid site and Los Angles site). Note





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-02/Exchange-2013-coexistence-project-phase-1.jpg




that the Exchange 2013 infrastructure is added in parallel with the existing

Exchange legacy infrastructure.

For example, the Exchange 2013 that we add to Madrid site will coexist with the

Exchange 2010 infrastructure.

The next step will be: migrating all the user’s mailboxes from the Exchange legacy

infrastructure to the Exchange 2013 infrastructure.

Step 3: Removing the legacy Exchange infrastructure

And the last step is to remove or decommission the Exchange legacy infrastructure.









The Exchange 2013 coexistence article series index page





http://o365info.com/the-exchange-2013-coexistence-article-series-index-page

http://o365info.com/exchange-2013-coexistence-environment-and-client-protocol-connectivity-flow-the-prefix

the importance of exchange 2013 cas in exchange 2013 coexistence | part 1/2 | 2#23

Documents