Re-enrolling Devices to DEP? And so much more...

1 - I'll assume you mean re-enroll without deleting the old device record? If so, yes. See the 're-enrollment' settings in Global Management to clear various settings based on your needs.

2 - Content Caching will provide the appropriate items to appropriate devices.

3 - After an erase and install, users will be prompted to accept management and enroll via DEP at Setup Assistant.

4 - Are you upgrading or doing an erase and install? For upgrades, they should already be enrolled, no need for DEP. Push the installer and script startosinstall to trigger the upgrade. If you're doing an erase and install, using a macOS Installer USB might be your best bet. Things might get easier next year however as you may be able to use the startosinstall command with the --eraseinstall flag.

1 - Yes, I'd like to not delete the old device record if possible.

3 - Just to verify, if I do an erase and install, it will prompt to accept management, even if the old device record is still in JAMF?

4 - Ideally, I'd like to do an erase and install and add them to DEP, but we need to do about a thousand desktops this way. Booting each one of them to USB doesn't seem to be very efficient or appealing. That's why I was trying to netboot them. Is there a way to netboot them, then I guess in JAMF Imaging (or some other utility), push out a script for startosinstall --eraseinstall? (Just thinking of this now...). Does the --eraseinstall require APFS? Most of our equipment do not have SSDs, so not sure this is an option for us..

I don't know if this was a one-off scenario but I just tried to re-enroll a Mac on 10.12 via DEP earlier today and was unable to simply because the computer record was in the JSS. Our only successful option was to delete the computer from the JSS and then it almost immediately picked up the PreStage and completed DEP enrollment.

This discussion appeared particularly relevant today as well and may be of interest to you. Again, I haven't had the time to extensively test with multiple 10.12 and 10.13 computers and my recent experience was on a single computer. What I saw may not be the norm anymore. Link: https://www.jamf.com/jamf-nation/discussions/19352/attempting-to-re-do-prestage-enrollment#responseChild116053 Maybe @stevewood could chime in to provide an update?

@cstout Wow, that's just a bit old. ;-) Lately in my testing I've been able to re-enroll a machine through DEP without having to remove it from the Jamf Pro Server. In fact, that is the way it should be, that a machine does not have to get deleted from the JPS for it to enroll via DEP.

We have multiple MDM servers setup in DEP, one for each business unit in our org. I have seen where the DEP configurations of the MDM servers have not worked and I've had to delete the MDM servers from DEP and all of the config in JPS (DEP config & Pre-Stage) and then re-create.

Also, if you are using two different URLs for your admin traffic and your client traffic, you must make sure that you do all configuration of the DEP server from the JSS URL. So whichever URL is in Settings -> Global Management -> Jamf Pro URL, make sure that is where you download the Private Key from and setup your MDM server. Otherwise you will get weird results.

Hope that helps.

@stevewood Oldie but a goodie, plus I knew you were still here. Thanks for the reply and as always, the wealth of useful information. Now, back to our regularly scheduled program. ;-)

Hello @nikki what we have been doing is the erase and install method on our existing Macs and they immediately re-enroll using DEP. We also have all of our Macs using our pre-stage enrollment so once the Mac is wiped and it restarts, we click through a couple of screens and accept remote management and all is well.

@cstout Thanks - it may be an old post, but it seems to work. If nothing else I may end up doing a combination of the script in that link + pushing out a cached copy of the High Sierra install and a startosinstall script to upgrade.

@stevewood Not sure we'd have to delete the MDM server from DEP (hopefully), since our iOS devices enroll fine, and a MacbookPro fresh out of the box will enroll fine. Just need to figure out these older computers... for now.

@mconners What do you use to erase and install? Do you mean the --eraseinstall switch to startosinstall (is that for 10.13.4 & APFS only?), or do you netboot to JAMF imaging, send a remote wipe command, etc?

Sorry @nikki I should have clarified my statement. Our first order of action was to get all of our Macs to 10.13.4 or higher and on APFS. This will support our process of using the startosinstall switch of -eraseinstall. So far, we are closing in on 80% of our student systems have been moved to both APFS and 10.13.4 or higher.

It's really nice to have all the moving pieces in place such as pre-stage enrollment, the correct OS and drive format. Now, we can easily remotely control our process of wiping a drive and laying down a fresh OS along with the apps any user should need.

Everything we do now is based on name. With the correct name, all of the profiles, policies and more flow down to the Mac without really any intervention.

Thanks! On to the next hurdle...
I'm currently testing 2 methods right now. 1 - We created a Netinstall set through System Image Utility to install a base High Sierra install. That erases the drive, so when it boots up again we can enroll into DEP. Then we're relying on individual policies to push out all the apps and settings it needs (unless someone can suggest a more streamlined way to do this). 2 - I pushed out a cached copy of the High Sierra install app through JAMF, then pushed out a script for macosinstall so that it upgrades. Then I was going to push out the osinstall script again to do an erase and install to get to DEP... while it's time consuming to reinstall twice (and then pull down all the apps again), it's less interaction on our parts in theory.

Doing both of these things (and also with our old image and user-approving the MDM profile), the MDM profile flips to Unverified and I have to manually type "sudo jamf trustjss" on each computer at some point. It's then verified again, but this is maddening. It's not like I can even push out a script to fix it - when the MDM profile is unverified, it won't access scripts. I assumed once it's in DEP it wouldn't do that anymore! Anyone know of a way to prevent the Unverified profile, or why it does that in the first place?

Hello again @nikki. If you wish, I have a few high level overview documents I created a month ago to describe our workflow. Send me an email if you would like to see them, I can send them your way. mconners@madisoncollege.edu

They provide some insights on what we do and how.

@nikki We have over 1000 devices to reimage and found that creating a share or a push service was too much to work with and could go wrong. I have done ~300 + devices in two days and it works well with the APS Apple configurator to create an image stick. 3-7 minutes to update the Firmware and a reboot to install the newest APFS, then a final reboot to wipe the SSD and install the OS... once that starts I can pull the USB stick and move to the next device.... goes quickly when one has 15 USB drives going at once. I recommend this to do a fresh clean install, then before creating the account run the smart group to delete the devices from JSS. Only one question I have for anyone who knows, I tried to use DEP and it said that our DEP is now included in ASM. So is that becasue we are a school?

@rhooper - Yes, I think that is exactly it. When we set up DEP last year, they told us to access our account through school.apple.com. I got the impression from the rep I spoke with that ASM was a relatively new thing (though I won't swear to that), and all school organizations would go through ASM moving forward.

About the flash drive method, this just blows my mind. I feel like moving away from netboot and automation and towards not only touching every machine but also having to use a flash drive on each is moving completely in the wrong direction. Am I alone in this? Last year we didn't have to touch most of our iMacs - we'd use Apple Remote Desktop to reboot them directly into DeployStudio, which would immediately push out an image and enroll JAMF in the postinstall scripts. I get the added security stuff now, blah blah blah, but really Apple? Using flash drives at this point is cumbersome at best. Especially since newer Macbook Pros only come with USB C ports...

But relying on a bunch of individual policies to execute smoothly on every single machine also is not the greatest plan, thus my dilemma...