We have come a long way from the good ol’ .pkg files we had back in days on 4.x. I have discussed at length both App-V 5.0 - OS Integration - State Changes and Global File State Changes in App-V 5.0, but what about when we make changes to global locations of registry for our application?
We can break down how this is handled into two categories; Admin and Non-Admin.
So you launch an App-V application as an Admin user and make a change to a global setting;
For example here I have chosen to enable automatic checks for updates and betas. This is a global change that writes to HKLM. As we are logged in as an admin user we write the change into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages\CA43F9E3-4C6F-4A71-8EE9-977EF8FF5F20\S-1-5-21-2435128332-2813322235-3721083121-500\REGISTRY\MACHINE\Software\Paint.NET
Notice we store the change not only under the context of the package itself but also under the sub-context of the Users SID, this means this particular change although global will only actually take affect for this particular user thus protecting other users on the same machine picking up another individuals changes.
So what about non-admin users? Well first of all we expect our applications to behave differently for non-admin users in that they shouldn’t be able to affect global change, this is a reliance on how the application itself is written first and foremost. For example Paint.NET in this case prevents users from changing its update settings:
However does anything stop us cracking open a regedit inside the bubble and changing our global registry keys in HKLM regardless? The answer is no…
For example here I have gone in as a non-admin user and changed the CHECKFORBETAS value in HKLM to hold the value virtualvibes. How is this possible!!
Well if we open up a local regedit we can see how this is handled. As a non admin cannot write to HKLM machine we find the changes being written to HKCU:
Now notice this is actually under the classes section of registry and not where we normally go to view traditional registry state for the user. This location is reserved for non-elevated processes writing to HKLM.
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.
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 appdata\local.
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.
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.
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%
@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.
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!