We have developed installer for CentOS platform there is one behavior that we have observed.
If we run uninstaller in GUI mode it starts execution of actions one by one during that if reboot happens, after reboot all files are present there and we can execute uninstaller again.
Same case for CLI
If we run uninstaller in CLI mode it starts it starts execution of actions one by one but if during that reboot happens, after reboot all files created by install4j are removed so we cannot execute uninstaller again as even uninstall script created by installer gets deleted.
Please comment on this behavior as ideal behavior for us would be the one seen in GUI mode.
Related
I was making a script to automatically install the LSPosed version of WSA that can be found Here and since it may need to enable Hyper-V/WSL it ckecks if they are enabled and if they aren't, it enables them and then reboot.
You can run the script again to complete the building/instalation but it would be nice if you could "schedule it" to execute on the next boot as well.
Is it even possible (it needs to run as admin user)?
I work on an NSIS installer doing (among other things) in this order:
uses UAC to run elevated (this is needed for other things made by
the installer)
closes explorer.exe
starts explorer.exe (using
Exec command)
launches the installed executable, running as same
user as the one launching (using Exec command)
and everything works good.
Now the installer is requested to be launched by a Service.
This ends in both explorer and the installed program been launched as SYSTEM.
How can modify the installer to get the program run as current logged user?
I know if it was not for steps 2-3 I could use explorer to launch my executable (this works!), but this does not fit my needs, since I need also to stop and start explorer.exe as the current user.
Any idea how can accomplish that?
If you are restarting Explorer because you are installing a shell extension then this is a flawed idea. A shell extension can be loaded in any process at any time (GetOpenFilename() etc). You should rename the file that is in use and delete it later with FILE_FLAG_DELETE_ON_CLOSE and/or MoveFileEx.
If you are restarting Explorer for some other reason (Why?) it is better to restart it with the token from OpenProcessToken (or WTSQueryUserToken if you could not get Explorers token)
I am having issues getting distributed software from SCCM to install properly. This goes for both MSIs and EXEs. The software deploys properly and the respected installer, msiexec or setup.exe, start, and can be viewed in task manager, but the software never installs. The process actually stays open in task manager and never finishes. There are no errors in execmgr.log.
I have tried running from the distribution point, downloading and running locally, running with admin rights, and running as local user. I am at a loss.
I know one particular install requires you to click next once even though it has the command line switches to run a silent install. All distributed software from SCCM installs hidden from the client (even if the program is told to run Maximized), so Next can not be clicked. Is there a way around that?
The programs that are not installing all run fine when I put the same command into cmd.exe that I put in the Command line in SCCM.
Any ideas to try?
There is a way around it. AutoIT allows you capture events, but it only works consistently if you use keyboard shortcuts. Stay away from using the mouse at all, as it's not consistent. It will go through keep track of entered commands and execute them with the same timing as when you capture the commands during a trial-run of the manual install. Sometimes timing can be an issue, so you have to test.
Not a great way of doing silent installs, but every once in a while you just can't do it with MSI commands.
We have an MSI installer (created using Wix) which is setup to be able to perform upgrades. Our clients are using it to upgrade our application on multiple machines at once using an SMS package running msiexec in silent mode.
The problem with this is that some of their users will still be running our application at the time the installer is run. We don't want to kick these users off, and running the install while they are using the app invariably breaks things.
Our ideal solution would be for the install to be scheduled to happen the next time the machine boots up.
This is a fairly hefty list of requirements, but does anyone know how I could achieve this or where I might look next?
You could add a value to the registry under HKLM\software\microsoft\windows\currentversion\RunOnce and it will run the next time a user logs on.
Windows Installer automatically detects files in use. Also, during a silent installation it handles them automatically:
files which are not in use are overwritten
files in use are scheduled for update after a reboot
As you can see, this is somewhat problematic because some files are updated and some file are not.
A good solution is to set REBOOTPROMPT property to "S". This way the target machine is automatically rebooted after install.
Unfortunately MSI packages cannot detect running processes, stop the install and schedule it at the next reboot. This could be done only with a custom EXE bootstrapper.
I’m creating a setup project (Windows installer) in vs2010. When the user install it for the 1st time – everything is working just fine, but when the user try to upgrade the old application that’s running prevent of coping the new dlls to the installed folder.
How to show a user a dialog box that force him to shut down an application that prevent the installer from override a dll?
You need to check if a process with the name of your executable is running.
Then you can either abort the installation, ask the user to shut down the process or shut it down for them.
If you go for the second option you'll need to double check that they actually have shut it down before proceeding.