http://docs.google.com/Doc?docid=d4dwfrz_1526dftnwxdv&hl=en
New Mailbox Features in Exchange 2007 SP1
Applies to: Exchange Server 2007 SP1
Microsoft Exchange Server 2007 Service Pack 1 (SP1) introduces the following new features for the Mailbox server role:
Public folder management improvements, including the new Public Folder Management Console
New public folder features
Mailbox management improvements
Ability to import and export mailbox data to .pst files
Changes to messaging records management (MRM)
New performance counters for online database defragmentation
Public Folder Enhancements
Exchange 2007 SP1 introduces several new features for public folders, including the ability to create and maintain public folders by using the Exchange Management Console:
Public Folder Management Console The Public Folder Management Console is a Microsoft Management Console (MMC) 3.0-based interface that provides administrators with a graphical user interface (GUI) for creating, configuring, and managing public folders. The Public Folder Management Console is located in the Toolbox. For more information about the Public Folder Management Console, see Using the Public Folder Management Console.
Public folder referrals You can create and maintain public folder referrals in the Exchange Management Console. The Public Folders Referral tab is located in the Public Folder Database Properties dialog box. For more information about how to create a public folder referral, see How to Configure Public Folder Referrals.
Public Folder Administrator permissions Exchange 2007 SP1 introduces a new administrator role called Exchange Public Folder Administrator. You can use this role to grant public folder administrative permissions to a user or group. For more information, see the following topics:
Understanding Public Folders
Managing Public Folders
Configuring Public Folder Permissions
Mail-enabled public folders included when reviewing address lists, e-mail address policies, and group memberships When previewing the recipients that are members of an address list, e-mail address policy, dynamic distribution group, and distribution group, you can now see the mail-enabled public folders that are included in the membership criteria. For more information, see the following topics:
Managing Address Lists
Managing E-Mail Address Policies
Managing Distribution Groups
Mailbox Management Enhancements
Exchange 2007 SP1 introduces the following improvements to mailbox management within the Exchange Management Console:
Bulk mailbox creation for existing user accounts In the New Mailbox wizard, you can now select multiple user accounts when creating mailboxes for existing user accounts.
Manage Full Access Permission wizard This new wizard in the Exchange Management Console allows you to grant or remove Full Access permissions for a mailbox.
Manage Send As Permission wizard This new wizard in the Exchange Management Console allows you to grant or remove Send As permissions for a mailbox.
For more information about mailbox management, see Managing User Mailboxes.
Mailbox Data
Exchange 2007 SP1 introduces the following improvements to managing mailbox data:
Export mailbox data directly to a .pst file You can now use the Export-Mailbox Exchange Management Shell cmdlet to export mailbox data directly to a .pst file.
Import mailbox data from a .pst file You can use the new Import-Mailbox Exchange Management Shell cmdlet to import mailbox data from a .pst file to a mailbox.
For more information about importing and exporting mailbox data, see the following topics:
How to Export Mailbox Data
How to Import Mailbox Data
Messaging Records Management
In Exchange 2007 SP1, you can apply MRM to managed default folders on an Exchange server that has an Exchange Standard client access license (CAL). (Managed default folders are folders that, by default, appear in a user's Microsoft Office Outlook mailbox, such as the Inbox.) This maintains parity with the Mailbox Manager functionality of Exchange 2000 Server and Exchange Server 2003. You can create as many managed default folders as you want in Exchange 2007 SP1.
Managed custom folders are a premium feature of MRM, and each mailbox that has managed custom folders requires an Exchange Server Enterprise CAL.
For more information, see Understanding Messaging Records Management.
Exchange 2007 SP1 also introduces a new parameter for the Set-Mailbox cmdlet called RemoveManagedFolderAndPolicy. This parameter performs the following tasks:
Removes any MRM policies from a mailbox.
Removes MRM properties from any managed folders that were created as part of the MRM policy that was applied to the mailbox.
Removes any empty managed folders and converts any managed folders that contain items to standard folders.
Enhanced Monitoring of Online Defragmentation
Exchange 2007 SP1 introduces the following improvements to help you monitor online defragmentation:
Extended information for Event 703 allows you to more easily monitor online defragmentation pass completions.
Two extended Extensible Storage Engine (ESE) performance counters for monitoring the effectiveness and efficiency of online defragmentation have been added for use with Performance Monitor (called Reliability and Performance Monitor in Windows Server 2008).
Using the Public Folder Management Console
Applies to: Exchange Server 2007 SP1 Topic Last Modified: 2007-08-24
The Public Folder Management Console, available in Microsoft Exchange Server 2007 Service Pack 1 (SP1), is a Microsoft Management Console (MMC) 3.0-based interface that provides you with a graphical user interface (GUI) to create, configure, and maintain public folders. You can access the Public Folder Management Console from the Toolbox in the Exchange Management Console. For more information about the Toolbox, see Using the Toolbox.
Elements of the Public Folder Management Console
Similar to the Exchange Management Console, the Public Folder Management Console is organized into three panes. In the Public Folder Management Console, these panes are called the public folder tree, the result pane, and the action pane.
Panes in the Public Folder Management Console
Mail-enabled public folders are represented in the user interface by the following icon.
System public folders and public folders that are not mail-enabled are represented in the user interface by the following icon.
Public Folder Tree
The public folder tree is located on the left side of the console and is organized by nodes that are based upon the public folder hierarchy. Exchange Server 2003 supports the use of a non-MAPI folder tree, otherwise known as an Application folder tree or General Purpose folder tree. Exchange 2007 supports only the default MAPI folder tree.
The MAPI folder tree is divided into the following subtrees:
Default Public Folders (also known as the IPM_Subtree) Users can access these folders directly by using client applications such as Microsoft Outlook.
System Public Folders (also known as the Non IPM_Subtree) Users cannot access these folders directly by using conventional methods. Client applications such as Outlook use these folders to store information such as free and busy data, offline address books (OABs), and organizational forms. Other system folders contain configuration information that is used by custom applications or by Exchange itself. The public folder tree contains additional system folders, such as the EFORMS REGISTRY folder, that do not exist in general-purpose public folder trees. System folders include the following:
EFORMS REGISTRY and Events Root By default, one content replica of each of these folders resides in the default public folder database on the first Exchange 2007 server that is installed in the first administrative group. This is the location where organizational forms are stored for legacy Outlook clients (clients that use an Outlook version earlier than Office Outlook 2007).
Offline Address Book and Schedule+ Free Busy The Offline Address Book folder and the Schedule+ Free Busy folder automatically contain a subfolder for each administrative group (or site) in your topology. By default, a content replica of a specific administrative group folder resides on the first server that is installed in the administrative group. These folders are used to store legacy free and busy information and OAB data for legacy Outlook clients. Legacy Outlook clients do not support the new features in Exchange 2007 that manage free and busy information and OAB data. (These features include the Availability service, the Autodiscover service, and OAB distribution on Client Access servers).
OWAScratchPad Each public folder database has an OWAScratchPad folder, which is used to temporarily store attachments that are being accessed by using Outlook Web Access. Do not modify this folder. Outlook Web Access running on Exchange 2007 Client Access servers does not use these folders to store attachment data. However, this folder is created during a pure installation of Exchange 2007.
StoreEvents Each public folder database has a StoreEvents folder, which holds registration information for custom Exchange database events. Do not modify this folder.
Other folders To support internal Exchange database operations, a tree may contain several other system folders, such as schema-root. Do not modify these folders.
Result Pane
The result pane is located in the center of the console. This pane displays public folders based upon the public folder that is selected in the public folder tree. The following columns are displayed by default:
Name This column lists the name of the public folder.
Parent Path This column lists the public folder path to the parent public folder. If a backslash (\) is displayed, the parent public folder is the top-level public folder for that tree.
The following columns are hidden by default:
Mail Enabled This column lists the mail-enabled status of the public folder.
Age Limit in Days This column lists the age limit (in days) of the public folder.
Local Replica Age Limit in Days This column lists the local replica age limit (in days) of the public folder.
Hidden From Address List This column lists the true or false status of whether the public folder is hidden from address lists in your organization.
Replicas This column lists the server name on which this public folder is replicated.
For more information about how to view these columns, see How to Customize the Exchange Management Console.
The result pane will display up to 10,000 objects. You can create filters to reduce the number of objects that are displayed. For detailed instruction, see How to Filter the Result Pane.
Note:
If you have more than 10,000 objects, the objects that are not displayed in the result pane before you apply the filter never display. The filter only applies to objects that are currently displayed in the result pane.
Action Pane
The action pane is located on the right side of the console. The action pane lists the actions based upon the object that is selected in the public folder tree or the result pane. The action pane is an extension of the shortcut menu, which is the menu that appears when you right-click an item.
Public Folder Node Actions
When you select the Public Folders node in the public folder tree, the following actions are available in the action pane:
Connect to Server Click this button to connect the Public Folder Management Console to a Mailbox server on which a public folder database resides. For more information, see How to Connect to a Server by Using the Public Folder Management Console.
Update Hierarchy Click this button to synchronize the public folder hierarchy from one server to the other servers on which public folder replicas exist. For more information about how to update the public folder hierarchy, see How to Update a Public Folder Hierarchy.
Public Folder Tree Actions
When you select a public folder in the public folder tree, the following actions are available in the action pane:
New Public Folder Click this button to use the New Public Folder wizard to create a child public folder within the public folder that you have selected. For more information, see How to Create Public Folders.
Export List Click this button to export the list of objects within that public folder. The list can be exported as a tab-delimited or a comma-delimited file. For more information, see How to Export Lists from the Exchange Management Console.
View Click this button to customize the management console. For more information, see How to Customize the Exchange Management Console.
Refresh Click this button to refresh the result pane. You can also press F5 to refresh the result pane.
Public Folder Actions
When you select a public folder in the result pane, the following actions are available for that public folder in the action pane:
Update Content Click this button to synchronize the public folder content from one server to the other servers on which public folder replicas exist. For more information, see How to Update Public Folders.
Mail Enable and Mail Disable Click these buttons to mail-enable or mail-disable a public folder. For more information about how to mail-enable or mail-disable a public folder, see the following topics:
How to Mail-Enable Public Folders
How to Mail-Disable Public Folders
Remove Click this button to remove a public folder. For more information, see How to Remove Public Folders.
Manage Send As Permission This button is available only for mail-enabled public folders. Click this button to use the Manage Send As Permission wizard to grant Send As permissions to users or groups for the selected public folder. You can also use this wizard to remove Send As permissions from users or groups. For more information, see How to Grant the Send As Permission for a Mail-Enabled
Exchange 2007
Understanding Public Folders
Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2008-01-09
Public folders, introduced in the first version of Microsoft Exchange, are designed for shared access and provide an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. Public folders are hierarchically organized, stored in dedicated databases, and can be replicated between Exchange servers.
Public folders are not designed for the following purposes:
Archiving data Public folders are not designed for archiving data. Users who have mailbox limits sometimes use public folders instead of their personal folders (.pst) files to archive data. This practice is not recommended because it affects storage on public folder servers and undermines the goal of mailbox limits.
Document sharing and collaboration Public folders are not designed for document sharing and collaboration. Public folders do not provide versioning or other document management features, such as controlled check-in and check-out functionality, and automatic notifications of content changes.
In Exchange Server 2007, public folders are an optional feature. If all client computers in your organization are running Microsoft Office Outlook 2007, there are no dependencies on public folders for features such as free and busy information and offline address book (OAB) downloads. Instead of using public folders for OAB downloads and free and busy information, in Exchange 2007, these features are serviced by the Autodiscover service, the Microsoft Exchange System Attendant service, and the Microsoft Exchange File Distribution service.
To connect to Exchange for OAB and Schedule+ free and busy functionality, all client computers running Outlook 2003, Outlook 2002, Outlook 2000, or Outlook 98 require public folders to be deployed. Exchange 2007 is the first version of Exchange that provides you with the option to not use public folders. However, until all client computers in your organization are running Outlook 2007, you should continue using public folders.
This topic provides the following information about public folders in Exchange 2007:
Public folder database creation during setup
Public folder trees
Public folder databases
Public folder replication
Public folder referrals
Mail-enabled public folders
Public folder access
Considerations with mixed Exchange 2007 and Exchange Server 2003 organizations
Best practices
Public Folder Database Creation During Setup
Computers running Outlook 2003 and earlier or Microsoft Entourage require a public folder database (previously called the public folder store) to connect to Exchange 2007. Therefore, in a pure Exchange 2007 organization, as you install the Mailbox server role on the first server, Setup prompts you with the question: Do you have any client computers running Outlook 2003 and earlier or Entourage in your organization? If the answer is yes, a public folder database is created. If the answer is no, a public folder database is not created.
When you install the second server, you are not prompted with the question, and Setup does not create a public folder database. Whether a public folder database is needed in the organization is decided only when you install the first server. After that, all public folder databases are optional. If you do not create a public folder database during Setup, you can always create one anytime after Setup is complete. For more information about how to create a public folder database, see How to Create a New Public Folder Database.
In a mixed Exchange organization, Setup does not prompt you with the question. In these organizations, to ensure backward compatibility to Exchange versions prior to Exchange 2007, a public folder database is created by default. Specifically, because Exchange 2007 is installed in its own administrative group, this public folder database will support legacy Schedule+ free and busy functionality.
For more information about installing Exchange 2007, see Deployment.
Public Folder Trees
Exchange 2003 supports the use of a non-MAPI folder tree, otherwise known as an Application folder tree or General Purpose folder tree. Exchange 2007 only supports the default MAPI folder tree. The MAPI folder tree is divided into the following subtrees:
Default public folders (also known as the IPM_Subtree) Users can access these folders directly by using client applications such as Outlook.
System public folders (also known as the Non IPM_Subtree) Users cannot access these folders directly by using conventional methods. Client applications such as Outlook use these folders to store information such as free and busy data, OABs, and organizational forms. Other system folders contain configuration information that is used by custom applications or by Exchange itself. The public folders tree contains additional system folders, such as the EFORMS REGISTRY folder, that do not exist in general purpose public folder trees. System folders include the following:
EFORMS REGISTRY and Events Root By default, one content replica of each of these folders resides in the default public folder database on the first Exchange 2007 server that is installed in the first administrative group. This is the location where organizational forms are stored for legacy Outlook clients (clients using an Outlook version earlier than Outlook 2007).
Offline Address Book and Schedule+ Free Busy The Offline Address Book folder and the Schedule+ Free Busy folder automatically contain a subfolder for each administrative group (or site) in your topology. By default, a content replica of a specific administrative group folder resides on the first server that is installed in the administrative group. These folders are used to store legacy free and busy information and OAB data for legacy Outlook clients. Legacy Outlook clients do not support the new features in Exchange 2007 that manages free and busy information and OAB data. (These features include the Availability service, the Autodiscover service, and OAB distribution on Client Access servers).
OWAScratchPad Each public folder database has an OWAScratchPad folder, which is used to temporarily store attachments that are being accessed by using Outlook Web Access. Do not modify this folder. Outlook Web Access running on Exchange 2007 Client Access servers does not use these folders to store attachment data. However, this folder is created during a pure installation of Exchange 2007.
StoreEvents Each public folder database has a StoreEvents folder, which holds registration information for custom Exchange database events. Do not modify these folders.
Other folders To support internal Exchange database operations, a tree may contain several other system folders, such as schema-root. Do not modify these folders.
Public Folder Databases
The public folder database contains data that is available to all users who have mailboxes and appropriate permissions.
Cluster continuous replication (CCR), local continuous replication (LCR), standby continuous replication (SCR), and public folder replication are very different forms of replication built into Exchange. Due to interoperability limitations between continuous replication and public folder replication, if more than one Mailbox server in the Exchange organization has a public folder database, public folder replication is enabled and public folder databases should not be hosted in CCR, LCR, or SCR environments.
For more information about public folders and high availability options, see the following topics:
Cluster Continuous Replication
Local Continuous Replication
Standby Continuous Replication
Public Folder Replication
Public folder databases replicate two types of public folder information:
Hierarchy Properties of the folders and organizational information about the folders (including the tree structure). All public folder databases have a copy of the hierarchy information. For a specific folder, the public folder database can use hierarchy information to identify the following:
Permissions on the folder
Servers that hold content replicas of the folder
The folder's position in the public folder tree (including its parent and child folders, if any)
Content Messages that form the content of the folders. To replicate content, you must configure a folder to replicate its content to a specific public folder database or list of databases. Only the databases that you specify will have copies of the content. A copy of the folder that includes content is called a content replica.
To learn more about public folder replication, see Understanding Public Folder Replication.
For information about managing public folder replication, see Managing Public Folder Replication.
Public Folder Referrals
When a client application, such as Outlook, attempts to open an Exchange public folder, the Exchange server determines which folder replica the client application should access. This process is called public folder referral. If a replica of the requested content exists on the Exchange server that serves the request, the client application accesses the local replica. If the replica does not exist on the local server, Exchange attempts to locate a replica in the same Active Directory directory service site. You can modify the flow of user traffic to allow referrals over certain connectors by specifying a list of referral servers and assigning a routing cost to each server.
For more information about public folder referrals, see the following topics:
Understanding Public Folder Referrals
Managing Public Folder Referrals
Mail-Enabled Public Folders
Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the folder. If you are developing custom applications, you can use this feature to move messages or documents into or out of public folders.
A mail-enabled folder is a public folder that has an e-mail address. Depending on how the folder is configured, it may appear in the global address list (GAL). Each mail-enabled folder has an object in Active Directory that stores its e-mail address, address list name, and other mail-related attributes.
Because mail that is sent to public folders is directed to the public folder database instead of to a mailbox in the mailbox database, Exchange routes e-mail messages by using a method that is slightly different from the method that is used to route e-mail messages to a regular mailbox.
For more information about public folder routing, see Routing Messages to Public Folders.
Public Folder Access
In the RTM version of Exchange 2007, the following client applications can access public folders:
Microsoft Office Outlook 2007
Microsoft Office Outlook 2003
Client applications that are compatible with Internet Message Access Protocol 4rev1 (IMAP4), such as Outlook Express
In Exchange 2007 SP1, the same client applications are used to access public folders, with the addition of Microsoft Office Outlook Web Access.
For more information about how to create and manage public folders by using Outlook 2007, see Public folders.
For more information about how to create and manage public folders by using Outlook 2003, see Using Public Folders.
For more information about how to create and manage public folders by using Outlook 2000, see Create an Office document library in an Outlook public folder.
Considerations with Mixed Exchange 2007 and Exchange 2003 Organizations
This section provides considerations for implementing and managing public folders in a mixed Exchange 2007 and Exchange 2003 organization.
Setup
When you install Exchange 2007 in a mixed Exchange 2007 and Exchange 2003 organization, Setup automatically creates a new administrative group and routing group within the Exchange 2003 organization. The Exchange 2007 servers that are added to your organization are included in the new administrative group and routing group. As previously mentioned, Setup also installs a public folder database on the first Exchange 2007 Mailbox server. In that public folder database, Exchange 2007 creates a new free and busy folder for the new administrative group. The legacyExchangeDN property for users whose mailboxes were created on an Exchange 2007 server (not migrated from Exchange 2003) maps to the Exchange 2007 administrative group name, and therefore also maps to the Free/Busy folder. By default, to facilitate free and busy searches from Outlook 2003 and earlier client users whose mailboxes reside on an Exchange 2003 server, the client users' free and busy information is posted to the Free/Busy public folder.
Management
In a mixed Exchange 2007 and Exchange 2003 organization, you can use Exchange System Manager to manage public folders. The following scenarios are supported:
Exchange System Manager should only connect to the Exchange 2003 public folder database for administration. From there, changes replicate to Exchange 2007.
In a pure Exchange 2007 organization, you cannot reinstall Exchange System Manager to manage public folders. You must use the Exchange Management Shell.
When verifying hierarchy replication or when viewing the Local Replica Age Limit value on a folder, we recommend using Exchange System Manager for public folders that exist on an Exchange 2003 server and using the Exchange Management Shell for public folders that exist on an Exchange 2007 server.
Outlook Web Access
In a mixed Exchange 2007 and Exchange 2003 organization, Exchange 2007 Client Access servers have a virtual directory named /public. In the Exchange 2007 RTM version, this virtual directory is used only to access legacy public folders. Specifically, the /public virtual directory will not connect to another Exchange 2007 Mailbox server because the Mailbox server does not support access to a /public virtual directory.
In Exchange 2007 SP1, you can fully access public folders from Outlook Web Access without having to use the /public virtual directory. In addition, the following public folder features are available in Outlook Web Access:
Full access to public folders on Exchange 2007 Mailbox servers without having to keep an Exchange 2003 Mailbox server available for public folder access from Outlook Web Access
Public folder search capabilities
Web Parts support
Updating the Public Folder Hierarchy
If you notice that the public folder hierarchy on one server is different from the public folder hierarchy on other servers in your mixed Exchange 2007 and Exchange 2003 organization, you may want to synchronize the hierarchy. In Exchange 2003 Service Pack 2 (SP2), the Synchronize Hierarchy command is used to synchronize the public folder hierarchy on an Exchange 2003 server with the other servers in your organization. In Exchange 2007, the Update-PublicFolderHierarchy cmdlet is used to synchronize the public folder hierarchy on the Exchange 2007 server with the rest of the servers in your organization.
Note:
You cannot run the Synchronize Hierarchy command on an Exchange 2007 server. Similarly, you cannot run the Update-PublicFolderHierarchy cmdlet on an Exchange 2003 server. However, running either command updates the public folder hierarchy in your entire organization.
For more information, see How to Update a Public Folder Hierarchy.
Public Folder Content Replication
To help stop public folder content replication errors in your organization, you can suspend the replication of public folder content. Suspending replication allows you to reconfigure the public folder hierarchy and replication schedules.
To suspend or resume the replication of public folder content in a mixed Exchange 2007 and Exchange 2003 organization, on an Exchange 2007 server, run the Suspend-PublicFolderReplication cmdlet or the Resume-PublicFolderReplication cmdlet in the Exchange Management Shell. Although you run these on an Exchange 2007 server, they will suspend or resume the replication of public folder content on all servers in your mixed organization. For information about using the Exchange Management Shell to suspend or resume the replication of public folder content, see the following topics:
How to Suspend Public Folder Content Replication
How to Resume Public Folder Content Replication
Best Practices
This section provides the best practices to consider when performing the following public folder tasks in your Exchange 2007 organization:
Creating public folder databases
Designing the public folder hierarchy
Performing nightly maintenance
Creating Public Folder Databases
When you plan for how many public folder databases to create in your organization, consider the following best practices:
For large enterprise topologies where public folders are heavily used, deploy dedicated public folder servers. This best practice stems from the general best practice of dedicating CPU resources and disk resources to isolated server functions.
Having fewer larger public folder databases scales better and is more easily managed than having several smaller public folder databases. By reducing the number of public folder databases, you can decrease the time that is required to back up and restore many smaller databases. You also reduce the amount of background replication traffic. Additionally, online maintenance of fewer larger databases is quicker than online maintenance of many smaller databases. Finally, it is easier to manage a smaller number of public folder databases from the perspective of applying permissions and content access, and implementing efficient replication and referrals.
The best practice of having fewer larger public folder databases is especially helpful when you consider your topology from the organization level. However, at the server level, some management and maintenance tasks, such as backup and restore processes, can be more quickly performed if you have several smaller databases. Ultimately, the number of public folder databases that you deploy must address your business requirements. As you determine the number of databases that you want to deploy, you must balance the cost of replication traffic against the costs of database backup, maintenance, and restore times.
Designing the Public Folder Hierarchy
As you design your public folder hierarchy, you must recognize the effect of hierarchy replication in your environment. Deep public folder hierarchies scale better than wide hierarchies. A deep hierarchy consists of many vertically nested folders, instead of many higher-level folders. A wide hierarchy consists of many higher-level folders with fewer vertically nested subfolders.
For example, consider how 250 folders might be arranged in a specific hierarchy. A wide hierarchy might have 250 direct subfolders under one parent folder. A deep hierarchy might have five top level folders, each with five direct subfolders. Inside each of those subfolders may be 10 subfolders.
In both these examples, there are 250 folders (5 × 5 × 10 = 250). However, the deep hierarchy offers better performance than the wide hierarchy for the following reasons:
The way that replication handles folders that have different permissions applied to them is more efficient in deep hierarchies.
Client computer actions (such as sort, search, and expand) against a folder that has 10 subfolders is much less expensive than a folder that has 250 subfolders.
Although deep hierarchies scale better than wide hierarchies, it is a best practice not to exceed 250 subfolders per folder. Exceeding 250 subfolders likely will cause an unacceptable client experience when a client computer requests access.
A factor to consider as you implement a hierarchy is the effect that permissions have on the experience a user has when they want to gain access to public folders. When each public folder subfolder has its own access control list (ACL) entries defined, every time that the Exchange server receives a new public folder replication message, the ACL for the parent public folder must be evaluated to determine which users have rights to view the changes to the parent public folder. If the parent public folder has a large discretionary access control list (DACL) entry, it may take a long time to update the view for each public folder subscriber.
Note:
The DACL for the parent folder consists of the sum of the DACLs of all the public folder subfolders.
You may have many megabytes (MB) of DACL data that must be parsed if the following conditions are true:
You have many subfolders under a single parent public folder.
Each of those subfolders has its own ACL defined.
This DACL data must be parsed so that the display can be updated for all the public folder subscribers every time that a public folder replication message is received.
Therefore, we recommend that you arrange your public folder hierarchy according to the user sets that gain access to the parent folders. Additionally, do not implement complex permission models for your public folder hierarchies.
Performing Nightly Maintenance
To make sure that your databases continue to operate efficiently, we recommend that you perform nightly maintenance on mailbox databases and public folder databases. Exchange 2007 Mailbox servers automate the tasks based upon the schedule that you set.
For more information about mailbox database and public folder database maintenance, see Maintaining Mailbox Databases and Public Folder Databases.
For more information about how to manage the public folder database maintenance schedule, see How to Set the Maintenance Schedule for a Database.
For More Information
For more information about how to manage public folders from Exchange 2007, see the following topics:
Managing Public Folders
Managing Public Folders
Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2007-08-16
This topic lists the management tasks you can perform for public folders, including links to topics that will help you complete the tasks.
Managing Public Folders
The following topics provide instructions for the management tasks that you can perform for public folders.
Managing Public Folder Databases
Managing Public Folder Replication
Managing Public Folder Referrals
How to Create Public Folders
How to Remove Public Folders
How to View or Configure the Settings of Public Folders
How to Update Public Folders
How to Get Statistics for Public Folders
How to Update a Public Folder Hierarchy
Managing Mail-Enabled Public Folders
A mail-enabled public folder is a public folder that has an e-mail address. Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the public folder. Each mail-enabled folder has an object in the Active Directory directory service that stores its e-mail address, address book name, and other mail-related attributes.
Important:
If you are creating a moderated public folder, that public folder must be mail-enabled. If it is not mail-enabled, the database cannot send e-mail because the folder does not have an e-mail address. You can use Microsoft Outlook to create a moderated public folder. For information about how to create a moderated public folder in Outlook 2003, see Create a public folder. For information about how to create a moderated public folder in Outlook 2007, see Create and share a public folder.
The following topics provide instructions for the management tasks that you can perform for mail-enabled public folders.
How to Mail-Enable Public Folders
How to Mail-Disable Public Folders
How to View or Configure the Settings of Mail-Enabled Public Folders
Public Folder Permissions
When new public folders are created, the public folder inherits the parent folder's administrative and client access permissions. You can use Outlook and the Exchange Management Shell to manage permissions for client users who use and manage public folders. You use the Exchange Management Shell to manage permissions for public folder administrators. For more information about public folder permissions, see Configuring Public Folder Permissions.
Using Scripts to Manage Public Folders
The commands that you use to manage public folders in the Exchange Management Shell can be combined into a script. You can use scripts that are installed with Exchange 2007 (as well as other scripts), or you can write your own scripts. Running scripts in the Exchange Management Shell can make public folder administration faster and easier by automating complex or frequently performed tasks. To learn more about using scripts for public folder administration, see Scripts for Managing Public Folders in the Exchange Management Shell.
Accessing Public Folder from Outlook Web Access
Access to public folders through Outlook Web Access for Exchange 2007 has the following requirements:
The home public folder server for the mailbox database must be a server that is running Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server. You can set the home public server by using the Set-MailboxDatabase cmdlet and the publicfolderdatabase parameter.
You must use a dedicated server for the Client Access server role. If the server that hosts the Client Access server role also hosts the Mailbox server role, public folder access may not be reliable through that server when users are accessing Outlook Web Access by using the Internet.
For more information about accessing public folders from Outlook Web Access, see How to Enable Users to Access Public Folders from Outlook Web Access.
Managing Public Folder Databases
Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2008-01-29
This topic lists the management tasks you can perform for public folder databases, including links to topics that will help you complete the tasks.
Cluster continuous replication (CCR), local continuous replication (LCR), standby continuous replication (SCR), and public folder replication are different forms of replication built into Exchange. Due to interoperability limitations between continuous replication and public folder replication, if more than one Mailbox server in the Exchange organization has a public folder database, public folder replication is enabled and public folder databases should not be hosted in CCR, LCR, or SCR environments.
For more information about public folders and high availability options, see the following topics:
Cluster Continuous Replication
Local Continuous Replication
Standby Continuous Replication
Public Folder Database Management Tasks
How to Create a New Public Folder Database
How to View or Modify Public Folder Database Settings
How to Move Public Folder Content from one Public Folder Database to Another Public Folder Database
Moving public folders replicas to another server requires replication of the folder hierarchy and the contents to the target server. For more information about how to update public folder content, see How to Update Public Folders. For more information about how to update public folder hierarchy, see How to Update a Public Folder Hierarchy.
Removing Public Folder Databases
The process for removing a public folder database requires several steps. In addition, the process is different if you are removing the last public folder database in the organization. Be sure to consult this topic before removing any public folder databases.
How to Create a New Public Folder Database
Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2007-09-20
This topic explains how to use the Exchange Management Console or the Exchange Management Shell to create a new public folder database.
Important:
If more than one public folder database exists in your organization, you cannot use cluster continuous replication (CCR), local continuous replication (LCR), or standby continuous replication (SCR). LCR, CCR, and SCR are types of storage group replication. LCR and CCR are available in the release to manufacturing (RTM) version of Exchange 2007 and in Exchange 2007 Service Pack 1 (SP1); SCR is available only in Exchange 2007 SP1. If you have two or more public folder databases in your organization, public folder replication is occurring, even if you have not configured public folders to be replicated. Public folder replication and storage group replication cannot be combined. Therefore, CCR, LCR, and SCR are available for a public folder database only if there are no other public folder databases in the organization. To learn more about CCR, LCR, and SCR, see Cluster Continuous Replication, Local Continuous Replication, and Standby Continuous Replication.
Before You Begin
To perform this procedure, the account you use must be delegated the following:
Exchange Organization Administrator role and local Administrators group for the target server
For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.
Also, before you perform this procedure, be aware of the following:
A server can contain only one public folder database.
Page zeroing is a process that is performed at the end of a streaming backup in which the data within the database is overwritten with characters that you have selected for that purpose. This makes the data unrecoverable by conventional means. As a best practice, if you want to enable page zeroing on a database, you should do so when you create the database. If you do not configure page zeroing when you create the database, the first time page zeroing is run against the database, it will significantly impact server performance. For more information, see Online Maintenance Database Scanning in Exchange 2007 SP1.
Procedure
To use the Exchange Management Console to create a new public folder database
Start the Exchange Management Console.
In the console tree, expand Server Configuration, and then click Mailbox.
In the result pane, click the server on which you want to create the new public folder database.
In the work pane, click the storage group in which you want to create the new public folder database.
In the action pane, click New Public Folder Database. The New Public Folder Database wizard appears.
In the Public folder database name box, type the name of the new public folder database.
(Optional) If you want to specify the location of the public folder database files, click Browse, and then enter the name and location of the new Exchange database file (.edb) for the public folder.
Select or clear the Mount this database check box. The default condition is to mount the database at the completion of the wizard.
Click New. The Completion page appears, indicating whether the public folder database was created successfully. This page also displays the Exchange Management Shell command that was used to create the public folder database.
To use the Exchange Management Shell to create a new public folder database
Run the following command:
Copy Code
New-PublicFolderDatabase -Name "My Public Folder Database" -StorageGroup "Second Storage Group"
Where "My Public Folder Database" is the name of the public folder database, and "Second Storage Group" is the identity of the storage group in which you want to create the public folder database.
Note:
There are multiple ways to specify the identity of the storage group (for example, by the storage group's GUID). For detailed syntax and parameter information, see the New-PublicFolderDatabase reference topic.
Important:
The new public folder database is created in the dismounted state. To mount the new database, run the following command: Mount-Database -Identity "My Public Folder Database". For more information about how to mount databases, see How to Mount a Database.
For detailed syntax and parameter information, see New-PublicFolderDatabase.
