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!