RunOnce Key needed for limited user
Most installations should be per-machine installations at this point. So with a per-machine installation say that you have a need to run something on the next reboot. Typically you'd put it in the HKLM RunOnce key. On Windows XP and Vista, limited or standard users don't have rights to delete from the HKLM RunOnce key.
Therefore, Windows won't even try to run whatever is in the HKLM RunOnce key.
So how do you effect a RunOnce in that situation??
Well, you could put the key into the HKCU, but this has problems, too.
1. Especially with the advent of Vista, it is HIGHLY recommended that you do not put user-specific stuff into your installer, for several reasons. Robert Flaming (former PM for the Windows Installer group at Microsoft has some valuable discussions about UAC and Vista and per-user problems on his
blog.)
2. If you use the Registry table to create the HKCU key, beware! Keep in mind who the 'current user' is going to be at the time when the registry keys get added. If you are on Vista, and the user had to provide an admin's login in order to run the installer, then the 'current user' will be the admin, NOT the real user.
3. This process falls down if it so happens that the person who installs is not the next person who logs on.
Here are some options to try for a solution to this problem:
1. Don't do it. Find some way to refactor the installation so that the thing you are trying to put into RunOnce can be initiated by your product when it is first launched. It is really best practice to put this type of configuration into the execution of the product rather than in the installer.
2. Put the item in the HKLM Run key, but then find some way to either delete it from the Run key after it runs, or modify the item you are running so that once it's been run it just immediately exits if it gets run again.
3. Create a custom action that adds an HKCU RunOnce reg key but author the action so that it runs Deferred WITH the Impersonate bit set. This should cause it to treat the Current User as the *real* user and not the admin. Note, however, that this option has drawbacks! For one thing, it would be hard to clean this up on uninstall because you can never be sure who 'current user' will be on uninstall. In most cases the key should be gone by the time uninstallation happens, but... For another thing, this just illustrates why it is best practice to keep all your installation actions and data at the per-machine level.