One note, the section below can mostly likely be turned into a variable or parameter to edit the version number on the fly in the future. Otherwise, have at it. Help me improve this thing.

I will def be trying this out as soon as possible. Awesome work @bwoods !!

Thanks @nwagner! Let me know how your testing goes.

@bwoods Thanks for posting the example. Since Jamf discourages calling the API from an arbitrary endpoint, and recommends it's better used from an administrator's system you might consider creating a script that uses the API to get the members of a Static or Smart Group as the target machines for an update, and then makes the send-updates endpoint API call to force the update for those machines.

@sdagley , good to know. I thought that wasn't an issue with the new bearer token feature. That's definitely something worth looking into. Thanks again.

Bearer token auth is an improvement if you're making repeated API calls, but it does still require some exposure of the credentials used to request the token.

Your APIUser, what privileges does the account require?

Privilege Requirements (jamf.com)

This function is going to be so helpful.

Out of curiosity, are you checking before running to see if the update is already installed?  I know Jamf inventory is not always the most reliable.  In the past we've checked by running softwareupdate -l and checking for the phrase "found the following new or updated software" in the results.  I think it still works on 11+, but with how Apple is treating that command I should probably try to get the MDM command version of that same idea up and running.

Hmm, I can't seem to get this working. Here is my output:

@markopolo it looks like your device id isn't being generated for some reason. Run my function below to test recovering the device id. Refer to the highlighted sections as they determine how the device id is generated.

It looks like you are generating a token properly though. 

@McAwesome I downgrade my test machine OS before I run this. This currently works reliably to update M1's running any version of Monterey, but I'm currently working on getting full OS Upgrades working. For instance, upgrading from Big Sur to Monterey.

Right what I'm meaning is a way to make sure the function needs to be called at all.  This kind of a function is likely to be used after some kind of pop up warning given to the end user.  No sense showing them a countdown if they're already up to date.

This is really solid.  Thanks for your work on this.

As an FYI unless you want to maneuver around password complexity I experienced issues the % symbols in the API account and passing that from the script.  I created a new account without it.

Thank you. You can use single quotes to get around the password issue as well. 

Ah okay, I see what you're saying. Jamf Pro doesn't always show the correct OS version, so I need to check that the reported version is actually the version on the client. 

Thanks, I wish I was better at this . I do appreciate the help...  

So if I reduce the script to this:

This is what I get:

 And if I use a "curl -s -X" instead of a "curl -s -H" I get this:

 Not sure what I'm doing wrong. Could there be something screwy with the API on my on-prem JSS?

@markopolo , you need the variables below to properly generate a bearer token. Otherwise your API call will fail. First practice generating a token, then try to get the device id. I suggest running this in a code editor like "CoderRunner" first.

Basically, there is a difference between the "authToken" and "token" variables. The "authToken" must be generated first, but contains unnecessary information like the expiration date. The "token" variable gets rid of the unnecessary information and can be used to properly make the API call.

I would also test running my original code above with your api account, then testing with your admin account. If you get different results, it's a permissions issue.

Thanks, I actually got it working last night (tried so many things I don't remember what fixed it). Here is the final script I'm using:

 Thanks for your help, I really appreciate it!

These couple of functions may help you add some safety checks in.

 Also if I'm not mistaken you can streamline your update command so you don't have to fiddle with it as much next time around.  If you don't specify a specific version, it will download the newest one based on device eligibility.

Thanks again

Testing also seeing how the schema\\parameters of the post on the mdm command can mirror this check box "Include major updates, if available"

@Gary_R , I found that full OS Upgrades can be completed with the configuration you posted above, but it doesn't work if you specify a version. I've only been able to do this with the Jamf Pro GUI though. Can't seem to get it working with the API.

Nice work. Thank you for helping me improve this. 

ok I'll keep poking around.

Hey @bwoods, thanks for sharing this. I am just testing now and it seems great!

I have version part so that machines just get the latest available update. I have found that the process is a bit abrupt though, Have you found anyway to warn users that their Mac is about to reboot to start the update?

I use a user interaction to let them know that updates are required but because the update takes a good while to download (especially 12.3.1 to 12.4) the fact that it just restarts without another warning is a bit unfriendly.

Be great to know what you, or others, have done to make this a better experience for users.