List of new features in Powershell V3
Posted by Alin D on April 11, 2012
Windows PowerShell v3 is right around the corner. It’s likely to ship with Windows 8, and it’s likely that releases for “downlevel” versions of Windows (Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 — but not Windows Server 2003 or Windows XP) will be released within a month or two, if not on the same day.
PowerShell’s becoming pretty hard to ignore. Windows Server 8 is building the vast majority of its administration on PowerShell, providing the option for GUI administration as well as command-line automation. Version 3 of the shell introduces some pretty important new features; here are the top five.
PowerShell’s Remoting is becoming more important, as it gradually transitions into being the primary channel for administrative communications on the network. More and more GUI admin consoles will rely on Remoting, so it was important to Microsoft to make it more robust. Remoting sessions can now be disconnected, enabling you to later re-connect to the same session from the same or from a different computer. Currently, the Community Technology Preview (CTP) of v3 doesn’t disconnect a session if your client computer crashes; instead, that session is permanently closed — so it’s not quite like Remote Desktop, which could be configured to hold the session open if that happened.
This is a big, big, big deal of a feature. Essentially, PowerShell’s new workflow construct enables you to write something very similar to a function, with PowerShell translating your commands and script code into Windows Workflow Foundation (WWF) processes. WWF then manages your entire task — which can include surviving things like network outages, computer reboots and more. It’s a way of orchestrating long-running, complex, multi-step tasks more efficiently and reliably. And don’t be surprised if the feature gets deeply integrated into the next release of System Center Orchestrator, as well as becoming a foundation feature that’s leveraged by any number of other server products.
PowerShell has always struggled with errors in the help files. Not that there were a ton of them, but it was tough for Microsoft to fix them, since doing so would basically entail issuing an OS patch. Nobody wants patches for help files! The presence of online help, hosted on the TechNet website, mitigated the problem — but only a little. In v3, help files can be updated on-demand, with new XML files downloaded from Microsoft servers whenever you like. So Microsoft can fix errors as they find them, and get you the fixes without requiring an OS service pack or patch.
PowerShell v2 introduced jobs, with the idea that the concept of “job” could be extended over time. In v3, a new type of job — a scheduled job — can be created to run on a schedule, or in response to an event. This isn’t all that different from Windows’ Task Scheduler, but you’ll finally have a way of accessing the capability from within PowerShell. Unlike the v2 jobs, which still exist, the scheduled jobs exist outside PowerShell, meaning they’ll continue to work even if PowerShell isn’t running.
One tough part about any command-line shell is figuring out how to use it. PowerShell’s help system tackles that problem quite well, provided you know the name of the command you want, and provided you know which add-in the command lives in, and that you remembered to load the add-in into memory. Yeah, that’s a lot of caveats. PowerShell v3 addresses the problem by automatically including all commands from all installed modules when it searches for commands; try to run a command that isn’t loaded, and the shell implicitly loads it in the background for you. Ahhh… much easier. This only works with modules that are stored in one of the folder paths listed in the PSModulePath environment variable, but that variable can be modified anytime you like to include additional paths.
PowerShell has always been great for working with Windows Management Instrumentation (WMI), a Microsoft technology that builds on the more-or-less industry-standard Common Information Model (CIM). In PowerShell v3, the WMI cmdlets continue to do a great job, but they’re joined by a new set of CIM cmdlets. At first it might seem like pointless overlap in functionality, but there’s a reason: The CIM cmdlets use WS-MAN, the protocol behind PowerShell’s Remoting feature, and Microsoft’s new standard for administrative communications. WMI, which uses harder-to-pass-through-firewalls DCOM, is officially deprecated, meaning it won’t be developed further — although it’ll continue to be available. CIM will be the “way forward,” with not only additional development to what we’ve always known as “WMI,” but with the possibility for cross-platform management in the future.
Overall, PowerShell v3 is shaping up to be pretty incredible. Get your hands on CTP No. 2 here and start trying it out today.