

Mac OS X Lab Deployment

Mike Bombich, bombich@apple.com
Apple Systems Engineer

Lab Guide v. 1.6

April 26, 2004
Introduction
Deploying the Mac OS in a lab environment changed dramatically when Mac
OS X was introduced. While Mac OS X's built-in security and stability
improve reliability and productivity, the underpinnings have changed
and lab managers face new deployment challenges.

In this day-long workshop, you will learn how to do the following:

• Prepare a Mac OS X installation for the rigors of a lab environment
• Install third party software and protect it from admin and non-admin users
• If desired/required, install and secure the Classic environment
• Create a customized environment for end users
• Implement a system that will restore the default user environment every time a
user logs in
• Create a deployable disk image of a custom OS X installation
• Deploy a disk image of a custom OS X installation over the network with little to no
interaction with each individual machine
• Develop software installation packages with PackageMaker
• Use Apple Remote Desktop to manage many aspects of a lab

This course has been designed to quickly bring you up to speed on best-practices for
deploying Mac OS X in a lab environment. Course participants are expected to have
basic lab management skills (i.e., experience with Mac OS 9 or Windows in a lab) and
a general familiarity with Mac OS X. This course is not, however, a replacement for
Apple Certified training. See the "Next Steps" section at the end of this document for
recommended Apple training courses.

Overview of Lab Deployment

1. Prepare the drive on the master machine
2. Install the OS and applications
3. Customize the user environment
4. Test everything for security, functionality, and reliability
5. Create a disk image of the master disk with NetRestore Helper, saving the disk
image to a network volume or Firewire hard drive
6. Restore the disk image to other machines with NetRestore
Tools
The following tools will be used to complete these activities:

Apple Remote Desktop

http://www.apple.com/remotedesktop

Package Maker
http://developer.apple.com

NetRestore and NetRestore Helper

http://www.bombich.com/software/files/netrestore.dmg

LoginWindow Manager
http://www.bombich.com/software/files/lwm.dmg

ShadowClassic
http://www.bombich.com/software/files/shadowclassic.dmg

Login scripts:
http://www.bombich.com/mactips/scripts.html

Some of these items will be pre-installed on your lab machine, the others will be
available for download from the lab server. All of the documentation for this workshop
will be located on your workstation and you are free to take it with you. Please do not
take the Commercial software.

Resources
http://www.macosxlabs.org
This site has volumes of information specific to deploying Mac OS X in a University
environment. If this workshop has left something out, macosxlabs.org will fill the gap.

http://www.bombich.com
Besides maintaining links to a lot of lab management software, this site also has
several white papers on topics key to deploying Mac OS X in a lab environment.

http://www.apple.com/education/technicalresources/
A great site hosted by Apple listing links to other great resources on the web.

http://www.apple.com/server/resources/
An Apple site listing lots of Mac OS X server resources.
ACTIVITIES
Note that the first two activities may already be done for you in the interest of time.

A: Choose a master machine and partition its hard drive

for this project
Your master machine should be your latest and greatest machine. Mac OS X is a very
portable operating system, but it is much more portable from newer hardware to older
hardware than older to newer. You should also choose a machine that has the most
hardware options/peripherals. For example, if you will have at least one machine with
a SuperDrive, use that machine to create your image, even if most other machines
won't have that option.

Many people have asked me if you should create a disk image for each "class" of
machine that you intend to support. For example, should you maintain a separate
image for G5s vs. G4s or Desktops vs. Laptops? The answer is not simple. I typically
recommend that you try to maintain only one master disk image. Create it on your
latest and greatest machine. If that is a desktop machine and the image does not work
quite right on a laptop, then try creating the image on the newest laptop you have and
see if it works OK on the Desktop machine. If it simply isn't going to work either way,
then resort to maintaining separate images. I suspect that in most cases, though, you
will be able to maintain a single image.

You should consider setting aside an entire drive to the development of your master
disk image. Development and testing of an image is much easier if you divide your
disk into at least three partitions: one will be the working (Work) partition, one will be
the model (Macintosh) partition and the third will be the testing (Target) partition.
Equal partition sizes are fine, though keep in mind that your work partition will need
nearly three times as much space as is required to hold your Master installation.

1. Boot your master machine from a firewire hard drive or network disk image
(NetInstall or diskless NetBoot) or attach it to another machine while in target disk
mode.

2. Launch Disk Utility and select the internal drive of your master machine (do not
select the formatted disk, rather select its parent item).

3. Click on the Partition tab and choose the three partition scheme. Name the three
partitions "Macintosh", "Disk2", and "Target". Click on the partition button.
B: Install the OS(es)
1. Reboot from the Mac OS X Install CD and install Mac OS X onto "Macintosh". When
setting up the machine for this lab, use "admin" as the username and "apple" as
the password.

2. Reboot from the "Macintosh" partition and run Software Update and apply whatever
updates necessary.

3. Use Disk Utility to restore the "Macintosh" partition to the "Disk2" partition.

4. When the restore process is complete, you will have two "Macintosh" partitions (Disk
Utility renames the "Disk2" partition). Rename the boot partition to "Work".

5. Download the "Mac OS X Lab Deployment Workshop" folder from the lab server and
keep it at the root level of the Work partition (so its easier to get to when booted from
the "Macintosh" partition). This folder contains all the tools, documentation, and
software required for this lab. You may keep copies of the tools and documentation,
but please do not keep copies of the software.

* NOTE: If these steps have been done for you, you may have two partitions named
"Macintosh", and one named "Target". Your system will be booted from one of the
Macintosh partitions. Rename the drive you are booted from to "Work" before
proceeding. You should only rename a drive (with a system installed on it) when you
are booted from it, otherwise, the LaunchServices database could contain inaccurate
information and may cause applications on another drive to be launched instead of the
ones on the boot drive.

C: Install your Applications and lock them down

Applications installed with third-party installer applications are usually owned by the
user that installed them. The applications that came pre-installed belong to the root
user, and this is usually the preferred situation. In this activity, you will set the
privileges of your applications to be owned by root. Do this only for apps that you
are installing. If you are deploying an image for faculty users, you may also want to
revoke write privileges on your applications as well so that the faculty cannot remove
applications. This can be easily changed by an admin power user, but keeps most
people from accidentally deleting applications. You may also want to modify the
privileges of the Applications and the root directories such that only the root user can
make modifications to them. Do this only when you are finished installing applications.

1. Reboot from the "Macintosh" partition.

2. Install all of the applications you want to deploy into the Applications directory.
3. Using the Terminal application, set the owner of your applications to the root user
and revoke write privileges from users that are not the owner or in the admin group
(type "ls -l /Applications" to get a list of the applications and who owns them):

sudo chown -R root:admin /Applications/[your app here]

sudo chmod -R o-w /Applications/[your app here]

4. Prevent all users (except for root) from removing items that they do not own from the
Applications directory (by setting the "sticky" bit):

sudo chmod +t /Applications

5. Optionally, you may revoke write privileges to the Applications and root directory
from users in the admin group:

sudo chmod -R go-w /Applications

sudo chmod go-w /

Members of the admin group may include faculty, but also include the admin user you
are using to setup the machine. Perform this step only when you've finished installing
applications. Also, I wouldn't recommend this step for a lab deployment where no user
will use the machine as an admin, its only purpose is to prevent admin users from
casually deleting items from the Applications directory and writing stuff to the root
directory.

If you perform step 5, then admin users will only be able to save documents and install
applications in their home directory. Imagine how easy will it be to back up someone's
personal data when it is in one folder that the user owns exclusively instead of
scattered all over the hard drive.

