The New Philosophy for Server Management in Windows Server 8 (Part 3)

by [Published on 10 May 2012 / Last Updated on 10 May 2012]

This article continues the discussion of Microsoft’s new management philosophy by discussing the newly redesigned PowerShell.

If you would like to read the other parts in this article series please go to:

Introduction

Throughout this article series, I have been talking about Windows 8’s new Server Manager - at least as it exists in the Developer Preview release. Even though the Server Manager has been completely redesigned, it is not the only area in which Microsoft has made major changes to the way in which servers will be managed. There are also some noteworthy changes to Windows PowerShell as well.

To be completely frank, PowerShell was kind of a pain to use in Windows Server 2008 and Windows Server 2008 R2. These Windows operating systems only included roughly about 200 PowerShell cmdlets. Even though that might seem like a lot of cmdlets to memorize (and it is), there simply were not enough cmdlets available for truly comprehensive server management. Many of the core operating system services were not even addressed by PowerShell. For example, to the best of my knowledge there are no native PowerShell cmdlets for managing things like DNS or DHCP.

That isn’t to say that Microsoft totally left administrators out in the cold. Often times administrators could accomplish tasks by switching to the legacy Command Prompt window and using either native Command Prompt commands or using utilities such as NETSH. Even so, there is simply no denying that constantly switching between PowerShell, the graphical user interface, and the Command Prompt window is not the most efficient way of doing things.

So what has changed in Windows Server 8? Well for starters, there are a lot more PowerShell commands then there were in previous Windows Server operating systems. The 200 PowerShell commands that existed in Windows Server 2000 8R 2 Have Given Way to a mind-boggling 2300 cmdlets.

Another major change that is being made to Windows PowerShell is that PowerShell sessions are now truly resilient. Essentially this means that users or administrators can disconnect from and then reconnect to a PowerShell session without losing the session state. It doesn't matter if the disconnection was intentional, or if it occurred as a result of a network connectivity failure.

Although being able to disconnect from, and reconnect to PowerShell sessions is nice, the ability to do so is more than just a convenience feature. As I'm sure you probably know, the version of PowerShell that we have today allows you to develop and execute PowerShell scripts. Scripting still exists in PowerShell 3.0, but Microsoft has taken it to the next level by including a workflow feature.

Workflows are very similar to scripts in that they are repeatable blocks of PowerShell code. What makes workflows different from scripts that we have today is that workflows can be interrupted and restarted. It will also be possible to run parallel instances of a workflow.

I realize that some of you who are reading this might be wondering if the ability to interrupt to restart a workflow offers any real world advantages. However, workflows provide at least one major advantage over the PowerShell scripts that we have today. Because workflows can be interrupted and resumed, it is possible to build a workflow that reboots a server and then resumes processing the instructions that once the reboot completes.

In case you're wondering, administrators will not be forced to completely relearn PowerShell in order to develop workflows. Workflows can be written using either the Windows PowerShell language or by using XAML. They are executed by a new Windows Server component called the Windows Workflow Foundation. Although it is beyond the scope of this article, Microsoft even plans to include a mechanism that will allow for workflow scheduling. This means that it will be possible to run jobs at a predetermined time without administrator intervention.

The Integrated Scripting Environment

Because PowerShell 3.0 places such a large emphasis on scripting and on workflows, Microsoft has built a new feature called the Integrated Scripting Environment. The Integrated Scripting Environment is designed to make PowerShell easier to use for beginners, while also providing more advanced editing capabilities to those administrators who need to develop PowerShell scripts.

The Integrated Scripting Environment is not installed on Windows Server by default. You can install it by opening a PowerShell window and executing the following command:

Add-WindowsFeature PowerShell–ISE

Command Discovery

With 2300 PowerShell commands, it is safe to assume that most administrators are probably going to need a little bit of help with figuring out what commands to use in various situations. Previous versions of PowerShell provided command help, but one aspect that was sometimes frustrating was that PowerShell cmdlets were often locked away in modules. Until an administrator loaded a module the commands associated with the module were invalid.

Modules still exist in Windows Server 8, but you won't have to worry about explicitly loading them in most cases. To show you what I mean, take a look at Figure A. In this figure I used the Get-Command *Disk* command to list every cmdlet containing the word Disk. Notice that PowerShell lists all of the cmdlets, regardless of which module they are a part of. The Get-Disk cmdlet for example, is a part of the Storage module.


Figure A: Cmdlets are listed regardless of the module that they reside in.

Now look at Figure B. I was able to use the Get-Disk cmdlet without first having to import the storage module. When I enter the Get-Module cmdlet, you can see that the Storage module was imported automatically when I ran the Get-Disk cmdlet.


Figure B: PowerShell 3.0 imports modules automatically on an as needed basis.

Another thing that Microsoft has done to make using PowerShell easier is to provide us with the Show-Command cmdlet. Entering this cmdlet provides a list of all of the available PowerShell cmdlets. As you can see in Figure C, you can search based on part of the cmdlet name and you can filter the results by module.


Figure C: You can use the Show-Command cmdlet to see a list of available cmdlets.

The really cool part of this dialog box is that it can help you with command syntax. If you look at Figure D, you can see that I have selected the Get-Disk cmdlet. The Commands window changes to display a series of tabs that allow you to specify values for any parameters that you want to use. When you are done, you can click the Run button to execute the cmdlet on the spot. Another option is to click the Copy button. You can then paste the full command into the PowerShell window or into a script editor.


Figure D: PowerShell assists you with command syntax.

Conclusion

In this article, I have shown you some things that Microsoft has done in order to make using PowerShell a little bit easier. Even so, this is only a small part of a much bigger picture. Believe it or not, Microsoft has gone to great lengths to simplify PowerShell. In the next article in this series, I want to show you a major improvement that Microsoft refers to as Syntax Simplification.

If you would like to read the other parts in this article series please go to:

Advertisement

Featured Links