Real Life Exchange 2003 anomaly

gorebrush

Well.

I'm a bit confused.

If I go into Exchange System Manager, **** out a list of the mailboxes in the organisation, stick it in an Excel spreadsheet, it reveals the total usage of these is nearly 73GB (Yes, I have a problem)

However, when you add up the total size of:

.edb
.log
.stm

etc.

Total size is 58GB. I did a full backup of Exchange to disk for copy purposes the other day, and that came back with using 62,000,000,000 (so around 58GB)

What's up with Exchange System Manager, does it miscount some items perhaps?

Help, because I dont know whether to panick (i.e. 73GB) or relax (57GB)

Any ideas?

macdude

Are you counting your public folders as well and all of the log files?

gorebrush

Should have mentioned that our Public Folders are basically empty.

Nothing in them (except the usual free/busy info)

blargoe

Maybe for the data stores, the smaller size is due to single instance storage for attachments, but for the individual mailboxes it counts every instance?

royal

blargoe wrote:

Maybe for the data stores, the smaller size is due to single instance storage for attachments, but for the individual mailboxes it counts every instance?

That would be my guess. SIS reduces edb size but still increases quota limit for mailboxes.

gorebrush

So, my ultimate question would be.

How have I lost 20GB in *actual* DB size.

And more to the point, which one "counts" towards the overall 75GB Mailbox Store size limit?

Logically by SIS - it would mean only one copy physically exists, therefore the 58GB figure is correct, and I don't have to fear an impending total and complete organisation wide failure of e-mail...

I'd never come across SIS before now, and I've done the MCP for 70-284 (albeit 3 years ago) and 70-236...

Have I been asleep?

gorebrush

I missed this SIS - Feel like an idiot now. LOL.

Still, means I can relax now.

HeroPsycho

The 75GB DB limit, only the file size of the db counts. For mailbox quotas, as already mentioned, SIS is not factored in.

gorebrush

Ha, so there's me telling everyone to reduce their mailboxes when i'm quite, quite safe.

Rawkin'

Still, there is no need for users to store over 2.5GB in their mailboxes (Limits were never introduced before I came here - it's my business now though )

HeroPsycho

gorebrush wrote:

Ha, so there's me telling everyone to reduce their mailboxes when i'm quite, quite safe.

Rawkin'

Still, there is no need for users to store over 2.5GB in their mailboxes (Limits were never introduced before I came here - it's my business now though )

Remember, there is still a need. Just because the technical limits are high, it doesn't mean you should go that high. You increase the time for db maintenance options, increase backup and restore windows which can blow your SLA's out of the water, increase the costs associated with running your mail environment, etc.

Also, don't forget large mailboxes hurt performance for your Exchange server. Any non-cached mode access to Exchange (OWA, delegate access, users not cached mode enabled) significantly increased the load on the Exchange server with large mailboxes that have over 1000 items in their critical path folders (Inbox, Sent Items, Calendar, Deleted Items). Mailboxes with large amounts of data tend to also have large amounts of items in their critical path folders, too.

Claymoore

Even after users clean up their mailboxes, the database will still be 58 GB until you use eseutil to defrag and compact the database:
http://technet.microsoft.com/en-us/library/bb123761(EXCHG.65).aspx
The message store will have to be taken offline and you will need free space on the disk at least 110% the size of the database.

I don't know what version of Exchange you are running, but have you considered splitting up your users into separate storage groups and message stores so you don't have one huge DB? 4 message stores of 15 GB each are easier to maintain than 1 60 GB db.

royal

Claymoore wrote:

the database will still be 58 GB until you use eseutil to defrag and compact the database:

Or the method I prefer since eseutil can take anywhere from 1 hour per 1-5GB. This method is to create a new DB, move mailboxes, delete old db, create the db again with the same name, and optionally move users back. Requires little to no downtime and gets the job done.

HeroPsycho

royal wrote:

Claymoore wrote:

the database will still be 58 GB until you use eseutil to defrag and compact the database:

Or the method I prefer since eseutil can take anywhere from 1 hour per 1-5GB. This method is to create a new DB, move mailboxes, delete old db, create the db again with the same name, and optionally move users back. Requires little to no downtime and gets the job done.

Just remember this loses single instance store on the data already in the database.

royal

Yep, that's always the case when you move users. Besides, SIS will be maintained on the new database. So you're not really losing any SIS after users are moved to the new DB. Only temporarily when users are split.