Windows PowerShell Blog

Going to TechEd? Join Us to Build a Solution on Windows PowerShell 3.0

2012-05-09T16:39:42Z

To cap off TechEd North America this year we are going to host a half day Windows PowerShell scenario walkthrough.

The event will take place at the Rosen Center on Friday June 15 from 8am – noon. During this time we will collectively solve a problem from the ground up using many of the new features in Windows PowerShell 3.0 and Windows Server 2012.

Starting from base Windows Server 2012 images, we will walk you through:

Writing a PowerShell script workflow to perform Server deployments
Creating a constrained endpoint that hosts only the deployment workflow
Delegate a set of credentials for the workflow to use
Exposing the workflow and it's results through a RESTful webservice
Using Windows PowerShell Web Access to manage the workflow

You will need to bring your own laptop to follow along.

Our room has space to accommodate 40 people. If you are interested please send a note to us at powershellteam@hotmail.com

Thanks

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Running show-command for a cmdlet

2012-04-13T01:34:23Z

Problem: Figuring out a cmdlet from its syntax can be overwhelming, especially for people new to PowerShell.

PS C:\> get-command get-process -syntax

Get-Process [[-Name] <string[]>] [-ComputerName <string[]>] [-Module] [-FileVersionInfo] [<CommonParameters>]

Get-Process -Id <int[]> [-ComputerName <string[]>] [-Module] [-FileVersionInfo] [<CommonParameters>]

Get-Process -InputObject <Process[]> [-ComputerName <string[]>] [-Module] [-FileVersionInfo] [<CommonParameters>]

Get-command –syntax displays the syntax for the command. The top of get-help will also show this syntax information.

What are all those lines and braces?

If you know the answer, please skip this section.

There is one line per parameter set. The square braces around a parameter indicate the parameter is optional. Square braces around a parameter name, indicate the name is optional (which means the parameter is positional). Angle brackets indicate the parameter type.

A Parameter Set is a mutually exclusive set of parameters. Mutually exclusive means you can either get a process by name, or by id, but not by name and id at the same time. Each parameter set is a different way to interact with the cmdlet, almost like a different cmdlet with the same name.

Some can ask if the parameter sets are a necessary complication. The only way to achieve the same 3 ways to get a process without something like parameter sets would be to have 3 cmdlets like Get-ProcessByName, Get-ProcessById and Get-ProcessByInputObject. If we extend this idea to all cmdlets, Nouns would be on average larger, there would be several names to remember for each cmdlet, separate documentations would be necessary and they would have repeated content referring to what is common between the cmdlets, etc. In summary, Parameter Sets are a great way to solve a somewhat complex problem of different ways to call a cmdlet.

Despite all this greatness, all those braces and lines can be a bit overwhelming for people starting PowerShell and trying to understand a cmdlet (and even for some experts, at a first glance).

Solution: Show-Command is a new cmdlet in PowerShell V3 that displays a graphical user interface for a command with a simpler overview of a cmdlet.

PS C:\> Show-Command Get-Process

Each tab is one Parameter Set for Get-Process. Cmdlets with parameter sets have a default parameter set. In case of get-process the default parameter set is Name, so this is the tab selected by default. Selecting the other tabs will display the following results:

Notice that for Name, the Run button is enabled and for Id and InputObject, Run is disabled. This is because there is no mandatory parameter in the Name parameter set, so it is ready to run, even with no parameter values. The Id parameter in the Id parameter set is mandatory (needs a value). This is indicated by the * near the parameter name. The InputObject parameter in the InputObject parameter set is also mandatory.

It is a very simple GUI, but it achieved some nice results so far regarding the problem it set out to solve:

Initially, the parameters for only one parameter set are displayed (the default parameter set), reducing the information to be understood compared to the syntax.
The braces indicating optional parameters are replaced by the friendlier GUI language of * and enabled/disabled buttons.
The visual separation of the parameter set tabs is an excellent way to convey they are mutually exclusive.

Additional details:

In each parameter set tab, parameter names are displayed alphabetically, but mandatory parameters are listed first.

The command run will be placed in history, so if you use “Arrow Up” after running show-command, you can see/modify what was run.

The Common Parameters section displays Debug, ErrorAction and other parameters common to all cmdlets.

The Copy button will copy the cmdlet to be run to the clipboard.

Hovering over a parameter will display a tooltip with additional information about the parameter:

Microsoft Script Explorer for Windows PowerShell Beta 1 Now Available

2012-04-09T22:45:00Z

We are very excited to announce the availability of Microsoft Script Explorer for Windows PowerShell (Script Explorer) Beta 1. Script Explorer is an extension of the Windows PowerShell content and guidance experience, combining the vast amount of knowledge held in the community with resources that are available from Microsoft.

Script Explorer is integrated as an Add-On to Windows PowerShell Integrated Scripting Environment (ISE). With Script Explorer, you can:

· Discover information that is related to Windows PowerShell from across the community and Microsoft.

· Search seamlessly across repositories such as the Microsoft TechNet Script Center and PoshCode.org to locate samples that are relevant to you.

· Establish, grow, and search local file systems and corporate repositories.

Search across multiple repositories

Script Explorer enables a single search experience across multiple repositories, including local file system, network file share, PoshCode.org and the Microsoft Script Center, which allows you to locate script samples, snippets, and modules. You can filter search results, read reviews and comments, and seamlessly integrate script code into Windows PowerShell ISE or other script editors.

Community and Microsoft guidance in one place

Script Explorer combines the rich information from the community and the guidance that is available from Microsoft, which helps you realize more of the benefits of Windows PowerShell. Script Explorer brings together resources such as the Windows PowerShell Survival Guide and how-to guidance.

Build a trusted library of scripts for your company

Script Explorer makes it easy to build a library of scripts for personal use or to establish and grow a corporate library of trusted scripts, modules, and snippets.

As shown in the illustration, Script Explorer allows you to search for PowerShell scripts on your local computer, your local network and intranet, and online script repositories. You are shown available scripts organized by category, and you can search for scripts from local and trusted community repositories by applying filters based on focus areas. Script search results return information about script usage, code samples, and details about the scripts.

When you find the scripts you that you need, you can store the scripts locally and use them at a later time or you can insert/copy in the editor.

Script Explorer isn't just about scripts. It also allows you to find other Windows PowerShell information such as modules, script snippets and even allows you to view how-to guidance topics from Windows PowerShell cmdlets and community resources, such as TechNet Wiki pages, to help you get started using Windows PowerShell.

Free download now!

Get started today with this free download of Microsoft Script Explorer for Windows PowerShell Beta 1.

Extensibility

You can also extend Script Explorer to include your own repository by using the Script Explorer Repository SDK.

Support

For support, visit Script Explorer for Windows PowerShell at the Microsoft Script Center online forums.

Also visit the forum for the latest status on Script Explorer services, to ask questions, and to provide feedback about Script Explorer. If you currently host a public repository, and you would like to make it available through Script Explorer, please contact Microsoft Script Explorer Customer Support.

Additional information

Joshy Joseph [MSFT]
Program Manager
Windows Server Information Experience

Improved WMI experience in PowerShell 3.0

2012-04-04T08:21:38Z

There is a famous quote often attributed to Jeffrey Snover, “IT Pros love and hate WMI. They love it because there is so much great stuff there. They hate it because it is complex to use”. Not to our surprise, most of the IT Pros and developers we talked to agree with this.

This is going to change with Windows “8”. We listened to your feedback and have made heavy investment in this area. This blog post standards based management in Windows Server 8 by Jeffrey Snover and Wojtek Kozaczynski provides an excellent overview. I would like to highlight two important aspect of improved PS+WMI integration that Wojtek talked about..

- CIM Cmdlets: PowerShell cmdlets to manage Standard Compliant CIM capable systems. Now you can manage any CIM+WSMan compliant system using the same set of cmdlets shipping with PowerShell 3.0. Imagine managing a hardware device or a non-Windows server from PowerShell, just like you would manage Windows.

- CIM-Based Cmdlets: PowerShell cmdlets written as a CIM Provider. For many IT Pros, terms like CIM operations, namespace, associations seemed to be way too complex, and many of them get nightmare about not getting WQL right. We heard the shout loud and clear. We are giving WMI developer right infrastructure and API to write cmdlets in native code, complete with PS semantics like verbose, warning, whatif/confirm etc. Out of the box, Windows "8" ships with a large number of new cmdlets that have been implemented as a WMI provider.

Our goal in PowerShell 3.0 is to provide 'first-class' experience for WMI. In the next few weeks, we will take you through a deep dive providing details of these investments . Stay tuned.

- Osama Sajid

Program Manager, WMI

Schedule for the upcoming PowerShell Deep Dive and a few videos from Frankfurt

2012-03-25T23:50:45Z

We’ve got a great lineup of sessions and speakers scheduled for the upcoming PowerShell Deep Dive in San Diego, CA on April 30 – May 2! The schedule was recently published on The Experts Conference site, and is also listed below for convenience. Be sure to check out the TEC site for abstracts and speaker bios.

If you’re still thinking about registering, it is not too late. Just follow the instructions listed on this earlier blog post.

Here are a couple videos from last PowerShell Deep Dive in Frankfurt that Dmitry Sotnikov has recently posted on his blog:

James O’Neill and his PowerShell Profile (part of the Lightning round)
Tobias Weltner on Regular Expressions in 5 minutes (also part of the Lightninground)
Bruce Payette covers Windows PowerShell Workflows in PowerShell 3.0. CTP2

And now for the schedule:

Monday
Time	Session	Speaker
9:00 - 10:00am	PowerShell Deep Dive Keynote	Jeffrey Snover
10:00 - 10:30am	Break
10:30 - 11:05am	When old APIs save the day (pinvoke and native windows dlls)	Tome Tanasovski
11:10 - 11:45am	Proxy functions	Kirk Munro
11:45 - 1:00pm	Lunch
1:00 - 2:15pm	Using Splunk ResKit with PowerShell to revolutionize your script process	Brandon Shell
1:00 - 2:15pm		Brandon Shell
2:20 - 2:55pm	Lightning Round
3:00 - 3:45pm	Remoting in V3	Krishna Vutukuri
3:45 - 4:15pm	Break
4:15 - 5:30pm	New Hyper-V PowerShell Module in Windows Server 8	Adam Driscoll
4:15 - 5:30pm	New Hyper-V PowerShell Module in Windows Server 8	Adam Driscoll
5:30 - 6:30pm	Meet the experts	--
6:00 - 8:00pm	TEC Party	--

Tuesday
8:00 - 8:35am	Formatting in Windows PowerShell	Jim Truher
8:40 - 9:15am	PowerShell and WMI: a love story	Kirk Munro
9:15 - 9:45am	Break
9:45 - 11:00am	PowerShell as a Web Language	James Brundage
9:45 - 11:00am	PowerShell as a Web Language	James Brundage
11:15 - 11:50am	PowerShell V3 in Production	Steven Murawski
11:55 - 12:30pm	Lightning Round
12:30 - 1:45pm	Lunch
1:45 - 3:00pm	How Microsoft IT Uses PowerShell for Testing Automation and Deployment of FIM	Kinnon McDonell
1:45 - 3:00pm		Kinnon McDonell
3:15 - 3:50pm	Job Types in Windows PowerShell 3.0	Travis Jones
3:55 - 4:30pm	Creating a corporate PowerShell Module Repository	Tome Tanasovski
4:30 - 5:00pm	Break
5:00 - 6:00pm	BOF / Roundtable

Wednesday
8:00 - 8:35am	Cmdlets over Objects (CDXML)	Richard Siddaway
8:40 - 9:15am	Build your own remoting endpoint with PowerShell v3	Aleksandar Nikolic
9:15 - 9:45am	Break
9:45 - 11:00am	PowerShell Workflows and the Windows Workflow Foundation for the IT Pro	Steven Murawski
9:45 - 11:00am		Steven Murawski
11:15 - 12:50pm	Incorporating Microsoft Office into Windows PowerShell	Jeffrey Hicks
11:55 - 12:30pm	TBD	Bruce Payette
12:30 - 1:45pm	Lunch

See you there!

Travis Jones [MSFT]
Program Manager - Windows PowerShell
Microsoft Corporation

Troubleshooting Windows Management Framework 3.0 Beta Installation

2012-03-23T00:35:00Z

This blog post explains how to resolve problems that may occur when you install Windows Management Framework (WMF) 3.0 Beta. WMF 3.0 Beta includes Windows PowerShell 3.0 Beta. You can find the WMF 3.0 Beta installation package on the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=240290.

The WMF 3.0 package installation is blocked when one or more of the following prerequisites are not met:

The package must support the platform and operating system.
Prerequisites must be met.
The package must not be a duplicate.

When one or more of the conditions is not met, an error message, such as the following one, explains that the update does not apply to the system.

WMF 3.0 Beta is shipped in four different packages. Each package is designed for a different operating system and service pack and a specific architecture. The following table lists the WMF 3.0 Beta packages:

WMF 3.0 Package	Target OS
Windows6.1-KB2506143-x86.msu	Windows 7 SP1 Client (x86)
Windows6.1-KB2506143-x64.msu	Windows 7 SP1 Client (amd64), Windows 2008 R2 SP1
Windows6.0-KB2506146-x86.msu	Windows 2008 SP2 (x86)
Windows6.0-KB2506146-x64.msu	Windows 2008 SP2 (amd64)

WMF 3.0 Beta Validation:

If Windows PowerShell is installed on the computer, you can use the WMF3BetaPrerequisiteCheck.ps1script that is attached to this blog post to verify that WMF 3.0 Beta is installed.

Package applicability:

The installation of the package might fail for one of the following reasons:

Architecture:

WMF 3.0 Beta packages are applicable only to computers with x86 and x64 architectures. WMF 3.0 Beta package installation fails if you try to install an x86 version of the package on an x64 computer, or an x64 version on an x86 computer.

Operating system:

WMF 3.0 Beta package is applicable only to Windows 7 with Service Pack 1, Windows Server 2008 R2 with Service Pack 1, and Windows Server 2008 with Service Pack 2.The WMF 3.0 Beta package installation fails on all other operating systems.

Service pack:

WMF 3.0 Beta package installation fails when the target computer does not have the minimum required service packs installed. The minimum service pack requirements are as follows:

Windows 7, Windows Server 2008 R2: Service Pack 1
Windows Server 2008 : Service Pack 2

The following table summarizes the WMF 3.0 Beta package applicability

Windows	Windows6.1-KB2506143-x86.msu	Windows6.1-KB2506143-x64.msu	Windows6.0-KB2506146-x86.msu	Windows6.0-KB2506146-x64.msu
Windows 7 SP1 (x86)	Yes
Windows 7 SP1 (x64)		Yes
Windows Server 2008 R2 SP1 (x64)		Yes
Windows Server 2008 SP2 (x86)			Yes
Windows Server 2008 SP2 (x64)				Yes

Prerequisites:

The following items are required for WMF 3.0 Beta package installation:

Microsoft .NET Framework 4: Full Installation:

The Microsoft .NET Framework 4 full installation must be installed on the computer before installing WMF 3.0 Beta.
To verify that .NET 4 full installation is installed on the computer, use one of the following methods:

Check for the presence of the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. The key should contain the Install registry entry with a value of 1.
In Programs and Features in Control Panel, check for the presence of the “Microsoft .NET Framework 4 Extended” update.
To install Microsoft.NET Framework 4 Full installation, go to http://www.microsoft.com/download/en/details.aspx?id=17718.

Windows Management Framework 2.0 [WMF 2.0]:

If the computer is running Windows Server 2008 SP2, you need to install WMF 2.0 before installing WMF 3.0 Beta. WMF 2.0 is not required for any other operating systems. You can download WMF 2.0 from http://support.microsoft.com/kb/968930.
To verify that WMF 2.0 is installed on the computer, in Programs and Features in Control Panel, in Installed Updates, search for the Windows Management Framework Core (KB 968930) update.

Duplicate package installation:

If either the current version, on an earlier version of the WMF 3.0 Beta package is already installed on the computer, the WMF 3.0 Beta installation fails with the following error message: "Update for Windows (KB250614X) is already installed on this computer."

To fix this problem, use the following procedure:

On Windows 7 SP1 and Windows Server 2008 R2 SP1, use Programs and Features in Control Panel to uninstall update KB2506143. To find it, click View installed updates and then search for KB2506143.
On Windows Server 2008 SP2, use Programs and Features in Control Panel to uninstall update KB2506146. To find it, click View installed updates and then search for KB2506146.

To complete the installation, restart the computer.

Sharath Gopalappa [MSFT]
Software Design Engineer - Windows PowerShell
Microsoft Corporation

Scheduling Background Jobs in Windows PowerShell 3.0

2012-03-19T16:39:19Z

One of the most common phone calls that the support team gets for Windows PowerShell is "How do I use Task Scheduler to schedule Windows PowerShell scripts?". As an administrator, you need to have full control over when scripts run in your environment. Perhaps you need run a script only during a one-off maintenance window or maybe you want to schedule some routine maintenance on a server so that it runs at non-peak times. Although it was possible to use Task Scheduler to invoke scripts in Windows PowerShell 2.0, it was not trivial. What's more, you were responsible for writing code to store the detailed results of your script if you wanted to view them later.

In Windows PowerShell 2.0, we introduced background jobs, which let you run commands asynchronously in the background. This allows you to get the prompt back and continue running commands at the command line while the background job runs. In keeping with our sacred vow to respect your investment in learning Windows PowerShell by reusing concepts, we reused jobs in many places with Windows PowerShell 3.0. This blog post introduces just one example of this: job scheduling. This feature allows administrators to schedule background jobs for execution at a later time or according to a particular schedule with a set of cmdlets right out of the box. One of the most valuable features of scheduled jobs in Windows PowerShell 3.0 is that we'll even take care of storing the results and output of your job.

Where to find the Job Scheduling cmdlets

The Job Scheduling cmdlets are delivered in the PSScheduledJob module that is included in Windows PowerShell 3.0 Beta and in the Windows Management Framework 3.0 Beta.

There are 16 cmdlets in the PSScheduledJob module that allow you to work with Scheduled Jobs, the triggers that cause them to run, and some more advanced configuration. To see the cmdlets, type:

PS > Get-Command -Module PSScheduledJob | Sort-Object Noun, Verb

Capability Name ModuleName
---------- ---- ----------
Cmdlet Add-JobTrigger psscheduledjob
Cmdlet Disable-JobTrigger psscheduledjob
Cmdlet Enable-JobTrigger psscheduledjob
Cmdlet Get-JobTrigger psscheduledjob
Cmdlet New-JobTrigger psscheduledjob
Cmdlet Remove-JobTrigger psscheduledjob
Cmdlet Set-JobTrigger psscheduledjob
Cmdlet Disable-ScheduledJob psscheduledjob
Cmdlet Enable-ScheduledJob psscheduledjob
Cmdlet Get-ScheduledJob psscheduledjob
Cmdlet Register-ScheduledJob psscheduledjob
Cmdlet Set-ScheduledJob psscheduledjob
Cmdlet Unregister-ScheduledJob psscheduledjob
Cmdlet Get-ScheduledJobOption psscheduledjob
Cmdlet New-ScheduledJobOption psscheduledjob
Cmdlet Set-ScheduledJobOption psscheduledjob

Basics of the Job Scheduling Cmdlets:

The JobTrigger cmdlets let you determine when scheduled jobs actually run. You can schedule jobs to execute one time (now or at a later date), daily, weekly, when certain users log on, or when the system first boots up.

The ScheduledJob cmdlets allow you to create and configure scheduled jobs. You use these cmdlets to perform actions like registering, unregistering, enabling and disabling scheduled jobs on the computer.

The ScheduledJobOption cmdlets allow you to specify advanced settings for scheduled jobs. With these cmdlets, you can configure many of the settings you're already familiar with in Task Scheduler, such as idle conditions that must be met before the job starts. The default values for each scheduled job should be sufficient in most cases, but the flexibility is there.

An example:

Imagine that you are incredibly passionate about configuring your computers for optimal energy efficiency. You've written a few lines to take the output of Powercfg.exe /energy and extract only the items that represent the most severe infractions. You want to run this analysis every night for a certain period of time so you can understand which issues appear most frequently.

With just a few lines, we can schedule our script to run on the server every night as part of an "EnergyAnalysisJob".

PS > $trigger = New-JobTrigger -Daily -At 3am
PS > Register-ScheduledJob -Name EnergyAnalysisJob -Trigger $trigger -ScriptBlock
{
powercfg.exe -energy -xml -output C:\temp\energy.xml -duration 60 | Out-Null
$EnergyReport = [xml](get-content C:\temp\energy.xml)
$namespace = @{ ns = "http://schemas.microsoft.com/energy/2007" }
$xPath = "//ns:EnergyReport/ns:Troubleshooter/ns:AnalysisLog/ns:LogEntry[ns:Severity = 'Error']"
$EnergyErrors = $EnergyReport | Select-Xml -XPath $xPath -Namespace $namespace
$EnergyErrors.Node | select Name, Description
}

Id Name JobTriggers Command Enabled
-- ---- ----------- ------- -------
1 EnergyAnalys... {1} ... True

If you've ever used the Start-Job cmdlet, the syntax of Register-ScheduledJob will look very familiar to you.

You can view the jobs that you have scheduled at any time by using the Get-ScheduledJob cmdlet. Scheduled Jobs are stored on a per-user basis, so Get-Scheduled job will only show the scheduled jobs that are relevant to you.

Windows PowerShell 3.0 keeps track of the results and output of scheduled jobs for you. If you come back to the server that runs the scheduled job a couple of days later, you can use the Job cmdlets (the same ones that you use to manage background jobs) to view and get the results of the EnergyAnalysisJob scheduled job. The nice thing about scheduled job results is that they are available even in different sessions! Since you are not always around to receive results when a scheduled job runs, we store them on disk so you can receive them at any time.

Here's an important "gotcha" that you should know. To get the results of scheduled jobs, you must import the PSScheduledJob module into the current session (Import-Module PSScheduledJob). Otherwise, the Job cmdlets, such as Get-Job and Receive-Job, do not return results for scheduled jobs. This is a bit of an exception to the module auto-loading behavior in Windows PowerShell 3.0. The reason is that Get-Job is in the Microsoft.PowerShell.Core snap-in, so using it doesn't automatically import the PSScheduledJob module. Also, if Get-Job were to automatically import all of the modules that implement custom job types, over time, the output would be crowded with irrelevant job types and performance might be affected by importing dozens of modules that aren't needed.

PS > Import-Module PSScheduledJob

With the PSScheduledJob module imported, Get-Job shows the results of "instances" of our scheduled jobs.

PS > Get-Job

Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
2 EventCollect... Completed True localhost ...
4 EnergyAnalys... Completed True localhost ...
6 EnergyAnalys... Completed True localhost ...

Scheduled jobs have BeginTime and EndTime properties that tell when the job instance actually ran.

PS > Get-Job EnergyAnalysis | Select-Object Name,BeginTime,EndTime

Name BeginTime EndTime
---- ----------- ---------
EnergyAnalysisJob 3/12/2012 3:00:01 AM 3/12/2012 3:01:12 AM
EnergyAnalysisJob 3/13/2012 3:00:01 AM 3/13/2012 3:01:14 AM

To get the results of a scheduled job instance, use the Receive-Job cmdlet.

PS > Receive-Job -Name EnergyAnalysisJob

# Results will vary based on your system's configuration, but you will see records like:
Name : USB Device not Entering Selective Suspend
Description : This device did not enter the USB Selective Suspend state. Processor power management may be prevented when this USB device is not in the Selective Suspend state. Note that this issue will not prevent the system from sleeping.

By default, Windows PowerShell keeps the results of the last 32 instances of each scheduled job. After 32 results are stored for a particular scheduled job, the oldest ones are overwritten by subsequent executions. To change the number of results saved for each scheduled job, use the MaxResultCount parameter of the Set-ScheduledJob cmdlet.

PS > Get-ScheduledJob -Name EnergyAnalysisJob | Set-ScheduledJob -MaxResultCount 100

Lastly, if you want to start a scheduled job manually rather than waiting for its triggers, you can use the DefinitionName parameter of the Start-Job cmdlet.

