Exchange Server 2007 常见问题解答(11)--Outlook Anywhere、IPv6、Remote Connectivity Analyzer

问：我们刚在组织中基于 Windows Server 2008 的服务器上部署了 Exchange 2007，一切都很正常，只有一个例外：即使我们根据 Microsoft Technet 上 Exchange 2007 文档中的指南配置 Outlook Anywhere（以前称为 RPC over HTTP），但无论我们如何尝试都不能从 Internet 上的 Outlook 2007 客户端连接到 Exchange 2007 客户端访问服务器。我们确定 SAN 证书受到客户端的信任，而且连接到客户端访问服务器的防火墙上的 TCP 端口 443 也处于打开状态。您是否遇到过这种问题？

答：事实上，我遇到过。您提到 Exchange 2007 安装在基于 Windows Server 2008 的服务器上。将客户端访问服务器安装在 Windows Server 2008 服务器上时需要特别注意，如果服务器启用 IPv6，Outlook Anywhere 则无法正常运行。因为将 Exchange 2007 SP1 安装在 Windows Server 2008 上时，系统将默认启用 IPv6，所以您必须确认将其禁用。我看过好几个案例中这样就可以解决问题。

有关 Windows Server 2008 上的 Outlook Anywhere 和 IPv6 为什么互相冲突，以及如何在 Windows 2008 服务器上适当禁用 IPv6 而不中断 Exchnage 2007 的详细信息，我建议您阅读 Microsoft Exchange 团队的博客文章，网址是 msexchangeteam.com/archive/2008/06/20/449053.aspx。应该使用 Exchange 2007 SP1 Rollup 4 解决此问题。

问：当前，我正在基于 Exchnage 2007 的消息环境中实施 Outlook Anywhere 和 Exchange ActiveSync，我想知道有没有办法可以测试 Outlook Anywhere 是否可以在我们外围网络的另一端按预期运行。此外，我希望确定环境中的自动发现服务已正确配置。您可以为我指点迷津吗？

答：是的，有办法可以测试 Outlook Anywhere 是否正常运行。Microsoft 的两名员工（Exchange 产品小组的 Shawn McGrath 和产品支持服务的 Brad Hughes）创建了基于 Web 的工具，称为 Exchange Server Remote Connectivity Analyzer (ExRCA)。您应该将此工具（图 1）视为原型，但我却没遇到任何程序错误或异常行为。此工具可以执行 Outlook 2007 自动发现和 RPC/HTTP 连接性测试，还可以测试 Exchange ActiveSync 和入站 SMTP 邮件流是否按预期运行。虽然 ExRCA 当前不受 Microsoft 支持，但我强烈建议使用它对 Exchange 2007 进行各种远程连接性测试。

问：我们的组织使用的是 Exchange Server 2007，而且目前正处于部署备用连续复制 (SCR) 的规划阶段。我们想为在另一个站点中的非群集 Exchange 2007 SP1 邮箱服务器上创建的每个邮箱数据库准备第二组数据。我们从 Microsoft Technet 上的 Exchange 2007 文档中阅读了很多有关 SCR 的信息，但是仍有个疑问无法获得解答：如果激活 SCR 目标，所产生的效果与使用 Move-Mailbox 以及为特定邮箱数据库中的所有用户邮箱指定的 –ConfigurationOnly 参数是否相同？换句话说，就是只更改 Active Directory 中的 Exchange 服务器位置。

答：既然您使用非群集邮箱服务器（也称为独立邮箱服务器）作为源 SCR 服务器，那么您的理解没错。因为您要激活其他服务器上的 SCR 副本，所以要使用数据库的可移植性。这意味着各个邮箱数据库中的用户邮箱在 Active Directory 中的 Exchange 服务器位置将更改。

如果 Exchange 2007 环境中的源 SCR 服务器是以群集连续复制 (CCR) 或单一副本群集 (SCC) 为基础，而且如果在故障转移群集中将被动节点用作 SCR 目标，则您可以使用相同的名称激活 SCR 目标，而 Active Directory 中的 Exchange 服务器位置不会更改。

