WMI is considered a valuable tool for system administrators, allowing management of Windows workstations, interaction with Microsoft products like Configuration Manager, monitoring of server resources, and more. Microsoft will explore various WMI usage options with PowerShell. By the end, you will understand when to use each method and may not have a clear favorite.

The Ways

There are three tools for managing WMI I want to share with you.

• The System.Management namespace.
• The WMI Scripting API.
• The CIM cmdlets.

Regarding WMI cmdlets such as Get-WmiObject, they won’t be discussing them today for two reasons: they’re only available in Windows PowerShell and the System.Management namespace offers similar functionality. If you haven’t tried PowerShell 7 yet, they highly recommend giving it a try.

The Procedure

Microsoft aims to address common tasks encountered in administering Windows devices, including:

• Querying.
• Calling a WMI Class method.
• Creating, Updating, and Deleting a WMI Class Instance.
• Bonus: Creating, Populating, and Deleting a custom WMI Class.

Microsoft also aims to demonstrate the advantages and disadvantages of each method and highlight where one method excels over the others.

The System.Management Namespace

If Microsoft had to choose, their favorite would be this method. It brings an object-oriented approach to WMI and makes WMI management easier to understand. Additionally, if you’re a C# developer, you’ll feel right at home.

Querying

To execute a query, you need an instance of the ManagementObjectSearcher class. There are three constructors worth examining.

• ManagementObjectSearcher(String)
  • The simplest one. Creates a searcher object specifying the query string.
• ManagementObjectSearcher(String, String)
  • Creates the object with the query and the scope.
• ManagementObjectSearcher(ManagementScope, ObjectQuery)
  • The same as the previous one, but with instances of the objects instead of strings. This gives you more options.

After obtaining the searcher, the Get method is called to retrieve the ManagementObjects.

$query = "Select * From Win32_Process Where Name = 'powershell.exe'"
$searcher = [wmisearcher]($query)
$result = $searcher.Get()

The variable $result holds an instance of the ManagementObjectCollection class, which contains all the Win32_Process instances as ManagementObjects.

$result = $searcher.Get()
$result | Format-Table -Property ProcessId, Name, ExecutablePath -AutoSize

```Output
ProcessId Name           ExecutablePath
--------- ----           --------------
     4116 powershell.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

This is how it looks like using the second and third constructors.

$query = "Select * From Win32_Process Where Name = 'powershell.exe'"
$scope = 'root\cimv2'
$searcher = [wmisearcher]::new($scope, $query)
$result = $searcher.Get()

# Or

$query = [System.Management.ObjectQuery]::new("Select * From Win32_Process Where Name = 'powershell.exe'")
$scope = [System.Management.ManagementScope]::new('root\cimv2')
$scope.Connect()
$searcher = [System.Management.ManagementObjectSearcher]::new($scope, $query)
$result = $searcher.Get()

Calling a WMI Method

Microsoft can either call a method on the resulting ManagementObject from the query operation, such as Terminate or call a method on the WMI Class object. Let’s create a new process using the Create method.

$commandLine = 'powershell.exe -ExecutionPolicy Bypass -Command "Write-Output ''Howdy! From WMI!''; Read-Host"'
$processClass = [wmiclass]'Win32_Process'
# The parameters are: CommandLine, CurrentDirectory and ProcessStartupInformation.
$processClass.Create($commandLine, $null, $null)

If the method is successful, you should see a PowerShell console and the Output Parameters displayed.

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 2
__PROPERTY_COUNT : 2
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ProcessId        : 11896
ReturnValue      : 0
PSComputerName   :

Creating, Updating, and Deleting a WMI Class Instance

Microsoft will use  ManagementClass.CreateInstance() method to create a new instance of the SMS_Collection class and then use Put to save it to the namespace.

$collection = ([wmiclass]'root\SMS\site_PS1:SMS_Collection').CreateInstance()
$collection.Name = 'AwesomeDeviceCollection'
$collection.LimitingCollectionID = 'PS1000042'
$collection.Put()
# The Get() method updates the $collection object with the new
# property values populated by the Config Manager.
$collection.Get()

Updating and deleting.

$collection = [wmiclass]"root\SMS\site_PS1:SMS_Collection.CollectionID='PS1000043'"
$collection.Name = 'AwesomeDeviceCollection_NewName'
$collection.Put()

# Deleting

$collection.Delete()

The WMI Scripting API

The WMI Scripting API is simply the WMI COM interfaces exposed through a Runtime Callable Wrapper, also known as the WMI COM Object. Although not as straightforward as the System.Management namespace, this method of managing WMI offers greater flexibility in its implementation.

Querying

To begin, Microsoft needs to create an instance of the SWbemLocator object, which serves as the interface to other objects and obtain a SWbemServices object by connecting to the server.

$locator = New-Object -ComObject 'WbemScripting.SWbemLocator'
$services = $locator.ConnectServer()

Next, Microsoft uses the ExecQuery method from the SWbemServices object to execute their query. This method returns a SWbemObjectSet, which is a collection of SWbemObjects, and its properties can be found under the Properties_ property.

$result = $services.ExecQuery("Select * From Win32_Process Where Name = 'powershell.exe'")
$object = $result | Select-Object -First 1
$value = $object.Properties_['ProcessId'].Value

Calling a WMI Method

First, they create an instance of the __Properties class, which holds the input parameters for the Create method. Then, they use the SWbemServices.ExecMethod() method to call Create.

$commandLine = 'powershell.exe -ExecutionPolicy Bypass -Command "Write-Output ''Howdy! From WMI!''; Read-Host"'
$parameters = $object.Methods_['Create'].InParameters.SpawnInstance_()
$parameters.Properties_['CommandLine'].Value = $commandLine

$output = $services.ExecMethod('Win32_Process', 'Create', $parameters)

The $output variable contains a SWbemObject, which is an instance of the Output Parameters property class.

$services.ExecMethod('Win32_Process', 'Create', $parameters)

Value       : 16172
Name        : ProcessId
IsLocal     : True
Origin      : __PARAMETERS
CIMType     : 19
Qualifiers_ : System.__ComObject
IsArray     : False

Value       : 0
Name        : ReturnValue
IsLocal     : True
Origin      : __PARAMETERS
CIMType     : 19
Qualifiers_ : System.__ComObject
IsArray     : False

Creating, Updating, and Deleting a WMI Class Instance

Let’s replicate our last example using the Scripting API.

$collection = $services.Get('\\.\root\SMS\site_PS1:SMS_Collection').SpawnInstance_()
$collection.Properties_['Name'].Value = 'AwesomeDeviceCollection'
$collection.Properties_['LimitingCollectionID'].Value = 'PS1000042'
$collection.Put_()

Updating and deleting.

$collection = $services.Get("\\.\root\SMS\site_PS1:SMS_Collection.CollectionID='PS1000043'")
$collection.Properties_['Name'].Value = 'AwesomeDeviceCollection_NewName'
$collection.Put_()

# Deleting

$collection.Delete_()

The CIM Cmdlets

For quick and efficient WMI data analysis without the need for interaction, the CIM Cmdlets are unbeatable. They are fast and provide convenient features such as auto-complete for class and namespace names and easy class retrieval with Get-CimClass.

Querying

Performing queries with the CIM Cmdlets is very pleasant. One line does it all.

$result = Get-CimInstance -Query "Select * From Win32_Process Where Name = 'powershell.exe'"

The parameters are similar to those of Get-WmiObject and can be used in a similar manner.

$result = Get-CimInstance -ClassName 'Win32_Process' -Filter "Name = 'powershell.exe'"

The auto-complete feature in Visual Studio Code.

Calling a WMI Method

The CIM Cmdlets offers a distinctive approach to executing WMI methods. The outcome of a CIM query is referred to as CimInstances, and instance methods cannot be invoked in the same way as with the other two options. Instead, a separate Cmdlet named Invoke–CimMethod is used.

$commandLine = 'powershell.exe -ExecutionPolicy Bypass -Command "Write-Output ''Howdy! From WMI!''; Read-Host"'
$result = Get-CimClass -ClassName 'Win32_Process'
$params = @{
  MethodName = 'Create'
  Arguments = @{
    CommandLine = $commandLine
  }
}
$output = $result | Invoke-CimMethod @params

# Or
$params = @{
  ClassName = 'Win32_Process'
  MethodName = 'Create'
  Arguments = @{
    CommandLine = $commandLine
  }
}
$output = Invoke-CimMethod @params

And the result:

Invoke-CimMethod -ClassName 'Win32_Process' -MethodName 'Create' -Arguments @{ CommandLine = $commandLine }

ProcessId ReturnValue PSComputerName
--------- ----------- --------------
    14932           0

Struggling to recall parameters? Same here! Fortunately, auto-complete also works with them.

Creating, Updating, and Deleting a WMI Class Instance

If you used the old WMI Cmdlets before, this will look familiar.

$params = @{
  Namespace = 'root\SMS\site_PS1'
  ClassName = 'SMS_Collection'
  Property = @{
    Name = 'AwesomeDeviceCollection'
    LimitingCollectionID = 'PS1000042'
  }
}
$collection = New-CimInstance @params

Updating and deleting.

$params = @{
  Namespace = 'root\SMS\site_PS1'
  Query = "Select * From SMS_Collection Where Name = 'AwesomeDeviceCollection'"
  Property = @{
    Name = 'AwesomeDeviceCollection_NewName'
  }
}
Set-CimInstance @params

#Or

$params = @{
  Namespace = 'root\SMS\site_PS1'
  Query = "Select * From SMS_Collection Where Name = 'AwesomeDeviceCollection'"
}
$collection = Get-CimInstance @params
$collection | Set-CimInstance -Property @{
  Name = 'AwesomeDeviceCollection_NewName'
}

#Deleting

$params = @{
  Namespace = 'root\SMS\site_PS1'
  Query = "Select * From SMS_Collection Where Name = 'AwesomeDeviceCollection'"
}
$collection = Get-CimInstance @params
$collection | Remove-CimInstance

Pros and Cons

The System.Management namespace is efficient for obtaining objects or class instances, and their aliases such as [wmi] or [wmiclass] simplify their usage if their paths are known. Calling methods is straightforward, but performing queries and complex operations may be slower and require managing more objects.

The WMI Scripting API is ideal when constructing comprehensive scripts for WMI management. With the SWbemServices object, you have access to most WMI features. Its direct access to RCW interfaces also delivers improved performance compared to the System.Management namespace, which wraps these interfaces for abstraction. However, retrieving individual objects or performing data analysis queries can be cumbersome with this method, as it requires more effort compared to the System.Management namespace.

The CIM cmdlets excel in performance when it comes to querying large datasets, and the CimInstance object is easy to work with when combined with other common objects like PSCustomObject. However, calling methods is not as straightforward as with other methods, and accessing methods like Put, Get, or Delete can be challenging.

Conclusion

With the knowledge gained from this discussion, you should now be able to choose the appropriate tool for working with WMI depending on your needs. No single method is the best in all situations, but each has its own strengths. By utilizing all of them, you will become a more effective System Administrator.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com

During a work conversation, a colleague asked me if it was possible to track changes to a Windows registry key. Microsoft was aware that changes to files can be monitored using the System.IO.FileSystemWatcher.NET class, but they were unaware of registry monitoring. However, they later learned that Windows has an API for it and that it can be called from PowerShell using Interop Services.

About tools

To achieve this, Microsoft will utilize Platform Invoke, also known as PinVoke. PinVoke is a .NET library that allows native APIs to be accessed by managed .NET code. This library is included in Windows via the Global Assembly Cache and also in PowerShell Core.

Moreover, they will utilize several Windows API functions, as listed below:

• RegOpenKeyEx: Responsible for opening a handle to the key.
• RegNotifyChangeKeyValue: Responsible for monitoring the key, and triggering an event when a change happens.
• CreateEvent: Responsible for creating the event.
• WaitForSingleObject: This will monitor the event, and return a result based on the outcome.
• RegCloseKey: To close the handle to our registry key.
• CloseHandle: To close the handle to the event created.

The final two commands are optional, as Interop Services provides a Safe Handle to wrap the handles. This handle is automatically freed by the Garbage Collector, but it is still good practice and builds the habit of tracking object lifecycles. If you plan to frequently interact with Windows, it’s important to become familiar with its memory management to avoid any unexpected behavior.

About definition

To utilize System.Runtime.InteropServices, Microsoft will need to write some of their code in C#. Don’t be intimidated, as C# and PowerShell are quite similar and it won’t be difficult. We’ll begin by defining our functions.

They will show step-by-step how to use RegOpenKeyEx, and the other functions will follow the same process. According to Microsoft’s documentation, the function definition appears as follows:

LSTATUS RegOpenKeyExW(
  [in]           HKEY    hKey,
  [in, optional] LPCWSTR lpSubKey,
  [in]           DWORD   ulOptions,
  [in]           REGSAM  samDesired,
  [out]          PHKEY   phkResult
);

Don’t be concerned about the “W” at the end. Many Windows functions have both ANSI and UNICODE versions. Functions ending in “A” are ANSI-compliant and those ending in “W” are UNICODE-compliant. When you call RegOpenKeyEx, Windows will automatically use one of the two versions.

• HKEY: This represents a handle, which is a type of pointer and can be represented as System.IntPtr in C#. As memory addresses are numerical, System.IntPtr is a specific type of integer.
• LPCWSTR: A pointer to a constant string with 16-bit Unicode characters, represented as System.String in our case.
• DWORD: A 32-bit unsigned integer, equivalent to System.UInt32.
• REGSAM: A Registry Security Access Mask, which they will discuss later.
• PHKEY: A pointer to a variable that will receive the opened key handle, which can be represented as System.IntPtr.
• LSTATUS: The function’s return type, mapped to a long, which we will represent as System.Int in C#.

The REGSAM data type is a collection of definitions that map Registry Key security to unsigned integers and can be represented as a System.UInt32 in C#. Microsoft will use the KEY_NOTIFY REGSAM, which corresponds to 0x0010. The final function definition will look similar to this:

[DllImport("Advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern int RegOpenKeyExW(
    IntPtr hKey,
    string lpSubKey,
    uint ulOptions,
    uint samDesired,
    out IntPtr phkResult
);

The first line in square brackets is the DllImport Attribute. It specifies the DLL containing the definition for RegOpenKeyExW. The CharSet = CharSet.Unicode sets Unicode as the encoding and SetLastError = true sets the last error with the corresponding Win32 error if the function call fails, which is important for debugging and problem resolution.

Following the same approach, we write the full code:

using System;
using System.Runtime.InteropServices;

namespace Win32
{
    public class Regmon
    {
        [DllImport("Advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int RegOpenKeyExW(
            int hKey,
            string lpSubKey,
            int ulOptions,
            uint samDesired,
            out IntPtr phkResult
        );

        [DllImport("Advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int RegNotifyChangeKeyValue(
            IntPtr hKey,
            bool bWatchSubtree,
            int dwNotifyFilter,
            IntPtr hEvent,
            bool fAsynchronous
        );

        [DllImport("Advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int RegCloseKey(IntPtr hKey);

        [DllImport("Advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int CloseHandle(IntPtr hKey);

        [DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern IntPtr CreateEventW(
            int lpEventAttributes,
            bool bManualReset,
            bool bInitialState,
            string lpName
        );

        [DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int WaitForSingleObject(
            IntPtr hHandle,
            int dwMilliseconds
        );
    }
}

The original lpEventAttributes parameter is from the LPSECURITY_ATTRIBUTES structure, but since we won’t be using it, defining it as int will not cause any issues. If Microsoft needed to use it, they would have to define LPSECURITY_ATTRIBUTES.

Writing the PowerShell code

$signature = @'
    Your code goes here.
'@

The final script looks like this:

using namespace System.Runtime.InteropServices

[CmdletBinding()]
param (
    [Parameter(Mandatory)]
    [string]$KeyPath,

    [Parameter()]
    [string]$LogPath = "$PSScriptRoot\RegMon-$(Get-Date -Format 'yyyyMMdd-hhmmss').log",

    [Parameter()]
    [int]$Timeout = 0xFFFFFFFF #INFINITE
)

Add-Type -TypeDefinition $signature

if (!(Test-Path -Path $KeyPath)) { throw "Registry key not found." }

switch -Wildcard ((Get-Item $KeyPath).Name) {
    'HKEY_CLASSES_ROOT*' { $regdefault = 0x80000000 }
    'HKEY_CURRENT_USER*' { $regdefault = 0x80000001 }
    'HKEY_LOCAL_MACHINE*' { $regdefault = 0x80000002 }
    'HKEY_USERS*' { $regdefault = 0x80000003 }
    Default { throw 'Unsuported hive.' }
}

$handle = [IntPtr]::Zero
$result = [Win32.Regmon]::RegOpenKeyExW($regdefault, ($KeyPath -replace '^.*:\\'), 0, 0x0010, [ref]$handle)
$event = [Win32.Regmon]::CreateEventW($null, $true, $false, $null)

<#
This will run indefinitely until it fails or reaches a timeout.
Adjust accordingly.
#>
:Outer while ($true) {
    $result = [Win32.Regmon]::RegNotifyChangeKeyValue(
        $handle,
        $false,
        0x00000001L -bor #REG_NOTIFY_CHANGE_NAME
        0x00000002L -bor #REG_NOTIFY_CHANGE_ATTRIBUTES
        0x00000004L -bor #REG_NOTIFY_CHANGE_LAST_SET
        0x00000008L, #REG_NOTIFY_CHANGE_SECURITY
        $event,
        $true
    )
    $wait = [Win32.Regmon]::WaitForSingleObject($event, $Timeout)

    switch ($wait) {
        0xFFFFFFFF { break Outer } #WAIT_FAILED

        0x00000102L { #WAIT_TIMEOUT
            $outp = 'Timeout reached.'
            Write-Host $outp -ForegroundColor DarkGreen
            Add-Content -FilePath $LogPath -Value $outp
            break Outer
        }

        0 { #WAIT_OBJECT_0 ~> Change detected.
            $outp = "Change triggered on the specified key. Timestamp: $(Get-Date -Format 'hh:mm:ss - dd/MM/yyyy')."
            Write-Host $outp -ForegroundColor DarkGreen
            Add-Content -FilePath $LogPath -Value $outp
        }
    }
}

[Win32.Regmon]::CloseHandle($event)
[Win32.Regmon]::RegCloseKey($handle)

Note

When calling RegOpenKeyExW for the first time, we don’t have the handle to the key yet, so we specify which root key we want to use. The parameter lpSubKey is optional. When not specified, the function will monitor the root key.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com

Admins of the environment can view analytics for Power Automate in the Microsoft Power Platform admin center. The analytics reveal information about flow runs, usage, errors, flow types (automated, button, scheduled, approval, business process), shared flows, and connector details. However, these reports do not cover Desktop Flows. To access the reports, the admin must:

1. Go to the navigation bar on the left side.
2. Select Analytics.
3. Select Microsoft Power Automate.
4. View the reports on the right side.

Who can view these reports?

Admins with a license and specific roles are able to access Power Automate analytics reports.

• Environment Admin – can view reports for the environments that the admin has access to.
• Power Platform Admin – can view reports for all environments.
• Dynamic 365 Admin – can view reports for all environments.
• Microsoft 365 Global Admin – can view reports for all environments.

For details on managing your tenant across the platform with different roles, refer to “Use service admin roles to manage your tenant.

Data Storage

A user-created environment is hosted in the region it is created in and all its data stays within that region for up to 28 days.

Data refresh occurs every 3 hours, with the last refresh time displayed in the top right corner of the page

What are the available reports?

Tenant and environment admins have access to the following tenant-level reports. Reports under the Runs, Usage, Created, and Errors tabs provide insights for both Cloud and Desktop flows. The default view is for the last viewed environment.

Runs report

The Runs report is displayed by default, offering a daily, weekly, and monthly view of all flow runs in an environment.

Usage report

This report gives insights into the types of flows in use, their trends, and the names of their creators.

Created report

This report offers insights into flow types created, trends, and details such as creation date and creator’s email.

Error report

This report provides information on recurring error types and includes error count, creator’s email, last occurrence time, and creator’s email for each flow.

Shared report

This report provides information on shared flows and their trends within the environment.

Connectors report

This report displays connector details and their related flows. Metrics such as calls per connector per flow, flow runs, and the flow creator’s email are available for standard and custom connectors.

Download reports

The reports are created using Power BI. Users can export data by selecting the ellipsis (…) for a KPI.

View reports in other environments

To view reports in another environment:

1. Select Change Filters.
2. Select the new environment from the Environment list and optionally, select a Time Period.
3. Select Apply

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com