VBScript vs. PowerShell

• Author
• Recent Posts

Justin Shin

I have been a Windows administrator for eight years and currently focus on Group Policy, backup, and IIS/Apache administration.

Latest posts by Justin Shin (see all)

• Password expiration email notification with PowerShell - Mon, Aug 26 2013
• WSUS basics and troubleshooting tips - Mon, Sep 24 2012
• FREE: SolarWinds Diagnostic Tool for the WSUS Agent - Fri, Jul 13 2012

VBScript is definitely fading, and PowerShell is rightfully gaining traction, but PowerShell’s learning curve and backwards compatibility issues will keep VBScript around a bit longer.

VBScript was once unquestionably the preferred scripting language of most systems administrators, offering them the ability to automate routine tasks and interact with Windows features like IIS, Active Directory, and Terminal Services. Using the Windows Scripting Host, VBScript performed tasks that the Windows shell (batch scripts) simply could not handle. Then, in 2006, Microsoft released an alternative to VBScript - and an extension to the basic shell - known as Windows PowerShell. Since then, VBScript has remained the same while PowerShell 2 has been released.

Of course it’s always nice to have more options. At the same time, the existence of two viable scripting languages poses some new questions for the budding admin. As we compare them head to head, let’s look a bit further into the benefits and drawbacks of each.

Functionality

Both VBScript and PowerShell offer similar feature sets. The difference between them is more about how they actually acheive those features, and in most cases, PowerShell takes the cake. VBScript utilizes COM components to access features while PowerShell is built on top of .NET, meaning that it utilizes the base classes and is capable of interacting with some applications (especially Microsoft ones) that cannot be manipulated via VBScript. In fact, the folks who developed Exchange 2007 actually built the entire management console using one-line PowerShell commands (called cmdlets) that do the dirty work for you behind the scenes. Because VBScript is now deprecated and does not respect .NET functionality, it is usually difficult or impossible to manage a .NET application like Exchange via VBScript.

Performance

Intuitively, one might think that PowerShell should blow VBScript out of the water in terms of performance given the fact that PowerShell is “integrated” with the kernel and VBScript relies on a COM interpreter. In reality, however, PowerShell and VBScript are roughly the same in terms of efficiency. We can speculate about why this would be the case - perhaps the added overhead of .NET roughly offsets the inefficiency of using COM components - but the bottom line here is that performance should not be a consideration when choosing between VBScript and PowerShell.

Compatibility/Deployment Readiness

The Windows Scripting Host dates back to Windows 98, so VBScript can be deployed to all of your Windows clients “out of the box.” On the other hand, PowerShell was released in 2006 and requires at least Windows XP. More importantly, it is not included in Windows distributions predating Windows Server 2008 and Windows 7, so you will need to deploy and install PowerShell on all of your XP, Vista, and Server 2003 hosts before you can get up and running with it. Perhaps you will want to use a VBScript to automate this process!

In many cases, PowerShell simply cannot perform all of its functions on pre-Windows Server 2008/Windows 7 systems. For example, the Active Directory module - an important one for most systems admins - requires Windows 7 and/or Windows Server 2008 R2. This can be a real deal-breaker if your architecture utilizes Windows Server 2003 or XP clients.

Learning Curve/Existing Scripts

For starters, we should be clear about one thing: VBScript is a scripting language. While PowerShell can be used for scripting, it is primarily meant to be a shell. So, if you are already familiar with a scripting language or Visual Basic, you might find VBScript quite easy to learn. If you are not a developer and have never used a scripting language before, you might find VBScript a bit harder to learn, but there are still resources and existing script libraries out there to help you get started on your first scripts.

Unless you are already familiar with the .NET base components, you will probably find PowerShell much more difficult to learn. This is not to say that PowerShell is not accessible - it’s just built on top of a larger framework and thus has a moderate learning curve attached.

Security

The Windows Scripting Host has gotten a bad rap over the years for being what Wikipedia terms a “vulnerability vector.” In years past VBScript could be executed through Internet Explorer and bad actors of all varieties would use VBScript to execute code at a high level of system privileges. PowerShell can use digital signatures (code signing) to prevent execution of malware, something that VBScript does not offer.

Brevity

PowerShell is, in most cases, simply shorter (but often less intelligible) than VBScript. Consider the simple task of renaming all files beginning with “CurrentLog” in their filename to “ArchiveLog:”

First, we have VBScript. We create filesystem objects to access, run a loop to catch the instances of what we are looking for, then use a function to split the filename string up and replace:

VBScript vs. PowerShell - VBScript example

Now, consider this PowerShell cmdlet. Assuming we have already navigated in the shell to the desired folder, we use this slick one-liner to rename the files:

VBScript vs. PowerShell - PowerShell example

As you can see, the VBScript example is perhaps more telegraphic, but there’s no debate as to which is shorter (and more elegant).

The Verdict

It’s somewhat telling that although VBScript has been in so-called “maintenance mode”- the final step before deprecation - systems administrators continue to use it today. Perhaps there is a laziness factor. I know that I have scripts in VBScript that I do not want to have to port to PowerShell. PowerShell, despite requiring far fewer lines of code, is far from intuitive. Plus, certain features in PowerShell require Windows 7 or Windows Server 2008 to even work at all.

The smart money is that PowerShell will be the Microsoft-platform automation language once Windows 7 and Server 2008 gain widespread use, and most would say that PowerShell has already become the scripting (and shell) language of choice in the Microsoft world. But, if PowerShell cannot play nicely with your existing architecture and needs, VBScript is still the way to go.