Inadvertent MacOS Upgrade

jkarpenske
New Contributor III

We had a really weird hiccup the other night - On the evening of the 13th I sent a command to our lab Macs to update to macOS 12.6.2.  I did this as I've always done in the past - by going to their smart group, viewing it, clicking "Action," selecting "Send Remote Commands," and then selecting "Update OS Version," "Specific OS Version," "12.6.2," and "Download and Install the Update, then restart."  Of the 80 computers I sent this command to, 65 of them successfully updated to 12.6.2.  Then, of that 65, 27 updated to 13.1 on their own.  At first I thought I may have accidentally told them to upgrade to 13.1, but If I look at the Hardware and Software History, I can see where they updated to 12.6.2, and the next entry is them updating to 13.1.  (That and the fact that many of them ended up on 12.6.2 as was desired)

Needless to say, this is not good - our labs were held back on Monterey for various reasons, and now we'll have to wipe and re-provision 27 Macs.  Does anyone have any idea what might have caused this? 

Possibly related, we have several smart groups such as "Ventura Fully Updated" that are based upon the version number of the OS.  I get an email notification when a Mac is added to or leaves that group.  Many computers have been added and removed from this group several times in the past few days - sometimes multiple times in the same day - even though their OS has not changed.  I'm not sure what's causing this, as we've not seen this before.

If you have any ideas, please let me know.  Thanks!

1 ACCEPTED SOLUTION

jkarpenske
New Contributor III

Working with Jamf, it was identified as a known issue on Apple's end.  Much like @SCCM suggested, there's a bug that causes the softwareupdate command to see Ventura as a minor update on an Intel Mac running 12.6.1 or 12.6.2.  Here's the text from the wrap-up email from Jamf:

It looks like the upgrade issue may be due to PI110833 - "Third-Party: Computers with macOS 12.6.1 and 12.6.2 can update to macOS 13.1 using `softwareupdate -iaR` command, even when a configuration profile is installed to Defer Major Updates for 90 days". We had a configuration profile with the software update payload configured to automatically install OS updates scoped to the affected Intel computers that would have triggered the softwareupdate command on the affected computers after the upgrade to 12.6.2. At his time, we disabled the automatic OS updates on the configuration profile and are tying the case to the PI.

Unfortunately, there doesn't appear to be a "fix" at this time, other than disabling automatic OS updates for machines that might be affected.

View solution in original post

13 REPLIES 13

Soundish
New Contributor

I think I've had the same thing. Sent remote commands to update our Monterey machines to 12.6.2, I didn't use the specific version option but did have the major updates box unchecked. Then out of good luck I found multiple machines halfway through downloading Ventura so was able to stop them from actually going to 13.1.

jkarpenske
New Contributor III

Ok, I'm glad I'm not crazy (well, at least not about this!) 😀. I'm going to open a ticket with Jamf, hopefully they can figure out what's going on and can prevent this in the future.

SCCM
Contributor III

What OS were they coming off? if it wasnt 12.6.1 i think there was a bug which saw Ventura as a minor update. i.e. that command sent to 12.6.0 or below would go to ventura unless you spesified the OS version.

jkarpenske
New Contributor III

All of my machines were coming off of 12.6.1.  I can't determine why some went to the OS I specified (12.6.2) while others continued on to 13.1.  I have a ticket open with Jamf, hopefully they can shed some light on the situation.  I still have some machines on 12.6.1 that I'd like to update, but I'm afraid to do it at this point. 😁

mikeo
New Contributor III

I have noticed the exact same thing.  Our lab systems are on 12.6.1 and I wanted to update them to 12.6.2, so I ran our JAMF Policy (based on "softwareupdate --install --all --restart").  About 1/3 of our systems came back running Ventura 13.1.  This is a MAJOR problem, since we need all of our systems running the same OS and are in no way prepared to just jump to Ventura.  So now we can't update the other 400 machines we need to because we don't need any more machines we need to go to, wipe, reinstall Monterey and then reinstall the software on.  If anybody hears anything back please post here.

