DFSR Unsuccessful on New Domain Controller (EventIDs 1058, 5014)

I have searched a lot and done quite a bit of troubleshooting to no avail.  There are a lot of posts on these issues, and none of them have helped me resolve the problem.  I believe it may be multifaceted, though, as some changes I made for one of them appeared to fix a time synchronization error I wasn't even worrying about yet.  That having been said, let me start from the beginning...

I have a single-server 2008R2 functional level Active Directory domain that was installed in that state (that is IIRC; it is possible that I installed it in 2003 functional level and migrated, but I definitely started with one 2008R2 server).  I recently added a 2012 server to the domain and promoted it to a domain controller.  The sysvol share never replicated, so I am getting the same event failures over and over.  The first thing I noticed was eventID 1058 (which is recorded every 5 minutes) in the system event log:

The processing of Group Policy failed. Windows attempted to read the file \\domain\sysvol\domain\Policies\{GPID}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could 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.

I started by doing a lot of searching on this, and one thing I tried after that searching is disabling IP/TCP/UDP checksum offloading on the network adapters on both servers.  Changing these settings on the 2008R2 server is what got time synchronization working, so it could have been relevant in the cause of the issue.  Both servers are hosting Hyper-V, so both are actually connected via the Hyper-V virtual switch, and I disabled the IP/TCP/UDP offloading on that adapter as well as the actual physical adapter.  I also rebooted both servers after the changes.  When doing the same on 2012 didn't help with the problem, I went ahead and changed it back.  I also used the following commands, whose output didn't provide me with any information I wasn't already aware of:

DCDIAG /V /C /D /E /s:2008R2DC > c:\2008R2dcdiag.log --on local DC
DCDIAG /V /C /D /E /s:2008R2DC > c:\2008R2f2012dcdiag.log --on remote DC
DCDIAG /V /C /D /E /s:2012DC > c:\2012dcdiag.log --on local DC
DCDIAG /V /C /D /E /s:2012DC > c:\2012f2008r2dcdiag.log --on local DC
repadmin.exe /showrepl 2008R2dc /verbose /all /intersite > c:\2008r2repl.txt --I don't remember whether I ran this on the 2008r2 server or the 2012 server
repadmin.exe /showrepl 2012dc /verbose /all /intersite > c:\2012repl.txt --I don't remember whether I ran this on the 2012 server or the 2008r2 server
dnslint /ad 2008R2IP /s 2008R2IP /r 2008R2dnslint --on Win7 domain member
dnslint /ad 2012IP /s 2012IP /r 2012dnslint --on Win7 domain member

I didn’t see anything out of the ordinary in any of the output from those commands, and I couldn’t find the netdiag command on either server to run it, so I assume the troubleshooting I was doing was for previous versions.  After all of this failed to yield anything interesting, I did some more searching, and found advice that multi-homed servers could cause problems. The 2008R2 server is running RRAS, and I can’t do much about that at the moment, but I did run the diagnostics above on the RRAS IP and still didn’t see anything out of the ordinary. I also confirmed that \\2008R2IP\ sysvol\prd-inc.com\Policies\{GUID?}\ and \\2008R2RRASIP\ sysvol\prd-inc.com\Policies\{GPID}\ were both accessible (and GPT.ini was accessible on both, and there are actually four group policies, all of which are accessible this way). The 2012 server was set up with VLANs on the physical interface, and had two VLAN interfaces enabled, giving it two Hyper-V virtual switches, so I removed the VLANs from the physical interface and got it down to the one Hyper-V virtual switch as well. I read something that indicated IPv6 should be set to automatic, so I removed my self-generated private IPV6 addresses from the 2008R2 server and the 2012 server and set them to automatic. After each of the changes mentioned in this paragraph, I verified the DNS servers were up to date, and they were. During this troubleshooting, I one user also let me know they couldn’t connect to a service that uses LDAP on the 2008R2 server to verify a user is logged in at a given IP, so I have to assume this user got logged in through the 2012 server and the 2008R2 server was not notified.  I didn’t use this additional piece of information in my troubleshooting because I didn’t know how, but it is interesting that DNS is replicating while other things besides DFRS don’t appear to be.

