了解公用文件夹

 

适用于: Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题: 2016-11-28

公用文件夹是在 Microsoft Exchange 的第一版中引入的,是专门为共享访问设计的,它为收集、组织信息及与您的工作组或组织中的其他人共享信息提供了一种轻松、有效的方式。公用文件夹是分层组织的,存储在专用数据库中,并且可以在运行 Exchange 的服务器之间进行复制。

公用文件夹并非用于下列目的:

  • 存档数据   公用文件夹并非用于存档数据。 有邮箱限制的用户有时会使用公用文件夹而不是个人文件夹 (.pst) 文件来存档数据。 建议不要采取该做法,因为这会影响公用文件夹服务器上的存储量,并且削弱了邮箱限制的目标。

  • 文档共享与协作   公用文件夹并非用于文档共享与协作。 公用文件夹不提供版本控制或其他文档管理功能,例如受控的签入和签出功能以及自动通知内容变更。

在 Exchange Server 2010 中,公用文件夹是一个可选功能。如果您的组织中的所有客户端计算机运行的都是 Microsoft Outlook 2010 或 Office Outlook 2007,则对于诸如忙/闲信息和脱机通讯簿 (OAB) 下载等功能,不存在对公用文件夹的任何依赖。在 Exchange 2010 中,不使用公用文件夹实现 OAB 下载和忙/闲信息功能,而是通过自动发现服务、Microsoft Exchange 系统助理服务和 Microsoft Exchange 文件分发服务实现这些功能。

在您的组织中的所有客户端计算机都运行 Outlook 2010 或 Outlook 2007 之前,您应该继续使用公用文件夹。

目录

运行 Outlook 2003 及更早版本或 Microsoft Entourage 的计算机需要使用公用文件夹数据库(先前称为公用文件夹存储)才能连接到 Exchange。因此,在纯 Exchange 2010 组织中,当您在第一个服务器上安装邮箱服务器角色时,安装程序会提示您回答下面的问题: “您的组织中有任何运行 Outlook 2003 及更早版本或 Entourage 的客户端计算机吗?” 如果回答是,则会创建公用文件夹数据库。 如果回答否,则不会创建公用文件夹数据库。

安装第二个服务器时,不会提示您回答该问题,且安装程序不会创建公用文件夹数据库。 在组织中是否需要公用文件夹数据库仅在安装第一个服务器时决定。 此后,所有公用文件夹数据库都是可选的。 如果没有在安装过程中创建公用文件夹数据库,则可以在安装完成后随时创建一个。 有关如何创建公用文件夹数据的详细信息,请参阅创建公用文件夹数据库

在混合 Exchange 组织中,安装程序不会提示您回答该问题。在这些组织中,为了确保对 Exchange 之前的 Exchange Server 2007 版本的向后兼容性,默认情况下会创建一个公用文件夹数据库。尤其,因为 Exchange 2010 是安装在它自己的管理组内,所以此公用文件夹数据库将支持旧版的 Schedule+ 忙/闲功能。

有关安装 Exchange 2010 的详细信息,请参阅部署 Exchange 2010

在安装过程中创建公用文件夹数据库

