For the most part, Server 5 has been a pleasant upgrade, but there was one rather major change that caused some headaches, especially when third-party web services are hosted on it, such as WebHelpDesk, JAMF Casper Suite, anything tomcat, etc...

Previously, all web services hosted by OS X Server were being leveraged by an Apache backend.  As such, you normally had to disable apache altogether with the following command:   

sudo apachectl stop

Unfortunately, this no longer works.  After much researching online I stumbled across this article from

Essentially, apache in OS X Server 5 is now acting as a proxy, so all web traffic goes through it first, not just HTTP(s) but other popular web ports as well: 80, 443, 8008, 8800, 8443, and 8843. As such, the trick is to tell Apache to not listen on the ports you need.

Simply edit the following file with your text editor of choice (vi, nano, etc): /Library/Server/Web/Config/Proxy/apache_serverproxy.conf

Navigate down about 10 lines to where you see the various 'listen [port]' lines.  Comment out those lines by adding a # in front of them.  For example, if you want to pass 8443 on to your Casper JSS, edit 'listen 8443' to show '#listen 8443'.  Once done, save the edit, restart the server and you should be good to go!

AuthorMike Muir
CategoriesTech Geekery

DeployStudio has become far and beyond one of the most indispensable tools in my tech arsenal for multiple Macintosh deployments.  It makes it incredibly easy to take a master image you've created for your office or a customer, and deploy it out to multiple systems over your network all while automating Computer Names, extra package installations, partitioning, Boot Camp, and many others...

However, there was one hiccup that made the whole process a little slower with the advent of OS X 10.7 Lion: hdiutil.  When Lion was released, Apple changed how hdiutil works behind the scenes (as far as I know) which drastically increased how long it takes when going through DeployStudio image creation.  I've given the image creation task about two hours for something as small as 20GB.  If you are attempting a deployment in one day, two hours can easily ruin your plans.  For some reason though, there are no slowdowns by using Disk Utility and saving the .dmg locally...

In the past, I usually just accepted it and figured out how to work around the slowdown, but we recently found a nice workaround using the free and open source Create-Recovery-Partition-Installer, available on GitHub at  By using this tool with the same copy of your OS X Installer, you can quickly make a small .pkg installer that will automatically create the Recovery Partition on the system you are working on.

This way, by using Disk Utility to create the .dmg locally and Create-Recovery-Partition-Installer, we can take the resulting .dmg and .pkg, move them to the DeployStudio Repository, and create a quick workflow in close to half the time it takes to use DeployStudio to do the same thing.

Here is final workflow I use in order:

  • Hostname Form- Preemptively enter in the computer name to be imaged immediately on start of the workflow.
  • Partition- Re-partition the first available physical hard drive (dont leave ext. HD's plugged in).
  • Restore- Restore the master image .dmg to the previous partition.
  • Configure- Apply the computer name and other info that was entered in during 'Hostname Form'.
  • (optional)Open/Active Directory Binding- pretty straight forward, it will bind itself to the directory of your choice.
  • (optional)Automatic Enrollment- Enroll the computer in your MDM Server of choice.
  • Package Install- Use the .pkg created with Create-Recovery-Partiton-Installer, postponed to be installed on first boot.
  • Generic Script- Specific for us at CRTG that runs a .sh script to enroll the client system into our monitoring Service we use through Watchman Monitoring.
AuthorMike Muir
CategoriesTech Geekery