SCCM
Contributor III

Are these Intel machines or M1's upgrading to Ventura or both?

jkarpenske
New Contributor III

Mine were all Intel machines.  Our M1's were unaffected.

BlindBrook_Lhri
New Contributor

Same thing happened here yesterday. Absolutely specified the OS version to update and it went and did the Ventura update immediately after. 

jkarpenske
New Contributor III

Working with Jamf, it was identified as a known issue on Apple's end.  Much like @SCCM suggested, there's a bug that causes the softwareupdate command to see Ventura as a minor update on an Intel Mac running 12.6.1 or 12.6.2.  Here's the text from the wrap-up email from Jamf:

It looks like the upgrade issue may be due to PI110833 - "Third-Party: Computers with macOS 12.6.1 and 12.6.2 can update to macOS 13.1 using `softwareupdate -iaR` command, even when a configuration profile is installed to Defer Major Updates for 90 days". We had a configuration profile with the software update payload configured to automatically install OS updates scoped to the affected Intel computers that would have triggered the softwareupdate command on the affected computers after the upgrade to 12.6.2. At his time, we disabled the automatic OS updates on the configuration profile and are tying the case to the PI.

Unfortunately, there doesn't appear to be a "fix" at this time, other than disabling automatic OS updates for machines that might be affected.

This doesn't seem correct. I went through the install log and saw where the command from the MDM was sent to do the 12.6.2 update. (sent twice):

softwareupdated[336]: SUOSUServiceDaemon: No active client to do MDM minor OS update, performing update via softwareupdated w/ options: {

	    DoInForeground = 1;
	    MDMInitiated = 1;
	    ProductKeys =     (
	        "MSU_UPDATE_21G320_patch_12.6.2"
	    );
	}
2022-12-27 12:01:58-05 101C02DD0E707F5 softwareupdated[336]: MDM status: {
	    "MSU_UPDATE_21G320_patch_12.6.2" =     {
	        phase = scanning;
	        progress = 0;
	    };
	    productKeys =     (
	        "MSU_UPDATE_21G320_patch_12.6.2"
	    );
	}

 The only way the scenario you describe could be happening is if the mdm command resulted in a software update -I -a -R or software update -I -r -R (install all or install recommended respectively). If that's the case why even bother with all the 'specified version" other than the requirement of the MDM bootstrap token? 

mikeo
New Contributor III

I got off the phone with Apple Support just a little while ago and I think we figured out this problem.  Long story short, instead of running "softwareupdate --install --all --restart", we need to enter the individual updates we need installed.  For instance, if you wanted to update to Mojave 12.6.2 and the Safari 16.2 update, the command would be "softwareupdate --install Safari16.2MontereyAuto-16.2 "macOS Monterey 12.6.2-21G320" --restart" in JAMF or "sudo softwareupdate --install Safari16.2MontereyAuto-16.2 "macOS Monterey 12.6.2-21G320" --restart" in Terminal.

For those interested, the reason why Ventura 13.1 is being installed when using the --all or --recommended flags with softwareupdate is Apple has made Ventura 13.1 a recommended update.  If you do a "softwareupdate --list" you will see that Ventura 13.1 lists as "Recommended: YES".  Really irritating since OS upgrades have never been a recommended update with Apple, but I guess somebody changed their mind about this.  Hope this helps.

mikeo
New Contributor III

*"update to Monterey 12.6.2", not Mojave.

SCCM
Contributor III

@mikeo if your gonna use those commands you need to be careful with your scoping. although versions of OS might be the same the builds might be different on M1 and Intel. Der Flounder did a write up on it a while ago:
Listing the full OS installers available from Apple’s Software Update feed on macOS Big Sur | Der Fl...

These are not the same as sending remote mdm commands, doing it this way wont override deferrals if you have them set