How would you handle the following scenarios?
- You have a Wireless Configuration and Offline Files GPO but only want laptops to see it.
- You have a BIOS update but only want a particular manufacturer to grab it.
- You have hardware (ex: SmartBoards) and want the software to automatically install when the device is connected.
In the past, I’ve tried to solve these issues with security groups, shadow groups, and careful OU placement. All were a pain to manage until I learned how to use WMI! In this three part series, we are going to cover WMI basics, using it with Group Policy, and integrating it with SCCM.
What is WMI and Why Should I Care?
Honestly, I can never remember what WMI stands for. I am sure that it is something like Windows’ Magical Interface but I could be wrong. In technical terms, it provides a standard method to query and store data. It gives an you a common way to extract hardware and software information! Ever wondered where inventory programs (like SCCM or Spiceworks) get their data? They are using WMI! Accessing this information is super easy and can save you a ton of time! But first, we need to briefly cover some terms.
WMI is organized into classes. Think of a class as an organized folder. The class Win32_BIOS will contain everything related to the BIOS. Win32_Processor stores the processor information. You can see available classes by typing wmic /? in a command prompt.
Each class contains members (objects). For example, the BIOS class contains a member named SerialNumber. We’ve made use of this before when we inventoried our serial numbers into Active Directory. Remember this: Classes Come Before Members.
Finally, you interact with members by using verbs. The two most common verbs that you will use are get and set. Let’s look at a few quick examples that shows how powerful WMI can be.