* Note: It may seem easier, you may be tempted, but do NOT use chmod -R 755 on
ANY root level directories, you will lose important setuid bits! Also, don't change the
owner of all items in the Applications directory with a sweeping command as "sudo
chown -R root:admin /Applications" -- you won't be able to print (among other things)
as some must be owned by daemon!

D: Securing the Classic environment (optional)

Lab administrators face many challenges when trying to deploy Mac OS X systems
with an installation of Mac OS 9. Perhaps the toughest challenge faced is that Mac OS
9 does not offer the same security structure that is offered through Mac OS X. A user
could potentially boot a machine into Mac OS 9 to subvert the Mac OS X security
structure and do considerable damage to the Mac OS X system.
To prevent this from occurring, lab administrators can take several measures
including:

1. Choose to not install Mac OS 9

2. Do not install the Mac OS 9 drivers when formatting the drive
3. Enable the Open Firmware password on each machine
4. Run the Classic environment from a disk image

Each of these procedures has advantages and disadvantages, and none of them can
provide the best solution by itself.

1) Clearly the first solution will prevent a user from booting into OS 9, unless the user
has a bootable CD or a firewire drive with Mac OS 9 installed.

2) The second option offers excellent security because a machine booted into OS 9
cannot see the OS X disk at all (the Classic environment can, of course, see the OS X
disk while booted into OS X). This method by itself, however, does not prevent users
from booting the machine from an external device or CD.

3) Enabling the Open Firmware password prevents users from booting the machine
without either access to an administrative account or knowledge of the Open Firmware
password. This method also has a "high-security" mode that can be used to prevent
the machine from booting at all without entering the password, though that particular
mode would probably not be appropriate in a lab setting. I recommend implementing
this basic security step in addition to any other solution you use to secure your
computers.

4) To further complicate matters, there is an unfortunate situation with some poorly

written Mac OS 9 applications in which they require the ability to write back to their
own directory. This security problem is only addressed by the last option, which is the
most flexible option for securing the Classic environment. This is not an easy issue to
address though: how do you secure items that must be read/write by all users? The
best solution that I have seen so far is to install the Classic environment onto a disk
image, lock the disk image, then mount the disk image with a shadow file. Locking the
disk image makes it read-only, preventing users from changing its contents, but the
shadow file allows it to be functionally writable. Instead of making changes to the
contents of the disk image, though, the changes are written to a temporary file. After a
logout and login cycle, the temporary file is discarded and the Classic environment is
presented to the user in a pristine state.

Ideally, such a system would be completely automated. As of Mac OS 10.2, the Classic
environment allows booting from a disk image (and will even mount a disk image
automatically when Classic is started), which is a huge step in the right direction.
Unfortunately, the Classic startup application does not provide a way to mount the disk
image with a shadow file.
In response to this, some clever folks at the Mac Support group at the University of
Utah and the University of Colorado Boulder (Jeff Greene) came up with a shell script
to replace the executable inside the Classic Startup application that mounts a disk
image with a shadow file, then executes the original executable which initiates the
Classic environment. ShadowClassic is a simple little application that I created to
make the implementation of this method as easy as clicking a button. The instructions
for complete setup follow.

There is one caveat to this procedure. If you launch an application that is stored on the
Classic disk image prior to launching Classic (i.e., by clicking on its icon in the Dock or
double-clicking on an alias of the app), the Finder will subvert ShadowClassic and
mount the disk image without a shadow file. To avoid this you can set Classic to start
up on login or by launching another Classic application first (that is not located on the
disk image).

Note: Follow these instructions carefully. RUNNING SHADOWCLASSIC IS THE

LAST STEP.

1. Determine what items you want to secure on a disk image

You will want to place the System Folder and any misbehaving applications on your
Classic disk image. Misbehaving applications do not work when the user that
launches them does not have read/write access to the application's directory. Check
out http://www.macos.utah.edu/macosx_crappyapps.html for a list of some (certainly
not all) misbehaving applications and instructions on how to figure out if your Classic
apps are crappy apps.

