Votes from Connect: 43

Original Date Submitted: 3/26/2013 1:25:17 AM

Description:
********Contact Information********
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 782064
***************************************

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
When using the Get-WmiObject cmdlet, lots of WMI metadata is included with the resulting objects including:

1. WMI qualifier names/values (and qualifier metadata: IsAmended, IsLocal, PropagatesToInstance, PropagatesToSubclass, IsOverriable)
2. System properties
3. WMI class path (eg. \\servername\root\cimv2:Win32_ComputerSystem.Name="servername")
4. WMI instance path (eg. \\servername\root\cimv2:Win32_ComputerSystem)
5. ManagementScope options via "Scope" property
6. WMI class-level information: __DERIVATION, __DYNASTY, __SUPERCLASS, _SERVER, __NAMESPACE, __PATH, __GENUS, __RELPATH, et al.
7. ... and probably others I'm missing

This information is absolutely vital to effectively developing automation scripts leveraging the Windows Management Instrumentation (WMI) service.

Unfortunately, the CIM cmdlets module does not return the same information as Get-WmiObject does. Please modify the CIM cmdlets to include this vital WMI metadata. In some cases, the data format may differ somewhat: eg. WMI object paths may be express using WS-Management lingo, instead of WMI monikers.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 782064 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=782064).

Repro Steps:
1. Launch PowerShell
2. Use CIM cmdlets (eg. Get-CimInstance -Class Win32_ComputerSystem)
3. Notice the lack of WMI metadata described

Expected Results:
The appropriate WMI metadata should be returned from CIM cmdlets in the PowerShell 3.0 CIMcmdlets module.

Internal BugId: 4158