• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Fixing File Permissions in App-V 5

Written by Dan Gough on. Posted in App-V v5.x

UPDATE: Microsoft have now resolved these permissions issues in App-V 5.0 SP2 HF4: http://support.microsoft.com/kb/2956985

There is still no solution if you need to write any of the restricted filetypes in the VFS however as discussed here: http://www.virtualvibes.co.uk/cow-and-its-exclusions-in-app-v-5-0/

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.

LocalAppDataVFS

Example default permissions:

permissionsbefore

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:

permissionsafter

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!

 

Tags:

Trackback from your site.

Comments (80)

    • Chris

      |

      Hi
      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

      Reply

      • Dan Gough

        |

        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).

        Reply

        • 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 \\10.1.1.9\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?

          Reply

          • Dan Gough

            |

            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?

            Reply

    • 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 = “AMO.dot”
      [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
      Copy-Item $COW_VFS_PATH\$APPGUID_TMP -Recurse $COW_VFS_PATH\$APPGUID

      # 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
      Copy-Item $PACKAGE_VFS_PATH\$APP_FILE_PATH\$APP_FILE_NAME $COW_VFS_PATH\$APPGUID\$APP_FILE_PATH\

      # 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
      $DESTINATION = $COW_VFS_PATH + “\” + $APPGUID + “\” + $FOLDER

      # Get the current Security Descriptor from new COW folder
      $ACL = GET-ACL $DESTINATION

      # 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
      $ACL.AddAccessRule($FileSystemAccessRule)
      }
      }
      # Apply the modified Access Control List
      SET-ACL $DESTINATION $ACL
      }

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

      Reply

      • Dan Gough

        |

        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*

        Reply

        • 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.

          Reply

          • 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 …

            Reply

          • Dan Gough

            |

            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!

            Reply

          • Quinn

            |

            FYI everyone:

            Just released yesterday:
            http://support.microsoft.com/kb/2956985
            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.

            Reply

          • Dan Gough

            |

            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: http://www.virtualvibes.co.uk/cow-and-its-exclusions-in-app-v-5-0/

            Hopefully this script is now redundant!

            Reply

  • 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:
    http://blogs.technet.com/b/appv/archive/2012/12/10/scripting-and-embedded-scripting-for-appv-5-0-dynamic-deployment-and-user-configuration-scripting.aspx

    “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

    Reply

    • packageologist

      |

      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)

      Reply

      • 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/

        Reply

  • 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)…

    Reply

    • Dan Gough

      |

      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.

      Reply

      • 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

        Reply

        • Dan Gough

          |

          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.

          Reply

  • 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”

    Reply

  • 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:

    cmd.exe

    /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?

    Paul

    Reply

    • Dan Gough

      |

      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.

      Reply

      • 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
        Paul

        Reply

        • Dan Gough

          |

          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.

          Reply

          • 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:

            cmd.exe

            /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.

            Paul

            Reply

  • 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?

    Jan-Kees

    Reply

    • Dan Gough

      |

      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.

      Reply

  • 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
    Paul

    Reply

    • Dan Gough

      |

      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?

      Reply

      • Quinn Woods

        |

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

        Reply

        • Dan Gough

          |

          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.

          Reply

          • 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.

            Reply

          • Dan Gough

            |

            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?

            Reply

          • 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.

            Reply

          • Dan Gough

            |

            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?

            Reply

          • 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.

            Reply

          • Quinn Woods

            |

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

            Reply

          • 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.

            http://support.microsoft.com/kb/2934349/EN-US

            Did anyone get it working meanwhile?

            Reply

          • Dan Gough

            |

            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.

            Reply

          • 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?

            Reply

          • Dan Gough

            |

            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.”

            Reply

          • Quinn Woods

            |

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

            Reply

          • Dan Gough

            |

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

            Reply

          • kiran sunkara

            |

            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?

            Reply

          • Dan Gough

            |

            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.

            Reply

          • 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…

            Reply

  • Jeroen

    |

    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: http://www.getonict.nl/blog/app-v-blog.html#app-v-set-acl

    Reply

  • App-V Decision Matrix v 4.0 |

    |

    […] locations during run-time. Dan Gough has you covered on this if you follow his instructions HERE Also as pointed out to be by Dan, branched upgrades which were possible in previous versions are no […]

    Reply

  • 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.

    Reply

  • 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.

    Reply

    • Dan Gough

      |

      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?

      Reply

    • Dan Gough

      |

      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?

      Reply

      • 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.

        Reply

        • Dan Gough

          |

          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!

          Reply

  • 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.

    Reply

    • Dan Gough

      |

      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!

      Reply

  • 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

    Reply

    • Dan Gough

      |

      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.

      Reply

      • Dan Gough

        |

        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.

        Reply

  • Paul GIbson

    |

    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
    Paul

    Reply

    • Dan Gough

      |

      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.

      Reply

  • Dan Gough

    |

    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!

    Reply

  • 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.

    Reply

  • 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?

    Reply

    • Dan Gough

      |

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

      Reply

  • chris

    |

    Hi Dan,
    all sorted

    Reply

  • google.com

    |

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

    Reply

  • 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?

    Bart

    Reply

  • 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?
    Regards
    Chris

    Reply

    • Dan Gough

      |

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

      Reply

Leave a comment