I recently had a chance to chat with Microsoft's Jeffrey Snover, partner architect, and Scott Ottaway, senior product manager, about Windows PowerShell. They first introduced me to PowerShell's primary features, which include
- A new scripting language. Designed for consistency and ease-of use, the PowerShell scripting language follows a verb-noun syntax (e.g., get-eventlog; stop-process) and uses a set of intuitive utilities (e.g., -sort, -list).
- A new command-line shell. PowerShell's interactive command-line shell works not only with the new PowerShell utilities but also existing Windows command-line utilities, such as Net Shell (netsh.exe). You can even run scripts written in different languages (e.g., .vbs and .bat scripts) from the command-line shell.
I had many questions, and Jeffrey and Scott took the time to answer them. Portions of our chat follow. Be sure to also check out the sidebar "PowerShell Resources," which includes resources that Jeffrey and Scott mention as well as some other PowerShell resources that Microsoft recommends.
Karen: You mention that having consistent syntax was an important goal when the PowerShell scripting language was being designed. Why is this consistency so important?
Scott: When we talked with customers, we found that inconsistency was one of the biggest blockers for not learning to use new tools. If you look at previous command-line tools in Windows, you'll find that we just don't have consistency. We weren't consistent within some command-line tools as they went from version to version. We also weren't consistent across various command-line tools, such as across Net Shell and WMIC. How you use WMIC to get WMI information at the command line is completely different from how you get WMI information in a VBScript script. In PowerShell, the commands that you use at the command line and the commands that you use in a script are one in the same. Jeffrey and the team did an excellent job in delivering on that goal. It took a while, but they delivered.
Jeffrey: When creating the PowerShell scripting language, one of our objectives was that if someone learns how to use PowerShell in one of our products such as Exchange Server 2007, it should be simple for that person to learn how to use PowerShell in another product that supports PowerShell. But being consistent can lead to some difficult conversations with product teams. For example, if I tell them that we use the verb Stop, they might say, "Well, Kill is more like what I want to do" or "Terminate is a little bit more precise." When users need to stop their scripts, they don't want to have to try to understand the difference between Stop, Kill, and Terminate. They just want to stop their scripts.
We're also trying to help admins strive for consistency. Like previous technologies, PowerShell has an SDK. Unlike previous technologies, PowerShell's SDK has very strong guidance about how to use it. Yes, you could use any arbitrary command, but don't. We're very prescriptive about how things should be done to provide consistency for admins. Here are the commands that you should specify. Here are the groupings and here are the names you should use.
Karen: You mention that PowerShell supports not only existing command-line utilities but also existing scripts written in other languages. Should admins use their existing scripts, or would it be more advantageous to rewrite them into PowerShell (.ps1) scripts?
Jeffrey: As a general rule, if you have a script that is doing what you need it to do, our recommendation is to leave it alone. If you need to make substantial changes to a script or it no longer meets your needs, then you have an opportunity to transform that script into a PowerShell script.
Karen: What do you think the learning curve is going to be for admins to learn PowerShell?
Jeffrey: It's a new environment with lots of elements of previous environments, so I expect it's going to take at least a couple of hours and for some people a couple of days, depending on how quickly they learn. But once you learn it, you'll know it forever. I think people will have an experience that's similar to the one I had learning DCL. When I first encountered DCL, which is the VMS command-line environment, I said, "Whoa, wait a second. This is not what I'm used to." I struggled with it until I finally said, "Hey, I'm just going to have to take a few hours to learn what it is." As it turns out, I learned DCL very quickly because I found that everything was completely consistent. Even though it's probably been over a decade since used it, if you put me in front of a VMS machine, I'd still be able to start typing commands and I'd pretty much get them correct because of DCL's consistency. We expect the same thing to happen with PowerShell.
Karen: Is Microsoft going to offer any PowerShell training?
Jeffrey: Microsoft doesn't currently offer formal training on PowerShell. But here are a number of books available. We have good documentation, such as a getting started guide and a primer. We have great online help in the product. And we have a very active newsgroup community and blogs.
Scott: We also have the TechNet Script Center, where we've been running scripting contests and new articles every week. There are lots of online Webcasts that provide demos on how to use PowerShell. On Channel 9, we even have a video that actually shows it working. And lots of user groups are starting to pop up in different countries.
Karen: You mention that it should be pretty easy for people to learn PowerShell. If people are completely new to scripting, would you recommend that they just concentrate on learning PowerShell and not any other scripting language, such as VBScript? Do you see PowerShell as a complement to or a replacement for VBScript?
Jeffrey: For those people who are already skilled in using VBScript, those languages will continue to be supported for quite some time. But VBScript is essentially feature complete. PowerShell is our new strategic direction. It is where we'll be investing all of our money and where most of our product support will be.
Scott: I have a little bit different take on that. If you're brand new to scripting, you're going to have to learn the basics, no matter what language you're learning. For example, you're going to have to learn what objects are and how to declare and close items. The initial learning curve is the same for VBScript, JScript, and PowerShell. After that point, I think it'll be easier to learn PowerShell because it has the WhatIf and Confirm utilities. With WhatIf and Confirm, people new to scripting can learn how to write a script without having any consequences—they can see what would happen without making any actual changes. PowerShell also has logging capabilities, so once they have the correct code, they can create a log and add the .ps1 extension to make it a script. Mastering the commands and the syntax in this learning environment will be much easier than trying to learn it from just a book or online examples. Because of PowerShell's consistency and integrated command-line shell and scripting language, you have a natural environment in which to explore what the PowerShell scripting language is like.
Jeffrey: Plus, PowerShell is perhaps an order of magnitude more powerful than VBScript. We rewrote one customer's 750-line VBScript program into a 15-line PowerShell script. PowerShell is a much more productive environment.
Scott: To be fair, I don't think that all scripts will see such a dramatic reduction in code, but there's almost always going to be some improvement. The bottom line is that PowerShell will never be worse than the existing code. And you're going to have functionality that you didn't have before, such as PowerShell's security features. PowerShell allows signed scripts and control over whether you're getting digital certificates to run scripts in your environment. These features are nice to have and not that hard to set up. Although you can create this type of functionality in VBScript, you have to write and maintain a lot of extra code. Because this functionality is built into PowerShell, it's much more user friendly. Another nice security feature is that, by default, PowerShell doesn't let you run scripts. To run scripts, you have to change the default settings. In large enterprises, admins can easily configure the security settings through Group Policy.
Jeffrey: The PowerShell project got started after Bill Gate's famous Trustworthy Computing memo, so everything was built with security first and foremost. There's a methodology we now employ for all software called the Security Development Life Cycle. Developers must go through training and follow a specified process. PowerShell is the only scripting language that has been developed using that methodology.
Karen: So are the stories about people finding PowerShell worms and other security holes greatly exaggerated?
Scott: Anyone who knows security knows the stories are nonsense. In one case, someone said you could write a PowerShell script that copies files—and if those files were bad files, then that would be a bad thing. Security people have looked at PowerShell, and we've come up smelling quite clean. If there are ever any problems, we're going to pay attention to them.
Jeffrey: The exploits weren't specific to PowerShell or Windows. They were taking advantage of naive users who were ignoring warnings that say something to the effect of "Hey, do you really want to run this?" Basically, those exploits can be ported to any scripting language.
Karen: We've talked about how PowerShell compares with VBScript and JScript. How does PowerShell compare with Perl?
Jeffrey: PowerShell is at least as programmatic as Perl, but PowerShell is far more interactive. Plus, if you take a look at a PowerShell script, it's very readable. With the verb-noun syntax, it reads like a sentence, so it's very self-documenting. Conversely, Perl is jokingly referred to as a "write only" language, which is to say that you might be able to write it, but you can never read it.
Karen: Is PowerShell usable across platforms?
Jeffrey: You can use PowerShell to support multiple Windows platforms through such technologies as WMI. For heterogeneous environments, one of our partners, /n software, fills that gap. This company has a free beta of .NET cmdlets for managing remote, heterogeneous environments.
Karen: Overall, do you think people are going to embrace PowerShell?
Scott: So far, we've had more than 330,000 downloads worldwide. As you probably know, Exchange Server 2007 uses PowerShell. What we've seen with the 500,000 beta users is that they almost overwhelming said that it’s a huge advantage having the PowerShell cmdlets available because they're able to automate every task in Exchange. We feel very confident that PowerShell will continue to have an upward trajectory in terms of adoption, especially by enterprise customers and people who understand the value of scripting systems administration tasks.
Jeffrey: A number of years ago, I studied the adoption of various technologies in this area to see what accelerated adoptions and what slowed adoptions. I discovered that some technologies were basically stagnant until there were books available. Once books were available, the adoption of those technologies took off. So, we worked very vigorously to have books available early on in PowerShell's life cycle. Andy Oakley's Monad book has been out for quite a while. Monad was the original project's name. Now there are quite a few books. One element that slowed adoptions was the lack of an IDE—an integrated development environment. So, we worked with companies such as SAPIEN Technologies and ScriptInternals. SAPIEN Technologies' PrimalScript 4.1 has great PowerShell support, and ScriptInternals' PowerShellIDE is a very nice looking GUI for PowerShell. And a member of our community produced PowerShell Analyzer, an IDE modeled after SQL Query Analyzer. Because PowerShell books and IDEs have been available early on, we're reaping the benefits in terms of high adoption rates and positive responses.
The response in the community has been overwhelming. If you read some of the blogs, people start out by saying things like, "I hereby declare my love for PowerShell" or "It's the greatest feature Windows has ever produced." It really strikes an emotional cord in people because it's the right tool solving the right problem in the right way.
We were also pleased to see that eWeek reviewed the product. They said that it was the most compelling new Windows feature that they had ever had the pleasure to review. As you can imagine, we were dancing when we heard that.
And companies have been successfully using PowerShell in production. MySpace.com, one of the prime destinations on the Internet, has been using PowerShell in production for about a year. They're managing thousands of IIS Web servers. At one point, they said they'd gone from managing 1,000 to 4,000 servers without adding any admins because they were able to automate their operations by using PowerShell. Tasks that used to take them 10 minutes are now taking them seconds to do. People who are using PowerShell in production are seeing dramatic transformations in their operations because of the automation afforded by PowerShell.
Karen: If you had to pick one favorite feature in PowerShell, what would it be?
Scott: I like the WhatIf utility because it's so helpful in learning all the commands. When you use this utility with a command, it tells you what it would have done but doesn't actually do it.
Jeffrey: PowerShell has a set of object utilities that you can use with XML, WMI, ADSI, .NET, COM, and other types of commands. They'll do sorting, filtering, formatting, conversion to XML, conversion to HTML, and other types of tasks.
PowerShell deals with all this complexity and masks it from users so that they don't have to think about it. The admin doesn't really care about the differences between WMI, ADSI, XML, COM, but in the old technologies, they had to because they had no choice. With PowerShell, users can concentrate on what they need to do and not have to worry about how to do it.
