Kaseya Community

Where do I find Kaseya's built in variables?

This question is answered

Where do I find all the built in variable names, like #vagentconfiguration.Machine_GroupID#? Where does Kaseya list out all the availabe Kaseya variables?

Verified Answer
  • Check the help file, scroll down to Database views. That has everything you need :)

All Replies
  • Check the help file, scroll down to Database views. That has everything you need :)

  • Good to have a look through the help file for those, here is a list of ones I use or intend to use at some point;

    Agent Temp Dir/ Working Folder    (c:\Kits\Agent or c:\kworking)   

    • #vAgentConfiguration.AgentTempDir#


    Agent GUID  

    • #vAgentConfiguration.agentGuid#


    Contact Information configured against the Agent (In Kaseya portal: Agent > Configure Agents > Edit Profile)

    • #vAgentConfiguration.contactName#
    • #vAgentConfiguration.contactEmail#


    Network Information      

    • #vMachine.IpAddress#
    • #vMachine.SubnetMask#
    • #vMachine.DefaultGateway#
    • #vMachine.DnsServer1#
    • #vMachine.DnsServer2#
    • #vMachine.DnsServer3#
    • #vMachine.DnsServer4#
    • #vMachine.DhcpEnabled#
    • #vMachine.DhcpServer#
    • #vMachine.ConnectionGatewayIp#
    • #vMachine.MacAddr#
    • #vMachine.timezoneOffset#


    Machine Name       (%COMPUTERNAME%)

    • #vAgentConfiguration.machName#
    • #vMachine.machName#


    Machine+Group     (computername.sub-machinegroup.machinegroup)

    • #vAgentConfiguration.Machine_GroupID#


    Machine Group name (sub-machinegroup.machinegroup)

    • #vAgentConfiguration.groupName#


    Current Logged in User Account Name   

    • #vAgentConfiguration.currentUser#


    Last Logged in User Account Name

    • #vAgentConfiguration.lastLoginName#


    OS Version 

    • #vMachine.OsInfo#
    • #vMachine.MajorVersion#     (5 = XP/2003, 6 = Vista/7/2008)


    Domain Name (Domain or Workgroup name)

    • #vAgentConfiguration.workgroupDomainName#


    Domain Type

    • #vAgentConfiguration.workgroupDomainType#

    0 (or Null) = unknown
    1 = not joined to either
    2 = member of workgroup
    3 = member of domain
    4 = domain controller

    Patch managment

    • #vPatchConfiguration.FileSourceUNCPath#   - Patch File Source UNC Path
    • #vPatchConfiguration.FileSourceLocalPath#   - Patch File Source Local Path
    • #vPatchConfiguration.FileSourceMachineId#   - Patch File Source Machine Id
    • #vPatchConfiguration.RebootAction#      - Patch Reboot Action
    • #vPatchConfiguration.contactName#
    • #vPatchConfiguration.contactEmail#

     

  • Are there any other variables?  For example is there a variable for the Kaseya Administrator who executed the procedure?

  • There are things like this #adminDefaults.adminEmail# that will send an email to the K admin scheduling the procedure on another machine

    #adminDefaults.adminEmail# - Email address of the VSA user who scheduled the agent procedure.

    #adminDefaults.adminName# - Name of the VSA user who scheduled the agent procedure.

    #scriptIdTab.scriptName# - Name of the agent procedure.

  • Cool!!  Another question, is there a variable that will identify the parent procedure that scheduled the child procedure to run?

    If Procedure-1 scheduled Procedure-2 to run in 5 minutes, is there a variable for Procedure-2 to know the name of the parent procedure?  I am only looking as I have many "starting" procedures that call different "clean-up" procedures to run afterwards.

  • im not sure of that but you could create a variable within the parent script which is the script name and pass that to the child script. we do something like that

  • Damian, look into using the Universal Variable steps for this.



    [edited by: Ben at 4:32 PM (GMT -8) on 2-29-2012] .
  • Yes you can use universal Variables However I would strongly recommend you don’t

    The universal variable is a fantastic idea but until the User can specify the name of the universal Variable ( and therefore make it unique ) and there can be potentially an unlimited number of them. Then universal variables are FAR FAR to dangerous to use.

    In theory since you only have a limit of 3 of them then you can only make 3 procedures which can reference them. Any more than 3 CAN result in 2 or more completely unrelated scripts righting and reading to the same variable and accidentally retrieving the wrong info leading to disaster.

    So sure you can use universal variables but if you do you might regret it later



    [edited by: Michael Dixon (enfusion) at 5:00 PM (GMT -8) on 2-29-2012] l
  • Another option is to read the following Database View #vScriptLog.ScriptName# into a Agent Variable (E.G.: Get Variable Constant, Data:  #ScriptName.ScriptName# Variable name: ParentScriptName).

    And then you can use the #ParentScriptName# in the Sub Procedure to log the Parent Agent Procedure name

  • ok, so with all of these great suggestions I think the global variable should work... however it didnt.  I am still testing but just want to see if anyone has some additional ideas.  I am having the parent procedure get a random number using the #global:rand# variable.  However when the child procedures execute they are not able to see that there is any data for that variable...

  • The best thing would be to post a pic of the before and after procedures

    Global variables won't  be passed if the second procedure is scheduled to run some time in the future it has to be run immediately

  • I just figured out the same thing.  That is really, really annoying as I have 3 child scripts that all need the variable from the parent.  But the 3rd child needs to run last...  hmmmm...

  • If you want to schedule into the future the safest thing to do is to write the variable to a text file or possibly a managed variable and read it back later. if all scripts get run on the same box id probably write it to a text file  



    [edited by: Michael Dixon (enfusion) at 7:18 PM (GMT -8) on 2-29-2012] l
  • And... KA-POW!!! I beat the system!!   Since my parent procedure calls the 3 child procedures, and I need the 3 children to run one after the other (but don't want Parent running Child1, then child1 running child2...) I was able to accomplish everything by placing pauses in the parent procedure in between the "Execute Procedure Immediately" for each child, and it works beautifully!

    Michael, thanks for the help, the last part wouldn't help me.  The problem is that because I have a few child scripts that are called by different parent steps i need to make sure that they don't trip over each other if they happen to be running at the same time.  So when i create the text files to hold on to some variable i use a number variable added to the end (AcctName123456.txt, AcctDesc123456.txt, PWreset123456.txt).  This way the LAST procedure that runs gets rid of any remaining txt files left behind by deleting *123456.txt.

    Really at the end of the day, I should just pass everything into a global variable and not have these text files, but that makes troubleshooting a whole lot harder,

    In case anyone is interested this is the madness that I have finally accomplished:

    Parent Script: Create local admin account (on domain it creates a domain admin account)

    --- Child Script 1: Changes the "Description or Comment" of the account created (so that it doesn't say "Added by Kaseya")

    --- Child Script 2: Sets the password to never expire

    --- Child Script 3: Cleans up all of the txt files left behind by the previous 3 scripts

    I do it this way because we initially have 3 accounts that we need created on each machine:

    1 - Account that is used by Kaseya "Set Credential"

    2 - Account that is used for Replay Backups

    3 - Account that is actually used by our techs to login to a computer (when needed)

  • It's good to see you got everything working. What was the reason behind using so many scripts? I would have thought one script to do everything would suffice.