So Kaseya has a Monitor Alert category called "New Agent Installed", which is in the Monitor module. What's unfortunate is that this category is missing in the Policy Management module, so I can't use this as a trigger to do what i need to do, which is: I would love to trigger procedures to install some some software, adding a local group to workstations, etc. I know I can assign ONE procedure in the Monitor module for this, so this is a huge limitation unless i create one massive script to do everything i want to do in it, but I'd really like to keep the scripts separated for administrative reasons. And I would also love to use Policy Management so that our procedures and monitors aren't scattered all over the place as is Kaseya best practice. Anyone have thoughts on how do we pull this off? The real fix would be "add New Agent Installed as an Alert type in Policy Management, but that may take years, if at all.
I also don't want or need to run these procedures on agents already installed, only new agents. Support is stumped thus far, which is disappointing, so please don't tell me to open a ticket. :)
You can use Policy Management to schedule a script to run once from a Policy ... HOWEVER, it will run even on machines that you have already done this on manually, but it will only run the one time. From then on, any NEW machine that has this policy applied automatically (i.e. - it's assigned to a group and the machine becomes part of the group the policy will apply and the script will run one time.)
Another thought on this - You could also create a field in Kaseya and have the very last script you run write to the field (it could be almost anything but a logical field for ONBOARDED makes sense to us, with a default set to FALSE) You can then create a view (or views) based on this custom field. Subsequently using this field to run the scripts via a Policy in Group Policy that runs all your onboarding scripts. This would be a more elegant solution, and would prevent the scripts from running on any previous machines that they have been run on manually. You would only need to manually set all of the previous agents to show that field as TRUE before assigning the policy anywhere.
Unfortunately, you can only set the New Agent Installed alarm manually. We've been asking Kaseya to add this to Policies for years, so those years have already passed... :( We instruct our clients to: "select all, click the Replace option, set Alarm and clear everything else, then Apply". There's no need to be selective, so it takes like 4 seconds to maintain when new clients are added.
Our customers do use this, however, pretty effectively to automate agent onboarding. We use it to trigger an alarm. That alarm in turn triggers an automated agent-procedure response via our workflow engine. This configures the agent, downloads our tools, creates/updates local accounts, runs an audit, applies monitors, and then runs an onboarding application. This onboarding app has a list of Agent Procedures that the MSP wants to run (for all agents, then all servers/workstations) and then customization procedures that the specific client needs run (again - all agents and then all servers/workstations), with exceptions handled by client / component.
Our MSPs use this to fully automate new workstations builds, including software install, removal, and even joining their customer's domain. Our tool keeps track of which systems have already run the init, which steps were performed, and which onboarding procedures were run, so running it a second time either won't do anything or will only apply tasks that have been added to the process since the last time it ran. This onboarding app can even perform location-specific tasks if machine groups are set up for that. It's all managed by a single configuration file hosted on the VSA. No custom fields were harmed in the process, and the process runs only when an agent checks in the first time (unless you run it manually). You can also suppress the onboarding app if you're onboarding an unmanaged client, or that client won't be managed until onboarded at a later time.
I've kinda gotten around this by creating a view where the "First Checkin" timestamp is newer than a certain date/time. The Policy executes a procedure which then runs through a series of procedures that builds out a new machine. This process only occurs on each new machine that checks in.