KACE Product Support

The first reason you would get a BAD_MAC_IP error is if you have duplicate KUIDs trying to check in. This is because the K1000,by default, is set to detect duplicate assets and not allow them into inventory.

Putting the amp agent directly intothe image you are using, rather than installing the amp agent post installation will cause this problem. There is ascript in the K1000 that allows you to reset your client KUID: K1000/Adminui >Scripting > Scripts > Reset KUID.

Also, you can manually reset the KUID by following the steps inthis article to delete the keys manually and have them re-populate: http://www.kace.com/support/resources/kb/solutiondetail?sol=111253

Here isanother article that addresses duplicate machines, disappearing inventory devices, and the over-arching question of duplicate asset management: http://www.kace.com/support/resources/kb/article/understanding-and-dealing-with-duplicate-machines-in-inventory

Anotherreason we have seen machines not propagating inventory, while giving theBAD_MAC_IP error, is due to altering a virtual K1000's hardware resources.

If youare dealing with a K1000 virtual appliance, you have the ability to alter theamount of resources that you allocate to the K1000. If the hardware in the virtualappliance is reduced below 4 cores and 8 gigabytes of memory, you may run intoissues with provisioning.

This isan example that I saw last week:

I was provisioning a group of 130 computers that were all freshly imaged. After they were provisioned they wouldn't populate into the K1000 inventory. Furthermore, the K1000 log was showingthe error 'BAD_MAC_IP=xxx.xxx.xxx.xxx' for the computers that I was provisioning. They were not populating into the K1000 at all. This is what turned out fixing this issue:

The Virtual K1000 was configured as such:

>OriginalHardware Configuration:  (4) cores and (8) gigs of ram.
>The K1000 hardware was altered to:  (1)core and (4) gigs of ram.
*This worked for a while until it reached roughly 1700 assets, then it startedthrowing out BAD_MAC_IP.*
>The hardware for virtual K1000 appliance was then changed to: (2) cores and (8) gigs ofram, and then rebooted. This fixed the problem and all of the machines startedchecking into inventory.

I would like to hear if anyone else has a weigh in tothis issue. There are other possibilities that I haven’t been able to fullytest in my lab environment, like the possibility for this to be caused byIP/DNS related problems.

I had a similar problem on a Debian GNU/Linux 9.9 box. They had been working fine until the latest upgrade on the SMA. I finally found the page athttps://support.quest.com/kb/129683/bad_mac_ip-provisioned-devices-not-populating-inventory, which pointed me in the right direction: The <OS> field in inventory.xml was empty. So I manually ran "/opt/quest/kace/bin/KInventory -machine -output /root/inventory.xml" and looking in
the newly-created "/root/inventory.xml" I found:

[2019-07-08.15:26:32][KInventory:fetch_OperatingSystem]
[fetch_OperatingSystem] Could not find major/minor from ""
sh: 1: lsb_release: not found

Doing an "aptitude search lsb" I found that lsb-base was installed, but lsb-compat was not. Shooting in the dark I did an "aptitude install lsb-compat", and then re-ran "runkbot 2/4/6 0", and bang! My machine shows up in my SMA's inventory screen, and seems to be working correctly. I was even able to force an inventory.

For me, I think I can consider my issue solved. The solution was to install "lsb-compat".

/Kent