zombie MCX

bentoms
Release Candidate Programs Tester

Hi all,

Having an issue whereby we had the key showInputMenu set to true for the loginwindow.plist... This seems to have caused issues when se clients are waking from sleep or screens saver & are then beachballing.

I set the MCX as unmanaged, & later deleted it.

Running a sudo JAMF MCX -username (user) -verbose doesn't show the MCX.

But the setting is being applied.

Should I delete/flush the MCX Cache @ logout next? & if so, what's your favourite method? (It's a user level MCX).

This linked script deletes the keys, so worse case I'm running this as a launch agent. https://github.com/macmule/DeleteLoginwindowPlistShowInputMenuKey

1 ACCEPTED SOLUTION

mscottblake
Valued Contributor

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.

View solution in original post

7 REPLIES 7

mscottblake
Valued Contributor

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.

bentoms
Release Candidate Programs Tester

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?

mscottblake
Valued Contributor

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.

bentoms
Release Candidate Programs Tester

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

Will report back.

JPDyson
Valued Contributor

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

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

bentoms
Release Candidate Programs Tester

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

bradtchapman
Valued Contributor II

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