Hello.
I’m just doing a little discovery data quality work and would like to ascertain as to which WMI properties are parsed to populate the ‘speed’, ‘duplex’ and ‘negotiation’ attributes on ‘DiscoveredNetworkInterface’ ??

I don’t really want to go into too much detail as to what i’ve done so far as it’ll send everyone to sleep i’m sure.
So I guess (if possible) i’d like a simple answer as to what WMI properties Tideway needs returned from the WMI queries for the “speed” attribute for example.
The WMI queries do a ‘SELECT *’ call from 3 classes….. but it’s which properties that are returned from these classes with a value that i’m interested in knowing.

FYI – I’m running my tests on Windows 2003 Server hosts.

Thanks

Unfortunately, thanks to the Windows driver architecture, the problem is more complex than you think.

The properties are actually described in vendor specific registry keys using vendor specific values. The Windows Slave is not just a simple proxy and this is one area where it has built in knowledge and understands which registry keys need to be recovered and how to map the (often esoteric) values into rational Speed, Duplex and Negotiation values.

WMI is used as an access type to get that registry key data but due to the complexity it is not reported on the platform page of any current Foundation release.

So the simple answer about what WMI class properties are used is “none of them” as this information is (strangely I agree) not part of the WMI model.

Your best approach is likely to be to ensure that you can query the registry on the target host and if you believe you have a type of adapter that is consistently not being understood to raise that with support so we can get it fixed.

To add to the information from Charles..

The information related to speed/duplex/negotiation for windows interfaces is handled by “mapping blocks” within the slave.conf file on each slave. If you open the file in an xml reader.. you’ll see dozens.. if not hundreds of “adapter match” blocks. Each block contains the registry key{s} to obtain, and maps out the values for those keys to the appropriate speed/duplex/negotion settings.

In theory you could write you own xml blocks if you had the data… but you would need to maintain them across upgrades.. and hopefully get them included into the next slave release.

Not sure if there is a plan/path to upgrade the known adapters data in the slave.conf file…. sure would be nice if there was a TKU type update for this.

It’s certainly something we are looking at and why I didn’t go into too much detail, the challenge is currently the configuration is held on the slave and we need to consider the most effective way to roll that out, especially if several slaves are in use serving different versions of Foundation in a phased upgrade.

In the mean time if cases are raised through support we can make sure changes happen in the next release. It’s one of those areas where some help from the community may be the most effective way forward as there is a great variety of NICs out there!

Thanks for replies Charles / Dave.

Charles taking into account your advice on how to troubleshoot these issues….
“Your best approach is likely to be to ensure that you can query the registry on the target host and if you believe you have a type of adapter that is consistently not being understood to raise that with support so we can get it fixed”

What (if possible) is the best approach to attend to large scale issues (ie thousands of NICs without speed, duplex or negotiation across a very large number of hosts)?.
Note: Slave settings at the site I am currently working are syncronised so there’s no issue with different NIC settings per slave configuration.

The slave logs do appear to track the registry queries but do not print the relevant IP address of the host that the query is running on. So, from a data filtering / analysis point of view, this makes this excersise very difficult.

Thanks

It’s difficult to give specific advice for something like this via the forum so if you have detailed advice consider using the Support and/or Professional Services route.

However to get a handle on the issue I’d start by looking for large patterns in the data to see if the major issue is with a particular common type of card.

On 7.3 the following query might help you get started:

SEARCH Host WHERE os_class = ‘Windows’
TRAVERSE DeviceWithInterface:DeviceInterface:InterfaceOfDevice:NetworkInterface WHERE NOT speed
SHOW SUMMARY, #InferredElement:Inference:Primary:DiscoveredNetworkInterface.#Member:List:List:InterfaceList.access_method AS ‘Access Method’

That will find all the NetworkInterfaces in Windows machines without a speed attribute set and then display these along with the access method used to recover the InterfaceList. If this is WMI it would be reasonable to assume we had access to the registry. You could then use the column charting for spotting the most common cards.

Note that the query will still work in 7.2 but you wont be able to get the access method.

I too have thousands.. if not tens of thousands of NICS with no speed/duplex/negotion stats. About a year ago I worked with someone in either support or product management.. who was able to provide me with a query that produced a list of all the NIC types that had this problem. I can’t find the query at the moment.. but what it boiled down to.. is while there are a large number of nics total.. it was really only about ~100 different network cards overall. Unfortunatley, we were forced to accept that our server design/engineering folks were using NICs that tideway simply didn’t have any data for.

I would guess that you situation is similiar.. and that its not really a problem with being able to obtain the data via discovery… is just that the particular interface cards you have, do not have known values within the slave.conf file that decodes all the registry keys.

Hello all.
I raised this point a couple of years back in regards to the difficulty of Windows slave discovery of Speed, Duplex and Negotiation.

Still to this day, these attributes are very poorly populated.

Charles mentioned the possibility of BMC having a TKU-like release of the Proxy xml code which checks against NIC types in the registry. I was wondering if any progress was ever made on this?

I do agree with Charles in that it will require a community effort working with engineering to provide as many problematic NIC types to get the data quality improved.

I just wanted to re-open a chat on this topic to see what other people’s thoughts were??

Thanks

FYI… We have an open support ticket open on this issue (ISS03896006). I noticed that in ADDM 8.3.0, it would not even populate the field if it found it using the WMI query of the Win32_NetworkAdapter class. It was a field called “Speed”. I have checked hosts that work and don’t work, and both have this same field. Hopefully this helps engineering integrate it into ADDM.

If that does not work, check out this link…

http://www.peetersonline.nl/wp-content/get-nicsettings.txt

I openned a support case and Support told me how to modify the winproxy.conf file in order to detect the speed/duplex that is configured. The problem is, if it is AUTO, it will not populate with the current speed/duplex. It basically looks at the registry key for the configured speed.