JAMF is new, computers are not. Need to "Reimage"

Have you tried caching the Mojave installer on the devices and then scoping the policy to do the erase and install to a smart group that contains devices that have the installed cached only? That way you are 100% sure they have the package before you try to run the command.

Then your policy is install package, excuse command under the Files and Processes node (no need for a script) which would be "/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall" --eraseinstall --newvolumename "Macintosh HD" --agreetolicense &

@BVTMark You might find this useful: https://github.com/grahampugh/erase-install

As it happens, I used ARD to copy the installer to ensure every mac had the 14.5.02 version before I realized I could do that with Composer.
But I like the direction you're going since I've not really touched the Files And Processes section.

That said, Am I barking up the wrong tree with DEP/Prestage?

You're kinda veering off when you're talking about DEP/Prestage. DEP is your friend. Prestage enrollment is your friend.

You've got two problems and they're not related.

Problem 1: Upgrade to Mojave. See posts above on how to accomplish this. If you've already got the installer on each device, absolute worst case scenario you can just run the wipe command in terminal.

Problem 2: Install software to Lab computers. There's some considerations to be made here.
1) Are all labs the same?
2) Are all labs in the same prestage?

Let's assume YES to both questions. You have two ways of scoping out your programs. A Smartgroup or by Prestage Enrollment. Prestage enrollment is my preferred scoping method, but you do you. 30GB is too big for one package, so make sure you have your apps individually setup as much as you can. You can always make them available in Self Service too if you feel like you're having trouble installing. If you do your apps individually, it's going to be easier to update when versions change.

Even if they aren't all the same or in the same prestage, you can put groups in other groups. For example: I have 2 mobile carts (cart1 and cart2), both of them are in a Smart Group called Carts. If every computer gets, e.g. Adobe Acrobat, scope it to the top Carts group. Maybe a poor example, but you'll save time targeting the correct amount of devices, no wasted installs/licenses.

As to naming, there's a couple options depending on what version of JAMF you are on. Some people use the MUT. Personally, I end up manually naming each one via the JSS once I'm done, but I'm a maniac. I run a policy to Reset computer names based on the name in JSS at Startup. Set up static smart groups for each room to save some headaches later. Naming conventions can be a boon or a burden. My best advice is to scope based on Smart group or Prestage, not device name.

As to the Active Directory bit, use the Directory function within your Pre-Stage to point it at your AD server and/or do it with a Configuration Profile and the Directory function. We also setup a Mobile Account via Configuration profile, so it kinda depends on your setup, this is under the Mobility function.

Watch the JAMF 100 series. Learn about the PPPC tool, you WILL be using this. You have time.

"/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall" --eraseinstall --newvolumename "Macintosh HD" --agreetolicense &

--eraseinstall
Won't work unless the machine your trying to re-install is already formatted in APFS format, if it's HFS+ it will fail.

@larry_barrett If i'm veering off, its because i'm a little confused and frustrated and trying parallel tracks so I don't paint myself into a corner as I try to hammer out a best practice going forward. It would seem like the best approach would be DEP/Prestage imaging, I thought that devices added to DEP after purchase/deployment would still be able to pick up the enrollment after a fresh OS install and I'm not finding this to be the case, but having been around a while, I know better than to pin my hopes on claims made by marking people, so I have a backup plan or two in place.

Last summer came down to installing High Sierra via USB and using the Apple Migration assistant to deploy the apps. after all hope of imaging failed. Talk about UGLY, but that was plan D after A B & C failed miserably.

Anyhow, yes, I have attempted to deploy Creative Cloud apps as a single package before and it's never, ever worked. I have it broken down to five packages plus MS Office plus the other stuff needed. The apps I'm less concerned with but I want people to understand that this is more than a few ebooks and Photoshop and that's why I prefer to reimage.

So let's say we take a close look at Plan A: Plan A is to use the DEP/Prestage to automate. I attempted to do a Command-Control-R internet boot, wipe the drive and reload Mojave. Nothing ever got back to the machine to join an MDM. Did I do something wrong, or is just never going to work?

@jstillio Yes, this particular lab shipped with High Sierra and APFS, the other lab I converted to HPFS during last summer's debacle.

