Having read Brien's previous article describing PST Horror Stories, you should now be well aware of the dangerous pitfalls of rogue and unmanaged PST files. Thankfully, 3rd party tools offer us a painless away to entirely avoid these problems, as Brien now explains.
Although they once had their place, PST files can be the bane of any Exchange Administrator’s existence. They are difficult to manage, and their use greatly increases the chances of data loss. When you also consider that PST file use may impact regulatory compliance, it is easy to see why so many organizations are taking steps to eliminate their use. In this article, I will explain some of the reasons why PST usage can be so problematic, and I’ll discuss some methods for merging PST data into a user’s mailbox (some of which have no doubt been covered here & elsewhere, but this will present a broad-spectrum overview).
The Trouble with PSTs
As I already hinted, PSTs have their place, but can be problematic for the organizations that use them. In the majority of the cases that I have seen, PST files are used as a mechanism for circumventing mailbox quotas; if users want to keep more messages than a quota allows, then they can simply move the excess messages to a PST file, where they are outside of the administrator’s control.
Of course PST’s aren’t always used as a mechanism for circumventing administrative controls; they do have some legitimate uses. For instance, I recently read about one method for migrating public folder data to SharePoint 2010 that involved the use of PST files.
However, if PST files are primarily used as a repository for end user data then one has to question how valuable PST data really is. If an organization has a mailbox quota structure in place that forces users to delete all but the most important messages, then some administrators may assume that there is nothing within the PST files that would be of any benefit to the organization. This seems like reasonably sound logic on the face of it, though naturally not without it’s caveats, which I’m not going to delve into here. The problem with this philosophy is that some users may move all of their messages to a PST file and keep nothing in their mailbox. In situations like these, one cannot assume that there is no important data in the PST file, because it will most likely contain a mixture of important and unimportant information.
So why not just allow users to continue using PST files? Several reasons, actually. The biggest problem with PST files is that they are usually located on the user’s local hard drives, and are therefore never backed up. Indeed, even though PST files can be placed onto a network share, doing so violates Microsoft’s best practices and, more importantly, increases the chances of data corruption.
Another obvious problem with allowing PST files is that their use can lead to data theft. In situations where users are storing their messages in local PST files, anybody who has physical access to users’ computers could easily copy PST files onto removable media, and then open the files on another computer. While it’s true that the security risks can be reduced by simple steps such as encrypting workstations’ hard drives, many organizations do not take such precautions. I’m not even going to dwell on password-protecting PSTs, as there are plenty of free cracking tools available, and Microsoft themselves have acknowledged that the password protection is pretty weak.
Last but certainly not least, the use of PSTs as a method of data storage may lead to regulatory issues. In the United States, there are several different sets of regulations mandating that certain types of data be secured in specific ways. If messages containing sensitive data were moved to a PST file on a user’s local computer, it would almost certainly put the organization into a non-compliant state.
On the same note, some organizations configure default mailbox and custom mailbox folders with message retention policies, which allow messages to be kept for the legally required amount of time, and then disposed of according to company policy. Moving a message to a PST file circumvents any retention policies that may be in place, and may put the organization at risk legally.
This all boils down to one simple message: Exchange data should ideally be kept in Exchange, not PSTs. Moreover, any PSTs lurching on hard drives or shared drives should be imported back into Exchange so that their data payload can be properly managed. If space is an issue, then older messages can be archived, but exporting messages to PSTs is a foolhardy method for keeping your Exchange server a lean, mean machine.
Mailbox Quotas
If you’re still reading this, you presumably agree with the sentiment just expressed. At the very least, you are willing (I hope) to be convinced. However, before you rush off to import PST files with merry abandon, a word of caution: Regardless of the method that you are planning on using to import PST files into Exchange, special care must be taken to ensure that any existing mailbox quotas are large enough to accommodate the inbound data. Otherwise, the import process will likely fail for some mailboxes. It might seem like a trivial point to raise, but experience has taught me that it’s a point that occasionally needs reiterating.
How PST Importer Can Help
Red Gate Recently introduced a new product called PST Importer 2010 which, as the name suggests, is designed to import PST data into Exchange Server with no mess and no fuss. Of course, I realize that right now many of you might be wondering why you should bother using a third party tool for such a seemingly simple task. To be quite frank, you should use a third-party tool because Microsoft just doesn’t give you any other good tool for importing PST data.
Keep in mind that I’m not saying that Microsoft doesn’t give you any tools for importing PST data; it’s just that their process can be quite complex if you use the built-in tools and suggested methods, and the PST Importer is designed to make this process much easier.
Locating PST Files
So what is it about importing PST data that makes it such a challenge? Well, there are several steps involved in the task, each with their own hurdles, and the first involves actually locating the PST files that you want to import. These files are usually scattered among the users’ workstations and network shared drives. Unfortunately, Microsoft doesn’t provide you with any native Windows tools that can inventory all of the workstations on your network and produce a report detailing the locations of all of the PST files.
When working to find a non-third-party solution to this puzzle, fellow technical author James Allison developed a pair of WMI scripts that can search the network for PST files, and then create a CSV file detailing the network paths of each file. While I have no doubts that the script works, it requires administrators to open Port 135 on all of the machines they wish to search. This port is blocked by default by Windows Firewall because of the long history of malware exploits that rely upon accessing it. In addition, the script does not support NAT traversal, which may be an issue for some organizations.
With that in mind, I want to talk about how PST Importer 2010 locates PST files, and why it is a superior solution to the manual, WMI-scripting process. Before I do though, I wish to point out that I am in no way trying to discredit James Allison or his scripts, and I will be the first in line to say that he’s done a great service by providing a free alternative for those organizations that are unable to invest in a third party solution. Even so, I want to highlight the advantages of using a commercial solution over the free one, because I believe that they are worthy of your consideration.
To start with, PST Importer 2010 does not require Exchange Administrators to run complex scripts, nor do they have to open Port 135 on their firewalls. Instead, administrators must simply deploy an agent to the target machines, which facilitates the PST inventory and collection process.
Once the agents have been deployed, administrators can immediately begin searching computers for PST files. The process for doing so is simple, and merely involves selecting check boxes corresponding to the computers that need to be inventoried. Once the computers to be inventoried have been selected, the next step is to schedule the PST search , which will allow the PST information to be collected at a time when it will not interfere with user productivity.
Identifying Who the PST Files Belong To
Of course, locating the PST files that exist on the computers in your organization is only the first step in the process. The next step involves trying to identify which PST files belongs to which users. The scripts that I discussed earlier are designed to make note of each PST file’s owner and the file’s location (which will also usually reference the owner), and while this information should provide a reliable method of identifying who each PST file belongs to, it is ultimately up to the administrator to confirm each PST file’s owner.
PST Importer 2010 uses similar information to determine the owner of each PST file, but it does so automatically, and so the administrator is saved from the task of manually verifying each PST file’s owner.
Before you actually begin importing PST data, I recommend that you take some time to educate the users about what you are doing. Otherwise, you can be sure that your helpdesk will receive lots of calls from confused users after the PST files have been imported.
Importing PST Data
The next step is the actual import process. Those of you who are performing the import without the aid of third party software can accomplish the task through the use of Exchange Management Shell commands or PowerShell scripts. However, if you’re not so confident in your scripting skills, or if you just don’t want the hassle, then the import process is a lot simpler with PST Importer 2010, because no command line interaction is required.
Before you can perform the import process using PST Importer 2010, you must determine what types of PST data you want to import into Exchange Server; the PST Importer will always import mail items, but you must decide if you want to import calendar items as well. The tool also contains an option for importing non-mail items such as contacts, tasks, and notes.
Once the PST files on your network have been discovered, the PST Importer uses the associated profile information to determine which Exchange Server mailbox to import each PST file into. The import process itself is performed automatically, and in a way that preserves any folder structures that were set up within the PST file (). You can import the PST items to either the user’s primary Inbox folder, or you can place the imported items into a newly created subfolder as a way of keeping the items isolated from any data that already exists in the user’s Inbox.
The Aftermath
Regardless of whether you use EMS commands or a tool such as PST importer, you are likely to discover that some PST files were not imported successfully. There are several different factors that can cause this.
To troubleshoot these failed imports, start by making sure that the computer containing the PST files was turned on when the import was attempted. If the computer is (or was) off, then the PST file will obviously have been inaccessible.
Another thing to check is that the user who owns the PST file did not have Outlook open at the time of the import, because if Outlook was open (and it had the PST file held open) then the import process will have failed.
You should also talk to the user and verify that the PST file is not password protected. If you find that a PST file is password protected and you cannot get the password then, as mentioned earlier (admittedly in a slightly different context), there are a number of cracking utilities freely available on the Internet.
Finally, it could be that the import failed because the PST file itself was corrupt. You can use the Inbox Repair Tool or any of the third party PST repair tools to try to correct the problem, but you should back up the PST file before you do so, as using these tools can lead to data loss.
Conclusion
As you can see, PST data can be imported into Exchange Server 2010 either manually, or through the use of third party utilities such as PST Importer 2010. Either method will work, and both share a few challenges (although these are more a result of working with PST files than the methods themselves). However, the PST Importer 2010 makes the process of locating, identifying, and importing PST data much easier.
This article was commissioned by Red Gate Software, engineers of ingeniously simple tools for optimizing your Exchange email environment. To download your 14 day free trial of the PST Importer 2010 visit the Red Gate site.
