Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RegistryPolicyFile: registrypolicyfile parser returns unsupported valueType for dword and qword resources #34

Open
chambersmp opened this issue Oct 24, 2023 · 2 comments · May be fixed by #35

Comments

@chambersmp
Copy link

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

The DSC wrapper module for gpregistrypolicydsc experiencesconstant corrective changes and warnings when managing reg_dword resources due to a case mismatch in the GPRegistryPolicyFileParser.psm1 and the valuemap within the resources schema file.

The GetRegTypeString() method in GPRegistryPolicyFileParser.psm1 is returning the the following unsupported values:

  • 'DWord'
  • 'QWord'

The expected values should be:

  • 'Dword'
  • 'Qword'

The file parser should output values aligned with the resource's schema file:
MSFT_RegistryPolicyFile.schema.mof

[Write, Description("Indicates the type of the value."), ValueMap{"Binary","Dword","ExpandString","MultiString","Qword","String","None"}, Values{"Binary","Dword","ExpandString","MultiString","Qword","String","None"}] String ValueType;

Verbose logs showing the problem

During a Puppet run, the dsc_registrypolicyfile resource generates warnings the existing registry file valuetype has been set to DWord. The schema expects this value to resolve as Dword

Warning: Provider returned data that does not match the Type Schema for `dsc_registrypolicyfile[Remove access to use all Windows Update features (Configure notifications)]`
Value type mismatch:
   * dsc_valuetype: DWord (expects an undef value or a match for Enum['Binary', 'Dword', 'ExpandString', 'MultiString', 'None', 'Qword', 'String'], got 'DWord')

Suggested solution to the issue

Update the GetRegTypeString() method in GPRegistryPolicyFileParser.psm1 to return the correct valuetype's aligned with the resource schema mof file.

  1. RegType REG_DWORD should output Dword instead of DWord.
  2. RegType REG_QWORD should output Qword instead of QWord.

Original:

    [System.String] GetRegTypeString()
    {
        [System.String] $result = ''

        switch ($this.ValueType)
        {
...
            ([RegType]::REG_DWORD)
            {
                $Result = 'DWord'
            }
...
            ([RegType]::REG_QWORD)
            {
                $Result = 'QWord'
            }
            default
            {
                $Result = ''
            }
        }
        return $result
    }

Updated:

    [System.String] GetRegTypeString()
    {
        [System.String] $result = ''


        switch ($this.ValueType)
        {
...
            ([RegType]::REG_DWORD)
            {
                # Return Dword instead of DWord
                $Result = 'Dword'
            }
...
            ([RegType]::REG_QWORD)
            {
                # Return Qword instead of QWord
                $Result = 'Qword'
            }
            default
            {
                $Result = ''
            }
        }
        return $result
    }

Version of the DSC module that was used

Version 1.2.0.

@johlju @PlagueHO @gaelcolas @danielboth @jcwalker
Please review and assist where possible, should be a simple matter of swapping from upper to lower case for the affected characters.

chambersmp added a commit to chambersmp/GPRegistryPolicyDsc that referenced this issue Oct 24, 2023
@johlju
Copy link
Member

johlju commented Oct 29, 2023

Since PowerShell normally is doing case-insensitive matching this is usually not an issue. If this cannot be resolved at the Puppet side, I suggest to avoid getting a regression that the resource (not the helper method of the class) should just output the value in either upper-case or lower-case depending on what is most appropriate. Add a unit test that validates that the resource actually always returns all values correctly. There should also be a unit test that also checks the MOF file so that the values there are not changed from either lower-case or upper-case (depending on the previous choice in the code).

@chambersmp
Copy link
Author

chambersmp commented Nov 6, 2023

@johlju Thanks for reviewing this issue and the PR #35. I'll review the code to see if the suggestion is possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants