Identifying the Jamf Pro server set in CasperCheck using an Extension Attribute

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

1. Test VM is enrolled in the test Jamf Pro server
2. CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.
3. CasperCheck runs its repair functions and enrolls the test VM in the production server.
4. I wonder why my test VM isn’t talking to the test Jamf Pro server.
5. I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.
6. Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

Session videos now available from Penn State MacAdmins Conference 2017

The good folks at Penn State have begun posting the session videos from the Penn State MacAdmins Conference 2017. The sessions slides and currently-available videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

As all the session videos have been posted to YouTube, I’ve linked my Storing our Digital Lives: Mac filesystems from MFS to APFS session here:

Deploying a pre-configured F5 Big-IP VPN client

As part of a discussion with a colleague, he said that he needed to build an installer for his shop’s F5 Network’s VPN service but wasn’t sure how. I hadn’t built one of these previously either, so I decided to look into it.

Fortunately, F5 Networks has made the process of creating one a fairly straightforward process, assuming that your VPN administrator can provide the needed config_tmp.f5c configuration file. Assuming that you can get that file, all that’s needed is making sure that the config_tmp.f5c file is located in the same directory as the VPN client installer.

The reason for this is that the postinstall scripts of the F5 VPN client installer are set to look for that file in that location, and will automatically import the configuration file’s contents if the file is found.

Once I had both the config_tmp.f5c config file and a copy of the F5 VPN client installer, I was able to create an installer using this method that handled both the installation and the automated configuration of the F5 VPN client. For more details, see below the jump.

Generating printer configurations using payload-free_package_printer_generator.sh

As part of a recent discussion, a colleague posted in the MacAdmins Slack that they needed to deploy printers as part of a DeployStudio workflow. DeployStudio doesn’t natively include this functionality, so that meant developing a way to deploy the desired printers to the appropriate Macs via one of the following methods:

• Using a script
• Using a management profile

As part of the conversation, I pointed to Nick McSpadden‘s PrinterGenerator tool:

https://github.com/nmcspadden/PrinterGenerator

Nick’s tool is designed to create printer configurations for deployment via Munki. However, my colleague wasn’t using Munki in this case and didn’t plan to deploy it. So even though there was a tool that could have solved the problem, adapting it to work for my DeployStudio-using colleague’s needs was going to take some time and effort.

The discussion got me started thinking about the problem of printer deployments and ways to solve it that could work for the vast majority of deployment solutions. After some research and testing, I’ve developed a solution that may work for most deployment needs. For more details, see below the jump.

Slides from the “Storing our digital lives: Mac filesystems from MFS to APFS” session at Penn State MacAdmins Conference 2017

For those who wanted a copy of my filesystem talk at the Penn State MacAdmins Conference 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/psumac2017pdf

Keynote – http://tinyurl.com/psumac2017key

Using Brisk to file bug reports with Apple

As part of preparing for macOS High Sierra, I need to file bug reports to report problems that I’m finding with the beta releases. As part of this, I’ve started using a tool named Brisk. It helps streamline the process by filing bug reports via a native app on my Mac, rather than having to go through this process:

1. Open a web browser.
2. Go through the process of signing into bugreport.apple.com
3. File a bug report Apple’s bug reporting web interface

Brisk also makes it easy to cross-post the submission of a bug report to OpenRadar. Since bugreport.apple.com is not publicly searchable and only allows developers to see their own bugs, OpenRadar is a way for developers to share their own bug reports and keep both themselves and their colleagues up-to-date on the status of various bugs filed with Apple. For more details, see below the jump.

Enabling least-privilege screensharing using Apple’s Remote Desktop Client and Screen Sharing.app

In a number of Mac-using environments, there is often a need for IT staff to remotely connect to a Mac’s screen using Apple’s Remote Desktop application and work with the person on the other end to resolve a problem. However, there can be several technical and human-centric issues with enabling remote assistance:

1. Authentication – To enable access using a username and password, that user account must be granted access rights by belonging to a group or by explicitly granting rights to a local account.
2. Password rotation – If you’re enabling screensharing via granting access to a local account, the security requirements in most environments mandate that those passwords be changed on a regular basis. However, securely changing the account password on multiple remote Macs can be a management challenge on its own.
3. Access privileges – A lot of folks don’t like the idea that someone they don’t know can take over access to their keyboards and screens without the remote customer saying it’s OK for them to do so. Frankly, I’ve been on both sides of this fence and I don’t like it either.

However, there is a way to enable screen sharing using Apple’s Remote Desktop Client and Apple’s Screen Sharing.app which does the following:

• Removes the need for any account to be enabled for screen sharing access
• Mandates that all screen sharing access be approved by the logged-in user
• Does not allow screen sharing access if no user is logged in.

For more details, see below the jump.

Filesystem session at Penn State MacAdmins 2017

I’ll be speaking at Penn State MacAdmins Conference 2017, which is taking place in State College, PA from July 11th – 14th, 2017. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development. For those interested, my talk will be on Wednesday, July 12th.

For a description of what I’ll be talking about, please see the Storing our digital lives: Mac filesystems from MFS to APFS session description. You can see the whole list of speakers here on the Speakers page.