Skip to main content
Question

Screen Saver starts immediately after login

  • May 30, 2013
  • 10 replies
  • 6 views

Forum|alt.badge.img+7

Yesterday I changed around some settings on some workstations so that I would no longer see the Apple ID/iCloud prompt at first login and I included a Configuration Profile that has a login window payload that allows local admins to bypass any managed restrictions.

Both of these work marvelously, but now those workstations are going immediately to screen saver after login and requiring a password to get back to the desktop (this is not the default privacy setting)

I accomplished the AppleID/iCloud disable by switching out the com.apple.SetupAssistant.plist file with one that looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>DidSeeCloudSetup</key> <true/> <key>LastSeenCloudProductVersion</key> <string>10.8.3</string>
</dict>
</plist>

The screen saver/password issue only happens at first login. I have tried returning the plist back to it's original state. I have tried removing the configuration profile for admin bypass. No Joy so far. Any ideas?

10 replies

jhbush
Forum|alt.badge.img+26
  • Esteemed Contributor
  • May 30, 2013

jshipman, we are seeing the same issue here. It seems to to have started after the 10.8.3 update. I only see it with AD network accounts.


Forum|alt.badge.img+16
  • Valued Contributor
  • May 30, 2013

I use a similar process and things seem to be working for me. I believe the editing of the com.apple.SetupAssistant.plist differs in 10.8 vs 10.7 so if you are using a 10.7 edited plist you may want to recreate it for 10.8.

I used the following two commands to create my modified plist:
defaults write /path/to/volume/Library/Preferencs/com.apple.SetupAssistant DidSeeCloudSetup -int 1
defaults write /path/to/volume/Library/Preferencs/com.apple.SetupAssistant LastSeenCloudProductVersion ’10.8?

I then packaged the modified plist with Composer and set it to FUT and FEU in Casper Admin.

Hope this helps,


Forum|alt.badge.img
  • New Contributor
  • May 31, 2013

jshipman, we are also seeing the same behavior after updating our clients to 10.8.3 (screen saver activates at first login for users). Will try what mark.sampers recommended and report back.


Forum|alt.badge.img+4
  • Contributor
  • August 8, 2013

Any update on this?


Forum|alt.badge.img+4
  • New Contributor
  • August 9, 2013

We are also seeing the same behavior. We are now on 10.8.4 and it hasn't been fixed.


Forum|alt.badge.img
  • New Contributor
  • September 6, 2013

We are also seeing this! Running 10.8.4 with AD accounts. We found the following in the system.log which may indicate the problem:

Sep 6 14:16:59 Marco-3901 mdmclient[642]: [Agent:824622809] Processing server request: EraseDevice for: <User: 824622809>
Sep 6 14:16:59 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] No PIN received in EraseDevice request
Sep 6 14:17:04 Marco-3901 mdmclient[642]: [Agent:824622809] Using loginwindow to lock screen for: EraseDevice (uid: 824622809)
Sep 6 14:17:04 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] ### Errors while processing: EraseDevice ###
Sep 6 14:17:04 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] <NSPOSIXErrorDomain:-2> FindMyMac 'EraseDevice' error: <ParamError> <NSPOSIXErrorDomain:-2>

It would seem that the mdmclient locks the screen and then fails.


Forum|alt.badge.img+1
  • New Contributor
  • October 31, 2013

Our 10.8 workstations are also exhibiting this same issue even after installing the 10.8.5 combo update. I wonder how many are affected by this issue. Our logs show exactly the same as what mattc posted. I take it there is no confirmed solution? Any feedback would be greatly appreciated. Thanks


Forum|alt.badge.img+20
  • Valued Contributor
  • January 27, 2014

This is pretty annoying. Has any one found a workaround for this ?


Forum|alt.badge.img+1
  • New Contributor
  • January 28, 2014

Ultimately, this issue for us appeared to correlate with Undercover unintentionally being blocked from communicating with its server by our web filter. As a result, I think it would trigger this behavior in an attempt to erase the device as a security measure but fortunately nothing was ever erased because it required a 6 digit pin that was not specified by Undercover. The behavior stopped once the exceptions were made in the filter. This was back in November and we have not seen the issue since. Thats the best we could conclude from our environment but it may be different in others. Hope the info helps.


Forum|alt.badge.img+20
  • Valued Contributor
  • February 12, 2014

whooo

This seems fixed in version 9 :)