WinRM service is restarted when running Set, which breaks the DSC run

[johlju]

When running the resource using

Invoke-DscResource -ModuleName JustEnoughAdministration -Name JeaEndpoint -Method Set -Verbose -Property @{
            EndpointName        = 'Microsoft.PowerShell'
            RoleDefinitions     = "@{ 'CONTOSO\DnsAdmins' = @{ RoleCapabilities = 'DnsAdmin' } }"
            TranscriptDirectory = 'C:\ProgramData\JeaEndpoint\Transcripts'
            ScriptsToProcess    = @('C:\ProgramData\JeaEndpoint\startup.ps1')
            VisibleCmdlets      = "'DnsServer\*',
                @{
                    'Name'       = 'Restart-Service'
                    'Parameters' = @{
                        'Name'        = 'Name'
                        'ValidateSet' = 'Dns'
                    }
                }"
}

At one point it restarts the WinRM service, which then fails the DSC run.

VERBOSE: [SQLTEST]:                            [[JeaEndpoint]DirectResourceAccess] Restarting WinRM service
WARNING: [WSManNetworkFailureDetected] The network connection to localhost has been interrupted. Attempting to reconnect for up to 4 minutes... 
WARNING: [WSManConnectionRetryAttempt] Attempting to reconnect to localhost ... 
WARNING: [WSManConnectionRetrySucceeded] The network connection to localhost has been restored. 
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 ses
sion and retry the operation if re-executing the operation does not have undesired behavior.
    + CategoryInfo          : InvalidOperation: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : HRESULT 0x803381fa
    + PSComputerName        : localhost

Would it be better to override the restart the service, and instead allow the resource to restart the node using $global:DSCMachineStatus = 1. 🤔

[johlju]

Same problem happens when running with Start-DscConfiguration.

[rpsqrd]

I don't think we should restart the machine -- that's a lot more disruptive than just restarting WinRM. This aspect of our DSC resource is a major pain point. It's avoidable if you use a CimCession that uses the DCOM protocol, but that's obviously atypical.

[johlju]

If a CimCession that uses the DCOM protocol works, then that sounds like a solution. Do you see any other problems using that method?

Typically you use DSC to configure a node to be in a desired state from a clean state(newly deployed). There are several resources that are restarting the node when necessary to get into the correct state, so the configuration can continue after the restart. When the machine is in desired state then there will be no more restarts by this resource. Unless there are some manually intervention making the configuration not in desired state, then to get the node into desired state again, another restart might be necessary (for example if the endpoint was manually removed). If that is not desired, there could be a parameter added to the resource like Force or RestartWhenRequired to opt-in for restarts. If opt-out, then the resource (Set() method) should throw an error saying it cannot make the node in desired state.

[johlju]

Maybe I misunderstood with the CimSession, I thought you meant that the reosurce should configure the environment using a CimSession? If you meant that running the configuration using a CimSession that would probably not work since the resource should work with Chef, Puppet, running Set() manually etc. I think the resource must be able to handle this internally regardless how it's started.

[ChrisLGardner]

I'd rather have the machine reboot than have the service restart, especially with the bug in #31 being a real possibility. If the LCM isn't configured to let the machine reboot whenever it needs to then it won't and we can ensure it logs out a message saying it needs to reboot.

[jnury]

Please ! Please ! Don't make 'reboot' a mandatory thing to change something in a JEA endpoint !

We deploy JEA endpoints and reconfigure them on hundreds of live servers without any problem as:

• we use a Pull Server (so the WinRM deconnection is not a thing)
• we have a patched version of the resource that workaround the WinRM issue #30
• we are aware of issue #31 so we don't use Path resource in the same configuration as JeaEndpoint

If you plan to use a reboot instead of a WinRM restart, please let the user choose this behavior with a parameter ;-)