On some of our servers, when using cmdlet "Add-MpPreference", we got error of "Provider load failure", after some investigation, we found following issues for WMI to create files? Did anyone experience similar issues before?

wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\NCObjAPI.DLL NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\wbemcomn.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\wbemcomn.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\bcrypt.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a

The cmdlet Get-PartitionSupportedSize as well as the CIM class MSFT_Partition (https://docs.microsoft.com/en-us/previous-versions/windows/desktop/stormgmt/msft-partition#members) either report wrong values for the maximum supported partition size or the documentation is not clear enough.

Creating a new partition that uses the maximum size produces partitions that fall 0.98MB short of the maximum supported size. It looks like the CIM class calculates some default offset into the reported SizeMax, since changing the offset did not change the issue.

Steps to reproduce:

foreach ($off in 1,10,15,20,50)
{

$null = Clear-Disk -Number 1 -RemoveData -Confirm:$false

$null = Initialize-Disk -Number 1 -PartitionStyle GPT

$reservedpartition = get-partition -number 1 -DiskNumber 1


$junkpartition = New-Partition -DiskNumber 1 -Size 5gb -Offset ($reservedpartition.offset + $reservedpartition.size + $($off *1mb))

$partition = New-Partition -DiskNumber 1 -UseMaximumSize -Offset ($junkpartition.offset + $junkpartition.size + $($off *1mb))

'Actual Partition Size: {0}' -f $partition.Size

'Supported Partition Size: {0}' -f ($partition | Get-PartitionSupportedSize).SizeMax

'Diff: {0:n2}MB' -f ((($partition | Get-PartitionSupportedSize).SizeMax - $partition.Size) / 1mb)

}

Votes from Connect: 23

Original Date Submitted: 5/22/2012 8:58:19 AM

Description:
Contact Information
Handle: somedude321
Site Name: PowerShell
Feedback ID: 743030

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Currently you need to do some serious developing to be able to use bits in a remoting session. Because bits doesn't allow a user logged in with powershell remoting to start jobs: "The remote use of BITS is not supported".

The remoting session has to impersonate System, or call via a process running as System, to be able to call bits.

I want the winrm service to be able to fix this automatically, the powershell commands (in the BitsTransfer module) should work transparently, in the same way the do locally.

The bits ps module wont be a serious replacement for .net framework components (webclient) before it works remotely. It's also a inconvenient surprise that scripts which works locally doesn't works in a remote session.

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

Repro Steps:
1. Log in remoted with powershell (invoke-command is sufficient).
2. Import BitsTransfer module.
3. Run any bits command.
4. Error

Expected Results:
Bits ps module command should work as is does locally.

Internal BugId: 3588

I am trying to get the details of the user logon to server and using the get-wmiobject in PS but not able to get details output is blank.

PS C:\Users\username> Get-WmiObject -Class win32_computersystem -ComputerName localhost | Select-Object UserName

UserName

PS C:\Users\username> Get-WmiObject -Class win32_computersystem -ComputerName localhost | Select-Object Name

Name

servername

i tried to run it on PS v.4 and v.5 on Win 2k8 r2 server and on 2k12 r2 as well but no luck .
but if i run same on my laptop its provide me the user name logon on to my laptop. This is bit strange why it is not working on server.
If any one has any idea whats wrong please update me.

Thank you
Majeed Attar

(Originally posted in https://connect.microsoft.com/PowerShell/feedback/details/1852524)

Standard CIM cmdlets can produce invalid output. I reproduced the problem with
two commands — Get-SmbShareAccess and Enable-NetAdapterChecksumOffload.
I also believe that the problem is not limited to these particular commands.

Below is an example of me executing 'Get-SmbShareAccess C$, D$' twice. Please
note that the first output is incorrect and it shows 6 entries for C$, instead
of expected 3 entries for C$ and 3 entries for D$:

PS C:> Get-SmbShareAccess C$, D$

Name ScopeName AccountName AccessControlType AccessRight

C$ * BUILTIN\Administrators Allow Full
C$ * BUILTIN\Administrators Allow Full
C$ * BUILTIN\Backup Operators Allow Full
C$ * BUILTIN\Backup Operators Allow Full
C$ * NT AUTHORITY\INTERACTIVE Allow Full
C$ * NT AUTHORITY\INTERACTIVE Allow Full

PS C:> Get-SmbShareAccess C$, D$

Name ScopeName AccountName AccessControlType AccessRight

C$ * BUILTIN\Administrators Allow Full
C$ * BUILTIN\Backup Operators Allow Full
C$ * NT AUTHORITY\INTERACTIVE Allow Full
D$ * BUILTIN\Administrators Allow Full
D$ * BUILTIN\Backup Operators Allow Full
D$ * NT AUTHORITY\INTERACTIVE Allow Full

This problem occurs randomly — i.e., sometimes the output is correct, and
sometimes it is not.

Below is another example of me executing Enable-NetAdapterChecksumOffload for
two adapters, with the same problem. The first output is incorrect:

PS C:> Enable-NetAdapterChecksumOffload A, B -IpIPv4 -PassThru

Name IpIPv4Enabled TcpIPv4Enabled TcpIPv6En

                                                             abled

A RxTxEnabled RxTxEnabled Disabled
A RxTxEnabled RxTxEnabled Disabled

PS C:> Enable-NetAdapterChecksumOffload A, B -IpIPv4 -PassThru

Name IpIPv4Enabled TcpIPv4Enabled TcpIPv6En

                                                             abled

A RxTxEnabled RxTxEnabled Disabled
B RxTxEnabled RxTxEnabled Disabled

Additional notes:

• The problem happens in both PowerShell 4 (4.0) and 5 (5.0.10514.0)




• The problem doesn't happen with -ThrottleLimit 1




• The problem doesn't happen if the objects are taken from the pipeline, for
  example, with Get-SmbShare C$, D$ | Get-SmbShareAccess



• 
  

  The problem happens from time to time, so a loop like below can be useful
  in reproducing it:

  while (1) { Write-Host ''; Get-SmbShareAccess C$, D$ }

  
  



• From my observations, the problem occurs with CIM cmdlets that invoke a
  non-static CIM method with output ¹ when these methods are executed in
  parallel for multiple CIM instances.

¹ A method with [Out]-parameter in .mof file and with the corresponding
<CmdletOutputMetadata> tag in the .cdxml file.

Please note that the described problem is not specific to the File Share cmdlet
(Get-SmbShare), but can also be reproduced with other commands — e.g., with
Enable-NetAdapterChecksumOffload, which is unrelated to File Sharing.

A common thing about these examples is that they perform concurrent requests
to the CIM provider and then join the results. The problem doesn't happen
with -ThrottleLimit 1, and I tend to think that the root of the problem is a
race condition happening somewhere around the following method:

Microsoft.PowerShell.Cmdletization.Cim.ExtrinsicMethodInvocationJob.OnNext()

The method is a part of Microsoft.PowerShell.Commands.Management.dll assembly.

As a blind guess, it could be that, when joining the results, the resulting
CIM object from another request is being incorrectly reused and treated as
the result of the request that's currently being processed. That could explain
the duplicated entries in the output.

Votes from Connect: 11

Original Date Submitted: 6/29/2013 6:19:21 AM

Description:
Contact Information
Handle: Keith Hill MVP
Site Name: PowerShell
Feedback ID: 791819

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

Problem Description:
Folks are so conditioned to using Get-Member to discover properties and methods on types that it is a bit unnerving to not find methods on CIM instances with Get-Member. It is also unintuitive IMO to have to use this:

Get-CimClass Win32_Process | % CimClassMethods

... to find CIM methods when Get-Member will happily show CIM properties. It would be nice to have Get-Member recognize CIM instances and display CIM methods perhaps with a special notion (CimMethod) so we know that we have to use Invoke-CimMethod to invoke that particular method. Another option is to add a new Get-CimMember cmdlet that is the CIM oriented equivalent of Get-Member.

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

Repro Steps:
Try to disover the CIM methods available on an instance of Win32_Process. We've been trained over the years to use Get-Member - no joy. Next we use Get-Command -CIM* and there is nothing in that list that looks like an "introspection" cmdlet.

Expected Results:
Either have Get-Member show CIM methods (with special notation that it is a CIM Method) or add a new cmdlet - Get-CimMember - to use for CIM introspection.

Internal BugId: 4274

Votes from Connect: 13

Original Date Submitted: 1/10/2012 7:54:16 AM

Description:

Contact Information
Handle: Doug Finke
Site Name: PowerShell
Feedback ID: 717747

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Do a "netsh http sh iplisten" and machines are listed, but not the loopback address.

Tried Enable-PSRemoting and got the error below. Once the 127.0.0.1 is added to the IP listener list, this works.

It's something that "winrm quickconfig" should catch.

WinRM already is set up to receive requests on this machine.
Set-WSManQuickConfig : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault&quot; Code="2150858770" M
achine="IIS.lab49.com"><f:Message>The client cannot connect to the destination specified in the request. Verify that th
e service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Manage
ment service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the f
ollowing command on the destination to analyze and configure the WinRM service: "winrm quickconfig". </f:Message></f:WS
ManFault>
At line:50 char:33
+ Set-WSManQuickConfig <<<< -force

+ CategoryInfo          : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException

+ FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

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

Repro Steps:
See the description.

Expected Results:
It's something that "winrm quickconfig" should catch when it is run as suggested by the error.

Internal BugId: 3274