Twelvetide, Day 13 (Bonus): Conference

This is the thirteenth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Join the Community”)

Bonus Day! There are many great conferences for Mac admins available right now: (dates are for 2017)

Of course these are great place to learn and watch sessions. Also to meet other admins from many different businesses and schools. Often many of the companies who make software for Mac Administration will have representatives at these conferences showing off their products and available for your questions.

Also these conferences give you a chance to share your knowledge. Most conferences will be very glad for speaker submissions.

Some of these conferences make the session videos and resources available after the conference, these are great resources to watch and learn, even when you do not have the time and money to travel.

(I am sure there are more that I missed, please add them in the comments!)

Also, there are many smaller Mac Admin meetings organised more regularly (or spontaneously) in local groups. The Slack Mac Admin forum can be a great place to find out about these meet-ups!

Twelvetide, Day 12: Join the Community

This is the twelvth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Share and Blog”)

Probably the largest Mac Admin community is the Mac Enterprise mailing list hosted by PSU. This mailing list is mirrored on Google groups if you prefer that interface.

There is also the Freenode IRC # osx-server channel.

However, most of the chat community has moved to the MacAdmins Slack. You can request access to the Slack forum here. You will need the Slack application which is available for Mac and iOS. The Slack forum has several channels for different tools and topics. Slack has a nice help page that’ll introduce to the many options and terms.

My favorite Slack keyboard short cut is “shift-esc” which marks everything as read.

There is also JamfNation. While it obviously focusses on Jamf solutions, it is still a great place to search for generic resources and solutions as well.

Finally, many open source projects have their own mailing lists or forums. For example AutoPkg has a Google group. The Munki project even has two groups: one for general discussion and one for development. Read the project documentation for details. It is often worth searching the group archives for your particular problem before posting and issue against the project.

Twelvetide, Day 11: Share and Blog

This is the eleventh part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

Since you are writing all your documentation anyway, some of that is probably very interesting for the wider MacAdmin audience. The best way is to just get a free blog on WordPress or Tumblr or some other free blog service and start writing.

“But, but, but… I want my own domain,” you say! “And my own design!”

If you already have a domain, or know exactly what you want for a domain, then go ahead, get it, install WordPress and start blogging. Otherwise you are overthinking and procrastinating. If a common wordpress blog is good enough for Rich Trouton and Greg Neagle, it is certainly good enough for every one.

Writing post for everybody is a great way to focus your thoughts on a problem and find flaws in your own reasoning. I often stumble over some preconception I have, research it, and then learn a lot while writing up a blog post (or book chapter). A blog post will obviously make your solution available to other admins through a search engine. Also sharing your problem and the solution to it will make it easier for you and other admins to share the solution in emails and forum posts by linking to your excellent post.

A good blog post should have a description of the problem and how and when you encountered it. What you tried to solve the problem (including the more interesting failed attempts) and then your solution. If the code or scripts required to solve the problem are longer you can post them on gist or turn them into a public GitHub repository. You need to remember to remove data from the scripts such as hostnames, user names and passwords before posting, though.

You should also mention the versions of macOS and any other software involved, so that future readers can quickly figure out if this applies to their problem. (Pet peeve of mine: make sure the post date is visible on your blog. I hate it when I read an article and can’t quickly tell how old it is and if it is still relevant.)

You should aim to post regularly to train the habit and your writing skills. However, since most of us have day jobs, ‘once or twice a month’ is a perfectly fine frequency. You can also use your blog to re-post and promote other administrators’ posts.

Most admin bloggers I know put links to their posts on Twitter. For me Twitter has replaced an RSS reader as the main means of getting notified on blog news. It is usually easy to connect your blogging engine to a twitter account (if not, choose another blogging engine). The MacAdmins Slack has a #blog-feeds channel which can notify for new posts.

A blog is also a vanity project. You can and should use it as an asset when you are applying for a new job or position. Of course, you should check with your current employer, on what and how you can blog about your work.

Some blogs worth following: (in no particular order)

This list is obviously far from complete. Feel free to add your blog and your favorite blog to read in the comments.

Twelvetide, Day 10: Write Documentation

This is the tenth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “File Bugs”)

We have all had this this moment when you are trying to figure how to do something you know you have done before, but just cannot remember what the thing was that made it work.

Documenting everything you do, no matter how trivial it may seem at the time is your protection against these moments.