Make sure you are assigning your DEP enrolled devices to a pre-stage enrollment. One good way to get help on these forums is to post screenshots of your workflow (e.g. Screenshot of your Prestage enrollment settings). There are a lot of variables, so you'll get more help with more info posted. I learned JAMF on the fly about 2 years ago and I'm very famililar with the frustration you're experiencing. JAMF Support is VERY helpful, don't be afraid to reach out to them.

If you are not choosing to automatically assign (see photo), make sure you are adding your DEP enrolled devices to the pre-stage scope.

Don't worry about the apps part yet. Get your Lab situated and your Smart groups setup.

@BVTMark I don't see you mention what you're doing to get these in scope. Enrolling them alone won't do it. The pre-stage is great for all the basic enrolment stuff but to get all your policies to run you'll have to scope those too. Sorry if that seems too basic but I'm trying to see anything here that would explain you trouble.
- Scott

I'm in the similar situation with company type. The change of Adobe licensing, as well as imaging. That's the issue with DEP. The "Zero Touch" that everyone goes on about is not actually Zero Touch. It means Zero IT Touch. But that's not a workable solution, because that's not how most businesses operate. They don't give machines to users. Not too mention that users don't want to sit there waiting for their machine to setup, even if they can see a nice fancy loading screen.

If the machines still netboot (presuming they're aren't too new). Then you can take advantage of that by using System Image Utility to make a Netinstall of Mojave that you can boot to.

I've got this partially done, but only works on DEP ones currently (another issue cause not all of ours were brought with DEP and no way to put them in).

