[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 407
  • Last Modified:

exchange 2007 run out of disk space where mailboxes are held

Hi,

Exchange 2007 on windows server 2008 in a clustered environment.

Due to a new backup solution in place that we didnt notice wasnt pruning the transaction logs my drive that holds the mailboxes has run out of space.

It is a clustered exchange 2007 environment.

I have 7 storage groups and none are bigger than 50gb the smallest being 7gb...

I was thinking if I could just bring a few of the storage groups online then i could move all the mailboxes out of one storage group into another thus removing the white space in the storage group... as a move takes this out?

Unfortunately due to not having any space the storage groups are all offline in failover cluster manager and exchange management console.

Could I temporarily move the EDB file of one of my storage groups, manually, to a network drive, keeping that storage group offline the whole time, bring two other ones up and consolidate them into 1 storage group? in essence removing the whitespace and freeing up enough space.. then manually put the other EDB file back into its folder it was in and bringing that online again... without damaging the storage group?

Or can I run eseutil /d e:\mailboxes\export\export.edb /t m:\mailboxbackup\export.edb

then remove the original file and replace it with the defragmented one? If so how does this work with exchange in a clustered environment?

Thanks

Antony
0
gardmanIT
Asked:
gardmanIT
1 Solution
 
KorbusCommented:
I would recommend attaching a USB hard drive temporarily,  You can then use that space to run ESEUTIL with the /D option to defrag the files and remove the whitespace.

http://technet.microsoft.com/en-us/library/aa998863(v=exchg.80).aspx


That being said,  I have NOT worked with exchange clusters, so you may want to get another expert's opinion too.
0
 
N-WCommented:
Performing an offline defrag on an Exchange cluster will cause quite a bit of downtime and reseed time.

The best method would be to create an additional database on temporary storage (i.e. external storage drive) and then move user's mailboxes to the new database. When all users are moved to the new database, you can delete the old database and move the new/smaller database back to the permanent storage.

With this method, there should only be a very small amount of downtime for the users.
0
 
Simon Butler (Sembee)ConsultantCommented:
If you have run out of space, the easiest option is to simply compress the logs using Windows. DO NOT compress anything timed in the last hour or anything that isn't a log file. That also means do NOT compress the entire directory, or drive. That will give you a lot of space very quickly, which will allow the databases to mount.
Then do a backup to flush the logs.

Running any kind of repair tool on a clustered database is a very bad idea, it will break the cluster.

Simon.
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 
gardmanITAuthor Commented:
Thanks for the info..

To temporarily help the situation what I have done is ran the following command

Set-Mailboxdatabasre IT -IndexEnbaled $false

Then moved the folder CatalogData to a spare drive..

This has temporarily given me a good enough amount of space that should buy me enough time to run an incremental backup to purge the transaction logs...

The copy status has failed on the cluster storage group copy.. but I can just re start that once I successfully get a transaction log purge... I think!
0
 
gardmanITAuthor Commented:
I ran an incremental backup from backup exec 2012.. this didnt actually clear the logs.. frustratingly.

However as I stated earlier CCR wasnt active due to space issues.

so I cleared out the catalogData folder on the passive side of the cluster (shutdown the exchange indexing service first). Then I right clicked on the storage groups in exchange management console and resumed CCR which caused it to come to life and for the transactions logs to purge themselves.

I found a document that stated transaction logs will not clear down if CCR is not working for whatever reason. You must fix this first before the logs will clear down.
0
 
gardmanITAuthor Commented:
My solution worked I did not try the others
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now