Software Update Service Deprecated

Apple really don't want Mac's in the enterprise do they?

I'm going back to 10.6...

They might be replacing it, just not as part of the macOS Server app. I can't imagine they actually plan to remove this functionality.

While I know this doesn't mean that the Apple SUS feature will be gone overnight, I do think that this is unfortunate. A SUS is far more compatible with the concept of patch management, a feature that is being slowly added into Casper now. Having granular control over updates is an important component of many patch management solutions.

For example, you may want to allow your users over time to be able to self install combo updates (the following assumes your users are admins.) There could be a number of reasons for this, but one example would be because you have groups of users who are your testers before you roll out a big update to your entire environment. Having a SUS (and your Macs pointed to it via a policy) makes this very easy. But, with a Caching Server, it's pretty much a free for all with no control over when your users see these updates. On top of that, you have to manage the storage for a lot of data you probably don't really care about keeping (like your users' App Store purchases.)

I know there's Reposado and JAMF's NetSUS (which is basically Reposado) but hopefully these options see renewed development interest because, without Apple's SUS in the future, this means the idea of patch management is moving in the wrong direction just as JAMF is getting on the bus.

Agreed @bmarks

@alexjdale there are a lot of things that Apple have done since the death of Jobs I never would have imagined happening with him around!! It actually makes me sad how far Apple have gone for "new features" instead of focusing on what made them different, implementing things right the first time!!

Sorry for the whinge, but as an old school Mac tech, I'm pretty sick of where OS X, and OS X Server have ended up. Casper has been the only saving grace, otherwise we would have gone to windows!

Wow, I am from the other school of thought.... Why wouldn't you want security updates installed right way?

I think we as admin/management staff are enable those companies that aren't testing and ready for updates and upgrades to continue they bad behavior.

If the app breaks the app breaks stop using crapy apps.

Come on even MS is keeping their apps working ....

C

@gachowski In my environment at least, I would strongly disagree with any workflow that involves zero-day release of OS X Combo and Security updates into my environment. Now, I'm not advocating for a longterm testing process either, but even that I wouldn't necessarily oppose within reason. I have been through enough situations where a Combo or Security update breaks some other piece of software, especially other components of our security stack. I won't name names but AV software, intrusion detection software and other endpoint management and security products oftentimes never have zero-day support for incremental OS releases and thus this leads to a less than secure environment anyway while also increasing the odds of bricking. Also, anyone who works with high end video and audio apps/hardware doesn't want their Mac patched so quickly either, but those users are even more hardened to change than I am. If I were to look at my notes, I could also pick out at least 2 or 3 (if not more) episodes within the last year or so when Apple pulled back and re-released a Combo or Security update because of issues that were newly introduced. So, in our environment, we test for seven days with 2 test groups of increasing size before flipping the switch on full deployment while simultaneously during those 7 days researching certain problematic 3rd party software to see if there are explicit announcements one way or another. And, if some of those Macs were AV Macs, I'd wait even longer. Again, this is what works for us, but I don't think we're the only company out there with a patch management solution/workflow like this, especially when you look at how JAMF is adding new features to support these types of workflows in an attempt (I assume) to gain market share from solutions like IBM BigFix.

From my point of view deprecating the SUS has two sides.

One side is: Most of the Mac users and companies I know only have MacBooks because of home office usage, mobility and so on. Most of the time the devices are neither in the company network nor in VPN and cannot reach a internal SUS. I even know companies where employees are in the CN only once a year. So, if you want patched clients, patching has to be done outside the CN. Patching outside can be two things: an external reachable SUS or simply Apple / Akamai servers. Using Apple's servers has definitely the benefit of not consuming company bandwidth. Using a Caching Server inside the CN has the benefit that it is "simply there". Nothing to configure or to deal with, for iOS and macOS. Great!
Using a SUS means, you have to touch every of your clients (SUS URL), configure the SUS, maintain the SUS, you have to deal with external reachability. Ugh!
And, to be honest: when was the last minor Update (10.x.1 to 10.x.2 or similar) that REALLY broke something? I can't remember...

Overall, the benefits of NOT using a SUS are:

• simply do your updates, regardless where you are
• you don't have to deal with company bandwidth (external reachable SUS)
• no SUS to configure or maintain
• Caching Server will do the bandwidth saving for iOS and macOS inside your CN for you - you don't have to deal with two technologies that are doing very similar things.

The other side is: You don't have real control over your updates. You are not able to suppress probably problematic updates
From my point of view this is the only thing that can be painful.

The way Apple is going is pure mobility and simplicity for the end user. Joining a VPN for doing software updates is not simple for the end user. From Apple's point of view, simplicity means just using an App (Per-App VPN is the keyword), simply work all over the world and you shouldn't deal with "old" things like manually joining a VPN.

You can still use Casper to enforce updates or suppress major OS upgrades, which can really break something.

In summary: from my point of view deprecating the SUS is consequent and not really a deal breaker. You cannot even suppress updates on iOS and people (Admins!!) learned how to deal with it. Lets move on to the future and don't care about old technologies like SUS. This is what Apple has done all over the years and in my option they are on the right way.

But, then again, at least Apple is still developing Server.app ;)

I would look at it from an additional perspective too. I'm making an assumption here, but by killing off the SUS it may also mean that Apple is on the verge of completing a unified distribution backend. Right now, from what I understand, that's not the case and that's what allows 3rd party projects like Reposado to exist, i.e. the Combo/Security/Firmware updates don't come via the actual App Store backend and instead come from Apple's own longstanding SUSs. If Apple goes 100% App Store with these additional updates, including even potentially removing them from the web, then this is going to make many of our jobs as Mac admins more challenging.

Not all places uses a patching strategy, but many do and JAMF is acknowledging this by adding patch management features to the JSS to accomodate some us. Many businesses do not give their users the luxury of applying updates on their own time and/or never restarting their Macs. Updates that require restarts are the most challenging, so having a solution that allows some control is becoming more and more important to a lot of Mac businesses. A Caching Server, to be honest, doesn't really solve any of those issues. A Caching Server really solves just one issue: WAN bandwidth. With the removal of SUS as an option, this could potentially break many patch management workflows and potentially make it impossible to acquire Combo/Security/Firmware updates to be used outside of the user's interaction with the App Store app.

Yes, many business rely on their users to be responsible for being up to date on their own but many business also have specific security requirements in place to have patches deployed within agressive timeframes. Where I work, for example, OS X is about 70% of a 30,000 computer populations. All three platforms here (OS X, Windows, Linux) have patch deployments monitored by two different security teams. That may seem like overkill, but that's the environment in which I work and I don't think I'm alone. In addition, we get regularly audited and while sometimes it seems ludicrous, we have to meet the exact same requirements as the other platforms. The Caching Server doesn't help with any of this either.

Being able to access the specific packages and having some control over when they are activated are important parts of these workflows for a lot of businesses. I guess my concern is that, while Apple is always moving forward and dragging us along with them, in this case, we're talking about the removal of a feature that could just completely break a huge chunk of the concept of patch management on the Mac platform. I may be looking a bit too far down the road and maybe JAMF's initial patching features are part of something bigger, the pieces of which haven't all been made public yet. But soon, patching workflows may have to evolve to relying on aggressive nagging via popups and forced restarts, both of which are going to be far more painful than just the loss of the SUS feature.

But @bmarks, there is no difference in patching mechanisms. Whatever the packages come from, a SUS or a Caching server, you can still use "softwareupdate -l", scripts and other stuff to deal with enforcing updates, enforced restarts and so on.

FWIW, I moved from ASUS to caching over a year ago.

I detailed it some here, as well as showing how clients can ignore updates... If wanted.

I know this completely off topic, but this reminded me of a question. When silently installing updates that require a restart via the softwareupdate command, is it assumed that the restart should be immediate, as soon as possible or is there a window of time within which the user could continue to operate without issue?

@bmarks You can do that, but we have seen "Unapproved Caller" errors which I believe come from the authorization DB being updated after silently installing OS updates without a reboot at the end. You usually see that when doing something which requires auth such as unlocking a system pref pane. We avoid silently installing updates for this reason. Critical updates are of course allowed to install silently.