The GPMC shows precedence as a number.
The smaller the number—that is, the closer to 1—the higher the precedence.
Therefore, a GPO that has a precedence of 1 will prevail over other GPOs. Select the relevant AD DS container, and then click the Group Policy Inheritance tab to view the precedence of each GPO.
2015年11月8日星期日
2015年8月7日星期五
2015年6月17日星期三
Description of Group Policy Restricted Groups
Restricted groups allow an administrator to define the following two properties for security-sensitive (restricted) groups:
https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCQQFjAB&url=http%3A%2F%2Fsocial.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F20402.active-directory-group-policy-restricted-groups.aspx&ei=lpqBVcLYCsyF8gXtgr6oDw&usg=AFQjCNHyPUtZcMS9YF25gLJeRZSuQdNvCg&sig2=-DcKcsUXLdKU4QuIoOp8vA
https://support.microsoft.com/en-us/kb/279301
- Members
- Member Of
Using the "Members" Restricted Group Portion of Policy
When a Restricted Group policy is enforced, any current member of a restricted group that is not on the "Members" list is removed with the exception of administrator in the Administrators group. Any user on the "Members" list which is not currently a member of the restricted group is added.Using the "Member Of" Restricted Group Portion of Policy
Only inclusion is enforced in this portion of a Restricted Group policy. The Restricted Group is not removed from other groups. It makes sure that the restricted group is a member of groups that are listed in the Member Of dialog box.Managing membership of Domain Groups by using Restricted Groups
Microsoft does not support using Restricted Groups in this scenario. Restricted Groups is a client configuration means and cannot be used with Domain Groups. Restricted Groups is designed specifically to work with Local Groups. Domain objects have to be managed within traditional AD tools. Therefore, we do not plan currently to add or support using Restricted Groups as a way to manage Domain Groups.https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCQQFjAB&url=http%3A%2F%2Fsocial.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F20402.active-directory-group-policy-restricted-groups.aspx&ei=lpqBVcLYCsyF8gXtgr6oDw&usg=AFQjCNHyPUtZcMS9YF25gLJeRZSuQdNvCg&sig2=-DcKcsUXLdKU4QuIoOp8vA
https://support.microsoft.com/en-us/kb/279301
Active Directory Group Policy Restricted Groups
The management of local groups on Workstations and servers in an organization can be done centrally by Group Policies. One of the ways to do that is to use Group Policy Restricted Groups.
Below is a table that summarizes the membership that could be updated using Group Policy Restricted Groups:
(*) Local Groups Nesting is not supported (http://technet.microsoft.com/en-us/library/ee681621(v=ws.10).aspx
)
Creation of a new Restricted Groups Group Policy:
To create a new Restricted Groups Group Policy, proceed like the following:




