Powershell: Dsc just doesn't work

Created on 5 Mar 2020  路  4Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

Open pwsh 7 and look for Dsc Resources (see screenshot)

Get-DscResource

Expected behavior

Return OOB DSC Resources (PSDesiredStateConfiguration)

Actual behavior

returns a warning saying there are no resources, yet in pwsh 5 there are.

Environment data

windows 10 x64

image

Area-DSC Issue-Question

All 4 comments

Weird. This works OK here;

PS C:\foo> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 10.0.19569
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0, 6.1.0, 6.2.0, 7.0.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS C:\foo> Get-DscResource  | ft name

Name
----
Archive
Environment
File
Group
Log
Package
Registry
Script
Service
SignatureValidation
User
WaitForAll
WaitForAny
WaitForSome
WindowsFeature
WindowsOptionalFeature
WindowsProcess

@doctordns are those from the OOB Dsc Resource, PSDesiredStateConfiguration? can you do Get-DscResource | Format-Table -Property Name, ModuleName?

@tomohulk I'm able to find the OOB resources, but _only_ the OOB resources:

Get-DscResource | Format-Table -Property Name, ModuleName, ParentPath
Name                   ModuleName ParentPath
----                   ---------- ----------
Archive                           C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_ArchiveResource
Environment                       C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_EnvironmentResource
File                              C:\WINDOWS\system32\Configuration\Schema\MSFT_FileDirectoryConfiguration
Group                             C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_GroupResource
Log                               C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_LogResource
Package                           C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_PackageResource
Registry                          C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_RegistryResource
Script                            C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_ScriptResource
Service                           C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_ServiceResource
SignatureValidation               C:\WINDOWS\system32\Configuration\BaseRegistration
User                              C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_UserResource
WaitForAll                        C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_WaitForAll
WaitForAny                        C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_WaitForAny
WaitForSome                       C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_WaitForSome
WindowsFeature                    C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_RoleResource
WindowsOptionalFeature            C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_WindowsOptionalFeature
WindowsProcess                    C:\WINDOWS\system32\WindowsPowershell\v1.0\Modules\PsDesiredStateConfiguration\DscResources\MSFT_ProcessResource

This appears to be happening in PowerShell 7.0, in the PSDesiredStateConfiguration.psm1 file, line 3848. I think the following:

$listPSModuleFolders = $env:PSModulePath.Split(":")

should be:

$listPSModuleFolders = $env:PSModulePath.Split([IO.Path]::PathSeparator)

It appears the nix path separator was used, so when the module is run on Windows it breaks in the path segments and not at the path seperators. It works for built-ins, because Get-Childitem will complete the path for '\WINDOWS\system32\WindowsPowerShell\v1.0\Modules', but the user level directories will have a ; left at the end making the path invalid. Line 3864 supplies an Ingore to ErrorAction, so these silently fail.

PS C:\Users\james> $env:PSModulePath.Split(":")
C
\Users\james\Documents\PowerShell\Modules;C
\Program Files\PowerShell\Modules;c
\program files\powershell\7\Modules;C
\Program Files\WindowsPowerShell\Modules;C
\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

I would have linked to files directly, but could not find a public source for PSDesiredStateConfiguration.psm1, or a place to file a PR. I have 2.0.5 locally.

Was this page helpful?
0 / 5 - 0 ratings