Fabien Tschanz

@ykuijs That is because IntuneEnrollmentPlatformRestrictions policies, specifically for Android enrollment policies, there can *two* resources be created: One for the `android` platform and one for `androidForWork`. Both have identical display...

@ykuijs As far as I remember, originally, the enrollment platform restrictions were policies, where one would specify the settings for all platforms in the same policy, like the default policy...

Thank you @ricmestre for the explanation. That's exactly what I intended to say, seems like my point didn't get across well enough. Sorry about that.

@ricmestre I fixed the searching by displayname you mentioned if the Identity is not found by additionally querying the `platformType` property. That way, only one policy will be found. ```powershell...

Okayyy, so let's sum things up for the moment: - The current implementation works if we change the Key in the MOF definition to the Identity and remove it from...

> > Wasn't looking at your code, just figuring out the issues I found with the current code but yeah that would fix it and yes we need to ensure...

I understand both ways and I'm fine to implement both variations, whichever option is selected. In my opinion, the overhead won't be as much as what's currently estimated, but we...

@ykuijs Currently, one resource in DSC creates one policy in Intune, except for Android, there are two resources necessary with the same display name. That's also what option 1 would...

@GeldHades27355 We are doing it pretty much the same way as @adhodgson1, but with Bicep instead of Terraform. For more granular authentication, we have different service principals for different workloads,...

@GeldHades27355 Terraform and Bicep are tools to manage the state of your infrastructure, in my case that's the management of the service principals, certificates, Key Vault, Automation Account and more....