脱机文件夹存储 (.OST) 文件包含用户的 Exchange 文件夹（专用的和公用的）和窗体的本地副本。.OST 存储在用户的本地驱动器上，并且与
Exchange Server 副本保持同步以便脱机使用。一个 .OST 特定于一个指定的邮箱，而其他 Exchange 用户无法访问它。
当登录到 Exchange Server 时，.OST 可以包含可供用户使用的文件夹的子集。当用户不再与服务器相连时（当他们在办公室外使用便携计算机时会出现这种情况），.OST
将允许他们访问任何公用文件夹及其专用信息存储中的文件夹。用户可以将邮件添加到公用文件夹，并从专用信息存储文件夹发送或删除邮件。当他们下一次登录到该服务器时，.OST
将与服务器上的服务器信息存储同步，但 .PST 文件则不进行同步。
.OST 是脱机存储的首选方法，因为在脱机工作时它允许使用公用文件夹和单位的窗体。因为 .OST 充当了 Exchange 文件夹的副本，所以可以在标准的
Exchange Server 备份过程中捕获数据。而本地 .PST 在大多数情况下只能由其所有者备份。.PST 允许使用 Exchange 客户端远程电子邮件功能：
下载邮件头信息、移动或复制邮件、下载以前删除不想要的邮件、下载其它邮件的同时阅读新邮件。.OST 同步进程不是多线程的。
对那些经常在办公室以外使用便携计算机的用户来说，.OST 是很有用的。他们应当将自己的 .OST 存储在他们的本地驱动器上，并知道如何手动使 .OST
信息与信息存储保持同步。对 .OST 用户有用的其它过程分别解释如下：
如何压缩 .PST
- 打开邮件控制面板。
- 选中“个人文件夹”服务并单击属性按钮。
- 单击开始压缩按钮。
.OST 同步日志
完成 .OST 同步时，“已删除的邮件”文件夹中会出现一个日志文件。如果您要查找同步细节和错误，则可以查看该文件。下面是一些错误和可能的原因：
表 7 .OST 错误代码和典型原因
8004010f
|
在创建了 .OST 后，用户已经更改了 Organization
Forms 注册表的语言。
有两个 Exchange Server 站点： 第一个有 Organization Forms 注册表，而第二个没有。如果没有正确设置公用文件夹关系，当第二个站点中的用户试图打开
Organization Forms 注册表时，他们将收到该错误消息。
用户添加了一个 Organization Forms 注册表，但随后被删除。
|
80030070
|
磁盘上没有可用空间。清空硬盘驱动器空间，然后再试一次。当试图同步大型附件时可能发生该错误。
|
80040115
|
这是个网络错误，它阻止操作的成功完成。执行基本的 RPC 网络故障排除操作。
|
从 Microsoft Exchange Server 删除了用户的邮箱
一个 .OST 包含邮箱的唯一 ID 标记，所以，如果在运行 Exchange Server 的计算机上删除了用户的邮箱并创建了新邮箱，那么 .OST
文件将不与新邮箱同步。要恢复 .OST 中的数据，必须在联机启动客户端之前立即执行如下步骤：
- 以联机模式启动 Exchange 客户端，在此过程中使用与以前用于 .OST 相同的配置文件。
- 将 .PST 添加到该配置文件。
- 将邮件复制到 .PST。
- 创建连接到新邮箱的新配置文件。
- 将邮件从 .PST 移动到新邮箱。
用于客户端的服务器端优化技术
网络配置
请确保您已经安装了最新的 Windows NT Server Service Pack
在较早版本的 Windows NT 网络支持文件中存在几个已知问题，这些问题可能会影响 Exchange 邮件客户端性能。在下列 Knowledge
Base 文章中详细说明了两个这样的问题：
- Q161938，标题： Slow Exchange client logons in due to resource deadlock
- Q149819，标题：RPC Causes Exchange Server to Hang All Connected Clients
使用 IPX/SPX 将客户端连接到 Exchange Server
在以 Novell NetWare 网络组件为主、且大多数工作站已经配置和优化以便用于 IPX 传输的环境中，使用 IPX/SPX 作为 Exchange
邮件协议可能是最好的选择。当您在这种类型的网络环境中配置 Exchange 服务器和客户端时，请考虑如下几个提示。
在 Novell 网络内的 Exchange 服务器名称解析：
当 Microsoft 邮件客户端试图在 Novell 网络上找到运行 Exchange Server 的计算机时，它将尝试定位用于 Exchange
Server 名称解析的文件服务器。它将为此发送一个 SAP“最近服务查询”数据包来找到最近的 NetWare 文件服务器。它获得响应的方式有两种：
- 如果文件服务器与客户端同在一个子网上，则该服务器将作出响应。
- 当且仅当路由器相信客户端子网上不存在服务器时，将由路由器代表其它子网上的服务器作出响应。
一旦找到 NetWare 文件服务器，它的平构数据库就会用于将运行 Exchange Server 的计算机名转换成 IPX 地址。
如果虽然 Exchange 服务器与客户端在相同的子网上，但该 Windows NT/Exchange 服务器中定义了内部 IPX 网络编号，那么
Windows NT 服务器将表现为好象是在其它子网上。换句话说，运行 Exchange 服务器的 Windows NT 服务器将充当 IPX 路由器，并对“最近服务查询”数据包作出响应。
详细信息，请参见 Knowledge Base 文章 Q162010，标题为： Exchange Server Name Resolution on
a Novell Network。
配置 Exchange Server 以便支持 IPX/SPX
在 Exchange Server 上配置 NWLink IPX/SPX 以便支持多种帧类型时，必须配置 IPX 使之具有唯一的内部网络编号。如果不这样，使用
IPX/SPX 的 Exchange 客户端可能在连接到服务器时遇到问题，尤其是当发送或保存带有附件的邮件时。
在 Windows NT Server 3.51 中配置内部网络编号
- 在控制面板中，双击网络图标。
- 在已安装的网络软件列表中，选择 NWLink IPX/SPX 兼容传输。
- 单击配置。
- 在内部网络编号框中键入唯一的 8 位数。
- 单击确定。
- 重新启动 Windows NT Server。
在 Windows NT Server 4.0 中配置内部网络编号
- 在控制面板中，双击网络图标，然后单击协议选项卡。
- 在网络协议列表中选择 NWLink IPX/SPX 兼容传输。
- 选择属性。
- 在内部网络编号框中键入唯一的 8 位数。
- 单击确定。
- 重新启动 Windows NT Server。
公用文件夹服务器和客户端访问考虑事项
Microsoft 邮件客户端（位于 A 站点的 Exchange 服务器的收件人）可能临时停止响应，或者您可能多次被提示要求输入特定域的域信任凭据，该特定域包含拥有
Organization Forms 文件夹（B 站点）的 Exchange 站点。当您试图打开读回执、投递回执或未投递报告 (NDR) 时，也会出现域信任凭据对话框。
当满足如下所有条件时，系统将提示您输入域信任凭据：
- 已经创建了 Organization Forms 文件夹。
- 已经在站点之间建立公用文件夹关系。
- 不存在 Organization Forms 文件夹的本地实例。
其它症状包括：
- 当试图打开读回执、投递回执或未投递报告时，A 站点（远离 B 站点）中的客户端的速度减慢，但 B 站点中的客户端可以按正常速度打开这些回执。
- 当为 B 站点设置了亲和关系，但 A 站点中的客户端没有通过 LAN 物理连接到 B 站点中的服务器时，两个站点中的客户端都会在试图打开读回执、投递回执或未投递报告时速度减慢。
- 当只包含 Organization Forms 文件夹的实例的服务器在网络上不可用时，A 站点中的客户端将提示输入域信任凭据，但 B 站点的客户端不作该提示。
- 当 A 站点和 B 站点的 Windows NT 域之间不存在信任关系，并且 A 站点客户端试图访问 B 站点服务器上的 Organization
Forms 文件夹时，系统将提示用户输入 B 站点中有效的 Windows NT 帐户的域信任凭据。
该行为是由设计所致。要避免它，请确保每个站点均有一个自己的 Organization Forms 文件夹实例。详细信息，请参见 Knowledge
Base Q157632，标题：XADM: Client Hangs or Prompts for Domain Credentials。
Exchange Server、IIS 和 OWA 客户端
对使用 Outlook Web Access 组件（Internet 浏览器，访问它们提交给 HTML 的邮箱）的客户端的性能考虑不同于基于 Exchange
和 Outlook MAPI 的客户端。由于大多数实际的处理工作是在 Exchange 和 IIS 服务器上完成的，所以性能和优化必须同时在服务器端上进行。
Outlook Web Access 网络通讯考虑事项
- 初始的客户端登录通讯量比基于 MAPI 的客户端套件大：每个客户端登录需要大约 65.195K。
- 发送邮件通讯将会使 IIS 服务器产生 30K 响应，这与邮件大小 (1,10, 100K) 无关，并且在客户端并没有压缩邮件正文。
- 在客户端发生了非常小的项目缓存：没有邮件，只有屏幕项目（这是每个浏览器默认的）。
Outlook Web Access 优点
- 不安装客户端软件 - 大大减少了管理成本和资源。
- 在客户端无配置维护 - 减少了管理邮件环境所需的时间和资源。
- 按需要创建配置文件 - 更容易实施远程和粗略的客户端配置。
请记住，客户端内存资源可能是个问题（很多浏览器窗口/会话等）。
Outlook Web Access 服务器大小
IIS 服务器可以独立于 Exchange 服务器进行配置，并且多个 IIS 服务器可以主持对单个 Exchange Server 的访问。
服务器执行所有针对客户端的操作（HTML 提交等），所以建议采用相对较低的用户/IIS 服务器比率。
下面是对每个运行 OWA 的 Exchange IIS 服务器上“轻量级”用户（一天发送 1 到 3 封邮件并回复 5 封）数量的一些经验性建议：
- 带 IIS 3.0 的 Exchange 5.0-300 个并发用户
- 带 IIS 3.0 的 Exchange 5.0 SP1-600 个并发用户
- 带 IIS 4.0 的 Exchange 5.5-800 个并发用户
这些数字来自如下测试配置：P166 双处理器计算机；256 MB RAM；IIS 和 Exchange 服务器同时运行在相同计算机上。在单独的计算机上运行
IIS 和 Exchange 时，处理器使用率稍微有所降低。
并发的 OWA 用户/服务器受到可用于 Windows NT 的可寻址内存空间的限制。无论是否会完全使用，每个 MAPI 会话均分配了一定数量的地址空间。通常，大约
800 个并发用户将使用全部可用空间。
上面的数字是针对“轻量级”用户的。增加 IIS 服务器的数量可增加用户的总体数量，但它们之间不是正比关系。测试表明，OWA 可以处理最多 800
个轻量级用户/服务器；而经验表明，“重量级”用户应当限制在大约 100 个以内。
当您安装 Outlook Web Access 时，应当安装 Windows NT 的最新修补程序，以便解决安全套接层 (SSL) 和内存漏洞中存在的问题。可以从如下位置下载它：
ftp://ftp.microsoft.com/bussys/iis/iis
-public/fixes/usa/ASP/asp-memfix/
这个自解压的压缩文件名为 ASP-MEMFIX.EXE。详细信息，请参阅 Knowledge Base 文章：
- Q176245，标题：XWEB: VBScript Error when Accessing Outlook Web Access Server
- Q176246，标题： XWEB: Unexpected Behavior when Accessing Outlook Web Access
服务器容量计划
进行 Exchange server 容量计划的最好资源是 TechNet 上的白皮书“MS Exchange 性能： 每个服务器的并发用户数”。它定义了影响
Exchange 服务器容量计划的因素，并解释了它们如何影响现有的基础结构。该白皮书还展示了几个基本的用户/服务器配置范例，并提供了一些数据（这些数据来自
Exchange Performance Team 的测试）可以应用到容量计划工作中，或应用到对您的并发用户/服务器数据的综合评估中。
服务器调节和维护
根据硬件、操作系统和 Exchange Server 系统参数的不同，在负载之下的系统性能会有巨大的变化。例如，您的硬件配置可能允许您启用或禁用辅助处理器缓存，或允许您配置磁盘分带、制作镜像和进行奇偶校验。Windows
NT Server 允许您更改各种设置，如来自系统分页文件的可用虚拟内存数量、前台和后台应用程序的任务选项、网络协议设置等等。
检验您的优化工作的最好工具是 Exchange Performance Optimizer。该程序在 Exchange Server 安装程序结束时自动运行。但极其重要的一点是，每当您的服务器硬件、系统设置或使用模式发生更改时，都应当再次运行该程序。例如，如果您给服务器添加了
RAM，那么只有等您重新运行 Performance Optimizer 之后，Exchange Server 才能利用它。请参见《Microsoft
Exchange Server 5.5 Resource Guide》的第 10 章“Optimizing Performance” (pp. 194-7)，以获得有关使用
Performance Optimizer 的详细信息。
