You don't mention your exact EV, EV client and outlook versions, please specify them.

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.

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.

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?

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

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.

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).

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

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.

Pls keep us informed, I'm really curious.

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?

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.

Maybe running a process monitor (like from sysinternals) on the client will give you more info.

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...

Interesting.

I'll take a look at the code again shortly.

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.

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?

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).

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

So more testing results and information...

We seem to have 2 seperate but related issues.

Problem 1 - Complete empty PST files with no messages in the PST remains to be maked as read only and not being deleted. (still trying to figure this one out and working with support)

Problem 2 - Most recently we have enabled more users and have noticed that some PST files are left with meeting messages left in them after a client driven migration.  From the report file on the EV server we see the following:

"Migration of \\LAPTOPR8Z9TR1\C$\Users\rich8685\Pictures\GDS.pst has been successful, but the PST file contains items that could not be migrated. The PST file has not been deleted."

So I opened some of these PST files and see that all the emails being left behind are meeting invites, declines, accepts, etc.  I sort by message class from within Outlook and I see the following message classes.

IMP.Schdeule.Meeting.Resp.Pos - this is a accept meeting reply
IMP.Schedule.Meeting.Resp.Neg - this is a decline meeting reply
IMP.Schedule.Meeting.Request - this is a new meeting request

So in looking at the default message class config on the EV server all these message classes do not exist.  I added them today and will post results again after some new users are enabled.

So Questions for you guys.

1 - If a PST after a client driven migration has items left in it like we found the PST file will not be deleted correct?  I assume this is a safe guard so that data is not lost since the pst file is not empty.

2 - We corrected this issue by adding the message class into EV.  Is it possible to re-process those PST files so then to import the IMP.Schedule messages and then get the PST file deleted?  I assume the answer is no because the PST was left as read only (attribute) and I dont think Client driven PST will remove the read only ingest then delete again.  Any thoughts here?

Thanks again.

Have you attempted to capture a processmon during the point of failure along with teh client log so you can see what is happeing on an OS filesystem level? May help to narrow the focus of the issue.