Details of the scenario you tried and the problem that is occurring
Working to map the DSC Resources in this module for Puppetization requires being able to load the cim class for each resource and introspect on its properties - this is the most accurate way to programmatically map a DSC Resource, including fully mapping nested CIM instances.
The way we do this is first, make a dummy call to Invoke-DscResource to ensure the CIM class we want to introspect is loaded, like so:
$InvokeParams = @{
Name = 'xRDServer'
Method = 'Get'
Property = @{foo = 1}
ModuleName = @{
# Path to the module on disk
ModuleName = 'C:\dsc\...\xRemoteDesktopSessionHost\xRemoteDesktopSessionHost.psd1'
ModuleVersion = '2.0.0'
}
ErrorAction = 'Stop'
}
Try {
Invoke-DscResource @InvokeParams
} Catch {
# We only care if the resource can't be found, not if it fails while executing
if ($_.Exception.Message -match '(Resource \w+ was not found|The PowerShell DSC resource .+ does not exist at the PowerShell module path nor is it registered as a WMI DSC resource)') {
$PSCmdlet.ThrowTerminatingError($_)
}
}
# Then we can check the DSC namespace for the expected class:
Get-CimClass -ClassName 'MSFT_xRDServer' -Namespace 'root\Microsoft\Windows\DesiredStateConfiguration'
The final line above errors like so:
writeErrorStream : True
PSMessageDetails :
OriginInfo :
Exception : Microsoft.Management.Infrastructure.CimException: Not found
at Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext
callbackProcessingContext, T currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle errorDetailsHandle)
TargetObject : root\Microsoft\Windows\DesiredStateConfiguration:MSFT_xRDServer
CategoryInfo : ObjectNotFound: (root\Microsoft\...:MSFT_xRDServer:String) [Get-CimClass], CimException
FullyQualifiedErrorId : HRESULT 0x80041002,Microsoft.Management.Infrastructure.CimCmdlets.GetCimClassCommand
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}
And we can see if we filter the DSC namespace for classnames matching xrd that it is indeed not loaded:
Notably, this worked fine for xRDCertificateConfiguration, xRDGatewayConfiguration, xRDRemoteApp, and xRDLicenseConfiguration before failing to load the CIM class for xRDServer. I reworked the catch/throw block to write the error anyway and in all cases the error message was the same - could not find RemoteDesktop module - but the other CIM classes still loaded into memory.
Not sure offhand how to hunt this one down but I wanted to at least raise it - of more than 50 modules so far converted, this is the only module we've encountered this problem with.
The operating system the target node is running
OsName: Microsoft Windows 10 Pro
OsOperatingSystemSKU: 48
OsArchitecture: 64-bit
WindowsVersion: 1909
WindowsBuildLabEx: 18362.1.amd64fre.19h1_release.190318-1202
OsLanguage: en-US
OsMuiLanguages: {en-US}
Version and build of PowerShell the target node is running
Details of the scenario you tried and the problem that is occurring
Working to map the DSC Resources in this module for Puppetization requires being able to load the cim class for each resource and introspect on its properties - this is the most accurate way to programmatically map a DSC Resource, including fully mapping nested CIM instances.
The way we do this is first, make a dummy call to
Invoke-DscResource
to ensure the CIM class we want to introspect is loaded, like so:The final line above errors like so:
And we can see if we filter the DSC namespace for classnames matching
xrd
that it is indeed not loaded:Notably, this worked fine for xRDCertificateConfiguration, xRDGatewayConfiguration, xRDRemoteApp, and xRDLicenseConfiguration before failing to load the CIM class for xRDServer. I reworked the catch/throw block to write the error anyway and in all cases the error message was the same - could not find RemoteDesktop module - but the other CIM classes still loaded into memory.
Not sure offhand how to hunt this one down but I wanted to at least raise it - of more than 50 modules so far converted, this is the only module we've encountered this problem with.
The operating system the target node is running
Version and build of PowerShell the target node is running
Version of the DSC module that was used
2.0.0