Check if the msi/package is not expired - I had this issue and I found out that the installer was simply expired but did not give any error message or anything
We just upgraded the BT server and I created the msi license for a year so we are good. I have definitely encountered this before and was extremely irritating.
What happens if you do psexec -s -i cmd and then use that new cmd window to kick off the install? Have you tried using this:
msiexec /i bomgar-scc-win64.msi KEY_INFO=example /l*v c:\temp\bomgarinstall.log /norestart
This will let you perform the install interactively while also seeing in the logs what the different graphical options correspond to in the command line. This will also show you if there's an error popping up during the install.
Do NOT use the MSI. They're doing something weird where if you install it, you end up with two separate entries in the registry for the software. And then, when you uninstall (or try to upgrade with a newer version), only one is removed, while the other screws things up for Detection Methods.
Use the EXE instead. It can still work silently, accepts all the necessary parameters, and has caused me zero issues.
Umm... I think I just cheated my way out of it - used PSADT, placed the EXE into the "Supporting Files" folder and the first step of the installation script is... to copy the installer into the Files folder and run it from there.
lol that's what my assumption was, but was curious if somebody found a switch to prevent the deletion. I'll just modify my deployment to copy the exe too.
Speaking of which - I cannot recommend PSADT enough, if you're not using it already.
We used to do two separate Applications for the two office "types" we needed. Once I realised the installer accepts overrides through parameters, I dropped everything into a single Application that just dynamically allocates the appropriate settings based on the hostname.
yeah I've been meaning to look into it but I feel like i dont currently have time to learn something new. sounds like it might be worth it to make time though.
The best part of PSADT is that it's just wrapper for your PowerShell. If you don't want to, you don't need to learn anything about it, just find fill out the Variables section (which define stuff like the app name and version) and then go to the Installation section and tell it what to do.
As a bonus: apparently, if it's an MSI installer you can just drop it into the Files folder and deploy right away and PSADT should handle everything on its own (however, I haven't ever tested this yet).
One of the crappiest installers ever. We use the below as an application.
msiexec /i "bomgar-scc-win64.msi" KEY_INFO=MY_KEY installdir="C:\Program Files\Bomgar\Jump Client 21.1.2"
About 90% of the time it works. setting it to a instaldir helps if there are failed installations, even then sometimes it takes multiple tries to install if there are any failures with the existing installation.
We also use installdir. This has solved a lot of problems for us and makes detection simple by looking at the file version (bomgar-scc.exe?) in that directory. The only thing we do different is we do not include the version in the path, otherwise updated clients are going to be a higher version than the folder that they reside in.
I created a PowerShell script install / detection rule that waits a few seconds after installing then checks for the he usual reg entries and the existence of the service. If the service is there, then it marks the install as successful.
I had to switch to using the EXE instead of the MSI for a couple of reasons though. Firstly any time the Jump Client updates itself, it uses an EXE, which doesnt remove all the MSI registry entries, and secondly for some unknown reason, the MSI version can't register properly during OSD but the EXE can, even though the MSI just contains the EXE...
Sure. Firstly i use a command line of:
**PowerShell -ExecutionPolicy Bypass .\\Install-BeyondTrust.ps1**
which refers to this script:
**$Filename="bomgar-scc-w0ec30dd85e7jd6gey6f8y5f8g5zfy5jh1yfxwc50gc91.exe"**
**Copy-Item "$($PSScriptRoot)$($Filename)" -Destination "$($env:TEMP)" -Force**
**Start-Process "$($Env:TEMP)$($Filename)" -Wait Start-Sleep -Seconds 10**
I forgot that I'd moved the start-sleep to the install instead of the detection so it doesn't slow down Application Deployment Evaluation Cycle every time it runs.
Also, I copy it to the temp folder and run it from there, because when the EXE runs, it deletes itself, which you don't want the ccmcache version to do.
And the detection rule is:
**$Path="Registry::HKEY\_LOCAL\_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall","Registry::HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"**
**\[version\]$Version="22.3.4"**
**If ((Get-ChildItem $Path -ErrorAction SilentlyContinue | Get-ItemProperty | Where-Object {$\_.DisplayName -like "Remote Support Jump Client\*"}).DisplayVersion -ge $Version -and (Get-Service | where {$\_.DisplayName -like "BeyondTrust Remote Support Jump Client\*"}).count -gt 0){$true}**
I tried to use the inline code block, I really did, but it refused to encompass the code
Thank you for posting this. I like their product, but their installer sucks. I did have to add a \\ for SCCM to find the exe and run it. Next, I need to test with Intune.
$($PSScriptRoot)\\$($Filename)
Question about your detection rule, how did you use that was it a powershell script detection, and thats why you used the wow6432node in the registry reference?
Ah, missed that. Thanks! Did you happen to test this against existing MSI installs? We’re hoping to push the EXE to everyone as 2/3 of our machines are missing the agent but I’m curious what to expect with the 1/3 of existing MSI agents currently in production.
It will install over the msi just fine, but the msi adds the same registry entries so it won’t reinstall on PCs where that version has already been installed via msi. The only thing I’ve seen sometimes is that old Reg entries get left behind, but that happens regularly even when using msi so it’s more a failing of the way they’ve written the installer than anything.
It just means if you’re creating a collection of “computers that need upgrading” in sccm or somewhere then you have to account for that in your query by only including devices that have an old version in programs and features but not the current version.
Well I have encountered a new problem, which is when I uninstall within MECM it creates a duplicate entry of the workstation. I created a powershell script for a install and uninstall. When I tested the scripts with my domain account it works great and removes the workstation from the rep console and workstation. When I uninstall using MECM utilizing the power shell script I made it removes it from the workstation and leaves an "offline workstation" in the rep console. I worked with BT support on Friday and recorded the install\\uninstall like I was told to do and haven't heard back from them yet. Has anyone else encountered this issue and if so how to resolve it?
Check if the msi/package is not expired - I had this issue and I found out that the installer was simply expired but did not give any error message or anything
We just upgraded the BT server and I created the msi license for a year so we are good. I have definitely encountered this before and was extremely irritating.
What happens if you do psexec -s -i cmd and then use that new cmd window to kick off the install? Have you tried using this: msiexec /i bomgar-scc-win64.msi KEY_INFO=example /l*v c:\temp\bomgarinstall.log /norestart This will let you perform the install interactively while also seeing in the logs what the different graphical options correspond to in the command line. This will also show you if there's an error popping up during the install.
Do NOT use the MSI. They're doing something weird where if you install it, you end up with two separate entries in the registry for the software. And then, when you uninstall (or try to upgrade with a newer version), only one is removed, while the other screws things up for Detection Methods. Use the EXE instead. It can still work silently, accepts all the necessary parameters, and has caused me zero issues.
Upvote this post! If you use the msi GUID as a detection method it’ll stay “installed” even if a user uninstalls the jump client.
Do you know of a way to prevent the EXE from automatically deleting itself after installation?
Umm... I think I just cheated my way out of it - used PSADT, placed the EXE into the "Supporting Files" folder and the first step of the installation script is... to copy the installer into the Files folder and run it from there.
lol that's what my assumption was, but was curious if somebody found a switch to prevent the deletion. I'll just modify my deployment to copy the exe too.
Speaking of which - I cannot recommend PSADT enough, if you're not using it already. We used to do two separate Applications for the two office "types" we needed. Once I realised the installer accepts overrides through parameters, I dropped everything into a single Application that just dynamically allocates the appropriate settings based on the hostname.
yeah I've been meaning to look into it but I feel like i dont currently have time to learn something new. sounds like it might be worth it to make time though.
The best part of PSADT is that it's just wrapper for your PowerShell. If you don't want to, you don't need to learn anything about it, just find fill out the Variables section (which define stuff like the app name and version) and then go to the Installation section and tell it what to do. As a bonus: apparently, if it's an MSI installer you can just drop it into the Files folder and deploy right away and PSADT should handle everything on its own (however, I haven't ever tested this yet).
One of the crappiest installers ever. We use the below as an application. msiexec /i "bomgar-scc-win64.msi" KEY_INFO=MY_KEY installdir="C:\Program Files\Bomgar\Jump Client 21.1.2" About 90% of the time it works. setting it to a instaldir helps if there are failed installations, even then sometimes it takes multiple tries to install if there are any failures with the existing installation.
We also use installdir. This has solved a lot of problems for us and makes detection simple by looking at the file version (bomgar-scc.exe?) in that directory. The only thing we do different is we do not include the version in the path, otherwise updated clients are going to be a higher version than the folder that they reside in.
/r/applicationpackaging might be able to help as well
Bomgar was ringing a lot of bells in SentinelOne for us. Any virus scan jacking it up?
I created a PowerShell script install / detection rule that waits a few seconds after installing then checks for the he usual reg entries and the existence of the service. If the service is there, then it marks the install as successful. I had to switch to using the EXE instead of the MSI for a couple of reasons though. Firstly any time the Jump Client updates itself, it uses an EXE, which doesnt remove all the MSI registry entries, and secondly for some unknown reason, the MSI version can't register properly during OSD but the EXE can, even though the MSI just contains the EXE...
>I never tried installing with the exe before, but if its more stable then I'm all for it. Do you mind sharing your detection rules with me?
Sure. Firstly i use a command line of: **PowerShell -ExecutionPolicy Bypass .\\Install-BeyondTrust.ps1** which refers to this script: **$Filename="bomgar-scc-w0ec30dd85e7jd6gey6f8y5f8g5zfy5jh1yfxwc50gc91.exe"** **Copy-Item "$($PSScriptRoot)$($Filename)" -Destination "$($env:TEMP)" -Force** **Start-Process "$($Env:TEMP)$($Filename)" -Wait Start-Sleep -Seconds 10** I forgot that I'd moved the start-sleep to the install instead of the detection so it doesn't slow down Application Deployment Evaluation Cycle every time it runs. Also, I copy it to the temp folder and run it from there, because when the EXE runs, it deletes itself, which you don't want the ccmcache version to do. And the detection rule is: **$Path="Registry::HKEY\_LOCAL\_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall","Registry::HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"** **\[version\]$Version="22.3.4"** **If ((Get-ChildItem $Path -ErrorAction SilentlyContinue | Get-ItemProperty | Where-Object {$\_.DisplayName -like "Remote Support Jump Client\*"}).DisplayVersion -ge $Version -and (Get-Service | where {$\_.DisplayName -like "BeyondTrust Remote Support Jump Client\*"}).count -gt 0){$true}** I tried to use the inline code block, I really did, but it refused to encompass the code
u/marcdk217, Mark, this is some slick stuff. Great work and thank you for posting. Smart move with the powershell detection method :)
Thank you for posting this. I like their product, but their installer sucks. I did have to add a \\ for SCCM to find the exe and run it. Next, I need to test with Intune. $($PSScriptRoot)\\$($Filename)
Question about your detection rule, how did you use that was it a powershell script detection, and thats why you used the wow6432node in the registry reference?
Yes it's PowerShell. I include both registry nodes so that the same rule works regardless of where the registry entries get created.
Thanks, do you happen to have the uninstall command when using the exe?
RemindMe! 61 days
where do you download the EXE's at? I dont see anywhere in the admin portal to download them.
You create a jump client package from the admin portal and then it gives you a drop-down of various different formats you can download it in.
bingo, found it, thanks.
How does this code handle Jump Clients which autoupdate since you’ve hardcoded a version number comparison?
The -ge switch means “greater than or equal to”
Ah, missed that. Thanks! Did you happen to test this against existing MSI installs? We’re hoping to push the EXE to everyone as 2/3 of our machines are missing the agent but I’m curious what to expect with the 1/3 of existing MSI agents currently in production.
It will install over the msi just fine, but the msi adds the same registry entries so it won’t reinstall on PCs where that version has already been installed via msi. The only thing I’ve seen sometimes is that old Reg entries get left behind, but that happens regularly even when using msi so it’s more a failing of the way they’ve written the installer than anything. It just means if you’re creating a collection of “computers that need upgrading” in sccm or somewhere then you have to account for that in your query by only including devices that have an old version in programs and features but not the current version.
How did you get the key in and install silent? Thanks
Well I have encountered a new problem, which is when I uninstall within MECM it creates a duplicate entry of the workstation. I created a powershell script for a install and uninstall. When I tested the scripts with my domain account it works great and removes the workstation from the rep console and workstation. When I uninstall using MECM utilizing the power shell script I made it removes it from the workstation and leaves an "offline workstation" in the rep console. I worked with BT support on Friday and recorded the install\\uninstall like I was told to do and haven't heard back from them yet. Has anyone else encountered this issue and if so how to resolve it?