Product: PST Enterprise
Product Homepage: Click here
Cleaning up PST files
Small mailbox quotas have for many years meant that without a proper archiving solution, many organizations have allowed end-users to configure auto-archiving features or export older email to PST files. These are often located on end-user PCs, network shares or just about anywhere. This data can be difficult to discover, and especially when it comes to data from shared mailboxes – even harder to assign to the original owner.
After moving to Office 365 you may now find that with 50GB quotas, it makes a lot of sense to begin a project to migrate data back into either the user’s primary mailbox or online archive. One problem with either leaving users to move data, or some other solutions on the market is making sure you get the right data, making sure that only relevant data is moved and have a means to audit data migrated.
Deployment and Configuration
PST Enterprise fits into the type of product that you don’t typically deploy yourself and instead, after providing hardware that meets Barracuda’s requirements, let them install as part of a guided deployment and configuration exercise.
For many do-it-yourself administrators this might not be great and of course it makes it harder to deploy as part of a simple trial. As a reviewer, this meant that it was a little easier than usual to get my hands on a fully configured environment as C2C provide ready-to-go demo environments that are accessible over the web.
The deployment itself is fairly straightforward though and from what I can gather from discussions with C2C (and bear in mind every customer may be different), getting the software setup and installed is usually done on a single day, with additional time used to set-up discover tasks, help train the project team or Exchange administrators and properly configure the environment to meet complex requirements.
The base deployment for PST Enterprise is focused around a single central server. This has two main web services – the administrator portal and self-service portal that’s optionally available to end-users. The central server is used primarily to configure how migrations operate, provide reporting capabilities, define policies and assign PSTs to users.
Alongside the central server, PST Enterprise runs on end-user workstations and/or an administrative workstation. Rather than run as a service with complex requirements, the client side for PST Enterprise has no special requirements, and doesn’t even need .NET – let alone a special version.
Options for PST Migration
PST Enterprise provides a number of options for moving PSTs into Exchange, which appears aimed primarily at meeting the needs of medium to large enterprises.
How the product works
The product is based on a client-server model, rather than a server-agent model. What does that mean? Well, some other products work by forcing the administrator to install agents on each individual client, which run as a service, and the central admin console reaches out to each client over the network. In contrast PST Enterprise runs as a client-side application, typically launched via a login script or executed using tools like SCCM. Each client reaches out to the central server and asks the server for instructions on a regular basis.
A client-server method makes a lot more sense than agent-based solutions as it ensures that you only need to make sure the clients can see the server on HTTP/S ports, which potentially means you could reach remote clients using PST Enterprise, even if they don’t use a VPN connection.
The primary function of the server is effectively command and control. Clients report into the central server and their actions are reported centrally and can follow pre-defined policies. As PST files are discovered on clients, an administrator can define the criteria that will be used to map these to individual users and then apply default policies. The workflow for the policies can be set to automatically import data into Exchange, or leave some options open, such as to allow end-users to categorise PST files based on what they know about their old content.
Figure 1: Viewing assigned PSTs in PST Enterprise’s Admin Website
Distributed PST Migration
A primary benefit of PST Enterprise is its ability to distribute the process of uploading PST data into Exchange. The idea behind PST Enterprise is that the client that created the PST will be responsible for uploading the data. This means that the client that runs the PST Enterprise client requires Outlook installed, and will use it as the mechanism for the data re-import.
Based on policies it could perform a number of steps, such as removing the ability to modify the data from an end user, re-attaching and importing data into the local OST, waiting for and logging upload process and then detaching and deleting the PST.
The primary benefit of this approach is that it appears to require less effort on behalf of the administrator and central servers. Data is uploaded to Exchange using Outlook so it requires no special firewall rules or permissions.
I can see this would be particularly useful in a global organization, where moving data through central servers would be a painful bottleneck. This approach allows Outlook to do what it does best, and sync the data up in its own time. To ensure that errors on upload (for example, oversized items failing to upload) logs can be generated after successful import so these problems can be investigated.
Centralised PST Migration and Moves
Of course, the distributed approach isn’t suitable for all use cases. It might be that other solutions with server-centric models work better for some organizations, particularly those where bandwidth is limited at sites. PST Enterprise has two features that when combined, provide a solid solution. PST files can be migrated centrally using a number of methods, including BITS, which means that if you do have users on slower or unreliable links you can trickle-feed the data server-side in the background.
Once the PST data has been transported centrally and removed from clients, the PST Enterprise client can run as an admin user that has been granted permission to multiple mailboxes. Using the same PST to user matching and policies that run when the clients are distributed, the client will use Outlook to push data to the associated mailbox. Naturally it would be nice if the PST Enterprise server did this rather than relied on Outlook on an admin workstation, but to be honest I would sooner C2C focused, as they have done, on using a single reliable method.
Policy Based Migration
The driver for migrations performed using PST Enterprise are policies. The idea behind these policies is that clients and PST files can have policies assigned to them, or just use default policies.
A client configuration policy may define, for example, how long after login PST Enterprise should begin to process PST data, and how it should report to the PST Enterprise Server:
Figure 2: Client Configuration
A PST policy defines aspects relating to the mailbox data that is found, and what to do with the data found – such as whether to migrate data older than a certain age:
Figure 3: Managing PST Policies
Self-Service Migration
A feature provided by PST Enterprise that helps it to stand out from the (rather small) crowd is the self-service migration options available to end-users.
Figure 4: An end-user choosing the policy for their PST files
Initially you may be sceptical that users will want to do anything themselves with PSTs, after all it’s often end-users who created the PSTs and left them in the first place. The primary user case – and one that users will want to be involved in – is when deciding what data to keep or delete. For example, you may choose to say that older PSTs will be deleted rather than imported, unless the user chooses otherwise by a certain date.
Overall functionality
The Outlook-based migration approach PST Enterprise uses feels simple, but it’s good to see it’s backed by what appears to be a solid reporting and migration engine. It’s not simply automating the Outlook client, as migrating doesn’t lock the Outlook client like a normal import does.
One aspect I wasn’t initially sure about was the client-side migration approach. The PST Enterprise client works in two parts – a background process and a monitor application. Both are typically launched via a login script.
Figure 5: Viewing imported data and manually opening the client monitor
The background process is, in a way, the core of PST Enterprise as it’s the part that does the migration work, downloading policies from the server and asking it what to do, then migrating data into the Outlook client for upload to Exchange or Exchange Online. Although it might seem like a simple approach, it’s effectively an approach that provides resilience, makes best use of available computing power, and takes advantage of existing bandwidth available to Outlook clients. While the option to install it as a service sounds helpful, it appears to have the major disadvantage that it might struggle to use resources the logged on user has access to, like Outlook, in the way it currently does.
Reporting of items in the environment as part of discovery, and those that are successfully migrated is built into the product. As effectively the data began as unmanaged, the chain-of-custody reporting that compliance archive migration products need isn’t strictly required here, however it’s important to be able to refer back and confirm that items were indeed imported into Exchange or Office 365 at a later date.
Figure 6: Viewing reporting data
The method PST Enterprise uses to detect PST owners is particularly clever. Having worked with products like this in the past, algorithms to detect owners usually include filename or file owner based matching, which can be pretty useless when it comes to Shared Mailboxes. PST Enterprise uses a different technique to match based on the most common recipient in the PST file, which can be tuned as necessary. This is more in-depth and must require more CPU to process but of course, the distributed approach makes this possible.
Figure 7: Configuration of the ownership assignment algorithm
Migrating PSTs via this distributed method isn’t an approach that seems suitable for all environments. It may be, for example, that Outlook 2013’s slider or Online Archives are in use to ensure the amount of data downloaded to the PST is kept to a minimum, and moving data to either Exchange via WAN links, or up to Office 365 during the working day may overwhelm existing network links.
In the area of centralised migrations, PST Enterprise is good – it excels in one area but feels lacking in another. The approaches on offer for first compacting PSTs, then the agent for migrating them using technologies including BITS and SMB are fantastic. It does feel like this engine should also be able to upload data into Exchange or Exchange Online, rather than rely on one or more centralised admin workstations that sit logged in and waiting to process data. However, this would not prevent me from recommending the product.
Figure 8: Viewing the configuration for central PST copy and moves
Support
Your first interaction with the product is likely to be via PST Enterprise’s support team who provide consultancy, product training and support. Because the product is installed and configured by C2C, this removes many of the typical reasons to contact support, and also meant that during the evaluation for the review we didn’t have reason to raise a support request. Having worked with customers who use C2C products and deal with the same support teams that provided our training and introduction session, it would be fair to say the support is more than adequate and over the course of the project customers remain on a first-name basis with their contacts in the C2C support teams.
How it compares to the competition
When a product’s primary competition is a free product it means the product has to do something different and special to be worthy of even considering. PST Enterprise fits into that category, as although there are paid-for products from a few other vendors, it has to compete with Microsoft’s PST Capture Tool 2.0. This was acquired from Red Gate Software as a fully developed product, but it takes a different approach and lacks all of the reporting features in PST Enterprise. In particular though the simple requirements of PST Enterprise’s client make it worthwhile; it does not require deployment of additional software or configuration of firewalls and makes use of the client’s install of Outlook rather than requiring a variety of very specific software versions installed on the server. We would expect most projects aiming to migrate PST content into Exchange to find much better ROI versus using free products due to these benefits – not to mention the self-service, policies and reporting features.
Final Thoughts
PST Enterprise has a hard act to follow when there are free products on the market claiming to provide similar functionality, however real-world experience with the drawbacks of Microsoft’s free PST Capture Tool and the multitude of additional features – and distributed migration approach – make PST Enterprise a product that should be top of your list for evaluation.
MSExchange.org Rating 4.8/5
Learn more about PST Enterprise
