「深入 Exchange 2013」08 代理、重定向、共存

回顾一下以前讲过的东西,CAS并不直接为客户端提供邮箱连接,而是以两种方式来保证客户端连接到正确的MBX:代理或和重定向。在代理连接当中,CAS接收客户端连接并且转发给恰当的服务器;在重定向连接当中,CAS仅仅是回应客户端一个恰当的服务器的FQDN以让客户端再次发起连接。

在Exchange2013的环境中,CAS只在少数几种情况下才会进行重定向动作。这是由于重定向迫使客户端进行再次连接,这种情况不是所有的客户端种类都可以接受的。

代理

CAS代理动作在Ex2010与Ex2007被设计的略微复杂,在Ex2013里已经简化不少,但是对于一些涉及到边界的问题,比方说流量需要被代理给下层的Exchange服务器或者是穿过复杂的AD站点拓扑架,碰到这些情况的时候还是得认真考虑一下。

首先,有两件事情在CAS代理任何东西之前就得保证完成,一是接收了初始连接的那台CAS(这里称为初始CAS)必须对客户端进行认证,然后它还得决定哪一台MBX正拥有该邮箱的活动数据库副本。

这两步完成之后,初始CAS开始代理流量。最简单的代理动作:IMAP与POP,CAS总可以在不考虑目标MBX的Exchange版本的情况下代理这两种流量。

其他的一些Exchange协议,包括Outlook Anywhere ,Autodiscover ,Outlook Web App ,Exchange ActiveSync(EAC),可用性服务和Exchange Web Service。它们通过HTTP或者HTTPS承载,CAS不关心这些协议流量中的内容,只关心这些协议的目标终结点位于何处。比如:Ex2010上有一个客户端邮箱,发起了一次Autodiscover请求,该请求被Ex2013的CAS收到,然后2013 CAS代理该请求给Ex2010的CAS,Ex2010 CAS返回Ex2010 MBX位于何处,答复给Ex2013的CAS,然后Ex2013 CAS再答复客户端这些Autodiscover信息。

上述的是Ex2010与Ex2013的共存代理情况,再来看看Ex2007与Ex2013的共存情况,当前Ex2013 CAS收到了来自客户端的Autodiscover 请求,该客户端的邮箱位于Ex2007 的MBX上,Ex2013 CAS会代理这个链接给 Ex2013的MBX,而非Ex2007的,这是由于Ex2013 MBX有特殊的姿势(代码)来handle Ex2007的Autodiscover 请求。

注意我们上面讨论的是Autodiscover 的代理方式,混合环境下Outlook Anywhere的代理方式就比较常规了,如何常规,配合我前面聊过的Outlook Anywhere三个版本的区别自己想想吧。

如果在当前的AD拓扑中有多台Ex2010 CAS可以当作代理流量的目标,那Ex2013 CAS又是如何来得知这些服务器都是可以正常运转的呢。我们一步步来看,最开始的时候,Ex2010就会查询AD获得一张所有Ex2007或者Ex2010CAS的服务器表。然后向这些表中的服务器的每一个协议的虚拟目录发一个 HTTP HEAD请求,这个请求每60秒发送一次。HTTP HEAD请求与HTTP GET请求不同,它只要求这些虚拟目录也就是我们所说的协议的终结点的页面头部;然后根据返回的响应来确定这些虚拟目录是否可用,如果终结点返回的是300类的或者是400类的HTTP响应,那么Ex2013 CAS就认为这台服务器的这些终结点可以被当成代理流量目标。如果请求超时或者是返回了一个HTTP 500类的响应,HTTP HEAD请求会立即重试一次,第二次HTTP HEAD请求如果再次失败,那么就认为这台服务器的这个终结点down了,则不会再向其代理任何流量了。

