The installer was packaged with InstallAware and I’ve confirmed that “setup.exe /s” works in an Admin command prompt. Doing wait setup.exe /s says complete but the log says the install fails (and doesn’t give a good reason I can parse – log here: https://pastebin.com/TVw0cgxK).
Things I’ve tried in BigFix:
-Running setup.exe /s out of a folder other than __Download
-Createfiling a .bat that runs setup.exe /s
-Createfiling a .bat that cds to a different working directory than __Download and running setup.exe /s out of there.
-disabling wow64 redirection
-Attempted override wait as a localuser with admin but got thread execution failed
I’m stumped. Any suggestions would be appreciated!
One of the first things I would do is run CMD as the SYSTEM account using PSExec and then run the installer there to see if it works. If it doesn’t work there then you know for certain you are going to have to run the installer as a user, which completely changes the approach.
how long does it say it takes? that option shouldn’t work because it should be wait __Download\setup.exe /s
Thought it seems like you have covered that in what you have tried.
This is definitely what I would try, copy the setup to a folder path THAT DOES NOT CONTAIN SPACES and cd into it, then run the setup from there. Did the path you try have spaces?
The other option is to try the full path, not just relative paths.
For every attempt, it makes sense to try it with and without this to see if it helps.
You may need to copy the setup to another location before running as current user / local user as admin because most bigfix folders will only be available for SYSTEM by default. Thread execution failed means that it didn’t even try to run the EXE, usually because it wasn’t available at the path given.
Yeah, that was me being lazy, I should have included that the regular old wait __Download\setup.exe /s doesn’t work.
No luck with a .bat both with and without wow64 redirection, specifying full path to the exe in a path without spaces. I even moved the .bat to a different directory and called it using the full path and no dice.
Not sure if this a red herring or what, but I notice that after every failed fixlet attempt, there’s an msiexec.exe process left running but not using any resources.
That doesn’t actually execute it as the system account I think.
I think it is PsExec -accepteula -h -s to run something as the system account.
Just run CMD /K as the system account, which will open a command window running under the system account, then you can run commands as the SYSTEM account from there.
It is very likely that the Setup.exe is calling an MSI it extracts from within itself, but I’d bet it isn’t finding the MSI it is extracting which is why it is failing. That is why I think the issue would have been solved by running a BAT file that CD’s into a particular folder to do it.
Well look at that… running it with PsExec the right way creates a setup.exe process that lasts forever and uses 12-15% CPU. Looks like I should figure out how to install this as a user instead.
So it never exits when run as SYSTEM? That is a bit odd that it is using CPU… I would think that would be a good sign that it is working on something and isn’t finished.
Also, when testing it with PsExec as the SYSTEM account interactively, try it without the silent flags. Just call it with setup.exe and not the /s and go through the UI interactively and if it works, then that means that it SHOULD work as the SYSTEM account, just needs the right silent flags.
If you run it as the SYSTEM account interactively without the silent flags and it fails or thinks it succeeds but things don’t work, then you are likely looking at the need to run as a user, but this is incredibly rare.
Boy is this thing finicky. That perpetual setup.exe was because I didn’t specify an absolute path for the log location.
Calling with just setup.exe doesn’t pop up an interface. It seems to spawn a setup.exe process that immediately goes to 0% CPU that lasts until you manually end it
C:\SASC>whoami
nt authority\system
C:\SASC>C:\SASC\setup.exe
Calling setup.exe /s in the same session creates the exact same log a fixlet creates and leaves that orphan msiexec process running.
So the trick is once you can get it working in this CMD window running as SYSTEM, then you should be able to do the same through BigFix with minor differences.
If you can’t get it to work in this CMD window running as SYSTEM at all, then that is a bigger issue that might require running as a user, which hopefully is not the case because that is annoying.
If you run setup.exe as a user, does it show a UI? or does this NEVER show a UI?
Does the vendor provide silent install instructions? Is it known to be deployable through anything?
Running from a regular admin command prompt pops up the UI, as does just double-clicking the setup.exe file.
They’re a pretty small (and local) company – I’m not sure how widespread they are. Google searches don’t come up with anything as far as silent installation or anyone having tried to deploy it. I’ll shoot their support an email, but I am willing to bet they won’t have the first idea what I’m talking about based on my previous interactions with this company
That is odd, generally running it through CMD as SYSTEM should also pop up the UI, though the execution environment is a bit different. Not sure if different flags for PsExec would change things, but if you can see the CMD window then I’d assume you would see anything it launches as well.
That pops up an interface! So basically when the installer starts and runs as system, there are no folders called mia* in C:\Windows\TEMP, then it creates a folder and immediately complains that the folder exists. If I try to delete/rename that folder, Windows complains that it’s open in another program. The install never completes.
For fun, I ran the installer interactively as a regular admin and watched C:\Windows\Temp. Either the mia* folder is not created at all, or it’s created and deleted so quickly during the successful install that I didn’t notice it happen.
Regardless, this is officially Not A BigFix Problem. Thanks for the help and the crash course on PsExec @JasonWalker and @jgstew!
Getting the UI and error message is a huge hint to where the problem is.
You might be able to get around this issue by specifying a temp folder on the command line. Another option might be to temporarily override the %TEMP% env var for the command only. I know there is a way to do this for Linux.
It seems like it is trying to copy the file to the same location that it is already located in.
My guess is that folder gets created under the user account’s temp folder, not the Windows/Temp one.
This vender definitely needs to test their installers when run as the SYSTEM account since that is how 99% of enterprise deployment is done.