After determining what applications you want to place on the disk image, determine
how much space they and the System Folder require. For the purposes of this
workshop, we will only copy the System Folder to the disk image. There is a System
Folder at the root level of the "Work" partition.

2. Launch Disk Utility.

3. Select "New > Blank Image" from the Images menu.

4. Save the image to /Library/Management (you will have to create that folder). Use
these settings:

Size: 50MB more than the amount of space that you determined in step 1.
Encryption: None
Format: read/write disk image

When Disk Utility is finished creating the image, it will be mounted on the Desktop.
Quit Disk Utility.

5. Copy your OS 9 System Folder and desired applications to the disk image. Place
any other System Folders (including the original) in the Trash. Empty the Trash.

6. Open the Classic Preference Pane in System Preferences. Select the System
Folder on the Classic disk image.

7. Click on the Advanced tab and check the box next to "Use Mac OS 9 preferences
from your home". This will store Classic prefs in ~/Library/Classic instead of in the
Classic System Folder.

8. Click back on the Start/Stop tab and start Classic. Test all applications and resolve
any issues.

9. In the Classic preference pane, make sure the System Folder on the Classic disk
image is still selected and stop the Classic environment. Close the Classic Preference
Pane and unmount the disk image. Do not re-open the Classic Preference Pane while
the disk image is not mounted.

10. Perform the first step of the next section (Section E) to create a non-admin user on
the system. Login as that user, mount the Classic disk image, then repeat steps 6-9.
Log back in as an admin user.

11. In the Finder, lock the Classic disk image in the image file's Get Info window.

12. Finally, launch ShadowClassic and enable the shadow image.

You should now be able to start Classic and make changes to the System Folder. Log
out and log back in, then launch Classic and verify that the changes are reversed.
Remember that you need to launch Classic by either launching a Classic application
that is not stored on the Classic disk image or by automatically starting it on login.

E: Home directory management

Default Home directory:
If you do not plan on using network-based home directories, you will want to setup a
default user account that is used for each person that uses the computer. To keep the
home directory clean and present each user with a consistent interface, you can
implement a login hook that will delete or move the default home directory and replace
it with a fresh copy.

1. In the Accounts preference Pane, create a new user without admin privileges. Use
these settings for the user (for the purpose of this lab, do not use any other settings
than those indicated below):
Name: Default User
Shortname: default
Password: apple

2. Logout and login as the default user.

3. Customize every aspect of the Finder that you think will be useful to your end-users.
I recommend setting the Finder to column view (if you get the window set to your liking,
close it, then every time you create a new one it will have those settings), and showing
the status bar (View > Show Status Bar). You can also customize the toolbar to include
"Delete", "Eject", and "Connect". Also customize the dock; I recommend removing most
of the stuff pre-installed in the dock and placing folders in the dock with aliases to
frequently used apps (if you have a lot, otherwise just drop the apps' icons into the
Dock). You may also want to include any Desktop Printers in the Dock as well because
they are no longer available in the Apple Menu. The more conveniences you add to
your image, the easier the migration to X will be. Also take the time to delete web
browser caches and history, recent items menus, etc.

Note: Keep in mind that Dock items are referenced with absolute paths. If you place
items in the dock from the user's home directory (like "Favorites"), those items will
appear as a question mark if that default home directory is used for a different user and
will be inaccessible. For example, suppose your model user is named "admin", and
you place an item from admin's account in the dock. If you later have a default user
named "student", that user will not have access to /Users/admin/path/to/item.

4. You should also look through each of the System Preferences panels to make sure
everything is set up appropriately. If you don't get the settings right here, you will have
to adjust them for every single computer that you image.

5. Run each application to make sure it works on the non-admin account and also to
initiate a default set of preferences. Place all applications in the /Applications folder.
Test the Classic environment and all Classic applications as the non-admin user as
well.

