Posted on 03-30-2022 03:35 PM
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?
Solved! Go to Solution.
09-15-2022 04:52 AM - edited 09-15-2022 04:53 AM
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.
Posted on 03-31-2022 01:30 AM
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.
Posted on 03-31-2022 03:33 AM
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.
Posted on 04-08-2022 07:50 PM
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?
Posted on 04-12-2022 03:44 AM
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.
04-13-2022 01:27 PM - edited 04-13-2022 01:29 PM
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.
Posted on 04-14-2022 07:14 AM
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.
Posted on 04-26-2022 06:07 AM
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.
08-24-2023 09:52 AM - edited 08-24-2023 10:00 AM
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.
Posted on 10-26-2022 06:52 AM
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?
Posted on 10-31-2022 04:46 AM
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.
Posted on 01-29-2024 04:59 PM
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.
09-15-2022 04:52 AM - edited 09-15-2022 04:53 AM
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.
Posted on 02-10-2023 08:32 AM
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
06-29-2023 07:45 AM - edited 06-29-2023 07:46 AM
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