Configuration Profiles being removed and reinstalled

We see this and have for a long time.

*raises hand*

Yes, I've seen this too, and it's frankly, infuriating. I first noticed it with an important SSL intermediate decryption cert that was mandated we install on clients, and I thought would be a good idea to deploy in a Config Profile over MDM/APNs from the JSS. Unfortunately, I quickly started seeing the profile being randomly removed and reapplied. I saw no rhyme or reason for it that I could make out. I only knew it was happening because without the profile, some sites don't load without errors in browsers. So, this led to clients getting errors in their browser when hitting certain sites that would miraculously clear up some time later when the profile got re-pushed.

In the end, I switched to a more manual method of deploying the same Config Profile in a script (meaning NOT using APNs for the push) and have had zero problems since then. I personally think it's a bug between APNs and the JSS. I don't know enough about how it all works on the backend to even speculate, but the fact that it does not happen if you install a profile manually leads me to believe it's something with APNs that is causing it to be removed (it's the exact same profile just downloaded, packaged and deployed and installed manually), but it may be related to the combination of Apple's service and the JSS.

I never opened a case on it, but I may do that at some point since I do think this is something Jamf needs to investigate more fully.

I can also confirm that I see this happen all too frequently as well and it is super frustrating. So often in fact, that I'm also considering reinstalling all of my Configuration Profiles with @mm2270's script rather than using APNs... at least for the really important ones. And I also agree with what @mm2270 said above regarding a bug involving APNs and the JSS, seems like maybe it might have something to do with the ProfileList command not getting a complete list of installed profiles?

Anyone see a reason why we wouldn't be able to install the same profile with APNs and with a script? Meaning the same payload, say Network (seeing as that would cause some trouble if randomly removed) but with different PayloadUUIDs and PayloadIdentifiers? This way if there was ever a problem with profile that was installed with APNs, we'd have a backup installed as well?

another raised hand here

We have the same issue with conf-profiles too. And also the same impact on AD-Binding and certificates. But in my opinion the issue didn't came up that frequent anymore in the past weeks. Like 2 months ago we have had a really big impact and there were 5-6 machines/week where a conf-profile was removed and the Macs couldn't connect to our corporate network anymore due to missing certificates. Sounds really interessting that a lot of admins have or have had the exact same problems!

Just throwing in an additional raised hand here ... still trying to gather anything helpful as to the 'why'. In the meantime, just manually getting the machine online via any means, clearing the failed profiles in the JSS and kicking off a simple recon ...

This is something we deal with daily in my organization!

We have over 800 Macs enrolled in the JSS and every single machine loses config profiles for our cert-based wifi and VPN weekly. Based on the consensus in this thread, it may be worth it for my team to look into creating a script instead of relying on the APNs if this is a bug that jamf can't shed any light on.

We have filed this issue multiple times and it just ends up getting closed.

We've been working with Jamf on this, and it looks like they are close to releasing a 9.98x hotfix. In the meantime, is anyone else using packaged mobileconfigs for 802.1x Wi-Fi? Luckily we have a legacy SSID that our users are connecting to, or else we'd be seeing major Wi-Fi outages when the Configuration Profiles get removed and re-installed. The whole thing has really soured me from using Configuration Profiles for Wi-Fi at all.

Its a daily occurrence here too with 500 iPads we get at least one a day that has dropped off the WiFi. We reduced it by pushing out two nearly identical profiles with the hope that they wont both drop off at the same time.

In the past when we have updated the certificates in the WiFi profile we found out the hard way that the old profile is removed first before it tries to update the profile, which cant happen because the WiFi drops out.

yep getting this daily as well.

Is there any official statement from JAMF? This 'problem' is really annoying and needs a lot of capacities to get the AD-side and WLAN working again!

They told me that they think the 9.100.0 release fixes the issue, and they hope to that out by "mid to late July". So hopefully any day now.

This sure sounds exciting ...

[PI-004083] Fixed an issue that incorrectly caused computer configuration profiles to redeploy multiple times.

This further cements i'll hopefully never have to use jamf to install wifi / cert related profiles and will rely on apple's profiles commands for those as long as I can.

So far 9.100 looks like it resolved the issue.

Thanks for the post @jason.bracy. It's good to hear it looks like they got this one fixed.
Here's to hoping it stays fixed. Jamf has a funny way of occasionally reintroducing old defects in later updates. Hopefully this isn't one of those.

Had the issue once. Was a corrupt database.

We are seeing profiles being randomly removed and reinstalled however it looks like ours are being removed then installed - running JAMF 9.101.0. Anyone else still having an issue like this?

Yep - see https://www.jamf.com/jamf-nation/discussions/25665/change-in-smart-mobile-device-group-membership-pulls-config-profiles-9-101

We're having the issue, but it didn't begin happening to us until v9.100.

dwenger- Were having problems too when moved too 9.101 wireless issues

Look for the following entry in the client logs.

mdmclient Received (401) response from server - removing enrollment profile: MDM Profile

Make sure to install Managed Client for macOS from Apple Developer site on the client.

https://developer.apple.com/bug-reporting/profiles-and-logs/?platform=macos

You can terminate a management relationship with a device by performing one of these actions:

Remove the profile that contains the MDM payload. An MDM server can always remove this profile, even if it does not have the access rights to add or remove configuration profiles.

Respond to any device request with a 401 Unauthorized HTTP status. The device automatically removes the profile containing the MDM payload upon receiving a 401 status code.
"

Source:
https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/MobileDeviceManagementProtocolRef/6-MDM_Best_Practices/MDM_Best_Practices.html

I'm curious if the fact that our logging is getting spammed to hell with entries like the following (see below) is indicative of the issues posted here. I'm also curious to see if other folks are getting similar errors in their server logs.

2017-12-29 10:41:00,740 [ERROR] [Tomcat-897 ] [MDMController            ] - Error processing mdm request, returning 400. Device: Null, CommandUUID: mraNull
2017-12-29 10:41:00,740 [ERROR] [Tomcat-884 ] [MDMController            ] - Error processing mdm request, returning 400. Device: Null, CommandUUID: mraNull
2017-12-29 10:41:00,756 [ERROR] [Tomcat-207 ] [JAXBPlistParser          ] - Error unmarshalling
2017-12-29 10:41:00,756 [ERROR] [Tomcat-207 ] [MDMController            ] - Error processing mdm request, returning 400. Device: Null, CommandUUID: mraNull

@emily that's the exact same error message I'm seeing in our logs. baffles the mind. i commented on it over on this discussion. i don't know if i ever included an update to it - jamf basically says that this is due to an issue with our wireless network which is causing timeouts.

After watching the video that Apple provided and other research we are going to Apple SSL Bypass (whitelist) for Apple.com, akadns.net, ibm.com so SSL Decryption will not happen which could be a culprit in the APNS not operating. Once it is applied we will retest things again. https://www.jamf.com/resources/videos/a-push-odyssey-journey-to-the-center-of-apns/