London Apple Admins, Mac Admin

Adobe CC2019 in Education – PSU 2019

Hi all,

If I time this right, this post should be going live about halfway through my talk at PSU on Adobe CC2019 and Shared Device Licenses in Education.

This talk is an extension and expansion of my previous meet up talk Moving out of the Pool: Adobe’s new Shared Device Licensing.

Video

The session is being recorded and so once the Video is live, I’ll add a link in here.

Slide-deck

deployment-considerations-and-workflows-for-adobe-cc2019-in-education-1.3-1.pdf

Attendee Notes

Massive thank to Nate Felton, there’s a Google Doc provided to attendees to allow them to make notes on the session. I’ve linked this here.

Links

As promised, here is a list of all the links from the presentation:

Aaand follow ups I suggest reading / viewing when you get the chance:

Standard
Mac Admin

The Great Adobe Purge of ’19

Earlier today, the #adobe MacAdmins Slack channel was awoken from it’s afternoon/morning slumber with the following message:

Shortly afterwards, I myself, along with other Adobe customers received the same email that can be found here

What does it mean?

Adobe have informed its customers that certain versions of certain Adobe applications are not longer part of any license. If you continue to use these unauthorised versions, you run the risk of claims of infringement by third parties.

Adobe have requested that you update or remove & upgrade (depending on how far behind you are) any unauthorised versions of software you have in your fleet. They also request you delete and (if possible) recreate any deployment installers for the affected versions.

Finally, Adobe will now only offer the latest two releases for applications via their packaging tools and the Creative Cloud Desktop App.

Which applications are these?

Adobe provided the below table:

As mentioned in the #adobe channel, the Product Versions do not match the Creative Cloud Marketing versions they ship with!

Take Photoshop, for example:

  • Photoshop version 20.x is from Adobe Creative Cloud 2019
  • Photoshop version 19.x is from Adobe Creative Cloud 2018

Patrick Fergus (@foigus) made a brilliant new table with the Official Marketing names as well as the applications numbers which should help Admins:

Why?

At this point Adobe haven’t specified why this new requirement has come about. There was an incident a few years ago where they lost a case around Dolby Labs’ copyrighted materials (link) but this doesn’t seem related.

It could be to do with the new Java requirements announced by Oracle earlier this year, since a number of the Adobe products have in the past utilised the local Java runtime.

At this point in time, who knows?

Credit

Credit goes to Eric Holtam and Parick Fergus along with everyone else in #adobe who shared and discussed the above!

Summary

This post covers the changes Adobe announced earlier today in regards to older versions of their Applications. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
Mac Admin

Mass-Deploying Settings for Atom

Hi all. This one came from a discussion during a recent training course I attended. How could we deploy settings for Atom, without overwriting any settings configured by the user? Things like suppressing first run messages, and disabling auto-update?

Firstly, some detective work…

The Atom application stores it’s configuration and data files in a hidden folder, in each user’s home area at ~/.atom/

Most (if not all) of the configuration settings are stored in a file called config.cson in this directory. This includes core application settings, as well as settings for any installed packages. Forcing this file to open in a text editor shows what appears to be very similar to (but not quite) a JSON file:

This is actually a CSON (CoffeeScript Object Notation) file as detailed by the Atom developers here.

Why not just set the file up and push out to all users?

In theory, this would indeed work (assuming you deploy the file with the parent directory, and permission it appropriately), but would also wipe out any settings configured by the end user. Not ideal or user friendly!

Ok, so how can we pre-configure these settings?

My first thoughts here were to write a Bash script to work on the file, adding the configuration into whatever settings were already present. After struggling for an hour or so with this, it was pointed out that Atom supports a ‘start up’ script for configuration via the application APIs, an init.coffee file!

An init.coffee file?

Yup, this is a file located in the same ~/.atom/ directory, with the name init.coffee. The file contains configuration commands in the format:

atom.config.set('[package].[key]', '[value]')

For example, the below will suppress the welcome screen at startup:

atom.config.set('welcome.showOnStartup', 'false')

I’ve built a full example init.coffee file that will:

  • Suppress the welcome screen on launch
  • Turning auto-update off (ensure to patch via other methods!)
  • Setting Telemetry consent to no and suppress the request.

That example file can be found here.

What else can the init.coffee file do?

To be honest, I didn’t delve too much further than this. I do know you can configure options for other packages (such as enabling the indent guide in the git-editor package), however check out the Atom developer documentation for more details.

So how can I deploy the init.coffee file?

So this init.coffee file will need to be:

  • Added to each user’s home area
  • Added to a directory called .atom at the root of the user’s home area
  • At least readable by the user account

