I know people who have tens of gigabytes of information squirrelled away in Personal Storage Files (PSTs). They have accumulated this information over the years and the data has often ended up in PSTs because they’ve been forced to move items out of online mailboxes to comply with mailbox quotas. Remember, it’s not so long ago since disk was expensive and the average mailbox quota assigned to new users in corporate Exchange deployments ranged from 100MB to 200MB.
Small mailbox quotas and the resulting small (and easily maintained) databases delight administrators but are a real pain to users as they then have to play the drag-and-drop game to shuffle items out to PSTs in order that Exchange can deliver new messages into the mailbox. Of course, some users positively delight in filing items into PSTs to build up a set of files over the years. These folk tend to be very organized and end up with a PST per project or a PST per year or some other such accumulation of PSTs that clutter up their PC and become yet another set of data that has to be migrated once the time arrives for the user to move to a new PC.
In any case, whether you are a filer who boasts a proud collection of beautifully organized PSTs or an average person who has been forced to move items in a higgledy-piggledy fashion into a PST dumping ground, the time might come when you need to make a decision about where that data should be stored in the long term. Let’s face it, PSTs have a chequered history when it comes to corruption (less so now with the latest UUENCODE format than with the older ANSI files) and some of us are not very good at backing up PC files, so there’s always the potential that some disaster will come along that results in data loss. There’s a certain attraction in being able to put the data somewhere safe – or at least somewhere a lot safer than a PST can ever be.
And so the thought came to me that I should do something about my PSTs. I hate having any PSTs around because I regard the format as being both insecure and fragile, but the nature of dealing with Exchange for nearly sixteen years is that I have some of the brutes on my PC. When I went looking, I found two that I cared about, amounting to some 2GB. I know that this is small beer compared to some of you out there but I have been careful to keep only stuff that I thought I might need in the future. In other words, I’ve applied a reasonable filter over the years – not that the filter has always been successful in determining what gets stored, but at least it resulted in a manageable amount of data to process.
I have a Plan P Office 365 subscription. All Office 365 plans come with the ability to use an archive mailbox (Plan P offers a 25GB archive limit) so this seemed like the right place to move my PST data. After all, Microsoft would then have the privilege of taking care of the data for me and I’d always be able to access it should the need arise. The only downside I could see was that I would no longer have offline access to the data because none of the clients that can access archive mailboxes support this mode. In short, if you want to access an archive mailbox, you better be able to make an online connection. This is the same whether the archive mailbox is on an Exchange 2010 on-premises server or an Exchange Online server.
Offline access wasn’t hugely important to me. After all, the reason why you put information in an archive is that you want to keep the information but not necessarily have immediate access to it. Anything that you think should be to hand should be stored in your primary mailbox where it can be accessed by any Exchange client and synchronized down into your OST if you use Outlook configured in cached Exchange mode.
So I hatched a plan to eliminate PSTs and move everything to the cloud. But how to effect the transfer? Well, if I had a lot of PSTs to move and wanted to spend some money, I could investigate some commercial software such as Quest Migrator for Cloud Email or Transvault Insight. However, I only had a couple of gigabytes to move and anyway, I’m cheap, so I decided that I would do the job manually.
Unfortunately Exchange Online doesn’t have an equivalent to the New-MailboxImportRequest cmdlet that’s available to import PST data into an on-premises Exchange mailbox. This is understandable because you don’t have access to some of the components that the cmdlet depends on when you use Office 365, such as the secure file share that’s used to hold the PSTs to be imported or being able to manipulate the settings of the Client Access Server (CAS) that does the work to move PST data into the mailbox.
Oh well, there’s always the good old drag-and-drop method using Outlook, which is what I ended up doing. The good news is that this approach works. The bad news is that it’s slow. Your mileage will vary depending on the network speed, the responsiveness of the server that hosts your archive mailbox, and various other influences but I ended up taking about 80 minutes to move 3,335 items amounting to 747.7MB. You can see how I retrieved information about the contents of the archive using the Get-MailboxStatistics cmdlet in the screenshot.
Some of the time taken can be charged to human weakness as I looked at items in the PST before moving them to the archive, so that’s another factor to take into account.
The interesting thing for me is the radical difference between the 2GB of PST data that I thought I had and the 747.7MB that Exchange Online tells me I now have. I don’t think that any information is missing so I therefore conclude that the difference is due to the relative inefficient internal storage structure used by PSTs when compared to Exchange databases.
So far I am happy with the decision to move everything from PSTs into an archive mailbox. I haven’t missed offline access at all and functions such as searching continues to work across both primary and archive mailboxes. I use Outlook 2010 and haven’t tested search behaviour with earlier clients. If, like me, you have an Office 365 subscription and want to get rid of some PSTs, you could do a lot worse than to migrate the data into the cloud. After all, you can reverse the process if you need to move back.
