This can happen under a few different situations. Effectively, this tells us that the JC installed on the OS, but was rejected from the appliance end when it connected, which trigged an uninstall of the JC.

Overall - the only way to know for sure what the issue is here, is to collet the Jump Client installer logs through placing the blog.ini file on the affected desktops while you attempt an JC install. You may wish to log a case with our Support Team if you need a copy of the blog.ini logging enabling file.

In our environment it ended up being related to permissions on user accounts changing. The endpoint would make the initial connection to the appliance, see that the user who made the jump client install no longer has access to do that, then uninstalls itself. 

It could also be firewall related as well - ensure traffic is being allowed over port 443 based on this document: https://www.beyondtrust.com/docs/remote-support/getting-started/deployment/ports-firewalls.htm

The blog.ini file will allow more insight to what is causing the issue as well - support can take a look and guide you. 

we were hitting the license max count. I thought we had some buffer room but apparently not the case. it was a hard limit

Good to hear we got to the bottom of this issue! Thanks for using the Commuity Forums!

It would be nice to be able to see logs from either the appliance or the jump client installer when this happens so we know what is causing the uninstall without a great deal of troubleshooting.

It can also be caused by bad CLI parameters. For example: I am currently experiencing issues with the jc_jump_group parameter on the MSI installer after upgrading from 24.1 to 24.2.

Hello CLT-Kevin.

Can I ask what type of issues are you having here? Have you got the blog.ini logging output from an error’ing installation yet?

When specifying a jump group using `jc_jump_group=jumpgroup:foo` on the MSI installer for 24.2.3, the appliance seems to reject the jump client and it immediately uninstalls itself.

Using `--jc-jump-group jumpgroup:foo` on the EXE installer works fine.

It’s been so long since I last pulled the blog.ini, I’ve forgotten how; could you refresh my memory?

Absoultely - the KB https://beyondtrustcorp.service-now.com/kb?id=kb_article_view&sysparm_article=KB0020193 outlines how do this.

Looking the documentation here: https://www.beyondtrust.com/docs/privileged-remote-access/how-to/jump-clients/deploy.htm - it shows that your command arguments for the MSI should be correct, so long as the ‘ jumpgroup:foo ’ part is using the code name assigned to the Jump Group. The example on this page even shows usage of that ‘ jc_jump_group ’ command.

I would highly recommend logging this with our Support Team, it is possible this something unexpected happening in this instance.

That’s my plan, but I’m waiting for the Portal team to fix my access to ServiceNow, so I figured I’d hop into the forums and see if anyone else was having similar issues. Thanks!

It was an ID10T error.

The blog.ini logs clued me in that we forgot to allow overriding the jump group during install.
Not sure why it was working with the EXE then…but the MSI works now.

Thanks!

Good to hear this is now resolved! Thanks for using the Commuity Forums!