Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Exchange 2003 (SBS) space issue EDB doesn't match mailboxes. Need more space.

Status
Not open for further replies.

pjw73nh

Technical User
Aug 20, 2012
8
US
Greetings,

I have an SBS 2003 Exchange server that is using a lot of space. There are only about 18 mailboxes on this system. I am on the verge of converting them to an online Exchange service, but need a another few weeks.

My data drive (which has other apps on it as well as the Exchange databases) is very full. The RAID 5 volume is 34 gb total and has 2.6 gb left. All the other Exchange related files (programs and logs are on a different volume. Only yhte Databases are on this volume.

My issue is that the Exchange database files total about 12 gb on the drive, and yet according to ESM (mailboxes), it shows about 5gb for all users combined.

Drive

Mailboxes

What can account for the extra usage in the DB files? How can I fix this? I just need it to run for another 2-3 weeks.

I have deleted a few users, and have cleaned up LOTS of emails from several of the high-use users, but it doesn't seem to make much difference.

Thanks for any help you may be able to provide.

P...
 
Check event ID 1221 in the application log - that might report 5GB or thereabouts of free space. The Exchange databases come to 12GB and you are saying that you've got 30GB used so there's another 18GB unaccounted for...maybe look at that too?

Deleting users and cleaning up emails won't shrink the DBs, only increase the white space so depending on the 1221 event result an offline defrag might help but might not.
 
Thanks for the reply Zelendakh. Perhaps I wasn't clear in my description. Disregard my comment about the total size of the volume. I think it may be confusing you.

My concern is that if I add up the total sizes of **mailboxes as shown in the Exchange System Manager** (My second picture), the total is about 5 gb for ALL mailboxes. If I add up JUST the 4 PRIV & PUB files, (first picture) it comes to about 12 gb.

Boiled down, my question is: Why do my total mailboxes equal 5 gb, yet the 4 files show 12 gb in file manager.

To answer your question, I have thousands of 1221 entries in my application event viewer. I have enclosed a sample of just yesterdays events. It appears that there are about 5-6 per day. It looks like the online defrag starts at 1:00 AM, then the next one (an hour or so later) finds a large amount of space, then 3 smaller ones. Nine mb or so.

See all the pics related to this post here:
All Pics

Can you explain white space to me? Is it for example, when a user's email box is deleted, the actual size of the EDB is not shrunk, but that user's space becomes available for use by Exchange?

If in fact this is the case, (that it turns out I have a ton of white space) what would it take to shrink the actual file size of the EDB and have that space usable for other applications. I only need the space for a few weeks until I migrate all the users to the online service.

Thanks for the help and assistance. I really appreciate it.

P....
 
Secondary question:

I don't have enough free space on my volume to do an offline defrag (MS says I need 110% of the DB size).

I do have another volume (non RAID) with about 8 gb free.

Can I do this:

1. Make a new Mailbox store on this new volume.
2. Move the existing users over to it. I'd probably do this with ESM "Move mailbox"
3. Once all the users have been moved over, delete the "old" mailbox store. freeing up 12 gb of space on my old volume.

Am I correct in assuming that this newly created EDB would not have any white space and would also start out "defragged"? If so, this may solve my problem until I get my users moved...

Are there any pit falls to this? Are there any other changes I need to make? Do I need to change any pointers or locations? Do I need to flag the new MB store as some kind of default? Any other steps?

Thanks.

P....
 
You can't make another mailbox store on the other disk unless you have Exchange 2003 Enterprise edition.

The only way you could do an offline defrag is if you had the disk space, and you could technically use an external drive to do it. If you can avoid doing a defrag at all, I would try to do that.

The important thing to keep in mind is that when you begin migrating mail to the cloud, it's going to cause a lot of log file creation on your server, equivalent to the amount of data being moved. Because you are so tight on space, I would enable circular logging on your mailbox database before moving mailboxes to the cloud, just to make sure that you don't run out of disk space in the middle of the process.

Some key concepts related to database size:

The database will NEVER shrink itself.

Free space is kept within the database file, and the database will NEVER grow unless that free space (white space) is used up.

If the 1221 event says that you have quite a bit of free space, then you don't have anything to worry about: your database file will not get larger in the next few weeks.

If it were the case that you are unable to find a 1221 event, or the event does NOT say that you have a lot of whitespace, then you'd have another issue on your hands.

The probable root cause for that discrepancy would be that the nightly online defrag and mailbox management process was not completing. Normally it runs from something like 1am to 5am, but if it doesn't complete, it just starts over again the next night. Chances are, in that situation, that it's never actually finishing.

How would this affect what you'd be seeing? It's this mailbox management process that actually determines what can be deleted from the database, and is what expires old data. Once it expires the data that has passed the retention window, that free space is reflected in the 1221 event that Zelandakh referred to. To resolve that issue, you'd want to change the mailbox management schedule to run all weekend instead of in just five-hour intervals each night. That would get the whitespace reporting working properly.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 
Dave,

Thanks for the reply. Great help and great explanation.

When you say migrating to the cloud is going to create log files, I have a couple of questions on this.

1. My Exchange logs are on another volume (the one that has 8 gb available). Does that make a difference.

2. I was planning on either using Ex-Merge (or where I only have 18 mailboxes) perhaps exporting each one to a local PST and then importing them on each users account on the cloud.

Slightly different topic:

All of the Exchange users (18) on this domain have dedicated workstations. They only use email. Outlook. Not calendar, not tasks, not public folders No other exchange features (except GAL). Only email. Seeing as how I am only going to need this for a few more weeks, How do you (and the forum) feel about:

Creating a pop3 connector to our ISP from each users outlook profile, export all info from their Exchange to a local PST file, delete their exchange connector, then operating them as a pop3 for the next few weeks.

I know I wouldn't have an email backup but I can deal with that offline for a few weeks for the 3 heavy users.

Wouldn't this allow me to disable exchange on the server and remove the large EDBs thus giving me some breathing room?

Thanks.

P...
 
On your first questions: 1) Yes, it means that your logs are not part of the space equation. 2) Export via ExMerge or some other similar means would not generate excessive logs.

I don't really like your idea, since it seems like it will take a lot of work (reconfiguring all clients) and leave you vulnerable for a while.

What would I do? I'd get started setting up the cloud immediately. I would use MigrationWiz.com (using a premium license per user would cost around $210 total) to connect the mailboxes in your organization up to the freshly provisioned mailboxes in the cloud and start syncing them. Once they are synced, just repoint all the clients to the cloud mailboxes that have been prepopulated and trigger one last sync. That's much easier than juggling .pst files and interim pop configurations, in my opinion. I've used MigrationWiz for 4-5 different projects and it's been great, especially since you know exactly where you are in the process and you can log on to the cloud server via web access and verify that everything looks good: same contacts, same subfolders, etc.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top