- #INSTALL KASEYA AGENT INSTALL#
- #INSTALL KASEYA AGENT UPDATE#
- #INSTALL KASEYA AGENT DOWNLOAD#
- #INSTALL KASEYA AGENT WINDOWS#
This allows you to programatically ID the group and org and perform client-specific automation during first check-in. Using the pre-built agents on the Manage Orgs/groups page allows you to manually deploy an agent directly into a specific group. That allows anyone to obtain the agent and create an agent in your VSA tenant, which has been considered a security risk for a few years now. You also should no longer publish the agent on VSA (or elsewhere). We've used it to migrate several thousand agents from one RMM to VSA in a couple of hours. The app finds and downloads the default installer and executes it. We have tools that allow you to migrate to VSA by simply running an app and providing args for the VSA host and machine-group.
#INSTALL KASEYA AGENT INSTALL#
If you're looking to selectively install an agent on a new computer, pull down the default installer and pass the machine-group parameter so it checks in directly.
#INSTALL KASEYA AGENT DOWNLOAD#
This is why you shouldn't use scripts that download and execute the installer to perform agent updates. You don't need to specify an agent package.
#INSTALL KASEYA AGENT UPDATE#
Running the built-in agent procedure or the update task from the menu updates in place.
Personally I might not bother doing all that, but the sky's the limit. Should be pretty hard to miss if your techs are trained to expect a specific desktop wallpaper being set to indicate the setup completed. Or get clever and have the script change something obvious like the desktop wallpaper after installing the agent and confirming the agent service is running. If you have the VSA system tray icon visible after install, your techs could check for that, and if it's missing run the script manually. So it doesn't hurt for you to have a way for a tech to manually run the script.
#INSTALL KASEYA AGENT WINDOWS#
If the script runs during windows setup because you customized the image, and there's no network connectivity during setup, the agent can't be grabbed from your VSA. While you could technically make it work on a private isolated network, the bigger issue is not having any connectivity at all when the script runs.
Lastly, I mentioned above that this depends on being able to download the agent over the internet. Maybe a group for all newly imaged agents?Īn interactive menu could work, but it'll be hard coded into your script, and you'll probably not want to put a huge number of groups to pick from (10 locations is probably fine, but if you've got hundreds or thousands of customers you wouldn't want all that hard coded into a deploy script). We also have a few special packages that put agents into specific groups, but we don't use them in any automated deploys. What we do is configure all new agents to go into one specific group that is a landing area where we triage and regroup agents into the correct groups.
Aside from being hard to find, this could also mean policies and procedures are applied, depending on what you have setup.Īnyway the agent URL should be publicly available over the internet, so as long as the new system has an internet connection when it runs the script to download the agent you should be fine to get it to check in. The worst that could happen is a device ends up checking in for the first time to the wrong group.
0 kommentar(er)
