4 Dec 2019 by Mike Weaver
Inspire: Winning Hearts and Minds
Successful change management requires inspirational leadership. Here’s how to keep your team on track.
Last week, we looked at how our approach helps you to find all the PSTs in your environment. Due to the spread and proliferation of these files, discovering them all and safely migrating (or eliminating), them, can be a resource-intensive undertaking. This is especially if you’re not using an agent to discover them. Once you’ve identified the files and gathered information on them, such as PST location and size for example, you can look to centralize them to stage them for processing and ingestion into the new target.
Once enabled for migration, the FlightDeck Agent deploys several registry keys to change the behavior and use of PST files for that user. The user is still able to attach and read PST files, but can’t add any new data to any PST file. The Agent then creates a snapshot of the attached PST files, and queues them for upload to the PSTFlightDeck Server. Non-attached PST files don’t require a snapshot, as there is no exclusive lock by Outlook. The centralization process occurs with QUADROtech’s ACT (Advanced Centralization Technology), utilizing Microsoft’s BITS protocol in the background for the underlying transfer.
This allows interrupted transfers to resume (in cases where the user laptop was undocked from company network for example) from the last successfully transmitted byte as soon a new connection is available. Furthermore, the bandwidth can be controlled through the use of the BITS GPOs in Active Directory. It’s important to note that BITS doesn’t require any kind of additional firewall ports to be open except for http/https. FlightDeck can also manage the number of files and total size of uploads to assist in managing bandwidth constraints.
If bandwidth is an issue, a local PST FlightDeck web service can be installed on the remote location on a small VM, or even a laptop, which can collect the PST files in the LAN. The collected files can then be shipped via shippable media (e.g. encrypted USB Drive) to the central datacenter.
In our next post, we move to the processing phase of our approach to PST migration.
If you missed Part 1, you can find it here.