I'm not sure what I am doing wrong here. In my test lab I have two physical boxes, each runs a 2012 R2 domain controller VM.  One is DC1 and the other is DC2.  I have moved FSMO rolls to the following: schema master and domain naming master are on DC1.  PDC, RID and Infrastructure master are on DC2.  They have static ipv4 addresses configured as such.  

DC1
IP:10.0.0.30
SNM:255.255.255.0
GW:10.0.0.1
DNS: P-127.0.0.1
Alt-10.0.0.31 

DC2
IP: 10.0.0.31
SNM:255.255.255.0
GW:10.0.0.1
DNS: P-10.0.0.30
Alt-127.0.0.1

All machines have an IPv6 address via the DHCPv6 server on my pfsense box which has a tunneled IPv6 address through hurricane electric.  They all can pass the IPv6 test pages.  On all my computers I noticed that looking at the network connection details the IPv6 DFGW has the address of fe80::xxxxxxxxxxxxx.  Im not sure if this has any significance at all so i'm just including it. As well as the IPv6 DNS servers are set to ::1

The DNS servers on DC1 and DC2 are each configured with forwarders.  Both DNS servers forwarders are set to 10.0.0.1, 2001:20:470::2, which is the hurricane electric IPv6 DNS server, and two google DNS servers 8.8.8.8 and 8.8.4.4.  Running an nslookup for google.com on the domain controllers yields the following results

server: unknown

address: ::1

non-authoritative answer:

name: google.com

addresses: 2607:f8b0:4009:801::1003
74.125.225.72
74.X
74.X
and so on..

Running nslookup for google.com on any other client computer yields the following results: 

DNS request timed out
Timeout was 2 seconds
Server: unknown
address: 2001:470:20::2

DNS Requst timed out
timeout was 2 seconds
DNS Requst timed out
timeout was 2 seconds
DNS Requst timed out
timeout was 2 seconds
DNS Requst timed out
timeout was 2 seconds
***request to unknown timed-out***

Now each computer passes IPv6 tests and has no issues on the internet so i'm not sure why that's what i get when doing an nslookup on the clients when the domain controllers appear to lookup fine.

Now that you know my configuration getting to my issue/s at hand.  I seem to be having replication issues.  When I open GPMC and click on my domain and then on the status tab click detect now it comes back under the status details 1 domain controller with replication in progress.  It has listed next to it SysVol Inaccessible.  

What am I doing wrong? Why is it inaccessible causing replication issues which I first noticed with GPOs not applying?  I only have a few test GPOs.

One other thing I noticed is when you click change and select a new baseline DC the IP for DC1 is a DHCP IPv6 address while DC2 has fe80::xxxxxxxx for its IP address. They both have the same number of GPOs.  It would appear that they are replicating or at least I think since I created a blank GPO on DC2 and it immediately showed up on DC1 and vise versa.  When I do a gpupdate on a client i get the computer policy could not be updated successfully.  The user policy was successful.

Running gpreport on the client results in under the computer policy 2 errors detected, a fast link detected and the following GPOs have special alerts which lists a few and next to them says AD / SysVol Version Mismatch.  Clicking on the 2 errors I get event ID 1096 and 7016.

The results under the user policy are no errors detected, a fast link detected, and one GPO has special alerts which is the same AD / SysVol Version Mismatch

Thanks!

• Edited by ventura_techtvman Tuesday, November 12, 2013 8:12 PM

Anyone?  If there is a more appropriate forum this should go under please feel free to move it or let me know.

• Edited by ventura_techtvman Wednesday, November 13, 2013 5:39 PM

Dear,

Decommision IPv6 from your environment

Make sure that you created a reverse lookup zone on your DNS server

Try nslookup from your client computers

Make sure that you have at least one GC

Try to access the SYSVOL from your domain controllers and test the GPOs on a client computer

Then we will get back to troubleshoot your IPv6 environment again.

Regards.

OK, My IPv6 DHCP server is turned off.  I have had a reverse DNS server setup.  I've rebooted both DC's. nslookup now works as it should for clients.  I can access sysvol from the DCs although never had an issue with that before.  If I do a gpupdate /force from a client it gives an error for the computer policy and says Windows could not apply the registry-base
d policy settings for the Group Policy object LDAP://CN=Machine,cn={30383050-421
1-4F14-BA59-9BF4AB320DB0},cn=policies,cn=system,DC=domain,DC=home. Group Policy
 settings will not be resolved until this event is resolved. View the event deta
ils for more information on the file name and path that caused the failure.
User Policy update has completed successfully.

Ive not had any issues accessing sysvol in the past and if i create a test gpo with nothing in it, it has always replicated right away to the other DC yet it shows sysvol inaccessible.

• Edited by ventura_techtvman Thursday, November 14, 2013 10:58 PM

Any Ideas?  It doesn't seem like its IPv6 related.

I ran DFS Replication Health report and below are the results if that helps any.

DC1   (2 warnings)    (View Server Details) 
  This member is waiting for initial replication for replicated folder SYSVOL Share.  
  The DFS Replication service is restarting frequently.  

  DC2   (2 warnings)    (View Server Details) 
  This member is waiting for initial replication for replicated folder SYSVOL Share.  
  The DFS Replication service is restarting frequently.  


 SERVERS UNAVAILABLE FOR REPORTING  (All servers reporting)
 SERVER DETAILS  (2 servers)(Hide All)
Rendering content. Please wait . . .
DC1(Hide All)
DNS name: dc1.domain.home 
Domain name: domain.home 
Reference domain controller: DC1.domain.home 
IP address: fe80::dcb7:47d:5cfa:75d0%12,10.0.0.30 
Site: TestSite
Time zone: (GMT-6:00) 
 ERRORS (There are no errors to report) WARNINGS (There are 2 warnings to report)

 This member is waiting for initial replication for replicated folder SYSVOL Share.  
  Affected replicated folders: SYSVOL Share 
  Description: This member is waiting for initial replication for replicated folder SYSVOL Share and is not currently participating in replication. This delay can occur because the member is waiting for the DFS Replication service to retrieve replication settings from Active Directory Domain Services. After the member detects that it is part of replication group, the member will begin initial replication.  
  Last occurred: Thursday, November 14, 2013 at 4:53:19 PM (GMT-6:00) 
  Suggested action: Replication will begin after initial replication is complete. If this state does not change, see The Microsoft Web Site.  

 The DFS Replication service is restarting frequently.  
  Affected replicated folders: All replicated folders on this server. 
  Description: The DFS Replication service has restarted 4 times in the past 7 days. This problem can affect the replication of all replicated folders to and from this server. Event ID: 1004 
  Last occurred: Thursday, November 14, 2013 at 3:56:39 PM (GMT-6:00) 
  Suggested action: If you restarted the service manually, you can safely ignore this message. For information about troubleshooting frequent service restart issues, see The Microsoft Web Site.  

 INFORMATIONAL

 Service state: Running 


 DFS Replication service uptime: 56 min.  


 DFS Replication service version: 6.3.9600.16384 

 Summary of replicated folder status 
  The following table provides a high-level overview of replicated folder status on this server. 

  Replicated Folder Status # of Files Received DFS Replication Bandwidth Savings 
SYSVOL Share Waiting for initial replication 0 0.00% 

  Data shown about the number of received files and the DFS Replication Bandwidth Savings accumulate from the time the DFS Replication service is started.
  No backlog is shown because the backlogged transactions for all members are relative to this server. 


 Current used and free disk space on volumes where replicated folders are stored 
  The following table describes the current used and free disk space on volumes where replicated folders are stored. 
  Volume Path Volume Label Volume Size Free Space % Free Space USN Journal Size 
C: (has no label) 39.5 GB 30.8 GB 77.9% 512 MB 




 DFS Replication Bandwidth Savings: 
  The DFS Replication bandwidth savings are computed by determining the total size of data replicated across the network using a combination of remote differential compression (RDC), which sends only byte-level changes, and stream compression. By comparing this figure to the amount of data that would be replicated across the network if RDC and stream compression were not used, you can determine the percentage of bandwidth saved. 
  Reduction in WAN traffic: 0 KB 
  The following table describes the total on-disk size of files that were replicated and compares them to the amount of data actually received over the network with DFS Replication. 
  Replicated Folder Total Size of Data If Received Without DFS Replication Actual Data Received Across the Network Using DFS Replication DFS Replication Bandwidth Savings 
SYSVOL Share 0 KB 0 KB 0.00% 
Savings from using DFS Replication 0 KB 0 KB 0.00% 



DC2(Hide All)
DNS name: dc2.domain.home 
Domain name: domain.home 
Reference domain controller: DC2.domain.home 
IP address: ::1,10.0.0.31 
Site: TestSite
Time zone: (GMT-6:00) 
 ERRORS (There are no errors to report) WARNINGS (There are 2 warnings to report)

 This member is waiting for initial replication for replicated folder SYSVOL Share.  
  Affected replicated folders: SYSVOL Share 
  Description: This member is waiting for initial replication for replicated folder SYSVOL Share and is not currently participating in replication. This delay can occur because the member is waiting for the DFS Replication service to retrieve replication settings from Active Directory Domain Services. After the member detects that it is part of replication group, the member will begin initial replication.  
  Last occurred: Thursday, November 14, 2013 at 4:53:19 PM (GMT-6:00) 
  Suggested action: Replication will begin after initial replication is complete. If this state does not change, see The Microsoft Web Site.  

 The DFS Replication service is restarting frequently.  
  Affected replicated folders: All replicated folders on this server. 
  Description: The DFS Replication service has restarted 4 times in the past 7 days. This problem can affect the replication of all replicated folders to and from this server. Event ID: 1004 
  Last occurred: Thursday, November 14, 2013 at 4:06:32 PM (GMT-6:00) 
  Suggested action: If you restarted the service manually, you can safely ignore this message. For information about troubleshooting frequent service restart issues, see The Microsoft Web Site.  

 INFORMATIONAL

 Service state: Running 


 DFS Replication service uptime: 46 min.  


 DFS Replication service version: 6.3.9600.16384 

 Summary of replicated folder status 
  The following table provides a high-level overview of replicated folder status on this server. 

  Replicated Folder Status Backlogged Sending Transactions Backlogged Receiving Transactions # of Files Received DFS Replication Bandwidth Savings 
SYSVOL Share Waiting for initial replication 80 28 0 0.00% 

  Data shown about the number of received files and the DFS Replication Bandwidth Savings accumulate from the time the DFS Replication service is started.
  Backlogged transactions are relative to member DC1 (dc1.domain.home). 


 Current used and free disk space on volumes where replicated folders are stored 
  The following table describes the current used and free disk space on volumes where replicated folders are stored. 
  Volume Path Volume Label Volume Size Free Space % Free Space USN Journal Size 
C: (has no label) 39.5 GB 30.4 GB 77.1% 512 MB 




 DFS Replication Bandwidth Savings: 
  The DFS Replication bandwidth savings are computed by determining the total size of data replicated across the network using a combination of remote differential compression (RDC), which sends only byte-level changes, and stream compression. By comparing this figure to the amount of data that would be replicated across the network if RDC and stream compression were not used, you can determine the percentage of bandwidth saved. 
  Reduction in WAN traffic: 0 KB 
  The following table describes the total on-disk size of files that were replicated and compares them to the amount of data actually received over the network with DFS Replication. 
  Replicated Folder Total Size of Data If Received Without DFS Replication Actual Data Received Across the Network Using DFS Replication DFS Replication Bandwidth Savings 
SYSVOL Share 0 KB 0 KB 0.00% 
Savings from using DFS Replication 0 KB 0 KB 0.00% 

                                                                                                                            

I have found out that DC1 the sysvol and netlogon folders are shared going to \\dc1  but \\dc2 there are no shared sysvol and netlogon folders.  How do I fix this?  I suspect this is why I'm having issues.

• Edited by ventura_techtvman Tuesday, January 21, 2014 8:59 PM

Microsoft don't recommend disabling IPv6 as it's being used for various things. I have correctly configured IPv6 DNS, DHCP etc. but hit exactly the same problem although can see AD changed being replicated correctly to my third DC3 that's on another physical machine. both DC1 (PDC) and DC2 are hosted as on the same physical machine. All are VMWare EXSi latest 5.5U2. DC1 and DC2 don't show "Domain controller(s) with replication in progress" + "domain.name.ext Inaccessible" errors in GPO editi when click Detect Now.

All VPSs are latest Windows 2012 R2 Standard.

There is another thread regarding this issue here: https://social.technet.microsoft.com/Forums/lync/en-US/45fef8f6-ccb8-4336-a0af-d6d2f6be2a46/version-number-for-gpos-not-in-sync-with-the-version-number-for-gpos-on-the-baseline-domain?forum=winserverDS

• Edited by someone666 Monday, February 16, 2015 4:45 PM

See bottom of this thread. It's about orphaned items deep in SYSVOL structure casuing described above problems.

http://community.spiceworks.com/topic/428020-2-2012-dcs-ok-add-3rd-2012-dc-and-sysvol-netlogon-not-ok?page=2#entry-4313282

Check this link please

http://blogs.technet.com/b/askds/archive/2008/07/15/five-common-causes-of-waiting-for-the-dfs-replication-service-to-retrieve-replication-settings-from-active-directory.aspx

Thanks,

Umesh.S.K