Computer Configuration/User Configuration cross-usage

[Neko-]

I'm currently looking into Group Policies (Windows 2003), and have
found something that (according to the training material Microsoft
provides) should be possible, but upon trying some things out in a live
environment was shown not to work.

Now maybe I'm overlooking something here, but I can't see what I'd be
missing. Maybe someone on this group can provide a bit more insight in
what is going on.

I have two OU's. One contains the computer account (Windows XP
machine), and the other contains the user account. I have created a
policy to provide a logo for the background like you would do in a
company environment. This setting I activated through the use of the
User Configuration\Administrative Templates\Desktop\Active Desktop. I
enabled the 'Active Desktop' setting here, and added the appropriate
picture to the 'Active Desktop Wallpaper' setting.

I then linked the policy to the container in which the useraccount
resided. Logged off the workstation, and logged in, which provided me
with the wallpaper as expected.

Since a company is more likely to consider adding a wallpaper to it's
computers rather then it's users, the next test was to set this same
policy to the container with the computer account. I unlinked the GPO
from the OU containing the user object, and linked it to the OU that
had the computerobject. I removed the policy on the workstation
alltogether, then replaced the background with some other picture just
to verify that the policy would change the wallpaper back.

Ran 'GPUpdate /force', restarted the PC to make sure that applying the
settings were done as would normally happen, but alas... no wallpaper
was assigned. Since the GPO was tested under the user account, the
actual properties of the GPO seem sound.

Now my theory is that any User Configuration settings will only be
applied to user accounts, and never to machine accounts. Although it
seems logical that the whole GPO should be applied if it applies to the
object. According to Microsoft it should be possible to use the logical
approach, and deduce that if a policy is applicable to an object it
will be processed as a whole, so both the Computer Configuration and
the User Configuration.

Now the rights are set to standard (meaning that only Authenticated
Users have access to the policy). This would be the only part I'd be
guessing that could hamper the policy itself. But thinking about it
logically, the computer does authenticate itself to the domain prior to
presenting a logon-screen. Would that be seen as an 'Authenticated
User', or does some group exist depicting 'Authenticated Computers'?

I've verified that (as is default) no part of the policy is set to
not-process (properties of the policy itself allows you to speed up
policy processing by disabling or enabling the Computer Configuration
node and/or the User Configuration node. Standard both are enabled). So
I'm also ruling this out as a cause.

Does anyone have more expirience with this, and is willing to share and
help me out in figuring this part out? Thanks in advance!

 

[Guest]

Hi Neko,

take a look at Loopback Processing of Group Policy maybe help to your cenari
http://www.microsoft.com/technet/pr...elp/abe2b1a9-975f-4b2f-b771-9e6a903e97db.mspx

Regards

 

[Neko-]

Loopback isn't enabled... Not by default anyway. And this reapplies the
computer settings *after* setting the user settings (if need be
overwriting certain user settings based on the merge or replace
option).

Now since I removed the policy alltogether and manually added a
background picture, then restarted, I assuming the following happened
recapping the whole: (each subsequent policy adds/replaces parts of the
previous ones):

* Computer executes policy (and should set a background I selected for
any user logging on on that computer)
- local policy has a background setting
- site policy isn't active
- domain policy is active, but has no settings for backgrounds
- OU policy has the background setting

* User executes policy (which isn't linked and as such does not
overwrite any settings made by the computer profile)
- local policy has a background setting (possibly overwriting the
previous computer background setting?)
- site policy not active
- domain policy is active, but has no settings for backgrounds
- OU policy isn't active.

So if this is indeed the order in which the whole thing is run, that'd
mean that the local user policy always is going to override the
computer OU linked policy. (listing it like this is giving me things
that may or may not be correct, but it atleast gives me idea's on what
might be happening. I seem to have provided atleast the thought-path to
solve my own problem )

I could try playing with loopback, aswell as the 'no-override'/enforced
option. It would be interesting to see if that actually does something,
so I'm noting that for a minor test tonight. If that does not work I
could try for removing the domain policy and verifying if that makes a
difference.

Thanks anyway for atleast replying. It's appreciated

 

[Neko-]

I asked the question at the site I could test the issue, prior to
testing. His believe (at that moment) was that the computer
configuration just applied to computer objects, and no user
configuration was applied. The other side of the coin was that the user
configuration was just applied to user objects. This did not comply
totally with certain items Microsoft tells us, so I did a minor test
and indeed loopback policy solved the issue.

I did manage to find out why that policy isn't applied straight from
the computer object policy even if no changes are made through later
policies, and the possible cause of some of the 'computer objects do
not process user configurations' confusion.

The computer logs on to the domain, and through the 'Authenticated
Users' gains access to process the policy. The computer settings are
imported into the HKEY_LOCAL_MACHINE (HKLM) registry key. The user
settings would be imported into the HKEY_CURRENT_USER (HKCU) key... if
it existed at that point in time.

Since the HKCU key is created when the user logs on, no settings made
to the user configuration node of the policy can be applied to the
computer object. There is nothing to apply them to.

As the user logs on the HKCU key is created, and can be filled, so
reapplying the policy through loopback then allows the user
configuration node to accurately dump it's information to HKCU, and
hence provide the requested items.

Hope this helps some people looking for why this issue didn't work
figure out what was going on.

 

[fmastro]

Thanks this post helped me solve my problem.

 

[Guest]

This was an excellent post that explained much. I had the same questions as
to why the user node of a policy was not being applied.

 

[Neko-]

No biggy... It only became clear to me after looking at the issue, and
hearing some other input regarding the nodes affected by the policy
bits.

Actually, it's pretty obvious if you know this, and think about how
it's applied. If you don't know this it might be a hassle tho to
figure out how certain things do not get applied and how it can be
solved.

Anyway, glad to be of help to people here

Neko-