Are you able to remote in (I know, ironic) and see if it’s actually installed?  Or at the very least, remote powershell in and browse their computer for evidence of an install?

Haven’t tried powershell. Why would the local device “company portal” show installed if it isn’t installed though?

I mean, how does the company portal know if something actually installed?  Does it just execute the EXE, and just assume it worked?  Does it do any checks?  Does it keep any logs you could look through?  Maybe it deployed the EXE, but there are networking complications that prevent the device from hitting the internet?

I think, overall, this is a common line of questioning with any software system that deploys other software.  My advice would be to powershell into one of the “problem” computers and take a peak at the logs to see if you can find anything out of the ordinary.

If you can find an endpoint that says successfully installed in Intune but does not have the jump client installed, attempt a reboot of the device first. I found some don’t launch the process “bomgar-scc.exe” until reboot.

In our case, after using process monitor on a machine that installed successfully (but did not have the client running) we found that the MSI is installing the app and then immediately uninstalling itself. In C:\ProgramData you may be in the same boat if you find folders named bomgar-scc-0x###### with ONLY a “remove.exe” inside.

Currently have a ticket open. Let me know if you’re in the same boat and I can relay what our solution is.

I have that folder with the “remove.exe” on my machine but it is working fine

Sorry about that! I meant to say ONLY a “remove.exe” inside. On a successful install you should have many other files including “bomgar-scc.exe”

Did we validate the JumpClient actually got installed while the JumpClient deployed was valid?
I know screen shot is from PRA, but RS would be similar.

Then for mass deployments, I would always recommend using MSI’s

@Jens Hansen Yes at the time of install the JumpClient was valid and we used the MSI.

@Chris M When I looked at my co-workers machine that shows an “install” but isnt showing up anywhere, they don’t even have a bomgar folder in C:\ProgramData

Can I ask if these machines had a Jump Client installed on them previously? If so, was that installed via the MSI Installer previously?

Overall, the best course of action is to try to deploy the Jump Client again to a known problem machine and ensure the ‘blog.ini’ logging enabling file in placed in the root of C:\. This should then generate a Jump Client installer log we (well, the Support Team) can review to advise why it failed. If you need a copy of the ‘blog.ini’, you’ll need to log a Support Case to get a copy of that.

Another post here discovered they exceeded the license count, which let to the JumpClient to uninstall as is got successfully installed.

https://beekeepers.beyondtrust.com/topic/show?tid=5553&fid=45

Did we validate the JumpClient actually got installed while the JumpClient deployed was valid?
I know screen shot is from PRA, but RS would be similar.

Then for mass deployments, I would always recommend using MSI’s

The client was originally installed with the MSI via win32 app in Intune. They were running successfully. (At least in my case, but I am not OP) Then suddenly disappeared off several machines. Many of them reinstalled successfully, but 10 or so refuse to install and immediately uninstall. (Don’t want to take over this thread and have a ticket open for this) The installer is/was valid at the time of reinstall and we are not near our max license count.

 

In our case (not sure if this applies to OP) it appears to have some sort of authentication error just before uninstalling. Found this by using the blog.ini to create a log.

 

I had this happen on a few installs as well. Seems to be hit or miss if the MSI actually creates the folder in my testing. 
(actually, looking again at process monitor (captured while running the MSI), the bomgar-scc.exe process appears to attempt to remove the “bomgar-scc-0x#######” folder on uninstall, but that clean-up fails in our environment on many occasions leaving only it and remove.exe in place)

@PhillC No the machines didn’t have a Jump Client installed on them previously. We had a small test group to begin with but we didn’t use MSI for that group. When we were ready to roll out company wide we used the MSI with Intune. That’s when we noticed install failures/errors.

Here’s how it works:

1. Detection Rules: Intune administrators set up detection rules that specify how to check if an app is installed. These rules can look for specific files, registry entries, or other indicators.

2. Company Portal Sync: The Company Portal app collects data from your device and sends it to Intune. This includes information about installed apps based on the detection rules.

3. Intune Evaluation: Intune evaluates the data against the detection rules. If the criteria are met, Intune marks the app as installed.

4. Reporting Back: Intune then communicates this status back to the Company Portal app, which displays the information to the user.

So, if Intune/Company Portal is reporting something is installed that isn’t, it’s likely due to the detection method/rules. For example, if the detection rule is looking for X version via registry key and that key still exists with the program uninstalled, it would still think the program is installed.