![]() |
|
|
| Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site | ||
|
|
Public Folders in Exchange 2000This material is reprinted from Exchange 2000 On Site
by Göran Husman. 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. 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:
3. On
the Edit menu, click Add Value and add this new registry value:
4. Use
the ESM and right click on the Exchange organization object at the top
5. Locate
the Everyone group in the Name pane
6. Remove
the Allow permission for the “Create top level public folder”. 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. 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. GP
Mail disabled by default, can be
Mail disabled by default, This material is reprinted from Exchange 2000 On Site
by Göran Husman. /Göran Husman 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