6. Finally, before you decide you are completely finished, look through the default
user's home directory for anything that can be trashed. Try to keep the overall size of
the home directory to less than a few megabytes if possible (any more and you will
start to notice a delay during login).

7. Empty the trash, then logout and log in as the admin user.

Create the default user template:

Logout then log back in as the admin user. We will create the default user template
from the home directory of the default account that we just created. If you plan on
creating new users on imaged machines you may also choose to replace the System
user template (in /System/Library/User Templates/English.lproj) with the default home
directory so that whenever a new user is created, that account gets your customized
interface automatically.
To create your default user template, do the following in the Terminal:

sudo ditto -rsrcFork /Users/default /Library/Management/default

sudo chown -R root /Library/Management/default

I made up the /Library/Management directory; you can use one that you're already
storing administrative-type stuff in if you'd like. The loginhooks that are included with
this lab reference the "default" user and the "/Library/Management/default" directories
specifically. If you use other settings, you will need to edit the login script accordingly.

F: Implement a login hook to manage default user home

directories
A goal of lab managers is to offer a consistent interface to end users every time they
visit a machine. This can be achieved quite easily with the use of default home
directory templates and a login script that deletes the "used" home directory and
replaces it with a fresh copy of the template.

1. A basic login script is available in the Tools folder of the Mac OS X Lab Deployment
Workshop folder. Open the script in a text editor and read the comments at the top of
the file to understand what it does and what settings you may need to change (in the
Properties section).

2. Copy this login hook into /Library/Management, and make sure that the executable
bit is set on the script:

sudo chmod a+x /Library/Management/refresh-default-homedir.sh

3. Launch LoginWindow Manager. You will use LoginWindow Manager to edit the
Computer domain preferences file of the loginwindow application.

4. Check on the box next to "Run this shell script on login". Drag the login script onto
the login script text field.

5. Click on the "Test" button to verify that the shell script will execute successfully. If
you implement a login script that does not execute successfully, you will not be able to
log in. If the test fails, open the script and check the Properties section to verify that all
of the settings match your setup. Also double-check that the script is executable.

6. When the test has completed successfully, click on the "Apply" button to update
loginwindow's system-wide preferences
7. Explore the other hidden features of the loginwindow application. What could you
use the "Loginwindow Message" feature for?

8. Quit LoginWindow Manager. You do not need to keep LoginWindow Manager on

the machine for the login scripts to run.

9. For future management of the default user home directory, examine the "1-
unlock.command" and "2-relock.command" scripts in the Mac OS X Lab Deployment
Workshop directory. They can be launched by double-clicking, but you should
examine them with a text editor first and make any appropriate changes to the
Properties section to suit your environment.

G: Network Home directories, Managed preferences, and

other network-based services
If you plan on using network services from a Mac OS X Server, you should set up those
services now. Configuration on the client is minimal. Usually all you need to do is to
bind the client to the Open Directory server or campus LDAP server. If this information
is available as part of Option 95 on your DHCP server, then no client configuration is
required. You should set up any automounted volumes at this time (applicable only if
not binding to a server).

H: Create a package installer to deploy software remotely

Apple introduced a new "Install package" feature in Apple Remote Desktop 1.2. This
feature allows you to remotely install packages of software, such as the Software
Update packages, to your legions of computers. You can also create your own
packages for distributing your own software and/or custom configurations.

Overview: First, you need to create a folder to store your project in. Next, you will
create a directory to hold files and another for resources. In the files directory, you will
create a replica of the filesystem, including only the items you plan to include in your
package. Next, you can create resources such as ReadMe files, license agreements
or postflight scripts and store them in the resources folder. Finally, launch Package
Maker, fill out some forms and create your package.

