This sounds like a good workaround. I have emailed JAMF about this too, but haven't heard anything. I'm sure they're all off at MacWorld:)

I was hoping for a solution that I could make a computer group with so that I could only run it on the computers that need it and not on every computer just for the 20% that actually need the client.

There is also talk of "leasing" CS3 licenses to departments on campus, in which case I would like to have self service only advertise the install on the computers that are in the CS3Licensed AD group. I may do this by having us add the users to a group as well and scope it that way temporarily, but the ultimate goal is to have it available for department machines, not users.

I was thinking of some sort of logic like:

1. run a policy that will check dscl for the group memberships of the computer.
2. install a dummy package.
3. base a smart group on the receipt of the dummy package.
4. scope the policies to the smart group

That way, I can not only run the policy just for the group, but also keep a record of who's in it. It's not a very elegant solution, but it may have to do.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

I'm a big fan of smart groups based on dummy receipts.
To break it down (as I would do it, at least):

Run the initial policy on all machines (once per day, limited to off-hours
if there would be any performance concerns). This policy does:
- run script that checks AD groups.
- if desired group is found, issue a custom trigger of "receipt exists".
- if desired group is not found, issue a custom trigger of "receipt does not
exist".

The "receipt exists" custom trigger policy does:
- Install the dummy package

The "receipt does not exist" custom trigger policy does:
- delete the dummy package's receipt

Smart group is scoped to the existence of the dummy receipt.

You can now scope to your smart group knowing that it consists of all
members of your target AD group, with up to a 24-hour lag behind changes in
group membership. If 24 hours is too big of a window, you could set it to
every15 (or 30 or whatever your periodic trigger is) and execution frequency
of "ongoing". This is pretty lightweight, so I don't think there's any
cause for performance concerns.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

Ideally I would like to create a smart group based on AD group membership. The reason for this is that this is a cross platform venture. For the backup system I was talking about, users register themselves at a web page that then adds them to a Bacula group in AD. On the PC side group policy will then install the client on their system because they have been added to that group. As it stands on the mac side when someone registers for the service we have to manually install the client.

As for the CS3 installs, when their department "leases" a license they're computers will just be added to an AD group (presumably automated by a website, hasn't been implemented yet) and the PC guys will use that group membership to advertise the install with SCCM. I would like the Mac side to be just as automated, once the website puts their computer in the AD group, the install will be advertised.

I think for the Bacula client install, the best solution would be to have a smart group based on the AD group, and then a run once per computer policy to install the client. For CS3, a self service install scoped to a smart group based on the AD group, which you can already do with users, but with computers, so that when the computer is added, the install will be advertised.

Before Casper we used AD group membership extensively to define which scripts were run, and what maintenance tasks were performed. The groups help us determine whether machines are labs, faculty, which particular faculty, and anything special about each (i.e. registered for backups).

Our network isn't segmented well enough to use segments (we have a lab and facstaff vlan for each building and that is all).

The major goal of this is to automate all of these processes. We all know that Mac admins have a lot to do and adding every individual user who decides to sign up for something is not high on my list:)

What would also be cool is a documented way to tie into the JSS with a web page (perhaps PHP) so that I could make a web page where people could sign up for something, get all the information I need and send some pieces to the JSS and some to other systems. Perhaps there's a way to do this. I hadn't thought of it before but boy does that sound cool.

Thanks for all the input. I really think mailing lists are a great way of narrowing down the best way to do something based on what other people have done.

Thanks again.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

Don't believe the JSS works with computer accounts in AD.

Craig E

Wouldn't you just create a smart computer group that goes off of the Active Directory Status attribute? You could either make it "Active Directory Status" is <<name of AD>> (if you have more than one and you want to specify which) or you could make "Active Directory Status" is not "Not Bound" It's a double negative, but that would return any machine bound to an AD, no matter what the AD is called.

See Attachment.

Maybe I don't understand completely your question?

j

"Bound to a directory" and "Member of a group" are different concepts.
I would also like the ability to recognize computer accounts and computer
groups.

You could work around the current situation with a script using logic like
so:

1. Query LDAP (AD) for the groups "my computer" ($2, assuming your machine names are the same as your AD names) belongs to.
2. grep the output for the group you want to key on.
3. call a custom trigger

The ability for Casper to recognize computer accounts & groups would be
better than this, but this can give you the same net effect as scoping a
policy to an AD group. This also assumes you have the ability to perform
LDAP lookups in AD. If your JSS is taking advantage of LDAP, then you could
use the same account to perform the lookup in the script.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

From Jamf:

What you will want to do is log on to the JSS, go to Admin, and add the LDAP server again, only scope it to computers rather than Users. That should give you the ability to scope to the AD groups.

That seems to work for getting computer and group records, but I haven't found yet how to scope a policy to that group, the JSS just seems to return Casper groups. I'll let you know when I find this out.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

On Jan 9, 2009, at 2:50 PM, Miles Leacy wrote:

