Nested Logic in Smart Groups for Mapping Multiple Printers

Does this not work?

Thus making it say that:
Department is Accounting
and
Does not have printer1 OR printer2

--
TJ

Also, you could create two smart groups. One to handle printer1 and One to handle printer2. Then scope the policy to push the printers back out to those two groups.

Honestly, there probably isn't a good way to do it without two policies. Unless you plan on re-mapping both printers if one is missing.

--
TJ

From your previous posts, I take it your transitioning and setting up Casper from scratch. To help ease your mind, sometimes there's no easy way to do things. Sometimes to accomplish a specific goal you will need multiple smart groups and/or policies. Once you've accepted this fact it becomes a little easier and you feel a bit more comfortable.

In this case, there are two options you have:
1. create a smart group and policy for each mapped printer.
2. forgo all logic and just assume that if one printer is missing they all need to be re-installed. Now sure how this will behave in terms of whether it will create additional print queues or if it would replace the print queues the computer currently has. I suppose this depends on how you are deploying the printers too. I long ago gave up on using config profiles to manage printers. Too inconsistent and other issues. I package up the drivers and deploy print queues and PPDs accordingly via a script instead.

Maybe someone has another way, but those are the two that come to mind.

Thanks @tthurman, that what I was thinking. Right now I do have (2) policies, but it seems overly complicated to manage.

Im starting to think that pushing out printers at imaging time, combined with Self Servce is enough. Otherwise Im spending a lot of time on printers.

Problem is, all my Macs are currently managed in OD/MCX (inlcuding printers). So when I migrate them over to JAMF and purge all the old OD/MCX settings, the exisitng printers will be removed - and thus I need to get the Macs re-mapped to the proper departmental printers again - a "printer boot-strap", if you will.

@bpavlov I was wondering what the consequences of re-mapping on top of an exisitng printer would be too.

I have done all the leg work and already have bash scripts written for all my printers, including PPD paths, etc. So it would just be a matter of (tediously) cutting & pasting all the code into the JSS (if I decide to go that route)

Only one way to find out what the consequences would be: test it out.

However, if you've got scripts and PPDs all rolled up into a nice package then you just need to upload that to Casper and start pushing it out. Depending on how you have it scripted it you could put in a logic check to remove the print queue of the same name if its detected on the computer. That's what I do anyways.

Applying the logic from tthurman above, it appears that remapping 2 printers when only 1 printer is missing seems to work fine.

Remapping a printer over the same exact exisiting printer is working OK. CUPS is not duplicating printer queues or anything freaky.

@dstranathan

Glad to hear it, mate.

Cheers.
TJ