Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
GPO inheritance

By default , GPO inheritance is enabled and settings linked to a parent object are applied to all child objects within a domain.
Note that: child domain are not subject to GPO inheritance.   Eg. GPO settings on are not inherited by objects in the domain.

  • Blocking inheritance: Parent policies do not apply to child, can be applied on a domain or an OU. To do this, right click the child domain or OU, click “block inheritance”.
  • Enforcing inheritance: The enforced GPO has the strongest precedence of all GPOs in its scope.The GPO’s settings are applied to all child objects, even if a GPO with conflicting settings is linked to a container at a deeper level.
    When two GPOs have the enforced option set, the GPO linked to the container highest in the AD hierarchy takes precedence.
GPO filtering:

two types of GPO filtering security filtering and windows management instrumentation (WMI) filtering

  • Security Filtering: Using permission to restrict objects from accessing a GPO. If you want to apply the GPO to a user group or computer, they must have Read and Apply Group Policy permissions. Authenticated users are granted these permissions and applies to both logged on users and computers.1. Apply the GPO to specific users or groups: click the GPO in the Group policy objects folder and click the Scope tab in the right pane. Use the security Filtering dialog box to add the new group to this GPO. Then the GPO only applies to these groups.2. Add exception groups to a GPO: click the GPO in the Group policy objects folder and click the Delegation tab in the right pane. You can see the complete list of ACEs for the GPO.
    The basic idea to set exception groups is deprive the read permission from the user group, so the GPO can not apply the user group anymore.  To do this, click Add button on the bottom left, then add the user or group name to which you want give the exception. then click the “Advanced…” bottom on the bottom right. choose the user name or group in the top box, then check the box bellow “deny” after “read” , click ok.
  • WMI filtering: This technology is gathering management information based on hardware platform, OS version, available disk space and so on.

WMI filtering uses queries to select a group of computers based on certain attributes, and then applies or doesn’t apply policies based on the query’s results. It’s similar to the preference item-level targeting.

You need to have a solid understanding of the complex WMI query language before you can create WMI filters.

WMI filtering examples:

Here’s an example of using one to select only computers running Windows 8 Enterprise:
Select * from Win32_OperatingSystem where Caption = "Microsoft Windows 8 Enterprise"

This next example uses the OS version number.

Windows 7 and Windows Server 2008 R2 have version numbers beginning with 6.1, and Windows 8 and Windows Server 2012 have version numbers beginning with 6.2. This command selects computers running an OS with a version number beginning with 6.2:
Select * from Win32_OperatingSystem where Version like "6.2%"

Check here for a list of windows version number:

The next example uses Version and ProductType. ProductType differentiates between client and server OSs. A client OS, such as Windows 8, has a ProductType of 1, and a server OS, such as Windows Server 2012, has a ProductType of 3. This example selects Windows 8 systems:
Select * from Win32_OperatingSystem where Version like “6.2%” and ProductType = “1”

Suppose you want a policy that installs a large application on target machines with at least 2 GB of disk space available. You can use the following command:
Select * from Win32_LogicalDisk where FreeSpace > 2000000000

This example targets computers from a specific manufacturer and model:
Select * from Win32_ComputerSystem where Manufacturer = “Dell” and Model = “Optiplex 960”

Loopback  policy processing :

In windows 2008, called  “User group policy loopback processing mode” in windows 2012 called “configure User group policy loopback processing mode”

Because computer boots first, so computer policy is applied first, then user logs on the computer, so user settings take precedence because of the GPOs applying to the user are applied last.
However, if you want the public computer to stay locked down no matter who access it, you can use loopback policy processing.


Perhaps you want standardized desktop settings, such as wallpaper, screen savers, Start screen, and so forth, so that these computers have a consistent look for visitors. All these settings are in the User Configuration node, however, so they can’t apply to computer accounts. loopback

Two modes:

  • Replace: All of the user’s setting will be completely replaced.
  • Merge: Any user GPO settings that do not conflict with the computer GPO settings still apply. Any user GPO settings that conflict with the computer GPO settings will be overwritten.
Steps to configure:

1. Create a GPO (or edit an existing one), and enable the “Configure user Group Policy loopback processing mode” policy setting in the Computer Configuration\Policies\ Administrative Templates\System\Group Policy node.

2. In the User Configuration node of the GPO, edit policies to set wallpaper, screen saver, and
Start screen options.

3. Link the GPO to the Public Computers OU.

Configuring Group Policy Client Processing

Group Policy is a client/server system. Each Windows OS has a Group Policy client that contacts a domain controller to see whether any GPOs that apply to the computer or user have changed since the last time the client contacted the DC. When Group Policy determines that a GPO should be downloaded, the client activates client-side extensions.

A client-side extension (CSE) is an extension to the standard group policy client that applies specific types of group policy settings to the client computer. CSEs are also used to apply group policy preferences.

  • Foreground processing: group policies are processed when Windows boots and when a user logs on. Group policies are processed at these times by using foreground processing. Certain policies, such as Software Installation, are processed only during foreground processing.
  • Background processing: After Windows has booted and a user has logged on, most group policy settings are refreshed periodically with background processing.

Group policies are processed only if the client detects that a policy has changed. In addition, some policies aren’t processed if the client detects that the network connection is slow. For many policies, you can change the way the client behaves by default. Settings for group policy process- ing behavior are found in Policies\Administrative Templates\System\Group Policy under both the Computer Configuration and User Configuration nodes. There are three main ways to change the default processing of certain types of policies, discussed in the following sections:

  • Slow link processing
  • Background processing
  • Process even if the Group Policy objects haven’t changed
Configuring Slow Link Processing

Processing certain policies across a slow WAN connection might not be desirable. For example, a software installation policy can use quite a lot of bandwidth if a large software package is being downloaded. A slow network link is, by default, a network connection that’s less than 500 Kbps.

Many types of policies aren’t processed across a slow network link by default, including the following:

• Disk quota

• Folder redirection

• Internet Explorer maintenance

• Scripts

• Software installation

• Wireless network policies

• Wired network policies

• Most preferences

Always applied:

  • Administrative Templates policies, because they control slow link processing and other client behavior.
  • Security Settings policies, ensure that security settings are always in effect.

Configure the speed to slow link:

You might want to change the default behavior of slow link processing. You can do this in a couple of ways:

• Configure the slow link detection policy—You can configure the threshold value of what’s considered a slow link. The range is between 0 and 4,294,967,200 Kbps; 0 indicates that all links are to be considered to be fast. If you set the value to 0, all policies are processed without attempting to detect whether the link is slow. The default value is 500 Kbps. You can also specify that wireless WAN (WWAN) connections are always considered slow. A WWAN is a 3G wireless link. To configure slow link detection, go to Policies\Administrative Templates\System\Group Policy, and enable the “Configure Group Policy slow link detection” policy.

• Allow slow link processing for selected policies—The policies that aren’t processed by default when a slow link is detected can be configured to allow processing. For example, if you want scripts to be processed even when a slow link is detected, enable the “Configure scripts policy processing” policy found in Policies\Administrative Templates\System\Group Policy

Changing Background Processing

After Windows is started, the Computer Configuration node of GPOs affecting the client is refreshed every 90 minutes with a random offset between 0 and 30 minutes. The random offset prevents all computers that were turned on at the same time from refreshing policies simultaneously. In some cases, changes occur immediately, while the computer is running, and in other cases, the policy setting is applied, but the system doesn’t reflect the change until the next restart. Likewise, after a user logs on, the User Configuration node is refreshed every 90 minutes with the same random offset period. These settings work for most situations, but you might want certain policies to be applied only when a computer restarts or a user logs on, forgoing the periodic refresh.

For domain controllers, the refresh period is 5 minutes with no random offset.

You have the option to turn off background processing for several types of policies and preferences, including but not limited to the following:

• Application preference

• Devices preference

• Disk quota policy

• Files and folders preference

• Internet Explorer maintenance policy

• Internet settings preference

• Local users and groups preference

• Network options preference

• Scripts processing

• Wired and wireless policy

For the full list of policies and preferences that can have background processing disabled, look in the Computer Configuration\Policies\Administrative Templates\System\Group Policy node.

You can also change the background processing interval for computers, domain controllers, and users. The Set Group Policy refresh interval for computers policy lets you set the refresh interval for computers from 0 to 44,640 minutes and the random offset from 0 to 1440 minutes. There’s a similar policy for domain controllers and users.

Note: Some policies, such as software installation and folder redirection, are never processed in the background. For example, it might be quite surprising to a user if an application is updated or uninstalled while it’s in use!

Processing Unchanged Policies

By default, the Group Policy client downloads and processes only policies that have changed. You can force policies and preferences to be processed even if they haven’t changed since the last time they were processed. To do so, select the “Process even if the Group Policy objects have not changed” check box . This option isn’t usually necessary because most settings configured by Group Policy can’t be changed by regular users.

By enabling this setting, such as for security policies, you ensure that any settings the user changes are reapplied at the next refresh interval or system start.  If this option is set for a preference, it overrides the “Apply once and do not reapply” option in the Common tab of the preference’s Properties dialog box.

Synchronous and Asynchronous Processing

Group policy processing can be synchronous or asynchronous.

  • Synchronous processing forces group policy processing to finish before certain other system tasks can be performed.For example, during system boot, Computer Configuration policies are processed first. If processing occurs synchronously, the user logon prompt isn’t displayed until all computer Configuration group policy processing is finished. After the user logs on to the system, user-based Group Policy processing begins; the user doesn’t see the desktop until that processing finishes. Thus, synchronous processing elongates the time it takes for a user to boot up the system, log on, and get productive.
  • Asynchronous processing allows displaying the user logon prompt while Computer Configuration policies are still being processed. Likewise, if User Configuration policies are processed synchronously, the user doesn’t see the desktop until processing is finished. Background processing is, by definition, always asynchronous.

In short, asynchronous processing is better from a user experience standpoint because users don’t have to wait as long for processing to finish.
Certain policies, however, require synchronous processing to ensure a consistent computing environment: Software Installation, Folder Redirection, Disk Quotas, and the Drive Mapping preference. After any of these policies are configured, the next system start or user logon might be noticeably slower because of synchronous processing.

When a slow link is detected, you can force asynchronous processing. To do this with policies that usually require synchronous processing, enable the “Change Group Policy processing to run asynchronously when a slow network connection is detected” policy. Like most of the policies discussed in this section, this policy is found under the Group Policy node.

Force synchronous processing by enabling the “Always wait for the network at computer startup and logon” policy, under Computer Configuration\Policies\Administrative Templates\System\Logon.

Group Policy Caching

Group policy caching, new in Windows Server 2012 R2 and Windows 8.1, is a client-side feature that loads policy information from a cache on the local computer instead of always having to download it from a domain controller. It can speed system startup because the cache is used during synchronous foreground processing, which occurs when the system boots.

Group policy caching is enabled by default on Windows Server 2012 R2 and Windows 8.1 computers. A new policy setting, Configure Group Policy Caching, in the Computer Configuration\Administrative Templates\System\Group Policy path allows you to disable caching and configure some parameter.

Group policy settings are cached each time background processing takes place. Note that the cache is used only when the system boots, not during background processing, and only GPOs that have caching enabled are saved. If you enable caching (which is enabled by default, so you need to enable it only if you want to change these parameters or override a higher-precedence GPO that disables it), you can change two timing parameters:

• Slow link value—This value specifies the threshold for the response time from a domain controller to consider a link slow. When the group policy cache is read, the client contacts a DC and measures the response time. If the response time is slower than the specified value, the link is considered slow. In this case, only policies with slow link processing enabled are cached.

• Timeout value—This value is the maximum time the Group Policy client waits for a response from a DC before determining that there’s no network connection to the DC. If a timeout occurs, group policy processing stops until a connection is established.

The group policy cache is on the local computer at %systemroot%\ System32\GroupPolicy\Datastore.

Forcing Group Policy Updates

As you know, you don’t need to wait for a system reboot, user logon, or refresh interval to update group policies on a client computer. By now, you’re quite familiar with the gpupdate.exe command you run on the client at a command prompt. However, additional options available with the gpupdate.exe command haven’t been discussed yet.

The following list describes this command and its options:

• No options—If you just type gpupdate and press Enter, the command’s default behavior takes place: The Group Policy client contacts a DC, and then downloads and applies only changed policies for both the Computer Configuration and User Configuration nodes of all GPOs applicable to the computer and user account.

• /force—All settings from all applicable GPOs are reapplied, even if they haven’t changed.

• /wait: value—Specifies the number of seconds the command should wait for policy processing to finish before returning to the command prompt. The default is 600 seconds. A value of 0 means don’t wait. (You’re returned to the command prompt immediately, but processing continues in the background.) A value of -1 means wait indefinitely. Even if the wait time is exceeded, group policy processing continues in the background.

• /logoff—The user is logged off after policy processing is finished.

• /boot—The computer restarts after policy processing is finished.

• /sync—Causes synchronous processing during the next computer restart or user logon.

• /target: Computer or User—You can specify that you want only computer or user policy settings to be updated.

Remote Group Policy Updates

The gpupdate.exe command is fine if you’re simply testing group policies, and both the server where you’re making changes and the client you’re testing changes on are convenient. However, suppose you make an important policy change that you want a number of clients or even a single remote client to download and apply immediately? Starting with Windows Server 2012, you can cause a group policy refresh remotely on Windows Vista and later clients by using the GPMC or the PowerShell cmdlet Invoke-GPUpdate.

Using the GPMC, you can force a group policy refresh for all computers in an Active Directory OU and all logged-on users of those computers. Simply right-click an OU containing the computer accounts on which you want the refresh to occur and click Group Policy Update. All computers in the OU and child OUs are refreshed.  This option isn’t available on the domain node or the Computers folder, so the target computer accounts must be in an OU.

When you force a group policy update from the GPMC, the following occurs:

1. A list of computers in the OU is created.

2. A list of users currently logged on to each computer is created.

3. A scheduled task that runs gpupdate /force is created on each computer for each logged-on user. The tasks are created with a random 10-minute offset to prevent all computers in the OU from initiating the update at the same time.

4. After the random delay period, users who are logged on see a command prompt open, and the gpupdate /force command runs.

The Invoke-GPUpdate PowerShell cmdlet performs similarly, except you specify a computer rather than an OU to update. By default, only changed policies are applied, but you can use the -force option to reapply all settings. In addition, you can cause the update to occur immediately or after a random delay specified in minutes. By using a pipe with the Get-ADComputer command, you can update several computers at once, including those in the Computers folder. The following two commands show examples of using Invoke-GPUpdate. The first example updates a single computer, and the second example forces updates on all computers in the Computers folder:

Invoke-GPUpdate -Computer 411Win8

Get-ADComputer -filter * -Searchbase "cn=computers, dc=411Dom1,dc=local" | foreach{ Invoke-GPUpdate -computer $ -force}
Configuring the Firewall for Remote Group Policy Updates

Target client computers must have the following inbound firewall rules enabled on the domain profile for a remote group policy update to be successful:

• Remote Scheduled Tasks Management (RPC)

• Remote Scheduled Tasks Management (RPC-EPMAP)

• Windows Management Instrumentations (WMI-In)

You can configure the firewall with the Group Policy tool or on the client computer. If you use Group Policy, a Starter GPO named Group Policy Remote Update Firewall Ports is available that already has the firewall settings configured correctly.

Group Policy Results and Modeling

No matter how well you understand group policy processing and inheritance, determining exactly what GPOs and policy settings are applied to an object can be difficult. Windows includes the following tools to help you determine which policies are applied to a user or computer and which GPO supplied the policy. The information supplied by these tools can help you troubleshoot group policy processing:

  • Group Policy Results—This wizard built into the GPMC creates a report to show administrators which policy settings apply to a user, computer, or both. To use this wizard, right-click the Group Policy Results node in the GPMC and click Group Policy Results Wizard. You have the option to display policy results for the current computer or another computer, and you can select which user to report on from a list of users who have logged on to the target computer. The wizard can show results only of policies that have already been applied to the computer or user. After the wizard finishes, the report has three tabs:
    • Summary: Shows information about which GPOs affect the specified computer and user. In addition, the report shows whether a fast or slow link was detected. You can right-click this window and click Print or Save Report (which saves it in an HTML or XML file).
    • Details: Displays information about the computer and Group Policy components, including when policies were last processed. All defined settings that were applied to the computer and user are listed. The Winning GPO column shows which GPO the setting came from . You also see a list of GPOs that were denied, why they were denied, and the results of WMI filters. As with the Summary tab, you can right-click to print or save the report.
    • Policy Events: Displays all events in Event Viewer that are generated by group policies. To see the events on a remote computer, all three Remote Event Log Management rules must be enabled for inbound connections on the remote computer
  • gpresult.exe—This command-line version of the Group Policy Results Wizard outputs a report onscreen, or you can specify the name of a file with an .html extension. To produce a summary report for the 411Win8 computer and the testuser1 user, enter the following at a command prompt:
    gpresult /s 411Win8 /user testuser1 /r
  • Group Policy Modeling—This is a what-if tool for group policies. Like Group Policy Results, it’s a wizard built into the GPMC that shows administrators which policy settings would apply to a computer and/or user account if it were moved to a different container. Essentially, the report shows which policy settings are in effect for a user whose account is placed in a particular OU and whose computer is placed in a particular OU.You can select user and computer membership in security groups so that GPO filtering is taken into account. In addition, you can select options for slow link processing and loopback processing and specify WMI filters. Group Policy Modeling produces a report similar to Group Policy Results with Summary and Details tabs. Instead of a Policy Events tab, the third tab, Query, summarizes the what-if choices that were made to produce the report.
  • Resultant Set of Policy (RSoP) snap-in—This MMC snap-in functions much like Group Policy Results and Group Policy Modeling. RSoP has two modes: logging and planning. Logging mode produces a database of policy results that you browse similarly to using the Group Policy Management Editor. Planning mode is similar to Group Policy Modeling, producing a database of what-if results based on the same criteria you can choose from the Group Policy Modeling Wizard.
