Disclosure – The author has been compensated to provide an honest opinion of the product in this review. You can read our full disclosure statement here.
I encountered my first PST file on day 1 of my very first job in IT. The company I worked for used Exchange Server 5.0, with very small mailbox quotas. The first step for new users after setting up the Microsoft Exchange Client was to add a PST file for the user to store their email in, so that they could avoid breaching their mailbox quota. I was on the help desk team, so I did this hundreds of times. PST files were seen at the time as a solution a problem.
Fast forward to today, and PST files are still found throughout many organizations, but now they are largely seen as a problem rather than a solution. PST files are big, bloated, inefficient files that store mailbox data in a way that is difficult to find when it’s really needed, such as during a legal case. And PST files have featured quite prominently in high profile data breaches such as the Sony hack in 2014, in which PST files containing email messages to and from the Sony Chairman were publicly leaked.
Yes, PST files still have some valid use cases. There are few better ways to transmit data between two air-gapped networks, or hand over a chunk of mailbox data to someone, than to simply export it to a PST file. But those are transient cases, moving data between two points or granting temporary access to a copy of it. They aren’t examples of the real problem – companies storing many gigabytes or terabytes of data in PST files throughout their network for long periods of time.
With Office 365 and its unlimited archive mailboxes in Exchange Online, the opportunity exists for companies to relieve themselves of the burden of storing, backing up, and searching through that mess of PST files. Ingesting the data into cloud storage is a logical solution to the problem, but it raises some problems of its own. How do you find all those PST files, attribute the data to a user, upload them to an archive location such as a mailbox, and then purge them from your network for good? If you’ve ever tried to tackle this problem, you’ll definitely understand that it isn’t easy.
Quadrotech believes that they have the answer with PST Flightdeck. I worked with Quadrotech late last year on the free eBook, the Complete Guide to Eradicating PST Files, and recently spoke about the challenges of PST eradication with their Chief Strategy Officer, Dan Clark, on episode 16 of the Exchange Server Pro podcast. And in this review I’m going to share my thoughts on how PST Flightdeck seeks to enable customers to eradicate PST files from their network.
The Install Experience for PST Flightdeck
Throughout this review you should keep in mind that PST Flightdeck is enterprise software. It is designed to work well for customers of any size, but it isn’t a simple, single-purpose application. Under the hood there is a lot of switches and knobs for tuning Flightdeck for complex and challenging scenarios. A full SQL instance is required for PST Flightdeck, there’s no option to install on SQL Express, but most enterprise customers will have SQL already available on their network.
At the smaller end, the architecture and system requirements might seem like overkill, and I could see how some customers might even be too small for deploying this product on-premises. Quadrotech offers cloud migration services that reduces the on-premises infrastructure required, including removing the need to run a SQL instance. Or there’s free tools available such as the PST Capture Tool from Microsoft, which can do the basic job of importing PST files, but are missing the features of PST Flightdeck that add most of the value to a larger project.
When deploying the full solution on-premises, you can install all of the PST Flightdeck components on a single server, or distribute them over multiple servers or sites, depending on your environment.
I went with a single server deployment for my evaluation, with PST files placed on some client computers as well as in a file share on a server.
Configuring PST Flightdeck
For evaluations, Quadrotech can provide you with a script that sets a bunch of options in the configuration to fairly aggressive settings. By this I mean scheduled events and workflow steps fire more often, helping move you along through a small evaluation or pilot quickly. Once you reach production stage though, these options wouldn’t be suitable. The defaults for most items seem quite reasonable, but as with any enterprise software if you need special tuning performed you’re likely going to engage the vendor or their partner to stand up the server for you and get it to an operational state.
Managing PST Flightdeck
Flightdeck presents a simple, easy to navigate management console. Once I was past the initial period of familiarization, I was able to get around pretty easily. There is also a web interface that can be provided to project managers so that they can monitor the progress of your PST eradication project without needing to ask you for status reports.
Discovering PST Files
I scattered a few PST files around my test lab and deployed the PST Flightdeck migration agent. Packaged as an MSI you can easily deploy the agent across your network using Group Policy, SCCM, or your preferred software deployment platform. At next login the agent scanned my client computers and quickly located the PST files.
My evaluation was performed on Windows clients, but just as I was finishing the review Quadrotech announced that a client for Apple Macs is now available too.
SCREENSHOT OF FOUND FILES
PST Flightdeck also provides a scanner for shared folders, which you can use to scan places such as file servers, and those archive storage locations that tend to be out there on the network holding all the PST files exported from the mailboxes of departed users. If you’ve got a bunch of DVDs or removable hard drives full of PSTs in your cupboard, dump them into a file share and let the shared folder scanner discover them.
Your choices for discovered PST files are straightforward:
- Ingest to Exchange or Office 365 mailboxes, or to Veritas Enterprise Vault, when ownership of the PST file can be determined
- Park the PST files in a central location for further inspection and attribution
The Exchange and Office 365 mailboxes can be either primary or archive mailboxes.
Demonstration of a PST Migration
I decided to migrate some PST files into archive mailboxes hosted by my on-premises Exchange server. There are two steps to kick off this process. First, mark the discovered PST files for migration.
Next, set a migration priority for the user. I had no need to specify a different priority for my users, so I just set them all to the same value. But I can think of scenarios where this would be useful, such as prioritizing VIP users, or prioritizing users in a site where the desktop fleet is about to be replaced (risking the PST files on the old desktops being lost).
At this point it’s also worth pointing out that Flightdeck allows you to configure different settings for different locations. In a complex deployment where you might have various Flightdeck components deployed to various physical locations, you can specify that agents in one location will upload their PST files to a particular server for processing, while users in another location can upload to a different server. This makes sense if you have distributed infrastructure such as Exchange servers on different continents. Why copy PST files from New York to London if they’re going to be ingested into archive mailboxes back in New York?
Once the migration was under way the end users involved in my tests received their first popup notifications from the migration agent. These notifications are customizable, and include popups and dialogs from the agent, as well as emails sent by the PST Flightdeck server to notify your users about the PST migration project. Users will receive the information they need to know, when they need to know it, all built in to Flightdeck. Having been involved in PST migration projects before where a small team of dedicated communications people handles all of this using a big spreadsheet and lots of broadcast emails, this definitely seems like a better idea to me.
First, my user receives a notification to restart Outlook.
Next, they’re prompted to start the migration now, or postpone it for up to 14 days.
When they start their migration, the PST files discovered by the migration agent and marked for migration by the administrator are presented to the user. They can choose to migrate a file, delete it, or mark it as “Not mine”. If the user claims a file is not theirs, you can upload it to a parking area on a server for further analysis.
The analysis is very interesting. When a PST migration is being manually driven, ownership of PST files is usually determined by a few basic criteria; the name of the PST file, where it is located, and whether it is attached to an Outlook profile. Those criteria can be misleading. Consider a scenario where a PST file has been provided to a Human Resources officer for an internal investigation. What if the name of the PST file is johnsmith.pst, but the file is located in a path that multiple users can access (for example, C:Temp), and is attached to an Outlook profile for user “Dawn Evans”? In that situation, ownership of the file is nearly impossible to determine without further manual analysis, which is time consuming and will still be inaccurate.
PST Flightdeck addresses those scenarios with what is called Six Factor Analysis (which they call 6FA). Ownership is determined with weighted criteria; file owner, scanned owner, user name in path, most common sender, most common recipient, and which Outlook profile it is attached to. If the weighted criteria add up to a 90% certainty, then ownership is automatically attributed to a user. If not, then manual intervention is required. In a large PST migration project, this type of automated and accurate analysis is critical.
After deciding what to do with the PST files, the files are uploaded in the background using BITS to handle interruptions and poor network connectivity. During our podcast discussion Dan Clark mentioned the case of PST files on computers located on oil rigs out on the ocean, which have very challenging network connectivity. That’s an extreme example I guess, but most companies will have something that interrupts connectivity such as desktops shutting down at night, or remote workers who connect and disconnect throughout the day.
After the PST files are uploaded to the server, another copy is made on the server as a backup before anything else is done. This is where my evaluation stalled, and the process didn’t move past the backup stage. I left it alone for a while, tinkered with a few things, probably made it worse, and then decided to contact Quadrotech support. I actually recommend that during any software evaluation you try out the vendor’s support process to get a taste for what you might need to deal with when you become a paying customer. I try to think of a few questions or support situations during an evaluation, but sometimes an actual problem occurs and I need to seek assistance anyway.
In this case, a little over a day later I’d spent an hour on a Webex desktop sharing session with Quadrotech support. It was an informative session, as the support staff were able to demonstrate to me how they were troubleshooting the issue, where to look for log files, and so on. In the end the problems were simple, but they were things that seemed to be missing from the documentation I was working from. Documentation updates are easy fixes though, and I suspect most Quadrotech customers have their initial configuration done by a consultant or partner anyway, and wouldn’t run into the same issues that I did.
With the migration working again, PST Flightdeck continued through the de-duplication and ingesting steps of the workflow, and the PST migration for my test users finished successfully. The content was where I expected to see it in the archive mailboxes of my users, and one more popup appeared on the desktops to notify the that the migration was complete. The migration agent even removed the PST files from the client machines.
Dealing with Departed Users
One of the scenarios I was interested in is PST files for departed users. Companies tend to treat departed user mailboxes in one of two ways:
- Mailboxes are hidden from the GAL and left on the server indefinitely, sometimes moved to a specific database.
- Mailboxes are exported to PST files which are stored on a file server or removable media indefinitely.
For the latter scenario, there is the question of where to put those PST files. One of the drivers of a PST eradication project is putting the data somewhere that it can be more easily searched and accessed when you need it. Dumping them all back into Exchange is not a very attractive proposition for large customers due to the cost of storage. Exchange Online mailboxes seem like a better idea, but wearing the cost of Office 365 licenses for departed users is also not a very attractive proposition, so inactive mailboxes (an Exchange Online mailbox that has a hold applied so that data is not deleted, and does not consume a license) should be considered.
Interestingly, the native PST ingestion capabilities Microsoft provides with the Office 365 Import Service do not currently support Inactive mailboxes, so if you’re using that service you would need to build your own workflow for provisioning mailboxes, licensing them, running through the Import Service procedures, then turning the mailboxes into Inactive mailboxes. All possible, but not efficient or reliable.
PST Flightdeck has a solution for this scenario by automating the complete process for you, with all the other Flightdeck benefits such as de-duplication, attribution, and reporting. If you have a big stash of PST files for departed users to deal with as part of your overall project, then this is a very useful capability.
What Doesn’t PST Flightdeck Do?
Since no software is 100% perfect for every scenario, you might be wonder what sort of gaps exist with this solution. PST Flightdeck fills the gaps left by other tools such as PST Capture Tool or the Office 365 Import Service, but in terms of an end to end PST eradication project there’s still some steps you’ll need to take outside of Flightdeck, such as configuring Group Policies to prevent the growth of existing PST files, and later to prevent the creation of new PST files.
That said, PST Flightdeck can play a part in rolling out those Group Policies to your users, by adding custom PowerShell scripts to your Flightdeck migration workflows that add users into the Active Directory groups that the GPOs are filtered to.
The attribution of PST files to users is also not 100% hands-free, with manual intervention required when the analysis can’t determine an owner with a high degree of probability, although I have to say it did a good job in my small sample. I think it’s reasonable to expect a low percentage of PST files will require some manual intervention in any size project.
Final Thoughts
Having dealt with the process of manually discovering, analysing, and importing large quantities of PST files in the past, the PST Flightdeck solution has many benefits that are obvious to me. It may have been overkill for some of the smaller PST projects I worked on, but for the larger ones it could have saved a lot of time and effort, and improved the outcome considerably.
If you’re not sure whether PST Flightdeck would be helpful in your situation, you can always consider deploying it as an evaluation and using it to scan your environment to see just how big your PST problem is. Armed with that information, and the knowledge that free tools have feature gaps and require a lot of manual effort, you might just find that PST Flightdeck will fit your scenario after all.
To find out more about Quadrotech’s PST to Office 365 migration services, please visit the PST Flight Deck product page
