Several Questions - Please help.

[ereid99]

At work we currently have one Exchange 2000 Enterprise server running. This server is an HP ML530 and has five 36GB drives.

The logical drives are as follows:
C: 12GB - System Drive
D: 30GB - Transaction Logs
E: 60GB - Database files

We are about to run out of space on drive E:. Currently the database files take up 52GB of the 60GB available. We also currently only have one storage group. So this brings me to the following questions. Any assistance would be great.

1. If we create new Storage Groups and move mailboxes to these does it copy only what is in the mailboxes? In a sense does it defrag the space during the move?

2. Can you apply different Mailbox Manager settings to each Storage Group?

3. Can the *.edb and *stm files for each Storage Group be on one logical drive or would it be better to have them on separate logical drives? Which would be the best performance?

4. Can the transaction log files for each Storage Group be on one logical drive or would it be better to have them on separate logical drives? Again what would be the best performance?

5. How would separate Storage Groups affect backups and restores? We only use NTBackup and don't have a need for brick level backups. We only need backups for a complete disaster recovery. We aren't restoring if someone deletes and e-mail that they happened to need.

6. Can you safely delete the First Storage Group if everything has been moved to new Storage Groups?

Thanks again for the help.

 

[xmsre]

1. It removes the mailbox from the source, but you have to do an offline defrag to reclaim the space.
2. Yes
3. Depends on user usage patterns. Many times you'll get better performance by placing them on seperate drives, and tuning the IO for the data type.
4. Better performance on seperate drives. If you put multiple log sets on the same drive, the IO pattern changes from mostly sequential to random. This negates the performance increase you get wrom writeback cache.
5. Minimal
6. Why would you want to? Rename it.

 

[ereid99]

xmsre, thanks for the responce. I have one more follow up question that pertains to moving the mailboxes to a new storage group and doing the offline defrag.

Currently we have one storage group. This could be easily split into three seperate storage groups (we have three departments so that would be the split). If we choose to do this should the offline defrag go faster for each group than it would for the single storage group now?

I know there isn't any way to really know without doing it, but it seems to me that it would faster to defrag the three storage groups seperately than as one big one.

Thanks again for the help.

 

[xmsre]

You can run the offline defrag against a store. A storage group can contain up to 5 stores, and you can have up to 4 storage groups [assumes enterprise edition].

When you move a mailbox, and the old one is deleted, the pages are first tombstoned, then evenually are freed. These freed pages, or whitespace, is defragmented by an online defrag during brackground maintenance. The only way to actually shrink the physical size of a database is by an offline defrag, which removes all the whitespace. Clearly, pages in the ese database are allocated and freed all the time. The only time that makes sense to do an offline defrag is after you remove a large amount of mail. You might want to shorten the wait by reducing your deleted item and mailbox retention, and waiting for an online defrag to complete before doing the offline defrag.

If you are moving all the mailboxes boxes off a store and are impatient, you may want to try another approach. After moving all the mailboxes off the store, simply dismount the store and delete the .edb and .stm files for the store. When you mount the store, click through the warning about a missing database, and a new blank one is automagically created. I actually prefer this method, especially on a damaged, repaired, or otherwise suspect database. Often time this is the fastest route rather that waiting hours or days for tombstones to expire and online defrags to complete before finally spending another full day doing the offline defrag. Make sure you do a backup before you start; you always want a recovery plan, especially when working with damaged stores. This article gives some detail for the process in 5.5. I know there's an equivalent E2K article, but I don't recall the KB number. The subject is actually covered in a fair amount of depth in most disaster recovery white papers. I guess this all goes to my answer to number six; why remove the first storage group? You can create all new stores and rename it.

I've done a few delegated administration designs in environments where delegation by store was desired. Creating a mailbox requires a minimum of "Exchange View Only Admin" permission. By default, the lowest level that you can delegate view only admin is at the administrative group. In some mid-sized companies, those that are consolidating as well as migrating to E2K3, it often does not make sense to dedicate an entire serve to a division of 500 or 600 users when the current hardware environment can easily support 5000+ users on a node; given adequate IO. I see a lot of consolidation efforts end up with only two to four servers with SAN attached storage. Anyway, to delegate at a level lower than the administrative group, you have to set the permissions manually. The means modifying the default pernissions. It it, howerver, very possible and probably worth pursuing if you want to delegate administration to the department level. The alternative is getting stuck with the task of creating all the mailboxes. The alternative is chaos if you give three different departments permissions at the administrative group level.

XMSRE