none
Device does not return correct Win32_ComputerSystem PCSystemType property in WinPE OSD RRS feed

  • Question

  • I have been using a vbscript to name our computers during OSD for the past couple years. I'm trying to modify it now to take some user error out of the process - currently it prompts the user to enter PC or LT and then the company's asset tag - some users can't get the PC or LT right and thus negate our GPOs for laptops and PCs after the computer is imaged.

    I have modified the script to query Win32_ComputerSystem and get the PCSystemType property and prefix the asset tag entered by the user with PC or LT based on the property result. It appeared to be working fine until I came across a particular laptop model - a Toshiba Tecra R950. When the laptop finishes imaging, a WMI query for PCSystemType returns a "2" for Mobile. However, when I boot up on our SCCM WinPE disk to begin the imaging process and query for PCSystemType it returns a "1" for Desktop and subsequently gets named as a PC by my script.

    Does WMI get this information from the BIOS? Is there a way I can modify it so it gives the correct PCSystemType during WinPE boot?

    • Changed type Yog Li Tuesday, December 25, 2012 10:33 AM
    Thursday, December 6, 2012 3:43 PM

Answers

  • Toshiba...  well, there's your problem.  :-)  I have had a lot of problems with their inconsistencies for BIOS settings and hardware data.  WMI get the information supplied by the vendor for those classes so your info is only as good as what they give you.  I don't think Toshiba provides any way have changing this information.

     

    However, with the PCSystemType property, I see a lot of inconsistency with many manufacturers and a lot of people don't rely on this property to solve the 'desktop or laptop problem'.

     

    The most accurate way to determine the form factor of the computer is to leverage the Win32_SystemEnclosure ChassisTypes array, but this can get complicated since what you consider a 'laptop' might be one of several things depending on what the manufacturer set (there might be a couple ChassisTypes that you would want as a LT).  Luckily, there is already a script that shows you everything you would need to leverage this method here:

    http://blogs.technet.com/b/heyscriptingguy/archive/2004/09/21/how-can-i-determine-if-a-computer-is-a-laptop-or-a-desktop-machine.aspx

     

    But, I think the simplest way to do this is simply look at the memory type - if it has SODIMM's, it is going to be a laptop/tablet and everything else is a desktop.

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/ec760cf4-891a-412c-8886-f4c2528c325e/

    If you want a desktop go for:
    Select * from Win32_PhysicalMemory where FormFactor != 12

    If you want a laptop go for:
    Select * from Win32_PhysicalMemory where FormFactor = 12

     

    A lot of people check to see if there is a battery present, but many laptops allow you to remove the battery and run from the power cord or dock, and that can lead to them reporting no battery.

    Select * from Win32_Battery

    Or, you could keep going with the PCSystemType property in general and just hard-code an exception in your script for your Tecra's model name comes up in the Win32_ComputerSystem's Model property.

     

    I hope that helps!

     

    Nash


    Nash Pherson, Senior Systems Consultant
    http://www.nowmicro.com - http://myitforum.com/myitforumwp/author/npherson
    <-- If this post was helpful, please click "Vote as Helpful".


    • Edited by NPherson Thursday, December 6, 2012 4:12 PM
    • Marked as answer by Yog Li Tuesday, December 25, 2012 10:33 AM
    Thursday, December 6, 2012 4:09 PM

All replies

  • Toshiba...  well, there's your problem.  :-)  I have had a lot of problems with their inconsistencies for BIOS settings and hardware data.  WMI get the information supplied by the vendor for those classes so your info is only as good as what they give you.  I don't think Toshiba provides any way have changing this information.

     

    However, with the PCSystemType property, I see a lot of inconsistency with many manufacturers and a lot of people don't rely on this property to solve the 'desktop or laptop problem'.

     

    The most accurate way to determine the form factor of the computer is to leverage the Win32_SystemEnclosure ChassisTypes array, but this can get complicated since what you consider a 'laptop' might be one of several things depending on what the manufacturer set (there might be a couple ChassisTypes that you would want as a LT).  Luckily, there is already a script that shows you everything you would need to leverage this method here:

    http://blogs.technet.com/b/heyscriptingguy/archive/2004/09/21/how-can-i-determine-if-a-computer-is-a-laptop-or-a-desktop-machine.aspx

     

    But, I think the simplest way to do this is simply look at the memory type - if it has SODIMM's, it is going to be a laptop/tablet and everything else is a desktop.

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/ec760cf4-891a-412c-8886-f4c2528c325e/

    If you want a desktop go for:
    Select * from Win32_PhysicalMemory where FormFactor != 12

    If you want a laptop go for:
    Select * from Win32_PhysicalMemory where FormFactor = 12

     

    A lot of people check to see if there is a battery present, but many laptops allow you to remove the battery and run from the power cord or dock, and that can lead to them reporting no battery.

    Select * from Win32_Battery

    Or, you could keep going with the PCSystemType property in general and just hard-code an exception in your script for your Tecra's model name comes up in the Win32_ComputerSystem's Model property.

     

    I hope that helps!

     

    Nash


    Nash Pherson, Senior Systems Consultant
    http://www.nowmicro.com - http://myitforum.com/myitforumwp/author/npherson
    <-- If this post was helpful, please click "Vote as Helpful".


    • Edited by NPherson Thursday, December 6, 2012 4:12 PM
    • Marked as answer by Yog Li Tuesday, December 25, 2012 10:33 AM
    Thursday, December 6, 2012 4:09 PM
  • Thanks, Nash. I had originally gone the system enclosure route but moved to PCSystemType because I thought it would be more consistent. I was getting unknown on a couple of our models when using system enclosure. I had also seen the script you suggested and thought of using it, but wanted to see if the PCSystemType would work. I hadn't really thought about checking the memory and think you're on to something there, so I'll check out our models and give it a shot. My final move will be to get the model number and just code each model into the script, but really want something more dynamic that won't have me manipulating the script every time we get new hardware.

    On the WMI note, do you know why the Toshiba would show a "2" for PCSystemType after Windows 7 is installed, but show the "1" at WinPE? Does it pull the data from a different area depending on the OS? I'm just trying to understand it a little better.

    Thanks again for the suggestion!

    Thursday, December 6, 2012 4:24 PM
  • I'm just throwing out a wild guess, but it could be that one of the drivers changes what is being reported by the hardware.


    Nash Pherson, Senior Systems Consultant - http://www.nowmicro.com - http://myitforum.com/myitforumwp/author/npherson <-- If this post was helpful, please click "Vote as Helpful".

    Thursday, December 6, 2012 4:27 PM
  • No longer can you rely on testing for SODIMMs as an indication of whether a machine is a Desktop or Laptop. Most of the All-In-One machine, and more of the Small Form Factor desktops have used SODIMMs for years now.

    The Battery is not useful either, as we have seen some models of desktops (such as the Lenovo ThinkCenter M72e) have a small battery internally also.

    If PCSystemType is not working correctly, then I would suggest either using the Win32_SystemEnclosure ChassisType property as suggested above, or if you have a fixed set of machines models that you are supporting, then you can use blanket model rules (such as Model like '%Latitude%' for Dell laptops etc) rather than relying on the ChassisType.

    Monday, December 17, 2012 10:51 PM
  • Wierd...  Thanks for posting that, oWretch.  It must be that Lenovo is inconsistent with the M72e, because the memory method is working for mine.  Even the current specs on their website say this should be straight SDRAM and not SODIMMS.

      

    I'm also very curious about what desktop models you are seeing where the internal battery reports back under SMS_G_System_BATTERY.  I've truthed out both these methods in at least a dozen large SCCM (HP, Dell, Lenovo) environments and never seen a desktop hardware model show up in SMS_G_System_BATTERY even if it has a UPS.

     

    I hope to see more info soon, especially since lots of people use the SODIMM method for Group Policy WMI filters which can't use the chassis type array.

     
    Thanks,

     

    Nash


    Nash Pherson, Senior Systems Consultant - http://www.nowmicro.com - http://myitforum.com/myitforumwp/author/npherson <-- If this post was helpful, please click "Vote as Helpful".

    Tuesday, December 18, 2012 12:27 AM
  • Hello,

    I know this topic has been opened a long time ago, but if you are looking for the right solution (which is the PcSystemType return the correct value) and you do not know where he pulls this information, I know and that's why I'm answering this topic .
    The original value comes from the ACPI table called "FACP" and field "PM Profile".
    In the original document (http://uefi.org/sites/default/files/resources/ACPI_6_1.pdf) on page 167 he says. "This field is in set by the OEM to convey the preferred power management profile to OSPM OSPM can use this field to set default power management policy parameters During OS installation. "
    So to fix this, you need to ask for your BIOS vendor to change the value in the ACPI

    I hope this helps others who also sought this information.
    Friday, August 19, 2016 10:01 PM
  • Hello,

    I know this topic has been opened a long time ago, but if you are looking for the right solution (which is the PcSystemType return the correct value) and you do not know where he pulls this information, I know and that's why I'm answering this topic .
    The original value comes from the ACPI table called "FACP" and field "PM Profile".
    In the original document (http://uefi.org/sites/default/files/resources/ACPI_6_1.pdf) on page 167 he says. "This field is in set by the OEM to convey the preferred power management profile to OSPM OSPM can use this field to set default power management policy parameters During OS installation. "
    So to fix this, you need to ask for your BIOS vendor to change the value in the ACPI

    I hope this helps others who also sought this information.
    Friday, August 19, 2016 10:01 PM