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

BVTMark
New Contributor III

We are a vocational school which uses a couple of Mac multimedia labs equipped with Adobe Creative Cloud. Now our Adobe licensing is changing as well as version updates. Plus I need to get everyone on Mojave and this is consistent with our departments process of summer computer upgrades.

So last summer's plan to reimage our mac labs failed disastrously with High Sierra, which prompted us to proceed with Jamf as an MDM solution after hearing that it is the best choice.

So my macs are enrolled in jamf and AFTER that I have the newest macs enrolled in Apple's DEP. So I am able to do policies and all that, but I'm having a devil of a time with the Mojave install. I've picked up a few things here and there scattered throughout Jamf Nation and Jamf Success, but nothing that really sets a clear path from start to finish.

I've tried a couple of steps to get that "Zero Touch" magic that I keep hearing about, but it's not coming to life. FIrst, these are lab computers and students are not here for the summer. Further, i'm pushing out about 30 gigs of software, which is why we reimaged previously.

First I tried a pre-stage enrollment with a mac that (again, we owned this prior to jamf, but I did enroll it in DEP After we received and it is in the scope in pre-stage enrollment. Not being exactly sure what would kick off the process, I did an internet reinstall, which only did an in-place OS upgrade.

So I tried an internet wipe and reload which did exactly that, and nothing else. Next I tried making a package in Composer that would drop the package in Applications and run the erase install. Here is the exact script which is set to run After the package in the policy.

#!/bin/bash

# Start Erase and Reinstall process Mojave
/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall  --agreetolicense --eraseinstall --newvolumename "Macintosh HD" --nointeraction &

exit 0

So it runs and nothing happens. Nothing. It does complete, it just does nothing.

A couple of things that need to be addressed: We are tied into active directory as we are predominantly a Microsoft school. The computers are named by asset number, computer type and room number i.e. 3456im123, once the OS install takes place, the computers need to be re-enrolled(?) and assigned the correct name and preferably rejoined to AD.

Each user needs his own desktop with his own application preferences.

So my preference by far and if possible is to use DEP and pre-stage imaging, but I need to make something happen this week, so I'll take what I can get.

Again, the core issue is getting a clean OS layed out, renamed and tied to AD and JAMF.

Can someone please help me with this?

1 ACCEPTED SOLUTION

BVTMark
New Contributor III

So this dumb little unlabeled, unassuming checkbox under PreStage Enrollments Scope....
optional image ALT text

View solution in original post

21 REPLIES 21

awginger
Contributor

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 &

sdagley
Esteemed Contributor II

BVTMark
New Contributor III

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?

larry_barrett
Valued Contributor

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.

CSCC-JS
Contributor II

"/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.

BVTMark
New Contributor III

@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?

BVTMark
New Contributor III

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

larry_barrett
Valued Contributor

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. fbc61c096b524b61bf95c5200ba76ccc

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

ScottyBeach
Contributor

@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

summoner2100
Contributor

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.

BVTMark
New Contributor III

@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

BVTMark
New Contributor III

@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."

larry_barrett
Valued Contributor

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.

BVTMark
New Contributor III

@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.

summoner2100
Contributor

@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.

summoner2100
Contributor

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.

BVTMark
New Contributor III

@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.

ScottyBeach
Contributor

@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

stevewood
Honored Contributor II
Honored Contributor II

@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:

0b2126380e08471dbc4edd9f9ffbe6b4

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:

fef1815adedf4ee0aaa5b3352652398f

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.

BVTMark
New Contributor III

So these are the PreStage enrollment settings:

This is the Device Enrollment page under settings.
07eb5bb7e2d14ec0920e41d589ab139e

General Settings under PSE:
26fd6ffd2ef14c979f3effb4f8716faa

Account Settings:
d8faec69c9b94dd6b0d2b99d6bd0564e

One profile is enabled, I use mostly policies.

BVTMark
New Contributor III

So this dumb little unlabeled, unassuming checkbox under PreStage Enrollments Scope....
optional image ALT text