When you install Exchange 2000, the Setup program automatically creates a default storage group and some default stores. While these default components will get the job done, they’re not necessarily the configuration of choice for every situation. In order to get the maximum performance out of your Exchange server, you need to know how to create, delete, and modify storage groups and the stores within them.

Why use storage groups?
Whether you’re installing Exchange from scratch or upgrading from a previous version, the Exchange 2000 Setup program creates a storage group called First Storage Group. By default, this storage group contains a mailbox store and a public folder store. Under normal circumstances, the first storage group and the two stores that it contains are all you need. But there are several reasons for modifying the storage group structure. For starters, the Exchange 2000 transaction logs apply to the storage group rather than to the individual stores. Therefore, if you wanted a store to have an independent set of transaction logs, you could place the store into its own storage group. Keep in mind that each active storage group places a certain load onto the server because the server must keep up with the transaction logs for each group, along with performing a few other minor administrative tasks.

As you’ll see later, there are times when it’s appropriate to place a store into its own storage group. Generally speaking, though, it’s a bad idea to put each store into its own storage group because of the added load this strategy puts on the server. But there are times when the creation of additional storage groups is the correct strategy, despite the greater burden on the server.  For example, creating storage groups will help you keep groups of mailboxes or public folders completely separate from each other. Also, some companies host e-mail services for smaller companies. Rather than buying a separate server for each company, the host companies group the small companies onto a single Exchange server. In such a situation, each of the hosted companies would usually have its mailboxes and public folders stored in an independent storage group to segregate them from those belonging to other hosted companies.

I’ve also seen additional storage groups used in high-security environments. One company that I deal with has its Exchange server configured so that the human resources department and the financial department use separate storage groups from everyone else. Moving these mailboxes into separate storage groups means there’s less chance of another user hacking into a human resources or finance department mailbox containing confidential data.

One of the strangest but most interesting uses of storage groups that I’ve come across was a case in which a friend actually used an Exchange storage group for disaster recovery. My friend had been called in to look at an Exchange server that had crashed. He soon discovered that the server had a corrupt database and that no backups were available. To fix the problem, he moved the corrupt database into its own storage group. He then recreated the corrupt store in its original location and manually rebuilt the mailboxes that the store contained. This meant that although the users’ mailboxes were empty, they were now at least able to send and receive mail. With the corrupt database safely out of the way, he set to work trying to extract data from it. The information he recovered was placed into the newly created store.

Any of the situations described above could be handled differently, and in some cases probably should be. Remember that Exchange 2000 allows you to create multiple stores within a storage group. Therefore, if you want to segregate departments or hosted companies, or even perform some sort of bizarre disaster recovery operation, you can easily do it with a separate store within a common storage group rather than creating a brand new storage group. So if it’s possible to create multiple stores within a storage group, and additional storage groups create additional server overhead, why would you ever want to create additional storage groups?

The reason is that separate storage groups act as completely separate entities with their own set of transaction logs. If you need to separate groups of mailboxes or public folders, placing them into entirely different storage groups not only creates an extra level of security, but it also provides some level of insulation from disaster. For example, if a store in Storage Group A were to fail, you could restore that store and replay the transaction logs without affecting Storage Group B. There is definitely something to be said for this type of isolation. You must simply decide if the benefits of isolating each store outweigh the additional load the storage groups place on the server.

Creating storage groups
As you’ve probably already figured out, storage groups are a server-level component. They’re not like routing groups or administrative groups, which can include multiple servers. To create a storage group, open the Exchange System Manager and navigate to your organization | Administrative Groups | your administrative group | Servers | your server. If you expand the server object, you’ll see the first storage group and any other existing storage groups. Now, right-click on the server object and select New | Storage Group from the resulting shortcut menus. When you do, the new storage group’s properties sheet will appear. This properties sheet contains only a few fields that must be completed. However, it’s worth taking a close look at these options because they have such a huge impact on the system’s overall performance.

The first thing you must supply is a name for the storage group. You can use any name as long as it isn’t already in use. I recommend using a meaningful name. As you enter the name, the Transaction Log Location and the System Path Location fields will automatically be completed. While you can certainly accept the values that Exchange places into these fields, I suggest taking a closer look at these locations.

There are a lot of different philosophies about where the system path and the transaction logs should be placed. There really isn’t a right or wrong way to set up these paths, but some paths are definitely more desirable than others. When choosing the location for these paths, you should place the system path on a physical drive separate from that of the transaction path. The idea behind this strategy is that if your hard disk dies, you don’t want the transaction logs to be on the same disk as the database, since the transaction logs are used in the recovery process. Therefore, make sure to use a separate physical drive—not just a separate partition.

An ideal situation would be to have two completely independent, super-fast RAID arrays. You could then place the system path on one array and the transaction logs on another. If you don’t have this luxury, I suggest placing the system path on the drive with the greatest amount of free space and placing the transaction logs on your fastest drive. Remember that when transactions occur, Exchange writes to the transaction logs first and then to the database later. Therefore, the transaction logs need to be placed on a drive that’s fast enough to keep up with the transactions as they occur in real time.

Next on this properties sheet is the option to zero-out database pages. If you select this option, which is a security feature, Exchange will fill a database page with zeros when the page is erased. This makes it much more difficult to recover any data that previously existed on the page. Zeroing out databases is a great security feature, but it significantly increases the burden on your server. Therefore, if your server has CPU power to spare, or if your Exchange server exists in a high-security environment, use this option. Otherwise, you’re better off leaving this box unchecked.

The last option on the properties sheet is a check box that allows you to enable circular logging, a mechanism that prevents your transaction logs from outgrowing the hard disk. With circular logging, Exchange starts overwriting the first transaction log file after the fifth transaction log file is filled up.

I recommend using circular logging as long as your server doesn’t perform enough transactions during the course of a day to complete a full circle, and as long as the server is backed up on a daily basis. If either of these conditions aren’t true, then you’re better off not using circular logging because doing so may prevent you from being able to completely recover from a disaster should you need to restore a backup. The only time that I’d recommend using circular logging if either of the conditions above isn’t true would be in cases in which the server simply doesn’t have enough disk space to accommodate the necessary transaction logs.

Moving storage groups
You can’t really move a storage group. After all, a storage group is a logical, server-level structure. What you can do is move the transaction logs or the location of the databases within a storage group. Both of these operations are very common for a couple of reasons: First, you might have to move a database or a set of transaction logs if your server is running low on disk space: second, you may have inherited an Exchange server that had the databases and transaction logs configured to exist on the same hard disk.

To move either the transaction logs or the system path location, right-click on the storage group and select Properties. When you do, you’ll see the storage group’s properties sheet, as shown in Figure A.

Figure A
The storage group’s properties sheet will allow you to relocate the system path or the transaction logs.

You can now use the Browse buttons to locate the new location for the transaction logs or for the system path. When you click OK, you’ll see a message explaining that you are about to move the component. If you accept this move, the stores will be temporarily dismounted until the move is complete.

You also have the option of moving individual stores within the storage group to new locations. To move an individual store, right-click on the store and select the Properties command from the resulting shortcut menu. When you do, you’ll see the store’s properties sheet. Select the Database tab and then enter the database’s new location into the space provided. When you click OK or Apply, you’ll see a warning that the database is about to be moved. If you move the database, it must be temporarily dismounted for the duration of the move.

Deleting storage groups
As strange as it may seem, there are situations in which you might want to remove a storage group. For example, if you’ve condensed the stores from the storage group into another storage group, there’s no point in keeping the empty storage group. You might also want to delete a storage group if the store contained within it has been damaged beyond repair and no backup exists.

Before you can delete a storage group, you must either move or delete the stores within it. To delete a store, simply right-click on it and select the Delete command from the shortcut menu. Exchange will ask you to confirm your intentions and will then display an interesting message. The message states that the database must be manually deleted. The reason for this is a safety feature. When you delete a store through the Exchange System Manager, the reference to the store is removed from Active Directory, but the store’s actual database remains on the hard disk.

Once you’ve deleted any stores within a storage group, you can delete the storage group by right-clicking on it and selecting the Delete command from the resulting shortcut menu. After the storage group is gone, it’s up to you to manually remove the log files and the checkpoint file.