My question is about the scope in features. In this situation why is Name = NULL when $node.Feature can be found for the name of the feature as can cluster and node name.
I can’t see why one works and the other doesn’t it would be interesting to know why, thank you.
Also how does PowerShell know that $node is even a member of the array $AllNodes in the first place?
I imagine because the AllNodes array is set in some way by PowerShell when passed as the ConfigurationData parameter that you can’t override it within your configuration. Or, when PowerShell parses your configuration block to turn it into a .mof file, that it will only replace $AllNodes with what gets passed in via the ConfigurationData parameter. Remember, configuration blocks are a form of Domain-Specific Language (DSL) built-in to PowerShell. Although it looks like standard PowerShell, it doesn’t behave like it all the time.
If you dot-source the file above into PowerShell, you’ll get a compilation error because the FooledYouIDoNotExist module doesn’t exist. In typical PowerShell, you wouldn’t get an error about importing a missing module until you actually tried to execute it.
So, configuration blocks, though they look normal, aren’t.
If you’re interested, you can see how quite a bit of DSC’s MOF compilation code works by looking at the PSDesiredStateConfiguration.psm1 file under c:\windows\system32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\ . In this case, the automatic Node variable is based on $script:ConfigurationData (which is only set when you pass in a value for the -ConfigurationData parameter):
Even if you were to have created a variable named $ConfigurationData instead of $AllNodes, it still wouldn’t have worked, because the DSC module would not have set that value at the DSC module’s script scope.