script tab

Casper: Launch Apps Only For Certain AD Users

This is another of those, ‘a customer asked for a solution and a I wrote a script that I want to share’ posts.

This customer runs a ‘Pcounter’ pull printing solution. This requires that their local application be launched at login for a user, but this site had two different applications (one configured for students and one configured for staff) that needed to be launched, depending on what AD group the user was in.

Setup

This script is designed to run on a login policy. The script will complete the following tasks:

  1. Check for a value of $3 (a login Casper policy should populate this with the username of the user logging in).
  2. If not, use the standard variable of “$USER”.
  3. Check if the logging in user is a member of the first specified group.
    • If so, launch the first specified application.
  4. Check if the logging in user is a member of the second specified group.
    • If so, launch the second specified application.
  5. Exit.

Take a copy of the script (see below for the URL) and add this to your Casper server:

1.Log into your Casper Server.
2.Navigate to the ‘Scripts’ section:
a.”Computers” > “Management Settings” > “Scripts”.
3.Click “New” and fill in any desired details on the first page.

ad group application launcher

4.Under the “Script” tab, paste the script in place

script tab

5. Under the “Options” tab, set the following settings:
a. “Priority” – At reboot
b. Parameter labels
i. Parameter 4 – First AD Group
ii. Parameter 5 – Second AD Group
iii. Parameter 6 – First App to launch
iv. Parameter 7 – Second App to launch

parameter labels

6. Save your changes.

Create a new Login Policy to run the script:

1. Navigate to the ‘Policies’ section:
a. “Computers” > “Policies”
2. Create a new policy, with the ‘Login’ trigger and frequency set to ‘ongoing’. In my example, I will use the two PCounter applications.

pc counter applications

3. Add out new script to the policy
a. Click on the “Scripts” section in the left hand side.
b. Click “Configure”

configure scripts

c. Click “Add” on our script.

click add on script

4. Fill in the details for the 4 parameters:
a. Fill in the first AD user group in the first parameter box (in our example the staff group)

first ad group

b. Fill in the second AD user group in the second parameter box (in our example the student group)

second ad group

c. Fill in the path to the first app to launch in the first parameter box (in our example the staff PCounter App)

first app to launch

d. Fill in the path to the first app to launch in the first parameter box (in our example the staff PCounter App)

second app to launch

5. Configure the scope as desired and save the policy.
6. Test the policy works as expected!

Usage

There are two key points over the usage of this script in Casper policies:

1. Where possible, try not to use overlapping AD groups. This will likely result in the script launching both applications.
2. Ensure to fill in all the boxes, or comment out the relevant parts of the script. This should prevent any false errors.

The Script

Rather than paste out the entire script we have added this to our public github repo. The script can be pulled from here.

Alternative methods

As with most things, there are many ways to skin a cat, there are also many ways to script something like this, including:

1. Use a launch Agent instead to trigger a local script
a. This would work fine, but if a site is using Casper, I feel it’s a better practice to control some items centrally. That way they can easily be excluded from some items, as well as modified if desired.
2. Use another / better scripting language.
a. I know bash / shell scripting well enough to be happy using over alternatives at the moment.

Summary

And that’s another possibly helpful script added for your use. Please feel free to test out, and tweak as much as you wish. Just please ensure to run on test systems first to be 100% happy that it works in your environment.

As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can.

Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *