locked
App-V and Non Persistent Desktops RRS feed

  • Question

  • We are deploying a VDI solution based around Xendesktop 7.1 with pooled (non-persistent) desktops using APP-V 5.0 SP2 in Shared Content store mode.

    When a user logs in for the first time the AppV start menu icons are created and user can then launch the apps fine.  The user can logout and then back in again and this again works fine.  The problem occurs when the desktop is rebooted, when they log back in the icons for the App-V apps are blank and attempting to launch the apps throws up an error as its still in the process of downloading files into %PROGRAMDATA%\appv and creating the junction points in %LOCALAPPDATA%\Microsoft\appv\client\integration which are not persistent with the pooled desktops.

    Even once the above has completed the icons still remain blank but the apps do launch OK.  The only way to get the icons back is to logoff and log back in.

    We have user refresh on logon enabled in the publishing server settings.

    This is going to confuse the hell out of users as firstly they will see blank icons and secondly as soon as they start clicking on them they are going to get errors about files not found.

    Does anyone know a way to get it to behave in a similar manor as it does at first logon, so the icons are recreated and the end user doesn't see the icons until they are ready to use.

    Thanks

    Mark.


    Monday, March 31, 2014 4:11 PM

Answers

  • Thanks for the replys,  I've now excluded %APPDATA%\Roaming\Microsoft\AppV\Client\Catalog from the roaming profile.   I've also created a powershell script which runs as a group policy logoff script to remove any appv icons from desktop and start menu when the user logs out.  The icons get recreated when the user logs back in.  Rather the user has to wait a little while for the App-V icons to appear than them clicking on blank icons and getting file not found errors.

    function DeleteAppVShortcuts($sourcepath) {
    $sc = Get-ChildItem -recurse $sourcepath -include *.lnk
    $sh = New-Object -COM WScript.Shell
    foreach ($_ in $sc)
    {
        $target = $sh.CreateShortcut($_).targetpath
        
        if ($target -like "*appv*") {
            remove-item $_.FullName
            
            }
           }
        }
    
    $source = $env:USERPROFILE + "\Desktop"
    DeleteAppVShortcuts $source
    
    $source = $Env:APPDATA + "\Microsoft\Windows\Start Menu\Programs"
    DeleteAppvShortcuts $source
    
    


    Friday, April 4, 2014 9:40 AM

