server42.company.com no longer resolves from *.forest.company.com servers

[Cerulean]

Greetings,

We recently replaced our old Checkpoint server (router/firewall) at one of our overseas divisions (forest.company.com) with Cisco equipment. All connectivity appears to be working fine now. Nothing changed subnet-wise; just a hardware replacement, that is all.

Here is the problem: from forest.company.com, we are unable to ping server42.company.com (does not resolve to an IP address), nor just 'server42', and we used to be able to. We can ping the IP address of server42 successfully, to which we also have a network share but even using the IP address in UNC path we get an error message like "no network provider accepted the given path" (Server 2003) or "a device attached to the system is not functioning" (Server 2008).

EDIT: Well, we just made an entry 'server42' into the server responsible for DNS at forest.company.com statically defining its IP address, and modified the KIX script to map \\server42\common instead of \\server42.company.com\common. Tested a user on two terminal servers, appears to be working. Not sure where those errors were coming from It's working now.

 

[RocketTech]

The bill is in the mail.

 

[necrophobic]

So on the DNS server that should've been resolving the hostname there wasnt an A record for the server? Are dynamic DNS updates allowed in the zone on the DNS server that server should be registered on?

 

[Cerulean]

So on the DNS server that should've been resolving the hostname there wasnt an A record for the server? Are dynamic DNS updates allowed in the zone on the DNS server that server should be registered on?

What it turned out to be (this is new information!) was on one of the servers in a local DC we forgot to add a route statement via cmd to the IP subnet of forest.company.com. After this, everything began working correctly.

 

[/usr/home]

What it turned out to be (this is new information!) was on one of the servers in a local DC we forgot to add a route statement via cmd to the IP subnet of forest.company.com. After this, everything began working correctly.

You shouldn't have to manually add routes on clients if everything was setup properly networking wise.

 

[Cerulean]

You shouldn't have to manually add routes on clients if everything was setup properly networking wise.

We're working across two entirely different subnet classes (192.168.x.x vs 172.16.x.x), and two different domains (company.com and forests.company.com vs just company.local). In addition, more than half of our locations were setup using Checkpoint firewall on HP DL380 G2/3 servers, and I think as of right now 2 or 3 of our divisions are using both Cisco and Checkpoint (but with Cisco as primary). There's a ton of VPN tunnels; it's nasty. Checkpoint is the biggest PITA to work with, even with non-contract premium Checkpoint tech support, and a very simple thing could bring down the entire Checkpoint VPN network. (Checkpoint is what the previous sysadmin selected and setup for the company.) We have to work with two completely different and separate computer systems (new and old) for a company in the 500-1000 employee count tier with worldwide facilities. There are so many "really?" and "who/what kind of persons configures or sets <whatever> up this way! *uberfrustration and facepalm*" on the old computer system; I don't know what experiences you have had, but everyone that has walked in and walked out (including the ones that are still in) has pity/"wtf" for the old computer infrastructure. Does this say anything, or what you say is still true?

 

[Haven]

Check your Active Directory Sites and Services and make sure all your subnets and sites are defined in there. Then it will know where things are.

Beyond that just having a default gateway and having the routers know where to go for what would be easier to work with, instead of having to remember to put a route state in every time you reboot the DC.