Using the Jamf Pro API to mass-delete computers and mobile devices

Periodically, it may be necessary to delete a large number of computers or mobile devices from a Jamf Pro server. However, there is currently a problem in Jamf Pro 10 where trying to delete multiple devices can fail. Jamf is aware of the issue and has assigned it a product issue code (PI-004957), but it has not yet been resolved and remains a known issue as of Jamf Pro 10.4.1.

To work around this issue, you can delete computers and mobile devices one at a time. This does not trigger the performance issues seen with PI-004957, but this can get tedious if you have multiple devices to delete. To help with this, I’ve adapted an earlier script written by Randy Saeks to help automate the deletion process by using a list of Jamf IDs and the API to delete the relevant computers or mobile devices one by one. For more details, please see below the jump.

I’ve adapted Randy’s original script into two scripts, one for deleting computers and the other for deleting mobile devices. Both scripts work with a text file of Jamf Pro IDs, and also include error checking to make sure that the text file’s entries contained only positive numbers.

To use these scripts, you will need four things:

  1. A text file containing the Jamf Pro computer or mobile device IDs you wish to delete.
  2. The address of the appropriate Jamf Pro server
  3. The username of an account on the Jamf Pro server which has the necessary privileges to delete computers and/or mobile devices.
  4. The password to that account.

The test file should contain only the relevant Jamf Pro IDs and its contents should appear similar to this:

Once you have the text file and the other prerequisites, the scripts can be run using the following commands:

To delete computers:

/path/to/delete_Jamf_Pro_Computers.sh /path/to/text_filename_here.txt

To delete mobile devices:

/path/to/delete_Jamf_Pro_Mobile_Devices.sh /path/to/text_filename_here.txt

For authentication, the scripts can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

Screen Shot 2018 05 19 at 3 45 57 PM

It is also possible to simulate a run of the script, to make sure everything is working before running the actual deletion. To put the script into simulation mode, comment out the following line of the script.

Screen Shot 2018 05 19 at 10 57 20 AM

To take it out of simulation mode, uncomment the line.

Screen Shot 2018 05 19 at 10 57 49 AM

In simulation mode, you can test out if the script is reading the text file properly and the authentication method. For example, the following output should be seen in simulation mode if the text file is being read properly and manual input is being used.

Screen Shot 2018 05 19 at 3 20 18 PM

The following output should be seen in simulation mode if the text file is being read properly and the needed values are being read from a ~/Library/Preferences/com.github.jamfpro-info.plist file.

Screen Shot 2018-05-19 at 11.09.52 AM

The scripts are available below, and at the following addresses on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Computers

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Mobile_Devices

delete_Jamf_Pro_Computers.sh:

delete_Jamf_Pro_Mobile_Devices.sh:

Upgrading from ESXi 6.5 to ESXi 6.7 via SSH and esxcli

Following VMware’s release of ESXi 6.7, I upgraded my ESXi 6.5 server to ESXi 6.7 using SSH and esxcli. For those interested, see below the jump for the details of the process I used.

Screen Shot 2018 05 15 at 3 31 55 PM

To upgrade from ESXi 6.5 to 6.7 using esxcli

 

1. Shut down all VMs running on your ESXi host machine.

2. Enable SSH on your ESXi server, if it is not already enabled.

3. Connect via SSH.

Screen Shot 2018 05 15 at 2 59 08 PM

4. Once logged in, run the following command to enter maintenance mode:

vim-cmd /hostsvc/maintenance_mode_enter

 

Screen Shot 2018 05 15 at 3 00 20 PM

 

5. After putting ESXi into maintenance mode, run the following command to set the correct firewall rules for the httpClient:

esxcli network firewall ruleset set -e true -r httpClient

 

Screen Shot 2018 05 15 at 3 01 06 PM

 

6. Next, run the following command to list the ESXi 6.7 updates available. You want the latest one that ends in -standard for your version of VMware.

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6.7

 

Screen Shot 2018 05 15 at 3 03 39 PM

 

7. Once you’ve identified the correct version of VMware (as of 5-18-2018, this is ESXi-6.7.0-8169922-standard), run the following command to download and install the update.

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.7.0-8169922-standard

 

Screen Shot 2018 05 15 at 3 45 50 PM

 

Note: It is very important that you run esxcli software profile update here. Running esxcli software profile install may overwrite drivers that your ESXi host needs.

 

8. Once the update has been installed and prompts you to reboot, run the following command to restart:

reboot

 

Screen Shot 2018 05 15 at 3 46 57 PM

9. After your ESXi host restarts, connect via SSH and run the following command to exit maintenance mode:

vim-cmd /hostsvc/maintenance_mode_exit

 

Screen Shot 2018 05 15 at 3 49 38 PM

 

At this point, your ESXi host should be upgraded to ESXi 6.7.0.

Screen Shot 2018 05 15 at 3 50 44 PM

Detecting if a logged-in user on a FileVault-encrypted Mac has a Secure Token associated with their account

A challenge many Mac admins have been dealing with is the introduction of the Secure Token attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume.

In my own shop, we wanted to be able to identify if the primary user of a Mac had a Secure Token associated with their account. The reason we did this was:

  1. We could alert the affected help desk staff.
  2. We could work with our users to rebuild their Macs on an agreed-upon schedule where their data was preserved.
  3. We could hopefully avoid working with our users on an emergency basis where their data could be lost.

To help with this, we developed a detection script. For more details, please see below the jump.

This script checks for the following:

  1. If the Mac is running 10.13.x or later.
  2. If the boot drive is using Apple File System (APFS) for its filesystem.
  3. If FileVault is enabled or not.

If the Mac passes the following checks:

  • Running 10.13.0 or later
  • The boot drive is using APFS
  • FileVault is enabled

Then the following action takes place:

  1. The logged-in user is checked to see if it can be determined.
  2. If it can be determined and it is not the root user, the sysadminctl tool is used to check to see if the account has the Secure Token attribute associated with it.

If the logged-in user account should have a Secure Token attribute associated with it and does not, the script will report the following:

1

Any other outcome, the script will report the following:

0

The script is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/detect_missing_secure_token

A complementary Jamf Pro Extension Attribute is available at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/detect_missing_secure_token

iMac : la rupture d’Apple

Il fallait vraiment avoir la foi pour croire au retour possible d’Apple en mai 1998. Steve Jobs a repris les rênes de la société depuis moins d’un an, et il a mis en chantier un plan ambitieux, axé durant les premiers mois autour de l’image de la marque, et de Mac OS (pas encore macOS), son joyau. Apple n’avait pas encore cependant marqué les esprits, et Mac OS X n’existait alors que virtuellement, le chantier de l’adaptation de NextSTEP au Mac ayant à peine commencé. La seule grande raison pour laquelle Apple avait fait parler d’elle quelques mois auparavant dans les médias, c’était lorsque Bill Gates avait daigné mettre 150 millions de dollars dans la boite (« Microsoft rachète Apple »), en actions sans droit de vote. Ce qui a permis surtout d’étouffer les procès en cours…

Mais il manquait une vraie annonce, capable de marquer durablement les esprits. Un produit capable de remettre Apple au centre de la scène. Capable de créer une déflagration.

IMac

L’iMac a été cette déflagration. Un vrai choc. Son annonce a été scrutée, analysée, disséquée. C’était un produit clivant, mais capable aussi de rassembler. Sa couleur (le fameux Bondi Blue, du nom de la plage de Bondi en Australie) ne laissait jamais indifférent

Je me souviens des débats sans fin sur fr.comp.sys.mac autour de cette annonce, de ce produit fou, sorti de nulle part, ressemblant à aucun autre. Et surtout de la rupture technologique qu’il a constitué, avec un processeur G3 performant, et l’abandon de technologies historiques comme l’ADB ou le port série, ou encore le SCSI, et l’adoption de l’USB, standard émergeant de l’époque. La fin du syndrome NIH : Not Invented Here. Des choix très critiqués à l’époque, mais finalement justifiés et qui ont permis à Apple de se relancer. Et puis, le début de la fin pour le lecteur de disquettes, alors que les clés de stockage USB n’étaient même pas un concept pour l’époque.

