bitsCN.Com 注意，由于公共文档夹存储中可能包含大量的空白空间，因此公共文档夹存储数据库的实际大小有时可能并不会增加，即便是其中已存储了越来越多的内容。
www_bitscn_com
假如对公共文档夹存储是否是导致创建事务日志的邮件的收件人这一问题存有疑问，请执行以下步骤：
bitsCN.nET中国网管博客
| • | 在邮件跟踪日志文档中，检查“top recipients”（主要收件人），并查看“<SERVERNAME>-IS@EXAMPLE.COM”是否是主要收件人之一，这里的 example.com 是您的域名。在运行 Exchange 2000 Server 或更新版本的服务器上，此地址是 MAPI 公共文档夹存储的默认 SMTP 地址。由于公共文档夹复制邮件是从一个存储发送到另一个存储，因此他将作为接收复制邮件的地址，而不是单个公共文档夹的地址。 bitsCN_com |
| • | 检查诊断日志记录是否已开启。能够开启针对公共文档夹复制邮件的诊断日志记录，了解服务器是否因此而不堪重负。若要开启日志记录，请找到 Exchange System Manager 中的服务器对象，并在诊断日志记录选项卡中开启日志记录： bitsCN.nET中国网管博客 ?????MSExchangeIS > 公共文档夹> 复制传入邮件（将其配置为最大值）。 www.bitsCN.com 假如服务器收到大量公共文档夹复制邮件，则能看到大量的 MSExchangeIS Public Store 事件，这些事件的事件 ID 在 3028 和 3030 之间（这些是最常见的 ID）。 bitsCN_com |
小心：
假如管理员的确认为存在不正确的公共文档夹复制，他（或她）应立即删除那些想要删除的副本。在任何情况下，他们都不应从队列中删除公共文档夹复制邮件，因为这会导致今后出现问题。在这个问题上，管理员必须“能够经受住暴风雨的考验”，他（或她）能够为系统邮件创建单独的连接器，然后对他们进行调度，以便让他们的“正常”邮件流能够游刃有余。
bitsCN.Com
开放的中继
假如服务器是个开放的中继，将会产生大量事务日志。通常，您还能够在 Badmail 文档夹中看到大量项目。当然，这里的关键在于锁定服务器，以便他不再作为一台开放的中继。其他一些文章已讨论过如何实现这个目的，因此在此不加赘述。有关邮件中继问题的更多信息，尤其能够参考微软知识库文章 895853：如何在 Exchange Server 2003 和 Exchange 2000 Server 中排除邮件中继问题。 bitsCN_com
假如 Badmail 文档夹中存在大量邮件，则表明可能存在问题。请注意，在 Exchange Server 2003 Service Pack 1 (SP1) 中能够进行配置以定期清空 Badmail 文档夹，必要时应把此措施也纳入考虑范围之内。
www.bitsCN.com
M:驱动器和 Exchange IFS 文档级防病毒扫描
扫描 M:驱动器 / Exchange IFS 肯定会导致事务日志出现爆炸性增长。大多数情况下，文档级的防病毒扫描程式都会修改他们扫描的项目。由于 M:驱动器是数据库的虚拟表示形式，因此扫描可能会对数据库数据库进行修改。因此，将会出现大量事务日志，而且这些日志通常在很短的时间段内生成（扫描期间）。通常，数据库的大小并不会增加。 bitsCN_com
通常，您能够在应用程式日志中看到事件，能够通过这些线索了解到 M:驱动器和 Exchange IFS 正在被扫描的事实。
中国网管论坛
假如 M:驱动器被公开并被扫描，那么可能记录的事件会包含以下文本：
中国网管联盟
扫描无法打开文档 M:\DOMAIN.COM\MBX\alias\Inbox\somesubject.EML bitsCN_com
一些防病毒软件可能会通过 //./backofficestorage/ 路径扫描文档。该路径仍然是文档级扫描，即便 M:驱动器并没有公开。 bitsCN_com
毋庸置疑，文档级扫描需要尽快停止！更多相关信息，请参见微软知识库文章 328841：Exchange 和防病毒软件。 bitsCN.Com
