Is there a way to have Kaseya install several applications once the agent is installed on a new PC? I have several applications that are installed on all computers. I am hoping to simplify the new PC setup process by having Kaseya installing those applications automatically when the agent is first installed.
I was thinking of creating an agent procedure that I could run but wasn't sure if there is an easier way.
yes inside of policy management
Yeah as asmith0684 mentioned, your best bet would be through Policy Management. There are several ways of handling this request but it will take a little bit to first set it up. Once you get it going, it will work flawlessly.
In a nutshell: create policy(s) for a new machine and add the application install procedures (+ whatever else you need) to that policy that you wanted installed on a new PC. Apply to the groups needed.
Personally, I would stay away from Software Management until all the kinks are worked out and works fine.
Policy Management for the win!
What I do because I find Policy Management doesn't always kick in right away is I create a agent template. Once you have created a template just assign the agent procedures you would like to have run once your deployment is done. What I do is have one procedure called "Post Deployment - Type of Computer" and then schedule off any of the procedures that need to run from there, I also schedule an Agent Update in case the installer is not current. This way you never need to adjust the template once created, and then any changes or adjustments are made within the "Post Deployment - Type of Computer" procedure. Once that is done create an installer or package and use the Select Copy Agent and select the template you made. Once this is done you shouldn't need to revisit the template and if any changes are necessary just change that Post Deployment procedure.
So I'm going to go out on a limb and disagree with using policies here. I LOVE policies and have more than 170 that manage almost every aspect of VSA - to the point that (aside from the time needed to add new clients) I spend less than 15 minutes a week on VSA administration in an environment with well over 3000 managed endpoints. Performing agent initialization and automatically installing applications when new agents check in is one of the few, if not only things not done by policy in our environment.
More specifically, the original poster asked how to configure machines when agents check in. Check in is an action, and actions are best responded to by procedures. In the simplest manner, set the New Agent Install alarm to run an initialization script, which can then call a series of procedures to install individual applications. Why individual procedures? So you can test them one by one and then use them individually to install specific apps. If the app install procedures work individually, then an initialization procedure can call the app install procedures without fear of them failing. It's also easier to create custom "assortments" of applications to install without duplication of the install logic.
Take it another step - use a managed variable to define which application set is deployed. Managed Variables are customer-specific, even group (site) specific. The single Agent Init procedure that runs when an agent checks in looks at the value of a managed variable. Depending on the MV value, it invokes one of several procedures that install all of the required applications. This expands easily - create a new App Install - Group X procedure that installs a specific set of apps, add an If MV = X / executeProcedure(App Install - Group X) pair of commands to the agent init procedure. Its all auto-magic from that point on.
What's missing from every description of policy above is one of the most critical parts - the view to control the policy. A policy without a view will not apply to anything unless linked to a specific machine. This is an important point, and an excellent reason to possibly have some policies without views - they need to be deployed to specific and manually determined situations. Rare, but sometimes this is easier to accommodate the 2 per 1000 agent situation than creating the mechanism for view-based automation.
Policies are condition-driven, not action driven. When a view detects a condition, it can allow a policy to apply, which sets configurations, deploys monitoring, and schedules patching and procedures. In most cases, the condition causes the policy to apply permanently - "this is a workstation, so apply the default workstation patch settings". In some cases, what we refer to as "remediation" policies, the view detects a condition (outdated application), schedules a procedure to run and update the application. Once the app is updated, the view is no longer valid, and the policy is no longer applied. While this works fairly well, it isn't very efficient in terms of VSA administration, because SOMEBODY needs to keep the version views up to date or the views and policies they drive become worthless. Only two of our policy control Views use version controls, and this is for the Kaseya Agent Update procedure - we find that our procedure based agent updating runs much more quickly and effectively than the built-in feature.
Our core RMM Suite product uses New Agent detection to run an initialization process, which includes an audit that detects roles, features, services, and applications. It then runs a client-specific procedure (by detecting the customer ID) and deploys the AV and standard applications that they require. The entire onboarding process takes between 4 and 12 minutes per agent (depending on app install time) to complete with no manual actions. Once this completes, policies apply based on the conditions detected to configure patching, application updating, and deploy monitors.
BTW - linking policies to customer groups is a level of tedium we avoid. Of the 170 policies we have, about 120 are linked to the Org Root, and we have a small set - about 6 right now - linked to a few customer groups to override the default settings of the core policies. Most of the 50 policies that aren't linked are provided for special situations that might arise and are not currently used in our production environment.
Oh, and in a cruel twist of irony, New Agent Checkin is the one alarm that can't be configured by policy! :(
There is some good wisdom in your response gbarnas! Thank you.
salih_cb, you now have options to choose from. Find what works best for your environment.