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:
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?
I am experiencing a related problem to yours; my school has more than 500 clients with about 400 of them being tablets, notebooks, netbooks. All of these mobile devices have both a wired NIC and a wireless NIC.
Currently the console reports TWO instances for each machine because it thinks that each NIC belongs to a different machine. I have tried various settings with DUPLICATE DEVICE DISCOVERY, which is located in the CONFIGURE SERVICES option on the core. None of my settings changes there have resulted in my device count shrinking...I still have duplicate devices being reported in the network view.
judging by your post I don't think that you have this specific problem, but it seems to me that once I resolve this I will be in the boat with you...wondering which NIC LDMS is going to try and use when a task is run against the machine...?
So far I'm not really enjoying this either.
We have run into the similiar issues with multiple IP addresse and have not found a resolution with LANDesk, however our workaround is to have the machines shipped from the factory with "LAN/WLAN Switching" enabled in the BIOS which automatically disables the Wireless connection if a LAN connection is detected. We have HP's so im not sure if this is only HP specific option in the BIOS but it has helped us out.
The core should be trying to contact the client by the IP address in the inventory at Computer > Network > TCPIP > Address. For the machines that you can't get to, does that address match the one currently active on the client? If not you may need to look into why the inventory record isn't getting updated. Also, is your DNS keeping up with these changes? If you ping the machine by name that recently changed IP, do you get the right IP? What about ping -a to the IP address? That often brings back the hostname. LANDesk can fall back to DNS when there are problems getting to the machine.
You really shouldn't have two instances of each machine just because they have multiple NICs. What are your settings for Duplicate Device ID? You can get to them from Configure > Services > Inventory > Device IDs. What Identity Attributes are set? What number is the trigger set to? Is the Reject duplicate identities checked?
Also, what are all the columns in your column set configured to? What values or information are you showing in the column set?
we also have some HP laptops in our deployment which have the LAN/WAN switching option in the bios; historically we have disabled this feature in preference for having at least the wireless always on and connected. Our user population gets all of its files from a network share rather than local copies, so we need a constant network connection state to service them. We wanted to ensure that network connectivity would always exist and we figured that the LAN connection would 'take over' most connections when it became available, otherwise those connections would remain intact on the wireless side.
have you experienced any negative consequences from going the route that you have and using only a single connection? I'm thinking about problems handing-off the open shares between the two nics...any thoughts on this being a problem?
@ Tanner, thanks for being present to this discussion
I've tried what seemed to be all manner of options to get rid of the duplicate devices; all to no avail. Perhaps you can just tell me what landesk expects me to use in terms of a configuration? This is a very typical environment with mobile devices containing two nics/two mac addresses.
explains some of this; still trying to digest it all
I was getting duplicates in my NETWORK VIEW due to a custom column set configuration which showed the IP address of the maching; as such the machines with two IP addresses would get double entries here.
Yeah, that's the problem... the active IP which the core can communicate with and the one in the inventory at computer.network.tcpip.address are not the same. While most everyone else seems to have issues with mobile devices (and we do too), our issues are more production server related. Mobile devices I'm less concerned with because I know eventually they're inventory will reflect the correct IP and our policies methods are pretty solids... so they'll get updates. But when you're trying to push updates or execute a workflow on an active production server that the core is finding offline... very frustrating.
Inventory updates are happening on their scheduled basis... and I used inventory history to verify, but one time it will come in with the active address and the next will be the IP which the core cannot communicate with. DNS wouldn't be an issue on our production side because we're using static IPs and static a-records, so when we do ping the machine they resolve fine. My thoughts were just to try each IP available from the last inventory. Since I haven't seen any detailed documentation on why the client chooses one IP over another on multi-NIC systems, it just made sense to try from top to bottom until the machine responds.
I'll throw in some images from a machine exhibiting the symptoms. Below is a system that has two addresses and is on two different networks. The 10.62.51.252 address should be the primary... it is pingable from the core, console server, my machine and a test machine... has a static address and a-record. The second address is 184.108.40.206 and is on an internal non-routable, no DNS entry, not even pingable IP. But the client during inventory decides to put it as the primary IP for the client?
I'm not a wiz kid with everything in inventory. I would say maybe open a case and talk to someone on the inventory team and see if they can help clear this up. You *MAY* want to look at Configure>Services>Inventory>Advanced settings>Use Connection Address. That can sometime help (or hurt) depending on the environment.
I've ran into this problem as well, although my particular problem was with WOL and multiple NICs. We have some training laptops that when they are being used are 100% wireless. We leave them locked in a closet which has AC and ethernet cables for every laptop. What happens is the laptops report in using their wireless nic. Then when we put them in the closet and try to wake them up (for patches, updates, class prep work, etc) we can't use LANDesk because LANDesk tries to wake up the wireless MAC address. It's very frustrating. I had to write a custom script to wake up these laptops. Luckily they don't change very often, so it wasn't a big deal.
I don't know if this matters to anyone at LANDesk, but this is not the first time I have had my boss ask me why I'm wasting time writing scripts to do something that is an advertised feature of a product we spent(d) tens of thousands of dollars on...
I had similar issues... I ended up just creating a Custom Vulnerability that only allowed one NIC to be active.