This appears to be a variant of the DTC and network configuration issues that I have discussed earlier, here and here.
Once again, DTCPing came to the rescue.
The client was running the eConnect integration on a laptop in a docking station, so it had both a wireless network connection and a wired connection.
When I ran DTCPing on the client, it ran fine and was able to connect to the server. But on the server, I received the familiar -->gethostbyname failure error message.
It turns out that the wireless network card was issued an address on a different subnet than the wired connection, which itself should be fine, but for some reason, the server could ping the wired IP address, but not the wireless IP address. And the server happened to be clinging to the wireless IP address for the laptop, preventing DTC from communicating back to the laptop.
To resolve the issue temporarily, I edited the hosts file on the server at C:\Windows\System32\drivers\etc\hosts and added a new line to force map the laptop computer name to the wired IP address.
After running nbtstat -R and ipconfig /flushdns, the server finally started to ping the laptop successfully on the wired network card.
Running DTCPing again, the gethostbyname error went away, and the usual Windows XP "access is denied" error returned, which I now ignore.
We then ran the integration on the laptop, and it worked fine.
The permanent solution for this client is a little more challenging. I suspect that their wireless network limits or blocks traffic to the wireless clients for security reasons, but that also prevents DTC from working properly. The best solution I could think of at the moment is to add a fixed address record in their DNS server for the laptop's wired network card, and/or give the laptop a static IP address for the wired network card, to try and force the GP server to always resolve to the wired IP address.
No comments:
Post a Comment