DeployStudioSetup

=**DeployStudio Configuration**= This wiki is to document the configuration of a private Mac OS X Server machine running DeployStudio for the purpose of reimaging machines. There are lots of different ways to reimage Macs, and traditionally a combination of a FireWire drive, Target Disk Mode, and Carbon Copy Cloner / Super Duper has been the simplest and most common solution for mirroring computers. However, with the advent of the new MacBooks that lack FireWire ports, the time has to come to rethink the process.

DeployStudio + Mac OS X Server has a lot of advantages. First and foremost, the difference in speed when using gigabit ethernet compared to FireWire is fantastic. FireWire 400 only allows a maximum throughput of 400 megabits per second, and FireWire 800 logically allows 800 mbps. Gigabit ethernet supports up to 1000 mbps (a.k.a. 1 gbps). Secondly, FireWire is limited to one computer at a time - a master hooked up to the slave. DeployStudio, since it uses TCP/IP and Ethernet, can support multiple computers at once. It also supports multicast, which theoretically works great for a large number of computers. [|Auctions online] [|Shopping Online] [|Auctions] [|iPhone] [|ipads] In my experience, on a cheap consumer-level gigabit switch (D-Link green 8-port gigabit switch), the multicast performed much much worse than using a bunch of unicasts at once. If you used a more enterprise-level switch (or a managed switch, such as an HP ProCurve), you'd probably experience a dramatic improvement. However, for the purpose of making a tiny private internet, an HP ProCurve is a bit like sandblasting a soup cracker.

DeployStudio has some disadvantages as well. Disk images require lots of hard drive space, and your disk speed will generally be your most limiting factor. CPU load was not terribly intensive even with 7 client computers going at once. The hard disk, however, was spinning for its life.

If you are used to booting off of FireWire drives and using Carbon Copy Cloner, then you will immediately notice one disappointment. Since DS requires the use of disk images, making a change to your image is no longer trivial. With bootable FW drives, you could simply boot into the image you wanted to modify, run updates or make whatever changes, and then it would be ready once you rebooted. With disk images, you have to make those changes, and then re-capture the image. Depending on the size of the image, this could be an hour, maybe two.

Those are some thoughts to keep in mind. Our current setup involves a recent MacBook Pro (2009 model, 2 GB Ram, 120 GB hard drive) with OS 10.5.8 Server installed (Unlimited License), a D-Link 8-port gigabit switch ("green" for less power consumption, although that's mostly negligible), 8 ethernet cables, and a surge protector sitting inside a backpack.

I have not tested 10.6 Server yet, but from what I hear the process is not significantly changed. As soon as I get a chance to actually try it out, I will update this (unless someone else beats me to it).

This documentation will cover the preparation and configuration of the server to act as a tiny private internet for the purpose of reimaging. Note that this requires no changes to the client computer configuration - they only have to be capable of NetBoot (which so far every is Mac we've come across in our school).

**PRE-PRODUCTION**
The obvious first step is to set up your images. Run Software Update, create at least one local administrator, and run each application once. Set the region code on the DVD player. Repair Permissions with Disk Utility. Make any configurations to your accounts that you prefer. Test, test, test! Nothing is more irritating than having to redo the image when you realize there's a problem //after// you've stamped it onto a client computer.

Some more suggestions:
 * Configure Apple Remote Desktop users and settings
 * Set master password for Filevault
 * Launch applications like Microsoft Word, which often have first-time run routines
 * Enable NTP (network time protocol)
 * Delete Directory Service entries (unbind from the server, that can be done automatically using a post-install script)
 * Use Onyx to dump all system and user caches
 * Delete the sleepimage out of /private/var/vm (don't reboot into Mac OS X after doing this, because then it recreates it)
 * Pair the machine with an Apple Remote, if you use it

Once you are fully satisfied with your system, you can create the image in one of two ways. You can use Deploy Studio's "Capture" workflow to capture the image onto the server through NetBooting, or you can use Disk Utility to create the image now and then copy it over manually. My recommendation is that you use Disk Utility, as you can set that aside and let it run while you work on other things.

In Disk Utility, you'll want to go to New -> Image from Folder. You do NOT want to use Image from Disk because it creates a different type of image. "Image from Folder" creates a stretchable image and ignores the freespace. "Image from Drive" makes a complete image of the drive, which will generally end up wasting your time. It also won't compress easily, and compression makes all the difference here.
 * Disk Utility Image Creation**

Don't use encryption on these images - I've had mixed results getting DeployStudio to successfully deal with them. However, you DO want to use Compression. It will take extra time in the creation of the image, but you'll enjoy significant time savings in the actual deployment process.

The image will need to go into the /deploystudio/Masters/HFS/ folder (which will be explained later).

**MAC OS X SERVER INITIAL SETUP**
The first question you are greeted with upon booting from the OS X Server disc is whether you want to use a "Standard", "Advanced," or "Workgroup" configuration. Basically, the only differences here are the amount of options you're presented with. Advanced provides the option to manage and configure all possible services, so go with that. "Standard" would be for a server that is not running its own DNS or DHCP, assuming instead that they're being provided elsewhere. "Workgroup" is for turning this into a DirectoryServices server only.

Enter in the Serial Number and Registration.

Create your first Admin Account. For this example, we'll use the username "admin" and the password "apple3."

For network settings, you'll want to manually configure this. Remember, this should not be plugged into the network- it will be its own provider for everything. Uncheck "Lights Out Management," and uncheck "Ethernet 2" (if it's an option). We'll only be using one ethernet port.

Set this to the private network address of 10.1.1.1, with subnet 255.255.0.0, gateway of 10.1.1.1.

For DNS, let's name this "server.apple.edu." Computer name will be "server." You can obviously change this to whatever you want, and use the domain of your own school instead of "apple.edu." For example, our Server MacBookPro is called "deployer.sacredsf.org," even though it'll never be on the internet nor actually share any DNS resolution with current network.

Skip configuration of DirectoryServices - it won't be needed for this task.

The base install of OS X Server is about 12 gigabytes.

When you've booted up, run all available Software Updates.

**CONFIGURING THE SERVICES**
Open up the "Server Admin" application. Remove the server from the list on the left, and instead you want to go to the Server menu -> Add Server. Enter in the name you provided above, "server.local" to access. We can change this later once DNS is running.

Now you'll want to configure the Services provided. If prompted, select "Choose Configured Services". You can also manually go to the Services tab by clicking on the "Settings" pane at the top, and then click on the "Services" tab on the right. Check the following boxes: AFP, DHCP, DNS, NetBoot, NFS, and OpenDirectory.

__Important Note__: This list of checked services only corresponds to what services are available to be managed. It has no control whatsoever or whether or not a service is running. It's entirely possible to configure a service, start it, and then uncheck the box in this list. You'll then have a service running, but you won't be able to manage or edit it until you check the box in the list again. It's best not to remove things from the list unless you are very, very sure you are done with it and it's disabled.

In the DNS service, click on the "Zones" pane. Click the "Add Zone" button, select "Add Primary Zone (Master)." Use whatever domain you want, it doesn't really matter: "apple.edu." (the ending period will automatically add itself). Under Nameservers, double click on the default "ns" entry, and change that to the DNS name of your server: "server.apple.edu".
 * Configure DNS**

Now, click the expansion arrow next to your domain in the DNS list on top. Underneath will be an entry for your nameserver. Make sure the name is correct, and then add the IP address of the Server to it. In this example, the Machine Name is "server" and the IP address is "10.1.1.1" (as we configured initially).

Verify that the reverse zone maps the correct IP address to the DNS name of the server.

Save the settings, and then click "Start DNS" at the bottom left.

Now open the System Preferences. Go to the Network pane. Add "10.1.1.1" as your DNS server. Under "Search Domains," add the domain you configured ("apple.edu").
 * Add DNS resolution to your network settings**

To verify that your DNS settings are correct, open up the Terminal. Type in: (the $ just indicates the prompt, do not enter it in) $ hostname The response should be the DNS name for the server, i.e. "server.apple.edu". $ host server.apple.edu The response should be the IP address for the server $ host 10.1.1.1 This should resolve in reverse to your DNS name. $ sudo changeip -checkhostname Again, this should match your DNS name.

If there are any problems, check your DNS zone configuration and make sure everything matches the details. It doesn't really matter what IP address you configure the server to use, or what names / domains you use, as long as you are consistent.


 * //CRITICAL NOTE//**: You must have a working ethernet connection plugged in from this point on. Plug the Server into a private switch. It doesn't need a live connection to the internet - only a valid working ethernet. When you look at the Network Status in the System Preferences, the dot should be "Green" and the connection should be up. Reverse DNS lookup //will automatically fail// without a live ethernet link, so you'll need one from now on.


 * Configure DHCP**

In the DHCP service, click on the "Subnets" pane. Select the subnet already provided. Rename the Subnet to "Private Network" (or whatever you want).

Set the Router to the IP address of the server (10.1.1.1). Set the starting and ending IP addresses to whatever range you see fit within your subnet, such as 10.1.100.1 through 10.1.255.253. Subnet mask in this case is 255.255.0.0. Unless you plan on doing a huge number of machines at the same time, you can set the Lease Time to 1 hour; it's rare that it'll a machine longer than that in the DeployStudio runtime.

In the "DNS" tab, enter in the IP address of the server (10.1.1.1). Change the default search domain to "apple.edu" (again, replace this with whatever you've been using so far).

Save the configuration, and start DHCP.


 * DNS Entry for Server Admin**

Now that you've got DNS and DHCP running, you can add the server via DNS to the server list in the Server Admin program. Remove the "server.local" entry in the list on the left, and go to Server -> Add Server. Add in "server.apple.edu." If you've done everything right, you shouldn't have any problems adding it to the list and managing it this way.


 * Configure OpenDirectory**

Select the "Open Directory" service. Go to the "Settings" pane. Change the role to an "Open Directory Master." For the Directory Administrator, use the username "diradmin" with password "apple3" (just for consistency, we're going to use the same password for everything; obviously you can use whatever passwords you want).


 * Configure AFP**

AFP requires no configuration. Simply Start the service.


 * Add the DeployStudio share**

Click on the server name in the list on the left, and click on the "File Sharing" pane. Highlight the hard drive, click the "Browse" button. Click the "New Folder" button, add a folder named "deploystudio" to the root level of the hard drive.

Highlight the newly created "deploystudio" folder, and then click on "Share."


 * Configure DeployStudio admin account**

Open the "Workgroup Manager" application (either in the Dock, or in the Applications folder). Connect to the localhost server with the admin account and password (or you can use the DNS name).

Click the little lock icon at the top right and authenticate with "diradmin" / "apple3" (which we specified earlier in the OpenDirectory configuration).

Click the "New User" button at the top. Call this user "Deploystudio" as a long name, "dsadmin" for a short name, and with password "apple3" (or whatever).

Save. Click the "Server Admin" button to bring you back to Server Admin.

//Note: If any part of this process fails for you, or you receive an error 68 from Open Directory while trying to modify settings, it's because reverse DNS lookup isn't working. Remember that you must ALWAYS have a working ethernet connection plugged in to the server while making these changes, because reverse DNS will automatically fail if the ethernet link is down.//

Go back to the Server Overview (click on the name of the server in the list on the left), and go the "File Sharing" pane. Click on the "Share Points" button, and highlight the "deploystudio" folder you created earlier. In the Permissions section below, click the "+" button at the bottom. Drag the "deploystudio" user from Workgroup Manager onto the "root" POSIX entry. The goal is to make sure that "dsadmin" has Read/Write permission to the entire "deploystudio" share. Save your configuration.

**Install DeployStudio**
Download the latest stable build of DeployStudio from the website, @http://www.deploystudio.com/Home.html. This is best done on another machine, and copied over with a flash drive. Remember that your Server is now serving out DHCP and DNS live, so if you plug it in to the wide network, you may run into serious problems.

Once installed, run the "DeployStudio Assistant" application from the /Applications/Utilities/ folder. When prompted, "Start" the DeployStudio server.

Click the radio button for "Set up a DeployStudio server." The address is going to be "http://server.apple.edu:60080" (the port should be put in automatically for you). For authentication, use the DS admin account "dsadmin" with password "apple3." Choose a Network Sharepoint, which will be "afp:server.apple.edu/deploystudio". Again, use the "dsadmin" account to authenticate everything DS-related.

If you want to, enable secure server (which changes the port to 60443). Since this is going to be a tiny private network, it doesn't matter whether you do or not.

You will also get a chance to modify the multicast settings. There's no easy way to explain these, so I'll leave it to the master Mike Bombich: @http://www.bombich.com/mactips/multicast.html. I do wish to reiterate my personal experience, which is that a cheap gigabit switch made for extremely poor multicast performance. I had more success unicasting 7 machines simultaneously (staggered startups) than I did using multicast for them. I blame the cheap switch for this, but I also won't hesitate to point out my inexperience with multicasting, and that perhaps some adjusting of the settings and experimentation would yield better results. Your mileage may vary, and I welcome you to post some of your own results.


 * Create a DeployStudio NetBoot set**

This is the part that can occasionally cause problems for some people. This step will need to be done on the newest Mac that you've got. What this step does is create a tiny bootable image that contains drivers for all the Mac models. Nearly every install of Mac OS X contains drivers for all previous bootable Mac models. Each new system update brings the drivers up to standard for all Mac OS X installs. For example, 10.5.8 includes all drivers for every Mac that was released up to that point. A Mac that has come out afterwards will have a special unique build of Mac OS X, and you may notice in your own experimenting that your older mirrors will not work on the new hardware until you've incorporated those drivers.

To reiterate: this step needs to be done on the newest Mac you intend to serve.

You can install DeployStudio on any Mac (it doesn't have to be running OS X Server to create a NetBoot set) and choose "Create a DeployStudio NetBoot Set" from the Assistant program. You just won't be able to actually serve the DeployStudio netboots from a non Mac OS X Server system.

From whatever machine you use, use "DeployStudio Assistant" to "Create a DepoyStudio NetBoot Set." Name it something useful - i.e. "iMac Late 2009" for example, so that you'll know what driver set it was using. Note that the NetBoot sets work across PPC and Intel machines (the only time we've encountered problems with this is with the extremely old G3 iBooks). Add a unique identifier for this NetBoot Set (i.e. 101). If you do additional NetBoot sets for whatever reason, make sure you make their identifiers unique! You definitely won't want two different driver sets with ID 101.

The address will be preconfigured to be your server, so make sure it points to "http://server.apple.edu:60080" (or "https://server.apple.edu:60443" if you're doing it securely). If this is being done on the Server itself, the dropdown menu will list it.

The default login should be "dsadmin" with password "apple3." You can set a VNC password if you like, although I've never once used it.

You will be asked for a Destination to place the NetBoot image. If you are doing this on the OS X Server, then choose /Library/NetBoot/NetBootSP0/. If you are NOT doing this on the server itself, then simply select the Desktop. You'll need to copy over the .nbi file into the server's /Library/NetBoot/NetBootSP0/ folder manually (i.e. through a flash drive or through file sharing).

Quit when done. This will create the boot image (.nbi file) in the proper location.


 * Configure NetBoot**

Go back to the Server Admin program. Click on the "NetBoot" service on the left. Click on the "Settings" pane.

At the top, select "Ethernet" as the only port with NetBoot enabled. If you're on a laptop, you definitely want to uncheck FireWire and AirPort; NetBooting over wireless is a very very bad thing.

At the bottom, check both "Images" and "Client Data" for the hard drive. If you were using an XServe that had multiple hard drives or RAID configuration, you could store the Client Data on one partition / drive, and the Images themselves on another. Since this example is using a MacBook Pro laptop, there's only one drive, so obviously it's going to be used for everything. You could potentially use an external drive, but then you introduce another bottleneck - the FireWire or USB connection of your external drive.

Save.

Click on the "Images" tab at the top. Your NetBoot image should be in this list with its unique identifier. Click the boxes for both "Default" and "Enable." Unless you have a specific PPC or Intel-only architecture, that should be kept to "Universal." Protocol should be kept to "NFS."

Save.

**Configure DeployStudio Workflows**
Open the DeployStudio Admin application (in /Applications/Utilities/). Authenticate with "dsadmin."

Click on the "Workflows" entry in the left list. Several Workflows are provided for you already: namely, Creating a new master, Restoring a Master, and multi-OS Restoration.

If you want to create an image from a NetBoot client directly onto the server, then you'll want to use "Create a new master from volume..." I highly recommend that you leave the default one alone, and make a copy. Do this by highlighting the "Create a new master..." workflow, and then clicking the two-window icon button on the bottom middle. That will create a duplicate of the workflow, which you can then freely modify. You can do this as many times as you need to.

The "Source" is the name of the hard drive. From a brand new computer, it'll most likely be "Macintosh HD," but you need to know this ahead of time. Generally you'll be modifying this workflow for a specific computer, so if I need to create an image of "Lab_Machine_1", then I either need to rename the hard drive on the computer or specify a new workflow every time I want to image something else.
 * Create a new master from a volume**

For "Type", you'll want "Compressed." The time savings in the end are worth the extra time taken now.

Format should be "Auto-Detect," but you can specify a file system ahead of time. Note that if you're doing a PC-based capture, this won't matter in the slightest because the PC Capture process ignores these settings and requires manual input.

You can put in Keywords to describe the image you're capturing, but I've never bothered nor had to use them.

"Temp volume" can be good if you have multiple hard drives. You can write directly from the capture to one drive, and then compress onto the other. It makes it go a bit faster and more efficiently, although as it states, it's optional.

Check the "Automate" button if you want this to be entirely unattended. Automation is the best part of DeployStudio, and allows you to set it up so that after booting, you don't need to come back until the process is complete.

Images captured this way are placed in the /deploystudio/Masters/HFS/ folder. If you do it manually using DiskUtility, you'll need to copy the disk images into that folder before launching DeployStudio Admin. It doesn't update in real time.

This is the real meat right here - the workflow that stamps an image onto a client computer. Create a copy of this and rename it to something that indicates what mirror image it is for.
 * Restore a master on a volume**

Select the image out of the drop-down list.

Check the "Restore image on the first drive available" box if the clients only have one drive (most Mac configurations). This grays out the "Target" field, which would otherwise allow you to specify the name of the drive that you wish to image.

If you wish to Rename the volume, enter the name into the appropriate field.

If you plan to use Multicast, you can check the box and adjust the sliders and fields as you see fit. I do not plan to use it, so I won't go into it.

The very first time you do this, I recommend unchecking the "Don't check restoration (faster)" box. It's good to verify it the very first time to make sure it goes okay. After the first one, though, you can skip it. I've never once had a problem with it that wasn't due to user stupidity (for example, disconnecting ethernet in the middle of a deploy... it's unrecoverable from there, so you'll need to start the whole deploy over).

Check the "automate" box if you don't want to require user interaction.


 * Create A Group of Computers To Apply A Workflow**

Now click on the "Computers" entry in the left list. Click the "+" icon at the bottom left to create a new Group. This Group represents any arbitrary list of computers that you want to apply a workflow to - for example "Elementary Lab."

Click on the Group you created. The first tab is "General," and here you have the option of setting the Local hostname or Computer name, but I find that it's generally easier to fix this manually depending on how you name your computers. This is optional.

The "Network" tab allows you to add specific unique network settings to your client computers after they've been imaged. The "Accounts" tab allows you to add user accounts to the client computers as well. Note that there's no way to customize the user accounts through DeployStudio - it will add a standard Mac OS X account from the default account template. Unless you are also using Workgroup Manager on an OS X Server to control the accounts, these will be standard configurations.

The only really important tab here is the "Automation" one. The first box is "Default group." This means that every computer you boot up into NetBoot will be added to this group, and use this Workflow. For unattended installs, this is what you want, so check the box.

Choose the workflow you want to start automatically. For example, let's say I copied the "Restore" workflow and renamed it "ELEMENTARY LAB." This tells me that the workflow will apply the mirror used on the Elementary Lab computers. Hopefully this sufficiently demonstrates the importance of a consistent naming convention for your workflows and images.

Check the first box "Reset default workflow..." This prevents the machine from booting back into NetBoot. The second box only needs to be checked if you need to make absolutely sure that after getting reimaged, a machine does not get the workflow executed on it again if it NetBoots. In general, if you're using a private tiny network, this isn't really that important, because you'll have complete manual control over that.

You are now completely set up and good to go.

//AN IMPORTANT NOTE ABOUT AUTOMATION: By using full automation with no user interaction, you save lots of time because the machines will do what they need to do without you having to babysit them or tell them to start. However, this makes it even more dangerous for the wide area network. If you set a completely unattended default reimaging on the wide network, and someone manages to accidentally boot to the network NetBoot server, this means they can potentially have their entire hard drive erased and/or reimaged without them having to do anything. With everything Automated, they won't get an opportunity to cancel short of shutting down the machine. A tiny private network won't have this problem, because obviously no random users will be going onto it, but this is a critical danger that I felt was worth noting.//


 * Ladies and Gentlemen, Start Your NetBoot**

Hook up your client computers to the ethernet switch, and start them up while holding down "N." That forces it to locate the NetBoot server. Assuming all goes well, you'll see the spinning globe icon underneath the Apple, and they will boot into the "DeployStudio Runtime" environment via the NetBoot image. If everything is automated, it should do its magic and then reboot automatically.

In our experience and testing, a ~20 GB image takes about 15 minutes to apply this way.

If anyone has any questions or concerns with this process, please email me at nmcspadden@sacredsf.org. Good luck!