Did you make sure you ran your mcx command while it was set to unmanaged? If you delete it before it gets the unmanaged update, it will never remove it.

At one point yes.

But cases have been sporadic, so not sure it has hit all.

So when you say it will 'never' remove it.

From where?

Would recreating the MCX work?

The unmanaged flag tells the client that it is no longer managed, allowing the users to change it if they want, but if the client machines do not request it before it is removed from the jss, then nothing is changed (according to the client). Just because the JSS isn't pushing it anymore doesn't mean the client will stop using the stored value.

What you will likely need to do is recreate a new mcx setting with the opposite value, then force all the clients to pull it down. Once you've confirmed they all have the new setting, it can then be removed from the JSS. If you want to un-manage the setting before removing it, you'll need to instantiate another pull from each of the clients a second time.

Thank you. Thought as much, but wasn't 100%.

Will report back.

You might have some luck clearing out the MCX cache from the users.

https://jamfnation.jamfsoftware.com/discussion.html?id=5171

@msblake, many thanks! re-setting to false has done it.. good to know in future

Reviving a very old thread about zombie mcx.

If you find that deleting the Managed Preferences folder doesn't fix this, they are probably hiding in Directory Services.

Try the following command as sudo or root:

dscl . -mcxdeleteall /

If it worked, you will see some output like this:

1 records updated in dsRecTypeStandard:Users
0 records updated in dsRecTypeStandard:Groups
1 records updated in dsRecTypeStandard:Computers
0 records updated in dsRecTypeStandard:ComputerGroups
0 records updated in dsRecTypeStandard:ComputerLists