Skip to main content

.Net Classes within VBScript: Doing Randomness and Arrays the Easy Way

·2 mins

Back in 2007, the Microsoft Scripting Guys posted a article titled “Hey, Scripting Guy! Be Careful What You Say.” This article changed everything in the way I scripted because it should how simply you can access some .Net classes through COM callable wrappers. The two they focus on are “System.Random” and “System.Collections.ArrayList”.

Set objRandom = CreateObject("System.Random")
Set objArrList = CreateObject("System.Collections.ArrayList")

ArrayList
#

When scripting in AD, Exchange or even the desktop, I am consistently working with arrays. Adding items and sorting arrays always required custom functions, overly wordy statements or re-dimensioning. This made working with arrays cumbersome. Their example for sorting the non-.net way:

For i = (UBound(arrNames) - 1) to 0 Step -1
    For j= 0 to i
        If UCase(arrNames(j)) > 
          UCase(arrNames(j+1)) Then
            strHolder = arrNames(j+1)
            arrNames(j+1) = arrNames(j)
            arrNames(j) = strHolder
        End If
    Next
Next

Now, using System.Collections.ArrayList:

DataList.Sort()

You can find a complete list of available methods here: ArrayList Class.

Random
#

Random numbers are handy for several uses. I typically use them for part of a file name when outputting temp files. Another great use is for auto-generating computer names in a test lab or deployment scenario.

In VB though, this was cumbersome and I always had to look up the exact syntax. And, the syntax isn’t exactly intuitive.

Randomize
Wscript.Echo Int((100 - 1 + 1) * Rnd + 1)

With the System.Random class, this is a lot easier:

Set objRandom = CreateObject("System.Random")
Wscript.Echo objRandom.Next_2(1000000,9999999)

You can find a complete list of available methods here: Random Class.

Related

vbScript: Quickly determine architecture

I’ve been using a routine to determine 64-bit v 32-bit workstations for some time checking the registry for the PROCESSOR\_ARCHITECTURE in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment path. However, this was proving to be error prone. So, I just gave up that method altogether since all Windows x64 editions have a “%SystemDrive%Program Files (x86)” directory. This makes it just a quick and easy call the folderexists method of the filesystemobject. The only downside is that can’t be used remotely but since most of my scripts are used in local policies, this shouldn’t be an issue.

Installing Java via Script and Group Policy

Due to some software requirements, there was a need to get JRE 1.5.0_09 rolled out across our enterprise. The requirements were pretty straight forward: Only install on client operating systems (Windows 2000, Windows XP, Windows Vista and Windows 7) Detect the versions of Java installed. If 1.5.0_09 is installed, exit. If 1.5.0_08 or less was installed, install this version. If it has a newer version, do nothing. The best way of determining the Java versions is to look in %program files%. On 64-bit machines, this is “C:program files (x86)Java”. On 32-bit, this is “C:program filesJava”. The script accounts for this.

Part 1: Blocking Bad Hosts - Finding Them, Easily

While troubleshooting some issues on an OWA Front-End server, I went over to the security log to see if the authentication attempts were getting past this box. The problem I found was the log was so full of failed logon attempts it was difficult to filter out what I was looking for. In a twelve hour period, there were thousands of 529 events in the security log. Now, I know this is nothing new, but I found a few patterns. I manually exported the log to a CSV, parsed out all the source ip addresses and opened it up in Excel. What I found was that 98.7% of failed logon attempts were made by just four different ip addresses. (I recommend using MaxMind’s GeoIP Address Locator for help in determining where the source addresses are located.)