(The following article is intended for experienced and knowledgeable system administrators only. If you find parts of the discussion below contain verbs you don't understand, techniques that you aren't comfortable with, etc., I recommend NOT attempting to follow these instructions or use the provided script. This technique requires some pretty-advanced skills and experience.)

What is this article about?

As an OS X system administrator, you may want to change the default appearance of OS X the first time a new user logs into it. For example, you might be writing lab instructions for students and want a particular file to be "guaranteed" to be in their home directory or on their desktop when they first login. You might want to be sure that certain applications are in everyone's Dock, or avoid having to require users to enter a serial number the first time they launch a particular program. Whatever your reasoning, the bottom line is that you want to change (from Apple's or some third party's defaults) the way a user's OS X interface or applications behave from the first time they login. There are two ways you can do that.  The first is to create an account for the user, login as that user, and make the changes.  That's the safest and best way to do it, but if a user logs in who doesn't have a local account on that machine (e.g., they authenticated through Active Directory or UNIX NIS), they won't have your customizations.  But there's another way that "doesn't care" if there is a local account on the system already, that will get the right set of customizations in place for every user who ever logs in (local or via the network).

In this article, I'll tell you how I did that at my company, and how you can do it, too.  But, please, before you make the decision to go down this path, read this entire article.  If you follow my instructions here carefully and test the changes you make thoroughly, you shouldn't have too many problems.  If you miss a step or don't test something, I can practically guarantee that you're going to have problems - and some of them you might not see for a week, a month, or more. 

Before you can understand the procedure for doing this, you need to know a little about how OS X stores a specific user's preferences, and how it decides what those preferences should be to begin with. Once you know that, you'll know much of what you need to know to be able to customize those defaults (but I promise you, you won't know everything you need to know).

How do initial user preferences get set by OS X?

When a local user account is created on an OS X system, OS X automatically creates a directory for that user in the "/Users" directory.  If you don't authenticate locally, you may have a script in place that creates that initial user directory for the user.  That initial user directory is where Apple sets the "default" user preferences for everyone on that particular machine.

For example, when a local user with the short name of "Fred" is setup on the system, a "/Users/Fred" directory is created on that computer. Inside this directory are files OS X creates to keep track of Fred's favorite settings (e.g., icon or list view in the Finder), files that OS X applications use to keep track of what Fred likes (e.g., his word processor's default font setting or his dictionary words), settings saved by his third-party software (like Microsoft Office), and files he's placed in his home directory. But if there wasn't a "Fred" directory before Fred's account was created, how did it get there?

There are two ways files can "automatically" end up in Fred's home directory. One way is that the files are created when Fred first tries to execute a particular application (for example, after the first time he launches Adobe PhotoShop). The other is that they were put there by OS X before Fred logged in, to provide a "base" environment for him to work in. That "base" environment comes from the files stored in the following directory:

   /System/Library/User Template/English.lproj

(This assumes that you're using the English settings in OS X. If you're using another language, your defaults may be coming from one of the other subdirectories in the "User Template" directory.)

When a new account is created, OS X copies the files in the above directory into a new subdirectory under "/Users". This creates the new user's initial "sandbox" environment.

So, the theory on which this article is based is that by modifying the contents of the above directory ("English.lproj") we can customize what new users will see when they first login to OS X.  Sounds very straightforward, right?  It's not.

So what's the catch?

Earlier, I mentioned that being thorough and careful in your testing is critical. While it is true that many kinds of customizations are indeed as simple as adding or replacing files in the "User Template" directory, some are not. Some customizations may not even be possible at all, without some major "hacking" at the files in that directory. You have been warned!

There are several things that can go wrong here, and I'm probably not going to be giving you a comprehensive list of the things I've seen go wrong because I can't honestly remember them all. Even if I remembered all the issues I saw, you may have different software or configuration issues in your environment that I haven't seen, and I can't warn you about something that didn't happen to me. Again, you have been warned.  Testing the changes after you make them is absolutely critical.  Testing the new user template thoroughly after any change is equally critical.

At a high level, all the problems boil down to one thing: There are some preferences files that store information which identifies the original user who made the customization. If those same preferences files are given to another user, when the user tries to do something involving the data stored in that preferences file, OS X will try to modify the files belonging to that original user. Since OS X's security will generally prevent one user from screwing around with another user's files, this new user is going to get security warnings, application errors, crashes, lock-ups, and other unpleasant results from our customization attempt. The only way you can be sure that this doesn't happen is to test, test, and re-test. Even if you test very thoroughly, odds are that your users are going to find something you didn't expect that isn't working. Mine did, and still do occasionally.

What's the procedure?

The process is pretty straightforward, really. First, begin with a Macintosh that you can afford to "trash" if need be.  That is, don't do this with a Mac whose configuration you can't easily and quickly put back to normal.  It is possible to render a machine partially (maybe completely) unusable by performing this little "trick".  Again, you've been warned...

You will begin by logging in as root or administrator and locating the following directory on the boot disk:

  /System/Library/User Template/English.lproj

Having found that directory, you should back it up somewhere on another drive, another partition, etc. This way, if you really screw things up badly later, you can restore this directory from the backup and start over again. My first time trying this, I had to start over more than once. Consider that another warning!

