DEP Enrollment Discrepency

[TomDay]

We've been testing DEP extensively the last few weeks preparing for a large shipment of Airs coming next week and after finally getting DEP to work correctly with our Macs, I noticed something strange that happens to 50% of the machines that get enrolled though DEP.

All devices during testing have fully wiped HDDs, new OS installed via netinstall and also computer records deleted from Jamf before running through DEP.

Anyone seen this or have any idea of what's going on? Why are some of the computers showing "Enrolled via DEP: No" and some "Enrolled via DEP: Yes"

[blackholemac]

Would you be willing to show a screen grab of your prestage config? There is a specific product issue that applies to us and may apply to you. I have a case in on the same thing at the moment.

[TomDay]

Sure here it is in 2 pieces

[jmahlman]

Hey @TomDay, long time no see. Have you tried running a recon on the systems that are marked as "No" to see if that changes to yes? I've seen some oddities with that as well.

[TomDay]

Thx @jmahlman good to hear from you. Recon doesn't help

[blackholemac]

Ty...I note that you had the same issue we did...

What is happening involves Apple’s New User-Approved MDM routines.

The simple fix is to uncheck “Allow MDM Profile Removal.” In general I don’t want to do this but it is becoming necessary.

The long-winded version...I’m presuming you have automatically installed Mac App Store apps, configuration profiles at the user level or are running the command referenced here somewhere in your workflow.

https://www.jamf.com/jamf-nation/articles/372/enabling-mdm-for-local-user-accounts

When you run any of these, UAMDM gets broken because the MDM profile gets tweaked and potentially reinstalled, breaking your DEP enrolled and UAMDM status. In general not too big of a deal unless you have an approved kernel extensions profile. (We do in my org so this is a problem.) when disallow removing the MDM Profile that is mitigated which is good for the kernel extension profile but bad for techs out in the field troubleshooting a bad or wonky MDM connection.

When you call support reference PI-004892 if you believe this issue is what is causing your grief.

[TomDay]

@blackholemac I worked with Jamf support last month on a issue where the Mac App Store Apps I had set to "automatically install" were not installing when I had the option unchecked for allowing removal. We finally figured out it was related to the defect. Those apps not installing causes a lot of issues for my Team so we are leaving the option checked. Thanks for confirming this is related to the same defect. Hope it gets fixed soon.

[blackholemac]

@TomDay ive not had a problem getting them to install. Ironically I’m having the opposite problem (potentially unrelated to this bug). When I set Mac App Store apps to auto install, they do it, but then they keep re-doing it. In my case I’m switching them to Self service...what I want from Jamf right now is device based App assignment for Macs implemented! One agent I spoke to believes that will go a long way to getting Mac App Store apps closer to true touch less.

As for a fix for UAMDM, They currently have a classified as a product issue on apples a they currently have a classified as a third party product issue on Apple’s end. That may well be true given the changes in UAMDM, That came midway through the high Sierra release

[debrat]

We are seeing this happen as well... a handful of enrolled computers are showing "NO" for "enrolled via DEP" and the MDM profile has the prompt to approve/accept. Our Prestage enrollment is set as unchecked for "Allow MDM profile removal". We are re-provisioning laptops that exhibit this behavior from scratch.

[neilmartin83]

I just wanted to dig this up as I see it too on some Macs that we're re-provisioning - seems to happen randomly and we know it's happened when after login, you're met with the Data and Privacy screen, which we suppress.

Until now I had Allow MDM Profile Removal ticked - I'll give it a try unticked to see how things go. Since Jamf is using the device channel for VPP deployments now, I'm assuming it won't cause as many issues with VPP app installs.

Wondering if folks are still experiencing this and if they have found any workarounds/fixes? I haven't contacted Jamf support yet but may do...