「深入 Exchange 2013」07 Autodisocver

(安西)

　　微软在Exchange 2007里引入Autodiscover自动发现服务，意图去简化用户配置Outlook与Exchange ActiveSync的过程。Outlook的配置文件虽然可以手动配置，但是从Autodiscover会覆盖手动配置的选项，在你做出一些更改的时候，明显批量的自动下发配置更方便。
　　Autodiscover还负责告诉Outlook当前的邮箱位置信息，Outlook会在与邮箱断开连接之后重新尝试Autodiscover。总而言之，这玩意儿跟Outlook Anywhere一样是个非常重要的，关乎客户端体验的功能。
　　需要注意的是，Autodiscover无法找到那些勾选了“不显示在Exchange地址列表”中的账户，你得手动为这些账户配置Outlook。
　　Outlook 2007/2010/2013，Outlook 2011 for Mac OS X，Outlook RT for Windows RT以及Windows Phone和Apple IOS内置的邮件客户端都支持Autodiscover。每一种客户端都会在其启动的时候进行Autodiscover请求，收到的结果是一份Autodiscover清单（XML格式），里面包含了一堆各种各样对客户端有用的信息。
　　Exchange ActiveSync收到的Autodiscover清单与常规客户端的Autodiscover收到的清单不同，常规的XML文件里包含了几百行信息，但是你可以通过下图里的对话框看到一些主要的信息，也就是“测试电子邮件自动配置“对话框，按住Ctrl接着右键单击屏幕右下角任务栏上的Outlook图标，在弹出来的菜单里选择测试电子邮件自动配置，就可以看到它了。输入你的Email地址和密码，然后勾上Use Autodiscover，如果自动发现成功，那么你显示的结果格式应该和图中大致差不多。可以看到Autodiscover返回的内容里包含了可用性服务的URL，OOF（out of office即外出设置）的URL，OAB脱机地址簿下载的URL，以及UM，还有Outlook调用的EAC(Exchange管理中心)功能的URL，发现没，Outlook 2013里面EAC还是叫ECP哈，其实是一个意思。

　　这份XML里另一个重要的信息就是标示出用户的邮箱目前存放在哪个服务器上，在上图里我们看到，由于该自动发现是针对一台Exchange 2013服务器运行的，所以其返回了该邮箱的GUID@域名作为后端MBX的标示，而不是常规的MBX服务器的URL。在很前面的CAS架构里已经提过，CAS会处理GUID@域名这种形式的服务器标示，并且根据GUID解析到恰当，拥有该邮箱活动副本的MBX。如果该邮箱因为故障转移，或者是状态切换，或者是邮箱移动，导致需要切换连接到新的MBX，Outlook完全不需要重新进行连接，因为他只和CAS进行通信，由CAS负责与MBX的连接。
　　另外，Windows版本的Outlook在失去与Mailbox连接之后会每隔60秒重复一次Autodiscover，其他的客户端也会有类似的重练行为设计。除了所请求的主要邮箱的数据，Autodiscover还会返回公共文件夹邮箱，共享邮箱以及站点邮箱（如果使用到了这些邮箱的话）的信息。
　　Autodiscover过程
　　上述的这些客户端，都遵循着预先设定好的一个过程来进行自动发现请求，我们就来一步一步聊聊这些请求：
　　基本的自动发现过程大致是这样个样子：
　　1、 客户端提供连接凭据，通常是用户的SMTP邮件地址和密码
　　2、 如果客户端加域了，那么客户单回去查询AD，拿到一张服务连接点SCP（Service Connection Point）的清单，下边我会说到这个。一旦查询成功，在这张清单里就会带有Autodiscover的URL。
　　3、 如果SCP查询失败，换句话说，客户端可能没有被加域，或者是连接不上域里的GC。客户端就会发送HTTPS POST到一些预先设定好的URL搭配地址，所谓的搭配地址，是将预先设计好的主机名和XML文件名称与第一步里输入的smtp地址的右边域名部分组合起来，打个比方，如果请求的用户是soda@contoso.com，那么客户端会请求https://contoso.com/autodiscover/autodiscover.svc，然后尝试https://autodiscover.contoso.com/autodiscover/autodiscover.xml。
　　4、 如果第三步，对这些预先设定好的搭配URL也连接失败，客户度会再发个未加密的HTTP GET请求到https://autodiscover.contoso.com/autodiscover/autodiscover.xml，看看是否收到HTTP 302重定向到正确的Autodiscover URL。这条步骤的作用是什么呢，仔细考虑一下在split-brain DNS这样的外部网站访问跟内部网络分隔的环境下，你就明白了。如果重定向成功，Outlook会生成一个警告，以提醒用户当前访问的服务器正在将请求重定向给另外的地址。
　　5、 如果经过上述步骤，客户端依旧没有获得正确的Autodiscover URL，客户端会进行DNS的SRV记录查询，这条记录就是_autodisover._tcp.domain，这个在常规部署过程中一般都会去加上的，我就不多说怎么加了。该条SRV一般会返回Autodiscover服务的终结点的FQDN，（注意这里的描述），如果查询成功，客户端会在返回的FQDN后面加上/autodiscover/autodiscover.xml组合成请求的URL，然后对该URL发起HTTPS POST
　　6、 最后一根救命稻草，如果上述步骤全部失败，客户端就会去查看本地存储的XML配置文件，存放的位置是在HKEY_CURRENT_USER\Software\Microsoft\Microsoft\office\X.0\Outlook\Autodiscover该注册表键值指向的路径，该路径里要事先存放好格式正确的Autodiscover清单文件。（注意注册表路径里的X.0代表Office的版本，比如14.0就是Office 2010,15.0就是Office 2013）。
　　自动发现客户端会受到几种HTTP响应，因为过程中都是HTTP连接请求。最好的情况下就是直接接收到确切的XML清单文件。也可能，前面说过了HTTP 302结果，也就是重定向；还有要求客户端验证的HTTP 401和403错误，以及HTTP 404如果你请求的服务器压根就不是个Autodiscover的终结点。
　　如果你要查看具体是那些URL会被返回给客户端，可以使用下边儿这个命令
Get-ClientAccessServer –AutoDiscoverServiceInternalURL　　通过SCP（服务连接点）访问Autodiscover
　　当你安装好一台新的CAS服务器之后，它自动的会在AD里去注册一个SCP对象。SCP顾名思义就是特定服务或者服务器的服务一个或者多个服务终结点，再说白了就是哪个服务对应哪个URL。SCP一般是被其他的应用所查询调用，一些开发的应用程序同样能注册他们自己的SCP。
　　下边就显示了当某台CAS安装完成之后，在AD中注册的SCP，其中serviceBidingInformation属性就包含了该Exchange Autodiscover SCP的URL。该SCP对象的其他相关属性里还会标识该CAS服务器属于哪个站点。当一台加入域了的客户端可以访问到GC，它就会用用户提供的凭据绑定该GC并进行SCP的查询。
　　（这也就是为什么，在这篇文章里头介绍过的http://sodaxu.blog.51cto.com/8850288/1416955，Exchange2010建立好CasArray之后要将每个服务器的这个属性改成CasArray的FQDN）

