Link to home
Start Free TrialLog in
Avatar of bhelm1
bhelm1

asked on

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
Avatar of page1985
page1985
Flag of United States of America image

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.
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.
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.
Avatar of bhelm1
bhelm1

ASKER

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
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?
Avatar of bhelm1

ASKER

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
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?
Avatar of bhelm1

ASKER

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
Can you ping each DC from the other one by FQDN?
ASKER CERTIFIED SOLUTION
Avatar of bhelm1
bhelm1

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of bhelm1

ASKER

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.