I had this issue in 9.5 and found it was the mini-scans that were doing it and I deleted the miniscans from the ldscheduler and eventually created agents that never ran miniscans. See if that might be your issue as well.
Sorry Joe, the tests are made with the following schedule for inventory:
I checked the local tasks on the device to see if there is a miniscan scheduled but there isn't:
I have uninstalled Virtual Box software on some devices that were affected by this issue and they are reporting now the right IP and NIC address (either in the corporate network or through CSA).
Does anyone know if there is an incompatibility of Landesk Management Suite with Oracle Virtual Box software or if there is a release notes page where I can find some information? I would like to be sure before I move Landesk from testing to production phase. We have lots of developpers who use it in their laptops for testing purposes and it could be a problem when identifying these devices through the console for management purposes.
We're having exactly the same issue. Some of our desktops are running Virtual Box and all of them are reporting their IP address being 192.168.56.1.
It's been almost one YEAR since this post was originally published. How can we not have a solution yet?
The binding order of the NICs is OK, so why is the agent sending the wrong IP address to the core server???
The agent should be updating the IP of the client that is currently connected to the LAN. How come it's reporting the address of an interface which can't reach the core server at all??? I mean, the agent IS contacting the core server via a LAN interface, right? So WHY isn't it reporting the RIGHT IP address, assigned precisely to THAT interface, through which the information is being sent?
And why can't we force any selected IP addresses in the core to be assigned via DNS, or even manually to work around this???
We don't want ALL of them using the DNS because we have laptops that may be connected via different interfaces (wireless / wired). Are we supposed to go to the computers and fix them one by one? Then what are we using a so called MANAGEMENT SUITE for? What if we have THOUSANDS of devices???
Seriously, this is a very nasty bug and must be fixed.
... if it's a "nasty bug" - why not open a support case? That will generally be more productive in such situations.
The community is generally better at helping with config / "how do I" issues - defects still need to be logged with support. Otherwise, dev will never see them.
A few points in general education however:
- Windows "Primary adapter" changes on a "per boot" basis (you can see the same sort of issue on multi-homed devices). The Primary NIC changes every boot "because reasons" ... UEFI allegedly should improve that.
- Since this sort of problem can exist with NAT environments as well, we've had (for many years now) - does that help you? (This is in the ADVANCED settings of the INVENTORY service)
... there's no specific "we're not supporting Oracle Virtual Box" situation in place at present. I'm not aware of running into these problems with VMWare / Hyper-V - by and large we mainly worry about "does the virtualisation work fine" ... network adapter stuff like this should not be a "we don't support that software" type call.
If the respective parties that want this to work better / properly log cases with support, we can gather the impacted folks into a ticket with dev & prioritise accordingly. Shouting "it's a huge defect" doesn't make it necessarily so (I've not heard anything about this myself, and work with some shops that use Oracle Virtual Box).
If it's straight forward enough to duplicate (by the sounds it is?), again, a ticket to support would be the best way forward. If / when a defect will then get logged, feel free to post the defect # on this thread, so that other folks who are affected can get themselves added to it as well.
Hope this helps?
There was also a defect opened in regards to something similar Defect ID 307783, which is marked as fixed. You may want to get onto the latest patch/sp and update your agents. However phoffmann is correct, you want to make sure that use connection address is enabled and make sure that "encrypted data transport" is not enabled
1 of 1 people found this helpful
Ah - good find!
... looks like the fix was built in September, so if you're on 2016.3 that should fix it ... see here in the 2016.3 readme - https://community.landesk.com/downloads/Readme/Pages/LD2016.3.html -- we have the following:
... so there we go. Issue should be resolved.
In the (I'd hope - unlikely) event that there's still a follow-up to this, you've got a defect ID to base it on.
OK, let me rephrase. What is discouraging is doing an exhaustive search to find out that the exact same issue has been around for at least eight months but so far we don't have valid answers or helping resources regarding it anywhere in the knowledge base for the community. Doesn't it look like that the user that published this post in the first place has been ignored? I don't know about others, but I *ALWAYS* try to find the solution for my problem by myself first, and only if I can't find it I would log a support call, which usually involves a lot of time. Having a comprehensive KB of known issues and this kind of threads with a correct answer is in the benefit for both Landesk support staff and us the users. We shouldn't have to open a support ticket for some odd behaviour that is well known and fixable by the users themselves.
Except that in this case, apparently, it is not, because I had found that information already and ensured that we had that configuration value set to "1" (which is the default if I'm not wrong), yet the IP address of the wrong adapter is still being reported. Or should we try and change it to zero, as we don't have any manageable devices behind NAT routers and we are not deploying the agent to our virtual devices?
As we can't force a change in the IP address assigned to a device, what we have tried is deleting the affected ones and rediscovering them. Then, the devices were listed correctly, but as soon as the computers were rebooted, their IP addresses would be wrong again and not reachable anymore.
Anyway, I apologise for not having taken a more constructive approach and I'm most thankful for your prompt reply. I will try setting that value to zero and tell you about the results. If everything is still the same next Monday, I'll do as you told me and log a support call. If we find a solution I will post it here hoping that it may help others as well. I'd welcome any theories on any other possible causes for this behaviour, though.
Just to update (apologies) - see the post about 2016.3 -- JonnyB has found a specific defect logged against VirtualBox that has been fixed there. That SHOULD hopefully address your issue specifically .
No problem on the frustration - we get it (we've been there).
The above defect is the reason why we try to push people towards support with "genuine defect issues" -- we can't catch every thread (we try), so some might slip through the cracks & defects never will get logged (and thus issues won't get resolved). We're not being obstinate ... .
Hoping everything will be good for you if you can / want to test against a 2016.3 agent (hopefully you have a lab Core where you can do this reasonably easily)?
Ah, I was typing and sending a reply at the same time as you, sorry about that.
Yes, I had found references to the "encrypted data transport" as well, but we already had it disabled.
But you might have found it! We are indeed running an earlier version. We will patch it and let you know if the issue is gone.
Again, thank you very much and sorry for my initial rudeness.
No worries. Long as we can get you back on track - all's well that ends well .
Sorry to everyone, I forgot to close properly this thread.
I forgot to mention that a couple of months after, I wrote a similar question again: Wrong NIC address in the inventory (virtual adapter instead of Ethernet adapter). Finally, I opened a case to Landesk support and they raised the Defect 307783.