User-Level MCX not applying on 10.10 Yosemite

Matt,

I saw the same in the beta program, haven't tested in release build. I had to move to config profiles as I can't wait for Apple to fix the issue, and I would guess that they may not.

C

We saw the same thing in the DP builds as well, and moved to Configuration Profiles for the bits that weren't getting applied - mostly screensaver settings like delay and password. We've got them deployed on the release as well and they seem to be working fine.

I've only got 1 test Macbook running Yosemite, but it seems to be enforcing my user-level MCX just fine (while logged in with a mobile account on AD).

FWIW.

@mapurcel, what version of the JSS are you running?

@bentoms, we're running 9.52

@mapurcel, might be worth testing 9.6 on a test server & seeing if that resolves the issue.

Seeing as 9.6 is the 1st version of the JSS to support 10.10

Also, don't forget MCX is deprecated in OS X since Mountain Lion, so YMMV. Not sure how much effort Apple is putting into it on the newer OS X releases...

~Ted

thanks guys. We just upgraded to 9.61 and the behavior is the same. The odd thing is that the user-level MCX apply correctly to our hidden admin account, but to no other account that logs in (mobile account, AD). The same MCX settings work fine on Mavericks.

One more note is that our admin account is a local account, so the user-level MCX seem to apply correctly to local accounts, but not to mobile accounts.

Seeing the same thing here.

If I run the command: /usr/sbin/jamf mcx –username yourusername -verbose

I see the mcx we're using listed in the returned results, but do not find the plist file anywhere.

Anyone figure this out?

Seeing the same thing here on Yosemite 10.10, or 10.10.1, and JSS 9.61. No matter what commands we run, the actual user level plist files don't get pulled down and so don't get applied. We haven't deployed Yosemite yet here, so we have a little wiggle room, but will likely need to move to Configuration Profiles now for these items.

We kind of knew something like this was coming, but hoped we could still get away with using them just a little longer.

OTOH, this could be a defect in Casper. Its unclear whether its the JSS that won't deploy them down, or just Yosemite that won't accept them. Since it doesn't happen against Mavericks systems, my guess its just Yosemite.

I did a work-around by writing a script for all of the user-level MCX settings (just a lot of defaults writes) until we can get approval to fire up MDM. I set it to run at login, seems to be working fine on yoyo clients.

meh... we said screw it and chose to go with a configuration profile. worked like a charm.

@ooshnoo +1 screw it LOL

Seeing this too with 9.62 & 10.10.1.

Anyone logged a defect for this?

I don't think it's a Jamf issue, I can't remember all the testing I did in the X.10 beta program, but I think I proved that it was an Apple issue...

Casper version 9.6 MCX worked with Mac OS X.9.x Casper version 8.x MCX did not work with Mac OS X.10 beta

C

++1 for running away form MCX and heading to profiles as quickly as you can. Even if you get these working it's going to continue suffering a long slow death on your units! While we transitioned we also used defaults write to sort out any MCX permission that didn't have a direct profile corollary.

We found that our MCX has been slowly dying with every new OS release starting with 10.8 and after much delay and inaction finally moved it all over to configuration profiles for 10.10. What isn't handled by the profiles is being handled via script for new deployments. Working so far on 10.10.x and Casper 9.62.

We're in the same situation here. We hung on as long as we could due to Config profiles being a little flaky when first introduced. As of 10.9.x we were still able to use most of our MCX settings. A few didn't work well in Mavericks, but most still did. With Yosemite it seems Apple has made a definite move to kill MCX functionality in the OS, as we're finding far less of them work than those that don't, so we're moving to Config Profiles as well. No choice in the matter.
I guess I'm old school, because I still prefer the simplicity and relative flexibility of MCX over Profiles, but hopefully at this point most of the issues from older revisions have been worked out. We'll see.

@dgreening. I am in the same boat and not quite ready to use Configuration Profiles :-( Can you share your workaround script?

We moved from MCX to profiles for 10.10.

Few issues, the main one is that OOTB profiles are "enforced" (to use an MCX term).

You can recreate the once or often behaviour with MCXToProfile, but some apps will not see the payloads unless set to once or often whereas not setting that key works.

It's lead us to manage less, as there was a few keys that in hindsight we shouldn't really have bothered managing.

The issue with Configuration Profiles is that it requires use of Apple Push Notifications (APNs), which in turn requires opening firewall ports and proxy (wpad.dat) modifications to enable direct connections from endpoints to Apple's servers. This is a no-no in our environment.
So we're stuck with MCX.
Question: In macOS 10.12 ("Sierra"), has the supported status or functionality of MCX changed?

@mthakur MCX has sort of been deprecated since profiles arrival in 10.7.

I personally found that user-level MCX stopped working reliably on 10.10.

You CAN use profiles, without APNS. By installing locally

Also, security are worried about APNS.. yet used WPAD.. Erm, look at this (there are countless other similar links).

@mthakur wrote:

The issue with Configuration Profiles is that it requires use of Apple Push Notifications (APNs), which in turn requires opening firewall ports and proxy (wpad.dat) modifications to enable direct connections from endpoints to Apple's servers. This is a no-no in our environment.

Clients establish stateful connection with Apple Push Notocation Servers (APNS). That communication is initiated at the client. Why would that be an issue?

Sounds like Security at your shop needs to be on a call with your team and Apple and JAMF. We did it at several companies, ironed out all concerns within an hour, everyone ends up on board, and you avoid aligning with Apple best practices, and you avoid hacking your way into the future.

Your company relies on you for guidance and mentorship on integration of the Mac platform in enterprise, no? :)