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.
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.
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.
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.
The below table shows how many stores and Storage Groups are supported in an Exchange Server.
Exchange Version | Total Storage Groups | Stores Per Storage Group | Total Stores |
Exchange 2000 | 4 | 5 | 20 |
| One store is reserved for maintenance (e.g. ESEUTIL and ISINTEG) One Storage Group is reserved for Restore Operation | |||
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.
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.
Property Page | Setting | Description |
| General | Default Public Store | The default public store that clients will connect to when accessing public folders through MAPI or OWA |
| Offline Address List | Offline address list available for Outlook to download | |
| Archive Messages | Message journaling – Archives all messages sent or received on this store to the location provided | |
| Database | Exchange Database and STM file | Location of EDB and STM file |
| Maintenance Interval | Schedule for on-line store maintenance | |
| Limits | Issue Warning | Mailbox size threshold to start sending warning messages to user |
| Prohibit Send | Mailbox size threshold to prevent user from sending messages | |
| Prohibit Send and Receive | Mailbox size threshold to prevent sending and receiving of messages | |
| Keep deleted items | Deleted retention time for deleted messages | |
| Keep deleted mailboxes | Deleted retention time for deleted mailboxes |
| To create a storage group on an Exchange server, use Exchange System Manager (ESM). Right click on the Exchange server object and select New, Storage Group. You will be presented with the dialog box shown in the slide. The Name field provides a logical display name for the storage group, from which the physical folder name containing the SG is derived. Once a SG is created you can proceed to create stores within it. | |||||||||||||
| |||||||||||||
System Policies
|
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.
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.
