EV client driven migration - failed to convert network path

[adebola24]

Hi 

I'm doing EV client driven migration - but having an issue with EV importing the .pst

I confirm from the client machine registry that the pst is marked - however EV does not import the PST

Within Personal Store Managment - Files - the PST is NOT LISTED

I notice the following from the EV log within outlook (ctrl + shift on an EV button)

++++ Failed to convert network path 'c:\users\doug\120712.pst'

PSTMIG: none of the PSTs in the current MAPI profile are ready for migration

PSTMIG: no PSTs in server list are ready for client side migration

PSTMIG: PST importer sleeping for 60 minutes (there is no work to do)

[adebola24]

to add to the above

The pst file is currently open within the outlook profile and I have restarted outlook several times

Server driven migrations work for this user but we want to use client driven

Thanks

[JesusWept3]

quick question, the user profiles, are they local to that machine or are they hosted somewhere else?
Seen 'similar' issues to this when people use roaming profiles and it goes on to a network share

So on the Desktop it looks like C:\Documents and Settings\UserName\
And EV tries to go to \\usersComputer\C$\Documents and Settings\UserName

But on the desktop it has something like

C:\Documents and Settings\UserName  ... maps to ... \\sanStorage\UserProfiles\UserName

[JesusWept3]

oh and also do your issues match these per chance? (They also had the same error, so not sure if you're seeing other issues also?)

https://www-secure.symantec.com/connect/forums/client-driven-pst-woes-particular-user-client-errors

[adebola24]

Hi - i saw that post - it has the same error as in the 'failed to convert network path' bit

as regards the profiles - i've attached a picture of what is set

[JesusWept3]

ok next stupid question would be, can EV connect to

\\usersComputer\C$\users\doug\ ?

 

[adebola24]

also here is part of the log which shows the error around failed to convert

im totally stuck with it

[adebola24]

thanks

yes it can - it shows the PST file and can open the file

[Rob_Wilcox1]

Hm interesting ..

Your client trace shows :

12/07/2011 17:07:05.721[3892]: PSTMIG: Found 3 PSTs in current MAPI profile
12/07/2011 17:07:05.722[3892]: DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.723[3892]: ++++Failed to convert network path 'C:\Users\doug\Documents\Outlook Files\1207 - 2 pst.pst'
12/07/2011 17:07:05.723[3892]: ~DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.723[3892]: PSTMIG: Found PST in profile: C:\Users\doug\Documents\Outlook Files\1207 - 2 pst.pst
12/07/2011 17:07:05.724[3892]: CDesktopCommon::EscapeXPathQuery: 0x0
12/07/2011 17:07:05.724[3892]: ~CDesktopCommon::EscapeXPathQuery: 0x0
12/07/2011 17:07:05.724[3892]: DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.725[3892]: ++++Failed to convert network path 'C:\Users\doug\AppData\Local\KVS\Enterprise Vault\AC6F0A6E58F3E1419B0EC0544A8EA65B\1B730F55FFD1F9440ADC16A33582A030E1110000EVSERVER01.mdc'
12/07/2011 17:07:05.726[3892]: ~DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.726[3892]: PSTMIG: Found PST in profile: C:\Users\doug\AppData\Local\KVS\Enterprise Vault\AC6F0A6E58F3E1419B0EC0544A8EA65B\1B730F55FFD1F9440ADC16A33582A030E1110000EVSERVER01.mdc
12/07/2011 17:07:05.727[3892]: CDesktopCommon::EscapeXPathQuery: 0x0
12/07/2011 17:07:05.728[3892]: ~CDesktopCommon::EscapeXPathQuery: 0x0
12/07/2011 17:07:05.728[3892]: DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.729[3892]: ++++Failed to convert network path 'C:\Users\doug\pst.pst'
12/07/2011 17:07:05.729[3892]: ~DesktopCommon::ConvertRemoteFileSpec: 0x0
12/07/2011 17:07:05.729[3892]: PSTMIG: Found PST in profile: C:\Users\doug\pst.pst

And in the client code we make an API call to : WNetGetUniversalNameW, which is failing, and hence you get the trace highlighted above.

I will try to dig into that tomorrow and see what it does, and post any suggestions (nudge me on Wednesday PM if you don't hear back !)

[JesusWept3]

Rob, will the client ignore MDC files or is it gonna try and migrate them?!?!?

[Rob_Wilcox1]

Fair question..  and the answer is .. I don't know.

I will check tomorrow.. too late in the day for me to repro, or read the code (too much).

[Rob_Wilcox1 · Accepted solution]

Looking at the code we won't migrate the MDC, but the picking up of that fact could be better.  Also the "failure" reported in the trace might be a red-herring...

So the question here with regards to these PSTs that aren't being picked up.. when were they added to Outlook?  By default, we only scan the machine every 7 days for PSTs, and add them to the server list.  We won't attempt to migrate PSTs that aren't in the server list.  So PSTs added to the client between the time interval don't get migrated.

LASTPSTSEARCH is the registry key, which on this client trace is showing as 12th July, ie yesterday.  

Can we try ...

Close Outlook
Delete that key

Start Outlook

Wait a bit

See what happens in that trace?

[adebola24]

Thanks Rob

That has worked and the PSTs have now been migrated - not sure why we get the 'failed to convert message mind' ?

the server list - is that the same list as within VAC - Personal Store Management - Files ?

how often by default will EV mark new PSTs ?

Would you recommend to leave the 7 day interval for PST searching ? 

Thanks

Chris

[Rob_Wilcox1]

The "failed to convert..." message relates, I think, to converting remote PSTs (which Microsoft advise against anyway).  The tracing could be better here !

Yes the server list is the one you see in the VAC -> Personal Store Management -> Files, you might have to do a few refreshes.

7 days is the default, it's overrideable on the policy for the user.

7 days seems reasonable to me.. the idea is to try and give plenty of time for the existing PSTs to migrate already.

[adebola24]

yeah ok thanks 

btw - this should probably be a new thread but what would you recommend as the best way to restore a mail from the journal archive to a usermailbox / user archive ?

Chris

[Rob_Wilcox1]

hehe yes new thread, please.