Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding Windows PowerShell in Windows 7.

Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sipping a cup of English Breakfast tea, with goji berries, lemon grass, and cinnamon. The taste is quite nice, and because the goji berries are sweet, I do not need to add any sugar or honey to my tea. Goji berries are not indigenous to Charlotte, North Carolina, so I use dried berries that I order with my other herbs and spices. Along with my tea, I am eating some homemade scones that the Scripting Wife made with the goji berries. They are rather lovely.

One of the more common questions I get about Windows PowerShell 3.0 runs something like this,“I have Windows PowerShell 3.0, but I do not see the Get-Disk cmdlet.” (Or words to that effect.) Part of the confusion stems from confusing Windows PowerShell 3.0 with the operating system.

Note   For information about installation, refer to Install PowerShell 3.0 on Windows 7.

For example, in Windows 7, when I install Windows PowerShell 3.0, I have access to 355 cmdlets and functions. To find this information, I first imported all of the modules, and then I used the Get-Command cmdlet to retrieve all functions and cmdlets. This is shown here:

In Windows 8, I do not need to install Windows PowerShell 3.0 because it is part of the operating system. When I import all of the modules and count the number of cmdlets and functions in Windows 8, I come up with 988. The output is shown in the following image.

Note  Interestingly enough, the output from $PSVersionTable is a little different in Windows 7 and Windows 8.

Look at the modules

So, where does the difference between Windows PowerShell 3.0 in Windows 7 and In Windows 8 come from? Well, it comes from the modules. In Windows 8, many of the teams at Microsoft created modules to permit remote management of aspects of their configuration. In many cases, this took the form of wrapping various WMI classes that have been part of the operating system for a long time. Therefore, just because I am working in Windows 7, it does not mean that I am unable to use Windows PowerShell to manage it—but it will be a bit more difficult.

So what are the modules that are available in Windows 7 after I install Windows PowerShell 3.0? They are listed here:

PS C:\> Get-Module -list | select name

Name

—-

AppLocker

BitsTransfer

CimCmdlets

ISE

Microsoft.PowerShell.Diagnostics

Microsoft.PowerShell.Host

Microsoft.PowerShell.Management

Microsoft.PowerShell.Security

Microsoft.PowerShell.Utility

Microsoft.WSMan.Management

PSDiagnostics

PSScheduledJob

PSWorkflow

PSWorkflowUtility

TroubleshootingPack

To get an idea of the number of cmdlets in each module, I decide to create a custom property in the Select-Object cmdlet. Here is the command that I created (this is a single-line command that I broke into multiple lines for easier reading):

Get-Module -list | select name,

@{L=’commands’;E={(Get-command -commandtype Function, Cmdlet -module $_.name).count}} |

sort commands -Descending| ft –auto

The command and its associated output are shown in the following image:

By examining the modules and the cmdlets, I can see where the Windows PowerShell 3.0 cmdlets and functions reside, and determine from whence they actually come.

Join me tomorrow when I will examine Windows PowerShell 3.0 in Windows 8.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy