word文档转成ppt教程：Outlook通过RPC或RPC over HTTPS访问Exchane邮箱-wps教程-PPT教程网

我们在前面的文章中已经介绍了Exchange邮箱的创建和配置，现在我们来看看如何访问Exchange邮箱。访问邮箱我们可以通过以下方式

A 用Outlook作客户端软件通过RPC/RPC Over HTTPS访问

B 用IE作客户端软件通过HTTP/HTTPS访问

C 用Outlook Express作客户端软件通过SMTP/POP3访问

D 用Outlook Express作客户端软件通过IMAP访问

E 通过EXIFS访问

从性能和安全考虑，用户倾向于采用Outlook和IE访问邮箱，这两种方式无论是性能还是安全与其他方式相比明显占优。Outlook和IE再进行对比，显然号称Exchange最佳客户端软件的Outlook还是更胜一筹。下面我们就来看看如何用Outlook通过RPC/RPC Over HTTPS访问Exchange邮箱。

在完成具体实现方法之前，我们要先了解一下RPC协议的特点，然后才能明白为什么很多防火墙管理员对RPC很头疼？为什么RPC数据包需要封装成HTTP格式？

RPC是远端过程调用的缩写，RPC协议特点很鲜明。普通的基于Winsock的网络服务大多有自己的固定端口，比如FTP守护21，HTTP守护80，但基于RPC实现的服务却可以守护随机端口。随机端口？！有没有搞错！客户端程序怎么知道每次随机产生的监听端口是多少？客户端该如何连接服务器呢。为了解决这些问题，RPC设计成这样的工作方式。首先，wordpress教程，每个基于RPC的服务都有一个UUID，UUID是一组128位长的数字，被用来区分RPC服务。UUID的定义是国际标准，跨操作系统。例如 Exchange信息存储服务的UUID是A4F1DB00-CA47-B31F-00DD010662DA。每次这些基于RPC的服务启动时都会选择一个高端端口进行监听，这个端口可以是随机的，然后这些服务会把自己的UUID以及自己这次监听的端口存储在终点映射器（End Point Mapper 简称EPM）的一个表中，EPM是专门为RPC设计的一个服务，端口是135，EPM记录了本机有多少个基于RPC的服务以及这些服务监听的高端端口各是多少。

现在假设有一个客户机要访问服务器上的Exchange信息存储服务，客户机首先要连接服务器的135端口，向EPM发起一个查询请求，查询请求中描述了自己所请求服务的UUID，此例应是A4F1DB00-CA47-B31F-00DD010662DA，然后请EPM告知这个服务对应的端口是多少。EPM查询后告诉客户机，你所请求的这个服务在6001端口监听。客户机接到这个答案后，接下来就会去连接6001端口，和Exchange信息存储服务胜利会师了！

听了上面的描述，大家就明白了为什么很多防火墙管理员对RPC很头疼，就因为RPC的动态端口！普通防火墙工作在网络层，传输层的居多，基本上只开放几个固定端口，用来保障网络安全。但如果防火墙后面有RPC服务，就麻烦了，为了保证RPC服务能被顺利访问，管理员有可能要被迫开放1024以上的所有高端端口！但如果开放得这么多，那防火墙也就成筛子了…..所以这个问题直到应用层防火墙问世以后才得以较好解决，例如ISA就作得不错，以后我们会给大家介绍，这里就不多说了。

电信部门对RPC服务也比较敏感，前两年的冲击波，震荡波等病毒，就是利用了RPC的一些漏洞在互联网上大肆传播，危害巨大。电信部门闻风丧胆，唯恐避之不及，干脆采用一刀切的手段，有些运营商把访问135端口的数据包直接丢弃，来它个难言之隐，一丢了之。这下运营商省事了，工程师们费事了。所有有时候Exchange服务器在内网用RPC访问很正常，一放到公网用RPC访问就很容易出问题。罪魁祸首其实是后台的运营商，所以工程师们为了应付电信的封锁，想出了给RPC包化化妆，封装给HTTP包这样的主意。这也是为什么今天我们要尝试用RPC/RPC Over HTTPS来访问邮箱的原因。

介绍一下今天的实验环境，如下图所示，由三台虚拟机构成，Florence是exchtest.com的域控制器，CA服务器，Berlin是Exchange＋SP2，Istanbul是域内的工作站，安装了Outlook2003，用来作访问邮箱的客户机。三台计算机的操作系统都安装了Win2003中文企业版，DNS服务器是我的物理主机192.168.2.24。

word文档转成ppt教程：Outlook通过RPC或RPC over HTTPS访问Exchane邮箱