Self Service Feature REQ

[tlarkin]

So,

It has come to my attention that certain users may need certain software and licenses are limited. Instead of me doing bunches of manual data entries and finding out all the individual laptops (out of 6,000) and creating a smart group out of them, I would like the idea of putting a password on a self service install. Then giving that password to that class, and so the students in that particular class can install it with their password. Then make a smart group of all users that have that application installed to track the licenses. I was talking to a teacher who wanted to buy 30 copies of some accounting software for a class. I was dreading the thought of me having to track down each student, the asset tag of their computer, and creating yet another smart group, then I thought if I could just put like a password on the self service install, the student could install it them self with that password.

I know that working in a 1:1 is way different but I have users that may switch laptops due to hardware failure and I just want them to be able to install it on whatever laptop they are given. In many cases when a laptop goes out for repair a spare is issued.

Thoughts?

---

Thomas Larkin
TIS Department
KCKPS USD500
tlarki at kckps.org
blackberry: 913-449-7589
office: 913-627-0351

[#2]

Tom,
Not sure if this would work, but could you create a user group that is allowed certain policies for self-service? In AD we have a building tech group that can install apps that are licensed like Office, but that install is not available to anonymous. I would think I could have a group in AD for the users that need that app and then maybe grant rights to that group to execute the install policy? I haven't tried it so I'm not sure if that would work. And a single password would be much simpler, especially since you could disable the policy after the correct number of licenses have been installed.

Nathaniel Lindley

++++++++++
Educational Technology
Saint Paul Public Schools
Saint Paul, Minnesota
nathaniel.lindley at spps.org
phone: 651-248-6861

[jstrauss]

Just a thought, and this is probably not very elegant, but it may work...

Can you get a list of the students in the class from the teacher and then create a smart group for computers with those logged-in users? Or manually search the inventory for users and match those to asset tags? I'm not in front of my JSS at the moment so I don't know if those options are feasible.

Do students in your environment go home with their laptops or are they issued a random one on a daily basis?

Jeff

Sent from my iPhone 3G

[milesleacy]

Presumably, you have a record of which machine was issued to whom (Ideally,
that info is stored in the JSS).

In the case you describe, I would suggest creating a manual group of the 30
machines intended to receive the software.

This doesn't address your stated desire to give a client the ability to
reinstall the app on any machine they use. To do that may take a few steps,
but I think you could get there with relative ease. I am assuming you are
using some variety of LDAP, likely Active Directory or Open Directory.

Here's what I'd do:
1 Create an LDAP group consisting of the people who should have this
software.
2 a Create a script that queries for the logged-in user's groups. If your
"accounting software" group is found, the script issues a custom trigger for
the installation. Run this script with a policy triggered by login, once
per user. b If you want to keep the self-service aspect, have the custom trigger
in the script above kick off the installation of an empty package instead of
the accounting software. Use the receipt from that empty package as the
criterion for a smart group to which the self-service policy is scoped.

I hope this helps.

----------
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

[#5]

I could be wrong, but can't you just require the user to login to self service and scope the policy to a specific group of users? That way no matter what computer they're on, they can get it and it won't appear for anyone else.

I would think, assuming this is accurate, that this would be an easy solution because there is no shared password and they would just log on with their normal domain credentials.

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

[milesleacy]

Only you know your environment and workflow, but it would seem to my eye
that the process you describe would save work on the front end only to
create work on the back end.
As I see the options, you can take steps to ensure the software is only
deployed to the appropriate users or you can take steps to clean up after
any unauthorized or otherwise undesired installs. If you use a password to
enable a self-service policy, people may (and by may, I mean will) share the
password with individuals for whom no licenses were purchased and you'll get
unwanted installs which you will then have to track down and uninstall. If
you use groups, only those people logging in with the correct account will
get the install.

Again, you know your environment better than anyone on the outside, but it
appears from my point of view that the groups method will be the easiest in
the long run.

----------
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

[kalikkalik]

Since this is more or less a desire to limit the scope of an install, is it possible to create a network segment just for that class, and use it as the filter? You could limit DHCP expirations to something like an hour, or immediate (depending on the equipment) - just long enough to grab some software and install. No mucking around with groups and other such nonsense - more or less a giant filter is enabled without you having to know the details.

You could patch in a local subnet or VLAN (wired), or setup a WAP and give it a temporary password (put it on the blackboard or something simple) - set the policy in casper to allow self-service for that policy within that network seg.

Since this gets into the network side of life...you never know - depends on how nice those guys play. Then, when no longer needed, turn it off.

-j

[tlarkin]

That would work but we run Layer3 VLANs here so the user keeps their first IP they get, which could be on a VLAN on the other side of the network. Like I said, I am special, short bus special, because my users roam around in user space with laptops hahahaha. I wish it was static desktops on set VLANs, life would be a walk in the park, and well boring too. If I had more help it would be easier to get some things done as well, but 6,000 laptops and 6 guys running the show you tend to have to do all sorts of things all day every day.

There is not a day that goes by that I don't reimage at least 10 laptops for whatever reason. I probably have casper imaging nightmares by now, but luckily my conscious blocks it.

I am just trying to figure out how to deploy educational software, which isn't developed for mass deployment in the first place to roaming users that could be anywhere at any given time on our network.

The password thing was the first thing that came to mind. Even the ones I have out now, looking at policy logs, kids don't install a text book if they don't need it. I am not too worried about that, but some things I would want to limit with maybe a password. It was just an idea, and I will try to think of other ways. Since they can be anywhere at any time with their laptop I wanted to do self service since they could do it from anywhere in our network that way.

[jarednichols]

It almost sounds like you have a need for a keyserver. Are there other pieces of software that could benefit from keying? I've played around with K2 and it seemed to work well, independently of whether or not the software was key aware.

j