Information Technology Reference
In-Depth Information
In Table 7-1, the Lock the Taskbar policy is in the GPO's User Configuration node. The policy
is Enabled for users in the Marketing OU and any of Marketing's child OUs. The policy is also
enabled for users in the Advertising OU (a child of Marketing) because it's not configured in the
GPO linked to the Advertising OU. The policy is disabled for all other users in the domain who
aren't in the scope of the Marketing OU GPO because of the Default Domain Policy's setting.
Every computer also has one or more local policies, but policies defined in GPOs in Active
Directory take precedence over all local policies. So taken together, policies are applied in this
order:
1. Local policies
2. Site-linked GPOs
3. Domain-linked GPOs
4. OU-linked GPOs
The last policy applied takes precedence over policies applied earlier, so OU-linked GPOs
have the strongest precedence when conflicting policies exist.
Understanding Site-Linked GPOs GPOs linked to a site object affect all users and
computers physically located at the site. Because sites are based on IP address, GPO processing
determines from where a user is logging on and from what computer based on that computer's
IP address. So users who log on to computers at different sites might have different policies
applied to their accounts. In addition, mobile computers can have different policies applied
depending on the site where the computer connects to the network. Keep in mind that if a site
contains computers and domain controllers from multiple domains, a site-linked GPO affects
objects from multiple domains. For simplicity, when you have only one site and one domain,
domain GPOs should be used rather than site-linked GPOs. As you might imagine, using site-
linked GPOs can be confusing for users, particularly with a lot of user mobility between sites, so
site-linked GPOs should be used with caution and only when there are valid reasons for differ-
ent sites to have different policies.
Understanding Domain-Linked GPOs GPOs set at the domain level should contain
settings that you want to apply to all objects in the domain. The Default Domain Policy is con-
figured and linked to the domain object by default and mostly defines user account policies.
Account policies can be defined only at the domain level. Typically, they're configured by using
the Default Domain Policy but can use a different GPO, as long as it's linked to the domain
object.
Active Directory folders, such as Computers and Users, are not OUs and, therefore, can't
have a GPO linked to them. Only domain-linked GPOs and site-linked GPOs affect objects in
these folders. If you need to manage objects in these folders with group policies, moving the
objects to OUs is recommended instead of configuring domain or site GPOs to manage them.
It might be tempting to define most group policy settings at the domain level and define
exceptions at the OU level, but in a large Active Directory structure, that strategy could become
unwieldy. Best practices suggest setting account policies and a few critical security policies at the
domain level and setting the remaining policies on GPOs linked to OUs.
Domains and their child domains aren't subject to GPO inheritance. In
other words, GPO settings applied to the coolgadgets.com domain are
not inherited by objects in the US.coolgadgets.com domain.
Understanding OU-Linked GPOs Most fine-tuning of group policies, particularly user
policies, should be done at the OU level. Because OU-linked policies are applied last, they take
precedence over site and domain policies (with the exception of account policies, which can be
applied only at the domain level). Because the majority of policies are defined at the OU level,
proper OU design is paramount in your overall Active Directory design. Users and computers
with similar policy requirements should be located in the same OU when possible.
 
Search WWH ::




Custom Search