I'm coming to the community first before I open case because I'm curious if others have this same issue. With the explosion in wireless use and servers which require multiple nics and special configurations we are seeing more issues where clients are failing several primary functions in Landesk because the core server is trying to communicate with the client on an IP that is not reachable even though another IP on the client is available and reachable from the core server.
I'll provide two examples:
- A server with 2+ nics. One of the IP addresses of the server might be in an unroutable vlan, dmz, etc. One of the other IP addresses will route to the core server. When the client communicates with the core (inventory, patching, swd, etc) it works fine because the OS is smart enough to figure out which nic to use. However, when the core tries to communicate with the client it will try and use the address which it cannot communicate without ever trying to use one of the other IP addresses from the inventory of the client.
- A laptop with a wired, wireless, and VPN adapter. Similar issue... the client could be on wireless and wired at the same time, or wireless connected to VPN to the core server, while also wired to their own internal network. There are more examples I'm sure, but this should suffice.
Our clients are configured to update when an IP address change is detected and getting updates from the client is not an issue. This works beautifully and is not the point of this post. While I've messed around on the laptop/desktop side with binding orders and whatnot it hit me as stupid to do so as we're setting up new servers which require configurations where this is not possible. Alternatively, it seems like such a simple solution for the core server's client discovery process to try and communicate with the client on all IPs which were reported in from the inventory and not a single one which might or might not be the correct one. Although, I guess another solution would be for the client (or server?) to mark which IP was used to send the inventory to the server and use the 'last known good IP'. Either way, it can be painful when you can't deploy software, helpdesk can remote control, and several other functions which show clients as being offline when their not.
Thoughts? Who else has seen this and feels my pain?