Out of Control Mailboxes 4

[myerscg1]

Hi Everyone,

When I upgraded from Exchange 5.5 to 2003 2 years ago, I went from a mailbox limit of 100Mb to no limit at all. Consequently, I now have 30 users over 1 gig, 1 user is at 10 gigs! My priv1.edb file went from 15gigs to 42gigs. Backups on exchange are taking forever.

What can I do to archive some of this data off of my exchange server and still give the users the C.Y.A. ability they require?

If I do the archive wizard in Outlook 2003, that will just move the data into a PST file on the user's workstation. That gives me zero recoverability if the workstation dies - I am not going to run backups on 100 machines!

I'd really appreciate any ideas some of you may already implementing.

Thanks

 

[WhoKilledKenny]

We have the user archive the .pst file to their home directory on a file server. That way the file server does the backup. Somethings to note:
Your clients can connect to the .pst file on their network share, but Microsoft doesn't support this due to file being at risk of corruption when connecting over the LAN. Best to have a local copy as well for connecting outlook and the .pst file.

.pst files should not become larger than 1.8 GB (I'm a little foggy on the actual size) or they can become corrupted. Best to train the user how to set up a new archive when the file reaches that size. Use a monthly or quarterly archiving standard (depending on the users usage).

Jesse Hamrick

http://www.powershellpro.com

 

[58sniper]

Go to a third party archiving solution such as Enterprise Vault. That will store the older mail in the vault, and replace the message in the mailbox with a stub. Within a couple of days, your mailboxes are down to a more manageable size.

Then enable limits again. (I'd actually do that now)

Pat Richard
Microsoft Exchange MVP

 

[mofusjtf]

I would archive old mail and then re-enable quota's for your users. Also force your users to empty their deleted items regularly. If a message has been deleted is it no longer needed. At least that is how I see it. If the users thinks the message is worth keeping they shouldn't put it in the deleted items folder.

Initially you will have some resistance but your users will learn. It might not be a bad idea to get the Execs on board. All you have to do is explain the cost of moving to Exchange Enterprise edition. I'm pretty sure they'll backup you up when they see that cost; especially if you indicate 2k7 which will require all new 64 bit hardware.

And PST files in 2003 and 2007 can be up to 20 GB. 2002 and earlier have the 2 GB limitation.

 

[xmsre]

Without limits, you can't effectively size your server. If you do not impose limts, as you have discoved, you'll eventually exceed whatever capacity you have.

PSTs are a bad soloution for oh so many reason. First, you're not solving anything, just creating more problems. If there is a business justification to keep the mail, put the storage $$$ into exchange and keep it on the exchange server. This keeps the mail in managed storage where it's backed up and cared for and reasonably assumed to be available.

You may come to the misguided belief that putting psts on a file server is a viable solution; it's not. Yeah, you may back up a file server, but it's not same.

1. PSTs are only supported when accessed locally. Data loss or accessability problems when it's on a file server, and you're on your own.

2. The PST file format stores attributes like the message body twice, meaning it consumes much more space than if you put it on exchange server.

3. Don't forget that there is no SIS if you put in a PST.

4. PSTs are fragile, and repair options are limited.

You actually end up buying and backing up more storage and getting far less reliability in an unsupported configuration; PSTs on file shares don't add up.

 

[aco636]

Hi All

Just to add my bit, I use a 3rd party solution that archives every mail in and out and also comes with tools to import pst in to a SQL database. Store the database anywhere you like.

With the solution I use, you can choose to use the desktop edition or full blown MS SQL so you can get clever with replication, etc.

Have a look at

http://www.gfi.com/mailarchiver/

You will have to spend some money!
REgards ACO

 

[xmsre]

Many of the archiving solutions out there use SQL or Oracle to store the index entries and put the individual items in the filesystem/compressed archive/proprietary archive/database. If I'm not mistaken, GFI can use either SQL or the filesystem. It's an important distinction if you don't already have the full blown SQL in your environment.

FYI: SQL Express 2005 has a max database size of 4GB. That might be sufficient for a nice demo, but wouldn't hold a heck of a lot of mail.

There's something to be said for taking the mail out of the PST and putting it in a compressed NTFS filesystem. Add a SQL index to the front of that and ... this is the direction many an archiving solution takes. Replace the compressed NTFS with a proprietary "vault" and that looks a heck of a lot like EV.

 

[58sniper]

Many of the archiving solutions out there use SQL or Oracle to store the index entries and put the individual items in the filesystem/compressed archive/proprietary archive/database. If I'm not mistaken, GFI can use either SQL or the filesystem. It's an important distinction if you don't already have the full blown SQL in your environment.

Also, solutions like Symantec's Enterprise Vault store the indexes in SQL, but the data in flat files. EV also stores an HTML version of the message for backwards compatibility.

It's been about a year since I last deployed the GFI solution, but I think a key difference between that and EV is that EV leaves a stub in the mailbox, and Mail Archiver doesn't. From a user standpoint, it's a little nicer to have one interface to find your email, IMNSHO.

Pat Richard
Microsoft Exchange MVP

 

[xmsre]

We use EV in my organization. It has it's good points, and bad ones. From a cost perspective, those solutions that don't require SQL or Oracle tend to be less expensive. On the other hand, at least keeping the index in a database makes retrieval a lot quicker. Then there's your point to consider Pat; to what degree does that product integrate with Outlook and/or OWA? I think the best advice I can give is to research the field ald evaluate multiple vendors' products before making a decision.

 

[rliebsch]

I feel for you. I have a smallish org. There are currently about 70 of us. Our Mailstore backup is just south of 200GB. It is backed up daily in about 4.5 hours. I still do a weekly bricklevel, which consumes the entire weekend.

One thing you might be able to do is to remove attachments from messages. I assume you back up your users computers. I would also assume the attachments have been saved to Documents or some such place.

Killing attachments will definitely free up space. Another thing is people forget to empty the deleted items.


Robert Liebsch
Systems Psychologist,
Network Sociologist,
Security Pathologist,
User Therapist.

 

[xmsre]

200GB backups taking 4 and a half hours ... ouch. Go get a Storevault and leverage the snapshots. Buy the SMBR option and you won't need the BLBs.

 

[9163]

hie

im also using exchange server 2003 and to deal with the problems of mailboxes over the limit, we have enforced limits on mailboxes such that when the limit is reached the user can no longer send or receive mail unless they empty their mailbox to the pst file. furthermore , we created .pst files on the user's PCs so that all old mail sits on their machines thus freeing space on the server.

 

[xmsre]

9163,

The achilles heel of that route is that you're taking mail out of managed storage and putting it into unmanaged storage. If the mail is business critical, then it needs to be in managed storage; if it's not then keeping it is a liability. You may want to discuss email retention with your legal department and see what they have to say about it. Most organizations have an email retention policy that balances business needs with the liability of keeping the mail around. To the managed/unmanaged storage point; if you ever get hit with a discovery order, you may not be able to produce if the mail is in unmanaged storage. This would mean losing the suit simply because you could not produce. If it's worth keeping, keep it in managed storage.

 

[9163]

so what do you suggest guys, because we have more than 400 users on a server based network and keeping their mailboxes on the server will send the sever crashing

 

[xmsre]

1. Work with management/the business units/your legal department to determine appropriate limits based on business needs. Enforce those limits.

2. If you do 1 above, then you already have the justification for the funding for any software/hardware required to meet the business needs.

3. Provision additional storage and/or servers if necessary to meet the business need.

Without limits you cannot effectively manage the messaging environment. Even if you do not impose limits, the de facto limit is the hardware platform; you don't want to hit that limit. The messaging environment is there to support the business. The trap that many folks fall into is that they don't tie limits to the business objectives. If there is a business need to keep the mail, then you need to provide managed storage for it; on exchange, via an archiving tool, etc. If there is no business justification for keeping the mail, don't keep it.