Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

       How did you like this article? Please vote and let us know.          

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Shannal L. Thomas
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath

 

 
 

Public Folders in Exchange 2000

This material is reprinted from Exchange 2000 On Site by Göran Husman.
Copyright * 2001 by The Coriolis Group. Used with permission

ghusman@OutlookExchange.com 

Public Folders

Ever since the first release of Exchange has it been possible to share information by using public folders. A public folder is similar to a mailbox folder, except that it can be visible for all users that have permission to see it. The default permission is that all users, regardless of what server they belong to, will be able to use the public folder for storing and reading items. All public folder data is stored in a public store consisting of one EDB file and one STM file. Every Exchange server must have one public store for the standard PF tree.

The public folder has two parts: the name (or hierarchy) and the content. The name is replicated to all servers in the Exchange organization, regardless of how large and distributed it is. It is the Information Store process that is responsible for this replication, not the Active Directory. The content in a public folder is only stored in one place, the public store belonging to the server where the item was created. This means that the folder name will be visible (unless it's hidden) to all users in the entire organization, but the content may or may not be accessible, depending on whether the client has access to the public store.

The Public Folder Hierarchy

In Exchange 2000, there are two possible types of public folders: MAPI folders and General Purpose (GP) folders. When you install an Exchange server, you will, by default, get the “All Public Folder” tree, which is a MAPI type of folder. It is the same as the public folder tree in previous versions of Exchange. The MAPI public folder tree can be seen by all types of clients who understands public folders, like Outlook (MAPI) clients, Web clients, IMAP4 and NNTP; it will also be visible through the file system, thanks to the ExIFS. The GP type of public folder, on the other hand, must be created manually. It is only visible for Web clients, NNTP, and by using ExIFS, applications like Word and Excel.

The names of the MAPI public folders are replicated to all public stores, making them globally visible. This can be a problem if you don’t have strict policies for creating public folders. Any Outlook client can create a public folder, and by default, all users have permission to do that. This could easily result in a public folder chaos. If, for example, we were to assume that you have an Exchange organization distributed over 3 different countries, and each country has one Exchange server with 300 users, you would have a total of 900 users. Now if every individual user creates one public folder each, the result would be 900 public folders showing up in each and every one's Outlook client. And to make matters worse, it could be that you are only able to access the content on folders belonging to your own server, depending on how your network is configured.  

Restricting Top Level Folder Creation

The best thing to do would be to take control of the situation right from the beginning by restricting the permission to create public folders in the top of the folder tree (also known as the “Top Level folders”) to a small group, making this group your official public folder administrators. This can be done with the ESM tool. Microsoft has an article about this, titled “Restricting users from creating top level folders in Exchange 2000 Server”, in which it describes how to use the Security tab for the Public Folders folder and deny the group Everyone “Create top level public folder” permission. But the problem is that this method is not really practical. If you do that, no one will be able to create a top-level folder, not even the administrator. This is due to the fact that in Windows 2000 a “deny” permission has priority over all other permissions; and all users belong to the group Everyone, even the administrators. The problem comes from the fact that this permission is inherited from the Exchange organization object. But when you look at the properties for that object, it doesn’t have any security tab displayed. Use the following method to display that security tab and remove the “Create top level public folder” permission for the group Everyone from the organization object:

   1.      Start the Regedit.exe utility

   2.      Locate the following key in the registry:
            HKEY_CURRENT_USER\Software\Microsoft\Exhange\EXAdmin

   3.      On the Edit menu, click Add Value and add this new registry value:
            Value Name: ShowSecurityPage
            Data Type: REG_DWORD
            Value: 1  
            Now you will see the Security tab for the Organization folder.

   4.      Use the ESM and right click on the Exchange organization object at the top
            of the tree; select Properties. Now you have the Security page displayed.

   5.      Locate the Everyone group in the Name pane

   6.      Remove the Allow permission for the “Create top level public folder”.
            Don’t select Deny since this would create the same result as the first method
            Microsoft recommends.

The only user that can create a top level public folder now is the Exchange administrator. I recommend that you create a special group for your Exchange public folder administrators and give that group permission to add top level folders.

NOTE: The registry method mentioned above is local for the computer where you add this new registry value. If you are using the ESM on more computers than one, you should add this registry value to all of them.

Mail-enabling Public Folders

If your mail enables a public folder, an object for this folder will be created in the Active Directory, but the address will not be displayed in the global address list. All MAPI folders will be automatically mail enabled, but hidden, if you run your Exchange organization in mixed mode. Table 2.4 describes the relationship between MAPI and GP folders in mixed versus native mode.

Table 2.4 MAPI and GP folders in mixed versus native mode.

PF type          Mixed mode                                    Native mode

MAPI             Mail enabled by default (cannot be     Mail disabled by default, can be enabled.
   
                    mail disabled). Default hidden from     If enabled it will, by default, be visible in
                       the global address list.                         the global address list

GP                  Mail disabled by default, can be          Mail disabled by default,
                       enabled. If enabled it will, by               can be enabled. If enabled it will
                       default, be visible in the global             by default be visible in the
                       address list.                                         global address list.


This material is reprinted from Exchange 2000 On Site by Göran Husman.
Copyright * 2001 by The Coriolis Group. Used with permission

/Göran Husman
MCSE, MCT

CEO Human Data

Back to Goran Husman's column on OutlookExchange


Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Pro Exchange. OutlookExchange.Com and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

© Copyright Pro Exchange, Inc., 2006