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:

(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.
(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
(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
(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.

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:

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:

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:

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:

London Apple Admins, Mac Admin

Using Adobe Creative Cloud Packager to create an uninstaller in preparation for Adobe Creative Cloud 2019 Shared Device License deployment

Hi All. So I was thinking….what’s the longest blog title I can legitimately use?

On a serious note, as part of most Adobe CC2019 deployments you’ll want to remove any previous Adobe Applications you have installed. Additionally, this is required if you’re moving from Device Licensing (Legacy – aka DL), to Shared Device Licensing (SDL) and CC2019.

If, when building your deployment packages, you kept the matching uninstaller packages, you can use these to uninstall the specific versions of your Adobe products.

You can also use the installed Command Line Tool to uninstall products, as long as you can look up the specific sapCodes and baseVersions (more info).

However, not everyone has kept these packages or fancies digging around the CLI tool. Or maybe you’re not sure exactly what versions of Adobe products you have installed on your fleet, and just want to remove them all. In that case, this post might be of help to you!

Please Note: Adobe Creative Cloud Packager (CCP) is not compatible with CC2019 and so you could argue it’s days are numbered! While the tool is still available, feel free to utilise it as required.

Downloading and ‘Installing’ Adobe Creative Cloud Packager

So first of all, let’s cover getting a copy of the Adobe Creative Cloud Packager (CCP). If you already have a copy installed, launch this from your Mac from the location /Applications/Utilities/Adobe Application Manager/CCP/CreativeCloudPackager.app and skip this section.

If not, read on:

1) Navigate to the Adobe Admin console at https://adminconsole.adobe.com

2) Login with an Adobe Admin ID who has access to your portal

3) Click “Packages” then “Tools” and then “Download for Mac” in the “Creative Cloud Packager” section

4) Once downloaded, mount the “CCPLauncher” disk image and open the “CCPLauncher” App inside

5) The App will firstly download the most up to date version of the CCP App, then ask for Admin rights to install this on the local device.

6) Once finished up, the launcher will also open the main CCP App. For future usage, you can launch this directly on this Mac from /Applications/Utilities/Adobe Application Manager/CCP/CreativeCloudPackager.app

Generating an Adobe Uninstaller

1) Once you’ve got the CCP App open, you’ll need to review the Software License Agreement. If you’re happy with these terms, click “Accept”

2) On the product selection screen, select the product your institute has purchased. In this example, I’ve gone for the lower section.

3) The CCP App will relaunch and you’ll need to log into an Admin Adobe ID. Do this and click “Sign in”. The CCP will do some background work that can between a few seconds, and up to 15 minutes (in one rare instance!)

4) Shortly, you should be back at a more…responsive page. This will show a warning that CCP is not for CC2019 usage. Scroll down until you can see a section called “Create Uninstall Package”. Click this.

5) Give your uninstall an appropriate name and an output location. Click “Next”

6) Now you get a chance to select the Apps you’d like to remove via this tool. If you expand a product section (in this example Photoshop), you can pick specific versions of the Adobe Apps to remove.

7) If you’re only concerned with removing all older Adobe versions, check the “Select All” box and click “Build”

8) After a few seconds, the CCP App will complete the Uninstaller build and output the result to the location you specified in step 5

9) The output of this won’t actually be an installer package, but rather a binary and an XML Config file

Using the CCP Uninstaller Output

So, you’ve done all this work, and all you got was a lousy ~~T-Shirt~~ binary and config file! The last part of the puzzle is using these to carry out the removals.

The binary file is a CLI tool (more info) that is used to complete the uninstall task/s. The syntax for this is (all on one line):

/path/to/AdobeCCUninstaller --uninstallConfigPath=/path/to/AdobeCCUninstallerConfig.xml

My suggestion would be to create a new macOS Installer Package that adds the above folder to /private/tmp/, then runs a post-install script with the above command.

In our example, this would be /private/tmp/Adobe\ Uninstall\ all\ non-CC2019\ Apps/AdobeCCUninstaller \

