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
Related
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.
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.
So basically I customized a Windows 10 install. I have the PerfLogs, Program Data, Temp and Users folders in C:\ replaced as symlinks to their actual location to D:\
The purpose being, I will only keep a image backup of C:\ and when the need arises that I need a fresh install of the OS, I will only overwrite the whole C: drive with the backup and don't even have to touch my old user profiles. It works without a glitch even as I moved my C: to an SSD.
I did it with a few simple tricks (I don't exactly remember everything I did, but once I got the build right, I just left it as it is as I thought I would never have to touch it again):
I remembered following tips and other guides like this:
https://commaster.net/content/windows-installation-tips-moving-user-folder-another-drive
the difference being I used symlinks instead of junctions with mklink command.
Some modification with registry and other files.
Several stages of booting until everything has been transferred and having windows re-create the profiles and configurations.
Anyways, I had to fix my Mom's PC, which was in a state of disarray as she thought she had to save all her files in C:\ and NEVER in Documents. I opted to install my customized Windows install, so if I need to fix it again, it would just be a cinch.
Before building this custom Windows install, I've made backups of my system with my usual backup tool, Paragon Partition Manager. They worked fine and when I had to change PC builds, such as changing my motherboard, all I had to do was change the drivers. So I thought with my custom Windows 10 install, that's all I had to do for my Mom's PC.
But I kept running into problems with Window's User Profile Service.
At first, it was having difficulty loading the Administrator account and seems to be defaulting to C:\Windows\System32\config\systemprofile, as it cannot seem to write to it's D:\Users\Administrator folder. I quickly fixed that, but, still, it can't load the Start Menu and other services.
The only one that was working almost completely was the user (just one - me) that was existing when I created the backup AND only works with a copy of the corresponding folder in D:\Users\MyUsername.
Obviously I wanted to create a user just for my Mom and one that is completely working and I don't wanna leave a copy of D:\Users\MyUsername in her PC. I figured all I had to do was create a user profile in Control Panel and Windows will recreate everything and all the configurations. The add user service in Control Panel wasn't working with Administrator, but only with MyUsername. But whenever I try to sign in to the newly created user, the "User Profile Service failed to sign-in" keeps popping up. I can sign into it in safe mode, at the first seemingly recreating everything with the first-time-sign-in-welcome-screen, but a lot of the services are not working. So creating another user profile with this new profile doesn't work.
More notably, I've tried:
net user username /add
and adding through advanced user profiles:
control userpasswords2
But the new registry keys for the new users in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList never gets created -- even after I go safe mode and manage to sign in to the new users.
I've also considered it might be a user permission issue, somehow being carried over from my PC build (if that makes sense, it still doesn't to me). Anyways, so with the newly created user logged in with safe mode, I tried changing permission for C: and D: for every single group to "Full Control". Then from that newly created user, create another user either through net user username /add or control userpasswords2. I even tried booting to Linux LiveCD and chmod-ding everything to 777 (I'm not even sure how that transfer to an NTFS. Then I try to sign in and even if I can forcibly sign in, it just isn't a glitch-free user profile.
Currently planning on making the installation process for a .NET application I'm selling smoother (read: "possible") for non-administrator users, I stumbled upon applications like Google Chrome and Microsoft SkyDrive:
They seem to not install into the usual "Program Files" folder, but instead into the "Local Application Data" folder of the current user.
Since this folder is on a per-user-basis, it is writable for the current user and no administrative permissions are required to write into.
I've managed to change my NSIS setup to work correctly and install into this folder, but I'm still unsure whether this is good practice and might have drawbacks or not.
My question is:
Do you have any recommendations on why to install or not to install into the "Local Application Data" folder?
(I do hope this question is programming-related enough to be kept here)
It was not clear from your question but you should install the program in $LocalAppdata\Programs and not just $LocalAppData (FOLDERID_UserProgramFiles constant in Win7)
I know I like apps that can install as non-admin, at least you know the app does not require a driver or that it messes with the machine configuration in other ways.
Some people prefer to do a machine-wide install and giving the user this option is not that hard in NSIS:
RequestExecutionLevel highest
Add a custom page with two radio buttons (Just Me and All Users) and gray out the machine-wide choice if user is not admin (UserInfo plugin)
Set $Instdir and SetShellVarContext based on install mode
Use SHCTX as the registry HKEY
Some IT people/domain admins might not be happy if their users can install stuff, that is the only negative I can think of but they should lock down the system properly if they think it is a problem IMHO...
I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?
Windows still lacks a convention for per-user installation.
When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.
(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)
What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.
One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.
I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.
As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.
The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.
In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.
Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).
The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.
That said, the option to install per-user is quite nice, as it means no permissions issues.
Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:
https://www.google.com/intl/en/chrome/business/browser/
I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.
Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !