Ingesting PSTs: WAN Connected Sites in Cached Mode
I've searched for this subject but couldn't find anything relatively recent (meaning newer than 2 years or so), so I'm posting anew in the hopes of getting some feedback WRT to the current (or upcoming...) version of EV.
We're looking to implement EV8 SP4 (or EV9, depending on required functionality), and our first project phase is to ingest PSTs across our enterprise and then prohibit further creation thereof. We have a central corporate HQ, and based on the testing I've done thus far the whole "Locate/Collect/Migrate" method should work for all users whose workstations and file/print server is local to the Archive and our Exchange Cluster.
However, we have about 80 sites located all across the country, and users at these sites do NOT have their own Exchange server. Their mailboxes reside on our Exchange cluster at our data center, they all run their Outlook in Cached mode, and each remote site has its own file/print server. We have a hub/spoke WAN architecture, and each remote site connects back to the HQ Data Center via 384K-768K lines, with a few topping out at 1.5MB. Getting the PSTs for these users into the EV archive (and presenting them back to the remote desktops) is a problem for which I've been unable to find an efficient (and officially supported) solution, which is why I'm posting here.
Based on a script that we ran across our enterprise, we'll have a total of about 12,000 PSTs totaling about 3 TB (that's TERABYTES with a 'T') in volume to get off of these remote servers and desktops (we have ~7 TB total PST data). We've got about 6000 total users, with only ~20% of those being local to our HQ. Suffice it to say we have a challenge in front of us. We're currently using Exchange 2003 & most clients have Outlook 2003 (all remote users are in cached mode).
Because of our limited bandwidth to/from these sites, I can't see the locate/migrate method being a very efficient model. For these remote sites we're considering the Virtual Vault or, some EV-managed cousin (via EVPM or similar) to Managed Folders (because our Exchange/Outlook version doesn't currently support them).
I've been working with our Symantec reps on this, and the only thing I've had presented to me is this:
1. Get the Outlook Add-in installed on user desktops & Mark the PSTs.
2. Run a successful 'Post-PST-Marking' Puredisk backup (our current process/tool for remote site backups) or copy all marked PSTs to an external HD and physically ship it back to our data center.
3. Stamp all remote PSTs as read-only and prohibit further creation in user Outlook profiles. Stop all further backups of PSTs.
4. Restore COPIES of remote PSTs to alternate location and ingest using the 'PST Migration Wizard'
5. Once ingested, await shortcut replication back to remote desktop & Outlook Profile
Here is where I have a huge problem with this:
My testing showed that by default no action will have been taken by EV components on the 'original' PSTs as found/marked in each user's mailbox. Thus, after the above process completes a duplicate PST/Archived-PST folder structure will be created. Since we're migrating COPIES of PSTs (albeit marked ones) the 'post-migration' action as set in the Wizard is taken on the COPY of the PST, not the original PST. The Outlook Client Add-In isn’t smart enough to distinguish the archived PSTs ingested via the ‘PureDisk-Assisted’ (or any other Wizard-based) method from the ‘original’ PSTs. I can’t see how it should be, as what we’re doing is manually populating the mailbox archive with data from a completely different location than where it originally existed. We can’t expect the client to do things it isn’t designed to do, and this (IMHO) is definitely beyond its design. So what’s the workaround? How do we do this, track it, and (most importantly) make it easy for our users? I can’t see this process working at all for our remote sites without a solution for this. An efficient method MUST be developed to get rid of the original PST file pointers in users' Outlook Profiles as well as their actual physical existence on the desktops/servers. Otherwise, users will have duplicate PSTs or some period where their PST data is simply unavailable until the replication of the stubbed PST data back to their cached mailboxes has completed. If this were a LAN environment this problem wouldn't exist, but because we're in a WAN situation with these sites I'm stuck with it.
As I see it, the primary pain points with this approach would be:
1. Bandwidth Saturation over the WAN links, impacting all services to/from the sites
2. The excruciatingly long amount of time that this would take to complete
3. User resistance, complaints, and lack of access to their PST data
Symantec staff first provided me with this approach/solution, but when I posed the question to multiple staff as to whether the above is an OFFICIALLY supported Symantec solution, all I heard were crickets... I haven't heard anything besides "we're checking with our product team". If anyone can comment on this aspect it would be appreciated.
If there's a Best Practices doc out there somewhere I'd welcome that (mention was made of such in a post that was several years old).
We're also considering an Exchange 2010 upgrade (skipping Exch 2007), but of course I know all about the issues with that. No EV support until EV 9.0, and then only with Exchange 2010 SP1 (I hope), and most people are aware of the quagmire that exists with EV and Outlook 2010 (we'll be lucky to see that by end of CY 2010).
Any all help/comments/recommendations are encouraged.