PowerShell How-To

5 Reasons To Use VBScript Instead of PowerShell

When PowerShell just won't cut it, it's time to turn to the legacy scripting language.

• By Adam Bertram
• 03/19/2015

I'm a huge PowerShell fanboy. I actively blog about PowerShell, tweet about PowerShell, and present about PowerShell. I'm also the president of a local PowerShell users group. Needless to say, I no longer use VBScript for anything unless absolutely necessary. I'm telling you this because even a deranged fanboy like myself will still use VBScript occasionally. Why? Because -- believe it or not -- there are still some instances when it makes sense to use a legacy scripting language like VBScript.

I polled the Twittersphere a few weeks ago about instances when VBScript would still be used in place of PowerShell, and I got a lot of great responses. Here are five reasons why it might still be a good idea to use VBScript instead of PowerShell.

1. If It Ain't Broke, Don't Fix It
We're all busy and, if you're like me, you've probably got way more work to do than you'll ever think about finishing. There's always a new project coming up, or a fire to put out, and I know it's sometimes hard to keep up -- let alone refactoring old code that's still working fine. Some may argue that leaving old, legacy VBScript code out there will eventually make your job harder. I would agree to a point, but it's important to consider the time it would require to update all of that code.

Let's say you've got help desk tickets coming in at record speed and you're juggling three high-priority projects at once. Are you really going to take the time to go back to that VBScript you created three years ago -- the one that continues to chug along without issue -- and update it? If so, I'd recommend you start looking for a new job, because you're probably going to get fired for wasting time with your perfectly-working scripts.

Instead, make it a point to create all your future scripts with PowerShell. If you need to modify an old VBScript script -- and if it makes sense -- rewrite it in PowerShell at that time. However, I only recommend rewriting old VBScript scripts in PowerShell if an old VBScript is broken or needs modification.

2. To Manage Computers that Can't Run PowerShell
Unfortunately, we all can't be running the latest operating system on all of our servers and clients. Luckily, PowerShell is mature enough now that it can be run on operating systems more than 13 years old (XP and Server 2003). Yet, there are still companies out there with Windows Server 2000 installed on their servers and Windows 2000 on their client computers. Because PowerShell cannot be installed on these legacy systems, VBScript is a necessity. Granted, there are ways to still use PowerShell to do things remotely, but if you have a script that must be run locally on a legacy system, you're forced to use VBScript.

3. To Install PowerShell
PowerShell comes preinstalled on Windows 7 and above on clients and on Windows Server 2008 and above on servers. On Windows XP and Windows Server 2003, PowerShell will work, but it needs to be installed as part of the Windows Management Framework 2.0. PowerShell can be installed without VBScript, but I've found using a script gives you more control over the installation. My MCPMag article on How to Deploy PowerShell in an Enterprise Environment gives a great example of using VBScript to install PowerShell.

4. When Performance Is Critical and You've Got the Time
Jeffrey Snover -- the godfather of PowerShell -- said this in a great Stack Overflow reply: "If the machine does less work, then you have to do more work. If the machine does more work, you have to do less work." I couldn't agree more. VBScript is "lighter" than PowerShell. It utilizes less memory and is generally "faster" than PowerShell at doing the same tasks.  However, the time required to code a solution in VBScript is considerably higher than in PowerShell. Would you rather be overly concerned about the performance of a script -- and spend 10 times longer coding a solution in VBScript for a minor performance gain -- or would you rather spend less time coding a solution in PowerShell?

Most admins will probably answer that they'd rather save time coding in PowerShell. However, I realize this might not apply in every situation. Perhaps there are mission-critical, life-or-death situations where a solution must be as fast as possible, and it can't be coded in C or C++. Instead, it must use VBScript (I know I'm stretching here). In these instances, by all means, use VBScript. Just make sure your employer knows why you're spending so much time dealing with the nuances of VBScript!

5. Scripting Inside MSI Installers
Although this situation won't apply to the majority of people, it's still one worth mentioning. Admins in charge of packaging software sometimes utilize custom actions inside MSI files. These custom actions automate various installation functions that must happen when an MSI file is run. At this point, Microsoft has not allowed PowerShell to run inside of an MSI file, so admins are still forced to use VBScript.

PowerShell is the preferred method to script anything in Windows. As you can see, though, there are some niche instances when legacy VBScript script is still needed. Can you think of any other valid reasons why you would choose to use VBScript instead of PowerShell? And the answer, "Because I've always done it that way" doesn't count!