Exchange 2003 Policies

Policies in Exchange Server 2003 are designed to increase administrative flexibility while reducing administrative effort. A policy is a set of configuration parameters that applies to one or more Exchange objects in the same class. For example, you can create a policy that affects certain settings on some or all of your Exchange servers. If you want to change these settings, all you need to do is modify the policy, and the modification will be applied to the appropriate server’s organization.

There are two types of policies: recipient policies and system policies. Recipient policies apply to mail-enabled objects and specify how to generate e mail addresses. Recipient policies are covered in Chapter 9, “Creating and Managing Recipients.” System policies apply to a server, a mailbox store, or a public folder store. These policies appear in the Policies container under the administrative group responsible for administering the policy (Figure 12-10).

Figure 12-10: System policy object.

Note

No default container is created for system policies when Exchange Server 2003 is installed. You must create one before you can start building system policies. Right-click the administrative group in which you want to create the policy folder, point to New, and select System Policy Container.

Creating a System Policy

Generally speaking, creating a system policy involves navigating to the appropriate System Policies container, right-clicking the container, and then selecting the kind of policy you want to create: a server policy, a mailbox store policy, or a public store policy.

When working with system policies, be sure to create the policy object in the administrative group that will be responsible for administering the policy. Failure to do so could lead to the wrong people having administrative control over your critical policies. Let’s take a look at how to create each of the three types of system policies, starting with server policies.

Creating a Server Policy

A server policy enforces message tracking and log file maintenance settings. It is not used to enforce security or other settings on the servers in the administrative group. To create a server policy, right-click the System Policies container, point to New, and then choose Server Policy. You will see the New Policy dialog box (Figure 12-11), where you specify the tabs that will appear in the policy’s property sheet. With a server policy, you’ll have only one choice: the General tab. Select the check box for this tab, and then click OK. You’ll see the configuration box where the policy will be created.

Figure 12-11: New Policy dialog box.

Next, you need to enter the name of your policy on the General tab of the policy’s property sheet. As Figure 12-12 shows, there are actually two General tabs. The first is for naming the policy. Choose a name that describes the task the policy is intended to accomplish, such as Message Tracking Policy or Enable Subject Logging Policy. Good naming at this stage will save you time in the long run because you won’t need to look at the policy’s properties to determine what the policy does.

Figure 12-12: Naming a policy on the General tab.

The General (Policy) tab (Figure 12-13) is the actual policy that is applied to the Exchange servers in your organization. It is named General (Policy) because you are potentially configuring the General tabs of the property sheets of all of your servers. (We discuss how to apply this policy to servers throughout your organization later in this chapter.) If you compare this tab to the General tab in a server’s property sheet, you will find that they are identical, except for the identifying information at the top of the tab.

Figure 12-13: General (Policy) tab.

On the General (Policy) tab, you can enable subject logging and display for all Exchange servers attached to the policy. This setting works in tandem with the Enable Message Tracking option. Together, these two settings ensure that messages passed in your organization can be tracked. Enabling these two options is useful for troubleshooting if some users are not receiving messages from other users. You can track the message through your organization to determine where it is getting stuck to pinpoint where your transport problems exist. For more information about message tracking and subject logging, refer to Chapter 26, “Monitoring Exchange Server 2003.”

Once a policy is in force, it cannot be overridden at the local server level. The message tracking policy we’ve been using as an example was set on the EX- SRV1 server in the Arizona administrative group. Figure 12-14 illustrates that the message tracking options are dimmed in the property sheet for the EX-SRV1 server because these values have been set by a policy.

Figure 12-14: Property sheet for the EX-SRV1 server, showing dimmed message tracking options.

At this point, you might be wondering how we applied the policy to our servers. Here are the steps you need to take to apply a policy after you create it. Simply right-click the new policy, and then choose Add Server. A dialog box opens that lets you choose any combination of servers in your Exchange organization. After you select the servers, click OK, and the policy is attached to those servers. To verify this, select the policy object you just created in the Exchange System snap-in. The servers you added should appear in the details pane (Figure 12-15). You can also check out all the policies that are currently applied to a server using the Policies tab on the server’s property sheet.

Figure 12-15: Servers to which the selected policy applies.

To remove a server from a policy, navigate to the server policy object in the Exchange System snap-in. Highlight the server you want to remove in the details pane. Right-click the server and choose Remove From Policy.

If you make changes to an existing policy after you save your changes, you will be presented with a message box asking whether you want to apply the changes in the policy to all the objects immediately. You can select either Yes or No. Selecting Yes will force the policy to be applied immediately to the target objects. Selecting No will cause the policy changes to be applied at normal replication intervals.

Creating a Public Store Policy

Public store policies encompass a number of configuration options, including maintenance schedules, limits, and full-text indexing. They are applied on a per- store basis across public folder tree boundaries.

The procedure for creating a public store policy is similar to the one for creating a server policy, described in the previous section. However, you have the option of specifying five tabs on the property sheet for a public folder store policy:

• General (Policy) You can enable support for Secure/Multipurpose Internet Mail Extensions (S/MIME) and specify that text should be converted to a fixed-sized font (10-point Courier).

• Database (Policy) You can specify when you would like daily maintenance to run on your public folders.

• Replication (Policy) You can specify how often you would like replication of public folders to occur as well as the replication size limit and the number of minutes that equates to the Always interval.

• Full-Text Indexing (Policy) You can specify the update interval and the rebuild interval for your public folders.

• Limits (Policy) You can specify storage limits, deletion settings, and age limits for all items in all folders in the public folder store (Figure 12-16).

  
  Figure 12-16: The Limits (Policy) tab of the property sheet for a public folder store policy.

You can learn more about the details of public store settings in Chapter 10, “Using Public Folders.”

To apply the policy to your public folders, you’ll need to associate the policy with the folders just as you did for the server policy in the previous section. By default, no policy is actually applied to its intended recipient; you must associate it with the object by choosing Add Public Store from the policy’s shortcut menu.

Unlike server policies, which have only one tab on their property sheets, a public store policy can have up to seven tabs. This doesn’t mean that you have to use all the tabs in a given policy. If you would like to add tabs to or delete tabs from an existing public store policy, all you need to do is right-click the policy and choose Change Property Pages. Then choose the tabs you want to add or delete, and configure them as needed.

Creating a Mailbox Store Policy

A mailbox store policy allows you to configure a number of settings for mailboxes, including the default public folder store, the maintenance schedule, a message journaling recipient that will receive copies of all e-mails that flow through the organization, and full-text indexing. When creating a mailbox store policy, you can choose to include the General, Database, Limits, and Full-Text Indexing tabs in the policy’s property sheet.

Note

Message journaling is a concept that was introduced with Exchange 5.5, Service Pack 1. Essentially, it sends copies of most e-mails to a common recipient for use later in either legal or governmental proceedings. This feature is most often enabled when a company is forced to retain all its e- mails to meet government regulations or for legal purposes.

On the General (Policy) tab, you can specify a default public folder store for the mailbox stores that will be associated with this policy. This ability is very handy when you need to create a large number of mailbox stores and want to associate most or all of them with a particular public folder store. The General (Policy) tab also allows you to specify the default offline address list that your selected mailbox stores will use. You can choose to archive messages on this store. In addition, you can enable client support of S/MIME signatures and a fixed-sized font for all incoming messages.

The only item you can set on the Database (Policy) tab is the time at which daily maintenance will run. If you are creating a public folder store policy as well, consider staggering their maintenance times to allow for better system performance during the online maintenance routine. In your planning, be sure to consider other routines that run during off-hours too, including backup programs, online defragmentation of the database, and replication.

Note

The major tasks that the store runs for online maintenance include making sure that the correct free/busy and offline address book folders exist for an administrative group and, if they don’t exist, creating them; purging database indexes that were previously created but haven’t been used recently; deleting items over the time limit that have exceeded the deleted items retention time (called a hard delete); expiring items in public folders over their age limit; purging deleted mailboxes from the store that are over their retention limit; and detecting mailboxes that are no longer connected to a user object as well as detecting mailboxes that have been reconnected to a user.

On the Limits (Policy) tab (Figure 12-17), you can specify storage limits and deletion settings. Based on mailbox size, you can also choose when you would like the System Attendant service to notify users that they have exceeded their limits. Using the Customize button to create a customized schedule allows you to set more than one time during a 24-hour period when users exceeding their limits will be notified by system e-mail that they need to take action to reduce the size of their mailboxes.

Figure 12-17: The Limits (Policy) tab of the property sheet for a mailbox store policy.

When you apply a mailbox store policy, you do so on a store-by-store basis, not on a per-storage-group or per-server basis. Also, the mailbox store does not need to be mounted for you to be able to associate it with the policy. You can learn more about the details of mailbox store settings in Chapter 11, “Using Storage Groups.”

Managing Policy Conflicts

Two different policies can conflict when applied to the same object. When this occurs, the typical behavior is for the newer policy to override the older policy. However, at times the newer policy will not be able to override the older policy and you will receive a message indicating that the object has been placed under the control of a conflicting policy. You will then be asked whether you want to remove the object from the control of the conflicting policies. Choosing Yes will apply the new policy, and choosing No will keep the old policy.