MAPI 文件夹树分为下列子树:

  • 默认公用文件夹(也称为 IPM_Subtree)   用户可以使用客户端应用程序(如 Outlook)直接访问这些文件夹。

  • 系统公用文件夹(也称为非 Non_IPM_Subtree)   用户使用常规方法无法直接访问这些文件夹。 客户端应用程序(如 Outlook)使用这些文件夹存储诸如忙/闲数据、OAB 和组织表单等信息。 其他系统文件夹则用于保存自定义应用程序或 Exchange 使用的配置信息。 公用文件夹树包含常规用途公用文件夹树中不存在的其他系统文件夹,如 EFORMS REGISTRY 文件夹。 系统文件夹包括以下内容:

    • EFORMS REGISTRY 和 Events Root 默认情况下,安装在第一个管理组中的第一个 Exchange 服务器上的默认公用文件夹数据库中存在这两个文件夹中每一个文件夹的一个内容副本。这是为旧版 Outlook 客户端(使用 Outlook 之前的 Outlook 2007 版本的客户端)存储组织表单的位置。

    • 脱机通讯簿和 Schedule+ 忙/闲   “脱机通讯簿”文件夹和“Schedule+ 忙/闲”文件夹自动包含您的拓扑中每个管理组(或站点)的一个子文件夹。 默认情况下,特定管理组文件夹的内容副本驻留在管理组中安装的第一个服务器上。 这些文件夹用于为旧版 Outlook 客户端存储旧版忙/闲信息和 OAB 数据。旧版 Outlook 客户端不支持管理忙/闲信息和 OAB 数据的 Exchange 2010 或 Exchange 2007 中的新功能。 (这些功能包括可用性服务、自动发现服务和客户端访问服务器上的 OAB 分发。)

    • OWAScratchPad   每个公用文件夹数据库都有一个 OWAScratchPad 文件夹,用于临时存储正在使用 Microsoft Office Outlook Web App 访问的附件。请不要修改此文件夹。

    • StoreEvents   每个公用文件夹数据库都有一个 StoreEvents 文件夹,此文件夹存放自定义 Exchange 数据库事件的注册信息。请不要修改此文件夹。

    • 其他文件夹   为了支持内部 Exchange 数据库操作,一个树可能会包含几个其他的系统文件夹,如 schema-root。 请不要修改这些文件夹。

在安装过程中创建公用文件夹数据库

公用文件夹数据库复制两种类型的公用文件夹信息:

  • 层次结构   有关文件夹的文件夹属性和组织信息(包括树结构)。 所有公用文件夹数据库都有一个层次结构信息的副本。 对于某个特定文件夹,公用文件夹数据库可以使用层次结构信息来识别下列内容:

    • 文件夹上的权限

    • 存放文件夹内容副本的服务器

    • 文件夹在公用文件夹树中的位置(包括其父文件夹和子文件夹,如果有的话)

  • 内容   构成文件夹内容的邮件。 若要复制内容,必须将文件夹配置为将其内容复制到某个特定的公用文件夹数据库或数据库列表。 只有指定的数据库才拥有内容的副本。 包含内容的文件夹的副本称为内容副本。

注释注意:
公用文件夹内容复制不受数据库可用性组 (DAG) 的控制。 您可以将公用文件夹数据库安装在具有 DAG 的服务器上;但是,公用文件夹将在 DAG 外部使用其自己的公用文件夹复制方法。

有关公用文件夹复制的详细信息,请参阅了解公用文件夹复制

在安装过程中创建公用文件夹数据库

当客户端应用程序(如 Outlook)尝试打开 Exchange 公用文件夹时,Exchange 服务器将确定客户端应用程序应该访问的文件夹副本。 此过程称为“公用文件夹引用”。如果所请求内容的副本存在于服务请求的 Exchange 服务器上,则客户端应用程序将访问本地副本。如果在本地服务器上不存在该副本,则 Exchange 会尝试在同一 Active Directory 站点中查找副本。 通过指定一个引用服务器列表并向每个服务器分配一个路由开销,可以修改用户通信流以便允许在某些连接器上进行引用。

有关公用文件夹引用的详细信息,请参阅了解公用文件夹引用

在安装过程中创建公用文件夹数据库

对公用文件夹启用邮件可以为用户提供更有用的功能。 用户除了能够将邮件投递到该文件夹以外,还能将电子邮件发送到该文件夹,有时还能从该文件夹接收电子邮件。 如果您要开发自定义应用,则可以使用此功能将邮件或文档移动到公用文件夹中,或将其移出。

已启用邮件的文件夹是具有电子邮件地址的公用文件夹。 根据配置文件夹的方式,它可能会显示在全局地址列表 (GAL) 中。每个启用邮件的文件夹在 Active Directory 中都有一个对象,该对象用于存储此文件夹的电子邮件地址、地址列表名称和其他与邮件有关的属性。

因为发送到公用文件夹的邮件是直接到达公用文件夹数据库而不是邮箱数据库中的邮箱,所以 Exchange 路由电子邮件的方法与用于将电子邮件路由到常规邮箱所用的方法有略有不同。

在安装过程中创建公用文件夹数据库

在 Exchange 2010 中,下列客户端应用程序可以访问公用文件夹:

  • Outlook 2010

  • Outlook 2007

  • Outlook 2003