--uninstallConfigPath=/private/tmp/Adobe\ Uninstall\ all\ non-CC2019\ Apps/AdobeCCUninstallerConfig.xml).

This new package can then be deployed by your management / deployment system of choice before you roll out your CC2019 Apps and SDL packages.

One last note, I did have two Apps left behind when I used this method, Adobe Scout and the Adobe Gaming SDK. I ended up writing a post-install / task script utilising the rm -R /path/to/App command to removing this two Apps.

Summary

This post covers using CCP to create an uninstaller solution for all currently installed Adobe CC Apps prior to a CC2019 SDL rollout. 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:

London Apple Admins, Mac Admin

Using AutoPKGr with a Jamf Cloud Distribution Point

Hi all.

One of the good things I like with performing Jump Starts is the variety of customer I get to work with. This includes a whole host of requirements and environments, along with various levels of ability and experience. With more experienced customers we typically have time to look into other areas outside a Jump Start that may benefit the solution and the customer as a whole. One such example was trying to get the great AutoPKGr to work with a Jamf Cloud Distribution Point (JCDS).

Backstory

Firstly a little backstory, AutoPKG / AutoPKGr utilises the amazing JSSImporter plugin in order to talk to your Jamf Pro server, map the File Share Distribution Points and upload the packages (as well as creating the policies and smart groups etc).

When Jamf released support for a Cloud Distribution Point, they also provided an interface (via the Web GUI or Admin App) to upload into an included Jamf Cloud Distribution Point (with the backend hosted in Amazon S3 buckets).

As this was included in a Jamf Cloud subscription, a lot of customers utilised this for package deployment, however this was incompatible with the JSSImporter tool.

This meant that any admins who wished to utilise both AutoPKGr and a JCDS would need to manually upload the new packages after each run.

On a recent Jump start I explored this with a customer and found out this is no longer the case. There is a beta version of the JSSImporter plugin that will work with JCDS!

Ok, it is a beta tool, and as such could always do with more testers, but you may find it suits your needs as-is. There are reports that it needs further tweaks for some admins and not for others. In my experience it tends to work fine as-is, although there’s a small time delay for the changes to show in the Jamf Cloud instance.

Setting up AutoPKGr to use the beta JSSImporter

I’ll assume you have AutoPKGr currently setup on a Mac, mostly configured and you’re familiar with AutoPKG and AutoPKG recipes.

1) Launch AutoPKGr, go to the “Folders & Integration” tab and click “Install JSSImporter…”

2) Follow the on-screen instructions to get the plugin installed. You can confirm that the plugin is installed on the “Install” page

3) Once complete, quit AutoPKGr

4) Fire up your web browser of choice and go to https://github.com/jssimporter/JSSImporter/releases

5) Find the “Bundled Dependency Testing” pre-release (version 1.0.2b2) and download the installer package here

6) Run the installer on your AutoPKGr Mac. Once complete, relaunch AutoPKGr. You’ll notice that the JSSImporter will still show as v1.0.0. This is normal and expected.

7) Go back to the “Folders & Integration” tab, click “Configure JSSImporter” and fill in your Jamf Cloud URL as well as your API username and password (recommendations for this account can be found here).

8) Click “Connect” to test the connection, then “Add Distribution Point”

9) Select “CDP” for the type and click “Add”

10) Click “Save and Close” to save these details

11) Continue the remaining setup requirements in your Jamf Pro Server (“Testing” static Computer Group etc – https://github.com/autopkg/jss-recipes#requirements-and-configuration)

12) Run some test runs with .jss recipes to ensure the packages are uploaded fine, the policies are created, the smart groups are made etc. Then you’re good to go!

More Information

More information can be found here:

Summary

This post covers how to setup AutoPKGr to use a beta JSSImporter plugin to work with a JCDP. 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:

	dazwallace on Firefox Configuration Profile…
	Montys mac musings on Firefox Configuration Profile…
	Weekly News Summary… on Grabbing packages out of Jamf…
	dazwallace on Grabbing packages out of Jamf…
	Nic on Grabbing packages out of Jamf…