PS > Start-Job -DefinitionName EnergyAnalysisJob

As you can see, working with scheduled jobs in Windows PowerShell 3.0 is a lot like working with regular background jobs, but with much more control. We hope you enjoy the flexibility and simplicity of this cool new feature.

Travis Jones [MSFT]
Program Manager - Windows PowerShell
Microsoft Corporation

When Windows PowerShell Met Workflow

2012-03-17T03:08:19Z

Meet the new kid on the block! Windows PowerShell Workflow (PSWF) is the latest addition to the Windows PowerShell family.

First, let’s establish the context for the decision to integrate workflows into Windows PowerShell. It starts with cloud computing and Windows-based datacenters. Cloud computing provides a set of highly available, scalable computing services that leverage high volume components (servers, disks, RAM, etc.) High volume components are less reliable than their tier 1 counterparts and even those occasionally fail. The key to cloud computing is to use software to deliver a reliable service in spite of failures. Cloud computing management needs to be reliable in spite of failures. This is where workflows come in. Workflows are typically long-running scripts that are designed to survive component or network errors and reboots.

Automation is the heart of creating and running private and public clouds at scale. By automating administration tasks and operations, you decrease cost and improve repeatability, quality, auditing and logging. This allows you to increase your server-to-admin ratio, take on more business and increase the value of your employees by freeing them up to deliver higher value functions. As an example, Erin Chapple explains:

“Server Manager accomplishes this by leveraging the multi-machine management capabilities of WMI, Windows PowerShell and Windows PowerShell’s new workflow capabilities. Virtually every operation done using Server Manager can also be done via Windows PowerShell”.

While building Windows PowerShell Workflow, we took advantage of the scalability and maturity of Windows Workflow Foundation 4.0 (WF) to bring the benefits of workflows -- long running capability and reliability -- to scripters and the Windows PowerShell ecosystem.

In one sentence, Windows PowerShell Workflow is all about:

Reliably executing long-running tasks across multiple computers, devices or IT processes

Until Windows PowerShell 3.0, the approach to solving this problem has been to combine Windows PowerShell and Windows Workflow Foundation with proprietary implementations. As part of our planning process, we talked to many customers and found many cloud providers and hosters who took WF and Windows PowerShell and put them together. Hundreds of design decisions need to be made during that process so the workflows for any implementation did not work with other solutions. We wanted to deliver the definitive integration of these two technologies in a way that could be used out-of-the box or as a reusable library in a third-party solution. For example, we have designed our implementation with extension points that allow applications to host our engine in a fault tolerant, scale out configuration with detailed auditing. The goal is for the community to write workflows that work with our in-box solution and then light up without modification in third-party solutions.

In Windows 8, we introduce Windows PowerShell Workflow with two key goals:

- Minimizing the complexity of automating across a large number of cloud or datacenter computers and devices.

- Creating an ecosystem where ISVs and partners can build solutions on top of Windows PowerShell Workflow and the artifacts can be shared with the community and used in any solution.

To achieve these goals, we decided to invest in the following areas for our first PSWF release:

- Simplified workflow authoring

- Leverage your existing knowledge

- Reliable workflow execution

- Performance and Scalability

Simplified Workflow Authoring

Windows PowerShell Workflow enables IT professionals and developers to author sequences of activities that are long-running, repeatable, frequent, parallelizable, interruptible, suspendable, and/or restartable as workflows.

A workflow is a set of activities. An activity is an individual step within a workflow that performs a defined task, such as getting the list of virtual machines in a host computer.

Leverage Your Existing Knowledge

We designed PSWF with our sacred vow in mind:

We respect your investment in learning Windows PowerShell by reusing concepts over and over to make sure learning Windows PowerShell was the best thing you ever did.

This is very important to us: making the most of your time and leveraging the investment you have already made in Windows PowerShell instead of asking you to learn a whole new language for authoring workflows. We care deeply about your ROI, so instead of creating new workflow abstractions, we used and built Windows PowerShell abstractions with workflow semantics.

At the same time, we want to work within the existing Windows Workflow Foundation ecosystem. This is why you have two options for writing a Windows PowerShell workflow:

- PowerShell script-based workflow: If you know how to write PowerShell scripts, you can reuse your assets and skills and learn a few new constructs to create workflows. For instance:

workflow

inlinescript { }

foreach –parallel

parallel { }

sequence { }

- XAML: If you have used WF or have existing XAML workflows from the community, your XAML workflows will still work in the PSWF world.

We will analyze these new constructs in the upcoming workflow posts to help you get started quickly.

Reliable Workflow Execution

Windows PowerShell Workflow helps you orchestrate the reliable execution of management workflows across multiple computers that target Windows and standard supporting devices in an IT environment.

To help increase the reliability and robustness of your workflows, we provide the following workflow features:

- Checkpoint-Workflow activity

- PSPersist parameter

- $PSPersistPreference variable

- Suspend-Workflow activity

Performance and Scalability

In addition to the areas above, we also invested heavily in improving the performance and scalability of the PSWF engine. Using PSWF, you can scale out workflow execution to thousands of managed nodes. The core investments that helped make this a reality are:

- Parallel Task Execution (parallel, foreach -parallel)

- Workflow Throttling

- Connection Throttling

- Connection Pooling

- Integration with the Disconnected Sessions feature

- PSWF Extensibility API

A set of future blog posts will analyze each of the investments above in detail.

Setup and Down-Level Support

Some of the questions we received after introducing this feature set and the investments above to our awesome Windows PowerShell MVPs were: “How do I install PSWF?” and “Can I use this feature set in down-level machines?” The good news is that Windows PowerShell Workflow ships as part of Windows PowerShell 3.0, which means that it is available wherever Windows PowerShell is installed. This includes the Server Core installation option, in which Windows PowerShell is available out of the box starting in Windows 8. PSWF is even available for down-level installations of Windows Server 2008 R2, Windows Server 2008 and Windows 7 via the Windows Management Framework 3.0 (Beta Release).

To Workflow or To Script… That is the Question

This post covered some of the common questions but the top five would not be complete without the following:

When should I write a PowerShell workflow vs. a script?

This question requires deeper analysis so we will answer it fully in a separate article. However, here are the basic reasons for writing a workflow so we help you start thinking about this.

For “Reliably executing long running tasks across multiple computers, devices or IT processes” you will typically need:

- Robustness (persistence, suspension and resumption capabilities, tracked execution)

- Enhanced PowerShell assets and skills (built-in library of management tasks, built-in parameters for multi-machine management, authoring workflows as scripts, workflow management through job cmdlets or APIs)

- Scalability and Reliability (parallel execution, connection and action retry, etc.)

If you need the above, you may want to consider writing a workflow instead of a regular script. More of this in an upcoming episode of Workflow awesomeness…

Show me the Money!

I know, I know, you can’t wait to get started! J Here is one of the most basic workflows you can write:

Now… How do you find it? How do you run it? How do you get help for it? So many questions, so little time! We wanted the answers to be as simple and as consistent with your existing knowledge as possible: Workflows behave just like every other Windows PowerShell command!

- How do you find it?

Get-Command Test-Workflow

Get-Command Test-Workflow -Syntax

- What is the proper way to name a workflow?

Verb-noun, just like you name any PowerShell cmdlet! Please remember to use approved verbs.

- How do you run it?

Test-Workflow

- How do you get help for it?

Get-Help Test-Workflow

- How do I run it against other computers?

Test-Workflow –PSComputerName ManagedNode1, ManagedNode2

- Will the awesome ISE Intellisense feature work for PSWF at some point?

That’d be a smart thing to do, wouldn’t it? As Cato said, patience is the greatest of all virtues.

But wait, there is more! Stay tuned for upcoming blog posts about using the new workflow common parameters such as PSComputerName and PSCredentials (the keys of the kingdom for running workflows in multi-machine environments), and the Windows PowerShell jobs and modules infrastructure for workflow execution. This is just the beginning!

Here is a sneak peak at what is coming next. These examples use some of the concepts that we will dive into during the next few weeks.

We Want You!

Now that you know the basics, we want to hear from you!

