GPOs not being processed 1

[Knutern]

I'm having a hard time, trying to troubleshoot why GPOs are not being processed on some users.

In this case i have compared to users which are located in the same OU and two computers. The two computers are not in the same OU, but they inherit the same set of GPOs. If i logon to the same machine as the user who has problems, the GPOs are processed.

I've set the UserEnvDebugLevel value to 10002 (hex) to enable verbose logging to file on both computers, but I see no obvious error.

I even experienced this behaviour on my own machine but i disappeared without me doing anything.

Concerning DNS, i've checked this too (using network monitor from the moment the laptop is on until logon is finished). No problems whatsoever, any DNS-lookup will execute and return expected values. Normally, our logon scripts are being executed from one of the GPOs. In this case however, I even changed the value of "Logon Script" of the user account, but not even the logon script is being run.

The NIC driver is the latest one available.

Has anyone out there experienced alike?



Cheers
Knutern

 

[avilov]

I would check that Loopback Processsing is not enabled in one of your policies. You can find it under Computer config\Admin templates\Systerm

if that didn't help check

http://technet2.microsoft.com/Windo...0c627456-5dfa-44db-b43a-e41c8f4f09231033.mspx

 

[djtech2k]

How are you applying the GPO's? I mean as in what groups? The default is authenticated users, which should get everyone.

Have you checked rsop.msc to see what settings are in place? Have you tried gpresult command to see what policies are inherited?

If those things verify that you are not getting the GPO, then I would guess that you have an AD topology or replication issue. It is possible that a specific user account is corrupted or not being known as an authenticated user, but if it is more than one user, it is unlikely.

 

[downloadkid]

download the gpmc tool from ms and run on a client machine the rsop logging to see if all the gpos are being applied to a given user on a given machine. The gpmc tends to provide a little more detail highlighting errors encountered.
from there you can then start the process of eliminations.
what type of environment have you set up? Is it a 2003 and xp clinet, or are the machines that seem to have the issues 2000 etc.

 

[Knutern]

loopback processing is not enabled.

I'm currently browsing the troubleshooting link you sent me, but on another note: if i enable logging on the client machine (HKLM\SW\MS\Windows NT\Current Version\Diagnostics, key RunDiagnosticLoggingGlobal, value 1 hex) it is of no help. I still have very little information in the application event log to troubleshoot from.

The GPOs are applied to authenticated users, otherwise it would not have worked when the users logs on to another machine. If I log onto the machin, the GPOs are being processed, and this rules out that there is something wrong with inheritence.

I will definitely try GPMC from the client machine.

Cheers
Knutern

 

[djtech2k]

Although unlikely, the user could have removed some permissions from the registry and essentially blocked GPO. I know this would take a knowledgable user, but it is possible to do.

 

[Knutern]

Just to let you know, we never really found out why GPOs were not applied. But on any machine this problem occured, logon would take from 15 minutes to more than one hour! Logoff too.

We found a "workaround/solution" though: by deleting the users profile (local and on server) the problems where gone by next logon.

DNS was working, GPResult returned the expected results etc. and all the other troubleshooting tips revealed nothing that could get us closer to this problem.

Thanks all who tried to help!

Cheers
Knutern

 

[Knutern]

Problem solved!!!!!

We found out, by accident, why this occurs: some of our users had installed Messenger 5.1 (for use with Exchange Live Communication) while our GPO installs 5.0.

Upon logon, when the GPOs are being applied, it determines that Messenger is not equal 5.0 and tries to install 5.0 over the 5.1 version, and voila.

What troubles me is, that this condition is not mentioned in the event log - normally. Not even when debuggin (all possible) was enabled.

However, one of my colleagues - he's a programmer - managed to provoke something which led to an entry in the event log. Then did some research and was able to reproduce it, and thereby solved it.

Cheers
Knutern