Customizing Default User Preferences in OS X
(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).