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

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

Rate This
  • Comments 32

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:

  1. 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
  2. Extract the contents of the downloaded CAB file by typing: expand <<package name>> -F:* <<destination you want for extracted files>>
  3. Close all Windows PowerShell 2.0 windows.
  4. 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.

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.

 

Travis Jones
Windows PowerShell PM
Microsoft Corporation

Leave a Comment
  • Please add 5 and 8 and type the answer here:
  • Post
  • Already downloaded and installed the CTPv1.  Can't wait for RTM.  One suggestion that I keep hearing, '$psise.Options.UseEnterToSelectInCommandPaneIntellisense = $true' should be set by default.

  • Great news - I wasn't expecting a CTP on downlevel OSes so quickly.

    How does this built compare to the one included in the Windows 8 Developer Preview?

    I've noticed the build there is rather deficient when it comes to documentation.   There is a very promising new Update-Help cmdlet included in that build, but it can not find the source it is trying to pull content from.

    Does this replace PowerShell 2 when installed on Win7, or is it side-by-side?  (There doesn't appear to be a readme either, perhaps it is inside the .cab)

  • There was, in fact, a very complete README inside the cab file.   It answers all the questions nicely aside from the actual build number, which I can check myself after installing.

    Judging from the README, it looks even better than I thought.   Thank you all!

  • Any documentation on this bit: "Windows PowerShell Web Service " ?

  • Another update:

    The README clearly claims this CTP installs side-by-side with PowerShell 2.0.   That has not been the case on my machine.  It installed into the same System32/WindowsPowerShell/v1.0 directory that both v1 and v2 have used.  It overwrote the existing executable.

    At a first smoke test it has been compatible with several custom modules I've written.  The only immediate error was in my profile trying to save a copy of function:TabExpansion before replacing it with something new.  (Not a bad thing, since the new builtin tab completion seems to be considerably better.)

    Frustrating that the README is so misleading though.

  • Check out the samples in the download to see all the feedback from Connect that's been incorporated into this release.  Thanks Guys!!

  • I have the Sp1 installed and still get the message that it doesn't apply. When I look at the update.mum the EN-US MUI is listed as parent, so it is required that you have this MUI installed :(. Also why does the WINDOWS6.1-KB2506143-x64-pkgProperties.txt show "Applies to="Windows 6.2""? 6.2 = Windows 8 and not Windows 7.

  • Great news, thank you!

    Is there any chance to take a look at the release notes without having to install the CTP?

  • Where can we find out more about Workflows? I've looked at the samples, but would like to know more.

  • Is it supposed to work on non-english version of Win7 SP1?

  • Does this installation replace current version of Powershell in the computer? Can I have both version?

    Thanks in advance

  • This release made my day!! And Rich Prescott nailed it! Thanks Rich, that non-default behavior was killing me.

  • Some of the new stuff looks like game changers, in particular the workflow stuff. Love it!

    BUT, there are still some unnecessary hurdles that I am sure drive away tons of people before they ever get to the cool stuff. My main quarrel is that using/enabling remoting is WAY too unreliable and complicated.

    In particular, the whole first-use experience is just broken for a scenario that I bet you guys in the Microsoft bubble never experience, but that is super common in the wild: no AD, I want to remote into some box somewhere, lets say a server hosted somewhere. I tried this today, it took me MORE THAN AN HOUR to get this working.

    I will spare you the details, but I think two simple things would make the whole experience completly smooth and a thing of two minutes or so.

    First, enable-psremoting should always work. It is just incredibly ironic that in product that is praised as robust/works in the event of failure, even something as simple as enabling remoting is so fragile. The thing that caused my trouble is that the computer I want to remote into has a network adapter that is classified as a public network. Which it should be, because this is a box that is accessible from the internet, so I don't want to place it into a workgroup. Well, and then enable-psremoting doesn't work, and it is incredibly frustraing to try to find out why not. Compare this with the experience of enabling remote desktop: one checkbox, and everything works. So, first call to action: make enable-psremoting ALWAYS work. Including when there is a network adapter that is on a public network. It would be fine to put up lots of warnings (although I don't see them with Remote Desktop), but if I really want to enable it, the command should do it.

    So, once I had that worked out, the trustedhost thing got into my way. If I understand that correct, this is a smiliar thing to what happens if I remote desktop into a machine that is not know to my client machine: I get a dialog warning me that my credentials will be sent to a machine that might not be what it claims to be (same with putty/ssh). Remote Desktop and putty get it right: it warns me, and with one click on YES I can do what I will probably want to do in 90% of the cases: Add that remote machine to the list of trusted hosts. Not so in powershell: I get an error and text saying I should read the help. I go there, it is pages and pages of documentaiton that is all quite detailed, and it simply is all too complicated. So, second call to action: when I open a remote tab in ISE and the remote host is not in the trusted host list, show the same dialog that remote desktop shows, and with ONE click on yes I can go ahead and connect.

    Now, I am sure this scenario is not what you target right now with the "we manage the cloud" fancy stuff. But, this is where people start. If someone used to linux hears that Windows has a new powerfull shell, she will most likely try a simple thing, like remote into some machine. I bet you everything that the vast majority of people will give up somewhere along the way simply because it is all too complicated, plus they will just say that a product that is supposed to make management simple but starts out with a complete configuration nightmare might just not be so great. I believe they would be wrong, but can't really blame them.

    So, two simple things that I think would amount to removing MAJOR roadblocks that exist right now.

  • So... no one from the team monitors these comments?

  • Please support Vista SP2. It's is in mainstream support still and should be supported. Windows 7 is the latest OS, Windows 8 isn't released yet.

Page 1 of 3 (32 items) 123