This is the second part of my discussion on the redesigned BigFix Self-Service Application. If you haven’t read part one I suggest you start there first.

Apps and Categories:

As I said in part one: publishing more applications to the catalog is just a matter of deploying the application tasks as offers and making them policies so they persist. Doing this will start to make your catalog look more and more like an actual app store:

But there is a part here I’m leaving out:

When you have only a handful of applications in the catalog it isn’t very difficult to find one among five or six. If you plan to publish dozens or even hundreds of applications though, it becomes more time consuming for users to scroll through all of them looking for a specific one. By giving your apps categories users can filter the catalog either by “All Categories” as in the screenshot above or you can filter by a specific category:

Whereby you would only see the applications that match that specific category:

In the example above, you may see several apps with multiple categories because you can assign more than one to an application. However, all the applications above are, at least, in the “Communication Tools” category. But this all seems to be pretty self-explanatory and easy to understand, so why am I bringing it up?

 Previously when I published an app from the console you might have noticed that the ‘Offer’ tab below the Title showed the app’s Category. 

This corresponds to the Category I entered when first adding the software to BigFix:

But the reason why the Offer tab shows a category is because I entered it there manually as I was taking the action in the Console. By default, when done through the console, an offer will not populate the category field even though it’s listed in the Properties of the task:

This will lead to the app falling into the “Uncategorized” bucket

By contrast, when you deploy the app via the WebUI, you do not have to select a category

By now I’m sure you’ve had the thought: “Why publish applications through the console at all when you can just use the WebUI and have the category automatically added?”.

The answer is simple: When taking action via the BES Console you have the mechanism to make the software package become relevant again after 15 minutes (as mentioned in the previous article)

BES Console

However, the WebUI has no such option (yet):

WebUI:

So when you publish this application via the WebUI it will apply only once and disappear after the user installs it. Only by using the Console can you apply the setting to make it become relevant again. Until IBM introduces a change to the way the SSA views installed apps you will need to publish applications via the BES Console and manually add a category if you want them to stay available for users for a re-install.

Making it Yours (Customizations):

In the tradition of leaving the best for last I’d like to finish up my discussion on the SSA by pointing out one of the biggest differences between it and the old Self-Service Portal: Branding.

A self-service application catalog is a platform that yields the same basic benefits for both IT staff and end-users:

• Less time spent talking to end-users/IT staff
• On-demand software delivery
• No middle-man to slow progress of requests
• Intuitive interface and progress indicators

The successful implementation of the mechanism that delivers these results is usually the main goal. The look and feel are often considered secondary. In the case of the BigFix Self-Service Application though, IBM has thought about that aspect of the platform as well. The SSA can be configured to reflect your ‘brand’. 

The default icon for the SSA is the BigFix logo and the label: “IBM BigFix Self-Service Application”

With just a few clicks this can be changed to reflect your own corporate logo and label:

The catalog title and footer can also be changed:

And this can all be done from the WebUI settings menu which is found on the top left corner of the home page:

Simply add your own text and icon and BigFix will create a task that will perform this configuration on any computers you target.

Being able to target only a specific subset of computers means you can create multiple SSA configurations with different logos and text and have different users see distinct SSA branding for their department, business unit, etc.

If you’ve looked carefully at this screen though you may notice that while it allows you to change the title there is no option for changing the footer text. For this you need to venture into the task that is created once you save this configuration. Unless you change it (first field in the screenshot above) the task will be called “Configure Self-Service Application”. 

• Find the task in the BES Console
• Edit the task
• In the Actions tab find the line “appendfile applicationName: …”
• Add the following line “appendfile helpMessage: <your message>” (as shown below)

• Save the Task

The task will now deliver this customization to any computer you target. Something to also bear in mind is that you do not need to use the WebUI and create a new configuration task every time you want to make a change. The relevant files that control branding for the SSA are all located in the “BigFix Enterprise\BigFix Self Service Application\resources” folder.

By simply changing the plaintext “ssa.config” file

And copying in a new “icon.ico” file you can change the look of the SSA on any managed endpoint.

I'm sure that if you've worked with the SSA you may notice that there are a few places where it can still be improved, but if you’ve used the old Self-Service Portal and are now using SSA you will agree that this wasn’t so much a refresh or an upgrade, but a thorough ground-up rethinking and implementation of a self-service application catalog. It is designed to fully integrate the capabilities of BigFix with the needs of end users. Furthermore, if you’ve used the SSA since its first GA version in 2016 you can see that IBM is serious about improving its functionality and ease of use. In tribute to my original post on the SSP I can still answer that question that every solution provider hates to get: “Do I need to install another agent for this to work?” with a resounding

“No! It will work with exactly what you have today”.