Fixing File Permissions in App-V 5

UPDATE: Microsoft have now resolved these permissions issues in App-V 5.0 SP2 HF4:

There is still no solution if you need to write any of the restricted filetypes in the VFS however as discussed here:

Back in App-V 4, there was a very useful checkbox labelled ‘Enforce Security Descriptors’, which was checked by default. App-V 4 would capture all of the ACL’s containing user permissions and store them within the sequence. By default, it would enforce these and prevent a standard user (or an admin user running without elevation) from writing to locations as C:\ProgramData, C:\Program Files and C:\Windows in the same way as a regular application. Since unticking this box would effectively make App-V ignore all of these permissions and allow users to write to these locations, it quickly became part many people’s standards and templates to leave it unchecked. The benefits are that you spend less time debugging permission based issues for poorly written apps that try to write to these folders, and there are no drawbacks since all changes are redirected to the user’s PKG file, leaving the system unharmed.

Now we have App-V 5 and things work rather differently. ACL’s are not captured at all, and the ‘Enforce Security Descriptors’ checkbox is gone. Instead, the App-V client uses the same permissions that are applied to the folders outside of the virtual environment. For example, if users cannot write to C:\Program Files normally, they will not be able to write to any VFS (Virtual File System) folders here inside App-V either. The only exception is your Primary Virtual Application Directory chosen during sequencing time, which is fully writeable (although somebody has alerted me that perhaps it’s not, so more investigation is needed here).  Also by the way, the registry is fully open to standard users when inside the virtual environment and does not suffer form the same restriction as the file system.

At the moment we have been given absolutely no way given to us by Microsoft how to fix this problem. With App-V 4 or even MSI, permissions could be applied to certain files and folders to allow them to work without requiring full admin rights on the machine. Apparently Microsoft believe that most applications now adhere to their guidelines and do not try to write to such locations, and also that nobody is still using legacy apps these days. Just like they believed that nobody used the Start Menu or that everybody with an XBox had a stable internet connection! Hopefully they will backtrack on this one too with a bit of pressure!

I found a Technet forum post discussing the problem and how to work around it, but none of the suggestions work. Any permission changes to where the application files are stored under C:\ProgramData\AppV are ignored inside the virtual environment. You also cannot change the permissions from inside the bubble as a standard user (I didn’t try as an admin).

After investigation, I discovered that the ACLs for these folders are not simply inherited at runtime, they are copied and stored in the user profile, where they can be changed. App-V 5 splits the user’s sandbox for each application between two locations – folders that typically roam, such as %APPDATA%, get stored under C:\Users\USERNAME\AppData\Roaming\AppV. Any changes to non-roaming locations, such as Program Files are written to the local appdata folder under C:\Users\USERNAME\AppData\Local. It is under here that the App-V client creates all of the common restricted VFS folders that we are interested in, and it does this when the virtual environment for a particular application is launched for the first time. The folder are also emptied and the default permissions re-applied when the application is repaired.


Example default permissions:


If you change the permissions on those folders to grant the Users group modify permissions, standard users can then write to those locations in the virtual environment. In fact you will have even more freedom than you did in App-V 4 since you can now create entirely new subfolders under Program Files, whereas in App-V 4 you could only write to subfolders that were created during sequencing!

One important thing to note is that you will only see the folders above that are part of your sequence.  If you need write access to a particular VFS folder, you need to ensure that folder is in the VFS within your sequence in the first place, as simply adding it to this local appdata location as an afterthought via a script for example does not work.

There are a few points to be aware of before trying to solve this with a script to modify the permissions:

  • The owner of each subfolder is set to the Administrators group and the Users group does not have full control; so standard users cannot adjust the permissions directly.
  • They can however delete and recreate the folders, and the new folders will then inherit full write permissions.
  • The folders do not exist at add / publish time to it’s not possible to change them with a script running as local system. It may be possible to add them from scratch, but since a repair resets the folders, it’s better to solve this with a script run within StartVirtualEnvironment.
  • However when the virtual environment initialises, it creates these folders and applies those permissions to the VE before running any StartVirtualEnvironment scripts. Once the VE is running, changes to the permissions from the outside take no effect until the VE is shutdown and restarted. Therefore an application will not see any of the changes applied until it is launched a second time.

I have put together a script (designed to be run outside of the VE at StartVirtualEnvironment) that does the following:

  • Checks to see if one of the VFS subfolders (APPV_ROOTS) has write access. The -guid switch is used to provide the package GUID.
  • If it does, assume script has already run or is not required, and quit.
  • If access is denied, the entire GUID subfolder is renamed, copied back to it’s original name, then the old copy deleted.
  • If the -warn switch is supplied, a popup box appears to warn the user that the permissions have been set, suggesting that they close and restart the application.
  • If the -error switch is supplied the behaviour is similar to the above with a different message, and the script exits with an error code, which can be trapped by setting RollbackOnError=True in the xml where you define the script. Use this if the application will not work at all without the permissions being in place to prevent it launching the first time around. Unfortunately the App-V client displays some further nasty error messages when a script returns an error, I don’t know if it’s possible to suppress these yet.
  • The -name switch can be used to supply a friendly package name to show on the message box popups. If the user launched lots of apps at once or put them in their startup folder, they might not know where the error is coming from otherwise.


Click here to download the script.


You can add this script to the default Scripts directory from the Package Files tab of the sequencer.  Then add the following to DeploymentConfig.xml:

The only mandatory parameter is -guid, which you can find from the very top of the xml file.  If you want to make the script error on first launch to prevent the app from loading until the permissions are ready, simply change -warn to -error and set RollbackOnError to true.

After running this, all folder permissions inherit from the user’s local appdata folder, which give System, Administrators and the owner (but not the Users group) write access:


So please share this around and comment below if you’ve found it useful or have any issues or ideas for improvements. It would be nice to be able to suppress App-V error messages from a failing script and automatically re-launch the application for the user but that presents further challenges!


86 responses on “Fixing File Permissions in App-V 5

  1. Pingback: App-V Decision Matrix V3 | App-V and Other Such Things

    1. Chris

      i would love to use this script
      but i get invalid guid error whenever i try use it?
      i have put the correct package guid in?
      can someone advise please?
      Thank You

      1. Do you have curly brackets or dashes in the GUID? If so try removing them so they are in the same format used for the folder names.

        I have an idea to make the GUID an optional parameter anyway, so will update the script at some point. The GUID can be determined automatically from looking at the working directory of the script; then the GUID will only have to be specified if you are using it in a connection group (which I haven’t tested yet either).

        1. Chris

          Hi Dan
          I now have this working manually
          but having use the app-v 5 configuration editor
          i have the script on a share so \\\content\scripts\adobe\vfcacls.vbs

          i have set this up to be on start virtual environment and i have tried using wscript and the scriptlauncher.exe application.
          nothing applies it?
          im using pathtoscript.vbs -guid guidofappv

          as i say works fine manually, does not work when published via app-v with machine scripts enabled.
          have you seen this before?

          1. Do you get an error or just nothing happening? I’ve not tried scripts from network folders yet, you might have to add the computer account to have permissions on the share, in the same way you would have to if you had an application shortcut to an exe on a network drive. Have you tried putting it in the scripts folder? Which section of which XML file have you put it in and how are you publishing the apps, globally or per user?

    2. grac

      Hi Dan,
      i have an issue with your script. First i work´s, but if you unpublish this appv package, you are unable to publish this package again until you delete this modified Folder. This is because the App-V Client has no longer permissions to modify your modified Folder. So we have build a script in powershell that read the permissions on the source Folder and reapply them to the modified Folder after we have made our changes to this Folder.

      So here the script …

      ForEach ( $APPVPACKAGE in (Get-AppvClientPackage -All) | Where-Object {$_.Name -like “SAS*”})
      [string]$APPGUID = $APPVPACKAGE.PackageId
      $APPGUID = $APPGUID.ToUpper()
      [string]$COW_VFS_PATH = “C:\Users\$env:username\AppData\Local\Microsoft\AppV\Client\VFS”
      [string]$PACKAGE_VFS_PATH = “C:\Users\$env:username\AppData\Local\Microsoft\AppV\Client\Integration\$APPGUID\Root\VFS”
      [string]$APP_FILE_PATH = “ProgramFilesX86\SASHome\x86\SASAddinforMicrosoftOffice\6.1”
      [string]$COMMON_APPDATA_PATH = “Common AppData\SAS\SharedSettings\6.1”
      [string]$APP_FILE_NAME = “”
      [string]$APPGUID_TMP = $APPGUID + “_”

      # Test if App-V Package is New Published to User
      if(!(Test-Path -Path $COW_VFS_PATH\$APPGUID\$APP_FILE_PATH)) {

      # Rename the COW Folder and Copy it with the original name. This make it Writeable to the User.
      Rename-Item -path $COW_VFS_PATH\$APPGUID -newName $APPGUID_TMP

      # Create the folder structure and copy the required file in place.
      New-Item -Path $COW_VFS_PATH\$APPGUID\$COMMON_APPDATA_PATH -ItemType “directory” | Out-Null
      New-Item -Path $COW_VFS_PATH\$APPGUID\$APP_FILE_PATH -ItemType “directory” | Out-Null

      # Read Folder structure form original COW Folder
      $VFS_FOLDER = Get-ChildItem -Path $COW_VFS_PATH\$APPGUID_TMP -Directory

      # Read Folder Permissions form original COW Folder
      ForEach ($FOLDER in $VFS_FOLDER){

      # Create ACE for current Folder in original COW Folder
      $ACE_ARRAY = (Get-Acl -Path $COW_VFS_PATH\$APPGUID_TMP\$FOLDER).Access

      # Set corresponding Folder in new COW Folder

      # Get the current Security Descriptor from new COW folder

      # Break the Permission inherited
      $ACL.SetAccessRuleProtection($True, $False)

      # Transfer the Permissions from original Folder to new COW folder
      ForEach ($ACE in $ACE_ARRAY){

      # If any Permission inherited do not break the inherited
      if ($ACE.IsInherited -eq $true){
      $ACL.SetAccessRuleProtection($False, $True)

      # If no Permission inherited start to build the new ACE for current folder
      else {

      # Build a new rule based on the current rule
      $FileSystemRights = $ACE.FileSystemRights
      $AccessControlType =$ACE.AccessControlType
      $IdentityReference = $ACE.IdentityReference
      $IsInherited = $ACE.IsInherited
      $InheritanceFlags = $ACE.InheritanceFlags
      $PropagationFlags = $ACE.PropagationFlags

      # Create the new FileSystemAccessRule
      $FileSystemAccessRule = $ACL.AccessRuleFactory($IdentityReference,$FileSystemRights,$IsInherited,$InheritanceFlags,$PropagationFlags,$AccessControlType)

      # Add the new rule to the Access Control List
      # Apply the modified Access Control List

      # Remove the original COW Folder
      Remove-Item $COW_VFS_PATH\$APPGUID_TMP -Recurse

      1. Thanks, I wasn’t aware of this issue, I’ll look into it, and either update the script or re-write it in PowerShell. Are you using that in a pre-launch script? I would assume $env:username would reference the system account if so?

        Hopefully Microsoft will fix the whole debacle on the next service pack anyway! *fingers crossed*

        1. grac

          Hi Dan,
          we have opened a Support call for this issue, and the Support Point us to your script. Unfortunately your script let us run in this issue. so we dig a little deeper in and find out that we fix the one issue while we are open an other issue … now our script are make what we expect, but unhappily it is in powershell and not a vbs script. This is because i´m better in powershell ;-).

          So now to your question … we run this script as a publishing script per user and not global (and so run it also in the context of a user) in which the user is no admin. So the variable $env:username reference to the logged on user.

          When we run only your script, then after unpublish the package you will no longer possible to re publish this package or sync the client with the publishing server until you delete this modified folder from your profile.

          1. I thought user scripts run under App-V were started with the environment variables inherited from the System account, which is why my script has to work around this by reading the Shell Folders registry key instead of the env var:

            I’ve not checked to see what Powershell does, or if the behaviour has changed in SP2.

          2. grac

            Hi Dan,
            if a package is published global, the Publishing script is run under the System account. If it is published to a user, it runs under the user and with the permission rights from this user. So if the user is not an admin the script is more complex, because you know not everything is possible as user.

            So let us show forward, the next App-V servicepack / featurepack (spring release 2014 maybe in the next four wecks) had added a feature called “Full-VFS”. This should fix this problem for ever …

          3. Yes, that’s how it’s supposed to work, however there was a bug in 5.0 that meant when running scripts as the user, the environment variables were set to those of the system account. Like I said, maybe they’ve fixed that now, I haven’t rechecked!

          4. Quinn

            FYI everyone:

            Just released yesterday:
            Please note “Issue 4” where it states that we now have the ability to resolve VFS permissions in sequenced packages. This is both a sequencer and client release.
            Please test and report your results, I’m curios what this community is experiencing in their environments.

          5. Indeed, I installed it a little while ago and have found the checkbox that grants write permissions, but haven’t gotten around to testing it yet. I assume it works as advertised, allowing the user to write to all folders of the VFS except the filetypes listed here:

            Hopefully this script is now redundant!

    3. Tobias

      Hi Dan,

      I am new to App-V and your Blog already helps me to get around with some tricky configs 🙂 thanks a lot.

      I try to virtualize MS Dynamics NAV Client with App-V 5.0 SP3 and have one issue and don’t know if it is possible.

      Sequencing the client is quite easy and works fine.

      But we have different NAV Server Versions in use (for development) and before starting the client there should be an version update.
      The version update is done by “copy and replace” of the files. (dll and exe)

      If I am right, we have to copy the files to %localappdata%\appv\… and then at starting the original client and the update files should be merged, isn’t it?
      But it is not working!

      I read about CoW that exe and dll’s could not be updated, could this be the cause?

      Thank You and kind regards from Switzerland

      1. Indeed, the CoW filter prevents you from writing to exe/dll files in the virtual environment. The only way around it is to create a separate package for each version!

  2. Craig Shenton

    Hi Dan

    This article and script is exactly what I was looking for thanks. However, I cannot get the script to execute. I can execute it manually from the command line, I see the prompt from the .vbs script and the application works perfectly.

    According to this Technet article:

    “StartVirtualEnvironment” cannot be run from the deploymentconfiguration file, only from the user configuration file?? I tried adding it here under but still wouldn’t run.

    Scripting is enabled, I am aware that I need to re-add the package to apply the deploymentconfig settings and re-publish to apply the user config settings.

    I have so many applications that need this to work so any help/suggestions you have forgetting this to execute would be greatly appreciated.

    Kind Regards

    Craig Shenton

    1. Hi,

      You could put this script in either xml file, but if you want it to apply to all users it’s best to put it in the deploymentconfig.xml. This diagram (taken from here) shows which scripts you can put where (click to enlarge):

      First of all just change the script to run cmd.exe so you can get visibility that something is happening. The xml snippet was copied straight from my own file I was testing with so it should work – open up the xml in IE or an XML editor and make sure you haven’t placed the script inside a commented out block!

      Also check that scripts are enabled – either via group policy or setting it via Powershell.

      Test locally on the client to rule out any issues with the back end – run Powershell as admin on the client, and type:

      Set-ExecutionPolicy remotesigned -force (if not already configured)
      Set-AppvClientConfiguration -EnablePackageScripts $true (if not already configured)

      Add-AppvClientPackage MyApp.appv -DynamicDeploymentConfiguration MyApp_DeploymentConfig.xml | Publish-AppvClientPackage -global (this is one line)

      1. Craig Shenton

        Hi Dan

        I re-sequenced the application and added the script in at the same time (rather than editing an existing .appv package). Followed your instructions and it now works perfectly.

        This has helped so much I can’t thank you enough but thanks again \o/

  3. Dan

    Not sure if this will resolve our issues, but we are trying to sequence a 64bit application on Windows 7 64bit OS

    We sequence it all okay and it launches on the sequencing PC successfully.

    When tried on a test PC, it will only launch when “run as administrator” is used.

    It will fail if you just try launching it regularly with the error “cannot find C:\Program Files (x86)…

    1. Sounds like it will help then. When you say C:\Program Files (x86)…, what’s after the … ? It should be able to find that directory no matter what. But perhaps it tries to create a file there then open it only to fail. Run a Procmon capture during application launch and look for the result ACCESS DENIED to confirm exactly what’s going on.

      If the fix works I’m glad to have helped, but I recommend that you and anyone else in the same boat open a support call with Microsoft so they are aware that this is something that needs to be fixed! In App-V 4, the sequencer would have captured the original permissions (perhaps the installer adjusts permissions on the file/folder in question) or you had a check box to allow the user to effectively have full write access everywhere. Now the functionality is gone, it limits the number of legacy apps that can be virtualised unless we resort to this less-than-perfect hack.

      1. Francis

        I tried it as you have explained but the script did not run this was what i wrote in the Adobe Acrobat X Standard_UserConfig.xml file :: wscript.exe VFSCACLS.vbs -guid 3621aa16-2389-476f-ab38-5255c4dd6b94 -name “Adobe Acrobat X” -warn </UserScripts and I added the VFSCACLS.vbs into the package at the script section

        1. Try changing the script to just bring up a cmd window first of all, there are multiple stumbling blocks that could prevent scripts running, from having scripts disabled, to not configuring or importing the custom config correctly.

  4. Dan

    Still having the same issue, just to confirm:

    I added the script in the deployment section of the APPV package

    I added the portion mentioned above in the deploymentconfig.xml

    I ran procmon, I didnt see any AccessDenied results – I saw only “File Not Found”

  5. Paul Gibson

    Hello, I have been trying to get this script to run within the DeploymentConfig file, but it will not run, even if I run the application as an admin,

    I have set script permissions, I do know it runs because I use the following within the same config file under MachineScripts, (this grants “Everyone” Full to the C:\ProgramData\”AppvPath” which shows up in the event viewer:


    /c %SYSTEMROOT%\System32\icacls.exe “[{AppVPackageRoot}]\VFS\Common AppData” /grant Everyone:(OI)(CI)F

    But if I run the following command:

    C:\Users\admin>wscript.exe VFSCACLS.vbs -guid 21F7AB27-AA1D-4E5B-B78A-32585
    46AA58B -name “test app” -warn

    It will apply, now my issue is 2 fold:

    1: The script will not run when I open the application, even as an admin with rights to the application.

    2: when I did manually run, I noticed that the C:\Users\admin\Appdata\Local\Microsoft\AppV\Client\VFS\”GUID”\Common Appdata, does not get edited, which is where most of my permissions for apps are needing write access.

    Can you Assist?


    1. I’m not entirely sure how you have this set up, maybe you could post a snippet from your config xml files and tell me if you are using user or global publishing?

      I don’t think the icacls.exe script is necessary btw, from my testing I couldn’t affect any permissions in the virtual environment by messing with the ACLs under [{AppVPackageRoot}]\VFS.

      1. Paul Gibson

        Thank you for your response. I actually now have the scripts running. I was publishing Globally which was not allowing any user scripts to run. That being said. I have another issue.

        Your script does allow the for the write access, but what is odd is when I look at the C:\Users….\VFS\”GUID”, the Common AppData permissions are not changed.

        Which I believe might be causing my application at each launch to show the “permissions have been changed, restart app” comment. as an end user.

        In reference to the the XCACLS, this does change the C:ProgramData…. permissions which is required for access with QuickBooks to write a license file, unless after your script, it may not be needed. Haven’t tested.

        Can you help me understand why the popup keeps occurring?

        Thank you

        1. It should all be explained in the article, but basically the only way to alter the VFS permissions in the bubble is to change the permissions on the folders under the user’s local appdata area. However, since these permissions seem to be read and applied to the virtual environment before the script runs, I put up a prompt warning the user to restart the application. The prompt should only appear on first launch, or again if you ever repair the app. If it’s appearing on EVERY launch, let me know – maybe there’s something different about your package and I might need to tweak the script.

          1. Paul Gibson

            Thank you for your responses. . In order for QuickBooks to run I need to use both your script and the XCACLS.That seems to work fine, other than I am running into a problem with the dreaded “Network Error” when I run the QB application as a Remote App. Not sure why this is quite yet.

            Here is the XML:


            /c %SYSTEMROOT%\System32\icacls.exe “[{AppVPackageRoot}]\VFS” /grant Everyone:(OI)(CI)F

            This is 100% successful for me

            Anyways, so the popup…

            For Adobe Acrobat XI, with out your script it would fail to run unless I was an admin. With your script it will run (after a second launch), but the popup comes up EVERY time. No errors though. What can I give you, so you know what is happening.


  6. Jan-Kees de Rijke

    Hi Dan,

    Thank you for your script! I had the same problem as Paul describes. When I take a closer look at your scritp I saw that you are creating a file in the folder: APPV_ROOTS. When I take a look at my VFS, it does contain a folder APPV_ROOT –> without (S).

    Why is that?


    1. I’m not entirely sure! But I had to choose a folder that was present in all of my packages and APPV_ROOTS seemed to fit. If you have no such folder then just change it to something that does exist, it’s only used to check if the permissions have already been applied.

  7. Paul

    Thank you again, can you tell me where do I change the folder selections in your script? I am not a scripting guy. Looks like that is in a couple of places.

    Thank you sir

    1. I’ll update the script later, it might be a simple case of search/replace APPV_ROOTS with APPV_ROOT; however I think the latter may have write access by default so it would be no good as the folder is used as a quick check to see if permission changes are required. I might need to rewrite this from scratch to make it more robust!

      I’d be interested to know if all the sequences you two are generating have only APPV_ROOT and not APPV_ROOTS – if so, perhaps you are using a different sequencer version to me, or you are deleting something when cleaning up the package that I’m not?

      1. Quinn Woods

        Have you had an opportunity to rewrite this? I cannot get it to work correctly with the Attachmate Extreme client.

        1. Where is it falling over exactly? The only issue I am aware of is where someone had a package that did not have a %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\PackageGUID\APPV_ROOTS, and the fix is to replace APPV_ROOTS with any other folder that does exist in there where the user cannot write to, such as the ProgramFiles one.

          If your package has an APPV_ROOTS folder in this location and you have some other issue, let me know and I can look into it.

          1. QUinn Woods

            I have a Root directory and a Scripts directory. I modified the vbs script to see if that was the issue and I can’t get it to work. I must have a syntax error.

          2. First of all, is the script even running? Make sure you’ve got it launching properly first as that could be your issue. Secondly, when you mention the Root and Scripts directory, that makes me think you are talking about the package contents rather than the user VFS folders under %localappdata% I referred to above?

          3. Quinn Woods

            Ok, I now have the script running correctly with APPV_ROOT. My issue appears to be deeper with Attachmate Extreme. I thought that granting write access to this folder would resolve it. Unfortunately it does not. All of our Attachmate products are suffering from the same C++ runtime abnormally terminated error. This is only an issue with App-V 5.0, 4.6 works great using Attachmate’s installation recipe.

          4. I’m having the same issue, I attempted to sequence 9.0 a couple of weeks ago and have been waiting to get my hands on the latest 9.3 patches before troubleshooting further. Perhaps try t the traditional method of deploying vcredists natively before sequencing and then manually on the client?

          5. Quinn Woods

            The method of installing the vcredists unfortunately does not work. I get the same error message. Let me know if you discover a resolution for this.

          6. You could try the latest hotfix that has just been released – you never know:

            I will give this a go tomorrow, but if you get a chance to try it before then, please report back!

          7. Quinn Woods

            Were you able to get the Attachmate client to install correctly? I was not successful with SP2 HF1.

          8. Mathias

            Seems like I can join the club. We deploy our our clients with the full set of VC++ redists because we’re slowly shifting from tradition packaging to App-V. I have tried 9.0, 9.0 SP2, 9.2, 9.2 SP1 and 9.3 versions of Attachmate EXTREME! and they all give me exact the same error as you’ve mentioned. Tomorrow I will give App-V SP2 HF2 a try, as HF1 has been retired.


            Did anyone get it working meanwhile?

          9. The App-V hotfix does not help, but the latest patches for 9.3 apparently fix the issue! I’ve not been able to try for myself yet as I’m still waiting for the customer to obtain the patch which needs a login to download.

          10. Mathias

            I did so and checked for any available hotfixes or updates for Attachmate 9.3 together with my collegue who has login credentials to the attachmate portal but unfortunately didn’t find any. Do you know maybe if it is a private fix, that needs to be requested?

          11. I haven’t got my hands on the patch yet (customer is very slow to respond!), but a previous comment from Quinn Woods on this very page says:

            “The issue is rooted in how app-v 5 captures the app-v environment. Attachment recognised this gap and resolved it in xtreme 9.3 HF1. Problem resolved.”

          12. Quinn Woods

            I have the patch if you want it. Do you have a method for me to share with you?

          13. Sure, I’ve sent you an email, let know if you did not receive it.

          14. I have been trying the same from past one month . Have any one got sucess with the new 9.3HF1 . ? I was not able to find the HF1 . Can you share HF1?

          15. I have a copy of it but unfortunately I only have 9.0 and am waiting for the person with the login credentials to get me the 9.3 update! I can forward a link onto you later, but if you have a login you can obtain it from Attachmate direct.

          16. Mathias

            Meanwhile my collegue added me to the Attachmate corporate account, so I am able to browse myself. Unfortunately there is no (official) 9.3 HF1 available. I will now try with the App-V 5.0 SP2 HF4. Alternatively we’re also looking to switch to the successor of Attachmate called Reflection, as we’re under maintenance. If I’ll have any luck I’ll post it here…

  8. Pingback: Sequence Adobe PhotoShop CS5 using Microsoft App-V 5.0 | IT Tech Log

  9. Pingback: Virtualize Adobe PhotoShop CS5 using Microsoft App-V 5.0 | IT Tech Log

  10. Check out this App-V 5.0 Powershell Script for setting Custom Security rights (Set-Acl) for the [{AppvPackageRoot}] (or any other App-V directory). It’s also very usefull for managing access to virtual Add-ins / Plugins in a (Office) Connection Group:

  11. Pingback: How to solve the App-V 5 file permissions with AppSense | IT Tech Log

  12. Pingback: App-V 5: On Explaining this New VFS to Softgrid Users - GLADIATOR@MSFT - Site Home - TechNet Blogs

  13. Pingback: App-V 5 Annoyances | IT Tech Log

  14. Pingback: App-V Decision Matrix v 4.0 |

  15. Pingback: Microsoft App-V: Dynamic Configurations or RES Workspace Manager? » Ingmar Verheij - The dutch IT guy

  16. Pingback: Webinar: Getting to Know App-V 5.0 SP2 |

  17. Quinn woods

    unfortunately it did not work for me let me know if it works for you.I still get the “runtime error! Abnormal program termination”.let me know what your results are.

  18. rileyz

    Heya Dan,

    First of all, just want to say many thanks for your VFScacls script, Ive used it many times so super handy with Adobe products.

    Now since this was written with app-v 5 SP1 in mind, I was wondering if you have had any issues with it in app-v 5 SP2? I trying to use it but I get the dreaded “This may be due to a network failure. Error code 0x0FD01B25” error. Weird thing is it works fine in App-V 5 SP1!

    Just doing a sanity check, I suspect its a App-v 5 SP2 thing ):

    Cheers, Riley.

    1. Hi, no I haven’t tried it again in SP2, so will do so as soon as I get the chance! Have you checked the event viewer for more info on the error?

    2. By the way, if it’s causing a problem, an alternative in many cases is to set your PVAD to the folder that needs write access. Out of interest, which Adobe products have you found that need this script and where are they trying to write to?

      1. rileyz

        Thanks for replying Dan, much appreciated.

        Adobe (grrrr, lol), with the Adobe products the user needs access to “ProgramData\Adobe\SLStore” and “Program Files\Common Files\Adobe\Adobe” (varies on x86 x64) to licence the product correctly, even with serialization. I did think of the PVAD idea, but alas only resolves one issue. This all stems from Adobe: Error 16 issue which crops up in series CS5, and to a lesser extent the consumer versions of products that uses the same line of licence activation developed around that time.

        I’ve done some more research into the issue and its not your script causing the issue, I suspected it wasn’t but wanted to double check – sorry about the false alarm there! Its something to do with SP2 – I tried a simple test appv package to launch notepad.exe with and it throws the same error.

        So Im thinking its a SP2 configuration issue – guess I will be log debug diving for the next few hours.

        Will get back to you with notes when I get it resolved.

        1. Thanks, I’ve not had time to look into this yet. Sorting the Adobe issues is the next thing on my agenda after I’ve finished the Java series!

  19. Quinn woods

    I actually figured it out. The issue is rooted in how app-v 5 captures the app-v environment. Attachment recognised this gap and resolved it in xtreme 9.3 HF1. Problem resolved.

    1. Excellent, thanks for the update – I am still awaiting my customer to get back to me with the Attachmate patches I requested, hopefully they do the job!

  20. Ian Clegg

    Hello Dan, just wanted to let you know that I’ve overcome the security issue for two applications that would error when run as non admin by modifying the VFS folder permissions in the C:\ProgramData\AppV. I had security issues with Sage Accounts 2013 and Dreamweaver CS5, giving the user write access here got both applications working and the permissions replicated into the users profile VFS folder

    1. Thanks, I’ll try this myself with another app I’ve just found that needs permissioning. This was the method that I first tried however and couldn’t get it to work back then, permissions were always copied from the local folders.

      1. Nope sorry, just tried again and the only way that works for me is the method described in the post! I adjusted the permissions on the folders under programdata, but the equivalent folders under %LOCALAPPDATA% just ignore them and copy the permissions from the local folders, just as I found originally.

  21. Hey Dan, firstly I want to thank you for how well your scripts have been working. I ran into an odd issue. the scripts were working on the same application, then I added another app to my clients machine and started getting this on all machines.

    ERROR: Unable to locate folder VFSPath.

    I know its part of your script, but where do I go to find the issue?

    Thank you

    1. The script looks for the local appdata location under here: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Local AppData.

      It then appends \Microsoft\AppV\Client\VFS\, followed by the Package GUID (you did supply the package GUID as a parameter to the script, right?).

      Put that all together and that’s the folder it’s looking for. It won’t exist when an app is first published but should be created on first launch of the app. Have any of the apps been placed in a connection group? I’ve not tested this scenario but I imagine you’d need to supply the GUID of the connection group instead, assuming they store user changes in the same location as regular packages.

  22. Following on from the commend earlier about this not working in SP2, I’ve managed to prove, that in my test environment at least, StartVE (and possible all user mode scripts) are broken in SP2 if you are logged on as a local account. The script works if logged in as a domain account. Whether the account is a standard user or admin seems to make no difference. More testing to follow, expect a post discussing this when I’m done!

  23. Ian Clegg

    Hi Dan, just looked at this again, this is confusing the life out of me. I’m deploying through SCCM 2012, I’ve just removed modifying the VFS folder so no changes to permissions. If I login to pc as non admin and launch Dreamweaver I see the error 16 which is the same as the Photoshop CS5 talked about earlier. If I log off and back on, launch Dreamweaver it works, no error. I tried another non admin user and it errors first launch for them, I log off and back on and it works 2nd time. These users have Mandatory profiles and I’ve checked they get deleted so I’ve no idea what is happening.

  24. Uzoma Obi

    Hello Dan,

    I have found your script very useful. I have used it will a few applications that require users have write permissions for the application to function correctly.

    I have one issue and one issue only on my current project. I have found out that applications that use the script, when published globally (Per Machine) the permissions are set without any issues. But when the application is published Per user the script does not run at all.

    Does this method of setting permission using APP V 5.0 only work for applications published globally?

    1. It should work for apps published to users also. Have you tried putting the script in the UserConfig.xml?

  25. chris

    Hi Dan,
    all sorted

  26. Very good post. I’m going through some of these issues as well..

  27. Bart Chevalking

    Hi Dan,

    Your Script works perfect! The only thing is…. after a reboot the extra permissons are removed and the script doesn’t work anymore…
    Any idea?


    1. No idea sorry, but I recommend updating to at least Hotfix 4 which renders this script mostly obsolete!

  28. chris

    Hi All,
    i have upgraded to hotfix 4 and this does NOT fix the issues on VFS permissions, i can tick the box on the sequencer to give rights to the VFS but it still errors for Adobe products with the error 16.
    has anyone successfully got this working without the need for the script?

    1. Works fine for me on all Adobe apps I’ve tried so far.

  29. Andy S

    I have the script working howbver client has disabled VB scripts, awesome.. Was this rewritten in Powershell by any chance??

    1. No, but the script is obsolete note since SP2 Hotfix 4 (or SP3) add a checkbox to enable write permissions!

  30. Andy S

    Well the app went to test and failing on permissions – I still have to sequence on sp2 Hotfx2 and no vb scripting allowed either.
    I assumed (perhaps wrongly ) by setting the PVAD to the caching folder C:\Program files\Cached Files this would then give users full writes to do this as app requires this as it is a hardcoded path.
    Would the PVAD inherit permissions if installing to c:\Program files ??

    1. The users should have full write access to the PVAD except for all the file extensions listed here:

      You can verify this for yourself by opening up a command prompt in the bubble as a standard user and trying to write to that location.

Leave a Reply