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.
two types of GPO filtering security filtering and windows management instrumentation (WMI) filtering
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: http://frankfu.click/microsoft/windows-fundamental/version-number-of-windows-os/
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.
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:
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.
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.
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:
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:
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
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!
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.
Group policy processing can be synchronous or 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, 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
.
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.
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}
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.
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:
gpresult /s 411Win8 /user testuser1 /r
We will talk about managing GPOs in the next page.
Page: 1 2
This website uses cookies.