Microsoft have announced their ‘PST Capture Tool’ in the past few days, which is a great step forward. They finally understand and acknowledge what email administrators have known for years – that PST files are evil.
It seems that this tool is/was the old RedGate tool which has been sold to Microsoft, revamped a little, had some testing and has been made available as a free download. Redgate were not in the messaging space very long, quickly withdrawing their archiving tool a few months after its release and now getting rid of their PST tool.
We have been dealing with PST importing and management projects for many years, so I was keen to see how far Microsoft had gone to help customer get a grip on PSTs.
Unfortunately it is one of those cases where ‘you get what you pay for’.
I’m sure a lot of this will come out in blogs and messaging articles over the coming days, but even a cursory look unveils a number of significant limitations. Here’s the top 5 in my opinion:
- Client Software Install – although it is only a shade over half a megabyte, it installs Windows services and needs a few bits of custom configurations (host server name and port). This approach doesn’t scale at all well. Maybe for 50 users, you might be able to visit all their desktops and get it installed, but not for a few hundred, never mind 50,000 users.
- PST Ownership – the data reported back on each PST file found is sparse at best, but it does include the (NTFS) ‘file owner’. The only ‘semi automated’ way of assigning ownership of a PST (and therefore which mailbox it gets ingested into) is to ‘use the file owner’. Unfortunately most PSTs are showing up with ‘BUILTINAdministrators’ as the owner, so it’s a case of manual assignment (selecting from the Global Address List) – again not feasible for more than a few tens of PSTs, never mind hundreds of thousands of PSTs
- Locked PST Files – most users have PST files open in their Outlook profile. It seems that the PST Capture Tool cannot process those because Outlook has a lock on them. Realistically this means the migration can only happen when users do not have Outlook open.
- Disconnecting / Deleting PSTs – this is going to be a really confusing one for the end users, when a migration is completed, the original PST is not removed from the Outlook profile or deleted, so users end up with all their PST content in their mailbox as well as the PSTs file still connected in Outlook. It would have been better to automatically remove these (at least from the profile, if not from disk also) when the file has been migrated.
- ‘Other’ PST Types – this is one that we came across a few years back – if a user adds a ‘SharePoint List’ or an ‘Internet Calendar’ to their Outlook profile then those are stored, under the covers, as PSTs. It seems this tool also imports the data from those. Migrate that data and it gets regenerated in the PST again and presumably imported again, later when it should not have been pulled in, in the first instance.
In summary, it is a good tool, if you are looking to go through a small scale migration of data, a handful of users, or a few tens of PSTs. Anything larger, in the hundreds, thousands or, as in one project we are running, millions of PSTs will require more control and a better thought through solution.
The key aspect of these larger projects is network bandwidth, in fact I believe this is where these projects will either succeed or fail. Customers are not taking the prospect of moving 600+TB of data over their networks lightly.
I believe there are some key limitations in the way the PST Capture Tool moves the data, but I’ll cover that in a future article. In the meantime, if you are having problems with PSTs and have found that the PST Capture Tool doesn’t meet your needs then have a look at our PST Enterprise solution, it’s the summation of years of experience, challenging, large scale environments and ironing out all those gotchas listed above (as well as many more)