Migrate Intune LAPS to new Settings Catalog Cmdlets

[FabienTschanz]

Pull Request (PR) description

This pull request does the following:

• Fixes an issue in Test-M365DSCParameterState that prevents it from dealing with desired values that are $null
• Fixes a couple of minor issues when dealing with setting catalog policies and values, especially the definitions
• Migrates the Intune LAPS resource to the new cmdlets for improved stability

This Pull Request (PR) fixes the following issues

None.

[NikCharlebois]

Why are we changing the type here, can't we cast to Boolean and keep the same type in the schema? Changing a type, even if there is a value map, could result in a breaking change.

[FabienTschanz]

@NikCharlebois The reason for that is because Export-IntuneSettingCatalogPolicySettings returns the values for the corresponding property based on the definition of the property in the settings catalog schema. The definition for PasswordExpirationProtectionEnabled is a StringSettingValue with true and false. Leaving the data type like that in the schema without a manual cast to Boolean would result in an incorrect configuration that cannot be compiled to MOF again. But to minimize any custom configuration in the logic, I disregarded a cast to Boolean, because it would only make the logic far more complex than a schema change for practically the same values (but strings and not Boolean).

Your concerns were my concerns as well, that's why I checked with a previously exported configuration and applied that with the new logic. Previously, since booleans were exported, and booleans are either True or False, they will implicitly be casted to the appropriate string value, matching the specified ValueSet in the schema and parameter definition. From that side, there is no breaking change possible.

Example: $True as a string is True, and $False is False. Both of these strings match the ValueSet, since PowerShell is case-insensitive.

Real example of a configuration:
PasswordExpirationProtectionEnabled = $True; will be compiled into PasswordExpirationProtectionEnabled = "true";

[FabienTschanz]

@NikCharlebois Any news? I honestly don't expect any disruption because the types are compatible with each other. But if you absolutely want me to leave the type, I can do that too, but when we want to align the resources, we should stick to a generalized approach wherever possible.

[FabienTschanz]

@NikCharlebois Can you please review the PR or tell me what to do? I have other PRs that are somewhat depending on the decision if we merge this one like it is or not. Thank you.

[NikCharlebois]

Since this is a breaking change, we need to follow the breaking change policy.

https://microsoft365dsc.com/concepts/breaking-changes/

This means that this PR cannot be merged until the first release of October to ensure minimal disruption on the customers.

[FabienTschanz]

@NikCharlebois I disagree. The handling of the type (strings with true and false vs boolean) is identical, as proven by the example I gave earlier. But if you absolutely want it that way, I can change the implementation to still use the boolean type. Do you want me to do it that way?

Or I can prove it to you with some real examples that there is no disruption with the updated MOF definition.

[NikCharlebois]

Agreed, but there are other more complex scenarios we always need to account for. Lots of customers are taking monthly snapshots (export) of their environment and running a discrepancy report over time. This would now start generating drifts where at some point it was equal to $false then later became "false"

[FabienTschanz]

@NikCharlebois I reverted the breaking changes and added a small workaround that works with the string values behind the scenes. There shouldn't be any more issues now.