Skip to main content
Solved

Devices not always deploying/enrolling correctly

V
Forum|alt.badge.img+5

Hi all, we are trying to finalise a roll-out of Jamf for Mac management, with zero-touch from IT. Devices are enrolled automatically to our Jamf MDM server in Apple Business Manager, and ideally we'd like to send devices directly to users, for them to unbox and run through Jamf Pre-Stage Enrollment.

The issue I have seen, maybe one in every 10 builds, is enrollment will not complete correctly. We have a device at the moment that hasn't renamed correctly, hasn't deployed all Enrollment Complete software/policies, and hasn't deployed all config profiles (including FileVault enablement).

Running this command locally on the device will essentially re-run enrollment:

sudo jamf policy -event enrollmentComplete

but my concern is sending a device to an end-user, the device doesn't enrol correctly, the user tries to work on the device but doesn't have Office apps, or the device doesn't meet security requirements, such as disk encryption.

Does anyone have any advice please?

Thank you

Best answer by sdagley

verticalben wrote:

Hi there, we are triggering multiple policies with the Enrollment trigger. Is the DEPNotify best practice?

"Allow Network State Change Triggers" was enabled - I have now unticked this. Thank you


@verticalben Using the DEP-Notify script to drive DEPNotify will be more reliable than multiple policies triggered by Enrollment. It's not the new hotness, but it still works. I would suggest that you have some sort of verification script that runs after your enrollment is finalized to verify that everything ran as expected.

View original
    Did this topic help you find an answer to your question?

    5 replies

    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • 3540 replies
    • March 7, 2023

    @verticalben How are you driving your enrollment process? Are you triggering multiple policies with the Enrollment trigger, or are you using something like DEPNotify-Starter that uses one Enrollment triggered policy to run  script that in turn triggers other polices and uses the DEPNotify app to provide progress feedback?

    Another thing that can cause problems with device enrollment is having "Allow Network State Change Triggers" enabled in Settings->Computer management->Check-in

    V
    1 person likes this
    • V
      verticalben
    V
    Forum|alt.badge.img+5
    • verticalben
    • Author
    • New Contributor
    • 8 replies
    • March 7, 2023

    Hi there, we are triggering multiple policies with the Enrollment trigger. Is the DEPNotify best practice?

    "Allow Network State Change Triggers" was enabled - I have now unticked this. Thank you

    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • 3540 replies
    • Answer
    • March 7, 2023
    verticalben wrote:

    Hi there, we are triggering multiple policies with the Enrollment trigger. Is the DEPNotify best practice?

    "Allow Network State Change Triggers" was enabled - I have now unticked this. Thank you


    @verticalben Using the DEP-Notify script to drive DEPNotify will be more reliable than multiple policies triggered by Enrollment. It's not the new hotness, but it still works. I would suggest that you have some sort of verification script that runs after your enrollment is finalized to verify that everything ran as expected.

    V
    1 person likes this
    • V
      verticalben
    S
    Forum|alt.badge.img+8
    • SCCM
    • Valued Contributor
    • 148 replies
    • March 7, 2023

    You might also want to look at what you have in your prestage. You want the bare minimum in there. not loads of apps ( Security config) the first policy you should deploy to M1 machines is prob still a Rosetta install. You could create a single policy which runs a script to run the other policies on a trigger, rather than setting them all to run at enrollement.

    V
    1 person likes this
    • V
      verticalben
    V
    Forum|alt.badge.img+5
    • verticalben
    • Author
    • New Contributor
    • 8 replies
    • March 8, 2023

    @SCCM , @sdagley , thanks both for your feedback. I'll have a look into something like DEP-Notify, that sounds like a much better idea!

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings