Global Registry State Changes in App-V 5.0

This post has moved here

Comments (8)

  1. Anonymous says:

    Hi Guys, appreciate you sharing your thoughts and I do hear you loud and clear. However I guess the thinking is data written to HKLM isn’t considered roaming data the same way %LOCALAPPDATA% isn’t. I know many applications are not written this way however
    best practice would remain that applications which have data that needs to roam should make sure these changes go to either HKCU or %APPDATA%

  2. Anonymous says:

    Again I do understand the challenges but imagine Paint.NET was locally installed via .msi, we would have the same challenge as the setting would write to HKLM anyway. In App-V 4.x it would of went to a global .pkg, which I never saw anybody roaming. At
    least we store the non-admin change in HKCU which neither .msi or App-V 4.x would? Regarding the other the behaviours you mentioned, again I hear you loud and clear, all I can say is they are all on the radar and some have already been addressed in SP2. Appreciate
    the feedback in any respect though as it’s all helpful!

  3. Anonymous says:

    In a previous post we talked about state changes with App-V packages and how these changes were stored

  4. tmangan says:

    Thamin, Administrators are real people too. Yeah, people shouldn’t normally be logged in as admins to run Paint.Net, but if they do I can’t think of one good reason to treat the app related data any differently because they are an admin. The changes should
    follow the user regardless of whether logged in as an admin.

  5. Angel_PRU says:

    Thamin, I couldn’t agree with Tim more, this makes no sense, especially in the case where we need these changes to folow the user (roaming profiles or a Persona Management tool. Just like saving app file changes in the program directory to appdatalocal.
    Really don’t undertand the logic in either one of those changes. But as always, thank you for taking the time to post the information.

  6. Dan Gough says:

    Thanks for the info, I’m going to have to test this. This sounds like it could bring problems similar to UAC virtualisation with the VirtualStore folder. The article does not discuss how UAC fits into this – e.g. if you are an admin user but nut running
    application elevated, I assume it gets treated in the non-admin context described above? If an admin user sees a different view of the registry depending on whether they choose to manually elevate the application or not, yet the file system view remains the
    same in both cases, then I predict a facepalm coming on. I’ll also have to see what happens if you have two apps in the same package, with one manifested with asInvoker and the other set to requireAdministrator; one app could be blind to the registry changes
    made by the other.

  7. Angel_PRU says:

    @Thamim, I happen to agree with you 100%, but as admins for large enterprises we are forced to support applications (in-house and vendor supplied) that rarely adhere to those best practices. 5.x includes some great new features, but defending the limitations
    to your management is very tough…its an upgrade where we lose support for allowing writes to the program directory (I am aware of the PVAD work-around), no roaming of program directory updates, no roaming of HKLM updates for admins, no support for executing
    a app from a network share (granting rights to computer accounts to a business share is NOT a viable solution), terrible publishing performance, subpar caching performance, no support for roaming profiles (glad this was fixed with SP2), and I am sure I am
    forgetting a few more.

  8. Anonymous says:

    CoW stands for Copy on Write and it’s a concept discussed in depth in our App-V 5 SP2 Application

Skip to main content