Kaseya Community

Learning the Scripting Basics

  • I am not new to Kaseya, but definitely new to the scripting side of things.  How do techs learn this scripting language with all of its idiosyncrasies?  Is there a manual that specifically goes over the basics of the language?

    I am trying to figure out how to perform a go to step so I can tell the procedure to go back to a step and recheck for the service being installed.  Can someone give me a hint as to where to start on this?

    Thanks in advance.

  • The advice I give to all Kaseya partners is how I learned.  Downloading from an exchange as a reference and source of information helped me tremendously grasp concepts and leveraging the different languages and approaches.

  • Oscar,

    I understand your point, but that approach doesn't provide us with the following: basics for properly formatting a script, best practices for getting the most out of a script, what to do and not to do in your scripts, etc.  I am very surprised that this is not one of those subjects taught in the Kaseya University.  Learning from OJT is slow and not always the best way to teach new employees.

    I wish the education department could create courses on Scripting 101, 201, and 301 for example.  I am sure I am not the only one that would benefit from these courses being created for the masses.

  • I agree with trnetwork. Oscar, can you elaborate a bit more other than ".. Downloading from an exchange as a reference...". What is "an exchange"?

    To tag onto the previous comment, I want to know what is going on under the covers a little bit. For example: How can I properly craft a procedure that requires a reboot mid-stream so when the OS comes back, the procedure will pick up where it left off. To understand what is happening and how the "engine" works will help us make better decisions when creating procedures.

  • I knew zero about scripting when I started using Kaseya.  I needed references, anything really to help me understand how to even script commands.

    The formatting, syntax, and commenting, and module behavior came from spending time reading the documentation on scripting in the VSA and sharing my scripts with clients and colleagues alike.  I have even mimicked the commentary style of upstream (Ronny) to my own as well.

    In regards to how the engine works, I really believe the popular opinion is right on! We should offer this content on the university and I will make sure they see your feedback.  Comments like this help drive the evolution of education at kaseya.

  • You are absolutely right Oscar. The content should be on the university.

    How long did it take you to really like you master scripting? At least to fell confident about it ? I believe for most of us who are trying to embrace scripting fear that we would have to spend an enormous amount of time to understand the formatting, syntax, and commenting etc..

  • By Exchange he will be referring to Kaseya Automation Exchange (automationexchange.kaseya.com). If you haven't used it go and have a look. It's a place for people to share scripts etc. I have learnt a lot by taking these scripts and seeing how they work, then using parts of that in new scripts.

    For a mid-stream reboot: If you reboot a machine mid script, it will restart the script from the start after the reboot. So I see two ways:

    Build logic into your script so that it knows it has already been run and skip to the 2nd half of the script. You can do this by say placing a dummy text file, or registry key before you issue the reboot. Then as the first step in your script, run an IF statement to check for it and then proceed

    Eg, IF c:\temp\rebootforscript.txt does not exist

     <do first half of script>

    <create c:\temp\rebootforscript.txt>

    <issue reboot>


        <do second half of script>

        <delete C:\temp\rebootforscript.txt>

    (don't forget to cleanup that temp file)

    2nd option is to break the script into two scripts and schedule the second part

    <do first half of script>

    <schedule 2nd half procedure to run in 15 minutes>

    <issue reboot>

  • The biggest mistake that admins make when trying to write agent procedures (IMHO) is that they try to be "purists". Write everything using the VSA language! Problem is, its a procedural language, not a scripting language.

    The procedures excel at delivering content (even checking if it needs to be deployed first), then executing content via "executeShellCommand" and similar functions, then collecting the logs via GetFile.

    We deliver over 300 Agent Procedures with our RMM Suite, and most are less than 20 lines, including comments. I can think of just a few that have 50 or more lines, mostly because we need to set/validate many variables and deploy several files before we execute the actual payload.

    If you can script in VB, PowerShell, or even Batch, that's where you should focus your effort. Things like looping, branching, and complex If/Case logic are a snap there, but just don't exist in the procedure language.

    Our first release used Service Desk for automation, and the Alert Intake process alone took nearly 900 lines to digest the alerts. We moved the process into an external app and reduced that intake procedure to just 12 lines, and today, have eliminated the need for Service Desk for ticket automation entirely.


  • Do it the way you would do any other language ....

    Start by writing down what you want to do and set it out in plain English step by step (pseudo-code) ... Then start one line at a time translating it to a Kaseya function in the script ....

    At first it takes a long time because you are not sure what each thing does and if it will fit your pseudo-code or not, and there is not a function for everything within Kaseya either, and sometimes you find that your pseudo-code was not specific enough either ... Sometimes you have to drop to writing a Command Line step, or a PowerShell step, etc .... Which means even more to learn if you don't already know those as well ...

    Eventually the code comes together and you get faster as you learn the strengths and weaknesses of Kaseya as well .... Along with @gbarnas comments above and some trial and error, you'll get it !!!

  • ,  it is very difficult to really teach scripting.   It is best learned by doing.    Find a problem, then search the Automation Exchange, Kaseya Community, Upstream Powerpack, and our site ClubMSP.com to see if anyone has already done what you need.  Why re-invent the wheel, right?    Even if it is not exact, as has said, you learn by tearing apart an old script and seeing how it is done, changing a few things, and solving your issue.

    As has said,  Kaseya is really a procedural language.   When I teach scripting, I make it clear that the "heavy lifting" is going to be done with  PowerShell, VBScript, or shell commands.   Kaseya makes it easy to deploy those commands to thousands of machines, and gather the information back.

    If you have an specific questions, you can post them here, or PM me and I am happy to help.

  • @trnetwork ideally if you can give us an example of what you want to do it will help us be more specific also if it is already achievable in the MSP Builder Catalog of procedures it could save you time/money.

    I wrote a post on the forums a while back on starting scripting in Kaseya but I can't find at the moment so I will try and recreate it as a generic basic guide that anybody can use.

    What do you want to do;
    The first steps with any scripted automation task is to define what you want to do and this can range from;
    - Auditing
    - Install/Uninstall (Applications, Drivers and Printers)
    - Maintenance
    - Remediation

    Next is to try and figure out the core of what you want to do, for example you might need to perform a maintenance task of archiving and purging a log folder. This would require two parts archiving the log files and then deleting the log files.

    From the example you would then break up the two parts of archiving and purging into smaller task that you would later tie together into one script/procedure. Each part you would test separately and combine with your main script until it is complete.

    The following is just an opinion, the biggest mistake most people make when they script in Kaseya is when they blindly execute the task having no way to know if the task was successful or not and also allowing the procedure to be executed on agents that do not qualify. This could include the wrong OS/Platform or might not meet the basic requirements such as it is missing the Application, the files or the registry key required to perform the task.

    Ideally your procedure should be structured with a start a, middle and an end.

    The start should include;
    - Defining of Variables.
    - Testing the computer to see if it qualifies for the task you want to execute and if it does not, end the procedure and write to the procedure log the reason for skipping the task.

    The middle should include;
    - Executing the task and if possible generating some output like a log file to provide more detail including if the task was successful or if it failed.

     The end should include;
    - Verifying that the task executed and if it was successful or if it failed.
    - Collecting the required information.
    - Perform a cleanup if required
    - Update the Procedure log with task status and generate a synthetic procedure failure if it failed.

     Variables are very important in scripting and very important for automation, Kasey has a few different types of variables. The definitions in the help file might be better but I will try and cover the basics.:

    • (Procedure) Variables, these are defined inside your procedure and is only accessible inside your procedure.
    • Global Variables, they are defined inside a procedure and can be access by any other linked procedure.
    • Managed Variables, they are defined per machine group and are accessible by any agent procedure.

    You also get;

    • Custom Fields, which allows you to define variables per agent.
    • Database Views, these are similar to custom fields however they are predefined by the Kaseya VSA and the values are populated by Kaseya audits. You can find the complete list of these "Database Views" in the Kaseya Help file and here is also a link to some of the common ones I have mentioned in the forums; See Link!

    Note that Database Views can be very handy and it was something I wish I knew about when I first started and it was never covered in the boot camps.

    There are other variables in Kaseya but they normally aren't accessible from Agent Procedures unless you use more advanced methods so I won't cover those.

    Synthetic procedure failure;
    This is a method that can be used force a procedure to fail. You would use this in an if statement to verify if the task you executed failed and you would precede the fail command by writing to the log explaining why the procedure failed and then use GetVariable File, defining the File as ERROR and the variable name as ERROR so it is easy to spot in the logs. This also means you can see the failure state of the procedure after it is executed.

    32/64Bit Compatibility;
    Most first attempts at scripting with Kaseya's agent procedures will run into the problem where procedure are not working as expected because of compatibility with 32 bit and 64 bit systems.

    You will note that there are separate 64bit registry commands, the executeShell command also has a 32/64bit option.

    You can run both 32bit and 64bit commands in same agent procedure by using an If OS 64 bit statement, execute 64 bit command and use an Else to execute the 32 bit command.

    Using 3rd Party Scripting tools;
    As mentioned by others Kaseya's Procedures has many limitations that more advanced scripting languages don't have, creating loops being the most requested one. The solution for this is when you need to do something more advanced then you write it in a more advanced scripting or programming language and execute it via a Kaseya Agent Procedure.

    There are a few things that you have to keep in mind when you use 3rd Party scripting tools;
    - Versioning: Some scripting language engines have different versions and the older version will often fail to execute newer commands. This is often the issue people run into with PowerShell, so if your PS script is depended on a newer version you will have to make sure that you update and maintain the versioning of PowerShell on the endpoints you maintain.

    - Security: Leaving uncompiled 3rd party scripts behind and reusing them could allow others to steal your Intellectual Property or worse modify it to cause trouble. Also some customers and/or their security tools might not allow certain scripting tools to function on their systems.

    Advanced Scripting;
    Consider turning the tasks that you often use in your scripts into separate generic scripts that you can pass variables to and can call from new procedures that would require those tasks.

    Good examples of this are creating or extracting archives using a GNU app like 7Zip or installing MSI files. Making your agent procedure modular can be extremely useful and it means you don't have to rewrite the same code over and over in different procedures.

    [edited by: HardKnoX at 1:15 PM (GMT -7) on May 19, 2019]
  • There's also a Fundamentals of Programming course on our website, available to anyone with a login.

    The course is "GTS-1-FOP - Fundamentals of Programming".

    This has the short booklet that I used when teaching an Intro to Programming at a local Community College, and the PowerPoint presentations from the class.