At some point, I’m not sure where it falls in the list of actions above, I decided to check the DFS Replication event log. There I noticed another error (which I just found out I failed to document, but do recall something about RPC failing (which is why I was disabling the IP/TCP/UPD offloading), and I do have a record of searching for “The primary Domain Controller for this domain could not be located”.  I also found this at some point:http://technet.microsoft.com/en-us/library/cc727259(v=WS.10).aspx I followed it to KB314494, but that didn’t help with my problem either. At another point I looked at KB887303, which also didn’t help with my problem. After all of this, I finally gave up, demoted the 2012 server, and went through the promotion process again. At that point, I can tell you that I see the following events on the 2012 server (I cleared all event logs before doing the promotion again):

Netlogon 5706 (in system, probably during promotion before reboot):
The Netlogon service could not create server share C:\Windows\SYSVOL\sysvol\prd-inc.com\SCRIPTS. The following error occurred:
The system cannot find the file specified.

DFSR 6016:
The DFS Replication service failed to update configuration in Active Directory Domain Services. The service will retry this operation periodically.

Additional Information:
Object Category: msDFSR-LocalSettings
Object DN: CN=DFSR-LocalSettings,CN=PRDRDS,OU=Domain Controllers,DC=prd-inc,DC=com
Error: 2 (The system cannot find the file specified.)
Domain Controller: PRDAD1.prd-inc.com
Polling Cycle: 60

DFSR 1210 (informational, of interest is the port number):
The DFS Replication service successfully set up an RPC listener for incoming replication requests.
 
Additional Information:
Port: 0

DFSR 6804:
The DFS Replication service has detected that no connections are configured for replication group Domain System Volume. No data is being replicated for this replication group.
 
Additional Information:
Replication Group ID: RGID
Member ID: MID

DFSR 6406:
The DFS Replication service detected that the local path of a replicated folder (domain) in its database does not match the newly configured local path (C:\Windows\SYSVOL\domain) of the replicated folder. The service will replicate the new path, and the old replicated folder path in the database will no longer be tracked as a replicated folder. This event is expected if the local path of the replicated folder has been changed.
 
Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: RFID
Replication Group Name: Domain System Volume
Replication Group ID: RGID
Member ID: MID

DFSR 2002 (Informational, probably not of interest):
The DFS Replication service successfully initialized replication on volume C:.
 
Additional Information:
Volume: VID

DFSR 4614:
The DFS Replication service initialized SYSVOL at local path C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner PRDAD1.prd-inc.com. If the server was in the process of being promoted to a domain controller, the domain controller will not advertize and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the synchronization partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers.
 
Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: RFID
Replication Group Name: Domain System Volume
Replication Group ID: RGID
Member ID: MID
Read-Only: 0

DFSR 4604 (informational, of interest is the alleged success):
The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:\Windows\SYSVOL\domain. This member has completed initial synchronization of SYSVOL with partner PRDAD1.prd-inc.com.  To check for the presence of the SYSVOL share, open a command prompt window and then type "net share".
 
Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: RFID
Replication Group Name: Domain System Volume
Replication Group ID: RGID
Member ID: MID
Sync partner: PRDAD1.prd-inc.com

I will repeat that this last event is especially noteworthy in that it looks like replication happened, but it didn't.  There are other informational events, but no more warnings after this (other than the repeated warning every 5 minutes as first mentioned in this post).

While compiling this, I had another user contact me with a problem, he can't access his network drives because the logon script didn't run, which means he logged in to the new DC.  I am probably going to demote it again now and wait until I have some new ideas to try before promoting it for a third time.  I deleted all of the logs from the commands run last time, so I will run them again before demotion in case someone else feels the need to look at them.  I feel it is safe to assume a third promotion wouldn't be helpful without something being fixed first.

Another thing I forgot to note here was that Group Policy event 1058 contains the following details:

Of particular note here is that the share that can't be accessed is pointing at the domain instead of the domain controller it should replicate from.  I did an nslookup on the domain, and the server lists itself first, which is presumably why it can't access the files (because they haven't actually replicated yet.  I read somewhere that someone solved this problem by copying the files manually.  I could probably do that, but don't want to do it as anything other than a last resort.  Incidentally, I didn't note this earlier, but I did have each DC pointing at the other as primary DNS last time, this time they are both pointing at the 2008R2 DC for DNS, obviously that makes no difference.