Securely erasing a flash drive in Windows with cipher

From time to time, we are given student flash drives either to use or to dispose of. For drives we intend to use, we usually consider using diskpart to clean them good enough. For drives we dispose of, we want to make sure that all data is securely erased so that no potentially-confidential or FERPA-relevant student data is leaked in the event that an enterprising person at an electronics recycler decides to have a peek.

Tools like DBAN can be used from a bootable environment to accomplish this task. However, this only allows you to wipe one flash drive at a time, and you cannot use the computer for anything else while it is running. What if you want to wipe several drives at once, or to wipe just one while doing other work on the computer?

The cipher command-line tool, also useful for encrypting or decrypting drives, can be used to securely erase the free space on a given volume by writing various bytes over any data that may be present so that it is unrecoverable. To use cipher to wipe a flash drive, follow these steps:

1. Reformat the disk using diskpart or some other tool.
2. Open a Command Prompt with administrator rights.
3. Run cipher /w:<drive letter>:\

Formatting the drive will ensure that the cipher tool considers it all to be "free space", and so overwrites the data. cipher will run for a fairly long time, depending on the size of the drive being erased. Once it has finished, the drive will be as clean as if it were brand-new.

It is worth noting that, because of the way flash memory works, you probably don't want to do this all the time to a flash drive, as each write slightly shortens the life of the memory. This may also cause marginal drives to finally fail, so keep that in mind if you intend to reuse a drive you are wiping.

Upgrading Jamf Pro 10.7.1 to Jamf Pro 10.8

Overnight, Jamf released an even newer version of Jamf Pro, version 10.8. Since we're still in the testing phase, I figure that now is as good a time as any to give it a try. So, back to the Mini!

On the Jamf download page, you are warned to run a check on your database before upgrading to Jamf Pro 10.7.1 or 10.8, as there is an issue with a certain Smart Computer Group criteria that can cause infinite loops and other issues. Since I had already run this check before upgrading to 10.7.1, I did not need to do so this time, but anyone who hasn't run it yet should before going any further.

According to the Jamf Pro 10.8 installer, all of the prerequisites are the same as on 10.7.1, so this should be a fairly straight-forward update. Just like last time, it installed as a standard .pkg installer. This time, I didn't stop Tomcat beforehand, just to see what happened. Nothing of note occurred because of this omitted precaution.

After the installation is complete, I was prompted to go to https://127.0.0.1:8443 to complete the database portion of the upgrade, with a strong admonition not to restart Tomcat while this is in progress. The browser sat at a blank white page for a minute or so, then switched to the usual gray screen with the Jamf Pro progress bar. After fifteen or so further seconds, the login prompt appeared.

Upon logging in, I was presented with a Software License and Service Agreement page, which required me to scroll to the bottom (after having carefully read the terms and conditions, of course) before I could click the Agree button.

Once agreed, I was taken to the normal Jamf Pro interface. I confirmed that all of our computers, Policies, etc. were as they should be. Upgrade completed with no issues.

Upgrading Jamf 9.101 to Jamf Pro 10.7.1

We have finally reached the point where discussion about how we can upgrade our Jamf server, running an aging software version 9.101, to the latest, greatest Jamf Pro 10.7.1. I had the good fortune of being the one who got to set up a more-or-less identical testing environment, copy over the production database, and perform a test upgrade to see what might be broken, so that we can plan how to recover when we perform the upgrade to our production server.

Currently, our main Jamf server runs on a Windows Server 2012R2 VM hosted at our central office location. It was not considered worthwhile to spin up a similar VM to test the upgrade process, so I installed Jamf 9.101 on a Mac Mini we had on hand.

The first thing to mention is that, when setting up Jamf 9.101 for the first time, you need to carefully read the prerequisites presented by the installer, and you do need to read the documentation it links to on the Jamf Nation website. Before installing Jamf , you must install Java SE 8, the unlimited-strength Java Cryptography Extensions, and MySQL 5.7. Additionally, you need to manually create a database table and user for the JSS in the database. Once all of this is done, you can install the JSS like any other piece of software using the installation .pkg.

Now, my Mac Mini was running the Jamf 9.101 server software, but it was empty - no computers, no Policies, etc. The purpose of this testing was to determine what, if anything, would be broken by the upgrade process, so I needed to import a copy of our current Jamf database into this new instance.

