Product Ideas Portal

Got an idea for a new feature? Maybe a tweak to make something work even better? Wish there was an integration with another product to make you even more productive? You've come to the right place.

The Product Ideas Portal lets you submit whatever product feedback you have, good, bad, ugly, and anywhere between.

Want to stay anonymous? Don't worry, no email address or name fields are shared on the public portal. You can create an account which lets you vote on other people's ideas and receive updates when your idea's status changes.

To learn more about how an idea becomes a feature, check out this infographic.


Properly remove old versions before deploying new version

We are licensed for both Remote Support (RS) and Privileged Remote Access (PRA). We deploy RS Jump Clients (JC) and RS Support Buttons (SB) to all of our client endpoints. We also deploy JCs to our servers as part of PRA. We have over 400 endpoints and over 100 servers.

This request is also related to the following feature requests that have made absolutely no traction over the past 2-4 years: A01-I-2562, A01-I-1845, A01-I-706.

For BeyondTrust internal staff, this is in regards to two tickets we have opened, one of which provides screenshots and extensive detail (CS0943367 and CS0943367).

We have the RS JC deployed to 400+ endpoints. We deployed this through the .msi. For some reason, every endpoint has TWO installations for the RS JC:

  1. BeyondTrust Remote Support Jump Client <domainname>.beyondtrustcloud.com > Version 20.1.3

  2. Remote Support Jump Client 21.1.1 [<domainname>.beyondtrustcloud.com] [GUID] > Version 21.1.1

The top software package is installed on 463 devices. The bottom software packages is installed on anywhere from 1-14 devices. Since there are different GUIDs, this second package shows up multiple times, up to and until 463 devices. Why there are two software packages being shown is completely beyond me. Additionally, the top software package is showing the old version of the software. This is the version that was installed when we deployed our appliance and pushed out the JC to the clients. There should only be one install of this software across all devices. As per the referenced feature requests, there is absolutely no reason to separate these installs out. As a result of doing this, we now have hundreds of 'Remote Support Jump Client 21.1.1' software installs showing, each with a different GUID, and the top-level package for all 463 devices is showing the wrong version.

While the above is directly related to the RS JC, this also occurs for the PRA JC; however, I noticed that there is no "top-level" package for the PRA JC. This could be because we deployed the PRA JC through the .exe instead of the .msi (the RS JC was all deployed via .msi). So while there is no top-level package showing an incorrect version for PRA RS, there are still about 30 software packages, each deployed to 1-2 machines, name:

  1. Privileged Remote Access Jump Client 20.2.3 [<domainname>.beyondtrustcloud.com] [GUID] > Version 20.2.3

In my testing, this issue also occurs with the RS Representative Console, also deployed via .msi. The following software packages exist:

  1. Representative Console <domainname>.beyondtrustcloud.com > Version 20.1.3

  2. Representative Console 21.1.1 [<domainname>.beyondtrustcloud.com] > Version 21.1.1

As you can see, this is very similar to that of the RS JC. The #1 software package shows every device that has the console installed, but it shows the older version. The #2 software package is what's actually installed on most of the devices. The PRA Access Console seems to also have 2 installations, much like the RS Representative Console.

I cannot confirm whether the issue with the consoles, the JCs, or the SBs is directly related to the usage of the .msi vs. the .exe. What I will say, though, is that removing or upgrading software that was deployed via the .msi is an absolute nightmare. The software does not properly remove itself from the software and/or it leaves traces to the software behind in the registry.

A combination of the inability to properly uninstall/upgrade mixed with several hundred software packages being detected with different GUIDs, also mixed with incorrect versions being detected, has created an absolute nightmare in our environment. This nightmare is not only related to compliance, but it also impacts our ability to properly detect which software is missing the software.

It is very disappointing that these feature requests have been opened since 2016 and 2018 and no traction has been made, and that now we are experiencing a similar issue.

While I am not a developer, the only way to resolve this in my eyes would be to insert only a single registry entry for the installed software, without registering a GUID (similar to that of A01-I-2562). All devices should use the exact same software name and should appear with the correct version installed. This goes for all versions of the software: RS JC, RS SB, RS Representative Console, PRA JC, PRA Access Console. There should be no duplicate software detected for a single installation.

Furthermore, in regards to removing the software, this issue appears to be directly related to the .msi. Removing the .exe version of the software appears to work perfectly fine. Removing the .msi from Add/Remove Programs (as any normal human would and should be expected to) does not properly clean up the registry. This is a known issue and you cannot expect everyone to remove the software using msiexec. This needs to be fixed, and should have already been fixed.

  • Guest
  • Mar 10 2021
  • Future consideration
  • Attach files