C’était aussi le vrai retour d’Apple sur le marché grand public et dans l’éducation, avec un ordinateur doté d’un port Ethernet (très rare en standard à l’époque), et d’un modem 33,6k en standard. Ce point avait tellement fait râler qu’Apple l’a corrigé avant la sortie de l’iMac, en intégrant finalement un modem à 56k, plus dans l’air du temps.

L’iMac a créé une rupture technologique et une rupture financière avec la fin du cycle infernal des baisses des ventes (il me semble qu’il n’y a eu ensuite qu’un ou deux trimestres où elle a vraiment bu la tasse ensuite, pas merci le G4 Cube…).

Mais surtout, l’iMac a créé une rupture émotionnelle, avec l’arrivée d’un ordinateur vraiment design, en rondeur, un véritable OVNI (« it comes from another planet… a good planet, with better designers, ajoutera-t-il malicieusement) dans le triste design industriel de l’époque. C’était la véritable arrivée de Johnny Ive aux commandes de l’Apple Industrial Design Group.

Qu’on l’aime ou pas, l’iMac aura été le symbole pour Apple d’un retour sur le devant de la scène, de sa renaissance, et le terme n’est pas trop fort. Et il est toujours amusant de constater qu’il s’agit sûrement du seul produit Apple à n’avoir jamais changé de nom depuis 20 ans, malgré ses différentes itérations qui l’ont petit à petit éloigné du concept original dans la forme, mais pas dans le fond : un ordinateur tout-en-un, pour tous.

Alors, joyeux anniversaire iMac. Le monde (et Apple) aurait été un peu moins sympa sans toi.

Et si vous avez envie d’en savoir plus sur le design des produits Apple, vous pouvez revoir ma conférence « Apple et le design », où je parle de l’iMac à partir de 24:30.

Oracle Java 10 JDK and JRE installation scripts for macOS

Oracle has started to release Java 10 for macOS, so I’m posting a couple of scripts to download and install the following:

Oracle has been releasing two separate versions of Java 8 simultaneously and may do the same for Java 10, so these Java 10-focused scripts are designed to allow the user to set which version they want to install: the CPU release or the PSU release.

The difference between CPU and PSU releases is as follows:

  • Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
  • Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.

For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, please see below the jump.

The scripts are available on GitHub via the links below:

Oracle Java 10 JDK: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jdk_10
Oracle Java 10 JRE: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jre_10

The scripts are also available as payload-free packages, compressed and stored as .zip files in the payload_free_package directory available via the links above.

Oracle Java 10 JDK script:

The script below will download a disk image containing the latest version of the Java 10 JDK from Oracle and install the JDK using the installer package stored inside the downloaded disk image.

How the script works:

  1. Verifies that the Mac is running a Java 10-compatible operating system
  2. Uses curl to download a disk image containing the latest Java 10 JDK installer from Oracle’s web site
  3. Renames the downloaded disk image to java_ten_jdk.dmg and stores it in /tmp.
  4. Mounts the disk image silently in /tmp. The mounted disk image will not be visible to any logged-in user.
  5. Installs the latest Java 10 JDK using the installer package stored inside the disk image.
  6. After installation, unmounts the disk image and removes it from the Mac in question.

Oracle Java 10 JRE script:

The script below will download a disk image containing the latest version of the Java 10 JRE from Oracle and install the JRE using the installer package stored inside the downloaded disk image.

How the script works:

  1. Verifies that the Mac is running a Java 10-compatible operating system
  2. Uses curl to download a disk image containing the latest Java 10 JRE installer from Oracle’s web site
  3. Renames the downloaded disk image to java_ten_jre.dmg and stores it in /tmp.
  4. Mounts the disk image silently in /tmp. The mounted disk image will not be visible to any logged-in user.
  5. Installs the latest Java 10 JRE using the installer package stored inside the disk image.
  6. After installation, unmounts the disk image and removes it from the Mac in question.

Quand la Freebox bloque les accès aux services Apple

Un de mes clients a constaté un souci étrange : impossible depuis chez lui de se connecter à l’ensemble des services d’Apple : App Store, iTunes Store, etc… tous répondent aux abonnés absents !

La solution n’était pourtant pas très difficile à trouver : c’était le bloqueur de pub intégré à sa Freebox qui faisait des siennes… Pensez donc à désactiver cette option dans les réglages de votre Freebox pour retrouver éventuellement un accès correct aux services Apple depuis votre Mac.

32-bit application alert message in macOS 10.13.4

Starting on April 12, 2018, Macs running macOS 10.13.4 will display a one-time alert when 32-bit applications are opened. This alert will appear once per user account on the Mac, when a relevant 32-bit application is opened.

Screen Shot 2018 04 12 at 12 02 17 AM

When the Learn More… button in the alert window is clicked, the following Apple KBase article opens in your default web browser:

32-bit app compatibility with macOS High Sierra 10.13.4
https://support.apple.com/HT208436

Screen Shot 2018 04 12 at 12 04 34 AM

 

For those who need to stop this alert from being displayed in their environments, I’ve built a management profile to suppress the warning. It is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/Disable32BitApplicationWarning

Whitelisting third-party kernel extensions using profiles

As part of macOS 10.13.2, Apple introduced the concept of User Approved MDM Enrollment (UAMDM). UAMDM grants mobile device management (MDM) additional management privileges, beyond what is allowed for macOS MDM enrollments which have not been “user approved”.

As of macOS 10.13.4, the only additional management privilege associated with UAMDM is that it allows you to deploy a profile which provides a whitelist for third-party kernel extensions. This profile allows a company, school or institution to avoid the need to have individual users approve the running of approved software.

Without the profile, third-party kernel extensions will need to be approved through the User-Approved Kernel Extension Loading (UAKEL) process. Here’s how that process looks:

1. When a request is made to the OS to load a third-party kernel extension which the user has not yet approved, the load request is denied and macOS presents an alert to the user.

Screen Shot 2018 04 11 at 9 16 13 PM

2. The alert tells the user how to approve the loading of the kernel extension signed by a particular developer or vendor, by following this procedure:

A. Open System Preferences
B. Go to the Security & Privacy preference pane

Screen Shot 2018 04 11 at 9 20 45 PM

C. Click the Allow button.

Screen Shot 2018 04 11 at 9 20 22 PM

Note: This approval is only available for 30 minutes. After that, it disappears until the following happens:

i. The Mac restarts
ii. Another attempt is made to load the kernel extension.

Screen Shot 2018 04 11 at 9 20 25 PM

While waiting for the kernel extension to be approved, a copy of the kernel extension is made by the operating system and stored in the following location:

/Library/StagedExtensions

Once approved, another copy of the kernel extension is made and allowed to load.

Screen Shot 2018 04 11 at 9 19 39 PM

This process is relatively easy for an individual to manage on their own computer, but it would be very difficult to manage when dealing with more than a handful of Macs. To help companies, schools and institutions, Apple has made a management profile option available to centrally approve third-party kernel extensions. For more details, please see below the jump.

To help whitelist all kernel extensions from a particular vendor or whitelist only specific ones, Apple has made two sets of identifying criteria available:

  • Team Identifier
  • Bundle Identifier

Team Identifier

A team identifier is a alphanumeric string which appears similar to the one shown below:

7AGZNQ2S2T

It appears to use a developer or vendor’s Developer ID for Signing Kexts certificate identifier. This certificate would be used by a developer or vendor to sign all or most of their kernel extensions.

Whitelisting using the Team Identifier has the advantage of being able to whitelist multiple third party kernel extensions from a specific developer or vendor. This capability allows Mac admins to identify a particular developer or vendor as being trusted in their environment and have all of the relevant kernel extensions be allowed to load by the whitelist.

Note: The UAKEL process appears to use team identity when approving kernel extensions, which potentially allows multiple kernel extensions to be approved at once.

Bundle Identifier

The Bundle Identifier is specific to a particular kernel extension. It is contained in the Info.plist file stored inside each kernel extension.

Screen Shot 2018 04 11 at 9 36 00 PM

Whitelisting using the bundle identifier allows the Mac admin to get very granular about which kernel extensions from a specific developer or vendor are approved and which are not. If using the bundle identifier as part of the whitelist, both the Team Identifier and the Bundle Identifier need to be specified in the profile.

To help Mac admins, a community-written Google Doc spreadsheet is available here which lists various team identities and their associated bundle identifiers:

https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit?usp=sharing

(Hat tip to Contains_ENG for creating the document and developing a script to detect the relevant kernel extension info.)

Using Team Identifier by itself in a third-party kernel extension whitelist profile

If you want to use only the Team Identifier when whitelisting kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

Screen Shot 2018 04 11 at 7 44 53 PM

Screen Shot 2018 04 11 at 7 44 57 PM

Using Team Identifier and Bundle Identifier in a third-party kernel extension whitelist profile

If you want to use both Team Identifier and Bundle Identifier when whitelisting specific kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

Screen Shot 2018 04 11 at 7 39 07 PM

Screen Shot 2018 04 11 at 7 39 13 PM

If you’re using Jamf Pro to deploy a third-party kernel extension whitelist profile profile, it should appear as a built-in profile option. Here’s how it should appear if using only team identifiers:

Screen Shot 2018 04 11 at 7 25 19 PM

Screen Shot 2018 04 11 at 7 41 10 PM

If using both team identities and bundle identifiers:

Screen Shot 2018 04 11 at 7 25 19 PM

Screen Shot 2018 04 11 at 7 25 29 PM

Reclaiming drive space by thinning Apple File System snapshot backups

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

Screen Shot 2018 04 07 at 2 04 39 PM

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

The tmutil command line tool on macOS High Sierra includes a thinlocalsnapshots function, which has the options shown below:

tmutil thinlocalsnapshots mount_point [purge_amount] [urgency]

Purge amounts are represented as bytes, so specifying 20 gigabytes of space would be represented by the number below:

21474836480

Urgency levels are 1 through 4, with the default urgency setting being 1.

Urgency level 4

Most urgent: Any current backup processes are stopped and thinning is performed immediately. The largest available backup will be the first thinned, with thinning proceeding through the next largest backups.

Urgency level 1

Least urgent: Current backup processes will be completed before the thinning process begins. The oldest available backup will be thinned first, with thinning proceeding through the next oldest backups.

To free up 20 gigabytes of space from the snapshots stored on the boot drive at maximum urgency, you would use the command shown below:

tmutil thinlocalsnapshots / 21474836480 4

The command may take a while to run, depending on what would need to be done to free up the requested space.

Note: The thinning process may actually free up more than the requested space, but it should free up the requested space as a minimum if the stored snapshots are taking up at least that amount of drive space.

Before snapshot thinning

Screen Shot 2018 04 07 at 2 02 44 PM

Snapshot thinning

Screen Shot 2018 04 07 at 2 05 37 PM

After snapshot thinning

Screen Shot 2018 04 07 at 2 06 13 PM

 

Quand Word 2016 refuse de se lancer

La dernière version en date de Word 2016 16.11.18031100  souffre parfois d’un problème curieux, vécu chez deux de mes clients sur certains postes : l’impossibilité de lancer le logiciel, qui semble attendre quelque chose qui ne vient jamais. Il rebondit dans le Dock, puis s’arrête. Et aucun message d’erreur. Réinstaller Office ne fait rien, pas plus que nettoyer les caches ou supprimer les préférences de Word.

Solution trouvée sur le canal Microsoft-Office de Macadmins sur Slack : 

– Fermez toutes les connexions réseau en déconnectant le câble Ethernet ou en coupant le Wi-Fi ;

– Lancez Word ;

– Reconnectez le réseau.

Testé et approuvé, et sûrement corrigé dans une version future. Pas impossible cependant que le bug revienne de temps en temps de façon aléatoire.