Thanks, Arsen. The Custom Settings payload with ./Vendor/MSFT/ApplicationControl/Policies/{GUID}/Policy as the LocURI and the WDAC binary created from ConvertFrom-CIPolicy and converted to base 64 in the Data field works. However, how does VMware suggest users update WDAC policies? I can think of 3 ways this can be done, only one of which seems to work in practice:
Replace CSP: Create a Custom Settings Profile and put the Replace CSP in the install settings section whose data payload is the updated policy but with the same policy ID. In other words, change a given policy without changing its ID (this is the only way the Replace CSP would work), compile, and send to the device with the Replace CSP using a temporary profile. Then, delete the temporary profile (deleting doesn't cause the underlying Custom Settings’ remove command to trigger). Now, since the old policy is still in the original Profile, it's Add CSP needs to be changed to the new policy for any new devices that get it installed. Doing this triggers the install command which causes all sorts of problems on the device, presumably because it's already installed. So this doesn't seem to be a viable solution.
Remove CSP and Add CSP, same policy ID: Manually trigger the remove command by removing the profile from the device. In order for this to work, the device needs to be restarted (Windows supports no-restart Adds, but not no-restart Deletes for WDAC policies). This causes an issue because this doesn't also send a notification to the device to restart so there's no saying when it will be restarted. This means that you can't then update the profile with the updated policy (same ID) because Windows thinks it's still installed and it will error out (just like the issue above). So this doesn't seem to be a viable solution, either.
Remove CSP and Add CSP, new policy ID: Manually trigger a remove command by removing the profile from the device. Create a new profile with the updated policy but this time ensure the updated policy has a unique ID. Add the new profile to the device. This will allow us to prevent blocking any new or changed software that would otherwise be blocked by the old policy. However, if we are updating a policy in order to block something, we would need to explicitly deny it in the new policy (I think this would work, I haven’t tried it yet) because the old policy would still allow it until the device restarts at some point. This works, but isn’t ideal.
Ideally, we would have the ability to send Replace CSPs for currently installed policies while also updating the relevant profile’s install settings without automatically sending an Add CSP.
