-
Notifications
You must be signed in to change notification settings - Fork 4
1. Installation and Setup
Multitenant Jamf Tools requires macOS 15 or newer.
Jamf Pro 10.35 or greater is required.
The use of either users or API clients for authentication are both supported.
AutoPkg is required for some of the scripts, including autopkg-run.sh, jamfuploader-run.sh, jamf-api-tool.sh and others. It is recommended to use the AutoPkgSetup tool to install and configure AutoPkg in a way appropriate for these tools.
jamf-api-tool.sh is a wrapper script for the jamf-api-tool project, and requires the grahampugh/jamf-api-tool repo to be cloned into the same parent folder as this repo. It also requires python3 installation, which is bundled as part of AutoPkg.
A note for Toolkit for MSP users
MJT is included in Toolkit for MSP, so these installation instructions are not required. Instance list creation is also done from Toolkit for MSP's Setup Wizard.
If you are familiar with git, you can clone the repo to your local computer. For example, you can use GitHub Desktop.
Note: it is no longer necessary to fork the repo to maintain your instance lists. See Create Instance Lists below to point to a folder of your choice.
- To download directly, visit the top page for the Multitenant Jamf Tools repo, click on the green "Code" button, and then click on "Download ZIP".
- Once downloaded, if your browser has not already unzipped the folder, double-click the ZIP file in Finder.
- You will see a folder called
multitenant-jamf-tools-main. Move this folder to a suitable location, such as yourDocumentsfolder, and please rename the folder tomultitenant-jamf-tools.
The scripts should normally be run in Terminal, directly from the multitenant-jamf-tools folder, e.g. ./managed-device-counter.sh. Typing ls lists all the available scripts in the folder.
Note: if you download directly and wish to update the content later (e.g. when changes have been made to MJT due to bugfixes or changes to the Jamf Pro API), bear in mind that any instance lists stored in the folder may be overwritten, so take backup copies before updating.
Jamf Pro instances are added to text files inside an instance-lists folder. An instance-lists folder already exist within the multitenant-jamf-tools folder, so you can use that, or you can create a folder elsewhere and set this as the default using the following command, where /path/to/instance-list is substituted for the folder you created:
defaults write com.github.autopkg instance_lists /path/to/instance-lists
You can maintain just a single text file, or multiple text files. You may find it useful to maintain multiple text files, for example test and production servers, or create temporary files depending on specific work tasks you are undertaking. This is because if your task involves performing repeated actions on a subset of your instances, it is quicker to put those instances into a separate file so that you can tell the script to perform the action on all of the instances in that file.
There are three example files in the instance-lists folder of this repo to show how this works. To create a real list, either copy one of the existing files, e.g. prd.txt.example, and remove .example so that the file becomes prd.txt and is recognised as a text file, and then double-click to open it in the default text editor (normally TextEdit):
Now you can edit the server list to cover all instances you wish to manage.
Note: The
.gitignorefile has been configured to ignore.txtfiles in theinstance-listsfolder of this repo, so if you use these file names, the contents will not be committed to the repo. This is more for the author's benefit, but if you are maintaining a public fork, you can use these files with no fear of them getting committed publicly.
Each file should contain a list of full URLs of the instances. See prd.txt.example for an example.
The first instance in the list is considered the default instance.
Certain tools are concerned only with computer-relevant content. It's possible to specify iOS-only instances on which you would prefer not to push settings that are specific to computers only. To do this, specify it in the text file by adding , iOS to the line, as follows:
https://some.jamfcloud.instance, iOSAll the scripts in this repo are designed to be run interactively, although many of the interactive options can be by-passed using command line parameters. When you run one of the scripts, you will be presented with a list of the instance lists that you have stored in the instance-lists folder, like so:
Instance lists:
[0] tmp
[1] dev-example
[2] tst
[3] prd
[4] tst-example
[5] prd-example
Choose the instance list from the list above
or press ENTER to choose list prd
Instance list :
The file prd.txt is hard-coded as the default list, meaning that if you just press Enter, it will select this list. To choose a different list, type the number listed, e.g. to select the tst list, type 2 and press Enter. You will then be shown a list of all the instances in that list:
Instance list tst:
(0) https://mytestserver.jamfcloud.com
(1) https://mytestserver2.jamfcloud.com
(2) https://mytestserver3.jamfcloud.com
Enter the number(s) of the destination JSS instance(s),
or enter a string to select the FIRST matching instance,
or enter 'ALL' to propagate to all destination instances
or press enter for '(0) https://mytestserver.jamfcloud.com'.
Instance(s) :
The first instance in the list is pre-selected, meaning that if you press Enter without entering a number, the first instance in the list (number 0) will be selected. If you enter any of the numbers, that single instance will be selected.
In most of the scripts, you may select multiple or all instances in the list. If you enter ALL, the action will be performed on all the instances. Alternatively you can select individual instances by putting spaces between them, for example entering 0 2 3 would select the first, third and fourth instances in the list. You can also select groups of instances, for example, entering 0-3 5 would select instances 0, 1, 2, 3, and 5.
The exceptions to the above are jocads.sh, mdm-commands.sh, and migration-tool.sh - see individual instructions pages for these scripts.
The API account credentials for each instance on which you wish to read from or perform an action on must be stored in the local computer's Keychain.
To get API credentials into the keychain, run the set-credentials.sh script. This interactive script will ask you to provide credentials for an instance list or lists that you specify. If the credentials are the same for all or a subset of the lists, the script gives you the ability to provide the credentials just once and it will write the credentials to all the specified instances.
To add credentials, first choose an instance using the menu that is displayed, as described above. Then, select the instance or instances that you wish to add or update the credentials of. As above, you can select one, multiple, groups of, or all instances in the list. The credentials you supply will apply to ALL instances you select (you're only asked once), so if all your instances have different credentials, you must run the script once for each instance.
Once you have selected the instance(s), you will be asked to supply the username. If the username matches an existing keychain entry, you will be asked if you want to keep the same password or change it (can leave it blank to keep the same).
Once you have provided both username and password, the Keychain entry is created or amended, and a check is made to verify that an API token can be granted using them. You will be informed if the request is unsuccessful.
Note that set-credentials.sh checks for an existing entry for the server you selected, and deletes it if found. This is to prevent multiple Keychain entries with different usernames being stored, which confuses the tools.
The use of API clients is supported. When running set-credentials.sh, enter the API Client Name and Secret in place of username and password, respectively. Since API clients are unique to each instance, you will need to enter each credential separately.
MJT is beginning the journey towards support for Jamf's new Platform API. Initially, there is one script that can be used to perform requests using Platform API: send-platformapi-request.sh. Platform API uses different credentials to Jamf Pro's API, which currently are created via Jamf Account in the APIs section (beta access required).
To store Platform API credentials in your Keychain, run ./set-platformapi-credentials.sh. You will be asked to supply the Region, Client ID and Secret.
If your instances have a FileShare Distribution Point (FSDP / SMB server), and you intend to upload or delete packages using autopkg-run.sh, jocads.sh and/or jamf-api-tool.sh, you can store the required credentials and optionally set up the server using the script set-fileshare-distribution-point.sh. As well as writing the SMB user and password to the login keychain, the script will ask you if you want to create or update the FSDP in the specified Jamf instances.
If you wish to send notifications to Slack when an API action is performed, add a file into the slack-webhooks folder with the same name as one of the list files in the instance-lists folder, and put the URL of the webhook in the file. There can be only one webhook URL in each file.
Tip: If you're in the habit of creating temporary instance lists for specific tasks, don't forget to create a file of the same name in the
slack-webhooksfolder!
This folder contains files specifically for use with jocads.sh. See the specific instructions page for jocads.sh for use.
Some of the scripts require an XML or JSON template in order to function, for example the scripts to create an SMTP server or an LDAP group. A set of templates is provided in the templates folder. A different path can however be provided.
Some of the scripts use AutoPkg recipes in this folder to perform tasks.