I'm running into the problem outlined in this question: How to prevent uninstaller elevating for Standard Windows 10 user? where unstallation of an app installed under the user's AppData folder works correctly from the classic control panel "Programs and Features" page, but fails from the Settings "Apps and Features" page, due to the unilateral attempt by Windows to elevate the uninstall process.
I should be able to fix the issue if I can determine the identity of the user that originally started the uninstallation, but as far as I can tell the token holding their identity is lost when the elevation happens.
Trying to make a comparison with Unix, but my understanding there is that more often the effective UID is changed to gain permissions, in that scenario I'm trying to recover the real UID.
Is this possible via the Win32 API, and if so how? I've googled long and hard, and all I keep turning up are pages telling me how to recover lost accounts or passwords.
Related
I created a Windows installer for a Client-Server program by using VS 2013 and InstallShield LE 2015.
I log in to a computer as Admin and run the installer. All works fine.
Then I modify the registry for Local_Machine for some keys to define the database location etc. for the program (this was done by the installation initially as well, but due to certain issues discussed in At each login the program tries to configure installation parameters in the HKEY_LOCAL_MACHINE registry, I removed the registry modifying section from the installer).
I then run the program by double-clicking the shortcut placed by the installer on the desktop and test it. All works well.
Then I log off the computer.
Another user with admin rights logins and clicks on the shortcut, and the problem comes: the program starts to reinstall itself!
Then it fixes itself and runs fine.
But If the first user logins afterward, she experiences the same reinstall operation so does the first user afterward ad nauseam!
So, even though the installer does not create any registry items by itself, somehow, as soon as the program accesses the registry, or whatever it thinks broken, the Windows OS intervenes and tries to repair whatever needs fixing.
The InstallShield LE does not allow setting shortcuts to be "Advertised Shortcut", or
I delete the shortcut created by the installer and recreate it manually after the installation and yet experience the same problem. So the nature of the shortcut possibly is not the cause.
This problem only happens for multiple logins to the computer. If many people login by using the same credentials, it never happens.
So, what's wrong? I studied many StackOverflow answers to resolve this issue with no success. Any help would be highly appreciated.
Stein gives a good set of instructions on how to diagnose problems with MSI programs in this StackOverflow answer. When I followed his instructions, I was able to check which component of my MSI program has a problem. It turns out, the serial bus controller library, MScomm32.ocx could not register under Win 10 properly. Once, I implemented the solution in this link, the above problem resolved and I could log in as two different users without initiating a reinstall process whenever the program icon was double-clicked to run.
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.
I'm marking this as a community wiki because I'm not really looking for one complete answer. So if you feel like posting one or two things that will activate the UAC prompt instead of a comprehensive list then go ahead.
What actions in Windows will activate UAC? I'd like to avoid it as much as possible because my application doesn't need admin privileges. And I'm sure many other people want to avoid it.
Specifically, I would like to know if reading from the registry would activate it. Or writing to it?
You don't need to address the above question, just anything that will activate it is fair game.
It's really hard to Google anything about UAC because you get bombarded with articles about how to disable it. And I'd rather not have my application make the assumption UAC is disabled.
Nothing "activates" UAC.
If your application would fail to run as a standard user under Windows XP it will fail to run under Windows Vista or Windows 7 as a standard user.
What you are really asking is: what actions can a standard user not perform under Windows?
The things a standard user cannot do are pretty well known (they've been the same since Windows 2000). The main ones are:
modify anything in HKEY_LOCAL_MACHINE
modify anything in the Windows directory
modify anything in the Program Files folder
If you try to do any of those they will fail on:
Windows 2000
Windows XP
Windows Vista
Windows 7
Nobody should have been running as an administrator for day-to-day computer use. If your application did any of those bad things in Windows XP it would fail. The user would have to:
logon (or fast user switch) to an administrator
perform the administrative task
switch back to their real account
UAC is a convience mechanism, allowing you to easily temporarily switch to an administrator. Nothing you do will "trigger" it; you have to make it happen.
If you know your code needs to modify a file in C:\Program Files\My App\Data, then you should add a button on your form that will trigger the elevation.
You then need to launch an (elevated) copy of your program, do the thing, and close.
I created a launch4j installer (an exe-wrapper for java programs) and named it "MyApp.exe". It doesn't need any admin authentication. It just runs fine without any UAC prompt.
BUT: If I rename this installer to "install.exe" or "setup.exe", the UAC icon appears and I get a UAC promp when starting the installer.
Seems as if there are some "reserved words" in filenames that cause windows to start a program with elevated rights (UAC).
We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.
Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.
It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.
To see this issue in action, do the following steps:
Run cmd.exe with no UAC
Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
Run cmd.exe as Administrator
Type "w:", and see the error message
At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.
Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?
This is by design.
Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.
Check out this link: Regedit Link
They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.
EDIT:
The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:
If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1
Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
I will be posting more information on this soon.
I've built an installer for my application by hand (don't ask why). And I set up the registry keys for its entry in the add/remove control panel under HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall. And it works fine. I need it to be under HKCU so my installer will run on Vista without asking to be elevated.
The issue I have is that if a user installs using a domain account with a roaming profile, and then goes to a different machine, there's an entry for my software in the add/remove control panel with no information in it. I don't want it to appear there for roaming users, my app does not get installed in such a way that it will work in that circumstance anyway. Is there anyway I can setup that entry so my app won't appear in the add/remove? Or have I doomed myself to it by making the entry under HKCU? Thanks!
fwiw:Google Chrome installs the way you did, but also suffers from the same problem since it installs in the profiles "local settings\app data" directory, which doesn't roam [1].
Rather than fix the install\uninstall problem, would it be reasonable to have your app roam with the user? Is it small and xcopy installable such that you could install it under Doc & settings\Application Data some place, which does roam?
[1] http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dseb_ovr_wpeu.mspx?mfr=true