Astronomer Mar 31, 2006   11:33 AM GMT

Wayne: Thanks for the quick response. I disabled the interface last night so it wouldn't interfere with logins today. I will try your fix tonight after the faculty go home. Thanks again. I will let you know the result. rt

15 pointsBadges:

Mortree Apr 3, 2006   1:46 AM GMT

A safer way is to use the Network Connections interface. If you follow the IP properties of the interface through Advanced to DNS properties -- you find a check box to register that connection in DNS or not. Of course you may find yourself burrowing through the global catalog and the 4 AD master roles to delete that private IP now that it was registered. I forget. It has been a long time since I had do that for simialr reasons. You will need to view details on that yourself if you need to do that. But now you have clue as to where to look. Oh and other AD domain masters will have that bad private IP in their DNS too as will all plain DNS servers that read updates from any domain master. I assume you do have a second domain master somewhere on the network -- as single domain masters are asking for a painful possibly incomplete restore at an undesirable time of day.

0 pointsBadges:

Astronomer Apr 3, 2006   2:41 PM GMT

The register this connection's addresses in DNS box was already unchecked. The registry hack didn't work either so we will be forced to do our backups on the main net. One thing about this disturbs me. We set up the backup connection months ago. The connectivity problem only appeared last week. I guess this is yet another microsoft mystery. It would be nice to track this down but I have other fires this week. The change to daylight savings time temporarily messed up our domain and I have been asked to keep this from happening again. Thanks for the suggestions. rt

15 pointsBadges:

Mortree Apr 3, 2006   7:25 PM GMT

Did DHCP get turned on later for this secondary network? Unfortunately while you can preserve fixed IPs where needed by reserving addresses -- the default DHCP process will also register those addresses in DNS.

0 pointsBadges:

Astronomer Apr 3, 2006   7:48 PM GMT

We aren't using DHCP. rt

15 pointsBadges:

Mortree Apr 3, 2006   8:08 PM GMT

Actually the DNS registration is probably a secondary issue that would "merely" tend to put normal traffic on the backup network. When you have ping problems you are more likely looking at IP routing issues with multihomed servers (lot of search clues in this sentence). As you know ping an IP address doesn't call upon DNS or any server functions. It is a direct routing issue. So I suggest that at some point the intereface was reconfigured and obtained a default gateway. Perhaps some human did so directly or perhaps you have RIP or some other routing protocol being generated for the private network now. If RIP was on for the server in question but no other device previous did...nothing would be communicated and no default gateway added. Alternatively IP routing may have have gotten turned on for that server (adding RRAS RADIUS etc as well as routing for itself). You don't want internal routing between the interface cards but each card to serve isolated functions. This might even have been caused by new advanced backup software as I seem to recall some Enterprise software tends to think it knows how to route IPs intelligently because it assumes such segments don't overlap at the same server. Things to think about http://support.microsoft.com/default.aspx?scid=kb;en-us;157025 See comments as to how multiple default gateways make data paths uncertain (request out one NIC and replies may come on other). http://support.microsoft.com/default.aspx?scid=kb;en-us;159168

0 pointsBadges:

Mortree Apr 3, 2006   8:25 PM GMT

To clarify Can you ping the various servers by using their assigned IPs directly without invoking DNS? Both normal and private backup nets reliably? If not then don't worry about DNS so much yet. Worry about multihomed routing and default routes first.

0 pointsBadges:

Astronomer Apr 4, 2006   3:33 PM GMT

It seems I didn't explain the situation adequately. This system is a 2003 domain controller running active directory DNS. It has two network interfaces. The first one has a standard IP on our main net with appropriate address, mask, DNS, WINS, and default gateway. The second interface is connected by a crossover cable to a second interface on the backup server. It had a private IP, class C mask, and no default gateway. The option box to register this connection's address in DNS was unchecked. When I saved this configuration during debugging it complained about not having a DNS server specified and said it would use itself. I don't remember this message from the first time we configured it, but it has been a while. When we had random connection problems in the domain I discovered when I pinged the server by name, I got the private IP and the ping failed. This led me to finding the private IP registered in DNS. When I removed the entry in DNS, I got the right IP during ping and it worked. The problem was that the private IP came right back again. We have never enabled routing of any kind on this system. I just checked with regedit and IPenablerouter is set to 0. The only system I intended to be able to reach the private IP was the backup server which has a compatible IP on its secondary interface. This worked well because veritas has us specify which interface is used by a backup job. The configuration worked for several months until DNS started handing out the private IP. There are no routes in our network to reach this private address. Once I disabled the second interface, the private IP disappeared from DNS and the random failures stopped. rt

15 pointsBadges:

Sonyfreek Apr 5, 2006   6:40 PM GMT

You could disable the "Register this address with DNS Server" setting on both interfaces and manually enter the DNS entry in the DNS Server for the primary interface. It's a bandage until you figure out why the server tries to register itself as the private IP. To further prevent the server from trying to register itself in the DNS, you should disable the "DHCP Client" on the server. Wayne

0 pointsBadges:

Astronomer Apr 7, 2006   12:45 AM GMT

Wayne: I waited until now because the college is closed down except for exempts today. I didn't want my experiments breaking anyone. You may find this hard to believe but I unchecked the main interface "register in DNS" box and enabled the second interface and watched the second IP appear in DNS then disabled the second interface and it vanished again. The next thing I did was stop the DHCP client service and enabled the interface. When I re-opened DNS the second IP was there. After disabling the second interface and refreshing the DNS, it was gone again. I restarted the DHCP client service and we will continue to do backups on the main net. I'm really starting to think these things are done differently on a DC/DNS system. At least this has been educational. rt

15 pointsBadges:

Sonyfreek Apr 7, 2006   9:46 PM GMT

RT, There's a KB article that you may have looked at on this. I stumbled on it. Of course, it says to upgrade to the latest Service Pack, which you may already be on: http://support.microsoft.com/?id=832478 Here's also an interesting article on dcdiag /test:dns on Searchwinit.com: http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1133065,00.html Wayne

0 pointsBadges:

Astronomer Apr 10, 2006   2:38 PM GMT

Wayne: Thanks for the link to the sp1 utilities. Running dcdiag /test:dns revealed a change on one of the other DCs the techs didn't tell me about. I checked and the problem DC has sp1 on it already. Based on the link this was a very good guess. rt

15 pointsBadges: