23rd January 2022 – 90 Days is Up

The 23rd of January is an important day for Mac Admins, why? It’s 90 days since macOS 12 Monterey was released so if you have deployed a macOS Update Defer Profile via your MDM it will expire.

What does this mean?
It means the macOS 12 Monterey Update will now start to show in the user’s Software Update as below:
Monterey in Software Update
You may also find Apple start pushing out messages that appear in Notifications saying update now to Monterey, not ideal really.

Can I still block it?
Yes and No.

If the Mac is on Big Sur then it’s a no, Apple deprecated the ignore command. If it is on High Sierra, Mojave or Catalina then you can still use the ignore command. For details on using the ignore command head over to Derflouder.

Anything I can do to stop users from updating?
Well certainly in Jamf you can. You can create a Restricted Software policy that will stop the install, it won’t prevent the user from downloading though but it will block it from running and display a custom on-screen message to your users, although the characters limit is short.

You can find Restricted Software in the left-hand nav:
Restriced Software Jamf Navigation

Have a look at Jamf’s documentation for how to block:

Here is an example of the policy setup to block Monterey:
Jamf Monterey Restricted Policy Example

In this example we are doing an exact process match, deleting the installer, killing the process plus informing Jamf users with notifications enabled (usually the Admins) the restriction policy has been broken and also showing an on-screen message to the end-user.
Hint: If you add a message and get an error when saving the restriction try shortening the message length.

Anything else?
There are a couple of Github scripts to also block the Monterey installer from running similar to a Jamf Restricted Software policy but that’s about it.

Apple really wants you to be getting the next macOS version out to your users within 90 days, great in theory but still, 3rd parties lag behind certifying their software.

Happy 23rd Jan!

Erase all Content and Settings – Control the menu item when you need it

There is a great new feature in Monterey to erase a Mac, very similar to iOS, you can read all about it on Apple’s site here:

A good post on krcs.co.uk prompted me to write this article on how you can control showing the Erase All Content and Settings Menu item via Jamf to have it show when you want by who you want as you may not want it to be accessible by your end-users. Jamf has added this already directly into the Jamf UI so it is as simple as ticking a box in Profile.

So lets start with creating a new Profile

Profile Setup
Create a new Profile in Jamf
Add the Restrictions payload
Select the Functionality section and scroll down

You will see the item and by default its unticked meaning, if you scope this to your target Mac’s the Erase All Content and Settings menu item won’t be shown.
Ticking it will allow the item to be shown.

Let’s say you scope this so the menu item is hidden but you want your IT Technicians to have access to it when they need to erase a Mac but without asking you as a Jamf Admin to change the Profile scoping adhoc per Mac, but how?…A Self Service “switch” is the answer.

A “switch” is possible by using two Profiles one with the item ticked, one unticked plus a Smart Group and a Policy that sets a Receipt for your on “switch” and you can have an “off” switch.

The Policy performs a Touch which writes a Receipt on the Mac and also must be set to do an Inventory Update (recon) which will update a Smart Group. The criteria of the Smart Group is looking for the Receipt and the scoping of the Profiles is set to the Smart group so if the Receipt is found the unticked Profile is removed and add the ticked Profile is added and therefore the menu item will be available!

The policy can be run via Self Service and you can control access to the Policy item to just your IT admins via scoping it to a User Group. When the Self Service item is run the menu item will be shown.

How To
Create a Profile and name accordingly and ensure the item is ticked, add any other Profile settings you require, leave un-scoped for now and save the Profile.
Now duplicate the Profile and name accordingly.
In this duplicate make sure the item is unticked. Again don’t scope yet and save the Profile.

Now create a new Policy

Add a Files and Process payload and in Execute Command field add a Touch command to add a Receipt to the Mac in the form of a .pkg

The touch command is the part in bold is the actual Receipt name and we add this to the Jamf Receipts folder.

touch /Library/Application\ Support/JAMF/Receipts/Restrictions_Allow_Erase_Reset.pkg

Now add a Maintenance payload to the policy and tick the Update Inventory box. This is required so the Mac can report back to Jamf the Restrictions_Allow_Erase_Reset.pkg is in place.

Make this Policy a Self-Service item, give it a nice icon a few instructions and drop in a category like IT Admin and Scope to only those you want to allow access to run it, like your IT Techs.

Now let’s Create the Smart Group
Name it how you want that’s relevant…like Mac’s with Restrictions_Allow_Erase_Reset.pkg

In Criteria find the item Packages Installed By Casper (I like Jamf keeping the old school name here!)
In the Criteria, setting ensure the Operator is has and the Value is the name of your Receipt pkg, so in this example Restrictions_Allow_Erase_Reset.pkg

Finally, save your Smart Group

Ok, so we have our Policy setting the Receipt and we have our Smart Group looking for Macs with the Receipt.

Let’s go back to our Profiles.

Our default position in this example is for the end user not to see the Erase All Content and Settings menu item so in the unticked Profile scope set the Target to be All Computers (assuming all your Mac’s are on Monterey) and set the Exclusion to be the Smart Group you just created.

So, all Mac’s will get the setting not to see the menu item but Mac’s with the Receipt will be excluded from getting this Profile.
Save the Profile and let it hit your Monterey Mac’s.

Now open the ticked Profile, go to Scope and select Specific Computers.

Click Add and this time your Deployment Target is going to be Computer Groups then select your Smart Group you created earlier that is looking for the Receipt.

So Mac’s in the Smart Group that is looking for a Receipt that is dropped in place by your Self Service Policy will now get this Profile when the unticked Profile is removed.

On a target Mac check it has your unticked Profile and check it’s doing its thing and the Erase All Content and Settings menu item is not showing in System Preferences.

Now open Self Service, find your Policy that will run the Touch command, which sets the Receipt, does an Inventory update and therefore based on our scoping will remove our unticked Profile and add our ticked Profile.

Run the item, allow it to complete which will take about 30 or more seconds as we have set it to do an inventory update. You then should notice the Dock open and Close as the Profiles are changed.

Now open System Preferences (Hint: if it’s still open close and re-open) and you will now see the Erase All Content and Settings menu item and the IT Tech can do the erase!

Of course, you may want to revert and hide the menu item. To achieve this is again really simple. All we need to do is create another policy to delete the Receipt we set with the Touch command and do an Inventory Update and add to Self Service. A simple rm of the pkg using the Execute Command in a Files and Process payload….don’t forgot to add a Maintenance payload to the policy and tick the Update Inventory box.

This policy when run from Self Service will move the Mac out of the Smart Group and therefore switch the Profiles back and hide the menu item.

Near the start of this article, I referred to it as a “switch” having both Policies is like an on/off switch, the one we use to write the Receipt is our On switch and one to remove the Receipt is our Off switch.

My guess is there are other ways to achive this, but this is my preferred, tested solution.

Hope that helps.

Mac SE Restore

Early Christmas Gift….a new to me Mac SE from around 1988. Comes with a huge 40Mb Hard disk and 4Mb of RAM. In its day this would have been around $3800. I started my career on one of these. This was the first model to ship with an internal disk drive and it also has the FDHD which is the 1.4Mb Floppy Drive

Mac SE

It powers on and is running OS 7.1.1. The plan is to Retrobrite the case as like all these vintage Mac’s the plastic yellows over time. Then give it a good clean inside and replace the clock battery before it explodes and possibly recap it.

Just need an ADB keyboard….anyone got one spare?

The plan was to buy an old Mac SE and gut it and modernize it but I just cant do that to this one…So if anyone has a dead Mac Classic or even just a case I’d be interested in taking it off your hands.

Checking if a Mac is Automated Device Enrollment Eligible – Jamf API Script

A dilemma I have come across recently is if a Mac is purchased and not in Apple Business Manager (ABM) then it won’t be an Automated Device Enrollment (ADE) eligible device so can’t be deployed as a ZeroTouch device but needs to either be registered which is now only just possible if its a Monterey device but has overheads (iOS15, Configurator 2, Managed Apple ID) or built using a more manual process.

But how can you easily check without booting the Mac?

You could log into ABM and check or log in to Jamf but what if you don’t want to add 10’s or even 100’s of accounts to your ABM or Jamf for your local engineers to access. At present, there is no API to ABM and the minimum account level of Staff still allows access to VPP settings so letting in users is not always ideal and adding and maintaining Jamf Pro access could be a chore based on your setup.

Well, there is an easier way and that’s using the Jamf Pro API (not classic) and device-enrollments/[ID]/devices request and creating a simple command-line tool.

When a device is in ABM and you have set up and pointed ABM to Jamf and in Jamf you have set up an ADE instance you will see your Macs in ABM in Jamf and you can assign these to your Pre-Stage for your Zero-touch deployment.

With a little bit of bash and a Jamf account with specific read-only access, it’s possible to search this list. When I say search you can’t do a direct search, there is no API reference to do that but what we can do is download a list of ADE devices, search it and then delete the download.

First, create an user account in Jamf and set it to only have the following access, that’s all it needs just Read Only for Automated Device Enrollment ensure you just have this in place and not write access.

Once done copy the script below and edit the URL, username adding your API username and password plus the ID number of your ADE instance in Jamf, if you just have one the ID is usually 1.

Save and run the script from the terminal and follow the instructions, enter the full serial number when requested.

The screenshot below shows using the serial 123456 and of course, it’s not found.

The screenshot below shows using a serial starting VQ and it’s found.

The full script is below, like a lot of scripting, there are multiple ways to achieve the same results.
Credit to William Smith aka talkingmoose as the script here really helped kick this off.

If I quickly go through it, after setting the URL and API details the file downloaded is set as my_ade_devices.txt, the next line is the ID of the ADE instance in Jamf. We then set some colours to make the script a bit easier to read.

The next part is the text on the screen when the script is run and a Y/N question. If we choose no we end if we continue we print some more text on screen then make the connection to jamf and do a curl to get the info and save it as a .txt file.

After that, we do our search for the user-entered text and then show results based on if the entered item is found in the text file and finally we clean up afterwards and delete the file.

To distribute the script I make it a .command file, chmod +x so its a simple double click to run. Then package using Jamf Composer and add to Self Service. Self Sevice has an IT Engineers section only and the Engneers must login to Self Service to access and install. I also tend to add some instructions or a video on how to use and link this in the Self Service description.

And thats is, simple command line tool to check your if a Mac is in ADE in jamf.

Feel free to take a copy change, improve as required.
As always using this is at your risk.


# Gets the device in ADE in Jamf


# server connection information

# Local file of the ADE devices

# provide the Jamf Pro ID of the Automated Device Enrollment instance; look in the URL when viewing the Automated Device Enrollment instance name

# Set the colour variable to make the script a bit more fun
# Clear the colour variable

printf "\n"
printf "${bold}Mac ADE Check${clear}"
sleep 2
printf "\n"
echo "This app will check if the serial number entered is a Mac in ADE in your Jamf environment."
sleep 1
printf "\n"

# Continue question
read -r -p "Do you want to continue [y/n]" input
case $input in
echo "Continuing..."
echo "Thanks for this tool. Goodbye."
printf "Please close this app by click the ${redbold}red${clear} dot at the top left."
echo "Answer was not Y or n so exiting"

echo "Getting a list of Mac's in that are registered in Apple Device Enrolment."
printf "${bold}Please wait, this may take 20-30 seconds...${clear}"

# created base64-encoded credentials
encodedCredentials=$( printf "$username:$password" | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i - )

# generate an auth token
authToken=$( /usr/bin/curl "$URL/uapi/auth/tokens" \
--silent \
--request POST \
--header "Authorization: Basic $encodedCredentials" )

# parse authToken for token, omit expiration
token=$( /usr/bin/awk -F \" '{ print $4 }' <<< "$authToken" | /usr/bin/xargs )

# submit scope for ADE ID
/usr/bin/curl "$URL/uapi/v1/device-enrollments/$ADEID/devices" -o "$downloadfile" \
--silent \
--request GET \
--header "Authorization: Bearer $token" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \

# expire the auth token
/usr/bin/curl "$URL/uapi/auth/invalidateToken" \
--silent \
--request POST \
--header "Authorization: Bearer $token"

# hide the downloaded file
chflags hidden "$downloadfile"

printf "\n"
printf "List of ADE Mac's downloaded.\n \n"
printf "Enter the Mac serial number of the Mac you need to check.\n"
printf "You can find the Mac serial number on the box or on the base of the Mac.\n"
printf "${bold}Enter serial number:${clear}"
read varserial
printf "The Mac serial number entered is: ${bold}"$varserial"${clear} \n\n"
echo "Searching...."
sleep 2
if grep -w -q "$varserial" $downloadfile;
printf "${greenbold}"$varserial"${clear} - ${bold}The Mac is registered.${clear} \n"
printf "Thanks for using this tool. Goodbye.\n \n"
rm $downloadfile
printf "${redbold}Computer Says No! - Mac Not Found ${clear}\n \n"

printf "${bold}This Mac is Not on ADE${clear} \n \n"

printf "${bold}Would you like to search again [y/n]${clear}"
read answer
if [ $answer = y ]
then do_file_action
exit 0
elif [ $answer = n ]
then echo "Thanks for this tool. Goodbye."
printf "Please close this app by click the ${redbold}red${clear} dot at the top left."
rm $downloadfile


Jamf Connect 2.6 – Azure Passthrough

Jamf Connect is a great product but what seems an annoyance to some is now gone in version 2.6.

Prior to 2.6 when using Azure (at the Jamf Connect login you entered your MS login ID, your password and then you would be asked to verify the password again to get into your Mac which did not seem a great UX and users could not understand why and they really do not like repetitive password entries. In 2.6 Jamf have added passthrough

“Passthrough authentication with Jamf Connect allows the password entered by users in the login window web view to be sent to Jamf Connect for local authentication”

As a Jamf customer when I heard this might be coming I started signing up for Jamf Connect Betas and in beta 2.6 it was introduced and we had up and running in 10 minutes.

All it takes to add the passthrough is one extra key and value in your Profile config.
Just add


Such a simple change to implement but makes a whole load of difference to the users.

If you use Google Cloud ID this is also available and I suspect other IdP will follow.

Now jamf, please can you make the password change consistent when a user is on-site or connected to VPN and we are using Kerberos and not when on onsite/VPN as it changes between a direct AD password or your cloud providers web-based version. I would really like the ability to overrule the on-site/VPN to use the cloud version, again for a consistent user experience.

Jamf Connect – Configuration file does not specify default realm error message

A few months ago we added Jamf Connect and all was good but recently and we started getting this error when a user was changing their password.

Jamf Connect Error

Jamf state this could happen If the Mac was previously bound to AD but we also saw this on new Mac’s that had never been bound, so the jury is out on the cause, but the good news is there is a simple fix.

The fix is to add a krb5.conf file to the user’s Mac (/etc/krb5.conf) and specify in that file the Kerberos realm.

For example the krb5.conf file would be:


Now we could of created this file, packaged in Composer, added to Jamf, created a policy, scoped and distributed but we have 5 realms (examples below)….so it seemed a lot of work to create 5 pkgs.


However, a quick search on https://community.jamf.com and this wonderful script by bigmikeey caught my eye. A quick test and we were in business. The Jamf community really is a fantastic resource.

All you need to do is change the MCSLTD.INTERNAL in the script below to your domain. Add the script to Jamf, create a policy and deploy. The krb5.conf is created on the users Mac and Jamf connect is killed and relaunched.


#Find the Current users ID.
currentUser=$( /usr/bin/stat -f %Su "/dev/console" )
userID=$( /usr/bin/id -u "$currentUser" )

#Unload the Jamf Connect Menu bar app
/bin/launchctl bootout gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

#Create the Kerberos file
touch /etc/krb5.conf

#Write the content into the file
cat << 'EOT' >/etc/krb5.conf



#wait 2 seconds
sleep 2

#Kill any running instance with the name Jamf Connect
pkill "Jamf Connect"

#Re-launch Jamf Connect Menu bar app (by launching the LaunchAgent)
/bin/launchctl bootstrap gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

exit 0

For our needs, we would have 5 scripts and change each one to the specific domain…..which I did! But a far more efficient way is to make the default_realm= value a variable, then have that variable set a script parameter in Jamf. So a single script, much more efficient.

So below is my version. You can see the domain variable is $4 and the default_realm=$domain


#Jamf Script Parameter

#Find the Current users ID.
currentUser=$( /usr/bin/stat -f %Su "/dev/console" )
userID=$( /usr/bin/id -u "$currentUser" )

#Unload the Jamf Connect Menu bar app
/bin/launchctl bootout gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

#Create the Kerberos file
touch /etc/krb5.conf

#Write the content into the file
cat << 'EOT' >/etc/krb5.conf



#wait 2 seconds
sleep 2

#Kill any running instance with the name Jamf Connect
pkill "Jamf Connect"

#Re-launch Jamf Connect Menu bar app (by launching the LaunchAgent)
/bin/launchctl bootstrap gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

exit 0

In the script Options section in Jamf you can set a Parameter Label as below:

Jamf Script Parameter Label

Then when you create your policy and add the script you can enter your domain in the script Parameter Value and you will see your label set in script Options:
Jamf Script Variable

Now when you scope and trigger the script the krb5.conf will be created with the value entered so in this case UK.DOMAIN.COM

Once again thanks to the Jamf community for this fix 😊

macOS 12 Monterey Release Day – The Enterprise Conundrum

Today, 25th October 2021 is macOS 12 Monterey release day.
macOS 12 Monterey logo

I’m not going to list the what’s new but for some Enterprises this time of year the pressure is on. For some companies they may be Day 0 ready and allow users to hit the upgrade button on release but for many Profiles and Restricted Software settings will be in-place along with banners and various communications channels to prevent and inform users not to update but there will be those users who want to either upgrade today or will be wanting a new Mac that will ship with Monterey installed.

Why Not Day 0 Ready?
There are a number of reasons for this, experience suggests it can better to wait for the .1 or the .2 to resolve any initial issues that have not been picked up through the 4 months of beta testing. However, also consider that additional installed software may seem to run OK but is it supported by the vendor.

For example if you use a 3rd party app for virus protection or VPN Connectivity if that app starts causing issues and you raise a ticket with the vendor have they actually stated macOS 12 Monterey is supported or will you ticket just be closed as running an unsupported OS. If it’s the latter then that may give you and your users a bit of headache.

IT Pressure

The pressure to allow macOS 12 Monterey is added to by the release of the new M1 Pro and M1 Max MacBook Pro’s, no one will want to buy an Intel MBP now even if you have access to stock but these new MacBook Pro’s and pretty much every Mac you can lay your hands on will now ship with Monterey and they can’t be downgraded. Even if you get a M1 Air with Monterey which last week shipped with Big Sur it should not be downgraded as potentially you are taking it out of any support agreements like Apple Enterprise Support (ACE).

So you have your conundrum of wanting to get the new amazing hardware and Monterey out to users to satisfy their requests but at the same time the potential of running apps that a vendor has not certified yet for Monterey. The best thing to do is communicate to your users, let them know the situation. The last thing you want is M1 Pros or even M1 Max running Monterey and the excitement that brings but then users getting a poor experience because of a crashing VPN client or a security app consuming the CPU!

Possible Solution
The best solution I have found for this for those who can’t wait is to provide an OS and /or hardware pilot. Just make it clear that it’s a pilot, list the apps that are not yet Monterey certified, lust any known issues, keep the pilot small and communications open perhaps via Slack or Teams channel and be on hand to help out at moments notice.

Work with your users, not against them. Let them know their Mac and apps could need updating at the drop of a hat. If you show them you care and are engaged most will help you out as you help them out and that way you will have a much better release ready for mass adoption when you are happy to go.

Worldwide Release Times
Honolulu, Hawaii — 7:00 a.m. HST
Anchorage, Alaska — 9:00 a.m. AKDT
Cupertino, California — 10:00 a.m. PDT
Vancouver, Canada — 10:00 a.m. PDT
Phoenix, Arizona — 10:00 a.m. MST
Denver, Colorado — 11:00 a.m. MDT
Chicago, Illinois — 12:00 noon. CDT
New York, New York — 1:00 p.m. EDT
Toronto, Canada — 1:00 p.m. EDT
Halifax, Canada — 2:00 p.m. ADT
Rio de Janeiro, Brazil — 2:00 p.m. BRT
London, United Kingdom — 6:00 p.m. BST
Berlin, Germany — 7:00 p.m. CEST
Paris, France — 7:00 p.m. CEST
Cape Town, South Africa — 7:00 p.m. SAST
Helsinki, Finland — 8:00 p.m. EEST
Moscow, Russia — 8:00 p.m. MSK
Istanbul, Turkey — 8:00 p.m. TRT
Dubai, United Arab Emirates — 9:00 p.m. GST
Delhi, India — 10:30 p.m. IST
Jakarta, Indonesia — 12:00 midnight WIB next day
Shanghai, China — 1:00 a.m. CST next day
Singapore — 1:00 a.m. SGT next day
Perth, Australia — 1:00 a.m. AWST next day
Hong Kong — 1:00 a.m. HKT next day
Seoul, South Korea — 2:00 a.m. KST next day
Tokyo, Japan — 2:00 a.m. JST next day
Brisbane, Australia – 3:00 a.m. AEST next day
Adelaide, Australia — 3:30 a.m. ACDT next day
Sydney, Australia — 4:00 a.m. AEDT next day
Auckland, New Zealand — 6:00 a.m. NZDT next day

Automate Mac App Updating in Jamf

A Jamf Admin’s tasks are never done….there always seems to be an app update you need to download from the vendor and upload to Jamf so your users are on the latest version and obviously the more apps you have the more you have to do so it can be quite a task to keep up.

Some of this can be controlled by Profiles for example Chrome can be set to be keystoned or configuring MAU to check and update Office but when you build a Mac you want it to be up-to-date straight away so that users does not get those update nags boxes to action.

So how can you keep the apps up-to-date in Jamf before deployment….Automation.

First off identify what apps you want to keep up-to-date automatically. If you already have set MAU to update Office and Chrome to stay up-to-date these are good candidates to have the very latest version install for your new builds but you might have some apps that you need to keep on a specific version until fully tested, perhaps a tool like Tanium or your VPN client.

Now you have your list there are two great options

Autopkg & Autopkgrhttps://autopkg.github.io/autopkg/ & https://github.com/lindegroup/autopkgr

Installomator  – https://github.com/Installomator/Installomator

Autopkg is framework that allows you to create recipes for software you want to update. It’s command line based but if that looks a little scary then Autopkgr is a UI for controlling Autopkg. I would highly recommend using Autopkgr just to keep things simple.

I’m not going to go into the detail of how you setup Autopkg/Autopkgr and create recipes as there are some great tutorials out there. What I will say is it requires an additional computer to run on. Perhaps you have an older Mac or a Mac mini, something that you can keep on 24/7 and connected to your network via Ethernet. It can be a little bit tricky to set up to begin with but once setup you can set it to check for a specific application like MS Office, download that app, package and upload to Jamf and update a policy. The policy then can be part of your new Mac setup process

So let’s say it’s the second Tuesday of the month and MS have just released Mac Office update. Overnight Autopkg will run, it will spot the update does its thing and uploads to Jamf. The next working day when a new Mac is built it will have that very latest update so on use no MAU update box for the user to deal with they will be on the very latest version of Office.

Autopkg is very capable and very flexible but it requires work and setup time.

Installomator is a little different but my now preferred solution. Installomator is a script you add to Jamf and then create a Jamf policy add the installomator script and specify the app you want install in the first Script Parameter Value in the Script payload of the Jamf policy. The Installomator script contains hundreds of values of apps and the associated download URL.

When the Policy runs the script gets the application directly from the vendors CDN. Unlike Autopkg the package is not stored in your Jamf instance it comes direct when required from the vendors server so is a more on demand solution. The policy can then be added to your build process. If using DEPNotify simple create a custom trigger name and add that trigger name to your DEPNotify script and ensure the policy scoping is correct.

The downside and upside of Installomator depending upon your point of view is you are not having to hosting the pkg or dmg. Now for some that could be great if your Jamf is hosted and bandwidth can be an issue but others security may be a concern. Have a read of Armin Briegels post on Installomator. The other issue is if the vendor changes the location of the download or changes it format from pkg to dmg, this will result in a failed policy so keep an eye on your installomator policy logs. If something fails you can most likely work out the new URL and either edit the script or create your own definition, it’s very simple to do and also you can submit any missing items to the dev team and help build out the solution for all.

So there are the two options. This article is intended to be high-level just to give an overview of options available to automate deploying the latest version of some apps.

In both solutions you will find some apps not available as a recipe if Autopkg or a definition in the Installomator script this is usually apps are only available to download after logging into an account, these you will still have to download, check the app and upload to Jamf.

I hope this quick overview helps give you some ideas of taking some of the burden out of app updating but most of all allows your users to get working on their Mac straight away with the latest version of apps installed.