10.9 softwareupdate --CatalogURL no longer implemented

The switch is gone but the softwareupdate binary still respects CatalogURL settings in /Library/Preferences/com.apple.softwareupdate,
so maybe you can get around it with a few defaults write's

So long as you don't use MCX, which would trump those settings. We have been using MCX to set a "default" catalog (which would be used in the case of manual software updates), and we also create a new branch each month with the new updates enabled (which would only be invoked by our patch management process). Of course, after a new patch cycle starts, we enable those same updates in the default catalog anyway, so procedurally we just need to change our approach.

The annoying side effect is having to enable the updates we want to enable at a specific time, to coincide with our patch cycle, rather than in an ongoing fashion leading up to the new patch cycle, as the same catalog could be used for user-prompted SWU's if we continue to use MCX. I haven't tested it with Config Profiles, but I would assume those also trump /Library/Preferences.

"I haven't tested it with Config Profiles, but I would assume those also trump /Library/Preferences."

Yes, it would, as in this case the config profile is just an alternate delivery mechanism for MCX.

The higher level question is really about how you get your patch certifiers (business-aligned customers, not IT people) pre-production patches. Right now, via MCX, we set a default catalog for all of our managed clients. I can't trust MCX to apply with a reliable priority, so I can't use MCX to set a different catalog for my patch certifiers. I can no longer tell softwareupdate to use a specific catalog. The Overwrites in Policies don't work with a Net/SUS because reposed lacks a root catalog.

I'm stuck on this one; I mean, I could download the packages and distribute them as I would 3rd-party updates, but that sucks.

The higher level question is really about how you get your patch certifiers (business-aligned customers, not IT people) pre-production patches.

Why not use the JAMF NetSUS appliance and set up a special branch just for your pre-production certifiers? You'd still probably have to write the CatalogURL into their plist in some way I guess if you can't rely on MCX. Maybe set up a Self Service policy that would write in the proper branch CatalogURL to both com.apple.SoftwareUpdate.plist files, then launch Software Update/App Store right after?

@mm2270 It's an approach I've considered; I've tried manually specifying the catalog url in /Library/Preferences and /var/root/Library/Preferences, as well as deleting /Library/Managed Preferences/com.apple.SoftwareUpdate.plist, but it doesn't seem to have the desired effect.

Hmm, interesting. I saw a post on another thread regarding the fact that 10.9 has some new caching for applications that causes changes to plists written to them with tools like defaults not to get properly read until some services are restarted. If true, this could be why you're seeing unreliable results. And if true, it means a lot of workflows are going to be broken under Mavericks. Nice.
I don't know why Apple made that change, but then, who knows why they do many of the things that make our jobs harder. Oh right, I know, because they don't give a damn about us.

Yep; softwareupdated seems to be the culprit in this case. I've added a line to the end of my script and it's working as expected. Here's what I've got so far; ignore the bit about getting the date and setting the branch name (in fact, I'm probably going to have to change that). Edit: OS check fixed

#!/bin/sh

# Filename: SetSUS.sh
# Purpose: Set the Software Update Server for root and all users to the OS-appropriate catalog
# Originally created by Jared Nichols
# Modified by Josh Dyson with auto-date branch name and 10.9 compatibility

# Variable for OS Version
osversion=`sw_vers -productVersion | awk -F. '{print $2}'`

# Variables for extant settings
mcxplist="/Library/Managed Preferences/com.apple.SoftwareUpdate.plist"
libplist="/Library/Preferences/com.apple.SoftwareUpdate.plist"

# Determine the branch name based on the date format YYYYMM
branch=`date "+%Y%m"`

# Remove the existing settings
if [ -f "$mcxplist" ]; then 
    rm "$mcxplist"
fi
if [ -f "$libplist" ]; then 
    rm "$libplist"
fi

# Create the CatalogURL based on branch name
susurl="http://netsus.foo.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_$branch.sucatalog"

# Set the CatalogURL for Root & System
echo "Setting CatalogURL to $susurl..."

defaults write /var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL "$susurl"
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "$susurl"

# Kill the softwareupdated daemon to make changes effective in 10.9
if [ "$osversion" == "9" ]; then
    killall softwareupdated
fi

Does anyone have an easy way to edit the Extension Attribute for capturing the current software update server since CatalogURL is no longer a valid option? Currently my profile is applying the server correctly, but the inventory collection extension attribute doesnt return anything for CatalogURL

@elislider][/url, I think there's some confusion here. A defaults read command still works to pull the CatalogURL as defined in the plist. What the original post is about is in regards to a special flag called --CatalogURL you could append to a sudo softwareupdate command to do a one time redirect of the Mac to a different URL than what's defined in the plist. Apple removed that capability in 10.9.

Can you post your script for pulling the CatalogURL? We have one and it works fine on any Mavericks systems. So my assumption is something needs to be adjusted in your EA script.

Ah, sorry, I see that my topic is not strictly related to this. Thanks for the clarification.
I actually discovered the problem just now. The JAMF supplied extension attribute for collecting the Software Update URL looks in:
/private/var/root/Library/Preferences/com.apple.SoftwareUpdate.plist
which exists but isn't holding any information.
If I redirect the "defaults read" command to simply
/Library/Preferences/com.apple.SoftwareUpdate.plist
then it works.

I sent my account rep an email to see if they had any awareness of the issue, or if I'm the crazy one and am doing something wrong.

Well that's interesting. We don't see that issue, but then again I think we're using our own crafted EA script and not something from JAMF. I'll have to look.
But not having the CatalogURL set in the root account is a little bit of a problem. When the Casper Suite sets the SUS for a client, its supposed to do it in all locations, I think, because, if you have a policy doing something like "Install all available updates" enabled, it would be running that as root, and therefore look at the software update preferences for the root account for direction on where to pull them from. If its not set there, I assume it may try to pull the updates from Apple's servers, but I don't know that for a fact.

I have my Software Update Server defined in the JSS config and I'm just using the built-in Policy functionality of JSS 9.2x to apply the Software Update Server settings to the computers, so if its not putting it in the correct locations then it sounds like a JSS bug.

So if I am using the built in JSS 9.22 configuration profile with Software Update Server defined to go to my NetBoot/NetSUS server, how may I tell if it is actually going there or not?

CatalogURL doesn't get returned from /Library/Preferences/com.apple.SoftwareUpdate.plist but I do see my SUS listed in the appropriate profile.

Just a quick update to this discussion; my method above doesn't actually seem to work. The MCX settings seem to survive. I'm still stuck.

After install Casper 9.22, I've started to see this error when checking for Software Updates -

An error has occurred

Can't load data from Software Update server
(xxxxxx..xxx.3cinteractive.com)

The SUS is configured at Computer Management -> Server Infrastructure -> Software Update Servers

Have you guys tried also restarting cfprefsd in addition to softwareupdated? From other posts around on 10.9, that seems to be the daemon that causes preference caching to not recognize changes right away. IOW, amend the last few lines of the script from @JPDyson][/url][/url to:

if [ "$osversion" == "9" ]; then
    killall softwareupdated
    killall cfprefsd
fi

@mm2270 Doesn't seem to change anything

Not to resurrect and old post, but I'm wondering if anyone was able to figure this out? I'm setting our SUS server using a configuration profile. We've changed the profile a couple times now and I wanted to start looking at the setting using and extension attribute. For some reason, I just can't seem to find the place that the setting is consistently stored. So far in my extension attribute script I've got:

currentUser=`last -1 -t console | awk '{print $1}'`

getSUS=`sudo -u $currentUser system_profiler SPManagedClientDataType | grep -A 2 "CatalogURL" | grep "Value" | awk -F " " '{print $2}'`

if [ -z "$getSUS" ]; then
    getSUS2=`defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL`
    if [ -z "$getSUS2" ]; then
        getSUS3=`defaults read /private/var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL`
        if [ -z "$getSUS3" ]; then
            echo "<result>Not Set</result>"
        else
            echo "<result>$getSUS3</result>"
        fi
    else
        echo "<result>$getSUS2</result>"
    fi
else
    sus=`echo "$getSUS" | awk -F "//" '{print $2}' | awk -F "/" '{print $1}'`
    branch=`echo "$getSUS" | awk -F "//" '{print $2}' | awk -F "_" '{print $2}' | awk -F "." '{print $1}'`
    echo "<result>Server: $sus, Branch: $branch</result>"
fi

exit 0

I've had some good luck using the system profiler to find the information, but not all the time. Anyone else have any suggestions?

@adhuston

Here is our EA script that is confirmed to work with 10.10.3:

#!/bin/sh

SWU='nosus'
if [ -f /Library/Managed Preferences/com.apple.SoftwareUpdate.plist ]; then

SWU=`defaults read /Library/Managed Preferences/com.apple.SoftwareUpdate CatalogURL`
fi
echo "<result>$SWU</result>"

@johnnasset

Thanks! I'll give that a shot!

Andy

If you're using a method of calling softwareupdate as root, you'll need to set/verify the preference in /var/root/Library/Preferences as well.