[ExchangeList] Re: Storage Philosophy (was: Re: PST size)

  • From: "Jason Sherry" <Jason.Sherry@xxxxxxxxxxxxxxxxxx>
  • To: <exchangelist@xxxxxxxxxxxxx>
  • Date: Thu, 7 Sep 2006 11:11:12 -0400

All of Rick's information below if good.  In addition to it I would
highly recommend going with an e-mail archiving solution.  


With such a solution you can give users a nearly unlimited mailbox size
and have the archiving solution store older e-mail, large e-mails,
attachments, etc outside of Exchange and the users can still get access
to them.  Some solution have great off-line support that even allows
users to get access to archive messages and attachments when they are
disconnected from the corporate network.


The important things are to #1 keep your Exchange server manageable, #2
meet any legal\regulatory compliance requirements you have, #3 not piss
your users off will small mailboxes, #4 get rid of all PSTs.  An
archiving solution get help you do all four.


In the May edition of Windows IT Pro magazine I reviewed 6 different
(http://www.windowsitpro.com/Article/ArticleID/49712/49712.html).  Quest
Archive Manager has added off-line and better PST support since I
reviewed their product.  They also had the best looking UI and with the
addition of off-line support would have given them the highest rating in
the review.  I found Symantec's Enterprise vault to be the best at the
time of the review, Quest and Mimosa's products were also very good.  In
addition, Mimosa's can also serve as a backup/restore solution with CDP
(Continuous data protection, think LCR in E2k7 to another server + a lot


Other product reviewed were C2C's Archive One, good product with lots of
flexibility; Sherpa Software's Mail & Archive Attender (two products),
you need both to meet most archiving needs; and GFI MailArchiver, very
basic product.


You can read it on-line at:
http://www.windowsitpro.com/Article/ArticleID/49712/49712.html.  I used
a spreadsheet to come up with my rating, you can view it at:


Unfortunately, ZANTAZ and EMC didn't respond to my request for an eval
version of their product within the timeframe needed, a month. I have
heard good things about ZANTAZ's solution, haven't ran across anyone
using the EMC one but that doesn't mean it isn't good also. 


If anyone has used the Zantaz or EMC products please send me an e-mail.
I would like to add a rating to my XLS on them for other people to
compare against the product I reviewed.



SharePoint 2007 will make things a lot easier since you will be able to
storage message directly in SharePoint.  


Remember PST's are BAD, don't use them and try to keep your users from
using them too.


Jason Sherry - Pro Exchange http://www.theproexchange.com

From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Rick Boza
Sent: Wednesday, September 06, 2006 11:56 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Storage Philosophy (was: Re: PST size)


Data Storage, Mailbox Limits, enabling or disabling PSTs - always
questions that come up when you're discussing messaging architecture
with folks, so I thought I'd comment and hear what others thought on
this subject (if you're not interested, feel free to delete now with my
humble apologies for dragging you to this point).


Basically I see two general philosophies: you have strict limits and
encourage people to keep mailbox size way down, which is more often than
not accomplished using PSTs rather than really 'managing' the mail.  Or,
you design the system to support the real storage needs of the company.


I know this concept may seem a little controversial to some, but the
thing about PSTs is they are inefficient, hard to manage (network
storage of a PST is not supported by Microsoft) and difficult to recover
in the event of failure.  So my thought is to look to the root problem,
and try to approach this from an architectural angle rather than a
medieval view of storage.


Think about it: when people are using PSTs, the data has to be stored
somewhere.  In many cases, best practices and formal support
notwithstanding, this wins up on file servers.  So what we now have is
email stored on your network disks, taking up space, no single instance
storage, and un-scannable in the event of some 'cryptic' event happening
- for example, a lawsuit requiring discovery.  Or maybe it's on the
local hard drive - not getting backed up.  If and/or when that drive
fails, goodbye data.


My philosophy is to build the messaging infrastructure to handle that
storage of messages.  Heck, you're going to wind up using less disk
space in the long run because of single instance storage.  This way you
have manageable data assets rather than unmanageable data assets.  Far
superior in my opinion.  Set your limits and retention policies to
reflect what is really needed.  You may need multiple policies to
support multiple "classes" of employee, but that's easy enough to manage
with multiple stores and storage groups.


Of course, you need to plan for alternate storage locations for data
that really needs to be kept - what better place than SharePoint?  Fully
searchable, some limited version control if necessary, and also
manageable.  Plus of course Microsoft is making huge investments in
SharePoint technologies, so you're investing design considerations in
something that is almost definitely going to be around for some time
into  the foreseeable future.


Anyhow, just some random thoughts on data storage and design versus PSTs
- opinions are (as always) welcome!



From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William
Sent: Wednesday, September 06, 2006 12:40 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: PST size


Indeed.  Mine definitely experience degradation around the 9-12GB mark.
Oh and the 1 hour plus time to wait for "Outlook did not shut down
propery. data.pst is being checked for errors" to complete at startup
(or when mounted) can be annoying.


FAT32?  Next they're going to say this is one Win98, right?



From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Periyasamy, Raj
Sent: Wednesday, September 06, 2006 6:50 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: PST size

Just think of 20GB PST files, even that's crazy.





From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Vincent
Sent: Wednesday, September 06, 2006 4:10 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: PST size

off the subject... but did you know that the 20Gb limitation for unicode
is a design feature ? The technical limitation is 33Tb... Now that's a
crazy thought.... Imagine your users with 33Tb files....

----- Original Message ----
From: Nick Parkes <nick.parkes@xxxxxxxxxxxxxxxxx>
To: exchangelist@xxxxxxxxxxxxx
Sent: Wednesday, September 6, 2006 10:05:43 AM
Subject: [ExchangeList] Re: PST size

Convert it from an ANSI format PST to a UNICODE format PST.


If just a single one, create a new UNICODE PST and move everything in
the old one to the new one.





From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Farhan Khan
Sent: 06 September 2006 08:56
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: PST size



But I want to know for my sake that it can be increased or not? Or if we
can increase than what's the procedure? 





On 9/6/06, shorabh upadhyay <shorabh.upadhyay@xxxxxxxxx> wrote: 



          I will suggest you to create new PST instead of increase the
size of your existing PST. Because 4 GB size is not recommended at all.


On 9/6/06, Farhan Khan <xs2farhan@xxxxxxxxx > wrote: 



how can we increase the size of outlook 2003 pst size from 4gb to


Thanks and Regards,

Shorabh S. Upadhyay
Engineer - Exchange Server Support
Progressive Infotech (P) Ltd. 


The information contained in or attached to this email is intended only
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient, or a person responsible for delivering
it to the intended recipient, you are not authorised to and must not
disclose, copy, distribute, or retain this message or any part of it. It
may contain information which is confidential and/or covered by legal
professional or other privilege (or other rules or laws with similar
effect in jurisdictions outside England and Wales).

The views expressed in this email are not necessarily the views of
Centrica plc, and the company, its directors, officers or employees make
no representation or accept any liability for its accuracy or
completeness unless expressly stated to the contrary.


Other related posts: