In July 2016 I wrote a blog article titled, “Power to the users: Using BigFix to create a Self-Service application catalog”. My motivation at the time was to answer the question I often got from clients: “Does BigFix have self-service software deployment capability?” While I would always answer “yes” there was often a bit of hesitation on my part because the implementation of the “self-service portal” was somewhat complicated and its interface was clunky, sparsely populated and not very configurable. 

With the advent of app ecosystems like Apple’s Appstore and Google Play, which can seamlessly support thousands of applications, IBM decided that they would rethink and redesign their own self-service offering. In December 2016, IBM launched the “BigFix Self-Service Application” (SSA). The SSA has already been through a series of updates (currently sitting at v2.1.0) and IBM continues to improve on its usability and interface; however, even the first version released was vastly superior to the Self-Service Portal it replaced. After having used it for over a year, I want to share my insights on installation, configuration and usability.

Setup:

The original Self-Service Portal (SSP) did not have a very intuitive setup process. To install it you had to:

• Install and configure a “Trusted Service Provider” to manage communication between the Portal and the BigFix Server
• Deploy the Self-Service Portal on which applications would be published
• Enable software distribution for the SSP
• Enable the Client UI Dashboard and generate a PIN to register the device on the SSP
• Register computers to specific users so they could see those computers when logging into their portal
• Create Application Management Groups and publish those groups as “portal offer” action types so they would appear in the user’s SSP rather than in the offers tab of the BESClient UI.

By contrast the Self-Service Application (SSA) uses the already-installed BES Client as its foundation and the existing BigFix “offers” framework as its delivery system. Assuming you already have the Software-Distribution content enabled all you need to do to install the SSA is run the task “Deploy IBM BigFix Self-Service Application”, Fixlet ID: 301 (Windows), 303 (Mac OS X) from the Software-Distribution External Content Site.

Once installed, the SSA will display an icon in the system tray with the BigFix logo. The title of this icon will be “IBM BigFix Self Service Application”

If you click on the icon you will get the default “Catalog” interface.

If no software has been published for you then this screen will be blank. If no additional dashboards have been deployed to you then you will only have the tabs:

• Catalog
• History

And that’s it on the client side. The computer is now ready to view and install published applications.

Publish Apps:

It’s now time to publish some apps. Find the application you wish to publish and click Take Action:

Once you get the Action Parameters dialog box you will need to select your targets as you do with a normal deployment; however, in a normal software deployment you would have this installed silently in the background without ever interacting with the end-user. In this case you want to ‘publish’ this software so users can accept it (or not) at the time of their choosing. For this you will need to go to the ‘Offer’ tab and select ‘Make this action an offer’. Optionally, you may also select ‘Notify users of offer availability’.

If you’re familiar with BigFix’s modus operandi then you know that the default duration of any action is 48 hours. That’s all well and good if you are silently deploying a patch or an application. Usually 48 hours is enough time for the action to complete on your target(s). When publishing apps in a catalog though you want them to persist. After all, a user may decide that he doesn’t want to install the app today, but may change his mind in two or six months. The app should always be there for whenever the user is ready to install it. For this reason, you should remove the ‘Ends on’ limitation.

The last place I want to focus in the Execution tab is the ‘Reapply behavior’. Under the current version of the SSA once an application has been installed or ‘accepted’ it will disappear from the catalog. This can be a problem if you uninstall the application and decide you want to re-install it later.

In my previous implementations of the SSA, I overcame this limitation by using methods that would have made Rube Goldberg blush. That is until the simplest of solutions was pointed out to me by fellow BigFixer James Stewart. Many of you will recognize him better by his handle ‘jgstew’ (Thanks jg!).

I won’t go into the mechanics of why the app doesn’t show up again if you choose the “whenever it becomes relevant again” because it’s not germane to this discussion; however, the way to make apps stay in the catalog even after they have been installed is to set the Reapply behavior to :

Reapply this action >> while relevant, waiting 15 minutes (the shortest time available in the drop down)

After you install the application it will still disappear from the catalog; however, as you can guess from the setting, it will re-appear in the catalog within15 minutes. This ensures that you will be able to uninstall and re-deploy this application to the same computer without having to create another action.

Once you complete these steps you have essentially published an application to your catalog. To publish more: rinse and repeat. There are, of course, some nuances to this process. I will cover these in part two of this series, but this is the meat of the process. 

Part two: Filling up your catalog, categories and the differences in deploying from the BES Console and the WebUI.