DEP: Remote Management/Enrollment vs System Sleep

[deej]

I've got DEP-based machine setup up and running - learned a lot about getting things in the right order - and it's working pretty great. I can already see how this will make things much easier, for new machines at least (figuring out what will happen to existing machines registered in DEP, particularly those the institution has bought but which have not been running our image will be the next thing).

The one thing that's got me stumped though is that the computer seems to take a long time to complete the "Remote Management"/enrolment step of the Setup Assistant (~20 minutes), to the point where the machine's out-of-box default power management settings cause it to go to sleep (~10 minutes) if left unattended. If I keep the computer awake by pressing keys, it completes flawlessly. If I don't, and then wake it up, it's kind of a coin-toss whether it will pick up where it left off and complete normally or need to be redone. But I can't readily give this to first and second level support and expect them to sit there for 20 minutes keeping machines awake.

I can tell when the Enrolment Policy kicks in, because the first thing in my DEP Policy, triggered by Enrolment Complete, is to run a script that locks out the screen and tells the user to stand by while provisioning completes (i.e. so they don't think it's "hung", and so they don't see and panic about the kext blocked messages that pop up while the machine is being set up, messages that will ultimately be resolved by the Approved Kexts configuration profile). The script also very early on executes a "pmset noidle" to keep the machine awake, allowing the remainder to complete smoothly. However, obviously this can only occur once enrolment is complete and it's all under way. There seems to be a very long gap where I don't have any control over the machine's power settings.

For info, the computer creates a record in the JSS quite quickly (as "DEP - 53R1ALNUM83R") upon starting the Remote Management/enrolment step - like, within seconds - which indicates it was enrolled by the PreStage enrolment method, and even indicates a Last Inventory Date of pretty much immediately that the record was created. That record is largely empty though; no apps, no OS details, etc, and is marked as Unmanaged.

Is it normal to take about 20 minutes before provisioning kicks in the Enrolment Policy?

[tnielsen]

I have noticed this too. I was wondering how I could initiate the next step faster. I have no answer for you but am investigating this now.

[Look]

Our environment got slower and slower in this regard over the course of several months (until it had reached several hours).
We then updated JAMF to 10.6 and after updating it was back down to a couple of minutes.
I suspect it was more to do with restarting everything than updating, but perhaps it was an actual bug (we were on 10.3 prior to updating).

[deej]

Thanks. I am seeing quite a few "JAMF Push Proxy return a non-200 status of: 403" errors in the logs (https://jss.domain.com:8443/logging.html). Not sure if it's related.
Configuration Profile revisions/pushes - e.g. Approved Kernel Extension for 10.13 - seem to take a while to push out as well. Again, not sure if it's related.
I'm logging it with Jamf.