Skip to content
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

Several modules have Managedidentity instead of ManagedIdentity #2464

Closed
fxlite opened this issue Oct 28, 2022 · 5 comments · Fixed by #2465 or #2515
Closed

Several modules have Managedidentity instead of ManagedIdentity #2464

fxlite opened this issue Oct 28, 2022 · 5 comments · Fixed by #2465 or #2515
Assignees
Labels
Bug Something isn't working V1.22.1026.1 Version 1.22.1026.1

Comments

@fxlite
Copy link

fxlite commented Oct 28, 2022

Details of the scenario you tried and the problem that is occurring

E.g. EXOOrganizationConfig, but this occurs in several of the EXO resources.

Verbose logs showing the problem

Suggested solution to the issue

For example, Line 1184 in MSFT_EXOOrganizationConfig.psm1 contains:

$SetValues.Remove('Managedidentity') | Out-Null

Which should be:

$SetValues.Remove('ManagedIdentity') | Out-Null

Due to hashtable keys being case sensitive, this does not remove ManagedIdentity from the splat on Line 1196, and the Set-TargetResource fails with "A parameter cannot be found that matches parameter name 'ManagedIdentity'."

The DSC configuration that is used to reproduce the issue (as detailed as possible)

Start-DSCConfiguration -Path <pathToCompilledEXOOrganizationConfigMOF> -Wait -Force

The operating system the target node is running

Version of the DSC module that was used ('dev' if using current dev branch)

1.22.1026.1

@andikrueger andikrueger added Bug Something isn't working V1.22.1026.1 Version 1.22.1026.1 labels Oct 28, 2022
@andikrueger andikrueger self-assigned this Oct 28, 2022
andikrueger added a commit to andikrueger/Microsoft365DSC that referenced this issue Oct 28, 2022
@mlhickey
Copy link
Contributor

mlhickey commented Oct 28, 2022

Hashtable keys are case-insensitive, the issue is more likely that it's not being correctly passed to begin with. Will try to investigate this resource over the weekend/early next week,

@andikrueger
Copy link
Collaborator

andikrueger commented Oct 29, 2022

@mlhickey thanks for the further investigation.

I marked my current PR as draft.

@fxlite
Copy link
Author

fxlite commented Oct 29, 2022

Thanks for the input. This is a good resource regarding case sensitivity in hashtables, depending on how they're initialized. I figured this was relevant, as when I altered the module myself, the parameter error disappeared...

@fxlite
Copy link
Author

fxlite commented Oct 29, 2022

Yeah, but the hashtable isn't getting initialized literally like you have the module unless I'm mistaken. For example:

image

@mlhickey
Copy link
Contributor

mlhickey commented Oct 29, 2022

I agree if they were being created that way, but here they are not. In this case it's being copied from $PSBoundParameters at line 1691:

$ValuesToCheck = $PSBoundParameters

Function to test against PSBoundParameters seems to bear out case-insensitivity:

image

Regardless, it was a typo on my part and should be rationalized regardless for sake of good coding.

@andikrueger - assume you did a case-sensitive search/replace across all resources and not just the EXO?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working V1.22.1026.1 Version 1.22.1026.1
Projects
None yet
3 participants