Compliance Error Importing Settings To Object When Deploying Changes To GPO. (4371135)

Compliance Error Importing Settings To Object When Deploying Changes To GPO.

The following error is seen when deploying changes to a GPO:

 

GPOADmin service account is not member of domain admins group and permissions have been delegated to this service account as per our minimum permissions online documentation.

There are certain environments in which GPOADmin service account requires Delete Subtree advanced permission as noted on step number 15 from our minimum permissions online documentation.

Grant GPOADmin service account Delete Subtree advanced permission. You may do this by trying the following:

1- Open Group Policy Management Console (GPMC).
2- In GPMC, expand Forest, then Domain and expand Group Policy Objects.
3- Click on the group policy in which you want to grant the service account the permission and go to the delegation tab.
4- Click Advanced, and click Advanced again.
5- Click Add and click select a principal.
6- Find GPOADmin service account and click ok.
7- On Type select Allow and on Applies to select This object and all descendant objects.
8- Select Delete Subtree and click ok.

The above step needs to be repeated on each GPO that GPOADmin will manage.

If your environment is large with hundreds or thousands of group policies, then instead of the manual process described above you may try one of the following PowerShell scripts to automate this step.

Set_DeleteSubtree_AllGPOs.ps1
Run this script if you want to grant your GPOADmin service account Delete Subtree advanced permission to all group policies from your environment. To use this script you must provide the domain name for the domain where the permissions are being set. When using a GMSA this must be the domain where the service account is located as GMSAs cannot cross domains. The initial import-module may need to be altered if GPOADmin is not installed to the "C:\" drive.

Script Usage: Set_DeleteSubtree_AllGPOs.ps1 -DOMAINNAME <Domain FQDN>


SetAddPermDeleteTree.ps1
Run this script if you want to grant your GPOADmin service account Delete Subtree advanced permissions only to a few group policies in your environment and not all. For example there are GPOs which their name starts with Desktop-, and there are other GPOs which their name starts with HR-, but if you only want to grant this permission only on the GPOs in which name starts with Desktop-, then only specify Desktop- in the -ObjectFilter variable.

Script Usage: SetAddPermDeleteTree.ps1 -ObjectFilter 'Server-*' -Account 'domain\userorgroup' -DomainDN 'DC=Domain,DC=COM'

Attached you may find both scripts, so that you may use the one that best works for your environment.

Script Disclaimer:
The information in the script(s) provided is known to work successfully; however, they have not been officially tested by Quest Software Quality Control.  If any of these instructions are changed and/or incorrectly used, intentionally or unintentionally, this solution becomes unsupported by Quest Software Support and Development.

 

SetAddPermDeleteTree
Set_DeleteSubtree_AllGPOs

One way we have dealt with this is to create a custom action to re-add the delete subtree permission before deployment. This was done in a case where the customer did not want to give permissions to the service account at a lower level. Another option would be to open ADSIEdit and connect to the Default Naming Context for the domain. Then navigate toe DC=domain / CN=System / CN=Policies. Here, right click on CN=Policies and select "Properties". Go to the Security tab and then click "Advanced". Here click "Add" and select the security principal for the GPOADmin service account. Set 'Type' to Allow, and 'Applies to:' to "This object and all descendant objects". In the Permissions list leave the default list and read permissions, and add the "Delete" and "Delete subtree" permissions. Then click OK. This should ensure that the delete subtree permissions are always available on the GPOs in the domain, and will not be removed when deploying a GPO as the permissions are set at the Policies container level.