Introduction
The Systems Management scripting engine is hugely powerful, allowing you to write and deliver your scripts (either as one-off jobs, recurring scheduled jobs, or monitors) to specifically targeted devices in your estate.
One of the facets of that engine is the ability to set “input variables” to a script, allowing you to re-use a single component to carry out multiple tasks without having to re-write code, or create (and maintain) cloned components.
This article is intended to take you through using those input variables, and outline how to refer to them in either batch or vbscript components.
Prerequisites
You will need to have a reasonable grasp of scripting concepts to make full use of this article, but it’s not too heavy going.
The worked example that we’re going to use to demonstrate the use of input variables is one that’s put together in article Creating Custom Components with Systems Management so it would probably be really useful to have read and understood that first.
What is an “Input Variable”?
An input variable is a way to allow you to define something in your script at runtime, rather than having it “hard coded” into the script itself. They allow you to use the same script to carry out different actions by just changing the variable, rather than the whole script.
For example, if you regularly had to restart a number of Windows services, you could create one component per service, like this:
or, more efficiently, you could write one “restart service” component, and pass the name of the service to be restarted when you run it. And that’s what input variables are for.
How do Input Variables work in Systems Management?
Systems Management, basically, creates Windows environment variables whenever a component executes which are set to the names and values of your input variables. You can then call these in your scripts just like you would do a “normal” environment variable (such as %computername%).
How do I create Input Variables?
Input variables are specified when you create your component. If you open up an existing component, you’ll see where to add them in the Variables section:
In the above screenshot, we’ve created an input variable called “FileName“, with a default value of ‘test.txt‘. So now when I set up a policy to use this monitor script, I am able to specify the value that this should be set to when it runs:
How do I refer to these environment variables in my script?
That depends what sort of script you are writing, so, in batch scripts, you just need to wrap the name of the variable you’re referencing in % signs:
In VBScript, its a little more complicated – you need to expand the environment variable, and set a ‘normal’ variable to that value:
And in PowerShell, they can be treated as child-items of a powershell drive called Env:
or, alternatively:
Worked Example
In this worked example, we are going to take the component we create in this article and modify it so that the drive, path and filename are no longer hard coded into the script – they will be variables.
– Open up the monitor component that’s checking for the file “test.txt“.
– Add 3 new input variables (one for the drive, one for the folder and one for the filename).
Notice that there are default values here, so if we run this monitor with no changes to the variables at all, it will check for C:\Test\Test.txt.
Modify the script to use these variables as described above instead of the explicit path:
Now recreate the policy that uses this monitor, and you’ll be able to specify the drive, path and filename on adding this component monitor – so with a single component you can alert on the existence of C:\Test\Test.txt, C:\Test\Check.xlsx and D:\Monitor\File.tmp.