*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

In this article, I shall be discussing some guidelines on converting Application Manager [AM] scripts from the 1990’s technology to this decade.

I remember working with VBScript way back in 1998 was barely out of high school and was already battling my way in to the unknown with Chumbawamba [Tubthumping] on every radio station and Lethal Weapon 4 hitting the cinemas.

Just think about that a little while… Boy do I feel old!

VBScripts were necessary as they were so much more powerful and flexible than batch scripts when it came to automation. They were great as user logon scripts when Active Directory [AD] came along as this gave AD admins a more flexible method of drive/printer mapping. AD was inferior to Novell at this point when it came to mappings as Novell had its own engine to do a lot with very little effort.

[code lang="powershell"]
MAP DISPLAY ON

MAP ERRORS OFF

IF MemberOf Accounts THEN MAP G:=\\FileServer\Accounts

IF MemberOf UKSite THEN

MAP L:=\\FileServer\Location\UK

ELSE

MAP L:=\\FileServer\Location\Global

END

MAP S:=\\FileServer\Shared
[/code]

This is something that AppSense Environment Manager accomplishes by making user environment customisation easy and little to no knowledge of scripting languages that anybody should be able understand.

Anyway, I digress…

The world is moving away from VBScript as it is an aging technology and administrators are moving towards the .NET framework and PowerShell.

Scripting in PowerShell is much easier than VBScript and accomplishes near enough the same results. The big difference is the amount of coding required in VBScript, 10 lines of code may be required whereas, in PowerShell, the same results can be achieved using a single line using the built in and 3rd party cmdlets.

However, you may need to achieve results that cannot be accomplished using cmdlets and need custom functions in order to get access to certain sets of data or perform actions in APIs, etc.

This is where PowerShell gives further extensibility in that you can develop these functions using the underlying .NET framework. This in turn can lead the way to starting your journey in to C# development.

Application Manager [AM] has allowed functionality to use COM objects to interact with it using automation scripting. The scripts are often written in VBScript as the AM Product Guide contains examples written only in VBScript.

Although they are only given in VBScript, it is fairly straightforward to convert them to PowerShell scripts.

Once you have done the conversion, you can then wrap them in functions and create your own cmdlets.

Converting your Variables

Conversion of your variables from VBScript to PowerShell is a very easy process.

VBScript:

[code lang="powershell"]
Dim someVariable
[/code]

PowerShell:

[code lang="powershell"]
$someVariable = $null
[/code]

Setting up the variable in PowerShell this way makes it easier going forward as it basically creates a NULL PowerShell object, ready to take whatever is thrown at it. This is similar to how VBScript variables work.

If you cast it to a specific type then certain return types may fail. For example:

[code lang="powershell"]
[string]$someVariable = $null
[/code]

By doing this you are creating an empty string object. I have seen an issue very recently whereby if you call a method and try to “out” a value where the return type is a VARIANT then it will fail to populate the value, even if what is returned is a STRING value

By sending a NULL object it is parsed and returned successfully using a Reference Variable or “[ref]”.

Reference Variables are used to pass parameters in to functions but to use the direct reference of the variable so that a value can be set in another piece of code and then be used in the calling piece of code.

More information of this can be found in the following MSDN article:

There are times where you will need to setup (cast) the variable to a certain type but just be aware of this pitfall.

Setting up the COM Object

In VBScript you would set up the COM object and store it in a variable using the “CreateObject” function.

[code lang="powershell"]
Dim objConfiguration

Set objConfiguration = CreateObject("AM.Configuration.3")

Dim objConfigurationHelper

Set objConfigurationHelper = CreateObject("AM.ConfigurationHelper.1")
[/code]

This is no different in PowerShell in that you would set it up and store it in a variable. Where it differs is that you would build it in to a new object of type “ComObject”.

[code lang="powershell"]
$objConfiguration = New-Object -ComObject AM.Configuration.3

$objConfigurationHelper = New-Object -ComObject AM.ConfigurationHelper.1
[/code]

In VBScript, SET is only required when assigning an object to a variable.

To Bracket or not to Bracket

When analysing your VBScripts you will find that you have lines of code that are firing methods/functions and you will have some that have brackets [parentheses] surrounding the arguments and others that do not.

This is due to the nature of what they are. If they have a return value [reading XML file in to a value, for example], they are a function and require brackets. If they are simply firing an action [saving a configuration, for example] then you are calling a subroutine.

[code lang="powershell"]
$ConfigurationXml = objConfigurationHelper.LoadLocalConfiguration("C:\Config.aamp")

$objConfigurationHelper.SaveLocalConfiguration "C:\Config.aamp", Configuration.Xml
[/code]

Now, in PowerShell [or .NET framework, C#, etc.] this does not apply. All arguments enclosed in brackets when calling the function/method.

[code lang="powershell"]
$ConfigurationXml = $objConfigurationHelper.LoadLocalConfiguration("C:\Config.aamp")

$objConfigurationHelper.SaveLocalConfiguration("C:\Config.aamp", Configuration.Xml) [/code]

This change makes things easier for any new coders to come along and understand and makes the learning curve ever so slightly smaller.

Cleanup

In the examples in the AM Product Guide you will see instances of the following:

[code lang="powershell"]
Set ConfigurationHelper = Nothing

Set Configuration = Nothing
[/code]

In both VBScript and PowerShell this is not really needed unless you are going to reuse the object.

In most cases the scripts will do what they need to do and close. Any memory allocations will be cleaned up once the script process has closed down.

However, should you need to do this in PowerShell for the reason given, then simply set the variable as $null.

In Closing…

Following the general guidelines in this article should see you well on your way to successfully migrating your VBScripts to PowerShell.

Happy days!

You can find an example of this conversion process in this article on the AppSense Support Portal.

I hope that you have enjoyed the article and have found it informative and useful for helping to build your script library even further.