Commands config get and config test invokes depended on resources

[haodeon]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Summary

I am having an issue with resources that define dependsOn being invoked despite the resource they depend on not being in the desired state.

The reason being, PSDSC resources like WebAdministrationDsc depend on cmdlets being available when IIS is installed but IIS is not installed yet when config test is run.

When I test how config set works, it performs resource configuration in the required order as defined by dependsOn and it works mostly.

The documentation says the dependsOn property defines "a list of DSC Resource instances that DSC must successfully process before processing this instance" but it's not clear to me what the definition of success is. Especially in terms of the config test command, is it the test passing or just that the test can execute sucessfully?

Steps to reproduce

Create the following configuration document

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/v3.0.0/config/document.json
resources:
  - name: Install IIS
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Install IIS
          type: xPSDesiredStateConfiguration/xWindowsFeature
          properties:
            Name: Web-Server
            Ensure: Present
  - name: Web server installed
    type: Microsoft.DSC/Assertion
    properties:
      $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
      resources:
        - name: Use powershell adapter
          type: Microsoft.Windows/WindowsPowerShell
          properties:
            resources:
              - name: IIS present
                type: xPSDesiredStateConfiguration/xWindowsFeature
                properties:
                  Name: Web-Server
                  Ensure: Present
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS')]"
  - name: Harden IIS
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Disable directory browsing
          type: WebAdministrationDsc/WebConfigProperty
          properties:
            WebsitePath: 'MACHINE/WEBROOT/APPHOST'
            Filter: 'system.webServer/directoryBrowse'
            PropertyName: 'enabled'
            Value: 'false'
    dependsOn:
      - "[resourceId('Microsoft.Windows/WindowsPowerShell', 'Install IIS')]"
      - "[resourceId('Microsoft.DSC/Assertion', 'Web server installed')]"

Call config test on the repro document

Expected behavior

For `dsc` to recognise either `dependsOn` has not been met and skip the `Harden IIS` resource or stop testing gracefully.

Actual behavior

The `config` test command exits abnormally with an error message.

It's understandably failing because the `Get-WebConfigurationProperty` cmdlet is not available yet until IIS is installed.

Error details

PS C:\Users\Administrator> dsc config test -f .\web.config.dsc.yaml                                                     2025-04-07T11:28:21.536876Z ERROR PID 2380: Exception: The term 'Get-WebConfigurationProperty' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
2025-04-07T11:28:21.597179Z ERROR Command: Resource 'powershell' [exit code 1] manifest description: Error
PS C:\Users\Administrator>

Environment data

PS C:\Users\Administrator> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.26100.2161
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.26100.2161
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

3.1.0-preview.2

Visuals

No response

[Gijsreyn]

Can this be related to #731, which is already solved in a PR (but has not been released yet) @haodeon?

[haodeon]

I understand there is a fix for assertions but it’s unclear to me whether assertions short circuit evaluations for config get and config test.

It’s also unintuitive to require an Assertion in order to gate a resource for get and test. Although it’s not wrong for it to be the case.

My first configs had no Assertion. I added it later when I thought it could help. I did find the assertion fix prior to opening this issue but the PR itself does not address the question of what config get and config test does with a failed assertion.

[SteveL-MSFT]

The assertion is intended to be run to verify the environment is appropriate before the config operation is run (as noted, there was a bug that didn't do this but has been fixed, will try to get a release with that fix out this week).

With other resources, execution should proceed unless a resource errors. That is if you're running test, if every resource successfully runs (regardless if any say it's already not in desired state), they should all run and return their info so you know which parts are not in desired state. get would work similarly in that as long as the resource returns successfully, they should all get run and the results returned.

[haodeon]

Thanks for the prompt responses.

From the info shared I now understand

• dependsOn only performs ordering
• Assertion is required to check dependencies even when the dependency is define in the config as a dependsOn

It sounds like the next release will solve my issue. I will test and close when I can confirm it does.

[SteveL-MSFT]

@haodeon both 6.0.2 and 6.1.0-preview.3 should have the fix so try either and close if it resolves your issue otherwise give my info if it's still an issue

[haodeon]

@SteveL-MSFT I have tried 3.1.0-preview.3 and Assertion is now fixed and gate the resource which depends on it.

The way DSC behaves by exiting with error code 2 when this happens is not ideal and I understand #737 proposes an enhancement but the result is just an error condition at the end of the run.

It would be nice if partial evaluations were allowed to proceed.

Closing this issue as fixed as this appears to be a design choice.