I am seeing assets duplicating, and attributes being mixed among the duplicates, making it really hard to identify what is what. I've been trying to work with tech support on determining what is happening, and it sounds like the program uses a device's IP address as a unique identifier. They want me to set my DHCP lease time longer. Not really a good option for me, and they are dodging the question of how to fix the duplicate/mixed assets I now have. I'm getting pretty bummed about this very rapidly.
Anyone else run into this? And why on earth would they use the IP ADDRESS to uniquely identify a network asset in a DHCP environment???
I found a way around the duplication.
In our setup we had it creating duplicates due to the discovery. It was making a copy of the asset if it had a new MAC address or new IP address
I edited the Discovery settings to "Sync with Existing Assets Only"
So far so good
We have been dealing with this for some time now. Lost records, duplicate records, duplicate records with different client and so on.
Does anyone know if there have been any fixes updates or a resolution to these problems. I'm currently asking because if I can't find that this has been resolved, we are looking to move to a different solution.
I just started using WHD in the last month, and I have just noticed the same issue. This has not been fixed and the asset integration is one of the reasons that we purchased this product.
We just discovered this bug in our asset database, which is now largely useless in terms of being able to identify who has what and where. This is a major bug. It's been documented in at least the last two revisions. Here's the thread from 2016: Re: WMI Asset Discovery Problems where mark.dangelo also commented.
Why isn't this a priority to fix? Suggesting that people go out and spend more money to buy either another Solarwinds product or a completely separate product is just irresponsible. (I work for a small state agency with budget limitations. This is not a conversation I will look forward to having with our CFO.) It's like the having the email engine continue to rely on TLS 1.0. It's a major, basic flaw and not fixing it in favor of adding additional features is, in my opinion, developer malpractice and unethical.
Why yes, I am angry. I have a staff of three, we have some major projects going on and now my team needs to take a couple of days to generate a clean inventory and (cross-fingers) re-import and then continue to use the product with one of the major features disabled. How would you feel?
So, any plans on fixing this for 2.6?
Connor W. Anderson
Chief Information Officer
Oregon Department of Geology and Mineral Industries
Won't be in 12.6 but it's currently planned for the next release. Here's the issue.
Current logic when the WMI discovery finds an asset:
Is there an asset in WHD DB, that has serialNumber AND ipAddress AND hostname AND macAddress the same?
if not, is there an asset in WHD DB, that has ipAddress AND hostname AND macAddress the same?
if not, is there an asset in WHD DB, that has ipAddress and macAddress the same?
if not, is there an asset in WHD DB, that has hostname and macAddress the same?
if not, is there an asset in WHD DB, that has macAddress the same?
Within each of those steps there is an assumption that the required attributes are available (are non-null).
If one of the fields is = null, logic goes to next step.
If any of the steps return a search result, the resulting asset is updated with new values.
If none of those steps return a result, then a new asset is created.
You see, that current implementation focuses on MAC address.
So if your DHCP server gives your laptop a different IP, logic should go to the hostname/macAddress combination and update the IP address on the existing asset. Not sure, why it is not happening, might be a bug, that we'll need to resolve.
Thanks for outlining how it works. I now understand why this doesn't work very well for us in our environment. It started out fine, but after some time, combined with reloading many of our PCs with Windows 10, along with changing our PC naming convention at the same time, has caused lots of overlapping or updating the wrong records, and duplicating entries. We're also using DHCP, and have multiple subnets that users will move between wired and wireless.
I think another thing that bites me is the Delete Asset checkbox isn't actually deleting the record from the DB. I think the documentation even says it's just flipping a bit on a hidden field in the DB. I've found that by deleting my entire list of assets and trying to start over with Discovery scanning again, then when assets are found again, the scan just flips that bit again and makes that old record show back up. I finally figured this out when I found that all the manually tracked fields I was adding to each record were magically showing back up on rediscovered assets AFTER I "deleted" the record.
I've also found that because it's not truly "deleting" the record from the DB, in some instances, it's possible to have subsequent Discovery Scans create multiple records with the same Asset No. when using Web Help Desk Numbering starting at #. I started at #1 when I first started doing Asset Discovery scans. I've "deleted" assets and rescanned, and would end up with two different records both with Asset #1....#2....#3 and so forth. In order for me to save either record with new info I'd have to manually update the Asset # to something unique before it will let me.
I guess for me, why is SerialNumber not in every line of logic? I guess maybe custom built PCs? SerialNumber would be the most unique thing in my environment which is all purchased OEM built PCs. On our virtual stuff all the VMs have virtual SNs that appear unique from what I see. So the only ones I can think that would have issues are the custom built PCs were that field has "To Be Filled by OEM". Couldn't the logic detect if the SerialNumber is blank or has "To Be Filled by OEM" and do a completely set of logic for those PCs? Then for everything else that is a major OEM PC (HP, Lenovo, Dell, etc.) keeping SerialNumber in all the logic steps would make sense.
I really don't like IP in that logic. On DHCP networks IPs change if you don't set reservations (which is very rarely done in our environment). We have several laptop users that will work from multiple locations so IPs will update on them depending on where they are when the scan is run.
I also don't like the MAC address being in there, as you point out it would change based on primary NIC, laptops probably the most affected. It's not unheard of to have a motherboard replacement on a machine which for sure would change the MAC if the NIC was integrated which most are.
This article is worth a look:
According to this, the only other truly unique value on a PC install is MachineGuid, but that only exists in Registry so I don't think you can find it with a WMIC command.
UUID is another that is close, and is in WMIC, but they have pointed out some instances where it returns all FFFFFF. But again, could make the logic fork to different rules if it detects that.
I could get behind the idea of letting me control the logic.
Other notes on WMI Objects and Discovery Scan in general:
I'd love to see the following added.
CPU Name (wmic CPU get name) *the existing WMIC command in WHD for CPU is not grabbing the Name but instead the CPU Caption which isn't very friendly when you want to know what CPU is in a PC.
CPU Core Count (wmic ComputerSystem get NumberOfLogicalProcessors)
RAM (wmic ComputerSystem get TotalPhysicalMemory) *Then Divide the value by 1000000000 to get a normal readable value. This is total physical RAM installed (less whatever integrated video is taking up. Capturing Used and Free memory isn't a great number when doing asset management IMO. I want to know how much RAM a machine has when I review what systems should either be replaced or upgrade etc.
BIOS Version (wmic BIOS get smbiosbiosversion)
BIOS Date (wmic BIOS get releasedate) *would need to be formatted to a readable date
OS Architecture (wmic OS get OSArchitecture)
And it would be great if I could have the ability to add some of my own WMI Commands.
For Discovery Scans it would be great if I had the ability to do a single one-off scan of a DNS name without having to run the full discovery scan on the entire network. If I image a new PC, and want to add that into assets, it takes forever to run a full discovery scan on whole network just so I can have it find/update one more machine.
Thank you for being responsive and transparent. I think this is the most complete description I've seen of this problem in the forums and it does help us develop a mitigation strategy.
That said, I have to echo CSmith's comment below. Both in terms of the prioritization of reading in the values and the general thrust that this really shouldn't be an issue for the customer to deal with. It's a matter of basic functionality and QC and should be fixed above other priorities such as feature enhancements. That is the ethical, right thing to do.
I'm not a DBA or much of a programer but I can think of a couple of ways around this.
But this absolutely shouldn't be a problem. Modern business networks rely on DHCP and multiple sites/vlans too heavilly and users are mobile. And now W10 has a MAC address masking feature for public WiFi networks that will muck with MAC values. This needs to get fixed.
Connor W. Anderson
Chief Information Officer
Oregon Department of Geology and Mineral Industries
I think we're in a loud agreement here. Both of you are correct. While creating a "proper" fix will be fairly expensive on the engineering side, I am trying to figure out, whether a quick and easy fix delivered in form of a buddydrop would satisfy you short-term. That's what my proposal above is about
Connor, your example around S/N and Asset Tag seems compatible with the configurable WMI discovery.
Are you able to tell if this dupli8cating issue also affects assets imported from outside systems like SCCM. I have a lot of duplicates and was working with Support to figure out what was happening. I was wondering if serial is not used as the key field like it should be. A matching serial should just update the existing record.
The case is romant as we hit the start of semester this week but I hope to reopen it next week.
Well, we have been working under the understanding that the bug is isolated to customers using the WHD built-in WMI discovery tool. But if you are seeing duplicates using SCCM or some such then that seems to me to want to escalate the issue since one of the given work-arounds is to use a different inventory sync tool.
Earlier in this thread, specifically in October of 2017, this issue was identified as very high on a priority list to resolve. Apparently not.
Personally, I think the idea of making your discovery logic tuneable is just passing the buck on to us so you don't have to fix it. This is something that should just work.
If it was mine to tune, IP address would be a parameter I would read in AFTER the device was identified by other static values. But I think this is something you should figure out and implement, not us.
Does this only affect assets that get updated via WMI? I have 22 locations, 2000 devices. I've noticed the duplication in devices where the site is updated via WMI. Will my inventory be intact for those sites not updated with WMI?
I've only seen complaints from those using the integrated WMI discovery tool.
So far the only answer I have gotten from SolarWinds is "use another asset discovery tool and integrate it" with a recommendation for Lansweeper. And that they know it's an issue and maybe kinda possibly hope to fix it one day.
Of course Lansweeper is only free for a very limited number of assets, at which point you have to pay 500 bucks annually to use it. So basically, SolarWinds recommends paying for a competing product and integrating it with their own as a solution to this issue.
After working with SW tech support for a bit, I have arrived at the conclusion that there is a major bug in this software. I have many assets in my database with duplicate entries, I have assets with attributes that are no longer correct and/or crossed up with other assets, and I have assets that are missing entirely. Serial numbers are now listed as the wrong make/model, associated with the wrong user, etc. My asset database, and presumably any ticket history per asset that I now have, are compromised. I have to physically verify my inventory again and reassociate machines with users as necessary.
The problem seems to stem from a flaw in the manner in which the IP address is used in conjunction with other data to determine the ID of the machine. If a device's IP address happens to change, as will be the case in a DHCP environment, some asset attributes appear to follow the IP address, while other attributes appear to follow either the asset ID number assigned by WHD or possibly the MAC address. Whatever is happening, it definitely is not right and my asset database is trashed.
I have asked that the case be escalated and will update here when I learn more.
Is anyone else having such issues?
We had the exact same issues using the built-in WMI discovery. It was using the IP address as the unique identifier and in a DHCP environment it's not usable. Why it doesn't just sync based on the Serial Number is what I don't understand.
We abandoned the WMI discovery as it just created way to many frustrations and mixed up asset information.
I can see why they would want to use a combination of parameters to ensure a device is uniquely identified, but I am convinced there is a bug in the logic they use to include the IP address within these parameters. WMI data and DHCP data agree with each other and show one thing, and the WHD asset data shows something completely different. And once records get attributes mixed up, it's hopeless.
Does anyone from SW read these posts? I have asked the support tech managing my case to escalate it because he keeps going around in circles, and he won't let go of it and do as I ask. It's getting frustrating.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.