PreStage scope priorities: mac address vs network segment

[woodjb]

My site is using Casper 8.61, and we have two types of computers that come through. Loaners, which should be imaged automatically, and client machines, which should log in but not image automatically. I've created two PreStage rules. One based on mac address, for the loaners, is set up to image the loaners automatically. The other is based on network segment, which selects our image for client machines but does not automatically image, as we have other parameters to select before we image.

Long story short, the network segment rule is preferred over the mac address rule, even though the mac address rule is more "specific". Is there any way of choosing which PreStage is selected when a machine matches multiple rules? Thanks.

[mm2270]

I don't think there is a way to prioritize one over the other. Network Segments for Pre-Stage really work best if you have a dedicated 'imaging lab' that has its own network IP range separate from everything else. That way, only a Mac booted up while connected to that physical network will fall into the Pre-Stage.
If you're adding in your regular network IP range and hoping the Macs won't fall into that Pre-Stage just because you have another one that uses their MAC address, I don't know if you will find an easy way to do that. My guess is the Mac reports in its IP before it can report in its MAC address to the JSS. Indeed, a Mac getting its IP from DHCP actually gets that information very early in the boot process, so that's probably why.

Have you tried reversing these, and making your client systems use the MAC address instead, or is that not feasible?

If not, and you happen to have access to a dedicated section of your network, even just a room with its own IP range, you might want to reverse these and assign your loaners to that Network Segment (once you add it into your JSS) and have them image that way, and let your regular client systems use the broader network range for you other Pre-Stage.

The other option is just to not assign a Pre-Stage to the client Macs at all. Just boot them up into your imaging environment, i.e. NetBoot, and then select the proper Configuration from the list. You mentioned you need to make some specific selections before actually imaging them, so is going that route a possibility?

[woodjb]

To answer your first question, obtaining the MAC addresses of the clients isn't feasible; client machines are generally new-in-box, and taking time to add those MAC addresses would be terribly inefficient. Either way we have no way of knowing their MAC beforehand, and client machines are generally one-shot images, where the loaners are imaged nearly daily.

We do have our own network segments, but the way networking has assigned the subnets, we don't have a reliable IP range to assign other than the broad range that is assigned to our building. Inevitably, a client or loaner would end up in the wrong subnet, and take the wrong image.

As for the last option, the reason we wanted a PreStage for the client machines is that our techs have complained of having to log in with their credentials and select every option, where the PreStage eliminates that hassle and speeds up the process. As for "specific selections", it's more or less which version of OSX will be applied, and nothing further.

Sorry if any of this confuses things further, we're just trying to come up with an efficient solution that lets us have two rules on the same network segment.

[mm2270 · Accepted solution]

OK, makes sense. So, are the loaner Macs already in your JSS and are just being wiped and re-setup?
If so, perhaps look into Auto-Run data instead of a Pre-Stage for those. I can't be sure, but I think Auto-run would override a Pre-Stage.
Auto run can't be used for new out of box Macs. Pre-Stage is really the only automation option for those.

[woodjb]

Yes, the loaners are in JSS after they've been imaged. I went ahead and added AutoRun data for each loaner. It was a bit more tedious than a PreStage, but it accomplished what I was after. Thank you, mm2270.