Introducing Windows PowerShell 3.0

Now that Windows 8 and Windows Server 2012 is available, the same is true for Windows PowerShell 3.0 since it is included in the operating system. Windows PowerShell will also be available for down level operating systems (Windows 7, Windows Server 2008 and Windows Server 2008 R2) shortly, as part of the Windows Management Framework (WMF). In addition to PowerShell, new versions of Windows Management Instrumentation (WMI) and Windows Remote Management (WinRM) is included in the WMF.

What is new?

PowerShell 2.0 brought a whole set of new features including background jobs, remoting and the PowerShell ISE. In PowerShell 3.0 there have been made a great number to these features as well as many new ones. I will go through some of the major news:

Workflows – Based on the Windows Workflow Foundation the PowerShell team have brought workflows into PowerShell. A workflow is a sequence of automated steps or so called activities which performs tasks or receives data from managed devices. This makes it possible for IT Professionals to perform automated tasks against a wide variety of devices, for example software installation. A practical example is the installation and configuration of a Windows Server Failover Cluster, where installation and configuration can be orchestrated from a workflow. Among the feature set of a workflow is the ability to suspend and resume execution, no matter if the reason is planned or a temporary network outage. You can see examples and read more about this feature in this article on the PowerShell team blog.

Enhancements to PowerShell Remoting – Robust sessions is a new feature in PowerShell Remoting which makes it possible for a PowerShell Remoting session, a so-called “PSSession”, to survive a temporary network outage. Delegated administration is another new feature in remoting, where a RunAsAccount can be configured on a remoting endpoint. This makes it possible to delegate tasks to for example helpdesk user, without needing to delegate tasks on the backbone application itself.

Simplified syntax – Especially for beginners, the syntax for various parts of PowerShell might be hard to remember and understand. An example of this is the syntax for the –FilterScript parameter of Where-Object and the –Process parameter of Foreach-Object, which both accepts a so-called script block. In version 1.0 and 2.0 of PowerShell we had to use the $_.propertyname syntax inside this scriptblock. For example Get-Service | Where-Object {$_.Status –eq ‘Running’}. In version 3.0, this still works, but there is an alternate more user friendly syntax as well: Get-Service | Where-Object Status –eq ‘Running’. Here we can see that we did not have to use the curly brackets or the $_. syntax. You should note that you have to use the existing syntax if you are doing more than one comparison, however, this makes it much easier for beginners who are likely to do a single comparison in the beginning. Also experienced users will enjoy this feature since it requires less typing.

More user friendly – A lot of enhancements have been made to make PowerShell more user friendly. A common mistake for new users is not loading the required module for the cmdlet they want to run. For example, if you run Get-ADUser without first running Import-Module ActiveDirectory, you would get an error message stating that Get-ADUser is not recognized. In PowerShell 3.0 there is a new feature called module autoloading, which automatically loads the required module for the cmdlet which is being run. Another features in terms of user friendliness is the new cmdlet Show-Command, as well as the Intellisense feature in PowerShell ISE. You can read more about these two features in this and this article on the PowerShell team blog.

Windows PowerShell Web Service – makes it possible to expose a set of PowerShell cmdlets as a Restful Endpoint via OData (Open Data Protocol). This makes it possible to run PowerShell cmdlets from both Windows and non-Windows devices. Note that this feature is more targeted against advanced users and developers.

Windows PowerShell Web Access – If you have used Microsoft Exchange Server`s webmail functionality, OWA, this feature will look familiar. The sign in page for PowerShell Web Access looks very similar to the OWA sign in page. When logged in, you will be presented with a PowerShell session. This makes it easy to use PowerShell both from a web browser on your computer as well as from mobile devices such as an Iphone or Windows Phone. Note that this feature requires Windows Server 2012. You can find instructions on how to configure this feature in this article on Microsoft TechNet.

Updateable help – Until PowerShell 3.0 the help files that is parsed when you are using the Get-Help cmdlet has been a part of the installation. Updating these files have not been possible, since rolling out help files through the channels for updating the operatingsystem (Windows Update, WSUS) could not be justified. Due to this reason, it was not possible for the PowerShell team to correct errors and enhance the help files after the product had shipped. To overcome this limitation, a new feature named updateable help has been added in version 3.0. There is a new cmdlet called Update-Help you can execute in order to update the help files. If you need to download the files in order to bring them over to a computer not connected to the internet you can use the Save-Help cmdlet. You can read more about updateable help in this article by PowerShell MVP Don Jones.

Microsoft Script Explorer – Technically this is not a part of PowerShell 3.0, but rather a standalone download released in the same timeframe as PowerShell 3.0. Using Script Explorer you can search for scripts and other resources on both Microsoft TechNet as well as 3rd party repositories and local UNC-paths, for example a company repository. Script Explorer can either be run as a standalone application or integrated into the PowerShell ISE as an add-on. By integrating it to the ISE you can copy scripts you find directly in to the editor. Script Explorer will also support Windows PowerShell 2.0.

In addition to the above mentioned features, there has been made a great number of bug fixes and enhancements based on feedback from Microsoft Connect.

There have also been added a significant number of cmdlets in Windows 8 and Windows Server 2012 to administer roles, features and the operating system itself. There is about 2 400 cmdlets in Windows Server 2012, the number depends on which roles and features is installed. This is a result of the fact that Windows PowerShell was added to the Common Engineering Criteria at Microsoft in 2009.

You can find links to more new features in PowerShell 3.0 in the Resource section at the bottom of this article.


As stated earlier, you already have PowerShell 3.0 if you are running Windows 8 or Windows Server 2012. To install PowerShell 3.0 on down level operating systems you must be running one of the following:

  • Windows 7 Service Pack 1
  • Windows Server 2008 R2 SP1
  • Windows Server 2008 Service Pack 2

Windows Management Framework 3.0: Contains new versions of PowerShell, WMI and WinRM.

Microsoft .NET Framework 4.0: This is a prerequisite for installing Windows Management Framework 3.0 on down level operating systems.

Microsoft Script Explorer will be available for the following operating systems:

  • Windows 7 Service Pack 1
  • Windows 8
  • Windows Server 2008 R2 SP1
  • Windows Server 2008 Service Pack 2
  • Windows Server 2012
  • Windows Vista Service Pack 2

Microsoft Script Explorer Release Candidate: This is the download for the Microsoft Script Explorer Release Candidate. This blogpost will be updated with a link to the RTM-version as soon as this is available.

Microsoft .NET Framework 3.5 Service Pack 1: This is a prerequisite for installing Microsoft Script Explorer. In Windows 7/Windows 8 this feature can be installed as a built-in feature.


The community around PowerShell is very active and are constantly contributing new resources. Here I have listed some resources which points you to many of these resources, both from Microsoft and the community.

  • Windows PowerShell Survival Guide– A TechNet Wiki article updated by the community. Here you can find links on how to get started with PowerShell as well as a great number of guides, books, blogs, training, videos and other resources.
  • PowerShell V3 Featured Articles– A TechNet Wiki article containing links to articles about new features in PowerShell 3.0.
  • PowerShell V3 Tips and Tricks– A TechNet Wiki article containing lots of examples about new functionality in PowerShell 3.0.
  • Windows PowerShell Support for Windows Server 2012– A Microsoft TechNet article with an overview and links to the Windows PowerShell modules in Windows Server 2012.
  • PowerShell Book Guide – An overview of various PowerShell books targeted at both beginners and more experienced users. There is also a link to a free ebook about PowerShell Remoting.

What`s New in Windows PowerShell 3.0

Since the release of Windows 7 and Windows Server 2008 R2, Windows PowerShell is included in the operating system and enabled by default. This means Windows PowerShell 3.0 will be available in the next version of Windows.

A preview version for developers of the next Windows version was released a few weeks ago, which means we also got a preview of Windows PowerShell 3.0. The  preview version of the client operating system is available here, while the server version is available on MSDN.

Earlier this week the PowerShell team announced that a Community Technology Preview (CTP 1) is available for download, which means we can also try out PowerShell 3.0 on computers running Windows 7 and Windows Server 2008 R2. The current version of the Windows Management Framework includes Windows PowerShell 2.0, Windows Remote Management (WinRM) 2.0 and Background Intelligent Transfer Service (BITS) 4.0, while the new Windows Management Framework CTP contains Windows PowerShell 3.0, Windows Management Instrumentation (WMI) and Windows Remote Management.

Some of the most important new features in PowerShell 3.0 is listed in the previous mentioned announcement from the PowerShell team, but there is also a huge number of other new features.

A great number of persons in the PowerShell community has already started to discover and write about the new features. One of them is the new Windows PowerShell Web Access in the next version of Windows Server, which Ive previously written an article about.

Instead of listing all the articles Ive discovered so far in this article, I posted them as a TechNet Wiki article as part of the existing PowerShell V3 Guide:

TechNet Wiki: PowerShell V3 Guide
TechNet Wiki: PowerShell V3 Featured articles

I would like to encourage you to contribute to the TechNet Wiki article when you discover new writings about Windows PowerShell 3.0.

