18185

CDXML: Cim jobs

One of the freebies you get when using CDXML is that the cmdlets you create automatically get the –AsJob parameter. I was thinking about jobs in general and realised that I didn’t know how CIM jobs were run.

To put this into context:

PowerShell jobs run in another PowerShell process that is started as a child of the PowerShell process in which you start the job.

WMI jobs use a process called unsecapp - C:\Windows\System32\wbem\unsecapp

Another process - C:\Windows\system32\wbem\wmiprvse.exe will also run.

 

In order to discover the process(es) used by CIM jobs I needed a CIM job that would run for a long time – using CIM_DataFile class to enumerate the files on disk would work. I created a quick module using that class

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Cim_DataFile'>
    <Version>1.0</Version>
    <DefaultNoun>DataFile</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

 

and saved it as Cim_DataFile.cdxml

 

After importing the module I opened another PowerShell session and got a list of processes as a baseline.

Then use the new cmdlet in a Job

Get-DataFile –AsJob

 

The job type is CimJob

A new process appears – wmiprvse. This the same process that appears with WMI jobs.  The path to the exe is C:\Windows\system32\wbem\wmiprvse.exe and the Description is: WMI Provider Host

This process provides isolation for WMI activities so that the whole of WMI isn’t pulled down in the event of a failure. 

The same process is started if Get-CimInstance Cim_Datafile is run.

CDXML–NetworkAdapterConfiguration–Search on Index

The Win32_NetworkAdapterConfiguration class has an Index and an InterfaceIndex property. Both are suitable search properties.

The take an unsigned integer as their value – leading to this addition to the CDXML file:

 

<Property PropertyName="Index">
<Type PSType = "System.UInt32"/>
<RegularQuery >
   <CmdletParameterMetadata PSName="Index" />
</RegularQuery>
</Property>


<Property PropertyName="InterfaceIndex">
<Type PSType = "System.UInt32"/>
<RegularQuery >
   <CmdletParameterMetadata PSName="InterfaceIndex" />
</RegularQuery>
</Property>

You can use the new parameters like this:

Get-NetworkAdapterConfiguration -Index 4

Get-NetworkAdapterConfiguration -InterfaceIndex 5

 

You should see by now how much easier it is working with cmdlets like this rather than having to remember the syntax for WQL filters and even the class names.

The full CDXML file looks like this

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_NetworkAdapterConfiguration'>
    <Version>1.0</Version>
    <DefaultNoun>NetworkAdapterConfiguration</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
       
        <QueryableProperties>
           <Property PropertyName="DHCPEnabled">
            <Type PSType = "System.Boolean"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="DHCPEnabled" />
            </RegularQuery>
           </Property>
          
           <Property PropertyName="IPEnabled">
            <Type PSType = "System.Boolean"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="IPEnabled" />
            </RegularQuery>
           </Property>

           <Property PropertyName="Index">
            <Type PSType = "System.UInt32"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="Index" />
            </RegularQuery>
           </Property>


           <Property PropertyName="InterfaceIndex">
            <Type PSType = "System.UInt32"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="InterfaceIndex" />
            </RegularQuery>
           </Property>

       
        </QueryableProperties>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
</PowerShellMetadata>

 

The module manifest file hasn’t needed to be changed to add this additional functionality. One of the great things about CDXML is that once you have the basic cmdlet working it is so easy to add extra parameters.

 

The next step is to use some of the methods on the class

CDXML–NetworkAdapterConfiguration–IP Enabled

Last time we added a search parameter enabling this:

Get-NetworkAdapterConfiguration -DHCPEnabled $true

I also want to be able to search based on if the adapter if IP Enabled using:

Get-NetworkAdapterConfiguration -IPEnabled $true

This can be achieved by specifying another search parameter:

<Property PropertyName="IPEnabled">
<Type PSType = "System.Boolean"/>
<RegularQuery >
   <CmdletParameterMetadata PSName="IPEnabled" />
</RegularQuery>
</Property>

This the same as was done for DHCPEnabled except that the IPEnabled property is used.

The full XML now looks like this:

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_NetworkAdapterConfiguration'>
    <Version>1.0</Version>
    <DefaultNoun>NetworkAdapterConfiguration</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
       
        <QueryableProperties>
           <Property PropertyName="DHCPEnabled">
            <Type PSType = "System.Boolean"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="DHCPEnabled" />
            </RegularQuery>
           </Property>
          
           <Property PropertyName="IPEnabled">
            <Type PSType = "System.Boolean"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="IPEnabled" />
            </RegularQuery>
           </Property>
       
        </QueryableProperties>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
