xRegistry: should not need to use the Force parameter

[fullenw1]

Details of the scenario you tried and the problem that is occurring

I am using xRegistry because unlike the native Registry resource it can handle the slash character in key names which is useful for disabling cipher suites. For example: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128 / 128

However, unlike the native Registry resource, when the xRegistry resource finds an existing registry value with different data it doesn't update the data if you don't use the Force = $true property.

If we want DSC to only detect values without modifying the data we can use the Monitor mode. On the other hand, the ApplyAndAutoCorrect mode is supposed to enforce every non-compliant value. Enforcing means we should not have to use some kind of Force parameter ... ApplyAndAutoCorrect is already supposed to be like a Force mode.

Verbose logs showing the problem

PowerShell DSC resource MSFT_xRegistryResource failed to execute Set-TargetResource functionality with error message: System.InvalidOperationException: The registry key at path HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters already has a value with the name NtpServer. To overwrite this registry key value please specifiy the Force parameter as $true.

Suggested solution to the issue

Come back to the native Registry resource behavior and make the xRegistry resource able to correct existing registry values without having to specify the Force = $true property. Possible implementations:

• Make the property True by default...
• Remove the property and enforce the value anyway...
• Other ideas...

The DSC configuration that is used to reproduce the issue (as detailed as possible)

# insert configuration here

The operating system the target node is running

OsName : Microsoft Windows Server 2019 Datacenter OsOperatingSystemSKU : DatacenterServerEdition OsArchitecture : 64-bit WindowsVersion : 1809 WindowsBuildLabEx : 17763.1.amd64fre.rs5_release.180914-1434 OsLanguage : en-US OsMuiLanguages : {en-US}

Version and build of PowerShell the target node is running

PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

xPSDesiredStateConfiguration version 8.10.0.0

[PlagueHO]

Hi @fullenw1 - you definitely make a fair point here.

PSDscResources Registry resource - the replacement for the inbox resources (https://github.com/PowerShell/PSDscResources/blob/dev/DscResources/MSFT_RegistryResource/MSFT_RegistryResource.schema.mof) also uses the Force parameter. So it might make sense to align to that module rather than the older inbox ones. If we were to change $force to default to $true then we should probably also change PSDscResources - which might not be possible (as it would technically be a breaking change - and we're not implementing breaking changes on PSDscResources).

So the question would be: Do we align the behaviour of xRegistry to PSDscResources Registry.

I'll mark this one as discussion so we can get some community input.

[mkht]

In my use case, I'm always specifying Force = $true. I have never thought it makes sense to specify $false for the Force parameter.

However, as @PlagueHO points out, changing the default value of the Force is a significant breaking change. I personally want to agree with the change, but it will be difficult. 🤔