Configuration Profiles not pushing to macOS devices

DaneAbernathy
New Contributor III

I’m having a strange issue that started within the last week or so. Some laptops are not receiving some configuration profiles. Two profiles in particular (maybe more but this is the first I have noticed), and not every laptop is affected. One is for Jamf Connect. It’s an uploaded profile straight from the Jamf Connect Configuration app. The other is for the Root3 support app.

I have tried different versions of each profile, one using the built-in Jamf Connect schemas and one with the upload. I have tried the same with the Root3 app, one using their JSON schema and one with the plist.

Neither will push down to some devices. Hardware doesn’t make a difference, and neither does os. It’s happening on Monterey and Big Sur, and intel or Apple processors.

I am at a loss. Logs for both say failed on the device inventory page and pending on the profile pages.

We’re on Jamf Pro Cloud.

Is anyone else having issues?

1 ACCEPTED SOLUTION

DaneAbernathy
New Contributor III

I have a final update on this, never really got traction from Jamf support on this specific topic. We ended up having two separate issues with computers and iPads, with two support tickets, and figured it out independently.

If you have extension attributes pulling LDAP from Azure through the cloud connector and the EA returns a "null" value, Jamf Pro will refuse to push configuration profiles that include Jamf dynamic variables. This also blocked Jamf Self Service from installing on some iPads since the App Configuration also uses dynamic variables. The attribute in question was businessPhones and some of our user's Azure user profiles don't have phone numbers, so Azure reports this as a "null" value which Jamf does not like.

 

So if you are having an issue where config profiles aren't pushing to computers, or some apps aren't installing to iPads, and you are a Microsoft/Azure shop, check your EA attributes that are using LDAP through the cloud connector. 

View solution in original post

14 REPLIES 14

PaulHazelden
Valued Contributor

Open a Support case with them, I have the same thing and have a case open. Maybe if they can see it on more than one server, they will fix it quicker.
I also have Jamf protect not updating, or any commands going through. It is something in the database they say.

And like you it is ramdom, some Silicon macs work some don't. Some Intel Macs work some don't

I have macs on the same VLAN that work and some that don't. There does not seem to be a common factor that you can point to and say, all of the macs that have this thing are the ones that work, and the ones without don't work.

I started a case this week. Still no word on what the issue is yet.  Have you received any word or solution from support yet?

Not exactly. They think there is some error in the MDM communication. They dont know the root cause. They gave me this Extension Attribute to look for the affected Macs...

#!/bin/bash
result=$(log show --style compact --predicate '(process CONTAINS "mdmclient")' --last 1d | grep "Unable to create MDM identity")
if [[ $result == '' ]]
then
echo "<result>MDM is communicating</result>"
else
echo "<result>MDM is broken</result>"
fi

Add this in as an EA, in your server, then run an inventory update on all devices.

Create a Smart group looking for them with MDM is Broken as a result. I have a lot.

Their fix is for me to erase them, remove the record and start again.

 

So I added that script as well, the machines having the issue are not reporting that the communication is broken lol

 

So, for me at least, that isn't the issue.

Possible breakthrough in figuring this out. I just went through each key in one of the profiles, one by one, and found that I had a key with a value of an extension attribute. Once I removed that key, BOOM completed and pushed. 


Do any of the ones you are having issues with have extension attributes?

 

I tried two different ones. one with an LDAP and one with a script. There were to fill the username in keychain to update the user's password in Jamf Connect when changing their password.

Mine is looking more like a script I was running to add a defaults write to a plist for NoMAD, was somehow breaking the MDM trust on the Mac. Looks like the only fix is to erase them. I can do a re-enrol in Terminal and that gives me back some control, but does not allow commands through.

Can you explain what you did here in more detail i think we are seeing this but im not familar with the terms you are using here.

 

Their fix is for me to erase them, remove the record and start again.

 

What do you mean by the statement above?  Remove the object from JAMF and re-image the device? 

Start the erase process on the Mac, then open Jamf server and find the record for the Mac you just set off to erase, and delete the record. Then complete the erase process and let the device re-enroll into jamf. it will create a new record, and a new ID number.

I've noticed some Macs that still check in and submit inventories but have stuck MDM commands.

Here's a Jamf EA that can assist:

https://github.com/jamf/Jamf-Nation-Extension-Attributes/blob/master/Verify%20MDM%20Enrollment.xml

 

#!/bin/sh
mdmEnrollmentProfileID="00000000-0000-0000-A000-4A414D460003"
enrolled=`/usr/bin/profiles -C | /usr/bin/grep "$mdmEnrollmentProfileID"`

if [ "$enrolled" != "" ]; then
	echo "<result>Enrolled</result>"
else
	echo "<result>Not Enrolled</result>"
fi

 

Create a Smart Group looking for devices that show "Not Enrolled." When you find some, they should show MDM commands stuck in a pending state. Generally, re-enrolling this devices will fix the issue. But at least this helps find these broken devices.

DaneAbernathy
New Contributor III

I have a final update on this, never really got traction from Jamf support on this specific topic. We ended up having two separate issues with computers and iPads, with two support tickets, and figured it out independently.

If you have extension attributes pulling LDAP from Azure through the cloud connector and the EA returns a "null" value, Jamf Pro will refuse to push configuration profiles that include Jamf dynamic variables. This also blocked Jamf Self Service from installing on some iPads since the App Configuration also uses dynamic variables. The attribute in question was businessPhones and some of our user's Azure user profiles don't have phone numbers, so Azure reports this as a "null" value which Jamf does not like.

 

So if you are having an issue where config profiles aren't pushing to computers, or some apps aren't installing to iPads, and you are a Microsoft/Azure shop, check your EA attributes that are using LDAP through the cloud connector. 

jschank
Contributor

  I have been using this.  This documentation seems to be more for Mojave devices.  Need to tweak on other macOS versions.  May also need to go into Disk Utility within recovery mode to mount Macintosh HD - Data.

  I recommend creating another Prestage that does nothing.  Move the object to that Prestage so when you re enroll it will not reinstall apps that you may have setup on your default Prestage environment.  You can move back once the device is working properly.

 

http://www.whoopis.com/core/mac-related/removing-a-non-removable.html

https://graffino.com/til/UmkCdmEx7v-remove-a-non-removable-mdm-profile-from-macos-without-a-complete...

 

 

 

Posting this Jamf Nation link that that talks about config profiles that stop pushing out. It might be what people are seeing. been working for months with Jamf on this. Also @PaulHazelden script was very useful 

https://community.jamf.com/t5/jamf-pro/jamf-configuration-profiles-stuck-pending/m-p/294333/highligh...