Open ricohomewood opened 5 years ago
@PlagueHO Any update to this bug? it makes xPsEndpoint unusable in Azure Automation DSC
Sorry, @ricohomewood - I misses this. I'll take a look.
Hi @ricohomewood - have you tried with the latest version of this module - 9.1.0? It looks like the problem shouldn't exist there and make have been fixed when the module was updated to the new structure (although there doesn't appear to be an entry - it may have been fixed as a side affect when I got all the tests working).
The function Set-DscMachineRebootRequired
is declared in the xPSDesiredStateConfiguration.Common module and exported. It is imported in the DSC_xPSSessionConfiguration resource.
Thanks @PlagueHO The updated version seems to have cleared that error but another does happen:
[2020-04-07 14:01:02Z] [web2]:[[xPSEndpoint]RemotePSEndpointConfig] Session configuration SpxRemotePS is absent
[2020-04-07 14:01:02Z] [WARNING] [web2]: [[xPSEndpoint]RemotePSEndpointConfig] When RunAs is enabled in a Windows PowerShell session configuration, the Windows security model cannot enforce a security boundary between different user sessions that are created by using this endpoint. Verify that the Windows PowerShell runspace configuration is restricted to only the necessary set of cmdlets and capabilities.
[2020-04-07 14:01:04Z] [WARNING] [WSManNetworkFailureDetected] The network connection to localhost has been interrupted. Attempting to reconnect for up to 4 minutes...
[2020-04-07 14:01:09Z] [WARNING] [WSManConnectionRetryAttempt] Attempting to reconnect to localhost ...
[2020-04-07 14:01:09Z] [WARNING] [WSManConnectionRetrySucceeded] The network connection to localhost has been restored.
[2020-04-07 14:01:09Z] [ERROR] The WS-Management service cannot process the operation. The operation is being attempted on a client session that is unusable. This may be related to a recent restart of the WS-Management service. Please create a new client session and retry the operation if re-executing the operation does not have undesired behavior.
[2020-04-07 14:01:09Z] [VERBOSE] Operation 'Invoke CimMethod' complete.
[2020-04-07 14:01:09Z] [VERBOSE] Time taken for configuration job to complete is 286.001 seconds"
The restart of the WS-Management service causes the above. Not sure if there is a different way this should be handled?
Hi @ricohomewood - Yes, I'd expect the WS-Man service restart to behave this way, however it isn't ideal that it is throwing an error during the process. It actually appears to be the DSC subsystem that it throwing the error itself, rather than the resource. One thing to note is that the resource suppresses the service WSMan Service restart - instead relying on the machine restart. Which from memory was to prevent this problem.
How did you apply the config? Was it Push over PS Remoting or via Pull Server?
Is the config you're testing above creating a new PS Endpoint or modifying an existing one?
One thing I should note about this resource: It hasn't been updated to HQRM so doesn't have any integration tests. This should be prioritized for this resource (something on the my very long backlog :cry: ). So it is possible there are issues like this that need to be sorted.
Thanks for the info ...
This is running as a pull server (Azure Automation) the client running on an Azure Windows 2016 Server Core VM. It was trying to create a new session endpoint BUT what is strange, running it on another VM it didn't error so can't explain that? Maybe a race condition?
I'll run some more on some other new VM's I need to create in Azure and see if that happens again. Thanks
Details of the scenario you tried and the problem that is occurring
Using Azure Automation as the pullserver with xPSDesiredStateConfiguration imported.
Setting a PSSessionConfiguration using the xPSEndpoint DSC resource as per below configuration example on an Azure IaaS VM running Windows Server 2016 Core returns an exception on the inital run stating that is cannot find the
Set-DSCMachineRebootRequired
cmdlet as part of the initialSet-TargetResource
functionality.This eventually corrects itself after the next convergence of DSC but is not ideal in a scenario if using terraform etc to configure DSC on an IaaS VM which crashes out the Terraform run as a result of the DSC extension throwing a transition failure.
Verbose logs showing the problem
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
Version and build of PowerShell the target node is running
Version of the DSC module that was used ('dev' if using current dev branch)
8.6.0.0
imported from Powershellgallery into Azure Automation Modules.