none
Group Policy Processing Failure Just the Start of my Issues

    Question

  • Hi,

    I've recently joined a company with a lot of problems.  In general domain services work well, apart from at one campus, where staff frequently complain of issues which translate into tech speak as group policy not processing, folder redirects not working and the user profile service not processing domain login requests properly, logging staff on with temp accounts.

    Today I checked for myself by putting my computer and user accounts into the same OU as the staff on this campus and sure enough, it's all gone to hell.  Can't load my profile at all and group policy won't process, complaining it can't find the policy file:

    C:\Users\TEMP>gpresult /r
    INFO: The user does not have RSOP data.

    C:\Users\TEMP>gpupdate /force
    Updating Policy...

    User policy could not be updated successfully. The following errors were encount
    ered:

    The processing of Group Policy failed. Windows attempted to read the file \\domain.net\sysvol\domain.net\Policies\{91D18D8C-12D9-40E3-92C3-5B4E2104C398}\g
    pt.ini from a domain controller and was not successful. Group Policy settings ma
    y not be applied until this event is resolved. This issue may be transient and c
    ould be caused by one or more of the following:
    a) Name Resolution/Network Connectivity to the current domain controller.
    b) File Replication Service Latency (a file created on another domain controller
     has not replicated to the current domain controller).
    c) The Distributed File System (DFS) client has been disabled.
    Computer policy could not be updated successfully. The following errors were enc
    ountered:

    The processing of Group Policy failed. Windows attempted to read the file \\domain.net\SysVol\domain.net\Policies\{8DC41EB6-545A-4D9E-8A3A-954CB2A2D9E9}\g
    pt.ini from a domain controller and was not successful. Group Policy settings ma
    y not be applied until this event is resolved. This issue may be transient and c
    ould be caused by one or more of the following:
    a) Name Resolution/Network Connectivity to the current domain controller.
    b) File Replication Service Latency (a file created on another domain controller
     has not replicated to the current domain controller).
    c) The Distributed File System (DFS) client has been disabled.

    To diagnose the failure, review the event log or run GPRESULT /H GPReport.html f
    rom the command line to access information about Group Policy results.

    I tried to see if I could find it manually by logging on to the DC at the campus and trying to browse the DFS path to the sysvol folder that contains the policies - sure enough, it's missing.  I check with the UNC path and it's the same.

    I try group policy modelling by specifying my user and computer account and selecting the DC at the campus; it generates the following error:

    Group Policy Infrastructure failed due to the error listed below.
    The system cannot find the path specified.
    Note: Due to the GP Core failure, none of the other Group Policy components processed their policy. Consequently, status information for the other components is not available.

    If I process the same from another DC on campus it processes without error.  There is a third DC here; it also produced the above error.  At this point I am becoming suspicious; I check and all 3 DCs have themselves as primary DNS server.

    A comparison of the sysvol policies folders on all 3 show different results on each.  Other DCs in the domain have 85 policy folders; 2 of the DCs on this campus have less and one has more (!).

    I am able to identify the missing policy as one which was implemented 9th April 2015 - this is the same date when the above errors started logging on the server.  Having said that, the DC in question only has about 40 policies in its sysvol folder and they are all dated from 2010, so it is missing a lot, not just this one.

    Every DC in the domain which I checked is logging the following error:

    Log Name:      DNS Server
    Source:        Microsoft-Windows-DNS-Server-Service
    Date:          5/20/2015 4:23:13 PM
    Event ID:      4521
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:      server.domain.net
    Description:
    The DNS server encountered error 32 attempting to load zone [our domain] from Active Directory. The DNS server will attempt to load this zone again on the next timeout cycle. This can be caused by high Active Directory load and may be a transient condition.

    ...even servers which are not having any problems.

    My feeling is that these issues with replication, user logon and GP processing are caused by DNS.  Having said that, I'm not sure what I should be looking for.  I want to change the DNS server settings on the DCs so they are getting updates from each other rather than themselves, but since this is the way all DCs are set up in the domain I am skeptical this is the root cause.

    I am looking for advice from the community about what I should be looking for within DNS that might be causing issues.  Please let me know if you have any thoughts or questions.  Very many thanks in advance!

    Regards,

    Robert

    Wednesday, May 20, 2015 4:05 PM

