Action Status For New Fixlets -- Download Failed

We’re having an issue with our new BigFix environment where we create simple fixlets with a new custom site, and every time we try pushing out to an endpoint, it will have the “Pending Downloads” message for about a minute and then fail.

I’ve verified that the endpoint is subscribed to the custom site and that the fixlet is relevant. The client is also installed on the endpoint and is checking in. I seem to be able to push out actions to the endpoint because I can change the Custom Settings and such.

No firewall denies on the hardware or software firewalls.

As far as I can tell, this sounds like a caching issue, but I know that the cache amount for the main BigFix server is set to 20+GB, and I see the SHA1 for the fixlet in the uploads folder.

The size of the file matches what’s shown in the action script.

I’ve been trying to replicate the settings we have in our other environment that’s fully functioning, but I can’t seem to find what I need to change to get the fixlets to download.

First thing to try is copy the URL to the file the action script is trying to download and paste to IE/Chrome/FF and see if it downloads.

Sorry, I should have mentioned that I have it manually downloaded. It’s not pulling from a url, but from the bigfix server itself.

How does it pull from the BigFix server?

Can you share your action script? Just remove any server name/ip address references.

Sure, it’s the standard action script that’s generated when you go through the software deployment wizard:

// ---------------------------------------------EDITING INSTRUCTIONS---------------------------------------------------------------------
// When editing this task through the Manage Software Distribution Packages dashboard, you will have the option to preserve any custom edits you make to this action.
// If you select the option to preserve custom edits, only areas bound by the comment markers ‘Preparation Marker’, ‘Command Marker’ and ‘Closing Marker’ are updated.
// To ensure that all your custom Action Script changes can be preserved, only make changes to areas that are not bound by the comment markers.
// Removing the comment markers may result in the Action Script not updating correctly during the next edit.
// See KB Article swg21668807 (http://www-01.ibm.com/support/docview.wss?uid=swg21668807) for more information.
// --------------------------------------------------------------------------------------------------------------------------------------

//**Begin Preparation Marker
// Download all specified files
begin prefetch block
add prefetch item name=C8D5C327087B19793777D10398150EC71F9AFB74 sha1=c8d5c327087b19793777d10398150ec71f9afb74 size=213489005 url=SWDProtocol://127.0.0.1:52311/Uploads/C8D5C327087B19793777D10398150EC71F9AFB74/setup.exe.bfswd sha256=568184ea27c7845ed43d7414a66d4275e83a2536d0c359db58dc42001f7c5622
end prefetch block

// All SWD files will go into a folder in the clients __BESData folder. This folder gets cleared on every restart.
parameter “baseFolder” = “__Download/”
// Move files into subfolders and unescape file names
move “__Download/C8D5C327087B19793777D10398150EC71F9AFB74” “{parameter “baseFolder”}setup.exe”

// Log setup
parameter “mainSWDLogFolder” = "{parent folder of client folder of current site}/__Global/SWDDeployData"
folder create "{parameter “mainSWDLogFolder”}"
parameter “logFile” = “SWD_DeploymentResults.log”

//**End Preparation Marker
delete __createfile
parameter “logFolder” = “{parameter “mainSWDLogFolder”}”
// Run setup process
delete run.bat

// Use .bat to set working directory to packages root, for setup command.
createfile until end
@ECHO OFF
cd "{parameter “baseFolder”}"
rem // See comments at the beginning of this action for an explanation of the comment markers.
echo %DATE% %TIME% >> "{parameter “logFolder”}{parameter “logFile”}"
echo Action ID: {id of active action} >> "{parameter “logFolder”}{parameter “logFile”}"
rem //**Begin Command Marker
echo Command: “setup.exe” >> "{parameter “logFolder”}{parameter “logFile”}"
set errorlevel=
“setup.exe” >> “{parameter “logFolder”}{parameter “logFile”}” 2>&1
set SWDExitCode=%errorlevel%
rem //**End Command Marker

echo Return code: %SWDExitCode% >> "{parameter “logFolder”}{parameter “logFile”}"
echo. >> "{parameter “logFolder”}{parameter “logFile”}"
exit %SWDExitCode%
end

move __createfile run.bat
// You will not be able to stop or take action on an applicable BigFix Client until your installer completes.
// So ensure no user input is required.
// If your package absolutely must interact with the user, replace ‘override wait’ with ‘override run’ and ‘wait’ with ‘run’.
override wait
hidden=true
completion=job
wait run.bat

//**Begin Closing Marker
// Get the return code of the previous action.
parameter “returnCode” = “{exit code of action}”

// Task will now exit.
exit {parameter “returnCode”}
//**End Closing Marker

We might think it’s a client issue on the endpoint so I’m testing that next. I had used the deprecated Client Deploy Tool to push out the client to the machine before because I was having difficulty using the client deploy wizard within the console.

Edit: Something I found is that if I make the fixlet an offer, I see it in the BigFix client on the endpoint and can attempt to run, but it gives me a download failed.

In the action status on the console it should show some status (I think on the “general” tab). Does it show "cached on server"or something else?

When I choose the action and go to the Summary tab, under Downloads it says it is “Cached on Server” and the status is complete.

That’s how it should look when it’s working. From the Action History, when you go to the ‘Reported Computers’ tab, select one of the computers that showed “Download Failed”, right-click it, ‘Show action info’. What does it say there?

A required download failed.
This action has been applied one time and won’t be applied again.

Status: Download Failed
Start Time: 2:20pm
End Time: 2:20pm
Exit Code: None

Action Script…

Well yikes that doesn’t help much.
Anything in the client log? I’m thinking something like wrong size or sha1.

Unfortunately, the size is correct and the sha1 is correct (at least, I can navigate to that SHA1 number in the uploads directory and see my setup.exe is there).

I can check the client logs again. The last log I checked stated that the download tried to start but then it says something along the lines of “Jobfailed – Download stopped” I’ll have to see exactly what it says, but that’s about right.

I’ve had a case open with IBM since last Friday, but even at a level 2, I’ve only had one reply so far, hence why I reached out here as well ha.

The only thing that might be weird is that the endpoint is on a different subnet than the server, but I assume that’s the case with most places. I haven’t really configured too much because I’m fairly new to BigFix and wanted the simplest setup out of the box.

Check this thread which discusses some of the prerequisites for SWD. Setting up Software Distribution

A copy of the client logs would be handy, and L2 should be asking for that on your support case.

If I had to guess, I’d bet that the SWD Download Plugin needs to be registered on your root server. I think the Manage Software Deployment Dashboard would say this…but I wonder if it may not report the prereq correctly if your Root server is not subscribed to the Software Deployment site? Not sure though because I’d expect the action status wouldn’t say “cached on server”, but maybe worth checking.

From the client this morning:

At 07:21:29 -0500 -
DownloadsAvailable: true (action id 135)
ActionLogMessage: (action:135) Non-Distributed - DownloadsAvailable
ActionLogMessage: (action:135) Submitting download request
ActionLogMessage: (action:135) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/C8D5C327087B19793777D10398150EC71F9AFB74/setup.exe.bfswd’
DownloadsAvailable: checking for 'http://bigfixserver:52311/bfmirror/downloads/135/0
DownloadsAvailable: true (action id 135)
ActionLogMessage: (action:135) Non-Distributed - DownloadsAvailable
ActionLogMessage: (action:135) Submitting download request
ActionLogMessage: (action:135) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/C8D5C327087B19793777D10398150EC71F9AFB74/setup.exe.bfswd’
At 07:21:30 -0500 -
ActionLogMessage: (action:135) JobFailed - cancel and fail action
ActionLogMessage: (action:135) DownloadJobFailed
ActionLogMessage: (action:135) ending action
At 07:21:30 -0500 - mailboxsite (http://bigfixserver:52311/cgi-bin/bfgather.exe/mailboxsite9169320)
Not Relevant - DS - Deploy - Symantec Endpoint Protection SEP - 14 (fixlet:135)
At 07:22:34 -0500 -
Report posted successfully

In the Manage Download Plug-ins dashboard I had to enable two plugins there, but they both were analyses.
In the Manage Software Distribution dashboard is where I created the handful of simple fixlets to tests. I’ve made these a number of times before in a different environment, so I’m confident in the ability to make those packages at least.

Is there a separate Manage Software Deployment Dashboard? I’m looking into the SWD download plugin as I type, but unless it was one of the plugins during setup, I’m unfamiliar.

Go to the page https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/90553c0b-42eb-4df0-9556-d3c2e0ac4c52/page/Utilities and download the SHA1 tool.

Run the command:

sha1 -r

Verify that the result of the sha1 is the same as what is in the fixlet for the file size and sha1.

Did you also register the download plugin?
https://www.ibm.com/support/knowledgecenter/en/SS63NW_9.5.0/com.ibm.bigfix.lifecycle.doc/Lifecycle/SWD_Users_Guide/c_manage_swd_dashboard.html

I’ll look into that SHA1 tool now. As far as the plug in, it appears it’s installed because only the “Unregister Download Plug-in for Software Distribution” task is available. Edit: Verified that register download plug-in was run two weeks ago with 100% completed, although the state is expired. I just unregistered then re-registered, but the download still failed.

I kind of wonder if it’s firewall related, but I don’t see any denies on the hardware firewall from the bigfix server to the endpoint. And currently the endpoint only has the hardware firewall enabled, no windows or software one.

Edit: I just pushed the fixlet to the relay server and it started running. The relay is on the same subnet, so I’m guessing there must be a firewall issue?

Thanks everyone for the help and suggestions. It did turn out to be a firewall issue, but was showing up under “threats” instead of “traffic” so I didn’t see it at first.

I had the network services guys tweak a few rules and was able to get it working.

Something I’ve been learning more and more over the past 6 months is that if there’s an issue, it’s probably firewall-related.

1 Like

Well that’s … Special. Do you kbow specifically what alert is getting triggered? I’m suprised the firewall can flag anything other than “traffic exists” as all the client/relay traffic should be going over TLS…