Creating Single Click Install for Mac OS X

[karthikeyan_mac]

Hi,

I need to create a Single Click Install for Mac OS X. One of our enterprise clients require it immediately. Please suggest as soon as possible.

Just user need to double click the package, it should install in the background silently and after installation it should the application is installed.

We use Composer to create the Package, but it does not have option to create a single click install. Windows Packagers do this but I dont have idea to do it on mac since I am new to package.

Thanks & Regards,
Karthikeyan M

[tlarkin]

If the install needs authentication there will be no such thing. Have you looked at deploying it via self service? that would allow the end user to do a single click install and it would not ask them for authentication since the local ssh account for casper would be doing the install.

[karthikeyan_mac]

Hi,

If we just authenticate, will it silently. If yes, then how to do it.

Regards,
Karthikeyan M

[John_Wetter]

Until you’re comfortable building packages that are fully automated, I think Self Service is the way to go. They can log in (or disable required login) and then have one click access to whatever software you have enabled for them.
John

[#5]

All you need to do is make sure the user has Self Service.app on their
machine, then make a policy in your JSS to install the package and check the
'Make this policy available for Self Service' box.

User can launch Self Service, click install, and the rest is done for them.

Bob

[tlarkin]

You can also use custom trigger policies for this. If you do authenticate via ssh and want to install composer packages you have tossed up on your JSS and replicated out to your distribution points, you can create a policy with a custom trigger. This can be done behind the scenes with no user interaction

sudo jamf policy -trigger mycustompolicy

[donmontalvo]

Karthikeyan,

Just curious, are you looking for a user initiated install? Or for a way to centrally distribute software without the user being aware (and thus no prompts)? If you set up a policy to push software to a user, there shouldn't be any prompts, unless the user is logged in.

Our preference in most enterprise environments is to only push to logged off computers. Then it's just a matter of alerting users that they shouldn't log in until an install completes (search archives for info on how to do this using iHook, etc.).

Thanks,
Don

[karthikeyan_mac]

Hi Don,

For multiple users we will pushing it via Casper policy.
We are looking for user initiated install. We will delivering packages to the user, they will install the packages(less number). If 1 or 2 systems requires the Applications, the local technician needs to double click and install it.

Regards,
Karthikeyan M

[donmontalvo]

Hi Karthikeyan,
Karthikeyan M wrote:

My apologies for my previous "blank" email, I meant to save it as a draft.

I flew to one of our clients in Burbank for a two day session with one of JAMF's finest (Tedd - with two d's). The agenda included several road map discussions and requests for proof-of-concept demos. Germain to this thread is the request to demo the Self Service feature in Casper Suite. Our intent is to push software to users whenever possible, but we also wanted to provide some software via the Self Service application.

Using Firefox for this test, we uploaded the custom pkg to JSS and scoped it as a Self Service delivery to a test user. Then we logged on to the Mac as that test user and launched Self Service. The user was prompted for credentials (#1). The user immediately saw the Firefox icon, clicked the icon and in less than a minute they had Firefox installed.

Since Firefox didn't require a reboot, the user never needed to close open documents, log off/on, or reboot. Not sure how this would work if we used a pkg that required a reboot. Maybe they'll just get a "You must reboot" dialog box (#2)? We checked to confirm that the installed payload didn't inherit the current user:group (which can happen with some cr at ppy installers), were pleased to see the permissions were correct, despite the fact the install happened while logged in as a standard user.

After this test was done, we had the user close Self Service. We then relaunched Self Service and entered the Helpdesk user's credentials. The entire installer library was immediately available. Sweet, now we know we can leverage Self Service for those times when Helpdesk or Desktop Support are providing remote assistance or perhaps at the user's desk.

I hope this helps address your inquiry about single-click install for Mac OS X. If Self Service auto-launches for the user who is being given software, it truly would be single-click.(#3)

*Open questions and/or feature requests:

1. Is there a way for Self Service to use cached credentials on launch; perhaps OPTION-launch to bring up username/password fields if necessary?
2. Is there a way to show a dialog box warning that at least one of the published installers would require a reboot? Also, is there a way to show a progress bar during Self Service installs so users don't force quit or force reboot the computer during a large install?
3. Is there a way to auto-launch Self Service on login if the user has been "given" something through Self Service?

Thanks,
Don

[lance_ogletree]

*Open questions and/or feature requests:
On Mar 4, 2010, at 1:52 PM, Don Montalvo wrote:

1. Is there a way for Self Service to use cached credentials on launch; perhaps OPTION-launch to bring up username/password fields if necessary?
2. Is there a way to show a dialog box warning that at least one of the published installers would require a reboot? Also, is there a way to show a progress bar during Self Service installs so users don't force quit or force reboot the computer during a large install?
3. Is there a way to auto-launch Self Service on login if the user has been "given" something through Self Service?

Thanks,
Don

1. Not that I'm aware of.
   You're only options are to a) Not require login b) Require login c) Require login (with anonymous login being available).
   If you have a case for this feature, send it on into the developers..

2. Couple of ways. a) Include the reboot information as part of the description field for the self service policy. b) Check the reboot option tab in the policy itself. You can provide for the reboot there as well. Even if you're not rebooting, you could have a dialog message stating that the install was finished.

2a) Progress should be visible in Self Service as to what is taking place during the install.

1. Self Service is really designed to be a user initiated process. That's not to say that through a lot of scripting you wouldn't be able to do this, I haven't seen a way just yet. Part of the problem you might run into in doing this is how to display the object in Self Service that is newly available to make it meaningful for the user to see Self Service auto launch.

One way to accomplish something similar might be to have a backend process at work that could generate an email to the end user.
Example would be for an approved software group.

Say you require users to seek approval for something expensive like Adobe CS 5. Once they have been approved, the user could be placed in a directory service group in AD or OD that identifies them as approved users for CS 5. That act of being placed in the group might generate an email to that user which could inform them to look for the software in Self Service. The CS 5 policy would be scoped to that directory service group so only the approved users would see the available software.

I'm sure some of the script wizards on the list might have some additional ideas for you as well..

just my 2¢

-Lance

--
Lance Ogletree
Systems Engineer
Mobile: (972) 342-5990
lance.ogletree at jamfsoftware.com<mailto:lance.ogletree at jamfsoftware.com>
....................................................................
JAMF Software
1011 Washington Ave. S
Suite 350
Minneapolis, MN 55415
....................................................................
Office: (612) 605-6625
Facsimile: (612) 332-9054
....................................................................
US Support: (612) 216-1296
....................................................................
http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

[ernstcs]

The only way I can see this working might be, since I haven’t tried it, would be to have two policies in parallel.

Policy 1) is your self service policy like you would normally have it
Policy 2) is a login policy that has a short sleep to let slow machine interfaces catch up, and then uses the ‘open’ command to launch Self Service

Just thinking about this for a minute this morning before caffeine sets in, the only thing that really needs to happen to make this work is it would be dependant on scopes of machines. You’d really need a smart group of computers to put in the scope for those policies, such that once the install takes place they no longer get either policy. This is most likely a smart group to a ‘Packages installed by Casper’ receipt, but could just be software versions.

Instead of just randomly launching Self Service you could use the parallel policy to display a message to the user at login guiding them to Self Service and why they need to install a particular piece of software as well.

I’m spent for the day. Cheers!

Craig E

[Bukira]

or maybe script a policy to add the Self Service application to the
users login items plist and then remove it after its installed

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
iPhone Developer
Apple Certified Technical Coordinator v10.5
LIS Development Team
Adelphi Building AB28
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

[ernstcs]

That would work, too I’m sure, but the less I have to touch users files on the system the better and likely more reliable. Then I don’t have to deal with modifying plists, etc...let the JSS do the work in the policies for me. Less script files to maintain, etc...

Craig E

[donmontalvo]

Ernst, Chris, Lance, as always - thanks for the excellent ideas! Our position is the same as yours regarding how to implement things...the more centralized, the more manageable.

I'm going to submit a couple feature requests to (1) enable Self Service to use cached credentials and (2) method to alert users that they have stuff waiting for them in Self Service.

Thanks,
Don

[#15]

As far as an alert system...

Couldn't you create a smart group in your JSS for machines that have not
received the receipt(s) for the latest package(s) you have available in self
service, and then have a policy that runs every day or so that runs
something like this:

/usr/sbin/jamf displayMessage -message "There are new packages available for
you in Self Service. Please download them at your earliest convenience."

Then as soon as they download whatever packages you're checking for, they
fall out of the group and don't see the message anymore.

You'd, of course, have to update the policy every time you put something new
into Self Service that you'd like everyone to download.

I haven't tested this, but in my head it should work with no problems...

Bob

[tlarkin]

Self Service is just like a web browser you can embed images, text, and
even video into it. Whenever I run a policy that requires reboot I put
in very large, bold and red fonts "YOU MUST QUIT ALL APPLICATIONS AND
SAVE ALL DATA BEFORE RUNNING."

As for self service triggering other policies you can do lots of things
with custom triggers.

[donmontalvo]

Hi Bob,

Thanks for the input, it's very much appreciated! I saw both your emails about this. Sounds like a great idea. We're going to test your suggestion, then implement.

I'm hoping to get the two feature requests under the wire for the 7.3(?) upgrade, since our customers are mainly enterprise environments, where centralization/simplification is the focus. Until then, we're happy to apply a policy workaround.

What we're mainly trying to avoid is going overboard with policies so we can prevent issues. As an example, our firm had Casper Suite deployed to an environment when it was at version 7.01. At the time, the only way to add a local hidden admin user account was to include a Quick Add pkg installer along with a shell script to the imaging configuration. When 7.1 was released, the on site Mac tech applied the upgrade without reading the release notes.

This created a conflict, as 7.1 included an option to create a local hidden admin user account. So the new checkboxes were turned on, and the old policy was never removed. Just an example of how a good solution can turn into a problem later on if things are not tracked properly. We're going to be implementing change control soon, so we're at least tracking these policy workarounds (they're very necessary, but want to head off any issues later on).

PS, I hope the mailing list server doesn't mangle the quoted text too much...I added both of your emails for clarity. :)

Thanks,
Don