Management commands getting stuck in a pending state

[user-BqBTAgwquG]

We’re currently battling an issue whereby some (but not all) of the configuration profiles we are deploying do not reach our Macs, instead they are stuck in a ‘pending’ state. One of them is our 802.1X Wi-Fi profile which is causing us serious problems.

I’ve tried the following:

• Deleting failed and pending commands via Mass Action
• Re-enrolling an affected device
• Verified communication to mdmenrollment.apple.com & *.push.apple.com
• Renewing the APNS token

…and unfortunately currently drawing a blank with support. Trawling through the client and server logs haven’t turned up anything useful. It was suggested that we might be hitting PI-009854, but the MySQL command provided by support disproves that theory.

We have a (non-clustered) on-premise instance of Jamf Pro v10.30.1 – we recently upgraded from v10.28.0. We’re only managing Macs with Jamf (no iOS).

Any suggestions would be greatly appreciated!

[Minomis]

Are the config profiles in each computer object getting stuck in the same order?
Just taking guesses here but maybe with the 802.1X profiles, would they be configured for auto-join?
It's possible there is a brief network drop during this time as the system attempts to switch connections?

[user-BqBTAgwquG]

@Minomis No, there just seems to be no sensible order about them!

Yes, our 802.1X profile is configured for auto-join, but we've been seeing the issue for quite a few days now (basically since we upgraded) and a couple of affected machines are connected to the wired network on campus so that I can Screen Share into them (via Jamf Remote).

I've also tried creating a brand new configuration profile from scratch, and that also gets stuck 😟

[WoodyG]

I am seeing this too.

[user-BqBTAgwquG]

What version of Jamf Pro are you running?

[WoodyG]

10.30.3 - (Cloud so I can't run the MySQL command)

It is on a test box I just wiped and upgraded to BigSur to test a new System Extension Config Profile which is "pending."  Gotta love Mac administration these days...

[bpstuder]

As I had that kind of issue, for me it was the certificate generation which was blocking the profile to be installed on the machine. So, for example, if you use a SCEP option in that profile, check the certificate is generated, both on the computer side and on the server side. Also check if another profile is not blocking the queue.

[user-BqBTAgwquG]

Thanks - I did actually de-scope our Wi-Fi profile from the affected machines which should be the only one making a certificate request. I also tried de-scoping some other profiles to see if that might unblock something, but no joy.

Out of interest, this is the MySQL command that would indicate whether you are hitting PI-009854:

SELECT mobile_device_configuration_profile_id FROM mobile_device_configuration_profiles WHERE external_config_profile_uuid IN (SELECT uuid FROM config_profiles_history WHERE (LOCATE('forceWiFiWhitelisting', payloads)!=0)) AND deleted=0;

If you get any output other than 'empty set' then it's probably the aforementioned PI.

[user-BqBTAgwquG · Accepted solution]

Thanks all for the suggestions.

This turned out to be an issue with our 'Panopto Default Settings' configuration profile which was blocking all the others due to be deployed. For some reason, the contents of the plist and the preference domain had been removed post upgrade from v10.28.0 to v10.30.1. All was well after I'd put the correct data back in.

[WoodyG]

This was exactly my case as well. A Config Profile where the preference domains were mysteriously wiped. Thanks all!