Everyone wrote: » No they don't need to use it. They don't need to keep e-mail for 20 years. When I was working in a DoD Environment with the same limitations, we had retention policies. You had your 100 MB limit (or less depending on rank actually), and you weren't supposed to keep more than 90 days worth of e-mail. If your job required you to receive a volume of e-mail that would cause you to exceed the 100 MB limit within 90 days, then you could ask for an increase which required approval. PST files were use at your own risk. Not allowed on the SAN, and not backed up for you. It's SO much easier in an DoD environment, you have policies to back you up, and can have Commanders sign off on new ones if needed. The company I work for now (not associated with the DoD at all) still has 100 MB mailbox limits. No retention policy, but PST files are still use at your own risk.
demonfurbie wrote: » how many users? are they using laptops or desktops? what os are they using?
gunbunnysoulja wrote: » Why would you assume they don't need it? Yes, they do need to keep it. We aren't talking about soldiers. We are talking about scientists, engineers, etc. at a research and development facility, and everything goes back 7 years. We do have some that have approval for >100MB on Exchange, however with Enterprise E-Mail right around the corner (DISA managed) that's a moot point anyways. We have 2,000 users and many have >10GB e-mail via .PST. 100MB works for many. I did a comparasion analysis of several different DoD entities in which that worked fine for them when researching the best approach for a backup solution (went with NETAPP) however for us it just isn't feasible. This is why I'm looking for those who can provide input on a solution for .PST files that is incremental, scheduled, and can be backed up while in use.
swild wrote: » Microsoft actually has a PST backup program. It's what we use at my company.Using the Microsoft Outlook Personal Folders Backup tool - Outlook - Office.com
demonfurbie wrote: » have ya thought about mapping a network drive and redirecting the pst files to that network drive with each user having there pst either named there user name or a folder for each user.
Everyone wrote: » Because e-mail has been my life for a very long time. They don't need it. E-mail is not a storage system. How often do any of them need to go back through 10+GB PST files and find an e-mail that is several years old? I guarantee you it is almost never. If there are legal (or other) requirements to keep information a certain number of years, keeping it in PST files is not the answer. PST files and e-mail hoarders are huge pet peeve of mine. An archiving system that puts data over a certain age onto tape in that rare off chance someone really has a legitimate need to pull up that memo that was e-mailed to them back in 2004 or whatever makes a lot more sense than backing up all of it up to a NAS or SAN. What kind of storage are the Exchange databases on? I find it really amusing when people want to take e-mail out of Exchange databases, put it in PST files, then put those files on the same storage system the Exchange databases are on. What kind of sense does that make? If you aren't saving any space, or using a cheaper storage medium, what is the point? If it's a moot point due to Enterprise E-mail coming up, then why waste the effort on this? You probably won't be able to keep anything you put into place once all your users are mandated to use that.
Claymoore wrote: » Obligatory Post - PSTs are not and never have been supported on File Servers:Network Stored PST files ... don't do it! - Ask the Performance Team - Site Home - TechNet Blogs
gunbunnysoulja wrote: » In regards to E.E., the moot point is requesting an increase of the Exchange limits. Everyone will have access to 4GB of DISA's cloud for inbox however people will unfortunately need >4GB. You make a great point about e-mail not being a storage system. I agree and the unfortunate culture this environment has had for the past couple decades has taught them to save all e-mails. The Exchange System is separate from our NETAPP NAS which we use for backup of everything else (shares and home directory). Politics play a large role in doing things this way for DoD as there is baseline provided funds, and mission funds. 100MB is baseline. Everything else the mission tenants need/want comes out of Mission funds which means a separate system. You make a good point however with archiving. We couldn't do that now as the users @ 100MB need access to much more than that daily, however with 4GB anything greater can probably be archived. We do have COMMVAULT and I did consider that for block level backups but maybe we can integrate that into an archiving solution. I'll check with the tape guys as well as that's not my lane but what do you recommend for an archiving solution to tape?
Everyone wrote: » Because e-mail has been my life for a very long time. They don't need it. E-mail is not a storage system. How often do any of them need to go back through 10+GB PST files and find an e-mail that is several years old? I guarantee you it is almost never. If there are legal (or other) requirements to keep information a certain number of years, keeping it in PST files is not the answer. PST files and e-mail hoarders are huge pet peeve of mine.
Everyone wrote: » You can't do incremental/differential backups of PST files. Anytime anything is added or removed from the PST file, it will have changed, so an incremental or differential backup of the file system the PST file is on will copy the whole file every time regardless. Backup software doesn't look inside the PST file and only copy new information. The only PST files that would not get picked up in an incremental backup would be files those that didn't get touched at all.
Everyone wrote: » That will work for you NOW while you still have your Exchange servers. That type of solution will no longer work for you once you go to Enterprise e-mail and the Exchange servers are all up at DISA.
Claymoore wrote: » We had lots of incidents of mail being rejected to our account execs because their mailboxes were full. It's amazing how much space calendar items take up, and any decent account exec has their calendar constantly booked. Then you start calculating space for attachments and a mailbox fills up quickly. Thousands of man-hours were wasted by people managing thier mailboxes rather than working. When those are $200 per hour consultants and AEs working on million dollar deals, you can justify buying terabytes of email storage in a hurry.
Claymoore wrote: » I somewhat agree. PST files are a data loss or data leak disaster waiting to happen and should be disabled through group policy. However, I honestly don't care if someone wants to keep all their email. The technology exists to give them large mailboxes and archives on cheap storage, so give them the space and save your bullets for another IT battle. 100 Mb limits are simply retarted today. As an Exchange admin, I was never subject to those rules before (who watches the watchers?) until I became a consultant and thus an end user of computing resources. We were subject to 100 Mb limits and almost all of us were always hitting warning thresholds or actual send and receive limits on a weekly basis. I had auto-archive rules tuned to different times for different folders to send to multiple PSTs at one point, but I eventually gave up and had a 30-day default rule that moved to an archive PST. I then backed up my laptop to a portable hard drive in preparation for the eventual laptop failure, re-image, or replacement. We had lots of incidents of mail being rejected to our account execs because their mailboxes were full. It's amazing how much space calendar items take up, and any decent account exec has their calendar constantly booked. Then you start calculating space for attachments and a mailbox fills up quickly. Thousands of man-hours were wasted by people managing thier mailboxes rather than working. When those are $200 per hour consultants and AEs working on million dollar deals, you can justify buying terabytes of email storage in a hurry.
Everyone wrote: » ...It is pretty transparent to the user too, a stub is kept in their mailbox, and the add-in retrieves the message through the Commvault server when a user tries to open it...
gunbunnysoulja wrote: » I originally thought this as well due to the inherent architecture of the .PST, however there are several programs out there that do incremental backup's of .PST's. I'm assuming it's a proprietary algorithm.
gunbunnysoulja wrote: » Can you suggest a viable solution after we no longer manage our own Exchange servers?
Everyone wrote: » Speaking of, the storage system for that must have cost a TON. IIRC close to half a million users, and they're all getting like a 4GB limit.
Everyone wrote: » Has to be a client side app then. Does the Army do (this is an Army site right?) the "Standard Desktop" too? If so, good luck getting approval to install a 3rd party app on the client for this.
Everyone wrote: » Yes and when people can get 7+GB from GMail or pick your favorite free e-mail service, it is hard to keep a 100MB limit. The number of users you have in the environment plays a huge part in cost effectiveness of just giving people larger mailboxes. There's a lot more to it than ## mailbox limit X ##### users. With the 60,000+ mailboxes I have in the environment I work in now, it was going to cost almost $500k to get the storage necessary to support an increase from 100 MB mailboxes to 500 MB mailboxes as part of a migration to Exchange 2010. With that many mailboxes, only about 300 have exceptions to exceed the current 100 MB limit, so only a fraction of a percent. Enterprise class SAN storage, replicated across geographically dispersed data centers, isn't cheap. For comparison, my last job with just under 4,000 mailboxes, I was able to increase their mailbox limits from 200 MB to a 3 tiered approach, 500 MB, 1.5 GB, and 3 GB, without using more storage than what was already assigned to Exchange, so no additional costs. In gunbunny's case here, there are policies keeping them at 100 MB right now, and even if the policy could be changed, investing in more storage to support a limit increase would not be an option due to pending migration of e-mail services to DISA's "cloud". Speaking of, the storage system for that must have cost a TON. IIRC close to half a million users, and they're all getting like a 4GB limit.
gunbunnysoulja wrote: » This is an Army site. We aren't using software for the incremental capabilities, however if we utilize a PST backup program, we will move in that direction. We can get a certificate of networthyness for pretty much anything if we can justify a need for it (and there aren't any vulnerabilities). Being outside of the normal DoD scope, we purchase some pretty obscure software for the engineers and scientists. The downside is a CON request takes some time.
Everyone wrote: » Assuming they don't block PST usage post migration, you'll have to rely on the users to create the PST files themselves (sounds like they already are anyway). If it's already up to them to create a PST file, why make the effort to back it up for them? I'm still a big fan of "You have 4GB (or whatever they give you after moving to DISA) of space now, clean out your freaking mailbox or STFU." + "If you want to have a PST file, have fun, but we aren't supporting it."
Claymoore wrote: » Well, there's your problem - you are putting Exchange on the SAN, which is the most expensive place you can keep it. Exchange 2010 is designed to run on local disks. SAS isn't necessary in most cases, SATA is fine. Even a JBOD configuration is acceptable if you have more than one DAG member in a site. Microsoft's internal mail servers and their cloud run on local disks which saved them a ton of money in storage costs when they moved to 2010. As Everyone knows (which if everyone does know, why am I pointing it out?), the Exchange Mailbox Role Requirements calculator is your friend when you want to properly size your mailbox servers. It has some quirks, and you need to understand why it makes some of the recommendations it does, but it is an invaluable tool. I used to just use for proper storage sizing, but often I am using the results to justify putting Excnage on a physical box to leverage local storage instead of virtualizing the mailbox server and storing everything on the SAN.
