Archive

Archive for the ‘Scripting’ Category

Updated Jamf Pro MDM lock script to add reporting feature

June 1, 2021 Leave a comment

Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to send device lock commands via MDM to multiple Macs

May 28, 2021 Leave a comment

Most Mac admins have had this conversation at one point or another over the course of their careers:

“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”

At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.

Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:

1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.

Screen Shot 2021 05 28 at 2 48 00 PM

3. Select the Management tab.

Screen Shot 2021 05 28 at 2 48 01 PM

4. In the Management Commands section of the Management tab, click the Lock Computer button.

Screen Shot 2021 05 28 at 1 57 43 PM

5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.

Screen Shot 2021 05 28 at 1 58 56 PM

6. Click the Lock Computer button.

Screen Shot 2021 05 28 at 1 58 57 PM

7. Click the OK button in the confirmation window.

Screen Shot 2021 05 28 at 1 59 42 PM

 

Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.

Screen Shot 2021 05 28 at 1 59 49 PM

 

For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.

Read more…

AutoPkg repo and logfile cleanup scripts for use with autopkg-conductor

May 14, 2021 Leave a comment

As part of running autopkg-conductor over a long period of time, you may see a large percentage of disk space used on the Mac where you’re running AutoPkg and autopkg-conductor. This is because AutoPkg doesn’t remove older files from ~/Library/AutoPkg/Cache and autopkg-conductor does not remove older logfiles from ~/Library/Logs. To assist with this issue, I’ve written a couple of scripts. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to mass-delete obsolete packages and scripts

April 16, 2021 2 comments

If you’re using AutoPkg and tools like jamf-upload or JSSImporter to automate the uploading of packages and scripts to your Jamf Pro server, it may be necessary to periodically delete a large number of now-obsolete installer packages or scripts from your server. To help with this, I’ve written a couple of scripts to help automate the deletion process by using a list of Jamf IDs and the API to perform the following tasks:

  1. Delete the relevant installer packages or scripts.
  2. Generate a report of which packages or scripts were deleted.

For more details, please see below the jump.

Read more…

Adobe Flash is dead – let’s get it removed

January 1, 2021 9 comments

After 24 years and 1078 known security vulnerabilities, Adobe Flash has reached end of life status as of December 31, 2020.

Screen Shot 2021 01 01 at 1 25 22 PM

To assist with the process of removing Adobe Flash, I’ve written an uninstall script which will completely remove Adobe Flash. For more details, please see below the jump.

Read more…

Setting up AutoPkg, AutoPkgr and JSSImporter on an Amazon Web Services macOS EC2 instance

December 20, 2020 1 comment

One of the outcomes of the recent Amazon Web Service’s Insight conference was AWS’s announcement that, as of November 30th, macOS EC2 instances were going to be available as on-demand instances or as part of one of AWS’s reduced cost plans for those who needed them long-term.

There are a few differences about AWS’s macOS offerings, as opposed to their Linux and Windows offerings. macOS EC2 instances are set up to run on actual Apple hardware, as opposed to being completely virtualized. This means that there are the following dependencies to be aware of:

  1. macOS EC2 instances must run on dedicated hosts (AWS has stated these are Mac Minis)
  2. One macOS EC2 instance can be provisioned per dedicated host.

AWS has also stipulated that that dedicated hosts for macOS EC2 instances have a minimum billing duration of 24 hours. That means that even if your dedicated host was only up and running for one hour, you will be billed as if it was running for 24 hours.

For now, only certain AWS regions have EC2 Mac instances available. As of December 20th, 2020, macOS EC2 instances are available in the following AWS Regions:

  • US-East-1 (Northern Virginia)
  • US-East-2 (Ohio)
  • US-West-2 (Oregon)
  • EU-West-1 (Ireland)
  • AP-Southeast-1 (Singapore)

The macOS EC2 instances at this time support two versions of macOS:

macOS Big Sur is not yet supported as of December 20th, 2020, but AWS has stated that Big Sur support will be coming shortly.

By default, macOS EC2 instances will include the following pre-installed software:

For folks looking to build services or do continuous integration testing on macOS, it’s clear that AWS went to considerable lengths to have macOS EC2 instances be as fully-featured as their other EC2 offerings. Amazon has also either made it possible to install the tools you need or just went ahead and installed them for you. They’ve also included drivers for their faster networking options and made it possible to manage and monitor Mac EC2 instances using AWS’s tools just like their Linux and Windows EC2 instances.

That said, all of this comes with a price tag. Here’s how it works out (all figures expressed in US dollars):

mac1 Dedicated Hosts (on-demand pricing):

$1.083/hour (currently with a 24 hour minimum charge, after which billing is by the second.)
$25.99/day
$181.93/week
$9493.58/year

Now, you can sign up for an AWS Savings Plan and save some money by paying up-front for one year or three years. Paying for three years, all cash up front is the cheapest option currently available:

$0.764/hour
$18.33/day
$128.31/week
$6697.22/year

Now some folks are going to look at that and have a heart attack, while others are going to shrug because the money involved amounts to a rounding error on their existing AWS bill. I’m mainly going through this to point out that hosting Mac services on AWS is going to come with costs. None of AWS’s existing Mac offerings are part of AWS’s Free Tier.

OK, so we’ve discussed a lot of the background but let’s get to the point: How do you set up AutoPkg to run in the AWS cloud? For more details, please see below the jump.

Read more…

Installing Rosetta 2 on Apple Silicon Macs

November 17, 2020 17 comments

With Apple now officially selling Apple Silicon Macs, there’s a design decision which Apple made with macOS Big Sur that may affect various Mac environments:

At this time, macOS Big Sur does not install Rosetta 2 by default on Apple Silicon Macs.

Rosetta 2 is Apple’s software solution for aiding in the transition from Macs running on Intel processors to Macs running on Apple Silicon processors. It allows most Intel apps to run on Apple Silicon without issues, which provides time for vendors to update their software to a Universal build which can run on both Intel and Apple Silicon.

Without Rosetta 2 installed, Intel apps do not run on Apple Silicon. So for those folks who need Rosetta 2, how to install it? For more details, please see below the jump.

Read more…

Detecting kernel panics using Jamf Pro

November 10, 2020 4 comments

Something that has (mostly) become more rare on the Mac platform are kernel panics, which are computer errors from which the operating system cannot safely recover without risking major data loss. Since a kernel panic means that the system has to halt or automatically reboot, this is a major inconvenience to the user of the computer.

6lYdt

Kernel panics are always the result of a software bug, either in Apple’s code or in the code of a third party’s kernel extension. Since they are always from bugs and they cause work interruptions, it’s a good idea to get on top of kernel panic issues as quickly as possible. To assist with this, a Jamf Pro Extension Attribute has been written to detect if a kernel panic has taken place. For more details, please see below the jump.

Read more…

Remotely gathering sysdiagnose files and uploading them to S3

October 16, 2020 1 comment

One of the challenges for helpdesks with folks now working remotely instead of in offices has been that it’s now harder to gather logs from user’s Macs. A particular challenge for those folks working with AppleCare Enterprise Support has been with regards to requests for sysdiagnose logfiles.

The sysdiagnose tool is used for gathering a large amount of diagnostic files and logging, but the resulting output file is often a few hundred megabytes in size. This is usually too large to email, so alternate arrangements have to be made to get it off of the Mac in question and upload it to a location where the person needing the logs can retrieve them.

After needing to gather sysdiagnose files a few times, I’ve developed a scripted solution which does the following:

  • Collects a sysdiagnose file.
  • Creates a read-only compressed disk image containing the sysdiagnose file.
  • Uploads the compressed disk image to a specified S3 bucket in Amazon Web Services.
  • Cleans up the directories and files created by the script.

For more details, please see below the jump.

Read more…

Backing up Jamf Pro Self Service bookmarks

September 27, 2020 Leave a comment

As part of working with Jamf Pro, I prefer to be able to save as much of the existing configuration of it as possible. Normally I can do this via the Jamf Pro Classic API and I have a number of blog posts showing how I use the API to create backups of my Jamf Pro configuration.

However, one set of data which is not accessible via the API are the Self Service bookmarks.

Screen Shot 2020 09 27 at 11 29 48 AM

If I want to back up this information, is there a way outside of the API? It turns out that there is. For more details, please see below the jump.

Read more…

%d bloggers like this: