Configure routers for BSDP OS deployment

Apple publishes this spares document http://support.apple.com/kb/HT4187 but I am going to try and convince you not to do this.

Unless you are looking to employ a self-service model in which the end user is imaging her machine, there really is no need to go through all this effort to provide NetInstall across the entire organization. And if self-service is the goal, then thin imaging is probably a better approach.

That being said, in most environments, the imaging process is performed once and then the machine is delivered to the end user. Frequent re-imaging, in my experience, is rare. Yes, there are the test labs were you need to reset to a default state but I've found Deep Freeze to be a better (and quicker) solution.

Next is the threat of accidental imaging. If you are providing access to the imaging server at all times, it is possible that an end user may accidentally boot into the imaging solution and there is a chance of complete data loss. Yes, this is rare, but I actually had a user leave a binder on a keyboard once and the machine booted up to the NetInstall window. Luckily, we did not configure imaging for unattended mode so no damage was done. But yes, I did panic.

So I would suggest leaving the NetInstall isolated to the subnet that the IT lab is in and where the server exists. After all, most often, the imaging process is handled by IT. If this is your model, then image in the lab and then deliver to the end user. Now you avoid unnecessary modification to the switching infrastructure for a process that should not be used that frequently.

R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

We do annual re-imaging of three student labs in a high school. Unlike Strontium90 we do find it very useful to re image student computers on demand. We have co-ordinated with our network folk to enable BSDP on all LAN segments at the school. It is a hassle for them to configure switches to do this. In Cisco they have to designate our Mac server as a DHCP helper. We are currently attempting to migrate from monolithic Apple imaging to thin imaging with the Casper product. But so far we are NOT finding thin imaging to be as robust. When not actively imaging we just turn off the service to prevent accidents..

piperspace wrote:

We are currently attempting to migrate from monolithic Apple imaging to thin imaging with the Casper product. But so far we are NOT finding thin imaging to be as robust. When not actively imaging we just turn off the service to prevent accidents..

Some admins use an Rsync approach overnight to restore clients to a known config, I believe Apple Stores use an overnight imaging process to restore demo machines.

With regards to thin imaging, I used to use monolithic aka. 'fat' imaging but have switched to thin imaging. I had a look at Casper but I find DeployStudio to be the best solution for imaging, other peoples opinions may differ. The approach I currently follow is as follows.

1. Create a virgin never booted image i.e. 'thin' image using either InstaDMG or AutoDMG
2. Load resulting image on to DeployStudio repository
3. Define a workflow in DeploStudio that - restores the thin image, copies preferences to User Template folder, installs local admin account, enrolls to Profile Manager, binds to Open Directory, installs packages, writes my choice of system-wide preferences, runs software update, etc., in otherwords traditional imaging workflow tasks

This works fine for me and means the resulting image is 'installed' specific to the model of Mac being imaged. No more cases of network interfaces having the wrong name etc.

There is one 'gotcha', DeployStudio itself can only auto-rename 'by-host' preference files if those files are already in the image being restored, because a 'thin' image does not have these I have to copy those preference files to the client after the image has been restored, I therefore have had to write my own script to do this renaming after I copy the files. In recognition of this issue the DeployStudio team have announced that they are going to add a new workflow command that will let you rename such files after imaging but during the workflow and hence it will no longer be necessary to use your own script to do this.

With regards to preventing undesired imaging restores, this is going to be a trade-off, if you do not store the DeployStudio runtime credentials in the netboot image, or use deliberately incorrect ones, then only someone who knows the correct credentials and manually enters them will be able to do a restore. However this would prevent a totally automated solution, it is possible for example to set machines to auto-reboot at a specific time and auto-run a restore - like presumably Apple Stores do overnight. Or as already suggested you could set your imaging server to only be online at specific times, hypothetically you could have a script to turn on DeployStudio late at night and to turn it back off in the early morning.

@ARQ-iTech

DeployStudio uses the same underlying NetBoot technology and therefore the answer is yes it would use BSDP.

With regards to a geographically dispersed requirement, DeployStudio supports a master/slave configuration. You would have a master setup at HQ where you create all the settings etc, and it would auto-sync to the slaves which act as local points from which clients can image themselves. You could setup DeployStudio slave Mac minis and ship them out to remote locations.

Here is the best reference I have seen on BSDP.

http://www.afp548.com/mactips/

Good luck with your worldwide deployment that must be done yesterday.