Integrating Bomgar and Jamf Self Service

To me, what follows didn’t seem overly remarkable, until I shared it in #jamfnation on the MacAdmin’s Slack. I received some great feedback and was encouraged to share what I did with the wider community. I honestly didn’t think it would be that useful to as many people as it was.

We use Bomgar to give our staff and students an easy way to get help when they need it, be that on their Windows PCs, Macs or even Android tablets. Unfortunately, the user’s journey with Bomgar on a Mac is something like this:

  1. Click a URL that takes you to an online form.
  2. Fill in that form with details about your issue.
  3. Download a Disk Image (DMG) containing the Bomgar client.
  4. Open/mount the DMG file.
  5. Open your mounted Disk Image and run the Bomgar application.

Not great and full of manual steps that a lot of people will find challenging or frustrating, especially in situations where they need help quickly to resolve their issues. It’s a faff and faffing is bad. There has to be a better way. And our students and staff love using Jamf Self Service.

It began with NoMAD

At this point, I give a well-deserved nod to the open source application NoMAD. If you’re in an Active Directory environment and you have Macs, you owe it to yourself to check it out, if you don’t know it already. Specifically, NoMAD has nifty Bomgar integration – you click a menu item and the Bomgar client magically downloads, launches and establishes a session. I gotta get me some of that! So, let’s dig into the code!

The good stuff is in here, the Swift class that deals with the Get Help menu item. The Bomgar specific stuff is this:

cliTask("curl -o /tmp/BomgarClient " + myURL )
cliTaskNoTerm("/usr/bin/unzip -o -d /tmp /tmp/BomgarClient")
cliTask("/usr/bin/open /tmp/Bomgar/Double-Click\\ To\\ Start\\ Support\\ Session.app")

Looks like the stuff in brackets can be run in a shell script, which is good. So let’s see what each line does.

  1. Use the curl utility to download the Bomgar client (myURL is a variable which contains the arguments for curl to send the correct data to your Bomgar server, using the Bomgar API. More on that in a moment…
  2. Unzip the Bomgar client.
  3. Run the unzipped Bomgar client application, and make the magic happen.

Curling one off

The fun bit is working out exactly what to tell curl to download and what to tell curl to tell your Bomgar server, so it downloads exactly what you want:

  • A zip file containing the client (not a DMG file!).
  • The right settings for your environment baked into the downloaded client.

Help is at hand, in NoMAD’s documentation, here. Specifically, this bit, which specifies using the defaults command to set the myURL variable for NoMAD as a preference:

'"https://bomgar.company.com/api/start_session -A \"Mozilla/5.0\\ (Macintosh;\\ Intel\\ Mac\\ OS\\ X\\ 10_11_4)\\ AppleWebKit/601.5.17\\ (KHTML,\\ like\\ Gecko)\\ Version/9.1\\ Safari/601.5.17\" -d issue_menu=1 -d session.custom.external_key=NoMAD -d session.custom.full_name=<> -d session.custom.serial_number=<> -d customer.company=<>"'

The -A argument is the User Agent – the browser and operating system curl pretends to be. It turns out that simulating Safari on OS X 10.11.4 makes the Bomgar server give us back a zip file containing the client application. Every other User Agent I tried resulted in getting a DMG instead.

Check out the -d arguments. Each one tells the Bomgar server something specific, in accordance with Bomgar’s API, so the session can be launched exactly how you want it to be. For our setup, it turned out that we needed to supply these:

issue_menu
codeName

issue_menu should always be set to 1, end of.

codeName specifies the Bomgar-specific Issue Code that your session will use, so it gets routed to the team/queue it needs to go to. It wasn’t in NoMAD’s source or documentation. I had to figure that one out for myself. According to the API reference, leaving it out makes the session connect to the default queue. In our case, it meant a black hole and our service desk staff were unaware of the incoming session.

You can get its value by logging into the admin interface for your Bomgar server, clicking the CONFIGURATION menu, then choosing ISSUES. Click on the Issue you want to route your sessions to and you’ll see its Code Name, like this:

A Script fit for Self Service

The next step is to get everything into a script. Here’s one I made earlier, which has a couple of variables you can edit for your Bomgar server URL and Issue Code – just change those to your liking:

You’ll notice a lot of ‘su-ing’ in there and a really long bit of Python (thanks to Macmule for that one!). That’s because this script will be run by a Jamf Self Service policy, and so runs as the root user. It needs to run each command in the context of the currently logged in user, so that’s why we do this – work out who that user is, then do the magic as them.

Once that script is in your JSS Jamf Pro Server, simply create a policy for Self Service that runs it. Job done.

What does it look like from the user’s perspective when it’s working? This! Our service desk was closed when I recorded it, but you get the idea…

Advertisements

Author: n.martin

Managing 450-odd Macs at a university, innit.

9 thoughts on “Integrating Bomgar and Jamf Self Service”

  1. Someone reached out to me about this after I mentioned that I got it working in our Self Service. The person stated that their users were standard users and were getting prompts for credentials. Since there are su commands involved I’d imagine this only works silently if the current user of the computer is an admin user? Any thoughts on a seamless experience for standard/non-admin users?

    Like

    1. I’ve tried it for both standard and admin users and it’s worked for both in my environment. Someone got in touch with me today about the same issue – maybe the same person.

      In their situation, they restrict mounting of DMGs to non-admin users. The Bomgar app that comes out of the zip file contains a hidden DMG which it mounts and then runs another binary inside that to get the session going. That’s the only thing I can think of which might be stopping it for them.

      Like

    2. Should also mention that I’m using other scripts that do su commands as part of login policies (like setting up user’s sidebar in our student labs) – no issues at all with standard user accounts either. 🙂

      Like

      1. Just use NoMAD and you don’t need to put it in Self Service. 😉

        Firstly, glad to see other people getting use out of this.

        Secondly, if you are in a multi-tenant environment, you can get some great use out of the session.custom keys, but you have to add them to your Bomgar instance first. It can really help the desk figure out who and what may be coming in.

        Like

      2. Hi Joel, thanks for your comments and your code! Yeah – the Self Service thing was more a culture based decision – for us, having it there made logical sense as we like to put all our software/fix it stuff in Self Service. But what’s really cool is it could be worked into any UX situation like an App with a Dock shortcut for example. That’s what I love about OSS – how it can be moulded to suit so many different needs.

        We’re just single-tenant so not taking much advantage of Bomgar’s great extensibility yet. I noticed that in the Rep Console, you do get the hostname, full user name and platform/OS coming up for incoming sessions started in this way, which is enough for us.

        Like

  2. Have you tried using the Bomgar Button? I believe it accomplishes the same thing and the user can put the Button on their desktop which allows them to connect to a representative quickly.

    Like

    1. I did but unfortunately what you get for a Mac is meant to be downloaded and run by users it deletes itself after it’s been run. I actually spent some time picking it apart and did manage to get something workable, but I favour this method as it always downloads the most up-to-date client from the server every time, and cleans up after itself on the Mac.

      Bomgar Buttons also expire after a set time – up to 5 years (so that’s perhaps not an issue). Having it in Self Service means we don’t have to deploy anything and it’s in a place where people are going to download software and solve issues etc.

      The script could be also easily re-worked into an app for a similar experience – e.g. so users click a Dock item and get a session.

      We deploy the Bomgar Button on our Windows clients though and it works well for them.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s