a public folder is a folder created to share information with others.

The owner of
a public folder can set privileges so that only a select group of users have
access to the folder, or the folder can be made available to everyone on the
network who uses the same mail client. Public folders in Outlook can contain
contacts, calendar items, messages, journal entries, or Outlook Forms. 

Public folder is shared folder it is used for share information within workgroup or organization.

1. The owner of public folder can set privilege so that selected users can access the folder.
2. Public folders in Outlook can contain contacts, calendar items, messages, journal entries,
or Outlook Forms. 
3. Public folders are hierarchically organized
4. It stored information in dedicated databases
5. Public folder replication is enabled between mailbox servers.
6. Public folder does not used for archive data.
7. In exchange server 2003 public folder is used for distribute OAB and free busy
information
8. If we outlook 2003 in exchange server 2010 then we need public folder.

Public Folder Database Creation During

Setup
 

When 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 isn't created.

When you install the second server, you aren't prompted with the question, and Setup doesn't
create a public folder database.

In a mixed Exchange organization, Setup doesn't prompt you with the question. In these
organizations, to ensure backward compatibility to Exchange versions prior to Exchange Server
2007, a public folder database is created by default. Specifically, because Exchange 2010 is
installed in its own administrative group, this public folder database will support legacy
Schedule+ free and busy functionality.

Public Folder Trees

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 can't access these
folders directly by using conventional methods.

The public folder tree contains additional system folders, such as the EFORMS REGISTRY
folder, that don't 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 server 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).

o 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.

o OWAScratchPad   Each public folder database has an OWAScratchPad folder,

which is used to temporarily store attachments that are being accessed by using
Microsoft Office Outlook Web App. Don't modify this folder.

o StoreEvents   Each public folder database has a StoreEvents folder, which holds

registration information for custom Exchange database events. Don't modify this
folder.

o Other folders   To support internal Exchange database operations, a tree may

contain several other system folders, such as schema-root. Don't modify these
folders.

Public Folder Referrals

When a client application 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.

Mail-Enabled Public Folders

 1. 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.
2. If you're developing custom applications, you can use this feature to move messages or
documents into or out of public folders.
3. A mail-enabled folder is a public folder that has an e-mail address. it may appear in the
global address list (GAL).
4. Each mail-enabled folder has an object in Active Directory that stores its e-mail address,
address list name, and other mail-related attributes.

Considerations with Mixed Exchange

2010 and Exchange 2007 Organizations
In a mixed Exchange 2010 and Exchange 2007 organization, you need to manage your public
folders and public folder databases from Exchange 2010. Exchange 2007 servers don't recognize
Exchange 2010 public folder databases due to Active Directory schema changes. The following
table describes the expected behaviors when performing certain public folder management tasks
on Exchange 2007 servers and Exchange 2010 servers.

Tasks Exchange 2007 servers Exchange 2010 servers

If any Exchange 2010 mailbox databases are in
your organization and don't have the
msExchHomePublicDB attribute populated, the
Exchange 2007 server can't update the Exchange
2010 mailbox database's
msExchHomePublicDB setting. Although you
receive an error message, the public folder
Create a public
database is created. Always works.
folder database
After you create the public folder database, you
need to change the default public folder
database. You need to perform this procedure
from an Exchange 2010 server. For details, see
Change the Default Public Folder Database for a
Mailbox Database.
Remove the default If any mailbox databases are pointing to the Works on both Exchange
public folder public folder database that you're trying to 2007 and Exchange 2010
database remove, you receive an error message advising servers provided that no
that you need to change the default public folder mailbox databases have
 database. To change the default public folder
database, perform the following steps:

1. On an Exchange 2010 server, change the

default public folder database for the
mailbox database. For details, see
Change the Default Public Folder
Database for a Mailbox Database.

2. On the Exchange 2007 server, remove all

replicas of that public folder database. the public folder
For details, see Remove Multiple Public database that you're
Folders from a Public Folder Database. trying to remove as the
default public folder
3. On the Exchange 2007 server, remove
database.
the public folder database. For details,
see Remove Public Folder Databases.

Note:
If the new default public folder database that
you're pointing the mailbox databases to is an
Exchange 2010 public folder database, see "Set
an Exchange 2010 public folder database as the
default public folder database for an Exchange
2007 mailbox database" later in this table.
If this is the last Exchange 2007 public folder
Works on both Exchange
database in the organization, the Remove-
2007 and Exchange 2010
PublicFolderDatabase cmdlet needs to update
servers provided that no
Remove the last the msExchFirstInstance property on the
mailbox databases have
public folder Exchange 2010 public folder database to $true.
the public folder
database in the This fails because the object version of the
database that you're
organization Exchange 2010 object is higher.
trying to remove as the
default public folder
Run the Remove-PublicFolderDatabase cmdlet
database.
from the Exchange 2010 server.
Set an Exchange Changing the default public folder database Always works and
2010 public folder doesn't work on an Exchange 2007 server if should be used to change
database as the either the mailbox database or the public folder the default public folder
default public folder database is an Exchange 2010 database. databases if your public
database for an folder database and your
Exchange 2007 Because Exchange 2007 servers don't recognize mailbox database are
mailbox database the Exchange 2010 public folder databases, the associated with different
Set-MailboxDatabase cmdlet must be run on an versions of Exchange.
Exchange 2010 server.
 On the Exchange 2010 server, change the default
public folder database for the Exchange 2007
mailbox database. For details, see Change the
Default Public Folder Database for a Mailbox
Database.

Return to top

Considerations with Mixed Exchange

2010 and Exchange 2003 Organizations
When you install Exchange 2010 in an Exchange 2003 organization, Setup automatically creates
an administrative group and routing group within the Exchange 2003 organization. The
Exchange 2010 servers 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 2010 Mailbox server. In that public folder database, Setup creates a free and busy
folder for the new administrative group. The legacyExchangeDN property for users whose
mailboxes were created on an Exchange 2010 server (and not migrated from Exchange 2003)
maps to the Exchange 2010 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 2010, 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 2010.

 In a pure Exchange 2010 environment or a mixed Exchange 2010 and Exchange 2007
organization, you can't 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 Shell for public folders that exist on an
Exchange 2010 or Exchange 2007 server.

Outlook Web App

In a mixed Exchange 2010, Exchange 2007, and Exchange 2003 organization, one of the
Exchange 2010 and Exchange 2007 Client Access servers has a virtual directory named /public.
You can fully access public folders from Outlook Web App without having to use the /public
virtual directory. In addition, the following public folder features are available in Outlook Web
App:

 Full access to public folders on Exchange 2010 Mailbox servers without having to keep
an Exchange 2003 Mailbox server available for public folder access from Outlook Web
App

 Public folder search capabilities

 Web Parts support

Return to top

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, 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 2010, the Update-PublicFolderHierarchy cmdlet is used to synchronize the public
folder hierarchy on the Exchange 2010 server with the rest of the servers in your organization.

Note:
You can't run the Synchronize Hierarchy command on an Exchange 2010 server. Similarly,
you can't 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 Update a Public Folder Hierarchy.

Return to top

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 organization, on an
Exchange 2010 server, run the Suspend-PublicFolderReplication cmdlet or the Resume-
PublicFolderReplication cmdlet in the Shell. Although you run these cmdlets on an Exchange
2010 server, they will suspend or resume the replication of public folder content on all servers in
your mixed organization. For information about using the Shell to suspend or resume the
replication of public folder content, see the following topics:

 Suspend Public Folder Content Replication

 Resume Public Folder Content Replication

Return to top

Best Practices
This section provides the best practices to consider when performing the following public folder
tasks in your Exchange organization:

 Creating public folder databases

 Designing the public folder hierarchy

 Performing nightly maintenance

Creating Public Folder Databases

When you plan 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 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. Also, 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's 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 users have 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:

 There are 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, don't 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
Mailbox servers automate the tasks based upon the schedule that you set.

Understanding Public Folder Permissions

You can configure public folder permissions for administrators or for users of client programs
such as Microsoft Outlook. Public folder permissions consist of various access rights that specify
the level of control a client user or administrator has over a public folder or public folder
hierarchy.

Client User Access Rights and Roles

Use the Exchange Management Shell to configure the permissions for users who use client
programs such as Outlook to access public folders. Whether you want to manually select the
access rights or use predefined roles that contain specific access rights, you'll use the Add-
PublicFolderClientPermission cmdlet.

Important:
To make sure users can send e-mail messages to a mail-enabled public folder, the public folder
must have at least the CreateItems access right granted to the Anonymous account.

The following is a list of client user access rights (followed by a table that shows the predefined
permission roles):

 ReadItems   The user can read items within the specified public folder.
  CreateItems   The user can create items within the specified public folder and send e-
mail messages to the public folder if it's mail-enabled.

 EditOwnedItems   The user can edit the items that the user owns in the specified public
folder.

 DeleteOwnedItems   The user can delete items that the user owns in the specified public
folder.

 EditAllItems   The user can edit all items in the specified public folder.

 DeleteAllItems   The user can delete all items in the specified public folder.

 CreateSubfolders   The user can create subfolders in the specified public folder.

 FolderOwner   The user is the owner of the specified public folder. The user can view
and move the public folder, create subfolders, and set permissions for the folder. The user
can't read, edit, delete, or create items.

 FolderContact   The user is the contact for the specified public folder.

 FolderVisible   The user can view the specified public folder, but can't read or edit items
within the specified public folder.

The following table lists the predefined public folder roles and the access rights that are included
in each role. The table headers reflect the access rights listed previously in this topic.

Note:
The FolderOwner access right and the Owner role have different permissions as shown in the
following table.

Access rights included with each predefined public folder role

Fol
Create Read CreateSu Folder der Folder EditOwn EditAl DeleteOw DeleteA
Role
Items Items bfolders Owner Con Visible edItems lItems nedItems llItems
tact
None                X            
Owner X X X X X X X X X X
Publishin
X X X       X X X X X
gEditor
Editor X X          X X X X X
Publishin
X X X       X X    X X
gAuthor
Author X X          X X    X   
Non-
EditingA X X          X            
uthor
Reviewer    X          X            
Contribut
X             X            
or

Note:
Client users can use Outlook to manage public folder permissions for public folders that reside
on a server running Microsoft Exchange Server 2010. For information about how to manage
public folder permissions from Microsoft Office Outlook 2007 or Outlook 2010, see Create and
Share a Public Folder. For information about how to manage public folder permissions for public
folders that reside on Exchange 2010 servers from Office Outlook 2003, see Outlook folder
permissions.

Administrator Access Rights

In Exchange 2010, there are two ways to grant administrators the rights to manage public
folders:

 Public Folder Management role group

 Add-PublicFolderAdministrativePermission cmdlet

The following table describes the differences between the rights that are granted by the Public
Folder Management role group and the rights that are granted by using the Add-
PublicFolderAdministrativePermission cmdlet.

Administrator access rights differences

Add-PublicFolderAdministrativePermission
Public Folder Management role group
cmdlet
The user can create top-level public folders. The user can't create top-level public folders.
The user is granted the AllExtendedRights
The user can be granted or denied specific rights
permission to public folders and the rights to
to public folders.
run the public folder cmdlets.
The user can administer any top-level public
The user can be granted the right to administer
folder, child public folder, and system public
specific top-level public folders and specific
folders in the public folder tree. In addition,
child public folders. However, the user's access
this user's access rights can't be revoked by
rights can be revoked by using the Remove-
using the Remove-
PublicFolderAdministrativePermission cmdlet.
PublicFolderAdministrativePermission cmdlet.
The Public Folder Management role group is a Not applicable
Role Based Access Control (RBAC) role
group that consists of the following roles:

 Mail-Enabled Public Folders role

 Public Folders role

 Public Folder Replication role

For more information, see Public Folder

Management.

The following list describes the standard set of administrative access rights that can be set on a
public folder:

 None   The administrator doesn't have any rights to modify public folder attributes.

 ModifyPublicFolderACL   The administrator has the right to modify Client Access

server role permissions for the specified folder.

 ModifyPublicFolderAdminACL   The administrator has the right to modify

administrator permissions for the specified public folder.

 ModifyPublicFolderDeletedItemRetention   The administrator has the right to modify

the Public Folder Deleted Item Retention attributes (RetainDeletedItemsFor,
UseDatabaseRetentionDefaults).

 ModifyPublicFolderExpiry   The administrator has the right to modify the Public Folder

Expiration attributes (AgeLimit, UseDatabaseAgeDefaults).

 ModifyPublicFolderQuotas   The administrator has the right to modify the Public

Folder Quota attributes (MaxItemSize, PostQuota, PostWarningQuota,
UseDatabaseQuotaDefaults)

 ModifyPublicFolderReplicaList   The administrator has the right to modify the replica

list attribute for the specified public folder (Replicas).

 AdministerInformationStore   The administrator has the right to modify all other public

folder properties not defined previously.

 ViewInformationStore   The administrator has the right to view public folder properties.

 AllExtendedRights   The administrator has the right to modify all public folder

properties.

Creating Custom Role Groups

In addition to the Public Folder Management role group and the Add-
PublicFolderAdministrativePermission cmdlet, you can create custom role groups that will
allow a user to only perform certain tasks. For example, if you want to allow an administrator to
manage public folders and mail-enabled public folders, but not public folder replication, you can
create a custom role group that includes only the Mail Enabled Public Folders role and the Public
Folders role. For more information about creating role groups, see Create a Role Group.