Well I’ve been pretty busy lately working with Mac’s which is something I don’t do very often. We have finally gotten round to automating the rollout of our Mac lab. I used a combination of tools as we dual booted the iMacs with Lion and Windows 7. To deploy the Mac side of things, I used DeployStudio. I used rEFIt to manage a GUI bootloader to switch between Lion and Win 7. To rollout Win 7, I used an altered Task Sequence from MDT 2012. Here is how I managed to get it all working…
Please see the foot of this post for references…
The theory
Deploystudio is a fairly straightforward package. Firstly, you create your deploy server via the DS assistant. Then create a netboot image – this is basically the mac version of a WinPE though a lot larger in size, nearly 2.5 GB! The netboot image is a striped down version of the Mac OS and is what we boot into when running a workflow. As well as giving us access to the features of DS, we can also access tools found in Utilities; disk and network utilities, terminal, etc.
From the DS admin tool, we can amend our workflows and create new ones. We can add packages for deployment and we can monitor the ongoing deployment tasks to clients.
When it comes to automating the installation of applications we can use the Iceberg package manager running on a target machine, to capture the apps and then copy them to the deployment server. Some packages require more work than others, hence in our main deployment workflow we have multiple package installation bundles as some software is happy to be installed from the netboot image, others require to be installed at next boot.
As we are dual booting the iMacs, we will be using rEFIt to manage a GUI boot loader, giving the user a graphical interface in which to select whether the mac boot into Lion or Windows 7.
Our master workflow will partition the drive in a way, which will allow us to install Windows 7 after the successful installation of Lion.
The Deployment process
Once we have the server setup we can turn our attention to the deploy admin utility and begin the deployment process. The deployment process itself couldn’t be simpler. Much the same as MDT 2012, we will boot to the netboot image and select the workflow we want to run. Once we click the play button, the workflow does its thing and requires as much interaction from the user as defined in the workflow configuration.
Before delving into that, we’ll have a look at how to create a Deployment server. The instructions for setting up and configuring the server have been influenced by the instructions within the DeployStudio manual, which is referenced at the end of this document.
Configuring the server pre DeployStudio
DeployStudio should be installed on a server platform; any form of Leopard or Lion will suffice. We will be making some changes to the services running on the server. To do so, open Server Admin.
DeployStudio, DS, doesn’t work well across subnets so you need to ensure that the server you are installing to is on the same subnet as the machines you will be deploying to. You need to ensure you have a static IP and if the server itself does not have DNS running, then it should have knowledge of the appropriate DNS server.
Only AFP and Netboot services need to be configured, OpenDirectory can also be configured but is not a requirement.
AFP, Apple File Protocol, allows us to share images scripts and files across the network. All we need to do with this service is ensure that Guest access is set to default and then start the service.
We cannot configure the Netboot service until we have created a netboot image, but we will discuss what has to be configured here. With Netboot selected in the left hand pane, select Settings>General. Check Ethernet, ensuring that you select the correct Ethernet port if you have multiple Network ports on your server.
Netboot Settings from Server Admin
From the bottom of the main window, check off the image and data locations. Ensure that you SAVE NOW, as you won’t be able to complete the following step if you haven’t done so.
From the tab along the top of the main window, select images. Verify that the netboot image that you created using the DeployStudio Assistant is visible. Select it, save and start the service.
From Workgroup Manager, create a deployment admin account. This is the account that will be used to login to the netboot image and run the workflows. It is important to ensure the password is very secure as with any admin account.
Back on the Server admin, we need to ensure that the admin account just created has correct permissions to the Public directory as this is where the DeployStudio repositories will be stored. To do this, select the server from the left hand pane and choose File Sharing from the top of the main window. Select share points and then select Public. Under the Permissions section of the window, use the + button to add the newly created deployment admin account to the permissions manager. Ensure that the admin has Read & Write permissions, save and exit.
Setting the permissions for the Deploy Admin account
With public still selected, click browse and then New Folder and call it DeployStudio.
Installing and configuring DeployStudio
Download Deploystudio from here: http://www.deploystudio.com/Home.html. Once you have it downloaded, go ahead and install it.
Once installed, open DeployStudio Assistant which can be found in /Applications/Utilities. From the list of options, select Setup a DeployStudio server.
DeployStudio Assistant
In the next window enter the server address followed by the port number, which will look something like this:
https://ServerName.com:60443 <– Default port number.
The username and password will be the account that we created in the last stage, the deployment admin user.
In the next window select whether this server will be a master or a replicator. Select the appropriate option and move onto the next screen.
This window is for the repository settings. Ensure that you select Network Sharepoint so that the repository is accessible throughout the network. Continue to the next screen.
Create the path to the repository, which if you followed the instructions when configuring the file sharing settings for the server, will be under Public. The syntax for this field will look similar to this:
Afp://ServerName.com/Public
Enter the username and password for the deployment admin account and continue on to the next screen.
Unless you require email notification, you can skip past this screen.
The network security window; ensure that com.deploystudio.server is highlighted from the drop down menu. Select the appropriate interface for your setup and leave the port number as the default 60443. Verify that the Reject Unkown computers box is UNCHECKED. Continue to the next screen.
This is the user group window. If you require more stringent security settings, you can only allow access to specific user groups. These groups must be created in the Workgroup manager although users can be added to the groups at any time. Continue to next screen.
This screen allows you to enable or disable Multicast. Even if your network is incapable of working with multicast, it is not advised to disable it at this point as you will not be able to change it at a later date. It’s best practice to leave this enabled. Continue to update the server settings and hit OK when the process is complete. The server has been configured, next up is the creation of the netboot image.
Creating a netboot image
Launch the DeployStudio Assistant and select Create a DeployStudio Netboot set from the menu. Read the service information window and continue to the next screen.
Netboot Creation Window: Name the image
Give the system a sensible name, UID, Language and time server. Continue to the next screen.
This windows allows you to specify a particular server to connect to as priority, along with an alternative – if you were to have a master and replicator DS server. The syntax this takes is as follows:
https://ServerName.com:60443
The authentication screen allows you to enter a default username and password for logging into the netboot image. Be warned that entering a default user and filling in the password field means that any time the netboot image is loaded, these fields will be pre-populated and the operator will be able to launch which ever workflows they wish.
To get around this, you can simply disable the netboot service from the Server Admin tool. This is the advised approach regardless of pre-populating the user and password fields.
There is also an option here for a VNC username and password. This is here so that admins can remotely connect to the netbooted client and view the status of the deployment.
Once you have made your choices here, move on to the next screen.
The options window allows you to select what extras you want to include into the netboot image. Some package installers require the use of Python or Ruby so it may be an idea to include those in your image. Make your choices and move to the final screen.
It’s important to leave the destination location as the default:
/Library/NetBoot/NetBootSP0 <– that’s SP zero, not an O.
If the location doesn’t already exist it will be created. Click continue and that’s the netboot image complete.
##Important: Once the netboot image is ready you will need to start the netboot service from the server admin. This process was described in the previous section; Configuring the server pre DeployStudio.##
An overview of the DeployStudio Admin tool
The DS Admin tool allows us to create the workflows, which we will use to deploy Lion, packages, scripts files and folders, etc. to our client machines. Down the left hand side of the utility we have various tabs.
Clicking on Activity will display currently running workflows, their progress and client name.
The Computers tab shows the known computers to the DS, this list can be pre-populated by use of serial number or MAC address. The advantage of this being that we can assign computer names, IP addresses and other things to specific MAC addresses/serial numbers.
The workflows tab will be the most frequented tab of the utility. This is where we can create our own workflows, as depicted in the below screenshot:
An Overview of the DeployStudio Admin tool
The featured workflow in the screenshot is fairly complex, partitioning the disk, installing the OS, copying files, installing software, and finally running the software update utility when the system boots in for the first time. We will look more at building workflows in a later section.
The Masters tab lists the captured and ready to be rolled out Lion images.
The Packages tab details all of the packages that have been uploaded to the DS repository. It also lists any package sets that will install multiple packages in the one shot.
The final tab, Scripts, displays all of the stored scripts in the DS repository. It also allows for you to create your own shell scripts for deployment.
Workflows
The master workflow that we will be using contains a partitioning step, which will ready the drive for the installation of Lion and Windows 7. It is important that Windows 7 is installed last.
By default there are a couple of workflows already created. Some of these we will use; some of them can be removed from the list. The ‘Create a master from a volume’ is the workflow used to capture a Lion image on the target machine, which will be used as the master base image of which will be installed on all Macs. This is ready to go right out of the box and requires no adjusting.
The recovery workflow is a custom one I made that will reinstall a working thin Lion image. Most useful when testing software installs and needing a fresh image without any software pre installed.
To create a new workflow, have the workflows tab selected in the left pane and then click on the plus symbol in the middle pane at the bottom of the window.
To add new tasks to the workflow, click on the plus sign next to the text ‘drag tasks here’. This action will open a third pane to the right of the central pane. This pane shows all of the tasks that can be added to a workflow. Some examples of these tasks would be install a package, restore an image, create an image, partition a disk and so on.
The documentation for DS is pretty extensive so I won’t go into too much depth here, we’ll just look at a few of the main tasks that can be incorporated into a workflow.
Partition
As the title suggests, this task will partition the drive. You have the choice of customizing the partition yourself but the task comes with some default options. For example, you can format the drive for a single Mac OS installation or you can set it up for a dual installation of Mac and Windows or even a triple boot Mac, Windows and Linux!
Adding the Partition task to a workflow
When choosing a dual or triple boot partition using the sliders, you can easily adjust the size of each partition. Mousing over the partition will display a pencil icon in the upper right corner of the partition which allows you to edit the title of said partition.
From the screenshot above you will note a couple of other things. The first is that you have the option of choosing the target disk for this action to be performed on. To fully automate the deployment process, it can be a good idea to change this from ‘user selected’ to first available disk.
The second item to take note of is the check box at the bottom of the window labeled ‘Automate’. Checking this box will automate this step and require no interaction from the user.
Restore
This task restores an image to a partition. As you’ll see below, there are many options for configuring on this task.
Adding the Restore task to a workflow
From now on, the target volume can be set to ‘previous task target’. We need to select the type of file system the image was created in, usually HFS and then obviously select the image to be used. These images, or masters as DS refers to them as, are the images that would be captured using the default ‘Create a master from a volume’ workflow.
The rest of the options are pretty self-explanatory. We can change the name of the volume if we want to, but seeing as we named it something sensible in the previous Partition task there is no need to rename. The only option I changed here was to uncheck the recovery partition checkbox, as we are unable to work with multicasting.
Ensure that the automate checkbox is ticked and move on to the next task.
Hostname Form
This task is optional. It allows you to name the machine. If you have prepopulated the computers tab within DS with either the serial number or MAC addresses of the Macs then when this task is displayed, the name given in the Computer tab will already appear as default name.
Unfortunately you are unable to automate this task.
Package Install
As the name suggests, this task is for the installation of software packages. You can either install singular packages or use a package set to install multiple items.
This task is fairly straightforward. As with every other task, select the drive you wish to install the software to and then select the software item or the software set to be deployed. As you can see from the screenshot, you have the usual check box for automate, and a second one for postponing the item/set until the first boot. Selecting this check box will copy the installers onto a temp directory on the local disk and will invoke them upon the next reboot. You also have a check box to ignore failures, this can be useful if an item installs but has some loss of functionality due to lack of Internet connection or user interaction.
Adding a Package to the workflow
To create a package set select the Packages item from the left hand windowpane and click the plus sign from the bottom of the pane.
The packages tab from the DS Admin tool
You can now add packages to these sets by dragging items from the main packages tab and dropping them on the name of the set you wish to add them too. We’ll look at how to add software to the DS server in the section titled Repositories.
Repositories
By default, the DS repositories are stored in /Shared Items/Public/DeployStudio/.
The repository directory
This is where we need to place items that will be used within the deployment. There are a few folders to take note of; Packages, Files and Scripts. These all link back to the DS Admin tool we just looked at. To import software we need to have the .pkg/.mpkg’s stored in the packages folder. Similarly, if we want to use the scripts or the copy files tasks in our workflow, we’d need to have the files and scripts located in the appropriate folders.
Installing Windows 7
We will be using MDT 2012 to install Windows 7. I have created a specific Windows to mac Task Sequence which runs much the same as any other TS. The TS runs a diskpart command which tells setup to install to the third partition as Mac uses the first. The only other change to note here is that the Bootcamp drivers could not be deployed conventionally as Out-of-the-box drivers, but were instead deployed as an application.
Apart from these two modifications, the roll out is the same as any other.
References
DeployStudio has a very detailed guide that includes walkthroughs. It can be found here:
http://web.me.com/driley/web/deploystudio_files/DeployStudio_Guide.pdf
digitlive 