GPOs not being applied

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a Win2K Ad Srvr (w/SP4) that does not apply any GPO
settings, local and/or domain level. The computer object
resides in the built-in 'computers' container, so only the
local and Default-Domain Policies should apply.

When I run the
'secedit /refreshpolicy machine_policy /enforce' command,
I get an SRV 2000 error in the event log:

Source: Userenv
Category: None
Event ID: 1000
User: NT Authority\System
Description:
Windows cannot query for the list of Group Policy
objects. A message that describes the reason for this was
previously logged by this computer.


It seems that the server has an old version of the
policies (having ran gpresult), but the new versions never
get applied. I have checked and the 'disable
computer/user configuration settings' are cleared.

I have 20 others servers in the 'computers' container and
only this one gives me this problem, so I suspect it is
something local.

I am at my wits end. Please help :-0
 
This almost sounds like a DNS issue... is this server set
up the same as the others, with regards to DNS?
 
That's what makes it all the more interesting... This
server points to the exact same DNS as the others.

For kicks, I even explicity gave the computer object read
and apply group policy 'allow' rights on the GPO and
nothing.

:-(
 
Any hosts or lmhosts file on it?
-----Original Message-----
That's what makes it all the more interesting... This
server points to the exact same DNS as the others.

For kicks, I even explicity gave the computer object read
and apply group policy 'allow' rights on the GPO and
nothing.

:-(
Click to expand...
 
This just keeps getting better...

To answer Ken, there are no hosts and lmhosts file; good
thought though!

To answer Derek, I have not seen any Deny's in the ACLs.

An interesting developement. Friday night, the
description changed for the Userenv 1000 error to
read: "Windows cannot determine the user or computer name.
Return value (1326)."

So, I removed the server from the domain, and rejoined
it. Once I rebooted after the rejoin, EventID 1704
(SceCli) was logged telling me the security policy in the
Group Policy objects are applied successfully. :-0

But wait, 7 minutes later, I am back to square one with
Userenv 1000 again telling me ...Windows cannot query...

Arrrgh!
 
I have removed the server from the domain and rejoined it
without any errors.

When the server was in a workgroup, the local policy was
applied. However, once I joined the domain Userenv 1000
errors started appearing again.

Thanks for the help!
 
Derek,

Thanks a bunch for your help!!!

I checked if it were a DNS problem. I ran netdiag in
verbose, I double-checked that all SRV records were
present and I ran nslookup on the SRV records from the
problem server, and all tests passed. I'm more than
confused now. If I am missing some tests, please let me
know.

Let me recap....All DNS configurations are correct (client
side and server side), the problem server is unique (no
duplicate SIDs, IPAs or name). There are no Deny ACLs and
authenticated users have Read and Apply GP permissions on
the GPO. No LMHOSTS nor HOSTS file is being used. The
GPO is not being blocked. All other servers in
the 'Computer' container have no problem.

When the problem server is a member of a workgroup, the
local GPO is applied. However, once I join the domain, I
get Userenv 1000 errors:
Source: Userenv
Category: None
Event ID: 1000
User: NT Authority\System
Description:
Windows cannot query for the list of Group Policy
objects. A message that describes the reason for
this was previously logged by this computer.

Am I missing something here? :-(

You would think that it is a DNS issue, but oddly enough
the problem server can resolve the SRV records.

This one is turning out to be a real stumper. Any other
ideas/suggestions?

Thanks again for the help!
 
how about the user side of things? Try this:

1) create a new OU
2) create a new user named Joe in the OU
3) create a new GPO and link it to the new OU
4) configure the GPO to remove the run command
5) log in as Joe to the "problem" computer
6) if the run command is removed, then move the "problem computer to the new
OU
7) configure the GPO linked to the new OU to now "not show the last logged
in user" (this is a computer configuration)
8) restart the "problem" computer and log on as Joe
9) logoff as Joe and now when you hit Ctrl-Alt-Del, there should not be any
name in the username box.

if this works, then there is something odd happening with the original OU.
If this fails for Joe and the "problem" computer, then the computer is
having trouble with the domain in some way, most likely a SID or name
duplication. If it is a SID problem, my guess is that a tool like ghost or
drive image was used on this computer, or another computer on the network.
If Joe works and the "problem" computer still fails, I would still lean
towards the SID, name duplication, or DNS area.

If all of this fails, I would turn on verbose logging and see what I can
find in the logs. If you need help tracking those down, I can help you with
those settings.

Let me know.
 
Just in case...see a GP that does not get applied and write down its
GUID.
Then see if the "problem" computer has access to the gpt.ini file
inside the gpt folder (in the sysvol share) named after its GUID.

