Your company has an organizational unit named Production. The Production organizational
unit has a child organizational unit named R&D. You create a GPO named Software
Deployment and link it to the Production organizational unit.

You create a shadow group for the R&D organizational unit. You need to deploy an
application to users in the Production organizational unit.
You also need to ensure that the application is not deployed to users in the R&D
organizational unit.
What are two possible ways to achieve this goal? (Each correct answer presents a complete
solution. Choose two.)

A.
Configure the Block Inheritance setting on the R&D organizational unit.

B.
Configure the Enforce setting on the software deployment GPO.

C.
Configure security filtering on the Software Deployment GPO to Deny Apply group policy
for the R&D security group.

D.
Configure the Block Inheritance setting on the Production organizational unit.

Explanation:
Answer) Configure the Block Inheritance setting on the R&D organizational unit.
Configure security filtering on the Software Deployment GPO to Deny Apply group policy for
the R&D security group.

http://technet.microsoft.com/en-us/library/cc757050%28v=ws.10%29.aspx
Managing inheritance of Group Policy
..
Blocking Group Policy inheritance
You can block policy inheritance for a domain or organizational unit. Using block inheritance
prevents GPOs linked to higher sites, domains, or organizational units from being
automatically inherited by the child-level. By default, children inherit all GPOs from the
parent, but it is sometimes useful to block inheritance. For example, if you want to apply a
single set of policies to an entire domain except for one organizational unit, you can link the
required GPOs at the domain level (from which all organizational units inherit policies by
default) and then block inheritance only on the organizational unit to which the policies
should not be applied.
Enforcing a GPO link You can specify that the settings in a GPO link should take
precedence over the settings of any child object by setting that link to Enforced. GPO-links
that are enforced cannot be blocked from the parent container. Without enforcement from
above, the settings of the GPO links at the higher level (parent) are overwritten by settings in
GPOs linked to child organizational units, if the GPOs contain conflicting settings. With
enforcement, the parent
GPO link always has precedence. By default, GPO links are not enforced. In tools prior to
GPMC, “enforced” was known as “No override.”
..
In addition to using GPO links to apply policies, you can also control how GPOs are applied
by using security filters or WMI filters.
http://technet.microsoft.com/en-us/library/cc781988%28v=ws.10%29.aspx
Security filtering using GPMC
Security filtering Security filtering is a way of refining which users and computers will receive
and apply the settings in a Group Policy object (GPO). Using security filtering, you can
specify that only certain security principals within a container where the GPO is linked apply

the GPO. Security group filtering determines whether the GPO as a whole applies to groups,
users, or computers; it cannot be used selectively on different settings within a GPO.
..
Notes:
GPOs cannot be linked directly to users, computers, or security groups. They can only be
linked to sites, domains and organizational units. However, by using security filtering, you
can narrow the scope of a GPO so that it applies only to a single group, user, or computer.
..
The location of a security group in Active Directory is irrelevant to security group filtering
and, more generally, irrelevant to Group Policy processing.
Further information:
http://technet.microsoft.com/en-us/library/cc731076.aspx
Block Inheritance
http://en.wikipedia.org/wiki/Active_Directory#Shadow_groups
Active Directory
Shadow groups
In Microsoft’s Active Directory, OUs do not confer access permissions, and objects placed
within OUs are not automatically assigned access privileges based on their containing OU.
This is a design limitation specific to Active Directory. Other competing directories such as
Novell NDS are able to assign access privileges through object placement within an OU.
Active Directory requires a separate step for an administrator to assign an object in an OU
as a member of a group also within that OU. Relying on OU location alone to determine
access permissions is unreliable, because the object may not have been assigned to the
group object for that OU. A common workaround for an Active Directory administrator is to
write a custom PowerShell or Visual Basic script to automatically create and maintain a user
group for each OU in their directory. The scripts are run periodically to update the group to
match the OU’s account membership, but are unable to instantly update the security groups
anytime the directory changes, as occurs in competing directories where security is directly
implemented into the directory itself. Such groups are known as Shadow Groups. Once
created, these shadow groups are selectable in place of the OU in the administrative tools.
Microsoft refers to shadow groups in the Server 2008 Reference documentation, but does
not explain how to create them. There are no built-in server methods or console snap-ins for
managing shadow groups.[5]
The division of an organization’s information infrastructure into a hierarchy of one or more
domains and toplevel OUs is a key decision. Common models are by business unit, by
geographical location, by IT Service, or by object type and hybrids of these. OUs should be
structured primarily to facilitate administrative delegation, and secondarily, to facilitate group
policy application. Although OUs form an administrative boundary, the only true security
boundary is the forest itself and an administrator of any domain in the forest must be trusted
across all domains in the forest.[6]