Handling Policy Failures

@Kennedy, we mostly scope ours to smart groups & ongoing & we use HTTP.

So, the JSS will keep trying it until completed, Which should then make the Mac be fall out of the Smart Groups scope.

We do same thing as bentmos. For instance with Office Updates:
POLICY: Microsoft Office 14.4.8 - Cache
Scope: Microsoft - Office - Not Current Version != 14.4.8 [Smart Computer Group]
Exclusions: Microsoft - Office 14.4.8 - Cached [Smart Computer Group]
Microsoft Office - Older than 14.1.0 [Smart Computer Group]

POLICY: Microsoft Office 14.4.8 - Installed Cached Update
scope: Microsoft - Office 14.4.8 - Cached [Smart Computer Group]
Exclusions: Microsoft - Office 14.4.8 - Installed [Smart Computer Group]
Microsoft Office - Older than 14.1.0 [Smart Computer Group]

I never have to flush errors this way.

I would recommend voting up the feature request on this one (https://jamfnation.jamfsoftware.com/featureRequest.html?id=3045). We also do a similar setup to @bentoms, just not with HTTP (which is our next plan). We've got AFP/SMB DPs in a lot of our environments which is a bit annoying.

@bentoms, on a side note, how do you find HTTP DP performance Vs AFP/SMB?

I had actually already moved a couple of policies over to ongoing to test - works well, which is why I don't think that feature request will be implemented in a hurry.

I have voted up that feature request, but I feel like we can already achieve what @Dickson is suggesting.

We can see the same functionality in the feature request by using ongoing policies. If we want to rerun on script failure, we can do that now with ongoing. If we don't want to re-run we just set it to once per computer.

With scripts, we can write bread crumb files if we only want a policy to run 3 times, and just use smart groups and limitations to achieve this.

Is there something you're thinking of with that feature request that we can't achieve already? I'm always looking for more options!

Thanks for everyone's input - gives me some piece of mind!

@davidacland - we moved to HTTP DPs just recently so that policies can execute offsite etc. I see no performance issues locally compared with AFP, our clients generally see speeds near what we'd expect as a maximum for their respective network speeds.

Cheers,
Gavin

@davidacland, most of our clients are on 100MB & we rarely push large files to clients.

When we were doing self service installs of 10.9, it took 30 minutes to cache the installer from the local DP.

That's fine for us, HTTP/S downloads being resumable was more important.

Just another quick thought for those not already doing ongoing policies, and are looking at moving to them: Make sure you update inventory as part of your policy. We had a couple of policies that didn't have the update inventory as part of the policy and kept installing until the smart groups were updated by a recon (performed at other intervals).

Cheers!

For the inventory/recon management I have done the following.
Create a smart group of machines where the Inventory is older than a day
Have a policy run recon on this group once per day.

Then have any "ongoing" policies set to "Once per day" instead.

It stops you having to recon all the time and one try a day until its successful is probably sufficient for most purposes.

Since doing this I have removed the recon step from pretty much all other policies except for the very rare instances like multi step processes.