Skip to main content
Solved

zombie MCX

  • December 5, 2013
  • 7 replies
  • 32 views
bentoms
Forum|alt.badge.img+35

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

Best answer by mscottblake

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.

    7 replies

    mscottblake
    Forum|alt.badge.img+24
    • mscottblake
    • Honored Contributor
    • December 6, 2013

    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
    Forum|alt.badge.img+35
    • bentoms
    • Author
    • Hall of Fame
    • December 6, 2013

    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
    Forum|alt.badge.img+24
    • mscottblake
    • Honored Contributor
    • Answer
    • December 6, 2013

    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
    Forum|alt.badge.img+35
    • bentoms
    • Author
    • Hall of Fame
    • December 6, 2013

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

    Will report back.

    J
    Forum|alt.badge.img+13
    • JPDyson
    • Valued Contributor
    • December 6, 2013

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

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

    bentoms
    Forum|alt.badge.img+35
    • bentoms
    • Author
    • Hall of Fame
    • December 13, 2013

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

    bradtchapman
    Forum|alt.badge.img+20
    • bradtchapman
    • Valued Contributor
    • March 2, 2017

    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

    Terms & ConditionsCookie settingsAccessibility statement