　　在多林场景下，SCP的存在也为客户端连接提供了便利性，客户端查询到了SCP返回的URL并进行了连接，实质上就是连接到了CAS，尔后再由CAS进行代理或者是重定向即可。
　　通过预设定的URL访问Autodiscover
　　所谓预设定就是指软件逻辑里已经写死了的，并没有什么花头。为了保证这种预设定的逻辑顺利进行，咱们应该能理解，Outlook客户端会进行URL的特定格式组装，Exchange服务器也会创建对应的Autodiscover的虚拟目录以应对这种请求；所以我们最好不要手动去该虚拟目录的路径。
　　Exchange providers
　　Autodiscover返回的XML清单文件里，包含了一个称为“Exchange providers“的列表，里面的XML条目详细制定了哪些服务可用，应该用什么方法去连接。也可以叫Outlook Providers。Outlook就是靠这一块信息来定位服务，进行各种连接。
　　下边附上一个XML样例的provider块，取自一台Exchange 2013全角色的服务器返回的Autodiscover 信息里，被<Protocol>这个XML元素标签包围。

　　从上边内容里可以看到，provider涵盖了Exchange服务器的DN，邮箱数据库的DN，以及用户邮箱的GUID。还包括了各种服务的URLs，也就是咱们在前边“测试连接：对话框里看到的内容。
　　一份完整的Autodiscover XML文件里可能包含多个<Protocol>，他们的用途分别描述如下：

• 　　EXCH类型的provider块提供了内部的Ex2007和Ex2010服务信息。
  
• 　　EXPR块提供了Ex2007和Ex2010对外部的Outlook Anywhere连接信息
  
• 　　WEB setting块提供了用户使用的Outlook Web Access的最佳地址
  
• 　　EXHTTP块则是Exchange 2013里的新增块，它会取代之前的EXCH和EXPR块为所谓的新式的客户端提供服务（指Outlook 2010 SP1或者更新版本）。EXHTTP块由Exchange 2013的CAS生成，包含各种已经开启的服务的内部与外部的连接信息。一般会存在两个EXHTTP块，客户端会始终先尝试第一个EXHTTP块，对应的是各种已开启的服务的内部连接信息，然后才会去尝试第二个EXHTTP快。这里你就能明白，为何Outlook Anywhere会始终先去连接内部的URL了吧？
  

　　在混合环境下，你可能看到那些仍旧存放在Ex2010 MBX里的邮箱用户依旧会收到Exchange 2010样式的Autodiscover数据，哪怕他们将请求发送给了Ex2013的CAS，Ex2013的CAS只是简单的将Ex2010用户的请求代理给Ex2010的CAS，然后由Ex2010的CAS生成Autodiscover XML清单，再经由Ex2013的CAS返回给客户端。我们在下一节中会详细说说Ex2013的代理和重定向。
　　Autodiscover中的配置信息更新
　　当客户端使用Autodiscover成功连接到了Ex2013的MBX之后，客户端会缓存收到的这些通过Autodiscover收到的配置数据信息。尔后，客户端会对这些信息进行update，以确保获取最新的邮箱设置，这些update包含以下内容：

• 　　OOF信息
  
• 　　通过其他用户的日历获知的可用性信息
  
• 　　OAB下载位置
  
• 　　UM信息
  
• 　　共享邮箱和站点邮箱的可用性与位置信息
  
• 　　公共文件夹邮箱的可用性与位置信息
  
• 　　客户端下一次连接查询的服务器名。
  

　　Outlook客户端每60分钟重新请求一次Autodiscover数据，在无法连接到MBX服务器的情况下，会每5分钟进行一次尝试直到成功连接或者你关掉Outlook。你也可以通过下面的命令来修改autodiscover的缓存生命周期（重试时间），以小时为单位。
Set-OutlookProvider –id ‘msExchAutoDiscoverConfig’ –TTL 3　　OK，对自动发现服务咱们就聊到这里，跟Outlook AnyWhere一样也是非常重要的内容，不知不觉就扯了这么些。下一章就来说说简单的，Exchange 2013的代理和重定向到底是咋回事。
　　最后照例打一下广告：

　　http://www.itcharger.com/
　　你身边的 IT 加油站！
　　也欢迎关注 ITCharger 的微信公众号，每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。