Screen Saver starts immediately after login

jshipman
New Contributor III

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 10

jhbush
Valued Contributor II

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.

mark_sampers
Contributor

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,

jlee
New Contributor

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.

petedogg
New Contributor II

Any update on this?

leegalan
New Contributor III

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

mattc
New Contributor

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.

Hernandez
New Contributor II

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

ClassicII
Contributor III

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

Hernandez
New Contributor II

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.

ClassicII
Contributor III

whooo

This seems fixed in version 9 :)