Open begna112 opened 4 years ago
Hi @begna112 - thanks for raising this and apologies for the very long delay in getting back to you. The Set-StrictMode
setting was added to the PSDscResource
and xPSDesiredStateConfiguration
to ensure the PS code within the resource was of high quality and reduce bugs. However, as you point out this does result in any code executed by the Script resource to also adhere to this convention - specifically in your examples that variables are declared before use.
Because the PSDscResource
module must remain feature compatible with the in-box PSDesiredStateConfiguration
module, it won't likely have any new parameters added to it. This is not the case for the community maintained xPSDesiredStateConfiguration
module.
One of the goals moving from PSDesiredStateConfiguration to PSDscResources was to minimize impact, but due to the nature of the move (lots of code was improved and bugs fixed) some DSC config changes was going to be possible. However, it was understood that some configs would require minor changes.
The move away from Set-StrictMode
for this module and the xPSDesiredStateConfiguration
isn't likely to be done due to the increased difficulty in maintaining a high quality.
However, installing PSDscResources
onto a machine should not cause it to be replaced throughout as long as you've specified the resource module to import in your DSC config unless you installed the module to $PSHome
(https://docs.microsoft.com/en-us/powershell/scripting/dsc/configurations/import-dscresource?view=powershell-5.1). Can you check you're installing these modules into a location where they won't be automatically imported by PS DSC?
Because the
PSDscResource
module must remain feature compatible with the in-boxPSDesiredStateConfiguration
module, it won't likely have any new parameters added to it.
If that is the case, why would you change the Strict Mode setting? These changes are specifically breaking compatibility with PSDesiredStateConfiguration
in Script resources, and possibly in others, like the Registry resource example above. (It's been so long since I tested that, but I'm fairly certain that it worked as expected without Force
, evaluating as True
when the value was already correctly set. Whereas with Strict Mode, it gave the error.)
Can you check you're installing these modules into a location where they won't be automatically imported by PS DSC?
Modules/DscResources are installed in C:\Program Files\WindowsPowerShell\Modules\
.
This will most likely not change in this module, but for the xPSDesiredStateConfiguration we could move the strict check to the unit tests so strict mode is checked during the test phase, and so it is not used during runtime. Suggest opening an issue in the repo for xPSDesiredStateConfiguration so it can b tracked, and then please send in a PR to xPSDesiredStateConfiguration that make the correct changes to the unit tests and code.
TLDR: PSDscResources should disable StrictMode in all of its Resources and optionally create parameters in them to enable this setting.
Details of the scenario you tried and the problem that is occurring
I recently needed to write some new Configurations and discovered that PSDscResources was the successor to PSDesiredStateConfiguration and xPSDesiredStateConfiguration. I wrote the new Configurations with PSDscResources and updated one or two (but not all) others to use it as well.
I deployed these changes to a test server (let's call this
Host1
) and had no issues until I provisioned a new host (Host2
). OnHost2
, suddenly many of my long-stable Mofs were failing to apply, whileHost1
had no issues.Only by removing the compliant settings on
Host1
so that the TestScripts would return$false
, was I able to replicate my issues fromHost2
.Some notes:
Set-StrictMode -Off
in the Test and Set bypassed the issue. This option is not available from other Resources such as Registry.Thankfully, uninstalling the PSDscResources Module returned my Mofs to working as expected on both
Host1
andHost2
.After some more research, I found that this behavior is due to
Set-StrictMode -Version 'Latest'
in every PSDscResources Resource. See below for logs and example Configurations.Verbose logs showing the problem
Some individual lines and their accompanying code that caused the error:
The DSC configuration that is used to reproduce the issue (as detailed as possible)
Both of the examples below failed regardless of which module was imported, as long as PSDscResources was installed. Both executed successfully with expected results before using PSDscResources.
Example1:
Error:
Example2:
Error:
Suggested solution to the issue
From what I can tell, no version of Powershell has StrictMode on by default. See documentation here.
This means that for any reasonable person working with Powershell on a regular basis, they would likely not be accustomed to writing scripts to confirm to StrictMode. Instead, many are likely writing code that works in the default PS environment, not necessarily what is perfectly correct.
Additionally, StrictMode was not originally on by default except for a few files (
CompositeResourceHelper, GroupResource, UserResource, RunAsHelper
). And it is explicitly disabled inPSDesiredStateConfiguration.psm1
.For someone migrating from PSDesiredStateConfiguration to PSDscResources, this behavior of defaulting to
Set-StrictMode -Version 'Latest'
is a breaking change. This will prevent others like myself from migrating to PSDscResources due to the effort required to revalidate and redeploy a potentially large number of DSC Mofs. If PSDscResources did not override PSDesiredStateConfiguration system-wide, then this might not be such a large issue as the work could be done one Configuration at a time, but that is not the case.Finally, I would argue that StrictMode being enabled is plainly non-standard for Powershell. It is a nice option, but should not be the default and definitely should not be a forced default.
PSDscResources should disable StrictMode in all of its Resources and optionally create parameters in them to enable this setting.
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 ('dev' if using current dev branch)
2.12.0.0