User Defaults in Mavericks not working past first login.

corcorac
New Contributor

I've run across a very unusual issue. I've always handled user defaults by copying an account into English.lprog. Now that I have several hundred new iMacs that came with 10.9 this method doesn't seem to be working for me. Initial log in works as expect but subsequent log ins do not get any of the default settings. In addition, non-admin users get a pop-up that says OS X needs to repair your library, enter admin name and password. They also see a pop-up that says A keychain can not be found to store "Username" (the name of the logged in user. I rebuilt the image on one of the new iMacs, I copied the user folder to English.lprog, ran chown, then run repair disk permission. Pulled the image with Casper Composer 8.73. Same issue as the image I built on one of my older mac minis and deployed to the new iMac, seems to work ok on the mini though.

To add to the weirdness, local accounts are fine, but network accounts are not. We have an Active Directory. I have searched all over and done a lot to try and figure this out. Any thoughts?

1 ACCEPTED SOLUTION

andrew_stenehje
Contributor

We've had the exact same thing. For us, it all appears to be related to an issue with 10.9 not seeing group membership properly in OD, which is using nested AD groups. We were using OD to use the option to "Create mobile account at login", but in 10.9, many accounts would not see proper pref settings and wouldn't do this. This is what caused the Library/Keychain errors and for the user folder/account to not get fully created. We bind to AD/OD using a custom script; I've updated it to "create mobile account at login" in the script rather than through OD, and that fixes the Library/Keychain/account/folder creation problems. However, many accounts still don't get proper MCX prefs from OD, apparently due to the nested group membership problem. For us, specific accounts would work when I added the user account to the OD group rather than just adding the AD group that they belong to.

Apple support has duplicated it and has forwarded it to engineering. I'd definitely suggest reporting it too. Let me know if you find out anything else because this is a big ticket problem for us.

View solution in original post

22 REPLIES 22

corcorac
New Contributor

And one more note, the messed up accounts only have desktop and downloads in their user account folder.

alexjdale
Valued Contributor III

We're not seeing any issues with this, but rather than copying the entire account, we only copy files and plists that we're adding/changing to their appropriate path in the template.

andrew_stenehje
Contributor

We've had the exact same thing. For us, it all appears to be related to an issue with 10.9 not seeing group membership properly in OD, which is using nested AD groups. We were using OD to use the option to "Create mobile account at login", but in 10.9, many accounts would not see proper pref settings and wouldn't do this. This is what caused the Library/Keychain errors and for the user folder/account to not get fully created. We bind to AD/OD using a custom script; I've updated it to "create mobile account at login" in the script rather than through OD, and that fixes the Library/Keychain/account/folder creation problems. However, many accounts still don't get proper MCX prefs from OD, apparently due to the nested group membership problem. For us, specific accounts would work when I added the user account to the OD group rather than just adding the AD group that they belong to.

Apple support has duplicated it and has forwarded it to engineering. I'd definitely suggest reporting it too. Let me know if you find out anything else because this is a big ticket problem for us.

View solution in original post

russeller
Contributor III

10.9 also changed how it managed preferences. For example, something simple like changing the wallpaper for accounts doesn't work with OD MCX managed preferences anymore in 10.9. This is because 10.9 ignores any values in ~/Library/Preferences/com.apple.desktop.plist (even though OD correctly applies this preferences) and instead 10.9 will read the desktop picture preferences from ~/Application Support/Dock/desktoppicture.db. Yes, that is correct, it is a SQLite db file that stores the desktop picture. Here is a really good article that explains how the desktop picture preference works in 10.9 http://1klb.com/blog/desktop-background-on-os-x-109-mavericks.html There is no MCX preference that can manage that in 10.9. A suggestion from JAMF was to use either an applescript or OSA in a shell script to do the following at login per user:

tell application "Finder"
    set path_to_wallpaper to POSIX file "/Library/Desktop Pictures/picturename.jpg"
    set desktop picture to file path_to_wallpaper
end tell

You can wrap that into a shell script or whatever with osascript. Here is the man page: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/osascript.1.htm... Speaking of osascript, if you write in ruby I found an interesting gem you can use http://rubygems.org/gems/osaka From the website: "Osaka wraps osascript (Applescript) and provides a ruby interface for automating tasks through the GUI on Mac".

trenta
New Contributor

I ran into the same problem. After a bit of mucking around I found that if I added a blank Library/Keychains folder to the User Template I haven't received the error so far in testing.

wtm001
New Contributor

Does any one else have any work arounds for this?

andrew_stenehje
Contributor

fyi~ It sounds like the OD nested group membership lookup problem is supposed to be resolved in 10.9.2.

wtm001
New Contributor

andrew,

Where did you read that from?

andrew_stenehje
Contributor

I have a ticket in with Apple Support for the problem and that is what they told me.

wtm001
New Contributor

Cool, thanks a lot!

FastGM3
Contributor

I don't use OD nested groups and I still have this problem. I am binding to AD with nested groups, with a custom script and create mobile account at login is enabled. UGH, any ideas?

I found this but have yet to try and create a defat user template after this process

https://support.apple.com/kb/TS5362

josaxo
New Contributor

I had a similar issue with new users not applying default preferences. I was able to resolve my issue by dropping my preferences files in:
/System/Library/User Template/Library/Preferences

Clay
New Contributor

Our issues are similar.
After the imaging process it is not fully getting the OD settings.
If we manually unbind then bind again and restart the computer, everything is then working as expected.

Thank you,
Clay

Clay
New Contributor

Hi josaxo ,
What preference files did you copy to /System/Library/User Template/Library/Preferences ?

Thank you,
Clay

Backas
New Contributor

Hello,

Did your issues resolved with 10.9.2? I have the same issue in 10.9.1 machines with AD only accounts with mobile homes (OS X needs to repair your Library).

Best regards

Kostas

andrew_stenehje
Contributor

10.9.2 did resolve the problems for us.

Backas
New Contributor

Thank you,

Did you had to rebind the affected machines?

Kostas

andrew_stenehje
Contributor

We didn't actually let anybody install 10.9 until 10.9.2 came out so it wasn't much of an issue for us. I think that the few people who had updated to 10.9 previous to 10.9.2 had all of their MCX prefs refresh when they updated to 10.9.2, but they didn't need to rebind.

FastGM3
Contributor

I'm still experiencing this issue with 10.9.2 but I can't remember whether I rebuilt my DUT after the 10.9.2 update. I'll try rebuilding it today to see if that helps. Someone in an earlier post had mention they cleared the files in their DUT's preference folder, that would defeat our purpose of creating custom templates so that wasn't a solution for me. Clearing the DUT's Keychain folder did not work for me either.

Currently we're still following Apple's KB article to fix the problem at login, which is a HUGE pain.

Chuck

Backas
New Contributor

DUT = Default User Template?

Kostas

FastGM3
Contributor

You got it ;-)

JAMAUAI
New Contributor II

@trenta's fix did it for me. Thanks.