New JSS configuration Guide

This guide is for JSSs that have VERY few to no machines currently enrolled and configured. Basically JSSs that are still being configured for production. If you are implementing this on top of a production JSS please reference the Pre-Existing JSS configuration Guide.

Step 1: Extension Attribute

Display Name: Initial Configuration Complete Check
Data Type: String
Input Type: Script
Script: See Below

Script: Please copy the contents of the Initial Configuration Complete Check.sh file here

Step 2: Smart Groups

1. Display Name: Configuration Required
        Criteria: Initial Configuration Complete Check, is not, true

2. Display Name: Configuration Complete
        Criteria: Initial Configuration Complete Check, is, true

Display Name Note: The display names for all the smart groups can be changed, BUT you will need to reflect that change in all the the smart group links in the polices defined below.

Step 3: LaunchDaemon Installation Policy

Display Name: Initial Configuration LaunchDaemon
Enabled: true
Trigger: Network State Change, Enrollment Complete, Recurring Check-in
Execution Frequency: Ongoing
Packages: See Below
Scope: Configuration Required

Package: Download, Upload and Replicate out the most recent JAMFInitialConfig Package for installation by this policy.

Execution Frequency reason: The installation policy is set to ongoing and not once per computer as a failed installation due to some unforeseen networking failure will not trigger a package re-installation. In general the ongoing setting might add some execution slowdown and repeat installs, but provides redundancy in the configuration process which is the goal of this project.

Step 4: InitialConfig Policy list setup

In this section you will have ability to construct as many or as few policies you would like to execute once per machine. Please ensure they follow the settings below, any settings not defined below you are free to modify. It is recommended though to name your packages in a number followed by the package name to ensure they execute in the proper order.

For example if you want SplashBuddy to install first you would have it's package name be "01 SplashBuddy" followed by the next package being named something like "02 Google Chrome".

Display Name: ## Package Name
Category: Initial Configuration
Trigger: Custom
Custom Event: InitialConfig
Execution Frequency: Once Per Computer

Execution Frequency reason: The InitialConfig policy call could happen more then once before the LaunchDaemon gets unloaded and removed. Therefore to avoid multiple of the same installations from happening a Once Per Computer execution frequency must be set.

Display Name Note: The display name can be changed if needed. If using a custom name you must ensure that the policy falls alphanumerically before your Configuration Receipt Policy.

Step 5: Configuration Receipt Policy

Display Name: 30 Initial Configuration Complete Receipt
Category: Initial Configuration
Trigger: Custom
Custom Event: InitialConfig
Execution Frequency: Ongoing
Scripts: See Below 
Maintenance: Update Inventory
Scope: All Computers

Script: Please use the contents of the Configuration Complete Receipt write.sh file here. This should be added to your JSS as a script item.

Display Name Note: The display name can be changed if needed. If using a custom name for this policy you must ensure all other policies triggered by the InitialConfig policy trigger fall alpha-numerically before this one.

Step 6: LaunchDaemon Unload and Removal Policy

Display Name: 90 Initial Configuration LaunchDaemon Removal
Category: Initial Configuration
Trigger: Recurring Check-in
Execution Frequency: Once Per Computer
Scripts: See Below 
Scope: Configuration Complete

Script: Please use the contents of the Initial Config LaunchDaemon removal.sh file here. This should be added to your JSS as a script item.

Display Name Note: The display name can be changed if needed.