Posted on 09-07-2016 11:21 AM
Hi All... I posted this in slack.. But I could really use some feedback on this. Been banging my head on this.. but here goes:
So i created a configuration profile.. that set a default screensaver to 3 seconds for all managed clients. However that MDM profile isn't working for one particular user, so instead of dealing with it, i just excluded him from the policy.. But, he cannot set his own screensaver timeout settings. Once he changes to 5 seconds, it goes back to "Immediately" when we go back to the Security & Privacy window after the setting is changed
I've deleted com.screensaver.plist files from ~/Library/Preferences, and from /Library/Managed Preferences.. rebooted, .plist was rebuilt, no change.. So i went and manually edited the .plist in those locations to a 5 second timeout, still reverts back to "immediately"
I've tested this on a different machine.. Once I add this computer to the exclusions from that config profile, they cannot adjust the timeout setting, reverts back to "immediately"
Am I missing something here?
Posted on 09-07-2016 11:57 AM
1) What version of the JSS are you running?
2) Are you sign a Login Window configuration profile.
In JSS 9.0 they started having issues where the Login Window profile would set the screen saver timer. This conflict would cause problems. There is a mention of a fix in 9.93 but I have not tested it.
Posted on 09-07-2016 12:11 PM
I'm still in 9.8.1.. and no it's not the Login Window configuration profile.. This is actually a Custom Payload setting..
Posted on 09-07-2016 12:16 PM
@JustDeWon in our environment we had a similar issue.
We found out another configuration profile with the "Finder" payload was causing the issue.
once we completely deleted that configuration profile the screen saver profile worked without any issues.
Also we have the "Login Window" and "Security & Privacy" combine into one configuration profile, because for some reason it does not work if we have those two payloads on a separate configuration profile.
(we are on 9.93)
hope that helps.
Posted on 09-07-2016 12:24 PM
@scentsy thanks.. that does help.. We have a finder preference only on imaged and reimages.. But it looks like those preferences are also getting installed once they enroll.. Kinda hard to manage when there isn't a policy for enrolled machines out there.. argh..
Posted on 09-07-2016 12:48 PM
You may have to install each profile individually to see which may be laying down the incorrect payload. In June, after not updating our JSS since March and not touching our profiles we had the Security and Privacy profile start blocking iCloud Drive. This was on devices where everything was working fine until the JSS re-installed profiles.
It has been a fun time with profiles this year.
Posted on 09-07-2016 01:11 PM
sighs... looks like it's going to be a long project for me.. Probably be simpler just fixing his issue of it not getting the 3 second MDM profile to begin with.. But ehh.. I am now focused on this..
Posted on 09-07-2016 02:18 PM
I have a nearly identical issue.
In a nutshell, any combination of the Login Window and Security & Privacy profiles causes my users to no longer be able to have control over their screensaver lock settings (grayed-out). My company doesn't have an HR/IT lock screen policy, so employees are free to set these parameters to at their discrection. Also - the (grayed-out) settings sometimes appear incorrect in the System Preferences pane GUI too (regardless if grayed-out or not). It's been rather messy to troubleshoot and communicate with my end users.
I have spoken to or emailed with at least 7 JAMF team members. They are able to reproduce my issue 100%. Last update is that I received is that my case has been escalated further up the chain to engineering/development.
The workarounds mentioned in this forum and the Internet-at-large (going back almost a year to circa ~9.81) are NOT working for me. I have tried them all, including combining the 2 payloads into a single configuration profile, importing custom .plist/.mobileconfig/XML settings from Apple Profile Manager, etc.
As a sanity check, JAMF was kind enough to curate a custom profile for me to my exact specifications for testing, but the issue still occurs. (i.e.; it's not just me).
My "workaround" is to simply manage the Login Window payload by itself and opt-out of using the Security & Privacy payload until a long-term solution allows them both to peacfully co-exist.
OS X 10.10 and OS X 10.11 (maybe older OS's too, not sure). JAMF 9.93 (just updated from 9.81 two weeks ago when this issue appeared)
Posted on 09-07-2016 06:31 PM
Yeah, this issue has been pretty frustrating and its a little disappointing that it wasn't fixed in 9.96. The only way I have been able to solve this is to create a signed configuration profile with Profile Manager that contains a Login Window and Login Items payload, then upload that to the JSS. I have no profile with a the Security & Privacy payload deployed to machines.
I believe this has been identified as Product Issue D-009503, which strangely isn't in the Known Issues section of the 9.96 Release Notes
Posted on 09-08-2016 07:06 AM
As mentioned above, I decided to pull both the Security & Privacy payload and the Login Window payload from all my Macs. I also un-scoped my Macs from these profiles as well. Later, I decided to create a new Profile, this time it contained only the login window payload (i.e.; Security & Privacy setting were no longer managed).
Boom. My lock screen problem came back again! Once again, users were no longer able to adjust their lock screen password time (grayed out in the OS X preference pane and the screensaver lock prompt never triggered at all). As soon as I removed the profile, the ability for users to control their lock screen settings returned.
Therefore, it appears that I have isolated my issue to the Login Window profile/payload. Im not sure if the Security & Privacy payload also contributes to the issue or not.
Next, Ill do the inverse an deploy only a Security & Privacy configuration profile.
Posted on 09-08-2016 08:51 AM
Posted on 10-27-2016 03:16 AM
@dstranathan @JustDeWon We just upgraded JSS from 9.81 > 9.96 and things have generally gone well—except that I noticed my screensaver wasn't prompting at all.
You both describe this well, and it sounds a lot like D-006393, no? They only implicate OSX 10.8.4/10.8.5, but clearly seems to be affecting my OSX 10.11.6 Mac (and others).
[D-006393] The Start screen saver after: option in a Login Window payload of an OS X configuration profile is not applied on computers with OS X v10.8.4 or v10.8.5.
We've had both Loginwindow and Security & Privacy payloads (as separate profiles) since 9.81 and it had always been working as expected.
It's interesting to compare JSS conf profiles to resultant MCX and to actual results (no prompt).
With "Security & Privacy" set to Require password [immediately] "after sleep or screen saver begins", I see this...
$ defaults read /Library/Managed Preferences/com.apple.screensaver askForPassword # Result... 0
And with "Login Window" > Options set to Start screensaver after  Minutes of inactivity", I see this...
$ defaults read /Library/Managed Preferences/com.apple.screensaver askForPasswordDelay # Result... 0
Posted on 01-16-2017 11:08 AM
Hey all -
@seabash (or anyone else)
I have a question along the same(ish) lines.
On 9.91, will be upgrading to 9.96 this or next week.
Just completed making images for 10.12.2. I noticed that it was not using the defined screen saver in the config profile (works for El Capitan). I have it set to use "flurry.saver" yet it is using "message.saver" The one with the annoying apple symbol that leaves marks on the screen for a few minutes after, then displays the computer name as the "message."
I was hoping someone could point me in the right direction. It doesn't appear the path changed for Sierra. Any ideas?
Much Thanks :)
Posted on 02-07-2017 11:23 AM
Does anybody have any luck with the Config Profile/Screensaver issue? I'm also on 9.96 and it seems to get the configuration profile, just that its not checked off to require password "immediately". I have had instances where some machines get it, and it is set. However after a reboot, or during use it somehow gets unchecked on its own. I have tried to change from User level to Computer level and it seems like the behavior is consistent.
Posted on 02-07-2017 11:24 AM
Forgot to mention, I've been seeing this happen on both 10.11/12 machines. Seems like the 10.11 machines have a better success rate vs the 10.12 computers.
Posted on 02-08-2017 10:28 AM
Yes we have had the same issue; flipping it to "5 seconds" seemed to fix it, but it seems like it is a bug in the actual console and the way it generates the mobileconfig file. I had found another page with more details here:
And there is a lengthy discussion on it here in the JamfNation which references the John Kitzmiller page:
Posted on 02-08-2017 10:37 AM
Hey @KSchroeder & @kquan -
I actually started my own thread on the issue and worked my way through the issue. I worked along side my jamf team and found a solution.
Here is the thread:
Posted on 02-08-2017 10:46 AM
@sabrina.oconnor Thank you! I will make note of it, I do have a support case going on with JAMF. We initially had two configuration profiles that were set to do different things, and they had suggested to consolidate them to one(since they were in the Security & Privacy preferences) I now have one config profile and its working on my 10.11 and 10.12 computers!