Functional Documentation Available?

[monkeydeus]

We have just finished up deploying a landing zone for our customer, and phase 2 is hardening it with EPAC and other activities.

I'm following the quick start and have some questions along the lines of why running Build-DeploymentPlans would include ANYthing in the plan files initially, before making any changes to the assignments, etc. In other words, if my client rightfully asks 'what is this thing doing', is there anything to help me explain it to them at this level? How it identifies policySetDefinitions to be updated or replaced for example?

I suspect it is referencing the enterprise landing zone policy list as a source of truth or something, just looking for confirmation?

[brianmooremsft]

So assuming here your client's new Landing Zone has some existing policy assignment before you started with EPAC, and you are following the Quick Start documentation, and you have gotten as far as defining your EPAC environment scope (your Landing Zone) in globalsettings.json in Step 7, and extraction of existing deployed policies and assignments from said environment scope (Landing Zone) in Step 8, and you then copied those extracted policies and assignment to the respective Definitions sub folders created in Steps 5 & 6, then running a first time run of a Build-DeploymentPlan would indeed contain plan instructions, particularly if you have the gloabsettings.json Desired State parameter set to "Full" instead of "OwnedOnly".

The reason is EPAC now thinks that it "owns" all policy deployments/assignments for the scope in question (in your case the client's Landing Zone), and EPAC will now "remove" any existing policy deployments/assignments which it has not previously deployed, and then proceed to re-deploy them according to its plan based on the assignments and policies in the Defintions subfolders. In effect, the first time run of Build-DeploymentPlans would remove policies and assignment that had been previously deployed manually or by other means, and then immediately redeploy them (as described in the Definitions subfolders), establishing EPAC's own record of the policy deployments and environment. If you allowed it to finish the deployment for the first time, and then ran a second Build-DeploymentPlans (assuming you make no policy changes in the interim), the Build-DeploymentPlans should contain no changes.

If your client has concerns about making changes to existing policy deployments in the Landing Zone, you can control this by setting the DesiredState Strategy parameter to "OwnedOnly", which means that EPAC will only attempt to manage policy deployments (policies+assignments) which it knows it has previously deployed.

LMK if this explanation helps, if not we can connect for a session to clarify.

[monkeydeus]

@brianmooremsft I've gone through the script files and it's very difficult to divine the logic of what determines replace vs update in the assignments by just following the code execution. Is there a simple(r) heuristic that determines this, or pseudo-code? Let me know if there is any other information or specific examples I could give you to assist in answering this - I've broken down all the assignments getting replaced or updated, whether they are policies or sets, etc.

[monkeydeus]

Thanks very much for getting back to me so quickly. I understand what you are saying, let me go back and reference the plan against the existing assignments. The numbers in policy-plan (e.g. "numberOfChanges": 13) didn't immediately make me think it was just taking ownership of everything (it seemed it was some sort of delta, leading to my thought it was identifying outdated definitions or assignments), but let me dig into it some more.