locked
App-V 5.1 HF1 Profilelist entry remains at logoff RRS feed

  • Question

  • Hi,

    We are using App-V 5.1 HF1 on Windows Server 2012 R2 in combination with a Mandatory Profile.

    When a user logs off, the user directory in c:\users\ is deleted but the registry profilelist entry remains.

    At second logon resulting in the error "The User Profile Service service failed the sign-in. User profile cannot be loaded."

    clicking Ok results in the remaining profilelist entry being deleted. So Third logon is normal again until logoff and so on ....

    I can fully reproduce this issue. When I uninstall App-V, everything works as expected.

    I did some further research: When I Install App-V 5.0 SP3 the issue is not occurring. But when installing App-V 5.0 SP3 HF02 (which even should resolve an open handle) the issue is back.

    Anyone ?

    Kind Regards,

    Gunther

    Tuesday, February 16, 2016 12:13 AM

Answers

  • I opened a ticket at Microsoft after posting this and got the following answer:

     

    “We know about that issue and this is – from an APP-V point of view – an issue with the Window Profile Service. Also see (German) http://blogs.msdn.com/b/sgern/archive/2015/10/23/10649786.aspx

     

    The Windows Profile Team is currently investigating this issue and we hope to see this Fix in the first half of 2016.

     

    What is happening is that with APP-V 5.0 SP3 HF2 we have introduced the LoadUserProfile() API Calls in APP-V which increase and decrease the Refcount when APP-V works with Profile Data.

    Now when a user logs of the logoff notification will send to the ProfSVC as well as the APP-V Client and really depending on timing if the ProfSvc reduce the refcount first and APP-V set it to 0 to signal the cleanup of the Profile, the deletion of the Keys will show an access denied.

    If APP-V reduce the refcount first so that ProfSVC signals the cleanup it will work.

     

    A hack could be if you set the refcount manually to 1 (or -1 whatever the value) is – the profsvc will always signal the cleanup – hence the issue will not occur.

     

    Another way to avoid this is to use APP-V 5.0 SP3 HF1 and not HF2.”

     

    This hack is not really recommended so I’ll wait for the HF and will use App-V 5.0 SP3 HF1 for now.

    My backend App-V Servers are already App-V 5.1 HF2 which isn’t a problem apparently.

    Wednesday, February 24, 2016 3:16 PM

All replies

  • Try with Hotfix 2 for App-V 5.1 and Hotfix 3 for App-V 5.0 SP3.

    https://support.microsoft.com/en-us/kb/3139245


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    app2pack.blogspot.com: app2pack.blogspot.com

    Tuesday, February 23, 2016 8:18 AM
  • Same issue here. I thought that I resolved the issue, but no. I tried even the second hotfix. No luck. Exactly the same behavior as Gunther is experiencing.

    I logged the same issue: https://social.technet.microsoft.com/Forums/en-US/4fd52332-de4f-4d82-be1d-aea52614c3db/user-profile-cannot-be-loaded-appv-rds-client-51-on-win2012r2?forum=mdopappv

    Joe

    Tuesday, February 23, 2016 5:56 PM
  • 5.1hotfix2 only fixed the issue, where the VFS folder was locked (because MS protected the VFS folder with a file handle (after SP2HF4)). The problem about the SID key not getting removed from the registry is still there (so far I've seen it only on 2012R2, not on 2008R2). I know MS is aware of the issue, but I would open a ticket.


    Roy Essers

    Tuesday, February 23, 2016 11:06 PM
  • I opened a ticket at Microsoft after posting this and got the following answer:

     

    “We know about that issue and this is – from an APP-V point of view – an issue with the Window Profile Service. Also see (German) http://blogs.msdn.com/b/sgern/archive/2015/10/23/10649786.aspx

     

    The Windows Profile Team is currently investigating this issue and we hope to see this Fix in the first half of 2016.

     

    What is happening is that with APP-V 5.0 SP3 HF2 we have introduced the LoadUserProfile() API Calls in APP-V which increase and decrease the Refcount when APP-V works with Profile Data.

    Now when a user logs of the logoff notification will send to the ProfSVC as well as the APP-V Client and really depending on timing if the ProfSvc reduce the refcount first and APP-V set it to 0 to signal the cleanup of the Profile, the deletion of the Keys will show an access denied.

    If APP-V reduce the refcount first so that ProfSVC signals the cleanup it will work.

     

    A hack could be if you set the refcount manually to 1 (or -1 whatever the value) is – the profsvc will always signal the cleanup – hence the issue will not occur.

     

    Another way to avoid this is to use APP-V 5.0 SP3 HF1 and not HF2.”

     

    This hack is not really recommended so I’ll wait for the HF and will use App-V 5.0 SP3 HF1 for now.

    My backend App-V Servers are already App-V 5.1 HF2 which isn’t a problem apparently.

    Wednesday, February 24, 2016 3:16 PM
  • Have a look at the following article KB3146751

    Roy Essers

    Wednesday, April 20, 2016 6:58 AM
  • Hello,

    We have the same error.

    Has anyone found a fix for this yet?

    Wednesday, November 9, 2016 10:12 AM