Group: Get-TargetResource throws with single member in group due to Type mismatch

[jrdbarnes]

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

When running Get-TargetResource on a Group with a single member, the Local Configuration Manager throws an exception, which appears to be due to a type mismatch with the resource schema.

https://github.com/dsccommunity/WebAdministrationDsc/issues/302 and https://github.com/dsccommunity/WebAdministrationDsc/issues/314 both helped point me in the right direction

Verbose logs showing the problem

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceGet,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'. VERBOSE: An LCM method call arrived from computer Server with user sid S-1-5-21-. VERBOSE: [SERVER]: [[Group]DirectResourceAccess] Invoking the function Get-TargetResourceOnFullSKU for the group Remote Management Users. VERBOSE: [SERVER]: [[Group]DirectResourceAccess] Resolving RemoteManagement_All in the domain Domain. A general error occurred that is not covered by a more specific error code. + CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimExcep tion + FullyQualifiedErrorId : MI RESULT 1 + PSComputerName : localhost

VERBOSE: Operation 'Invoke CimMethod' complete. VERBOSE: Time taken for configuration job to complete is 3.312 seconds

Suggested solution to the issue

Members = $members Members = [System.String[]]$members I have tested this solution on the machines generating the error, and it has resolved the bug.

I don't understand quite why this works though, as I would have thought the LCM would be able to cast the String to a String Array easily?

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

$InvokeParams = @{Name = 'Group'; Method = 'Get'; Property = @{groupname = 'Remote Management Users'}; ModuleName = @{ModuleName = 'C:/ProgramData/PuppetLabs/puppet/cache/lib/puppet_x/psdscresources/dsc_resources/PSDscResources/PSDscResources.psd1'; RequiredVersion = '2.12.0.0'}}
Invoke-DscResource @InvokeParams -Verbose

The operating system the target node is running

OsName : Microsoft Windows Server 2019 Standard OsOperatingSystemSKU : StandardServerEdition 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

Name Value PSVersion 5.1.17763.2931 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.17763.2931 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)

2.12.0.0

[jrdbarnes]

I've just found https://github.com/dsccommunity/xPSDesiredStateConfiguration/pull/701 which shows a much nicer fix put in place in xPSDesiredStateConfiguration. I will leave this open, as the bug still exists in this module, and it may be useful for someone else with the same error.

[danmetzler]

What is the status of this then? Will it be fixed here also because of the dsccommunity/xPSDesiredStateConfiguration#701, or is this waiting for a pull request? (I see the fix to xPSDesiredStateConfiguration has been sitting there for over a year.)