4 Top Reasons PST Migration Projects Fail
1. You can’t get hold of the critters…
Although some organizations have been diligent in centralizing all PST files onto file shares, working with PSTs over a network link is, in fact, unsupported by Microsoft.
By default, PST get written to the local drive, but savvy users can create and copy PSTs anywhere on the ‘c:’ drive, other partitioned drives, USB sticks, and external hard drives.
This means your first and most daunting challenge is actually tracking down PST files.
Then, even if you can locate them, getting a long-enough time-window to do anything about them can be tricky, especially in organizations that have a lot of laptop users that connect to the network intermittently.
Added to this is the fact that PSTs are designed to be accessed by just one application at a time, which means that if the user has Outlook open, any other background application designed to capture PSTs can’t usually access them.
In the face of such adversity, sometimes a technical approach can’t beat a pragmatic approach. For example, a large pharmaceutical company we know ran a ‘PST collection day’ at their corporate team-building events, where road warriors were asked to drop their laptops in a tent on arrival for ‘frisking’.
This might work for some organizations, however, with the proper tooling to collect PSTs, these day are long gone.
A tiered architecture, ideally one where the elements requiring the most computing power are hosted in the cloud (such as Microsoft Azure), is going to be the way to go for those companies that fear the size and topology of their network and highly distributed aspect of their workforce will be a barrier to cleaning up PSTs.
With the heftier parts of the architecture hosted elsewhere, it only leaves minimal software footprint ‘Agents’ to be deployed to the locations that need scanning.