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 products (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 more). 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: http://izzy.org/data/Archiving%20Products.xls. 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. Note: 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! 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.