Hey folks,
I'm sending out this request to the Configuration Manager mailing list in
addition to the PowerShell mailing list, because this issue with PowerShell
affects Configuration Manager folks uniquely, as well as people who are
leveraging WMI eventing through PowerShell.
If you are familiar with automating ConfigMgr using PowerShell, you might be
familiar with the concept of "lazy properties." In order to modify a
ConfigMgr object that has "lazy properties," you must first retrieve the
individual WMI instance using its fully qualified path. If you do not do
this, then you will lose the values of the lazy properties, effectively
removing critical data from Configuration Manager (eg. Collection membership
rules). For example, consider the following code:
$CollectionList = Get-WmiObject -Namespace root\sms\site_lab -Class
SMS_Collection;
foreach ($Collection in $CollectionList) {
# NOTE: We must use the __PATH system property to access
# the fully qualified WMI path to the Collection object.
# Else, we will not get the "lazy" properties.
$Collection = [wmi]$($Collection.__PATH);
}
For people using WMI eventing, or even those who generally use PowerShell to
comb through WMI namespaces and classes, the __DERIVATION system property is
absolutely vital to determining which classes inherit from other, more
generic, classes. For example, to find all WMI classes that inherit from the
abstract __Event WMI class, you can use this code:
Get-WmiObject -List | ? { $_.__DERIVATION -contains '__Event'; };
When Microsoft released PowerShell version 3.0 with Windows 8 and Windows
Server 2012, they introduced a new CimCmdlets PowerShell module. This module
can access the same information in WMI that the WMI cmdlets and type
accelerators could, however there are at least two very important
limitations in the module:
1) The CimCmdlets module does not return certain WMI system properties
(eg. __PATH, __DERIVATION, __GENUS, __DYNASTY, etc.)
2) The CimCmdlets do not make a distinction between instance and static
WMI methods, which limits the "discoverability" of WMI method applicability
a. The order of input parameters for WMI methods is also not
specified, requiring additional discovery effort outside PowerShell
b. WMI methods are also not bound to the serialized/deserialized CIM
objects, meaning that calling WMI methods requires more effort
If you could, please vote on the following issue:
https://connect.microsoft.com/PowerShell/feedback/details/782064/dcr-cim-cmd
lets-not-returning-wmi-metadata
To continue using the CimCmdlets going forward, especially with
Configuration Manager, it is imperative that we get these WMI system
properties populated.
Cheers,
Trevor Sullivan
================================================
Did you know you can also post and find answers on PowerShell in the forums?
http://www.myitforum.com/forums/default.asp?catApp=1
