Exception calling "ContainsKey" with "1" argument(s): "Value cannot be null. (Parameter 'key')"

[arrerezai]

Describe the bug Latest changes to the Build-AssignmentDefinitionNode.ps1 file introduced plenty of weird messages and behavior while running the Build-DeploymentPlans.ps1.

To Reproduce Run the Build-DeploymentPlans.ps1 file locally while moving from epac 10.3.4 to 10.4.0.

Expected behavior The red colored message should not appear, nor should the yellow message.

Screenshots

EPAC Version EPAC Version 10.4.0.

[arrerezai]

@apybar, since you introduced the latest changes with your merge, maybe you have a feeling of what should be corrected not to see the messages in the image above?

[apybar]

@arrerezai - thank you for submitting this. Let me work with the team to push a fix today.

[apybar]

@arrerezai - I found the issue and fixed the bug on my end. Seems there is an issue with some of the parameter names.

The red text is obviously appearing due to this issue. The yellow text is actually an intended warning to alert that there are parameters within your assignment JSON that are referencing policy definitions that are deprecated. Just giving additional ways to allow visibility to policies that are deprecated within Policy Sets.

Waiting for the reviewal process and bug will be fixed today when I push v10.4.1 - This ticket will close once the release has been published. Please open another ticket if the issue persists.

[arrerezai]

@apybar, all right, good that you found it quickly. What was the issue?

Regarding the yellow message, sure, but then I would like to ask you - when is it a great time to remove thse policy definitions along with their assignments completely rather than calling deprecated ones and having a warning message that should be read more like an informational message?

[apybar]

@arrerezai - Sometimes the parameter names within in the JSON assignment don't match the parameter names of the Policy Set JSON file. i.e. "listOfAllowedLocations" is my parameter in my Assignment which is actually referenced as "allowedlocations_list" in my Policy Set. It was throwing an error when it couldn't find the parameter name since they didn't match. I'll have to insert some logic for these use cases.

As far as your second question - ideally its best practice to remove a deprecated policy or identify a replacement as soon as found. Majority of the time we see customers creating custom policy initiatives and then months later (or sometimes never) realize some of the policy definitions used for the policy set were eventually deprecated.

Also - there are some built in Policy Sets that sometimes use deprecated policies temporarily as they roll out changes to the built in Policy Sets. Majority of the time these policies are set to "Disabled" automatically when a Policy is labeled as "Deprecated" in the Policy Portal, but can sometimes fall through cracks . EPAC takes an additional step to parse through any custom or built-in Policy Sets, find deprecated Policy Definitions, and then set the policy effect for the deprecated Policy Definitions to "Disabled" in the latest EPAC update (v10.4.0) using the global settings property "doNotDisableDeprecatedPolicies". Read more here: https://azure.github.io/enterprise-azure-policy-as-code/settings-global-setting-file/ https://azure.github.io/enterprise-azure-policy-as-code/settings-desired-state/

[arrerezai]

Please quickly check this comment I just posted and if you still think this should be closed, you may close it again:

https://github.com/Azure/enterprise-azure-policy-as-code/pull/689#issuecomment-2187055645

[JerJon]

I had the same issue but with fix 10.4.1 the problem has been gone.