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

  • From: "Rick Boza" <rickb@xxxxxxxxxxxxxxx>
  • To: <exchangelist@xxxxxxxxxxxxx>
  • Date: Wed, 6 Sep 2006 13:56:02 -0400

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!


Rick 

 

From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William
Lefkovics
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.

 

--Nick

 

________________________________

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? 

 

TIA

 

 

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

Farhan,

 

          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: 

 

hi,

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

TIA
 





-- 
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: