Finding Computers That Are Laptops

Determining which computers are laptops is useful in a variety of circumstances. For example, you might want to install the Advanced Client only on laptops. If all of your computers are already discovered and inventoried by SMS, you can create a collection for the laptops and then advertise the Advanced Client to the laptops. However, computer vendors do not use a standardized method to identify laptops. Consider the alternatives and use whichever methods are appropriate for the laptops in your organization.

To identify laptops, consider using the following hardware inventory properties:

• Win32_SystemEnclosure, ChassisTypes(1)=10. This property when set to the value of 10 is equivalent to "notebook." However, not all computers provide this property. This class is defined in the SMS_def.mof.

• Win32_Battery or Win32_PortableBattery. If any instances exist, then the computer is probably a laptop. However, uninterruptible power supplies sometimes are reported as batteries, so this might not be reliable if some of your computers have uninterruptible power supplies. This class is defined in the SMS_def.mof, but reporting is not enabled by default.

• Win32_PCMCIAController. If any instances exist, the computer is probably a laptop. This class is defined in the SMS_def.mof but reporting is not enabled by default.

• Win32_DriverVXD.Name = "pccard". If any instances exist, the computer is probably a laptop. However, this option works only on Microsoft Windows 98 computers. This class and property are enabled for reporting by default.

• Win32_ComputerSystem.Manufacturer. If you purchase your laptops from a different vendor than your desktop computer and server vendor, this value might reliably identify your laptops. This class and property are enabled for reporting by default.

• Win32_ComputerSystem.Model. You might need to check for a variety of different models to include all of your laptops. This class and property are enabled for reporting by default.

• Static record. You could define your own property in a MIF or MOF and set it when the computer is originally set up for use in the production environment.

• Power scheme. Laptops usually use the Portable/Laptop power scheme (number 1). This is a registry entry, so you can use the following MOF to collect power scheme data, which uses the WMI property registry provider:

  #pragma namespace("\\\\.\\root\\CIMv2")
  // Registry property provider
  instance of __Win32Provider as $PropProv
  {
      Name    ="RegPropProv" ;
      ClsID   = "{72967901-68EC-11d0-B729-00AA0062CBB7}";
      ImpersonationLevel = 1;
      PerUserInitialization = "FALSE";
  };
  instance of __PropertyProviderRegistration
  {
      Provider    =$PropProv;
      SupportsPut    =TRUE;
      SupportsGet    =TRUE;
  };
  [DYNPROPS]
  class Power_Mgmt
  {
      [key]
      string  index = "current";
      sint32 CurrentPowerPolicy;
  };
  [DYNPROPS]
  instance of Power_Mgmt
  {
      [PropertyContext("local|HKEY_CURRENT_USER\\Control Panel\\PowerCfg|CurrentPowerPolicy"),
      Dynamic, Provider("RegPropProv")]
      CurrentPowerPolicy;
  };
  

  Note

  • If you have only Legacy Clients you can include the previous MOF directly in the SMS_def.mof. In this scenario, remove the registry provider definition because it is already defined in SMS_def.mof.

In addition, the following MOF must be added to SMS_def.mof:

#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report     (TRUE),
  SMS_Group_Name ("Power Management"),
  SMS_Class_ID   ("MICROSOFT|POWER_MGMT|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentPowerPolicy;
};

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.