Video Screencast Help

Shouldn't I run the PST Collector and Migrator after hours?

Created: 11 Nov 2013 • Updated: 01 Dec 2013 | 6 comments
This issue has been solved. See solution.

I'm running EV 9.0.4 R1 on the server and on the Outlook add-in side.  I've been working through some tests of the PST migration process.  The admin guide says to run each task (Locator, Collector, Migrator) during business hours.  I can see running the Locator during the day to hit as many active computers as possible, but in my tests of Collecting and Migrating, it seems best to run these two tasks after hours when the users are not in Outlook.

We're going with the Server driven model and searching the registry for this first phase.  We can't collect any PSTs during the day if the user still has them open in Outlook.  It seems best to let targeted users know when their PST(s) are going to be migrated and run those tasks over night.

I guess we could ask people to close the PST files during the day as well. 

How have those of you that have done larger migrations scheduled the collection and migration tasks?

Any advice is greatly appreciated!

Operating Systems:

Comments 6 CommentsJump to latest comment

Rob.Wilcox's picture

Well if your users are all laptop based, for example, and they take their laptop home, you'll have a hard job pulling files from their machines.

If they're desk based warriors and leave their machines on overnight (oohh, environmental impact, anyone?) then yes you can pull the files overnight.

RhoSysAdmin's picture

I understand that I'll miss some people overnight.  But if I migrate during the day, I'll need to have them close the PST file out of their Outlook, correct?  I guess I'm trying to make sure I haven't been doing something wrong.  The collector task isn't able to copy anything that's actively open in Outlook, correct?  It hasn't been able to in my tests.

And the Collector task will flag the PST read only when it tries to grab it to prevent the user from altering it while it's copied to the holding area and migrated.  So for those we process during the day, I'll need to let them know that their PST(s) will be unavailable until they magically appear in the "Migrated PSTs" folder (or whatever I end up naming it).

I realize I could go w/ the client driven model, but that didn't sound good, especially for our users with obscenely big PST files.

Am I on the right track?

Rob.Wilcox's picture

I am of course a little biased, but really, the requirements you're describe fit perfectly with PST FlightDeck

RhoSysAdmin's picture

I'm set for now.  We're going to coordinate with end users for the first couple rounds of collecting PST's and do the collection/migration during the day w/ the Server driven model.