Exchange 2010问答:使用 DAG

使用数据库可用性分组是个不错的选择，尤其是因为您可以在多个位置复制和存储这些分组 – 但要注意寻址问题。

Henrik Walther

解决难题

问：我们部署了 Exchange 2010，并利用数据库可用性分组 (DAG) 为所有邮箱服务器配置了高可用性。事情很顺利且一切都按预期进行，除了一个小细节。

如果收到员工通过 DAG 中托管的邮箱发送的邮件，该收件人反过来向其他员工或其他组织的人发送邮件，则他们收到邮件中 Internet 邮件头将显示使用 APIPA 地址（如 169.254.5.133）配置了邮箱服务器。由于我们对所有 Exchange 2010 服务器使用的是静态 IP 地址，因此我们不知道它为什么会显示为 APIPA 地址（见图 1）。您能不能提供一些线索？

答：这个问题很有意思。简单来说，只有利用一个或多个 DAG 为 Exchange 2010 邮箱服务器配置高可用性并且 DAG 功能基于 Windows 故障转移群集 (WFC) 组件时，才会发生此情况。不属于 DAG 的邮箱服务器不会发生此行为。

让我们仔细看看这里出现的问题。Windows Server 2008 R2 中的 WFC 组件希望使用 WFC 的应用程序（如 SQL、Exchange 和文件服务器）能够通过特定方式找到群集资源。该应用程序应使用 DNS 服务器找到合适的信息以便连接到群集资源。

这就是所谓的客户端访问点 (CAP)。一个 CAP 包含一个 NetBIOS 名称以及一个或多个 IP 地址资源。在 Windows Server 2008 R2 中，如果服务器支持动态更新，则一旦在 WFC 中 CAP 联机，就会在 DNS 中注册 CAP 信息。

遗憾的是，有些应用程序会跳过 DNS 步骤，而将使用绑定列表中的第一个网络适配器直接连接到群集节点。默认情况下，绑定列表中列出的第一个网络适配器是 Microsoft 故障转移群集虚拟适配器（见图 2）。此适配器是使用 APIPA 地址配置的。

图 1 Internet 邮件头中的 APIPA 地址

图 2 Microsoft 故障转移群集虚拟适配器

下面，请您猜一猜哪个应用程序不会使用 DNS 来定位和连接群集资源呢？猜对了：Exchange 2010（以及 Exchange 2007）。

如何解除这点烦恼呢？幸运的是，利用名为 nvspbind 的小工具就可以轻松解决，可从 MSDN 代码库：code.msdn.microsoft.com/nvspbind 下载此工具。Nvspbind 专门用于从命令行修改网络绑定。

下面我们来查看服务器中适配器的绑定顺序。运行 nvspbind.exe /o ms_tcpip。如图 3 中所示，首先列出的是 Local Area Connection* 9（等同于 Microsoft 故障转移群集虚拟适配器）。

图 3 使用 nvspbind 查看绑定顺序列表

接下来，我们需要在列表中将 Local Area Connection* 9 下移。运行如下命令：

nvspbind.exe /- “Local Area Connection* 9” ms_tcpip

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false

然后，使用以下命令卸载数据库：

Dismount-Database MDB01 -Confirm $false

接下来，将数据库和所有日志文件复制到另一个位置，如 USB 驱动器。

复制过程完成后，使用以下命令重新安装活动的数据库副本：

Mount-Database MDB01

现在，将 USB 磁盘连接到用来承载数据库的服务器，并将数据库和日志文件复制到文件夹中并确保路径与源服务器上使用的路径相同。

使用 Add-MailboxDatabaseCopy -SeedingPostponed 参数添加数据库副本。具体命令如下所示：

Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed

请注意，不存在种子设定过程，因为 EDB 文件及关联的日志文件已就绪。最后，使用以下命令重新启用循环日志记录：

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true

移动办公人员

问：我们运行的是 Exchange 2010，并且我们有很多移动办公人员都高度依赖 Outlook Web App 或 OWA（也就是 Outlook Web Access）。这些用户在密码过期后将无法登录到 OWA。我们还发现，对于那些在首次创建用户帐户时帐户设置为“用户下次登录时必须更改密码”（见图 6）的新员工，他们必须使用其他机制更改密码，否则无法登录到 OWA。

图 6 启用“用户下次登录时必须更改密码”

自多年前我们从 Lotus Domino 迁移到 Exchange 2003 以来，一直被此问题所困扰。您知道我们该如何解决此问题吗？

答：现在正是解决此问题的好时机。当 Exchange 团队开始规划 Exchange 2007 SP3 和 Exchange 2010 SP1 时，他们决定弥补这一不足之处，以便能在用户密码过期或用户帐户设置为“用户下次登录时必须更改密码”时登录到 OWA。他们开发了 OWA 密码重置工具。此工具是一个 IIS 7 模块，可检测过期密码并将用户重定向到全新的“更改密码”页。

图 7 Outlook Web App 2010 基于表单的身份验证登录页面

我们来看一下实际的效果，怎么样？用户尝试使用基于表单的身份验证 (FBA) 登录页面登录到 OWA 2007 或 2010，如图 7 中所示。此时用户将重定向到新的“更改密码”页，如图 8 中所示。用户需要在此页中输入当前密码和新密码，然后单击“提交”按钮。

图 8 Outlook Web App 2010“更改密码”页

现在密码已更改，用户可使用新密码进行登录。是不是很简单，很友好？

请记住，在安装 Exchange 2007 SP3 或 Exchange 2010 SP1 之后，默认情况下不启用“更改密码”页。您需要使用注册表项来启用此页。更具体地说，您需要登录到每个 Exchange 2007 或 Exchange 2010 客户端访问服务器 (CAS) 并启动注册表编辑器。

在注册表编辑器内，浏览找到：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA。您需要在此处创建一个名为 ChangeExpiredPasswordEnabled 的新 REG_DWORD 注册表项。通过将数据值设置为“1”来启用它，如图 9 中所示。

图 9 为 OWA 启用“密码更改”所需的注册表项

现在，无论移动办公人员的密码已经过期还是需要更改，他们都可以登录到 OWA。