Simple PING test: VBScript vs PowerShell

As a preparation for my TechEd Asia 2008 session on Windows PowerShell, I've been trying to convert a few of my administrative scripts to demonstrate how easy tasks can be done using PowerShell. Here's one I just did: simple PING test. Here's a sample VBScript code that checks whether a PING test is successful or not. I call the VBScript and pass it a parameter which is the hostname or IP address of the computer I want to ping

VBScript:
strComputer=Wscript.Arguments.Item(0) 'parameter passed = hostname

wmiQuery = "Select * From Win32_PingStatus Where Address = '" & strComputer & "'"

Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set objPing = objWMIService.ExecQuery(wmiQuery)
For Each objStatus In objPing
If IsNull(objStatus.StatusCode) Or objStatus.Statuscode<>0 Then
Reachable = False 'if computer is unreacable, return false
Else
Reachable = True 'if computer is reachable, return true
End If
Next

Wscript.Echo Reachable

Here's the equivalent script using PowerShell

Param($hostname)
$ping = new-object System.Net.NetworkInformation.Ping
$Reply = $ping.Send($hostname)
$Reply.status

You can see how much easier it is to accomplish a simple task in PowerShell. It makes the life of an administrator much better, especially if you have to write scripts that automate repetitive tasks. I'll post more samples of the VBScript codes you've probably seen in this blog converted to PowerShell

So your PowerShell script won't run?

In case you're wondering why on earth your PowerShell scripts don't run, its because scripting in Windows PowerShell is not enabled by default. Imagine your custom .NET assemblies being blocked until such time you register them on your global assembly cache (GAC). This is to make sure you don't run just about any script on your system. This is normally referred to as the restricted execution policy. You'll probably encounter something like this if it's the first time you'll run a PowerShell script

You can find out more about execution policy in Windows PowerShell by typing Get-Help Set-ExecutionPolicy on your PowerShell command window. You should also make sure that you have permissions to run scripts on your machine. Check either your local or your domain security policy to be sure. Plus, unlike VBScript where you can just double-click and run, PowerShell scripts don't behave that way. You need to call PowerShell before running the script. This is to make sure you don't accidentally run the script by just double-clicking. It does make sense especially if your machine get's exploited by a virus or a worm.

TSQL Debugger is now on SQL Server 2008 RC0

I have long waited for this feature as I got used to Visual Studio's debugging feature where you can simply put a breakpoint beside a code line and hit the debug button. SQL Server Management Studio now has a Debug button together with the Execute button (except that in Visual Studio, your F5 key would be your Debug command whereas in SQL Server, that would be the Run/Execute command).

This will allow you to step over your code - whether it is calling a stored procedure or a TSQL script - and step thru it a line at a time or at one shot. You can even step thru nested calls, like calling a stored procedure that calls another stored procedure. It will open up a new tab displaying the codes for the procedure or function that you are calling from your TSQL code. I'm just glad it's already in RC0. Check out my video from BlogCastRepository.com on how this works

I'm going to TechEd Asia 2008

I've just confirmed my hotel booking for TechEd Asia 2008 and have already started working on my sessions. I will be doing 2 break out sessions - one on SQL Server 2005 disaster recovery and one on Windows PowerShell. Check out this blog regularly to find out more on what I will be covering for TechEd. There's definitely a thousand and one reasons to go so register now to enjoy the discounts.