Skip to content

Single Thread Apartment required for Enable-WSManCredSSP and Disable-WSManCredSSP #3353

Closed

Description

@jeffbi

When given -Role Client, these cmdlets attempt to make use of the IGroupPolicyObject COM interface. IGroupPolicyObject requires that it be called from a Single Thread Apartment. STA is not supported in CoreCLR, so these cmdlets will fail when using the Client role.

This is the underlying cause of issue #2599.

The core folk have an existing issue for support of STA.

Steps to reproduce

Enable-WSManCredSSP -DelegateComputer ServerA.foo.xyz.com -Role Client -Force
or
Disable-WSManCredSSP -Role Client

Expected behavior

Perform the operation without error.

Actual behavior

Throws System.InvalidCastException when trying to cast an object to IGroupPolicyObject.

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSRemotingProtocolVersion      2.3
GitCommitId                    v6.0.0-alpha.16-49-g97be759cc7bd33abbe220dd87...
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSEdition                      Core
CLRVersion
PSVersion                      6.0.0-alpha
BuildVersion                   3.0.0.0
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Activity

  1. iSazonov commented on Mar 17, 2017

    @iSazonov
    Collaborator

    Related #2969

  2. iSazonov commented on Mar 18, 2017

    @iSazonov
    Collaborator

    CoreFX issue https://github.com/dotnet/corefx/issues/522 milestone is 1.0.0-rtm so I set "Waiting - NetStandard20"

  3. karelz commented on Mar 31, 2017

    @karelz

    Ilya (@iSazonov) what is exactly the expectation for .NET Standard 2.0? Are there any missing APIs? Or just missing capability of the runtime? -- in that case it would be more about .NET Core 2.0 than .NET Standard 2.0.
    Either way, I am not sure if we can make that happen in .NET Core 2.0 timeframe -- let's have that discussion in the new CoreFX issue. Is it something blocking PowerShell Core release? Is it something that PowerShell team (or community) is interested in contributing to CoreFX repo?

  4. iSazonov commented on Mar 31, 2017

    @iSazonov
    Collaborator

    Karel Zikmund (@karelz) We have some Issues here about this (2 or even more).
    I believe Dongbo Wang (@daxian-dbw) can comment in depth. It seems Dongbo Wang (@daxian-dbw) already open such Issue in CoreFX repo.

  5. daxian-dbw commented on Mar 31, 2017

    @daxian-dbw
    Member

    I didn't open a new issue in CoreFx repo on this topic. Currently we call ShellExecuteEx directly in MTA thread, it would have problems for some shell extensions that require COM, but it's fine for common uses, such as opening file exploere or a file based on its extension.

    However, this issue seems indicating that it's blocking our remoting scenario, Hemant Mahawar (@HemantMahawar) and Joey Aiello (@joeyaiello), can you please weigh in and see if this will block PowerShell Core 6.0 RTM release?

  6. iSazonov commented on Apr 2, 2017

    @iSazonov
    Collaborator

    In General, Windows still widely uses the COM as well as Forms that require STA. If .Net Core does not provide access to these subsystems, PowerShell will lose a lot of functionality. I would like to have Get-WmiObject.
    I do not dare to open the CoreFX Issue because I do not know these APIs deeply.

  7. alexandair commented on Apr 2, 2017

    @alexandair
    Contributor

    Ilya (@iSazonov) Why do you need Get-WmiObject? What about using Get-CimInstance instead?

  8. iSazonov commented on Apr 2, 2017

    @iSazonov
    Collaborator

    Aleksandar Nikolić (@alexandair) In this discussion, it is important that both cmdlets use COM.

  9. added this to the milestone on Jul 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions