Q我们的邮件传递基础结构基于 Exchange 2007 SP 1。 Windows Server 2008 上安装 Exchange 2007 SP 1 的所有服务器。 我们有两个数据中心，在主数据中心和备份，我们可以故障转移灾难取得主。 在我们主要的 Datacenter 所有邮箱服务器都基于群集连续复制 (CCR) 为了提供一个本地的高可用性解决方案。 对于故障邮箱服务器转移从主数据中心到备份数据中心，我们可以使用备用连续复制 (SCR)。 这意味着所有在 CCR 基于群集的邮箱服务器 （CMSs） 在主数据中心还充当 SCR 源。 每个 SCR 源中已安装被动邮箱服务器角色的待机群集的形式备份的数据中心中有相应的 SCR 目标
最近我们两个数据中心之间的站点故障转移测试并，遗憾的是，我们遇到的问题当我们尝试恢复到待机群集 CMSs 时。 运行与 Setup.com/help 时在 /RecoverCMS 开关，我们得到 图 1 所示的错误消息。
图 1 恢复 CMS 到待机群集时的安装错误
我想知道是否您已经看到此错误时恢复待机群集并，更是重要是否您具有一种解决方案为它的 CMS。
A是，我有恢复到待机群集的 CMS 时遇到此问题的 misfortune。 幸运的是，这也是站点级别的故障转移测试过程中。 （我是否需要解释为什么测试故障转移解决方案很重要？）
得到我认为的一点是我必须测试相同的设置之前没有问题的次数。 但是，所有以前的恢复测试是 Exchange 2007 安装了 SP 1 在 Windows Server 2003 和 Windows Server 2008 上为时我遇到此问题的情况。
这使我能够发现如何 Windows Server 2008 故障转移群集与 Windows Server 2003 的群集的工作。 在 Windows Server2003 您创建，和在将群集专用群集服务帐户。 在 Windows Server 2008，您不能再做这 ； 而，故障转移群集运行在"本地系统"。 检查应用程序和系统登录待机群集我尝试恢复在 CMS 后，我发现 图 2 所示的错误。
图 2 由于权限不足而引起故障恢复错误
此事件 ID 错误说明 Windows 故障转移群集没有必要更新 Active Directory 中的 CMS 计算机帐户权限。 此外列出了三个可能的原因。 因为我们要恢复在待机群集上的现有 CMS，我们可以忽略第一个。 因为我们没有到达计算机对象的任何配额，我们也可以忽略的编号 2。 最后一项，但是，是非常有趣。 它告诉我们验证 Windows 故障转移群集我们恢复在 CMS 具有 CMS 计算机帐户对象的"完全控制"权限。
在 Active Directory 用户和计算机中 CMS 计算机对象的属性页上安全选项卡查看显示待机群集上没有"完全控制"权限 （图 3）。
图 3 </a0>-待机群集不具有的完全控制 ” 权限
将待机群集具有"完全控制"权限添加到 CMS 计算机对象解析为我此问题，并且它应该执行您的环境中相同。
撰写 (2月尾) 时，存在的有关此问题在公共场所像 TechNet 或所有知识库文章中的任何信息。 但是，我的好朋友 Tim McMichael 从 Microsoft 客户支持服务具有写入博客张贴内容进入比我能够做的得更详细的本主题。 请转签出更多信息的 Tim 的博客 (" 适合 CNO （群集名称对象），Windows 2008 中的 Exchange 2007 SP 1 安装程序操作的权限。 ").
Q我们当前精心制作一个站点级故障转移解决方案的过程中。 为我们 Exchange 2007 SP 1 的消息基础结构我们将备用连续复制 (SCR) 作为灾难恢复解决方案，我们的主要及备份数据中心之间。 因为只将某些我们最终用户已升级到 Office Outlook 2007 与其余部分仍在 Outlook 2003，我们获取了一个问题。 要备份数据中心，从主数据中心发生故障转移的 Exchange 2007 SP 1 服务器，将只是拾取两个 Outlook 版本所做的更改执行所需的 SCR 站点故障转移步骤后？
A非常好的问题，和实际，是该的答案取决于您使用可移植 RecoverCMS 或数据库性进行故障转移到备份数据中心邮箱服务器。 如果您主数据中心中有独立邮箱服务器，并复制这些备份的数据中心使用 SCR，独立邮箱服务器然后可以使用数据库可移植性为了故障转移，Mailbo x 数据库。 如果必须单一副本群集 (SCC) 或 CCR 邮箱服务器在主备份数据中心和待机群集中您备份的数据中心中，您将使用 / RecoverCMS 开关恢复整个 CMS，备份数据中心。 为故障转移机制使用 RecoverCMS 时, 您通常不必担心在故障转移后的 Outlook 客户端连接。 请记住，CMS 的 IP 地址会更改。 但是，如果已配置为 5 分钟根据为最佳的实践建议的 Live (TTL) 值，DNS 时间，注意将有稍有延迟之前 Outlook 客户端将能够重新连接到在 CMS。
如果您要在作为恢复机制使用数据库可移植性的情况则有点不同，根据 Outlook 客户端版本。 Outlook 2007 客户端将反映这些更改会自动通过 Autodiscover 服务客户端访问服务器上运行的。 这意味着您不进行任何手动更改为此 Outlook 版本。 但是，这并不一定与 Outlook 2003 客户端。 当邮箱已恢复另一台服务器上时，存储邮箱数据库的服务器名称显然将不同。
可能想知道不会在 –ConfigurationOnly 使用 Move-Mailbox cmdlet 时此问题后切换故障转移？ 是，仍然重要因为 Outlook 2003 不支持自动发现服务。 这意味着原始服务器的邮箱存储之前，以便更新在 Outlook 的 MAPI 配置文件中该服务器名称故障转移必须联机。 如果原始服务器已脱机，服务器名称不能将自动更新。
因此，如果您遇到灾难的主数据中心中的所有服务器都都脱机，您必须重新使用工具 （如 Microsoft Exchange Server 配置文件重定向器 (exprofre Outlook 2003 MAPI 配置文件配置结合登录脚本，以便反映这些更改。 值得注意是否所有客户端位于主数据中心，则将需要重新生成它们仍。
Q我们 Exchange 2007 SP 1 的消息基础结构中所有我们邮箱服务器都是群集连续复制 (CCR)-已启用。 我们的每个群集节点中安装四个网络接口卡 (NIC)。 两个 NIC 被各行各业，并且已连接到公用网络等接受 Outlook 客户端请求。 第三个 NIC 用于检测信号网络 CCR 中两个群集节点之间。 第四个 NIC 有是专门用于日志传送目的中。 使用 Enable-ContinuousReplicationHostName cmdlet Exchange 2007 SP 1 中引入，我们具有 (才能获得日志传送冗余) 指定可从活动的日志文件提供到被动节点使用检测信号和专用的日志传送网络。 此工作很好，真正减少尤其是在情况下在公用网络上的通讯，其中一个种子重新设定一个或多个邮箱数据库所需 （尽管这应该是相当少见）。
我们也有这些 CCR 基于邮箱服务器和我们备份数据中心中的多个 SCR 目标之间启用 SCR。 这将导致我们的问题。 可以使用 SCR 使用 Enable-ContinuousReplicationHostName cmdlet 吗？
A很高兴 EnableContinuousReplicationName cmdlet 都已有所帮助。 但是，此 cmdlet 专门创建的 CCR 解决方案后, 答案问题是，遗憾的是，不，当前不支持此 SCR 解决方案中。
Q我们有只转换从 Exchange 2003 到 Exchange 2007 SP 1。 窗口 Server 2008 上运行所有的 Exchange 2007 SP 1 服务器角色，我们的 Exchange 2007 邮箱服务器基于 CCR。
操作工作为止很好，但是我们遇到的问题脱机通讯簿 (OAB)。 当该更新与新的邮件对象时，更新不在最终用户反映 Outlook 2007。 我们已被解决该问题且具有事件 ID 1021 中找到应用程序日志具有下列描述客户端访问服务器上：
复制代码
Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location> This is normal if the directory has never been generated. Otherwise, make sure this directory and share has read permission for the "Exchange Servers" group.
我们尝试将 OAB 手动从 CCR 基于邮箱服务器复制其中托管到客户端访问服务器。 这将导致 Outlook，更新，但我们想获得永久解决此问题。 是否有该方案？
A我已经关闭的 Road，过。 此问题的原因是因为 Windows 2008 故障转移群集的行为的方式。 Windows 2008 故障转移群集引入了称为共享范围的新概念。 基本，共享范围的方法文件共享是特定节点名或群集之一命名对象的共享主机。 共享共享节点名称时, 它不能被访问群集的邮箱服务器 (CMS) 名称。 有关文件共享范围的多 geeky 详细信息，请参阅此文章请求核心团队博客上 （" Windows Server 2008 故障转移群集中的文件共享范围 ").
要解决此问题，您需要安装 Exchange 2007 SP 1 累积修补程序更新 5 或更高版本，在其中包括所需的 Bug 修复。 另请参见文章" Exchange 2007 CAS 不能从 Windows Server 2008 的 Exchange 2007 CCR 群集上 OAB 共享复制 OAB ." 因为此累积更新将与其某些回归，很重要，使用此解决方案之前仔细阅读汇总更新 5 KB 文章。
Henrik Walther 是 Microsoft 认证 Master： Exchange 2007 和 Exchange MVP，拥有超过 15 年的 IT 业务中的体验。 他适用作为 Trifork 基础结构咨询 （一个 Microsoft 金牌合作伙伴在丹麦） 在技术架构师和为 Biblioso Corporation （托管的文档和本地化服务于一个基于的美国公司） 的技术编写器。