Open FabienTschanz opened 3 months ago
Thanks @FabienTschanz, love the idea of a whitepaper. I agree with you that the Intune catalog keeps increasing in complexity and that taking a breather to properly document the process is something that should be done. Happy to circulate this internally with the Intune team for feedback.
@NikCharlebois Glad to hear you are interested in the idea of a whitepaper. I prepared something the like for now in the form of a blog post, which could be published in the Microsoft365DSC blog, but I'll adapt to whatever you guys think is best in the way of publishing and format.
Please let me know about the details in what form you'd like to have it and where, if possible, I can share it for feedback and more information (if necessary). Would love to take a deeper look into the Settings Catalog, and maybe we can all work together to improve some things that aren't quite right at the moment.
Looking forward to the collaboration 😄
I'd also love some kind of documentation on this, but probably Intune team should also be made aware that adding almost infinitely recursive properties, through the Children property, deep inside each type of settings catalog policy is not fun if you want to use them with config as code, in this case through M365DSC.
@ricmestre Totally agree, that thing was such a pain to debug and build... I got it working with all my testing, and I hope there isn't a change in the near future, otherwise we might be in a hell of hurt 😅
@NikCharlebois Do you already have some idea on how the whitepaper should be structured or received feedback from the Intune team?
@ykuijs @NikCharlebois @andikrueger @William-Francillette
As you might know, I am the one who updated (almost) all of the Intune resources that require the settings catalog. This meant writing code for the resource generator that generates the .psm1 and .mof files, as well as the handling of the properties when specified in a configuration and then gets sent back to Microsoft Graph. Some of those cmdlets include:
Resource Generator:
Get-SettingsCatalogSettingDefinitionValueDefinition
Get-SettingsCatalogSettingDefinitionValueOption
Get-SettingsCatalogSettingDefinitionDefaultValue
Get-SettingsCatalogSettingDefinitionValueType
New-SettingsCatalogSettingDefinitionSettingsFromTemplate
New-ParameterDefinitionFromSettingsCatalogTemplateSetting
M365DSCDRGUtil:
Get-IntuneSettingCatalogPolicySetting
Get-IntuneSettingCatalogPolicySettingInstanceValue
Get-IntuneSettingCatalogPolicySettingDSCValue
Export-IntuneSettingCatalogPolicySettings
As the settings catalog grows and more policies are converted over, the logic gradually increases, making the handling of those settings even more complex. Multiple entries with the same id or entire duplicate setting subtrees are just scratching the surface of what's there to encounter.
Because it's currently probably only me that knows a fair share of the settings catalog and its quirks, I am thinking about creating an entire Whitepaper of what the settings catalog is, how it is structured, what the specific types, settings, collections etc. are and how that thing is managed. This is mainly for me to have a well written documentation of how this all plays together, but it would also serve the purpose of distributing knowledge across us fellow Contributors and you, the code owners.
What do you think of it? Please let me know.
PS: I am currently working on the settings catalog policy for Device Control (Endpoint Security --> Attack Surface Reduction), which includes some nasty surprises that we didn't yet encounter, like an array of settings that can't simply be written as normal parameters but instead require an entirely new type to be created. This Whitepaper would also serve the purpose of taking off pressure from myself as the only one who knows how that thing works and share a better understanding.
Maybe there is somebody on the internet out there who has better ideas than I do. Then I would be very glad to have that one onboard and share ideas on how to improve the current implementation.