App-V 5 SP2 Redirected Folder Permissions

I have been neglecting my blog recently due to the fact that in the last 3 months I have gotten married, renewed my Citrix certifications and joined a humungous project, the blogging had to take a back seat to the rest of my life for a while. This is a short post inspired by a conversation about some issues in App-V 5.0 SP2 with my good friend Rory Monaghan of rorymon.com, he is a Microsoft MVP for App-V and an all-around technical type of guy. Hopefully it gets me back on the blogging waggon.

Unfortunately I have recently found myself a victim of the requirement for App-V client machines to be given modify access on redirected user shares for sequenced applications to work correctly.According to the powers that be at Microsoft App-V 5.0 SP2 supports %AppData% folder redirection (http://technet.microsoft.com/en-us/library/dn508408.aspx) …….they may have forgotten to mention it only works if you give the App-V client machine modify access on the share in question. Now sports fans this is not only modify permissions on the redirected appdata folder but modify permissions on the ROOT of the redirected folder share!

As you can see when launching a sequenced application (Opera browser) from the procmon below the App-V client exe clearly looks for access on the share I used to host user directed folders

The application you are trying to launch will also most likely give you this error message in the App-V client event logs. Note: the 0x5 designates this error as being related to permissions.

So to amend the current documentation it should read that App-V 5.0 SP2 supports folder redirection as long as you give the App-V clients modify access on the root of the redirected folder share. Now while this may be fine and dandy in a mom and pop outfit it is not going to fly in an enterprise environment where you need to submit a change request in order to put in a new desktop background! As I had hit a brick wall with our Security team it was time to turn to my trusty Google machine.

The piece of literature I found the most useful was the App-V 5 SP2 Application Publishing and Client Interaction document which can be found at http://www.microsoft.com/en-us/download/confirmation.aspx?id=41635

This helped me understand why the App-V client was behaving the way it did. I will draw your attention to page 19 of the document in question

As you can see from point 3 in the first list, the appdata folder in the sequenced application VFS will be mapped to the local appdata directory. On virtual application launch the App-V client queries the redirected appdata location and copies the required data to the local appdata location where it is in turn used by the App-V client on behalf of the sequenced application.

A procmon would appear to confirm this behaviour as you can see below in addition to the access denied error above you should also see a file not found in the local appdata user COW location and of course the application doesn’t launch.

From the above we can deduce that if the sequenced application contains an appdata folder AND the user launching the sequenced application has a redirected appdata folder THEN the App-V client makes a call to the users redirected appdata folder on behalf of the client machine and copies the necessary application files to the following location: %localappdata%\Microsoft\AppV\Client\VFS\{Application Guid}\AppData

So what do you do when all the above points are true but you are not in a position to open up permissions on the redirected folder share or remove appdata redirection?

The only other option available is to remove the appdata folder from the sequenced application and see what happens.

But I hear you say what happens if your application has a functional requirement on the appdata folder? Well assuming App-V behaves like it used to if the folder is removed completely from the VFS of the sequenced application then the application should look outside to the local machine for the files in question. As a result you can if necessary stage the required files/folders outside of the virtual application and allow it to access them from the user profile as it would if the application were installed locally.

The first step is to get a copy of those files in case they are needed for staging. The quickest way I found was to take a copy of the .appv file of your sequence and rename it to a .zip file

You can then browse into it natively and copy out the files you need as per below. Note that you will need to remove the %20 from the file and folder names that have spaces in order to make the files/folders useful outside the sequence.

Now that you have taken a copy of the contents of AppData from the .appv file it is time to open up the original and delete the appdata folder from within the sequence.

You will notice in the case of Opera there are a large number of user preferences I captured in the sequence that went to the appdata folder so keeping a copy as per the previous step was probably a good idea.

Once the AppData folder has been removed from the sequence save it and republish it. All going well the application will launch without the symptoms mentioned in the first half of this article.

On an aside I also had to remove the User Pinned folder from the sequence also to allow the application to launch without the Virtual FileSystem Subsystem failure message. You may have to do some trial and error with your sequence if you are not in a position to open modify permissions on redirected user folder share.

So now that you have gotten your application to launch by removing the appdata folder (and possibly other folders) you will need to determine how your application behaves on first launch. In the case of Opera it launches without any of the saved settings that were captured at sequence time but in the case of another application AppData may have been captured as part of sequence and is not actually needed. (eg, Notepad ++ saves an xml in appdata but removing the appdata folder does not appear to affect the functionality of the application so I did not bother staging it)

In the case of Opera I didn’t want my users to have to go through the first launch wizards and settings so I replaced the %20 from the extracted files and folders with an actual space and used a third party tool to stage the files and for copying to the users profile at login.

So far the above workaround has allowed me to launch more than twenty applications in an environment where I am not in a position to open modify rights on the network share hosting the redirected user folders. I hope that it helps someone in the same bind. Obviously it will be up to you to determine if you need to extract and stage the contents of the appdata folder on an application by application basis.

I would love to hear similar experiences or even a better work around than the above so feel free to leave a message on the blog or on Twitter. I have heard a rumour that Client Impersonation will be implemented in the next version of the App-V client so I will be keeping my eyes peeled for that!