Disaster Recovery

Planning and creating Exchange 2000 storage groups

Storage groups can vastly improve Exchange 2000's performance and reliability. But how do you plan and implement them? In this Daily Drill Down, Jim Boyce shows you how.

I introduced you to Exchange 2000 storage groups in the Daily Drill Down entitled “Understanding Exchange 2000 Server storage groups,” but I’m sure you’re wondering how to plan for and create them. In this Daily Drill Down, I’ll show you how.

Planning your groups
Storage groups add a whole new level of complexity to Exchange 2000. This added complexity is not necessarily a bad thing, because it gives you flexibility. However, complexity and flexibility mean that you must also plan more. For example, will you use a single storage group with multiple databases? How many databases will you use in each storage group (reserving one for Isinteg), and how much space do you expect each one to require?

As you’re considering these issues, think about how Exchange Server availability will affect different users. If you have certain groups that must have as little downtime as possible, those groups should have their own databases, if not their own storage groups. But don’t stop at simply separating groups into different databases or storage groups. If you have a department that performs mission-critical functions requiring continued Exchange Server access, break that department into multiple databases. This will enable most users in the department to continue working even if a problem occurs with one of the stores in the group.

Assume you have a sales force of 500 users, for example. If you used a single store for all of them and the store became corrupted, everyone would be down while you brought the store back online. If you used five separate stores, however, only 20 percent of the users would be down, and the rest could continue working without interruption.

The number of users you need to accommodate is also an important consideration. As the number of users grows, the need for additional stores and storage groups increases to ensure smaller databases for faster backups and restores. Adding other stores also helps reduce the impact of a corrupted store, even when the users are not performing mission-critical tasks.

Archival and recovery planning
Another consideration when you’re planning your storage groups is the backup and recovery scheme you’ll employ to protect your stores and storage groups. Examine the needs of each group to determine how individual databases or each storage group needs to be backed up. For example, you might decide that backing up once a week is adequate for certain stores (such as newsgroup folders) but daily backups are required for other stores. Some departments or businesses might need more frequent backups than others.

When analyzing disaster recovery requirements, also take into account the capacities and capabilities of your backup equipment. Compare the backup throughput of the backup system with the amount of data you expect to be backing up in each storage group and/or store (database). This will tell you how long it will take to back up each store. That information will help you determine how to structure the storage groups for disaster recovery.

If you need to make sure that you can recover a store for a particular group of users in no more than an hour, for example, determine the restore throughput and then determine how much data you can restore in 30 minutes (because you’ll spend the other 30 minutes initiating, troubleshooting, and verifying the process). With that information in hand, work backward to determine how large the store can be based on the throughput for the backup system. Divide that size by the estimated requirements per user to determine how many users you can put in a store. Then, create as many stores as necessary to accommodate the entire group of users based on that limit.

As you develop your disaster recovery plan, keep in mind that the transaction logs in a given storage group apply to all stores in the group. Just backing up a particular store isn’t enough. You also have to back up the transaction logs. You should consider the storage group to be the smallest backup unit in any backup.

Determining the number of servers required
After you analyze your organization, hosting requirements, capacity needs, and disaster recovery needs, you’ll be able to decide how many stores you need to accommodate all of your users, departments, businesses, and so on. With that number in hand, you can find the number of servers you’ll need.

For example, assume that after your lengthy analysis you determine that you need a total of 37 stores to achieve the performance and reliability levels you require. You can host six stores per storage group, but we’ll assume a maximum of five to allow for recovery as explained previously. This means 37/5 storage groups, or a total of eight storage groups, which will accommodate up to 40 stores. So, at a maximum of four storage groups per server, you need two servers to accommodate your 37 stores.

Creating storage groups
The planning process for implementing storage groups takes considerably longer than actually creating them. In fact, creating storage groups and stores is a relatively easy process. The following sections explain how to do it.

The first step is to create the new storage group. To do so, open the Exchange System Manager and expand the Servers branch. Right-click the server on which you want to create the storage group and choose New | Storage Group. The Exchange System Manager opens a property sheet for the storage group. The General page includes the following options:
  • Name: Specify the name by which you want the new storage group displayed in the Exchange System Manager.
  • Transaction log location: Specify the path where you want the transaction log stored. The default is \Program Files\Exchsrvr\name, where name is the storage group name specified in the Name field.
  • System path location: Specify the location for storing temporary and recovered files. The default is the same as the default transaction log location.
  • Log file prefix: This field displays the log file prefix assigned to the transaction logs. This field is blank when you create a new storage group but displays the prefix when you view the properties for an existing storage group.
  • Zero out deleted database pages: Select this option to have Exchange remove deleted database pages from the hard drive. Removing the pages provides better security because deleted data is actually deleted from the drive, but it imposes additional overhead that has an impact on performance.
  • Enable circular logging: Select this option to allow Exchange to perform circular logging on the storage group, replacing log files that have a time stamp older than the checkpoint file.

You can use the Details page to add an administrative note to the storage group. For example, you might include notes about its intended use, responsible parties, and so on. The comments are optional. After you click OK, the Exchange System Manager creates the storage group and displays it in the console.

Creating a mailbox store
After you create a storage group, you can create mailbox stores, public folder stores, or both in the storage group. Creating a mailbox store requires a little more input than creating a storage group, but it is still easy. Here’s how:

Open the Exchange System Manager, expand the Servers branch, and expand the server on which the storage group resides. Right-click the storage group in which you want to create the mailbox store and choose New | Mailbox Store. The Exchange System Manager displays a multipage property sheet. The General page includes the following options:
  • Name: Specify the name for the mailbox store. Exchange uses the same name by default for the store file names.
  • Default public store: Specify the location for the public store file. When creating a new store, you can accept the default to create a new store or click Browse to select an existing store.
  • Offline address list: Specify the offline address list. When creating a new store, you can accept the default to create a new address list or click Browse to select an existing one.
  • Archive all messages sent or received on this store: Select this option to journal to a mailbox all messages sent and received by users with mailboxes in the store. Generally you should create a mailbox specifically for journaling messages. You can select any recipient in the directory. If you want to journal to a mailbox within the new store, leave this option unselected. Create the store, create the mailbox to use for journaling, and then open the properties for the store and select this option, specifying the desired mailbox. Note that journaling to a different store provides an additional level of redundancy—if the journal mailbox resides in a different store, you can still retain the journal messages even if the originating store is lost and unrecoverable.
  • Clients support S/MIME signatures: Select this option if you want the mailboxes in the new store to support S/MIME for digital signatures and encryption. Outlook 98 and later—as well as Outlook Express—support S/MIME.
  • Display plain-text messages in a fixed-sized font: Select this option to have Exchange use a fixed-sized font (10-point Courier) to retain formatting for diagrams, columns, and so on in plain-text messages. If you deselect this option, Exchange uses a variable-width font, which can cause formatting to be lost.

The Database page lets you configure a handful of options that specify the store file path and names, maintenance, and startup options for the database files. These options include the following:
  • Exchange database: Use this field to specify the path and file name of the rich-text portion of the store.
  • Exchange streaming database: Use this field to specify the path and file name of the streaming data portion of the store.
  • Maintenance interval: Specify the interval at which you want the store maintenance utilities to run on this store.
  • Do not mount this store at startup: Select this option if you don’t want the store to mount automatically when Exchange starts up. You can then mount the store manually. You can change this behavior by simply changing this property later for the store.
  • This database can be overwritten by a restore: Select this option if you want Exchange to allow the store files to be restored from a backup, replacing the existing store files. In general, you should leave this option unselected because restoring the store files from a backup causes all messages sent or received since the backup to be lost. If your store is so corrupted that you can’t recover it, open the properties for the store, select this option, and then perform the restore operation to replace the unrecoverable files.

You can use the Limits page to impose limits on the size of the store. You can set limits on user mailboxes and specify how long deleted items remain in the store before being purged. The options on the Limits page include the following:
  • Issue warning at (KB): Use this option to specify a size limit for user mailboxes. When the limit is reached, Exchange sends the user a warning message to delete messages.
  • Prohibit send at (KB): Specify a limit at which the user is prohibited from sending additional messages. When the mailbox reaches the specified size, Exchange sends a warning message directing the user to delete messages and prevents him from sending additional messages until the mailbox size is reduced below the specified limit.
  • Prohibit send and receive at (KB): Specify a limit for the mailbox at which the user is prohibited from receiving and sending messages. When this limit is reached, Exchange sends the user a warning message directing him to delete messages. Incoming messages are rejected and the sender receives a nondelivery receipt (NDR).
  • Warning message interval: Specify when the server should generate limit-warning messages. You should generally specify a nonpeak period because of the overhead imposed by the process, unless performance is not an issue in your situation.
  • Keep deleted items for (days): Specify the number of days that deleted items can remain in the store before being permanently deleted. You can specify a value from 0 to 24,855. A value of 0 causes items to be deleted immediately.
  • Keep deleted mailboxes for (days): Specify the number of days that deleted mailboxes will remain in the store before being permanently removed. You can specify a value from 0 to 24,855. A value of 0 causes the mailboxes to be removed immediately.
  • Do not permanently delete mailboxes and items until the store has been backed up: Select this option to have Exchange keep deleted mailboxes and items until the store has been backed up. Exchange will then process the deleted items to purge them.

The Full-Text Indexing page lets you configure full-text indexing for the store, enabling fast searches in the store. Configure the update interval and rebuild interval and use the check box to turn indexing on and off for the store.

The Details page shows the creation date and last-modified date for the store. You can also enter administrative notes in the text box to keep a running set of notes regarding changes that you or other administrators have made to the store.

Use the Policies page to view the policy objects associated with the store. You can apply policies at the server, public store, or mailbox store. The types of policies you can apply vary according to the object on which you’re applying policies. For a mailbox store, for example, you can apply General, Database, Limits, and Full-Text Indexing policies. These policies enable you to define and implement settings for archiving, message limits, and other settings discussed previously that you might otherwise set manually for the store. The advantage to using policies to apply the settings is that you can configure them once and apply them to multiple Exchange objects to simplify administration. For example, if you use the same settings for all of your mailbox stores, you can configure a mailbox store policy once and apply that policy to all stores, saving you the trouble of manually configuring settings for each one.

The Policies page doesn’t enable you to configure policies but instead simply shows which policies apply. To apply policies, you first need to configure the System Manager to display Administrative Groups. Doing so is very simple. In the System Manager, right-click the organization and choose Properties. On the General page, select the Display Administrative Groups option and then click OK. After you click OK, restart the System Manager.

Next, create the policy settings you want to apply to various stores. Create as many policy sets as you need at this point. You’ll apply them to your stores in a later step.

If you don’t currently have a System Policies container (indicated as System Policies in the Administrative Groups branch), you need to create one before you can create policies. To create and set up a System Policies container, as well as an initial set of policies, open the System Manager and expand the Administrative Groups branch. Right-click the administrative group in which you want to create the System Policies container and choose New | System Policy Container. Next, right-click the newly created System Policies container and choose New | Mailbox Store Policy.

System Manager will display a New Policy dialog box in which you select the types of policies you want to add (General, Database, Limits, and Full-Text Indexing). Select the types of policies you want to create and click OK.

On the Properties sheet, enter the name for the policy object on the General page. Click the remaining tabs and configure policy settings as desired. The number of tabs depends on the types of policies you selected previously. Click OK to create the policy object.

To apply a policy object to a store, right-click the policy object under the System Policies branch and choose Add Mailbox Store. Select the stores to which you want to apply the policy object and click OK.

Creating a public folder store
Creating a public folder store is just as easy as creating a mailbox store, but the process is somewhat different. If you haven’t created the public folder tree yet for the public folder store, that’s the first step. Then you can create the public folder store and associate it with the tree.

To create the folder tree and the store, launch the Exchange System Manager and expand the administrative group to locate the Folders branch. Right-click Folders and choose New | Public Folder Tree. On the resulting property sheet, specify the name for the new tree on the General page. Click the Details page and add administrative notes, if desired; then click OK.

After you create the folder tree, you can create public folder stores. Right-click the newly created folder tree and choose Properties; then click the Security tab and configure ACLs as desired to control access. In the System Manager, right-click the storage group in which you want to create the public folder store and choose New | Public Store. Specify a name for the store on the General page and then click Browse to specify the public folder tree to associate with the public folder store.

Configure properties for the store as needed using property sheets identical to the ones mentioned above. Finally, click OK to create the store.

If you skipped the section on creating mailbox stores, read through it now to learn about the options you can configure for public folder stores and about how to create and apply policy objects to the folder store.

Conclusion
Properly designed storage groups can increase Exchange 2000’s speed and reliability. However, to make things work right, you must do a little planning and then actually create the groups and stores. In this Daily Drill Down, I’ve shown you how to create storage groups and stores.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
0 comments

Editor's Picks