這一章來給大家講Outlook Anywhere，概念比較重要，但是容易混淆，大家得仔細閱讀，仔細區分。
RPC over HTTP/HTTPS
首先得理解，爲何在Exchange 2013當中，僅支持Outlook Anywhere的Outlook MAPI客戶端連接方式。早期版本的MAPI訪問依賴的是TCP的RPC協議直接連接到MBX服務器，而Exchange2013則使用HTTPS封裝的RPC協議。這就意味着，如果你在當前是Ex2007或者Ex2010的環境當中，再增加一臺Ex2013的服務器，那你幾句得在所有的舊版本的CAS服務器上，無論是面向內部的還是外部的，都開啓Outlook Anywhere。
Ex2013 CAS服務器對這塊做出的更改是完全重構了一個新的代理模塊，模塊名應該是Httpproxy.dll，老的是叫RpcProxy.dll。所以Ex2013的CAS已經沒法直接代理RPC的流量。如果一臺Ex2013的CAS收到了HTTPS封裝的RPC流量，那麼他沒法去解封裝，他只認識HTTPS不認識RPC，而是將其代理給任何有rpcproxy.dll模塊的服務器，比如Ex2013的MBX（MBX上有這個模塊）或者是其他的早期版本的CAS服務器。
前面說的比較模糊，讓我們再梳理一遍：
Ex2007或者Ex2010：
在 Exchange 2007 中，對於如 Outlook Web 服務（包括可用性服務和外出設置）及脫機通訊簿下載這樣的 HTTPS 連接，Exchange 和其他 MAPI 客戶端與CAS進行通信，但是對於目錄服務查詢，則直接與MBX上的 MAPI RPC 組件和GC上的 NSPI 終結點進行通信。
在 Exchange 2010 中，這些連接在CAS或CAS Array的 MAPI RPC 連接點上建立，提供統一的訪問體驗。
Exchange 2013：
收到了一個MAPI直接連接，丟棄。
收到HTTPS封裝的RPC連接，查看環境中誰能解開RPC包，代理給它，默認是代理給Ex2013的MBX角色。
在Ex2007或者Ex2010的CAS，啓用Outlook Anywhere可以使用Enable-OutlookAnywhere命令，比如：
Enable-OutlookAnywhere -Server 'CAS01' -ExternalHostname 'CAS01.contoso.com' -ClientAuthenticatioinMethod Basic -SSLOffloading $False -IISAuthenticationMethods Basic,NTLM
注意這裏：如果是混合部署環境，你需要對舊版本的OutlookAnywhere爲IIS身份驗證方法增加一條NTLM。
當然你也可以用Exchange 管理控制檯的嚮導來啓用Outlook Anywhere，我就不多說了。
Exchange2013的Outlook Anywhere已經默認啓用了，你唯一需要做的就是應用一張有效的證書給它，如果不應用證書而是一直使用默認的自簽名證書，你會被客戶端的抱怨給淹了…（額外說一點，這證書用不用在MBX上無所謂，因爲CAS知道這些連接已經被Kerberos驗證過了，所以他只關心這張證書是否能用來加密。）
MAPI over HTTP
隨着時間進步，微軟的產品裏也慢慢的想拋棄掉RPC這種陳舊的連接方式，所以在Exchange 2013 SP1中，提出了（從O365搬來了）MAPI over HTTP這樣一個新功能，也就是說，在這個新特性裏去掉了RPC的封裝層。將MAPI請求直接封裝在HTTP請求/響應組裏，省去了RPC請求/響應的步驟，如下兩幅對比圖。
關於Mapi Over Http我會另外再單獨寫篇文章如何去進行配置啓用。或者等不及的你，可以先看看這個：https://technet.microsoft.com/zh-CN/library/bb123741(v=exchg.150).aspx 自己動手玩一下，我會在隨後的文章裏詳細描述Mapi over Http是怎麼幹活的。
捋一捋捋一捋
OK，聊到最後，還有一些問題要細說一下：
比方我Outlook Anywhere的內外網URL不一樣，在Outlook Anywhere配置的時候，我填的是外部的URL，那麼如果我在內部訪問，他是不是會從公網繞一圈回來？首先，你剛剛安裝好Ex2013，並且配置好了自動發現，你除了去配一下Outlook Anywhere的外部URL，客戶端讓它自動發現並配置profile就行了。其次，如果你一定要手動去玩，OutlookAnywhere沒那麼笨，無論在何種環境下，他會首先去連接內部URL，不信你配好了之後，連接完成，或者這麼說，至少等客戶端經歷過了一次Autodiscover，過會再打開那個Exchange代理設置的窗口，你會發現最上面的代理URL變成了他喵的內部URL，類似下圖一樣：
關於這種現象的解釋請參照這裏：https://support.microsoft.com/zh-cn/kb/2754898/en-us 其實也沒啥解釋，程序行爲使然（但是注意，Outlook客戶端實際上是從Autodiscover信息裏，拿到了內部URL和外部URL這兩個URL，只是在這個窗口裏默認只顯示內部URL！）
再接下來，你要給Exchange申請證書了，裏面要寫一些域名，你不想用通配符，而申請證書的時候，證書裏面不能放入Internet上無法解析的主機名，也就是你的內部URL，怎麼辦？這裏比較容易混淆，內部連接，客戶端到Ex2013的Outlook Anywhere是RPC over HTTP，即不需要用證書建立TLS通道。外部連接，客戶端用的是RPC over HTTPS，需要用證書進行加密；怎麼提交域名，現在明白了嗎？
你最開始的時候都是說的HTTPS，到這裏又變成了HTTP和HTTPS，到底是啥情況？
我再捋一捋，最開始的時候說的是TCP協議類中的HTTP協議，以HTTPS的URL，用SSL加密封裝着RPC流量。現在說的是未經過SSL加密（HTTP）和經過SSL加密的RPC流量，無論是HTTP還是HTTPS開頭，對於CAS來說，他都沒法拆開裏面的RPC包，只能代理給MBX角色。看下邊的圖對比下就明白了：
下圖展示了外部用戶通過公網訪問Exchange 2013，協議HTTP，加密SSL，URL開頭https
下圖展示內部用戶訪問Exchange 2013，HTTP連接，端口全用80，所以你現在應該知道內部用戶訪問用不用證書去驗證DNS名了？（碼打的比較厚，教育網，全是公網IP，沒辦法只能遮着點~）
最後一個問題，我內部URL和外部URL能一樣嗎？當然能，只要保證內部與外部的DNS解析到不同的內外網ip就行。
好了，終於扯完了這一堆，希望能夠給你帶來一些新的知識。下一章我們聊聊命名空間的設計，也就是規劃Exchange2013所使用的一堆DNS命名。
最後照例打一下廣告：
你身邊的 IT 加油站！
也歡迎關注 ITCharger 的微信公衆號，每週更新的文章也會在這上面發佈; 同時也有其他關於微軟私有云技術的文章的分享。
