1. I can’t talk much on the intricacies of each, but we haven’t had issues using the .msi installer
2. Yes - Could be related to the issues you were experiencing with MSI. In my scenario I had created the jump client installer, then revoked permissions for that user, and the jump client would then install on the endpoint > connect to the appliance > see the user who made the jump client no longer has permissions to create jump clients > auto-uninstall
3. Not to my knowledge. Maybe you could do this with the API?
4. We don’t do overrides during the installation, but I have heard others adding specific info to the name/comments so you can more easily search in the representative console. We use the API to update the comment field after installation to contain who the computer is assigned to, their department, the computer model, etc.
5. I don’t believe this is supported, but we change the service start mode to be “auto” instead of delayed. This makes the jump client show online much quicker in the representative console

Removing expired/dead jump clients - You probably know this but thought I’d mention just in case - you could lower your setting “Number of days before Jump Clients that have not connected are automatically deleted”. Some code examples might also help cleaning up duplicate records if you run into that - Easy way to find and remove duplicate clients in Admin console. | Community

Thanks for the input mjhall.

1. I tested both the MSI and EXE installers and I can’t see any functional differences between them. I guess it just depends on what your particular workflow. If I crack open the MSI it’s just an EXE installer inside anyways.
2. Okay, it confirms what I’ve seen in practice and in things I’ve seen in log files. I don’t understand logic behind the decision to tie installers to users. If you need to invalidate an installer, then create an administrative action to do that so it can be assigned.
3. Yeah, seems possible to edit the Jump Client config based on this. I wonder why this is limited only to the API though.
4. Good info on override use cases.
5.  I could probably script it with PowerShell during deployment. But good call.

Good tips on console cleanup.

I’ll be testing out client replacement deployment here soon, but I found a way to detect and remove clients using the current installer key before installing the replacement version. It’s somewhat clunky, but it works for now. Always room for improvement with PowerShell! 😀

Personally I always lean towards a MSI installer but for Remote Support I would say AVOID THEM!!!!  They are a poorly implemented wrapper for the EXE installer.  If you use Orca you can see how it works and the MSI does nothing really.

I have found the MSI installers to be really unreliable.  If you are using detection logic to see if the MSI is installed as your logic then its not worth its weight in gold.  If the jump is removed from the console or someone uninstalled it manually (Add / Remove programs or uninstall from the notfications area) the MSI is left behind but its hidden (Marked as a System component in the Registry) so your logic may never automatically reinstall the client as its actually still left in place.

In regards to Overrides we only use them so we set the device owners UPN in the comments to make it easy to find who the user is.  We have a powershell script that runs finds the user from Azure AD Registration in the Registry and then adds that to the command line so we see it in the console.

If I needed to do this I would look to use something like PS App Deploy to find the current ones installed uninstall them and then reinstall them in one session.