Next, while logged in with administrator privileges, create two new accounts on the Mac. One should be called "default" (because my script below depends on that particular name... if you change the name, change the script accordingly or it won't work). The other can be any name you like, but I suggest using the name "test" to keep things consistent with these instructions.  Neither of these accounts should have administrator privileges.

You will notice that there is now a "default" directory inside the "/Users" directory on the boot disk. This directory contains the base settings that OS X has provided for a new user, customized slightly for the new user called "default".  This "default" user directory is where we'll make the customizations that we'd like all our users to have.  Once we've made the customizations we want to make, we'll copy this "default" user directory over top of (and replacing the matching files within) the "/System/Library/User Template/English.lproj" directory.  When a new user is created, that user will (as normal) get a copy of the "English.lproj" directory which contains our customized settings.  In this example, we'll use the "test" user to simulate someone logging in for the first time and getting our new settings.  Later, ANY first-time user will get the new settings.
With your environment setup as recommended here, it's time to begin. Login as "default". Make all the changes you want to make for your users. For example, change the desktop pattern to the company logo, adjust the default Finder views to "list", turn on the screen saver, etc. When you have configured the "default" user's environment to your standards or needs, log out.

Log in as "root" (rather than admin, because it will work more easily for this process). Run the script provided below to overwrite the system's base "User Template" with the files from "/Users/default". Now, locate the "/Users/test" directory if it exists. Delete the "test" directory, leaving the rest intact. Log out as root. Login as "test". You should see that things look a lot like they did when you were logged in as "default". (If not, I've given you bad instructions here and what you should do is log back in as root, delete the "test" account, then re-add the "test" account. It's been a while, and I'm working from memory here.)

At this point, you should try everything you possibly can. Browse files in the Finder, click on all the shortcut buttons in the Finder window, change system preferences for things, etc. When you've done all the "OS X" stuff that you can, start testing the applications. For example, launch Safari, add a bookmark, remove a bookmark, change the default home page, download some files, etc. Continue for every other application and function on the system that you think your end users might possibly ever use. You're going to find that some things don't work. I can almost guarantee that. What do you do if something doesn't work?  Cry. No, just kidding. Don't do that. You might get the keyboard wet, and that could cause other problems.

Here's where you become a sort of "Sherlock Holmes of OS X". The "crime" you're investigating here is that the application (or part of OS X) that is misbehaving is doing so because in one of the many preferences files in "/Users/test", some piece of information is telling that application that it needs to be modifying something (a file or directory) that belongs to "default" rather than "test". Since OS X's security won't let that kind of activity take place, the application is behaving oddly for "test" but quite normally when "default" is logged in. Your job is to figure out which file(s) in "/Users/test" are causing this problem.  (If you ignored my instructions earlier and setup the "test" account as administrator, some things will work normally that shouldn't, because an administrator COULD modify some of "default's" files.)

I recommend starting in the "/Users/test/Library" directory to find your culprit (but it may not be there, so branch out if you have to). Most likely it will be a file in the "Preferences" subdirectory whose name ends in ".plist" but it could be elsewhere. The files in this directory are all given names that should clue you in to the fact that they relate to the application that's misbehaving. For example, in my own Preferences directory there is a file named "com.microsoft.Word.plist". If I was troubleshooting a Microsoft Word problem, I'd suspect this file first, especially if it shows a modification date that is around the time I setup my Word preferences in the "default" account.

To see if this is the file where the problem exists, I'd log in as "root" and move that file from "/Users/test" to somewhere else. Then I'd log back in as "test" and try doing the thing in Word that didn't work. If it works now, I've found the right file. What you do next is going to be one of the following:

• Don't include the file in the User Template. In this case, you'll adjust the script below to delete that file from "/System/Library/User Template/English.lproj" after it has synchronized with the default directory. This will ensure that you don't later on forget that this file is a problem and include it for other users.
• Fix the problem within the file. This is a lot harder, and maybe not even possible depending on the setting that's at fault. Open the file in TextEdit. It will often (though not always) be in somewhat-readable XML format. You may find as you scan through the contents of the file that there is a line in there that references "/Users/default" or something that points to a resource "owned" by default. In some cases you can delete these lines from the file and the preference gets filled in with the name of the user who just logged in when they try to launch that application. If so, you'll need to make a note for yourself that you have to delete such-and-such line from such-and-such file to make the application work for other users.
• Fix the problem by merging some preferences from the "default" directory plist file with those in the backup of the original "User Template" directory. In other words, you might find that by adding a line or two from the original Word preferences file in the backup of the original "User Template" directory you can create a new file for the new "User Template" that works for all users.
• Use the file from the backup of the original "User Template" that you made before changing anything. (Some applications may require a "blank" preferences file to be there the first time they're launched.)

If you haven't guessed, the second and third options above are a lot of work, and fraught with error. Plus, to implement them properly you need to document what you did, adjust the script below to automate that in the future (if you can), etc. I found it to be more trouble than it was worth to me in nearly all cases, and I went for the first option (or the last, if that didn't work).

Each time you think you've fixed a problem, I recommend that you delete the "test" directory in "/Users" and try the same test again. Then test everything else you can think of in that same application. You may find that in fixing this issue, you've created another. I don't have any good scientific way to figure out what works and what's broken other than to test and re-test.

So there you have it. That's how you setup a profile to be customized, but the same for all first-time users.

I found something you missed!

If you discover some changes that should be made to my script, perhaps you'll drop me a line and suggest how I can improve it. If you have specific tips on how to correct problems with a given application, I'm interested in those, too. I'll add the information here for others to use if you share it with me. (Since this web site isn't my full-time job, don't expect me to perform instant updates, but I will get around to it as soon as I can.)

Disclaimer:  As with all my scripts and articles, this has worked for me on the systems I administer. Carefully implemented and tested, it ought to work for you in many cases as well. But I provide this information and the script below on an "as is" basis. If it works for you, great! If it doesn't, you agree that by using the information or script that you've assumed all liability and responsibility for what happens to you, your network, and your computers (and anything else I've forgotten that might be affected).