Weekend Scripter: Understanding PowerShell in Windows 7

Weekend Scripter: Understanding PowerShell in Windows 7

  • Comments 3
  • Likes

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:

Image of command output

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.

Image of command output

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


















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:

Image of command output

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 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Will the WMI wrappers from Win8 ever be ported to Win7?

  • @Dan H. I would not think so, because it would require significant architectural changes.

  • Many (or possibly even all) of the new Cmdlets that are only available in Windows 8/2012 use WMI classes that don't exist in previous versions of the OS, such as everything in the root\StandardCimv2 namespace.  Unfortunately, that means it's not as simple as implementing the same WMI wrappers on an older OS.

    There are older WMI classes that expose some of the same information in Windows 7, but in many cases, the information was read-only.  WMI didn't expose very much functionality for making changes via the Win32_* classes, though there are a few notable exceptions, such as managing printers.  The VBScripts in C:\Windows\system32\Printing_Admin_Scripts\ on the older OS used WMI, for example.

    If you're really feeling frisky, you could try to take the new MOF files from a Windows 8 machine and see if you can get WMI to load them on Windows 7.  I doubt it would work, but you never know until you try.