All replies

  • Hi Mark,

    In our non persistent VDI environment (VMWare) we are excluding %LOCALAPPDATA%\Microsoft\AppV and %APPDATA%\Roaming\Microsoft\AppV\Client\Catalog, and publishing works as expected (we are also using SCS).

    We had (still have) issues with how the junction points are created and VMWare Persona, and also with how the COW directories are created under %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\, which is why we are excluding all the way up to %LOCALAPPDATA%\Microsoft\AppV, AND we had to change the default creation of junction points.

    I'm not familiar with Xendesktop, but I would start with the appdata catalog location, which is something you likely don't want to roam with the user.  If it still doesn't work, what you use to roam profiles may have issues with the junction points, and / or the permissions of folders in %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\.

    One thing I'm confused about, when does your environment refresh the machine and upload the user's profile?  At logoff, reboot, or both? 

    Monday, March 31, 2014 5:09 PM
  • If I was you I would take a look at logs from a reboot to see what's going on. You might have something which is managing the user settings\data that is interfering with your App-V directory...

    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon

    Tuesday, April 1, 2014 3:35 AM
  • Thanks for the replys,  I've now excluded %APPDATA%\Roaming\Microsoft\AppV\Client\Catalog from the roaming profile.   I've also created a powershell script which runs as a group policy logoff script to remove any appv icons from desktop and start menu when the user logs out.  The icons get recreated when the user logs back in.  Rather the user has to wait a little while for the App-V icons to appear than them clicking on blank icons and getting file not found errors.

    function DeleteAppVShortcuts($sourcepath) {
    $sc = Get-ChildItem -recurse $sourcepath -include *.lnk
    $sh = New-Object -COM WScript.Shell
    foreach ($_ in $sc)
    {
        $target = $sh.CreateShortcut($_).targetpath
        
        if ($target -like "*appv*") {
            remove-item $_.FullName
            
            }
           }
        }
    
    $source = $env:USERPROFILE + "\Desktop"
    DeleteAppVShortcuts $source
    
    $source = $Env:APPDATA + "\Microsoft\Windows\Start Menu\Programs"
    DeleteAppvShortcuts $source
    
    


    Friday, April 4, 2014 9:40 AM
  • We exclude the following locations from copying up in the users profiles:

    AppData\Local\Microsoft\AppV

    AppData\Roaming\Microsoft\AppV\Client\Catalog

    Saturday, April 12, 2014 12:46 AM
    Moderator
  • We exclude the following locations from copying up in the users profiles:

    AppData\Local\Microsoft\AppV

    AppData\Roaming\Microsoft\AppV\Client\Catalog

    AppData\Local is excluded by default - is this something you've had to explicitly add for your environment?


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or other MVPs.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V

    Saturday, April 12, 2014 5:53 AM
    Moderator
  • Appdata local is excluded from roamingby default but prior to appv 5 we had it turned on. Because of how appv creates the COW folders, VM ware persona would copy the data up but bring it back without all the crazy permissions... Breaking publishing. We also had an issue that we worked with VM ware to resolve where persona would not allow junction points to be created, again breaking publishing. That fix may not be available to customers yet. 

    Sent from my phone. 

    Sunday, April 13, 2014 1:02 PM
  • Aaron,

    I'll need to circle back and see why I explicitly added that in. 

    Monday, April 14, 2014 8:31 PM
    Moderator
  • Hi, we use View Persona with non-persistent desktop pools and app-v 5 and I'm having issues with the app-v junction points not being recreated. Could you share what VMware provided you with regards to a fix for junction points and View Persona?

    I cant find any public reference to a fix for this issue, so would appreciate any information you have.

    Thursday, May 22, 2014 5:14 AM
  • The SR we placed was 13334836906, and we worked with Kirk Jones at VMWare (we being Prudential).  I do not have the Agent version that this will be 'fixed' in however.  If you need more info by all means let me know.  This was only wrapped up maybe 2 months ago with them.

    Regarding the fix, what VMWare did was to allow junction points to be created in folders monitored by persona.  The junction points will NOT be synched with the users roaming profile, just excluded.  We also have non-persistent pools, and ended up using as a permanent workaround setting the App-V 5 client to use a different spot for junction ponits.  You can do this via the command

    Set-AppVClientConfiguration -IntegrationRootUser C:\mydirectory

    This will cause the App-V 5 client to place junction points for the user to a different location.  In our environment we are using a dir off of C:\, just make sure you ACL the folder for the user.

    FYI -- We are NOT able to roam the localappdata App-V COW stuff with persona, only the %appdata% stuff.  Persona chokes on the crazy permissions of the \VFS folders.

    Thursday, May 22, 2014 4:00 PM
  • Appreciate the information. We mainly use floating pools, so I have tested out changing the user integration path to a folder off of c: drive as opposed to the users profile. From my testing this works well, as the junction points now get created each time I log onto a new virtual machine, which wasn't occurring with View persona and the local appdata path.

    I haven't tested roaming the localappdata\Microsoft\AppV\VFS path as yet, but will test that out. Hopefully this shouldn't be too much of an issue (assuming it doesn't work) in that these settings are not as important as the appdata settings.

    Are you using App-V Full Infrastructure deployment for your VDI? We currently have SCCM 2012 integrated App-V and I'm testing with the new App-V 5 SP2 hotfix4 client update with the Preserve User Integrations setting turned on for the VDI machines and shared content mode enabled.

    If I pre-add the App-V packages to the base image (not publish), once a user targeted app is installed for a user, these apps and shortcuts remain available at the next logon and can be launched straight away without waiting for the sccm client to reinstall the application again. It would be nice not to have to pre-add the package, but it takes too long to re-evaluate at each logon (at least in sccm integrated scenario).

    Friday, May 23, 2014 6:38 AM
  • Hey I'm sorry I missed that you had responded.  We are in a similar boat, primary using floating pools, although we do currently support App-V on physical machines and dedicated VMs. 

    I would assume you get the same experience with roaming the %localappdata% VFS folders, if you are able to get somewhere let me know.  At the end of the day MS is breaking best practice by applying the weird permissions, but my argument has been that VMWare should support us doing that, forget the reason.  If I want to apply crazy permissions on my folders, I should be able to.

    We use full infrastructure for all floating, and SCCM (not yet on 2012) on all physical.  We also tried the preserve user integrations but without pre-adding packages but didn't see a huge gain.  I will say this is something we mean to revisit when we have time.  As I'm sure you have seen, App-V 5 publishing isn't exactly fast.  I am not convinced there isn't something wrong with our setup, we see delays of 30-90 seconds before the progress bar even starts.  We have engaged MS multiple times on this however.

    We are back and forth about using SCS.  Everything I've seen about it makes me happy except that (I believe) you can't configure packages to use feature blocking when not on SCS, and fault tolerance when on SCS.

    If you pre-add packages to our image, I'm assuming you miss the add-package script window correct?  Many of our packages have scripts that need to run elevated, and since we are targeting users that's our only way to do it.  Really wish we had other options to run things as system.

    Please feel free to reach out to me via email if you'd like, always good to be able to bounce stuff off others in the same boat.  I have my email in my profile.

    Tuesday, June 3, 2014 8:13 PM
  • According to Citrix article (http://support.citrix.com/proddocs/topic/user-profile-manager-5-x/upm-using-with-app-v.html).   I know that this is specific to the Citrix UPM solution, but would I think that the recommended exclusions would be the same regardless of your profile management solution.

    You must exclude the following items using Profile management
    exclusions:

    • Profile Management\File system\Exclusion list\directories:
      • AppData\Roaming\Microsoft\AppV\Client\Catalog
      • AppData\Local\Microsoft\AppV
    • Profile Management\Registry\Exclusion list:
      • Software\Microsoft\AppV\Client\Integration
      • Software\Microsoft\AppV\Client\Publishing
    Tuesday, June 3, 2014 9:42 PM
    Moderator
  • The Performance Guidance for AppV 5 that was published on 5/1/2014 is great!

    http://technet.microsoft.com/library/dn659478.aspx

    Using App-V 5.0 Sp2 Hotfix 4 with all user targeted applications, after applying the following registry setting, the start menu integrated shortcuts have only taken a few seconds to load now (compared to 15 to 30 seconds before). 

    HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Integration\
    PreserveUserIntegrationsOnLogin = 1

    Additionally, we've been moving to using SCS on the RDS clients, and the performance has actually been better with SCS.

    Tuesday, June 3, 2014 10:06 PM
    Moderator
  • No worries, good to hear back. I'm trying to use SCCM 2012 R2 integrated VDI with App-V as we use SCCM 2012 and App-V for our physical desktops so ideally we don't want to setup App-V full infrastructure for just floating VDI.

    I've done some testing and I can pre-add App-V packages to the gold master image using an sccm task sequence - this installs the packages globally. I then have another step to globally unpublish the app-v apps so that the packages are added but not available (only stub files as we use shared content store). The gold master has the preserve user integrations enabled.

    Once this gold master is available in the floating pool, the first time a user logs on it takes a little while for the user published app-v apps to come down being sccm integrated. These only perform a publish operation as the packages are already added in the base.

    However at the next logon, as the integrations are stored in the persona profile, the user can launch all these applications straight away which is great.

    The issue I currently have is with SCCM Virtual Environments (Equivalent of connection groups). The task sequence, for some reason doesn't create the Virtual Environment and I cant find a way of creating these in the base as yet. These will be added/enabled for each user on the floating pool but this takes a little time to kick in, so I'm trying to figure out if there is a way to do this.

    I don't think you will lose the ability to run the scripts when adding the package to the base - it will just run them against the gold master which I assume is where you would want them. Any user scripts would then run on the first publish.

    Check out http://www.loginconsultants.com/en/about/blog/all/item/first-results-app-v-5-sp2-hotfix-4 - they have seen huge improvements on a 400 seat VDI after using hotfix 4 and PreserveUserIntegrationsOnLogin = 1.

    From 4 minutes down to 12 secs for publishing (with pre-caching).

    They only include in their profiles, so I'm not sure that the localappdata\Microsoft\AppV\VFS is necessarily required.

    <AppData>\Microsoft\AppV\Client\Catalog
    <AppData>\Microsoft\AppV\Client\Integration

    Wednesday, June 4, 2014 7:18 AM
  • Thank you both very much for the info.  In our environment a lot of our packages have script to install drivers, etc, that I don't believe we could put into our master image - so I don't think we would be able to do the add-package of all packages into our image because there would be bits of code (some licensed) live on machines that aren't supposed to have it.

    What are you guys doing?  Do you have any concerns with licensing and putting licensed code into a master image even if users can't use it without being provisioned in AD?  I'm NOT asking anyone to put themselves on the hook for licensing and if you don't want to answer in a public forum I totally understand, but I know that would be a point of resistance for us.

    If you are pre staging the packages, are you allowing driver installs etc that require admin rights to run during the add-package?  With user targeting, we don't have any other native way to run prereqs elevated, and unless I'm missing something we can't force global publishing (giving us a system script at machine/pubish) to a user AD group in full infrastructure.

    Or do you guys do something totally different that I'm missing, like pre add the packages with no drivers and use SCCM 2012 and task sequencer to do that?

    Wednesday, June 4, 2014 7:14 PM
  • We don't pre-add anything at all in ours, everything is streamed and user targeted.  Since the content shares and the pooled XenDesktop machines are in the same Data Center, the time to launch applications is minimal.

    Here's what our config looks like:

    • Full App-V infrastructure (not using SCCM to deliver App-V apps)
    • PackageInstallationRoot = D:\App-V (which is a persistent disk thats locally attached to each of the pooled machines.   Each machine has its own)
    • SCS Mode:  We are in the process of turning this on for our pooled machines, but currently we have the majority running with SCS off.  The performance is better with it on though, and the disk savings is great.
    • HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Integration\
      PreserveUserIntegrationsOnLogin = 1

    Roaming User Profiles are configured with the following exclusions:

    • Profile Management\File system\Exclusion list\directories:
      • AppData\Roaming\Microsoft\AppV\Client\Catalog
      • AppData\Local\Microsoft\AppV
    • Profile Management\Registry\Exclusion list:
      • Software\Microsoft\AppV\Client\Integration
      • Software\Microsoft\AppV\Client\Publishing

    Our core images, prior to sealing them up are handled as follows:

    • Prior to logging out of the machine for the last time, Get-AppVClientPackage - All | remove-appvclientpackage
    • Remove any package remnants from the registry in HLKM (..\client\packages\(del all subkeys), ..\client\streaming\packages\(del all subkeys), ..\MAV\configuration\packages\(del all subkeys)
    • Completely delete the D:\App-V folder if it exists
    • Delete C:\ProgramData\Microsoft\AppV folder if it exists

    To ensure that the the machines come up clean, we use the following Startup script on each:

    powershell -Command Import-Module "AppVClient"
    powershell -Command "Get-AppvClientPackage -All | Remove-AppVClientPackage"
    net stop AppVClient
    takeown /F "D:\App-V\*" /R /D Y
    icacls "D:\App-V\*" /grant System:F /T /C
    icacls "D:\App-V\*" /q /c /t /reset
    rmdir "D:\App-V" /S /Q 
    rmdir "C:\ProgramData\Microsoft\appv" /S /Q
    net start AppVClient
    • Additionally, because of some inconsistent performance in regards to the rmdir "D:\App-V" /S /Q command, I have a scheduled task that runs 5 minutes after a system is restarted that runs the following script as well to ensure that the D drive package cache is cleared
    net stop AppVClient
    rmdir "D:\App-V" /S /Q
    net start AppVClient

    Our machines are all restarted on Sunday mornings, during a time that users will not be trying to access them.

    This all might seem a bit excessive, but the goal is to ensure that when a machine is spun up, that the Users roaming registry, Machines registry, Machines C:\ProgramData\Microsoft\AppV, and Machines AppV Cache are all in the same state.  If one of these isn't, you will experience issues such as the applications only launching one time, the icons (integration points) not showing up for users at times, or the client service not starting at all.


    Wednesday, June 4, 2014 7:57 PM
    Moderator
  • Hello,

    If the application requires a driver or other component, we install a driver or other component beforehand. Scripting using the add-package trigger is just one method to achieve this, however any additonal deployment method will also achieve this.

    If you are restricted to install something on a machine due to the fact that it will be available for everyone in a  shared Environment you would either need to discuss this with the licensing party, or isolate the machine from the users who are not licensed to use it.

    In general, if someone is using a machine and there are ways that the machine can have a baseline that would avoid a scenario where something is installed at any given point during this usage I always install Components as long Before as possible.


    Nicke Källén | The Knack| Twitter: @Znackattack

    Wednesday, June 4, 2014 8:02 PM
  • Hi Cody, thanks for the detailed information.

    Just to confirm, are you running non-persistent desktops i.e. they get wiped completely at each logoff?

    As you aren't caching any app-v packages within your gold master image, how long does it take following a user logon to a floating pool machine before they see all their App-V shortcuts, now that you are using hotfix 4 for app-v 5 sp2? I know you said a few seconds, but just to confirm exact timings.

    How many app-v applications would be published to the user in this time? If the speed is pretty good in this scenario, then this is a better alternative to pre-caching the app-v apps into the gold master and would required much less ongoing maintenance.

    Also, what's the reason for having the PackageInstallationRoot on D:\ ? Is this a legacy setup as you weren't using shared content store originally and these persistent disks were placed on faster storage etc?

    Wednesday, June 4, 2014 11:29 PM
  • The machines get completely wiped at each restart.  Nothing is cached at all in the master image.  We are using the 5.0 SP2 Hotfix 4 RTS client.  The timing to get the icons can vary depending on the amount of applications because of all of the integration points, but if you disable all of the unused integration points in all your packages it greatly helps.  I'll give you a few different timing scenarios though so that you can see what I mean.   My timings are done with users that have at least 7 to 10 applications via App-V.   With this amount of applications, and none of them optimized yet (by disabling unused parts of the package), the icons are being delivered in less than 10 seconds of users being able to see the start button to click on it.  Prior to Hotfix 4 and the PreserveUserIntegrationsOnLogin=1 setting, this would take from 30 to 60 seconds to populate the icons.

    Now, about the PackageInstallationRoot on D.

    In our environment, we already stored all of the EventLogs for each machine on a persistent D drive.  So, when we encountered the issue Nicke Kallen helped to identify, where when using versions of Citrix PVS prior to 7.1.1 (could be off on the exact version), we decided to see what happens if we moved the packageinstallationroot to this persistent location during testing.  Since it fixed the issue, and we weren't ready to upgrade PVS (we were using version 5. something at that point), we decided to go with it. 

    Thursday, June 5, 2014 2:14 PM
    Moderator
  • Thanks Cody, it sounds as though the performance improvements around publishing and preserving user integrations has made a great difference to your setup.

    I think 10secs or less for a user to get their published apps in a floating VDI environment is more than acceptable. Not sure that we can achieve this with sccm integration however - hopefully this will change in the future.

    For the PackageInstallationRoot, I'm not aware of this issue - we use VMware View for VDI, but thanks for the info.

    Thursday, June 5, 2014 11:57 PM
  • Thanks Mark i took your code and change a pair of things, remove the parent folder of those links and take care to not remove the entire sourcepath

    function DeleteAppVShortcuts($sourcepath) {
    $sc = Get-ChildItem -recurse $sourcepath -include *.lnk
    $sh = New-Object -COM WScript.Shell
    foreach ($_ in $sc)
    {
        $target = $sh.CreateShortcut($_).targetpath
        
        if ($target -like "*appv*") {
            if ($_.Directory.FullName -eq $sourcepath){
            # we don`t want remove e.g the entire desktop folder, do we ??
            remove-item $_.FullName}
            else {
            remove-item $_.Directory.FullName -Force -Recurse}
            
            }
           }
        }
    
    $source = "\\ProfileHost\UserProfiles$\" + $env:USERNAME + "\UPM_Profile\Desktop"
    DeleteAppVShortcuts $source
    
    $source = $Env:APPDATA + "\Microsoft\Windows\Start Menu\Programs"
    DeleteAppvShortcuts $source

    Wednesday, March 29, 2017 12:22 PM