PDC DNS/Replication Errors

As you suspect, DNS is the place to start.

1. Verify DNS is installed, that it has a Forward Lookup Zone for your Domain, and that the _msdcs folder exists.
2. Verify that your server refers to a valid DNS Server (one that can answer for LEISURE-PARCS.LOCAL). It is extremely important that it doesn't attempt to refer to a public DNS Server, or any other server that isn't aware of the AD Zone.
3. Restart the NetLogon Service and run "ipconfig /registerdns". This forces the server to attempt registration of it's Service Records and Host Record (respectively). Check the Event Log for registration errors.

Chris

Thank you for the quick reply Chris. In answer to your points:

1. DNS is installed and the service is running. It contains a forward lookup zone and the _msdcs folder exisits.

2. The server refers only to itself as a primary DNS server. (Using forwarders to refer to ISP DNS).

3. Restarted the NetLogon service and ran the command, there doesn't appear to be any errors.

That sounds good. Are there any other Domain Controllers? And if so, do they show the same set of issues?

Have you run DCDiag and NetDiag against the DC at all yet?

Chris

Another of my domain controllers appears to be fine. It doesn't take the extended amount of time to show the logon screen. It does however have this logged in the event viewer:

------------------------------------------------------------
Source: MSDTC

MS DTC could not correctly process a DC Promotion/Demotion event. MS DTC will continue to function and will use the existing security settings. Error Specifics: d:\nt\com\complus\dtc\dtc\adme\uiname.cpp:9351, Pid: 1536
No Callstack,
 CmdLine: C:\WINDOWS\system32\msdtc.exe
------------------------------------------------------------

This is the only warning though everything else appears normal.

I have run dcdiag /test:dns and it appears to pass and a netdiag also passes.

Run dcdiag on it's own, there doesn't appear to be a significant problem in DNS. The promotion / demotion event error is a little more odd.

Chris

Attached dcdiag output. I must note that I have been having a few issues with slow logon times with regards to my Windows XP clients. With three of my machines taking over 5 - 10 minutes to logon.
dcdiag-pdcon.txt

Are both DCs Global Catalog servers?

If not, what server is the GC?

SG

This is Windows Server 2003 R2 SP2. The clients are pointing to this server and my other domain controller for DNS.

When I looked in the event log in reference to the errors i believe it is this:

------------------------------------------------------------
Source: DCOM

DCOM was unable to communicate with the computer 193.38.113.3 using any of the configured protocols.
------------------------------------------------------------

I say believe because i am only going off the time stamp the event was logged.

I followed the instructions Chris and i'm not sure if it was a coincidence but I re-ran the dcdiag after I restarted the MSDTC service and now everything has come back as passed.

In answer to snusgubben's question, yes they are both GC's.

What's 193.38.113.3?

I wonder, in DNS, which Host (A) Records are recorded for your Domain Controllers? Just the regular internal IP?

And the same question for the domain name (same as parent folder) entries?

Chris

193.38.113.3 is our ISPs DNS server.

In DNS configuration the Host (A) Records all correspond to the correct domain controller name.

Puzzling. The errors you're suffering from very much suggest that they're heading off to the wrong DNS server for name resolution, although I don't see how that can be the case with the settings you've mentioned.

The netlogon error at the top didn't reproduce when you restarted the NetLogon service, did it?

How about the clients, they also claim they can't find the domain?

Chris

It didn't reproduce itself but upon rebooting the server the NETLOGON warning appears again.

Dynamic registration or deletion of one or more DNS records associated with DNS domain 'DomainDnsZones.LEISURE-PARCS.LOCAL.' failed.  These records are used by other computers to locate this server as a domain controller (if the specified domain is an Active Directory domain) or as an LDAP server (if the specified domain is an application partition).  

Possible causes of failure include:  
- TCP/IP properties of the network connections of this computer contain wrong IP address(es) of the preferred and alternate DNS servers
- Specified preferred and alternate DNS servers are not running
- DNS server(s) primary for the records to be registered is not running
- Preferred or alternate DNS servers are configured with wrong root hints
- Parent DNS zone contains incorrect delegation to the child zone authoritative for the DNS records that failed registration  

USER ACTION  
Fix possible misconfiguration(s) specified above and initiate registration

---------------------------------------------------------

Just for reference the NTDS Replication warning is still appearing:

Active Directory could not use DNS to resolve the IP address of the source domain controller listed below. To maintain the consistency of Security groups, group policy, users and computers and their passwords, Active Directory successfully replicated using the NetBIOS or fully qualified computer name of the source domain controller.
 
Invalid DNS configuration may be affecting other essential operations on member computers, domain controllers or application servers in this Active Directory forest, including logon authentication or access to network resources.
 
You should immediately resolve this DNS configuration error so that this domain controller can resolve the IP address of the source domain controller using DNS.
 
Alternate server name:
 mailhost
Failing DNS host name:
 edba5279-baa1-4dbc-a406-8c6a8c864745._msdcs.LEISURE-PARCS.LOCAL
 
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur.  To log all individual failure events, set the following diagnostics registry value to 1:
 
Registry Path:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
 
User Action:
 
 1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
 
 2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\" or "ping ".
 
 3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns 
 
  dcdiag /test:dns
 
 4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
 
  dcdiag /test:dns
 
 5) For further analysis of DNS error failures see KB 824449:
   http://support.microsoft.com/?kbid=824449
 
Additional Data
Error value:
 11004 The requested name is valid, but no data of the requested type was found.
---------------------------------------------------------

Well the clients logon, it just takes quite a long time for the desktop to appear. (It finishes applying settings etc then sits on a blank screen with just the desktop background and mouse curser visible. Anywhere between 1 minute to 10 minutes.

Additional information. When looking at one of my client mahcines that took a few minutes to logon I found this in the event log:

------------------------------------------------------------
Source: Userenv

Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=LEISURE-PARCS,DC=LOCAL. The file must be present at the location <\\LEISURE-PARCS.LOCAL\sysvol\LEISURE-PARCS.LOCAL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. ). Group Policy processing aborted.
------------------------------------------------------------

The normal cause of something like that is that it can't properly resolve leisure-parcs.local. It must be able to resolve those to the DC IPs. If there's another IP in there you end up with Group Policy Processing errors like that.

The Policy does exist in the location stated otherwise though?

Chris

Well when looking at the error and it states you should be able to access this path: <\\LEISURE-PARCS.LOCAL\sysvol\LEISURE-PARCS.LOCAL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>, well i can't because it doesn't state the server name? Am i missing something here?

I can access \\PDCON.leisure-parcs.local\sysvol\LEISURE-PARCS.LOCAL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

With PDCON being the name of my primary domain controller. I can also access this file for any of my domain controllers.

Ok that's where my lack of knowledge comes in. Yes I can access that path.

What happens when you run "nslookup leisure-parcs.local"?

The client will use the domain name only, which is why it needs to map back to the IPs for each DC. It's the entry listed as "(same as parent folder)" in your DNS console.

Chris

C:\>nslookup
*** Can't find server name for address 172.16.1.1: Non-existent domain
*** Can't find server name for address 172.16.1.2: Non-existent domain
*** Default servers are not available
Default Server:  UnKnown
Address:  172.16.1.1

> leisure-parcs.local
Server:  UnKnown
Address:  172.16.1.1

Name:    leisure-parcs.local
Addresses:  172.16.1.1, 172.16.1.2

>

This is the nslookup output from the client as mentioned above.

Just having a look through the dns entries on the server and there doesn't appear to be a (same as parent folder) HOST (A) record for one of my domain controllers.

It should dynamically register if you restart the NetLogon service on the DC. That forces it to register all records held in C:\Windows\System32\Config\netlogon.dns.

This bit is normally caused when there's no Reverse Lookup Zone:

Default Server:  UnKnown

nslookup attempts to resolve the name from the IP it's given when it starts up. It's not generally an important error.

I don't like the time-outs you get before that, they're a bit odd. Especially as it then connects to the DNS server it tried first.

Chris

Don't those non-existent domain errors occur because it is tried outside of the nslookup shell? As you can see when i run the command from the nslookup shell >leisure-parcs.local the only 'odd' thing is due to no reverse dns not being setup.

If you run nslookup (without arguments) it should just go in like this:

C:\Stuff\Scripts> nslookup
Default Server: my-dc-01.my-domain.net
Address:  10.10.1.10
>

Just try issuing a command line this:

nslookup
server 172.16.1.2

Just to see if it comes back with the timeout again.

It's worth adding the Reverse Lookup Zone anyway, tends to make life easier. Just enable Aging on it so it doesn't get too cluttered.

Chris

C:\>nslookup
Default Server:  pdcon.leisure-parcs.local
Address:  172.16.1.1

> server 172.16.1.2
Default Server:  [172.16.1.2]
Address:  172.16.1.2

>

OK i've configured rdns and now see the following after an nslookup. Do you suggest I reboot the server to see if I continue to have these problems?

Rebooting might help anyway. It's extremely odd that it isn't giving you the server name when connecting to 1.2. That's one of your other DCs?

Chris

It is giving me the server name now, must have just taken a little while for it to add its own PTR record. Yes 172.16.1.1 and 172.16.1.2 are my domain controllers/dns servers.

So that is all working, nslookup requests are working fine. DNS looks like it is working fine. I'm going to give the PDC a reboot now and have another look in event viewer to see if anything has changed. I really appreciate the help by the way Chris. You deserve a medal for being so patient ;).

Sounds good to me, let me know how it gets on :)

Chris

Right - server still takes its time preparting network connections and applying computer settings. I'm also still getting NETLOGON and LSASRV warnings in the event viewer. Also experiancing the same NTDS Replication warning as seen in one of my replies above.

I did just wonder if it were having problems because the DNS service hadn't finished starting.

And I wondered if it could be improved by making the DC refer to another DC as alternate DNS in TCP/IP configuration.

Or is that already set?

Chris

Well that has sorted out the speed issue but it has brought some problems of its own.

------------------------------------

The DNS server was unable to complete directory service enumeration of zone ..  This DNS server is configured to use information obtained from Active Directory for this zone and is unable to load the zone without it.  Check that the Active Directory is functioning properly and repeat enumeration of the zone. The extended error debug information (which may be empty) is "". The event data contains the error.

------------------------------------

The DNS server was unable to complete directory service enumeration of zone _msdcs.LEISURE-PARCS.LOCAL.  This DNS server is configured to use information obtained from Active Directory for this zone and is unable to load the zone without it.  Check that the Active Directory is functioning properly and repeat enumeration of the zone. The extended error debug information (which may be empty) is "". The event data contains the error.

------------------------------------

The DNS server was unable to complete directory service enumeration of zone 1.16.172.in-addr.arpa.  This DNS server is configured to use information obtained from Active Directory for this zone and is unable to load the zone without it.  Check that the Active Directory is functioning properly and repeat enumeration of the zone. The extended error debug information (which may be empty) is "". The event data contains the error.

------------------------------------

The DNS server was unable to complete directory service enumeration of zone LEISURE-PARCS.LOCAL.  This DNS server is configured to use information obtained from Active Directory for this zone and is unable to load the zone without it.  Check that the Active Directory is functioning properly and repeat enumeration of the zone. The extended error debug information (which may be empty) is "". The event data contains the error.

------------------------------------

Hmm I'm not so sure. Journal Wrap has quite an explicit set of errors associated with it, as you mention above. Replication failures that don't seem to be occurring in this instance. Besides, such things would show in DCDiag.

In fact this is exhibiting remarkably few errors, quite troublesome :)

Don't let me stop you looking into Chief's suggestions of course.

I'm also curious about the replication scope you've set for each of your DNS Zones under the DNS Console?

Chris

Well you will be happy to know that all warnings / errors appear to have been solved this morning. Thank you for your reply ChiefIT but upon coming in this morning it looks like it has replicated to itself and everything seems to be running fine. As a note upon restarting the server this message appeared in the event viewer.

------------------------------------
All problems preventing updates to the Active Directory Database have been cleared. New updates to the Active Directory database are succeeding. The Net Logon service has restarted.
------------------------------------

So i'm not sure what the definitive answer to this topic is. The MSDTC fix that Chris provided should be highlighted as an solution as that worked but what do you believe is the solution to the question as a whole as were playing around with DNS a lot!

The only problem now is my clients logging on, but I think that should be saved for another question! Chris if you wouldn't mind looking at my other open question regarding slow client logons I would appreciate it!

Excellent Tom! Glad to see things are working out.

Truth is, neither Chris or I were wrong. Registering the SRV and Host A records suffices in many situations. The reasons your communications broke down to a problem with Journal Wrap were most likely DNS issues. The reasons you are having problems with logons are most likely DNS issues.

The only thing I provided to you was the ability to replicate your data set when normal replications methods were stopped in their tracks. When in journal Wrap, a communications breakdown takes place and typical replications processes fail. When it fails, you may not have the ability to replicate using traditional means. Journal Wrap errors are few and far between these days because bandwidth speeds allows for a speedy replications with good checks and balances. So, most errors are resolved by simple DNS edits and other communications tweaks.

You are not totally out of the woods yet. You may still have DNS errors, from the sounds of it. I was hoping fixing the replication set would replicate DNS data and resolve your DNS issues. On your other issues, I would certainly look into your prefered DNS and What protocols you are using to access your DCs. Slow logons are 99% a problem with the prefered DNS and 1% using the wrong protocol, like 'Client Services For Netware'.

I can't think of a better candidate to have on your side than Chris. He leads the EE pack in fixing DNS issues for a reason.

Sounds like you are in good hands and are starting to get into good health. So, that is good news.

'lo again,

Sorry for the late reply, had horrible problems getting onto EE all day yesterday. Fortunately everything is happy again now.

The underlying cause is a bit of a tricky thing, it's more likely that you had a collection of very minor issues conspiring to make life very difficult. It's quite possible the problem with MSDTC was one of the contributing factors, and that it was slowing down startup of AD.

That in turn would make DNS slow to load causing the startup errors you were seeing.

I'm not entirely certain what the "one" solution would be here though, as you say, we played with a lot of different things.

Chris