This installer has a serious design flaw. It installs applications to LocalAppData folder. A folder that automatically get's deleted when a user logs off. So after every logoff the data and application is lost. This is how Windows is designed any this installer seems to ignore this.
Read https://www.hass.de/content/developers-best-practice-windows-user-profiles why you must not do this, please.
Software need to be controlable by admins. We need MSI installers that install to ProgramFiles. If you need to update software, you need to run a background task or an scheduled task to run this as Admin.
How can we block users to run these bad installers via AD GPOs?
Windows doesn't clear LocalAppData on reboot, only dopey "IT Professionals" set that up. Sorry, we simply disagree on how to write software and I recommend you pursue an alternate solution.
Ignoring OPs arrogance, Squirrel _can_ create MSIs that install to Program Files to satisfy the needs of dopey professionals everywhere! Although, probably still best to look somewhere else...
I must say that I'm not dopey, but developers who do not understand how windows work may be... or are just newbies who think their end user home pc is how everything works. Enterprise is different, but this roaming profile stuff is standard in companies who manage their computers properly.
Installing software to local app data is forbidden by ms rules!!! Only temp files that can get lost should be saved there. Expect the data to get lost in this folders. The application need to handle this, too.
I'm not the maintainer or developer of the software that uses this installer.
Please fix this bug please and try to listen that this is absolutly wrong what the installer currently does. Clearing local app data is a gpo that exists by default in windows. If your installer is compatiple with windows you need to follow ms rules and expect this.
Have you read the article?
Yes, it's opinionated and incorrect and poorly cited.
Do you know what roaming profiles are and how they work? Really?
Yes. LocalAppData doesn't roam.
Have you really understood how many GB may need to be copied over the network if a user logs in and applications are installed in appdata local?
Hopefully zero! Because it's not in AppData/Roaming
Do you know that people may change their computer every day? But want to keep their data, desktop and so on.
I sure do! Do you know why? I used to do it quite a bit when I was working on the Windows Kernel at Microsoft.
Have you really read msdn documentation properly?
Honey, I've _written_ MSDN documentation.
Have you ever implemented a terminal server?
Yep!
Installing software to local app data is forbidden by ms rules!!! Only temp files that can get lost should be saved there. Expect the data to get lost in this folders. The application need to handle this, too.
Citation needed.
I'm not the maintainer or developer of the software that uses this installer.
So why the fuck are you bothering me?
One more thing. Non admins are not allowed to install software. Otherwise you end with a zoo of unprotected software that does not get the updates it needs at the right time. Admins controll who gets a pice of software and not stupid end users who just install something, forget about it and bam - they are attacked. End users have no idea about security and software updates.
Google Chrome team understood it. That is why an Enterprose msi exists for chrome and that is why there is a gpo available from google to block their installers / updates of every google product, too. Provided by Google. They understood they opened the pandora box.
Ah! This is the best part! Squirrel.Windows is explicitly designed so that users can install software without admin permissions. It doesn't matter whether the admin wants it or not, users can still install Squirrel.Windows apps, even as a standard user account.
Squirrel.Windows apps also silently update in the background, so admins don't get to control updates (and in fact, don't need to, because updates Just Happen silently)
With all respect, I do not know you nor what exacly you done at ms, but kernel does not sounds like admin and gpo and roaming profiles. It sounds more like win32k.sys/ntoskernel what is really a different area. I do not like to make this a competence battle and whom di** is larger. But it sounds like you may never administered an enterprise windows network with roaming profiles on daily basis for 20 or more years. Have you?
I'm sure there are applications that are not properly maintained, never get updates, but may include - just some typical examples - weak openssl version or some browser addons attackable via your webbrowser or other bad code. And I'm sure the setup will not uninstall automatically if a developer stopped maintaining his software because he changed his job, has other interrests, or is not so well educated in writing secure code like ms emloyees are, and so on.
Please let me know how you install a software to localapp data e.g https://prepros.io/, logon to a different computer without loosing local app data (that holds the application), if localappdata is excluded from roaming (best practice since... 20-25 ? years). I think I do this for about 25 years now (since windows nt 3.51) and all data in local app data is not there. Installation is destroyed. The icon on desktop points to a dead location. How should this work for a user?
There exists clear documentation in msdn that you should install "per user" software to appdata folders and temp stuff to localappdata. Just because local disks are faster than the network for write intensive applications. AppData folders are typically redirected to a server home folder. So that the application does not get lost on logoff, but temp stuff get's cleaned up and does not fill disk endless (another well known issue) on multiuser pool computers. I know, per user apps are allowed without admin permission. Maybe we thankfully do not see them often.
Just curious...is the popcorn refillable for this thread, because its damn entertaining!

