Which to learn for administration: VBScript or VB.Net?

[Phoenix-IT]

Greetings! Been reading these forums for a while, but this is my first posting.

I'm getting a little overwhelmed at work by projects that involve a lot of administration tasks. I'm looking to automate and am trying to decide which language is best to learn; VB.Net or VBScript. I understand that VBScript is on it's way out. However, does VB.Net support all of the WMI & ASDI functionality that VBScript does?

Thanks Much!

[allen2]

I would choose vbscript. VB .NET is mostly to make projects and therefore not likely to automate simples tasks.

[Yzöwl]

Why not go for Monad, it is the successor to vbscript and is in many ways similar.

[RogueSpear]

For admin type scripts, I primarily use VBscript, but I also throw in a little AutoIt as well. You can use WMI with VB.NET though I find it to be more difficult than with VBscript and the functionality provided by ADSI is really built right into .NET 2.0 anyway.

Monad is fine, but it sure does take a little getting used to. Personally, I'm waiting for it to go final and then see what sort of complications others run into. Staying ahead of the technology curve sounds great in theory, but I prefer to stick with tried and true in a production environment.

If you happen to manage an Exchange 2003 server or plan on deploying Exchange 2007, Monad is practically mandatory for the good admin.

[CoffeeFiend]

.

Edited November 7, 2006 by crahak

[Phoenix-IT]

VBScript sucks. Big time. Even if you can stand the language itself, the features still suck (it's really a crappy language... just look at things like error handling or variable declaration!) I'd pick preatty much ANYTHING before that. The only reason why some people still use it for admin tasks (besides not knowing anything better) is it needs no runtime on the client PCs and they want to run the scripts on the client PC themselves (instead of running one script remotely that'll connect to client PCs and do its job - and not deal with .net fw deployment seemingly).

That's what I was wondering... Since WMI is accessable from the network, why can't the script/app run on the server and configure the client remotely? The thing is, I'd have no idea how to go about that.

Thanks for all your replies folks... You were a big help.

[CoffeeFiend]

.

Edited November 7, 2006 by crahak

[RogueSpear]

If you want to run a script on the PC locally and need elevated privledges, you can also assign the script to run as a startup script in group policy. The script will execute before the user is presented with a logon prompt and actually doesn't run as a traditional user, but using the local system account. I've been doing it this way for years and it works perfectly.

[CoffeeFiend]

.

Edited November 7, 2006 by crahak

[RogueSpear]

Whatever works.