Joe- Did you bounce the offending FRS service? Depending on the size of the replica set, all could be well in a few minutes but AFAIK you must restart FRS.
Since you have it in your Local Policy which I assume makes any regulatory-types happy, I'd just leave it till you have time to troubleshoot it further if that is necessary. Fixing FRS should resolve the problem if everything else is right. -----Original Message----- From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] Sent: Wednesday, September 09, 2009 3:22 PM To: NT System Admin Issues Subject: RE: group policy updating Bob, Thanks for the explanation, it makes it more logical for me. I looked in the FRS logs, and there's one error repeated over and over, from around July sometime. It's an Event ID: 13559, Source: NtFrs. It says that the FRS has detected that the replica root path has changed from "c:\windows\sysvol\domain" to "c:\windows\sysvol\domain". Seems like the same exact path to me, but oh well. It also says that a file with the name NTFRS_CMD_FILE_MOVE_ROOT needs to be created under the new root path. I looked in that path, and that file was there...almost. There was no underline between FILE and MOVE. I've fixed that, and we'll see in the morning if FRS is working again. In the meantime, I've gone back into the client machines that weren't taking the GPO update and manually added the login banner to their Local Security Policy. Should I go back and delete that again, in hopes that the GPO does it tonight, or should I leave it until tomorrow, and see if it works then? >>> "Free, Bob" <r...@pge.com> 9/9/2009 2:46 PM >>> Joe- First thing you need to do is figure out what is causing the version mismatch and correct it, then tackle the client side issues. Any of your clients could be encountering the problem and not processing policy correctly. I assuming that gpotool told you something like Error: Version mismatch on DCx, DS=12345, sysvol=45678 and only one of these sysvol versions is mismatched? Further assumption is that you have a problem with FRS since a) you said your DS replication was OK, and b) that's almost always what it is IME. Look at the FRS logs on that DC and see what they say and we can take it from there. Depending on what is going on with FRS, sometimes it is as simple as making an insignificant change to the GPO, saving it, undoing said change and saving it again and waiting for the new version number to replicate out. /aside I've seen %logonserver% mentioned a couple of times, you can't put a lot of store in that evar because your GPOs are based on a DFS referral for the SYSVOL[1].The DC a client is currently "communicating" with (aka SecureChannel) is not necessarily the same as the server that authenticated you interactively. What is actually used can change from that server for a variety of reasons. The :logonserver% evar also isn't maintained, it is set once at logon and stays that way until you log off and log on again. So all you can really count on it for is to tell you who authenticated your interactive logon. On the box I am typing this on, all three (%logonserver, SecureChannel & sysvol) are different DC's. If you want to know where you are getting your sysvol share from do: dfsutil /pktinfo and look for the entry something like [dc1.full.domain.name\sysvol] State:0x131 ( ACTIVE ) [1] The system volume is a domain-based DFS root, and each domain controller in the domain hosts a link replica of the share. To locate the system volume, a client computer queries the logon server for a list of DFS link replicas. The logon server returns a list of all servers in DFS that host the system volume. This list is in random order. Servers that are located in the same site that the client computer is located in are put at the top of the list. A user can be authenticated by one domain controller, and can download policies from another domain controller in the site. ./aside -----Original Message----- From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] Sent: Wednesday, September 09, 2009 1:31 PM To: NT System Admin Issues Subject: RE: group policy updating So, after I run the gpotool /checkacl, I ended up piping it to a text file, and the errors it finds, are version mismatches on the server I knew about. Here's where I stand: 3 DCs MoDC01 - 2K3 Virtual MoDC04 - 2K8 Virtual WSDC02 - 2K3 Physical GPMC is installed on MoDC04, and that's where I made the GP change. The change is to a policy we call Member Server Policy, and I added a login banner to it. Prior to this change, the login banner that existed was input manually, most into the Local Security Policy, and a few to the registry at: Machine\Software\Microsoft\Windows NT\Winlogin\. Immediately after applying the GPO change on MoDC04, I went back through the servers that were set manually before, and deleted the entries in Local Security Policy, and the registry (data, not the keys themselves) Yesterday afternoon, I noticed some client servers weren't updating the GPO. I tried gpupdate /force with no luck. This morning, after troubleshooting, I found that the "bad" clients are connected to various DCs for logonserver. Also found out that MoDC01 does not have the changes made to the GPO. MoDC04 and WSDC02 are both the same, with the latest changes. I've looked at replmon, which shows all sucesses. I've turned on verbose logging on a client server that is having issues, and it doesn't list the Member Server Policy at all. I've used gpotool, and the errors it shows are the version mismatches on MoDC01. There's nothing in that report showing lack of rights/credentials to process the GPOs. Bottom line: I have client servers that are not updating this new GPO, some trying to get it from MoDC01, some trying to get it from WSDC02, and one or two trying to get it from MoDC04. >>> "Free, Bob" <r...@pge.com> 9/9/2009 12:45 PM >>> It's far easier and more thorough to check GPOs with GPOtool.exe (ResKit). AD can be replicating fine but if FRS is having issues so can your GPO. It will evaluate both the GPT (sysvol portion replicated by FRS) and the GPC (AD portion replicated by DS replication) for any inconsistencies. It can optionally check the sysvol ACL which can also be a problem occasionally. I would run gpotool /checkacl from a system in the domain that is encountering issues. That way you can rule out any inconsistencies with the GPO plumbing on all the DCs before you start mucking around with clients. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