Tips:如果在多台Ex2010CAS与Ex2013CAS的混合环境中,你想指定某台Ex2010 CAS排除在代理流量之外(停止接收Ex2013的代理流量),比方说你当前要开一个维护窗口(暂时停掉该台Ex2010 CAS进行升级打补丁维护之类的),或者是你计划直接砍掉它,那么你可以使用Set-ClientAccessServer命令里的一个参数-isOutOfService来让它置身事外。命令如下:

Set-ClientAccessServer –identity EX2010CAS01 –IsOutOfService $true

运行了这个命令之后,除非你再次将-isOutOfService置为$false,否则这台Ex2010就一直闲在那了。

重定向:

在以下几种情况当中,Exchange 2013 CAS会重定向连接:

1. 当接收到入站的统一消息呼叫时。

2. 当一个邮箱位于Ex2007 MBX的用户打开Outlook Web App时候,Ex2013CAS会把这个请求重定向给Ex2007的CAS,这是因为Ex2007不接受Ex2013的Outlook Web App代理连接流量。

3. 当一个邮箱位于其他AD站点的Ex2013用户发起Outlook Web App连接,而这个其他AD站点的CAS上也设置了外部地址的情况下,本地收到该连接请求的Ex2013CAS会对其进行重定向。打个比方,北京的用户在上海站点,访问上海站点的Ex2013 CAS的OutlookWebApp,而他的邮箱位于北京站点的MBX,且北京站点的CAS上设置了外部访问URL,那么上海的CAS就会将北京的CAS的外部访问URL返回给客户端,让客户端进行重定向。如果北京站点的CAS没有设置外部访问URL或者是设置了与上海的CAS一样的外部访问URL,那么上海的CAS就会进行代理该连接,而不是重定向了。

还有一种重定向就是IIS的重定向,即你访问https://mail.contoso.com不用带后面的/owa/,这种配置大家应该都做过,非常人性化的设置,如果你没有玩过这个,那么可以参考这里:https://technet.microsoft.com/en-us/library/aa998359(v=exchg.150).aspx

CAS的共存和迁移

共存的首要任务,就是装一台Ex2013的CAS,并且把所有的入站流量放到这台新CAS上。做这种更改最主要的是修改整个系统的架构配置,而并非是配置Exchange,我们梳理一下这些任务:

1. 评估AD的站点拓扑,看是否需要作出什么改动

2. 为新的CAS服务器重新申请并安装证书。(下一章我们会聊聊Exchange的证书)

3. 为修改做好准备:包括反向代理,防火墙,负载均衡。

4. 考虑好外部与内部的DNS修改。

当你准备好以上任务的时候,你就可以尝试装一台Exchange 2013的CAS,然后验证入站流量是否如你所预期的那样流过它。微软推荐将这台Exchange 2013的CAS 放在1、面向外部的2、处理Autodiscover请求的位置,这样就可以让Ex2013的CAS来Handle这些Autodiscover的请求。换句话说,你得把公网映射改到这一台上来,配置好这台Ex2013 CAS的外部访问地址,验证好这台Ex2013的外部访问之后,你就可以添加更多的Ex2013服务器了。当然后续步骤还有很多,这仅仅只是个开始,仅仅!

混用的URL对Ex2010迁移到Ex2013的影响

在Ex2010当中,微软推荐的做法是不要让外部客户端直接解析到CAS Array,然后Cas Array与Outlook Anywhere主机名分开。要做到这两点很简单,改改DNS就行了嘛。如果你为这两个服务分配了相同的URL,当然也可以正常跑没问题,很多管理员都这么干:Outlook Anywhere设置成与RPC CAS Array的命名空间一样,mail.contoso.com,然后依靠split-brain DNS来让外部客户端只访问外部IP地址,外边儿也叫mail.contoso.com。然后对于其他的服务也这样,比如Exchange ActiveSync和Outlook Web App。这时候我们就认为,Mail.contoso.com这个域名是一个混用的URL。类似下面这张图:

