Exchange, Stubbing, and Database Space Reclamation

This is a tad annoying. It's nice to have an explanation of it all but I had thought that the update would be more aggressive as morser points out.

Like him for my environment there wouldn't be a problem with a 'traditional' Online Maintenance run behind the scenes.

We also stub everything after 30 days, not so much for disk space as for backup since we are rather constrained in that area. As a finance company we have to journal everything anyway, goes to an EMC Centera. Therefore for us it doesn't really matter where the majority of the message lives, if it is in the Centera all we need is the stub pointer to be left in Exchange, hopefully not taking up too much space.

We use a combination of SAN and local storage between physical and virtual servers (one physical server has local storage as a security measure - we once had an EMC engineer switch off our SAN by mistake), remember that a lot of people use Exchange purely as a VM nowadays and are thus forced to use SAN storage, or perhaps high capacity iSCSI.

For reference an HP midline 1TB SATA drive for a physical server will come out at about $270 with a 1 year warranty. So definitely lots cheaper than SAN but not usable in all circumstances, especially if you want to use 1U servers and have large DB's.

Up to now I've been doing the old disk expansion, new database creation, mailbox move dance and was hoping that when I upgraded to SP2 I'd be able to do one last mailbox move for everyone and then be in a more or less steady state.

Usually recover at least 50% of the storage used by the old database.

Sounds like I'm still going to be doing the dance, just less often.

Which isn't helpful since as I said I'm backup constrained and have to back up the old database, the new database AND all the log files while I'm doing the moves.

If you search in the Exchange forums you'll probably see my previous complaints on this issue. :-)

Neill