Group Policy Processing Exceptions
As with everything, there are always
exceptions to the rules.
If a workstation is in a domain and a user logs on with a
LOCAL account only, the computer configuration settings are
processed only and then any LOCAL user account
configurations. Also, if you log on to a domain member that
is disconnected from the network with a CACHED DOMAIN ID,
you will not get your UPDATED user configuration settings.
You will log on with the CACHED credentials ONLY.
GPOs may be affected by Block Policy Inheritance and
No Override settings.
Site, domain, or OU level group policy
inheritances can be blocked via the Block Policy Inheritance setting. (GPO links set to No Override are
always applied and cannot be blocked — I will mention this
in a minute.)
Block Policy Inheritance is applied at the site,
domain, or OU level and is an all or nothing deal. It cannot
be applied to specific GPOs or the links. If you set Block
Policy Inheritance at the site level, then all of the site
level group policy settings from all site level linked GPOs
are stopped. If you set Block Policy Inheritance at the
domain level, then all of the domain level group policy
settings from all domain level linked GPOs are stopped. If
you set Block Policy Inheritance at the OU level, then all
of the OU level group policy settings from all OU level
linked GPOs are stopped from any and all GPOs linked at that
OU and all inheritance is stopped from that OU as well.
[NOTES FROM THE FIELD] – If
you set Block Policy Inheritance at the OU level, it will
affect inheritance from that OU down if the GPOs are set to
that OU. Anything lower in the hierarchy is not affected.
That is, if you have an OU called US and child OUs named NY,
MA and CT and if the children of each one of those are Sales and
Management, and you place a Block Policy Inheritance at US,
you will stop anything set at US from propagating down to
all of the OUs below it. If you set three identical GPOs,
one at NY, MA and CT, these WILL propagate down to the Sales
and Management OUs.
No Override is applied to the
GPO links, and it always trumps Block Policy Inheritance. If
Block Policy Inheritance is set at the site level and there
are three site level GPOs and one of them has No Override
set to it, then Block Policy Inheritance will stop the other
two but not the one set to No Override.
GPOs linked to sites, domains, or OUs
can be set to No Override so that none of its policy
settings can be overridden at any level. That is, if site
level GPO C is executed third and wants to change a setting
that No Override site level GPO A set, it won’t be able to
since No Override was set. If any domain level GPOs (which
are processed AFTER all of the site level GPOs are
processed) attempts to change a setting forced from the site
level GPO it will not be able to do so either.
[NOTES FROM THE FIELD] –
This is a very sticky and difficult exception to wrap your
head around. (It was for me anyway.) There is a great
download on the
Microsoft website and the main page it is on also defines
this as well:
“You can set No Override on a
specific Group Policy object link so that Group Policy
objects linked at a lower-level of Active Directory, closer
to the recipient user or computer account, cannot override
that policy. If you do this, Group Policy objects linked at
the same level, but not as No Override, are also prevented
from overriding. If you have several links set to No
Override, at the same level of Active Directory, then you
need to prioritize them. Links higher in the list have
priority on all Configured (that is, Enabled or Disabled)
settings.
If you have linked a specific Group Policy object to a
domain, and set the Group Policy object link to No Override,
then the configured Group Policy settings that the Group
Policy object contains apply to all organizational units
under that domain. Group Policy objects linked to
organizational units cannot override that domain-linked
Group Policy object.”
GPOs may also be affected by a
Loopback setting, which provides alternatives to the
default method of obtaining and executing the normal order and
processing of computer and user configurations.
Domain user settings come from a GPO
list that depends on all of the factors mentioned earlier.
Local GPOs are first, then site GPOs, followed by domain
GPOs, and finally OU GPOs, as well as any ordering lined up
by the domain administrator and so on.
In some cases you might not want to
have user specific settings applied to certain computers.
For example, you might have a software deployment set to
your user ID so that no matter where you went in the domain
and no matter which computer you logged on to, it would allow you
to have that program at your disposal. This might not be
warranted on a server that you need to log on to locally
with your domain ID. This is where loopback is an asset.
Loopback can be set to Not Configured, Enabled, or Disabled,
just like any other group policy setting. Once loopback is
enabled it can be set to Merge or Replace.
When Replace is set, the GPO list for the user is
entirely overwritten again by the computer configuration
GPO. The computer configuration GPOs replaces the user
configuration GPO in its entirety.
[NOTES FROM THE FIELD] – In
this scenario the computer configuration GPO is run at
startup and every time a user logs on to the given computer
or server their user configuration GPO is run. However,
before the GUI appears to allow the user to work on system,
the computer configuration GPO is run again to “correct” all
of the user configuration GPO settings by overwriting them.
When Merge is used, the GPO list is obtained for the
computer at startup and is appended to the GPO list obtained
for the user after they log on. Basically the computer
configuration is applied again later which allows it to take
precedence if it conflicts with settings in the user’s list,
but it may not overwrite all of the settings made by the
user configuration GPO.
[NOTES FROM THE FIELD] – In
this scenario the computer configuration GPO is run at
startup and every time a user logs on to the given computer
or server their user configuration GPO is run. However,
before the GUI appears to allow the user to work on system,
the computer configuration GPO is run again to “append” all
of the user configuration GPO settings by ADDING the
computer configuration GPO settings to the system again.
This may not overwrite all of the settings made by the user
configuration GPO like the loopback replace setting does.
Well, that wraps up this section
of Windows 2000
Active Directory Group Policy. I hope you found it informative and
will return for the next installment of Learn Active
Directory Design and Administration in 15 Minutes a Week.
If you have any questions, comments or
even constructive criticism, please feel free to drop me a
note.
I want to write good, solid technical
articles that appeal to a large range of readers and skill
levels and I can only be sure of that through your feedback.
Next week, I plan to start with an
overview of the Lightweight Directory Access Protocol (LDAP). (Really, I promise!)
Until then, best of luck in your
studies.
“F.Y.I. can mean more than one thing”
Jason Zandri
Jason@Zandri.net