WaitForAll WSManFault

Tagged: ,

This topic contains 4 replies, has 2 voices, and was last updated by  Don Jones 2 years, 4 months ago.

  • Author
    Posts
  • #25283

    Kris Parr
    Participant

    I'm trying to use WaitForAll to prevent the resources on one machine for running until a first machine is completed. However I get the following fault when pushing my DSC config to the second machine.

    The WinRM client cannot process the request. The destination computer (xxxxx:5985) returned an 'access denied' error. Specify one of the authentication mechanisms supported by the server. If Kerberos
    mechanism is used, verify that the client computer and the destination computer are joined to a domain. Possible authentication mechanisms reported b
    y server: Negotiate Kerberos

    Both machines are domain joined, any ideas on how to fix this ?

  • #25307

    Don Jones
    Keymaster

    So, I guess the usual WS-MAN/WinRM troubleshooting steps apply. Are you providing the FQDNs of the computers? Otherwise, Kerberos might fail the lookup. What're the permissions on WinRM on the destination machine? You'll need to figure out what account the source machine is using to make the connection, and ensure it has permission to do so.

  • #25343

    Kris Parr
    Participant

    Thanks for your help...

    I am using the FQDN for the machine. I've running the DSC resource with my credentials using PsDscRunAsCredential, in the DSC log I can see an informational log of "Impersonation successful. Thread is running under the context of ". If I remote onto the one machine, I can create a new-pssession to the second machine, using these credentials, so it seems that they have the required access. However when trying the WaitForAll resource I get the following exception in the log...

    Message Sending data to a remote command failed with the following error message: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
    HResult -2146233087
    StackTrack at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
    at System.Management.Automation.PowerShell.CoreInvokeRemoteHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
    at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
    at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
    at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
    at Microsoft.PowerShell.DesiredStateConfiguration.Internal.ResourceProviderAdapter.ExecuteProviderCommand(IntPtr resourceConfigurationInstanceHandle, IntPtr regInstanceHandle, String operationCmd, LCMDebugMode debugMode, UInt32& resultStatusHandle, Collection`1& result, ErrorRecord& errorRecord)

  • #25354

    Kris Parr
    Participant

    This seemed to be a mismatch in the versions of PSRemoting, upgraded both machines to the latest WMF 5 release and all is good.

    Thanks.

  • #25356

    Don Jones
    Keymaster

    Weird. Please, please, please bug this in Connect along with some of the evidence you've posted here – the team should really be looking at cross-version compatibility, and this might be a big help to them.

You must be logged in to reply to this topic.