Answers

  • > DCs apart from the PDCe but only 3 servers are out of whack.  As such,
    > it should be fine to process on only those 3, right?  I'd like to try
    > and minimise the scope as much as possible.
     
    Yes, of course :)
     
    > Further - of those 3 servers, only 1 is in a journal wrap state; the
    > others do not log that error, but never the less their SYSVOL folders
    > are wrong.  I can see that they are all configured to replicate to AND
    > from each other so I think this is the reason.  Also, only 1 of the 3 is
    > getting updates from the next site over.
     
    Again yes. If you do a deep dive into replication issues, in most cases
    it's only one server that really causes the problem. It depends on the
    replication topology which servers need a D2 and which don't.
     
    In this case, I'd stop replication on all 3 servers, then do a D2 on the
    one that has a replication partner in a different site, then D2 on the
    others.
     
    > data from each other.  Is it advised to change replication through AD
    > Sites & Services before making this change, so that replication can only
    > go in one direction (from the next site over), then change back to the
    > desired setup?
     
    No. "D2" means discard your sysvol content and grab it from where ever
    you can.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Wednesday, June 03, 2015 1:11 PM

All replies

  • > \\domain.net\sysvol\domain.net\Policies\{91D18D8C-12D9-40E3-92C3-5B4E2104C398}\g/
    > /pt.ini from a domain controller and was not successful. Group Policy
    > settings ma/
     
    Repair sysvol replication - it is broken, most probably due to a journal
    wrap error on the PDC emulator.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Wednesday, May 20, 2015 4:30 PM
  • Hi Martin,

    Thanks for that - albeit the issue is that the the file replication in SYSVOL isn't working, is there a way to prove that from a log or diag tool?

    I ask because most KBs I found online tended to finger DNS as the likely culprit and I can see a lot of DNS errors on the server in question.  Having said that, there are definitely some errors regarding FRS on the server:

           

    Log Name:      File Replication Service
    Source:        NtFrs
    Date:          4/21/2015 12:32:20 PM
    Event ID:      13568
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      server.domain.net
    Description:
    The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR. 

     Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 
     Replica root path is   : "c:\windows\sysvol\domain" 
     Replica root volume is : "\\.\C:" 
     A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons. 

     [1] Volume "\\.\C:" has been formatted. 
     [2] The NTFS USN journal on volume "\\.\C:" has been deleted. 
     [3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal. 
     [4] File Replication Service was not running on this computer for a long time. 
     [5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:". 
     Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state. 
     [1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service. 
     [2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set. 

    WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again. 

    To change this registry parameter, run regedit. 

    Click on Start, Run and type regedit. 

    Expand HKEY_LOCAL_MACHINE. 
    Click down the key path: 
       "System\CurrentControlSet\Services\NtFrs\Parameters" 
    Double click on the value name 
       "Enable Journal Wrap Automatic Restore" 
    and update the value. 

    If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above

    Would the above be consistent with sysvol replication issues?

    Tuesday, May 26, 2015 3:01 PM
  • Also, would I be right in thinking that the below taken from here is the correct process for carrying out a repair?

    To perform a nonauthoritative restore, stop the FRS service, configure the
    BurFlags
    registry key, and then restart the FRS service. To do so:
    1. Click Start, and then click Run.
    2. In the Open box, type cmd and then press ENTER.
    3. In the Command box, type net stop ntfrs.
    4. Click Start, and then click Run.
    5. In the Open box, type regedit and then press ENTER.
    6. Locate the following subkey in the registry:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
    7. In the right pane, double-click BurFlags.
    8. In the Edit DWORD Value dialog box, type D2 and then click OK.
    9. Quit Registry Editor, and then switch to the Command box.
    10. In the Command box, type net start ntfrs.
    11. Quit the Command box.
    When the FRS service restarts, the following actions occur:
    • The value for BurFlags registry key returns to 0.
    • Files in the reinitialized FRS folders are moved to a <var style="box-sizing:border-box;margin:0px;padding:0px;">Pre-existing</var> folder.
    • An event 13565 is logged to signal that a nonauthoritative restore is started.
    • The FRS database is rebuilt.
    • The member performs an initial join of the replica set from an upstream partner or from the computer that is specified in the Replica Set Parent registry key if a parent has been specified for SYSVOL replica sets.
    • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
    • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

    Tuesday, May 26, 2015 3:14 PM
  • sure looks like it
    Tuesday, May 26, 2015 8:49 PM
  • > The File Replication Service has detected that the replica set "DOMAIN
    > SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
     
    What I already guessed in my previous post.
     
    About the recovery procedure:
     
    First check FRS eventlog on the PDC (!) emulator. If the PDCe is fine,
    continue with D2 (non authoritative restore) on all other DCs.
     
    If the PDCe has the issue, too, then FIRST do a D4 (authoritative
    restore) on the PDCe, afterwards a D2 on all others.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Wednesday, May 27, 2015 2:36 PM
  • Hi Martin,

    Thanks again for your reply.  You recommend to process D2 on ALL other DCs apart from the PDCe but only 3 servers are out of whack.  As such, it should be fine to process on only those 3, right?  I'd like to try and minimise the scope as much as possible.

    Further - of those 3 servers, only 1 is in a journal wrap state; the others do not log that error, but never the less their SYSVOL folders are wrong.  I can see that they are all configured to replicate to AND from each other so I think this is the reason.  Also, only 1 of the 3 is getting updates from the next site over.

    Because of this I am worried that after processing D2 on all 3 they might not get the authoritative replication and instead replicate bad data from each other.  Is it advised to change replication through AD Sites & Services before making this change, so that replication can only go in one direction (from the next site over), then change back to the desired setup?

    Wednesday, June 03, 2015 9:13 AM
  • > DCs apart from the PDCe but only 3 servers are out of whack.  As such,
    > it should be fine to process on only those 3, right?  I'd like to try
    > and minimise the scope as much as possible.
     
    Yes, of course :)
     
    > Further - of those 3 servers, only 1 is in a journal wrap state; the
    > others do not log that error, but never the less their SYSVOL folders
    > are wrong.  I can see that they are all configured to replicate to AND
    > from each other so I think this is the reason.  Also, only 1 of the 3 is
    > getting updates from the next site over.
     
    Again yes. If you do a deep dive into replication issues, in most cases
    it's only one server that really causes the problem. It depends on the
    replication topology which servers need a D2 and which don't.
     
    In this case, I'd stop replication on all 3 servers, then do a D2 on the
    one that has a replication partner in a different site, then D2 on the
    others.
     
    > data from each other.  Is it advised to change replication through AD
    > Sites & Services before making this change, so that replication can only
    > go in one direction (from the next site over), then change back to the
    > desired setup?
     
    No. "D2" means discard your sysvol content and grab it from where ever
    you can.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Wednesday, June 03, 2015 1:11 PM
  • Hi Martin,

    Believe it or not we have only just attempted this today. :)

    I have disabled the FRS service on all 3 DCs on the affected site and performed a non-authoritative restore on the server with an inbound partner on another site.  I could see the following event log events:

    1. The File Replication Service is stopping
    2. The File Replication Service has stopped
    3. The File Replication Service is starting
    4. File Replication Service is initializing the system volume with data from another domain controller
    5. The File Replication Service moved the preexisting files in c:\... into c:\...
    6. The File Replication Service successfully added this computer to the following replica set...
    7. The File Replication Service successfully added the connections shown below to the replica set...
    8. The File Replication Service is having trouble enabling replication from [DC2 on same site]...
    9. The File Replication Service is having trouble enabling replication from [DC3 on same site]...

    That was the last event.  I expected the sysvol would begin replicating from the partner DC from the other site immediately; I then confirmed the replication schedule was set for once every hour, but this period has now passed and I am still not seeing any events logging to say it is happening/complete and the sysvol folder is still missing.

    I then tried to perform "Replicate now" through AD S&S by finding the affected DC, right-clicking on the inbound partner DC from the other site and hitting replicate now, but it doesn't seem to run, giving the following message:

    One or more of these Active Directory Domain Services are between Domain Controllers in different sites.  Ad DS will attempt to replicate across these connections.  For information about how to verify replication, see help and support.

    I'm a bit stuck as to what to try next.

    Regards,

    Robert

    • Marked as answer by kidtrebor Sunday, August 23, 2015 10:04 AM
    • Unmarked as answer by kidtrebor Sunday, August 23, 2015 10:04 AM
    Saturday, August 22, 2015 1:22 PM
  • Actually the problem now seems to be solved - I manually created a replication partnership between another server on this site and one on a different site and then performed the non-authoritative restore, which was successful.  After this I ran D2 on the other servers on this site and it seems also to have been successful.  Finally, I carried out a replication test by creating a disabled GPO on the remote site and confirmed it replicated across the wire to this site.

    Thank you so much for your help, Martin!

    Regards,

    Robert

    Sunday, August 23, 2015 10:03 AM