As entertaining as this is.... I actually have a serious question which may be on topic. An a managed IT provider, we use software for our support and service desk which is all packaged by Squirrel. We've run in to a problem because we are deploying the software routinely for end users to utilise.
It is a bit of a backwards situation, in this case it works quite fine but the end user isn't instigating the installation, we are. But what I have learnt is that when we were filtering on who has the software installed, and then installing it for them I think we could potentially have caused an issue with the update manager.
Occasionally, if the RMM has not updated the list of installed software, we would try to push the Squirrel installer again. But the software may have already been running, we then run into this issue: https://github.com/Squirrel/Squirrel.Windows/issues/1015
Is it possible to install as System user, to a hardened directory (e.g. Program Files, or Program Data) and then build a "Start Up" file to run it as the user and then routinely run --update ? Or are we barking up the wrong tree?
As it is what I've found we need to do is be triple checking to make sure the app isn't running under another user before trying to install it, because we run in to this issue. Say in a mine site that runs 24\7 where control room operators share a desktop. They may not log off and may "switch user", then the RMM tool can't find the software installed for the second user and will try to install it, but because it is already running in the background as another user I think this is where issues start.
Only other thing I can think is this issue is no longer around and we need to re-install from scratch which the compiled version is using a different Squirrel packager. I certainly am not a software engineer, but I grasp the concepts so understand the benefits of Squirrel, we just want to make sure we are handling it in a way that is supported.
If you're doing managed IT, you want to use the MSI that Squirrel generates, this will solve this race between running and installing (and probably be way more compatible with what you're used to)
I suppose I should make my own thread somewhere, is there a support channel other than "issues". Running the System Wide installer as an MSI worked, but there was no real way to push it over to another user. Say you run it as System when the computer is not logged on, how does the user get it in their start up to use the app?
I say this without any real further information though, it was 10 months ago I last looked at it. Since then - as you know - more than an entire lifetime of changes have occurred and I simply don't remember all the details.
Guess I will start by reading the wiki and go from there?
Here is my process and my problem:
TL;DR: Read the bottom EDIT.
Running the MSI "Machine Wide Installer" just seems to place the "regular" installer here: "C:Program Files (x86)\AppName Installer\appname.exe" it isn't actually the application. It will then just unpack to AppData for each user, but there is no way to automatically run the installer other than running the MSI and then placing it in a script to make it start, or in to the all users startup. But I feel like this would break the whole normal Squirrel installation process.
So the process I am using is this:
Nothing in "C:Program Files (x86)\AppName Installer\"
Nothing in "C:\Users\Administrator\AppData\Local\AppName"
Run MSI: msiexec /i "appname.msi" /QN
After install: See new file and location "C:Program Files (x86)\AppName Installer\appname.exe", nothing in "C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" or HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce or Run and app is not running or attempted to run the seeded install file.
Execute "C:Program Files (x86)\AppName Installer\appname.exe", watch the Squirrel go mad with the green loading screen, check the seed files under "C:\Users\Administrator\AppData\Local\AppName" and App is running already.
Check C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup and the Shortcut is there, it will run as this user. Target is: C:\Users\Administrator\AppData\Local\AppName\AppName -a "--autostart"
Log off, and log on as another user. No application anywhere, only other than on the seed file under "C:Program Files (x86)\AppName Installer\appname.exe", but nothing in any automatic startup.
So after doing this, logging on as another user. The application is nowhere to be found.. not in startup, or anywhere.
EDIT: Forgot to look in syswow64, found it. AND found the issue. The path is not encapsulated, AND the path variable used by the software vendor was %programfiles% and not %programfiles(x86)%.
So under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run there is a seed command here which uses the "C:Program Files (x86)\AppName Installer\appname.exe" --checkinstall
BUT it is using %programfiles%\AppName Installer\Appname.exe --checkinstall
RATHER THAN "%programfiles%\AppName Installer\Appname.exe --checkinstall"
AND FURTHERMORE it should be "%programfiles(x86)%\AppName Installer\Appname.exe --checkinstall"
......
Is this the software vendor problem, or a Squirrel problem?
How about in HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
Yeah I had a long reply, but looks like you got in before me! Check my last.
"%programfiles(x86)%\AppName Installer\Appname.exe --checkinstall"
Nope, %ProgramFiles% is correct because of WOW64 Registry Value Redirection
I don't know if this is quoted, but stupid question, are you sure you're not just waiting long enough on login for it to run? Run often takes a few seconds after login before it gets invoked.
Let me double and triple check. Certainly should be encapsulated though, with or without wow64 redirection, spaces need encapsulation? I waited at least the whole time while I wrote my reply above... at least 10 minutes.
Will come back to you.
What are your thoughts on the encapsulation?
Okay, you are correct both redirection on wow64 is working AND encapsulation does not matter.
I tested again by using this process:
2017-10-24 11:14:19> Program: Starting Squirrel Updater: --processStart AppName.exe -a --autostart
2017-10-24 11:14:19> Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\nmptest\AppData\Local\AppName\packages\RELEASES'.
In the absence of Squirrel updater checking if it has been uninstalled, and again I am not a software engineer so I do not understand the mechanics behind the process and Unhandled exception... I have constructed a one liner which solves the issue, but I wonder if Squirrel has syntax or command options to do similar?
if exist "%localappdata%\AppName\.dead" rmdir "%localappdata%\AppName" /S /Q & "%ProgramFiles(x86)%\AppName Installer\AppName.exe" --checkInstall
So just if it has been uninstalled and .dead exists, then it will remove it and let the seeder re-start and kick off again. This runs as each user and my thought is I can just replace the existing Run to prepend the command if exist "%localappdata%\AppName\.dead" rmdir "%localappdata%\AppName" /S /Q & to clear it off if it has been uninstalled?
If the .dead folder exists, it means that this particular user chose to uninstall your app, you shouldn't reinstall it for them automatically.
In our case it is a support application as a requirement to engage the service desk. It is a directive from the owner of the organisation to deliver an application to support their ongoing IT operations. If the software is uninstalled, the staff become unsupportable and fall out of support compliance.
If it is uninstalled, we must re-install it this is the directive of the support agreement in place by either a board of directors in a publicly listed organisation or an owner of a business.
Does Squirrel support this mechanism, or do we need to remove the .dead file to re-install from the Machine Wide installer seed?
Does Squirrel support this mechanism, or do we need to remove the .dead file to re-install from the Machine Wide installer seed?
You need to remove it yourself
Awesome. Too easy!
Thanks for all your help.
Most helpful comment
Yes, it's opinionated and incorrect and poorly cited.
Yes. LocalAppData doesn't roam.
Hopefully zero! Because it's not in AppData/Roaming
I sure do! Do you know why? I used to do it quite a bit when I was working on the Windows Kernel at Microsoft.
Honey, I've _written_ MSDN documentation.
Yep!
Citation needed.
So why the fuck are you bothering me?