New module Microsoft.Windows.Settings

[Gijsreyn]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

This PR introduces the new Microsoft.Windows.Settings module. The module will become responsible for configuring a variety of Windows settings without the need for separate individual modules. This addresses the overall modularization, standardization, and introduces the DSC community guidelines.

Microsoft Reviewers: Open in CodeFlow

[Gijsreyn]

Hello @denelon and @AmelBawa-msft. As an attempt to address multiple challenges, e.g., script analyzer, modularization, and standardization, this is the main module Microsoft.Windows.Settings. I recognize this PR might be quite large, but yes, it's the output Sampler generates. I've explicitly left the azure-pipelines.yml file intact, so there's a reference to how it can be built up; as you mentioned earlier, the pipelines were being reviewed.

I intend to make the module the grandfather of all Windows Settings and slowly move the other modules that have either already been released or are open for pull requests to be added in here. That way, they follow a certain standard, and we don't constantly have to use the same functions repeatedly. Of course, not all registry settings have either 0 or 1. In that case, they will be more self-contained.

P.S. Perhaps the GuestConfiguration module that also uses Sampler already gots details how to build the Azure Pipelines.

[denelon]

Thanks! I've got some discussions planned today with @AmelBawa-msft to cover the roadmap for Microsoft.Windows.Setting - I think we may want to stick with the singular name, but I'm open to whichever is best for being idiomatically correct in terms of PowerShell.

[Gijsreyn]

Awesome Demitrius. I took the plural name because as with the others that were developed already, it could contain one or more settings. In this case, it will definitely contain more settings. There isn't really a strongly encouraged development guideline for module names (only for cmdlets, it should be singular), and I also took some reference from the Az module (e.g., Az.Accounts, `Az.Resources).

I'm always open to rename it to a singular.

[denelon]

@Gijsreyn I'll ask @AmelBawa-msft to take a look as soon as he's done wrapping up what he's working on. We will have some "catch" up with all the open PRs.

[denelon]

We're definitely having some challenges thinking about the best way to organize the settings into resources. Given the Windows Settings App get updated and settings get moved around, it's tricky to think about the best way to logically organize them. What ever we decide here will be something we have to live with and support somewhat long term until we get a Windows Settings DSC v3 resource.
I'm also starting some other discussions with internal folks about the pipelines and our publishing process. @AmelBawa-msft has started reviewing the PR and getting up to speed with some of the DSC Community best practices.

[AmelBawa-msft]

I am guessing we are not using this publish right? I think that's for publishing on github but correct me if I am wrong 😊

[AmelBawa-msft]

Just thinking out loud since we are still developing resources and enhancing the process ❤️

When listing the resources in Microsoft.Windows.Developer module, each feature is resource (output below)

Get-DscResource -Module "Microsoft.Windows.Developer" | Select-Object Name

Name
----
DeveloperMode
EnableDarkMode
EnableLongPathSupport
EnableRemoteDesktop
OsVersion
ShowSecondsInClock
Taskbar
UserAccessControl
WindowsExplorer

Comparing to Microsoft.Windows.Settings, should each resource also be a feature or that would not be scalable/optimized?

Get-DscResource -Module "Microsoft.Windows.Settings" | Select-Object Name

Name
----
FindMyDevice
General

I noticed that we have two resources (from this PR) "General" and "FindMyDevice". "General" hosts several properties, one per feature, which may not be consistent with the Developer module, but that may be okay, or maybe we want to change the Developer to align with this approach (that's okay as well). Also I am curious how we should approach grouping the features/properties here, should we make our own grouping categories, or do we need to follow Windows Settings grouping? My concern with following Windows Settings is that in case they decided to make a change we may need to continue to be forward compatible with our original decision.

CC: @denelon