Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Mailbox databse has been grwoing very quickly
Happy New Year Experts,
Need hand with my mailbox database. Over the past few days, this database has grown 20 GB. It did the same Christmas Eve. I'm sure there are ton of people sending holiday greetings out,but for a 50 person company this seems excessive. I'm not seeing any errors in my logs. Nothing obvious, but where do I start looking? How can I tell if there is a bot somewhere sending mail? What logs should I be looking in. i know I've done a lot with Exchange but I've never been in this boat. We're running Exchange 2010 SP2 RU3.
Slainte
Need hand with my mailbox database. Over the past few days, this database has grown 20 GB. It did the same Christmas Eve. I'm sure there are ton of people sending holiday greetings out,but for a 50 person company this seems excessive. I'm not seeing any errors in my logs. Nothing obvious, but where do I start looking? How can I tell if there is a bot somewhere sending mail? What logs should I be looking in. i know I've done a lot with Exchange but I've never been in this boat. We're running Exchange 2010 SP2 RU3.
Slainte
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I would start looking at mailbox file sizes. People aren't just sending mail, they're sending attachments of unusual size (AOUS's). Inconceivable!
If someone's sending a photo album or music, that could be it.
If someone's sending a photo album or music, that could be it.
Awesome. I know how to check mailbox sizes but how can I check and see whether or not they're sending huge attachments?
You could also log into the Exhcnage management console, Toolbox, Message tracker and check some users to see if someing is sending or receiving a ton of mail based on specific critera you enter.
using the script here http://gallery.technet.microsoft.com/scriptcenter/bb94b422-eb9e-4c53-a454-f7da6ddfb5d6
you can parse all the message tracking logs for a period and check who has sent how many emails and what size they were that should help you track down if there are paritucalr users sending large emails
you can parse all the message tracking logs for a period and check who has sent how many emails and what size they were that should help you track down if there are paritucalr users sending large emails
NVM got it to work, not seeing anything out of the ordinary. My largest mailbox is 1GB, so I'm thinking this database may just be swollen and needs to either be defragged or rebuilt. Am I on the right track here?
Can you upload a working copy of that script? I'd like to test it myself. It lookslike a great idea.
There is no way to reclaim whitespace in the database.In order to get the freespace back, yYou will need to create a second mailbox database and perform a mailbox move then delete the old db.
In Exchange 2003, we ran on off-line defrag to reclain free space. I think you run the same process with 2010.
taken from:
http://blogs.technet.com/b/exchange/archive/2012/01/30/3470667.aspx
How can I reclaim the whitespace?
Naturally, after seeing the available whitespace in the database, the question that always ensues is – how can I reclaim the whitespace?
Many assume the answer is to perform an offline defragmentation of the database using ESEUTIL. However, that's not our recommendation. When you perform an offline defragmentation you create an entirely brand new database and the operations performed to create this new database are not logged in transaction logs. The new database also has a new database signature, which means that you invalidate the database copies associated with this database.
In the event that you do encounter a database that has significant whitespace and you don't expect that normal operations will reclaim it, our recommendation is:
Create a new database and associated database copies.
Move all mailboxes to the new database.
Delete the original database and its associated database copies.
http://blogs.technet.com/b/exchange/archive/2012/01/30/3470667.aspx
How can I reclaim the whitespace?
Naturally, after seeing the available whitespace in the database, the question that always ensues is – how can I reclaim the whitespace?
Many assume the answer is to perform an offline defragmentation of the database using ESEUTIL. However, that's not our recommendation. When you perform an offline defragmentation you create an entirely brand new database and the operations performed to create this new database are not logged in transaction logs. The new database also has a new database signature, which means that you invalidate the database copies associated with this database.
In the event that you do encounter a database that has significant whitespace and you don't expect that normal operations will reclaim it, our recommendation is:
Create a new database and associated database copies.
Move all mailboxes to the new database.
Delete the original database and its associated database copies.
is it actually the database or the logs that are filling up?
have backups run recently and succesfully
also check these two settings
Get-MailboxDatabase dbname | fl recoverable*
Get-MailboxDatabase dbname| fl *retention*
have backups run recently and succesfully
also check these two settings
Get-MailboxDatabase dbname | fl recoverable*
Get-MailboxDatabase dbname| fl *retention*
just double checking you got the script running ok - i had a few issues with UK date format let me know and i can get the working copy i have uploaded
It's the databases. We have circular logging enabled (not my cal, my superiors, so I can't change that) the retention and recoverable settings are default
i know you are on a later version but this might be worth consudering
http://support.microsoft.com/kb/2621266
http://support.microsoft.com/kb/2621266
Premium Content
You need an Expert Office subscription to comment.Start Free Trial