For a Microsoft Exchange Server 2000 Administrator, knowing and being able to manage Information store is one of the most important challenging tasks. Because the Information store manage and deal with most valuable resources on an Exchange server which is User Data. I will be covering about Exchange 2000 Information Stores and its features, Stores and Storage Groups, The internal structure of the Store, details of the Extensible Storage Engine which is used to store our information, and finally details of using Full Text Indexing for your stores. There are a lot of good information available in the Internet, I will try to condense them all and bring the highlights in three-part article.

Introduction

In Part I, we will look at Stores and Storage Groups in more detail. Each Exchange Server deployed in an organization has an information store. The information store can contain storage groups, data stores, and databases. Here we focus on Stores and Storage Group and its management.

Exchange 2000 Information Store 

As you notice the above picture, the core units of Exchange 2000 storage are the Information stores, sometimes referred to as databases. The two types of Exchange stores are worth noting below, as they are created when you install new Exchange Server in an organization.

Storage Groups

Information stores are grouped into Storage Groups (SGs) on an Exchange 2000 server. On the surface, Storage groups & database seem to be the most fundamental Exchange Server components. As you go deeper, the reasons for creating additional storage groups and databases become more clear. Storage groups are the containers for mailbox and public folder stores and each storage group can have multiple data stores. In other words, a storage group is defined as a collection of databases which share a common set of transaction logs and run under a separate instance of ESE to other storage groups.A storage group can contain up to 5 stores. Transaction logs are covered in more detail later in this series.

Creating Additional Storage Groups

You can have maximum four Storage Groups on each Server. Creating additional storage groups results in increased overhead on the Exchange Server. Approximately 100MB of memory is required to bring each SG online in addition to 10MB for each store in that SG. Therefore SGs should only be created when its absolutely required. I can list out the following scenarios where you may want to create additional SGs:

You need more than five stores – A SG can only accommodate 5 stores

ASP hosting to provide maximum data isolation – Stores within the same SG share log files for their data. If a business needs total data isolation they should be given their own SG

You have different back up requirements between stores – Normal backup operations are carried out at the SG level. Therefore if your Exchange server is being backed up once a day, but you have a store which needs to be backed up every 6 hours, put that database in separate SG and configure a separate backup schedule for it.

You need to enable circular logging on some stores – Circular logging is generally not recommended for reasons of recoverable.Because Circular logging will over write the transaction logs. However in some scenarios, such as on connector or news feed servers, you do not need to back up stores. In this case these databases should be put into their own SGs where circular logging has been enabled. Circular logging can only be configured at the SG level.

Number of Stores

The below table shows how many stores and Storage Groups are supported in an Exchange Server.

 Maintenance utilities such as ESEUTIL and ISINTEG require a spare database for temporary storage within the same SG as the database they are running against.

Exchange caches a lot of information for each database. The amount of memory buffers required is directly related to the amount of data in the stores. Microsoft did rigorous testing and estimated that the highest number of SGs that could be safely supported in this environment was 4. In the future with 64 bit Windows, we may see the reintroduction of up to 15 SGs per Exchange servers.

Create and Configuring the stores

To create a store on an Exchange server, use Exchange System Manager (ESM). Right click on the SG and select New, Mailbox (or Public) Store. You will be presented with the dialog box shown in the picture below. The Name field provides a logical display name for the store, from which the physical file names are derived. Clicking OK will allow you to mount the new store. Once mounted, you can start using this database immediately.

Mailbox Store Settings

Creating and Configuring Storage Groups

Mailbox and public stores can be configured with individual settings such as mailbox limits and default replication intervals. Sometimes, however, it is necessary to set the same settings on multiple stores and enforce them so that they cannot be changed except by a select number of administrators. This can be achieved using system policies.
There are three system policies in Exchange 2000:

 Mailbox Store Policy – Used to enforce settings on mailbox store objects
 Public Store Policy – Used to enforce settings on public store objects
 Server Policy – Used to enforce settings on Exchange server objects

Creating System Policies

Policies are created in the System Policy container underneath the Admin Group. If this container does not appear in ESM, then right click the Admin Group and select New, System Policy Container. Right clicking on the container will allow you to create the three types of policies.
When you create a policy, you will be presented with a template of some of the properties of the object that the policy relates to. For example if you create a Mailbox Store Policy the template will contain Limits settings, Database settings and so on. The Exchange server policy will contain Message Tracking options. Properties of the object which do not appear in the policy cannot be enforced and must be set individually on each object.

Once a policy is created you then need to apply the policy. Until you apply it, the policy has no effect whatsoever. You can apply the policy to any object of its own type in the organisation that you have administrator rights to. Once the policy is applied, then properties of that object set in the policy are applied to the object and those properties will then be greyed out so that they cannot be modified on the object itself.

Enforcing Policies

Once a policy is applied to an object, then the properties defined in the policy cannot be modified on the object. However, an administrator can remove an object from a policy and then modify those properties. To remove an object from a policy you must have administrator permissions on the policy itself. In order to enforce policies and prevent administrators removing themselves from them, create a separate Admin Group and move all policies to it. Then only grant policy administrators administrator rights to that Admin Group.

Summary

In part I of this article series I covered the the main components of an Exchange server Information Store - Stores and Storage Groups. We defined Information Store & Storage Groups, understood the numbers associated with Stores and Storage Groups. Now we know how to manage Stores & Storage Groups using system policies. I’ll come back to you soon in Part II to share how the information store is structured.