locked
Interaction between App-V 5.1 client and HKCU\Software\Classes\Applications RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

    I have a question regarding the registry key HKCU\Software\Classes\Applications and published App-V packages.

    We are running App-V 5.1 on Windows 7 x64. For userprofile management we use VMware UEM. Cached userprofiles are removed when logging off. We have not configured in UEM to save this Applications key. So it is (also) removed when logging off.

    After publishing a package to an user, the application path is registred there. The strange thing is that, after logging off and on, not all App-V applications are reregistred there.

    I know I can configure in UEM to save the Applications key. But I want to know why some applications reappear there and others not.

    Can anyone explain how this mechanism works?

    Tuesday, February 6, 2018 11:57 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    No, only applications with shell extension you'll find here. If you are looking for user based published appv apps, you must look under: 

    HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages

    Why would you save that key? If a user logs on for the second time, appv will sync again and publish the app (incl it's extension points).

    Roy Essers

    Friday, May 4, 2018 10:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Why would you save that key? If a user logs on for the second time, appv will sync again and publish the app (incl it's extension points).

    Roy Essers

    We use SCCM integration and mandatory profiles. If we don't save certain App-V client data, App-V packages won't work after next logon. Because there is no refresh.

    After a few years experience with this integration, my conclusion is that it does not work well. At least in our scenario. We had a lot of problems. I am glad that we are moving (back) to App-V FI.

    Friday, May 11, 2018 7:13 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    So you target those appv packages to machine collections, and after a package is rolled out though config manager machine bases, and a second logon the package does not work (because of mandatory profiles)?

    Roy Essers

    Friday, May 11, 2018 8:36 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Most of the app-v packages are targeted to user collections. So the publishing data is gone at next logon. Maybe it's better to say that the packages are not available immidiately after logon. That's why we use UEM to save and load the roaming app-v data (Appdata and HKCU). And that scenario does not work well. Especially due to stacking virtual environments and synchronization conflicts.

    We also tested with this script but it does not work.


    Friday, May 11, 2018 1:59 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    OK... I think this has something to do with the application deployment evaluation cycle which runs every 7 days (by default).

    Your scenario, like VDI/Citrix with mandatory profiles, is no ideal scenario to use Config Manager for user target App deployment in general (definitely not app-v if you're used to Full Infra). 
    I had a look at the script, and although I have not tested it, I can't see why this should not work….

    Anyhow it it not easier to perform an app deployment evaluation cycle? What happens if you run this manual on the client? Do those app-v apps get published? Also remove those UEM settings first (just for this test).

    If this works, you could use the following script at login, to force a app deployment eval:

    Invoke-WMIMethod -Namespace root\ccm -Class SMS_CLIENT -Name TriggerSchedule "{00000000-0000-0000-0000-000000000121}"|Out-Null

    Roy Essers

    Friday, May 11, 2018 7:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    try to use the following registry key:
     
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Catalog]
      "UserCatalogWaitingPeriod" = DWORD:5000
     

    Microsoft fixed a race condition between catalog manager and Profile roaming service that allowed the catalog manager wait for a couple of seconds while the profsvc is preparing the user profile folder.

    this is documented here:

    https://support.microsoft.com/en-us/help/4018510/june-2017-servicing-release-for-microsoft-desktop-optimization-pack

    Friday, May 11, 2018 8:32 PM