Skip to main content
Solved

De-scoping machines from Config Profile immediately after Enrollment

  • May 4, 2023
  • 14 replies
  • 29 views
N
Forum|alt.badge.img+7
  • Nate1
  • Contributor
  • 26 replies

Hello!

In the Jamf Connect documentation it suggests that some scenarios require scoping a config profile solely during enrollment:

Best Practice: Jamf recommends maintaining settings that only should be used during enrollment in a separate configuration profile. This allows you to remove the settings after enrollment without impacting other Jamf Connect settings.

My question is this:

What's the best way to scope machines into a config profile only during enrollment then immediately remove them from that after? 

Background: we use prestage enrollments and have an "enrollment only" configuration profile for the Notify Screen to install necessary apps, but that requires resetting the authchanger. We do so in the config profile, but one it's enrolled we no longer want to run the config profile with that authchanger reset.

 

Thank you!

Best answer by sdagley

@Nate1 There's a couple of options depending on how fast you want the unneeded profiles removed

If you don't mind waiting a create a Smart Group with the criteria Last Enrollment was more than 1 day ago, and use that Smart Group as an exclusion for the Configuration Profile.

If you want it removed as soon as possible you can use a Smart Group that contains machines that have finished going through your enrollment process, something like an application that is a default install. As with the above mechanism you'd just add this Smart Group as an exclusion for the Configuration Profile you want to remove after enrollment.

    14 replies

    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • 3567 replies
    • Answer
    • May 4, 2023

    @Nate1 There's a couple of options depending on how fast you want the unneeded profiles removed

    If you don't mind waiting a create a Smart Group with the criteria Last Enrollment was more than 1 day ago, and use that Smart Group as an exclusion for the Configuration Profile.

    If you want it removed as soon as possible you can use a Smart Group that contains machines that have finished going through your enrollment process, something like an application that is a default install. As with the above mechanism you'd just add this Smart Group as an exclusion for the Configuration Profile you want to remove after enrollment.

    T
    Forum|alt.badge.img+19
    • Tribruin
    • Honored Contributor
    • 582 replies
    • May 4, 2023

    @sdagleyhas a good suggestion in using a file to trigger whether enrollment is complete. What we do is write a file to the drive when enrollment is complete. (It has the date the enrollment was completed.) We have an EA that checks if that file exists or not and returns a Yes or No. We have a Smart Group called BUILD COMPLETE that is computers with the EA = Yes. 

    You could do something similar and just exclude the Smart Group from your Profile. Once the file is written and an inventory is taken, the computer is added ot the Smart Group and the profile would be removed. 

    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • 3567 replies
    • May 4, 2023

    @sdagleyhas a good suggestion in using a file to trigger whether enrollment is complete. What we do is write a file to the drive when enrollment is complete. (It has the date the enrollment was completed.) We have an EA that checks if that file exists or not and returns a Yes or No. We have a Smart Group called BUILD COMPLETE that is computers with the EA = Yes. 

    You could do something similar and just exclude the Smart Group from your Profile. Once the file is written and an inventory is taken, the computer is added ot the Smart Group and the profile would be removed. 


    @Tribruin A hidden file and an EA to detect it is the approach I actually use to declare my enrollment process is complete. I figured for orgs new to Jamf Pro using an app installed as part of their initial enrollment might be an easier indicator.

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • 26 replies
    • May 4, 2023

    Thank you everyone!

     

    As suggested by the replies, I have added a quick line near the end of my Notify script to touch/create a file. I then created an extension attribute to check if that file exists and have a smart group for all machines with that file and excluded that smart group from the scope of the temporarily-needed Config Profile.

    This has the added security benefit of adding a check for that same file at the beginning of the Notify script and exiting if it sees it! That way it will not accidentally run twice (though hopefully this is already of course solved by removing the config profile in the first place).

     

     

     

    The verbose answer:

    In the Notify script add (near the end):

    #create "dummy" file to indicate machine has been imaged. This will be used with an extension attribute to indicate enrollment is complete touch /usr/local/jamfconnect/scripts/enrolled.txt && date > /usr/local/jamfconnect/scripts/enrolled.txt

    This creates a dummy file, and if necessary (though completely optional) adds the date/time of when it runs

     

    Create an extension attribute:

    #!/bin/zsh if [[ -f "/usr/local/jamfconnect/scripts/enrolled.txt" ]]; then echo "<result>true</result>" else echo "<result>false</result>" fi

     

    Create a smartgroup that checks for that ^ EA as "true".

     

    For the temp Config Profile:

    • scope IN a group that makes sense for machines you're enrolling (this could be any of a million things that make sense for your environment but we use built-in attribute: "Enrollment Method: PreStage enrollment" and the value is this prestage enrollment we setup)
    • scope OUT a smartgroup with criteria is "[your extension attribute from above] is TRUE"

    For the ongoing Config Profile, just scope IN that same smartgroup from bullet #1 in the temp Config Profile above

     

    Lastly, as an optional step, in the Notify script add near the top:

    #Check for 'enrollment complete' file created at end. If exists, exit this script: if [[ -f "/usr/local/jamfconnect/scripts/enrolled.txt" ]]; then echo "Enrollment file already found!" exit 0 fi

    (I added this into my script after line #12 that contains "echo $TOKEN_UPN" from the example script in the Jamf Notify documentation)

    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • 3567 replies
    • May 5, 2023

    Thank you everyone!

     

    As suggested by the replies, I have added a quick line near the end of my Notify script to touch/create a file. I then created an extension attribute to check if that file exists and have a smart group for all machines with that file and excluded that smart group from the scope of the temporarily-needed Config Profile.

    This has the added security benefit of adding a check for that same file at the beginning of the Notify script and exiting if it sees it! That way it will not accidentally run twice (though hopefully this is already of course solved by removing the config profile in the first place).

     

     

     

    The verbose answer:

    In the Notify script add (near the end):

    #create "dummy" file to indicate machine has been imaged. This will be used with an extension attribute to indicate enrollment is complete touch /usr/local/jamfconnect/scripts/enrolled.txt && date > /usr/local/jamfconnect/scripts/enrolled.txt

    This creates a dummy file, and if necessary (though completely optional) adds the date/time of when it runs

     

    Create an extension attribute:

    #!/bin/zsh if [[ -f "/usr/local/jamfconnect/scripts/enrolled.txt" ]]; then echo "<result>true</result>" else echo "<result>false</result>" fi

     

    Create a smartgroup that checks for that ^ EA as "true".

     

    For the temp Config Profile:

    • scope IN a group that makes sense for machines you're enrolling (this could be any of a million things that make sense for your environment but we use built-in attribute: "Enrollment Method: PreStage enrollment" and the value is this prestage enrollment we setup)
    • scope OUT a smartgroup with criteria is "[your extension attribute from above] is TRUE"

    For the ongoing Config Profile, just scope IN that same smartgroup from bullet #1 in the temp Config Profile above

     

    Lastly, as an optional step, in the Notify script add near the top:

    #Check for 'enrollment complete' file created at end. If exists, exit this script: if [[ -f "/usr/local/jamfconnect/scripts/enrolled.txt" ]]; then echo "Enrollment file already found!" exit 0 fi

    (I added this into my script after line #12 that contains "echo $TOKEN_UPN" from the example script in the Jamf Notify documentation)


    @Nate1 Thanks for following up with details on how you implemented your solution.

    I actually make a lot of use of flag file/EA/Smart Group trios for scoping things in my environment because our Jamf Pro API endpoint isn't accessible to devices not connected to the org network. Here's a post with the utility script to create flag files and a template EA for reading them: https://community.jamf.com/t5/jamf-pro/self-service-policy-to-display-a-list-of-static-groups-and-prompt/m-p/256635/highlight/true#M237842

    S
    Forum|alt.badge.img+8
    • ssoun
    • Contributor
    • 20 replies
    • May 6, 2023

    What we do is create a Config Profile without any scoping and only add it to PreStage. Once PreStage is done, the config profile is automatically removed since there's no scope to it. We use it to change the authchanger to the Notify screen.

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • 26 replies
    • May 6, 2023

    What we do is create a Config Profile without any scoping and only add it to PreStage. Once PreStage is done, the config profile is automatically removed since there's no scope to it. We use it to change the authchanger to the Notify screen.


    @ssounI have found this to not work. Is that not the case?

    If my config profiles aren't scooped to the machines I want them on, even for just the prestage enrollment, they won't apply.

    S
    Forum|alt.badge.img+8
    • ssoun
    • Contributor
    • 20 replies
    • May 6, 2023

    @ssounI have found this to not work. Is that not the case?

    If my config profiles aren't scooped to the machines I want them on, even for just the prestage enrollment, they won't apply.


    We are using it without issues with Jamf cloud. We have the auth changer for the notify screen in a config profile that is only in PreStage, there are no computer or user scope on the config profile and it applies during PreStage. Are you selecting the config profile in your PreStage? We are also deploying a Microsoft Office installer selection config profile that way and it's working correctly to apply only during PreStage. 

     

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • 26 replies
    • May 6, 2023

    We are using it without issues with Jamf cloud. We have the auth changer for the notify screen in a config profile that is only in PreStage, there are no computer or user scope on the config profile and it applies during PreStage. Are you selecting the config profile in your PreStage? We are also deploying a Microsoft Office installer selection config profile that way and it's working correctly to apply only during PreStage. 

     


    That's very interesting! I could swear I tested this quite a bit because that way would make the most sense... But never got it to work and only after scoping in the machines did it apply, even on first/prestage boot.

    I do know that with them scoped out it does download, but I was nearly positive it didn't apply.

    I'll text more next week

    T
    Forum|alt.badge.img+19
    • Tribruin
    • Honored Contributor
    • 582 replies
    • May 6, 2023

    If a config profile is installed during the PreStage it will only be installed until the first Jamf Recon has run. This usually happens a couple of minutes after the initial enrollment. At that point, Jamf will calculate the scoping and either leave the profile installed or remove it. 

    So, it is a race condition whether the profile will still be installed at any point during setup. It may work, but, personally, I would not want to rely on it. 

    S
    Forum|alt.badge.img+8
    • ssoun
    • Contributor
    • 20 replies
    • May 6, 2023

    If a config profile is installed during the PreStage it will only be installed until the first Jamf Recon has run. This usually happens a couple of minutes after the initial enrollment. At that point, Jamf will calculate the scoping and either leave the profile installed or remove it. 

    So, it is a race condition whether the profile will still be installed at any point during setup. It may work, but, personally, I would not want to rely on it. 


    From the sound of what the OP wants, which is just to set the Auth Changer to the Notify screen, setting no scope for the config profile should work since it's the first thing that runs. Even if the config profile is removed during the Notify screen, it shouldn't matter as all it does it set Jamf Connect to use the Notify screen, which is already running.

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • 26 replies
    • May 10, 2023

    From the sound of what the OP wants, which is just to set the Auth Changer to the Notify screen, setting no scope for the config profile should work since it's the first thing that runs. Even if the config profile is removed during the Notify screen, it shouldn't matter as all it does it set Jamf Connect to use the Notify screen, which is already running.


    Okay so a bit of some interesting updates:

     

    I was able to test by removing my machines from the scope entirely but something was still not working correctly: I had two config profiles, and only one was downloading on enrollment with my prestage. That one had 3 payloads: The Auth Changer (upload), the Jamf Connect settings (upload), and the com.jamf.connect.login (Jamf Application). For some reason, the Auth Changer would work because the Notifiy script would start, but oddly it was the default script, not the one we created.

    Adding my second config profile (which was an exact duplicate of the first just WITHOUT the Auth Changer) would start the correct Notify Script. 

    That lead me to believe I could use both pare down my first config profile to ONLY the Auth Changer upload and nothing else.

    So now I still have two config profiles: One that has a single item: The Auth Changer upload (from the end of this doc: https://learn.jamf.com/bundle/jamf-connect-documentation-current/page/authchanger.html)

    And another that has my Jamf Connect Settings. 

     

    The first isn't scoped at all, the second is normally scoped to all machines going forward, and both are downloaded during the Prestage Enrollment. That could eliminate the need extension attribute as it's not technically being used anymore (it was only used to scope OUT the original config profile - but that doesn't have any scope at all anymore). It could also eliminate the need for the lines in the Notify script to create the dummy file and check for it but I'll leave those as a safety precaution anyway.

    S
    Forum|alt.badge.img+8
    • ssoun
    • Contributor
    • 20 replies
    • May 10, 2023

    Okay so a bit of some interesting updates:

     

    I was able to test by removing my machines from the scope entirely but something was still not working correctly: I had two config profiles, and only one was downloading on enrollment with my prestage. That one had 3 payloads: The Auth Changer (upload), the Jamf Connect settings (upload), and the com.jamf.connect.login (Jamf Application). For some reason, the Auth Changer would work because the Notifiy script would start, but oddly it was the default script, not the one we created.

    Adding my second config profile (which was an exact duplicate of the first just WITHOUT the Auth Changer) would start the correct Notify Script. 

    That lead me to believe I could use both pare down my first config profile to ONLY the Auth Changer upload and nothing else.

    So now I still have two config profiles: One that has a single item: The Auth Changer upload (from the end of this doc: https://learn.jamf.com/bundle/jamf-connect-documentation-current/page/authchanger.html)

    And another that has my Jamf Connect Settings. 

     

    The first isn't scoped at all, the second is normally scoped to all machines going forward, and both are downloaded during the Prestage Enrollment. That could eliminate the need extension attribute as it's not technically being used anymore (it was only used to scope OUT the original config profile - but that doesn't have any scope at all anymore). It could also eliminate the need for the lines in the Notify script to create the dummy file and check for it but I'll leave those as a safety precaution anyway.


    The config profile without a scope should just be the auth changer. You would want the other 2 settings in a separate config profile that is scooped to machines as those are more permanent configurations. You shouldn't have all 3 together in 1 config profile as the auth changer is only needed in the beginning to change the prestage to launch the notify screen.

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • 26 replies
    • May 10, 2023

    The config profile without a scope should just be the auth changer. You would want the other 2 settings in a separate config profile that is scooped to machines as those are more permanent configurations. You shouldn't have all 3 together in 1 config profile as the auth changer is only needed in the beginning to change the prestage to launch the notify screen.


    Understandable!

    I wasn't sure when the non-Auth Changer settings would get applied to the machine so I initially had everything in one. Then as I slowly split them apart in trying to troubleshoot I was nervous about fully removing everything, namely Filevault. My thoughts were to have two similar Profiles and they could hand off to each other whenever it suited them with no concern of mine - because they had nearly the same settings.

    Obviously somewhere along the line it dawned to me to have both downloaded at Enrollment rather than just one, and use just one for the Auth Changer settings.


    Terms & ConditionsCookie settingsAccessibility statement