Recently I took up the task of converting our department’s various paper forms to digital. Not only were we collecting a lot of paper over the years with our various forms, but we were duplicating our paperwork in a Google Spreadsheet manually, which led to data inconsistencies and significantly delayed returns of equipment. These forms included:
A student technology loan form
An employee technology loan form
A technology usage form for equipment dedicated to employees and departments each year
A technology work authorization form for granting permission to work on students’ and teachers’ personal technology
A data recovery acknowledgement form
I was looking to accomplish the following:
Eliminate our paper completely. We had a filing cabinet full of completed forms in differing sorting arrangements that made them difficult to find and extremely difficult to cross reference all the things different people had checked out or loaned to them.
More clearly define and smooth the process. In the case of student long-term technology loans (more than 1 month), our department requires student advisors to OK the loan before allowing students to check out equipment. Whether a student walked in on their own or their advisor sent in a Helpdesk ticket, the paper forms made the process clumsy by requiring advisors to visit our office to sign off on the loan.
Allow forms to be completed both within and outside our office. While the nature of digital forms makes them easy to share and distribute, I wanted these to be able to be completed on any device.
Store all form submissions in one place. This would make it much easier to keep track of all form submissions.
Allow forms to be resubmitted. Because we would be shifting the responsibility of completing these forms to our users, there was a chance a form could be completed incorrectly. For example, a student could indicate they were checking out a laptop but forget to include the power adapter. We needed to be able to make these changes such that it changed both in the form and the central response repository.
Have an automated way of creating a calendar event for the due date of technology loans. This would help us ensure technology was returned to us on time and serve as a reminder if it hadn’t.
Have a user-friendly form landing page. When forms were completed on one of our department devices, I wanted to have a clean and clear way for our users to access all our forms.
Ultimately I developed a solution using Google Forms and Google Spreadsheets and one which I’m pleased with. The main components are listed below:
A Google Form for each of our existing forms
A single Google Spreadsheet with each Google Form linked to a separate sheet
A script attached to the Google Spreadsheet for tracking the Edit URL of each Google Form submission (more on this in a bit)
An HTML landing page for a clean and user-friendly way of accessing the forms in our office
Alternatively, a Google Site would work perfectly well
In part 2 of “Moving Our Technology Paper Forms to Google Forms“, I covered the process for linking the forms to a single spreadsheet, organizing and protecting the spreadsheet, and creating a Google Script to collect the Edit URL for each form submission.
This post covers the process of creating our HTML landing page for our various forms and getting this on several Android devices and a public computer we had available for this purpose. I also reflect a bit on our deployment.
To address the Meltdown vulnerability, Apple released a security update for macOS High Sierra (10.13) and later for Sierra (10.12) and El Capitan (10.11). While we avoid performing major OS and other software updates during the year to avoid negatively impacting our users, we were eager to patch this widely known security hole. Up until this point we haven’t had a reason to deploy a institution-wide patch to all our managed Macs, and we actively disable automatic software checks. So, it was time to figure out a workflow.
Apple normally releases software updates through the Mac App Store and later through other sources. Normally I prefer grabbing Apple-related updates through their Support Downloads page, as this allows us to upload a single PKG to our distribution point, and then cache the PKG on our machines so that our users can then install the software at their convenience through Self Service. However, at the time Apple had not yet released the update to their support page yet, and while I’ve been eager to test and deploy reposado to keep the update deployment within our LAN, rather than out to Apple’s servers, it just wasn’t feasible given the time-frame.
While Jamf Pro supports the ability to install all available software updates via policy, I only wanted to download and install the applicable security update. I opted instead to use the Mac’s built-in softwareupdate command-line tool to cache the security update for a later install triggered by our users.
The basic structure was as follows:
Determine the softwareupdate name of the patch and the update ID of the folder that gets created in /Library/Updates
A smart group containing all the eligible machines for the security update
A script to refresh the available softwareupdatelist and download the desired security update
A script to install the cached security update
An on-demand policy with a custom trigger to download the security update
An automated policy to invoke the on-demand policy via custom trigger to download the security update behind the scenes
A Self Service policy for our users to install the security update at their convenience
An email notifying users of the update and deadline to install it, after which the update would be installed automatically
This post covers the individual components of our security update deployment solution, while a second post covers the policy build and deployment.
See below the jump for our details about our workflow.
“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.