It's not that you want to violate security, but that the situation seems to be that now a limited user cannot create a HKLM key where previously it apparently worked. My point about other users and HKCU was that I couldn't tell if you were advertising a feature for the same user or you were advertising in the sense that a different user logs on and gets install on demand of "missing" items, but they would typically be user profile items and not HKLM items.
Regardless of the elevation of the original install, it's not clear to me that a limited user is allowed to create HKLM items under any circumstances that aren't somehow blessed by an administrator. I don't exactly know the privileges of the actors in your scenarios of repair and advertisement, sorry if I missed that. There's also the logging policy option - if you're not getting logging for the advertise error the system-wide logging policy might tell you what's going on. If you still have the original MSI that worked ok you could reproduce the original working scenario with a log, or reverse engineer what's different by looking at the MSI files. Assuming the actors are limited users, the kind of thing that might have happened is that the old MSI worked accidently because of some issue that caused a repair to install that key. That's different from a situation where the new MSI is more explicitly trying to have a limited user create a HKLM item. I think that's the general are I'd look at based on that starting theory, and look for logs and other data that might support or disprove it, and at the keypaths and component/feature ownership of the items. --------------- Phil Wilson On Fri, Apr 11, 2014 at 4:06 PM, Phill Hogland <phogl...@rimage.com> wrote: > I don't want to violate the security. The applications in the bundle were > installed on the first install in a per-machine install. Burn was elevated > at the UAC prompt. There are many other keys which are part of this app > which are also written under HKLM. (I am not intending to do a per-user > install.) > > However in one MSI package in my bundle chain, the only Feature had: > <Feature Id="QuickDisc" Title="$(var.AppName)" Level="1" > InstallDefault="local" TypicalDefault="advertise"> > > and there is a shortcut on the desktop which is advertised. > > So for some time now (testing on Windows 8) I run the bundle and all > packages get installed, but the files related to this particular package do > not get installed, until after the bundle completes and I click on the > application's desktop shortcut. At which point msiexec launches the package > to do what I am calling the 'advertised' install of the files, and then > launches the application. (I did not realize that it is a 'repair' if that > is the case.) So these registry keys that write to HKLM have been part of > the package for some time, but only recently does this one fragment, which I > moved from one wxs to another wxs file start displaying this error. The log > for this package when Burn is running is verbose, but when the shortcut > launches msiexec only the error line is displayed. I will work on this more > next week. > > Since I want to install the application on a per-machine basis (and write > config info to HKLM) it sounds like I should not allow the feature to be > advertised (or go back to the application developer and get them to write > the application so that interaction with HKLM is not needed, which I would > prefer). > > I think I assumed that when Burn was run, and UAC was accepted to elevate > the install, that the automatic invoking of msiexec by clicking on the > advertised shortcut would either also run elevated (or that the elevated > stuff had already been done when the package was launched by burn as a > per-machine ALLUSER=1 package). So am a little confused wondering: > 1) why it worked for so long and when I moved source code it stopped > working? (I know, I should know what I changed more than others.) But I > wonder if I am missing something in understanding this. > 2) If the install of the application (by clicking on the advertised > shortcut) is in a per user context, and this is a per-machine setup, should > I disable advertising the feature? or do something else to prevent this? > > In the MSI package (on Win 7 and later, based on the MSDN ALLUSERS docs) > should set the properties in my MSI of ALLUSERS and MSIINSTALLPERUSER to > assure a per-machine installation? > > I'm just wondering what the best approach for a per-machine installation, > and not trying to do something that would violate security. > thanks for any advice. > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594083.html > Sent from the wix-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
