Installer doesn't offer an option to install for all users

[physhster]

In an enterprise environment, it is desirable to have apps installed in Program Files as part of a standard computer or app deployment process. Google uses %LocalAppData% for Chrome but offers an option for enterprise installation. Could we get a silent install switch that installs silently in Program Files instead?

Thanks

[anaisbetts]

Because of the way Squirrel works, Program Files is actually a much more difficult proposition than it seems - however, your suggestion on Twitter is super interesting, because it would allow IT admins to still deploy everywhere but we still get the great background update experience. You mentioned you had some better ideas than dirty hax, can you explain?

(Edit: Said hax: https://gist.github.com/physhster/7f2ee1cbb36e03258401) - edit default user template, add Setup.exe to RunOnce

[physhster]

So, to take the Chrome example (https://www.google.com/work/chrome/browser/) since you guys seem to like a "no friction" installer, I would offer a separate MSI installer that installs in Program Files (with UAC warnings but that doesn't matter since we run in silent mode anyway). Chrome handles autoupdates just fine even when installed in Program Files.

[physhster]

Also, I would actually recommend against messing with the default registry hive with no warning. It's quite difficult to clean up afterwards. It just happens to work well for us here.

[anaisbetts]

Chrome handles autoupdates just fine even when installed in Program Files.

Do you know how it manages to do this?

[physhster]

They make a separate MSI installer that installs into Program Files. See https://www.google.com/work/chrome/browser/

[anaisbetts]

@physhster Sure, that gets you in the door, that's easy. But how do they update that without popping UAC dialogs all the time

[willdean]

There are two Google Update services on my machine here which run as LocalSystem - I suspect they're what's doing it. Installing a service feels like pretty much the anti-Squirrel, though.

[physhster]

Either with clever permissions or with a service that runs as the local SYSTEM account. Honestly I have no idea but I can dig a bit... But some other shops do it so that means it can be done.

[physhster]

I guess @willdean found the answer then. I know it's not pretty to have an updater service running but if it's good enough for Google, I don't have a problem with it. Quite the contrary actually.

[anaisbetts]

Hah! I've got a big problem with it :) It would complicate this whole thing by at least an order of magnitude and unless it was written very, very carefully, it would be a gaping security hole

[willdean]

For what my option is worth (nothing!), I think it would be very difficult to get right too - and things like updating the update service itself aren't trivial either.

I can't currently remember what the problem would be with using an elevated initial MSI installer to alter the permissions on the "program files/my app" folder to allow non elevated overwrites later. Does that not work for some reason, or is it just considered to be horribly bad form?

[physhster]

In this case I'd rather have UAC notifications for updates and software that's installed in the right place.

[anaisbetts]

Does that not work for some reason, or is it just considered to be horribly bad form?

The bigger problem is what to set it to - when we install as a single user, we can set it to that user (or rather, we just inherit it), but in Program Files we have to allow anyone to update it, which is Bad. The best I can think of is "Authenticated Users" (i.e. anyone who has logged in), but that's like one step above "Everyone"

[physhster]

To follow up on my Twitter suggestion, this works well for any new user. Not the existing ones... And again, messing with default registry hives is quite a big security risk too. Can't imagine how pissed people would be when they find out.

[anaisbetts]

@physhster Well that's the trick though, if we can edit the default hive, we can also roll down the list of actual users and mess with theirs too :)

[physhster]

In order for this to work, you need full admin privs, or run as the user... Chicken and egg problem that you face when running the installer remotely as the local or (god forbid) domain admin. The default hive is what makes the user's registry upon first login. You need to alter it before the first login or load the user's registry separately to edit it. But you can't do that while the user is logged in. Chichen and egg... I love chicken omelette.

[anaisbetts]

God, this plan is getting more and more complicated by the minute - see why I didn't want per-machine installs!

[physhster]

I get it :) I'm merely representing the enterprise market here. I feel like it's something you'll have to address at some point either way.

[anaisbetts]

I feel like it's something you'll have to address at some point either way.

Agree, just trying to find the best way to make everyone happy without turning Squirrel into a total mess from a developer usability perspective

[andymac4182]

Could it work with a similar idea that Octopus deploy uses where you have a folder in the c drive outside of program files. eg C:\Squirrel\AppName\ This would work for some enterprises. I am sure most would prefer to have it in program files but this might be a decent middle ground.

[physhster]

I edited the subject of the issue. To be fair, I don't think it matters where it's installed as long as all users can use the app.

[mwhitis]

In order for this to work, you need full admin privs, or run as the user... Chicken and egg problem that you face when running the installer remotely as the local or (god forbid) domain admin. The default hive is what makes the user's registry upon first login. You need to alter it before the first login or load the user's registry separately to edit it. But you can't do that while the user is logged in. Chichen and egg... I love chicken omelette.

If you've got an update service running as system, the you can impersonate the logged on user and write directly to their registry without needing to separately load their hive on your own. That would at least get around the chicken and egg issues with logged on users.

If you do that, plus modify the other users registry hives, plus modify the default user, you're all set! :)

[mwhitis]

I feel like it's something you'll have to address at some point either way. Agree, just trying to find the best way to make everyone happy without turning Squirrel into a total mess from a developer usability perspective

I agree with physhter here, I think it's an area that would need to be addressed before you see any enterprise adoption. Have you ever thought about a plugin/extensibility model? I know you're trying to keep Squirrel simple, so that may be too much. it would allow you to keep the core functionality clean but support use cases like this. Just thinking out loud, really.

[anaisbetts]

I agree with physhter here, I think it's an area that would need to be addressed before you see any enterprise adoption.

I'm certainly not disagreeing with the premise of making it easy for IT admins to be able to deploy Squirrel-based apps, only the proposed implementations :) That being said, ClickOnce doesn't support this at all and people still use it, so I'm not sure I agree with your assessment

Have you ever thought about a plugin/extensibility model?

This will almost certainly never happen - this is what was in the original Squirrel.Windows and it was a complete disaster - when you try to load these plugins into your process, you also drag along all their dependencies and they end up conflicting / shit gets Weird™.

[eeevans]

I agree, @paulcbetts , better to keep it simple and not pollute squirrel with MSI concerns. For someone looking to replace ClickOnce I wouldn't expect these types of features.

[anaisbetts]

Alright, I think I've come up with something far simpler than these other proposals

The Plan:

• Setup.exe will now support a new parameter, --machine, which implies --silent. This parameter will do the following:
  1. Scan the embedded Zip to determine the name of the package being installed (i.e. the package ID of the .nupkg file).
  2. We create a new directory, C:\ProgramData\SquirrelMachineInstalls and copy ourselves to it, giving ourselves the name "PKGNAME.exe"
  3. We set the folder ACLs to Admin-write if they don't exist
  4. We create a Run entry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run that invokes the Setup.exe we've copied off, with a new --checkInstall parameter
  5. The spawned --checkInstall will check for the directory %LocalAppData%\PKGID (by looking at our own EXE name) - if it exists, we bail out immediately. If it doesn't, we act as if we were invoked with --silent

Why?

• This approach will solve it for both users already on the system as well as users who are created after the fact
• This approach is slightly less efficient than adding RunOnces to every user (and future user via the template), but it's far simpler, and the --checkInstall can be very fast in the simple case (and since Setup.exe is a C++ application, we don't have to load a huge runtime).

