FR: Policy System Requirements and System Assignments

[ernstcs]

Morning,

So this one is somewhat of an odd duck, but I'll put it out there (yes,
JAMF support is in my BCC field) just to see if anyone else is as weird.

Problem Background: I often create two different policies for essentially
the same software install or upgrade, Office 2011 for example. One install
is for desktop support (Tech Install) and one install is for the end-user
(End-User Install). If a tech logins to self service with the proper
credentials the option appears since the tech install is scoped to that
particular support group in AD. In order for the end-user to see the
install someone with rights to policy management must add their computer
to the policy.

Problem Itself: Office 2011 (or pick your title) has specific system
requirements. For the tech install I can easily create a smart group that
only includes systems that meet the requirements and doesn't have the
software. However, aside from the individual package requirements I can't
stop an end-user from attempting to install the software multiple times
(I'll see the errors) if another person has added them to the end-user
policy without verifying requirements are met first. I can't scope to that
smart group for the end user install because it would show up everywhere
for everyone when we don't necessarily want it to.

You might be thinking: So why on earth do you allow someone access to add
systems to policies if they aren't going to be diligent enough to make
sure the system meets requirements? Answer: I'm lazy, but I do trust them
to not touch anything else. I'm not desktop support, the people in charge
of going out and working with office systems, and I certainly don't want
to add a box every time they want to allow an end user to install the
software on their own. Then you might ask, why not just make it available
every where for the end users so you don't have to add each of them? Well,
unlike some places we like to actually inform our customers of anything
special they need to be aware of before they do something, and the desktop
support folks have a decent handle on the unique needs of some users. You
may also be thinking I really don't have a problem at this point if I just
deal with the situation differently, or perhaps let them deal with
installs with Casper Remote. Humans make mistakes, and I want this system
to help any where it can to catch those.

Why not do...: As I've already mentioned, I'm lazy (otherwise known as
efficient). Casper Remote poses many of the same issues because of complex
multiple package/script installs. Unless that other person knows all of
the pieces and order to make an install work it might fail or be
incomplete. Policies are nice because it encapsulates the necessary
install process.

Possible Solutions for Many Problems:

- Make self service policies more aware, in that if packages/scripts have
OS requirements, read that and compare it to the system when Self Service
is launched and do not display options that don't meet requirements, or
have a unique category that shows those that would be available if these
necessary system requirements were met.

- Allow me to set particular users or groups in rights management to only
manage the machine scope of a policy. I could go either way on this, if
I'm letting someone into policy, I'm letting them in at my own risk.
However, it would be nice to let the desktop group add systems to a self
service once they've talked to them, and not bother me. I imagine I could
create a custom web interface to deal with this through the API. My only
other tie in request here goes back to limiting the scope of systems a
particular set of users and groups have rights to touch within the JSS, so
they can't touch my lab boxes.

- I would love to see the availability of a predefined policy in Casper
Remote. This is nice because I've already encapsulated the necessary steps
for the complete install/uninstall process, and the tech doesn't need to
know the steps, or will forget parts. They don't need to walk over to a
box or remote into it to run the self service.

- I would love to see the availability of a predefined policy in Casper
Imaging. This is nice for many of the same reasons. If I don't have CS5 as
part of the base configuration they don't need to go in after the fact
with self service to install it once imaging is done. A tech could just
customize the install and check a single box for CS5, and doesn't need to
know it takes like 10 packages and 4 scripts to make it work.

In conclusion: So now that I've gotten that out of my system, here's what
some of this boils down to. I love the fact that the JSS can be so
modular, but there are many many instances where being able to create
what's essentially called an advertisement in SCCM would be great during
imaging time and with Casper Remote. That's essentially extending the
availability of policies into Casper Imaging and Casper Remote. However, I
think it needs to happen before policies even, you should be able to take
a set of packages/scripts, and create and "advertisement", a sequence of
events with those items, and make it available as a single check box for a
policy, imaging, or remote. This may require you to hide the individual
pieces from being available in those interfaces, but if you ask me, that's
totally fine because users can't mess with it unless it's an
"advertisement".

Sorry for such a long explanation, but I'm not sure I could have conveyed
it properly without doing so. Any one care to tell me I'm an idiot (I get
that often here, don't worry), or have a better solution? Other comments?

Have a good one...and go Packers!

Craig E

[ernstcs]

Version 8, as you can tell, was focused in MDM. But, with that initial
milestone out of the way, perhaps JAMF will be focusing on, what I'm sure
is, a monster list of feature requests.

Craig E

[tlarkin]

this is script-able with custom trigger policies and shell scripts

[ernstcs]

But what isn't? I'm talking about adding functionality into the system interfaces to make it friendlier though, right?

[#5]

I agree that one should be able to set up predefined groups of tasks that can be run, though I think there should be a better name for it. Certainly, having this capability would be a significant step toward making the Casper Suite more friendly in general. Ultimately, I think there is much room for improvement in the Suite to greatly enhance its usability. In fact I made a list of such improvements (and sent it to our contacts at JAMF); unfortunately, none of them showed up in version 8.0. I hope they get at least some them into 8.1...

[tlarkin]

Well for what it is worth I have 1 post image script for both my 10.5.8 image and my 10.6.4 image and I use OS detection to determine the few OS specific packages get installed. Here is an example:

OSversion=/usr/bin/sw_vers | /usr/bin/awk '/ProductVersion:/ { print $2 }'

case ${OSversion} in

10.5.) `/usr/sbin/jamf policy -trigger my_10.5_policy`;; 10.6.) `/usr/sbin/jamf policy -trigger my_10.6_policy`;; esac

You could probably do a processor one as well via the system_profiler binary