Managing GPOs

The following sections discuss GPO backup and restore, GPO import and copy, GPO migration, and GPO delegation.

GPO backup and Restore

In a large, complex network, with many different policy needs for users, servers, and 10 workstations, configuring and testing GPOs often takes many hours. Thankfully, Windows has a solution for backing up and restoring GPOs in case disaster strikes: GPO backups. GPO backups are also useful if you need to revert to an older version of a GPO or if you delete a GPO accidentally. For example, if many changes are made to a GPO and the changes cause unexpected problems, you might save time by restoring an older version instead of trying to undo the changes.
When you back up a GPO, the policy settings are backed up, but so are the security filtering settings, delegation settings, and WMI filter links. What’s not backed up are the WMI filter files associated with the WMI links, IPsec policies, and GPO container links.

Backing up a GPO is a simple three-step process:

1. In the GPMC, right-click the GPO in the Group Policy Objects folder (because you can’t back up a GPO from the shortcut link to an Active Directory container) and click Back Up.
2. Select (or create) a folder where the GPO should be stored. 3. Enter a description of the GPO, if you want, and click Back Up.
Multiple GPOs can be stored in the same folder, so you don’t need to create a folder each time you back up a GPO. The folder where you store GPO backups should be secure and backed up by a regular system backup routine. You can also right-click the Group Policy Objects folder and select options to back up all GPOs and manage backups.

The procedure for restoring a GPO varies, as follows:

• Restore a previous version—If the settings of a backed-up GPO have been changed and you need to revert to an older version, right-click the GPO in the Group Policy Objects folder, and click Restore from Backup. All policy and security settings in the current GPO are replaced by the backup GPO’s settings.

• Restore a deleted GPO—Right-click the Group Policy Objects folder and click Manage Backups to open the Manage Backups dialog box.

• Import settings—You can import settings from a backed-up GPO to an existing GPO by right-clicking the GPO and clicking Import Settings. This action is similar to restoring a GPO, except the existing GPO need not be the same GPO as the backed-up GPO. As with a GPO restore, all existing settings in the current GPO are deleted.

GPO Copy and Paste

If you simply want to copy the settings of a GPO into a new GPO, you can do so using the following steps from GPMC:

1. Right-click a GPO in the Group Policy Objects folder and click Copy.
2. Right-click the Group Policy Objects folder.
3. Click Paste. You’re asked whether to use the default permissions for the new GPO or preserve the existing permissions of the copied GPO. Make your choice and click OK.
4. Click OK in the progress dialog box after the copy is finished. The new GPO is named “Copy of OriginalGPOName.” For example, if you copied GPO1, the new GPO is named “Copy of GPO1.”
5. Rename the copied GPO by right-clicking it and clicking Rename.

Resetting Default GPOs

Making changes to the two default GPOs (Default Domain Policy and Default Domain Controller Policy) isn’t recommended. However, if you do make changes and need to revert to the original settings, you can do so without using a backup and restore operation. You can use the command-line program dcgpofix.exe to reset settings for either or both default GPOs. This command also resets permissions and any existing security or WMI filters:
• dcgpofix—Resets both the Default Domain Policy and the Default Domain Controllers Policy

• dcgpofix /target:DC—Resets the Default Domain Controllers Policy

