02-09-2012 08:12 PM
We have client driven migrations going and things are working well. In the PST policy "Post Migration" settings, we have defined to delete the PST file after the ingest. So here's what happens... Client driven migration runs, finds PST files on attached in the Outlook profile ingests the PST and removes the PST from the Outlook profile but doesnt delete the PST.
Here is a sample of the client log which doesnt show much. I have run some additional tests and no matter the location of the PST file (network share or local disk it will not delete the PST file.)
I did see a note in another tech article that said if the vault store is set to remove safety copy after backup that it will wait until items are backed up first. However in this case the vault store is configured to remove safety copy immediately after archive.
I dont think its a permissions issue because this problem happens even if the PST is local on the PC like the logs show below.
Suggestions?
10/02/2012 03:46:14.427[ 448]: Body is <?xml version='1.0' encoding='utf-8'?><PSTFILES pstIncludeDeletedItems='1' pstExpandOfflineVault='1' pstClientSearchRestricted='1' ComputerEntryId='1C78020F14031154EB6DCCE8C1EB3CAD91011700EVSERVER1' StorageServiceEntryId='1E2BC8B9D3D4D1542AB156184D5FE8AB61e10000EVSERVER1' ExchangeMailboxEntryId='1C708583EEEDA2043824E182B858742391n10000EVSERVER1' IncludeShortcuts='0' MaxPstChunkSize='10000'><PSTFILE PstFileIdentity='2' FileSpecification='C:\dloads\Dloads
10/02/2012 03:46:14.429[ 448]: Body is PST.pst' Status='4' ProfileConnected=''/><PSTFILE PstFileIdentity='4' FileSpecification='C:\dloads\psthotfix\Aaron's PST.pst' Status='1' ProfileConnected=''/><PSTFILE PstFileIdentity='1' FileSpecification='C:\Documents and Settings\evtest1\Desktop\Aaron's PST.pst' Status='4' ProfileConnected=''/><PSTFILE PstFileIdentity='3' FileSpecification='C:\Documents and Settings\evtest1\Desktop\Network attached PST 001.pst' Status='4' ProfileConnected=''/></PSTFILES>
10/02/2012 03:46:14.431[ 448]: PSTMIG: Found 1 PSTs ready for deletion
10/02/2012 03:46:14.431[ 448]: PSTMIG: Unable to delete PST C:\dloads\psthotfix\Aaron's PST.pst
10/02/2012 03:46:14.432[ 448]: Internet connection state: 1 (18)
10/02/2012 03:46:14.433[ 448]: Internet connection state: 1 (18)
10/02/2012 03:46:14.433[ 448]: PSTMIG: Found 1 PSTs in current MAPI profile
10/02/2012 03:46:14.433[ 448]: ++++Failed to convert network path 'C:\Documents and Settings\evtest1\Local Settings\Application Data\KVS\Enterprise Vault\25084EAF7A3E4D46B7CFCF7FB39D9BEF\1B681EA4F5A54A748B13D2765AE4A60301110000EVSERVER1.mdc'
10/02/2012 03:46:14.434[ 448]: PSTMIG: Found PST in profile: C:\Documents and Settings\evtest1\Local Settings\Application Data\KVS\Enterprise Vault\25084EAF7A3E4D46B7CFCF7FB39D9BEF\1B681EA4F5A54A748B13D2765AE4A60301110000EVSERVER1.mdc
10/02/2012 03:46:14.435[ 448]: PSTMIG: None of the PSTs in the current MAPI profile are ready for migration
10/02/2012 03:46:14.435[ 448]: PSTMIG: No PSTs in server list are ready for client-side migration
10/02/2012 03:46:14.436[ 448]: PSTMIG: PST Importer sleeping for 60 minutes (there is no work to do)
10/02/2012 03:47:45.925[1692]: DTCC: WaitForMultipleObjects: 258
Solved! Go to Solution.
02-23-2012 12:03 AM
By the Support Engineer contacting me... is one way. I'll write it via that route.
Or in a more formal route by escalating it through the support processes to the Customer Focus Team.
02-09-2012 11:59 PM
You don't mention your exact EV, EV client and outlook versions, please specify them.
02-10-2012 01:36 AM
Is that PST still connected to the Outlook profile?
Is the file marked as read-only, or hidden? Having said that in the code, I can see that we make the file 'normal' ie not readonly, then attempt the delete. Unfortunately in our client code we don't report the error code of why the delete failed.
02-10-2012 06:38 AM
EV 9.02 on the server and client and the PST is being removed from the Outlook profile with no problems but the PST file is not being deleted. I checked the PST file and yes it is marked as read only. Does that make a differnce? I can only assume that they Client driven migration is doing this read only mark? It must be because once the PST file is marked read only you cannot open it in Outlook anymore and prior to the ingest the users had them opened in Outlook.
Thanks in advance for the help.
02-10-2012 07:09 AM
The PST is made read-only when all of the chunks of data from the PST file have been uploaded to the EV server.
The deletion takes place 'later' and what we try to do is ..
a/ Make the PST read/write (and we log an error in the client trace if that fails)
b/ Delete the file (if that fails we log the exact bit of text you indicated, and make the file read-only again).
Maybe the user doesn't have permission to delete the PST?
02-10-2012 07:11 AM
Could it be this: http://www.symantec.com/business/support/index?page=content&id=TECH76019 alternatively have a look a this: http://www.symantec.com/business/support/index?page=content&id=HOWTO32220
02-10-2012 07:26 AM
Its marking the file attribute as read only for sure. So your saying when it tries to delete the file it removed the ready only attribute first? I dont think that is happening. All files we have checked still have the read only attribute set. The user does have R/W access (permissions) to the PST files.
As for Percy's post - I did check both those articles. The PST migrator task is running as default and the ev service account is running the task and has db owner to the directory db.
This is driving me nuts.
02-10-2012 07:31 AM
Maybe I confused things slightly...
At the end of migration, the PST will get marked read-only by the Outlook Add-in.
In the snippet of client trace, the following is logged :
10/02/2012 03:46:14.431[ 448]: PSTMIG: Found 1 PSTs ready for deletion
10/02/2012 03:46:14.431[ 448]: PSTMIG: Unable to delete PST C:\dloads\psthotfix\Aaron's PST.pst
In that area of the code we :-
a/ Make the file read/write (and log an error in the client trace if it fails)
b/ Delete the file (and if that fails, we log the above, and make the file read-only again)
So... the issue is that we (The Outlook Add-in) can't delete the file. The Windows API call that is made to delete the file can return the error code, so that it can be output, but, the Add-in ... doesn't (unfortunately).
02-10-2012 08:18 AM
Just brainstorming. Maybe I am totally wrong...
I understand it is no profile(is removed), nor location, nor permission issue. And EV is actually trying to delete.
Now I never (and I mean never) use spaces or strange characters in my file names, I have had my problems with that in the past, so let's hope EV has no problems with the space and the apostrophe in the name. In the FieIdentity field it is replaced by 's. (typical HTML) Now you have the problem with more pst's but maybe they are all called Peter's PST, Paul's PST etc., that's why this came up in my twisted mind:-)
gtnx
paul
02-10-2012 08:52 AM
Well its worth a try... I will remove those characters and try again. I hope that isnt it because we would have to have over 20,000 users rename PST files. That would be a pain to say the least.
02-11-2012 01:41 AM
Pls keep us informed, I'm really curious.
02-13-2012 07:10 AM
Removing special characters from the PST file didnt help. Back to the drawing board.
Would a dtrace show any errors on not being able to delete the PST? I dont think it would but wasn't sure.
Any other ideas before I call support?
02-13-2012 07:19 AM
The 'delete' is happening purely client side. The client checks with the server, and is told which PSTs are ready for deletion, then tries to do it... by flipping the read-only bit, to make it read/write, then trying to delete it.
02-13-2012 11:36 AM
02-14-2012 01:38 PM
Results from more testing...
If I manually remove the read only attribute on the file then run the client drive migration again the PST file is getting deleted! So it appears the problem is that EV client is having problems removing the read only on the PST file so that it can do the PST delete.
I opened a support case and I am working with support. So far we can't get it resolved. Next thing we are going to try is a EV client update so see if a newer client has a different reaction...
02-15-2012 11:47 AM
Interesting.
I'll take a look at the code again shortly.
02-15-2012 11:53 AM
According to the code if we can't make the PST non-readonly, the following should be traced out:
Could not un-mark PST file as read only: + name of the PST file
You're not getting that, at least not in the trace you put in the first post, so we think it succeeded. It's a Windows API call we make, so, it might even possible to do a test app (if/when you get that far) to see what happens.
02-21-2012 03:10 PM
So just an update. I have had a case open with Support for sometime and we have not made any progress. They have done a dtrace but couldn't find anything that would help. The only update I have is that this problem is not consistent. We now have over 100 users doing client driven PST migrations. I would say that 10% of those have PST files being deleted as expected and configured by the PST policy while others are just sitting with the read only attribute still checked on and I assume that is why the PST file is not being deleted.
Anymore thoughts would be appreciated. We have over 10k users to enable and need to get this figured out. Do you think a GPO or firewall policy could be blocking the API call to delete the file?
02-22-2012 12:56 AM
In my personal opinion you need a little test app that does the same thing as the EV core code, and see if it works (on the machines where the PST fails to be deleted).
02-22-2012 01:47 AM
Hi Aschnarrs,
from my expierence, you might encounter different other problems when doing Client Driven Migrations.
You might want to have a look on our PST FlightDeck which helps you to establish a "real" workflow when migrating the files. As well all files are Preflight-Checked, Filtered and Deduplicated before ingesting into ev. You can as well involve the user to chose the PST-Files which should be migrated.
More on this: http://www.quadrotech-it.com/products/pst-flightdeck/
Drop me a pm, if you would like to dive deeper into it...
Peter