Windows PowerShell Web Access

In the Windows Server Developer Preview (“Windows 8 Server”) released recently, a preview version of Windows PowerShell 3.0 is also included. In addition to the many news in the next version of PowerShell which I wont cover in this article is a brand new feature named Windows PowerShell Web Access. As the name indicates this makes it possible to use Windows PowerShell using a browser from a computer, in addition to mobile devices.

Installation, configuration and user experience

Windows PowerShell Web Access is available as a feature in the new Server Manager:


After the feature is installed, some additional steps which is described in %systemroot%WebPowerShellWebAccesswwwrootREADME.txt is required:

To complete the installation of Windows PowerShell Web Access, please perform the
following tasks:

1) Open a Windows PowerShell console with elevated user rights.

To do this, right click on PowerShell.exe, or a Windows PowerShell shortcut,
and then click "Run as administrator."

2) Be sure your Windows PowerShell environment is configured to run scripts.

For more information, see "Running Scripts from Within Windows PowerShell"

3) Run the following script:


This is typically C:WindowsWebPowerShellWebAccesswwwrootsetup.ps1

4) Create a server certificate.

For a test server, you can create a self-signed certificate by using the
Web Server (IIS) management console:


From within the IIS management console, open the Web Servers parent node.
This is typically the node immediately under the Start Page node.

In the results pane, select "Server Certificates" on the center pane, then
select "Create Self-Signed Certificate."

5) Create an SSL binding.

In the IIS management console, select "Default Web Site," and then click
"Bindings" on the "Actions" menu. Click "Add," select "https" on
the "Type" pull-down menu, and then in the "SSL certificate" list, select the
certificate that you created in step 4.

For more information about how to create a server certificate and an SSL binding,
see "How to Set Up SSL on IIS 7"

The setup.ps1 script will create a new Web Application Pool and a new Web Application in Internet Information Services:

$ErrorActionPreference = 'stop'

$wwwroot = "${env:windir}WebPowerShellWebAccesswwwroot"

if (!(Test-Path $wwwroot))
Write-Error "PowerShell Web Access has not been installed on this machine"

# Copy localized files to neutral location
foreach ($target in ($wwwroot,"$wwwrootbin"))
foreach ($culture in ("en","en-us","qps-ploc"))
$source = "$target$culture"

        if (Test-Path $source)
copy "$source*" $target

# Setup ASP.NET application
Import-Module WebAdministration

if (Get-WebApplication -name "pswa")
Write-Error "The Windows PowerShell Web Access application (pswa) already exists on this machine"

New-WebAppPool "pswa"

New-WebApplication -Name "pswa" -Site "Default Web Site" -PhysicalPath $wwwroot -ApplicationPool "pswa"

If the script runs successfully, it returns the following output:

PS C:> C:WindowsWebPowerShellWebAccesswwwrootsetup.ps1

Name                     State        Applications

----                     -----        ------------

pswa                     Started

Path             : /pswa

ApplicationPool  : pswa

EnabledProtocols : http

PhysicalPath     : C:WindowsWebPowerShellWebAccesswwwroot

The final configuration step is to create and add a binding to a certificate as described in the link provided in the readme.txt file.

When done, you can access the feature by using the URL https://<servername>/pswa :


Specify credentials and a computer name to connect to, then hit the “Sign in” button. Another connection type available is “Connection URI”:


The options available under “Advanced Options”:


The available authentication types:


After signing in, youll be presented with a console looking like this:


The console host is called “ServerRemoteHost”:


Tab-completion works just like in the regular Windows PowerShell console host, and we also have access to the history by pressing the up and down arrows. To logoff, there is a Logoff-button in the bottom right corner.

The PowerShell Web Access also works perfectly fine on mobile devices. Ive tried it on a Windows Phone 7 device, but unfortunately I dont have any screen captures to share yet.

Congratulations to the Windows PowerShell team for providing this excellent new feature!

Note: Please be aware that this is a feature in a prerelease version of the next version of Windows Server, and thus the feature might be different in the final product.

Update 15.09.2011

Screen capture from PowerShell Web Access running on an Iphone:









Update 21.03.2012:
With the release of Windows Server 8 beta the configuration steps has changed. After installing the PowerShell Web Access feature you need to install a PSWA Web Application:


By default no authorization rules exist. Here is an example on how to create one that allows access to all computers (*) for the specified username/group:

Add-PswaAuthorizationRule -UserName domainusername -ComputerName * -ConfigurationName microsoft.powershell

Detailed instructions is available in the Deploy Windows PowerShell Web Access article on Microsoft TechNet.