完了等你装好Exchange 2013 CAS之后,你会发现环境里边的MAPI客户端不能用了!因为他们还在访问你统一设置的外部地址,mail.contoso.com,而这个地址现在已经指向了Ex 2013的CAS,而Ex2013 CAS不会接收任何MAPI直接连接。这咋办,MAPI连接不成功,Outlook就会自动回退到Outlook Any where连接方式。

那么我们再寻思寻思,如果我们在安装Exchange 2013之前打开了OutlookAnywhere,在旧的环境当中,注意一下你的Outlook Any Where的配置对话框里有这么两行

也就是说,如果我们想要Outlook Any Where客户端在内部环境里同样使用RPC over HTTP连接而非RPC直接连接,我们就得勾上第一个,那不得一个一个客户端的配?并不用,这两条配置是包含在Autodiscover 配置文件里的,记得上一章我们讲了Autodiscover里有各种Provider吗,这个配置由OutlookProvider来handle。所以在Exchange 2010的EMS里执行这样两条命令,就可以修改Autodiscover的配置文件,达到更新这两个配置的目的:

Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

如果你因为某种原因要将这个选项调整回去,那么就执行

Set-OutlookProvider EXPR -OutlookProviderFlags:None
Set-OutlookProvider EXCH -OutlookProviderFlags:None

改完了之后,等待Autodiscover刷新好所有的客户端,随机挑选几个验证一下,看是否如下图所示

这样连接过程就变成了下面两张图的样子:

通过上述步骤,我们保证了outlook客户端不管在内部还是外部,都会使用RPC/HTTPS来进行MAPI连接到Ex2013的CAS,这样就无所谓你是不是混用URL了。说到这里,大家应该明白了为什么在前面的章节里提到,只要共存环境里准备出现Exchange 2013,就得首先把老版本的CAS服务器上的Outlook AnyWhere全打开。

一口气又扯了一大堆,讲起来还是比较抽象,大家还得多结合平常的环境多思考思考,下一章我们聊聊轻松一点的话题:Exchange中的证书。

最后照例打一下广告:

http://www.itcharger.com/

你身边的 IT 加油站!

也欢迎关注 ITCharger 的微信公众号,每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。

时间: 2024-10-23 08:01:04

「深入 Exchange 2013」08 代理、重定向、共存的相关文章

「深入 Exchange 2013」07 Autodisocver

微软在Exchange 2007里引入Autodiscover自动发现服务,意图去简化用户配置Outlook与Exchange ActiveSync的过程.Outlook的配置文件虽然可以手动配置,但是从Autodiscover会覆盖手动配置的选项,在你做出一些更改的时候,明显批量的自动下发配置更方便. Autodiscover还负责告诉Outlook当前的邮箱位置信息,Outlook会在与邮箱断开连接之后重新尝试Autodiscover.总而言之,这玩意儿跟Outlook Anywhere一样

「深入 Exchange 2013」03 内部vs外部

这一章我们来讲内部访问与外部访问. CAS是干嘛的,还不就是为了给企业网络里的内部用户,或者是给穿过防火墙连接进来的外部用户提供服务的.一些组织可能对内部和外部用户的访问都不设限制,也有一部分组织限制了外部用户的连接.也就是说,这些部署了Exchange的组织,都有这样一个可以灵活控制内/外访问的需求. 内部vs外部最主要的不同点就是客户端以哪种URL连接,并且用哪种验证方法进行身份验证.在CAS上这些设置是独立于每一种协议的,比方说当前我要查看某前端上OutlookAnyWhere的内部与外部

「深入 Exchange 2013」01 客户端访问角色架构

Exchange 2013当中CAS角色的重要性不用多说.在Exchange Server4.0.5.0和5.5版本中,都没有特定的一个客户端访问功能角色,Exchange 2000引入了前端服务器的概念(front-end),这种服务器不存放任何邮箱数据,只提供客户端连接.一直到Exchange 2007,带来了第一次CAS角色的迭代:尔后在后面的产品中不断被加强改善. 在Exchange 2007的时候,CAS角色就已经负责以下三种类型的流量: 外部连接 内部连接 被其他CAS服务器重定向,

「深入 Exchange 2013」04 负载均衡

客户端关联性(已死~) 由于之前提到的CAS架构的改动,我们提到,Exchange 2013的CAS里不再需要客户端关联性.客户端关联性就是指在一次客户端连接过程中,一直是与同一台CAS服务器进行通信:换句话说,当客户端连接到了一个特定的CAS之后,该CAS会一直对该客户端提供服务直到该连接断开为止.为了达到这个目的,CAS必须维持该会话状态,在连接过程中经过的负载均衡器(支持客户端关联性的Load Balancer)才能知道是哪一个CAS正在处理该连接,从而进行正确的分流.如果负载均衡器或者是

「深入 Exchange 2013」05 Outlook Anywhere

这一章来给大家讲Outlook Anywhere,概念比较重要,但是容易混淆,大家得仔细阅读,仔细区分. RPC over HTTP/HTTPS 首先得理解,为何在Exchange 2013当中,仅支持Outlook Anywhere的Outlook MAPI客户端连接方式.早期版本的MAPI访问依赖的是TCP的RPC协议直接连接到MBX服务器,而Exchange2013则使用HTTPS封装的RPC协议.这就意味着,如果你在当前是Ex2007或者Ex2010的环境当中,再增加一台Ex2013的服

「深入 Exchange 2013」14 接收连接器

接收连接器在概念上要比发送连接器简单一点,每个接收连接器只用侦听来自你分配给它的ip地址和端口的请求,然后将SMTP会话传送出去即可.接收连接器使用权限组来决定哪些发送者被允许使用该连接器,权限组则是预先定义好的一系列安全主体对某个对象(当前场景下则是接收连接器)所拥有的权限,比如说是"任何有邮箱账户的用户"即Exchange Users,或者是"组织里的任何Exchange Server"即Exchange Servers.这种模型类似于NTFS权限模型,先把用户

「深入 Exchange 2013」11 传输架构Part1

阅读过TechNet文档的人肯定对下面这张图不陌生,这张图完整诠释了整个Exchange 2013的邮件传输架构,前一章里已经简要讨论过的几个组件都在里头,然而还有一些其他的组件也值得深入讨论.首先咱们来聊聊图里边出现的重要词汇. 1."代理"在这里是指Agents,而非是proxy,即处理或者传输消息的某一块程序代码.图中的agents直接反映出Exchange的Business logic,例如Exchange的反垃圾和恶意软件筛选组件属于协议代理,路由代理.邮件传递代理和邮件提交

「深入 Exchange 2013」13 发送连接器

啥是连接器? 连接器是一种存储在AD里的对象,被Exchange的传输服务所调用,以获取邮件流的逻辑连接路径.目前版本中连接器的大部分设置都只能在Exchange Management Shell里来设置,Exchange Administration Center(EAC)里并没有包含全部的选项(哪怕是之前版本里能够在EMC里设置的).图形界面下咱们主要通过EAC里,邮件流那块里头的接收连接器选项卡和发送连接器选项卡来配置连接器.当你选择了一个连接器之后,右侧的窗格里就会出来关于改连接器的一些

「深入 Exchange 2013」10 传输服务简述

前面的内容里面,已经为大家比较深入的介绍了Exchange2013的客户端访问角色涉及到的诸多细节.在接下来的章节里就跟大家聊一聊Exchange 2013里的传输服务,这一节总共的内容都比较多,而且更偏向理论,所以咱先来一篇简述,然后再分拆开一个一个讲. 在之前的版本中,由Exchange2007引入了Hub Transport(集线器传输)角色作为所有邮件信息的传递中枢,任何发送或者接收到的邮件都必然会经过至少一个Ex2010与Ex2007的集线器传输角色:那么在Exchange2013当中