Many people use Enterprise Vault to finally remove the thousands of PST files from their messaging environment. One thing to consider if you go into this area in any detail, and for any sort of medium to large scale of implementation is what to do with the PST Holding Area folder. In fact you should take note of the information in this article whatever the size of the Enterprise Vault environment, as it will help show that you shouldn't just take even the small things at face value.
The question is "Where should the PST Holding Area reside?"
In this article I'll describe three possible ways of siting the PST Holding Area folder in your environment.
As-is, just on one Enterprise Vault Server
This is the simplest approach that can be taken and is actually not as bad as you might think. When you are configuring the PST related tasks on the Enterprise Vault server you are quite often suddenly presented with a dialog saying you need to set the PST Holding Area on the site properties before you continue. So quick as a flash, you create a folder on the Enterprise Vault server, share it out, and put that down on the site properties. The immediate problem is then solved, and whatever you were configuring when you got the pop-up dialog will now let you continue, and your PST migrations can actually begin.
In small to medium environment this actually works out quite well. Your migrations are usually taking place outside of any kind of normal archiving window, and the tasks themselves also have the ability to throttle based on the number of threads, so you won't be placing too much additional load on the Enterprise Vault server.
The question comes though as to what happens if there is more than one Enterprise Vault server. In this situation, the tasks on the second server will use the PST Holding Area on the first server. Again this usually isn't a problem either. The first server is going to incur a small increase in the overall load placed on it, but again normally this isn't too much of problem.
If you want to have the same sorts of load across a number of servers though, or your environment is much larger, then you might consider the next option...
Using some sort of network attached storage device is often the route that administrators take for storage, especially with the promise of 'near limitless' space. After all it is sometimes difficult to deduce exactly how much space will be required to migrate the PSTs that are distributed across a wide environment. This means it can be a bad idea to have the PST Holding Area folder co-located with your Enterprise Vault. But with a NAS, the PST Holding Area on the site properties will be a specific share on the a remote device. The device, of course, can be shared with other applications too; it doesn't need to be exclusively for PST migrations. Also with this approach no additional disk I/O is added to any of the Enterprise Vault servers in the environment. This means that the Enterprise Vault servers can be more gamely employed in actually doing the migration of the data, rather than hosting it, and serving it up to either itself, or to other Enterprise Vault servers in the environment. There is a small downside in that it is going to increase the network traffic because the server does have to go and get the data from the NAS.
The biggest issue that these approaches don't cater for is what happens in a single site environment where the Enterprise Vault servers are in different cities, or different countries? They might still be well connected, in networking terms. A fast link might exist between the locations, which is why the machines have ended up in the same Enterprise Vault site, but you as the administrator don't want all the PST traffic flying over WAN links.
The issue here is that the PST Holding Area is a site wide property. One solution to this is hostname mapping as we see in the next section.
Hostname mapping tries to address the situation where the PST Holding Area would ideally be best suited to be 'local' to the Enterprise Vault server - wherever that server is. So if you have a server in Manchester and a server in London, you really want a 'fake' or 'virtual' host that each server can then resolve more locally, perhaps even to themselves, or a local NAS device.
For the purposes of this article let's assume that we want the holding area for our machines in Manchester and in London to be local to the Enterprise Vault server. In order to do that we could:
1. Create a folder on a drive on each server, let's call it PSTs.
2. Share the folder out.
3. Apply two specific registry keys (see below) to each server.
4. Pick a fake/virtual name, let's say we decide on PSTSrv.
5. Add a hosts file entry on each Enterprise Vault server so that PSTSrv resolves to the local machines IP address
With these in place it means that we can edit the site properties and change the holding area to \\PSTsrv\PSTs. We can then test on each server what happens if we browse to that UNC, and even create a small text file. You will be able to see the text file from the machine you create it on, but not from the other machine. It's actually quite spooky when you first do it! However it's not spooky or magical, and it does work.
The registry keys that need to be set are:
The machines need to be restarted when the keys have been added.
These allow you to browse network shares and hosts via an alias, which is effectively what we've done in the preceding steps. So for this situation it solves things quite nicely. The PST Holding Area folder specified at the Enterprise Vault site level is resolved to a 'local' share, and migrations can happen like this - no problem.
As you can see there are a number of different options which are available when designing and implementing this particular aspect of Enterprise Vault. Which option you choose, and even whether you go with a different option is down to you, and the team that is going to work on the environment. Do you use one of these methods, or a different solution altogether? Let me know in the comments...