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 cool.com are not inherited by objects in the au.cool.com 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:

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.

e.g.

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.

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 $_.name -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.

 

We will talk about managing GPOs in the next page.