If you read the original post https://sccmentor.wordpress.com/2013/10/17/unable-to-unpublish-app-v-5-apps-with-appdata-redirected/ you’ll note that SCCM 2012 is not able to unpublish applications when you redirect AppData using folder redirection.
Well the problem is not restricted to SCCM 2012. This is an App-V issue and the same behaviour occurs when you attempt to unpublish the package via PowerShell.
As discussed I had to manually remove the package folder from the APPDATA\Roaming\Microsoft\AppV\Client\Catalogs\Package\{Package ID} folder.
I narrowed down that the account attempting to remove the folder was actually the local computer account. So if I need to unpublish packages for a batch of users I can achieve this by assigning Domain Computers access to the users home drives where the AppData folder now resides. Hmmm this can’t be right, but it gets me round the problem for now.
As an aside I downloaded the App-V SP2 beta client to test the folder redirection support of the latest client. It’s definitely working better to support applications that stored data in the Roaming\AppData folder, however it still won’t unpublish the packages unless I allow Domain Computer rights to the user home drives or AppData.
In the meantime I have logged this with the Microsoft App-V SP2 development team and am awaiting feedback on the issue.
SCCMentor - Paul Winstanley 
This topic is right down my alley. We are awaiting SP2 for the very same reasons you are, problems stemming from the redirection of AppData. What I can’t understand for the life of me is how Msft did not design App-V 5.0 with the redirection of AppData in clear view, since this is quite a common practice among enterprises. I would like to add my voice to the chorus here, so how exactly does one log something with the “Microsoft App-V SP2 development team”. It’s critical that SP2 works with AppData folder redirection right out of the box (without granting perms to Domain Computers, etc.)
Joe,
I’m glad I’m not the only one being frustrated by this ‘oversight’. You can go to https://connect.microsoft.com/ and sign in/up. Once in click the Directory menu option and then join the Microsoft Application Virtualization 5.0 SP2 Beta. Once you are in there click the Feedback menu. My post is on page 2 and you can vote this up and also comment to state you are experiencing the same issue. To be honest the more votes/comments the better and the more chance we have of the App-V team addressing the problem. I have tested some apps that weren’t working well in SP1 with SP2 beta all the FD problems had gone away however the unpublishing issues have not.
Paul, would this also be the reason that when toggling Migration Mode from 0 to 1 (which gives authority of FTAs from 4.6 to 5.0) does not work as advertized within our environment? Well, to clarify, even if Migration mode is set to 0, and I publish a 5.0 app to a machine, 5.0 owns the FTAs right away. Toggling Migration mode in the configuration of the client has no effect either way.
I’m not sure in this instance Joe. Your best bet would be to grab the SP2 beta when you have joined the programme and test again on a client with it installed. It would be good to know from your testing.
Is this the issue you are encountering. http://social.technet.microsoft.com/Forums/en-US/1786ad97-9347-41ba-bb80-379db0ce3650/rebuild-appv-5x-shortcuts?forum=mdopappv
not quite…sounds like he has 2 non-overlapping separate shortcuts (1 4.6 and 1 5.0)…our shortcuts always overwrite each other depending on last one installed. But the FTA issue he describes might be related to mine. I’ll try the sp2 beta and see what happens. I’ll let you know but it might be some time before I can get around to it and by then RTM may already be out.
So I’ve now done that and the news is rather foreboding. Installed an App-V 4.6 SP2 version of Centrify Putty. All good. I then installed an App-V 5.0 version of Centrify Putty. Shortcut over-wrote the 4.6 shortcut as intended. So far, all good. Then I went into Software Center, highlighted the 5.0 version, selected uninstall in the lower right of the window. I get “waiting to apply changes”…then “removing”….and…”removal failed”…ugh! More information under the error message status says “Unable to make changes to your software” and at the bottom of same window, the more specific “The software change returned error code 0x87D0128F (-2016406897). I then take a peek at the AppEnforce.log via cmtrace and find the following highlighted in blood red:
“Here is the error message generated by the process:
Unpublish-AppvClientPackage : Application Virtualization Service failed to
complete requested operation.
Operation attempted: Unpublish AppV Package.
Windows Error: 0x78 – This function is not supported on this system
Error module: Catalog. Internal error detail: 86B0572600000078.
Please consult AppV Client Event Log for more details.
At line:1 char:106
+import-module ‘c:\Program Files\Microsoft Application
Virtualization\Client\Appv …
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~
+CategoryInfo :InvalidResult: (:) [Unpublish-AppvClientPackage]
, ClientException
+ FullyQualifiedErrorId : UnpublishPackageError ,Microsoft.AppV.AppvClientP
owershell.UnpublishAppvPackage”
I then consult the AppV Client Event Log in the Event Viewer as this error message states to do:
Number of events under “Admin”: 0
Number of events under “Virtual Applications”: 0
Under “Operational”, at the time when I attempted to uninstall the Centrify Putty Appv 5.0 app within Software Center, it posts the following message (Level is Information):
“Package { } version {} was unpublished for the user.”
ALL THIS HAS ME GREATLY CONCERNED.
By the way, while on the same system, I checked the perms on the redirected AppData folder and “SYSTEM” has “Full Control”.
Joe
Set domain computers rather than system with full control and try again
I’ll try it but regardless of the outcome having to change the permissions on such folders may be a security issue. This is no small matter within the enterprise and we were never anticipating having to make such changes.
I totally agree and personally I’m holding off for SP2 in the hope that this is resolved.
OK, I granted Domain Computers (and all subfolders and files) “Full Control” on the AppData folder. No difference. Even threw in a reboot for giggles. Not good.
I mean just think about it. Even in a small commercial operation, you would never want any and all domain joined computers to have even just “Read” access to the data housed in a user’s roaming “appdata” folder. There’s always the chance that private data (and metadata) may be placed intentionally or accidently in this folder.
Not good at all…
Hi Guys,
I know currently AppData folder redirection is currently not supported when using App V 5
http://technet.microsoft.com/en-us/library/jj713463.aspx
The following directories must be available on a local volume for each user that logs into the computer running the App-V 5.0 client:
• %APPDATA% \ Microsoft \ AppV \ Client \ VFS
• %LOCALAPPDATA% \ Microsoft \ AppV \ Client \ VFS
Paul,
Absolutely correct.
The main concern going forward is that the SP2 beta is stated to support folder redirection, however for unpublishing packages it is still displaying the same behaviour as SP1.
This needs to be resolved before release to fully support FD so I have logged my concerns.
I have managed to use the Domain Computers permission fix in the interim to get around my problem. This is not ideal.
Tim Mangan, if you’re out there, can you weigh in here??:)
So as you know, MDOP 2013 R2 is out now. Anyone test the RTM of appv 5.0 sp2 yet? How is it for unpublishing from Software Center when appdata is redirected?
Cheers Joe. I’m planning on taking a look this week.
Based on the following from Microsoft I’m not holding out much hope on it.
‘App-V 5.0 SP2 supports appdata folder redirection. When the virtual environment is started, the roaming appdata state from the user’s roaming appdata directory is copied to the local cache. Conversely, when the virtual environment is shutdown, the local cache associated with a specific user’s roaming appdata is transferred to the actual location of that user’s roaming appdata directory.’
Joe,
The unpublishing problem still persists in SP2.
*sigh. And giving domain computers access to appdata is still a workaround?
It was yes
So I guess the question now is, should this be a showstopper for migrating from 4.6 to 5.0? Probably not. But the plan for us is to deploy the same set of 40 + virtualized apps that we have in the 4.6 in the 5.0 format to a small group of pilot users. If, say, an app like centrify putty doesn’t behave well in he 5.0 format for whatever reason, we wanted the ability to revert the app back to the 4.6 format for that user or all users. It appears that simply telling the user to uninstall the 5.0 app via Software Center won’t be an option. So what are the options?
So aside from being unable to gracefully unpublish apps either thru SCCM or powershell command, does the claim that sp2 “now supports appdata redirection” hold water? Do settings and prefs within the Appv 5.0 apps follow the user? Do other errors present? I guess where I’m getting at is that if the only problem is the “unpublish” one, then we’ll most likely go forward given that 5.0, at least on the surface, addresses many shortcomings present in 4.6.
Joe,
So far SP2 has fixed all the issues that we have experienced with applications and folder redirection, such as having to introduce scripts to copy files into appdata\roaming and a permissions issues with an app writing back to into it’s own program folder. So far the only issue we have is the unpublishing of packages.
Cheers
Paul
I am using the App-V 5.0 SP2 client with SCCM 2012 R2, and was able to install/uninstall my application when deployed to a computer collection. After deploying the application to a user collection, I was unable to uninstall via SCCM and got the error: 0x87D0128F (-2016406897) “The App-V sftmime command returned failure”.
What did work to uninstall was in powershell “Get-AppvClientPackage -All” to list all packages, then “Remove-AppvClientPackage -Name ‘PackageName'”.
Thanks, while that may work, it isn’t something a user could easily utilize. Users in large scale will want to use that which is intuitive, they will simply want to highlight to undesired app in Software Center and click the uninstall button.
Steve – this is interesting. Can I confirm that this is with folder redirection in place? As Joe states it wouldn’t be a fix for end users using the Software Center or via an uninstall application in the SCCM console.
Paul – Yes, we are using folder redirection. I haven’t tested this with users installing/uninstalling via the Software Center, only when deploying the uninstall to a user collection.
I don’t get it. I get the app-v sftmime command returned failure too, but only on a couple of machines out of thousands have the issue.