I'm working on an installer for our application. The installer makes some changes to the HKEY_CURRENT_USER\Software\Company\AppName registry key, which the application then looks for the first time it runs. The application then does different things based on the registry keys it finds.
This works great, until you try to install the application as a user account (i.e. non-administrator) on windows 7 (and maybe Vista, I haven't tested that yet).
When the user tries to install the application, Windows elevates to the administrator account's credentials. This means that any changes to HKCU in the registry are made to the administrator's registry, not the launching user's registry. Thus, the keys are not visible to the application when it launches for the first time under the user's account.
We can't be the only people whose installer needs to communicate with the app it installs. Is there no way to reliably use the registry to do this?
We can't rely on the user launching the app after he installs it, so passing the information as a command-line parameter isn't a viable solution. The only way I can see to do it is to have the installer invoke a utility as the original user, which gets or sets the registry key itself; this seems to be a bit of a silly hoop to have to jump through.
Edit: The application needs to delete the keys after it's used them, so I can't just put them in HKEY_LOCAL_MACHINE.
There are 2 recommended approaches for what you want:
Use a per-user installation which
doesn't require Administrator
privileges. You will be able to use
HKEY_CURRENT_USER, but your product
is not installed for all users.
Use a per-machine installation which requires Administrator privileges. In this case you need to redesign your application so it reads its settings from a configuration file. HKEY_CURRENT_USER should be used only when saving user-specific settings, not for global application settings.
Basically, if your application is per-machine, it should use HKEY_LOCAL_MACHINE or a configuration file. If it's per-user, you can use HKEY_CURRENT_USER. Any other combination has limitations and will not work the way you need.
If you need your application's information to be available to all users, use the HKEY_LOCAL_MACHINE hive.
EDIT - 2 alternatives:
Change the security of your registry
keys to allow users to edit/delete
them,
Use the ProgramData directory (instead of the registry) to store
the data.
Related
I'm building an installer with WiX to install a program, per machine (not per user), and it gives them the option to register the program. Registration involves entering user name and organization (or accepting some defaults from Windows settings), and entering a valid registration key. When the registration key is validated, I write registry settings in the HKEY_LOCAL_MACHINE area with this information. Under Windows, when one runs the MSI, it prompts automatically for an admin password to be able to set registry values in HKEY_LOCAL_MACHINE. So far life is good...
I am including an option in the MSI to give the user the option to defer registration until a later point in time. However, if the user is a normal user and they are running the application, if I have a dialog in the app which prompts for name/org/product-key, Windows doesn't the app to write the information to HKEY_LOCAL_MACHINE. So a user cannot use the application itself, running as a normal user, to perform a registration per-machine as the MSI does after prompting for admin credentials.
My thought then was, for post-installation registration, to either (a) find a way from within the application to elevate privileges, with a prompt for admin credentials, allowing it to write HEKY_LOCAL_MACHINE (is this possible?), (b) include an option in the installer that, when run and the app is already installed and not registered, walks through the registration as it would during a normal install. It would then prompt for the admin credentials and life is good again. Alternatively, (c) create a separate MSI that just does registration, install this with the program, and call this MSI from the program when the user selects the "Register..." command in the program.
I've not seen either of these approaches done by any applications before, so I'm not sure either is a good approach. Other than that, however, I'm not sure how, post-installation, I can conveniently allow the user to do a per-machine app registration. Ideally, I'd like to be able to do it from a command within the app, but re-running the installation MSI would be minimally acceptable.
How is this normally done? Or are per-machine installations even normally accompanied by per-machine registrations?
Very good question - I have dealt with this issue many times myself. No ideal solutions, but several options (as you have already discovered).
Before answering, I want to point out that I have a strong aversion against doing too much registration and configuration in the setup itself. It is error prone, and much better done in the application itself for a plethora of reasons: Installer with Online Registration for Windows Application (recommended quick read - tidbits from real life experience).
Writing to HKCU
As you already know, one option is to keep the license key and registration in HKCU only. This is often acceptable unless you want to share a license key between many users on the box. The license key, if added to HKCU, will also generally roam with the user to other computers - which can be helpful or desirable.
Personally, this is the option I prefer: not registering anything in the setup, but writing to HKCU or the user-profile from the application (as explained in the link above as well). As stated, the only drawback is that you can't write a shared license key to HKLM so it applies to all users and not just a single user. This appears to be the core of the problem you are describing.
Writing to HKLM
Setup writes HKLM: Write the HKLM license key (and registration) during the setup to HKLM as Phil has described above using the default Windows Installer properties (just listing this as an option - which you already know about). This should work OK in my opinion - but your issue seemed to be to allow the "deferred registration".
Custom HKLM ACL permissioning: In order to write to HKLM from your non-elevated application, one way to do it is to use your setup to apply custom ACL permissions to the location in HKLM where you want to write the shared registry key from your application. Your application can then freely update this specific location in HKLM at any time without elevated rights. You simply add ACL write access for "Users".
WiX supports this, but I don't have a sample for you available, please check the WiX documentation for permissioning.
Using custom permissioning is generally frowned upon (and I agree it is not ideal design), but it allows any user to add a license key to HKLM without any elevation after the install (and also allows any users to delete it - which can be a problem).
See section 14 here for a quick description of why custom permissioning is not generally recommended: How do I avoid common design flaws in my WiX / MSI deployment solution?
In summary, I don't generally suggest setting custom permissions, but it will definitely work. I have done it myself when client requirements are such that this is the only thing they will accept. It will violate logo requirements for Windows applications, but it should be less serious than the security issues that result from option 3 below.
Run app as admin: If you don't want to apply ACL permissions, I believe you can prompt the user for admin rights for your application as described here (I believe this is what Phil referred to in his comment if I understand correctly):
How do I force my .NET application to run as administrator? (the legendary Hans Passant - one more answer).
This is most definitely not recommended (but we want to show people what is possible too). Your whole application will run with admin rights all the time, which is not a good idea at all.
Doing this will violate a key part of logo requirements for Windows applications and you will also open your application up to attack from malware.
Definitely try to make your users understand the consequences of this "easy fix". I would make sure to put all responsibility on the client if they go for this option - they must understand what they are doing.
Note that you should be able to use this manifest approach to launch a separate EXE with elevated rights to do only the registration. See next bullet point.
Elevate app on demand: I am not familiar with the technical details of elevating your application on demand whilst it is running - as you invoke a dialog or feature that needs HKLM access. Perhaps Phil knows a way to achieve this? I found some links though:
Elevating during runtime (from Code Project)
How to elevate privileges only when required? (good read)
Skimming the linked content above, it seems like you can launch a separate EXE with elevated rights to do your registration - a known option for you I assume.
Would love to hear back if this is something you decide to try. Could be useful for all of us.
Internet validation: Just throwing an option out there: what I often want to do is to put the whole registration license key validation online from within the application (never, ever try this from the setup, just so that is mentioned - a setup that tries to access the Internet might be the biggest deployment anti-pattern of all - at least for now).
I write the license key from the setup, and the validation of it takes place on application launch against a server on the Internet. Then there is no validation code in your application or your setup to crack.
You need an Internet "handshake" and you can repeat this process per user - allowing you to tightly control who is using your license key.
Nothing is ever easy, and proxy server issues could cause problems. Corporate deployment would also mean that such "online activation" is frowned upon. They want applications fully installed after deployment.
Separate registration MSI: I would prefer not to create a separate MSI just for the registration process as you mention in your question. This just seems like unnecessary complexity that can break easily. For one thing you get a dual source problem that must be permanently maintained. I would guess that this could become a classic support issue.
Re-run original MSI: I am honestly not sure if re-running your original setup to do the registration will launch it elevated or not. I think it will be elevated (should be, can't see any reason why it shouldn't - the MSI database stores a flag to determine if elevation is required "Word Count"), and then you should be able to add your registration details provided you access the registration dialog from the setups "modify" or "repair" modes.
This kind of registration is usually done using the standard Windows Installer properties so it just works.
If you have a verification key then it's typically associated (in the dialog) with the standard PIDKEY property which then after validation becomes the ProductId property.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370826(v=vs.85).aspx
Similarly the user name and company name are associated in the dialog with the USERNAME and COMPANYNAME properties.
After this, they're available through (Win32) MsiGetProductInfo () by asking for RegOwner etc:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370130(v=vs.85).aspx
or similar APIs (WMI does some of this).
So generally speaking you just set the properties from the dialogs and it all just works with no need for you to write them to the registry.
My application updates some registry fields related to licensing under HKLM. This is for accessing the information for all users in the system. This makes us to make our application run as administrator. Is there any other location in registry where I can keep information which can be accessed by all users?
Registry HKLM and folder %ALLUSERSPROFILE% are accessible to all users, but meant for writing to at install time (as admin).
Registry HKCU and folder %APPDATA% are accessible to current user and meant for writing to at any time.
Why are you modifying licensing info (shared by all users) during run and not just during install?
You could place as an (e.g.) XML document in the file system under a shared folder instead of the Registry.
E.g. System.Environment.SpecialFolder.CommonDocuments or CommonApplicationData.
No there is not. If you have to make a modification that will affect/be visible to all users, you have to deal with UAC or elevate your application on startup. This is part of the design of UAC. If, however, you were to write to a file you could grant all users access to that file without UAC interference.
If, however, you are only reading the registry, you can do this without elevating your security rights. Therefore, if you write once to the registry and then just read it later, you can do so when only elevating your privileges once.
Here is an article on playing nice with UAC:
http://msdn.microsoft.com/en-us/magazine/cc163486.aspx
I'd make your installer precreate the registry entries (it runs as admin typically), and open up their permissions using GetSecurityInfo and SetSecurityInfo. Then your app can write to them without any special perms.
Problem: I need to create registry keys in my simple application (MS VC++ project), but this simple application could work in different modes:
if I launch it with WinXP, it's started as a service
if I launch it with Vista or Win7, it's started as a console window
On WinXP, I could install service and also I could write to HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\ section. It's ok.
But, when I'm trying to launch my application on Vista/Win7, and it trying to save some data to HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\ registry section, I get the error message, that I can't do that.
Question: Could anyone tell me, where I could write (create) some data (keys) in registry on all of this systems WinXP, Vista, Seven.
PS. HKEY_CURRENT_USER section I'm unable to use, because, services are working on it's own sessions, so data stored by user in HKEY_CURRENT_USER will not be accessible to service.
PSS. I'm unable to give the administrator rights to the application for save some data. I need another "folder" in registry to write there "for free".
Code examples:
REGKEY service(HKEY_LOCAL_MACHINE, TEXT("System\\CurrentControlSet\\Services"), KEY_READ, REGKEY::open);
REGKEY app(service, TEXT("my_application"), REGKEY::create);
// here comes error
UAC prevents access to HKLM on Visa/7/2008, so without elevation to administrative privileges your application cannot access keys contained within it.
If you can't use HKCU then your best bet is to store the data on disk in a format of your choice, in a directory under CommonApplicationData created by your installer with the appropriate permissions.
If I install an application on windows XP and that application writes some keys to HKCU registry , then will those keys be copied to HKCU for other users?
I tried installing one application and verified some keys getting created in HKCU.
Now I logged in into another user and I can find same keys in HKCU for that user.
Both the users were in same Administrator group.
I repeated the same steps in VMWare image of windows xp but I was not able to find the registry keys in other users in vmware image.
I want to know that is it windows feature to copy all registry keys in HKCU of all users?
No, and that's a very good thing. There are corporate machines in big companies that are usable by 100.000 other users (no joke). HKCU is roaming there. If an application would pull in all those 100.000 profiles from across the world, literally, administrators would be more than a little angry.
Note that HKCU usually is a link to HKEY_USERS\S-1-5-21-{UserID}
There are one nice feature of Windows which can be used to implement the scenario which are very close to what you need. The name of the feature is "Active Setup". The feature use many administrators of corporate network to make some customization of the installed software which will be done with respect of changes in the user profile or HKCU.
After introducing of Internet Explorer 4 (I hope it was IE4) Microsoft find out that sometime one need be able to run small setups which can modify HKCU setting or modify some files from the user profile. So Microsoft made some components of IE4 which do this. Later the components (the Active Setup) was the part of the Windows operation system.
Since the time one can use following registry keys to do this
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[Guid]
and
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Active Setup\Installed Components\[Guid]
The main setup of a software run in administrative context and create HKLM key SOFTWARE\Microsoft\Active Setup\Installed Components\[Guid] with some values. The most important are the REG_EXPAND_SZ value with the name StubPath and the Version value. The StubPath define the path to the mini-setup which should be run if the user login and he don't has SOFTWARE\Microsoft\Active Setup\Installed Components\[Guid] in his HKCU part. After the run of the mini-setup it make the copy of SOFTWARE\Microsoft\Active Setup\Installed Components\[Guid] values from HKLM to HKCU, so the setup will not be started at the next login. So the HKLM values define the mini-setup and HKCU values are used for verification whether the mini-setup must be run/re-run. If one increase the value of the Version value in HKLM part, the mini-setup will be re-run once and the HKCU value of Version will be updated.
So the main software setup can not only create some HKCU settings, but also for example export it in the reg-file and it can use regedit.exe /s TheRegFile.reg as the value of StubPath.
If can read here short description of the Active Setup.
No you can't do this. What's more it would be a giant security hole if you could. Profiles are private to each user.
No. There is no such feature. HKCU is stored in a file in the user's profile. Applications that keep data per user in the registry create the data on the first run for that user.
I have an application that is installed per-machine (since it uses a service). One part of the application is a system tray application that allows the logged-in user to monitor the service operations. I'm trying to figure out how to best install this monitor application.
Each individual user should be allowed to configure whether or not he/she wants to run the monitor application at login. This means that the HKLM/Software/Microsoft/Windows/Run key is out - this only allows configuration for all users.
There is of course the corresponding HKCU-key, however if one simply installs to this key, it will only be for the user that installs the application.
The SO question Launch app on startup for all users, but also allow per-user setting (Windows) refers to the technique of simply having a user-configurable regkey or similar that is checked by the startup-application on to determine whether or not to run. But this means that the application has to start in order to check the value and I would prefer not to bloat the user's startup if I can avoid it. The benefit of this approach is that it is possible to remove the regkey on uninstall.
Another way to accomplish the installation part may be to use Active Setup to create the HKCU regkey on login, this is however undocumented and it seems to me that there is no easy way to uninstall the regkey if the application is uninstalled? I would assume that leaving registry values under the Run key for HKCU might create problems for users after uninstallation.
Is there a standard way to handle per-user startup applications using Windows Installer? Especially with regard to how to uninstall these later on?
Looks to me like you're close to answering your own question. I think you may just need to divide up the responsibility of configures whether to auto-run for each user... er, let me explain:
You can use either a self-healing component of HKCU Registry keys or ActiveSetup to ensure that every user gets the configuration.
If you use an HKCU Registry key, your MSI installer needs to have a component with it's "key file" as an HKCU entry--so thus the first time a new user launches the program, Windows Installer will do a self-heal to write those entries. One of those entries would be your HKCU/Software/Microsoft/Windows/Run value, but not the key value, because you want the users to be able to remove it and not have it come back every time they run the program! You would then want your program to have an option to remove the auto-run value.
If you use ActiveSetup (which I would recommend because it's simple and it "just works"), then you might find it easiest to make a simple app (or VBScript or such) which prompts the user if they want to have the monitor program auto-run. So your ActiveSetup would launch the prompt program/script, and the prompt program would create the HKCU/Software/Microsoft/Windows/Run value or, better yet, just a shortcut in the user's Start Menu\Programs\Startup directory.
A bit lowtech possibly, but can't you just add a shortcut to the user's startup folder (Start menu/Programs/Startup)?
I guess you would use the HKLM/Software/Microsoft/Windows/Run in this case. The feature to run the monitor application at startup or not really belongs to the monitor application and not the installer. At log-on the monitor application can detect if this is the first time that the monitor application has been run and present the user with an option to always run the monitor application on start up or not.