The PST FlightDeck Process – Our Approach to PST Discovery
This week, we begin a series of short posts to describe the process behind the PST FlightDeck approach to PST/Offline Mail ingestion. We’ll look at how we discover all the PSTs in your environment, even across network shares and home drives, centralise, process and ingest them before rehydrating any shortcuts contained within.
Step 1 – Discovering all the PSTs
The difficulties surrounding the proliferation of the PST file in the modern enterprise was a dominant topic of conversation at Microsoft Ignite 2015. As they spread across your environment, they can cause a massive amount of duplicated information to be stored on your hardware as well as pose a threat to user email access if they corrupt. Today, looking to migrate your PSTs to Office 365, or even eliminating them entirely, is a wise choice for anyone looking to preserve user access and gain greater control over the day-to-day management of email data.
First, you need a method to locate all the PSTs. You can take an agent-less approach from a central server, but this would require the need to remotely connect to every machine connected to the domain (or potentially the whole forest) to look for the PSTs. Click here to learn more about the pros and cons of agent vs agent-less approaches to PST Discovery.
By deploying an agent, such as the PST FlightDeck Agent, to the company computers & laptops using any Software-Distribution-System (e.g. SCCM, Altiris, etc.), the agent will scan the configured paths for PST files and any associated metadata. Additionally, it will scan the user’s Outlook profiles and determine which PST files are currently attached to Outlook, and which ones are not. The information about the discovered PST files (Owner, PST Name, PST Path, Creation Date, Last Modified Date, Size, Attached or not, etc.) will be transmitted via HTTP/HTTPS web service back to the PST FlightDeck Server and can be used for further planning of the migration.
It’s important to understand that the PSTFlightDeck Agent runs under the security context of the user, therefore no administrative account that has access to fileservers and user workstations is required. Typically, local drives and the user’s home share are scanned with the user agent, while Group-Shares are scanned from a central location using the fileserver scanner. This approach ensures maximum security while simplifying the owner detection process.
The Discovery Phase is independent from the following migration phases and is typically done upfront, to fetch the required data necessary for detailed planning of the migration (e.g. how many PST files are there, where are they, their size, age, distribution, etc…).
Check back next week to learn about our centralisation process for the discovered PST files and remember to follow us to keep up to date with our new content.