2K and XP Pro clients "ignoring" Group Policy

[cpfcu]

Hi,

We're running a mixed-mode 2K AD domain with four DC's at our HQ site and one DC at a remote site. I am pushing out the Windows SUS Auto Updates client to our 2K and XP Pro client machines and I have a handful of them that are simply "ignoring" the Group Policy. No events in the clients' App or System logs, it's as if they're oblivious to the GPO... I used gpresult on the XP Pro machines and the RSOP doesn't even acknowledge the GPO, even after using gpupdate numerous times with various switches (/force, /sync, /boot). When I use ADU&C and manually connect to each DC, the GPO is correctly applied to the OU. AD doesn't seem to think we have any slow links (unless I'm looking in the wrong place). Also, a handful of the machines that are getting the GPO, report "cannot find the path specified". I gave Read/Execute permissions to Authenticated Users and Domain Computers for the folder with the MSI package (the folder is located on a file server at our HQ location). Does anyone have any suggestions?

 

[cpfcu]

That's correct, that was the whole output.

 

[mlichstein]

Oh no wonder...you added some extra commands.

Just run 'repadmin /showreps'

 

[cpfcu]

Here's the output with just /showreps:

C:\>repadmin /showreps dc=domain,dc=com dc1
Leo\dc1
DSA Options : (none)
objectGuid : 4f915d07-b451-4f60-a99b-6770fc4ae1a9
invocationID: c926c04d-cd42-49f0-9327-af6dc6cb35f8

==== INBOUND NEIGHBORS ======================================

dc=domain,dc=com
HQ\dc4 via RPC
objectGuid: f694ed0a-ace6-49be-9e90-a30436b8493f
Last attempt @ 2004-03-08 16:48.46 was successful.

==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============

C:\>

 

[mlichstein]

Dude..."repadmin /showreps dc=domain,dc=com dc1" is not the same as "repadmin /showreps"

 

[cpfcu]

That's about how well it's been going for me since February... LOL

Let me try this the right way, "live from the DC1 server console, it's Saturday Night Live":

C:\>repadmin /showreps
Leo\DC1
DSA Options : (none)
objectGuid : 4f915d07-b451-4f60-a99b-6770fc4ae1a9
invocationID: c926c04d-cd42-49f0-9327-af6dc6cb35f8

==== INBOUND NEIGHBORS ======================================

CN=Schema,CN=Configuration,DC=domain,DC=com
HQ\DC4 via RPC
objectGuid: f694ed0a-ace6-49be-9e90-a30436b8493f
Last attempt @ 2004-03-08 16:48.46 was successful.

CN=Configuration,DC=domain,DC=com
HQ\DC4 via RPC
objectGuid: f694ed0a-ace6-49be-9e90-a30436b8493f
Last attempt @ 2004-03-08 16:48.46 was successful.

DC=domain,DC=com
HQ\DC4 via RPC
objectGuid: f694ed0a-ace6-49be-9e90-a30436b8493f
Last attempt @ 2004-03-08 16:48.46 was successful.

==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============

C:\>

 

[mlichstein]

How many other DCs are there in this domain. Do they have any errors in their file replication logs?

Also, are you running a firewall on any of these servers?

 

[cpfcu]

There are 4 other DCs in the domain, all at the HQ site. I will get back to you on the FRS logs. No firewall on any of the DC's (only between them and the Internet), just virus protection.

 

[markdmac]

We had problems at a client site with replication between DCs that sounds similar to your troubles.

Might I suggest that you also check the status of your FSMO roles on each of your DCs. You will probably find that they don't agree with each other.

I hope you find this post helpful. Please let me know if it was.

Regards,

Mark

 

[cpfcu]

Mark,

I will check that also, thank you for the suggestion!

 

[cpfcu]

Sorry everyone, I may have to look at this tomorrow. We just completed a software upgrade and it still has me tied up for now. Thank you for your help!

 

[cpfcu]

OK, sorry for the delay, I have checked the FRS logs on all servers except DC1 (DC1 is at the Leo site, DC2 - DC5 are at the HQ site). Here is a summary of the warnings:

DC2: on 2/28/04 it shows 1 13562, 2 13509's, and 3 13508's; on 2/11/04 it shows 1 13508 and 13562; and on 2/10/04 it shows 1 13509 and 1 13508.

DC3: shows 3 13508's per day from 3/15/04 through 3/8/04.

DC4: no warnings from 3/4/04 through 6/26/03 (note that DC4 was the DC listed in the repadmin /showreps command from DC1. Also, DC4 holds the FSMO roles).

DC5: on 2/11/04 it shows 1 13508; on 11/12/03 it shows 1 13508; and on 10/23/03 it shows 1 13509 and 1 13508.

For reference, here are the warning descriptions:

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13562
Date: 2/28/2004
Time: 7:13:49 PM
User: N/A
Computer:
Description:
Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller DC.domain.com for FRS replica set configuration information.

Could not find computer object for this computer. Will try again at next polling cycle.

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13509
Date: 2/28/2004
Time: 6:07:04 PM
User: N/A
Computer:
Description:
The File Replication Service has enabled replication from DCx to DCx for c:\winnt\sysvol\domain after repeated retries.

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13508
Date: 2/28/2004
Time: 5:03:22 PM
User: N/A
Computer:
Description:
The File Replication Service is having trouble enabling replication from DCx to DCx for c:\winnt\sysvol\domain using the DNS name dcx.domain.com. FRS will keep retrying.

Following are some of the reasons you would see this warning.

[1] FRS can not correctly resolve the DNS name dcx.domain.com from this computer.
[2] FRS is not running on dcx.domain.com.
[3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.

This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.

 

[cpfcu]

And DC4 is the only connection object listed under AD Sites/Leo/Servers/DC1/NTDS Settings, thus the output of the repadmin /showreps command.

 

[h11]

Have you look into your dns servers on this issue?? It seems that this all revolves around a dns problem. If you use Ad and your dns is not working or functioning properly you will not be able to replicate to your other servers because they have no ideal what dc2, dc3, dc4 and dc5 are. Check in your dns server for a record pointer for all your servers.

 

[cpfcu]

After checking the DNS service on all DC's, they all show the correct A and PTR records for each other and no recent warnings or errors in the event logs.

 

[h11]

Ok try ping them by their names and also do a dns lookup on them to see if they resolve. in other words ping dc3 or nslookup dc3

 

[cpfcu]

All from my workstation, I pinged each DC and then used nslookup across all DC's for each DC. In other words, nslookup dc1 dc1, nslookup dc1 dc2, nslookup dc1 dc3, etc. Everything resolves OK. Should I try using Terminal Services and repeating from each server console, or would that be the same thing as specifying the DNS server to use in the nslookup commands?

 

[markdmac]

I'd check it on each DC just to verify results since each DC could have a different DNS configuration. Let's make sure that they all resolve OK.



I hope you find this post helpful. Please let me know if it was.

Regards,

Mark

 

[cpfcu]

I wonder if I have the DC's DNS configurations set incorrectly (in TCP/IP properties)? Here are the results from running ipconfig and nslookup for all DC's using Terminal Services:

DC1: ipconfig DNS servers are DC1, DC4, DC5, DC3, and DC2; all nslookups OK
DC2: ipconfig DNS servers are DC3, DC5, and DC4; all nslookups OK
DC3: ipconfig DNS servers are DC2, DC5, and DC4; all nslookups OK
DC4: ipconfig DNS servers are DC2, DC3, and DC5; all nslookups OK
DC5: ipconfig DNS servers are DC2, DC3, and DC4; all nslookups OK

The only variation that I noted: DC5 has RRAS, and DC4 (the FSMO) and DC5 are the only DCs where the nslookups show both the physical and RRAS IP addresses.