Let Sleeping VBScript Scripts Lie

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, talks about when to replace a VBScript script and when not to. Microsoft Scripting Guy, Ed Wilson, is here. One of the really awesome things about the Microsoft Ignite conference in Chicago this year was the chance to talk to literally thousands of people who stopped by the Scripting Guys booth on the Expo floor. One of the things that surprised me was the number of people who apologized—actually apologized—for still running VBScript. They would say something like, “We still run lots of VBScript in our environment.” OK… Let me make this one thing perfectly clear, there is nothing wrong with running VBScript scripts. In fact, I would say that it is closer to the opposite. It is a good thing. The point of automation (no matter what the language) is to automate stuff. That is, to make things easier. Here are some reasons for running VBScript scripts:

  • If the script works, continue to use it.
    You gain nothing in terms of productivity by simply converting existing scripts into Windows PowerShell.
  • If the script uses an interface in a supported way, continue to use it.
    Hey, if a script is supported, it is supported. If there is nothing wrong with a script, there is no reason to replace it. It is a tool. It does a job, and as long as it continues to do that job, there is no reason to replace it.
  • If the script does not require modification, continue to use it.
    If the existing code meets your needs, there is no reason to replace it. But if it needs additional features, such as logging or error handling, you might begin to think about replacing it with a Windows PowerShell script.
  • If the script is effective, meets your needs, and does so in a safe and secure method, continue to use it.

You get the idea. If a script works, does not require maintenance, is safe, secure, and effective, there is no reason to replace the script. It is a misconception that Windows PowerShell is good and that everything else is bad. Sure, there are some Windows PowerShell fans. There are people who love Windows PowerShell, get Windows PowerShell tattoos on their arms, write Windows PowerShell songs, make Windows PowerShell T-shirts, stickers, hats, socks—even tennis shoes with the Windows PowerShell logo on it. I think that is great, but it is not necessary. In fact, I think it is a bad idea to waste time rewriting old scripts into new Windows PowerShell code. Let me repeat myself… It is a bad idea to waste time rewriting old scripts into new Windows PowerShell code. “Why?” you may ask. Well, let me tell you… First of all, we just agreed that the old script is safe, secure, effective, and does the job. That means it costs you absolutely nothing to continue to use the old script. So why waste time and resources to simply switch from old code to new code if there is no gain? I am talking about a direct swap. There may, in fact, be some legitimate reasons for writing Windows PowerShell code to replace an old script. Here are some reasons for doing so:

  • As a learning activity.
    One of the challenges in writing a script (in any language) is figuring out how to accomplish the task. If the old script does a particular task, it might be a useful learning activity to rewrite the old script into the new language. I did this when I was getting started with Monad. In fact, I have done something similar to this with every language I ever learned, from assembly language to C++. Later, as I learn the new language, I often figure out that the new language has features that make performing the activity much easier.
  • If the old script needs a major rewrite.
    If the old code no longer meets my current needs, and if a rewrite is required, it makes sense to do the rewrite in the new language. I find that I learn better when I have a specific task I want to accomplish. Sure, it might take more time to write it in a new language, but the learning opportunity should make it worthwhile. Eventually, you will begin to leverage the Windows PowerShell advantage, and routine tasks will take much less time than writing in other languages.
  • If there are security concerns.
    If you are doing things in your old language that are not safe, you should definitely switch to Windows PowerShell and take advantage of the built-in security features. Windows PowerShell was designed with security in mind, and it leverages all the great security work that was done in the .NET Framework, WinRM, and in Windows.

Windows PowerShell is powerful enough that there are always new things you can automate. The better you become using it, the more opportunities you will see. So, there is no need to duplicate existing functionality. In fact, as you learn Windows PowerShell, you will see that many times the approach that was required in VBScript is not the approach to take with Windows PowerShell. So, translating VBScript into Windows PowerShell is definitely a bad idea. If the old scripts work, leave them alone, and focus on the new cool things you can do with Windows PowerShell. That is all you need to know about taking time to rewrite your VBScript scripts into Windows PowerShell. Join me tomorrow when I will talk about more cool Windows PowerShell stuff. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy


Discussion is closed.

Feedback usabilla icon