AMEN! AMEN! AMEN!

I've barely started using Casper and already found this to be lacking. It's all fine and dandy to define the list of computers you want to apply a policy to, but if that's all of your 4000 machines, EXCEPT for 10, then you have a lot of clicking ahead of you!

Jeff

I concur...not that I have 4000 systems.

I'd like to exclude users from a particular policy as well, like if I want
almost all of my domain users to run it, but not X,Y, and Z user. That would
be lots of clicks...like...12,000+.

Craig E

This is a good way to use the Department field, or maybe use Extension Attributes (i.e. ARD Fields - set ARD Field 4 to "Legacy", can use that as an exclusionary approach to policies).
On Sep 23, 2010, at 5:27 PM, Ernst, Craig S. wrote:

I've used this to create Smart Groups that use Department to prevent certain machines (i.e. Servers) from getting a softwareupdate policy applied to them accidentally...

--Robert

You can already scope to OD/AD groups when you create policy, would that help you do what you need?

Many of my customers are not doing AD or OD integration, so there's a need for this type of functionality outside of that, but I've been able to work around it with departments/extension attributes.

Ah I see, I guess I sort of assumed that anyone with massive amounts of deployed technology was using some sort of directory service. My other suggestion would be to scope it out by network segment, or buidings/departments in Casper. If your network guy chops everything up in VLANs then you can use that to your advantage. My network guy does and by looking at a subnet range I know immediately what building and if it is a wired or wireless connection.

Nope. And remember you can't use nested groups either. And I shouldn't need to create a bunch of other groups to deal with it.

On Sep 24, 2010, at 10:43 AM, "Thomas Larkin" <tlarki at kckps.org<mailto:tlarki at kckps.org>> wrote:

You can already scope to OD/AD groups when you create policy, would that help you do what you need?

Hi all,

We worked with JAMF Support over the past few days to come up with a way to exclude Macs from policies (just get them into JSS for inventory only). Well, today I got a call from Nick Amundsen offering an idea that might do the trick for us...well, it did. I thought I'd share it with the list...

SCENARIO:
We are told to add 100 Macs to JSS, but to *ONLY* pull inventory information (do not make any changes to them). So we need to exclude them from all current and future policies. How do we get Macs into JSS safely?

SOLUTION:
1. Create "Exclude_Department_A" department in JSS.

1. Create custom QuickAdd pkg and append the department flag to the end of the recon section of the embedded postflight script (QuickAdd.pkg/Contents/Resources/postflight):

   
   
   

   -department "Exclude_Department_A"




2. Add criteria to existing Smart Groups to exclude the department:

   
   
   

   Location > Department is not "Exclude_Department_A"




3. Add same criteria to future Smart Groups




4. Optional: Create "master" Smart Group using step #3 to scope future global policies.

Now all we need to do is wait for JAMF to add an exclusion list feature to JSS. :)

Don

Hi Cem,

Sure, here's what we have. Note that I've x'd out account names and hashes...

If you look at the end of the "Run Recon" command, you'll see we added the switch with the department name. I used vi to edit the file, but any editor will do (of course if you use Word the script might break...). :)

Don

--------------------------------- START ----------------------------------------

#!/bin/sh
#
# 20100926 Added department to Run Recon command. DM

####################################################
## Create the configuration file at /private/etc/jamf.conf
####################################################
/usr/sbin/jamf createConf -server 'xxxxx' -path '' -port '9006' -securePort '8443' -isSecure

####################################################
## Turn on SSH
####################################################
/usr/sbin/jamf startSSH

####################################################
## Create a new account
####################################################
/usr/sbin/jamf createAccount -username 'xxxxx' -realname 'xxxxx' -passhash 'xxxxx' -admin -hiddenUser

####################################################
## Run Recon
####################################################
/usr/sbin/jamf recon -username 'xxxxx' -passhash 'xxxxx' -sshUsername 'xxxxx' -sshPasshash 'xxxxx' -swu -sizes -department "Department xxxxx"

####################################################
## Enforce the Management Framework
####################################################
/usr/sbin/jamf manage

--------------------------------- END ----------------------------------------

Not a bad solution, but we need the department to be the actual
department. I suppose you could use another field, but something we've
played with is extended attributes. You simply make an extended attribute
flag that you can set to "YES" (e.g. Exclude Forced Software Updates) and
then on your "software updates available" smart group you exclude machines
that have "Exclude Forced Software Updates" extended attribute flagged YES.

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Yep, agreed, extension attributes would be a more graceful method for 7.2 or later.

** Sent from my iPhone **

I have always wanted something similar to groups in Casper. It could just be a text file somewhere that Casper reads and it lists what group the machine is in in Casper. This can be smart groups, or even say configurations, and then have a set of variable that can be ran when executing policy. I never really took the time to write up a feature request because I am not a developer and would not be sure the best way to describe it.

A quick example would be printers. I could add a printer to the JSS and then in say, a tab called "Access," I could limit that policy to only those groups by checking them on/off. This should be exempt from existing directory services as it should stand alone with out AD/OD or even ED.

I am very lucky as my network is very segmented. So, when I need to scope vague things our, or exclude certain machines I do it by network segment. Like when I want packages to only go over wired connections, I can do that because wireless has it's own subnet range.

I also am not afraid to do some creative scripting, but I think it would be nice to start storing some sort of identifier in a text file that Casper knows what it stands for. Group A, B, C, D, E and so forth and this doesn't have to be stored server side to reduce overhead on MySQL, it can be stored client side, in say , /etc/jamf.conf or something and it could just be plain text. That way you can include/exclude machines by simply checking the box in the policy and then the casper client can test for such data in the policy if specified.

I may not be explaining this right, but I think it would be a nice and robust feature. Plus keeping it client side in a text file means I can use more of my creative scripting methods on top of the GUI to make it even more robust.