Virtualization woes (UPDATE: Issue Solved) [modified]
-
First off, I've always gone to great lengths to ensure my apps install/register as admin and run as user. I tested an in house application .msi on Vista, the app stores some configuration settings in HKLM. The app doesn't run until it is licensed (which is normal) so I run the "registration" as admin which drops a couple more hardware sensitive values into HKLM under the SOFTWARE key for our organization along the previously installed values put there by the msi. The REGSAM=KEY_ALL_ACCESS during registration. Now, when I create a standard user account, log in, and try to run the app, I don't see the values I previously put in HKLM except for those put there by the msi. The REGSAM=KEY_READ for normal operations. I'm not sure why virtualization is kicking in for a KEY_READ but even if that is by design, why are the values, that I placed in HKLM, as admin, with REGSAM=KEY_ALL_ACCESS only showing up when I'm logged in as admin and not a regular user. I feel like this technology penalizes those who have attempted to follow all the WinNT rights rules over the years. I'd prefer not to embed or use manifests and having the admins use "reg.exe" to prevent virtualization on our \HKLM\Software\organization\app key seems unreasonable. (UPDATE: When I try to use reg.exe to prevent registry virtualization on our organizations application key while I'm logged in as admin, I get "ERROR: Access is denied") :~ (UPDATE2: OK, I have to go to cmd.exe, right click on it, and choose "Run as Administrator" (while I'm already logged in as administrator) to run cmd.exe as administrator. Now reg.exe lets me turn off virtualization to my software key) :sigh: (UPDATE3: However, I'm still not getting the values when logged in as "User" and attempting to perform a KEY_READ. Regedit.exe displays incorrect values when logged in as admin and as user even though programmatically as admin I get the correct registration values. This is so silly it's not even funny anymore.):mad: Am I missing something simple or do I have to modify my installation and application behavior because Microsoft needs to accomodate the programmers who did not follow the rules for the last 10+ years? (Note: I've already googled quite a bit so I've hit most of the obvious MSDN articles on this but I'm hoping I missed something right under my nose) thanks in advance for any guidance -- modified at 16:32 Friday 13th April, 2007 For anyone suffering the same fate, a manifest with "AsInvoker" in the security section remedied my issues.