Build-ExemptionsPlan function fails when trying to add builtin and custom policy sets as exemptions

[doenoe]

Describe the bug When trying to add builtin or custom policy sets as exemptions via a .jsonc file as described here, the Build-ExemptionsPlan function fails with the following error:

Confirm-PolicySetDefinitionUsedExists: C:\Users\user\Documents\PowerShell\Modules\EnterprisePolicyAsCode\10.2.2\internal\functions\Build-ExemptionsPlan.ps1:401:29
Line |
 401 |                              -AllDefinitions $AllDefinitions.policyset …
     |                              ~~~~~~~~~~~~~~~
     | A parameter cannot be found that matches parameter name 'AllDefinitions'.

To Reproduce Create a .jsonc file and add a custom or builtin policy set to exempt and run the Build-DeploymentPlans function.

Expected behavior Build-ExemptionsPlan should run without errors.

EPAC Version 10.2.4

[arrerezai]

Hi @doenoe,

I am not an author of EPAC but based on my experience, being on the same EPAC version as you are (which currently is the latest), it works fine for me. Thought maybe I could give you a hint of how I'm constructing the jsonc files (one per PAC environment) and there might be a slight chance you are doing it differently and can gain something out of my example:

Here is how I have set it up:

{
    $schema": "https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/policy-exemption-schema.json", //This line might as well be deleted as the schema isn't updated with the correct parameters for EPAC v10+ so it cannot even be used as a reference anymore
    "exemptions": [
        {
            "name": "<guid>",
            "displayName": "<Exemption name as seen in the Portal>", //Ensure this is short as EPAC is currently merging the subscriptionId and assignmentId on to the exemption name and it cannot exceed 128 chars altogether
            "description": "<Description of the exemption>", //Cannot exceed 512 chars
            "exemptionCategory": "<Waiver or Mitigated>",
            "expiresOn": "<expiration date>", //yyyy-MM-ddTHH:mm:ss.fffffffZ (in Zulu time) or leave empty if no expiration date
            "scopes": [
                "<one or many scopes, comma-separated>"
            ],
            "policyDefinitionId": "<policy definition id for the policy you would like to exempt the assignment of>" //This is for built-in policies
        },
        {
            "name": "<guid>",
            "displayName": "<Exemption name as seen in the Portal>",
            "description": "E<Description of the exemption>",
            "exemptionCategory": "<Waiver or Mitigated>",
            "expiresOn": "",
            "scopes": [
                "<one or many scopes, comma-separated>"
            ],
            "policyDefinitionName": "<the name of the policy definition, which is equivalent to the very last part of the policy definition id>" //This is for custom policies
        }
    ]
}

Hope it helps!

[doenoe]

Hello @arrerezai,

Thank you for your reply. Have you tried deploying exemptions on policy sets? That's where I end up getting the errors. As per your example file, policy definitions deploy without problems on my side as well.

[arrerezai]

Oh, my mistake, was a bit too quick. I read the first line of the subject only "Build-ExemptionsPlan function fails when trying to add builtin and custom policy". Unfortunately, I have not deployed any exemptions on the initiatives so I wouldn't know if there were to be any problems... Hope you get the appropriate answer from one of the authors!

[apybar]

I've assigned to myself and will test with latest version of EPAC - will provide a response once tested.

[arrerezai]

I have tested this myself for a custom policy set now and it leads to the same issue as @doenoe is experiencing:

Unless you know what the issue is @apybar , then maybe @techlake has a clue on what's not working?

There are no updates to the Build-ExemptionsPlan.ps1 between v10.2.4 that @apybar apybar is on, on v10.2.5 that I am on, and v10.2.9 that to this date is the latest.

[apybar]

@arrerezai , @doenoe - We identified what’s causing the issue. Hoping to push the fix by tomorrow.