-
Notifications
You must be signed in to change notification settings - Fork 532
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test-DSCResource failing with call depth overflow #5762
Comments
At that point why not just use the regular Settings Catalog? There's no point in having another one almost the same, and uber complex as Settings Catalog already is, unless you made one that under the hood was a Settings Catalog policy but you used simpler properties and values for it like a few policies that we have today and where this is done. |
It's for a policy our client wants to export, to be fair I have it working for what they need, but I assumed to get the module accepted it'd have to support all the setting? I can certainly reduce the scope if that's acceptable? |
Although re-reading that I'm not fully sure I get what you mean? I started on the module as the policies I wanted weren't exporting/supported by existing modules, but yeah, it has opened a bit of a can of worms it seems... |
@ricmestre I don't think there is a resource that contains the regular Settings Catalog capability. All the other resources are based on templates from the Settings Catalog, so they have their properties available by definition in the template. That's not the case for the regular policies, they are fetched dynamically by a way I wasn't able to reproduce unfortunately. @dannyKBjj Attached is my version a little bit updated to match the latest changes from Microsoft365DSC. I didn't find any issues whatsoever during |
I made the question not to detract the inclusion of this resource, the reason I asked is because my customers expect to have support teams using markdown files to deploy changes (not blueprints) and I was never able to make the current Settings Catalog policy to work, and kinda gave up on it already to be honest, so I just dump the Settings property from the blueprint as-is into the markdown file and then it's business as usual like modifying a blueprint which even I cannot make anything of it because I don't know what those properties and values are or do. There's this project on GH [0] which has some spreadsheets which might help a bit but also doesn't tell you what the properties do but the files there are not updated regularly anyway so... Then seeing yet another monstrosity added to the project gives me yet more nightmares!!! @dannyKBjj This is not your problem, I'm just baffled at how the Intune team were able to create something with potentially infinite nested levels of properties, it may work in the backend but no one will actually use this in a configuration-as-code scenario, except for maybe exports but definitely not deployments. |
Yeah, indeed, although it kind of is my problem, because the client wants to M365DSC to support it for iOS. I've defined a recursive object structure in my mof and from my testing so far it seems capable of correctly exporting, testing and setting. I can't say I've been through all 15 areas yet, but so far the structure seems good. The catch seems to be that if I have more than one policy defined in the M365TenantConfig.ps1 I run into the 'call depth overflow'. I'm unsure why that's an issue, as it should be testing each policy individually anyway? @FabienTschanz I tried the edited files you attached, but they fail to export the configurations from my tenant and won't work with my existing localhost.mof as you've removed 2 of the properties (Technologies and Platforms) ? I'd assumed they were essential parts of the JSON structure for the policy, but perhaps not? I'll diff the files later to what else you've changed. |
@dannyKBjj I removed them because for this specific case with iOS, the platform and technologies are always the same. @ricmestre I was working on a Settings Catalog Whitepaper, but I never got the required assistance to understand how the settings are fetched behind the scenes for policies without a template. Therefore I don't have a working solution for this 😢 |
Description of the issue
Hi,
Creating a custom dsc resource for iOS catalogue settings. This is resulting in some pretty deep nested structures - more complex than any other resource I've done. My dsc export compiles fine. I have 2 policies in it. When I run Test-DSCresource
The script failed due to call depth overflow.
+ CategoryInfo : InvalidOperation: (0:) [], CimException
+ FullyQualifiedErrorId : CallDepthOverflow
+ PSComputerName : localhost
But here is the strange thing - If I edit the M365TenantConfig.ps1 and recompile with either one, or the other of the 2 policies it seems to work just fine...
Perhaps I'm swimming out of my depth but but to my mind if one or the other policy is OK, that implies that the code in the resource is OK? I suspect I'm running into some sort of DSC limitation ?
I've attached my work in progress resource module and ps1 export. Hopefully I'm not doing something stupid (or hopefully I am!) Either way, if someone could advise that'd be much appreciated.
The configurations (x2 working, combined, not working) :
TestConfigs.zip
The DSCResource I'm working on:
TestModule.zip
Microsoft 365 DSC Version
1.25.205.1
Which workloads are affected
Intune
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version
The text was updated successfully, but these errors were encountered: