Creating DNS records in OS X Server for top level domains

It is not very common to see this, but if in a rare circumstance you are hosting a zone file in house for your DNS, but it is sharing the same domain as your website, you or your employees might be stuck not being able to access your website.  Unfortunately, OS X Server does not have a way in the GUI to create a top level DNS record (sometimes seen as an @ record).  However, this can still be done via commandline...

cd /Library/Server/named

sudo nano db.domain.com

Add your A record for your [domain.com]:

domain.com. 10800 IN A target_IP_Address

Once done, restart DNS in Server.app, clear your DNS cache and you should be good to go...

Workflow for a quick master image creation and deployment using DeployStudio

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 https://github.com/MagerValp/Create-Recovery-Partition-Installer.  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.

Flushing DNS cache in Yosemite

New command to flush DNS caches in OS X Yosemite:

sudo discoveryutil udnsflushcaches

Installing MDM Profiles Remotely

More tech stuff.

Say you are managing tens or hundreds of OS X computers, and have a new MDM server in place, but don't want to have to go to each machine and install the enrollment profiles by hand.

Sure, you could email the enrollment profile to each user, but they would still need admin rights to install it, not forgetting how you will convince them to install it in the first place...

Luckily, Apple created a binary called profiles that can take care of it all via command line:

profiles -I -F [.mobileconfig filepath]

It makes it even easier to remotely install profiles with Apple Remote Desktop, as you can copy the necessary .mobileconfig profiles to each machine in a standard place (like /Users/Shared), then install the trust profile (if needed), then the enrollment profile without issue.

If you need to uninstall all profiles from a system, you can use the -D command to delete all config profiles on a system, but it will ask an 'are you sure?' question, so if you are doing it remotely via ARD, make sure to echo the answer beforehand:

echo "yes" | profiles -D

Watchman Monitoring

So anyone who supports Apple or Unix computers REALLY needs to look at using Watchman Monitoring.  Its just a tiny client that runs in the background and periodically phones home to report on the status of *many* services: CrashPlan, Time Machine, HD Failure, RAID status, etc, as well as server services such as OS X Server, Kerio Connect, Daylite Server and more.

Its such a great service, and designed from the ground up for the Apple platform.  Last time I checked, we have it installed on close to 300 systems, and it is rock solid.  Everytime we've done a server/master image deployment, we have been able to easily install the agent behind the scenes using a simple ARD Unix command and it automatically phones home.

Seriously, its really helped us be proactive.  People need to check it out.

Oh yeah, and Allen Hancock made it really generous in its pricing.  Totally worth it.

Troubleshooting Bomgar clients

We use a Bomgar Appliance for remote access for our contract customers.  Its a very nice piece of hardware, supplying some nice security for remote access and management that you dont get in many other systems.  Its expensive, but pretty damn nice in my opinion.

You can enable logging on the OS X client agents by doing the following:

1. Open a new plain text file and add the following:

[blog/debug]
output = /tmp/$COMPANY-$APP_NAME.log
category.All=All
flush_interval=0
file_size_limit=75M
file_size_limit_retain=5F
enabled=1

2. Save the file as blog.ini.

3. Copy the blog.ini file to the Bomgar agent package located at /Users/Shared/bomgar-scc-[installdate]-[jumpclientid].app/Contents/Resources/

4. Restart the client with the following:

sudo launchctl unload com.bomgar.bomgar-ps-xxxxxxxxxx-xxxxxxxxxx; sudo launchctl load <full path>/com.bomgar.bomgar-ps-xxxxxxxxxx-xxxxxxxxxx.plist

5. Retrieve the log files by grabbing the .log file located in /tmp.

6. Delete blog.ini.