Author Posts

May 15, 2015 at 8:24 am

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 ?

May 16, 2015 at 6:22 am

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.

May 18, 2015 at 2:13 am

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)

May 18, 2015 at 7:30 am

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.

May 18, 2015 at 7:55 am

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.