• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 611
  • Last Modified:

FRS Not Replicating - Error 13508

I have a networking with two DC's running Windows 2003 R2 that have the error 13508.  We did recently change the name of the domain admin account and when I first noticed the replication issues I checked the FRS service and it was still running under the old user id.  I changed the ID/password to reflect the changes but no replication.  I did follow the following kb article here: http://support.microsoft.com/kb/315457, but the attempt to rebuild the replication set was unsuccessful.  Currently only one server is authenticating domain logins.  Attached is a copy of the dcdiag log files from each server.
dcdiag-bakerhill.log
dcdiag-trmsrv.log
0
bhelm1
Asked:
bhelm1
  • 6
  • 5
1 Solution
 
page1985Commented:
Take a look at this warning in the output:
Warning: DsGetDcName returned information for \\trmsrv.FRSBNET, when we were trying to reach BAKERHILLII.

Also, take a look at this:

KRB_AP_ERR_MODIFIED error from the server host/trmsrv.frsbnet.  The target name used was FRSBNET\TRMSRV$. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server.  Commonly, this is due to identically named machine accounts in the target realm (FRSBNET), and the client realm.   Please contact your system administrator.

This seems like we have something crossed somewhere.  Start by checking DNS (and WINS if you have it, but likely you don't).  Make sure the IPs all point to the right places.  Also, can you provide screenshots of the _MSDCS subzone (and all folders underneath) in DNS so that I can review them and see if everything matches up?

Also, please check the event log (system and application) on both domain controllers and tell me if you see any errors.

This item is likely a symptom and not a cause, but I often see this if the DC was just promoted.  Is TRMSRV new as a domain controller?

There are warning or error events within the last 24 hours after the SYSVOL has been shared.  Failing SYSVOL replication problems may cause Group Policy problems.
0
 
page1985Commented:
While I will give best effort to help resolve these issues (and I think we can fix this), it is worth noting that Active Directory does not support a root domain (meaning FRSBNET as the end of the FQDN).  Active Directory requires at least a tier 2 domain (such as frsbnet.local) according to Microsoft specifications.
0
 
page1985Commented:
Also, here is another issue.  Your internal systems (and domain controllers) should always point to your domain controllers for DNS.  Do not use external/public DNS servers for internal name resolution because it causes problems with name lookups for your network.  Instead, configure forwarders in DNS so that your domain controllers look outside for non-authoritative records.

   DNS server: 208.67.220.220 (<name unavailable>)
               All tests passed on this DNS server
               This is a valid DNS server
               Total query time:0 min. 0 sec., Total WMI connection time:0 min. 42 sec.
               
            DNS server: 208.67.222.222 (<name unavailable>)
               All tests passed on this DNS server
               This is a valid DNS server
               Total query time:0 min. 0 sec., Total WMI connection time:0 min. 41 sec.
               
            DNS server: 8.8.4.4 (<name unavailable>)
               All tests passed on this DNS server
               This is a valid DNS server
               Total query time:0 min. 0 sec., Total WMI connection time:0 min. 42 sec.
               
            DNS server: 8.8.8.8 (<name unavailable>)
               All tests passed on this DNS server
               This is a valid DNS server
               Total query time:0 min. 0 sec., Total WMI connection time:0 min. 42 sec.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
bhelm1Author Commented:
Look at the DNS, everything appears to be set correctly, each domain is a DNS server and points to itself for the primary DNS server and then to the other server as the secondary DNS.  The four DNS server records in you last post are not set under Local connection properties but are set as the DNS forwarders on each DNS server.

Looking under the Application & System events I have some 1219 (Winlogon), 1030 (Userenv, the user cannot query for the list of group policy objects.), 1054 (Userenv, windows cannot obtain the domain controller name for your computer network) & 1096 (Windows cannot access the registry policy file..)

Neither server is new to the domain.  Attached are the screen shots of the MSDCS subzones from each server.

Thanks
DNS.zip
0
 
page1985Commented:
If you look under gc._msdcs, you'll notice there is a reference to 169.254.150.2.  Is there actually a system with this IP?  If not, it would be good to remove every reference of it that you can find.

Everything else under _MSDCS looks healthy.  Can you also send me screen shots of the _TCP, _UDP, _sites, DomainDnsZones, and ForestDnsZones from the frsbnet root?
0
 
bhelm1Author Commented:
No there is not machine with that IP.  I search through and found that record in a few other spots and removed it.  Attached is a screenshot of the other DNS settings.
DNS-2.zip
0
 
page1985Commented:
OK.  Those sections of DNS look good.  Last piece.  Would there happen to be any crosses in the A records for bakerhillii and trmsrv?  Does one point to the other and vice versa?  Are there any duplicate A records?

Also, do you have WINS?
0
 
bhelm1Author Commented:
No, we don't use WINS.  I checked the dns and there doesn't appear to be any duplicate records under the, each DNS has it's own A record and the A record of the other DNS.  Under the Local Area Connection each DC points to itself and the other DC.
DNS.jpg
0
 
page1985Commented:
Can you ping each DC from the other one by FQDN?
0
 
bhelm1Author Commented:
After trying to rebuild the SYSVOL, replication was still unsuccessful and some workstations began to have issues authenticating to either server.  We contacts Microsoft support and they had to run some repairs on the global catalog and FRS, MS support was on the system between 5-6 hours before the servers began to replicate correctly.  Sorry I'm unable to provide the specifics of the resolution to this issue but our system is replicating successful now and all error have been cleared up.

Thanks for your input.
0
 
bhelm1Author Commented:
Due to the natural of the issues and being unable to access time sensitive information we had to resort to contacting Microsoft for a resolution.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now