You can send feedback directly to the Windows PowerShell Workflow team by using the Windows PowerShell Connect site at http://connect.microsoft.com/powershell. We triage Connect bugs several times a week and make a point to add comments to each of the bugs.

While you wait for our next post, here are some additional resources about Windows PowerShell 3.0 and Windows PowerShell Workflow:

Getting started with Windows PowerShell Workflow (Download WMF3 CTP2 Windows PowerShell Workflow.pdf)

PowerShell v3: Workflow is the Flagship Feature (by Don Jones – PowerShell MVP)

PowerShell Workflow, Defined (by Hal Rottenberg – PowerShell MVP)

Rocking the Windows Server 8 Administrative Experience

TechNet docs on the Workflow module

Writing a Windows PowerShell Workflow in the Visual Studio Designer

SDK/MSDN documentation

We hope you enjoy the new Windows PowerShell Workflow functionality of Windows 8. We are having lots of fun building it!

Mir Rosenberg [MSFT]

Senior Program Manager

Windows PowerShell

Install PowerShell Web Access on non-English machines

2012-03-16T20:58:00Z

We can check our emails, go on Facebook, and get news feeds on our favorite topics from anywhere and everywhere. Then why not manage our machines from everywhere as well! Windows Server 8 Beta brings you the new feature, Windows PowerShell Web Access, which provides a Windows PowerShell console in your web browser. What! If that’s your reaction, check out Introducing Windows PowerShell Web Access in Windows Server 8.

This post offers a workaround for using Install-PswaWebApplication cmdlet on non-English Windows Server 8 Beta builds to install Windows PowerShell Web Access (aka PSWA). As a quick reminder, Windows PowerShell Web Access offers a Windows PowerShell cmdlet named Install-PswaWebApplication which automates post-installation configuration steps. So open Server Manager and get started!

After adding the feature via ARW in Server Manager or successfully running Install-WindowsFeature PS cmdlet, you will need to follow some additional configuration steps to complete feature installation. Install-PswaWebApplication is a Windows PowerShell cmdlet which offers a quick and easy way to setup the web application and the website in IIS. If no other parameters are specified, the cmdlet uses the default values of “PSWA” for application name, “pswa_pool” for the application pool name and “Default Web Site” for the website. The values for application name and website name can be changed by specifying values for –WebApplicationName and –WebSiteName parameters for Install-PswaWebApplication cmdlet. They can also be changed manually under IIS. The application pool name may also be changed under IIS Manager.

On a non-English Beta build, if no values are provided for Install-PswaWebApplication, the cmdlet will fail. This is because the cmdlet tries to locate the localized equivalent for “Default Web Site” in IIS Manager but in IIS Manager the root website name is always in English. The following is a picture of IIS Manager in a pseudo localized build –

This problem exists only on non-English builds. If you want your website under the “Default Web Site” container in IIS, here are 2 workarounds for that -

1. Provide the english string, "Default Web Site", as a value for the parameter -WebSiteName. Therefore, for successful cmdlet execution, run the following -

Install-PswaWebApplication –WebSiteName “Default Web Site”

2. The second approach is to manually configure the website and the web application pool in IIS Manager. More details and instructions on how to set these up manually can be found in the Windows PowerShell Web Access help doc.

If you have any feedback, you can send it directly to the Windows PowerShell Web Access feature team via the PowerShell Connect site: http://connect.microsoft.com/powershell

Kriti Jindal

Program Manager

Windows PowerShell Web Access

Microsoft Corporation

Introducing Windows PowerShell Web Access in Windows Server 8 Beta

2012-03-07T23:51:00Z

Windows PowerShell Web Access lets you manage your Windows Servers anywhere and anytime.

Windows PowerShell MVPs are excited about Windows PowerShell Web Access. We just had a MVP summit here at Microsoft and I had the pleasure of talking to some of our MVPs. Some of them told me that PowerShell Web Access was the best part of Windows Server 8 Beta! Wow, that made me feel good. There are so many awesome things in Windows Server "8" Beta. Windows PowerShell by itself has several valuable improvements. I don’t know about being the best, but Windows PowerShell Web Access is going to be a hit.

Windows PowerShell Web Access is an IIS web application that provides a Windows PowerShell console in a web browser. The IIS application acts as a gatway and you can connect through it to any machine in your environment with Windows PowerShell remoting enabled.

Windows PowerShell Web Access has several security layers you can read more about in the Windows PowerShell Web Access help documentation. I want to point out that you can create rules to determine who has access to which machines and which endpoints on those machines.

PowerShell Web Access is a new Windows Server feature and detailed installation instructions are available in the Windows PowerShell Web Access help documentation.

Once Windows PowerShell Web Access is installed and configured it will act as a gateway between users on their web browsers and target machines they want to manage.

Many web enabled devices will run Windows PowerShell Web Access. We developed Windows PowerShell Web Access using web standards. HTTPS, Javascript, and cookie support are all you need to use the Windows PowerShell Web Access web application. There are many devices out there and we didn't get to test them all. But we did do limited testing on popular devices like the iPhone , Android Phone, and Windows Phone. Try Windows PowerShell Web Access on your favorite device and let us know how it goes!

Windows PowerShell Web Access provides more incentive for you to write Windows PowerShell cmdlets. If you have been debating whether to write Windows PowerShell cmdlets for something, maybe now is the time to get started. Any cmdlets you write can be exposed via Windows PowerShell Web Access. So when you write your cmdlets you are developing web based management tools. Awesome!

Windows PowerShell Web Access is one more way Windows Server 8 is enabling remote multi-machine management. Now you can access your servers via PowerShell from anywhere. Would you, would you, on a train? Would you, could you, on a boat? Try Windows PowerShell Web Access and you may! You can use it in a house, with a mouse, or anywhere you like.

You can send feedback directly to the Windows PowerShell Web Access feature team via the PowerShell Connect site:

http://connect.microsoft.com/powershell

Mike Emard

Senior Program Manager

Windows PowerShell Web Access

Microsoft Corporation

Windows Management Framework 3.0 Beta Available for Download

2012-03-01T21:20:39Z

Yesterday we published a Beta version of the Windows Management Framework 3.0.

Windows Management Framework 3.0 Beta makes some updated management functionality available to earlier versions of Windows. Windows Management Framework 3.0 Beta can be installed on the following Operating Systems:

Windows 7 Service Pack 1 (32-bit & 64-bit)
Windows Server 2008 R2 Service Pack 1 (64-bit only)
Windows Server 2008 Service Pack 2 (32-bit & 64-bit) – NEW! Beginning with this Beta release.

Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI and WinRM. The Beta version also includes a Server Manager CIM provider. This CIM provider allows users of Server Manager in Windows Server “8” to collect and view management data from servers with Windows Management Framework 3.0 installed.

Feedback & Bugs
We welcome any feedback or bug submissions to the Windows PowerShell Connect site: http://connect.microsoft.com/PowerShell. The release notes include a list of user submitted Connect bugs that have been fixed since Windows Management Framework 3.0 Community Technology Preview #2.

Additional Information:
Release notes are available on the download page. They contain important information about changes since Windows PowerShell 2.0 and a list of known issues.

You must uninstall any other copies of Windows Management Framework 3.0 before installing Windows Management Framework 3.0 Beta.

This software is a pre-release version. Features and behavior are likely to change before the final release.

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Last Call for PowerShell Deep Dive Session Proposals

2012-02-14T01:01:00Z

Thank you to those who have already submitted a session proposal or two! We’ve received a lot of good ideas, and luckily there are a few days left for anyone still thinking about submitting a session for the upcoming PowerShell Deep Dive.

Please send your proposed session title and brief abstract to TEC2012@quest.com before February 15th. We’re open to ideas for both the 75 minute regular sessions and the 35 minute deep dives. Proposals will be reviewed in the next week and responses will be sent out shortly after. Speaker packages include registration, airfare and hotel.

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

It’s Time For Another PowerShell Deep Dive!

2012-01-27T00:30:52Z

The PowerShell Deep Dive is going to be at The Experts Conference USA again this year! The event is being held in San Diego, CA from April 29 - May 2.

Registration is currently open, but we wanted to provide some info on a few changes to the event structure.

The PowerShell Deep Dive is now considered an official track at TEC.
The event will last the full 3 days. This is up from 1.5 days at TEC USA 2011 and 2 days at TEC Europe 2011.
The session format will be a combination of the past two events. There is going to be a combination of

Full length 75 minute sessions
The usual 35 minute Deep Dives (this is the main focus), and
5 minute lightning rounds

As usual, we will be sending some folks (probably ~3) from the PowerShell Team to this Deep Dive and will be kicking the event off with a Keynote.

Registration Info:
Early bird registration runs through the end of January and is priced at $1575. To sign up:

Navigate to the registration page
Click “Register for TEC 2012”.
Fill out the form. No registration code is needed

Speaker Info:
Good news for speakers! Since we are now an official track on TEC, speaker packages are being covered by the TEC organizers. The standard TEC speaker package includes registration, airfare and hotel.

Please send your session proposals for all three session types to TEC2012@quest.com before Feb 15.

Cheers!

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Another Holiday Gift from the PowerShell Team: PowerShell 3.0 CTP2 - Getting Started with Windows PowerShell Workflow

2011-12-22T00:46:00Z

After delivering the Thanksgiving Gift this year, it’s time for a Holiday Gift …. No not as big as the one we had about 3 years ago …!!

Today, we published the “Getting Started with Windows PowerShell Workflow” document on the CTP2 download page, just look for “WMF3 CTP2 Windows PowerShell Workflow.pdf”. This will help you get started with the
newest addition to PowerShell functionality – Windows PowerShell Workflow.

Please continue to provide your feedback via PowerShell Connect so we can receive customer input in a timely manner.

Hemant Mahawar [MSFT]
Program Manager
Windows PowerShell

Windows Management Framework 3.0 Community Technology Preview (CTP) #2 Available for Download

2011-12-02T23:22:00Z

I’m pleased to announce that the Community Technology Preview #2 (CTP2) is available for download.

Windows Management Framework 3.0 CTP2 makes some updated management functionality available to be installed on Windows 7 SP1 & Windows Server 2008 R2 SP1. Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI & WinRM.

IMPORTANT: If you have WMF3.0 CTP1 installed, you must uninstall it before installing CTP2.

Overview of changes since WMF 3.0 CTP1
1. Customer Reported Bug Fixes
Many customer reported bugs have been fixed since the WMF 3.0 CTP1. The release notes contains a list of bug titles, but please check Connect for full details.

2. Single Command Pane in Windows PowerShell ISE
The Command and Output panes in Windows PowerShell ISE have been combined into a single Command pane that looks and behaves like the Windows PowerShell console.

3. Updatable Help
The WMF 3.0 CTP1 release notes described a new Updatable Help system in Windows PowerShell 3.0 and included a copy of the help content. The Updatable Help system is now active on the Internet. To download and update help files, type: Update-Help.

4. Windows PowerShell Workflows
A number of enhancements have been made in the scripting experience for Windows PowerShell Workflows, including new keywords: Parallel, Sequence & Inlinescript. A document describing these changes will be published to the download page shortly.

5. Remote Get-Module
The Get-Module cmdlet now supports implicit remoting. You can now use the new PSSession and CIMSession parameters of the Get-Module cmdlet to get the modules in any remote session or CIM session. A number of other module enhancements are listed in the release notes.

Feedback & Bugs
We welcome any feedback or bug submissions to the Windows PowerShell Connect site: http://connect.microsoft.com/PowerShell

Additional Information:
This software is a pre-release version. Features and behavior are likely to change before the final release.

This preview release is designed to enable the community to experience and review the preliminary designs and direction of key features Windows PowerShell 3.0 and to solicit feedback before features are finalized.

For an interesting post describing what to expect with a CTP, read this very old post from Jeffrey

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Recordings from the First PowerShell Deep Dive

2011-10-06T18:41:00Z

If you’re wondering what to expect at the upcoming PowerShell Deep Dive in Frankfurt, Germany or you just plain love PowerShell, then you may enjoy these recordings taken from the first PowerShell Deep Dive. Many thanks to Dmitry Sotnikov for making them available.

Proxy Functions – Jeffrey Snover

Little Known PowerShell Tips and Tricks – Lee Holmes

WMI: Gems and Gotchas – Richard Siddaway

Defining domain-specific vocabularies using Windows PowerShell – Kirk Munro

It’s not too late to sign up for the October 17 & 18 Deep Dive either.

Go to the TEC registration page
Create an account. You need to do this again for TEC Europe, even if you attended TEC USA earlier this year.
Enter registration code: ATGNJR6E
Select “PowerShell Deep Dive” for the “Which conference do you plan to attend” question.

Travis Jones
Windows PowerShell PM
Microsoft Corporation

PowerShell Deep Dive Lineup

2011-10-06T00:42:00Z

We’re less than two weeks away from the PowerShell Deep Dive at The Experts Conference in Frankfurt, Germany and the schedule for the two day event is looking great!

There’s even going to be a bit of PowerShell V3 content during the Keynote (we’ll reiterate some of what was shown at BUILD last month) and in Dmitry’s “Get your jobs done” session.

Monday

Time	Session Title	Speaker
09:00 – 10:15	PowerShell Deep Dive Keynote	Kenneth Hansen
10:15 – 10:30	Break
10:30 – 11:05	Get your jobs done!	Dmitry Sotnikov
11:10 – 11:45	PowerShell Events	Richard Siddaway
11:45 – 12:20	Notes from the Field - PowerShell in the Enterprise	Brandon Shell
12:25 – 13:00	Delegated Administration with PowerShell Remoting	Aleksandar Nikolic
13:00 – 14:00	Lunch
14:00 – 14:35	Evolution of the PowerShell Language	Jason Shirk
14:40 – 15:15	How to build custom type adapters	Peter Monadjemi
15:15 – 15:50	PowerShell Anywhere How to embed PowerShell in C#, build UI around Powershell, and deploy PowerShell as a web application in Azure.	James Brundage
15:55 – 16:30	How Do They Do That – Formatting with PowerShell	Thomas Lee
16:30 – 17:00	Break
17:00 – 17:35	Lightning Round
17:40 – 18:15	Production Module Design for the IT Pro	Brandon Shell

Tuesday

Time	Session Title	Speaker
09:00 – 09:30	Concurrent scripting in PowerShell	Bruce Payette
09:40 – 10:15	Get your game on! Leveraging proxy functions in Windows PowerShell	Shay Levy and Kirk Munro
10:15 – 10:30	Break
10:30 – 11:45	Problem Solving session
11:45 – 12:20	PowerShell - 6 things to avoid	Richard Siddaway
12:25 – 13:00	WMI Query Langauge - The language of systems monitoring and management via WMI	Ravikanth Chaganti
13:00 – 14:00	Lunch
14:00 – 14:35	Lightning round
14:40 – 15:15	How-To Turn CLI Tools into PowerShell Tools	Jeffery Hicks
15:15 – 15:50	PowerShell SWAT - Guerilla Tactics From The Field	Tobias Weltner
15:55 – 16:30	Maximize the reuse of your PowerShell	James O'Neil

The Lightning Rounds are going to be a series of ~5 minute discussions around whatever attendees suggest.

The Problem Solving sessions can be thought of as mini Script Clubs. Bring something you’re working on or have struggled with recently and get some stuff done!

Abstracts for sessions can be found on the TEC site.

Travis Jones [MSFT]
Windows PowerShell PM
Microsoft Corporation

Cmdlet Help Editor is now released on CodePlex

2011-09-21T04:37:12Z

I published the source code for the Cmdlet Help Editor on CodePlex here: http://cmdlethelpeditor.codeplex.com/ . Please feel free to contribute.

for more information on the Cmdlet Help Editor, please check out the following post: http://blogs.msdn.com/b/powershell/archive/2007/09/01/new-and-improved-cmdlet-help-editor-tool.aspx

Wassim Fayed [MSFT]

Windows Management Framework 3.0 Community Technology Preview (CTP) #1 Available for Download

2011-09-19T23:56:26Z

Windows Management Framework 3.0 CTP1 makes some updated management functionality available to be installed on Windows 7 SP1 & Windows Server 2008 R2 SP1. Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI & WinRM.

Windows PowerShell 3.0
Some of the new features in Windows PowerShell 3.0 include:

Workflows
Workflows that run long-running activities (in sequence or in parallel) to perform complex, larger management tasks, such as multi-machine application provisioning. Using the Windows Workflow Foundation at the command line, Windows PowerShell workflows are repeatable, parallelizable, interruptible, and recoverable.
Robust Sessions
Robust sessions that automatically recover from network failures and interruptions and allow you to disconnect from the session, shut down the computer, and reconnect from a different computer without interrupting the task.
Scheduled Jobs
Scheduled jobs that run regularly or in response to an event.
Delegated Administration
Commands that can be executed with a delegated set of credentials so users with limited permissions can run critical jobs
Simplified Language Syntax
Simplified language syntax that make commands and scripts look a lot less like code and a lot more like natural language.
Cmdlet Discovery
Improved cmdlet discovery and automatic module loading that make it easier to find and run any of the cmdlets installed on your computer.
Show-Command
Show-Command, a cmdlet and ISE Add-On that helps users find the right cmdlet, view its parameters in a dialog box, and run it.

WMI
WMI in Windows Management Framework 3.0 CTP1 introduces:

A new provider development model
This new model brings down the cost of provider development and removes the dependency on COM.
A new MI Client API to perform standard CIM operations.
The API can be used to interact with any standard WsMan + CIMOM implementation, allowing management applications on Windows to manage non-Windows computers.
The ability to write Windows PowerShell cmdlets in native code
The new WMI Provider APIs supports an extended Windows PowerShell semantics API allowing you to provide rich Windows PowerShell semantics. e.g., Verbose, Error, Warning, WhatIf, Confirm, Progress

WinRM
With Windows Management Framework 3.0 CTP1:

Connections are more robust
Session disconnect and reconnect, with or without client session reconstruction, allows long-running tasks to continue even when the session in which they were started is closed and the client computer is shut down. This feature also allows administrators to reconnect from different computers to check the status of remote running tasks and get results.
Connections are more resilient
In Windows PowerShell 3.0 CTP1, connections can survive short-term network failures; the client-server connection is not severed at the first sign of trouble. If network problems persist, the client is safely disconnected and can reconnect by using the Connect-PSSession or Receive-PSSession cmdlets.

Windows PowerShell Web Service
Windows PowerShell Web Service enables an administrator to expose a set of PowerShell cmdlets as a RESTful web endpoint accessible via the Open Data Protocol (OData). This provides remote access to invoke cmdlets from both Windows and non-Windows clients.

Prerequisites

Windows Management Framework 3.0 CTP1 can be installed on the following supported operating systems:

Windows 7 with Service Pack 1
Windows Server 2008 R2 with Service Pack 1

Windows PowerShell 3.0 requires version 4.0 of the common language runtime (CLR). CLR 4.0 is includes with the Microsoft .NET Framework version 4.0.

To install WMF 3.0 CTP1:

Download and extract the correct package for your architecture from the Microsoft Download Center
1. For 64-bit systems, download WMF3-CTP1-x64.cab
2. For 32-bit systems, download WMF3-CTP1-x86.cab
Extract the contents of the downloaded CAB file by typing: expand <<package name>> -F:* <<destination you want for extracted files>>
Close all Windows PowerShell 2.0 windows.
Run the WINDOWS6.1-KB2506143 MSU.

NOTES:

You do not have to uninstall or remove any programs before installing the WMF 3.0 CTP1.
This package requires Service Pack 1 (SP1) for Windows 7. If you receive a “This update does not apply” message when trying to install, verify that SP1 is installed.

To uninstall the WMF 3.0 CTP1:

Locate and uninstall the following installed Windows Update: KB2506143

Additional Information:

This software is a pre-release version. Features and behavior are likely to change before the final release.

Travis Jones
Windows PowerShell PM
Microsoft Corporation

8 Abstracts for the PowerShell Deep Dive in Frankfurt

2011-09-01T16:41:25Z

We’re super excited about the upcoming PowerShell Deep Dive in Frankfurt on October 17 & 18.

The agenda is starting to shape up nicely, so I wanted to share a number of abstracts submitted by members of the PowerShell Community that we’ve already accepted. You can also find this info on The Experts Conference website.

Cheap registration of 850 Euros is coming to an end on September 6. If you’re sitting on the fence, hopefully these abstracts will encourage you register while you can still save 150 Euros.

And now for the abstracts…

Delegated Administration with PowerShell Remoting
Speaker: Aleksandar Nikolic

In this session you will learn how to set up a fan-in PowerShell endpoint, and then use it to assign specific administrative tasks to the appropriate users and groups without changing the membership of local Administrators group. By using just the IIS configuration files and PowerShell scripts we will enable dynamic creation of customized automation environments.

Get Your Game On! Leveraging Proxy Functions in Windows PowerShell
Speakers: Shay Levy & Kirk Munro

Join Shay Levy and Kirk Munro in this session as they take a deep dive into proxy functions in PowerShell. Shay and Kirk have been working together on PowerShell Proxy Extensions, a powerful module that leverages proxy functions and makes it easier than ever to create these powerful extensions to PowerShell. They will demonstrate what proxy functions are and why they are important, and then show how a little scripting savvy (and a really long script) can make your life easier by allowing you to create everything from very simple proxy functions that extend PowerShell to more complex proxy functions that override existing commands, fixing bugs and adding missing features at the same time, all while leveraging inline help as much as possible.

How to Turn CLI Tools into PowerShell Tools
Speaker: Jeffery Hicks

PowerShell is everywhere but there are still many command line tools in the IT Pro’s toolbox, In this session we’ll look at how to turn just about any command line based tool into a PowerShell tool so that you can incorporate it into your PowerShell scripts and daily management tasks. The power of objects in the pipeline is amazing and there’s no reason not to include tools like NETSTAT.EXE or NBTSTAT.EXE.

The Challenge of CLI Tools
Console Text to PowerShell Objects Techniques
Putting It All Together

PowerShell: 6 Things to Avoid
Speaker: Richard Siddaway

PowerShell is a complex tool that provides many ways to accomplish the same task. Some of these ways are better than others. This session supplies some ideas of things to avoid. It builds on the presenter’s experience of:

Using PowerShell
Writing and answering questions in the forums
Judging the PowerShell scripting games

The things to avoid are:

Not using the pipeline
Not using advanced functions
Not creating objects for output
Not using string substitution and multiplication
Not using the built in constants
Not using remoting sessions

Not using these options will make your PowerShell code longer, harder to maintain and you will spend a lot of time inventing functionality that already exists. The session will be mainly code demonstrations.

PowerShell Anywhere
Speaker: James Brundage

Learn how to host PowerShell anywhere. This deep dive covers how to embed PowerShell in C#, build UI around Powershell, and deploy PowerShell as a web application in Azure.

PowerShell SWAT – Guerilla Tactics from the Field
Speaker: Tobias Weltner

In this session, Tobias Weltner shares plenty of “special PowerShell weapons and tactics” that emerged from numerous trainings and PowerShell projects over the past five years. Learn how little things can make huge differences: speed up code, turn plain folders into self-discovery modules, tap into the Windows API and easily read/write INI files, change screen resololution or dim your video display. Regardless of the area you are managing with PowerShell, this session will provide plenty of tricks, fun and inspiration to enhance and improve existing code.

Production Module Design for the IT Pro
Speaker: Brandon Shell

In this session we will deep dive into the thought process behind production module design. The presenter will explain the reason for choices made for the Splunk Module and his own BSonPosh module.

WMI Query Language – The Language of Systems Monitoring and Management Via WMI
Speaker: Ravi Chaganti

This session will include an introduction to WMI Query Language, including:
Concepts of WMI Query Language

Keywords and Operators
Demo on using PowerShell to execute basic WQL queries

Building Complex WMI queries for advanced systems monitoring and management

Working with WMI associations
WQL for event queries
Building Permanent WMI consumers
Demo

Real-world examples of WQL and PowerShell

Demo (Working with performance counters using WQL and PowerShell)
Demo (Building Complex scheduling tasks using WQL and PowerShell)

Travis Jones [MSFT]
Windows PowerShell PM
Microsoft Corporation

Get-Help -Online Fails in German

2011-08-23T15:02:00Z

The Online parameter of the Get-Help cmdlet opens the online version of the help topic for a command in your default Internet browser. If you don't use this feature regularly, you should. Online help topics are typically the most up-to-date version of the help topics, because module authors can update them at any time without redistributing the module. Online help topics are especially critical for modules in the $pshome directory ($env\SystemRoot\System32\WindowsPowerShell\v1.0) which cannot be updated easily, because they are part of Windows.

PS C:\> Get-Help -Online Get-Command
-or-
PS C:\> Get-Help -on Get-Command

Sadly, the Online parameter does not work on German versions of Windows. Get-Help gets the URI (Internet address) of the online help topic from the first link in the Related Links section of each in-box help topic. In our German help topics, the URI is followed by what was intended to be a helpful note. However, Get-Help interprets the note as a part of the URI and the command fails.

RELATED LINKS
Online version: http://go.microsoft.com/fwlink/?LinkID=113324 (möglicherwei se auf Englisch)

Ironically, the helpful note says that the online topic might be in English, although it is truly in German.

To notify users, I've added a note to the description of the Online parameter in U.S. English (en-US) and German (de-de) versions of the Get-Help topic explaining that the parameter does not work in German.

TROUBLESHOOTING NOTE: The Online parameter of the Get-Help cmdlet does not work correctly with German (de-DE) versions of Windows PowerShell help topics. This parameter is reserved for future use in German versions of Windows PowerShell. (http://technet.microsoft.com/en-us/library/dd347639.aspx)

HINWEIS ZUR PROBLEMBEHANDLUNG: Der Onlineparameter des Cmdlets "Get-Help" funktioniert mit deutschen Versionen (de-DE) der Windows PowerShell-Hilfethemen nicht ordnungsgemäß. Dieser Parameter ist für eine künftige Verwendung in deutschen Versionen von Windows PowerShell reserviert. (http://technet.microsoft.com/de-de/library/dd347639.aspx)

To view the entire set of Windows PowerShell help topics from Microsoft in German, start at http://technet.microsoft.com/de-de/library/bb978526.aspx. You can also open a help topic on TechNet in any language, and then replace the language code in the URI.

For example, the URI for the Add-Computer topic in U.S..English (en-US) is:

http://technet.microsoft.com/en-us/library/dd347556.aspx

And the URI for the Add-Computer topic in German (de-de) is:

http://technet.microsoft.com/de-de/library/dd347556.aspx

Our non-English help topics are not updated as frequently as the English topics. However, we're experimenting with many different way to improve our localized help, including our Community Translation Pilot Project (http://blogs.technet.com/b/tonyso/archive/2009/11/17/technet-community-machine-translation-pilot.aspx). If you have suggestions, please comment on this post or send feedback directly to me through Connect (http://connect.microsoft.com/PowerShell) or e-mail (juneb@microsoft.com).

June Blender [MSFT]
Senior Programming Writer
Windows PowerShell Documentation

Extending Discounted Registration & Session Proposal Deadline

2011-08-02T16:03:40Z

The deadline for discounted registration of 850 Euros is going to be moved out to Tuesday, September 6. This is just over a month before the conference date and a little more in line with what we did for the first PowerShell Deep Dive.

To sign up:

Go to the TEC registration page
Create an account. You need to do this again for TEC Europe, even if you attended TEC USA earlier this year.
Enter registration code: ATGNJR6E
Select “PowerShell Deep Dive” for the “Which conference do you plan to attend” question.

Beginning September 7, registration will go up to the full price of 1000 Euros.

We’re also going to give everyone a little more time to submit proposals. We’ll be accepting proposals until Thursday August 18 and responding to folks the following week.

Travis Jones [MSFT]
Windows PowerShell PM
Microsoft Corporation

PowerShell Deep Dive Registration Info & Call for Session Proposals

2011-07-20T00:25:00Z

Here’s some more info on the 2nd PowerShell Deep Dive that will be at TEC Europe 2011 in Frankfurt on October 17 & 18.

Registration Info

Registration is now open for the PowerShell Deep Dive! The cheaper registration fee of 850 Euros is available until August 12. After that, registration will go up to 1000 Euros.

To sign up:

Go to the TEC registration page
Create an account. You need to do this again for TEC Europe, even if you attended TEC USA earlier this year.
Enter registration code: ATGNJR6E
Select “PowerShell Deep Dive” for the “Which conference do you plan to attend” question.

Event Structure

We’re extending this PowerShell Deep Dive by a half day based on feedback we received after the last event. This Deep Dive will offer two full days of sessions (Monday & Tuesday), with some sort of Script Party at the end of each day.

We are also doing away with the longer 75 minute sessions. This PowerShell Deep Dive will consist solely of 35 minute Deep Dive sessions.

Session Proposals

We’re accepting session proposals for Deep Dive sessions through August 3. That’s two weeks from now, so you should start thinking about your session…

To submit a session proposal, fill out the attached form & return it to tec2011@quest.com. Make sure to select “The Experts Conference PowerShell Deep Dive” in the "Speaking Event Preference” section.

Travis Jones [MSFT]
Windows PowerShell PM
Microsoft Corporation

PowerShell Deep Dive @ The Experts Conference Europe 2011

2011-07-12T21:36:00Z

Based upon the excellent reviews received at the first PowerShell Deep Dive, we're pleased to announce a PowerShell Deep Dive will be coming to The Experts Conference 2011 in Germany.

The PowerShell Deep Dive provides a deep technical and strategic engagement within the PowerShell Community. Attendees interact one-on-one with presenters, team members and other key members of the PowerShell Community.

Deep Dive sessions take on a shorter and more technical format than the standard conference (35 minutes versus the usual 75 minutes). As with the first PowerShell Deep Dive, registration will limit the number of attendees to encourage a deeper engagement during the event.

This time around, the PowerShell Deep Dive has been extended to run for two full days: October 17 & 18.

Additional information (e.g., how to submit proposals, deadlines & registration details) will be available in the next week, but we figured everyone could use a couple days to craft the request for money & time off to their bosses.

Travis Jones [MSFT]
Windows PowerShell PM
Microsoft Corporation

Windows PowerShell Blog

Going to TechEd? Join Us to Build a Solution on Windows PowerShell 3.0

Running show-command for a cmdlet

Problem: Figuring out a cmdlet from its syntax can be overwhelming, especially for people new to PowerShell.

What are all those lines and braces?

Solution: Show-Command is a new cmdlet in PowerShell V3 that displays a graphical user interface for a command with a simpler overview of a cmdlet.

Microsoft Script Explorer for Windows PowerShell Beta 1 Now Available

Improved WMI experience in PowerShell 3.0

Schedule for the upcoming PowerShell Deep Dive and a few videos from Frankfurt

Troubleshooting Windows Management Framework 3.0 Beta Installation

Scheduling Background Jobs in Windows PowerShell 3.0

When Windows PowerShell Met Workflow

Simplified Workflow Authoring

Leverage Your Existing Knowledge

Reliable Workflow Execution

Performance and Scalability

Setup and Down-Level Support

To Workflow or To Script… That is the Question

Show me the Money!

We Want You!

Install PowerShell Web Access on non-English machines

Introducing Windows PowerShell Web Access in Windows Server 8 Beta

Windows Management Framework 3.0 Beta Available for Download

Last Call for PowerShell Deep Dive Session Proposals

It’s Time For Another PowerShell Deep Dive!

Another Holiday Gift from the PowerShell Team: PowerShell 3.0 CTP2 - Getting Started with Windows PowerShell Workflow

Windows Management Framework 3.0 Community Technology Preview (CTP) #2 Available for Download

More Videos from the First PowerShell Deep Dive

Recordings from the First PowerShell Deep Dive

PowerShell Deep Dive Lineup

Monday

Tuesday

Cmdlet Help Editor is now released on CodePlex

Windows Management Framework 3.0 Community Technology Preview (CTP) #1 Available for Download

8 Abstracts for the PowerShell Deep Dive in Frankfurt

Get-Help -Online Fails in German

Extending Discounted Registration & Session Proposal Deadline

PowerShell Deep Dive Registration Info & Call for Session Proposals

PowerShell Deep Dive @ The Experts Conference Europe 2011