Hmm . . .
I think that several issues that should be thought of distinctly and
separate, have been muddled together here.
We have
- mail box size limits
- storage management
- .PST usage
- .OST usage
- budget and PHB management
- Data and information management
I think you will do best, if you separate these from each other, and deal
with them as appropriate. If it will help, I'll comment on a couple of
them, in a specific order.
Budget and PHB Management: You need to have a yearly budget. Part of it
has to be for your hardware. That will include maintaining what you have,
and a program for upgrades that is tied to both your depreciation schedule
and your life cycle plan. If your PHB has not required you to coordinate
these, or even draw up some of them, then you need to manage your PHB and
get them done and blessed. You cannot survive without them.
Storage Management: In a static organization (in terms of the total number
of users), as you replace hot spare spindles for your RAID system, each new
spindle should hit a budgeted price point. Do this in targeted sizes, so
that you are auto-magically increasing your capacity over time. You should
NEVER have to buy a larger array to get more storage for a finite
population, if you are doing a good job of managing what you have.
Mail Box Size: Bigger is better - usually. It is not IS's business to be
passing judgment on the business value of what your customers want to store,
nor how they want to organize it (except as noted below). Your job is to
manage to your budget, and make sure that your budget is sized to your need.
Customer satisfaction is an element of service quality that you should be
measuring. If you aren't, your policies have no validity - even if you
think they are about right.
Data and information management- This has NOTHING (as in not one little
bit) to do with storage management. If your organization wants to achieve a
state of managing your digital information and data, and the job has been
given to people that manage storage, then you will fail. Data and
information management is a discipline of the library sciences. If you
don't have someone with that kind of training who is providing requirements
to your storage management people, then all you have is useless chaos. If
that is your situation, then your policies about capacity and limits are
capricious and without a foundation in the needs of the business. But alas,
most IT shops are run this way.
.OST usage. An .OST file is an Off-line STore. Unfortunately, it is
limited to being a mirror of folders on your server that have been flagged
for offline availability. As far as I know (hey, I make mistakes too),
there is no way to have a folder in an .OST that is not in the server store.
So, customer data that properly belongs in a personal store and not in your
enterprise message store, has to go someplace else.
.PST usage. A .PST does those things that an .OST cannot. Most (if not
all) of your customers will have message data that is either personal or
private, and which they feel is inappropriate to keep on one of your
servers. The reasons for this are almost infinite, and usually consistent
with your business rules and guidelines (even if you think they aren't). A
.PST is a terrible thing to use as a message delivery destination, but it is
an excellent Personal STore. I think we would be better off, neither
Exchange nor Outlook were in the storage business. It would be better to
have a general purpose DFS service in both client and server versions, and
simply have the ability to create special folders that were valid mail
destinations, but alas we are not yet there. Someday. So for now, we have
to deal with what we have.
-----Original Message-----
From: Exchange.ListServe
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 2:02 AM
To: Exchange Discussions
Subject: *groan* PST Files
Hi.
Standard Version of EX5.5, SP4. 200+ users.
We are looking at educating users in not storing everything in their email,
but storing in either a .pst or .ost. Money is an issue, my company won't
pay
for us to upgrade to 5.5 Enterprise or Exchange 2K, so there's no option IMO
other than educate the packrats, and set up an archiving solution.
I've also read the arguments in the FAQ, but wonder what other folks in a
similar
situation would do, with regard to archiving.
Currently our priv.edb is 13.9 GB, while the pub.edb is 226MB, so would
archiving
essential emails on Public folders be a reasonable idea?
Some of our client handlers need to keep archives for some of our clients,
in case
of compliance issues.
Jon
****************************************************************************
*****
DISCLAIMER
Any opinions expressed in this email are those of the individual and
not necessarily the Company. This email and any files transmitted
with it, including replies and forwarded copies (which may contain
alterations) subsequently transmitted from the Company, are
confidential and solely for the use of the intended recipient. It may
contain material protected by attorney-client privilege. If you are not
the intended recipient or the person responsible for delivering to the
intended recipient, be advised that you have received this email in
error and that any use is strictly prohibited.
If you have received this email in error please notify the IT
department by telephone on +44 (0)117 311 8555 or via email to
[EMAIL PROTECTED], including a copy of this
message.
Please then delete this email and destroy any copies of it.
****************************************************************************
*****
_________________________________________________________________
List posting FAQ: http://www.swinc.com/resource/exch_faq.htm
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe: mailto:[EMAIL PROTECTED]
Exchange List admin: [EMAIL PROTECTED]
_________________________________________________________________
List posting FAQ: http://www.swinc.com/resource/exch_faq.htm
Archives: http://www.swynk.com/sitesearch/search.asp
To unsubscribe: mailto:[EMAIL PROTECTED]
Exchange List admin: [EMAIL PROTECTED]
