We have a task that does 3 things: 1 unintalls an app; 2 installs an app; 3 installs another app. Everything works just fine except the 2nd app does not run until someone logs in directly or via remote desktop and then it runs just fine. And it runs just fine if someone is already logged in. I am using a wait command on 2 above. Is there anyway around that and what is actually happening ? It seems to be an msi wrapped in a wise installer, but it doesnt behave correctly when we do a silent install and the company will not help us with it. Also, I cannot find a way to have it install from a file(the defaults) and so we poke them in using a macro program compiled to an exe.
I don’t think there is anything specific to BigFix that would cause this problem. I imagine that the installer itself is waiting for the user to login and thus agent is waiting for the installer. You can try to test this by running the application without the user logged in through something like the Task Scheduler independent of BigFix.
If indeed this is the case, you might try to only run this action when “user is currently logged in” OR you can try to repackage the application using commonly available repackaging tools.
Yes, the installer seems to be waiting for the user to log in.
Are there any ways to force the process to run without being logged in or to fool the program with a virtual context or is that just hopeless ?
What are the best repackaging programs to look at both free and purchased ?
If we run with “user is currently logged in” using RunAsCurrentUser.exe does this interfere in any way with the currently logged in user? Do they see it etc ? And often we will have to restart the computer after the install thus disturbing the user.
If we are in a secure internal network, is there anyway via Bigfix to force a log on, run the install and then force the logoff ?
Which are the best approaches and which are pretty much a waste of time ?
It seems to me like the easiest option is simply to choose “run only when the user is logged in” option in the Take Action Dialog. From my understanding of your issue, this will prevent your problem from occurring because the user will be guaranteed to be logged in (unless you were saying that the installer will not run as SYSTEM account even if a user is logged in, in which case you will need to use runascurrentuser.exe).
Here is some additional information about packaging tools: