Windows 8. PowerShell v3. Merry Christmas!

This month, and possibly some of next month, I'm going to be spending time covering the upcoming changes in PowerShell v3, which should ship for the first time with Windows 8 (whatever the final name of that product ends up being).

Let's get some standard disclaimers out of the way. First, I'm using publicly-available, pre-beta "developer preview" code. That means everything I'm looking at and sharing with you is out of date, because even as I write this Microsoft is forging ahead with development. That said, I'm going to be focusing more on features than on "bugs," so most of what I'm writing should eventually come true.

Now let's cover some facts.

First, PowerShell v3 will definitely be made available for Windows 8 (which it will ship with), Windows 7, and Windows Vista - plus their server equivalents, Windows Server 2008, Windows Server 2008 R2, and whatever "Windows 8 Server" is called. It will probably NOT ship for Windows XP or Windows Server 2003, in keeping with Microsoft's "N minus 2" policy.

However, v3 should remain as close to 100% backward-compatible as Microsoft can make it, meaning all of your v1 and v2 scripts and commands should execute with no changes, or with only minor changes. Many technologies will remain cross-compatible between v2 and v3. So, if you have v2 installed on an XP box, you will likely be able to remote into it using a v3 shell. The lack of v3 on XP shouldn't be a total deal-breaker for most organizations, although this is definitely a sign that the world is moving on from XP, and that it's seriously, seriously, seriously time to start the upgrade planning (if you haven't already).

It's likely that WinRM, the technology underneath PowerShell's Remoting features, will be turned on by default - at least on the server OS. I know some folks are going to scream "security" about this, but let's not get carried away. Windows Server already turns on a vast number of management protocols by default; WinRM is not only "one more of the same," it's the technology Microsoft is trying to migrate all of those other protocols to. Microsoft is also moving to a "headless server" model with a lot of determination; you need something turned on in order to start configuring the server to begin with. WinRM is it. Now, this whole "turned on by default thing" is probably still open for discussion, so be sure to give Microsoft your feedback if you have it. Personally, I'd love seeing it turned on by default on all domain-joined client computers, too, but I'm not sure if that's even under consideration. Nothing's been said, yet.

We do know, thanks to Windows IT Pro's Paul Thurott, that nearly everything (if not everything) administrator-wise will be PowerShell-accessible. We can tell, because most (if not all) of the admin GUI consoles are being built on PowerShell. So you'll still have your GUI (don't panic!), but you'll also be able to drop "below" the GUI and use PowerShell directly. Huzzah! That also bodes well for Server Core and the "headless" theme, since Server Core can't run a GUI... but it can definitely run PowerShell.

Which is another theme: If you've still got admins who aren't comfortable running GUI management tools on their machine, rather than RDPing into the server console... well, start to change that habit. The direction forward is "stay off the console." Start getting people into that pattern. Sure, you may have some apps running on servers that can't be managed remotely. That'll happen. For everything else, get into the remote management habit. 

Finally, don't ignore Windows 8 just because it's a "developer preview." On the contrary: Get involved. Take a look. Now's not too late for Microsoft to consider feedback - if you wait until beta, or worse until Release Candidate status, you're too late to make a difference.

Discuss this Blog Entry 1

on Oct 5, 2011
Does not run on Vista.

Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×