The following instructions guide you through creating a package to update your default
user template and the login script. The instructor will use the example below for
demonstrative purposes. When you go through this exercise yourself, you may
substitute in any other applications you want.
* If the files you are including in your package are not readable by the admin user, you
will need to log in as the root user in order to successfully create the package.

** If any of the files that you are including in your package have resource forks then
you will need to have the Developer Tools installed (vs. just having a copy of Package
Builder). If you would like to build a package with resource forks, you can reboot from
the "Work" partition which has a copy of the appropriate Developer Tools.

1. Create a project directory on the Desktop named "Lab Update".

2. Create a "files" and "resources" directory inside "Lab Update".

3. Create the following directory tree inside "files":

Library/Management
Library/Preferences

4. Now copy the original items to their appropriate directories within your build
directory:
/Library/Management/default --> ~/Desktop/Lab Update/files/Library/Management
/Library/Management/refresh-default-homedir-savetmp.sh --> ~/Desktop/Lab
Update/files/Library/Management
/Library/Preferences/com.apple.loginwindow.plist --> ~/Desktop/Lab Update/files/
Library/Preferences

5. Suppose you've deleted some files from your default home directory template.
Installing the package will merely merge the new and the old directories, so you will
need to delete the old directory first. Create a shell script that will run before the files
are installed. It will look like this:

#!/bin/sh
/bin/rm -rf "$3"/Library/Management/default

The installer application passes a few arguments to pre/postinstall scripts. The "$3"
argument is the path to the target drive, there is no space between the "$3" and the "/
Library...". Read Package Maker's documentation for information about implementing
scripts in your package. Name the script "preinstall", set its executable bit, and place it
in the resources directory.

6. Launch Package Maker. In the first tab, provide a name, version, and description for
the project.

7. In the Files tab, choose the "files" directory in your Lab Update project folder.

8. In the Resources tab, choose the "resources" directory in your project folder.

9. In the Info tab, leave "/" as the default location and select "Required Restart" and
"Root authorization". Read Package Maker's documentation in the Help menu for
more information on the other options.

10. Fill in the requested information in the Version tab following the examples.

11. Save your Package Maker project into your project directory (File > Save).

12. Choose "Create Package" from the File menu and save the package to your
project directory. Test your package on a test system.

13. In the Remote Desktop Admin application, select the computers that you want to
distribute the package to.

14. Select "Install Package..." from the File menu and select the package in your Lab
Update project folder.

I: Create an "Apple Software Restore"-ready disk image

The next step is to create the disk image that you will use to deploy your configuration
to other machines. This workshop suggests the use of NetRestore Helper (NRH)
because it was specifically designed to make this process very easy with very few
steps. Alternatively, you can manually perform the same steps that NRH performs by
following the instructions provided in the asr man page. You could also use Disk
Utility's "Create new image from folder" option. NRH has an extensive Help system
and there is a wealth of information at http://forums.bombich.com if you run into
problems.

1. Reboot from the "Work" partition. You may want to run a disk utility on the Macintosh
partition before proceeding to verify that there are no directory problems.

2. Launch NRH and click on the "Create Master Image" tab.

3. Choose the "Macintosh" partition as the source and choose "Read-only

compressed" as the format.

4. Authenticate and click on the "Create Master Image" button. You will be prompted to
choose a location to save the disk image to. For this workshop, choose the "Work"
partition (the Desktop is convenient). Note that your target requires approximately 2X
as much free space as is used on your "Macintosh" partition.
J: Test your image
1. Launch NetRestore and drag your master disk image file onto NetRestore's location
field.

2. Choose "Target" as the target disk and check all the "Options" boxes.

3. Authenticate, then hit the Restore button. Depending on the size of your disk image,
the restore process should take 4-10 minutes.

4. When the process completes, the system will reboot and you will have the
opportunity to test everything that you had installed on the Macintosh partition.

K: Prepare your image for mass distribution

The final step is to restore the disk image to other computers. There are several
methods for performing this feat, including NetInstall, Disk Utility, the command-line asr
tool, and NetRestore. NetRestore is a flexible, customizable, open-source GUI for the
command-line asr application. NetRestore can be used to restore images kept on an
external hard drive, a DVD, or on a network server.

To be able to restore your disk image to a machine's hard drive in the fastest and most
efficient manner possible, you must be able to unmount that disk so that asr can
perform a block-level restore. To be able to unmount a disk, you cannot be booted
from that disk and there cannot be any open files on that disk. Essentially, you must
boot that machine from a CD/DVD, external Firewire drive, or a network disk image.
There is extensive documentation included with NetRestore, so I will only describe
one scenario here: Restoring an image while booted from a network disk image. This
method has the added advantage of allowing you to administer everything remotely.

The basic process here is that a client computer boots from a disk image maintained
on the server. When the client boots, the only application that launches is NetRestore
and it either starts restoring your master image to the local hard drive immediately or
gives you the option to choose a configuration, target and options prior to imaging.

1. Copy your master disk image to an AFP file server or web server. Note that
NetRestore Helper allows you to save your image directly to any mounted AFP
volume.

2. On your Master machine, launch NetRestore Helper and click on the "Create
NetInstall Set" tab.

3. Provide a name for your image set (for example, NetInstall-Restore), a unique id
and a brief description. Save the image set to your Desktop.
4. When NetRestore Helper finishes creating the image set, it will ask if you want to
configure NetRestore now. Choosing to do so will launch the copy of NetRestore that
has been installed in the Utilities folder of the NetInstall-Restore image set, and you
will have the opportunity to edit the preferences and configurations.

5. In NetRestore, select "Edit Configurations..." from the NetRestore menu. Create a

configuration that references your master disk image file on your file or web server.
Test the configuration by selecting it in the list of configurations and clicking on the
"Test" button. If the image mounts, then you have set up the configuration correctly.

6. Close the Configurations Manager and select "Preferences" from the NetRestore
menu. Set up some default preferences, but do not enable full automation. Save the
preferences.

7. Quit NetRestore and unmount the disk image.

8. Copy the image set to /Library/NetBoot/NetBootSP0 on your NetBoot server. At this

point you could reboot your client machine from the server and restore your master
image set.

The Instructor will review how to setup NetBoot on the server and will demonstrate
some more advanced features of NetRestore. The Instructor will then use Apple
Remote Desktop to choose the NetInstall-Restore image set as the startup disk for all
computers in the lab. When the machines reboot, they will be imaged with the original
configuration of the host's computer lab.
Next Steps
Hopefully by now you have gained some basic information on how to quickly deploy
Mac OS X in a lab environment. Deployment and management are very different
things though. Depending on how many computers you have to manage and how
complex the infrastructure and deployment requirements are, there are two different
routes to take to better prepare yourself for properly managing your Macs (see the
certification roadmap at http://training.apple.com/certification/).

Apple Certified Technical Coordinator

Mac OS X technical coordinators and entry-level system administrators tasked with

maintaining a modest network of computers using Mac OS X Server should follow the
Apple Certified Technical Coordinator track (http://train.apple.com/cert/actc.html). This
consists of two courses and their associated exams:

Mac OS X Help Desk Essentials:

http://train.apple.com/course/D2713ZA

Mac OS X Server Essentials:

http://train.apple.com/course/D2709ZA

Apple Certified Systems Administrator

Full-time professional system administrators and engineers who manage medium-to-

large networks of systems utilizing Mac OS X Server in demanding and relatively
complex multi-platform deployments should follow the Apple Certified Systems
Administrator track (http://train.apple.com/cert/acsa.html). This consists of two courses
and their associated exams:

System Administration of Mac OS X Clients:

http://train.apple.com/course/D2813ZA

Mac OS X Server Administration and Integration:

http://train.apple.com

Additional Courses

Directory Services:
http://train.apple.com/course/D2854ZA