You have a few options for this, depending on the toolset available, and personal preferences:

  1. (If you’re a Jamf customer) – Create the file in-place, package as a disk image via Jamf Composer and deploy with FEU (Fill Existing Homes) and optionally FUT (Fill User Templates) enabled.
  2. (If you use Outset) – Package up the file to be deployed somewhere local, and have a ‘login once’ or ‘login always’ script to copy the file into place
  3. (If you’re happy writing a LaunchAgent) – Package up the file to be deployed somewhere local, and have a Launch Agent triggered script to copy the file into place
  4. (If you’re lazy!) – I’ve written up a script that can be found here. This creates the directory and writes the file out to all home folders in /Users/and all User Template folders in /System/Library/User Template. This can be triggered as a script in a Jamf policy, a Munki post-install script or a traditional postinstall script in an installation package!

Summary

This post covers a possible method for pre-configuring some helpful Atom settings for your deployment. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
London Apple Admins, Mac Admin

Firefox Configuration Profile Support

Hi all. This week I’ve been mostly recovering from coming down from the fun that was the MacADUK conference (that my employer helped curate and direct). On the last day I bumped into Mike Kaply, on his second MacADUK speaker engagement.

Some Background…

Mike may be familiar to some of you as the developer of the great Firefox Client Customisation Kit v2 (or CCK2). This tool allowed you to create a management configuration using a nice clickable GUI, instead of editing a large number of various files and key/values. The tool could then spit out an extension (that could be installed in your Firefox deployment), or a Zip file (that could be injected in your Firefox App bundle) to control a whole host of options.

I still remember spending many hours (many years ago) manually carrying out this work (which can be found with a previous-previous-employer here). With the discovery of Mike’s CCK2 solution, that workload reduced significantly. Combined with Greg Neagle’s Firefox AutoPKG recipe, it pretty much vanished!

Mike eventually moved to a more ‘in-house’ role with Firefox but still remained active in the Firefox community, including with us admins. One of the key requests that many of us still had was “proper” macOS native management tool support (e.g. Configuration Profiles)!

The Goodness!

With my own roles and employers changing, I lost track of the progress but it turns out Mike and the team got it all working with Firefox version 64!

Support is with both the (current at time of writing) mainstream Firefox release as well as the ESR. No more injecting files into the Application Bundle!

Details of the various settings and keys can be found here, however, Mike has strongly suggested, instead of building your own profiles by hand, use the great (and free) Profile Creator tool from Erik Berglund to generate your Firefox configuration profiles.

Examples!

This weekend I had a play around with some profiles and created the following 3 examples that show you what you can do. For reference, all three were tested on Firefox version 66.0.2 and Firefox ESR version 60.6.1esr:

Setting the Homepage

This profile sets Firefox to open the Homepage when opening a new tab, sets the homepage to https://datajar.co.uk and locks this setting to prevent the user from changing it.

Firefox – Set Homepage.mobileconfig

Disabling Auto-update

This profile disables Firefox’s built-in auto-update option (please ensure to patch Firefox often via an alternative system, as you should with all web browsers).

Firefox – Disable Autoupdate.mobileconfig

This is how this appears in the About menu for both Firefox and Firefox ESR

Firefox with auto-update disabled
Firefox ESR with auto-update disabled

Generic Lab Setup

This last one is a bit more interesting. It contains a whole heap of settings that I personally feel may be ideal for a lab environment, including (but not limited to):

  • Homepage set (same as above)
  • Auto-update disabled (same as above)
  • Add-ons and profiles disabled
  • Default browser check disabled
  • First run and recently updated pages disabled
  • Default bookmarks removed
  • Proxy set (and locked) to use the macOS system proxy settings

Firefox – Lab setup.mobileconfig

Summary

This post covers a much better way to manage Firefox settings, and keeps it in line with other fully-macOS support tools. Big thanks to Mike and his team for all their work and the MacADUK team for putting on a great conference! As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
London Apple Admins, Mac Admin

Configuring Azure SSO in Jamf Pro – A Better Way?

Hi All. Time for another post from the tales of an Integrator!

This time I was helping a customer integrator Azure Active Directory with Jamf Cloud for SSO/SAML. Now Jamf has a number of KB articles on the matter but there’s always a window between the last time these are updated and when an IdP vender makes some changes. Additionally, sometimes it’s helpful to utilise a guide written from a different prospective to get a better understanding.

A New Hope Guide

After searching around for updated guides and more information, I stumbled across a new guide from Microsoft themselves. This can be found here

Tutorial: Azure Active Directory integration with Jamf Pro

Why is this better?

Well, firstly it should be more current with the Azure specific options (since both the KB and Azure are under Microsoft’s control).