• dcgpofix /target:domain—Resets the Default Domain Policy

GPO Migration

You might need to migrate GPOs from one domain to another for a variety of reasons. For example, you have a multidomain environment, and two domains have similar policy require- ments. After perfecting the GPOs in one domain, you can migrate them to be used in the other domain. Migration is also useful when you have set up a test environment that’s similar to one of your production domains. You can configure and test a GPO in the test environment thoroughly, and then migrate it to the production domain.

GPOs can be migrated across domains in the same or different forests by adding the domain to the GPMC. To add a domain in the same forest, right-click the Domains node in the left pane of the GPMC and click Show Domains to open the dialog box.  Then select the domains you want to add to the GPMC.

To add a domain from a different forest, right-click the Group Policy Management node in the left pane of the GPMC and click Add Forest. Then enter the name of the domain in the forest that you want to add.

When you have multiple domains in the GPMC, you can simply copy and paste a GPO from the source domain’s Group Policy Objects folder to the target domain’s Group Policy Objects folder. When you click Paste in the target folder, the Cross-Domain Copying Wizard starts. It gives you the option to use default permissions or preserve existing permissions on the GPO and translates any security principals or UNC paths in the GPO.

A second method for migrating GPOs uses the backup and import procedure. The biggest difference between these two methods is that the copy-and-paste method creates a new GPO, and the backup and import procedure overwrites settings in an existing GPO in the target domain.

Configuring a Migration Table

If you’re migrating several GPOs from one domain to another, you might want to use a migration table to map security principals and UNC paths. A migration table is a list of security principals and UNC paths in a GPO that can be mapped to the security principals and UNC paths in the destination domain. The migration table can then be used when copying a GPO from one domain to another.

You create a migration table by right-clicking the Domains node in the GPMC and clicking Open Migration Table Editor or using the Cross-Domain Copying Wizard. In the Migration Table Editor, click Tools, and then choose Populate from GPO or Populate from Backup. All security principals and UNC paths used in the selected GPO are listed. By default, the Destination Name column is set to “<Same As Source>.” You change this column to translate information, as in the second entry in this figure. Special identities and built-in groups don’t need to be translated.


GPO Management Delegation

The possible permissions for GPO delegation depend on whether you’re working with the GPO or the target the GPO is linked to. Eight possible permissions can be applied to GPOs and the container objects they’re linked to through delegation:

On Group Policy Objects folder

  • Create GPOs—This permission applies only to the Group Policy Objects folder where you can find all GPOs in the GPMC. When you click the Group Policy Objects folder and click the Delegation tab in the right pane, you can view, add, and remove security principals who are allowed to create GPOs in the domain. By default, Domain Admins, Group Policy Creator Owners, and the System special identity have this permission.gpo_delegation_create

On site, domain and OU

  • Link GPOs—This permission can be set on sites, domains, and OUs and determines who can link or unlink a GPO to or from the container. Administrators, Domain Admins, Enterprise Admins, and the System special identity are granted this permission by default.gpo_delegation_link
  • Perform Group Policy Modeling analyses—See figure 2, This permission is set on domains and OUs and determines who can run the GPO Modeling Wizard (discussed in “Group Policy Results and Modeling” earlier in this chapter) on the specified container. The default users are the same as for the Link GPOs permission.
  • Read Group Policy Results data—See figure 2, This permission is set on domains and OUs and determines who can run the Group Policy Results Wizard (discussed in “Group Policy Results and Modeling” earlier in this chapter) on users and/or computers. The default users are the same as for the Link GPOs permission.


  • Read—This permission is set on GPOs; users with this permission can view settings and back up a GPO. By default, the Enterprise Domain Controllers universal group has this permission for all GPOs.
  • Read (from Security Filtering)—This permission is used in group policy filtering. By default, the Authenticated Users group has this permission for all GPOs. It includes both the Read and Apply Group Policy permission and is generally set in the Scope tab of a GPO’s Proper- ties dialog box.
  • Edit settings, delete, modify security—This permission is set on GPOs and determines who can edit, change status on, back up, delete, and change security on a GPO. By default, Domain Admins, Enterprise Admins, and the System special identity are granted this permission.
  • Edit Settings—With this permission, security principals can change existing settings, import settings, and enable or disable a GPO. No users are granted this permission by default.



Group Policy Best practices: