Reset the macOS printing system through the command line

Sometimes you need to reset your printing system to resolve some weird issues with one or more of your print queues. Prior to macOS Catalina, one way to reset the printing system was through the GUI. For example in macOS Mojave, you could go through System Preferences > Printers & Scanners and right-click (cmd + click) the list of printers and select “Reset printing system…” from the contextual menu.

If you’re reading this blog post you’re probably interested in automating that task. Back in 2015, I set out to find a way to do this programmatically so that it could be scripted. I shared the script on JamfNation at the time. Today, the logic and script still works, but it sure would be nice if it wasn’t needed in the first place.

With macOS Catalina, Apple silently introduced a new option in their printtool command line tool to reset the printing system. Type the following in Terminal:

/System/Library/Frameworks/ApplicationServices.framework/Frameworks/PrintCore.framework/Versions/A/printtool --reset -f

And just like that, all your print queues should disappear! There’s not much more to this blog post than that. I just wanted to document this new option because it hasn’t really been documented anywhere that I can tell. And it’s a handy one liner that may come in handy when troubleshooting. Hope this is helpful to you in some way. I’ve also gone ahead and uploaded my original script to Github as well.

Preemptively granting permission to Camera and Microphone in macOS

Starting with macOS 10.14, Apple introduced the requirement that applications requesting access to certain APIs would require permissions from the end-user. This is commonly referred to by other IT administrators are Privacy Preference Policy Control (PPPC) or Transparency Consent Control (TCC). The intent is to make the end user aware of what the application they are using requires access to. In 10.14, the list of services that could be whitelisted included 25 TCC services and it has grown to 39 services. From a consumer perspective, the can be a good thing, albeit exhausting, as you need to essentially provide access to multiple services for individual apps.

Apple to their credit has allowed IT administrators to manage most of these services that applications require in order to function by use of configuration profiles when your device is enrolled into an MDM server (whether user approved or via DEP). However for 4 services (Microphone, Camera, ListenEvent, and ScreenCapture), Apple decided that even IT administrators on enterprise-owned devices cannot preemptively provide allow access to these services (one can only deny access). This complicates things because end-users often need to join video conferences on the fly and those applications typically require access to the microphone and camera. If the user gets bombarded with different alerts to provide access, they may accidentally deny it and not be aware how to resolve the issue. Every application/developer is on their own in terms of how to best communicate how to resolve accidental denials of apps to functional services. And for some services, it is implied that you need to quit the app and restart it. Yes, you need to get out of the meeting and re-join it. This becomes an IT support issue as you can imagine.

It’d be great if Apple would provide proper options to allow these services on enterprise-owned devices that are supervised by an MDM server. You can submit feedback to Apple at http://feedbackassistant.apple.com.

To cut to the chase, I was alerted to this article from Zoom last week where it seems that Zoom is recommending that you provide full disk access to Zoom Rooms so that it can then provide itself Camera and Microphone access. Shame on Zoom for doing this since this is after all how we got here in the first place (Dropbox previously got caught doing similar stuff in 2016, but quickly rectified it). But I do get it to some extent. From their perspective, they are concerned about providing as seamless of an experience as possible. And the same is true of IT administrators to some extent. Computers are tools for people to get work done. It shouldn’t be super complicated to join video conference meetings on your computer in 2019. But Apple has made it so.

Since the cat’s out the bag, I made a script that provides camera and microphone access. It was designed to work with Jamf Pro which automatically has granted its binaries full disk access when its MDM profile has been user approved (or installed via DEP). This allows the script to make the modifications to the user’s TCC.db. I tested this against Microphone, Camera, ListenEvent, and ScreenCapture services (kTCCServiceMicrophone, kTCCServiceListenEventkTCCServiceCamera, and kTCCServiceScreenCapture). The last two don’t work just so you’re aware.

To use this script, add it to your Jamf Pro server and make use of Jamf Pro Script Parameters:

Parameter 4: is used to provide the full path to the application (e.g. /Application/Firefox.app)
Parameter 5: is used to provide the TCC service name. See $tcc_service_list array for valid entries. Of importance to you will be: “kTCCServiceMicrophone” and “kTCCServiceCamera

The script can be found on my GitHub repo. Feedback/improvements always welcomed.

Revisiting: A macOS upgrade method using Jamf Pro Self Service

Back in 2017, I released my script that I use to do macOS upgrades in my organization through Self Service. Since the script I wrote has changed, I thought a new post was deserved to account for the changes I’ve made.

At my organization, we leverage the macOS installer app from Apple which has a neat little command line tool called startosinstall. There are quite a few scenarios that need to be accounted for to avoid running the upgrade in a situation where it would ultimately fail. With that in mind, here are some of the requirements I came up with that the upgrade script needed to solve:

  1. Computer has sufficient free drive space.
  2. Ensure the user is plugged into a power source.
  3. Confirm that the volume is not presently undergoing encryption/decryption.
  4. Provide a way for the end user to do FileVault authenticated restarts if possible.
  5. Provide dialogs to give the user feedback such as a time estimate and dialogs on what to expect next.
  6. Make use of Jamf Pro script parameters to allow for customization and potential re-use for future operating systems releases.
  7. Provide logging to see where failures may appear.
  8. Allow use of an install package that can be used with macOS 10.13+ installers.
  9. Make sure that the macOS installer app does not have expired certificates.
  10. Perform a jamf recon immediately after upgrade.

Continue reading Revisiting: A macOS upgrade method using Jamf Pro Self Service