PowerShell 2.0 - Community Technology Preview (CTP) 3 released

Microsoft recently released the third Community Technology Preview for PowerShell 2.0. Sporting a vast number of improvements, PowerShell 2.0 is shaping up to be a robust, reliable choice for administrators with enterprise-grade features critical in many organizations. Scott Lowe walks you through some of the highlights.

Although version 2.0 of Microsoft's PowerShell scripting language has not yet made it to the beta stage, Microsoft has released a third community technology preview of the shell. Designed to provide those interested a sneak peak as to what might make its way into the final release of version 2, it's important to note that a community technology preview is not a beta and features may come and go. Microsoft makes it very clear that CTP software is not in any way neither designed nor supported for production use and that CTP software may not even closely resemble final code. In short, don't build solutions on CTP software and then complain when it breaks later on!

What's coming in PowerShell 2.0?

PowerShell 2.0 is packed full of new features designed to make it a more powerful, easier to use scripting language than the initial 1.0 release. I'll discuss a few of the more significant enhancements here.

ISE

The most immediately noticeable addition to PowerShell 2.0 comes in the form of the Windows PowerShell Integrated Scripting Environment (ISE). ISE is a GUI-based PowerShell script development tool designed to make it much easier to create and modify PowerShell scripts. Although there are other free third party development solutions, such as Quest's PowerGUI, it's nice to see the PowerShell team working to tame the beast a bit.

Remoting

PowerShell 2.0 will also greatly enhance the ability for a PowerShell script to work against remote systems. In short, an administrator can, from his own workstation, issue PowerShell commands that are executed on remote stations, with the output being returned to the administrator's own screen. Of course, in order for remoting to work, the remote computer must have PowerShell installed. The beauty of remoting in PowerShell 2.0 is that the remote user doesn't see any visual representation that a PowerShell process is being executed, beyond the actual PowerShell process appearing in Task Manager. If user's did see screens start popping up on their desktops in the middle or a work day, imagine what would happen at the help desk when the phone started ringing!

Background jobs

If you take a deeper look at the remoting functionality in PowerShell 2.0, you'll understand that this new feature works because of PowerShell 2.0's ability to run jobs in the background, shielded from the user. Locally (or remotely, for that matter), administrators can create scripts that run in the background; that is, the script executes and the administrator is immediately returned to a new PowerShell prompt while processing continues in the background. Later, when time permits, the administrator can gather the results of the command for further action. The ability to run jobs in the background -- or asynchronously -- means that an administrator can keep working without constantly waiting for scripts to finish execution.

Transactions

PowerShell 2.0 also adds the ability to develop full transaction-based scripts complete with cmdlets for starting, committing, and rolling back a transaction in the event of an error or other condition. This capability starts to make PowerShell an attractive choice for even the most complex business processes as administrators can be more sure that scripts can return data to its original state if necessary.

Multiline comments

In PowerShell V1, comments that spanned lines were, quite frankly, a pain in the neck unless you used a tool like PowerGUI. Each comment line had to start with a # symbol. Failure to include one of the symbols meant a bad script. PowerShell 2.0 introduces the <# and #> script elements between which PowerShell script developers can embed as many comments across as many lines as they wish. While it doesn't sound like a major improvement, if you look at almost any serious programming or scripting language, they all have the ability to handle multiline comments.

New cmdlets, parameters, variables and operators

PowerShell 2.0 is the next major release of the language and, as such, includes a huge number of new cmdlets, new parameters for existing cmdlets, new permanent variables and some new operators, such as the -Split and -Join operators that allow the splitting or joining of strings based on certain characteristics. There are new cmdlets to support background jobs (Start-PSJob, Stop-PSJob, etc.), to support transactions (Start-PSTransaction, Undo-PSTransaction, etc.), and new cmdlets to support PowerShell 2.0's enhanced debugging capabilities (Set-PSBreakpoint, Get-PSBreakpoint, etc.) As I said, some existing cmdlets have also received new parameters. For example, the Stop-Process cmdlet now has a -force parameter. The Export-Csv cmdlet now sports a -Delimiter parameter so you can specify what character you want to use. While many of the new cmdlets and parameters are designed to support the new overall functionality in PowerShell, many enhancements also make PowerShell 2.0 a much more robust language overall.

Summary

PowerShell 2.0 has been in development for a long time and, with the third CTP under its belt, it's looking like a huge step in the right direction for this excellent scripting language.

—————————————————————————————————————

Have a topic idea or question you’d like me to address or answer in a future post? Email me directly right here at trfeedback@slowe.com.

About Scott Lowe

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

Full Bio

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at slowe@email.com.

I have worked with Powershell quite a bit, and I find it is a long overdue step, but still lacking in many ways over *nix bash-type environments.
In some ways it has been great, having the ability for background processes will be a bonus. I would have a dedicated machine utilize some powershell scripts that would poll various networking equipment and initiate a fail-over when it needed to.
Now on to transaction-based commands; This sounds in principal like a nice-to-have feature but thinking about it, its use should have descretion if used.
As an mcts in sql2005, I can think of all kinds of scenarios having this ability would be handy, especially on remote computers. One hang-up with this is timeouts. How long does it wait for a 'transaction'? In the SQL sense some transactions may hang out for hours or longer with a deadlock.
I haven't yet tried any of the CTPs of version 2, but I am now quite curious to. I will be trying the transaction example from MS here: http://www.microsoft.com/technet/scriptcenter/topics/winpsh/transactions.mspx
but hold it open, then try opening a second transaction-based command on the same registry key. With several administrators in an enterprise environment, this can easily becoming an auditing nightmare if not kept in check with change controls.

Scott -
Thanks for the heads up on this! Over the last few months, I started scratching the surface with PowerShell, and I like it a lot! I plan on really learning it in depth this year, something I never did with traditional batch files or Windows scripting.
Are there any good books that you would recommend for learning PowerShell?
Thanks!
J.Ja

I write a few scripts here and there and I really like PowerShell 1.0 (I have not used 2 yet, I'll wait until it's released).
PowerShell uses objects, which can be connected to each other which makes scripting easy. For example a basic VBscript that took me 20+ lines to write could be done in 4 lines in PS.
You can add Snapins that allow you to manage other systems. I use Quest for AD, MS Exchange and VMware snapins to manage those systems.
Some simple commands:
get-help
get-qadcomputer | where-object {-not $_.memberof}
This displays all computers in AD that are not a member of any computer group.
get-qaduser | select-object displayname
List all AD Users by DisplayName
Get-ADPermission UserName | export-csv ?path c:\FileName.txt
Get current mail permissions on a user and export to a file
I'm still learning and trying different things but I find it to be a POWERfulSHELL.

PowerShell is the up and coming standard for MS scripting. Exchange, SQL etc can all be managed with powershell.
I recently started trying to learn powershell in my free moments.
It looks to be much more powerful and flexible then VB. What jumped out at me right off was text filtering and reg ex.

PowerShell is indeed the future. More and more of the last two or so year's worth of management tools are really just PowerShell script generators. At this point, learning anything other than PowerShell is like becoming a Windows 3.1 guru in 1999.
J.Ja