We have packaged up the latest Autodesk 2016 suite of applications (seperately) using their packaging tool, which creates a setup.exe installer, which you need to pass a number of parameters to. When I execute the installation string locally on a test machine, it installs fine. When I upload the same files to Software Distribution and put in the same installation string, the files cache, the setup.exe shows up in task manager but it just sits there with 0% CPU load and the BESClient.exe process is chewing 50% of my CPU for ages and then settles down (BESClient.exe) to around 7%. After that the Autodesk and Sub Applications’ setup.exe’s are sitting there doing nothing.
I did not see this happen when the same command was executed via an admin command prompt on an identical test VM.
Why is SWD so flakey? We only just upgraded to 9.2.5 on our Server, Clients and Relays. To ensure the platform isn’t broken, I can push other software installs to this test machine fine - DropBox for instance.
I have tried installing the software using both methods, using the batch file method via the Software Distribution console and by simply having 'waithidden __Download\Setup.exe ’ in my actionscript.
Anyone else seen strange issues like this when using Software Distribution?
I’ve only seen this behavior when the Installer prompts the user for some form of Input. The most frustrating was an application that prompted the user to click OK when the install finished.
Also, you should verify that the installation is not trying to write anything to the CurrentUser registry key, since it doesn’t exist for LocalSystem.
I agree with @TimRice. Sounds like a context issue. You may need to run as a local or domain account. We use psesec in the action script for such installs.
If the installer attempts to launch a window of any kind or interact with the desktop then it will fail like this. The agent is a service and services can’t interact with the desktop (its a security thing)
When you run it manually does it bring up any dialogs? Are you instructing it to be silent?
Tim/Alan, we ran the command from an administrator’s account locally on a machine and it runs fine (No prompts or anything). We found the app drops a sub-installer’s files into %TEMP% for running some sub-installs, while the parent installer manages the sub-tasks.
When run as a local admin, you see CPU load on both the parent and child installers and the app installs fine. When run via an action with the same command, we see both the parents and child setup.exe’s, but there’s just no activity. The sub-installer’s files are dropped to the system’s %TEMP% directory - C:\Windows\Temp\ - and we can see them appearing there.
The install is definitely silent.
Autodesk support both the all-in-one install, which we have been trying and a individual install, which we have now implemented as a workaround. The individual install we have broken into seperate tasks with their own relevance for discovering the pre-reqs existance, with the application’s installer running at the end, which has solved our issue.
Just thought I would bounce this off the forums to see if anyone has any tips and tricks or seen this bahaviour before with a silent install.
You can use psexec.exe -s cmd
to open a new Command Prompt using the LocalSystem account. Psexec is part of the Sysinternals Suite (www.microsoft.com/sysinternals). You may find that your setup.exe behaves differently when run in LocalSystem context, and that may provide a clue as to what’s happening.
I had one frustrating case where %TEMP% did not seem to be defined for the LocalSystem context on one client machine.
Hi Jason,
The BES Client service runs as the LocalSystem account already, so wouldn’t all commands run as ‘System User’, when you take an action, already run as the LocalSystem user? We are seeing the %TEMP% already being populated when the installation runs. I will give PSEXEC a go though and see if it resolves the issue with this installer, although based on the documentation from Autodesk for this install, the install string works fine in SCCM, which doesn’t make IEM look great in front of a customer.
I refer to using psexec completely outside of bigfix, to open a command window running as LocalSystem with which you can interact.
Then you can manually run each step of your installation script / command lines, and you will have a visible window to show you any error messages presented by the installer.
That is often helpful to troubleshoot installers that do not run properly uner the LocalSystem account, regardless of whether you intend to deploy via BigFix, SCCM, Group Policy, or any other deployment tool.