Device Type win 8 Desktop vs. Laptop

Hey

I got an issue in IEM9.2.2 where pretty much all Windows8.X laptops are reporting as desktops.

I tracked the issue to being the “Device Type” testing 2 ways if a battery is in the device… but the 2 checks are AND’ed, causing the laptops only having the one battery-type detected, not to register as a Laptop. I switched the detection of the windows Device type to use OR instead, causing all win8 Laptop devices on MY setup to register as Laptops. Can someone please confirm this relevance to report more correctly on win8.X Laptops??

Kind regards Jesper

MyTestingDeviceType property:

(
if(it starts with "Win") then 
if(it as lowercase contains "mobile")then "Mobile" 
else(
if(it = "Win95" OR it = "Win98" OR it = "WinME")then "Desktop" 
else(
	if(nt workstation product type != product type of operating system) then "Server" 
	else if (
					exists active device whose
					((class of it as lowercase = "battery" OR class of it as lowercase = "system") AND service key value name of it as lowercase = "compbatt")
				) 
		  OR (
					exists active device whose(class of it as lowercase = "battery" AND service key value name of it as lowercase = "cmbatt")
				)
	then "Laptop1" else "Desktop1" ))
else "Unknown"
)
of name of operating system
1 Like

This relevance as well as the physical/virtual relevance and some similar have always had edge cases that they do not handle correctly and require some refinement.

Part of the problem is that it is hard to write the relevance to handle all cases correctly without all possible cases to test against.

Your improvement makes sense, but it is possible it causes a different set to become miss classified.

I plan to take a look and get back to you.

@jgstew, yea, seems like the OR will mark a lot of desktops as laptops.

After seeing this, I separated the two ways of asking about battery to be able to seek for somekind of pattern. It seems that win8 NEVER detects the first way of determining battery, whereas the second way seems to ALWAYS detects a batteryon both win7 and win 8… My best shot has then now changed into:

(
if(it starts with "Win") then 
if(it as lowercase contains "mobile")then "Mobile" 
else(
if(it = "Win95" OR it = "Win98" OR it = "WinME")then "Desktop" 
else(
	if(nt workstation product type != product type of operating system) then "Server" 
	else if /*(
					exists active device whose
					((class of it as lowercase = "battery" OR class of it as lowercase = "system") AND service key value name of it as lowercase = "compbatt")
				) 
		  OR*/ (
					exists active device whose(class of it as lowercase = "battery" AND service key value name of it as lowercase = "cmbatt")
				)
	then "Laptop1" else "Desktop1" ))
else "Unknown"
)
of name of operating system

Suppose ill be posting a bit more w. some success/failure stats.

1 Like

I think there needs to be a Device Type analysis with all of the different relevance pieces broken out individually as well as including some possible relevance that could be used for refinement to then try to determine what the best approach will be.

One issue I have seen is that this relevance or ones like it gets tripped up by a desktop being connected to a Battery Backup / UPS.

Ok, got a little further here with some simple stats:

The approach with only using the cmbatt-part seems to actually solve 261 laptop devices out of 335 running windows 8 (the rest was detected properly as desktops).
It also does not mess up any of my thousands of win7 device-detections.

My personal bet is that “people” rather wants the windows 8-laptops detected right, rather than having one or two laptops on UPS detected right.

I have been trawling the forums here, and the discussions have not really helped me in finding how to identify the UPS-issues: Im not going to use WMI as that seems sometime unpredictable… So if anyone have some pointers to a post inhere describing a solution, or at least points out now to identify a UPS driven device, ill be glad to see it. I am aware though, that this method of using “Microsoft ACPI-Compliant Control Method Battery” will match all devices having the the advanced power config installed, and thereby also potential UPS-powered devices. Just thought it would be pretty easy to filter out these after the fact.

Later…

I do have some related analyses:

http://bigfix.me/relevance/details/2999413
http://bigfix.me/analysis/details/2994755
http://bigfix.me/analysis/details/2994755

We do know this issue, though you can override the property with a setting.

_BESClient_DeviceTypeOverride

It seems Windows 8+ changed the battery types yet again… so we are trying to get this right. As @jgstew mentions, it gets complicated more when you have a UPS attached which is why we have the complexity there, and apparently some VM’s add a “battery” element to their hardware making it… sigh… a laptop VM

1 Like

Hey @AlanM

