Problem with configuring the iOS-Mobile Device Name using Prestage Enrollment and DEP

[BGV652]

Hello guys,

I just wanted to know if someone is experiencing the following problem too.
I have enrolled multiple iPads (Model: iPad Air) via the JSS and its Prestage Enrollment. Those devices are getting connected to our JSS via Apple's DEP.

The configuration of the Mobile Device Names of those Devices in the Prestage Enrollment is shown in the following screenshot:

As you can see the Mobile Device Name on an iPad should be "iPad650-SERIALNUMBER".

Because of different reasons those devices need to be fully wiped quite often.
Afterwards they are getting reactivated via DEP and reenrolled via Prestage Enrollment in the JSS.

Every second wipe/activation the correct Mobile Device Name is getting applied just for a few seconds and after that the Device is getting renamed just to "iPad".

At the moment we are using iOS 10.0.1 and JSS 9.96. The problem existed also in older versions of iOS and JSS.
The MDM Profile is applied after each wipe/activation.

[wenwei_hsu]

Would you happen to have a config profile with the Restriction payload where it restricts renaming devices? In my case, some of our devices are stuck with the original enforced name after wipe and re-enroll with DEP. Sending command to rename device does not work either. I had to exclude the device from the config profile in order to rename it via the JSS command.

[ChicagoGuy1984]

I have the same exact problem, which causes our issues with App Assignment and Home Layout. (both are set) according to what Pre-Stage Enrollment the device goes through. I am not sure what @whsu is referring to but we are not restricting the Naming or "Enforcing" it either .. I just want them to be named ' based on the Pre-enrollment group.

Thanks For any tips if you encountred this issue and thanks @BGV652 for explaining the problem well.!

Also Running 10.0.1 and JSS 9.96

Thank You,
Marek

[damienbarrett]

I wish that something as simple as an iOS device name could be controlled/enforced authoritatively from the JSS. I learned the hard way that devices will keep their names based on what's set in the PreStage enrollment configuration profile. For instance, if you tell the PreStage to name iPads with a serial number, then they will keep renaming themselves as serial numbers until you change the PreStage, wipe the device, and allow it to go through the Setup Assistant again. For my already-deployed 500 iPads, this is a problem -- I can't easily pull them back into until next Summer.

For the time being, JAMF gave me a Python script that allows me to rename devices in my JSS based on an authoritative Excel spreadsheet I have -- it just manipulates the field in SQL directly. This would be awesome, except every time each iOS device does an inventory update, the name in JSS changes back to a serial number.

To get around this in JSS, I've built static groups for my iPad groups. I can't rely on a device name to sort my iOS devices into Smart groups.

[mpermann]

@damienbarrett I'm able to force the iPad name to be set to whatever I want to set it to in the JSS. Our PreStage Enrollment though is set to Default Names rather than serial numbers. I'm able to go to the General payload on a device and click the Edit General button and then set the name and check the Enforce Mobile Device name and have the device name change on the iPad to what I set in the JSS. So when you do that on an iPad device record the name just resets back to the serial number? That would be highly annoying.

[bfrench]

We do not set device names in the prestage - we use a policy - but we are seeing the same issue. The device name will reset to "iPad" - if I edit the policy but not make a change to it the name will change back to what we have the name set to in the policy. We are now using JSSMUT to enforce names on iPads - http://jssmut.weebly.com/

[dprowse]

I am stuck with this too.

My environment has a mix of DEP and standard devices. My DEP assigned units are not following the rule in the pre-stage ( MCC - <serial>) and just named "iPad". I cannot change them manually even with the "modify device name" restriction checked in the Profile.

Any ideas how I can resolve as I think there is a conflict somewhere but cannot see it?

[Rhio]

If you have a Restrictions Policy and you want to ensure they follow DEP rules you must have the Restrictions Policy allow name changes like the screenshot below, otherwise, the Restrictions Policy stops the DEP policy from applying the correct name change.

[yadin]

