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.
Related
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.
How do I install another agent on the same Windows VM? I ran the MSI and installed it into another folder but it just unregistered the old one and the latest one took over.
What you've done so far is good, but its not the full story. For some God-forsaken reason, JetBrains made this super common thing, hard.
So you've one agent in D:\Agent-A and another in D:\Agent-B and during install you ensured they don't share any folders or ports etc.
Okay, now you have to open Notepad.exe as Administrator (to bypass the world's most annoying software 'feature', UAC) and edit:
D:\Agent-B\launcher\conf\wrapper.conf and near the bottom, append " B" to all the wrapper.console.title and wrapper.ntservice.* property values.
Now, open a Command Prompt as Administrator (to bypass the world's most annoying software 'feature', UAC) and CD into the following folder:
D:\Agent-B\bin
Now run:
service.install.bat
Check the outcome. Check that the new service appears in Windows. Start it. Wait for it to come online and authorize it in TC web UI if needed.
Done.
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 writing an NSIS installer and the setup program elevates "as administrator" as needed on Windows 7 / vista.
I need to run the installed program at the end of the install and don't want to launch it with the same privileges as the installer.
The regular NSIS exec commands run the child process with the same permissions as the installer.
There is a UAC plugin for NSIS, but the documentation on it isn't great and it seems v. new; I'd prefer not to use that plugin.
Ideally, I'm looking for a small .exe I can include that'll launch the target program without UAC elevation. Does this exist?
Any other suggestions?
Thanks!
You only have two options:
Uncheck and remove the run checkbox (When running on NT6+)
Use the UAC plugin (It is not that new, but it is a pain to use, so I would suggest you just go for the first option)
There is no external program you can use since it is impossible to get back to the original user from a elevated process (You can try, and get pretty close, but it will not get the correct user in every case)
I found the following, which could be wrappered into a a simple command line utility:
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It only took about an hour to get that code working for my project, and it works flawlessly so far. ;)
I'm fairly new to deploying desktop applications, so this is the first time I'm building an installer for my software. Currently, the first time I run my software after installing it, it crashes. After that, it runs fine. I'm still in the process of debugging this issue, but I've noticed that a reboot immediately after installing and before running the software seems to fix this crash.
What are common reasons that some installers ask you to reboot before running the software?
Also, why do some installers need to restart before finishing the installation?
Thanks in advance!
Generally, reboots between install and running are because you're replacing system DLLs that are locked. The installer sets up a run-once registry entry that copies the DLLs during boot before they're locked by Windows, and then your application can use the new DLL that you laid down.
In general, this is highly discouraged. There should be no reason anymore for anyone other than Windows itself to need to reboot after install anymore.
I'd suggest going back into a debugger to find out more details about why your application is crashing. Hopefully you have enough tracing available in your code to allow that type of debugging.
In general, a reboot is only required if the installer needs to replace files that are currently in use (and locked) by the OS. Sometimes installers will err on the side of reboot-just-in-case, but this is rarer than it used to be.
We've got a case with an installer I maintain where we need to force a reboot for vista only due to UAC and privilege elevation. Once the setup is complete we need to trigger a program as the current user context, not the elevated Vista context.
In your case, I suspect that some files haven't been correctly registered and you just need to stick with the debugging ;)