有关如何使用 Outlook 2007 创建和管理公用文件夹的详细信息,请参阅 Create and share a public folder(英文)。

有关如何使用 Outlook 2003 创建和管理公用文件夹的详细信息,请参阅使用公用文件夹(英文网页)。

在安装过程中创建公用文件夹数据库

在混合使用 Exchange 2010 和 Exchange 2007 的组织中,您需要通过 Exchange 2010 管理公用文件夹和公用文件夹数据库。由于 Active Directory 架构更改,Exchange 2007 服务器无法识别 Exchange 2010 公用文件夹数据库。下表介绍了在对 Exchange 2007 服务器和 Exchange 2010 服务器执行某些公用文件夹管理任务时的预期行为。

 

任务 Exchange 2007 服务器 Exchange 2010 服务器

创建公用文件夹数据库

如果有任何 Exchange 2010 邮箱数据库位于组织中,且没有填充 msExchHomePublicDB 属性,则 Exchange 2007 服务器无法更新 Exchange 2010 邮箱数据库的 msExchHomePublicDB 设置。尽管您会收到一条错误消息,但系统将创建公用文件夹数据库。

创建公用文件夹数据库后,您需要更改默认的公用文件夹数据库。 您需要从 Exchange 2010 服务器执行此过程。有关详细信息,请参阅为邮箱数据库更改默认公用文件夹数据库

始终有效。

删除默认公用文件夹数据库

如果有任何邮箱数据库指向正尝试删除的公用文件夹数据库,您将会收到一条错误消息,提醒您需要更改默认的公用文件夹数据库。 若要更改默认的公用文件夹数据库,请执行以下步骤:

  1. 在 Exchange 2010 服务器上为邮箱数据库更改默认公用文件夹数据库。有关详细信息,请参阅为邮箱数据库更改默认公用文件夹数据库

  2. 在 Exchange 2007 服务器上,删除该公用文件夹数据库的所有副本。 有关详细信息,请参阅从一个公用文件夹数据库中删除多个公用文件夹

  3. 在 Exchange 2007 服务器上删除公用文件夹数据库。有关详细信息,请参阅删除公用文件夹数据库

注释注意:
如果邮箱数据库所指向的新的默认公用文件夹数据库是 Exchange 2010 公用文件夹数据库,请参阅该表后面的“将 Exchange 2010 公用文件夹数据库设置为 Exchange 2007 邮箱数据库的默认公用文件夹数据库”。

适用于 Exchange 2007 和 Exchange 2010 服务器(如果没有任何邮箱数据库具有您尝试作为默认公用文件夹数据库删除的公用文件夹数据库)。

删除组织中的最后一个公用文件夹数据库

如果该数据库是组织中的最后一个 Exchange 2007 公用文件夹数据库,则 Remove-PublicFolderDatabase cmdlet 需要将 Exchange 2010 公用文件夹数据库的 msExchFirstInstance 属性更新为 $true。这将会失败,因为 Exchange 2010 对象的版本较高。

从 Exchange 2010 服务器运行 Remove-PublicFolderDatabase cmdlet。

适用于 Exchange 2007 和 Exchange 2010 服务器(如果没有任何邮箱数据库具有您尝试作为默认公用文件夹数据库删除的公用文件夹数据库)。

将 Exchange 2010 公用文件夹数据库设置为 Exchange 2007 邮箱数据库的默认公用文件夹数据库

如果邮箱数据库或公用文件夹数据库是 Exchange 2010 数据库,则更改默认公用文件夹数据库不适用于 Exchange 2007 服务器。

由于 Exchange 2007 服务器无法识别 Exchange 2010 公用文件夹数据库,因此必须在 Exchange 2010 服务器上运行 Set-MailboxDatabase cmdlet。

在 Exchange 2010 服务器上,更改 Exchange 2007 邮箱数据库的默认公用文件夹数据库。有关详细信息,请参阅为邮箱数据库更改默认公用文件夹数据库

始终有效并用于更改默认的公用文件夹数据库(如果公用文件夹数据库和邮箱数据库与不同版本的 Exchange 关联)。

在安装过程中创建公用文件夹数据库

