-
Notifications
You must be signed in to change notification settings - Fork 60
Register-PSSessionConfiguration causes WinRM service hanging in state 'stopping' #30
Comments
@PaulHigin: are you aware of problems in Register-PSSessionConfiguration/WinRM that could explain this behavior (and issue #31 ) ? |
/cc @manojampalam for the WinRM aspects Thanks for reporting these issues, Julien. I've seen this behavior a few times, but nowhere near as frequently or consistently as you are describing. Have you seen this behavior on 2008 R2 / 2012 / 2016 as well, or just 2012 R2? |
For now, I only deployed my configuration on 85 hosts, but only on Windows 2012 R2. |
This bug repeated consistently on 2016, I worked around it by putting the call to Register-PSSessionConfiguration within a PSJob, waiting for 10 seconds, setting $global:DSCMachineStatus = 1 at the end of the set block. I will try and make my code a bit cleverer and then post it |
@djwork : what about calling Register-PSSessionConfiguration within a PSJob and entering a loop until the job is OK or a timeout of, say 30 seconds, is expired. While in the loop, if the service is 'stoping' for more than, say 5 seconds, we run the 'force restart' script I mentioned above ? It would be quite safe as the WinRM isn't left hanging, other services running with the same process are restarted as well and the resource would be compliant at first run. Of course, patching WinRM to avoid hanging would be the best solution ;-) |
@jnury [DscResource()]
} |
Hi all, As I've done a 'lot' of refactoring and would appreciate a code review before filling a PR ;-) This is what I've done:
|
@manojampalam |
We are looking into this now and will follow up. |
Hello @manojampalam, any news ? The workaround shipped in PR #46 is really 'heavy' ... but it was triggered on half of my last deployments, so it's really useful. Hope you can fix the WinRM restart problem directly in the WinRM service and we can remove the workaround some day. If it helps: on some of my hosts, it seems that the LanmanWorkstation service (which is co-hosted in the same process as WinRM) ended on an error while WinRM restarted after Register-PSSessionConfiguration. |
Hello guys |
Hi jnury, I am Chenming YU, who works with Manoj for WinRM area in Microsoft. Based on the symptom of you situation, I suspect it is similar with one case in past, which the pending action of winrm hang in dsctimer wakeup activities. (hosted inside winrm service). To checked whether wakeup of dsctimer is activated within WinRM: -
if still repro with those workaround, please chat me with the memory dump of the pending winrm service (svchost.exe, via Taskmgr >> marked process >> "create dump file") |
Hi @cmyu-gh, it seems I missed your answer, sorry for that. I'm not able to use Start-DSC* with -Force as I use the Pull mode, so the configuration is automatically triggered. Will the second option apply to Pull mode as well or is it only for the Start-DSC* commands ? |
sorry about the late response, in your situation, can You check the below regvalue on the repro machines, : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System:DSCAutomationHostEnabled if it is '1' or ('2' and %windir%\system32\Configuration*mof existed), then it might prove my suspect on dsctimer plugin of WinRM. otherwise, can you forward me the repro dump of winrm service in hang for advance analysis. in case of pull control on your case, there is a workaround in directly stop dsctimer plugin within winrm (the effect needs steprestart-service winrm)
**please ignore 2nd option posted before, it is force cimsession protocol via DCOM instead of WinRM -- switch set in some management cmdlets. |
Note, this is still an issue on PowerShell 5.1 on Windows 2019 |
Hi,
I use DSC to deploy JEA configuration on many Windows Server 2012 R2 hosts:
About 3 times out of 4, when Register-PSSessionConfiguration is triggered by the DSC module, WinRM service is restarted but hangs on Stopping.
It seems to happen more frequently when the configuration causes WinRM to change Logon As (from Network Service to Local System).
Is there a 'correct' way to avoid this behaviour ?
We use the following script to force restart WinRM service (with SCCM as we lost PS remoting ability on host):
Should-we add WinRM restart problem detection/mitigation directly in the DSC resource ? I can provide a PR for that (with a less verbose code ;-))
The text was updated successfully, but these errors were encountered: