Working with Volumes in CIM


Summary: Microsoft Scripting Guy, Ed Wilson, talks about working with volumes with Windows PowerShell and CIM.

Hey, Scripting Guy! Question Hey, Scripting Guy! I don’t understand CIM at all. I mean, I thought it was basically WMI, but when I use WMI to look at volumes, I see different stuff. Can you help me?

—AB

Hey, Scripting Guy! Answer Hello AB,

Microsoft Scripting Guy, Ed Wilson, is here. There are some questions that seem to be rather easy to answer, and then become confusing. So I am going to jump in and introduce CIM Week.

The Windows Management Instrumentation (WMI) is Microsoft’s implementation of the Common Information Model (CIM). WMI has been around since NT 4.0. Although it does a great job, there are some issues with it.

For one thing, is relies on Distributed COM (DCOM) and Remote Procedure Calls (RPC)—both of which involve a bit of overhead. In addition, it is not very firewall friendly because it requires a large number of open ports.

In Windows 8, we introduced something that would be lighter, that would be firewall friendly, and that would work with the remoting features in Windows PowerShell. It becomes a bit confusing that we call the cmdlets “CIM cmdlets.” Technically, WMI stuff also could be called CIM stuff because it implements CIM. The Windows PowerShell team blog has some great articles that explore the architecture and implantation details, and take a specific example to look at why things seem different.

There is a Get-Volume command. I say command because Get-Command lists it as a function from the Storage module. These are wrappers.

Where some of the confusion comes into play, is in comparing it to the Win32_Volume WMI class. The output is similar, but different.

When I use Get-Volume on my local machine, it returns a nicely formatted output. This is shown here:

PS C:> Get-Volume

DriveLetter FileSystemLabel FileSystem  DriveType  HealthStatus SizeRemaining Size        

———– ———– ———-  ———  ———- ———-       —-

C                   NTFS              Fixed      Healthy     108.53 GB  126.48 GB

E           NEW VOLUME  FAT32       Fixed      Healthy       1.52 GB    1.99 GB

            Recovery    NTFS        Fixed      Healthy      59.83 MB     300 MB

D                                   CD-ROM     Healthy           0 B        0 B

One of the things that is a bit confusing with Get-Volume is that there is no –ComputerName parameter. It might seem to be a huge oversight. But there is a parameter named –CimSession. OK, fine. But does that mean I need to first create a CIM session to use the command? And if so, how do I do that?

One thing that is great about the CIM commands is that I can create a CIM session to multiple computers at the same time. I can then use that CIM session as an argument to the –CimSession parameter. Here is an example:

PS C:> $cim = New-CimSession dc1, sgw

PS C:> Get-Volume -CimSession $cim

DriveLetter FileSystem FileSystem DriveType HealthStatus SizeRemaining Size PSComputerName

——— ——— ——— ——— ——— ———      —- ———

C                   NTFS      Fixed     Healthy   116.91 GB 126.48 GB dc1     

          Recovery  NTFS      Fixed     Healthy    59.83 MB    300 MB dc1     

D                             CD-ROM    Healthy         0 B       0 B dc1     

          System… NTFS      Fixed     Healthy    89.18 MB    350 MB sgw     

C                   NTFS      Fixed     Healthy   116.86 GB 126.66 GB sgw     

A                             Removable Healthy         0 B       0 B sgw     

D         VMGUEST   CDFS      CD-ROM    Healthy         0 B  26.31 MB sgw     

I can use the Get-CimSession parameter to see if there are any open CIM sessions. This is shown here:

PS C:> Get-CimSession

Id           : 3

Name         : CimSession3

InstanceId   : 84597c7e-f348-4f77-a320-3e36aec67a04

ComputerName : dc1

Protocol     : WSMAN

Id           : 4

Name         : CimSession4

InstanceId   : 15cc6611-2085-4c1d-8e71-56c0f64dd08b

ComputerName : sgw

Protocol     : WSMAN

Note that the CIM sessions use WSMan. This is the standard Windows PowerShell remoting protocol that was introduced in Windows PowerShell 2.0. It is cool because it uses a single port and is firewall friendly. In addition, introduced in Windows Server 2012, it is automatically enabled on server operating systems.

As shown here, if I want to remove the CIM sessions, I use the Remove-CimSession cmdlet:

PS C:> Get-CimSession | Remove-CimSession

PS C:> Get-CimSession

PS C:> 

But, I do not have to do that. I can supply a computer name as an argument to the CimSession parameter. When I do this, a connection is made, the command runs, and the connection drops. This is shown here:

PS C:> Get-Volume -CimSession dc1, sgw

DriveLetter FileSystemLabel FileSystem DriveType HealthStatus SizeRemaining Size PSComputerName

——— ——— ——— ——— ——— ———      —- ———

C                   NTFS      Fixed     Healthy   116.91 GB 126.48 GB dc1     

          Recovery  NTFS      Fixed     Healthy    59.83 MB    300 MB dc1     

D                             CD-ROM    Healthy         0 B       0 B dc1     

          System… NTFS      Fixed     Healthy    89.18 MB    350 MB sgw     

C                   NTFS      Fixed     Healthy   116.86 GB 126.66 GB sgw     

A                             Removable Healthy         0 B       0 B sgw     

D         VMGUEST   CDFS      CD-ROM    Healthy         0 B  26.31 MB sgw      

I can verify that nothing is left behind by again running the Get-CimSession cmdlet:

PS C:> Get-CimSession

PS C:> 

AB, that is all there is to using CIM to make a connection and to return volume information. CIM Week will continue tomorrow when I will talk about more cool Windows PowerShell stuff.

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 

Comments (0)

Skip to main content