Good Luck
 
I tried your suggestion. The user policy was applied to
Joe, but the computer policy was not applied to
the "problem" computer.

I used ntdsutil to check for duplicate SIDs and found
none. I used nbtstat -n and checked WINS to look for
duplicate names and found none. And nslookup verifies the
srv records... hmm... :-(

What logging are you talking about?

Thanks!
 
Thanks! After more research, I also
added: "RunDiagnosticLoggingGroupPolicy"
under
"HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Diagnostics"


After rebooting here is what the userenv.log logged (see
below):

I can't find anything worth while on the net with the
following: USERENV(10c.3d0) 13:23:15:476 GetMachineToken:
AcceptSecurityContext failed with 0x8009030c
USERENV(10c.3d0) 13:23:15:476 GetGPOInfo: Failed to get
the machine token with -2146893044

Complete list:
SERENV(2f0.a24) 13:23:15:304 LibMain: Process Name:
C:\WINNT\system32\secedit.exe
USERENV(2f0.a24) 13:23:15:320 RefreshPolicy: Entering with
1
USERENV(2f0.a24) 13:23:15:320 RefreshPolicy: Leaving.
USERENV(10c.3d0) 13:23:15:320 ProcessGPOs:
USERENV(10c.3d0) 13:23:15:351 ProcessGPOs:
USERENV(10c.3d0) 13:23:15:351 ProcessGPOs: Starting
computer Group Policy processing...
USERENV(10c.3d0) 13:23:15:367 ProcessGPOs:
USERENV(10c.3d0) 13:23:15:367 ProcessGPOs:
USERENV(10c.3d0) 13:23:15:382 ProcessGPOs: Verbose output
to eventlog requested.
USERENV(10c.3d0) 13:23:15:382 EnterCriticalPolicySection:
Machine critical section has been claimed. Handle = 0x538
USERENV(10c.3d0) 13:23:15:398 ProcessGPOs: Machine role
is 2.
USERENV(10c.3d0) 13:23:15:398 PingComputer: PingBufferSize
set as 2048
USERENV(10c.3d0) 13:23:15:414 PingComputer: First time: 0
USERENV(10c.3d0) 13:23:15:414 PingComputer: Fast link.
Exiting.
USERENV(10c.3d0) 13:23:15:429 ProcessGPOs: User name is:
CN=SERVERNAME,CN=TEST,DC=ROOT DC=COM, Domain name is:
DOMAIN
USERENV(10c.3d0) 13:23:15:429 ProcessGPOs: Domain
controller is: \\DC.root.com Domain DN is root.com
USERENV(10c.3d0) 13:23:15:445 ProcessGPOs: Calling
GetGPOInfo for normal policy mode
USERENV(10c.3d0) 13:23:15:445 GetGPOInfo:
********************************
USERENV(10c.3d0) 13:23:15:460 GetGPOInfo: Entering...
USERENV(10c.3d0) 13:23:15:476 GetMachineToken:
AcceptSecurityContext failed with 0x8009030c
USERENV(10c.3d0) 13:23:15:476 GetGPOInfo: Failed to get
the machine token with -2146893044
USERENV(10c.3d0) 13:23:15:492 GetGPOInfo: Leaving with 0
USERENV(10c.3d0) 13:23:15:492 GetGPOInfo:
********************************
USERENV(10c.3d0) 13:23:15:507 ProcessGPOs: GetGPOInfo
failed.
USERENV(10c.3d0) 13:23:15:507 LeaveCriticalPolicySection:
Critical section 0x538 has been released.
USERENV(10c.3d0) 13:23:15:523 ProcessGPOs: Computer Group
Policy has been applied.
USERENV(10c.3d0) 13:23:15:523 ProcessGPOs: Leaving with 0.
USERENV(10c.3d0) 13:23:15:539 GPOThread: Next refresh
will happen in 98 minutes
 
I fixed it!!! :-0

Thanks for all your suggestions.

After several tests using netdiag, one result came up with
the trust relationship b/n domain and the server as
failed. The obvious solution was to remove the server
from the domain and rejoin it. Which about two weeks ago,
I DID!

However, the one step that I didn't do was after I removed
the server from the domain to actually delete the computer
account from AD and replicate. Then, re-add the computer
account and replicate. Only then did I re-join the domain.

I am still wondering what caused the trust relationship to
break. But, being that I didn't build the server from
scratch...I'll never know.

Thanks Derek!
 
AH!

You know, I always do that, remove the computer account from AD. I guess I
get lucky:-).

I am very glad you figured this out. AS for why computers lose their trust
with the domain... it is a mystery to me! However, it does happen!
 
Back
Top