According to http://docs.jamf.com/technical-papers/jamf-pro/deploying-macos-upgrades/9.21/Packaging_and_Deploying_the_macOS_Installer.html
Specifically: After dragging the Mojave install.app into Jamf admin it is suppose to extact the InstallESD.dmg file into Jamf Admin. I don't see it there. Not sure why. Following the instructions from below.
Step 1: Add the .app File for macOS to Jamf Admin or Composer
Adding the .app File for macOS to Jamf Admin
Jamf Admin extracts the InstallESD.dmg file from the .app file so you can cache and install it using policies. 1. Open Jamf Admin and authenticate to the Jamf Pro server. 2. Drag the .app file to the main repository in Jamf Admin.
Jamf Admin extracts the InstallESD.dmg file, analyzes its contents, and adds it to the master distribution point and Jamf Pro.
The InstallESD.dmg file is displayed in blue text until you add it to a category. 3. Double-click the package in the main repository. 4. Click the General tab and choose a category for the package. 5. Click OK.
Eh, I wouldn't follow that guide anymore at this point. At one time that was a good way to do it, but there are better methods now, as long as your Macs are on a relatively recent version of macOS to start with.
Take a look at this thread: https://www.jamf.com/jamf-nation/discussions/25509/macos-high-sierra-upgrade-methods-options
Don't be turned off by the fact that it has "High Sierra" in the title. Many of the linked scripts/workflows have been updated or validated to work with Mojave as well. In particular, I've used @Rosko's script here with pretty good success.
That being said, I've yet to use it to upgrade a HS Mac to Mojave, but looking over the current version, I believe it should work just fine.
@mm2270 and @jafienko I have been doing this for about a year now. Mainly, this is the process we use to "reset" the OS by wiping the drive, loading the OS and redeploying the applications. I do have a self service policy for those who want to only update the OS and it has worked pretty well. I say pretty well because we haven't had a lot of folks doing it this way. Most will use the App Store when updating from home or on some other non-college network.
+infiiity on @Rosko's script(s)....its been a lifesaver in our environment (even if Apple occasionally tosses a wrench into the workflow).
His GitHub page has loads of useful info, and is a must-bookmark page...thank you Jamf for hiring him!
PS, avoid DMG...use PKG, as recommended on his GitHub page...
If anybody is interested I have adapted @Rosko's macOSUpgrade script to incorporate parts of @grahamrpugh's erase-install script and his modified version of @gregneagle's installinstallmacos.py to download the OS installer from Apple's software update servers rather than downloading it from a Jamf Pro distribution point. It needs some sanitization before it's suitable for public consumption, but I could post it on GitHub for the curious.
Random question for anyone: using the method from kc9wwh/macOSUpgrade - it has worked amazing. I have been able to successfully deploy this update using 2 policies, one for the pkg file of the installer and the other containing the script. I've been able to update multiple Macs off our university campus network since many are working from home. I have 150 iMacs now to update on campus. The pkg file pulls from the SMB share just fine, but then the script calls out to Jamf Cloud based on the network logs and I know scripts are stored in the database. During testing, I have only done 5 Macs one at a time and I am ready to do the remaining 150 on campus. Has anyone who has used this specific method (or any scripted macOS upgrade method) notice any networking issues or a major impact on their network? Jamf Support says it should not have any impact on the network for this many Macs. Trying to plan accordingly and am open to any tips. Thanks!
@BRoper It's hard to say since every environment is different. I would recommend if possible that you try to deploy the installer app in advanced so that it's already on the computer. Perhaps schedule it so that it gets deployed after business hours and doesn't have as much impact on users who need to access on-site resources.