Skip to main content
Answer

Self Service Scope to Smart Groups

  • June 27, 2012
  • 9 replies
  • 48 views
F
Forum|alt.badge.img+10

bonus points for the alliteration in the subject???

Just curious if anyone is getting clever with how you scope out your App installs within self service. I'm debating if it is worth it to create smart groups for machines that do not have an app installed and then limit the scope of that Self Service policy to that group. So basically if you don't have Firefox installed you will see it available in Self Service but as soon as you install it (and fall out of the 'no Firefox' smart group) it will no longer show up within Self Service.

Worth the effort?

Best answer by mm2270

That's generally how we approach it. Reason is, for certain installs (Firefox in particular) you don't want someone trying to install it on top of the existing application. You would think that users would know if Firefox was already installed on their systems, but some people just don't look in /Applications. If it ain't in their Dock, they think it not there. In the case of Firefox, installing on top of an older version tends to break the app. There is of course the case of upgrading, which requires preinstall scripts, etc. It would also call for a more defined Smart Computer Group looking for either Macs with No Firefox, or Macs with a version of Firefox not matching the current one you're publishing.

For larger package installs we'll tend to cache the package with one policy, build a Smart Group looking for Macs with the cached package present and use that group as the scope for the 2nd policy that installs the cached version, and drop that in Self Service. Its nice because it can make what would otherwise be a long install process (download large pkg, run installer, run recon) into a shorter process of just the install + recon.

    9 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • June 27, 2012

    That's generally how we approach it. Reason is, for certain installs (Firefox in particular) you don't want someone trying to install it on top of the existing application. You would think that users would know if Firefox was already installed on their systems, but some people just don't look in /Applications. If it ain't in their Dock, they think it not there. In the case of Firefox, installing on top of an older version tends to break the app. There is of course the case of upgrading, which requires preinstall scripts, etc. It would also call for a more defined Smart Computer Group looking for either Macs with No Firefox, or Macs with a version of Firefox not matching the current one you're publishing.

    For larger package installs we'll tend to cache the package with one policy, build a Smart Group looking for Macs with the cached package present and use that group as the scope for the 2nd policy that installs the cached version, and drop that in Self Service. Its nice because it can make what would otherwise be a long install process (download large pkg, run installer, run recon) into a shorter process of just the install + recon.

    J
    Forum|alt.badge.img+26
    • jhalvorson
    • Honored Contributor
    • June 27, 2012

    I offer JMP, iLife, and EndNote scoped to smart groups which included the logic that if they didn't have it installed, it will appear in Self Service. The only issue is that after the app is installed, you must enable "Update Inventory" to make it work like you mentioned. The issue is that the entire "install" process is much longer due to the recon step.

    I believe it's been requested, but is there a way to limit the recon to only inventory Applications? That would speed up the entire Self Service experience for our users.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • June 27, 2012

    Yeah, I would like the ability to push the Recon process into the background instead of it taking up screen time as part of the Self Service "installation". That would address the extra time for the policy to complete for the end user. Its true that it makes the whole installation feel like its taking longer than it actually is. Hmm, I think that would be a good feature request actually.

    F
    Forum|alt.badge.img+10
    • frozenarse
    • Author
    • Contributor
    • June 27, 2012

    Thanks for the confirmation. It seemed like a good idea to keep things clean and for the "re-install" issues mentioned.

    Regarding the method of Caching and then installing.... Do you have the cache policy in Self Service as well?

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • June 27, 2012
    Regarding the method of Caching and then installing.... Do you have the cache policy in Self Service as well?

    Nope. Those run in the background silently. The end user only sees the "Install application X" Self Service policy, which is actually just installing the cached version already sitting on their Mac waiting to be called.

    J
    Forum|alt.badge.img+26
    • jhalvorson
    • Honored Contributor
    • June 27, 2012

    @mm2270, Do you have a routine for cleaning up cached packages that are replaced with newer versions of the software? I like your idea and may give it a try, but I don't want to fill up the user's hard drive with idle packages.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • June 27, 2012

    Yeah, I didn't create it, but there is a policy set for an every 15 trigger Once per week that just does an 'rm -r' from the Run Command in the Advanced tab on the path: /Library/Application Support/JAMF/Waiting Room/* and then updates Inventory again. That takes care of anything that doesn't get kicked off for whatever reasons.
    We really only use cached packages for the bigger installs though, which there aren't many of for us. If the install is relatively small, like Firefox, etc. we don't bother to cache it in advance.

    F
    Forum|alt.badge.img+10
    • frozenarse
    • Author
    • Contributor
    • June 27, 2012

    Ok I think I follow...

    You have a 'Cache Policy' scoped to a certain set of machines (or perhaps all) that caches certain large applications. This is prior to the end user even requesting the app?

    Once it is cached a smart group is populated with that machine and the self service 'install policy' is available via Self Service for them to kick off the install whenever it is convenient for them.

    My only question now is how do you determine which machines get those larger apps cached on them?

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • June 27, 2012
    My only question now is how do you determine which machines get those larger apps cached on them?

    Well, that's a little harder to answer. In our case, it depends on the application, but in most cases, we determine which Macs need the app in question based again on inventory information. For example, while we aren't actually doing this, you could add an Office 2011 updater into Self Service, once its been fully tested. Scope it by creating a Smart Computer Group for Macs that still have the older version of Office installed. First policy caches it, then runs recon, which in turn adds that Mac to another Smart Group scoped to the SS policy that the end user sees. They click install, it installs the cached copy and away you go.

    If you have specialized apps that you only want certain users or Macs to see in SS, that will take a little more work, but there are ways, whether through LDAP groups, Static Computer Groups or whatever.

    In the case of requests, I guess you could monitor an email the users are sending the request into and add their Macs in on a case by case basis (Add Individual Computers) but that would only be necessary for the silent caching policy. The other Smart Group/policy combo will take care of having it appear for them in Self Service.

    Terms & ConditionsCookie settingsAccessibility statement