Exchange Server 2007 常见问题解答(3)

　　问：我们最近从 Exchange Server 2003 迁移到了 Exchange Server 2007。现在经常接到投诉，说受限用户在登录到 OWA 2007 时如果选择“此计算机是私人计算机”选项，Outlook® Web Access (OWA) 便会超时。用于验证私人计算机超时的相应 Exchange 命令行管理程序命令是什么?

　　答：请稍等片刻。首先我会解释为什么私人计算机(与公用计算机相对)会有一个单独选项(参见图 1)，然后再介绍这些选项的行为差异。 我的目的是使用户能够通知 Exchange 需要什么样的安全级别 - 例如，是在使用机场的公用网亭登录到 OWA，还是在使用家用计算机登录。Exchange 管理员可以选择区别对待这些会话类型。例如，管理员可以将经过身份验证的会话在公用计算机上的超时(比如在几分钟内)设置得比在私人计算机上的超时(最长可达三天)更快。管理员还可以根据用户的选择对其他设置进行不同的配置。例如，管理员可能会将对 SharePoint® 文档库和 Windows® 文件共享的访问权设置为只向私人登录开放。当然，这取决于指定权限选项的用户。如果管理员不信任用户做出的权限选择，他们可以为每个选项指定相同的超时值及其他配置选项。

　　

　　图 1 公用和私人计算机会话类型允许使用不同的超时设置及其他配置选项

　　这里讨论的选项在 Exchange 2003 中就已经存在了，而当时基于表单的身份验证也是首次引入 OWA。(历史注释：基于表单的身份验证的首次实现在某种程度上是由一位杰出的项目经理设计的。我不会公开她的身份，但我想告诉您她后来通过为《TechNet 杂志》的一个双月刊专栏撰稿而名利双收。)

　　此设置实际上是存储在注册表中的，但由于 Windows PowerShell™ 提供了一个用于更新注册表的接口，因此您可以使用 Exchange 命令行管理程序配置此设置。当用户在登录过程中选择私人计算机选项时，以下示例会将超时时间设置为 1440 分钟(也就是一天)：

　　set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\

　　MSExchangeOWA’ -name TrustedClientTimeout

　　-value 1440 -type dword

　　既然此设置位于注册表中，那么如果需要，您当然可以使用 Regedit 自己更新此注册表项：

　　#include

　　with the registry.h>

　　#include

　　company we will ever be able to stop making

　　that standard disclaimer about mucking with

　　the registry.h>

　　不管怎样，您都需要重新启动 IIS，以确保 OWA 启用新设置。为此，只需选择“开始”|“运行”，然后运行 iisreset /noforce。

　　问：我们鼓励使用完整 MAPI Outlook 客户端工作的每一个人将所有不太急需的项目都存档到个人文件夹 (.pst) 文件中。但是，当用户从家中登录到 Outlook Web Access 时，已存档项目却不可用。如何才能通过 OWA 界面使用这些 .pst 文件?

　　答：我很遗憾地告诉您，OWA 不支持对 .pst 文件的访问。OWA 始终都是一个仅限联机使用的客户端。为确保不在本地计算机上留下任何个人数据痕迹，我们做了大量工作 – 其中包括首先在 Exchange 2003 中推出的安全注销机制和 Exchange 2007 中的 WebReady 文档查看等功能，WebReady 文档查看可确保缓存的附件副本不会留在硬盘上。因此从 OWA 访问 .pst 文件与我们使之成为一个易于部署的仅限联机使用的客户端的初衷不符。

　　尽管如此，但总的来说，.pst 的使用也是我们希望讨论的一个有趣话题。去年秋天我们碰到了一个客户，该客户分配给其用户的邮箱配额约为 200MB，并且几乎每个用户都至少有一个(如果不是更多).pst 文件。由于该组织的一项政策要求将消耗在擦除和更换用户计算机上的工作减至最少，因此所有用户都需要将其 .pst 文件存储在一个网络共享中。而该网络共享应由中央系统进行备份。

　　首先，从网络共享访问 .pst 文件时存在一些已知问题。正如 OWA 从一开始就被设计为仅限联机使用一样，.pst 文件从一开始就被设计为在本地存储。不管网络多么好，都会存在延迟等问题，而这都会导致数据远程存储(用户同时还需要访问这些数据)出现问题。

　　其次，该组织的邮箱配额有点小(必须得承认，我们奢侈地享受着大约 2GB 的企业邮箱)，这是因为它不想将所有邮箱数据都放在 Exchange 中(否则接下来 Exchange 就要负责备份所有这些数据)。但是，用户将 .pst 文件中的数据存储在由中央系统备份的网络共享中，管理员要做的工作实际上并未减少。事实上，很可能会由于各种因素而增加很多工作，例如：没有跨多个 .pst 文件的单实例存储、与 .pst 文件问题(如忘记密码和通常的网络扁平化)相关的支持人员成本、病毒攻击后难以清除 .pst 文件中的消息、出现法律问题时难以发现 .pst 文件中的消息、维护不同备份系统的开销等等。

　　因此我们奉劝您仔细考虑您的配置决策所涉及的各种成本。您可能会发现这些成本过高，而另一个配置最终可能会成为一个更好的选择。

　　问：我的 Exchange 命令行管理程序命令出了问题。它不运行了。这是怎么回事?

　　答：我们无法回答这个问题，但可以告诉您，为了得到最好的帮助(无论向谁求助)，您都应使用 Windows PowerShell 中称为 start-transcript 的内置 cmdlet 来记录您执行的命令以及得到的结果。然后将这些详细信息原封不动地粘贴到电子邮件消息、博客文章或论坛上的问题中。

　　打开 Exchange 命令行管理程序会话并键入 start-transcript，如图 2 所示。Exchange 命令行管理程序会自动开始将所有后续命令记录到一个类似如图 3 所示的文本文件中(不用担心，应用程序会告诉您该文本文件的位置)。若要停止记录，只需键入 stop-transcript。

　　

　　图 2 使用 start-transcript cmdlet 记录您所使用的命令及其结果

　　

　　图 3 Windows PowerShell 保存您所使用的命令的记录，并将其存储在一个 .txt 文件中

　　无论是谁帮您解决问题，您所使用的命令及所返回结果的完整列表都会提供巨大帮助。但在与您不认识或不信任的人共享该日志之前，一定要进行检查，确定其中是否包含可能已经返回的机密数据或敏感数据。

　　问：我看到 Exchange 2007 安装程序在根域中创建了一个新的组织单位 (OU)。其名称为 Microsoft Exchange 安全组，其中包含五个新的 Exchange 2007 安全组。能否将这些组移至其他 OU?能否移至其他域?

　　答：此问题涉及在 Active Directory 准备阶段在根域中创建的五个通用安全组 (USG)。这些组包括：

　　Exchange Organization Administrators

　　Exchange Recipient Administrators

　　Exchange View-Only Administrators

　　Exchange Servers

　　ExchangeLegacyInterop

　　在 Exchange 2000 和 Exchange 2003 中，(在 Exchange Domain Servers 和 Exchange Enterprise Servers 中)移动默认安全组的能力是有限的。更清楚地说就是您可以移动它们，但会中断正在进行的事务。(有关此问题的详细信息，请查看 support.microsoft.com/kb/260914。)因此这种能力确实非常有限。

　　在 Exchange 2007 中，情况就不同了。默认的五个组可以移动。您可以将它们移动到相同域的不同 OU 中，或者全部移动到其他域。

　　如果您“丢失”这五个组，而不知道将它们移到了何处(即哪个 OU 或域)，您可以随时检查下面容器上的 otherWellKnownObjects 属性的值：

　　CN=MicrosoftExchange,CN=Services,

　　CN=Configuration,DC=,DC=com

　　当组被移动时，此属性上相应的位置信息也会随之更新，这样您就可以随时了解组的位置了。太巧妙了!

　　问：我在我的域中发现了一个称为“Exchange Install Domain Servers”的全局安全组。它是干什么用的?

　　答：您肯定是在监视您的 Active Directory®。实际上，安装了 Exchange 2007 服务器的每个域中都会有一个称为 Exchange Install Domain Servers 的组。该组是在 Microsoft Exchange 系统对象 (MESO) OU 中创建的。如果您检查此组，您会看到它正在成为根域的 Exchange Servers 组的一个成员，Exchange Servers 组是一个通用安全组。

