Mountain Lion User Template

Not sure if this will help you in your situation but I basically do the same thing for ML and our macs and it works. Essentially, I configure the mac the way I want in a local admin account with our personalized settings that will apply to all users (VPN, proxy, turning settings off, energy saver, etc) erase the keychains (like wifi passwords, proxy credentials) and restart. Upon restart, I go into single user mode, and enter the following commands:

rm -rf /Users/youraccountname/Library/Caches/* rm -rf /Users/youraccountname/Library/Keychains/login.keychain rm -rf /Users/youraccountname/Library/Preferences/SDMHelpData rm -rf /Users/youraccountname/Library/Saved Application State/* rm -rf /System/Library/User Template/English.lproj ditto -V /Users/youraccountname /System/Library/User Template/English.lproj chown -R root:wheel /System/Library/User Template/English.lproj

These commands basically remove caches, the login.keychain file, and then utlimately the user template. Then it makes the local admin accounts user folder the new template. You can do this in terminal if you want from the local admin account, however a very annoying terminal window pops up every time a new AD user/local user logs in for the first time. It goes away after one restart but still, annoying. If you do it through single user mode, no pop up.

The only thing left to do would be to run a "repair permissions" through disk utility while booted to a hard drive and/or other mac, on the mac with this local admin account with all the settings and new user template.

Once that's done, you can just make a disk image using disk utility or composer and deploy. Works for me, hopefully helps you out.

Would this method work to repair a broken user template that contains blank files instead of folders?

I would most likely say yes, because it erases/removes any existing user template you have (on the system you're making it on) and replaces it with a brand new one. So as long as the new user template has the folders, then yes.

Modifying user templates to customize the OS X user experience has a long tradition and can be tricky. I'm not sure what methodology you're using to capture all your user settings, but I would highly recommend NOT copying an entire user directory into the User Template. There is a lot of what many of us call "cruft" inside of ~/Library, and most of it is not needed to have a functional User Template that copies settings to new user accounts.

If you're planning on modifying User Templates to apply settings, I highly recommend taking a modular approach, and building a DMG package in Composer for each setting you intend on modifying, and then deploying each setting individually to your User Template. Although it takes a lot of time up front, building a separate package for each setting has several advantages:

1.) You intimately learn what property list files (.plist) are associated with what preferences and settings at a system, user, and application level.

2.) Some property list files don't change between application revisions or operating system revisions, so they can be used for a significant amount of time.

3.)You can mix and match preference packages between different configurations in Casper Admin.

4.) Only the settings you need modified actually get modified. There is less risk of inadvertently pushing settings to users that you did not mean to modify or edit, causing unforeseen issues to end users and yourself.

There are probably more advantages, but those are the three most important ones.

The easiest way to figure out what property list files are associated with the settings you are modifying is to put Composer in "Monitor File System Changes" mode, make your change, then see what files get changed. You'll notice that there are some files that get 'touched' every time you make a change, and you can learn to filter those out.

At a deeper level, you can open up the property list files that have your saved changes and learn what properties inside the file are actually the ones that control the the settings you modified. Many property list files have many entires that deal with location of the application window on screen, etc, that don't need to be there in your User Template. The property list file will get modified by the end user as they use the operating system or applications later on.

Some applications still use binary preference files (Microsoft, Adobe) that are left over from the OS 9/Carbon days. These files you won't be able to edit, so you just copy them as is and hope for the best.

Probably not the exact answer you were hoping for, but I hope it helps.

@perrycj - That is how we were doing it so Snow Leopard but thought the more modular approach would be better.

@taugust04 - We use compose to only capture the plists we want, so basically we used the "User Environment" options in composer but found it did not capture everything we wanted so we have a list of plists and settings we set in there. We then combine all the plists into one pacakge only including the ~/Library/Preferences folder

As i said in my initial post it works perfect if you deploy it after reboot, it adds all the plists we customised in to the English.lproj but it will not do it during imaging, Last time i tested it, it worked using the "install to boot volume during imaging" but that reboots the mac into the special casper imaging mode which we are trying to avoid if we can (just one less step for things to go wrong)

This is one of the reasons that I prep OS base images manually as opposed to using .dmg's or .pkg's to insert plist files. I find two simple ways work for me.

1) I setup a user (any user will do) with the preferences I want (however you like to edit .plist files works). Then I manually move them to the /System/Library/User Template/English.lproj directory of my proposed Base OS and manually repair the permissions on that directory. You can then package the OS as any other base image (unless you use instaDMG which is a whole other ball game).

2) Create a self-deleting script @ firstboot. This has been discussed in many threads in the forums.

This is assuming that you are imaging units in the first place. These do NOT apply to thin-imaging processes!