Question about Repair-DSCEngine function

[CJHarmath]

Hi,

While browsing the code I've noticed the function Repair-DSCEngine which is actually killing all DSC engine host processes. And not only that, but it's being called 10 times in a loop from 2 places, which is kind of weird to see without understanding the context.

Can you guys please add comments to this function explaining why is this actually necessary ?
Also I wonder what happens if there is a periodic DSC config running and you are killing the DSC engine ?
For example I have a web server which is syncing contents from a DFS share every few minutes.
Depending on the size of the content, network bandwidth, etc this can take some time.

Ideally an analyzer would be free from side affects, so I just want to make sure I understand how safe is it to kill the DSC engine's process / what are the potential side effects and in general why is this necessary ?

for ($i=1; $i -lt 10; $i++) { 
    Repair-DSCEngine -ComputerName $computer -ErrorAction SilentlyContinue
}

do {
    $processID = Get-Process -Id $dscProcess
    $processID | Stop-Process -Force}
while ($processID.ProcessName -match "WmiPrvSE")

Thanks!

[rkyttle]

Repair-DSCEngine and the calls to kill the DSC engine are related to the Force parameter that is part of Start-DSCEAscan. We can certainly add in more comments to the code about this. This code is only called when the Force parameter is used, and it is provided to handle scenarios where the LCM on a system is busy processing a standard consistency check. If a system is already busy running a consistency check, DSCEA cannot check its status so we included the Force option to kill the LCM first before attempting a scan. The reason for the looping and multiple calls is that we found that the LCM does not always kill the existing consistency check from just one attempt, so we call it multiple times to ensure that DSCEA can succeed. Again, this is not the default mode, running DSCEA will not perform this action unless Force is specified.

[rkyttle]

https://microsoft.github.io/DSCEA/mydoc_scan.html also references the Force flag.

By default, DSC comes in the mode Apply and Monitor. This means a configuration will continue to attempt to apply to a system until it successfully completes, and then every 15 minutes the LCM wakes up and performs a consistency check. As the LCM can only handle one operation at a time, if the LCM is busy with this built in consistency check, DSCEA will be unable to scan the system. If the configuration has successfully applied and is now in this Monitor phase, there shouldn't be any negative impact to killing the LCM to allow us to attach with another process. An alternative to this would be updating the LCM to Apply Only mode, which would prevent the LCM from becoming busy due to the consistency checks. Again, Force is not enabled by default, and should not be used unless it is needed to troubleshoot scanning issues.

[CJHarmath]

Thanks for the detailed explanation Ralph Kyttle (@rkyttle) and sorry for the slow response!

Perhaps there could also be a check for the LCMState if it's idle.
If not then wait / retry for a while in the normal case.
Unless the -force is specified in which case kill the DSC host process and proceed.

I was trying to reproduce a case when running a long operation such as copying many files by the File resource and run the DSCEA but it didn't seem to terminate the file resource's process when ran the DSCEA scan with force, so I am not really sure under what circumstances would this happen / how to reproduce.
One case I can think of is when the DSC config fails due to a file lock, etc then it will stuck in pending state.

I would just try to avoid an analyzer scan to interfere with an active configuration process otherwise scanning the environment is not guaranteed to be side effect free.