CIMSession Issue

This topic contains 5 replies, has 3 voices, and was last updated by  postanote 1 month, 4 weeks ago.

  • Author
  • #97025


    Hi there –

    I'm working on a VM lab with two, non domain joined, Windows 10 clients. I've added each client to the other's TrustedHosts in WinRM, and can successfully execute Get-CIMInstance commands using the -ComputerName parameter.

    Here's the issue: I can create a CIM session with New-CIMSession. However, when I try to use it (Get-CIMInstance -CIMSession), I get the following:

    "get-ciminstance : The WinRM client cannot process the request. If the authentication scheme is different from
    Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination
    machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that
    computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the
    following command: winrm help config."

    Any help would be appreciated. Thank you!

  • #97028


    There are several steps to getting PSRemoting properly configured.
    Are you certain you did them all?

    See the following...

    PowerShell V2 Remoting on Workgroup Joined Computers – YES It Can Be Done

    There are a number of extra steps to take to get V2 remoting to work on workgroup joined computers like the ones in your home – unless you're running a DC at home (sick puppy). First up, is a registry setting that makes V2 remoting work on workgroup computers

    PowerShell remoting between two workgroup machines

    If you're an IT Pro, PowerShell remoting is a great tool for doing quick, ad hoc management tasks on computers from the comfort of your own home or office. However, before you can log into a machine, you have to make sure that it's properly configured to grant you access – for safety's sake, the default settings don't allow remote access. If the machine you're trying to log into is in a Workgroup, which doesn't have the same stringent security requirements and infrastructure of a typical Domain setting, you'll have to modify a few additional settings in order to get this done.

        # On client side
        winrm quickconfig
        winrm set winrm/config/client '@{TrustedHosts="Computer1,Computer2"}'
        # On server side
        Enable-PSRemoting -Force
        winrm quickconfig
        # for https
        winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="_";CertificateThumbprint="_"}
        # for http
        winrm create winrm/config/Listener?Address=*+Transport=HTTP
        # Test with
        Test-WsMan ComputerName
        Test-WsMan ComputerName -UseSSL
        # Set TrustedHosts with PowerShell
        # Or with PowerShell (as Admin)
        Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "Computer1,Computer2"
        # And check (don't need Admin for that)
        Get-Item WSMan:\localhost\Client\TrustedHosts
  • #97031


    Thanks for the quick response!

    Those two links cover the steps I've taken so far. I am able to remote from one to the other using Enter-PSSession. I can also successfully run commands remotely using Invoke-Command with the ComputerName parameter. The only time I run into an issue is using a CIMSession name (after I've created it using New-CIMSession).

  • #97034


    I figured out my issue. The error message showed the ComputerName as the "friendly name" I had used with New-CIMSession. That name was not in TrustedHosts. When I reran "Get-CIMINstance -CIMSession" with the computer name (which had been added to TrustedHosts), it worked like a charm.

    Thanks again for your reply on this one, postanote!

  • #97052


    It's much easier in Powershell V4. You can try invoke-command instead.

You must be logged in to reply to this topic.