The netinstall can be modified with post install scripts, and packages that can complete the install (I'm still working on that part myself).

But that would be my suggestion to look into, especially if they aren't all DEP machines. DEP is Apple's solution to a problem that never actually really existed. *shrug.

@ScottyBeach Okay, I'm still kinda new to Jamf, but I assume you are referring to the SCOPE tab next to the OPTIONS tab within the Pre Stage Enrollment section, in which case, yes, I have scoped all macs in this lab

@summoner2100 OMG You GET IT! Yes! "Here's your new Mac, stand by while we download 30 gigs of applications over your wifi. You'll be up and running in 10 to 15 hours."

We use a hidden admin account to log into the device before hand and run policies. "Zero Touch" isn't even a goal of mine, because in the real world, people need more than just a Safari browser. Even if your programs are set to install after Enrollment Complete, we'd still do this before it gets to the end user.

@larry_barrett agreed, I'm not expecting anything more than Microsoft's lite-touch WDS would deliver, and that's to make my own job less of a hell. I'm okay with kicking off an install manually, but the less I have to do, the more I can focus on other priorities.

@BVTMark Litetouch WDSMDT doesn't even really do that much. I have Litetouch for my machines currently and it only prompts for two screens. Task sequence, and machine name. Technically, I can get rid of the task sequence screen as well, but I like to leave it there for the other techs.

But yeah, I get the whole "zero touch" issue. It doesn't work at all in education.

I will actually give you one tip though if you haven't already. Put the Jamf deployment share over a HTTP download link. I've moved a site over to that, and boy the speed difference to smb shares, and this is only currently a test using an app called Houston on a mac mini to host the link. Even with adobe, over http is faster.

@summoner2100 I generally use WDS to deploy a fresh windows install, along with Office and some utilities. But now we have an image for our enginerding and drafting shop with several Autodesk packages plus several dozen apps specific to the enginerding shop.

The great part of WDS is the elimination of mini setup afterwards, the machine is named, domain joined and mostly ready to use after it’s done.

But anyhow, my Apple rep had an engineer poke around and we discovered that Apple is not getting enrollments from jamf. Now I have a ticket with Jamf support.

@BVTMark We're still on Jamf 10.9 but I understand that on cloud instances of 10.13, there are options to scope and deploy packages and Configuration Profiles from a Pre-Stage. Maybe not so in on-prep and earlier versions. (Certainly not ours.) I also understand that the packages deployed from a Pre-Stage should be kept to a minimum. Maybe just a package to start a process going to get the rest of your packages and scripts deployed via Policies. Thos Policies are what I was referring to as needing to be scoped. I think when we move to 10.13 in a cloud instance we'll only deploy a package for DEPNotify and have it call for all the other post-enrolment policies.
Are you deploying all your other stuff in Policies after enrolment or trying to get them all out from a Prestage?
Maybe others on 10.13 can confirm or deny my wild claims about how those may work.
- Scott

@BVTMark

Using what @larry_barrett identified as your two tasks to tackle:

1. Upgrading all labs to Mojave
2. Provisioning the systems

Here are some ideas. I'm going to make an assumption that your systems are all APFS since they are running High Sierra. I know that's a bad assumption to make, but I'm going to make it.

Upgrade option 1: Since you mentioned you had already pushed out the Mojave installer, utilize ARD to send out the upgrade command using the Apple installer: "/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall" --eraseinstall --newvolumename "Macintosh HD" --agreetolicense &

That should restart the machine and continue the erase and install of Mojave.

Upgrade option 2: Utilize a policy in Jamf that has that command in the Execute Command field of Files and Processes. Scope to all lab computers with a trigger of Logout. Initiate a restart of the lab computers utilizing another policy in Jamf that sends /sbin/shutdown -r now. That should restart the computers and kick off the "logout" policy.

Upgrade option 3: Utilize ARD to send the install command.

Upgrade option 4: Utilize Mac Deploy Stick to get the macOS upgraded. Not ideal since this involves physically visiting each machine. However, adding in the Arduino dongle could give you some automation to the Zero Touch piece.

Now, as far as getting the software on the system I believe you said that all of these are in DEP. We can all agree that "Zero Touch" is not really that. There are, at a minimum three (I think) clicks before you get to the desktop of a system. So any workflow to get software on these systems will require a visit to each one for a few minutes of work.

I am a believer in utilizing scripts to do the software installations at provisioning time. You get more control (IMO) and can do a lot more stuff. I also believe in using a progress screen even if this isn't in front of a user. It provides feedback to the tech that is building a system so they do not think the system has "stalled" out and they wind up restarting. Have a look at DEPNotify-Starter from Jamf. It will get you started with this if you've never done a script or DEP Notify. The workflow I have built out for our environment (over 15k Mac under management) utilizes this process. Even though my presentation from JNUC last year doesn't go deep on provisioning, there is a demo video you can watch: JNUC2018

A prerequisite to using the script method is to have all of your software installers in "install" policies in Jamf. We utilize a policy for each app install that is just an installation policy with a custom trigger, scoped to all computers, and set to ongoing. This way we can "call" this policy from any other policy (or script) and then we only have one policy to ever change if the app is updated. You can watch @talkingmoose presentation from JNUC 2017 for more ideas and "flesh" around this: Moving Beyond Once Per Computer Workflows

Option 1 - PreStage with Enrollment Complete Policy - Setup your PreStage Enrollment the way you want it. We allow the creation of an account during Setup Assistant so we have that set in Account Settings:

Allowing account creation, whether an admin account or a standard user, gets you to the desktop automatically once Setup Assistant is done, which aids in the running of DEPNotify.

Otherwise the PreStage is pretty straight forward. Obviously make sure your systems are checked on the Scope tab.

Next we setup a Smart Group that has Criteria set to Enrollment Method: PreStage enrollment with the value set to the PreStage:

Next a policy that is set to Ongoing with a trigger of Enrollment Complete. We add our provisioning script to the policy and scope it to the Smart Group we just created.

Now when the computer gets done enrolling the policy should kick off and our software gets installed. Since we're using the script method we only have to have this one policy to install all of our software, and we can control the order the software gets installed without having to use special naming conventions for policies (1 - Install this first, 2 - Install this second, etc).

Option 2 - Policies for each software title - If you do not want to go the method above, you could simply create installation policies for each software title, scoped to All Computers, set to Once Per Computer, and triggered on Enrollment Complete, or Recurring Check-In or Logout maybe. Downside here is that you have to name your policies alphabetically if you need to install in a certain order.

Option 3 - One policy with all software - Create one policy that has every software title added to it, scoped and triggered as in Option 2. The downsides to this are the fact that if you have a software title update you have to edit every policy that has that title, and unless you're naming your application packages alphabetically, you have no control over order.

Hopefully this gives you some ideas that might tickle a brain cell. These are by no means the only ways, just ways that I might tackle the same situation.

So these are the PreStage enrollment settings:

This is the Device Enrollment page under settings.

General Settings under PSE:

Account Settings:

One profile is enabled, I use mostly policies.