Home » 2012 » May

Archive for May, 2012

Using DeployStudio in a Dual Platform Environment

Posted 2012/05/24 By mikep345678

(Another post copied from someone else [wiki.sdsm.k12.wi.us/users/tmetallo/weblog/49560/Using_DeployStudio_in_a_Dual_Platform_Environment.html  perhaps?]– but the original doesn’t seem to be around any more, so this is from Google’s cache…)

Using DeployStudio in a Dual Platform Environment

Summary of our Environment

  • We are running a single, Dual quad core 2.8 GHz, XServer with OS 10.6.6 and 8 GB RAM.
  • We are running the standard NetBoot service on our Mac server.
  • We are running DeployStudio 1.0rc125 (100127).
  • We have roughly 240 OS 10.6.4 Macs (approx. 100 dual boot) and 900 Windows XP PCs.
  • We have approx. 3600 user accounts (staff and students)
  • We have a Windows Server 2003 Active Directory and use Windows LDAP services for both Macs and PCs.
  • All staff and student home directories are on stored on our SAN through Windows Servers.
  • DHCP and DNS are both handled by our 2008 Domain Controllers.
  • We had used RIS and WDS for system imaging until this the fall of 2009 when we decided to standardize to DeployStudio.

Major Points:

Both Mac and Windows PC computer name and MAC Address must be entered into OD through WorkGroup Manager. This is necessary for the Windows PC because the automation process below will look at the OD database first.

A major point to know is you will need to add a CNAME record into DNS for theDeployStudio Server. This is important because the PCs will ONLY look for the server by this name. IT MUST BE – deploystudiopcserver and the alias will point to the XServe DNS name you are using for DeployStudio. This is where I stumbled initially so I wanted to emphasize it.

I added options 66 and 67 to our DHCP server main scope. Option 66 will be thefull DNS name of your XServer, and option 67 will be the PXE boot file for DeployStudio which is pxelinux/pxelinux.0.

It is very important to add an IP Helper-Address to the VLAN(S) that you will be imaging on. This helps the workstations see the DeployStudio Server.

In our environment we have one image repository that contains all of our Mac and PC images. You will need to create a few shared folders. NetBootClients0, NetbootSP0, and Images. You will also have to create a local account for DeployStudio service. This account need admin ACL full control privlege of the Images share point. Admin will only need access to the NetBootSP0, and NetBootClients0 share points.

BootCamp and BootPicker are free downloads and needs to be added to the Mac image if you are creating a dual boot image.


So how is it done? Let’s start at the beginning!

In the beginning it was dark… No, that’s to far back. Let’s start this at creating a repository, loading DeployStudio Server, and creating a NetBoot set. This is vital to getting the clients to netboot, and in the PC world PXE boot.

Choosing the DeployStudio Server

Your DeployStudio server does not have to be a super, oober-geek, mega-machine. We have a single XServer (outlined above) which is our Wiki, Blog, Podcast Producer, and DeployStudio server. We setup a volume with an Images share point. I will cover the share point and permissions a little later. For now just know you will need a place to put your images, both Mac and Windows. Our average images size is roughly 12 GB for a Mac image (with apps) and 7 GB for a Windows image (no apps). With these image sizes you chew through drive space on your repository server pretty fast.

This is what DeployStudio recommends for server:

  1. •Mac OS X 10.4.11 to 10.6.3
    (Mac OS X server is required for Netboot deployments)
  2. •PXE 2.0 compatible Ethernet cards in your PCs to allow network imaging.
There is some VERY helpful information on the DeployStudio site in their Forums and their Tips page. Any questions or issues that I have had with DeployStudio (and there has not been many knock on wood) I have resolved using the links above. Kudos to the users who posted information here.

Installing DeployStudio Server

I’m not going to spend much time on the actual install. That information can be found here.

What I would like to cover is some of the key points for a successful install.




  • Make sure the DNS name of your server is registered and working in DNS. Use this command in terminal to check the server host name: sudo changeip -checkhostname. Make sure Current HostName and DNS HostName match. If they do not check your DNS cname entry on your DNS server.
  • You need to download and install that last release of DeployStudio on your server.
  • You will need to be logged on as an admin for the install.
  • You will need to create a local user account on the server for the DeployStudio service.
  • Install DeployStudio to the default location.
  • Run DeployStudio Assistant to set to setup the DeployStudio Server.
  • When asked to enter a URL use IP addess format not the fully qualified or DNS name. This will make for a more reliable connection.
  • If SSL connection was chosen during configuration the server URL path will be HTTPS and not HTTP, and the port will be 60443. Here is an example:https://192.168.1.xxx:60443, and the log on account will be the DeployStudio account you setup earlier.


Installing DeployStudio PC Server





  1. Start DeployStudio Assistant.
  2. When prompted for the DeployStudioPC Server enter the same IP address you used for the DeployStudio server (https://192.168.1.xxx:60443).
  3. The log in will be the same account you used above for DeployStudio.
  4. The Repository URL will be the full path to your Images share point. The cifs prefix allows the PC client to see the Image share point on the Mac server. Example: cifs//<server_ip_address>/images.
  5. The cifs authentication will be the same account you used above.
  6. Save your changes.
  7. We are running DHCP on a Windows Server so we added options 66 and 67 to our DHCP server main scope. Option 66 will be the full DNS name of your XServer, and option 67 will be the PXE boot file for DeployStudio which ispxelinux/pxelinux.0.
  8. DeployStudio PC PXE boot clients must see a DNS entry for the DeployStudio server with the DNS name of deploystudiopcserver, and the alias will point to the XServe DNS name you are using for DeployStudio. This is where I stumbled initially so I wanted to emphasize it.

Something to note – The DeployStudio PC PXE client is a basic Linux PXE client. Nothing cute or graphical about it, but what it lacks in graphics it more than makes up for in performance. It is has the potential of being very fast, depending on your network of course.







Creating a NetBoot Set

Use the newest piece of Mac hardware you have to do this. It SHOULD be backward compatible with your older hardware. You will probably have to create a seperate NetBoot set for your Intel Macs and your Power PC Macs.


  1. Start DeployStudio Assistant.
  2. Choose create a DeployStudio NetBoot set.
  3. The System name is a descriptive name. I usually put the DeployStudio release number and Mac OS software version somewhere in this name. Example: DS.1.0.RC17.OS10.6.2
  4. The Unique identified has to be unique per build. The identifiers start at 101 and go up to 65535. I just make sure I add one to the last identifier I used last. Keep it simple.
  5. We increased the time out to 300 seconds (5 minutes) to make sure the systems don’t time out do to latency.
    A .nbi file will be created and should be around 2 GB in size.
  6. Copy this new .nbi file from the location you saved it to a folder on the DeployStudio server called NetBootSP0. This folder should have been created when NetBoot was setup.



Adding the IP Helper-Address to Your Network

We are very fortunate to have a network infrastructure made up of all Cisco networking equipment. Since we have multipe VLANS it was neccessary to add a IP Helper-Address to the VLAN config on our managed switches. Here is some information on doing that.

  • You will have to telnet into your switch and enter the enable password, enter config mode, and add the line to your vlan ip helper-address xxx.xxx.xxx.xxx
  • Save your config.

So Let’s Connect Some Clients!

The Mac clients are very easy to connect to DeployStudio. Simply boot hold down the “N” key while booting and the workstation will NetBoot to the NetBoot Server and automatically connect to DeployStudio.







Hold the “N” keydown and a grey globe will apprear on the screen. This tells you that NetBoot has been initialized.







Hold down “N” until your see the Apple Logo on top of a smaller spinning globe. You can let go of the “N” key at this point and the system should be booted to the DeployStudio Runtime screen shortly.





Somthing to note: You can run DiskUtility from with in the DeployStudio Runtime screen. This is very helpful for modifying system partitions. I have also used DU to create a BootCamp partition for Windows with out touching the master Mac partition. Just dedicate some of free space on the Mac partition to use for the Windows partition.






The Windows clients are also very easy to connect. Make sure PXE booting is enabled for your network card. For intergrated NICs this is done in BIOS. Once you know PXE booting is enabled boot the computers and press the F12 key immediately after POST. This will give you the boot options menu on most systems. Choose PXE boot and the system should automatically boot to the DeployStudio server.





The DeployStudio boot is basically a Linux PXE boot file, after that you should see the following:


DeployStudio PC

The DeployStudioTeam

Please press:

– ‘0’ to boot into the local disk(default)

– ‘1’ to boot into maintenance mode

To enter the actual DeployStudio program you will have to choose option 1, or maintenance mode. At this point the Linux PE environment loads (a lot of text scrolls off the screen which is mainly drivers), and then VIOLA, you be brought to the DeployStudio Main Menu. See what I told you, not cute at all, except for the little creatures at the top of the Linux PE screen, and, I have don’t have any idea what they are either.




The DeployStudio PC Main Menu

[1] Restore Boot (default) – this is used to pull a new fresh image down from the server.

[2] Restore Boot (advanced) – This is used if you would like to choose more than one partition

[3] Image Host – This is used to create new master image for the repository on the DeployStudio server.

[4] Restart Host – This is used to (know stay with me on this..) Restart the host!

In my experience you will spend most of you time using option 1, or option 3.

Option 1 will take you to the master image list. This is a list of the PC images found in the /images/masters/PC folder on the repository volume of the DeployStudio Server. Simply arrow down to the image you would like to use and press enter. You will be asked to enter a CAPITAL (upper case) Y to start the imaging process. Keep in mind your are in a Linux PE and it is case sensitive.

Once the imaging process starts a progress screen comes up to show you how the imaging is going.




Preparing the Master Windows Workstation

This process is not major rocket science. We have been prepping and deploying Windows images for decades now. The trick comes in with automating the process. In our case we use key items, Windows Sysprep, and two .vbs scripts that run after the Sysprep answer file runs, actually the last line in the sysprep.inf file starts the first .vbs script. Here is the we use.

  1. Take your model workstation and delete all the local partitions. Use FDISK or something similiar.
  2. Create a new system partition only 50 GB or so. After imaging the remaining disk will show as free space. This allows your older, smaller drives to play along.
  3. Next load Windows fresh
  4. Load all device drivers
  5. Load all Windows Updates
  6. Make any environment modifications. If you wanted the changes to apply to all new profiles create a new local admin profile and make all the system changes you need to, log on as local admin and copy this new profile over the default user profile. This will become the new default user profile and all first time users who log on will get this profile.
  7. Use Windows Sysprep to prepare the workstation for imaging. See detail below.
  8. Now this is where is gets a bit tricky. We worked with software engineer (no, not Choo-Choo Charlie even though he was an engineer) to write two custom .vbs scripts. Here is an exmple of each and what they do. I can’t express enough how vital these are and how much they changed how we image.

Sysprep with a Twist

Use Microsoft Sysprep for Windows XP

  1. Make sure your computer is a member of a workgroup and not a member of the domain.
  2. Type “control userpasswords2” in the Run dialog box. This will bring up the User Accounts properties menu. Disable CTRL+ALT+Delete at log on temporarily. Let the system log onto the desktop as admin to allow the .vbs scripts below to run (Advanced Tab at the top).
  3. Use Sysprep Manager to have the workstation log on as administrator once and run firstboot.vbs file from C:\Windows
  4. Choose “Use Mini Setup” and “Reseal” in Sysprep.

Here is a good example of our sysprep.inf



Sysprep.Inf Contents – Could be copied and pasted













Firstboot VBS – (firstboot.vbs) Must be placed on root of Windows folder.

Can be copied and pasted into a text document and saved as firstboot.vbs


‘ Sysprep firstboot script
‘ Searches AD for a computer account with the current MAC address
‘ If found, rename the computer appropriately, then reboot and bind to AD
‘ If not found, bind to AD with the current name
‘ The machine must be set to autologin for this to work
On Error Resume Next

‘ AD info
domain = “your_domain”
user = “your_admin”
passwd = “your_password”
ou = “ou=Your Computers,dc=your,dc=school,dc=edu”

‘ OD info
odserver = “your_od_server”
odsearchbase = “cn=computers,dc=od_server,dc=dc=your,dc=school,dc=edu”


Set wmi = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2”)
Set shell = Wscript.CreateObject(“Wscript.Shell”)
‘ Get MAC Address
Set nics = wmi.ExecQuery(“Select * from Win32_NetworkAdapterConfiguration Where IPEnabled = True”)

For Each nic in nics

‘ This line may need to be adjusted to filter out unwanted NICs
‘ such as wireless adapters, etc. The names will vary based
‘ on the hardware & chipset.
If Not Left(nic.Description, 9) = “Bluetooth” and not Left(nic.Description, 16) = “Broadcom 802.11n” Then
macaddr = LCase(nic.MACAddress)
End If
‘ Get name from OD
Set conn = CreateObject(“ADODB.Connection”)
Set cmd = CreateObject(“ADODB.Command”)
conn.Provider = “ADsDSOObject”
conn.Open “Active Directory Provider”
Set cmd.ActiveConnection = conn
cmd.Properties(“Page Size”) = 1000
cmd.Properties(“Searchscope”) = ADS_SCOPE_SUBTREE

cmd.CommandText = “SELECT cn FROM ‘LDAP://” & odserver & “/” & odsearchbase & “‘ WHERE macAddress='” & macaddr & “‘”
Set rs = cmd.Execute

cn = “”
Do Until rs.EOF
cnarr = rs.Fields(0).Value
cn = cnarr(0)
cn = Replace(cn, “mac”, “pc”, 1, 1)
‘ Rename, bind, & reboot
For Each machine in wmi.InstancesOf(“Win32_ComputerSystem”)
If Not cn = “” Then
res = shell.RegWrite(“HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\sysprep”, “c:\windows\secondboot.vbs”, “REG_SZ”)
shell.Run “shutdown.exe /r /t 0”
res = machine.JoinDomainOrWorkgroup(domain, passwd, domain & “\” & user, NULL, JOIN_DOMAIN+ACCT_CREATE)
shell.Run “shutdown.exe /r /t 0”
End If

Secondboot VBS Must be placed on root of Windows folder. (secondboot.vbs)

Can be copied and pasted into a text document and saved as secondboot.vbs

‘ Sysprep secondboot script
‘ Binds to AD after renaming the machine (in firstboot.vbs)
On Error Resume Next

‘ AD info
domain = “your_domain”
user = “your_admin”
passwd = “your_password”
ou = “ou=Managed Computers,dc=your,dc=school,dc=edu”


Set wmi = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2”)
Set shell = Wscript.CreateObject(“Wscript.Shell”)

‘ Wait 30 seconds for the network to come online

‘ Bind, remove the autologin registry key, & reboot
For Each machine in wmi.InstancesOf(“Win32_ComputerSystem”)
res = machine.JoinDomainOrWorkgroup(domain, passwd, domain & “\” & user, NULL, JOIN_DOMAIN+ACCT_CREATE)
shell.RegDelete(“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon”)
shell.Run “shutdown.exe /r /t 0”

Here are the files in .txt format. Save them to C:\Windows folder and change the extension to .vbs , the last line of the Sysprep.inf file will look for them there.



In a Nutshell

So here is the entire process in a nutshell.

Setup a DeployStudio Server for system imaging and image repository

Setup NetBoot, DHCP, and PXE booting

Add a IP Help-Address that points to your DeployStudio Server to your VLAN

Add a DNS entry for the DeployStudio Server and a CNAME entry for deploystudiopcserver

Load BootPicker on your Mac image

Create a master image for both Mac and Windows

[MACENTERPRISE] Managing Chrome: The Rough Guide

Posted 2012/05/19 By mikep345678

[Editor’s note: This isn’t mine– total props to Nick McSpadden, who posted it to the MacEnterprise mailing list! Thanks, Nick!]



This is a sort of follow-up to my guide on managing Firefox, this time focusing on managing Google Chrome.  I’m working on current Chrome version 18 (which just today got updated to 19), and I don’t know for sure how far back this will work, but I think anything higher than v16 properly supports the MCX policies.

The good news about Google Chrome is that it supports MCX!  Unlike Firefox, which requires specific and somewhat obtuse procedures for managing it (including depending upon an add-on that is independently maintained by a hard working individual), the most important parts of Chrome management can be done with already-existing MCX controls.

First let me start off with a link to a very helpful set of information: http://www.chromium.org/administrators
That link covers just about everything you’ll need to know about Chrome policies and management, though some of it is buried.  I discovered (much to my chagrin) that the Chromium site is much more thoroughly documented that Google’s official “Chrome for Administrators” site.

Some important notes about Chrome MCX: all Chrome policies are required to be set to “Always.”  They’re like Profiles from Profile Managers – there’s no middle ground.  Even if you set it to “Once” or “Often,” Chrome will treat the policy as permanent and prevent the user from changing it.  Any policy being managed by MCX in Chrome will be grayed out to user interaction (and there will be a message in the “Options” window about how some settings are being managed by the administrator).  So you’re going to have to “Always” manage these settings whether you like it or not.

The good news is, there’s an alternative, the Master Preferences.  The downside is that the Master Preferences is a “once” option, and doesn’t prevent the user from changing it.  It’s a good way to provide default settings without restricting the users’ ability to personalize it later on.  More on that later.

So, following the Mac Quick Start Guide: (http://www.chromium.org/administrators/mac-quick-start)

1) Inside a fresh copy of Google Chrome is a nice fresh copy of the manifest.  Access it here:
/Applications/Google\ Chrome.app/Contents/Resources/com.google.Chrome.manifest/Contents/Resources/com.google.Chrome.manifest
2) Load this manifest into WGM
3) Here’s the full description of all policies in the Chrome manifest: http://www.chromium.org/administrators/policy-list-3
4) There are some particularly important settings that will be relevant to most.  Here’s what my plist looks like for a lab computer (no individual users):
AutoFillEnabled – False (disables the ability to store autofill information)
BookmarkBarEnabled – True (forces the bookmark bar to show up on all tabs, all the time)
HideWebStorePromo – True (prevents the web store from trying to sell you things, but does not disable the web store)
HomePageIsNewTabPage – False (if you don’t disable this, the homepage will be set to the default Chrome tab page, which opens up the “Most Visited/Apps” switcher)
HomepageLocation – URL (even if you set this, if HomePageIsNewTabPage is set to true, this URL gets ignored)
PasswordManagerEnabled – False (for lab machines, I don’t want them saving passwords, intentionally or accidentally)
RestoreOnStartup – 0 (0 forces it to open the homepage URL on startup)
SyncDisabled – True (same reason as Password Manager – I don’t want these personalized at any time).

That gives you a basic setup for most things you’ll need to worry about.  If you deploy this, you’ll notice a few problems, though.  The first time you launch Chrome, it gives you an undismissable dialogue box asking you if you want to make Chrome the default or submit other info.  That’s bad.  The above manifest also provides no way to control the auto update mechanism, if that’s something you want to do.

This is where the Master Preferences file comes in – http://www.chromium.org/administrators/configuring-other-preferences.  By specifying a Master Preferences file, we can load up default preferences for user accounts *when they are created.*  Note that the Master Preferences file has absolutely no effect on already existing Chrome profiles – only upon new-user generation does Chrome load this file.  It literally copies and pastes the settings in here into the appropriate places in ~/Library/Application Support/Google/Chrome/Default/Preferences.

On Mac OS X, the Master Preferences file must be located at:
/Library/Google/Google Chrome Master Preferences
(yes, really – the file must be named “Google Chrome Master Preferences” with no extension), and must obviously be readable by any user who can launch Chrome (i.e. use 644 permissions).

The Master Preferences file is a JSON file that can contain any of the preferences normally used by Chrome.  If you want the full list of all possible preferences, load up a default Chrome profile and take a look at the Preferences file I mentioned at the path above.  It has everything you’d ever want (and a lot of stuff you probably don’t).  To save you some time, here are some important ones you’ll want to use specifically for deploying Chrome:

“homepage_is_newtabpage” : false,
“browser” : {
“show_home_button” : true,
“check_default_browser” : false
“bookmark_bar” : {
“show_on_all_tabs” : true
“distribution” : {
“skip_first_run_ui” : true,
“show_welcome_page” : false,
“import_bookmarks” : false,
“import_bookmarks_from_file” : “/Library/Google/chrome_bookmarks.html”,
“make_chrome_default” : false
“sync_promo” : {
“user_skipped” : true

The chromium.org page I linked above goes into a bit more detail about this, but I want to give a quick note about the interaction between preferences and MCX.  MCX always wins.  Any policy managed by the MCX and also specified in the Master Prefs will always go the MCX policy.  In the example above, if I had set “homepage_is_newtabpage” to true, it would still be false because MCX sets it to false, and that policy is always enforced.

The really import part is the “distribution” section.  “skip_first_run_ui” will get rid of that annoying dialog box that comes up when you first launch Chrome.  The “import_bookmarks” option asks the user through a UI dialog box if the user wishes to import bookmarks from another browser.  Obviously, we want to suppress that.  There’s an option instead to silently import bookmarks from an HTML file.  You can create this bookmarks HTML file by setting up the bookmarks the way you want, and then Exporting them in the Bookmark Manager.  I place that bookmarks file in /Library/Google/ because it’s already used, but you can put it anywhere.  There is, however, a known bug that has now been assigned a milestone and a solver in Chromium’s bug list – the “import_bookmarks_from_file” is actually ignored if the “skip_first_run_ui” is set to true.  So right now, you can’t silently import your bookmarks in.

The “sync_promo” item doesn’t seem to be necessary if you disable Sync in the MCX settings above, but since MCX policy always wins over Master Prefs, there’s no penalty or downside to including it.

Note that your JSON syntax has to be perfect for this to work.  Any incorrect comma placements, and it simply ignores your master prefs file.  If you find that your Master Prefs isn’t loading up as expected, run Chrome from the Terminal with the debug log turned on to see what’s happening:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome –enable-logging –v=1
This places a file called “chrome_debug.log” in ~/Library/Application Support/Google/Chrome/Default/ (i.e. default user data directory).  The first line will tell you exactly what went wrong with your Master Prefs file.

Now, there’s still one more problem here: new tabs open up to the default Chrome “New Apps / Most Visited” switcher page (called the newtab page).  Unfortunately for us, there’s no way to change this behavior present in the UI.  The good news is, this behavior annoys plenty of other users, and there are a million extensions you can use to get rid of it.  More good news, is that you can silently include extensions in your MCX manifest!

So simply add this to your MCX settings above (forgive the pseudo XML here, just to indicate type of key):
ExtensionInstallForcelist – <array>
dpjamkmjmigaoobjbekmfgabipmfilij;http://clients2.google.com/service/update2/crx – <string>

This silently forces the install of an extension called “Empty New Tab Page,” and specifies an update URL for it (required, since Chrome autoupdates its extensions too if they come from the Chrome Web Store / Extensions pages).  The extension does what you think it does – you get a blank page.  There are other extensions for customizing the new tab pages, or anything else, so as long as you get the extension ID (it’s the long block of letters in the beginning), you can load whatever you want in here.

There you go!  I’ve tested this using Local MCX on my 10.6 and 10.7 machines, and it works perfectly (deployed through Munki as well).  On the whole, Chrome is a bit easier to manage and deploy than Firefox, just because it doesn’t require modifying the app itself to do this.  Also, the Master Preferences file works for any instance of Google Chrome – even if the users install a copy somewhere other than /Applications.  This also does work for Chromium, the open-source version of Chrome.

Hope this helps someone.

Nick McSpadden
Schools of the Sacred Heart

US Code for Copyright & Fair Use:

MacEnterprise, Inc

Using NetCat, dd and bzip to copy drives in Linux

Posted 2012/05/02 By mikep345678

Boot from PartedMagic on Source and Target machines.

On terminal of Target machine:

  • use ifconfig to determine ip address (targetip)
  • netcat –l –p 2525 | bzip2 –d | dd of=/dev/sda

On terminal of Source machine:

  • bzip2 -cvv /dev/sda | nc targetip 2525