Return to Service app maintaining scope after it is run

[marstalls]

Does anyone have suggestions how to maintain iPads in the Return to Service app scope after it is run? The iPads are dropped from static groups, and I can't think of a smart group that will retain the iPad after it is erased (other than all iPads and I don't want scope this to all iPads).

[stevewood]

You could use the PreStage as criteria for a Smart Group. The criteria is "Enrollment Method: PreStage enrollment" and then you choose the name of the PreStage. Only word of caution is that if the PreStage gets deleted at a later date, all of the devices enrolled by that PreStage will fall out of the Smart Group. I think that happens if the PreStage is renamed as well, but am not 100% on that.

Aside from that, finding some criteria that is unique to the devices would help as well. If you're requiring a sign in during the enrollment, finding an attribute from your directory service that you could key off of might work as well.

[marstalls]

Thank you @stevewood. I went off in a different direction inspired by your suggestion.

To make a smart group that sticks for Return to Service (Let's call it RTS here.) I used several bits of info from the PDF "Jamf+Return+to+Service+-+Guide.pdf."

First, I added the RTS Extension attributes as explained in Appendix B, 3. Add Return to Service to Attribute

Second, make a smart group as explained in Appendix B, 4. Add Smart Device Group. EXCEPT I did not include the second criterion: "App Name has Return to Service." I only kept the first criterion. (Important bit.)

Third, I followed the explanation under the heading Send to Mobile Device. For my test iPad, I went to its tab Inventory > General and set Return to Service to "Start". Hit Save.

Fourth, I scoped the RTS app to my newly made smart group Return to Service.

I ran the app on the test iPad again. It went through the whole process, got its Wi-Fi, went through the configuration, and then identified my test iPad as still belonging to the RTS smart group which is in scope of the RTS app and it re-installed the app, pretty as you please. Yay.

I'll test this some more. It looks like the only thing I'll have to do for iPads that I want to run RTS app is to manually set their Inventory > General > Return to Service to "Start." Small price to pay. I've only got a smallish subset of my iPad fleet that need this capability. I can manually change their inventory setting to make this Rube Goldberg thing work.

[marstalls]

I found another way to isolate a group of iPads manually so that they will stay in whatever scope—for profile or app—that you want. If you don't depend on the Inventory Asset Tag field for your workflow, try this.

In the Inventory tab for the iPad, go to General. Click Edit. Add some brief meaningful peculiar text to the end of the Asset Tag field. Repeat for other iPads you want to isolate in this group.

Make a new Smart Group. I named it the peculiar text from the above step. Set the criterion to Asset Tag Like YourPeculiarText. Save. This smart group will not be emptied by running Return to Service so you can use this method to stay in scope of profiles and apps on the other side of running Return to Service on an iPad.

[Ehouston3]

I agree with Steve, this is the approach I took as well (Smart Group with criteria). The Jamf documentation is great and everything works nicely. I utilize the Mobile_Configuration EA and populate it with a config name, then use that as the criteria for the Smart Group. The Smart Group is then in scope to the WiFi config profile used for RTS and the Jamf Return to Service app. I chose to add the "rts_auto" key to the AppConfig also and configured several of the workflows from the documentation in Jamf since I was playing with triggering RTS on connect with cfgutil and API calls.