Secondly, was this little gem I found part-way through:

That’s right! you can install a Microsoft browser extension that will automatically configure the SSO settings in your Jamf Cloud console with the right options!

This should speed up the process, as well as reduce mistakes and miss-configurations!

I’m afraid there doesn’t seem to be an extension for Safari, so you’ll have to use Chrome or Firefox. If anyone has a chance to test with IE and Edge, let me know and I’ll update the post.

I’ve also included links to the Jamf KBs below:

Summary

This post covers a different (arguably better) way to setup Azure SSO with Jamf Pro. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
London Apple Admins, Mac Admin

Grabbing packages out of Jamf Cloud DP

Hi All,

This is something I’ve seen crop up in Slack a few times recently so I thought I’d write something up! When you upload packages, is there a built-in method to grab a copy of those installers out of a Jamf Cloud Distribution Point (JCDP)?

Grabbing those Packages

With a traditional File Share Distribution Point (FSDP) you could simply mount the File Share, or go via the host server OS and grab whatever packages you require.

Currently, there is no official method for re-grabbing packages you upload to a JCDP (at least not yet?). An ongoing suggestion would be to ensure you keep a copy of packages you upload to a JCDP somewhere locally. But that’s not gonna help you if you’ve already got stuff already uploaded.

The How

1) Grab a Mac or a VM you have enrolled in your Jamf Instance

2) Create a new policy, and add this device to the scope

3) Using the “Package” section, add the package you need a copy of.

4) Ensure to select “Cache” from the “Action” drop down menu

5) Run the policy on your Mac from step 1. This can be via a Self Service policy, recurring check in trigger or a manual trigger

6) Once the policy has run (successfully!), open up Terminal on the Mac. Switch to root / sudo.

7) Use the cd command to navigate to /Library/Application Support/JAMF/Waiting Room/

cd /Library/Application\ Support/JAMF/Waiting\ Room/

8) If you run an ls command here, you should see your package cached locally

ls -al

9) Use the cp command to copy the installer package to your desktop folder

cp ./[package name] /Users/[username]/Desktop/

10) Change the permissions on the package to make it usable

chmod -R [username] /Users/[username]/Desktop/[package name]

11) There you go, the package should be on your desktop, ready for use elsewhere.

12) Delete the policy you create in step 2

13) Repeat the steps above for each package you need.

Feature Request Time!

Ok I’ll admit, this is rather long. If you agree, check out this Feature Request and get upvoting!

Summary

This post covered how to grab packages back out of your Jamf Cloud Distribution Point. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard
London Apple Admins, Mac Admin

Using Autopkg for package Uploads to Jamf Cloud only

Hi all, in a follow up to a previous post on using AutoPKGr with Jamf Cloud (Using AutoPKGr with a Jamf Cloud Distribution Point), I worked with a second customer on how to use the same system, but only to upload the packages. No smart groups, no policies, just the packages!

But….Why?

A fair question. If you wish to utilise the included Patch Management system you will need to upload packages ready to link them to software versions. As explained in the previous post, this could be a manual task.

Alternatively you can use the AutoPKG recipes to package and upload your software patches, but this will also include smart groups and policies (since this pre-dates the Jamf Patch Management system).

What if you could have the best of both worlds? What if you could use AutoPKG/r to package and upload software to your Jamf Cloud server , ready for you to link to your Patch Policies / Versions?

Turns out, you can!

How?

So to do this, I took an example .jss policy (in this case the Firefox one) and started removing the various Arguments keys until I found the minimum required. Turns out, it’s only one!

            <key>prod_name</key>
            <string>%NAME%</string>

That key alone will upload the package into your Jamf Cloud server without any of the Smart Groups or Policies. But, it will also upload it without a category, so if you need / want this, you’ll need the second key:

            <key>category</key>
            <string>CATEGORY GOES HERE</string>

The JSSImporter processor will automatically create this category if required, upload the package and set the category.

Please Note: In order to avoid confusion with already existing .jss recipes, I’d suggest using .jss-upload instead of .jss

How does that look?

Well altogether, the process section of the recipe looks as follows:

<key>Process</key>
<array>
    <dict>
        <key>Arguments</key>
        <dict>
            <key>category</key>
            <string>CATEGORY GOES HERE</string>
            <key>prod_name</key>
            <string>%NAME%</string>
        </dict>
        <key>Processor</key>
        <string>JSSImporter</string>
    </dict>
</array>

I’ve uploaded an example of the changes to a Firefox recipe here.

Summary

This post covers how to create an AutoPKG recipe to only upload packages to your Jamf Pro server. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Standard