在Exchange 2010当中，拥有与Exchange 2007相同的5个角色。但是，各角色之间进行了一些重要的架构改变和责任转变。在本文中，我将着重向大家介绍与客户端访问角色相关的细节变化。
从Exchange 2007开始，微软便为Exchange组织推出了5个执行不同功能和服务的角色。微软尤其为客户端访问服务器角色(CAS)推出了多种新的访问服务，如：Web服务、可用性组(DAG)、自动发现服务和日历服务。
在Exchange 2010当中，拥有与Exchange 2007相同的5个角色。但是，各角色之间进行了一些重要的架构改变和责任转变。在本文中，我将着重向大家介绍与客户端访问角色相关的细节变化。
Exchange 2010中最重要的变化是：客户端访问服务器角色(CAS)中采用了2个分别被称为RPC客户端访问服务和通讯簿服务的新服务来建立MAPI、NSPI和RFR方式的客户端访问。这一新功能和改变主要用于取代 Information Store与RPC终端的这种通讯方式。但 Exchange 2010 Information Store 的RPC终端功能并未被完全移除，它的功能已经被更改为只接受来自CAS服务器的请求。
公共文件夹数据库访问方式的RPC终端仍保留在邮箱服务器角色上，但Outlook客户端现已改为通过RPC客户端访问服务来访问邮箱角色上的公共文件夹数据库，而非通过 Information Store。
背景
在Exchange 2003中，所有的客户端都直接连接到 Information Store的数据访问和数据呈现服务，或通过前端服务器代理连接到Information Store的数据访问。
在Exchange 2007中，微软开始整合数据访问路径，使大多数客户端(例如：OWA、POP和IMAP)都通过一个被称为Exchange中间层的业务逻辑层。此中间层创建了进入所有服务器角色的库，客户端通过这个共同的业务逻辑层采取一致的业务逻辑以实现其优势。在这一点上，MAPI客户端(如Outlook)和WebDAV客户端(如Entourage 2004)仍直接连接到 Information Store。
(图1)
在 Exchange 2010中，CAS中的新RPC终端托管代码与上层核心业务逻辑层共享其它内部Exchange 2010服务器角色。此外，WebDAV功能已被移除，这意味着使用WebDAV的应用程序需要更新或迁移至支持Exchange Web Services的新版本。
(图2)
Exchange 2010中间层
为了确保对这项中间层架构的改进，微软为客户端访问服务器角色添加了2个新服务：RPC客户端访问服务和通讯簿服务。
RPC客户端访问服务用于处理所有邮箱数据库连接，通讯簿服务用于处理所有活动目录数据库连接和访问。一个值得注意的例外则是--公共文件夹。公共文件夹连接和客户端连接都使用邮箱角色上的RPC客户端访问服务，并非 Information Store。
RPC客户端访问服务
在Exchange 2007或更早版本时，MAPI客户端都直接连接到邮箱服务器。这意味着当发生故障转移时，客户端将从他们的MAPI连接和目录直接断开。在Exchange 2010中，我们的客户端连接都通过抽象方式"远离"邮箱服务器，因此，当邮箱数据库发生故障切换时，客户端最终会保持MAPI和当前目录的连接状态不至中断过久。这无疑为Outlook客户端提供了一个用于更完美的用户体验。
实现客户端连接到CAS状态的无缝切换和故障转移是此架构的主要优势之一，由抽象的客户端进行 Information Store连接可在访问用户邮箱失败时把对用户产生的影响降到最低。另一个巨大的优势和好处在于：所有客户端都能够使用相同的代码和逻辑来访问存储内容。这意味着，无论客户端通过IMAP、MAPI或OWA进行访问，我们都不必再对业务逻辑进行统一数据格式的操作，这样做是为了减少类似的MIME到MAPI转换问题。此外，这种模式也使得信息存储过程更为精简。
RPC客户端访问阵列
当客户端访问服务器与邮箱服务器进行通讯时，实际上客户端访问服务器是通过承载数据库的邮箱服务器与邮箱数据库进行通讯。当你的环境中客户端访问服务器或客户端访问服务器阵列配置为使用数据库可用性组(DAG)时，这则形成一种特别明显和有效的客户端访问服务器负载均衡阵列。在非负载均衡环境中，邮箱数据库会关联多台客户端访问服务器的负载均衡阵列。当在环境中启动或添加2台或多台客户端访问服务器后，我们就可以配置和使用RPC客户端访问阵列功能了。
默认情况下，在配置客户端访问阵列之前，环境中的所有数据库都只与一台客户端访问服务器关联和通讯，Outlook客户端也直接与客户端访问服务器进行通讯，直到你成功配置客户端访问阵列。
如果要使用CAS阵列，则需要提前进行配置，其步骤如下：
为客户端访问阵列挑选一个合适的FQDN
添加客户端访问服务器到活动目录站点当中，以形成负载均衡阵列。在DNS中将上一步中选好的FQDN解析到负载均衡阵列的虚拟IP
配置数据库使用CAS列阵
New-ClientAccessArray -FQDN -Site <站点名称>
New-ClientAccessArray cmdlet可以帮助我们创建客户端访问阵列，它将在活动目录站点中创建一个对象来代表客户端访问服务器的负载均衡阵列。如下图：
(图3)
以上3步完成之后，在当前环境(同一AD站点)中所有新建的邮箱数据库都将与此阵列关联。当创建新数据库时，会自动从活动目录中获取阵列的networkAddress属性，并将数据库的RPCClientAccessServer属性写入到活动目录当中。
关联CAS阵列到邮箱数据库
邮箱数据库的对象属性被称为RpcClientAccessServer，此属性中包含了客户端连接到MAPI服务时需要使用到的信息。如果您的环境中有超过1台以上的邮箱数据库，你将在不同的服务器上看到多个不同的RpcClientAccessServer值。
通过下列命令行可查看数据库关联的客户端访问服务器或客户端访问阵列：
Set-MailboxDatabase <数据库名> -RpcClientAccessServer <客户端访问服务器名或客户端访问阵列名>
这条命令将更改邮箱数据库的legacyExchangeDN属性值，这个值的存储位置为：
CN=Mailbox Database ##########,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
在改变此属性值之前，你必需要知道阵列的RPC终端路径的值。
RPC客户端访问服务高可用性解决方案
(图4)
在数据库可用性组(DAG)和客户端访问负载均衡(NLB CAS)阵列环境中，活动管理器保持跟踪数据库的活动状态，并将服务器信息报告给CAS阵列。正因为这样的设计，Outlook客户端就不必保持每台数据库服务器连接，只需与CAS阵列连接即可。在这样的设计和环境中，如果CAS阵列的某台邮箱数据库服务器发生故障，客户端可以在30秒内恢复访问。
通讯簿服务
在Exchange 2010之前，客户端使用Exchange服务器的一个"咨询服务"来查找名称服务提供程序接口 (NSPI) 代理，这个"咨询服务"通常会将Outlook指向全局编录(GC)服务器，并且此功能提供了一个名为目录服务代理(DSProxy)的组件。Outlook希望使用MAPI访问同一服务器时，也会使用这项"咨询服务"。
当Outlook联系客户端访问服务器时，有2种可能性会发生：
如果用户邮箱在Exchange 2010邮箱服务器角色上时，则：
当用户邮箱在同一站点的客户端访问服务器时，则由本地客户端访问服务器或客户端访问服务器阵列进行响应
当用户邮箱在不同站点的客户端访问服务器上时，则访问请求会被转发并由远程客户端访问服务器或远程客户端访问服务器阵列进行响应
当用户邮箱被移到旧版本的Exchange上时，则访问请求会被直接发送到用户邮箱所在的邮箱服务器。
其实这种方式还可以充当查找可写域控制器和访问全球地址簿(GAL)的简化方案。
(图5)
RPC加密设置
默认情况下，Exchange 2010的RPC客户端访问服务需要进行加密连接。这就意味着，在默认情况下Outlook 2003客户端将无法连接到Exchange 2010。如果你的环境中还有Outlook 2003客户端需要使用RPC客户端访问服务连接到Exchange 2010 的话，我建议您为Outlook 2003启用加密功能，而不是在服务器上直接禁用加密。对于此问题的更多信息可以参考http://support.microsoft.com/?kbid=2006508。
除了对RPC进行加密外，在Exchange 2010中 UDP支持功能也已被移除。因此，在联机模式下，Outlook 2003客户端只能使用轮询消息，这将导致Outlook 2003在访问和更新Exchange 2010项目状态时有轻微延迟(平均30秒，最多1分钟)。要解决这个问题，我们主要使用如下2种方式：
使用Outlook 2003缓存模式
在客户端访问服务器(CAS)上调整轮询间隔。(这将影响到客户端访问服务器的性能)
相关信息您可以参考http://support.microsoft.com/kb/2009942
RPC客户端访问的好处
对于客户端进行抽象化的业务逻辑使得Exchange 2010的存储数据库实现起来更为灵活、简洁，这也使得微软可以相对早期版本的业务逻辑剔除不必要的众多API以达到优化目的。其实，微软已经在存储中移除了邮箱规则和传输堆栈，还移除了Microsoft Exchange邮箱助手中的日历处理逻辑，以及去掉了对ExCDO的支持和针对项目级别的安全标识符等。
另一方面，为了提高邮箱连接的可伸缩性，微软还从中间层中移除了RPC端点。Exchange 2007时代，微软在Windows TCP/IP协议栈中不论IP地址数和源端口，都有效地将每邮箱服务器的连接限制为60000个。Windows 2008发布时，这些限制已从Windows中取消，并且每个IP地址都支持1个端口。但是，我们现在还并不能真正利用上这一改变和优势，因为DSProxy还未支持这项新改变。这就意味着，邮箱服务器被限制为最大60000个出站TCP连接与全局编录(GC)进行通讯。此存储进程也采用硬编码方式，最大只支持65535个RPC上下文句柄。总而言之，考虑到邮箱配置文件及CPU可扩展性的支持等限制和影响，我们之前最多只能使用15000个活动邮箱。
(图6)
Exchange 2010针对后端存储可用性的改进请参考上图。
当Exchange 2010引入RPC客户端访问服务后，我们的应用前景就开始变得一片光明。在Outlook客户端和CAS服务器之间，针对客户端会话会有一个1对1的连接映射。此外，CAS服务器还可以断开空闲的客户端会话以释放出连接资源，让CAS更好地与邮箱数据库进行通讯。现在，CAS能够与客户端共享100个连接池，当CAS主动断开客户端后，客户端只是挂在断开状态，当客户端需要再执行某些操作而进行主动连接时，CAS才会为客户端重启并恢复连接状态。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
