In
mike i said:
Neither FQDN nor NetBIOS names work for pinging or
anything else. As far as the details of the network,
here's the overview:
Subnet A: Internal network with private IP addresses. 2
win2k DC's with with AD integrated zones. Both DC's are
in the same domain. Neither of the servers can browse the
resources on Subnet B, nor ping them by name.
Subnet B: DMZ with 3 win2k servers. Different private IP
network. The firewall serves as the router between the 2
networks, but the policy allows all traffic between Subnet
A and Subnet B. All 3 servers in this subnet are member
servers of the same domain as the DC's on Subnet A. All 3
servers can browse the resources on the DC's and ping the
DC's by name (FQDN and NetBIOS). In fact, all 3 were able
to join the domain from Subnet B.
IP properties: All servers have static IP's. The first
DNS server listed is the first DC. The second is the
ISP's DNS server. However, even if the ISP's DNS server
is taken out, the problem persists.
Hi Mike, thanks for posting that additional info.
THe first and MAIN thing I would do is immediately remove the ISP's DNS
addresses. This is paramount for a proper funtioning AD. I can provide a few
links on this, but you can read/search thru these newsgroups and you can see
the consensus on this. Just use your internal DNS servers ONLY (this goes
for the DCs and clients as well) and configure a forwarder. If the
Forwarding option is grayed out, delete your Root zone and refresh the
console and try again. This article shows these two steps: Keep in mind,
each DNS needs to be forwarded individually to the ISP. So this has to be
done on all DNS servers. Do not forward to each other.
http://support.microsoft.com/?id=300202
As for IP properties in your DC/DNS server, it's recommended that the first
should point to it's partner, and the second entry to itself. That relieves
a couple issues.
Ok, that stated, now let's take a look at your DC/DNS servers. Since they
are AD Integrated zones, that's good. I want to suggest to put one in the
DMZ, but it's not necessary. Since B (the DMZ) can access A, but not the
other way around, I am curious if there is any Event errors showing up? I
have a feeling that it's either there is a rule blocking traffic in one
direction but not the other. I am curious if there is any MTU modifications
or an H.323 optimization going on (which is default in scenarios such as
this). For example, under many router manuf, when there are mutliple NAT'd
private IP interfaces, traffic between the subnets may be squelched to a
degree. The biggest problem I've seen is H.323 traffic being optimized,
which causes a problem with LDAP communication. LDAP uses a PDU (process
data unit) sixe of 300k, but H.323 uses 64k. SO what we usually do, say if
this were a W2k server, we disable H.323 support, which then LDAP will
communicate. In some router brands, I've seen MTU optimizations for video
conferencing (H.323) and were set below 1500bytes (such as 1460). Once put
back to 1500 bytes, the problems go away.
In summary, take care of and clean up the DNS settings on all your machines
first, please. This may all be a simple issue of DNS resolution. Believe me,
using an external (such as an ISP), *WILL* caused numerous issues. All you
have to do is search back thru these posts to see what I mean. I'm leaning
towards that is being the problem and second, torwards the router. It may
also be a combo of the two. I don't think it's an MTU issue at this point.
Remove those ISP's from your DCs and member servers and clients and let us
know how you make out.
--
Regards,
Ace
Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
