Why PSTs aren't needed

  • 18 March 2021
  • 2 replies
  • 61 views

Userlevel 3
Badge +4

Recently I was on a call with a prospect that had an RFP for a solution that would copy PSTs to a central location so they could be backed up. While Commvault could backup the PSTs files, the major issue with this is that PSTs were activity being used by end users. This means Outlook would have the PSTs open, thus locked to a basic file copies and even if we used the VSS support to get snapshot of them they would not be in a consistent state in some cases. Therefore, this would lead to backing up corrupted PST files. Furthermore, if a user had a say 2GB PST today and they added a single email to it, the entire PST would need to be copied\backed up again. With Commvault we would dedupe the data before going to the ContentStore but with other backup or file copy solution this would lead to possible exponential growth. PSTs are also not supported on network shares, mainly because if there is a network interruption they can easily lead to corrupted PSTs. PSTs also cannot be searched or managed centrally. So there are many reason to get rid of PSTs and most organizations have done this many years ago. The reasons PSTs were primary used was because mailbox limit were too small and users had to delete or move items to get below their limits, so they used PSTs to hold items. There are other reasons to, but the primary and most other valid use cases in the past are no longer valid today with a properly architecture Exchange environment (Note: Using flash\expensive storage is NOT a properly architecture environment).

 

On a call with this client I went over the issues with PSTs, including trying to copy or back them up, and how Microsoft introduced features in Exchange 2010 to really eliminate them. The technical person on the call for the client was not aware of Exchange Archive Mailboxes, Microsoft's recommendation for cheap (JBOD & SATA) storage, and the many PST issues I brought up (I assume they were not on the Exchange team). So I wrote up this email below to document the solution from Microsoft and also mention how Commvault can help with the elimination (ingestion of them into the ContentStore only).

 

Microsoft introduced archive mailboxes in Exchange 2010, primarily to keep primary mailboxes sizes down and to eliminate the need for PSTs. These mailboxes are really just a secondary mailbox, that will show up in Outlook and OWA automatically. Users can manually move, or user applied or policy-based retention tags can be used to move, items from a primary mailbox into an archive mailbox. Archive mailboxes can also be stored in a different database then primary mailboxes and even in a different DAG. This allows for them to be easily placed on different servers, storage, and have different DAG replication copy settings. It’s very common, and follows the Microsoft Exchange Preferred Architecture guide, for JBOD and SATA storage to be used for both primary and archive mailbox database, thus keeping storage costs down.

  • While the current guide is for Exchange 2019, the Exchange database architecture and guidance has been the same since Exchange 2010. Furthermore, also very little has changed for archive mailbox and retention tags support since Exchange 2010, so all the articles below are valid for 2016 too.

 

Clients I have worked for many years now are focused on the elimination of PST following these basic steps

  1. Eliminate the need for PSTs
    • This is most commonly done by providing larger mailbox limits or using archive mailboxes, as outlined above.
    • Commvault has also helped our customers by using clean-up policy to remove attachments from older emails or remove entire emails, based on age, size, folder, and/or message type. End-user can then access these removed attachments by click the HTML link inserted into the modified emails easily or removed messages can be accessed via the Commvault end-user web console, optional Outlook extension, and via the IMAP protocol that is supported by most email clients. Items stored in Commvault are single instances\deduplicated, compressed, and encrypted and almost any type of storage can be used for it.
  2. Educate users on how to access their legacy PST data
    • If items imported back into their primary mailbox, very little education should be needed. If an archive mailbox is used, users will see a second mailbox folder structure in Outlook and little education should be needed also.
    • If Commvault is used, most customers educate users to goto a website to access messages older than the retention period configured in Exchange and\or the Commvault clean-up policies. In addition, the Commvault Outlook extension can be deployed to provide similar support of an Exchange archive mailbox access.
  3. Set PSTs to Read-Only and block the creation of new ones via Office Group Policy support
  4. Ingest PST data and allow end-user access to it
  5. Remove PST files from Outlook and file system
    • Removing links to PSTs from Outlook is documented here: How to use Outlook policy to control PST use and creation using the DisablePST registry\policy setting.
    • Once PST data has been imported, the links to PSTs should be removed from Outlook, and then the files should be deleted from all system.

 

Microsoft articles on this topic

 

3rd party articles


2 replies

Userlevel 4
Badge +9

Very nice write up.

The only use case for PST I see in the future is when a migrated mailbox protected with Exchange Mailbox Classic requires legacy messages (or even the whole mailbox) restored into Exchange Online. Whilst you can at the moment use an access node with exchange mailbox classic to write into Exchange Online, that ability will soon disappear in 2021 because the agent does not support OAurh2 Authentication flows.

Userlevel 3
Badge +4

We’ve had support for Modern Authentication since FR21, so OAuth shouldn’t be an issue.

We also support “importing” (really it’s just reindexed using v2 using the data on the ContentStore) from the v1 classic agent into the v2 mailbox agent. So PST shouldn’t be needed for the case you outlined above, if I follow it correctly.

Reply