Lower the retry intervall on collector and migrator tasks

[Tobbe]

Hi.

I'm trying to push forward in a large PST migration. One of my isses is that when the collector task tries to collect a PST the very first thing it does is to put it in read-only mode. If it then, as step two, fails to copy the file it leaves it in read-only until next retry which is at the earliest 24 hours later.

I would like lto ower the retry intervall but the smallest value that can be entered through the GUI is once/day. This means that it will not even try to recollect it at the other half of the day which might very well be off business hours for parts of the users.

I know that this can be tampered with by changing datevalues in SQL but that really seems more like a move that I can see my self doing in a lab environment and not at a live system.

So is there, besides the SQL trick, any way to force EV to retry a failed collect more frequently and in the best of worlds, a possibility to trigger individual PST files with a "RUN NOW" command regardless of time the last attempt to collect it was made?

Finally, we are not using client driven migrations due to the fact that you cannot limit the shortcut creation by the date on the item being migrated. That functionality is limited to server based migrations for reasons unknown to me...

[MichelZ]

Unfortunately, this is the only way I know of.

You could open a support case with SYMC, and get their "approval" for this, which should get you confident to runin t on a Live system.

Setting back the Date in SQL is not really a big deal, I think.

There is no "run now" command, either :(

That's an interesting point with the client driven migration.

Are you sure that it does not obey the Policy rules in client driven migration?

Never tried this, but from my point of view it should work the same.

Regards

Michel

[Tobbe]

Thanks for the reply Michel.

I really can't recall where I got the info that claimed that clientdriven migration can't create shortcuts selectively and I've been taken that as a fact for quite som time.

Now that you point this out I've been trying to find that info again but the more I look, the more it seems that my statement is incorrect.

It should indeed follow the migration policy settings, so I do beleive that we will reintroduce the push method into this migration.

Regarding editing the SQL I've done it before and you are right, it is not complicated, but it does generate alot of events if you for instance still have a locatortask running since it will try to write duplicates into the SQL table.  

Also, in this scenario the SQL servers are being handled by a different set of administrators so in order to process some PST files on a daily basis the adminstration involved would have to include EV admins, SQL admins and the actuall endusers all synchronized.

Thats a bit too steep, compared to the much wanted "run now" button

Again - Thanks for you time and help. Now I'm off to verify that clientdriven actually does limit its shortcut creations.