The tool recommended to me on Jamf Nation, the Jamf Migrator, looked like a great place to start. This tool takes URLs and login credentials for two Jamf servers, a source and a destination, and uses the Jamf API to clone one server to another; alternatively, it can create an XML file from the source server that can later be uploaded to the destination server using the same tool. So, I downloaded this tool to my MacBook, gave it the information it needed, and clicked the "Go!" button. The tool reported that it was able to transfer some, but not all, of most of the things that it can transfer, but failed completely to move any Printers or Configuration Profiles. When I checked the Jamf instance on my Mini, I found that it had only actually moved over three computers. The same issue occurred after several more tries. I don't know what the issue was, but obviously, this tool wasn't going to work in my environment.

Luckily, Jamf provides a tool to back up and restore databases. I used the Jamf database tool to create a backup of our current database, then used it to restore that backup to the testing Jamf instance. This was much more successful than the migrator tool - all of our computers, Policies, Configuration Profiles, etc. were imported, and what's more, so were our VPP tokens and other system settings. I went into the JSS settings to change the JSS URL, turned off the SMTP server (so that my team members would not be inundated with emails from this testing environment), and made a few other changes to make sure that nothing funny would happen with the cloned instance running alongside the original. I enrolled a test Mac to this new JSS, and confirmed that everything was working.

I then set about installing the upgrade to Jamf Pro 10.7.1. No intermediate upgrades are required, so it is actually a very easy progress. The Jamf Pro 10 installer comes as a .pkg, just like the original Jamf 9.101 did, and all you need to do is to install it like any application. The Jamf Pro installer stops Tomcat (though I stopped it beforehand out of caution), installs the necessary updates, then restarts Tomcat. After the installation is complete, the web interface shows that Jamf Pro 10.7.1 is starting up, and eventually presents you with a login screen.

I logged in using the same credentials as I had before the upgrade. I was pleased to find that nothing appeared to have changed or broken - all of the computers appeared to be there, and their data appeared to be valid enough, and so did all of my Policies and Configuration Profiles. It appears that, at least in our case, the upgrade to Jamf Pro 10.7.1 will be painless. We'll see when we do it in production.

Mac Administration with JAMF, Part 4: Creating Packages with Composer

Previous updates have focused on the JAMF web interface, where most of the management capabilities are exposed through Policies and Configuration Profiles. This time, I will cover Composer, a tool in the Casper Suite that allows you to create software installation packages that you can deploy via Policy.

When you open Composer for the first time, you will be greeted by a dialog offering a choice of different ways to capture the sources that will be used to create a package:

One way that you can create a package using Composer is by taking a snapshot of your system before and after an installation. Once the before-and-after snapshots are made, Composer compares them to figure out which files were affected by the installation, then copies them into a .DMG or .PKG that you can deploy using JAMF. There are three snapshot "methods" that you can use with Composer:

• Normal Snapshot - Composer creates a listing of all files that exist on the boot drive before and after the installation process, then compares them to find only the new files that have been created.
• New & Modified Snapshot - Like a Normal Snapshot, Composer compares files that exist before and after the installation. In this mode, it also takes into account any files that were modified between the two snapshots (it's unclear whether it does this by checksum, modified date, etc.). This means that, for example, you can install one program and change some settings in another, and both of these actions will be captured. If you install the created package on a computer, both the new software and the changes made to the other program will be installed. 
• Monitor File System Changes - Rather than creating a full-disk snapshot before and after an installation, Composer will listen for FSEvent events processed through the filesystem, and will use these to figure out which files need to be captured. Composer warns that, in cases where a lot of filesystem activity happens quickly, this may not capture everything correctly.

In most cases, you will want to use a Normal Snapshot. A New & Modified Snapshot is useful if you need to make changes to some files or programs related to the installation, but this can also cause problems, as it captures all files that change between the start and finish of the process, including browser history, login/logout records (if the computer locks itself, etc.), and, most importantly, any changes made to the Keychain on your Mac. Luckily, it's possible to selectively remove certain files from a Composer snapshot before building the package, but it's very important to be aware of what's actually being captured using the New & Modified Snapshot mode. To be absolutely safe, you can use a separate machine for Composer (I use an old Mac Mini), or a virtual machine, to make sure you build packages in a "clean" environment.

Another option Composer gives is Build OS Package, which is exactly what it sounds like. You can configure a Mac exactly the way that you want, then use Composer to capture an image of the disk that can be deployed to other Macs using JAMF as part of an Imaging Configuration. Effectively, this is analogous to capturing a base image from a PC, then using it in a Task Sequence in SCCM.

Unfortunately, as you can see in this screenshot, the version of Composer that I currently have access to does not support APFS disks, so going forward this will be a less viable tool for High Sierra, Mojave, etc. However, this isn't such a big deal, since Mac imaging is dead. For older, Sierra-based environments, though, this is a handy tool.

Composer also provides some pre-made "manifests", lists of files known to be changed by certain software installers, in the Pre-Installed Software section. You can use these to capture common software without having to wait the minute or two it takes to capture a snapshot.

This main section shows manifests that come with Composer, or that you have installed yourself. In the Not Installed sub-section, many more manifest files for other programs are available. All of the manifests available by default were created by JAMF themselves, but the JAMF Nation website also has a list of community-created manifests for almost any piece of software you could need to package.

Finally, Composer can also capture certain settings on the computer, which can be deployed in a package just as if they were an application. The available settings for capture can be found in the User Environment section.

These work similarly to the software manifests described above, in that Composer knows which files hold which settings. Unfortunately, this also means that if you are stuck with an older version of Composer, or if Apple decides to change where settings files are located, this portion of the tool may not be able to capture everything. Even if it does, because of the way Mac OS preferences work, it may not be desirable to do so - for example, the Dock settings you capture with Composer will completely overwrite users' Docks, including any customizations they may have made. For most of the settings here, a more appropriate method of management would be to use a Policy or Configuration Profile, which offer more fine-grained control over exactly what you want to change.

So, what is the process to create a package using a Snapshot? First, go back to the Snapshot section, and select Normal Snapshot. Then, click Next.

Enter the name of the package you want to create (usually, the name of the program, its version number, etc.), then click Next.

Composer will then begin to capture its pre-installation snapshot. You can see its progress as it indexes various parts of the operating system and user data directories.

Once the snapshot is complete, you will see this screen. This is your cue to perform the installation, make changes to files, and perform any other actions you want to capture. Once you have made your changes, click Create Package Source.

When you click the button to create the package source, Composer takes another snapshot, capturing any files that have been created since the first snapshot.

Once the "After" snapshot is created, Composer will present you with a list of the files it found to have been created. As you can see, I created a folder on my desktop called "test folder", and a text file within called "test.txt".

This is the main work area in Composer. Here, you can make changes to the files in the snapshot - you can delete them, change their owner/group/permissions using the handy dialog in the bottom-right, and even drag-and-drop them into different folders. In most cases, for software installations, you will want to leave things as they are.

When you have everything set up the way that you want it, you are ready to build the package using one of the two Build buttons in the toolbar at the top of the window. Composer offers a choice of two different kinds of package that you can build: .DMG or .PKG. These both perform the same basic task, but accomplish it in different ways:

• .DMG packages are what they sound like. Composer creates a .DMG disk image file duplicating the structure and properties of the folders and files captured in the screenshot. When you deploy such a package via Policy or Casper Remote, the JAMF binary on the client Mac copies everything out of the DMG to the same location on the computer. .DMG packages are indexable in Casper Admin, which means that you can use JAMF to uninstall them as well.
• .PKG packages are like "normal" installer packages that you might download from a vendor. You can deploy these packages via JAMF tools, or you can copy them to a flash drive and install them using the normal double-click method, even on a Mac not managed by JAMF. In addition, these packages can include preinstall and postinstall scripts (and a few other kinds, for non-flat packages) that allow you to perform pre-installation checks, post-installation cleanup, or any other scriptable actions that you might want to happen alongside the installation of files. However, .PKG packages cannot be indexed by Casper Admin, so they are not easily uninstallable without creating a separate uninstaller package.

Either of the Build options will let you choose where to save the created package, and will then build and save it there. Depending on the size of the installation you captured, it may take a long time (upwards of 45 minutes for OS captures or very large applications), but it is usually relatively quick.

If you have an installation that you know will not require much customization - for example, an application whose installation process is "drag me to the Applications folder", you can skip the normal snapshot-install-snapshot process, and create a package source with only the files you choose. For example, to create a package that just installs the Google Chrome app in the Applications folder, you can do this:

First, open Composer to the main package work area. Then, drag-and-drop the Google Chrome .app file to the left-hand pane, in the empty lower area.

Composer copies the files for the Chrome app to a temporary storage area, then creates a package source for it, just like it did using the snapshot method above.

You can now build a .DMG or .PKG package for this, and deploy it using whatever method you may choose to install Google Chrome. The disadvantage of this method is that you do not capture any settings changes made - with Chrome, for example, you may want to set a default homepage, etc. when capturing the package; in that case, the Snapshot method is more appropriate. 

More and more applications are moving to models where the Snapshot method does not work, whether because it writes changes to the system-wide Keychain, or other files that are not appropriate to copy from one user to the next, especially across different machines. Some of these, like Chrome and Firefox, allow you to embed special configuration files directly into the .app itself to change things like default homepages, etc. This is in keeping with Apple's changes to macOS installation, where direct captures and deployments will be less and less viable going forward. Therefore, this app-only package creation method will become more and more useful as time goes on.