How to create an OS X Default Profile/Template & Bind to AD - 10.5 - 10.8

[jasric89]

I use this script under the "root" user. If you are not using root user this will not run. "root" user should rarely be used but because there are a a number of commands in this script that use sudo I used the root user so there is no prompting. Also make sure the user you are using is called "default"

 

** Next year I plan to change this to "administrator"

 

Oh yes sorry I remember now. That worked.

[Carter]

Oh yes sorry I remember now. That worked.

 

what was the issue? Was it that you were not using "root" or "default" user?

 

.

[brian_g108]

Hey Carter this may be a crazy question, but in the Automator script for Lion/Mountain Lion did you remove the command for repair permissions?

I was looking at the script and didn't see it.

[artmcortez]

Hi Sir,

Is the default profile/template for OS X Lion will work also for OS X Mountain Lion?

[Reyesjai]

Hello Carter,

 

I've followed the steps outlined in your instructions; however I'm getting the same error here as mentioned by Sampson. When logging in with an AD user, I get the "the system was unable to unlock your login keychain". I tried to download the updated file from the link but it appears broken?

[nukethis]

Does this script work in Mavericks? It's time to start updating my Macs at work. Thank you for creating this script!

[UniMis]

If anyone needs for information on this please ask away

 



 

I know its a while since you have posted but if you are still around by any chance, could you take a look at my script I made based on yours? mine doesnt quite work and I am stuck at figuring out why.

 

https://www.dropbox.com/s/0v4bvs8ea1hf9mc/Mavericks_default_profile.zip

[Carter]

Currently I cannot modify the start of this topic but please see the following for changes and download links:

 

Yosemite Automator Script

No Permissions repair - http://twistedmac.com/downloads/default_profile_no_permissions_repair.zip

*With Permissions repair - http://twistedmac.com/downloads/default_profile_with_permissions_repair.zip

 

* If I've made a lot of changes to the "administrator" profile I will run permission repairs prior to imaging of the computer. Minor changes I don't bother

 

Changes

- I've removed a line that removed an old folder that was the codename for iCloud sync. This is no longer needed.

- I've added a line (first step) that backs up the original default user template prior to erasing the contents. It will place a .zip file in the "administrators" home folder

[Carter]

** Update

 

Made minor adjustments

 

http://twistedmac.com/downloads/default_user_profile_march26_15.zip

 

As always since this is an Automator script you can just open it in Automator and make needed adjustments.

 

.

Edited March 26, 2015 by Carter

[Carter]

* Update

 

Please hold off on running this script unless you want to test it out. I'm having an issue with permissions where new users login and the logged in user has no read/wrire to the standard fodlers within the user profile. Hope to re-write this script tomorrow to work a little differently.

 

As far as I can tell this issue might be due to the 10.10.2 update for Yosemite.

Edited March 30, 2015 by Carter

[Carter]

* Update

 

Had a couple issues with permission and copying the profile root folders but now working. Needed to roll back to previous commands.

 

http://twistedmac.com/default_user_profile.zip

 

.

[Ephemerality]

Hi Carter,

Thanks for your efforts with your script, it has been very handy.

I am running into an issue setting up a system with 10.10.3 on it. I configured the profiles the same as on previous systems before running the script. When new users log in and open an application (Chrome, for example), it gives and error that "keychain cannot be found to store Chrome".

I redid the default profile from scratch and doing everything manually, and tried a number of solutions I found online such as deleting all files in the /English.lproj/Library/Keychains directory, deleting only the login.keychain, etc, but it is still giving that error.

Any idea what be going on? I am going to re-do it with 10.10.2 in case the .3 update is what broke it.

Thanks

[Carter]

That's odd, the line command sudo rm -rf /System/Library/User\ Template/English.lproj/Library/Keychains/* is there to remove the keychain which then forces new user logins to create a new keychain. Is your main user you are creating a profile with called "administrator"?

 

 

So you get this error no matter what application you use?

 

 

I'm out of province for the next week supporting an event so I can't really test to much but I can see what I can dig up.

 

 

.

[Ephemerality]

Thanks for your reply.

I am using 'administrator' for the main user, 'default' for the template user, and then logging in as root to run the script.

The error seems to occur in any application that attempts to use the login keychain. We have students using their Active Directory account to log into the system and it asks them to reset to defaults and input a password for the keychain, which our older (10.7) systems were not doing. On those systems, they just log in and it would auto-create a new login keychain for them with their AD password.

 

Edit: It seems to work fine on 10.10.2. I am updating to 10.10.3 to see if I can replicate the issue.

Edit 2: Updated to 10.10.3 and redid the template, seems to be working fine. Not sure where the issue was before. However, it seems to be copying the profile over from the 'administrator' user instead of the 'default' user I have set up, unsure if that is how it is supposed to work, but users can log in without issue now so it's not too big of a deal. Thanks!

Edited May 25, 2015 by Ephemerality

[googlemad]

Any chance of a El Capitan update?

[Carter]

Any chance of a El Capitan update?

I honestly haven't even tried the script with El Capitan yet.

I'll gear up a computer today with the latest version of OS X El Capitan and run the script to see what needs to be adjusted.

[Carter]

Any chance of a El Capitan update?

 

Have an image built and it seems that the whole script works except for the last step "repair permissions". If you remove this step it will work. I'll get an updated version uploaded shortly.

 

Apparently in OS X 10.11 El Cap they've removed what they consider to be an old idea that's not required anymore. You can't just repair permissions anymore.

[Carter]

UPDATE - New Download Page for All Files

http://twistedmac.com/index.php/downloads

[sicariis]

I'm attempting to use your script on a El Cap Image I'm creating for deployment but it seams that your latest link isnt working. Thanks

[Carter]

I'm attempting to use your script on a El Cap Image I'm creating for deployment but it seams that your latest link isnt working. Thanks

Sorry about that! Had a "Name Servers" issue with my domain which I've now fixed. The site should be back online shortly.

[dreimiller]

4 years ago when I was the Mac Tech here I used to set up user templates but I haven't done so since then so it's possible that something in OS X has changed since then that I'm not aware of that's causing the problem that I'm seeing. I've been Googling all morning trying to figure this out and I ran across your script so I tried it to see if it avoided the problem but it is still happening. When a new user logs in they are correctly inheriting all of the settings that I want them to have but the "favorites" on the left side of a file dialog box (which I didn't modify at all) as well as the Downloads folder that I added to the Dock are both pointing to the temporary account that I used to create the user template instead of pointing to those folders in the user's directory and as a result they aren't usable due to lack of permissions. Any idea why this would happen? If I restore the archived version of English.lproj and log in as new user then those folders all work correctly. If I manually copy either the entire temporary account or just the Library folder from the temporary account to English.lproj those folders still end up pointing to the temporary account. If I log in as root and run your El Capitan script it runs fine but the result is the same problem. I'm baffled. Thoughts? Edited November 28, 2015 by dreimiller

[Carter]

4 years ago when I was the Mac Tech here I used to set up user templates but I haven't done so since then so it's possible that something in OS X has changed since then that I'm not aware of that's causing the problem that I'm seeing. I've been Googling all morning trying to figure this out and I ran across your script so I tried it to see if it avoided the problem but it is still happening. When a new user logs in they are correctly inheriting all of the settings that I want them to have but the "favorites" on the left side of a file dialog box (which I didn't modify at all) as well as the Downloads folder that I added to the Dock are both pointing to the temporary account that I used to create the user template instead of pointing to those folders in the user's directory and as a result they aren't usable due to lack of permissions. Any idea why this would happen? If I restore the archived version of English.lproj and log in as new user then those folders all work correctly. If I manually copy either the entire temporary account or just the Library folder from the temporary account to English.lproj those folders still end up pointing to the temporary account. If I log in as root and run your El Capitan script it runs fine but the result is the same problem. I'm baffled. Thoughts?

Hello @dreimiller

 

Unfortunately you're not the only person with this issue. It has been an on going issue since OS X 10.10 Yosemite which has followed over to OS X 10.11 El Capitan. The issue has to do with the preference file for the sidebar found at "/Users/username/Library/Preferences/com.apple.sidebarlists.plist"

The only shortcuts that have an issue are those that retain to the default user. (In the case of my script that would be the administrator). I can't remember where I've posted this but the only fix is to remove the folders that relate to the user. This does suck and I've had many complaints from our students but unfortunately I'd rather them not see the broken folder/shortcuts and go to the "Go" menu to select their desired location.

 

I have tried modifying the "com.apple.sidebarlists.plist" file with no luck and I've also tried adding the "com.apple.sidebarlists.plist' by having our Profile Manager push it out and still no luck.

 

This is very frustrating and once I can come up with a work around I'll get something posted.

 

.

[harryn]

Carter, wish I had've found this thread when it first started. Would've saved me a lot time.

For what it's worth........just delete the default user you used for your template and no more problems. El Capitan recreates them for the new user, and then no more permission issues.

Thanks again.

[Carter]

Carter, wish I had've found this thread when it first started. Would've saved me a lot time.

For what it's worth........just delete the default user you used for your template and no more problems. El Capitan recreates them for the new user, and then no more permission issues.

Thanks again.

 

I've been very tempted to run with the stock finder/sidebar preferences but we still want to remove "Air Drop" & 'iCloud Drive" and this is not possible without the preferences messing up. It's a really poor setup how Apple handles the preferences for the sidebar.

[jasric89]

Are you saying if you run the automator command and then delete the default user the sidebar will work? I have noticed in the automator script that it references the admin account and not the default account for El Capitan I changed this manually was this done for any particular reason?

 

Thanks