Multiple Mac Boot partitions

I don't think so, atleast not easily. Casper used to use the MAC address as a unique identifier, then they switched to the serial number. I think you might need to get creative with your smart groups. Perhaps leave a crumb file somewhere on each OS.
ie touch /var/.standardimage and touch /var/.csdepartment
then use smart groups to scope based on that. That will also save you the problem of licensing. If each machine was treated as two, your licensing requirements just doubled.

Casper 9 uses the UDID, not the serial number, but same difference. Its a hardware ID, so I agree it would not be easy to see them as two separate Macs. Using the "breadcrumb/dummy receipt/touched file" approach is also the only way I can think of to achieve this, maybe. You can create a Smart Group for your CS department booted partitions to use as an exclusion in any policies they may not want applied to their partitions.

The only issue I see is if you enroll both OS partitions into Casper you'll be overwriting the record in the JSS each time its booted into the other OS and recons again. I'm not sure how well that will work out for you. It might be fine, but I would test that out.

More than you would probably want to do... but you could have a completely separate instance of Casper for them to enroll to. Not sure how licensing etc... etc... would work with this though.

Could one of the two OSes be netbooted?

Thanks for the suggestions/ideas. I'll work with it and see how well the breadcrumb method would work with the records also switching back/forth, but it might not be a bad idea to see if the CS department ultimately would want to manage their own instance, and we'd just share packages as needed. Probably healthier long-term. :)

@pete_c To make sure I'm understanding your question, do you mean to have one of the two images hosted on a netboot server, rather than as an actual installed partition, and just network booted as needed for students who need to access that image?

I haven't tried it but I suspect having the Mac report into a single JSS twice would cause quite a few problems. The inventory would get pretty confused. For example:

• What applications would it report as being installed?
• If you run a policy "once per computer", it wouldn't run on the second partition
• If you have any extension attributes reporting the state of the machine this could keep switching

I would go with the recommendation from @Look and set up a multi-context JSS, so you could have https://yourjss.com:8443/standard & https://yourjss.com:8443/cs on the same server.

You would just need to check on the license implications with JAMF.

Ahh cool thanks for the correction @mm2270 I knew they switched it to a hardware/board id assumed it was serial number.

Yep if the OP has the licensing to support it, multi context JSS sounds like the best option. I suppose technically if you're paying a licence fee per "machine" you might be able to get away with it? JAMF are nice guys after all ;)

I am working on this solution because our department is over budget and I have zero test set-up.

What this looks like so far:
- 3 partitions, each with 10.10.5: partitions a, b, and c
- a unique "breadcrumb" file on each partitions: a.crumb, b.crumb, c.crumb
- 3 extension attributes, each informed by a script that detects the presence of the respective .crumb file. "true" - specified .crumb file exists; "false" - the specified .crumb does not exist. The attributes are named similarly to these: a?, b?, c?

What I'm currently working on:
- A script that re-enrolls the machine, with an enrollment ID, so that the jamf binary functions for a booted partition. This also forces an inventory update so the proper extension attribute is populated with "true".
- A script that forces a check-in so that policies are ensured to trigger
- A launchd agent that is triggered at login to be loaded and run. It will execute the above scripts.

Not Tested:
- I have not tested policies.
- I have no idea how configuration profiles are going to work.

Behaviour:
As expected, a single machine entry shows up in the JSS. When any partition is enrolled, the other two become invalidated. Upon re-enrollment the proper extension attribute is populated with "true", while the others are "false".

I'll update this post when I have more of the design completed.