MUT v6.0.0 is now available!

mlev
Contributor

It's finally here!

Hello everyone! I'm so excited to announce the release of MUT v6.0.0! MUT v6 is a collaboration between myself, a few other Jamf's and even a community member who submitted a PR on Github! 

MUT v6 includes code from a whopping FIVE (5) contributors now, and resolved eight (8) filed Issues on GitHub. 

As always with MUT, I strongly recommend trying out a small, test run of just a few devices before doing a massive update to your entire fleet. MUT is a very powerful tool, and while I've done plenty of testing, it is good to be careful, especially with a change as massive as this.

Changelog:

  • Added "Classic Mode" fallback when a Group or Prestage update failed due to CSV issues
  • Added ability to leverage new API endpoint for enforcing and unenforcing Mobile Device Names (requires Jamf Pro 10.33+)
  • Added ability to update Is Leased
  • Various bugfixes and optimizations

Known Issues

  • There should be a more verbose feedback if a user attempts to enforce a mobile device name, but is not on Jamf Pro 10.33+. I would like to add a popup/alert for this.

Classic Mode Details

The MUT v5 used a new method to update groups and prestages. This new method was far more efficient, but required the CSV to be perfect. Any lines with devices that were already in scope, or no longer in the environment would cause the entire update run to fail. Because of this, MUT Classic was made available, which updated group or prestage line-by-line, just as MUT v4 did.

These line-by-line submissions are far less efficient, and take significantly longer, but if there is a bad line in the CSV, MUT will simply skip over it and move on.

Now, in MUT v6, you get the best of both worlds. MUT v6 will initially attempt the new, more efficient update method, but on the off chance that it fails, you will be presented with the option to attempt a "Classic Mode" update.

Classic Mode PromptClassic Mode Prompt

It is important to note that incorrect lines will still fail with this Classic Mode, but those lines will be reported in the MUT.log for later review, and any other lines will still go through successfully.

It is important to note that Classic Mode is not compatible with "Replace" update attempts via MUT, as the entire Group or Prestage would simply be replaced with the last working line of the CSV.

Classic Mode Failure PromptClassic Mode Failure Prompt

Enforce Name Details

Once upon a time, MUT enforced names with no issue. Some API changes made this far more difficult, but as of Jamf Pro 10.33, there is an endpoint which allows for the Enforce Name checkbox to be checked or unchecked via the Jamf Pro API.

MUT v6 can leverage this endpoint, and can allow you to either enforce or unenforce the name of your Mobile Device. There is a new "Enforce Name" field in the Mobile Devices template, and this field accepts a boolean value of TRUE or FALSE. These updates can be done on their own, or in combination with any other updates.

Enforce Name ExampleEnforce Name Example

Intro and Usage Video

Useful Links

13 REPLIES 13

JayDuff
Contributor II

Being able to mass-set the Enforce Names checkbox is something I've been waiting for since we first got Casper, in 2015!  THANK YOU!!!

I'm glad you're excited! There used to be a bit of a "workaround" that MUT leveraged, where if you sent a DeviceName command via the API, it would check that box. Unfortunately that was removed a year or so ago, but this new endpoint is purpose-built for this, which is a better solution anyways. πŸ˜€

JayDuff
Contributor II

I actually found the email of the ticket I opened for this on 9/1/2015! 

Anyone else remember Shannon McIntosh?

jphillips
Contributor

Mike, what is the new endpoint for enforcing device name?

aarond
New Contributor III

Been super helpful! Especially love the ability to check or uncheck the enforce mobile device names checkbox.

Seen this behavior since v5.
Making a mobile device static group change (both add and remove) and it is successful, but it says it fails and shows this.

2021-10-25 07:22:35 [INFO  ]: Token only has -457 seconds left to live. Suggest getting a new token.
2021-10-25 07:22:41 [INFO  ]: Token only has -463 seconds left to live. Suggest getting a new token.
2021-10-25 07:22:44 [INFO  ]: Token only has -466 seconds left to live. Suggest getting a new token.
2021-10-25 07:22:47 [INFO  ]: No stored delimiter found. Using default delimiter of , .
2021-10-25 07:22:52 [WARN  ]: The user has selected to allow untrusted SSL. MUT will not be performing SSL verification. This is potentially unsafe.
2021-10-25 07:22:52 [INFO  ]: A new token was successfully generated by MUT.  200.
2021-10-25 07:23:10 [INFO  ]: Token has 1782 seconds left to live. Proceeding with current token.
2021-10-25 07:23:10 [INFO  ]: Beginning CSV Parse - Scope update.
2021-10-25 07:23:10 [INFO  ]: Submitting a PUT to https://our.JSS.URL:8443/JSSResource/mobiledevicegroups/id/396
2021-10-25 07:24:11 [FATAL ]: The request timed out.

 

