我们发现了一个异常行为，似乎与邮件附件的大小有关。当我将一封附带了一个附件（假设 11MB）的电子邮件发送给外部用户时，收件人如期收到了邮件。但如果将此邮件（包括附件）转发回内部网络中的发件人，发件人却收到了一份发送失败报告 (NDR)，指明此邮件大小超出了当前系统限制或收件人的邮箱已满。
仔细研究问题后我们发现：在邮件离开组织的某个时候，附件大小增加了约 30%。我想知道，通过 Internet 发送和接收电子邮件时附件大小为什么会增加？更重要的是，这种现象正常吗？
答：简单地说，是。这种现象通常是预料之中的，不仅对 Exchange Server 2007 是这样，而且对 Exchange Server 的早期版本以及任何其他支持 MIME（多用途 Internet 邮件扩展）和使用 Base64 对附件进行编码的消息传递系统都是这样的。内部 Exchange 用户向 Exchange 组织内的收件人发送的邮件不需要执行任何内容转换。这意味着在传送过程中您是看不到邮件或附件的大小增加的。而发送到外部收件人的邮件可能需要执行内容转换。
标准 SMTP 邮件（也称为纯文本邮件）包含邮件信封和邮件内容—邮件标题和邮件正文。这些元素以 7 位 US-ASCII 纯文本为基础。当邮件包含非 US-ASCII 纯文本的元素时，必须对元素进行编码。处理这类非文本内容（包括附件）时，使用 MIME 进行编码。Exchange 2007 和早期版本的 Exchange Server 使用 Base64 算法对附件进行编码。Base64 的缺点是它会使附件的大小增加 33%。
在 Exchange 2007 中，除使用 Outlook Web Access 外，其他大部分与传输相关的内容转换均在集线器传输服务器上执行。有关更详细的解释，请参阅 technet.microsoft.com/library/bb232174 上的主题“了解内容转换”。
问：我们正在从 Exchange 2003 向 Exchange 2007 过渡。我们已经将所有用户邮箱都迁移到了 Exchange 2007 邮箱服务器，所有服务器均已使用群集连续复制 (CCR) 进行了配置。目前，我们正在将所有公用文件夹从原有的 Exchange 2003 公用文件夹服务器复制到基于 CCR 的邮箱服务器上。但是，我们在测试中发现，当 CCR 群集上出现数据丢失故障转移时，其他节点上的公用文件夹数据库就不会联机。故障转移后，我们也无法对其进行手动装入。
我们拥有可以镜像生产环境中 Exchange 2007 基础结构的实验室环境，测试显示这里也出现了同样的问题。在发生故障转移的任何 CCR 群集上，任何邮箱数据库中都没有这一问题，因此这似乎与 CCR 群集上的公用文件夹数据库有很大的关系。我们想对所有数据库（包括公用文件夹数据库）实现真正的冗余，您能帮我们剖析一下导致这种行为的根源吗？
答：CCR 使用的复制方法与 Exchange 2007 中公用文件夹复制所使用的方法截然不同。因此，如果其中一个公用文件夹数据库在基于 CCR 的邮箱服务器上托管，建议您不要将 Exchange 组织内的多个公用文件夹数据库与基于 CCR 的邮箱服务器合并在一起。在过渡期间您可以实际这样操作，Exchange 产品组支持将公用文件夹数据库托管在基于 CCR 的邮箱服务器上（例如，原有的 Exchange 2003 服务器）。但强烈建议您在复制完所有公用文件夹数据后删除非基于 CCR 邮箱服务器上的公用文件夹数据库。
您在 Exchange 消息传递环境中遇到的问题属于正常现象。如果您有多个公用文件集数据库，而其中一个托管在基于 CCR 的邮箱服务器上，则在故障转移（即非计划中断）时，基于 CCR 的邮箱服务器上的公用文件集数据库将会脱机。
实际上，在上一个主动节点再次出现之前，无法使公用文件夹数据库联机。此外，对于托管公用文件夹数据库的存储组，所有事务日志文件都必须可用。
如果不具备这种条件，那就应该考虑从上一个完好的备份中还原公用文件夹存储，浏览可用日志，然后从还原的数据库为其他节点重新设定种子。或者，也可以从头开始创建公用文件夹存储。在这种情况下，必须恢复原始的主动节点、新建公用文件夹数据库，并从 Exchange 组织内的其他公用文件夹服务器中复制公用文件夹数据。
颇有些奇怪的是执行无损（有计划）中断时公用文件夹数据库处于联机状态。这是正常的表现。有关详细信息，请参阅规划群集连续复制上的“群集连续复制和公用文件夹数据库”。
问：在我们基于 Exchange 2007 的消息传递基础结构中，所有邮箱服务器都是使用 CCR 配置的。我们对 CCR 的工作方式非常满意，但希望您可以解答一个问题。
每晚进行联机维护时，我们要联机整理碎片。我们如何确保 CCR 群集内被动节点上的数据库在联机维护期间可以完成碎片整理。
答：在此过程中联机碎片整理任务（删除所有标记为移除的项，然后将这些项占用的空间变为可用空间）会生成新的事务日志文件。在 CCR 主动节点上生成所有的事务日志文件都会被复制到被动节点，造成其上数据库的更改。
明确这一点后，请确保计划联机维护时间，以免与您的备份时间发生冲突（因为这会强制联机碎片整理中断）。就这一点而言，并不需要每天、每周、甚至每隔一周进行碎片整理。以前，Exchange 产品组指南中规定联机碎片整理至少每隔一周进行一次。但因每个组织的环境不同，随着 Exchange Server 2007 SP1 的推出，情况发生了变化。有关该新指南的详细信息，请参阅 Microsoft Exchange 团队博客上的帖子。
问：我们计划使用 Exchange 2007 CCR 实现邮箱服务器的真正冗余。目前，我们正在研究如何与 CCR 结合使用传输转储程序，以确保在从 CCR 主动节点向被动节点进行丢失数据故障转移时不会丢失任何邮件。您知道哪些需要我们注意的传输转储程序问题吗？
答：传输转储程序可确保在从使用 CCR 的 Exchange 2007 邮箱上的一个节点向另一个节点进行丢失数据故障转移时，数据的损失最小。这可以通过重新传送最近提交至邮箱服务器的邮件来完成。在丢失数据故障转移期间，您很有可能会丢失一些事务日志文件，并还会因此丢失实际数据。如前所述，传输转储程序重新传送最近提交至邮箱服务器的邮件，从而确保能够恢复丢失数据故障转移期间损失的数据。不过，由于传输转储程序驻留的集线器传输服务器只传送邮件，因此在即将进行丢失数据故障转移时创建的某些数据将会丢失，例如任务和日历项等。
问：目前我们正计划从 Exchange 2003 组织向新 Active Directory 林中的 Exchange 2007 组织进行跨林迁移。我们广泛研究了跨林迁移文档“如何从单林向跨林过渡”，该文档指出应该建立林信任而不是在各林之间建立外部信任。为什么不能使用外部信任？
答：尽管 TechNet 杂志上的 Exchange 2007 文档指出您应该使用林信任而不是外部信任，但这并不意味着您不能使用外部信任。实际上，虽然外部信任非常适合跨林 Exchange 迁移，但它有一个缺点。由于您不能使用已登录用户的凭据（无论为其分配了哪些权限），因此在创建链接邮箱时您必须指定一个具有适当权限的帐户，用于访问受信林中的域控制器（参见图 1）。
图 1 创建链接邮箱时在“Master Account”（主帐户）页面上指定一个帐户
问：我们的组织刚刚过渡到 Exchange 2007，到目前为止我们对新版本非常满意，只有一个例外。当初我们在使用 Exchange 2003 SP2 时，能够将我们的环境配置为将用户邮箱的简单显示名做为出站邮件的发件人显示。遗憾的是，在 Exchange 2007 中找不到类似的功能。Exchange 2007 中千万不要没有该功能！
答：Exchange 2007 RTM 中确实缺失了这一功能，之后在 2008 年 10 月发布的 Exchange 2007 SP1 Rollup Update 4 (RU4) 中才得到了修正。利用 SP1 RU4，您可以再次将 Exchange 配置为在出站邮件中显示简单显示名，效果同使用 Exchange 2003 SP2 一样。此任务可以使用 Windows PowerShell Set-RemoteDomain cmdlet 和参数 –UseSimpleDisplayName 完成。例如，要在发送到 contoso.com 域的出站邮件上启用简单显示名，请使用图 2 中所示的命令。
图 2 将简单显示名用于出站邮件
问：对基于 Exchange 2007-CCR 的邮箱服务器中被动节点上的数据库副本进行碎片整理时，有什么最佳做法？如果对 CCR 中一个节点上的数据库进行了碎片整理，但未对其他节点上的数据库执行此操作，会不会令 Exchange 产生混淆？
答：如果需要脱机整理碎片，那么应始终在 CCR 群集中的主动节点上执行，切勿使用被动节点。还请注意，如果您对主动节点上的一个或多个数据库执行了脱机碎片整理，则必须对被动节点上的特殊数据库彻底重新设定种子。
举例来说，如果您有一个 200GB 的数据库（若使用 CCR，通过超过 1GB 的网络复制时建议的数据库大小为 200GB），对其进行碎片整理将需要几个小时（好的经验法则是每小时2-4GB）。但在完成碎片整理后，您还将需要将 200GB 的数据复制到被动节点上。如果通过公共网络传送日志文件，这会影响您最终用户体验到的网络整体性能。
在大多数情况下，执行脱机碎片整理的目的是要删除数据库中的所有空白区域，以便减小数据库的大小。但由于空白区域在数据库进一步增大之前就会被重新使用，通常没必要这样做。数据库中或磁盘本身是否有可用空间并不重要，明白了吗？
如果在数据库中有许多千兆字节的空白区域，而您想将其删除，那么更好的方法是将全部邮箱移出该数据库，移入一个新的数据库内。
Henrik Walther 是一名 Microsoft 认证架构师：Exchange 2007 和 Exchange MVP，而且具有 14 年以上的 IT 从业经验。他是 Interprise Consulting（位于丹麦的 Microsoft 金牌合作伙伴）的技术架构师，同时身兼 Biblioso Corporation（一家专门从事托管文档和本地化服务的美国公司）的技术撰稿人。