Hey, Scripting Guy! With the release of the Community Technology Preview (CTP) 3 for Windows PowerShell, some of our staff have gone ahead and updated their computers. I am now beginning to worry that I need to check the version of Windows PowerShell that is installed on a computer before I run a script. I have two questions, the first of which is obvious: How do I do this. The second question is this: What the heck is a CTP anyway?

- WS

Hi WS,

Let’s answer the second question first. What is a CTP? In the old days, when you were writing your computer program (probably poking holes in key punch cards—I still have some lying around), you would first analyze the requirements for the application, do some flow-charting to determine the inputs and the outputs, and then come up with a mock-up. After the customer gave you the go-ahead, you would develop a working prototype. We typically would refer to these things as an alpha. We could continue to refine the product, work on things, and as we were working on the code many times we would realize that things maybe were not working the way we had envisioned that they would work. After we had things working pretty well, we would again show it to the customer. This is a beta. Now we need to fix bugs. So we work real hard fixing the bugs. When we have things working well, we call that a release candidate. Sometimes we go through several release candidates before we actually release the product.

The problem with that approach was the long lead time between the pre-beta product, and the short lead time between the beta product and the released product. In other words, when a product hits beta, its features are pretty much set. So getting input from a customer during the beta phase is good for finding bugs, but it is bad for finding out if what you are making is actually what the customer wants. To resolve this situation, several groups at Microsoft came up with the idea of the community technology preview(CTP), which allows for earlier feedback from the community to the product group doing the coding. Windows PowerShell 1.0 went through a CTP, and it worked out great. Windows PowerShell 2.0 is once again going through a CTP, and many changes to the product have been directly attributed to feature requests coming from our customers. So you can think of a CTP as not being feature complete or bug free. You can think of a beta as pretty much being feature complete, but not bug free. A release candidate is feature complete, and mostly bug free. When working with a release candidate, what you see is pretty much what you will get when the software finally ships.

If you want to identify the version of Windows PowerShell that is running on your computer, you can read the RuntimeVersion value from the registry. This registry key is seen here:

One way to read from the registry is to use the registry provider from within Windows PowerShell and read a registry value as you might read a property from a file or a folder. To do this you need to use the HKLM PS drive—HKLM: in this case—and follow it with the path to the registry key, which is \SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine. You can then select the item property you are interested in, which is RunTimeVersion in this example. This is seen in this script:

$path = "HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine"
$psv = get-itemproperty -path $path
$psv.RunTimeVersion

People who are familiar with VBScript may wish to create the WshShell object and use the RegRead method. To do this we use the HKLM moniker as a shortcut to refer to the HKEY_LOCAL_MACHINE registry key. The HKLM moniker when used with the WshShell object is case sensitive.

We store the path to the Windows PowerShell configuration information in the $path variable. Next we use the New-Object cmdlet to create an instance of the WshShell object. This COM object has the program ID of Wscript.Shell. We store the returned object in the $wshShell variable. After we have the WshShell object, we use the RegRead method to read the registry key value, which we specify by placing the path and value name in an expanding string: “$path\RunTimeVersion”. This script is shown here:

$path = "HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine"
$WshShell = New-Object -ComObject Wscript.Shell
$WshShell.RegRead("$path\RunTimeVersion")

There may be times when you wish to use WMI to read the registry. To use WMI to read the registry, we need to use the stdRegProv WMI class. The stdRegProv WMI class has always been in the root\default WMI namespace. Beginning with Windows Vista, we also have an instance of the stdRegProv WMI class in the root\cimv2 (which incidentally really is the default namespace). What this means is that you can use the stdRegProv WMI class from either the root\default WMI namespace or from the root\cimv2 WMI namespace. It does not matter as it is the same WMI class. As a best practice, I recommend that you use the instance of the class from the root\default WMI namespace (as is done in the GetPsVersionWmi.Ps1 script below) to ensure compatibility with older versions of the Microsoft Windows operating system. WMI uses coded values to determine the registry tree (also known as a hive). These coded values are seen in the table just below. HKEY_DYN_DATA registry tree only exists on Windows 95 and Windows 98.

Table 1 WMI registry tree values

We use the value 2147483650 and assign it to the $HKLM variable. This value points the WMI query to the HKEY_LOCAL_MACHINE registry tree. We then assign the string software\Microsoft\PowerShell\1\PowerShellEngine to the variable $key. When using WMI to read the registry, the key is not preceded with a backslash.

We assign the registry property value we wish to read to the $value variable. Now we use the [wmiclass] type accelerator to obtain an instance of the stdRegProv WMI class. We specify the root\default WMI namespace to specify which version of the stdRegProv WMI class we wish to use. We could also have preceded the namespace with the name of a computer and read the registry from a remote computer. After we have created an instance of the stdregProv WMI class, we use the resulting System.Management.Managementclass to call the GetStringvalue method. The GetStringValue method takes three arguments: the registry key coded value, the registry subkey string, and the property name. Two values are returned by the method call. The first returned value is the returnvalue, which will indicate the success or the failure of the method call; the second is the svalue, which is the string value that was stored in the registry property. The complete GetPsVersionWmi.Ps1 script is seen here:

$hklm = 2147483650
$key = "SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine"
$value = "RunTimeVersion"
$wmi = [wmiclass]"root\default:stdRegProv"
($wmi.GetStringValue($hklm,$key,$value)).svalue

We can also use the .NET Framework classes to obtain information from the registry. To do this, we use the Microsoft.Win32.Registry .NET Framework class. We use the GetValue static method, which takes three parameters. The first parameter is the registry root and key name. The second parameter is the registry value you wish to read, and the last parameter is the default value of the registry key value. In the GetPsVersionNet.Ps1 script, we assign the HKEY_LOCAL_MACHINE string value to the $hklm variable. Next we assign the string representing the remainder of the registry path to the $key variable. The registry key property value we wish to retrieve is stored in the $value variable. We then use the [Microsoft.Win32.Registry] class and use the two colons to signify that we wish to use a static method and then use the GetValue method with the $hklm, $key, and $value parameters passed to it. The GetPsversionNet.ps1 script is seen here:

$hklm = "HKEY_LOCAL_MACHINE"
$key = "SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine"
$value = "RunTimeVersion"
[Microsoft.Win32.Registry]::GetValue("$hklm\$key",$value,$null)

Well, WS, as you have seen, to work with the registry there is a Windows PowerShell provider, a COM object, a WMI class, and a .NET Framework class. This plethora of methodologies is one of the big strengths of Windows PowerShell. It is also a significant source of confusion for people just learning Windows PowerShell. What is the best thing to use? If you are just making the transition from VBScript, use whatever is most comfortable to you.

I personally like using regread from the wshshell object. It is easy, fast, and makes sense. When I need to connect to a remote computer, I use WMI. I almost never use the .NET version. At times, however, I like the simplicity of using the Windows PowerShell provider. It makes it very easy to use. Stay tuned. We will be working with the registry all this week, and maybe by the end of the week you will find what works for you. See you tomorrow. Peace.

Hey, Scripting Guy! In a previous column, you told us a couple different ways to save Excel spreadsheets. In that column, you said that one of the things you could do with the SaveAs method was password-protect a spreadsheet. However, you didn’t show us an example of this. How can I use a script to password-protect a spreadsheet?

-- MC

Hey, MC. Well, as we hinted at in the previous column you mentioned, any time you call the SaveAs method you can include password-protection as an optional parameter. To demonstrate, here’s a script that creates a new worksheet, writes the current date and time in cell A1, and then saves the worksheet as C:\Scripts\Test.xls. On top of that, it password-protects the spreadsheet, giving it the password %reTG54w:

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1).Value = Now
objWorkbook.SaveAs "C:\Scripts\Test.xls",,"%reTG54w"
objExcel.Quit

If you’ve done any scripting with Microsoft Excel, this is about as simple a script as you’ll ever write. The only “gotcha” to be aware of occurs in this line of code, where you actually save the file and password-protect it:

objWorkbook.SaveAs "C:\Scripts\Test.xls",,"%reTG54w"

Admittedly, there’s nothing fancy about this line of code; you just have to make sure the password (%reTG54w) is the third parameter passed to the SaveAs method. The first parameter is, of course, the file name. The second parameter is the file format. Because we’re using the default format, we don’t need to set a value for the second parameter; however, we do need to include a placeholder for that parameter. That’s what the back-to-back commas (,,) are for: they simply indicate that the value for the second parameter would go here if we actually had a value for the second parameter. By including this placeholder, the password becomes the third parameter, which is exactly what we want.

After you run this script, try to open the file C:\Scripts\Test.xls; you’ll be prompted to enter the password before the file will actually be opened. Incidentally, this will happen even if you try opening the file using a script. (Sorry, but using a script won’t allow you to bypass the password protection.) But can’t you specify the password when you open the file? Of course you can; that’s what happens with this script:

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Open("C:\Scripts\Test.xls",,,,"%reTG54w")

Note that when opening a spreadsheet the password has to be the fifth parameter; thus we have the file name, three placeholders, and then the password. This can be a little confusing, to say the least, but here’s a rule of thumb: just put in one more comma than you have placeholders. In this example, we have three placeholders, so we insert four commas. If we had nine placeholders, we’d insert ten commas. And so on.

But what if you decide later on to remove the password? No problem: simply open the file and set the value of the Password property to an empty string. Here’s a script that does just that: it opens the spreadsheet, removes the password, and then uses the SaveAs method to re-save the file. After running this script, try to open this spreadsheet from within Windows Explorer; you should be able to do so without being prompted for a password.

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.DisplayAlerts = FALSE

Set objWorkbook = objExcel.Workbooks.Open("C:\Scripts\Test.xls",,,,"%reTG54w")
Set objWorksheet = objWorkbook.Worksheets(1)

objWorkbook.Password = ""

objWorkbook.SaveAs "C:\Scripts\Test.xls"
objExcel.Quit

What if you didn’t want to remove the password, but merely wanted to change it? In that case, just set the Password property to the new password rather than to an empty string. And before you ask, yes, we could have used the Save method here rather than SaveAs. We stuck with SaveAs simply to be consistent with the previous script. We’re also aware that “Consistency is the hobgoblin of little minds.” But, hey, what size minds would you expect the Scripting Guys to have?!?

Hey, Scripting Guy! I’m wondering if you can help me before I tear all my hair out. I’m trying to write a script using WMI that checks for a few core services such as antivirus, remote desktop software, and the like. The intention is to bolt this information onto another one of your (brilliant little) scripts I use to e-mail this information if certain things aren’t installed.

I’ve found a really convoluted script somewhere on the Internet that enumerates all services along with service users and a count of services at the end, but this is really overkill. I just want an “If exist” type script for a handful of services, which we can then run on all our PCs!

- RT

Hi RT,

The Scripting Guide talks about listing the status of services, and probably is the kind of script you were railing against. People sometimes make a big deal about Windows PowerShell "one liners," but you can certainly use a more compact syntax within VBScript as well. The thing is, no one ever did. I actually came up with this type of syntax when I was writing the Microsoft Press book, Microsoft Windows Scripting with WMI: Self-Paced Learning Guide. I also used it quite a bit when I was writing scripts for the Windows Vista Resource Kit (First Edition). In that book, I was interested in printing out the user name and the computer name. Because the script might be run remotely, I could not use any of the properties from the WshShell object. You can also use something such as this VBScript to solve your problem.