New OS patching methods?

I'm not 100% certain, but I believe all patches that show up in SUS are available as direct downloads from Apple, but the reverse is not true. Not everything you can download from their support site shows up in SUS. Simple example of the latter is the Bash Update 1.0 patches.

As for fragmentation of the OS, we're kind of in the same boat. its been a challenge to get everyone updated in a timely manner, especially when we're delayed in rolling out the new OS because we need to wait on laggard vendors to update their products to be compatible.
With the release of Yosemite, we've had to drop support on 10.6. (yes, we still have a small number of clients on that version) We're going to be making a concerted effort to get users upgraded to 10.8 as a minimum OS from this point out to help reduce the fragmentation, although we'd prefer to have everyone on Mavericks or better really.

As for how to actually do the patching, man, that's a very broad question that is likely to generate a thousand different responses. There's no one correct way to do it. I would guess some would stand up a local SUS, enable whatever updates have been tested and qualified and then push them with something like "Install all updates" or softwareupdate -ia in a policy, say at logout.
Of course there's also community driven projects, like Patchoo.

We EOL'd 10.6 a while ago, and now we plan to EOL 10.7 once we roll out 10.10, following apple's unofficial Current +2 support model... 10.10 + 10.9 + 10.8...

We have kind of a hybrid of patch as patches become available and patchoo... but both can be pretty random and sporadic.

The patching method I was specifically asking about was grabbing all the patches on a particular day and then pushing them out via policy.

The patching method I was specifically asking about was grabbing all the patches on a particular day and then pushing them out via policy

If you mean multiple patches with one policy, I tired that once and couldn't deal with it. I'd have one of five fail to install on a given machine for some reason, then the policy logs would show that the policy failed for that machine. Which is true, but it was really only a 1/5th failure. Then I had to dig around to see which package failed, it was ugly.

Back to single policies for each update here.

I've been in a similar situation… trying to find a way to automate patching/OS updates. We use Intune to manage our Windows machines, and I'd love something comparable. Intune basically catches the updates on the machines, then lets the client defer updating for a week. After a week, it updates and forces the reboot to install. And this happens on a rolling basis; when new updates are released, it kicks off the cycle. I'd love something configured that way for our Macs… I put in a feature request for rolling software update policies but I don't know if that will ever happen.

Check out my old feature request if you haven't already

https://jamfnation.jamfsoftware.com/featureRequest.html?id=662

In the mean time, check out AutoPKG if you haven't already for 3rd party patches

Some of the Safari updates have been available in SUS but not from support.apple.com. So it's a bit of a mess.

I typically use a SUS and "approve" updates after they've been tested and validated. Sometimes this means manually downloading/adding to Casper/scoping to test machines, other times it may involve pointing the clients to a different update server, or removing an update server and having them go to Apple directly for updates.

It's a huge mess and it's also an example of an area where JAMF could greatly improve Casper Suite to make admins' life easier. Whether they will or not is a great question...

We run an internal SUS that all of our MACs point to, which allows us to control the updates the machines get. We also run a software update policy once per month which forces the updates. We also have an ongoing policy setup in self service to allow the users to update at will.

You could also check out Reposado. You can have multiple branches, so a test branch and then branches for classes, departments,etc for example. There are various ways to trigger this on a weekly/monthly basis.

Oxford University covered this topic within this:

http://www.jamfsoftware.com/news/video-the-college-challenge-mac-management-at-the-university-of-oxford/

https://mjung.net/publications/20121023-JAMF-NUC-The_College_Challenge-Macs_at_Oxford/Marko%20Jung%20-%20JAMF%20Software%20NUC%202012%20Minneapolis%20-%20Managing%20Macs%20at%20Oxford%20-%2020121018-1455-web.pdf

Due to Apple releasing updates at random times of the month we made the decision that "Patch Tuesday" applies to all operating systems. Second tuesday of the month we start the test process for all updates that have been released over the past month. We have a test branch setup on a NetSUS server and we also go out and find any updated versions of AppStore apps and other 3rd party apps. Individual policies are created for nonSUS apps and scoped with smartgroups.

@frozenarse - how are you deploying those updates when release time comes?

After the test period is complete, we approve the updates in the production branch of NetSUS.
For the Casper policies that handle the app updates we just mess with the smartgroup that the policy is scoped to. So for testing time the smartgroup looks for "App version is not 2.0" and "Computer group is member of TEST". Once the testing is complete we remove the criteria for the TEST group and it now will apply to all machines.

We did some custom scripting using CocoaDialog for a UI to allow for user interaction. We start our patch cycle the same day we patch Windows systems and provide a similar workflow: users are prompted daily to install updates we've blessed, and they are given until a certain date to install before it becomes mandatory and is forced. The script will inform the user of how many updates are available and let them know if a reboot is required. If so, a second script shows a countdown timer and forces the reboot at the delay we selected.

I handle the updates themselves by having the script read in a text file which is a list of the updates we've tested and blessed. The script runs softwareupdate -l, sees what is needed from that list, downloads those updates, then prompts the user (so the install can begin immediately since the updates are cached already). All of the heavy lifting is done by the softwareupdate service, which I very much prefer over processes that install the update packages directly.