"Deep Exchange 2013"05 Outlook Anywhere

This chapter is for you to talk about Outlook Anywhere, the concept is more important, but easy to confuse, we have to read carefully, carefully distinguish.

RPC over Http/https

The first step is to understand why the Outlook MAPI client connection for Outlook Anywhere is supported only in Exchange 2013. Earlier versions of MAPI access relied on TCP's RPC protocol to connect directly to the MBX server, while Exchange2013 used the HTTPS encapsulated RPC protocol. This means that if you add a Ex2013 server to your current Ex2007 or Ex2010 environment, you'll have to turn Outlook Anywhere on all of the older CAS servers, whether internal or external, on the other.

Ex2013 CAS server changes made to this block are completely refactored a new proxy module, the module name should be Httpproxy.dll, the old is called RpcProxy.dll. So Ex2013 's CAs have been unable to directly proxy RPC traffic. If a Ex2013 CAS receives RPC traffic from the HTTPS package, then he can't unpack, he only knows HTTPS does not know RPC, Instead, it proxies it to any server that has a Rpcproxy.dll module, such as EX2013 's MBX (which has this module on MBX) or other earlier versions of the CAS server.

The earlier said is rather vague, let us comb again:

Ex2007 or Ex2010:

In Exchange 2007, Exchange and other MAPI clients communicate with CAs for HTTPS connections such as Outlook WEB services (including availability services and out-of-Office settings) and offline address book downloads, but for directory service queries, they are directly related to the MBX The MAPI RPC component communicates with the NSPI endpoint on the GC.

In Exchange 2010, these connections are established on the MAPI RPC connection point of the CAs or CAS array, providing a unified access experience.

Exchange 2013:

Received a MAPI direct connection, dropped.

Receive an RPC connection to the HTTPS package, see who can unlock the RPC package in the environment, delegate to it, and by default is the MBX role that the proxy gives to Ex2013.

In CAs Ex2007 or Ex2010, enable Outlook Anywhere to use the Enable-outlookanywhere command, such as:

Enable-outlookanywhere-server ' CAS01 '-externalhostname ' CAS01.contoso.com '-clientauthenticatioinmethod Basic- Ssloffloading $False-iisauthenticationmethods BASIC,NTLM

Note here: If you are in a hybrid deployment environment, you need to add an NTLM to the IIS authentication method for older versions of Outlookanywhere.

Of course you can also use the Exchange Management Console Wizard to enable Outlook Anywhere, and I won't say much.

Exchange2013 Outlook Anywhere has been enabled by default, the only thing you need to do is to apply a valid certificate to it, if you do not apply the certificate, but always use the default self-signed certificate, you will be the client's complaints flooded ... (Needless to say, this certificate does not matter on MBX, because CAs knows that these connections have been authenticated by Kerberos, so he only cares if the certificate can be used for encryption.) ）

MAPI over HTTP

As time progresses, Microsoft's product also slowly want to discard RPC This old connection way, so in Exchange SP1, proposed (moved from O365) MAPI over HTTP such a new feature, that is, in this new feature removed the RPC encapsulation layer. The MAPI request is encapsulated directly in the HTTP request/Response group, eliminating the RPC request/response steps, as shown in the two contrast graphs below.

650) this.width=650; "height=" "title=" clip_image001 "style=" border:0px; "alt=" clip_image001 "src=" http:/ S3.51cto.com/wyfs02/m00/6e/f8/wkiol1wnmvosrhydaaepdccfjoi676.jpg "border=" 0 "/>

650) this.width=650; "height=" 273 "title=" clip_image002 "style=" border:0px; "alt=" clip_image002 "src=" http:/ S3.51cto.com/wyfs02/m00/6e/fc/wkiom1wnmtaywzooaad26khexjw678.jpg "border=" 0 "/>

About MAPI over HTTP I will also write a separate article on how to configure Enable. Or can't wait for you, you can take a look at this: https://technet.microsoft.com/zh-CN/library/bb123741 (v=exchg.150). aspx Play it yourself, I'll describe in detail how MAPI over HTTP works in a subsequent article.

To smooth out a stroke

OK, talk to the end, there are some questions to elaborate:

For example, my Outlook Anywhere intranet URL is not the same, when the Outlook Anywhere configuration, I filled out the external URL, then if I was in the internal access, he will be a circle back from the public network? First, you've just installed Ex2013, and you've configured auto-discovery, and instead of matching the external URL of Outlook Anywhere, the client lets it automatically discover and configure the profile. Second, if you must go to play manually, outlookanywhere not so stupid, regardless of the environment, he will first to connect the internal URL, do not believe that you have been well, the connection is complete, or so, at least the client has experienced a autodiscover, After you open the window for the Exchange agent settings, you'll see that the top proxy URL becomes his meow internal URL, similar to the following:

650) this.width=650; "height=" 251 "title=" clip_image003 "style=" border:0px; "alt=" clip_image003 "src=" http:/ S3.51cto.com/wyfs02/m01/6e/f8/wkiol1wnmvpih_k8aafsx4dyyzq021.jpg "border=" 0 "/>

For explanations of this phenomenon, please refer to here: https://support.microsoft.com/zh-cn/kb/2754898/en-us In fact, there is no explanation, the procedural behavior (but note that The Outlook client is actually from the Autodiscover information, get the internal URL and the external URL of the two URLs, but in this window only the default display of internal url! ）

Next, you want to give exchange to apply for a certificate, the inside to write some domain name, you do not want to use wildcard characters, and when you request a certificate, the certificate can not be placed on the Internet cannot resolve the host name, that is, your internal URL, how to do? It is easier to confuse the internal connection, the client to Ex2013 Outlook Anywhere is RPC over HTTP, that is, the TLS channel does not need to be established with a certificate. External connection, the client is RPC over HTTPS, need to be encrypted with a certificate, how to submit the domain name, now understand?

You start with the HTTPS, and here it becomes HTTP and HTTPS, what is the situation?

I'm going to go through it. At the very beginning, the HTTP protocol in the TCP protocol class is used to encapsulate the RPC traffic with SSL encryption in the URL of https. Now is the non-SSL encryption (HTTP) and SSL-encrypted RPC traffic, whether HTTP or HTTPS at the beginning, for CAs, he can not open the inside of the RPC packet, only proxy to the MBX role. Look at the comparison below to see the following figure:

Shows external users accessing exchange 2013 via public Network, protocol HTTP, encryption Ssl,url start HTTPS

650) this.width=650; "height=" 398 "title=" clip_image004 "style=" border:0px; "alt=" clip_image004 "src=" http:/ S3.51cto.com/wyfs02/m01/6e/fc/wkiom1wnmtareuccaae4tzbvj_u092.jpg "border=" 0 "/>

Show internal user access to Exchange 2013,http connections, ports are all 80, so you should now know that internal user access uses no certificates to verify DNS names? (code dozen of relatively thick, education network, all public network IP, no way can only cover the point ~)

650) this.width=650; "height=" 347 "title=" clip_image005 "style=" border:0px; "alt=" clip_image005 "src=" http:/ S3.51cto.com/wyfs02/m02/6e/f8/wkiol1wnmvsgevjoaags6cijhdm957.jpg "border=" 0 "/>

650) this.width=650; "height=" 394 "title=" clip_image006 "style=" border:0px; "alt=" clip_image006 "src=" http:/ S3.51cto.com/wyfs02/m02/6e/fc/wkiom1wnmtfbi_mtaakvgzinl6m513.jpg "border=" 0 "/>

Last question, can my internal URL and external URL be the same? Of course, as long as the internal and external DNS resolution to a different network IP on the line.

Well, finally finished the pile, hoping to bring you some new knowledge. In the next chapter, we'll talk about the design of namespaces, which is a bunch of DNS naming used by planning Exchange2013.

This article is from the "Castamere Rainy season" blog, be sure to keep this source http://sodaxu.blog.51cto.com/8850288/1666118

"Deep Exchange 2013"05 Outlook Anywhere