I’m installing the app endgame in my environment.
prefetch SensorWindowsInstaller.exe sha1="" size="“
url of the file
sha256=”"
prefetch SensorWindowsInstaller.cfg sha1="" no size was defined for this file
url of the file
sha256="“
waithidden__Download\SensorWindowsInstaller.exe -c
url of cfg file -k
66EF074E27A81C1F83AD -d false -l “c:\windows\system32\logfiles\sensor_install.log”
” " the last entry in the script is highlighted in red and I receive the “Unable to parse action script line 1:” error
I was able to verify an installation of this agent on a windows 10 system and verified the logfile in its location. Attempting to install this agent on win 2008 and 2012 servers.
Is my problem with creating the log file or something else.
Thank you for your help. I was able to consult with a colleague and hash out my issues. My newness to the environment impacted my ability to get around some of my problems.
Looking at the action script, my first guess is that the config parameter ‘-c’ should reference the local path of the config file you downloaded, which would be under the BES Client’s __Download folder, rather that trying to reach the config file on a network share path.
Because the client runs under the SYSTEM account, it generally won’t be able to connect to network shares.
Instead it would be something along the lines of -c "{pathname of download folder}\SensorWindowsInstaller-Detect-new-ver.cfg"
Edit: oh, the actual prefetch urls would need to be a web site for much the same reason, the BESRootServer service also would not authenticate to a network share as a user account. It’s pretty common to either set up an internal web server for things like this, or to copy the files to the root server under the wwwrootbes\Uploads folder, and reference the urls as https://localhost:52311/Uploads/directory/filename, which is what the Software Deployment Dashboard would have simplified for you.
Thank you for your help. For starters, the url was wrong. My co-worker finally provided the correct one. Afterwards I was able to create a fixlet using Software Distribution Wizard. Finally I had to use the createfile until utility in order to capture the inputs for the log file being created during the install.
HELP!!! Here is my completed action script
prefetch 3b01470dc0bea3fb0e04b2b46ff2302e67efebee sha1:3b01470dc0bea3fb0e04b2b46ff2302e67efebee size:3975584 https://bfrepo/Endgame/Windows/SensorWindowsInstaller-Detect-new-ver.exe sha256:cbbae5c04727afb4bae662c874a5da1b53e6cd26f8122b48b13a518f58b78b61
createfile until ENDOFFILEMARKER
cd C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_Windows_Servers__Download
"SensorWindowsInstaller-Detect-new-ver.exe" -c SensorWindowsInstaller-Detect-new-ver.cfg -k 66EF074E27A81C1F83AD -d false -l "c:\windows\system32\logfiles\sensor_install.log"
ENDOFFILEMARKER
move __createfile Endgame.bat
dos Endgame.bat
Now BigFix is indicating that it has completed this action on the target however when I look at the target the app was not installed. My colleague helped me with the createfile until command in order to create a text file which captures the installation steps. The sensor_install.log file is created during this install and the createuntil command was used to capture and create this file. This ran successfully on workstations but was not successful on servers. Is this line "cd C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_Windows_Servers__Download " causing my problem?
Wow, until you quoted the sensor_install.log, I would have expected a problem like “BESClient is installed on D: drive on the servers” or “you need to quote the path on the CD command as there are spaces in it”. But if that server_install.log is getting generated that implies the batch file is at least working enough to launch the installer.
It looks like this product in particular is problematic, in that it reaches up ti the internet at installation time to download more of its package. You might ask your vendor to provide an “offline installer” that doesn’t require additional downloads.
Otherwise, check whether your traffic from Servers to Internet is allowed, you may need to define a proxy server or add firewall rules. In some organizations it is common to require a proxy server to access the Internet, and your infra team might configure the proxy clients via a Group Policy or logon script that applies to clients but not to servers.
The way this particular product is doing its downloads looks troubling from a security perspective as well…if it’s downloading a CA certificate on the fly and then explicitly trusting it for the remaining downloads, it might possibly allow a man-in-the-middle attack if an adversary could replace both the downloaded CA key and the payload it is authenticating. Usually one would expect CA keys to either be trusted by the OS explicitly (like public web browsing) or baked-in to the product configuration (like a BigFix masthead), not downloaded dynamically at installation time.
Can you clear up something for me? My colleague was able to use the command below to install the app locally on the server.
{“SensorWindowsInstaller-Detect-new-ver.exe” -c SensorWindowsInstaller-Detect-new-ver.cfg -k 66EF074E27A81C1F83AD -d false -l “c:\windows\system32\logfiles\sensor_install.log”} to install the app locally. What rights are required for BigFix to install apps on servers vs workstations?
In my environment BF is used to patch workstations and has not been configured to patch or deploy apps to servers Windows or Linux? Are there configuration steps required to perform these tasks on servers?
If you only have the Patch module, and don’t have full Lifecycle, there is still a wizard you can use to create a simple software package without writing the actionscript from scratch.
Look for the ‘Windows Software Distribution Wizard’ under the BES Support site. This might help you cut a lot of corners in terms of the issues you’ve had above.
The BigFix Agent runs as system, so when it’s installing a software package it will do so under system context. If you need a software package to be deployed under specific user context, then you will need to use the ‘RunAs’ option in the action script: