When evaluating Group Policy requirements for an organization, we can identify some settings that are common for objects in the entire domain. But at the same time, some settings are unique to departments or specific groups. Any Group Policy that is applied at the root level will be inherited by other organization units by default. Therefore, organization units can have inherited group policies as well as directly linked group policies. In that case, which Group Policy will be processed? Will it prevent any group policies? If the same setting is applied to different policies, which one will win? To answer all these questions, it's important to understand how Group Policy processing works.

There are mainly two types of policies in the Active Directory environment:

• Local policies: Windows systems are supported to set up local security policies. These policies are not similar to domain GPOs, and they contain limited features that are more focused on security settings. It is applied to any user who logs in to the system.
• Non-local policies: These policies are Active Directory-based policies that we will be discussing throughout this chapter. These policies will apply only to the domain-joined computers and Active Directory users. These policies are feature-rich compared to local policies.

Group Policy can be applied to three levels in the Active Directory environment:

• Site: Group Policy can be linked to an Active Directory site. Any site-level Group Policy will apply to all domains in that site.
• Domain: Any Group Policy applied at the domain level will apply to all users and computers' Active Directory objects under that domain. By default, the system creates a Group Policy called Default Domain Policy at the domain level. Most of the time, domain-level policies will be used to publish security policies that are applicable to the entire infrastructure.
• Organization units: Group Policy at the OU level will be apply to any user or computer object under it. By default, the system creates an OU-level Group Policy called Default Domain Controllers Policy, which applies to the domain controller's OU. Group Policy settings applied at the OU level are more specific as the target audience is small.

The following diagram illustrates the policy levels in Active Directory:

In the Active Directory environment, group policies will be processed in this order:

• Local policies
• Site policies
• Domain policies
• OU policies

In general, this order is called LSDOU. The first policy to be processed is the local policy, and the last one to be processed is the OU policy. This doesn't mean that the most preferred policy is the local policy. Of all four policies, the policy that holds least precedence value will be the winning GPO, which is the OU policy. This processing order is important when policies have conflicting values. The policy at the OU level will be the closest policy to the object. As I said earlier, OU-level policy settings are more specific according to organization requirements. Therefore, they hold the most accurate policy setting for the targeted objects. This order is the default processing order, and based on the requirements, it is possible to change the precedence order. We will be looking into this later on in this chapter.

In order to apply computer Group Policy settings successfully, the device should have a valid connection to domain controllers, and to apply user Group Policy settings, a user (the domain account) should log in to the domain-joined computer that has an active connection to domain controllers.

Group policies are mainly processed in two different modes. By default, Group Policy's computer settings will start to process during the startup process before the user log-on box prompts. Once the user enters the username and credentials, Group Policy's user settings start to process. This pre-processing mode is called foreground processing. During the foreground process, some policies will finish processing but some will not. They will be processed in the background after login and network connection is initialized. Also, once the user logs in, every 90 minutes, the group policies will run in the background by default. This is the second mode of Group Policy processing.

Foreground processing can be further divided into two sub-modes. Before Windows XP was introduced, all the policy settings that ran in the foreground mode finished before the user saw the desktop after the login process. This is called a synchronous mode. But after Windows XP, the default mode of processing is asynchronous, which means it doesn't wait until the Group Policy process finishes or before the user starts to use the computer. When the computer is presented with the login screen, in the background, the computer settings part of the policies will still be processing. After the user logs in, system will start to process user settings as part of the policies, by the time computer loads into initial home screen, the group policies may still be processing in the background. There are four policy settings that are defined by Microsoft that are always processed in the asynchronous mode. If any policy has folder redirection, software installation, disk quota, and drive mapping enabled, it will be processed in the synchronous mode. Not only that, all the startup scripts also run in the foreground in synchronous mode.

This default behavior of processing provides a faster logon time for users, but at the same time, some policy settings can take up to two logon cycles to apply the changes fully. This behavior makes an impact on security settings. As an example, if we want to block access to control panel settings and if the policy setting not processed in the synchronous mode, when the user logs in, there is a possibility for them to have access to the Control Panel. Then, it is not going to give the expected results. This default mode is useful when users are connected through a slow link. Because if it's not, it can take an awful amount of time to finish the Group Policy processing. If there is no specific reason, it is recommended that you use synchronous mode always. This can be changed using Group Policy. The policy settings are located at Computer ConfigurationAdministrative TemplatesSystemLogonAlways wait for the network at computer startup and logon. One disadvantage of this is that even when there is slow link detection, system will still process it in the synchronous mode.

As I explained earlier, there are four Group Policy settings defined by Microsoft that always run in the synchronous mode. Even if systems are connected via slow link, it will process these Group Policy settings in synchronous mode. Therefore, it is recommended that you enable the following two Group Policy settings to force the asynchronous mode when you log in via slow link and remote desktop services. Forcing the asynchronous mode for slow links can be enabled via Computer ConfigurationAdministrative TemplatesSystemGroup PolicyChange Group Policy Processing to run asynchronously when a slow link is detected. Forcing the asynchronous mode for remote desktop services can be enabled via Computer ConfigurationAdministrative TemplatesSystemGroup PolicyAllow asynchronous user Group Policy processing when logging on through Remote Desktop Services.