Is anyone else seeing an issue where Configuration Profiles are being removed and reinstalled randomly? Usually not an issue until we started deploying AD Certificates via Configuration Profile. If the machine is not on the Corporate network then the reinstall fails and when the user comes back into the corporate network they cannot connect because they don't have the Certificate.
To be clear... The JSS is not issuing a remove profile command, the profiles just disappear and the JSS attempts to reinstall them.
I have an open ticket, but they can't figure out what is going on.
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!
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'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.
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.
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.
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
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/