Explainer: App-V error 29-000010FE with User Data redirected to a network share

InfoButtonSo have you had a chance to try out Windows 7 Service Pack 1 or Windows Server 2008 R2 SP1 yet?  It should have been available to MSDN and TechNet Subscribers as well as Volume License customers yesterday so I'm curious how many have actually had a chance to try it out.  I've been running it for a few days now and so far I'm pretty impressed.  And, with Dynamic Memory and RemoteFX in Windows Server 2008 R2 SP1, if you work with any kind of virtualization you'll definitely want to check it out.

Speaking of virtualization, I'll get back to the real purpose of this post, which is to let you know about a recent issue our very own Madelinde Walraven recently ran into.  She's based over in our office in The Netherlands and is a real Top Gun when it comes to App-V.  If you're over in Europe and ever called for support there's a good chance you've spoken to her.


Recently, I came across an issue that I would like to share and document for future reference. I was troubleshooting a configuration where Microsoft App-V desktop clients had their App-V User Data redirected to a network share. This folder was configured to be always available using Offline Folders/CSC (Client Side Caching).

The issue we ran into was one where an application launch failure was displayed if the network connection was down and an application repair had been performed:


[The Application Virtualization Client could not launch {appName}.  The file is currently not available for use on this computer.  Error code: 460F3-00000729-000010FE] 

An application repair removes the User PKG file, which resides in the redirected folder that is using CSC. After you have repaired the application, it looks like the local User PKG is deleted properly and when you browse to the share (while being offline) you will find no PKG there, but this is not actually the case!

When you browse to the physical copy of the folder, which is located in C:\Windows\CSC\..., you will find that the PKG is not completely removed at all.  What happens is that the PKG is still there but it is being cleared (0KB).  Because of this, App-V generates an error because the PKG file it detects cannot be used.

So why is it cleared, and not deleted? As soon as we have a network connection again, everything syncs and the cleared file gets deleted as expected. The CSC mechanism needs to clear the files before deleting them when the client is offline, otherwise it would not know how to synchronize when the network comes up again. If no file was physically on the client, and an old copy is still on the server, we would get the old one back to the client instead of having the old one removed permanently.

So this explains why the error 29-000010FE could happen.

Madelinde Walraven | Senior App-V Support Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

clip_image001 clip_image002

Comments (1)
  1. Philippe says:

    There seem to be other cases, where this error shows up.

    We had the same error this morning. In this case, no repair had been performed, and the PC was online.

    What we could find out:

    1) the user had set the appv client to "work offline" as he was away from the network for quite a long time

    2) in the meantime, we upgraded the package

    3) as he was connected again, he changed to "work online"

    4) there was a sync conflict, with the package file (UsrVol_sftfs_v1.pkg)

    As soon as we resolved the conflict, the error disappeared

Comments are closed.

Skip to main content