Resolve Get-TargetResource failing for MSFT_IntuneSettingCatalogCustomPolicyWindows10

[ajkenah]

Pull Request (PR) description

This PR updates the function that generates the Settings property on the returned MSFT_IntuneSettingCatalogCustomPolicyWindows10 object as part of the Get-TargetResource function.
I've updated the property generation so that the function is creating nested CIM instance objects instead of hash tables.

This Pull Request (PR) fixes the following issues

Get-TargetResource for MSFT_IntuneSettingCatalogCustomPolicyWindows10 fails because the LCM can't handle nested hash tables after a depth of around two or three. This is a known issue with the LCM and its inability to assign nested objects to match the schema if the object is nested too deep.

Details are captured in Issue #6092

Task list

• Added an entry to the change log under the Unreleased section of the file CHANGELOG.md.
  Entry should say what was changed and how that affects users (if applicable), and
  reference the issue being resolved (if applicable).
• Resource parameter descriptions added/updated in the schema.mof.
• Resource documentation added/updated in README.md.
• Resource settings.json file contains all required permissions.
• Examples appropriately added/updated.
• Unit tests added/updated.
• New/changed code adheres to DSC Community Style Guidelines.

[ajkenah]

@microsoft-github-policy-service agree

[ajkenah]

I seem to have an issue with deploying one of my Setting Catalog's. Putting this back into draft while I work out what's going on.

[ajkenah]

It looks like the Rename-M365DSCCimInstanceParameter function isn't renaming the odataType property on the nested Settings (during Set-TargetResource). I suspect that's causing the issue I'm seeing. Let me confirm, and if so I'll raise another issue for it and link to this PR too.

[FabienTschanz]

@ajkenah I already have a PR open that fixes an issue with exactly this function, see #6747. Do you want to check with the updated code from that PR?

[ajkenah]

@ajkenah I already have a PR open that fixes an issue with exactly this function, see #6747. Do you want to check with the updated code from that PR?

Sounds good! I'll check it out over the next few days

[ajkenah]

Everything is working fine now. @FabienTschanz, I've tested your changes, and they work fine. The issue I was seeing however was on my side, I was pulling the odataType property from the wrong location, meaning it was missing. All fixed now.