[DarwinJS]

You all may have already figured this out - but you should be giving write permissions to everyone to c:\programdata if you want anyone on the machine to use it.

It is Microsoft best practice for software developers open up the permissions when the software creator wishes to - but the default is that "The first user to create / touch the folder get's special creator / owner modify permissions" Since enterprises frequently install with a totally different user ("SYSTEM" account under many software distribution systems) - the default permissions do not work when the actual end user did not run the installer in their machine context.

If you don't do this, your folder will be subject to UAC Virtualization of any writes to that folder for any user that does not have permissions - and then things get VERY confusing (yeah, I know - like they aren't already).

On the flip side of best practice - by placing software EXEs in ProgramData and opening permissions you open up the software EXEs to malware injection. Technically to be safe from that you should comply fully with the Microsoft model - and I believe your new --machine switch will allow you to in this way: A) advise users of your installer that the --machine switch requires the install be running in an elevated administrator context - either log severe warnings or block the install if this is not true at runtime. B) Place the EXE files in C:\Program Files where they are safe from malware inject by the user's regular permissions. C) Application state data that should be able to be modified by everyone in c:\ProgramData and open the permissions to everyone (since the installer is likely NOT being run by the actual user profile who will use the software. D) if the software dev wishes to keep the application state on a per-user basis (individual settings) then it is supposed to go in %localappdata%\software.

