PST migration on the field experience

[Maxie_Braggs]

Gentelmen,

we are in the process of implimenting EV 9 for a large customer.

We know there are methods like, Client driven,server driven etc that assist with PST migration with their advanatages and disadvantages.

In a scenarion where EV servers located in a centralised site and users connected over WAN links(some are slow, some are good).

In this scenario, where I have migrate a large number of users to the central archive..i initially though would go with the client driven appraoch for its ease of use and other featiures such as it migrates the user pst's when the users are connected and prompts for PSt password if the PST is password protected.

But customer already has EV 7 and 8 implimented in couple of places and when i enquired about the best practices and lessons learnt during the PST migration in the past, they mentioned that they initially opted for client driven appraoch but found that to be unreliable for reasons such as users connected over slow WAN links etc.and the method most of the regions adopted is "copy the user PST's to a central location such as file server and migrate them from that place to the central archive".

What are your thoughts, as which method somebody prefer for PST migrations? tips/any lessons learnt from the past PST migration experience..pls share.. have a good week end..

Best regards,

Maxie

[JesusWept3]

the slow connection is the exact reason why you would use client driven though

[WiTSend · Accepted solution]

I'm still a big fan of the client-driven migration.  It solves many problems, runs fairly automatically, provides for minimal user and admin disruption and cleans up after itself.

Copying PSTs and shipping, importing, telling the user to stop using the old one, etc... this is a very admin and user intensive process.

My 2 cents...  Use client-driven migration understanding that you have the 80/20 rule.  80% will be handled quietly and efficiently, 20% will require some hands on to finish the project.

[AndrewB]

no sense in me writing the same thing that's already been said twice. +1 for JW and +1 for maxwits.

[Adam_Spiteri]

Where are the PST files located? We originally tried the client-driven method for the reasons already listed, but after a couple of weeks a very small number of the files were imported successfully. We ended up with a lot of end user interaction with the process and disruptions, exactly what we wanted to avoid.

My PST files are located in just a few locations on servers and I find the locate and migrage method is much more reliable. Yes we do have to notify people that their PST files will be unavailable while they are migrated, but this is less intrusive than having them restart the migrations and not know exactly where mail is while days go by waiting for the migration to finally succceed.

[Maxie_Braggs]

Thanks guys for the inputs..some of you feel client driven appraoch would be good..the last post from Adam says client driven did not help..

So, is it a combination of methods that could be followed..say for Ex: start with Client driven(80-20 rule), if effective follow the same else switch to other method such as centralised appraoch or server driven etc..what you say?

[Fisker]

Client driven does work, the issue is that the due to network issues (Often happenin on WAN) the packets ID get out of Sync - and the Client driven migraiotn stops, and "repairing" is still not easy as you need to get to the client.

If you have large amount of data +(1-2)TB - then I would look at alternative way's of doing this, if less -  then the 80/20 may not be a bad solution, will take some "sneakers" running around and fixing the issues, as you cannot say which ones will fail...

In any case update to the latest SP - as the newer versions have become a lot better at handling ingestions..

You may want to look at the whitepaper under www.glasshouse.com "Guide to PST Migration Testing"

[Maxie_Braggs]

Thanks Fisker and all..

I will go through the doc.Thanks for all the inputs..

[Maxie_Braggs]

thanks all for the valuble inputs..