　　简明扼要地说，Exchange Install Domain Servers 是在某一子域中运行 Exchange 2007 安装程序时用于处理可能的 Active Directory 长复制循环的组。例如，假设您有一个名为 Root 的根域、一个名为 Child 的子域以及 Child 子域的一个名为 Grandchild 的子域。(我们知道，此命名方案是很逼真的!您一定能够猜得出吧?)

　　若要在此组织中开始安装 Exchange 2007，首先必须扩展该方案并准备您的 Root 域。这将创建我们在上一个回答中讨论的五个原始 USG。

　　接下来，假设您需要在 Grandchild 域中运行安装程序。为了能够在本地域中启动 Exchange 2007 服务，安装程序会将 Exchange 2007 计算机的一个计算机帐户放入 Root 域的 Exchange Servers 组中。但由于您现在是在 Grandchild 域中，Exchange Servers 组的成员身份复制可能需要一点时间。

　　Exchange Servers 是一个通用组，其成员身份复制是在整个林中进行的。由于存在潜在的复制延迟，Grandchild 域中的安装程序可能无法启动服务，因为安装完成之前不会复制权限。这就是在某个域中首次安装 Exchange 2007 服务器时，它会在本地域中创建 Exchange Install Domain Servers 组的原因。

　　Exchange 计算机帐户将会成为该组的一个成员(作为安装的一部分)。该组的成员身份为服务提供了足够权限以便在安装结束时进行启动(即使尚未从 Root 域复制 Exchange Servers 组的成员身份)。请注意，本地域复制通常比域间复制要快。

　　问：Exchange 2007 文档讲到运行安装程序时应使用 /PrepareLegacyExchangePermissions 开关(即使在针对 Exchange 2007 扩展架构之前)。这是为什么?(另外，您是否曾为此开关用过更长的名称?)

　　答：得知您在运行安装程序前阅读此文档我们感到很高兴。您觉得此文档如何?

　　/PrepareLegacyExchangePermissions(或缩写为 /pl)是一个开关，明确地说，它为 Exchange 2000 和 Exchange 2003 收件人更新服务 (RUSes) 提供写入 Exchange 信息属性集和 Exchange 个人信息属性集的权限。在 Exchange 2007 架构扩展过程中，有些属性(如 Proxy Addresses)会从 Active Directory 公共信息属性集移动到 Exchange 信息属性集。默认情况下，Exchange 2000 和 Exchange 2003 RUSes 没有写入 Exchange 信息属性集的权限。实际上，这意味着如果先运行 Exchange 2007 架构扩展，则会中断 Exchange 2000 和 Exchange 2003 RUSes，因为它们将不能标记任何新的收件人!(要阅读有关这些属性集的详细信息，请转到我们的博客 msexchangeteam.com。)

　　因此，扩展 Exchange 2007 架构之前运行 /pl 开关非常重要。您还应确保将此更改复制到具有 Exchange 2000 或 Exchange 2003 收件人的所有域(因此这些域存在 RUSes)中。如果稍后向林中添加新域，并且需要将 Exchange 2000 或 Exchange 2003 RUSes 放入这些域中，则也应在这些域中运行 /pl 开关。

　　这样的话，在首次运行 /pl 开关时，如果使用具有 Enterprise Admin 权限的帐户运行此开关，情况会简单得多。然后，根域的安装程序会识别哪些域需要运行 /pl，并会在所有这些域上运行 /pl 开关。如果不使用 Enterprise Admin 帐户，则必须使用 Domain Admin 对每个域单独运行 /pl 开关。所幸的是，Exchange 2007 文档列出了所有权限要求。

　　最后，您问我们是否曾为此开关用过更长的名称。比如连续重复三遍 /PrepareLegacyExchangePermissions：

　　PrepareLegacyExchangePermissions

　　PrepareLegacyExchangePermissions

　　PrepareLegacyExchangePermissions

　　我们想过使用 /Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname，但随后我们还是选择了更短和更友好的 /PrepareLegacyExchangePermissions。

　　好了，我们就用它了。但您还可以使用更短的 /pl。就是它了 - 我们保证!