Mavericks Config Profiles Not Enabling Shutdown Button

I had the same issue, plus the login screen showed a list of users instead of my desired username/password. I had set my image System Preferences to show username/password and Shutdown button. Somehow, it would never take the settings. I found a config profile I had created to set the Security preference to allow software to be installed from anywhere (not just signed software) also contained elements of the Login Window preferences. I did not see anything exactly configuring the window, but once I disabled the profile, everything was back to normal. Look through your Config Profiles to see if any of them contain a Login Window configuration piece, and disable it. Make sure that profile is removed from the Mac, reboot, and let us know what the results are.

@majedian21

@Mike_Meyers ' suggestion would be where I'd check first.

If we have multiple config profiles that have something specified in a Login Window profile payload, what usually happens is the most restrictive setting 'wins', and the option to show the shutdown button being unchecked/disabled is considered more restrictive by the OS than showing the button so the profiles that have a Login Window payload with the option to show the shutdown button unchecked would take precedence over the profile that has the option to show the shutdown button checked.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff

The security profile that included pieces of the Login Window configuration did not have any mention or indication of the Shutdown button at all, but when I disabled that profile, the button showed back up. Strange.

Thanks,

Mike

@Mike_Meyers

By default, if you just add a Login Window payload (even if you change nothing else) the box for Show Shutdown Button is unchecked. If there were other options set on a Login Window payload for the security profile we'd set up, and that Show Shutdown Button was left unchecked, the OS would still view it as the button being visible being 'restricted', so the settings from the security profile's Login Window payload would take precedence in the OS over the profile that was set up to specifically have the Show Shutdown Button box checked in the Login Window payload.

It's one of those things that's enough to drive you nuts when troubleshooting as most people look at it and don't view it as a 'restriction' so much as an on/off option; OS X, however, looks at it as a type of restriction, so the profile that has the most restrictive payload on it is the one that gets its settings properly applied.

That would likely explain why disabling the security profile that had a Login Window payload on it allowed the other profile with the Login Window payload that specifically had Show Shutdown Button to work.

In cases like that, we'd recommend trying to put all of the Login Window payload items you want set on one profile, and split out the non-Login Window payloads for the security profile into a separate profile.

Thanks!

Amanda Wulff
JAMF Software Support

@amanda.wulff

I usually have each setting split out to different profiles. The profile causing the issue had a Security & Privacy setting to change the GateKeeper software install restriction default from "Mac App Store and identified developers" to "Anywhere". Nowhere in the profile on the JSS does it show anything affecting the Shutdown button. When you are looking at the Profiles in System Preferences on the Mac, it shows that Profile. When you highlight the profile to see the settings, that specific one included "Loginwindow Preferences", even though nothing was set for the Login Window from the JSS. Something in the Security & Privacy setting affected the Shutdown button, even though it was not shown on the JSS or in the details of the Profile on the Mac itself.

I ended up just using a command in a policy to deal with GateKeeper, but why I had to go to that was rather peculiar.

Thanks, Amanda, for the info!

Mike

@Mike_Meyers

Huh, well, that IS odd! Apologies for misreading there!

I do know we had some defects in older versions of the JSS that were taken care of in 9.31 that could cause that behavior, but we typically only saw it if the Security & Privacy payload was on the same profile as the Login Window payload.
One turned out to be an Apple defect with a RADAR filed, and had to do with not allowing users to change passwords even if the option was allowed in the profile, so I don't think that one is necessarily relevant here.

The other one could cause Security & Privacy OR Login Window profile payloads to not be fully removed from the client machine even if the profile itself was removed. When it happened we saw all sorts of weird behavior, including seemingly unrelated settings not being applied properly; looks like that was fixed in 9.31 though. If what you saw happened on 9.3 or earlier, I wonder if it was maybe that old defect causing the behavior.

Amanda Wulff
JAMF Software Support

@amanda.wulff

I only found it strange because it occurred right after we upgraded our JSS from 8.73 to 9.32. It was very frustrating until we resolved it. I worked with Joe Burns on it. We tried having Joe create profiles and sending them to me, and I created brand new profiles to deploy. It changed Macs that had been up on Mavericks for a while. Their Mac would check in with the JSS, and at next boot the list of users and no Shutdown button issue would rear its ugly head.

Mike

@Mike_Meyers

I'd file that under 'strange' as well; I do know there were some issues with 10.8.5 and some of the pre 10.9.4 Mavericks machines that could cause that, some of which were filed with Apple as RADAR bugs as we could replicate the problem by using Profile Manager and removing the JSS from the equation.

I did find a defect that describes the exact behavior you’re mentioning here, D-006795, but it looks like it was canceled out as a ‘could not reproduce’.

It may be something we need to have development take a second look at since it does still seem to be happening.

Amanda Wulff
JAMF Software Support

Wow, appreciate all the great feedback on this. I will attempt to disable each of the 8 Configuration Profiles scoped to this computer to see if any of them interfere, starting with the one we use for the Security payload. Like you, @Mike_Meyers we separate out each payload into different Config Profiles. We may have to re-evaluate that approach if that is the problem. I will update this discussion ASAP.

I would just suggest looking at any of the Macs that already have the 8 Config Profiles. Log in, go to System Preferences>Profiles, and check to see if there are any others that have "Loginwindow Preferences" as part of the Settings list. Even if it doesn't list the Shutdown button in the Details, I would start by disabling those Config Profiles.

Good luck!

Mike

@Mike_Meyers][/url][/url][/url][/url

I did as you suggested and took a look at the clients with the 8 existing Profiles installed and saw the Security payload setting 'Loginwindow Preferences' - same exact issue as you!

I re-scoped the Security Config Profile (can't hit a checkbox to disable a profile, correct?) off of my test client and, after a client restart, it did successfully show the Shut Down Button. Success!

@amanda.wulff][/url][/url][/url][/url

Possible solutions I'm hearing:
- Upgrade to 9.32 (although it seems that this issue is still happening?)
- Consolidate all of our payloads into a single configuration profile

Questions:
- Will the Security payload still overwrite my Loginwindow payload if they're in the same Config Profile?
- What is the expected behavior of Config Profiles that have conflicting settings? Workgroup Manager had the logic to merge individual settings within a .plist without issues. In other words, if the Security payload must set a certain preference in the loginwindow.plist, why shouldn't it be smart enough to not affect the other settings in the same .plist?

@majedian21

The defect that was canceled was listed for 9.3, but makes no mention of 9.31 or 9.32, so it certainly couldn’t hurt to try updating to 9.32 and see if it starts working as expected.

I would recommend re-creating the profiles after upgrading as opposed to just re-scoping the existing ones, however, just to have a ‘clean’ profile to test with.

It’s possible that having both the Login Window and Security & Privacy payloads on the same profile may get around it, but the notes on the defect aren’t clear about that; the main mention is that if you deploy ONLY a Login Window profile it works, but as soon as the Security & Privacy payload enters the mix it seems to go a bit weird.

I have e-mailed my team lead and asked if he could request Development revisit D-006795 in light of this thread, and included a link to this thread, since the behavior both of you are describing is exactly what’s detailed in the defect notes.

The notes also mentioned that, in working with Apple, they were not able to reproduce the issue when using a profile made in Profile Manager and that the profile the JSS generated had keys in it that the Apple tech did not expect to see. If we’ve got Profile Manager available, it may be worth seeing if we can make the same profiles in Profile Manager, upload them to the JSS, leave them signed/locked, scope them, and see if they work.

If they do not, take those same profiles from Profile Manager, package them with Composer, and try pushing them out as part of a policy and see if it works as expected.

If they do, we’ve narrowed it down to an issue with the JSS; if they still don’t work right, it may be an Apple defect that we’ll need to open a RADAR for.

In general, expected behavior for configuration profiles or MCX settings is “the most restrictive set of settings wins”. If there are conflicting settings between profiles or MCXes being pushed out, the one that is the most restrictive will be the one that gets applied and the other one will be ignored.

That is only supposed to apply in cases where the settings that conflict are the same, however, so, if you had one Login Window payload that had the box to show the shutdown button checked, and another Login Window payload on a different profile that had that box unchecked, the second one would be the one applied.

When the settings in question are different, as they appear to be in this case, they shouldn’t conflict at all and that’s what typically lands it in the ‘unexpected behavior/defect’ pile.

This is also expected behavior for JSS related permissions where user groups are concerned; if a user is in Group A and Group B, and Group A has access to use Casper Admin, for example, while Group B does not, a user that is in both groups will not have access to use Casper Admin.

If there hasn’t been a case opened up with your Technical Account Manager about this specific issue, please do so so we can get it attached to the currently closed defect and have more resources for Development to look at when they revisit it. Even if it’s not something you need to troubleshoot further, we’d like to have a case in our system so we can attach it to the defect for review.

@Mike_Meyers I’ll see if I can find the case of yours where you and Joe worked on getting the issue worked around and will attach it to that defect when I find it.

I’ve also added a link to this thread in the defect’s notes.

Thanks!

Amanda Wulff
JAMF Software Support