I'm a big fan of smart groups based on dummy receipts. To break it down (as I would do it, at least): Run the initial policy on all machines (once per day, limited to off- hours if there would be any performance concerns). This policy does: - run script that checks AD groups. - if desired group is found, issue a custom trigger of "receipt exists". - if desired group is not found, issue a custom trigger of "receipt does not exist". The "receipt exists" custom trigger policy does: - Install the dummy package The "receipt does not exist" custom trigger policy does: - delete the dummy package's receipt Smart group is scoped to the existence of the dummy receipt. You can now scope to your smart group knowing that it consists of all members of your target AD group, with up to a 24-hour lag behind changes in group membership. If 24 hours is too big of a window, you could set it to every15 (or 30 or whatever your periodic trigger is) and execution frequency of "ongoing". This is pretty lightweight, so I don't think there's any cause for performance concerns. ---------- Miles A. Leacy IV ? Certified System Administrator 10.4 ? Certified Technical Coordinator 10.5 ? Certified Trainer Certified Casper Administrator ---------- voice: 1-347-277-7321 miles.leacy at themacadmin.com www.themacadmin.com On Fri, Jan 9, 2009 at 3:22 PM, Ryan Harter <rharter at uwsp.edu> wrote: This sounds like a good workaround. I have emailed JAMF about this too, but haven't heard anything. I'm sure they're all off at MacWorld:) I was hoping for a solution that I could make a computer group with so that I could only run it on the computers that need it and not on every computer just for the 20% that actually need the client. There is also talk of "leasing" CS3 licenses to departments on campus, in which case I would like to have self service only advertise the install on the computers that are in the CS3Licensed AD group. I may do this by having us add the users to a group as well and scope it that way temporarily, but the ultimate goal is to have it available for department machines, not users. I was thinking of some sort of logic like: LYuTfX7wpJ0NGrcVWUfd

---

Casper mailing list Casper at list.jamfsoftware.com http://list.jamfsoftware.com/mailman/listinfo/casper

I'd like to update everyone on this issue. Jamf has replied to my emails saying that this is actually possible. What you need to do is:

1. Set up a new LDAP server (even if you have one for users) and scope it to computers.
2. Click "Text Server" and make sure you can see the groups, computers, and computer's group membership.
3. The groups from AD should now appear in the "Static Computer Groups" section with their source being "Active Directory".

That is what Jamf says should be happening, however, I've gotten through setup two and they still don't show up in Groups. It could be an environment specific problem, but I'll let you know how to get it working when I figure it out.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

I've written a script that will check for specific group membership in AD. This should get you started scoping to AD groups if you need to. The workflow is as follows:

1. This script runs as a daily policy on all machines.
2. The gmark_SCLBaculaClient202 trigger that this fires off installs an empty package called gmark_SCLBaculaClient202.dmg
3. A smart group is scoped to the package receipt of the gmark_SCLBaculaClient202.dmg, allowing me to scope policies to computers in that group.

I have to say thanks to Miles A. Leacy for the header ;) And hopefully some future release of Casper will have the ability to pull groups from AD. I already submitted it as a feature req.

#!/bin/bash

##### HEADER BEGINS #####
# gmark_checkSCLBaculaClients2.0.2.bash
#
# Created 14012009 by Ryan Harter
# ryan at ryanharter.com
# Copyright 2009 Ryan Harter
#
# This script may be copied and distributed freely as long as this header remains intact.
#
# This script is provided "as is". The author offers no warranty or guarantee of any kind.
# Use of this script is at your own risk. The author takes no responsibility for loss of data
# or damage that may result from use of this script.
#
# It is intended to be run as part of a Casper policy triggered by login.
#
# Note: This script will need to be modified to fit your environment. This is how it works
# for me, but is provided as a template.
#
##### HEADER ENDS #####

# Standard error redirect and UWSP logging function
exec 2> >(logger -p local7.error)

function log { syslog -s -k Facility local7 Level Info Message "$1"
}

# Environment Specific Variables - You need to change these.
LDAPURI=ldap.uwsp.edu
BASEOU="ou=uwsp workstations,dc=uwsp,dc=edu"
HOSTNAME=hostname | awk -F"." '{print $1}'
ADGROUP="SCL Bacula Client 2.0.2"

# Trigger for Casper Policy
TRIGGER=gmark_SCLBaculaClient202

### Below this line shouldn't need to be modified

log "Searching for $ADGROUP membership for $HOSTNAME."

ldapsearch -Q -H ldap://$LDAPURI -b "$BASEOU" -u "(cn=$HOSTNAME)" memberOf | grep "$ADGROUP"

if [ $? -eq 0 ];then log "$HOSTNAME is a member of the $ADGROUP group. Installing dummy package..."

# Run the policy to install the dummy package. jamf policy -trigger "$TRIGGER"

# Updates inventory so the smart group gets updated jamf recon
fi

exit 0

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu