第 3 章计划新邮件服务器时要解决的问题

您的用户是否都处于同一物理地理位置，即是否都在一个建筑物中？是否都在同一层楼上？是否都在同一房间中？或者您在圣路易斯 (St.Louis) 是否有总部，在丹吉尔 (Tangiers)、巴塞罗那 (Barcelona) 和奥什科什 (Oshkosh) 是否有分支管理机构，在新加坡 (Singapore) 和塔城 (Tuscaloosa) 是否有工厂？在当前的电子邮件系统中，每个位置有多少 Exchange 服务器和用户？迁移后，每个位置有多少 Sun Java System 服务器将为用户服务？

在当前的电子邮件系统中，如何将用户分配到各种 Exchange 服务器？仅按地理位置分配？按组织内的管理实体分配，例如，销售部门、工程部门与客户服务部门等等？或者按业务单位或小组分配，例如产品 XYZ 小组与产品 ABC 小组？

各用户的教育和培训背景？他们使用电脑有多长时间？在迁移过程中他们有多大可能需要管理员或服务台的“临场指导”？

用户分组标准和含义

确定一次迁移的最佳用户数。最佳的迁移组大小将部分取决于服务器上每个用户的数据量。迁移组大小应该与企业服务台的大小和可用性相关，因为您可以假设将需要服务台协助的最小用户百分比。

最开始的几个迁移组应小于预期的最佳大小，因为在较大的组形成相应较大的结果前，最初的这些组很可能将暴露出无法预料的文档问题和通信计划问题等。最初几个较小的迁移组还将帮助您预测组织的服务台对以后较大迁移组的需求。

最后，迁移逻辑组中的用户通常是有帮助的，它们在业务功能或管理实体或临近组方面相关，因此在迁移过程中可以相互支持。

桌面安装方法

Sun Java System Connector 部署工具包包含各种工具，其中有很多操作选项，可以通过这些选项针对大多数环境和管理员偏好来设计和实现适当的迁移策略。下列主题描述了最常用的方案，并解释了 Sun 的迁移工具如何适应这些方案。

交互用户安装（自助式）

Sun Java System Connector 安装向导简单易懂，便于最终用户自己运行。可以将安装向导放在文件服务器上，这样就不需要在最终用户工作站上单独安装。但是，将 Java System Connector 软件物理安装在用户桌面上要求的访问权限，在通常情况下对很多或大多数最终用户都是禁用的。如果其中有任何一个最终用户不具有在自己桌面上安装的权限，那么可能需要选择以下两个策略之一：

访问每个用户的工作站并使用自己的管理员权限将软件物理安装到用户的桌面。

使用配置管理工具（如 Microsoft 的 SMS）将软件“推送”到多个用户桌面（在下面的“通过 SMS 或其它配置管理工具进行自动化‘推送’”中进行说明）。

将软件物理复制到用户桌面后，用户即可运行安装向导来配置软件并转换现有的个人文件夹 (.pst) 文件。

运行转换程序的最终用户将向 Sun Java System 服务器提供自己的凭证。因此该方法允许转换有口令保护的 .pst 文件（请参阅下面的“Outlook 中有口令保护的个人存储”），用户还可以指定应该转换哪些个人存储以便与新的 Sun Java System Connector 软件一起使用。（用户可以阅读未转换的电子邮件，但是无法答复这些邮件，因为新服务器不熟悉未转换的地址。对于具有一些较旧个人存储的用户而言，很可能以后需要答复这些邮件，因此最好保留这些文件不转换。转换可以在后台运行，这样用户的计算机可以做其它工作，但是转换过程很可能降低其它应用程序的性能。）

从组织的服务台寻求支持的需求在增加，这可能很大程度上取决于用户的技能及网络配置“前”和配置“后”的复杂性。

您作为管理员，在访问多个用户工作站以将软件物理复制到用户桌面（对于尚未得到相应授权以便自己执行该任务的用户）时，必须投入的时间和努力。

管理员在用户计算机上执行安装

您可能希望让某些用户进行如上所述的“自助”安装；但是指派管理员访问其它用户的桌面，以便为他们执行部分或全部安装和配置任务。对于那些自己准备执行任务有困难的顶层主管或非技术用户而言，该方法可以确保平稳地迁移。部署计划应该指出是否许可管理员对组织中的任何用户及哪些用户进行此类访问。

通过 SMS 或其它配置管理工具进行自动化“推送”

在用户桌面上安装软件要求的访问权限，在通常情况下对很多或大多数用户都是禁用的。这些网络的大多数管理员使用配置管理工具（如 Microsoft 的 SMS）将软件“推送”到多个用户的桌面，这种方法可以回避对用户访问权限的要求。如果网络使用的是最终用户无法安装软件的“锁定”Windows 环境，则这种自动化配置管理可能减少管理员对单个用户桌面的访问次数。

为了成功执行“推送”分发，可以使用部署配置程序来为每个用户建立两个不同的捆绑安装软件包，以便连续执行。第一个软件包将对必需的 Sun Java System 软件执行“推送”安装，而第二个软件包将运行交互过程，用户可以由此选择已安装软件的配置和他（她）们现有数据文件的转换。甚至可以使用该“推送”方法来完全自动化最终用户的转换过程，但是需要某些脚本，因为必须通过特定于每个最终用户的信息（如用户的 Sun Java System 凭证）来调用软件包。

部署配置程序的《参考》提供了使用 Microsoft 的 SMS 来执行该软件“推送”分发方法的说明。《参考》还解释了如何使用带有 SMS 脚本的命令行开关，并通过将用户个人文件夹 (.pst) 文件的必需用户口令传递到桌面安装程序来将该过程完全自动化。

桌面安装的命令行开关

Sun Java System Connector 安装向导支持命令行开关，这些开关可与上述其它桌面安装方法或《Sun Java System Connector for Microsoft Outlook Deployment Configuration Program Reference》中“Application Notes for Special Circumstances”章节下面描述的 SMS 脚本组合起来使用。

/USERNAME=xxx，其中 xxx 是 Sun 服务器上的用户名
/PASSWORD=xxx，其中 xxx 是 Sun 服务器上的口令
/FULLNAME=xxx，其中 xxx 是用户的显示名称
/EMAILADDRESS=xxx，其中 xxx 是用户的电子邮件地址
/DN=xxx，其中 xxx 是 Sun 服务器上的用户 DN
/NEWPROFILENAME=xxx，其中 xxx 是已创建配置文件的名称
/SAVEPASSWORD=n，其中 n = 1（保存）或 0（不保存）

/OLDDOMAIN=xxx，其中 xxx 是 Exchange 域
/OLDUSERNAME=xxx，其中 xxx 是 Exchange 用户名
/OLDPASSWORD=xxx，其中 xxx 是 Exchange 口令

迁移重要的服务器数据：不只是邮件

旧的服务器包含用户的重要信息，有效的迁移将提取并使用该信息来为新的 Sun Java System 服务器提供用户帐户。除了用户的旧电子邮件外，旧的服务器还包含用户日历、任务、个人通讯录和联系人。旧的服务器还包含用户名、主要的 Internet 地址、Internet 别名、电话号码、邮政地址，甚至还有描述性信息（如用户的部门、职务等等），还有企业的所有公共通讯组列表。

尽管详细的服务器数据迁移量不在本文档的讨论范围，您还是应该知道旧的服务器是重要的数据资源，可以挖掘这些数据资源以便在 Sun Java System 上提供用户帐户和邮件传送过程中有更改时使用。Sun 专业服务可帮助您了解和使用部署计划中的服务器数据迁移，而且第三方公司将提供技术和专家意见来推动服务器数据的迁移。

服务器迁移传输阶段的邮件传送

并非所有用户都将同时从旧的服务器迁移到新的服务器。在新服务器上创建和提供了用户帐户后才进行用户的实际迁移。同样，具有相同地址的用户邮箱将在传输阶段同时驻留在新旧服务器上。因此必须定义某些临时的邮件转发规则以确保传输过程中用户的邮件传送正确。

即使组织正在实现新的 Internet 地址，旧的地址也必须保留在旧服务器上，因为只有当用户旧的主 Internet 地址继续传送到正确的服务器时才可以传送较旧邮件的答复。由于指定域的所有 Internet 邮件都必须转到在相关 MX 记录中指定的单个服务器，因此组织必须确定何时更新其 MX 记录以指向新的 Sun Java System 服务器。

如果在传输开始阶段将 MX 记录切换到 Sun Java System 服务器，则必须配置 Sun Java System 服务器，以便将无法传送到本地邮箱的所有邮件都发送到旧服务器上的相应邮箱。此外，在 Sun Java System 服务器上提供新用户时，必须在新服务器上定义转发规则，这样将正常传送到新邮箱的任何邮件才能转发到旧服务器上的相应用户邮箱。当每个用户都迁移到新服务器后，必须删除新服务器上的第一个转发规则，并在旧服务器上定义新的规则以将所有用户邮箱都转发到相应的 Sun Java System 邮箱。

另一方面，如果在传输阶段结束前 MX 记录都将指向旧服务器，则必须将旧的服务器配置为发送那些无法本地传送到 Sun Java System 服务器上相应用户邮箱的邮件。用户迁移到新服务器后，必须在旧服务器上定义新的规则以将旧服务器上其它用户发送的邮件转发到该用户在 Sun Java System 服务器上的新帐户。

迁移过程中同步全局通讯录

大型组织很可能要求数周或数月完成分阶段的迁移工作，在传输过程中两个系统上都会有一些用户。很多组织希望所有用户都能访问准确的企业目录（白皮书、全局通讯录），但是准确性要求在雇用、调动、辞退员工时对两个服务器目录进行定期同步。因此部署计划应该指定某种机制，以便在传输阶段定期同步两个目录。

Sun 专业服务可帮助解决该问题。还有另外几个产品可执行目录同步。

Sun Java System 服务器的新用户 ID 和口令

大多数网络系统都设计为防止其它人发现用户口令，对于 Microsoft Exchange 尤其如此。这些安全措施使得从旧服务器迁移到新服务器时无法自动保留用户的现有口令。

同时，很多组织都希望对他们的 Internet 地址形式进行标准化，或者在迁移到 Sun Java System 过程中合并域。因此组织必须提前决定如何派生帐户名和 Internet 地址、如何分配用户的新口令。

网络管理员还必须设计一种方法，将这些用户凭证传达到用户和公司服务台。一种常用的方法是只需在组迁移前准备电子邮件合并，这样在迁移组首次登录到新服务器时，该组的每个成员都将及时地单独收到自己的凭证。

Outlook 中有口令保护的个人存储

Outlook 用户可以将口令分配给个人文件夹 (.pst) 文件，但是 Sun Java System Connector 安装向导需要打开和修改这些文件，以便将它们转换成可与新的连接器软件和 Sun Java System 服务器一起使用。因此最终用户必须为要转换的所有 .pst 文件提供口令。

安装向导将在必要时自动提示用户输入必需的口令，显然这需要用户的参与，因此不可能进行无提示模式安装。如果对您来说以无提示模式运行安装向导很重要，系统将在转换过程中指示您删除所有这些口令，或者只需通过适当的口令运行向导。如果安装向导在无提示模式中运行，而且遇到了有口令保护的文件，则它不会转换该文件，并将报告未转换所有的文件。取决于管理员的部署配置工具中的设置，安装向导还可能记录错误事件。