Kaseya Community

Variable Based on Triggering Machine Name

This question has suggested answer(s)

I want to run a procedure on a machine, which schedules another procedure on a different machine and I want to pass information from the original machine to the target.

My specific example is:

Linux update procedure starts on a linux Virtual Machine, one of the first steps is to schedule a procedure on the virtual host to immediately create a checkpoint. So at this point, the checkpoint procedure needs to be able to know the name of the linux server that needs a checkpoint, and that is where I am stuck.


All Replies
  • Obviously I could just make dedicated agent procedures with this kind of info coded in, but I was hoping to create a single, more flexible/reusable procedure.

  • I don't believe that it is possible. I wanted to do the same (again with a linux machine as the target) but it seems that the variables are only held on the machine running the procedure and cannot be passed across to another endpoint.

  • If you know the Agentguid of the 2nd machine then the 1st script can write a text file with the variable detail to the VSA directly to the vsashared folder. The 2nd script can then read the file content to get the variable data. By using the agentguid as the file name the second script on 2nd machine therefore knows which file to check as it will be its agentguid.
  • My best, mildly over complicated, thought so far is to use file creation and cross agent copying, to do something along the lines of; make a file on the VM that is named the VMs name, then transfer it to a folder on the host and schedule the checkpoint script there, then the checkpoint script checks the folder, reads the filename in and uses it for the checkpoint command, then deletes the file.

    I think too, since procedures run sequentially on each machine, this should work, even at some level of scale as written, because even if there is more than one file, there should be a number of run's scheduled that equals the number of files and each run cleans up the file it based its work on. So if a run reads the "wrong" file name because of timing, it will do the job, delete the file, and the next instance will run and process the other name and it should all happen in close enough timing that it doesn't matter. Though I could also use the same kind of process to send a snapshot creation confirmation file back to the VM if I wanted to go that far.

  • Hah! And here Paul and I are writing almost the same idea at the same time.  Good to know its not a crazy plan.

  • You may want to explore the use of the universal variables which are not agent or machine dependent but accessible by all agents in all procedures.

  • I would suggest a custom field for the Host Machine Name. You can populate this using a separate Agent Procedure that runs periodically. This is just useful information to have in Kaseya for your day-to-day technicians.

    Once you have that in a custom field, you can look up the agentGuid. You might need to build a custom query for that using SQL Read; I don't think you'll be able to do it using the SQL View option since the hostname probably won't exactly match the Machine ID in Kaseya, unless your Kaseya groups follow the FQDN of the machine's hostname.

    Once you have the agentGuid, it is easy to run a procedure on a different machine using the Execute Procedure command in the AP.