Hello, and welcome to my session titled
Simplifying Application Management
Using Custom Schemas
In Configuration Profiles.
My name is Leonardo Cacioppo,
and I am an Apple endpoint engineer
at Argonne National Laboratory.
Prior to Argonne, I also spent
approximately eight years in education
in both K-12 and higher ed.
Today I'll be going over
some background information
on the historical methods
of configuring custom settings
for applications in Jamf Pro,
a few of the built-in options
that already exist,
using custom JSON schemas
to configure those settings
for applications that aren't built in.
And a brief introduction
to writing JSON schemas
for those applications.
So before Jamf Pro version 10.18,
the primary method for configuring custom
settings for applications was by uploading
a Plist file to Jamf Pro.
This was a common workflow for people,
but the one issue with it was that
whenever modifications or changes
needed to be made,
typically you had to re-upload
a Plist file to replace the one
that was already there.
Now, this meant that you would have to
either keep track of that Plist file
for uploading at a future date
or be able to reconfigure it pretty easily
in order to do that.
I want to give an example
of a Plist file
for those that may be unfamiliar.
A Plist, or a preference list,
is just a text file on macOS
that's displayed in XML
and contains preferences
for a given application.
For example, if you were to go into
an application like a web browser
and configure things like the homepage,
whether or not the application
were to auto update,
or any other things that you may modify
in the preferences of an application.
That application is likely writing out
those preferences
to a preference list file,
so that it can refer back to them
at a later time
when it needs to revert back to those
settings when you reopen the application.
Enforcing these via configuration profile
is just mandating those settings
for computers in your environment.
In here, you'll see that these are
just stored in arrays and keys.
And I want to point out
a few of these in particular,
so that we can refer and call back
to them later during the presentation,
to show the similarities
between a Plist and a JSON schema.
The first key I want to point out
is this ADDomain key,
which you'll see is stored
as a string value.
And the second one, this Deny local key,
you'll see it just has the word true
under it.
Sometimes you'll see just the word
true or false,
and sometimes you'll see this explicitly
defined as a Boolean value.
But again,
this is just a bit of formatting
that we're just trying to remember
for when we call back to it later.
Things started to change a little bit
in Jamf Pro version 10.18.
That was when the native
Office 365 management options
were built in to that Applications
and Custom Settings menu.
This process was great.
And now those settings for things
like Microsoft auto update
could be configured via this point
and click interface,
that made creating
and changing those settings very easy.
The feature further expanded
in Jamf Pro 10.19,
where not only did this feature exist
for Microsoft Office,
it also existed for a few
Jamf applications,
and also introduced the ability
to use custom JSON schemas.
So that you could upload or copy
and paste in a JSON schema,
and configure the settings
for any application that you wanted.
I was surprised
that I didn't know about this sooner.
So for a comparison,
I want to show you a snippet
from a JSON file, also for NoMAD login
like the original Plist file was.
Now this may look very different
from the XML view of the Plist file,
but they are largely focused
on the same data.
Under the properties section here,
you'll see that it has the exact same
ADDomain key,
which is again, shown as a string type.
And you'll see the Deny local key
also exists here defined as a Boolean,
that true false type.
Whether a setting is configured via
a preference list, whether it's done via
JSON, they're going to apply
in the same way.
The main difference here
is that using these
JSON schemas allows you to work
in a nice graphical user interface
within Jamf Pro,
to create and change those settings.
This especially becomes very user-friendly
if you have other non-technical users
changing those settings
for different applications.
In Jamf, we're going to have
a few different ways
of utilizing those JSON schemas.
We have the built-in options,
which include some Jamf Applications
and External Applications,
but those are the ones that won't exactly
show you the JSON behind the interface.
They are just automatically built in
to Jamf Pro.
And then we'll have the custom schemas,
which are the ones
that you can upload yourself.
In regards to built-in applications,
we'll start with the Jamf Applications.
Started by navigating to configuration
profiles and creating a new one
with a application
and custom settings payload.
We can click on Jamf Applications,
and then we can choose from the different
application domains that are available.
Currently that includes things
like Jamf Connect and Compliance Reporter.
Once we would select the application
domain, the version,
and the variant,
we'd be met with the point and click
interface to configure the settings
for that application.
Very similar to that,
we have the external applications,
but the ones that are built into Jamf Pro.
Again, started by going to creating
a new configuration profile one with
an application in custom settings payload.
But instead of Jamf Applications,
we would choose External Applications.
When choosing the source
of Jamf repository, we would see the ones
that are automatically built into Jamf.
This includes things like Google Chrome,
Microsoft Office,
and Microsoft Auto Update.
But again, after choosing the application,
the version, and the variant,
we get met with that point and click
interface for each of those
unique applications,
and the settings that are possible
to configure for them.
The one different one here
is this Custom Schemas option.
The setup of it is very similar
to the external applications.
The main difference is when you create
the custom settings payload
and go to external applications,
instead of Jamf repository,
you would choose custom schema,
and you would be met
with an add schema button.
From here, you could copy and paste
in the JSON file itself,
or you can upload the JSON file here.
There's plenty of applications
that you can do this for,
including NoMAD, Zoom,
Firefox, BBEdit, and many more.
Many of these applications already have
JSON schemas created by the manufacturer
or others in the community.
Once saving that screen, you get met with
that point and click interface.
You'll see here, I have a demonstration
of it with NoMAD login.
And you'll see the same keys
that we were defining in the Plist file
and in the JSON file earlier
are right here in nice form fields
and dropdown values.
That active directory domain shows up
as a fillable form field
that you can just type in
whatever the string is.
And the Deny local users has a dropdown
with the options of true and false
since that was configured
as a Boolean value.
The nice thing here is,
if any changes need to be made,
modifications, it's as easy as going back
into the configuration profile,
modifying those text fields or dropdowns
and saving the configuration profile.
You would then be prompted on if you want
to redeploy that out to your entire fleet
and can choose to do so or not from there.
One of my favorite examples of this
is the Mac admins Nudge tool
if anyone is using that,
to update the operating system
on their macOS devices.
Since that is commonly updated
to enforcing new operating system version,
or to change the date
by which it needs to be installed.
If you use the JSON schema
for configuring Nudge,
it's as simple as going back
into the configuration profile,
modifying those settings and clicking Save
to have it redeployed out.
One of the other nice features here
is the Plist Preview button.
When you press the Plist Preview button,
it shows you what this would look like
as a Plist file.
Now, you'll see, this looks very similar
to the Plist file that we started with
at the beginning of this presentation.
Again, we have that ADDomain key
shown as a string, and that Deny local key
showing with true as a Boolean value.
This is all just showing you the Plist
format of the configuration profile.
So it's really easy to see that
it's enforcing the same exact settings.
It's just a cleaner and an easier method
to do so with a user interface
that more people can understand.
Now, you may be saying
that you don't know how to write JSON
and that's totally fine.
The main reason
I wanted to present on this
was to bring attention to the fact
that there are already plenty
of JSON schemas that already exist
and are available to use without you
needing to know how to write JSON.
Because once they're pasted in,
you'll be met with the dropdown menus
for configuring those settings.
For this reason,
I wanted to bring attention
to the Jamf custom profile schemas GitHub.
A collection of these JSON files
written by the community
that you can use in your own environment,
should you choose.
I stumbled across this in a Jamf Nation
discussion board post while working on
making settings for supported browsers.
I originally went down this path
when I was trying to figure out
how to configure settings for all
the supported browsers at my workplace.
In a Jamf discussion board post,
I found a link to a JSON schema
that had been made by Microsoft
for Microsoft Edge,
and came across this link
to the schemas on GitHub.
Going through the repositories
I found that other Mac admins
had already created schemas
for applications like Firefox,
NoMAD, BBEdit, and countless others.
For that reason, I want to make sure
that I plug that GitHub
so others can take advantage of these
already written JSON files as well.
So here's the QR code for the links
to those repositories on GitHub.
And I'll leave this up on the screen
for a moment.
Again, the benefit here
is that you don't need to go
and try to reinvent the wheel
for a lot of these common applications.
As a peer may have already taken the time
to create the JSON file.
And though you don't have to be able
to write JSON files to use these,
if you understand Plist files
or are comfortable with those at all,
you'll be able to look at these files
and get an understanding of what they do
or what settings they're enforcing.
You can always also rely on that
Plist Preview button
in the configuration profile screen,
to see which settings are being enforced
when you change anything.
Of course, this list on GitHub
is not exhaustive
and may not have a certain application
that you would like to use it for.
But that also opens the opportunity
if you're interested,
to create your own JSON schema to use.
And if you decide, publish it to GitHub
for others in the community
to use as well.
So that brings me to the last part
of the presentation,
which is constructing your own
JSON schema.
For me, the application
I wanted to use this for
was NoMAD login,
which is why most of my examples
in this presentation have been
structured around that application.
The way I initially went about
creating the JSON schema for it,
was looking through that GitHub
and following the format
that others had used
and trying to replace it
with the different keys and types
that NoMAD log-in needed
in order to be configured.
It was only when I was more
than halfway through that process
did I come across an application
made to simplify that process,
called Managed App Schema Builder.
So I wanted to give a brief walkthrough
of that application and how it works.
This is the Managed App Schema Builder
application,
and this is what it looks like.
So when we're creating a JSON schema,
the first couple things we need to do
is input a preference domain
and a domain description.
Since we're doing NoMAD login
in this example, the preference domain is,
menu.nomad.login.ad.
And this will be unique
based off the application
that you're configuring the settings for.
The domain description I just put
NoMAD Login.
Once we're ready,
we can click the plus sign
in the lower left-hand corner
and create a key.
We get prompted for the value of
what preference key we'd like to create.
In this case we'll create that
ADDomain key that we've been working with.
Once we click Add, we get prompted
and we can add a few more settings.
You'll see, on the left side
that ADDomain key now shows up
in the list of keys,
and we have to fill out a few things,
including the key friendly name,
the description of the key,
and the type.
The key friendly name
is more just for your information.
If ADDomain is something
that you think you needed to clarify
to make it more obvious
what needed to be put in there,
you could change the key friendly name
to Active Directory Domain,
or whatever would make sense for you
to understand
what that setting is enforcing.
The description of the key.
You can put in a description
of what it does,
what the options of the values
in that field could be.
Or even a link to a support website
that may define what the keys are
and what options may be.
And finally, you have the dropdown field
that shows the type.
In this case, ADDomain is a string value.
Once we're done with an individual key,
we can press the plus sign again
to create additional keys.
So for a second one,
I did the Migrate key, for example.
For NoMAD login that's the setting
where if you have mobile directory
bound users with active directory,
this setting would migrate them
to a local account.
So again, we're putting in
a key friendly name,
a description of the key and a type.
In this case, we have a Boolean value.
The dropdown here that shows the different
types can be configured with a string,
a Boolean value, an integer.
Whatever the specific key needs to be
for that manufacturer can be selected
there in that dropdown value.
Once we're done,
we can click the Save button
on the lower right-hand corner,
and we'll be prompted to save this to
whatever location on the computer we want.
Now, the nice part about this is
we can use this for two different things.
Option one is, if you want to come back
to this later and create additional keys,
you can open up an existing JSON file
that you've created in this application,
and continue where you left off,
or add additional keys that you may need.
The other option is you can either
open that file, and copy and paste
the raw content directly into Jamf.
Or you can upload that file to Jamf
at that application
and custom settings screen
where you're adding the JSON schema.
And this is already in a format
that's compatible with Jamf,
so it makes it really easy
to create those JSON schemas,
especially if they're simple ones
where you only need
to configure a couple keys.
So again, I wanted to plug
this application as well.
So this QR code leads to the GitHub of the
Managed App Schema Builder application.
If you think this is something
that'd be beneficial to you,
here's where the repost are located,
or you can download the software
to make your own JSON schemas.
I found this super helpful
especially in learning
the formatting of a JSON schema,
where I can look at the file
after it's created as well.
This link will also be on my next slide
with the references as well.
So this is just a few references
and handy links that you can reference
if you're trying to use JSON schemas
in your own environment.
The first one is json-schema.org/.
It has a lot of background information,
formatting,
it has a nice getting started guide.
So if you're trying to learn more about
JSON schemas in general,
that's a great starting point.
Secondly, jsonlint.com
is a great formatting checker
for JSON files.
It's helped me out a lot,
a couple of times
when I've had either a rogue,
or a missing bracket,
or parentheses, or a comma.
This can check the formatting
if you're getting an error in Jamf Pro
when you try to paste it in,
saying that you're in an incorrect format.
And then again,
the two links to the GitHub projects
of the Jamf custom profile schemas
and the Managed App Schema Builder.
I hope that you have found value
in this information
and that you might be able to have
these schemas help you in your environment
as much as they helped me.
Thank you for your time.
And thank you for listening.