I am trying to do a query to obtain setting values of RSOP_SecuritySettingBoolean in PowerShell (and WMI) but it returned nothing. The following query I attempted:

E:\>PS E:\> Get-WmiObject -Namespace "root\RSOP\Computer" -Query "SELECT setting FROM RSOP_SecuritySettingBoolean Where KeyName='ClearTextPassword' and precedence='1'"

PS E:\>

For your extra information:

E:\>ver

Microsoft Windows [Version 10.0.14393]

PS E:\> $psversiontable

Name Value
---- -----
PSVersion 5.1.14393.1198
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1198
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

My Windows 10 OS is still fresh, installed about 2 months ago via ISO. Why is it not returning any results? Please help. Thank you.

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

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

(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