C & D require that the software the installer contains also follows these rules and if necessary, probes these standard locations for it's configuration files.

I know way more than I intended to on this topic because I needed to know it to create and teach this course: http://csi-windows.com/courses/foundations

[stajs]

@DarwinJS I found your post informative, thanks for sharing!

[anaisbetts]

You all may have already figured this out - but you should be giving write permissions to everyone to c:\programdata if you want anyone on the machine to use it.

That's a security issue, we re-ACL the folder we write to, to be equivalent to Program Files, with read-Everyone. I don't know why I'd give write-Everyone permissions to that folder. I think you misunderstand how --machine works :)

[skaryshev]

Commenting on closed topic. Just my $.02 on an entirely different scenario of deployment for all users. First of all we already don't need to update shortcuts. Update.exe --processStart is smart enough to figure out the latest and greatest .exe to launch. Update.exe only needs to supply a working directory itself instead of relying on "Start in" field in a shortcut - very small change. This way we can create shortcuts only once on initial install. Second. Deploy application into C:\Users\Public location which is a realm of INTERACTIVE users (built-in dynamic group for all users authenticated by Windows UI). There are default directories Public Documents, Public Pictures etc., so we create another directory like Public Applications, Public App, Program Files, Public bin, usrbin - you pick a name (just do not let IT go ballistic on breaking Microsoft recommendation to deploy to Program Files). Third. Desktop shortcuts go to C:\Users\Public\Desktop to make them accessible for all users. Unfortunately Public Desktop requires elevated privileges to write. We can not avoid admin intervention here but for initial install only since shortcuts are static now. The same for Start Menu shortcuts in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ And that's it. Now all users can run and update application. Uninstall needs elevated privileges again to remove the shortcuts.

[hatton]

We're facing this issue, primarily for university lab situations. Since there are a lot of users per machine, we decided we couldn't go with the current --machine/MSI approach, which installs a new copy for each user (if I understand correctly).

Happily, in this scenario, we really don't need the update capability. We don't even want it. I know... that's the whole point of squirrel, but we don't want to go back to hand-maintaining a wix file just for this one small set of users.

So here's the rough plan we're going to attempt:

• Use a shim wix which just launches setup with --allUsers. The msi will be named <product><version>-MultiUserNoUpdate-Shim.msi.
• Add a new --allUsers flag, which causes Squirrel
  • to install to %COMMONPROGRAMFILES(X86)%
• At runtime, if we are running from Program Files, disable auto update/version check.
• We will place shortcuts in ProgramData\Microsoft\Windows\Start Menu\Programs\ and %PUBLIC%\Public Desktop. Not clear at the moment from where we'll do this (possibly from wix).

If anyone sees a problem with this plan, I'd appreciate hearing it. We are particularly ignorant about how this kind of bogus msi system will work in the computer lab scenario where admins do something once to install on all machines. At the moment it seems cheapest to just build this and then have the customers with this problem give it a try.

@paulcbetts I'm assuming this is not a good fit for an upstream PR.

[swirly]

@hatton is totally right In a production environment or a high school, we do NOT want automatic upgrade done by users. We want rock solid state and we update once or twice a year, after careful testing. Actually, squirrel installer fails lamentably in a roaming profile environement. Roaming profiles are saved usually centraly, and the c:\Users\ part of local is wipped out regulary in any lab where many users are using the computer (else the HD space will rapidly be reduced to none) In such an environment, a squirrel installed app does simply disappear every day Using the actual system wide installer protocol and letting admin manage their networks would be the normal windows way of interacting Actually, any squirrel installed product can not be used in a high school network with windows management

I had to develop a hand made installer for ATOM in an high school, but did not have the courage to do so for github desktop or gitkraken wich are simply not used because of this approach

[cztomczak]

@paulcbetts How can you write to HKLM without administrative privileges? In regards to point 4:

We create a Run entry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run that invokes the Setup.exe we've copied off, with a new --checkInstall parameter

[josephrowe]

I found this thread with google. I'm looking for an MSI installer for schools. I need to install git desktop app using my teacher account, and when other users logon they don't have to re-install the app.

please send me a trusted URL, on the git domain. I've seen several MSI installers, but they come from very odd URLS. If there is a way to hack the default installer please list those steps. Thanks, J

current steps:

• logon as teacher to win7 pro using school active directory authentication
• install git desktop app
• restart, have student logon

result: No ability to run git desktop app

expected result: Some type of installer with option to install for all users

[anaisbetts]

@josephrowe Hi this is not a user support forum, if you're looking for the GitHub Desktop MSI installer, it's at https://central.github.com/deployments/desktop/desktop/latest/win32?format=msi

[Neustradamus]

Any news on it?

[Neustradamus]

All good softwares when we install use by default "Program Files" (or recently "Program Files (x86)" for 32 bit apps in 64 bit system. Bad softwares do not use it.

It is since Windows 95 and maybe before, no?

[tovodeverett]

I think some more thought needs to be done on this strategy. I understand the desire for Squirrel to avoid per-machine file installs because that interferes with seamless updates by the users, and seamless updates by the users is what allows the developers using Squirrel to assume that the user base is generally on the latest version (or a very recent version), and thus avoid having to maintain support for older clients from the server side.

However, the current per-machine approach has some serious drawbacks. I am not a corporate machine administrator, but I manage three home computers and they average 9 users for each computer:

• Admin, since I refuse to run as root
• One for each member of my family (that's 4)
• A "guest" account
• A "movie watching" account (300% zoom to make life easier when sitting on the couch)
• An account for accessing work (keeps it isolated from my personal account)
• An account for a FLL team I coach
• Other accounts as necessary

A per-user Discord install is 450+ MB. That means that if I allow the Discord installer to run as Admin, which triggers the per-machine strategy above, I have to pay a 4+ GB price per computer just to have Discord installed, because the minute someone logs in with an account, even if that account will never use Discord, it will silently drop stuff all over their AppData directory.

I know I'm not going to convince Squirrel to avoid the per-user app directory, but at least let me only deal with the disk usage and increase in backup sizes for the accounts that actually use Discord (less than a third of the machine/account combinations I manage).

Consider the following approach when the installer detects a per-machine situation:

• Retain the "drop the installer into C:\ProgramData\SquirrelMachineInstalls" approach.
• If that works, create a per-machine shortcut in the Start Menu (and you can stick one on the Desktop if necessary) that points to that installer.
• Give the user running the initial installer a message that says, "We have done a polite per-machine install. Do you wish to install for this user and launch it now?" If the user says yes, then go ahead and install for that account and launch it. Otherwise, leave that user profile unsullied - after all, why would I ever want to run Discord from my Admin account?
• When users run the per-machine shortcuts, that triggers the installer to check that the per-user install is present (if not, install for that user) and up-to-date (if not, update it) and then launches the app. If the installer can tell that this was a per-machine install (based on the location of the installer in the "C:\ProgramData\SquirrelMachineInstalls" directory), then it doesn't even need to drop shortcuts!

I feel like this would be a fair compromise. As installation program developers, keep in mind that you have another constituency that isn't mentioned in https://github.com/Squirrel/Squirrel.Windows/blob/develop/docs/goals.md - you speak to developers and users, but fail to mention system administrators. Many computers don't have a system administrator (they may have a user that ends up doing that work, but most users do not separate in their mind the roles of being an administrator vs. being a user). Spend some time thinking about the needs and requirements of system administrators, and you will end up with a better installer. To this day, I refuse to install QuickTime or iTunes on any computer I manage, despite having an iPhone (my get-out-of-jail card is iMazing), because I spent a decade struggling with the installers when I did automated management of NT 4 and Win XP desktops. Please don't make me end up feeling the same way regarding products that use Squirrel for their installer!

For now, I just spent spent 20 minutes ripping Discord completely off this computer (dir /s /a is my friend), hunting through the registry to find the Run key and other detritus, and then fell back to identifying which users will use it and then running the installer for each of them one at a time (I do not want to my users run installers) so as to avoid triggering an install for all of the other accounts as well.

[anaisbetts]

@tovodeverett if you send me a self-addressed, stamped envelope, I will be glad to send you a $5 USB key to store all of the Discords you need.

[Neustradamus]

@anaisbetts: Do you do it for all people who have this installer problem?

[anaisbetts]

Yes

[tovodeverett]

Unfortunately, redirecting %USERPROFILE% to a USB key seems like a sort of bad idea for a whole host of reasons (performance, reliability both electronic and physical, etc.). Ditto for redirecting %APPDATA% or %LOCALAPPDATA%. I'm pretty sure one could find a number of applications that assume that "%APPDATA%" == "%USERPROFILE%\AppData\Roaming". Sure, one might get away with it by using ntrights.exe -u Users +r SeCreateSymbolicLinkPrivilege to grant users the privilege of creating symbolic links and then using mklink to redirect the Discord folders to the USB drive, but the last time I tried using that approach to redirect %APPDATA%\.minecraft\saves to a folder on the user shares on my Samba server so that my kids would see the same set of Minecraft data no matter which machine they happened to use, Minecraft eventually modified their code and started crashing, so I've stopped trying tricks like that. The thought of relocating the entire C:\Users folder to a USB drive seems even worse - it's going to be difficult to administer the machine if the encryption key for the USB key gets sideways.

Sure, 4 GB isn't going to kill me. But 10 applications that have space consumption like that will run my notebooks low enough on space that Windows 10 Feature Updates won't run. Not to mention that I end up closer to running out of adequate space on the set of USB spinning rust drives I use for backups, so now I've got to drop cash on new versions of those. I get that your reaction to my suggestion is to belittle it and to insist that space is cheap, but keep in mind that system administrators can react just as flippantly and put in place restrictions (app white listing, volume quotas, etc.) that would prevent users from installing or using those apps.

I understand that the Squirrel installer ethos seems to be a reaction to the frustration felt by developers at the difficulty of easily deploying update to end users, but I think it short-sighted to ignore the externalities imposed on the people who have to manage, secure, backup, and support (not to mention justifying budgets to purchase) the computers those end users rely upon. Just as I should seek to understand the frustrations and difficulties that lead to the development of Squirrel, I encourage you to understand the legitimate concerns of another constituency. There are win-win solutions out there, the trick is finding them.

Here's another thought - what if running the installer as an admin could create a world-writable shared folder for all of the downloaded files that was never-the-less secure for multiple untrusted users on a single system? Each user would have their own set of digitally signed file hashes that they download from the infrastructure servers and would open files with a persistent read-lock upon launch (thus blocking writes to the file), then verify the hash, and keep the persistent read-lock open as long as they were relying upon the file. All file downloads would be versioned, with new ones dropping in beside old ones. The last user to close a file would delete it if there was a newer version, thus keeping overall disk utilization to a minimum. I know that's a huge lift, and I've just suddenly tossed it over the fence with a, "Hey, could this work", but it's probably easier than convincing Microsoft to deploy deduplication support in Windows 10 2009.

[anaisbetts]

So, the easiest workaround in your case is (note I'm describing Discord but this works for all Squirrel apps)

1. Uninstall Discord on one of your user profiles

2. Note that it leaves a folder behind in %LocalAppData%\Discord with a .dead file - this is Squirrel's signal to not install this on a profile, because the user chose to uninstall it

3. Take that dead Discord folder and copy it to all the profiles you don't want Discord on - this folder isn't machine specific so you can drop it on other machines too

Another approach is to not use the machine installer at all and just use the per-user installers, I'm not sure why in general if you only want Discord on a few users you'd use the MSI at all!

[tovodeverett]

All I did was download DiscordSetup.exe (ver 0.0.51.0, 62,636,856 bytes), log into my Admin account, and run DiscordSetup.exe from a UAC-elevated Command Prompt. It automatically detected that it had full privs, created the C:\ProgramData\SquirrelMachineInstalls folder, created the entry in HKLM..Run, etc. There was no communication from the installer that indicated it was installing to the user profile vs. the machine (like a more traditional installer), but the complete lack of questions from the installer left me suspicious, so I located the app shortcuts and checked their targets. That's when I realized it had done a per-user install, and ran uninstall from the "Program and Feature" Control Panel (no need for Admin to have it). I then went to log in under my day-to-day account to research Discord installer behavior, and it silently installed and the shortcut showed up on my desktop. That was when I realized it was going to start silently installing on all the profiles. So I logged back in as Admin and started spelunking through the file system and registry so I could identify the hooks and remove them.

Once I had some idea how the installer behaved and had completely removed it, I figured the easiest workaround was to simply avoid running the installer with Admin privs and only actively install it to the profiles that needed it. Then I found this thread and decided to chime in. I no longer do corporate desktop management (I did it for 16 years and that was enough, although it has left me with the odd behavior of maintaining manual build and configuration documentation for the machines I manage at home), so my current workaround is good enough for my home machines.

I'm still in IT, though, and I had the realization yesterday that the reason dealing with Microsoft Teams is such a nightmare for my compatriots that do desktop management is that Teams uses Squirrel. I suspect they ended up using the MSI in conjunction with OPTIONS="noAutoStart=true" on the desktops. That said, I think they are still struggling heavily with figuring out how to (or if it is even possible to) support Teams in the Citrix environment - they have solutions for profile management, but 600 MB per-user would cause serious capacity issues.

My larger point is that Squirrel has traded one set of issues for another, but that with some clever problem solving, you might be able to come up with a solution that retains the benefits for your current primary constituency (namely developers who want low-friction upgrades for their user base), but that reduce the impacts you have placed on a unrecognized constituency.

[anaisbetts]

Running as elevated admin fails on normal Squirrel, Discord must have modified their fork and not contributed it upstream (they never do)

[Neustradamus]

On several machines with more 100 users, I have seen several software installations:

• 100x Brave installations
• 100x GitHub Desktop installations
• 100x GitHub Atom installations
• 100x Myki installations
• 100x by each Electron based software installations
• ...

I will not cited all softwares...

And with deployment of roaming user profiles :

• Data multiplication by users on machines
• Data multiplication by users on servers
• Data multiplication by users on local backups
• Data multiplication by users on external backups
• ...

A USB key is very very small to solve this historical problem!

I hope that you wil reopen this ticket and solve it.

To all people: I had done a comment here about this problem:

• https://github.com/Squirrel/Squirrel.Windows/pull/466#issuecomment-573240187

[mimi89999]

Your approach does not work well in domain environments with roaming profiles. It was already stated several times, but I will restate the issues since this issue is kept closed.

• It makes things slow as adding hundreds of MB of program files for all users at the same time for all users is a recipe for a disaster
• It takes space from user quotas (we increase those for all Squirrel apps) and takes NUMBER_OF_USERS * APP_SIZE space on the disks of the domain server for every app. If you have a hundred users that will be a huge waste of space
• Breaks software restrictions policies that disable execution from user profile folders (a security requirement we have)
• Many other issues that have been explained very well

We are following all security advisories and are basically able to run the installer the same day on all machine. Works for most software. I don't see why you want to force those auto updates.

[anaisbetts]

This is the way Squirrel works and once again, this is not a user support forum. Please take this up with your software vendor.