So why not just store these files in %TEMP% instead? Great question. If the vendor made that happen I wouldn't have this lovely blog post.
(Just for a note this application utilized multiple folders on the root of C: as well, TMP being one, since we move our PackageInstallationRoot to a different drive, TMP isn't available on C:)
With that all said, what am I looking to solve?
Well, I don't want to be creating folders on the root of the C: drive as this application will be on our 'generic' PVS Citrix servers and minimizing the potential for pollution on the master image is a goal, having to create a folder and configure permissions is possible and I've done it before but it's not very clean or elegant; really if we're going to do that then we may as well pollute the C: drive. We want to maintain portability so creating a C:\TMP folder on the master image prevents us from publishing this package on desktops or other systems in the future unless this is well documented requirement.
We've just learned a new trick though, we can try using Microsoft ACT to create a file path shim that redirects the path to a different one. So let's do that...
|Huh. That doesn't look right.|
|I see SUCCESS...|
I ran across a similar issue on another application and what I found was that the embedded component appears to be running *outside* the bubble. Since the shim targets applications (in this case prowin32.exe) all reads from prowin32.exe are being redirected by other processes are not. I suspect (though I have no proof), in this case, that somehow the IE component is breaking outside the bubble and so it's NOT getting redirected.
Can we force all programs to get redirected to the proper path? Yes, we can.
Using symbolic links we can force any access to the directory to be redirected to the AppV package path. AppV will then see this is a path within the 'bubble' and redirect *again* to your local profile where the AppV5 writes will take place.
I removed the shim and then executed:
mklink /d C:\TMP C:\ProgramData\Microsoft\AppV\Client\Integration\D8E3DB68-4E48-4409-8E95-4354CC6E664B\Root\VFS\ProgramFilesX64\dlc11.2\TMP
Tracing with procmon.exe now showed us this:
And the application now displayed this:
So the application is now working without any issues, all of these 'temp' files are being redirected to a location where they will not be saved between sessions so no cleanup is ever needed. We need to add the mklink.exe to the DeploymentConfig.xml.
And we are now done.