dsccommunity
xWebConfigPropertyLocation - For the ability to modify locked config sections
Description
xWebConfigPropertyLocation specifies the location parameter to Get-WebConfiguration so that modifications to locked config sections can be made.
Proposed properties
[Key, Description("Path to website location (IIS or WebAdministration format).")] String WebsitePath;
[Key, Description("Filter used to locate property to update.")] String Filter;
[Key, Description("Name of the property to update.")] String PropertyName;
[Key, Description("Location is used to update locked sections in the root config.")] String Location;
[Write, Description("Indicates if the property and value should be present or absent. Defaults to Present."), ValueMap{"Present","Absent"}, Values{"Present","Absent"}] String Ensure;
[Write, Description("Value of the property to update.")] String Value;
Special considerations or limitations
I considered extending xWebConfigProperty to include location, but from testing, the location would need to become a key property. This would break older uses of xWebConfigProperty by requiring an additional parameter be added.
If a property is to be written to the web.config, I believe location should not be used, hence why I generated a new resource for this specific purpose.
@geoffguynn Thanks for opening the issue. xIisFeatureDelegation is an option for unlocking config sections, but in cases where that is not a viable option, I can see the value in using the Location parameter.
However, I don't think we should have redundant resources to add one parameter because that would be a lot duplicate code. We've introduced breaking changes in the past and it would just be documented and the major version number of the module would increment. For users who did not want to use Location tag, they would need to start proviging an empty string as the value for that setting in their configurations. Otherwise, I think we should be able to incorprate Location into resources like xWebConfigProperty and xWebConfigPropertyCollection as breaking changes.
@johlju any issues introducing a breaking change to add a new Key property to xWebConfigProperty?
It is not an issue to introduce breaking changes as long as it improves the resource. Agree that in this case it is needed to not introduce duplicated code.
Sometimes it’s not possible to see every aspect of a resource when it’s first created, so breaking changes is inevitable to improve the resource module.
Curious, what is “location” in this case? I haven’t heard the term before so trying to learn :)
What is a locked configuration section? Are the locked configuration sections known so we could have a ValidateSet where one value could be ‘None’?
If the location could be any value, I understand the need for a blank value. The blank value would mean the default configuration location?
Certain properties in the web.config are by default locked to a location tag in the xml of applicationhost.config
My sample.ps1 for this resource shows one such property.
When this happens, you can add a tag in the applicationhost.config called AllowOverride=True (which is not desirable from my customer's preference) or by specifying a location paremeter that tells the cmdlet to put the setting in a Location tag in the applicationhost.config
https://docs.microsoft.com/en-us/iis/manage/powershell/powershell-snap-in-changing-simple-settings-in-configuration-sections#dealing-with-locked-sections
I got some more spare time and did testing on the "blank parameter" suggestion. Here's what I came up with.
When using location as a key param, the set, get, and test functions require it to be set mandatory, and by doing so, a blank string will not be accepted. The only way I was able to get it to work is to set a throwaway value of "None" and then filter for it when making the calls in the function. Is that an acceptable solution?