Something other than DEPNotify

t_jones
New Contributor III

Does everyone use DEPNotify for the enrollment process? Or does anyone use something different?

19 REPLIES 19

mark_mahabir
Valued Contributor

We are currently looking into this as we are only just getting going with Automated Device Enrollment. DEPNotify was recommended to us by Jamf and a Jamf Professional Engineer wrote the extremely useful DEPNotify Starter script:

https://github.com/jamf/DEPNotify-Starter

Similar solutions are available but are probably not as popular (I believe Splashbuddy was, once, but is no longer being developed/has morphed into something else).

float0n
Contributor

There's quite a few different onboarding solutions out there. Some are open sourced like IBM, Splashbuddy, or Depnotify. Some are free with paid upgrade options like Ceremony or Octory.

Technically, Jamf can now do a lot of the features these solutions offer with custom enrollment settings and the ability to install packages during enrollment now.

mark_mahabir
Valued Contributor

@float0n One thing to bear in mind though - only Jamf Cloud customers (i.e. with Cloud DPs) are able to upload packages and scripts to PreStage Enrollments it seems, so as an on-premise customer we are unable to take advantage of that particular functionality.

DEPNotify was pretty easy to set up in my experience, especially using the starter script.

tvalente
New Contributor II

@float0n Ceremony and Octory are the same, the app has been renamed to Octory some time last year.
It cannot manage package installation and such, though. It can do a lot of things, but the app will not handle PKGs or anything that Jamf is already handling as per deployment process.

t_jones
New Contributor III

DepNotify is easy to set up and thats what we've been using. Unfortunately it doesn't offer everything we want it to do and is limited to specific numbers of input fields. So, Im just looking to see what other options are being used.

dletkeman
New Contributor III

I'm surprised DEPNotify-Starter hasn't been updated in awhile. At least DEP Notify was updated as a universal binary. Would love to see more development on this. It's a great tool!

wmehilos
Contributor

On-prem folks can use Enrollment Packages now, but the master distribution point has to be accessible over HTTPS without authentication.

rkeleghan
New Contributor III

The new version of DEP Notify has been release - Version 1.1.6 Can be found here. - #depnotify channel of the MacAdmins Slack

jyoakum
New Contributor III

You can always just use the Jamf helper binary with a script to perform this as well, albeit without as many bells and whistles as DEPNotify.

gachowski
Valued Contributor II

I told my circle of friends that they are doing it wrong if they are still using IBM, Splashbuddy, or Depnotify.... : )

/Library/Application Support/JAMF/bin/Management Action.app/Contents/MacOS/Management Action -title "Fast IT" -subtitle "Message 1 of 4 during the enrollment process." -message "Hi, We are installing software and configuring this Mac. This will take up-to 30 minutes"

bwoods
Contributor II

My name is Commander Shepard, and DEPNotify is my favorite GUI for provisioning. Simple configuration, Shows installation progress, and Joel updates it when necessary.

honestpuck
New Contributor III

Here at my current employer we had a fair amount of success with DEPNotify and a hacked version of DEPNotifyStarter.sh. We are just in the process of moving to Octory as it allows us a better GUI and such things as pop up guides for users.

Octory does cost money. Contrary to what has been said here Octory is perfectly capable of package installs if you want.

dletkeman
New Contributor III

@honestpuck I was looking at Octory recently. Is the price reasonable with all the currency conversion is done? The interface looked pretty slick in an example I saw. Just wondering if it's easy to configure.

peternbevan
New Contributor III

I can confirm that enrollment packages are available for PreStage enrollments for on-prem customers. We created a small un-authenticated https: share just for the enrollment packages in addition to our existing main and DMZ distribution points. You have to create your own custom manifest files and Jamf Admin complains when it doesn't find the enrollment packages in the main DPs, but just ignore the error messages it throws.
We use Jamf Connect which has the Notify provisioning script originally from DEP Notify built-in. 'twas all working fine until Apple Silicon came along - now if I use the Notify script provisioning an M1 machine I get a guest appearance from ASA after enrollment and provisioning which gifts the user their own shiny admin account. Nice. This doesn't happen without the Notify script. Support call with Jamf about this is still outstanding, so the jury is out on that one.
The great benefit of Jamf Connect is that our users can authenticate against our cloud identity provider and provision their own machines from the comfort of their lockdown homes.

stevewood
Honored Contributor II

@peternbevan You can actually accomplish this without a manifest file. You do not need to create a custom manifest, your package just needs to be built as a distribution package. If you are unfamiliar with distribution packages, or with packaging in general, may I suggest this fine book from @arminBriegel - Packaging for Apple Administrators.

I use a folder structure with a build script for doing my packaging. As part of the workflow I create a package, convert the package to a distribution package, and then sign the package:

#!/bin/bash
args=("$@")
pkgName="${args[0]}"

echo "Supply the package name and version: build.sh <pkgname> <version>"
# get date for package name
myDate=`date +%Y%m%d`

# Name of the package.
NAME="${pkgName}"

# Once installed the identifier is used as the filename for a receipt files in /var/db/receipts/.
IDENTIFIER="com.yourcompany.$NAME"

# Package version number.
VERSION="${args[1]}"

# Remove any unwanted .DS_Store files.
find ROOT/ -name '*.DS_Store' -type f -delete
find scripts/ -name '*.DS_Store' -type f -delete

# Build package.
/usr/bin/pkgbuild 
    --root ROOT/ 
    --scripts scripts/ 
    --identifier "$IDENTIFIER" 
    --version "$VERSION" 
    "Output/$NAME-$VERSION-$myDate.pkg"

# Build Distribution Package
/usr/bin/productbuild 
    --package "Output/$NAME-$VERSION-$myDate.pkg" 
    "Output/$NAME-$VERSION-$myDate-dist.pkg"

productsign --sign '<yourdevelopercertname>'  "Output/$NAME-$VERSION-$myDate-dist.pkg" "Output/$NAME-$VERSION-$myDate-dist-signed.pkg"

Folder structure:

c331180444ec44e0bec3d324fa633ec8

Place your folder structure in the ROOT folder, any pre or post scripts in the scripts folder, and then run the Build.sh script (contents above) with something like: /path/to/build/template/Build.sh <packagename> <version>. If you keep the package signing bit in you will be prompted for credentials. That will output a file like: packagename-version-date-dist-signed.pkg along with 2 other packages. I'm lazy and haven't added the bits to clean out the other 2 package files.

For example, if I wanted to package Jamf Connect for distribution during PreStage (which I do), the folder structure might look like this:

c5e1743581cc4e17b37f6d3f8c62f29f

Placing any logos I need for Jamf Connect, or anything else, in the logos folder. Obviously adjust that folder path to wherever you might store your company logos and such.

The postinstall script simply calls the Jamf Connect installer:

#!/bin/zsh

TMP_PATH=/tmp
LOGIN_FILENAME=JamfConnect.pkg

installer -pkg "$TMP_PATH"/"$LOGIN_FILENAME" -target $3

/usr/local/bin/authchanger -reset -JamfConnect -Notify

exit 0

And I'd call that by changing into that folder in Terminal and running:

./Build.sh JamfConnect 2.1.2

And the output would look like this:

9cf2de3901dd4850941855b7d072be97

Again, I'm lazy and haven't re-written the script to get rid of the .pkg and -dist.pkg files.

As far as DEPNotify we use it quite heavily for provisioning and we also use it for longer Self Service installs, like installing an entire set of Adobe products. It just gives us a nice way of providing feedback to the end user.

IMO, the "DEPNotify-Starter" script should be used as a template, or as a proof of concept for how it can work. The script is way more complicated than it needs to be for basic provisioning. I would suggest you grab DEPNotify, run it on your machine locally, and throw text into the depnotify.log file so that you can see in real time what is going on. once you've figured out how it works and what you want, then build your own script to trigger.

Because our organization is quite large and quite complicated (over 300 different business units) we had to get very tricky with our provisioning. Currently our team provisions for over 100 different business units and each business unit might have up to 4 different builds that are snowflakes from the other business units. So we potentially have 400 different builds (it's not that high but you get the picture). Because of that I had to write a custom Python script that uses a JSON file as a data file containing all of the permutations of our builds.

We were originally using cocoaDialog to ask for some key information from the techs that were building computers (country, city, agency, building, email, asset tag) because we utilize that information to build the computer name and to determine which build. We are in the process of converting this over to use the Okta information (gleaned from Jamf Connect on first login) for the user and then only asking for things we do not have using the Register function of DEPNotify.

My point being, look at the DEPNotify-Starter script, pick out the pieces that you might want to re-use (the policy loop to install policies from a trigger array is one that I highly suggest grabbing), play around with DEPNotify on your machine, and then go experiment with your own provisioning scripts.

Just my 2 pennies...

dstranathan
Valued Contributor II

@mark.mahabir Can you elaborate on why having your JSS on-prem was not working with Prestage enrollment workflows?

mark_mahabir
Valued Contributor

@dstranathan Because I am greeted by this:
cb4954ad744a4d328946e30d16170a6a

dstranathan
Valued Contributor II

@mark.mahabir Ahh gotcha. This can be resolved in most cases.

-Make sure the Jamf DSP repo for the PreStage package is on an HTTPS server that is available on the Internet. DMZ etc.
-Make sure the HTTPS share does NOT require authentication. Must be readable by the public.
-Make sure the PreStage package is signed so that it is trusted.
-Make sure the PreStage package has Distribution XML metadata for Intel and ARM (if you have M1 Macs)

Here is a great PDF to check out by Arek Dryer, located at https://hcsonline.com/support/white-papers/how-to-deploy-depnotify-as-a-jamf-pro-prestage-enrollment-package-with-custom-launching-scripts

Bigby-Woody
New Contributor

Hi all! Just to clarify @honestpuck , Octory is not capable of installing package installs unless you are executing a script or a Jamf policy, which requires the PRO version. It could be possible to use the termination script feature to install some packages but it's not really the planned used case.
Another point also: as it was mentioned above, Octory is free and it's possible to get the PRO version to get more features, which has to be paid (0.20€ /device /month)