</PowerShellMetadata>

CDXML–adding search parameters

Last time you saw how to create a cmdlet from the Win32_NetWorkAdapterConfiguration class:

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_NetworkAdapterConfiguration'>
    <Version>1.0</Version>
    <DefaultNoun>NetworkAdapterConfiguration</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

Now its time to add some parameters that can be used for searching.  This will be equivalent to performing these actions:

Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "DHCPEnabled='True'"

Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "IPEnabled='True'"

Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "Index=0"

Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "InterfaceIndex=3"

Lets start by looking at the DHCPEnabled property

£> $class = Get-CimClass -ClassName Win32_NetworkAdapterConfiguration
£> $class.CimClassProperties["DHCPEnabled"]


Name                            : DHCPEnabled
Value                             :
CimType                       : Boolean
Flags                              : Property, ReadOnly, NullValue
Qualifiers                      : {MappingStrings, read}
ReferenceClassName :

 

The parameter DHCPEnabled takes a Boolean value.  At the moment I don’t want anything clever like pipeline input – just the ability to use a parameter

This requirement translates to:

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_NetworkAdapterConfiguration'>
    <Version>1.0</Version>
    <DefaultNoun>NetworkAdapterConfiguration</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
       
        <QueryableProperties>
           <Property PropertyName="DHCPEnabled">
            <Type PSType = "System.Boolean"/>
            <RegularQuery >
              <CmdletParameterMetadata PSName="DHCPEnabled" />
            </RegularQuery>
           </Property>
       
        </QueryableProperties>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
</PowerShellMetadata>

The changes are defined by the  <QueryableProperties> tags

        <QueryableProperties>

Define the WMI property you are searching on

           <Property PropertyName="DHCPEnabled">

Define the type of the data the parameter accepts

            <Type PSType = "System.Boolean"/>

Define the query type – in this case a straight forward search

            <RegularQuery >

Define the name you want the parameter to have  - doesn’t have to match the WMI property name
              <CmdletParameterMetadata PSName="DHCPEnabled" />
            </RegularQuery>
           </Property>
       
        </QueryableProperties>

 

You can use the changed cmdlet like this:

Get-NetworkAdapterConfiguration
Get-NetworkAdapterConfiguration -DHCPEnabled $true
Get-NetworkAdapterConfiguration -DHCPEnabled $false

The full syntax on the cmldet is:

Get-NetworkAdapterConfiguration [-DHCPEnabled <bool[]>]
[-CimSession <CimSession[]>] [-ThrottleLimit <int>]
[-AsJob]  [<CommonParameters>]

The cmdlets over objects technology automatically adds these parameters:

-CimSession

-ThrottleLimit

-AsJob

-CommonParameters

Next time we’ll add the other search properties

CDXML–network adapter configuration

I’ve amended the new-cdxml function created earlier in the series:

function new-cdxml {
[CmdletBinding()]
param (
[Parameter(Mandatory=$true)]
[string]$class,

[Parameter(Mandatory=$true)]
[string]$noun,

[string]$namespace = 'ROOT\cimv2',
[string]$path = "C:\Scripts\Modules\Hardware"
)

$code = @"
<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='$namespace\$class'>
    <Version>1.0</Version>
    <DefaultNoun>$noun</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>
"@

$file = Join-Path -Path $path -ChildPath "$class.cdxml"
Write-Verbose -Message  $file
Set-Content -Path $file -Value $code

}

 

The change is making the class and noun parameters mandatory. In PowerShell 3 & 4 you can simplify the syntax slightly:

param (
[Parameter(Mandatory)]
[string]$class,

[Parameter(Mandatory)]
[string]$noun,

[string]$namespace = 'ROOT\cimv2',
[string]$path = "C:\Scripts\Modules\Hardware"
)

 

I prefer to use the PowerShell 2.0 syntax and actually state that Mandatory=$true.  This is for 2 reasons. Firstly, its what I’m used to and it works – I haven’t got round to changing my default templates. Secondly, I prefer to use this syntax because its immediately apparent to me that the parameter is Mandatory.

This time I’ve used the Win32_NetworkAdapterConfiguration class because it enables me to introduce the use of search (filter) parameters in CDXML cmdlets; it has a number of very useful methods and it enables me to introduce the use of format files.

 

Using new-cdxml you can create the basic module

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_NetworkAdapterConfiguration'>
    <Version>1.0</Version>
    <DefaultNoun>NetworkAdapterConfiguration</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

 

To add this into the module manifest amend these two lines as shown:

# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
NestedModules = @('Win32_BIOS.cdxml',
                   'Win32_ComputerSystem.cdxml',
                   'Win32_DiskDrive.cdxml',
                   'Win32_NetworkAdapterConfiguration.cdxml'
                    )

# Functions to export from this module
FunctionsToExport = @('Get-Bios',
                      'Get-ComputerSystem',
                      'Get-PhysicalDisk',
                      'Get-NetworkAdapterConfiguration'
                      )

 

You now have a hardware module consisting of:

£> Get-Command -Module Hardware

CommandType     Name
-----------             ----
Function               Get-Bios
Function               Get-ComputerSystem
Function               Get-NetworkAdapterConfiguration
Function               Get-PhysicalDisk

 

The output from Get-NetworkAdapterConfiguration on my Windows 8.1 virtual machine looks like this:

ServiceName   DHCPEnabled   Index   Description
-----------        -----------         -----     -----------
netvsc             False                0          Microsoft Hyper-V Network Adapter
kdnic               True                 1          Microsoft Kernel Debug Network Adapter
tunnel             False                 3          Microsoft ISATAP Adapter
netvsc             False                4          Microsoft Hyper-V Network Adapter #2
tunnel             False                5          Microsoft ISATAP Adapter

 

Now this is the same display that Get-CimInstance produces and for my purposes it doesn’t work.  I need to create a format file to produce the display I need. I also want to be able to filter on various criteria including DHCPEnabled, IPEnabled, InterfaceIndex, Index  and Description. I also want to be able to search on any of these individually or in any logical combination

Transferring modules from Windows 8 or 8.1 to Windows 7

Windows 7 shipped with PowerShell 2.0 installed.  Windows 8 brought PowerShell 3.0 and Windows 8.1 brings PowerShell 4.0.

 

Windows 8 and 8.1 also have a lot of modules installed. This extra functionality widens PowerShell reach immensely – the networking modules alone are a significant step forward.

When you install PowerShell 3.0 or 4.0 on Windows 7 you don’t most of the new modules. This has puzzled many people and I’m often asked how those Windows 8/8.1 modules can be made available on Windows 7.

The short answer is that you can’t.

The long answer is that you can’t because, for the most part, those modules are based on CIM (WMI) classes that were introduced in Windows 8 or 8.1. A lot of the system management functionality you see in modern Windows is based on CIM classes that then use the CDXML approach to create PowerShell modules.

Installing the new CIM classes on Windows 7 is not possible – so you can’t get the modules on which they are based.

If you want the new functionality you have to upgrade to Windows 8.1

CDXML–scripting creation

So far you’ve seen how to create CDXML files by hand – though you probably used cut and paste rather than typing everything from scratch.

Its time to bring a bit of automation to creating CDXML files. The XML is fairly simple and you’re only changing a couple of values so you can do this:

function new-cdxml {
[CmdletBinding()]
param (
[string]$class,
[string]$noun,
[string]$namespace = 'ROOT\cimv2',
[string]$path = "C:\Scripts\Modules\Hardware"
)

$code = @"
<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='$namespace\$class'>
    <Version>1.0</Version>
    <DefaultNoun>$noun</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>
"@

$file = Join-Path -Path $path -ChildPath "$class.cdxml"
Write-Verbose -Message  $file
Set-Content -Path $file -Value $code

}

I saved this as NewCDXML.ps1.  This will eventually  become the basis of a CDXML file creation module. I set defaults on the namespace and the path – feel free to change them if required.

The function is run as:

new-cdxml -class Win32_DiskDrive -noun PhysicalDisk

which produces this CDXML file

<?xml version='1.0' encoding='utf-8'?>
<PowerShellMetadata xmlns='http://schemas.microsoft.com/cmdlets-over-objects/2009/11'>
  <Class ClassName='ROOT\cimv2\Win32_DiskDrive'>
    <Version>1.0</Version>
    <DefaultNoun>PhysicalDisk</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet='DefaultSet'>
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

 

The Hardware.psd1 file needs to be altered:

# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
NestedModules = @('Win32_BIOS.cdxml',
                   'Win32_ComputerSystem.cdxml',
                   'Win32_DiskDrive.cdxml'
                    )

 

and

# Functions to export from this module
FunctionsToExport = @('Get-Bios',
                      'Get-ComputerSystem',
                      'Get-PhysicalDisk'
                      )

 

The module now looks like this:

£> Get-Command -Module Hardware

CommandType      Name
-----------                ----
Function                Get-Bios
Function                Get-ComputerSystem
Function                Get-PhysicalDisk

 

This makes creating additional components for your module much easier.

CDXML: Add a cmdlet for computer system

Continuing the creation of a Hardware investigation module – its a simple matter to add a cmdlet to retrieve the computer system data ie Win32_ComputerSystem

First create a CDXML file like this:

<?xml version="1.0" encoding="utf-8"?>
<PowerShellMetadata xmlns="http://schemas.microsoft.com/cmdlets-over-objects/2009/11">
  <Class ClassName="ROOT\cimv2\Win32_ComputerSystem">
    <Version>1.0</Version>
    <DefaultNoun>ComputerSystem</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet="DefaultSet">
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

 

The only difference from the Win32_BIOS.cdxml is the WMI class and the default noun

Save in your Hardware module folder as Win32_ComputerSystem.cdxml

Modify the hardware.psd1 file in two places -

NestedModules = @('Win32_BIOS.cdxml',
                  'Win32_ComputerSystem.cdxml' )

 

AND

FunctionsToExport = @('Get-Bios',
                      'Get-ComputerSystem')

Save the hardware.psd1 file.

Now when you open up PowerShell

£> Get-Command -Module Hardware

CommandType     Name                  ModuleName
-----------     ----                  ----------
Function        Get-Bios              Hardware
Function        Get-ComputerSystem    Hardware

 

£> Get-ComputerSystem | Format-List

Domain              : Manticore.org
Manufacturer        : Microsoft Corporation
Model               : Virtual Machine
Name                : WIN81
PrimaryOwnerName    : Richard
TotalPhysicalMemory : 1857605632

Note default display is a table.

For now we’ll keep adding investigative cmdlets to our module – though there are some methods on Win32_ComputerSystem we’ll be adding to our module later.

CDXML: Module Manifest

Last time we created a module using CDXML to wrap the Win32_Bios WMI class. This gave us a cmdlet – Get-Bios.  As the intention is to create a number of modules that expose the WMI classes related to hardware we need a module manifest file (.psd1) to load them so that we can take advantage of module auto-loading in PowerShell 3 & 4

Remember – one WMI class per CDXML file and each CDXML file is treated as a module

I find the easiest way to create new manifest is run New-ModuleManifest and give it the full path to the psd1 file you want to create

 

New-ModuleManifest -Path C:\scripts\Modules\Hardware\Hardware.psd1 –PassThru

 

You can then open the file in ISE and edit to give this:

#
# Module manifest for module 'Hardware'
#
# Generated by: richard
#
# Generated on: 30/11/2013
#

@{

# Script module or binary module file associated with this manifest.
# RootModule = ''

# Version number of this module.
ModuleVersion = '1.0'

# ID used to uniquely identify this module
GUID = '55512ad7-c2aa-4678-818f-8f19b4f110dd'

# Author of this module
Author = 'Richard'

# Company or vendor of this module
CompanyName = 'Macdui'

# Copyright statement for this module
Copyright = '(c) 2013 Richard. All rights reserved.'

# Description of the functionality provided by this module
# Description = ''

# Minimum version of the Windows PowerShell engine required by this module
# PowerShellVersion = ''

# Name of the Windows PowerShell host required by this module
# PowerShellHostName = ''

# Minimum version of the Windows PowerShell host required by this module
# PowerShellHostVersion = ''

# Minimum version of Microsoft .NET Framework required by this module
# DotNetFrameworkVersion = ''

# Minimum version of the common language runtime (CLR) required by this module
# CLRVersion = ''

# Processor architecture (None, X86, Amd64) required by this module
# ProcessorArchitecture = ''

# Modules that must be imported into the global environment prior to importing this module
# RequiredModules = @()

# Assemblies that must be loaded prior to importing this module
# RequiredAssemblies = @()

# Script files (.ps1) that are run in the caller's environment prior to importing this module.
# ScriptsToProcess = @()

# Type files (.ps1xml) to be loaded when importing this module
# TypesToProcess = @()

# Format files (.ps1xml) to be loaded when importing this module
# FormatsToProcess = @()

# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
NestedModules = @('Win32_BIOS.cdxml')

# Functions to export from this module
FunctionsToExport = @('Get-Bios')

# Cmdlets to export from this module
CmdletsToExport = '*'

# Variables to export from this module
VariablesToExport = '*'

# Aliases to export from this module
AliasesToExport = '*'

# List of all modules packaged with this module
# ModuleList = @()

# List of all files packaged with this module
# FileList = @()

# Private data to pass to the module specified in RootModule/ModuleToProcess
# PrivateData = ''

# HelpInfo URI of this module
# HelpInfoURI = ''

# Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.
# DefaultCommandPrefix = ''

}

 

You can cut out the items you don’t need but I prefer to leave them as reminders of the commands.

Once the file is modified – save it back as Hardware.psd1

Start a new PowerShell console and your new module is available for use immediately.

This also means that you can add new CDXML files and test them independently of the module. Once you’re happy with the new functionality you add the appropriate lines to the module manifest.

CDXML

Its been stated many times that over 60% of the modules in PowerShell 3 & 4 are created using CDXML – objects-over-cmdlets.

This involves taking a WMI class and wrapping it in XML to create a PowerShell module. At this time many admins are running for the door but it really isn’t that difficult.

Most admins will have used the Win32_Bios class

£> Get-CimInstance -ClassName Win32_Bios


SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : BIOS Date: 05/23/12 17:15:53  Ver: 09.00.06
SerialNumber      : 5518-5018-0990-2526-2313-2106-44
Version           : VRTUAL – 5001223

 

To create a CDXML file type this in ISE:

<?xml version="1.0" encoding="utf-8"?>
<PowerShellMetadata xmlns="http://schemas.microsoft.com/cmdlets-over-objects/2009/11">
  <Class ClassName="ROOT\cimv2\Win32_BIOS">
    <Version>1.0</Version>
    <DefaultNoun>Bios</DefaultNoun>

    <InstanceCmdlets>
      <GetCmdletParameters DefaultCmdletParameterSet="DefaultSet">
             
      </GetCmdletParameters>
    </InstanceCmdlets> 
  </Class>
 
</PowerShellMetadata>

 

Everything is boiler plate except two lines:

<Class ClassName="ROOT\cimv2\Win32_BIOS">
which shows the namespace and the class you are using

 

   <DefaultNoun>Bios</DefaultNoun>

which sets the NOUN of the PowerShell cmdlet you are producing. The verb is automatically set to GET.

I keep all my scripts in a folder called c:\scripts – this has subfolders by category. I also amend my module path in my PowerShell profile

$env:PSModulePath = "C:\Scripts\Modules;" + $env:PSModulePath

to add the \scripts\modules folder. This folder has all of the module I develop to keep them separate from the Microsoft modules.

 

I’m creating a module called Hardware that will contain a suite of CDXML files for accessing WMI classes related to hardware.

I saved the XML above to C:\Scripts\Modules\Hardware\Win32_BIOS.cdxml

For testing I change directory the C:\Scripts\Modules\Hardware folder and I can test my new module.

£> Import-Module .\Win32_BIOS.cdxml
£> Get-Command -Module Win32_BIOS

CommandType     Name                   ModuleName
-----------     ----                   ----------
Function        Get-Bios               Win32_BIOS

 

Running Get-Bios produces:

£> get-bios


SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : BIOS Date: 05/23/12 17:15:53  Ver: 09.00.06
SerialNumber      : 5518-5018-0990-2526-2313-2106-44
Version           : VRTUAL – 5001223

 

Exactly the same as using Get-CimInstance.

You also get a set of free functionality (meaning you don’t have to do anything)

£> Get-Command Get-Bios -Syntax

Get-Bios [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [<CommonParameters>]

£> $sess = New-CimSession -ComputerName server02
£> Get-Bios -CimSession $sess


SMBIOSBIOSVersion : 6NET61WW (1.24 )
Manufacturer      : LENOVO
Name              : Ver 1.00PARTTBLX
SerialNumber      : R81BG3K
Version           : LENOVO - 1240
PSComputerName    : server02

 

The properties displayed are controlled by the PowerShell formatting system as with most WMI classes. You can display all data:

Get-Bios | Format-List *

 

Next time we’ll create a module manifest file to enable module auto-loading