Trigger-Based Policy Fails

[sepiemoini]

I am noticing that while still largely successful, most of the trigger-based policies in my environment produce failed or otherwise unsuccessful push attempts on client machines within the specified scope.

Take for example the case of a Dropbox update that I created this morning. This policy is scoped to an existing Smart Computer Group for those requiring the most recent release of the application. The total scope of machines started an hour ago was targeted at 428 clients. As of right now, 115 clients have successfully installed the update while 16 have failed. All 16 clients are failing with the following error code.

Executing Policy Dropbox 3.14.7 Push... Downloading Dropbox 3.14.7.pkg... Downloading <JSSPackageLink>... The network connection was interrupted while downloading the package from <JSSPackageLink>. Attempting to reconnect... Downloading Dropbox 3.14.7.pkg... Downloading <JSSPackageLink>... Error: Dropbox 3.14.7.pkg is not available on the HTTP server. Running Recon... Retrieving inventory preferences from <JSSLink>... Locating accounts... Locating package receipts... Searching path: /Applications Locating software updates... Locating printers... Gathering application usage information...

I used to believe that the "the network connection was interrupted while downloading the package" error suggested that the client machine had lost network connectivity during the download but given the frequency that this was occurring, I decided to investigate. What I found was that I was able to ping and perform an SSH session onto the machine with the provided IP address in our JSS which suggests to me that the client never lost connectivity. Has anyone experienced this or something similar in their JSS environment? If so, could you please weigh in on this?

[sepiemoini · Accepted solution]

@rdwhitt When performing an SSH session onto a client who failed to received the push with the above error, I am unable to view the contents of the specified directory mentioned in your last post. It looks like the Downloads folder is locked down with permissions.

<hostname>:JAMF administrator$ cd /Library/Application Support/JAMF/Downloads -bash: cd: /Library/Application Support/JAMF/Downloads: Permission denied <hostname>:JAMF administrator$

I went ahead and tried to navigate to the same directory on my machine via Finder and found the same thing which supports my claim from the SSH session. Is there a way that you're aware of to bypass or grant permissions to this directory from Terminal?

[rdwhitt · Accepted solution]

You'll need to grab root first;

In terminal run

sudo su -
cd /Library/Application Support/JAMF/Downloads
rm -rf packagename.pkg

As for correcting it; for me the issue isn't happening on too many machines so I just manually fix each one. You could delete the file on a group of machine via Casper Remote or ARD, then run the "Flush all errors" in the policy.

[rdwhitt]

I've run into this a few times recently and if I check the /Library/Application Support/JAMF/Downloads folder on the client I will see the package there. If I delete the package from that folder and then flush the policy, it will run successfully. Why it is failing on a specific subset of clients when they appear to have solid network connections, I'm still not sure.

[sepiemoini]

@rdwhitt Ah, very interesting. I will SSH into a client with the posted failure and verify if that is the case with my environment. I will follow up once I am able to confirm my findings. As for correcting this subset of failures, what was your approach? Was this automated? If so, do you mind sharing the specifics?

[sepiemoini · Accepted solution]

@rdwhitt When performing an SSH session onto a client who failed to received the push with the above error, I am unable to view the contents of the specified directory mentioned in your last post. It looks like the Downloads folder is locked down with permissions.

<hostname>:JAMF administrator$ cd /Library/Application Support/JAMF/Downloads -bash: cd: /Library/Application Support/JAMF/Downloads: Permission denied <hostname>:JAMF administrator$

I went ahead and tried to navigate to the same directory on my machine via Finder and found the same thing which supports my claim from the SSH session. Is there a way that you're aware of to bypass or grant permissions to this directory from Terminal?

[rdwhitt · Accepted solution]

You'll need to grab root first;

In terminal run

sudo su -
cd /Library/Application Support/JAMF/Downloads
rm -rf packagename.pkg

As for correcting it; for me the issue isn't happening on too many machines so I just manually fix each one. You could delete the file on a group of machine via Casper Remote or ARD, then run the "Flush all errors" in the policy.

[sepiemoini · Accepted solution]

Thanks for the help, @rdwhitt! It looks like that this is an internal issue with an older guest wireless profile and those working offsite, from remote locations and off of the VPN. Because our JSS is not accessible unless a connection to our internal network is active, this relatviely small population of clients routinely fail.

[Jeff-JAMF]

Have you tried forcing the DP to use AFP or SMB (vs HTTP)?