Jump Client immediately uninstalls after installing. Version 24.1.1

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!