MUT v6.0.0 is now available!


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.


  • 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


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. 😀

Contributor II

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

Anyone else remember Shannon McIntosh?

Release Candidate Programs Tester

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


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

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..

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.


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?

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

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.

New Contributor II

Mut is telling us we need to update to JAMF 10.33 but we are currently on JAMF 10.35...It is not allowing the name enforcement because its saying we need to update but we are already on 10.35

Contributor II

We are seeing this as well.  In fact, we migrated to cloud hosted last week, so we're on 10.41 now.  I hope @mlev has a fix soon!  I have 38 iPads in need of name enforcement!  🙃


Upon checking the logs, it looks like this actually started during a run on our on-prem server (we migrated to the cloud last week).



2022-09-13 03:17:16 [INFO  ]: <?xml version="1.0" encoding="UTF-8"?><mobile_device><id>6927</id></mobile_device>
2022-09-13 03:17:16 [INFO  ]: Submitting a request to to update the name of device *REDACTED* to 'iPad 7548' with enforcement set to TRUE.
2022-09-13 03:17:16 [INFO  ]: Successful name enforcement request. 200.
2022-09-13 03:17:16 [INFO  ]: Submitting a PUT to https://*REDACTED*:8443/JSSResource/mobiledevices/serialnumber/*REDACTED*
2022-09-13 03:17:17 [INFO  ]: Successful PUT completed. 201.
2022-09-13 03:17:17 [INFO  ]: <?xml version="1.0" encoding="UTF-8"?><mobile_device><id>6921</id></mobile_device>
2022-09-13 03:17:17 [INFO  ]: Submitting a request to to update the name of device *REDACTED* to 'iPad 7549' with enforcement set to TRUE.
2022-09-13 03:17:17 [INFO  ]: Successful name enforcement request. 200.
2022-09-13 03:36:59 [INFO  ]: Beginning CSV Parse - Attributes update.
2022-09-13 03:36:59 [INFO  ]: Attempting to GET the Jamf Pro Version from the API.
2022-09-13 03:36:59 [ERROR ]: Failed PATCH. 401.
2022-09-13 03:36:59 [ERROR ]: {
  "httpStatus" : 401,
  "errors" : [ {
    "code" : "INVALID_TOKEN",
    "description" : "Unauthorized",
    "id" : "0",
    "field" : null
  } ]
2022-09-13 03:36:59 [INFO  ]: Jamf Pro Version: 
2022-09-13 03:36:59 [ERROR ]: Enforcing Mobile Device Names requires Jamf Pro 10.33 or higher. Please upgrade to the latest version of Jamf Pro in order to use this feature.
2022-09-13 03:36:59 [INFO  ]: Submitting a PUT to https://*REDACTED*:8443/JSSResource/mobiledevices/serialnumber/*REDACTED*
2022-09-13 03:37:00 [INFO  ]: Successful PUT completed. 201.
2022-09-13 03:37:00 [INFO  ]: <?xml version="1.0" encoding="UTF-8"?><mobile_device><id>4945</id></mobile_device>
2022-09-13 03:37:00 [ERROR ]: Enforcing Mobile Device Names requires Jamf Pro 10.33 or higher. Please upgrade to the latest version of Jamf Pro in order to use this feature.
2022-09-13 03:37:00 [INFO  ]: Submitting a PUT to https://*REDACTED*:8443/JSSResource/mobiledevices/serialnumber/*REDACTED*
2022-09-13 03:37:00 [INFO  ]: Successful PUT completed. 201.



Oddly, migrating to the cloud has had no effect on this.

I think I solved it!


We had a CNAME in our DNS for the old on-prem server to point to the cloud server.  I was using that as the URL in the MUT.  I replaced the URL with the URL, and now it's working!  It's taking 10-12 seconds per device, but it IS working.


For what it's worth, we're on 10.40.1 and I have not had an issue enforcing names. Talk of going to 10.41 soon so we'll see what it looks like if we do.

New Contributor



when we use MUT to upload the Data to Jamf we get following error after some time : 

022-11-24 12:17:35 [INFO ]: Submitting a PUT to xxxxxx

2022-11-24 12:18:06 [ERROR ]: Failed PUT. 502.

2022-11-24 12:18:06 [ERROR ]: <!DOCTYPE html>



























<link rel="icon" sizes="192x192" href=''>

<link rel="apple-touch-icon-precomposed" sizes="180x180" href=''>

<link rel="apple-touch-icon-precomposed" sizes="152x152" href=''>

<link rel="apple-touch-icon-precomposed" sizes="144x144" href=''>

<link rel="apple-touch-icon-precomposed" sizes="120x120" href=''>

<link rel="apple-touch-icon-precomposed" sizes="114x114" href=''>

<link rel="apple-touch-icon-precomposed" sizes="76x76" href=''>

<link rel="apple-touch-icon-precomposed" sizes="72x72" href=''>

<link rel="apple-touch-icon-precomposed" href=''>

<link rel="shortcut icon" href='' type="image/x-icon">

<link rel="icon" href='' type="image/x-icon">

<link rel="mask-icon" href='' color="#5b6983">


<meta charset="utf-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">


<link rel="stylesheet" type="text/css" href=""/>


<title>Jamf Cloud - Timeout</title>



<header class="jamf-nav--fixed headroom headroom--top headroom--not-bottom" data-headroom="" data-offset="70">

<div class="jamf-nav__bar jamf-nav__bar--global">

<div class="jamf-nav__bar-content">

<div class="jamf-nav__links" role="tablist">

<a class="jamf-nav__link" href="" data-analytics-title="Home">

<svg xmlns="" viewBox="0 0 162 56" class="brand__logo">


<path class="logo__River" fill="#778eb1" d="M33.6,7 C28.1,7 24.8,9.3 23.3,14.3 L19.5,26.2 C18.1,30.1 15.8,31.7 11.7,31.7 L2.2,31.7 C1,31.7 0,32.7 0,33.9 L0,40 C0,41.1 0.9,42 2.1,42 L40.7,42 C41.9,42 42.9,41 42.9,39.8 L42.9,9.1 C42.9,7.9 42,7 40.8,7 L33.6,7 L33.6,7 Z M2.3,0 C1.1,0 0,1.1 0,2.3 L0,18.5 C0,19.8 1,20.8 2.3,20.8 L10.5,20.8 C14.2,20.8 19.4,20 20.8,13.4 C20.8,13.4 22.2,6.7 23,2.8 C23.3,1.3 22.2,-7.10542736e-15 20.7,-7.10542736e-15 L2.3,-7.10542736e-15 L2.3,0 Z"></path>

<path class="logo__wordmark" fill="#fff" d="M152.9,13.3 C152.9,7.8 156.6,5.2 161.8,5 L161.8,9.5 L160.9,9.5 C158.6,9.5 157.4,11.4 157.4,13.7 L157.4,17.3 L161.6,17.3 L161.6,21.3 L157.4,21.3 L157.4,43.5 L152.9,43.5 L152.9,21.2 L149,21.2 L149,17.2 L152.9,17.2 L152.9,13.3 L152.9,13.3 Z M137.3,27.7 C137.3,23.2 134.7,21.2 131.6,21.2 C127.9,21.2 125.1,23.6 125.1,27.9 L125.1,43.7 L120.6,43.7 L120.6,27.7 C120.6,23.2 118,21.2 114.9,21.2 C111.2,21.2 108.4,23.6 108.4,27.9 L108.4,43.7 L104,43.7 L104,17.6 L108.5,17.6 L108.5,20.7 L108.6,20.7 C109.8,18 113,17 115.7,17 C118.3,17 121.2,17.7 123.3,21.5 C124.9,18.2 128.3,17 131.7,17 C137.3,17 141.6,20.4 141.6,27.2 L141.6,43.7 L137.1,43.7 L137.1,27.7 L137.3,27.7 Z M83.1,29.9 C77.6,29.9 75.8,32.6 75.8,35.1 C75.8,37.6 77.6,40.3 83.1,40.3 C88.6,40.3 90.4,37.6 90.4,35.1 C90.4,32.6 88.5,29.9 83.1,29.9 L83.1,29.9 L83.1,29.9 Z M90.2,26.2 C90.2,21.9 85.9,20.9 82.5,20.9 C80.1,20.9 77.8,21.5 75.4,22.7 L73.4,19 C77.3,17.3 80.4,17 82.7,17 C88.9,17 94.7,19.7 94.7,25.9 L94.7,43.7 L90.5,43.7 L90.5,40.9 C88.2,43.3 85.7,44.3 82.3,44.3 C76,44.3 71,40.8 71,34.9 C71,30.1 75,25.9 82.2,25.9 C84.9,25.9 87.8,26.7 90.2,28.9 L90.2,26.2 L90.2,26.2 Z M62.5,6 C64.2,6 65.6,7.4 65.6,9.1 C65.6,10.9 64.2,12.3 62.5,12.3 C60.8,12.3 59.4,10.9 59.4,9.2 C59.4,7.4 60.8,6 62.5,6 L62.5,6 L62.5,6 Z M60.4,17.4 L64.9,17.4 L65,46.9 C65,53.7 60.6,56 55.7,56 L54,56 L54,51.8 L55.7,51.8 C60.1,51.8 60.5,49.4 60.5,47.1 L60.4,17.4 L60.4,17.4 Z"></path>







<div id="page-content" style="margin-top: 69px">

<div class="container-fluid">

<div class="row">

<div class="col-sm-12">

<div class="well">

<h2>This Service is Temporarily Unavailable</h2>

<p>Please excuse the inconvenience. It appears your request has timed out. Please try again shortly.</p>

<p>Please contact us if you need immediate assistance or would like more information.</p>


<div class="well">

<h4>Technical Support</h4>



<span class="col-xs-2">United States</span>

<a href="tel:+6122161296">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> (612) 216-1296</a>



<span class="col-xs-2">Australia</span>

<a href="tel:+610280152224">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +61 02 80 15 22 24</a>



<span class="col-xs-2">Hong Kong</span>

<a href="tel:+85258084970">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +852 5808 4970</a>



<span class="col-xs-2">United Kingdom</span>

<a href="tel:+442030147479">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +44 20 30 14 74 79</a>



<span class="col-xs-2">France</span>

<a href="tel:+33184886656">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +33 1 84 88 66 56</a>



<span class="col-xs-2">Germany</span>

<a href="tel:+496996759737">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +49 69 96 75 97 37</a>



<span class="col-xs-2">Netherlands</span>

<a href="tel:+31202410671">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +31 20 241 06 71</a>



<span class="col-xs-2">Japan</span>

<a href="tel:+81345406654">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> +81 345406654</a>



<span class="col-xs-2">China</span>

<a href="tel:4008907842">

<i class="jcon-answer" role="presentation" aria-hidden="true"></i> 400-890-7842</a>



<span class="col-xs-2">Email</span>

<a href="">

<i class="jcon-paper-plane-2" role="presentation" aria-hidden="true"></i></a>










Do you guys have any idea, how I can solve this ? 


New Contributor

Hello, I am relatively new to MUT and noticed in the UserTemplate a field that says "Managed Apple ID (Requires Jamf Pro 10.15+)". My question is, what can go in here? I have Managed AppleIDs for my students but my understanding was there is no way to populate them or even have them show up in Jamf Pro. So how do these work and or even show up in Jamf Pro?

New Contributor

Woow, amazing tool...must recommended for all jamf users spl in schools