How many MDM Servers do you have in ASM?

FastGM3
Contributor

We have roughly 7000 iOS devices. We found for workflow reasons over the course of a few years and perhaps a bad practice, we got ourselves into about 230 MDM Servers on Apple School Manager.

We use them pretty much as the directional highway to our sites in Jamf. Drop a serial number in a specific sites MDM Server and it flows all the way through to a site pre-stage, smart folder, profiles without having to log into Jamf and assign the devices.

Never did we find a limit, nothing was documented that you couldn't. Nothing in Jamf docs and nothing in Apple docs states a specific limit or do's and don'ts at least what I could ever find.

I hear all this could be changing and was curious if anyone else had perhaps 10 or more MDM Servers in ASM?

Thanks

12 REPLIES 12

Sandy
Valued Contributor II

We have 11 with devices assigned and one I use just for sync w/ jamf, and 2 more that are for transitional/temporary use

thebrucecarter
Contributor II

Wait. You guys bought 230 licenses for Jamf Pro?

Clearly I am missing something here...

FastGM3
Contributor

@bcarter5876

These are MDM instances that you create in Apple School Manager for DEP enrollment in Jamf. There's no charge or licensing involved for an MDM Server. It's not really a server, that's just what they call it in Apple School Manager. It doesn't host anything except a DEP token from your Jamf server.

Hope this helps

stevewood
Honored Contributor II
Honored Contributor II

We have upwards of 100 MDM servers in ABM and we do see issues. While not published, Apple will throttle your calls to ABM/ASM. We have an AppleCare Enterprise case along with a Jamf case open about this. We get errors in the Jamf logs about being unable to communicate with the DEP service. But for our workflow we need that many. We're in the process of changing this workflow to get down to less than 10 servers.

FastGM3
Contributor

@stevewood

We have an open AppleCare Enterprise case as well. Good to hear we're not alone. I know our iOS team would really like to continue using their servers for workflow reasons as well.

Our Apple rep is suppose to help them decommission some of these but it's unrealistic to think we can easily narrow 240+ down to even 50 or less.

I'm hoping we're not the only ones, the more facing the issue maybe they will accommodate us. If we would have known there was a limit to begin with, we would have come up with different deployment workflows. Now taking them away is going to cause a bunch of headaches!

MLBZ521
Contributor III

We're also seeing these same issues. We have roughly ~120 Sites and have a DEP Token per Site, as that is required with Site functionality. We've had DEP syncing issues for a while now (Since Casper v9.xx). As soon as it's fixed, the next change breaks it again. Which causes a lot of headache and confusion with our Site Admins.

We also have a case open with Jamf and Apple Enterprise Support. Jamf has confirmed this is an issue on Apple's side which they're "working on, but an ETA is not available." Their recommendation is less than 50 Tokens, which is the first time we've ever been given an actual number in all the times we've had issues with DEP Tokens syncing between Jamf and Apple.

The environment was originally setup in this manner, using Sites extensively, before DEP was setup. Since I've come in, I've tried to change this workflow, but it's a slow process. As fast as I can consolidate a group's multiple Sites. We onboard another group which gets their own Site as well.

FastGM3
Contributor

@MLBZ521 Thanks for the feedback. In macOS we keep it real simple 3 or 4 MDM servers, but when we started getting the iOS devices each site got there own MDM Server here as well. And because we are in education, we broke the sites up by Admin, Teacher and Student adding even more MDM Servers. It was a workflow the iOS team came up with and it worked for them, that was the important thing. For a number of years it seemed like we changed our iOS deployment practice every other month. Apple Configurator was always changing.

I will have to add that both Apple and Jamf have been doing an awesome job communicating and working with us on this. I hope you guys are getting daily updates and emails, if not keep pressing on. Fingers crossed we get a quick resolution.

Chuck

MLBZ521
Contributor III

I have received regular responses from Jamf, but nothing back from Apple unfortunately.

While I do plan to consolidate the number of Sites (and DEP Tokens) that we currently have, I do hope that can resolve this issue. As I have proposed a similar workflow as you describe to our Site Admins. i.e. Have a DEP Token that is unique to a workflow, so after assigning a device in ASM, it flows through Jamf without any further actions required.

russeller
Contributor III

Hey @MLBZ521 We have around 60 MDM Servers in ASM. We see long save times when editing PreStages, and I figure it might be related to this issue. Do you see it take awhile to save PreStages sometimes?

I was considering consolidating down to 1 MDM Server in ASM and then using something like the Jamf Setup where the iPads would all have one PreStage they'd go through and then instead of the PreStage naming the iPad to put it into a Smart Group we'd have this Jamf Setup app, or something similar, that would require the techs in the field choose their "PreStage" they are supposed to be a member of. It would add some data to the device record, like an extension attribute, that would scope it to their SmartGroup then it would behave normally after that.

I have no idea how'd this all work yet, but I'm exploring this method.

MLBZ521
Contributor III

I personally do not work with PreStages that often to give an accurate response to save times. I manage the Jamf platform and only interact with some areas if I'm troubleshooting or helping a tech. (In other words, I don't setup to many devices directly these days.)

That said, it does seem longer than it used to be in the Casper 9.xxx days, but we have also grown a lot more, have a lot more DEP enabled devices....and.....have poor performance issues with our Jamf servers. (This is an entirely different conversation topic and I don't want to deviate from the point of this thread. But I will say, at least point, we believe it is "self-inflicted." [Lots of poorly configured Policies, Smart Groups, etc, by Site Admins.].)

MLBZ521
Contributor III

I meant to share this earlier this week, just been a bit behind:

Our Apple SE shared the open issue at Apple:

DEP Returning 429 error when multiple server tokens are associated with a single MDM Description: Customers associating multiple ASM/ABM server tokens with a single MDM server may receive 429 errors from the DEP service when the MDM is interacting with the API. This will prevent further communication with a specific server token until replaced. Update: Engineering has temporarily adjusted our throttling behavior and many customers will no longer see this. Those with high numbers of servers tokens (50+) may still see this intermittently. If customers are still seeing the issue frequently, please send an escalation. Engineering is working on a longterm fix designed for customers utilizing multiple ASM/ABM server tokens with a single MDM server.
The issue has a score of 100 which means that it has the highest priority of getting fixed among all issues Apple is currently working.

So we'll see how long it takes...

gsonis
New Contributor

oh this makes me feel so much better about my environment:
Healthcare
3052 iOS under mgmt
12 Tokens or as ABM calls them (Servers)
I thought 12 was a lot :) One Points to MS Intune (Legacy) and others all to Jamf

Wasn't a result of a build up, but rather by design.

While I have to let many "engineers" into Jamf, only a few have keys to the kingdom that is ABM.
Each prestage (separate use-case) catches it's own devices automatically and provisions.

I do have Sync Errors "!" on the Prestages sometimes if the device isn't properly deleted before moving.
Logs are key

March is almost here... Spring cleaning?

This way devices cannot be repurposed quietly without the right staff being engaged.