IMPORTANT: You should refer to the table that summarizes the membership that could be updated using Group Policy Restricted Groups before applying the new group policy.
Expected behavior when using a Restricted Groups Group Policy:
When using a Restricted Groups Group Policy, the following behavior is expected:
Microsoft support for Group Policy Restricted Groups:
Description of Group Policy Restricted Groups: http://support.microsoft.com/kb/279301
Tips:
Tip 1: It happens that, for operational tasks, a user needs to be added as member of a local group to perform an action and then removed later. If a Restricted Groups Group Policy is used for the local group members then the user can be added as member of the group and automatically removed after the re-appliance of the group policy.
Tip 2: To add new domain members to a local group using Group Policy Restricted Groups without removing the current members, you can proceed like the following:
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx
Below is a table that summarizes the membership that could be updated using Group Policy Restricted Groups:
| Local Group | Domain Group | |
| Using of 「Members」 |
|
Not applicable
|
| Using 「Member Of」 |
Not Applicable (*)
|
|
Creation of a new Restricted Groups Group Policy:
To create a new Restricted Groups Group Policy, proceed like the following:
- Create a new Group Policy, go to Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups and then select Add Group… after doing a right click on Restricted Groups
- Specify the name of the group to update its membership and then click on OK
- If you would like to add members to the group then click Add … for Members of this group
- If you would like to add the group as member of a local group then click on Add… for This group is member of
IMPORTANT: You should refer to the table that summarizes the membership that could be updated using Group Policy Restricted Groups before applying the new group policy.
Expected behavior when using a Restricted Groups Group Policy:
When using a Restricted Groups Group Policy, the following behavior is expected:
Type of update
|
Behavior
|
Update of 「Members」
| Any current member of the group that is not on the 「Members」 list will be removed (Local administrator user cannot be removed from Administrators group even if it is not in the 「Members」 list). All users / domain groups that are in the 「Members」 list and are not members of the group will be added as members. |
Update of 「Member of」
| The membership is added if it does not exist |
Description of Group Policy Restricted Groups: http://support.microsoft.com/kb/279301
Tips:
Tip 1: It happens that, for operational tasks, a user needs to be added as member of a local group to perform an action and then removed later. If a Restricted Groups Group Policy is used for the local group members then the user can be added as member of the group and automatically removed after the re-appliance of the group policy.
Tip 2: To add new domain members to a local group using Group Policy Restricted Groups without removing the current members, you can proceed like the following:
- Create a domain group and add the domain users / groups as member of it
- Use 「Member of」 feature to add the new domain group as member of the needed local group
2015年6月2日星期二
What Is the Central Store?
What Is the Central Store?
If your organization has multiple administration workstations, there could be potential issues when editing GPOs. If you do not have a central store that contains the template files, then the workstation from which you are editing will use the .admx (ADMX) and .adml (ADML) files that are stored in the local PolicyDefinitons folder. If different administration workstations have different operating systems or are at different service pack levels, there might be differences in the ADMX and ADML files. For example, the ADMX and ADML files that are stored on a workstation running Windows 7 with no service pack installed might not be the same as the files that are stored on a domain controller running Windows Server 2012. This could lead to administrators not seeing the same settings in a GPO.
The central store addresses this issue. The central store provides a single point from which administration workstations can download the same ADMX and ADML files when editing a GPO. The central store is detected automatically by Windows operating systems (Windows Vista or newer or Windows Server 2008 or newer). Because of this automatic behavior, the local workstation that the administrator uses to perform administration always checks to see if a central store exists before loading the local ADMX and ADML files in the Group Policy Management Editor window. When the local workstation detects a central store, it then downloads the template files from there. In this way, there is a consistent administration experience among multiple workstations.
Creating and Provisioning the Central Store
You must create and provision the central store manually. First you must create a folder on a domain controller, name the folder PolicyDefinitions, and store the folder at C:\Windows\SYSVOL\sysvol \{Domain Name}\Policies\. This folder is now your central store. You must then copy all the contents of the C:\Windows\PolicyDefinitions folder to the central store. The ADML files in this folder also are in a language-specific folder, such as en-US.
If your organization has multiple administration workstations, there could be potential issues when editing GPOs. If you do not have a central store that contains the template files, then the workstation from which you are editing will use the .admx (ADMX) and .adml (ADML) files that are stored in the local PolicyDefinitons folder. If different administration workstations have different operating systems or are at different service pack levels, there might be differences in the ADMX and ADML files. For example, the ADMX and ADML files that are stored on a workstation running Windows 7 with no service pack installed might not be the same as the files that are stored on a domain controller running Windows Server 2012. This could lead to administrators not seeing the same settings in a GPO.
The central store addresses this issue. The central store provides a single point from which administration workstations can download the same ADMX and ADML files when editing a GPO. The central store is detected automatically by Windows operating systems (Windows Vista or newer or Windows Server 2008 or newer). Because of this automatic behavior, the local workstation that the administrator uses to perform administration always checks to see if a central store exists before loading the local ADMX and ADML files in the Group Policy Management Editor window. When the local workstation detects a central store, it then downloads the template files from there. In this way, there is a consistent administration experience among multiple workstations.
Creating and Provisioning the Central Store
You must create and provision the central store manually. First you must create a folder on a domain controller, name the folder PolicyDefinitions, and store the folder at C:\Windows\SYSVOL\sysvol \{Domain Name}\Policies\. This folder is now your central store. You must then copy all the contents of the C:\Windows\PolicyDefinitions folder to the central store. The ADML files in this folder also are in a language-specific folder, such as en-US.
標籤:
Active Directory,
GPO,
MCSE,
Windows Server
Applying GPOs
Computer configuration settings are applied at startup, and then are refreshed at regular intervals. Any startup scripts run at computer startup. The default interval is every 90 minutes, but this is configurable. The exceptions to this default interval are domain controllers, which have their settings refreshed every five minutes.
User settings are applied at logon and are refreshed at regular, configurable intervals. The default for this is 90 minutes. Prior to Windows 8.1 and Windows Server 2012 R2, all logon scripts run at sign-in. By default, in Windows 8.1 and Windows Server 2012 R2, logon scripts run five minutes after sign-in. You can use Group Policy to remove this delay by modifying the Computer Configuration\Policies\Administrative Templates\System \Group Policy\Configure Logon Script Delay setting.
Note: A number of user settings require two sign-ins before the user sees the effect of the GPO. This is because multiple users signing in to the same computer use cached credentials to speed up sign-ins. This means that, although the policy settings are delivered to the computer, the user is signed in already. Therefore, the settings do not take effect until the next time the user signs in. The Folder Redirection setting is an example of this.
You can change the refresh interval by configuring a Group Policy setting. For computer settings, the refresh interval setting is found in the Computer Configuration\Policies\Administrative Templates \System\Group Policy node. For user settings, the refresh interval is found at the corresponding settings under User Configuration. An exception to the refresh interval is the security settings. The security settings section of the Group Policy is refreshed at least every 16 hours, regardless of the interval that you set for the refresh interval.
Note: A number of user settings require two sign-ins before the user sees the effect of the GPO. This is because multiple users signing in to the same computer use cached credentials to speed up sign-ins. This means that, although the policy settings are delivered to the computer, the user is signed in already. Therefore, the settings do not take effect until the next time the user signs in. The Folder Redirection setting is an example of this.
You can change the refresh interval by configuring a Group Policy setting. For computer settings, the refresh interval setting is found in the Computer Configuration\Policies\Administrative Templates \System\Group Policy node. For user settings, the refresh interval is found at the corresponding settings under User Configuration. An exception to the refresh interval is the security settings. The security settings section of the Group Policy is refreshed at least every 16 hours, regardless of the interval that you set for the refresh interval.
標籤:
GPO,
MCSE,
Windows Server
訂閱:
文章 (Atom)