VBS vs PoweShell for Logon Scripting

I can't seem to find many examples of PoweShell scripts on EE. MS seems to be pushing PS, do the members of EE think it is worth migrating scripts to PS.

It PS a better future environment or is VBS still the best way to go for the near term? Are there compelling reasons like powerful new features in PS to make it worth the switch?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

In my opinion, for logon scripts, given that they're relatively simple in their functionality, VBS and Powershell are much the same.  Of course they are different in syntax, but I actually find VBScript a bit simpler for these simple tasks.

In Powershell, you map a drive using:
New-PSDrive –Name "G" –PSProvider FileSystem –Root "\\server\share"

Open in new window

In VBScript, you use this:
Set objNetwork = CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "G:", "\\server\share"

Open in new window

I think Powershell is more suited to more administrative type scripts, that you run from an administrator console to retrieve information.  Powershell if a very efficient way of getting a job done with less code though, and is often less than half of the code of an equivalent VBScript, especially when working with files, active directory objects, and output formatting, as a lot of the operations are performed under hood behind single commands.

For me, I will definitely keep using VBScript for Logon tasks, probably until the Windows Script Host no longer ships with Windows

I've seen quite a large number of PS scripts here on EE in response to questions, though I have to admit many people are asking the same questions.  Another good resource if you're looking for existing scripts is the Technet Repository. There is a huge number of PS (and VBS) samples there.

I definitely see PS as the way of the future.  I was never a VB scripter (only ever modified a few existing scripts), but when I see VBScript equivalents of PS script, they're usually twice as long or more.  Some of the best new features in PS that I'm aware of are:
- its remoting capabilities, like running the same command on many remote machines in parallel
- the way it handles everything as objects, which helps with passing along information to different commands and formatting
- the reduction in amount of lines of code needed

With that said, I don't think there's much value in converting existing VBS to PS.  You may want to move forward with PS becoming your primary scripting language for new scripts, but that's different than converting existing resources.

I like what Ed Wilson had to say on the matter (quoted from https://borntolearn.mslearn.net/b/weblog/archive/2009/09/14/ed_2d00_wilson_2d00_on_2d00_translating_2d00_vbscript_2d00_to_2d00_windows_2d00_powershell).
I even wrote a series of Hey Scripting Guy! articles that talk about converting VBScript to Windows PowerShell (one such example is here).  But in all actuality, I have translated less than 1% of the more than 10,000 VBScripts I have written in my lifetime.

There are several reasons for not translating VBScript to Windows PowerShell:

    Waste of time. If the VBScript works, leave it alone.
    Better way of doing things. Many VBScripts wrestled with things such as opening files, retrieving property values of objects and writing output to the console. These types of tasks are nearly automatic in Windows PowerShell.
    There are too many new things to script using Windows PowerShell. Many things that were impossible to do using VBScript are now possible using Windows PowerShell. There is a seemingly endless list of new things to script. I simply do not have time to go back and translate VBScript code.

Reasons to translate VBScript to Windows PowerShell:

    You are just learning how to script, and would like to have an example to follow along with.
    You have a rather complicated COM based script, such as Word or Excel automation, that will not be significantly different when written in Windows PowerShell.
    You are in the process of phasing out VBScript from your network, and you need to quickly migrate your existing scripts.

Probably the biggest reason not to translate from VBScript to Windows PowerShell is because you will want to take advantage of the new features that Windows PowerShell offers. Often the difference between a 50 line VBScript and a Windows PowerShell script can be as many as 49 lines of code. You can save yourself an awful lot of work once you learn how to allow Windows PowerShell to do the work for you.

And another from him.
Great stuff footech. I like that mantra, it's similar to "if it ain't broke, don't fix it". I would re-iterate that, don't rewrite scripts, unless you want to use them as a good learning point, because you know what you should end up with.

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Yes, rewriting VB scripts can be used as a learning experience.  My approach in that case would be to determine the goals of the VB script, and it's intermediate goals, and then just apply PS techniques to accomplish those goals - rather than doing a line-by-line (or command-by-command) translation.  It's similar to how you might rewrite a script to optimize it - the first time writing a script you might use whatever you could find, then later on, with greater experience, you might examine what you wrote previously and see how you could accomplish the same goal in a much more efficient manner.

One other bit that I would put forward in support of knowing PowerShell is that many (and increasing in number) Microsoft (and even non-Microsoft) products are managed/configured through PS.
ElegantSolutionsAuthor Commented:
Footech provided the most thorough  answer with links.

Footech, could you provide a link to your favorite  Logon script example?
Though I appreciate the points, I think this should have been a split as Rob Sampson provided some good perspective too.

I really don't have any logon script examples to share.  Any scripts would be dependent on what you want to accomplish, which can vary widely.
Thanks footech, but I'm not concerned about "opinion" related questions like this, since every comment is generally useful.

@ES, first off, in terms of getting your Powershell scripts to run as logon scripts, read theses:

And as for an example, see this one that maps drives based on group membership:

Although I don't why the author chose to use NET USE in that example, that just shows the multiple ways of doing the same thing ;-)


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ElegantSolutionsAuthor Commented:
Yes, Rob Sampson's last post was Very useful so if the moderator would split the points with him, that would be proper.
ElegantSolutionsAuthor Commented:
I appreciate both the opinion and the factual links from both authors.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.