Problem Client driven pst migration

[mickelingon]

Hi

I've stumbled on a problem with client driven migration.

It works but not to 100%

Some have the status ready to copy but nothing happens and I can't manually change the status.

And some says migrating and has done so for a long time. a couple of them for 7 days.

Please advice

best regards

Mikael

Message Edited by mickelingon on 02-20-2008 01:36 AM

[mickelingon]

Hi

Seems lika it is the migrating part that is the issue.

I have set the number to 5 simultaniously migrations, but there are 8 in the VAC.

So I think 3 of them are hanging. And when I look at history and detail view nothing changes.

Here is a log of a pst file that still says migrating

And i can se the file ....38db in the pst holding folder. Is this one hanging. (the log says successfull?)

By the way, this migration started 2008-02-14

Migration of PST: \\LUNA\j$\user\AgBr\Outlookarkiv\Personliga mappar(1).pst

Migration Settings
------------------

Client-driven migration of part 38 of PST - the totals are the accumulated totals of all parts migrated so far
Migration Start Time: 2008-02-20 10:05:59
Migration End Time:   2008-02-20 10:06:28
Migration Copy File:  \\HYPERION\E$\PST Holding\Temp\pst387_38.db
Shortcut Mode:        Create shortcuts and move them to Exchange Mailbox

Include Deleted Items:              true
Set PST Hidden:                     true
Set PST Read-Only:                  true
Compact PST:                        false
Delete PST:                         false
Archive Non-Expired Calendar Items: true
Cancel Mailbox Auto-Archive:        true
Merge PST Folders:                  false

Migration Results
-----------------

Number of folders processed: 9
Number of items archived to vault: 2756 of 2841
    - Number of items not eligible for archiving: 85
Number of items moved to mailbox:  1691 of 1691
    - Number of archived items moved to mailbox: 1606
    - Number of other items moved to mailbox: 85

PST Migration completed successfully

any suggestions

Message Edited by mickelingon on 02-20-2008 04:18 AM

Message Edited by mickelingon on 02-20-2008 04:18 AM

[TonySterling]

hmm, that is a bit interesting.  If you haven't already I would have support take a look.

Please let us know what they say.  :)

[mickelingon]

Hi

I logged this as a case at Symantec, they responded quickly and I sent them a Dtrace and client log during a Client driven migration.

They said it could be a MAPI issue on the client.

I was asked to look if CDO was installed on the client and also check the mapisvc.inf and then run the fixmapi.exe.

This didn't help though

Anyone else having the same problem?

Mike

[MichelZ]

Mike

What exactly is the issue here?
In the log you posted, the bottom line says "PST Migration successful"... ?

Cheers
Michel

[mickelingon]

Hi

The problem beeing that the pst is only set to "ready to copoy" and is not migrating.

I can't change this and nothing happens.

The log is only to show the date, it was a long time ago.

This particulary user did start migrating.

I have a client log and a trace for this problem. But there is a lot of rows so I will not post it here.

Can I send it to you?

Mikael

[John_Chisari]

I actually think this is going OK - remember this is client driven migration - the migration relies on 2 things.

- The user have Outlook open.

- The PST Migrator schedule - if it's only running for a few hours a day - then this may be why it is so slow.

In client driven migration, chunks (10mb default) are sent to the EV server 1 at a time.  So it sends 1 chunk - and then the migrator migrates it (just as long as the Migrator is in schedule).  During this time the client continuously polls the EV server to see whether it has finished.  When the chunk has finished migrating - then the client will send across another 10mb chunk and so on.

So from that log - the client sent across 38 chunks of 10mb each and it took a week for it to happen.

[mickelingon]

Ok I hear you, but the problem is that this log is not relevant enymore.

I have this problem on 16 users out of 400.

And I can't get these to start, They are still set to "ready to copy" after one month. And have still not migrated.

Mikael

[MichelZ]

Mikael

Any chance those Users left the company, or aren't using Outlook regularly?

Cheers

Michel

[mickelingon]

Hi

No, they use their client on regular basis.

I've tried to regenerate the PST migration by deleting it from EV and.

Disable the user for Client driven migration and enable them again and then on the client press start PST search (or simular to it).

It then shows up again in EV but set to Ready to copy and doesn't start to migrate.

Thanks

Mikael

[John_Chisari]

I would suggest logging a case for this one - have your client log and IIS log from EV server ready to give to the tech for analysis.

[mickelingon]

Hi

Already done, but it's slow and there is no progress.
So I thought I would see if someone have had the same problem.

Mikael

[Shawn_R__Cordei]

We too are having a simular problem, and some others. We are not getting new pst migrations for a while now. They remain "ready to copy" in the files list. I opened a case with Symantec last Friday. Going into the 3rd working day and still having heard anything from them.

The other problem could be related. We have never had more than 2 simultanious pst migrations with CBM. Now that the last 2 have finally been migrated, no more psts are being migrated at all. The settings for the migration tast is to limit 10 simultanious pst migs.

Any ideas?

[Skelly]

Did you get a solution to this issue. We have a similar problem, 3 client driven migrations stuck on 'Ready to Copy'.

Cheers

[MichelZ]

Could you post a client log from the User?
(CTRL + SHIFT + Click on a EV Icon in Outlook)

Cheers
Michel

[wilsond3010 · Accepted solution]

We had a simlar issue with a couple of users

and it turned out to be there main laptop was being worked on and they logged into a temp laptop and something strange happened with there pst client migration cause it kept look for the file saying i know you've got it.

eventually it timed out and we removed the item from the pst list view inside enterprise vault admin console  also do a f5 refresh on it  just incase