Hey, Scripting Guy! Can I Use Windows PowerShell 1.0 Scripts on Windows PowerShell 2.0?
(Editor’s note: Portions of today’s Hey, Scripting Guy! Blog post are excerpted from the Microsoft Press book, Windows PowerShell 2.0 Best Practices by Ed Wilson which is now available for pre-order.)
Hey, Scripting Guy! I see that Windows PowerShell 2.0 has officially released now and is included in Windows 7 and Windows Server 2008 R2. When will it be available for down-level systems? Should I go to the trouble to upgrade those systems to Windows PowerShell 2.0?
— JS
Hello JS,
Microsoft Scripting Guy Ed Wilson here. It has been a lovely week in Charlotte, North Carolina, in the southern portion of the United States. The temperature has been around 70 degrees Fahrenheit with clear blue skies. I ordered a new desktop computer for the house so that I will have an additional Windows 7 computer to play with. Windows 7 officially launched last week. After several years of work by lots of people, it is gratifying to see the amount of good press among the reviewers for this operating system. I have been using Windows 7 for more than two years, and it has proven to be rock solid. There is much that I like about Windows 7, but the feature I am most excited about is Windows PowerShell 2.0. If you have Windows 7, you already have Windows PowerShell 2.0. If you are using a down-level operating system such as Windows Vista or Windows XP, you will need to download and install Windows PowerShell 2.0. You can obtain it from the Microsoft Connect site. There are separate packages for Windows Vista, Windows XP, and Windows Server 2003. The package for Windows Server 2008 and Windows Vista are the same. If the package says “Release Candidate,” it is not the final version and is not supported version. The final bits will be made available in about a month or so.
If you are talking about your personal computer, there may be little reason to not use Windows PowerShell 2.0. After all, it is a very small, free download from the Microsoft Download Center. But as we will see in a little bit, there are some dependencies that must be met, and it is the dependencies that may tilt the scale in one direction or the other.
Clearly the main reason to use Windows PowerShell 2.0 is for the new features. As we will see this week, there are some very compelling features available. At the top of that list is remoting. Perhaps second on the list of compelling features in Windows PowerShell 2.0 is the graphical scripting console, which is like a script editor and has been a top requested feature from the field since the earliest beta of Windows PowerShell 1.0. The requirement for this feature is the .NET Framework 3.5.
Compare to Windows PowerShell 1.0
If you are dreading learning a new version of Windows PowerShell because you just got comfortable with Windows PowerShell 1.0, you do not need to worry. You can use Windows PowerShell 2.0 in exactly the same manner as you were using Windows PowerShell 1.0, and the advantage will be better performance and fewer bugs. Gradually, you may wish to utilize some of the new features such as remoting, access to diagnostic logs, and some of the more advanced features such as modules to help you create more robust and powerful scripts.
100 percent backward compatible
A major design goal for Windows PowerShell 2.0 was that it would be 100 percent backward compatible. In other words, any script that was written for Windows PowerShell 1.0 would run on Windows PowerShell 2.0. Because we do not permit Windows PowerShell 2.0 and Windows PowerShell 1.0 to be installed on the same computer at the same time, we did not want to cripple a customer’s scripts upon upgrade.
There are three ways in which this backward compatibility was achieved. These are seen in the list below.
· No Windows PowerShell 1.0 cmdlets or commands were renamed.
· No changes to Windows PowerShell 1.0 parameters were permitted.
· The version tag was introduced.
Technically, the version tag existed in Windows PowerShell 1.0, and this is why you could use it in those scripts. However, before the introduction of Windows PowerShell 2.0, there was no need to use the version tag.
Using the version tag
To maintain compatibility with Windows PowerShell 1.0, you can use the version tag. Strictly speaking, the version tag is not a requirement to enable Windows PowerShell scripts to execute. As seen in the QueryEventLogForTimeErrors.ps1, a script that was written on a Windows PowerShell 2.0 computer, we do not use the version tag. However, this script does not use any new features from Windows PowerShell 2.0, and as a result it is a script that could run equally well on either Windows PowerShell 2.0 or Windows PowerShell 1.0.
QueryEventLogForTimeErrors.ps1
Get-EventLog -LogName system |
Where-Object { $_.timegenerated -ge [datetime]::today -AND $_.source -eq ‘w32time’ } |
Format-Table -Property TimeGenerated, entrytype, message -AutoSize –Wrap
As seen in the following image, the requested information is returned on a Windows PowerShell 1.0 computer and the script runs without errors. Any script that was written on a Windows PowerShell 1.0 computer will run on any computer that has Windows PowerShell 2.0 installed. However, only scripts that do not use new Windows PowerShell features when written on Windows PowerShell 2.0 will run on a Windows PowerShell 1.0 computer. To ensure compatibility, it is recommended that you use the version tag.
The above script is rather inefficient. The reason for this is because of the way the script operates. It gets all the events from the entire system event log, and passes them to the Where-Object cmdlet where the filtering takes place. On my laptop, this script takes nearly 12 seconds to run. We can do better than that by using one of the new parameters that was added to the Get-EventLog cmdlet—the source parameter. The revised script, which uses the new Windows PowerShell 2.0 features, is seen here.
QueryEventLogForTimeErrorsV2.ps1
#requires -version 2.0
Get-EventLog -LogName system -source w32time|
Where-Object { $_.timegenerated -ge [datetime]::today } |
Format-Table -Property TimeGenerated, entrytype, message -AutoSize –Wrap
There are actually two benefits to the revised script. The first benefit we see is the code is much simpler to understand. Now we have a single where clause, instead of the more complicated compound where clause. The second benefit is that the script completes in half the time on my laptop.
As mentioned earlier, the #requires –version 2.0 tag is not a requirement to enable using the new features of Windows PowerShell 2.0. If all your computers are running Windows PowerShell 2.0 and you will never share your scripts with another person, there is no real need to have the #requires –version 2.0 in your code.
The problem comes into play when a Windows PowerShell 2.0 script is run on a computer running Windows PowerShell 1.0. As seen in the following image, the error message can be a bit misleading:
From a troubleshooting perspective, an error that states that the source parameter cannot be found could be a bit confusing. Additionally, if the script is run on a computer with Windows PowerShell 2.0 installed on it, the script will run without generating any errors. This type of error could cause a network administrator or a help desk person to waste hours trying to duplicate the error and determine root cause for the problem. To prevent this, use the #requires –version 2.0 tag. When this tag is present, the script will still generate an error when run on a Windows PowerShell 1.0 computer; however, the error is more readable because it specifically tells the user that the script is being run on an incorrect version of Windows PowerShell. This error message is seen here:
As a best practice, I recommend setting the #requires –version 2.0 tag in any script that uses a feature from Windows PowerShell 2.0. If you are not certain whether the script you are writing uses a Windows PowerShell 2.0 feature, include the #requires –version 2.0 tag anyway. It does not cost anything, and it will save you a lot of troubleshooting work in the future.
JS, as you can see there is nothing to fear when working with Windows PowerShell 2.0. It will be a seamless transition. Join us tomorrow as we continue looking at Windows PowerShell 2.0.
If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, keep on scripting!
Ed Wilson and Craig Liebendorfer, Scripting Guys
Light
Dark
0 comments