Issue link: https://epubs.iltanet.org/i/50188
finds and incorporates existing PST files or manages the content within them. Some firms or corporations are content to live with PST files, provided they know that all the files are safely stored in a single location. Recently, however, more organizations are opting to eliminate these files. The larger mailbox capacity offered by Exchange 2010 is enabling this approach, but the idea of elimination is also being driven by an increasing awareness by attorneys of the challenges and risks that PST files present. There are many technology challenges related to doing away with PST files, and these are complicated by the fact that there is no single standard methodology to follow. The file complexities, multitude of destinations, as well as the steps necessary to remove these files require the use of advanced technology and, thus, a serious commitment from the IT department. So what are the best steps to take when conducting a PST project? PHASE ONE: DETERMINE THE SCOPE The biggest challenge facing any organization undertaking a PST project is understanding the scope of the problem. It's important to know how many PST files exist, where they reside, how much relevant data they contain and whether it is necessary to archive everything. These are all questions that need to be answered before other parameters of the project can be determined. Calculating the number of PST files may be a challenge, but there are some tips to help. A good rule of thumb is to assume an average of three per active user, but that number is related to the extent of the mailbox quota. If mailbox quotas have been aggressive, there will likely be a higher number of PST files. For limited quotas (approximately 100MB), there may be five or more PST files per active user. It is also important to consider inactive users who may still have PST files sitting on a file-share or server, effectively with no owner and no current mailbox with which the data can be associated. If an accurate count related to staff turnover is not available, a sizeable percentage should be added to account for former users. The size of PST files is also related to the limits of users' mailbox quotas. If these quotas aren't particularly aggressive, for example, one could assume 500MB per PST. For aggressive quotas, the assumption should be 1GB. Although Outlook 2003 had limits of 2GB (before corruption) on PST files, later versions allow PST sizes of 10GB or more. This provides a sense of the amount of data that may be part of the project. For instance, a 20,000-user organization could have 60,000 PST files scattered around the network and on laptops and desktops. This would suggest an initial estimate of 30TB to 100TB of data before adding a percentage for former employees. The outcome of this phase should be a detailed list of all PST files in the organization, so you need to go a step beyond calculating the number and size. To truly understand the scope of the project, gather detailed information such as filename, server/workstation, who the owner is and more. There are a number of simple tools and scripts available that will list file names and their sizes on disk, but these are limited and do not provide enough information to effectively scope the project. Compiling the data allows for a much more accurate projection of time scale and network loading. www.iltanet.org Tech Potpourri 39 ad hoc