But also, problems will occur, whether you are present or not. If you want to go on an extended vacation trip away from the internet, spend your week-end with your family, or just go home to sleep, you need the basic documentation so co-workers can resolve the most urgent issues without you. The better and more complete your documentation is, the farther and longer you can be away.

If you are working in a team or organisation, you probably have some tool in place, usually a wiki or CMS. You can spend days, weeks and months discussing and choosing the proper tool. Though I am not saying the tool doesn’t matter at all, any tool that is actually being used is better than a tool that is not used.

There are several great tools for personal documentation:

Finally, I will hand the virtual microphone to Rich Trouton, who has (repeatedly) said all of this so much better than I can.

Twelvetide, Day 9: File Bugs

This is the ninth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

As Mac administrators we are often very deep in parts of the OS that most other users, even developers and other power users, never touch. We need support for features from a software vendor that is very specialized. Often the vendors themselves do not understand the needs of admins, even Apple.

So we need to let them know about those needs and if necessary educate them. Not just Apple but all software vendors. And this is not just in the software itself but also the deployment workflow (installers).

For Apple the main way to file bugs is bugreport.apple.com, also known as Radar. Since the interface can be a bit cumbersome, there is a nice tool called QuickRadar that will simplify the process. (Rich Trouton has a nice write-up on Quick Radar.)

If you have an Enterprise Support you should also file your bugs through that channel. Talking with your Apple Systems or Consulting Engineer can also help. They may surprise you with a solution, but at the very least they are aware of your issues and have different channels inside the company to make them heard.

Don’t expect quick resolutions. Apple is a big company and macOS a very big and complex project. However, when requests and bug reports pile up from multiple sources and channels, Apple does take notice.

Don’t forget to file bugs with other vendors, too!

Twelvetide, Day 8: Check the Competition

This is the eighth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Open Source”)

When you have your management system running happily it is time to build a new one. There is much to learn by having an alternative management system up and running, even if it never leaves your testing environment. You will have to question and re-analyze many of your scripts, workflows and presumptions. You will become a better sys admin in the process.

Since you built a solid testing environment after Day 3, you can dedicate part of your testing infrastructure to building a second environment for testing an alternative management system.

If you have a commercial management system, then Munki is the obvious choice for an alternative server. If you have Munki running, you can usually get a demo license for one of the commercial servers. Even if you come to the conclusion that the management system you started out with is the best for your setup, you find pieces of your workflow that can be improved while re-building everything in a different way.

This doesn’t just hold for the management system, but also for the imaging system (DeployStudio, Imagr, Casper Imaging etc.) or your packaging tool (Jamf Composer, Packages, pkgbuild, munkipkg) or any other tool really.

Twelvetide, Day 7: Open Source

This is the seventh part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Automate”)

I have already mentioned open source projects in previous days’ articles. There is a great and vibrant open source community among Mac admins. You can take part by just using the tools, but if you got into git and GitHub (follwing the Day 4 resolution) you can also, fork and extend and contribute.

Some projects are larger and complex, others are just quick simple tools.
– Munki: open source Mac management system
– autopkg: automate package download and creation
– Imagr: automate netboot installation
– AutoDMG: automate system image creation
– AutoCasperNBI and AutoImagrNBI: creates netboot image sets for Casper and Imagr
– BSDPy: cross-platform NetBoot alternative
– NoMAD: alternative Active Directory connection without permanent binding
– outset: provides hooks for login and startup scripts
– ProfileCreator: (still early development) UI tool to build configuration profiles
– micromdm and commandment: both still in development, open source projects to create MDM servers
– osquery: cross-platform endpoint monitoring

This list is far from complete. There are so mnay other interesting tools. Tim Sutton has a longer list just for Python MacAdmin tools.

Twelvetide, Day 6: Automate

This is the sixth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Replace a Legacy Practice”)

There a many tedious and repetitive tasks for system administrators that are ripe for automation. However, automation always brings with it an initial time cost. You need to put time and effort into analysing the task and writing an script or tool to automate. In some cases the time invested may not pay off.

Even if you do not know how to code (yet! see: Day 2) you can profit from the automation tools others have written. Most management systems have some level of automation, and hooks to extend that.

  • autopkg and AutoPkgr: tools to automate detection, downloading, re-packaging and import of software.
  • Recipe Robot: tools to automate the creation of autopkg recipes to automate the download and packaging of software (very meta)
  • outset: outset lets you put scripts and packages in a folder structure to be executed at login or startup etc.
  • Imagr: automate NetBooted installations
  • python-jss: access to the Jamf server API through python
  • quickpkg: quickly build packages from dmg or zip wrapped applications
  • munki-pkg: automate package building
  • mcxToProfile and makeProfilePkg: simplifies the creation of configuration profiles and installer packages to install them
  • Managing Printers With Munki: process can also be transferred to other management systems

Twelvetide, Day 5: Replace a Legacy Practice

This is the fifth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Version Control”)

If you have been doing Apple Administration for a few years or more, you will appreciate how quickly the environment is changing. The amazing rise and popularity of iPhones and iPads ahve forced Apple and Apple admins to revisit many aspects of management. Not only has Apple drastically advanced the MDM spec (though I would still argue it is far from complete) but Apple administrators have developed and publized many new practices.

Imaging

It is not that long ago that “monolithic” or “golden master” imaging was the most common practice to preload Mac with the OS, applications and configurations. However, there are many issues with this setup as it is very hard to prepare and even harder to manage and update once it is deployed. Apple likes to introduce new hardware with specific OS builds, and you would have to re-build your entire image for new Macs.

The next step is what I call “thick imaging” (the names for Imaging are not used consistently among Apple admins). This involves build a large monolithic image with tools such as AutoDMG, CasperImaging or FileWave Lightning. This will create a never booted, hardware independent (except for those pesky new macs with new specific OS builds) image. Getting the process to build this “thick image” with scripts, configuration profiles and package installers can be very tedious. However, once you have the workflow. You can re-create new images after a software update quite easily. When you use target disk mode over Thunderbolt or USB3 you can re-image huge images very, very quickly. Use this practice when you need to be able to re-image machines fast, like in a classroom or laptop loaner setting.

Next more advanced step is “thin imaging”. Here an admin will lay down the base OS and install the client software and configuration needed to connect to a management system. (Munki, Jamf Pro, Filewave, etc.) Then the management system takes over and installs all necessary configuration and applications or provides them as optional installations to the user.

You can either find a way to install the management client on the existing OS (Target Disk Mode, Recovery HD) or create a base OS (like thick imaging, but just the management client settings) and lay that down with NetInstall or disk-to-disk imaging.

Finally, with MDM and Apple’s Device Enrollment Programm (DEP) you can give up on ‘imaging’ entirely. When a Mac enrolls into an MDM service, client software for a management system can be installed and take over more installations and configurations from there. When a device is registered with DEP at purchase it will be enrolled with your MDM automatically at first boot and after every clean re-install.

This is likely the way Apple wants to move the macOS management strategy in the future. It is after all the only option with iOS.

Other Legacy Practices

Local MCX

It used to be a great trick to put enforced configuration settings (MCX) into the local directory (where the local users are stored). At the time this solution was introduced it solved a few problems for which there was no other solution. Now, Configuration Profiles, wether pushed from an MDM or installed locally solve those problems. You should be moving all settings that can be managed to Configuration Profiles. And you should file bugs with Apple for those settings that cannot be managed with Profiles.

Login Hooks

While login hooks still work with macOS Sierra they have been deprecated for a while now. The modern supported alternative is to use Launch Agents. Thankfully, you do not have to re-invent the wheel and build launchd property lists for everything, but you can use outset instead.

Capturing Files for Installer Packages from Disk

Composer encourages this practice by default. However, there are many pitfalls with this. When you can, you should install or build packages directly from the disk image or archive downloaded. Capturing files should be a last resort for truly horrible installers, not a common practice.

You can read more about building proper installers in my book “Packaging for Apple Administrators” is on sale!

Twelvetide, Day 4: Version Control

This is the fourth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Test”)

Version Control is one of those habits that are a bit hard to get into, but once you have, you will wonder how you ever did without.

If your organization already has a version control solution and infrastructure in place, it is probably best to use that. There should be documentation, experienced users, and best practices which can help you get started.

If you are entirely new to this, however, git is probably the best place to start. git and GitHub are also very popular in the Mac admin community.

The easiest way to install git on macOS is to download and install Xcode. You can get Xcode for free from the Mac AppStore or from the Apple Developer download page. You can also get a standalone installer from the git page directly.

Version Control systems work best against text based files, such as code, xml, html and plain text or markdown files. However, they are not entirely useless when applied to files stored in a binary format.

The command line tool git has everything you need to start with version control. You can have local repositories or connect to a server over http[s] or ssh. Xcode and most text editors have git integration built in. There are a plethora of GUI git clients to choose from.

There are countless tutorials and books available. An astonishing amount of them are free: