microsoft
Replace RoleScopeTagIds with their display name
Description of the issue
Comment from @adrian-haeusser in #6434:
Additionally, we had a brief discussion with our team regarding the current implementation using the RoleScopeTagIds. The Ids of Intune Role Scope Tags are incremental (0 = Default, then counting upwards with each created Intune Role Scope Tag). This could cause issues applying configurations to tenants where "identical" Intune Role Scope Tags were created in a different order. Would an implementation where the Intune Role Scope Tag's DisplayName (which is also the key listed for the IntuneRoleScopeTag M365DSC resource) is resolved for its RoleScopeTagId possibly provide a better solution (e.g., when applying to a wide range of tenants)?
This is a very valid point - If we clone the configuration from one tenant to another where some scope tags were already existing, then their ids most likely would not match, making the mapping of the scope tag ids invalid.
The proposal is to update the export of the RoleScopeTagIds property to be the display name of the scope tag and not the id. This requires a lookup, which can be implemented with just a tiny little bit of overhead (probably not even measurable). But this would also be a breaking change.
@ricmestre What's your take on this - I think if we do that, we should do it right away to be ready for the October breaking release. An interim solution could also be that we allow "integer" and "strings" as the id, while looking up what the value is and acting accordingly to that. If it's a string, resolve the id. If it's already the id, use that.
Microsoft 365 DSC Version
DEV
Which workloads are affected
Intune
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version
I think this could be done now to be honest and not have to wait until October, I didn't check them all up but I think RoleScopeTagIds is defined as String[] in all resources right? So it could be just a matter of flipping the export to use the tag names instead of the ids by default, then when importing the policies call [Int]::TryParse by default first on each tag and if it's an integer do what it currently does, otherwise if it's actually a role scope tag name then try to search for its id using the name instead.
Another way to not mess up with the current parameter, you could add another parameter called RoleScopeTagNames which would match the already exported Ids and only use that parameter as fallback if the Ids can't be found, adding parameters is not a breaking change, I used something similar when I added RootCertificateDisplayName to MSFT_IntuneDeviceConfigurationSCEPCertificatePolicyWindows10
Yeah, but I don't feel like updating 100+ Intune resources just to add a RoleScopeTagNames. I'll probably just update it inline and do a parse check to determine if it's an integer or a display name.
yep, the easy route is just to use the same parameter, in this case like I said since it's already a string[] and you don't have to change the type then it's not a breaking change and can be done right away
Hello @FabienTschanz, I've been going through some of the previous issues I had opened and wanted to check in, whether you'd have a short update on this enhancement? Thanks for you contributions and I can understand, if this is currently not prioritized!
No update yet. The focus is currently on some higher hitting bugfixes and general "quality of life" improvements when using the module. I have some ideas on how to implement your idea though, but it will probably take a couple more weeks to be ready.