Automating the world one-liner at a time…
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:
WMI WMI in Windows Management Framework 3.0 CTP1 introduces:
WinRM With Windows Management Framework 3.0 CTP1:
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 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:
NOTES:
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
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.