Rhio, thanks for posting this information that JAMF fails to point out. JAMF, you really need a QA department, this is terrible design. You're stepping on your own management features and failing to work properly. This is not an issue with Profile Manager, partly because they can actually handle pre-stage naming, in addition to managing names properly at every other point.
1. We want to prevent users changing the name of a device. THIS SHOULD ABSOLUTELY BE POSSIBLE WHILE YOU MANAGE THE NAME. The fact that these are mutually exclusive settings, in different locations, is terrible design and a bug you should have fixed long ago.
2. In addition to the above, this setting of not allowing name change prevents you from setting the name when editing the device in the console. There is no error. There is no indication why it doesn't work, it just reverts on Save. This again, is terrible design, and gives the impression your software simply does not work.
3. The system does not work properly in the end anyway. Names are not set timely and accurately in any case on any OS. Even with the above settings, the device is named iPad initially, despite the name being part ENROLLMENT. This means it should NEVER be iPad, and yet it is for several minutes after enrollment. This is even worse for MacOS systems. 20+ minute lags in names being in sync between client and server, and failing to be managed at all, means that smart groups and policies and profiles based on them just do not work.

You have taken Management out of MDM.

[Hernandez]

Whoa there, pull in the reigns a bit. The challenge is with the sequence of when these commands are hitting the device upon enrollment. I am not convinced this is exclusively a Jamf issue. There is actually a simple solution to this challenge that I have found to be effective and dependable.

Solution:
Keep your device scoped to your config profile that does not allow the device name to be modified. Just create a smart group to leverage as an exclusion for your config profile . The only criteria is "Display Name" is iPad. Then call it a day, go grab a cold tasty beverage of choice and celebrate the spoils of your accomplishment!

Ultimately, this is what I have observed:
iPads will be named "iPad" by default upon being wiped/restored. Once they begin to enroll, the Config Profile will immediately load before the enrollment process can name the device (Apple, Jamf?). As a result, it will lock the device name from being modified (again, if name modification is not allowed in the CP) and we end up with a device named iPad that can't be changed. However, with the added exclusion smart group, the config profile will not load for the device if it is named "iPad". Once the enrollment process assigns the desired name (serial number, prefix, etc.), the device will then magically fall into scoping for your config profile. Your device will then have the desired name locked in place.

Hope this is helpful!

Thanks

[yadin]

Yes there are multiple ways to work around the deficiencies, you outline one of them, we use another. This in no way negates the fact that we are working around design and functionality failures. For an expensive enterprise product, this is not the expectation, especially when Profile Manager handles all these things much better. It's not an Apple issue, their product works, it's a JAMF issue. Yes JAMF does a ton of things PM does not, but the basic things PM does, it does better. JAMF needs to spend time fixing the product foundation so the bells and whistles are a better selling point. Biggest case in point, managing names of prestage devices is tragically and cripplingly missing, which has a ripple effect causing at least 3 work arounds, manual steps that shouldn't be needed, inefficient deployments, and completely negates the idea of a zero touch deployment.

[szultzie]

i think this is great that the issue has been around for years now, going back to JSS 9.96 from the OP. But this doesn't surprise me. Every-time i try to do something new using JSS, i get into such a situation. I set something that for all intents and purposes looks right(based on Jamf documentation in th GUI and admin guide) , then something bad happens(last issue was my profiles would delete after 30 days, not after 30 days from last log in. like the Confg Profile states pretty clearly, sure this was on MacOS management not iOS, but its the same thing with iOS looks like), i call support they say its a Product Issue. Yet every few months there is a new Jamf Pro with all these new fancy features, and the old bugs rarely get fixed or addressed in any ways. Then the nex update the prety new feature becomes a Product Issue. lol

So in Jamf Pro 10.8 we will be able to pre populate device records, great but about 3 years to late since now we are being forced to do zero touch DEP, but now we have to touch again. Just a big circle.

Jamf is starting to be a joke. A very expensive joke. Wish we didn't have so much invested in it, otherwise i think i could get my management to let me switch to anything else. Management doesn't understand the headaches we admins face, and i gather that Jamf management works the same way, they dont take support peoples input and are just being fueled by marketing and profits, i just hope they fix this before a new MDM comes around that actually cares about stability not features.

I know some if not most is Apples doing as well, but as i was told in the past, nobody is moving the 800LB Gorilla until it wants to move itself.