Programming4us
         
 
 
Applications Server

Microsoft Exchange Server 2003 : Administering Public Folders

5/4/2011 5:58:29 PM

Managing E-Mail Properties for Public Folders

Public folders created natively in Exchange Server 2003 using Exchange System Manager are not mail-enabled by default. This differs from folders that have been migrated from Exchange Server 5.5, which are all mail-enabled during the migration. Therefore, after creating a public folder in Exchange Server 2003, you must mail-enable the folder if you want it to be able to receive e-mail. Mail-enabling a public folder is done through Exchange System Manager.

  1. In Exchange System Manager, navigate to the public folder you want to mail-enable.

  2. Right-click the folder, point to All Tasks, and then click Mail Enable.

Mail-enabling a public folder by default creates e-mail addresses for X.400 and SMTP. You can view these e-mail addresses or add additional addresses, if necessary. If you right-click the public folder that you mail-enabled and click Properties, you will see that there are additional tabs, as follows:

  • E-Mail Addresses

  • Exchange General

  • Exchange Advanced

  • Member Of

E-Mail Addresses Tab

On the E-Mail Addresses tab, you view and create e-mail addresses to be associated with the public folder.

  1. Click the E-Mail Addresses tab.

  2. Click New, and then select SMTP Address from the list of e-mail address types. Click OK.

  3. Type an e-mail address for the folder and click OK.

  4. View the new address on the E-Mail Addresses tab, shown in Figure 1.

    Figure 1. Configuring e-mail addresses for public folders

You can configure alternate e-mail addresses, as well, though there can be only a single primary address.

Exchange General Tab

On the Exchange General tab, you configure properties for the public folder that are similar to what you would configure for a user mailbox. When you click the Exchange General tab, you first see the public folder tree that the folder belongs to, as well as the alias for the folder. Generally, the alias is the same as the folder name, though you can choose to make it different, which is useful if the folder name is long.

Real World: E-Mail Addresses and Aliases

Unless there is a compelling reason to have an alias different from the e-mail address, you should leave it the same. The following is a real-world scenario that illustrates this policy.

The company Fabrikam, Inc. has had the address fabrikam.com for about a year; prior to that, its address was contoso.com. Whenever the administrator set up a new user, his SMTP address always defaulted to @contoso.com, and the administrator would have to change the SMTP address manually to @fabrikam.com. The administrator found the global Recipient Policy setting for defining e-mail addresses and changed the SMTP address policy from contoso.com to fabrikam.com.

When Exchange Server updated everyone’s e-mail addresses based on the new policy, it used the Alias field to regenerate SMTP addresses. Approximately 20 percent of mailboxes, distribution lists, and public folders had matching aliases and SMTP addresses (for example, an employee named Jenny Lysaker had both her SMTP address and alias as Jenny) and were unaffected by the update. However, approximately 80 percent had different aliases and SMTP addresses (for example, an employee named Bob Gage had an alias of BobG and an SMTP address of Bob). In these cases, Exchange overwrote the existing SMTP address with the new one and drew from the Alias field to create the new one. As a result, most employees, distribution lists, and public folders were unavailable to users outside of the organization because their addresses were no longer correct. Faced with the prospect of restoring from backup or manually editing each SMTP address and correcting it (about 750 addresses total), the company chose the latter.

The restoration would be a tedious process, and one that could be avoided by having the aliases match the SMTP address. The administrator caused the problem by having Exchange update all existing addresses, but the inconsistency in naming aliases and e-mail addresses contributed to the seriousness of the problem.


Figure 2 shows the Delivery Restrictions dialog box that opens when you click the Delivery Restrictions button on the Exchange General tab.

Figure 2. Configuring delivery restrictions for a public folder


The delivery restrictions are similar to what you would configure for a user mailbox. If you have folders both send and receive e-mail, you can set limits on the size of the messages. Under Message Restrictions, you have the option of limiting who can send e-mails to the folder. This is useful when you have a folder being used by an application or by a limited group of users and you want to prevent others from sending messages to it. You can also prevent only specific users from sending to the folder.

On the Exchange General tab, click Delivery Options to configure Send On Behalf permissions for the folder and to configure forwarding addresses. If you are using a public folder to support a customer base, such as for receiving feedback e-mail, you might want to allow employees to reply to a customer as the address associated with the folder (such as feedback@contoso.com) rather than using their personal address. You would use a forwarding address if you wanted an additional e-mail address to receive the messages, as well. For example, you might want the main support person for a customer forum to receive the e-mails in their own mailbox in addition to having the messages reside in the public folder.

Exchange Advanced Tab

When you click the Exchange Advanced tab, the options shown in Figure 3 are available.

Figure 3. The Exchange Advanced tab


The first setting you can configure is the Simple Display Name, which controls how the folder appears in address lists. If you have a public folder name that is complex or contains non-ANSI characters, you can specify a Simple Display Name that will appear instead in your address lists.

Often, public folders are created for a specific application or purpose and are not intended to be used by users in the organization. It is useful to hide these folders from address lists so users do not even see them. The Hide From Exchange Address Lists option controls whether these folders are visible in address lists. A hidden folder still functions and can receive messages, but it is not visible when browsing the list of recipients in the Global Address List (GAL).

There is also the option of defining custom attributes for public folders. When configuring recipient objects (typically user mailboxes), Exchange Server 2003 provides fields for defining a number of attributes for the recipient, such as department, title, phone extension, and so on. The list of attributes is not exhaustive, so Exchange Server 2003 allows you to define custom attributes. With public folders, by default you don’t have the option of defining many of the common attributes, but you can click Custom Attributes on the Exchange Advanced tab and define additional attributes for the folder, as required.

Finally, the Exchange Advanced tab informs you of the administrative group in which the public folder resides.

Member Of Tab

The Member Of tab is used to add the public folder to Active Directory groups so that you can make the public folder part of a distribution list. When a public folder belongs to a security or distribution group, it receives all messages sent to the e-mail address associated with the group. The Member Of tab is shown in Figure 4.

Figure 4. The Member Of tab


Since you cannot log on as a folder, putting a public folder in a security group does not allow it to authenticate for accessing any resources. However, security groups can be mail-enabled like distribution groups, so it may be useful to add a public folder to a security group for e-mail alone.

Setting Storage Limits on Public Folders

Public folders are largely unlimited in the type of data they can hold. They are also used to make resources available to users outside of the organization, such as customers. Therefore, the size of public folders can grow quickly. Delivery restrictions can help to keep the size of individual items in the public folder within a defined size, but they do not prevent the folder from growing in size until it fills the hard disk. In order to control the size of the public folder itself, you implement storage limits. The Limits tab of a public folder is shown in Figure 5.

Figure 5. The Limits tab


There are three ways to configure storage limits. You can set storage limits on an entire public store or on individual public folders. You can also create a public store policy and apply the policy to as many public stores as necessary. When you set limits on the public store, all folders in the store inherit those settings. This allows you to configure settings in one place and have the settings applied to many folders (as many as you have in the store).

A public store policy allows you to configure settings in one place and have the settings apply to multiple public stores (up to as many as you have created), which in turn apply to all of the public folders in the public stores. For large organizations, policies greatly simplify the administration of public folder storage. When a policy is applied to a public store, the storage limits cannot be overridden at either the store level or the individual public folder level. However, if you configure storage limits on a public store, you can override the limits on an individual public folder basis. This allows you to make exceptions to the limit settings configured at the store level.

Age Limits

One important feature of storage limits for public folders is the ability to set age limits, which is the amount of time a folder will retain items before automatically deleting them. This feature is disabled by default, but it is very commonly used when public folders are used to host Internet newsgroups, which often generate thousands of messages and gigabytes of content daily. Setting an age limit on this type of content allows you to keep public folders from being cost-prohibitive to maintain in terms of disk space requirements.

Moving Public Folders

Part of the administration of public folders is maintaining the organization of the public folder tree. Depending on who has permissions to create folders, you might find the structure of the tree becoming inefficient and nonintuitive over the course of time as users work with public folders. Exchange Server 2003 allows you to move public folders within a tree so you can maintain a public folder structure that works well for your organization. You can also copy public folders and paste them into other folders in the public folder tree.

Tip

Public folders can only be moved within a public folder tree. You cannot move or copy a folder between trees.


Exchange System Manager is used to move and copy public folders. The easiest way to move a public folder is to drag and drop it from one location to the other. You can also right-click the folder you want to move and click Cut from the menu, and then right-click the destination folder and click Paste. Copying a folder follows a similar format. Right-click the folder that you want to copy and click Copy, and then right-click the destination folder and click Paste.

Public Folder Replication

In a large organization, it is usually inefficient and, at times, even costly for remote sites to access public folders in other sites separated by slower wide area network (WAN) bandwidth. This is especially true when there are toll charges for bandwidth usage. Exchange Server 2003 supports replication of public folders, which places replicas of folders in other public stores. A replica can be placed in a public store on a server in another site and the content replicated back and forth on a schedule (such as after business hours).

Every server in an organization has a Default public store that is associated with the Default public store tree. In order to set up replication for public folders you have created in additional public folder trees, you must first create a public store on the server that will hold the replica. When you configure a public store, you associate it with a particular public folder tree. Even though you associate the store with an existing tree, this by itself does not enable replication. Once you have a public store on a destination server, you can configure a public folder to replicate to the other server.

To replicate a public folder, perform the following steps:

1.
In Exchange System Manager, navigate to the Folders container and expand the list of public folder trees. Expand the tree that contains the folder you want to replicate.

2.
Right-click the desired public folder, and then click Properties.

3.
Click the Replication tab, shown in Figure 6.

Figure 6. Configuring replication properties


4.
Click Add. This will open a dialog box that lists the servers with an available public store. Select a public store and click OK.

5.
Typically, there is no need to change the Public Folder Replication Interval, which is the schedule, or the Replication Message Priority. However, you can change their configuration here, if necessary. Once done, click OK to complete the process.

Tip

You can also remove a replica using a similar process, in which you choose to remove rather than to add a replica.


You might change the replication schedule if you have content that needs to be replicated more or less often than normal. For example, you might want a folder that contains important project information to replicate whenever a change occurs. You could configure that folder to replicate on a different schedule than the rest of the folders. Likewise, you can configure a replication schedule at the public store level and have it apply to all public folders in the store. In addition, you can use a public store policy to configure replication settings, just as you did in setting storage limits.

Exchange Server 2003 uses a multimaster replication model, which means that all replicas of a public folder are equal and contain the exact same content. A replica copied from one server to another is a separate instance of a public folder and its content. There is no master replica, which means that modifications to any replica are replicated to other replicas equally.

Depending on the nature of the public folder, you may not want to replicate a particular public folder. For example, you may have a public folder that contains critical customer data that the users in your organization rely on to make business decisions. To ensure that the information contained in the public folder is completely up-to-date, you should consider not replicating that particular public folder.

When considering replicating a public folder, you should also weigh network traffic against client traffic. A folder that contains constantly changing information, such as a newsgroup downloaded from an external site, is probably not a good candidate for replication because replicating such a public folder could result in more network traffic than simply allowing users to access it across the WAN.

Manual Replication

While replication usually occurs according to the defined schedule, there are times when you might need to manually initiate replication rather than waiting for the replication interval to elapse. An example would be when you have just created a new public folder tree or public folder and want to make it available to other servers immediately. You can initiate manual replication on both public folder trees and public folders. To replicate a public folder tree manually, perform the following steps:

1.
Right-click the public folder tree in Exchange System Manager and click Send Hierarchy. The Send Hierarchy dialog box, shown in Figure 7, opens.

Figure 7. Manually replicating a public folder tree


2.
Select the server that you want to replicate from (the source server), and choose one or more servers that you want to replicate to (destination servers). You can choose to resend only changes that have been made since a specified number of days ago.

3.
Click OK, and when Exchange System Manager prompts you that a large amount of network traffic can be generated by this procedure, click Yes to continue.

Manually replicating a public folder is similar to the previous procedure. In step 1, right-click the public folder and then click Send Contents. Steps 2 and 3 are the same.

Public Folder Referrals

When a user connects to a public folder store and the store does not contain a copy of the content the user is requesting, Exchange Server 2003 automatically redirects the user to a server that does contain the content. This occurs behind the scenes with no intervention required by the user and is known as a referral. In the default configuration, Exchange Server 2003 will attempt to refer the user to another server within the routing group and then use the routing group structure to go to a server in another routing group, if necessary. Exchange Server 2003 allows you to configure specific servers to which referrals are allowed and to assign costs to each server in order to prioritize the list of referral servers. To customize the list of referral servers, perform the following steps:

1.
Right-click the desired server in Exchange System Manager and click Properties.

2.
Click the Public Folder Referrals tab, shown in Figure 8.

Figure 8. Configuring public folder referrals


3.
The default setting is to use routing groups. Click the drop-down list under Public Folder Referral Options, and click Use Custom List.

4.
Click Add and then select the servers you want to configure as referral servers. Click OK when done, and then click OK again to save the new configuration.
Other -----------------
- BizTalk 2010 Recipes : Business Rules Framework - Deploying and Undeploying Policies
- BizTalk 2010 Recipes : Business Rules Framework - Calling the Business Rules Engine from an Orchestration
- BizTalk 2010 Recipes : Business Rules Framework - Calling the Business Rules Engine from dot NET
- BizTalk 2010 Recipes : Business Rules Framework - Creating Custom Fact Retrievers
- BizTalk 2010 Recipes : Business Rules Framework - Setting Rule Priorities
- BizTalk 2010 Recipes: Business Rules Framework - Creating Facts
- BizTalk 2010 Recipes: Business Rules Framework - Creating and Testing Rules
- BizTalk 2010 Recipes: Business Rules Framework - Creating a Business Policy
- Exchange Server 2003 : Creating Public Folders (part 2)
- Exchange Server 2003 : Creating Public Folders (part 1)
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 3) - Working with Offline Address Lists & Creating and Applying Recipient Policies
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 2) - Administering Address Lists
- Exchange Server 2003 : Creating and Managing Address Lists and Recipient Policies (part 1) - Creating and Modifying Address Lists
- Microsoft Exchange Server 2003: Configuring Information Stores (part 2) - Moving Exchange Server 2003 Storage Groups and Databases
- Microsoft Exchange Server 2003: Configuring Information Stores (part 1) - Adding Storage Groups and Databases
- Microsoft Exchange Server 2003: Configuring Recipient Objects (part 9) - Managing Mail-Enabled Groups
- Microsoft Exchange Server 2003: Configuring Recipient Objects (part 8) - Moving Mailboxes with the Microsoft Exchange Mailbox Merge Wizard
- Microsoft Exchange Server 2003: Configuring Recipient Objects (part 7) - Moving Mailboxes with the Exchange Task Wizard
- Microsoft Exchange Server 2003: Configuring Recipient Objects (part 6) - Configuring Mailbox Permissions
- Microsoft Exchange Server 2003: Configuring Recipient Objects (part 5) - Configuring Storage Limits with Mailbox Store Policies
 
 
Most View
- Central Management Servers (part 3) - Configuring Multi-Server Query Options
- ASP.NET 4 in VB 2010 : Site Maps (part 2) - Binding an Ordinary Page to a Site Map, Binding a Master Page to a Site Map
- Securing Windows 7 : Thwarting Snoops and Crackers (part 2) - Locking Your Computer Manually, Automatically
- Windows 7 : Understanding User Account Control (part 1) - Elevating Privileges
- Windows Server 2008 : Work with Group Policy Modeling and Results
- Windows 7 : Configuring Windows Defender to Scan Email
- Managing Websites with IIS Manager (part 1) - Creating a Virtual Directory
- Windows Server 2008 Server Core : Configuring the Command Window
- Windows 7: Managing Your Hardware with Device Manager (part 1)
- Windows 7: Troubleshooting Device Problems (part 3)
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS