Recently we found that the JSS was setting our clients Software Update Catalog URL to http://:/index.sucatalog.

Well, as detailed previously, we moved from using Software Update servers to Caching.

The move to caching servers actually meant I shot myself in the foot some & caused my own issue. JAMF Support got me things sorted & below is how & my guess work as to what was happening.

The Issue

In removing the need to define a Catalog URL due to moving to caching servers, I removed all defined Software Update Servers from my JSS.

However, I left a few policies like the below:

It was that innocuous drop down that caused the issue, as having that set but with no Software Update Server defined for the Network Segments scope the JSS was setting the Catalog URL as per:

The Hypothesis

When setting a Software Update Server in the JSS you only add the FQDN of the Software Update Server, such as UPDATES.MYCOMPANY.COM.

The JSS then takes that FQDN & wraps the http://:/index.sucatalog around it, making the URL something like:  http://UPDATES.MYCOMPANY.COM:/index.sucatalog

Or in bash:

So with nothing passed for the Software Update Server FQDN or the variable $updateServerFQDN above having no value, then the JSS just sets the URL to: http://:/index.sucatalog

The Resolution

Simple really, in the JSS find the policies incorrectly setting the JSS as shown in the image above & change the drop down from “Each computer’s default software update server” to “Apple’s Software Update Server”, as shown below:

After which, subsequent runs of any policies including the above would set the client to use Apple. As the below shows:

Tracking Down The Issue

I started investigating the issue when I realised a number of our Mac’s were behind a OS X point release.

When moving to caching servers, we had set a policy for all Mac’s that ran the below:

sudo jamf -removeSWUSettings

This should have been enough to reset each Mac to look at Apple for Software Updates & therefore use our caching servers.

However, as you can see from the above I hadn’t realised yet that that this was only part of the solution.

So I set about figuring out what was going on with the below Extension Attribute & a Smart Group that was the EA returning “Set”

Then a policy would run the below again to reset:

sudo jamf -removeSWUSettings

Obviously, with the details of the issue given above this merry little dance could have carried on until the heat death of the universe.

Anyways, just thought I’d share how I shot myself in the foot some (& like I really need any more help with that).