PST storage 1

[Azza76]

Hello,

Just a quick question to see what other Exchange admins do.

We currently run Exchange Standard with a Store size of around 60Gb. Some of our users (due to no fault of there own - there just huge email users) have mailboxes upto 7Gb. To try manage this I asked users to archive off emails older than a year to a .pst file. These .pst are stored on shared network drives where they are backup up nightly.

However - Microsoft recommend .pst files are not stored on network shares. So where do other Exchnage admins sotre them. If we store them locally on individual machines they won't be backed up.

Any suggestions?

 

[MarkArnold]

If they do have large mailboxes then the best service you can offer them is to let management spring for Enterprise Edition.
If that's not an option then you would want to look at ways to manage those PST files. Putting them on a network share and backing them up is a pretty bad idea. Every time they are opened the archive flag changes and the whole thing has to be backed up..... unless you're using a decent SAN as storage that will just backup the changed disk blocks.
If that is the case then storing them on the SAN storage isn't the end of the world as you can recover from the inevitable corruptions pretty easily.

And of course, remember that you've still got another 15GB to go before it all ends in tears.

 

[58sniper]

These .pst are stored on shared network drives where they are backup up nightly.

That's also totally unsupported by Microsoft. You're asking for trouble if you put it there. And what do you gain? Is drive space on your file server cheaper than drive space on your Exchange server?

I don't allow .pst files. It's that simple. You can't remotely compact them. You can't index them. Legal discover is more difficult. Lots of reasons not to use them.

Pat Richard
Microsoft Exchange MVP

 

[Zelandakh]

Enterprise.
Disk drives.
Public folders - there's another 75GB to play with if you want.
PST. Bad. Bad, bad, bad, bad, bad...

 

[Azza76]

Thanks - I get the picture! Hahaha

So upgrading to Enterprise Edition and installing more disks as neccesary seems to be the way to go.

Surely you guys don't let the mailboxes grow and grow without any kind of limit though? Do you never archive off emails? I would have though someone with a 10Gb mailbox would be a bad thing?

 

[markdmac]

I'll stray from the party line here and offer the following.

First, I think your direction to the users was good in having them archive mail out to the PST files. Any mailbox that grows beyond 2GB is just asking for trouble in my opinion.

What I would have further suggested is that you had users archive by year. Hopefully no user has more than 2GB per year. Rather than having the users do the archiving, I would have done it for them using ExMerge. ExMerge has options that let you specify the date range of the data to be archived out. Doing it this way you can ensure it gets done and it is all of 3 minutes work for you. I keep stressing that 2GB limit because ExMerge won't support working with a PST larger than that size. For this reason I warn customers not to let their mailboxes get to large in case we ever had an issue where we absolutely needed to ExMerge out their data.

Next thing I would do is download a copy of the PST Backup Utility from Microsoft, it is free and overcomes the network access issue. You have the users access the PST files locally on their systems and use the backup utility to copy any changes it may have up to the server for your normal scheduled backup. the utility copies the file when Outlook closes per the schedule you set.

You can get the tool for free at:

http://office.microsoft.com/search/...D=X2aCt3Shx0&respos=2&rt=2&pid=CD010798351033

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[paulha]

A star for the PST backup utility link, could be very useful for clients who do have PST's, thanks.

 

[58sniper]

There are other issues to consider, including the fact that messages take more space in .pst than in a mailbox. Also, messages in .pst lose Single Instance Store.

A better solution would be to implement a mailbox archiving solution, and then limit the size of the mailboxes to something manageable, like a couple hundred MB.

Pat Richard
Microsoft Exchange MVP

 

[paulha]

Good points Pat, far easier to manage too, if all mail is held on the server.

 

[xmsre]

First, the official line from MS:

http://support.microsoft.com/kb/297019

http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx

1. In really small (less than 50 user) environments you could probably get away with it but,

a. the solution doesn't scale
b. it's unsupported, you're on your own.

the local pst and using the pstbackup utility as Mark mentions is a novel way to get around some of the support limitations (at least you're not accessing the pst over lan or wan) but,

1. It's still very fragile and the best support has to offer is "run the outlook inbox repair tool"

2. It still requires more space and you still lose SIS.

3. The thousands of other reasons for not using PSTs in the first place still apply.

As Pat mentions, there are a range of archiving tools out there, from GFT to Symantec and a dozen other vendors in between, in all sorts of price ranges. It would be worth examining this option as well.


To Mark's comment on mailbox size: It's not really the size per se that matters, it's the number of items per folder. I could have a 5GB mailbox with 500 10mb items in the inbox and it will perform better than a 100mb mailbox with 10,000 10K items in the inbox. Tke key is to keep the number of items in any folder below 5000 ( I'd say substantially below, but 5000 is the number MS puts out). The reason folders with a large number of items perform poorly is simply this; as the size of 11 default views for a given folder increases, the chance that the views will be in cache decreases. As number of items increases you eventually reach a point where the 11 views must be created on the fly each time you access the folder.

 

[markdmac]

xmsre, for my recommendation on the 2GB limit, I was actually referring to the fact that ExMerge does not support exporting an entire mailbox to a PST file if it will Exceed 2GB.

To both you and Pat, I agree with what you are recommending, but don't like the fact that extra cost is involved due to the third party tools. While not ideal, my solution uses all MS technologies and requires no extra expenditure.



I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[xmsre]

The version of the MST provider as embodied in MSPST.DLL that ships with Exchange 2003 does not support Unicode PSTs. The version of MSPST.DLL that ships with Outlook 2003 adds new entry points to support the new format. Even if you mucked with mapisvc.inf and managed to swap the the two, Exmerge would still make the downlevel ANSI calls. Without a rewrite, we're stuck with ANSI PSTs if we're using Exmerge.

It's interesting that some third party tools like ontrack's powercontrols, require you to install outlook 2003 on the migration host. This allows them to make the new unicode calls and avoid the 2GB limit. Short of using such third party tools instead of Exmerge, you could break the job up into smaller ones. The current recommended strategy to deal with the exmerge 2gb pst limit is to break it up based on date ranges and export to multiple pst files.

In the really small (tiny) environments where you'd be tempted to put the pst files on the file server regardless, the solution you offer with the pstbackup tool is certainly preferrable. Using this solution you're backing the local pst up to a network share and not connecting outlook to a pst on a network share. This elimininates the conflicts with 297019 and puts you back on a supported footing.

The problem is that the solution doesn't address any of the shortcomings of the pst format in and of itself. There's too much manual intervention and it doesn't scale well. As the organization grows, it's time to start considering archiving options. These options exist in practically all price ranges. On the lower end are those that use a compressed ntfs volume as the target, and on the higher end are those that use a SQL or Oracle database. Some products, such as the GFI one, can do either.

 

[markdmac]

A very fair assessment xmsre. Depending on the size of the organization will certainly determine how much scaling is needed.

These days I mostly deal with small business since my company specializes in that market.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[xmsre]

I guess I'm at the other end of the spectrum. I mostly deal with large enterprises. My current project is 120,000 seats.