Interesting. The reason MUT is saying it failed is because it's receiving a fatal error/timeout when things get submitted. Based on the :8443 I'm assuming you host your own server? You could potentially try beefing up the server temporarily to see if you still receive timeouts, or perhaps spin up a dedicated node specifically for API calls (check out the IBM presentation Mac@IBM Under the Hood, JNUC 2016, at around the 4:50 mark they show a network map that shows this https://youtu.be/E9FUBo17CAs?t=290).

What's especially interesting to me is that the call works even though it receives a timeout. I'm assuming the request is submitted and works fine, but no response is received within a given timeout time, so it just assumes it didn't work. I dont' believe there's any timeout limit like that built into MUT, so I _assume_ that's an API thing, but I'm not 100% confident in that answer. 

tl;dr "Weird. At least it's working?" haha. sorry..

aarond
New Contributor III

We do host our own server. I may play with your suggestion a bit later, but for now like you mentioned, it works so whatever.
At least after the first few times where we pulled our hair out and before we realized it was working...
No big deal now.

Just thought I'd throw it on your radar if it wasn't already when I saw this post.

Oh for sure. I appreciate it! I'm not positive what might be causing it, but I would guess it's a timeout on the API side of things. 

I'm planning on implementing some deeper debugging/logging, hopefully with different "levels" of logging as well, so you can slim down the logs if you want and only see errors, or get more verbose/debug level logs enabled instead. Perhaps that would reveal something as well.

palmna
New Contributor III

Very excited about being able to enforce the device name however, I'm running into issues.  I'm currently trying to update >5,000 device names and it'll successfully update a few hundred of them before I start getting these for the remaining 4,000+ devices:

2021-10-27 09:47:31 [INFO  ]: Submitting a PUT to https://JSSURL:8443/JSSResource/mobiledevices/serialnumber/SERIAL#HERE
2021-10-27 09:47:32 [INFO  ]: Successful PUT completed. 201.
2021-10-27 09:47:32 [INFO  ]: <?xml version="1.0" encoding="UTF-8"?><mobile_device><id>20558</id></mobile_device>
2021-10-27 09:47:32 [INFO  ]: Submitting a request to to update the name of device SERIAL#HERE to 'John Smith' with enforcement set to TRUE.
2021-10-27 09:47:32 [ERROR ]: Failed name enforcement request. 401.
2021-10-27 09:47:32 [ERROR ]: {
  "httpStatus" : 401,
  "errors" : [ {
    "code" : "INVALID_TOKEN",
    "description" : "Unauthorized",
    "id" : "0",
    "field" : null
  } ]
}

I'm guessing the API token is expiring before it finishes.  According to the MUT.log the token was generated at 07:48:19 and the first error was at 08:18:20 so it worked for 30 minutes.

I bet you're exactly right. I have been looking into token auto-renewal, but never got around to building it because I hadn't seen a use-case where it was needed. Looks like that's different now!

In the mean-time, as a workaround, I'm fairly certain the token expiry is set to the same time as your login session expiry in Pro, so if you wanted to, you could extend that session time, and get through some more lines before it times out on you. 

It appears this option is only available for Prem and premium cloud customers, but I see an :8443 in your URL above so maybe you're Prem?

https://docs.jamf.com/technical-articles/Configuring_the_Jamf_Pro_Server_Session_Timeout.html

I'll look into token auto-renewal, too.

palmna
New Contributor III

Your observation is correct, I am using an on-prem cluster.  I'll look at extending my session timeout or I might just chop my device list into smaller chunks. 

Thanks for the reply and for all your work on MUT!

To be honest, chunking out the CSV is your best bet for now. I know it's a bit of a pain, but at least you're not having to modify your server and extend session times and all of that.

Glad you like the app! I'm pretty excited about this release.