问：我们刚刚完成我们企业环境中的 Exchange Server 2007 部署，想知道是否支持将六个 Exchange 2007 安全组（在为 Exchange 2007 安装准备林和域时，由 Exchange 2007 安装程序创建）移动到另一个组织单位，而不是移到在根域中创建的 Microsoft Exchange 安全组 OU。

答：Exchange 2000/2003 不允许将 Exchange 组移动到林中的其他 OU，但 Exchange 2007 却真正支持此操作。您可以看到为 Exchange 2007 准备林时创建的六个 Exchange 2007 安全组（参见图 2）带有两个唯一的属性戳记，第一个是众所周知的 GUID，第二个是可更改的可分辨名称。

当安装程序运行时，林的 OtherWellKnownObjects 属性将分别添加这两个属性，这可确保 Exchange 能够在林中的任一位置找到安全组。因此，您可以将组随意移动，甚至可以移动到是林中的其他域！您可以在 Ross Smith 撰写的精辟的《Exchange 2007 权限：常见问题》 (technet.microsoft.com/bb310792) 中查找其他详细信息，该文章包含在 Microsoft TechNet 上的 Exchange 2007 文档中。

问：由于基于 Exchange 2007 消息环境中的重组，我们希望将每个 Exchange 2007 CCR 邮箱服务器的文件共享见证移动到另一个集线器传输服务器。您是否可以对如何以受支持的方式完成此操作提供一些指导？

答：将文件共享见证从一个 Exchange 2007 集线器传输服务器移动到另一个服务器相当简单。只需采用当初为群集邮箱服务器配置文件共享见证所遵循的步骤即可。唯一的区别是您需要指定服务器的路径。相应的步骤位于 Microsoft TechNet 上的 Exchange 2007 文档内的“如何配置文件共享见证”一节中（请参阅 technet.microsoft.com/bb124922）。

顺便说一下，您应该知道，如果在配置文件共享见证时使用 CNAME 记录指向您的集线器传输服务器，则接下来的任务只是将目标主机的完全限定域名 (FQDN) 更改为各个 CNAME 记录指向的别名（请参见图 3）。

但是请记住，如果您将群集节点放在其他站点中，将更改 Exchange 产品小组提供的站点恢复指南（请参见 msexchangeteam.com/archive/2008/04/03/448615.aspx）。一般来说，Exchange 产品小组不再建议您在 Exchange 2007 Geo-Cluster 环境中使用 CNAME 记录。

问：我们计划提高组织中 Exchange 2007 消息服务器的安全设置。我们的安全优化计划的一部分是加密 Exchange 数据库所在的卷。我们想知道是否建议或甚至支持将 Exchange 数据库文件存储在使用加密文件系统 (EFS) 加密进行加密的卷上。

答：答案很显然是否定的。Microsoft 并不支持将 Exchnage 2007 数据库放在基于 EFS 的加密卷上。事实上，.edb、.log、.stm (Exchange 2000/2003)、.dat、.eml 和 .chk 文件都不支持这种做法。主要原因是这种类型的加密将产生额外系统开销，从而明显影响性能。

为了进一步保护您的 Exchange 2007 数据文件，您应该防止对 Exchange 计算机的未授权访问，以及使用 S/MIME 消息格式来加密消息数据。此外，如果您将 Exchange 2007 安装在 Windows Server 2008 上，请考虑使用 BitLocker 来保护卷。

问：我刚刚将 Exchange 2007 SP1 安装在同时也是域控制器的 Windows Server 2008 服务器上。因为我在此环境中不使用 IPv6，所以安装完 Exchange 2007 SP1 后，就禁用了“网络连接”下的 IPv6，然后我重新启动服务器。当恢复连接时，Exchange 2007 服务却再也无法启动。应用程序日志中记录的错误 214 包含下列信息：

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).

答：我看过不少报告中提到过这种情况。虽然将任何 Exchange 2007 服务器角色安装在同时也扮演域控制器角色的 Windows Server 2008 服务器上并不妥当，但允许一个或多个 Exchange 2007 服务器角色在禁用 IPv6 的域控制器上运行应该没什么问题，特别是这种情况在测试实验室和其他地方都很常见。目前的解决方案是在服务器上重新启用 IPv6。有传闻说 Exchange 2007 SP1 Rollup 4 将解决这个问题。