了解 EXOLEDB 默认文件夹

 

上一次修改主题: 2006-01-11

作者:Jason Nelson

本文介绍了 Microsoft® Exchange 服务器上的各种 EXOLEDB 文件夹,并说明这些文件夹的用途。

在邮件数据库 (MDB) 初始化过程的“接受客户端”阶段,EXOLEDB 在 NON_IPM_SUBTREE 下创建了多个系统文件夹。一些文件夹由于历史原因被保留下来,但大多数文件夹都有实际的用途。如果这些文件夹被删除,将会对服务器产生影响。其中任何文件夹都不应当是重复的。创建的文件夹包括:

  • \NON_IPM_SUBTREE\schema-root\
  • \NON_IPM_SUBTREE\schema-root\Default
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views
  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal
  • \NON_IPM_SUBTREE\OWAScratchPad

无论在哪一种情况下,以 GUID 命名的子文件夹都对应于具有相同 GUID 的 MDB 对象。

创建的第一批文件夹是架构文件夹。

下面的列表介绍 schema-root:

  • \NON_IPM_SUBTREE\schema-root\
    在 Exchange 2000 Server 中引入。
  • \NON_IPM_SUBTREE\schema-root\Default
    在 Exchange 2000 Server Service Pack 1 (SP1) 中引入。
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
    在 Exchange 2000 Server SP1 中引入。
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
    在 Exchange 2000 Server SP1 中引入。

下面显示了公用 MDB 的典型架构路径:

  • File://.BackOfficeStorage/<domain>/<TLHName>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1

专用 MDB 架构路径位于系统助理邮箱下。

EXOLEDB 支持多种架构或属性类型定义。这些文件夹支持 Exchange Web 存储开发平台。其理念是文件夹项目可以引用各种版本的架构,并且各个版本彼此共存。在 Exchange 2000 Server 中,架构文件位于架构根文件夹中,因此对架构的更改可以有效地传播到所有项目。但是,这导致了应用程序开发工作区方面的问题,因为需要根据情况处理每个项目以删除或添加属性,于是 Microsoft 采用了版本控制方法。在 schema-root 下,Microsoft 使用应用程序和版本元素创建子文件夹,以允许有效地进行无缝升级。EXOLEDB 监视架构文件夹中发生的变化,从而可以在处理发生时传播条目、转储架构缓存,以及重新填充。\schemaroot\default 文件夹是普通文件夹项目获取其架构的位置,并且 schema-root 文件夹被标记为指向 ExchangeV1 文件夹。EXOLEDB 从 .xml 文件填充架构条目,通过事件接收器 EXSCHEMA.EXE 处理此操作。无法删除或移除架构事件接收器绑定,原因是与大多数事件不同,该事件在 EventBindings 文件夹中没有对应条目。

下面的列表介绍 EXCHWEB、视图、IMG 和控件:

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

这些项目是在 Exchange 2000 Server SP1 中引入的,它们未加入到 Exchange 2000 Server Service Pack 3 (SP3) 和 Exchange Server 2003 中。

为了让本地存储打开引用 Microsoft Outlook® Web Access 控件功能的项目,文件必须位于可以同步的文件夹中。这些文件夹以前包含 Outlook Web Access 的 Web 数据的副本,以允许打开 LIS 存储的项目,但实际上从未在 LIS 之外使用。

接下来,EXOLEDB 启动事件绑定系统,这会创建 StoreEvents。

下表中介绍的所有存储事件文件夹都是从 Exchange 2000 Server 开始出现:

  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal

这是事件绑定文件夹,EXOLEDB 在此存储为特定 MDB 构建的事件的信息。启动时,EXOLEDB 必须枚举此处的事件,如果拥有大量事件接收器,则会导致较长的存储启动时间。Exchange Server 2003 在此方面的性能已得到显著改进,但是装入 MDB 的时间仍然受行数影响。对于每个绑定,会验证类,以及是否拥有有效的事件方法(如 onsave 或 ontimer)、有效的 clsid 及接收器参数。匹配类为 ANY(任意)的事件只能在 GlobalEvents 子文件夹中注册。

在创建架构文件夹并启动事件绑定系统之后,EXOLEDB 会创建 Outlook Web Access Scratch Pad。

OWAScratchPad 在 Exchange 2000 Server SP1 中引入。它显示如下:

  • \NON_IPM_SUBTREE\OWAScratchPad

投递必须从某个位置开始以暂存附件和执行公用存储登录,该位置即 Outlook Web Access Scratch Pad。由于分布式创作和版本管理 (DAV) 不能跨 MDB 运行,因此在每个邮箱上都需要一个可供编写邮件的位置,以支持添加附件。邮件暂存在 OWAScratchPad 中,直到添加了所有附件或者被保存。Outlook Web Access Scratch Pad 上的大小限制控制通过 Outlook Web Access 可以添加的附件大小。尝试投递更大的邮件会导致下列错误:

  • 此项目超出了为此文件夹定义的最大大小,因此无法保存。请与您的管理员联系以放宽文件夹的大小限制。

如果未设置注册表项 HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA REG_DWORD 值“Message Size Limit”,则在 EXOLEDB 初始化过程中,OWAScratchPad 的大小始终重置为 1 MB。这对于 Microsoft SharePoint® Portal Server 是必需的,因为 EXOLEDB 不了解您是否在 magma 模式下运行。

Outlook Web Access 以平面 URL 格式投递到 Scratch Pad,这意味着它们直接引用文件夹和邮件。这是为了支持深度 vroot,其友好 URL 可能过长。

请考虑以下常见问题 (FAQ)。

此问题可分为两种类别:

  • Active Directory 对象删除某个存储时,您无法告知 Active Directory 该公用文件夹对象已消失。因此,重新创建文件夹时,它们不会连接到相应的 Directory Service 对象。于是会创建新目录服务对象。
  • 实际文件夹如果将文件夹设置为复制,并且相关的存储被删除,则 EXOLEDB 会在启动时重新创建该文件夹,而复制会创建任何此类文件夹的第二个副本。这会导致事件绑定出现问题。通过友好 URL 删除重复文件夹非常危险,因为两个文件夹通常具有重复的友好 URL。

当具有相同编号的系统文件夹的数目增加时,会在目录服务代理上附加随机数字以使其唯一,从而产生类似 controls12345678 的名称。

如果您尝试删除这些文件夹,EXOLEDB 会将它们还原。同样,文件夹中的大多数都具有特定用途,如果这些文件夹不存在,就会对服务器的运行产生负面影响。

如果架构文件夹丢失(即未出现在 ipm 子树下),则通过将以下注册表项设为 REG_DWORD 值 0,就可以重新填充架构:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID>

EXOLEDB 自动授予任何人对架构文件夹的读取访问权限。可以修改此访问控制列表 (ACL),但如果重新触发架构传播,则会删除所做更改。

在复制系统文件夹的程序中,不需要复制文件夹内容。

有关详细信息,请参阅以下 Exchange 博客文章:

 
显示: