“Did you try restarting your computer? …” is undoubtedly the most common question asked by IT to users. And perhaps unsurprisingly, the majority of user issues get resolved by completing this simple task. Before most computers had SSDs, this wasn’t a task most users wanted to do for the simple reason that it took several minutes to close all running applications, reboot, get back to the login screen, and then fully load the OS. Thankfully, most laptops now have SSDs and so this task is significantly faster – 10 to 30 seconds total at most. And yet we still struggle to get our users to reboot.
Rather than wait for the Helpdesk tickets and phone calls to come in, we’ve taken a more proactive approach to encourage our users to reboot their computers themselves.
There are 4 things that make this work:
An extension attribute to collect the last time a machine has rebooted
A smart group to collect all computers that haven’t been rebooted after the desired amount of time
A script that presents the desired notification using jamfHelper
A policy that presents the notification to the user
Whether or not you’re looking to have your users reboot on their own, this same structure can be applied to other notifications you may want to present to your users. As an example, we use a similar structure to inform our teachers and administrators when their internal storage has less than 25% free space, as well as less than 10%.
Two years ago, I invested in the Synology 1815+ (8-bay) NAS to serve as my digital media library, primary computer backup, and some of my Docker container testing. Sadly, over the winter holiday after a brief loss of heat in my apartment it died unexpectedly. RIP.
Thankfully I was able to get the unit replaced fairly quickly and seamlessly transfer my drives from my old 1815+ system to the new one without any data, setting, or configuration loss.
I also bought 2 x 6TB Western Digital Reds to replace two of my existing 3TB Reds and migrating those drives was also pretty painless.
See below the jump for an overview of this process.
Whether you have automated policies which install printers where they’re needed or have users install them themselves via Self Service, deploying printers in Jamf Pro is fairly painless.
A few times this year however, we’ve run into issues with some of our older printers that required us to replace them with newer models. If you happen to use a print server, however, it can be challenging to simultaneously remove and install new printers via Jamf while using the original printer name with the newly deployed printer.
As a result, I wanted to develop a smoother process for these printer swaps and so that all machines in our environment that had the old printer installed would get the new model without impacting those users’ machines.
Complicating matters in our environment was the fact that we configure several proactive policies for installing printers. In the event a computer in one of our departments or labs does not have all the necessary printer(s) already installed, these policies kick in the next time a computer checks in (every 15 minutes) and reinstalls all applicable printers. I wanted to be sure then to avoid having the old printer reinstalled via these policies once we deployed the new printer.
Additionally, the native “unmap” option in the Jamf Pro Printers payload within Policies requires that the printer name deployed on machines match what’s on the server. However, the new printer I needed to deploy needed to have the same name as the old printer in order to match the same printer queue name on our institution’s print server. I needed to be able to simultaneously uninstall the old printer, reinstall the new printer with the same name, and not unnecessarily impact our users.
Ultimately, I developed the following workflow to accomplish this task:
Temporarily disable the applicable proactive printer install policies we had configured.
Change the old printer information in Jamf Pro to something different in order to upload our new printer configuration.
Create a policy scoped to all computers with the old printer installed to run 1) a script uninstalling the old printer and 2) a printer payload to map (install) the new printer.
Once successfully deployed, update the applicable proactive printer policies with the new printer and re-enable the policies.
“If it ain’t broke, don’t fix it.” But not all things have to be broken to know they could be better …
In a spree of watching past Mac Admin presentations from various conferences not too long ago, I learned about BSDPY: a replacement to the one thing that many environments loath having to have run on Mac hardware in production – a NetBoot server. A Mac NetBoot server allows IT administrators to run a fully-functional Mac operating system on a Mac from over the network. This is frequently used for imaging Macs, as it does not require local storage. Mac NetBoot servers can also be used to deploy network-based macOS installers (NetInstall) as well as run Apple-provided troubleshooting tools with Apple Service Toolkit (AST).
The problem with the macOS NetBoot Server is that it is entirely dependent on Mac hardware running macOS and the macOS Server application. As a result, many environments begrudgingly deploy Mac Minis (or Mac Pros) as servers in production in order to utilize this functionality.
Having personally started down the road of Linux administration, I took it upon myself to move everything currently on our Mac mini – our JSS, file distribution point, and NetBoot server – all to an enterprise-grade server. BSDPY proved easy to get going by comparison once I found the right guide (thanks to @bruienne – who is also the creator of BSDPY – over on the #bspdy MacAdmins Slack channel!) .
In a previous post I went through my process for editing the postinstall script of a Jamf QuickAdd package for use with Rich Trouton’s CasperCheck tool so that it does not trigger any enrollmentComplete policies you may have.
Recently I completed an upgrade of our production JSS (Jamf Pro) and found that since version 9.82 Jamf has changed this postinstall script slightly. The process itself hasn’t changed, but the line in the script you comment out to prevent enrollmentComplete policies from running is different.
Notice now that the enroll -invitation command in line 40 now by default includes the -noPolicy flag. Only after confirming that this enroll command completes successfully does it run a policy -event enrollmentComplete.
The only other notable change is line 30 where it creates the jamf config file (/Library/Preferences/com.jamfsoftware.jamf.plist). You’ll notice the new -verifySSLCert flag. This is what determines whether or not the client will verify the SSL certificate on the JSS. There are 3 options here:
always (default) – this should be used unless you are using a cert using the built-in Certificate Authority.
always_except_during_enrollment – this is the option we use, and is recommended for those using the built-in Certificate Authority in your JSS.
never – does not check the certificate on the JSS.
Make sure then that you build your QuickAdd package after you configure this on your JSS to ensure the proper value is applied to your machines should CasperCheck run.
Working for a school, historically we’ve had students with computer accommodations conduct written portions of exams on Windows laptops. This is because by default Microsoft’s built-in Notepad application does not offer any spelling or grammar features and therefore requires very little configuration or hands-on time in order to be exam-ready.
Recently however, I ran into some issues with a student taking a language exam on a PC as this required the student to use accented letters (é, ñ, etc.) using the Windows alt codes. Unfortunately, because the exam was taken on a laptop we had difficulties using the Windows alt codes on PCs without a NumPad requiring us then to use the character map, which isn’t great for test-taking.
Since accented letters are a bit easier to enter on Mac – and don’t require you to memorize or reference a series of alt codes – I started down the path of how to configure our Macs for taking either written or auditory exams.
Below are the list of things I wanted to accomplish:
Setup a separate testing user
Since our students have network folders, we don’t want them signing in with their own credentials on the machine and accessing these resources.
Disable Internet connectivity
Since most exams involving a computer don’t require an Internet connection, we want to disable the network service entirely so there isn’t a risk of Wi-Fi being turned back on. That being said, I also want to do this in a way that for me and my team is quick and easy to both turn on & off as needed without having to connect to our network.
Determine the application for written exams & lock it down
While Microsoft Word is the more widely used word processor on the Mac, many of its settings (at least as of this writing) are not manageable. Microsoft Office 2016 versions 15.33-36 have started to add additional managed preferences (see this Google Doc for a complete list), but as of yet don’t meet our needs here. TextEdit then is the logical choice, but offers spelling and grammar checking, which we need to disable.
Have audio output to multiple sources for auditory exams
In the case of language exams, we need to be able to have both the student and the proctor hear the same audio. Thankfully, the Mac natively allows you to output audio to multiple sources, but takes a bit of configuration.
Prevent access to Spotlight
While a really handy tool for finding files, performing calculations, and defining words, we don’t want students to utilize this functionality during exams. So how do we lock down something embedded in macOS that can’t really be turned off?
I recently started testing some of our existing software on the latest version of macOS Sierra (10.12.5) and ran into an issue with the TI-SmartView CE emulator software for Mac when trying to activate with our institution’s license that was a result of a change Texas Instruments had made to the software installer that wasn’t communicated and is somewhat buried line in their software installation and activation knowledge base article.
While there have been many write-ups and presentations on the impending doom of imaging, it’s not quite dead yet …
If you’re still an imaging shop, you may know that of all the wonderful things that jamf logs during the imaging process, the actual imaging configuration that is used during imaging is not one of them.
This has been a feature request on Jamfnation since 2012. Though as of this writing the feature is listed as “Planned”, there’s no reason you couldn’t implement a workflow that accomplishes this right now.
There are two methods:
A script that runs in an imaging configuration workflow
A policy that runs following imaging & enrollment
There are likely other workflows already out there that accomplish this in a similar way, but this is the process I’ve come up with for my environment. At the very least, I hope this gives you something to work from in developing your own solution.
I also have a couple optional additions that I include at the end as part of this larger solution, which you can choose to incorporate if you wish. This includes:
A modified script that runs during an imaging workflow that includes writing additional User & Location data to a local PLIST for inventory collection.
An inventory collection policy that runs a custom command in order to automate the collection of User & Location data (user, department, building, and room) in the JSS.
A couple of scripts to calculate the total time (hours:minutes:seconds) it takes to image a machine.
This post covers how to configure CasperCheck in order to avoid potential issues rerunning policies you may have configured in your JSS / jamf pro with the enrollmentComplete policy trigger.
Know that I do not cover all the ins and outs of configuring CasperCheck here. Go on over to the CasperCheck Github repo for that.
I welcome your comments and feedback, so if this guide helped you or you’re having issues, feel free to post a comment. You can also hit me up on the MacAdmins Slack group. If you’re not already a member, you can sign up here.
CasperCheck requires a QuickAdd package in order to automatically reenroll a Mac that either no longer has the jamf binary or can no longer run policies.
In our environment we utilize the enrollmentComplete policy trigger to run several policies post-enrollment that install our local admin account, run a script, install our Wi-Fi profile, and a few other things we need to configure.
The problem arises with the default QuickAdd package postinstall script, as it runs the below command:
## Run enroll
$jamfCLIPath enroll -invitation XXXXXXXXXXXXXXXXXXXXXXXXXX
This reenrolls the Mac with the invitation (which does not expire) and checks for policies with the enrollmentComplete trigger. If you have policies that use this trigger and computers are still in the scope, this will cause them to rerun when CasperCheck reenrolls them using the standard QuickAdd package, potentially producing issues you would really like to avoid.
Edit your QuickAdd package’s postinstall script for use with CasperCheck by including the -noPolicy flag to the enroll command to prevent triggering your enrollmentComplete policies.