Everything you need to know to get started and a little bit more….
Most users will never need to worry about deploying an image to more than one or two computers, but in some scenarios it will be necessary. There are many tools available to facilitate this but here I will discuss the ones that I use regularly.
There is some depth to large scale dual boot deployments so I will try to keep things as simple as possible here whilst also providing some useful links if you wish to learn more about the tools that are available.
The first thing that you will need is a dedicated server to host and deploy your images from; I currently use a 2011 Mac Mini server with OSX Snow Leopard Server installed.
The software I use to achieve my dual boot deployments is DeployStudio. Before discovering this software I was using a combination of Carbon Copy Cloner and WinClone to manually deploy my images to the computers I look after. At first I was only looking after 20 computers so the extra time it took to work manually didn’t seem that big a deal. Now I am looking after around 80 Macs in total so being able to manage my images centrally and deploy over the network is essential to my productivity.
DeployStudio is freeware and won’t cost you a penny, however if you end up using and appreciating the software they do take donations via the website above. The key features of this software are:
The website provides a very comprehensive guide that is very easy to follow and will get you up and running within a few hours. Everything is well explained and there is also a support forum where users can share ideas and get help with any problems. So far any problem I have come across has been solved by discussion with other users on the forums.
Please visit the website listed above and download the documentation. It is essential to read if you are going to make use of the software and is much more effective that me writing up a basic user guide for it here.
DeployStudio will allow you to deploy single, dual and triple boot systems over your network. The built in tools make this process very easy compared to any other method that is available currently. The software has a great GUI that lets you customise your deployment in a variety of ways. There are a few built-in “workflows” that will let you immediately create or deploy and image to a networked computer. Within this GUI you can also create your own workflows.
The workflows I currently use are:
Once I have created my images and readied them for deployment, I then create my dual boot restoration workflow. This will partition the destination drive and deploy both images to the target computer. It is also possible to bundle more functions into your workflow such as automatically binding to a domain or mapping network drives.
The software works best when the server is on the same subnet as the target computer or computers. If you are deploying across subnets like I have to you will need to use DeployStudio to create bootable USB drives. Once you boot to this drive on the target computer it will connect with the deployment server and you will be able to work across subnets. I have had some problems with this method- a combination of the network I am working on and unreliable USB drives. If you can, it is very much worthwhile imaging on the same subnet as your server; the speed is dramatically faster too.
Binding OSX to Active Directory:
When I first started deploying dual boot Macs I had never had to bind OSX to a Windows domain. Here are the basic steps of binding to Active Directory in OSX:
Apple Logo > System Preferences > Accounts > Login Options > Open Directory Utility
Unlock > Tick Active Directory > Click the Pencil
Enter your directory domain e.g. “domain.name.com” > Enter the computer name that exists in Active Directory > Click Bind
Enter your username and password > Fill in the “Computer OU” section with the correct OU information from your Active Directory > Click OK.
If you see a pop-up telling you that the computer already exists in AD, click on OK and join that entry in the AD. You should have already created your groups and computers in AD previous to starting this binding task.
Creating a user template:
It is usually beneficial to create a user template before deployment; this means that all users will have a unified desktop and dock. To do this you will first need to enable the root user on the Mac you are creating your image on. To do this:
Apple Logo > System Preferences > Accounts > Login Options > Open Directory Utility > Unlock > Edit > Enable Root User > you will be prompted to create a password for this user.
You can customise your user template to your own specifications, usually I will at least make sure that all users have the same dock showing all available applications and also copy over any application specific settings that need to be enabled for every user using the computer.
Below is a brief guide on how to give all users the same dock, from this you should be able to work out how to apply other settings that suit your own needs to the user template.
Firstly you will have to set the dock to your required specification in your favoured user account, for simplicity I just use the “admin” account that I normally use. Now log out of that account and log in as “root” using the password you set when enabling the root user.
Open a new finder window and navigate to Macintosh HD > Users > Admin > Library > Preferences, once you have this folder open you need to copy the following file: com.apple.dock.plist
Now you need to paste this file to the user template, to do this open the following folder from Macintosh HD: System > Library > User Template > English.lproj > Library > Preferences, now paste the copied file from the previous step.
Now that this file is in place, any new user that logs in to the computer from now on will have the same dock settings as you created in the admin profile. Try this now by logging back in to admin and creating a new user, when you log in the dock should be the same as the one you created earlier.
I work in an environment where the overall network is centrally managed, thus I have no way to upgrade domain controllers or change any of the current architecture. Currently we still use Windows Server 2003 which is really showing its age now.
There are some common problems I have come across working in the environment mentioned above, some of them I have worked around and some seem to just be quirks that we have to live with.
This is a symptom of being joined to a domain server still running 2003 software. It can be worked around if you know the same user is going to log on to the computer each day. To do this you can simply add a script to run on logon and map the drive for the user. If this is a multi-user environment then the best thing to do is make the users aware of how to access the home network drive manually should they need to use it.
This problem leads to your being unable to log in to OSX due to the system time being out of sync with the domain controller. The way I got around this was with a small registry hack in Windows to allow Windows to communicate with the domain controller even when the time is out of sync. Once this is done you can tell windows to ignore daylight savings time, this will then let the time stay correct in OSX. Unfortunately the drawback of this is that for half the year your Windows system clock will be one hour behind.
I have been unable to find a permanent solution to this problem but think that a newer domain controller beyond 2003 should help overcome this.
I will consistently get a BSOD when both OS are joined to the domain and the Macintosh HD partition remains viewable in Windows. My theory is that this is due to something running at domain level trying to use all available drives (Macintosh HD is write protected but still visible) or Windows trying to spread the page file over all available drives. In either scenario the fact that Macintosh HD is visible causes the computer to think it can write to it, when it tries and fails the BSOD happens.
To resolve this is very simple, in Windows go to: Windows Button > right click Computer > Manage > Disk Management > Right click on the HFS partition > Change drive letter and paths > Select the Drive Letter > Remove.
These are the three most consistent problems I see happening in my current work environment, if you have further information on any of these or if you have encountered other problems then please let me know.
The final problem I have faced is not a software problem, it’s a user problem. Apple peripherals will go missing! Every day here we seem to lose another keyboard or mouse. The wireless peripherals fly out the door since you can’t secure them, the wired ones take a bit longer but the short cables are pretty hard to secure too. This is no doubt due to the high value of Apple branded peripherals. My only solution to this problem was to bulk buy generic low cost/quality keyboards and mice; once enough go missing the whole lab is replaced with these and the thieves only have themselves to blame for now being stuck with generic brand peripherals.