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.

dsccommunity/WebAdministrationDsc#302 and dsccommunity/WebAdministrationDsc#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 dsccommunity/xPSDesiredStateConfiguration#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.)