We are just starting to use DEP for Mac enrolments, using on-prem Jamf Pro 10.13. Went to do a build using new Macbook Pro h/w that had been in sitting in storage for a while. I allocated the Pre-stage job in JSS, and then powered on device. DEP job was not picked up and standard setup screens were displayed (Data & Privacy screen etc.) Turns out the MBPro system had lost the current date and time and was showing as Jan 2002.
I went through the manual setup steps, created an account, then manually set the date and time. I then wiped the disk and re-installed the O/S. Booted up and wham, the device picked up the DEP job, and enrolment commenced. The only way to fix the time is to follow these steps, as the date and time are not accessible during the boot/setup stage. Anyone else come across the situation and solutions to resolve ?
In our computer PreStage, under Setup Assistant Options, we leave the "Location Services" unchecked. This way during setup, we are prompted to enable Location Services which in turn sets the date and time based on location. Not sure this is what you're looking for but thought I would share. Good Luck...
@mark.sampers Thanks Mark. Unfortunately its a bit of a catch-22. IF the device does not have the correct date/time, it will never pickup the DEP job :(. Hence with your suggested approach where you have set the DEP job to allow location services the device will never get to that point (hope that makes sense). Additionally, from my testing, i have found that once a device has got to that point in the setup process where it has failed to detect that the device is DEP managed, even rebooting and restarting the process it will never pick up the DEP task. I'd suggest a flag is set at that point that the device is NOT DEP managed. A wipe and re-install of the os is then required to wipe that setting to then be able to DEP enroll that device.
@mainelysteve and @jracosta great tip - thanks guys ! With DEP we are aiming to minimize interaction/minimal touch for our provisioning engineers who perform the pre-stage/setup on behalf of the user. In the situations I've seen the invalid date issue there is no indication during the setup stage that the date is wrong before its too late. By the time its clear the DEP assignment is not detected, its gone beyond that point in the setup process, and I have to correct the date, re-install the OS and run through the setup process/DEP enrollment again (reducing value of DEP) :-( So the dilemma is, do I add an additional step to the build/enrollment of EVERY Mac device, or deal with it by exception? For new hardware we install the MacOS from a USB (using createinstallmedia - Mojave for now) , so Im thinking that at that point I include a manual step (for every new Mac device) to jump to terminal during the boot to USB, then check the date before I do the wipe/OS install, and if incorrect then fix. Using this approach all devices should be good to go with an automated DEP install. Its just a pain to have to add this manual step, when were trying to achieve minimal interaction. Open to other ideas how to further automate/streamline this though ? thx all
<update> @jracosta looks like Apple in their wisdom have removed the NTPDATE cmd from >=Mojave, replaced with SNTP cmd JAMF article here although cant get this to work during setup phase without SUDO, and p/w for SUDO unknown at this point as _mbsetupuser a/c is being used and p/w not known for this a/c. So will have to revert to using the "date mmddttttyy" cmd during initial wipe/install OS stage, unless theres other options ?
Just a. It’s for anyone else following this thread. I was convinced a time mismatch was why my VM wasn’t enrolling via our prestage enrolment. The reality was that I had copy/pasted in the serial number etc to the .VMX file and it didn’t like the encoding of the characters. Typing it all in manually resolved. Worth a try - (I know this doesn’t sound like OPs issue)