I got a few hundred VM’s here, they can all be properly detected as VMs as they are all ID’ed as Virtual Platform in ComputerModel, so they do not have to use the battery-scheme.

I also see the benefit of the _BESClient_DeviceTypeOverride, but in daily use, thats simply not practical as I do not want to micromanage (Thats why I got the TEM in the first place :-))

Genious Idea:
It looks like the ComputerModel works pretty good (ok, I Know it’s WMI, but it seems to work pretty good, and is pretty basic, so i would not expect it to change…: )

if (exists wmi) then (string values of selects "Model from Win32_ComputerSystem" of wmi) else ("N/A")

How about just make a webservice, looking up the model, http://LapOrDesk.com/2355HFG returning Laptop.
That way the relevance could just do the lookup, and set the _BESClient_DeviceTypeOverride

… Mkay… there will be some manual work maintaining this database… hmmm

More references to similar discussions:
https://forum.bigfix.com/t/is-laptop/1706

… seems like MS says we need to find the Active Device w. HardwareID of “*PNP0C0A” to be able to identify an external battery:

ACPI Spec, Batteries and PowerSupply

This is what we should be looking for instad of the string “Microsoft ACPI-Compliant Control Method Battery”… and it is localization-proof…

( hardware ids of it ) of active devices

Will list all the HW ID’s, but i cant seem to get this to work:

( hardware id of it ) of active devices whose ( hardware id of it as lowercase ends with “PNP0C0A” as lowercase)

You don’t need to use Model from Win32_ComputerSystem, the same info can be found using the SMBIOS inspector, which also works on Linux and is faster.

http://bigfix.me/analysis/details/2994751

You don’t need to micromanage the setting of:

_BESClient_DeviceTypeOverride

Just come up with the relevance that works for a particular set of systems, then have a policy action that sets that setting using the relevance if it is not already set.

You could also run arbitrary code to make the determination, then set the Override. You could even have it be smart enough to only set the override if it disagrees with the IBM relevance.

! you are SO right… makes perfect sense, thanks.

1 Like

The fixlet/task to manage the override setting could have very limited scope so that it would only affect a very particular class of machines by using relevance to only be relevant on that type of machine, then have further relevance that detects the specific edge case of improper devicetype for that specific kind of machine. This makes it much easier to actually determine the override because you don’t need to create a single set of relevance that will work properly for ALL computers, it just needs to detect the specific edge case and address it.


Example:

Relevance 1:

windows of operating system

Relevance 2:

/* Windows 8 or later */ version of operating system >= "6.2"

Relevance 3:

(Whatever_is_needed_to_detect_DesktopUPS_Misidentification_as_Laptop)

And I do plan on fixing it. The main issue is its fairly complex to figure out all the subtleties in relevance (though of course possible) but much easier in code, so there is already a check in there for an inspector that works on Mobile devices but not desktops/laptops yet so at some point in the future we will be fixing it through that inspector.

2 Likes

How about using SMBIOS analysis instead. It’s hardcoded in the BIOS and most OS’s support and you get the benefit of breaking out your various hardware into various chassis types. . .

See here:
http://bigfix.me/analysis/details/2994751

SMBIOS/WMI etc inspectors are there to help yes, but be aware they can be memory intensive sometimes and we are at the whim of the OS/BIOS vendor how well these work. We try to come up with better ways to get you out of having to use those if its something used a lot

Does anybody know where are we at with this? I was hoping this was changed in 9.2.3

1 Like

I am getting more and more wrong device (and Computer) type results. PC’s that are laptops are being reported in as “Workstation”. When I look at the property “Computer Type” and “Device Type” I see the following relevancy:

(if ((exists active devices whose (class of it as lowercase = “battery” AND service key value name of it as lowercase = “compbatt”) AND (not exists active devices whose (service key value name of it as lowercase = “hidbatt”)))) then “Laptop” else “Workstation”))

It seems to report back FALSE on the …AND service key value name of it as lowercase = “compbatt” part…

Is this needed?

I think this is a version I made some improvements to long ago here: https://bigfix.me/relevance/details/2996922

Related: https://bigfix.me/analysis/details/2994751


There are definitely some refinements needed for this and the Physical vs Virtual property.

See here: Best way to determine physical vs virtual

It takes a lot of effort to get all the different potentially useful raw data and test that against a large enough set of different models.