I can think of ways to make that happen on newly imaged machines, but I can't think of one off the top of my head, that would work for previously imaged machines. You would need some sort of identifier on the unit itself (a receipt or specific package that could be inventoried, etc). Mind you, I am trying to answer your question regarding a script (EA) of some kind, being able to do this. If you have the prestage still in the JSS you could pull the info from that, in a variety of ways.
What's leading you to ask this specific question?
OK. I'm sure you have plenty of good reasons that I don't understand. So my short answer is: Include a receipt or other unique package in each configuration. You can run any number of policies tied to a "SMART Group" set to computers with each specific receipt file. Just in case you're not familiar, a "Dummy Receipt" is simply an empty, named file that exists in the place where the JSS looks for package receipts. You can create a "Dummy Receipt" simply by running the following command:
#!/bin/sh touch /Library/Application Support/JAMF/Receipts/dummyreceiptname.pkg
You could put something like this in the first run script for each pre-stage. Instead of "dummpreceiptname.pkg" you use something like pre-stage-1.pkg
With that said, my mind is still saying that there may be a more efficient way for you to distribute packages after imaging based on "stuff". What are you deploying after imaging and how is that broken up? It sounds like you're separating devices before you onboard (image, etc) them. I find that often they can be organized within the JSS by things like: Department, building, Tag#, etc so that you don't have to do this type of manual sorting.
What we are trying to do is have 2 different mac configurations that require different certs and different AD requirements. Prestage can take care of that for us. What prestage can't do is run any scripts. So in the post enrollment script (Enrollment trigger) we need to do a little more on one then the other prestage. So I was hoping there was a way to test in the post enrollment script which prestage it was and install the rest.
How are you running your post enrollment script? If it's a truly "post" enrollment then you should consider using a first boot or first run script as part of your pre-stage configuration. That will allow you to differentiate between the two pre-stages. Am I making sense?
You can make a smart group based on the Pre-stage enrollment used. Then create a policy that is scoped those machines. If you have that policy run a custom trigger you could have one fleet run all of the 'deploy1' custom triggers and another that runs 'deploy2' custom triggers and have them setup like that. I currently do that same kind of setup for our DEP machines. Smart group the enrollment prestage method and then have a main Policy that kicks off the custom trigger to install all of the individual policies for DEP machines. Name your Policies with numbers so they run in order. i.e. '00 - Install Chrome' '01 - Install Office' etc. If they all have the ongoing frequency and the custom trigger set, they will run in order when the custom trigger is called.
Yeah - I was trying to avoid having two enrollment policies, but I don't think I have a choice. Most likely I will just fire off all the policies, regardless of deploy type (from one enrollment policy) and use the smart group to ignore the ones based on prestage enrollment type.
It would be nice if you could plant something on the box during prestage enrollment and test for it.