如果在 Exchange 2010 组织中安装 Exchange 2003,则安装程序会在 Exchange 2003 组织内自动创建管理组和路由组。添加到您的组织中的 Exchange 2010 服务器包含在新的管理组和路由组中。如先前所述,安装程序还会在第一个 Exchange 2010 邮箱服务器上安装一个公用文件夹数据库。 在该公用文件夹数据库中,安装程序会为新管理组创建一个忙/闲文件夹。 在 Exchange 2010 服务器上创建(而非从 Exchange 2003 迁移)其邮箱的用户的 legacyExchangeDN 属性映射到 Exchange 2010 管理组名称,因此也映射到忙/闲文件夹。默认情况下,为了促进从其邮箱位于 Outlook 2003 服务器上的 Exchange 2003 和更早版本客户端用户进行忙/闲搜索,请将该客户端用户的忙/闲信息张贴到忙/闲公用文件夹。

在混合使用 Exchange 2010、Exchange 2007 和 Exchange 2003 的组织中,可以使用 Exchange 系统管理器来管理公用文件夹。 支持下列方案:

  • Exchange 系统管理器应仅连接到 Exchange 2003 公用文件夹数据库以进行管理。在这里将更改复制到 Exchange 2010。

  • 在纯 Exchange 2010 环境或混合使用 Exchange 2010 和 Exchange 2007 的组织中,不能重新安装 Exchange 系统管理器来管理公用文件夹。必须使用 Exchange 命令行管理程序。

  • 验证层次结构复制或查看文件夹上的本地副本期限限制值时,我们建议为存在于 Exchange 服务器上的公用文件夹使用 Exchange 2003 系统管理器,而为存在于 Exchange 2010 或 Exchange 2007 服务器上的公用文件夹使用命令行管理程序。

在混合使用 Exchange 2010、Exchange 2007 和 Exchange 2003 的组织中,Exchange 2010 或 Exchange 2007 客户端访问服务器具有一个名为 /public 的虚拟目录。 可以对 Outlook Web App 中公用文件夹进行完全访问,而无需使用 /public 虚拟目录。

重要重要说明:
Exchange 2010 Outlook Web App 客户端无法查看 Exchange 2003 服务器上的公用文件夹。

此外,在 Outlook Web App 中还提供了下列公用文件夹功能:

  • 无需保持用于从 Exchange 2010 访问公用文件夹的 Exchange 2003 邮箱服务器,即可完全访问 Outlook Web App 邮箱服务器上的公用文件夹

  • 公用文件夹搜索功能

  • Web 部件支持

在安装过程中创建公用文件夹数据库

如果发现某个服务器上的公用文件夹层次结构与其他服务器上的公用文件夹层次结构不同,则可能需要同步层次结构。在 Exchange 2003 Service Pack 2 (SP2) 中,使用 Synchronize Hierarchy 命令对 Exchange 2003 服务器与组织中其他服务器执行公用文件夹层次结构同步。在 Exchange 2010 中,Update-PublicFolderHierarchy cmdlet 用于使 Exchange 2010 服务器上的公用文件夹层次结构与组织中的剩余服务器同步。

注释注意:
不能在Exchange 2010 服务器上运行 Synchronize Hierarchy 命令。 同样,也不能在 Exchange 2003 服务器上运行 Update-PublicFolderHierarchy cmdlet。 但是,运行任一个命令都会更新整个组织中的公用文件夹层次结构。

有关详细信息,请参阅更新公用文件夹层次结构

在安装过程中创建公用文件夹数据库

若要帮助停止组织中的公用文件夹内容复制错误,可以挂起对公用文件夹内容的复制。 挂起复制使您能够重新配置公用文件夹层次结构和复制计划。

若要在混合组织中挂起或恢复对公用文件夹内容的复制,可在 Exchange 2010 服务器上的命令行管理程序中运行 Suspend-PublicFolderReplication cmdlet 或 Resume-PublicFolderReplication cmdlet。 尽管您是在一个 Exchange 2010 服务器上运行这些 cmdlet,但是它们将挂起或恢复您的混合组织中所有服务器上的公用文件夹内容的复制。 有关使用命令行管理程序挂起或恢复公用文件夹内容复制的信息,请参阅下列主题:

在安装过程中创建公用文件夹数据库

本部分介绍在 Exchange 组织中执行下列公用文件夹任务时应考虑的最佳实践:

  • 创建公用文件夹数据库

  • 设计公用文件夹层次结构

  • 执行夜间维护

对要在组织中创建多少个公用文件夹数据库进行规划时,请考虑下列最佳实践:

  • 对于公用文件夹使用频繁的大型企业拓扑,请部署专用公用文件夹服务器。 此最佳实践起源于将 CPU 资源和磁盘资源专用于独立的服务器功能的通用最佳实践。

  • 拥有少数较大的公用文件夹数据库与拥有许多较小的公用文件夹数据库相比,伸缩性更好且更易于管理。 通过减少公用文件夹数据库的数量,可以缩短备份和还原许多较小数据库所需的时间。 还可以减少后台复制通信量。 此外,少量较大数据库的联机维护比许多较小数据库的联机维护要快。 此外,从应用权限和内容访问以及实施有效的复制和引用的角度来看,管理更少数量的公用文件夹数据库会更加容易。

    从组织级别上考虑拓扑时,拥有少量较大公用文件夹数据库的最佳实践特别有用。 但是,在服务器级别上,如果有多个较小的数据库,一些管理和维护任务(如备份和还原过程)执行起来会更快。 最终,部署的公用文件夹数据库的数量必须满足业务要求。 在确定要部署的数据库的数量时,必须平衡复制通信的开销与数据库备份、维护和还原时间的开销。

设计公用文件夹层次结构时,必须认识到在您的环境中复制层次结构的影响。 深公用文件夹层次结构与宽层次结构相比,伸缩性更好。 “深层次机构”由许多垂直嵌套的文件夹(而不是许多较高级别文件夹)组成。 “宽层次机构”由许多较高级别文件夹和少量垂直嵌套的子文件夹组成。

例如,请考虑一下如何在一个特定的层次结构中排列 250 个文件夹。 宽层次结构可能在一个父文件夹下有 250 个直接的子文件夹。 深层次结构可能有五个顶级文件夹,每个文件夹有五个直接的子文件夹。 在这些子文件夹中,每个子文件夹可以含有 10 个子文件夹。

在这两个示例中,都存在 250 个文件夹 (5 × 5 × 10 = 250)。 但是,深层次结构与宽层次结构相比,能提供更好的性能,原因如下:

  • 复制时处理应用了不同权限的文件夹的方式在深层次结构中更有效。

  • 针对具有 10 个子文件夹的文件夹的客户端计算机操作(如排序、搜索和展开)与针对具有 250 个子文件夹的文件夹的客户端计算机操作相比,开销要低得多。

尽管深层次结构比宽层次结构伸缩性更好,但最佳做法是每个文件夹不超过 250 个子文件夹。 如果超过 250 个子文件夹,很可能会在客户端计算机请求访问时导致无法接受的客户端体验。

实施层次结构时要考虑的一个因素是,当用户希望访问公用文件夹时权限对用户体验的影响。如果每个公用文件夹子文件夹都定义了它自己的访问控制列表 (ACL) 条目,则每次 Exchange 服务器收到新的公用文件夹复制邮件时,必须对父公用文件夹的 ACL 进行评估,以确定哪些用户有权查看对父公用文件夹的更改。 如果父公用文件夹有一个很大的自定义访问控制列表 (DACL) 项,则为每个公用文件夹订阅者更新视图可能会花很长时间。

注释注意:
父文件夹的 DACL 由所有公用文件夹子文件夹的 DACL 的总和组成。

如果下列条件为真,可能必须分析许多 MB 的 DACL 数据:

  • 在单个父公用文件夹下有许多子文件夹。

  • 这些子文件夹中的每一个都定义了它自己的 ACL。

必须对此 DACL 数据进行分析,这样每次收到公用文件夹复制邮件时,才能更新所有公用文件夹订阅者的显示。

因此,我们建议您根据已获得父文件夹访问权限的用户集安排公用文件夹层次结构。 此外,不要对公用文件夹层次结构实施复杂的权限模型。

若要确保数据库持续有效工作,我们建议对邮箱数据库和公用文件夹数据库进行夜间维护。Exchange 邮箱服务器会根据您设置的计划自动执行任务。

在安装过程中创建公用文件夹数据库

 © 2010 Microsoft Corporation。保留所有权利。
显示: