The race condition applies only when running scripts. That I can force it when I don't use scripts is clear. However you can test for yourself if you have a roaming environment where the VFS_Local isn't there when you logon from a previous publishing attempt, you can manage to start the app before staging is 100% complete and then the VFS Copy Job which is running on StartVirtualEnvironment will fail in a 50/50 chance.
Yes I can copy from inside the VFS, but as you outlined that is only a good solution when it's just a couple of files. Ideally would be an app which does uses the COW (so runs inside) but copies everything from a share where I copied to contents to previously. The only obstacle is to build a list of App-V folder name = real foldername so it knows that ProgramFilesX86\Foo\Bar.ini translates must get copied to C:\Program Files (x86)\Foo\Bar.ini
The race condition would be because you are not using the scripts. This provided the optimum timing, as the script wouldn't run until everything was in place, but would finish before the client would launch the app.
However, Microsoft made some security changes since the tool was released and you are running in an environment with lots of moving parts that may also contribute. It is something I will look into, but it might take a while to get to (something about paying customers expecting to have priority).
If the issue is a known file/files, you can skip this tool and maybe solve other ways:
You can have a script perform the copy inside the package. Unfortunately, terminateVE scripts won't run inside the VE, so the script has to be embedded inside the package and user shortcut would have to point to this script:
1) Look to see if backed up copy of file and copy it.
2) run app
3) back up a copy of it.
I have also solved the issue by creating a custom file redirection shim for the app.
I now tested again using StartProcess and robocopy. Same results if I am fast enough in clicking on the virtual app icon then I can manage to start the App before the COW Local is created. This leads to robocopy failing to copy stuff -> app has no settings again -> close app -> robocopy /MIR -> will delete all settings I once had for the app but /MIR is required so things actually also get deleted again and won't just bloat. If I give it some time to finish staging then it works every time but in case of published applications I cannot give it time because XenApp launches the app when it thinks it's ready.
I didn't include it in any Scripts section yet. I just tried manually from a command line.
Now the complicated stuff (we are using App-V 5.0 SP3 for RDS):
However tool aside there seems to be something fundamentally wrong with App-V and the permissions on the COW Local folder. See App-V absolutely hates it if you tamper with them on the COW Local folder. When a user is logging into XenApp server in combination with App-V Publishing server then it takes a while until the App-V client stages the COW Local VFS folder which happens on the Logon Publishing Refresh event. If you open a published ICA or RDP desktop then you can see the App-V icons briefly flash when this happens. This is also when App-V finishes creating the basic folder structure under %LocalAppData%\Microsoft\AppV\Client\VFS which are not there immediately after Logon and you can see them getting populated. However as said this doesn't happen immediately after Logon. The problem is now the following: If you copy any stuff into %LocalAppData%\Microsoft\AppV\Client\VFS before!!! App-V finishes the staging then bad things will happen and your virtual apps will refuse to start because you screwed up the permissions which App-V expects. It really wants to create the folders there by itself. If you copy something back after those folders have been created then everything is fine. In fact this is the reason why we cannot just include the folder using our Profile Management solution because the Profile Management will not create it with the proper permissions (and it does that before App-V can create the folders) and thus render apps unusable
So now we are trying to work around the issue by using scripts in the user config. And there is a new problem:
There is a race condition with the COW Local VFS staging and StartVirtualEnvironment event. In like 50% of the cases it's not finished and at the time the App-V client will trigger the script to run, the folder is not fully setup and the settings either screw up the app completely or only get partially copied. On the next attempt it may work as expected. This is especially a problem when using published App-V applications in a XenApp environment as the time between Publishing Refresh and actual launch is very thin.
We wanted to give your tool a shot since we unfortunately have a lot of bad written apps which fall in this category and need to roam the COW Local, because they save .INI files or other stuff there. However upon a quick test with Google Chrome and App_Remediation.exe /saveall nothing is being copied anywhere. I also cannot see anything going on in Process Monitor. The utility just loads and then exits. We were just curious how it would accomplish this, since we have the issue that normal user accounts are ot able to copy the COW Local INCLUDING permissions with robocopy in the first place (which I think it uses itself to copy the stuff). BUT without the permissions in place on the COW Local like TrustedInstaller etc. applications will fail to start on the next instance.
Like for example User Profile Management from Citrix easily allows us to include additional folders to roam but when it copies back the COW Local without permissions all App-V applications refuse to start until the folder is deleted and App-V re-creates them itself on the next publishing attempt.
Looking forward to hear your thoughts on the issue.