Controlling your group policies with Wmi filters

The possibility to control group policies with wmi filers have been around for quite a while, but still I see companies doing weird stuff with logon script instead of using it. In fact most companies I am visiting don’t know how to use it, and therefor they don’t. And in many cases running group policies that are not intended for the computer can create serious problems.
Instead of using wmi filters and script you might of course create an OU design that will help you, but even then it will be cases with policies running on computers it should not have been applied to or not running on all computers its intended to. For example if somebody creates a new forest wide group policy adjusting the firewall rules, intended for all Windows client. You might not want that policy implemented on your server. Using a security group for filtering might prevent it from running on the servers but it might also cause all new clients to not run it, since they need to be put into the right security group. Selecting a wim filter that checks if the computer is running the right OS version or maybe just the right system (workstation, server or domain controller) are a great way to reduce the risk for implementing wrong group policies.
Creating new group policies are a process that needs to be done right. My way of doing it, are to always create a policy that is not linked to any thing. Next step would to be remove the “Authenticated Users” group from the Security Filtering and select the right wmi filter




Selecting what group you should user are always a question. Something you should know when taking that choice are:

· Authenticated Users = A group that includes all users whose identities were authenticated when they logged on. Computers are also part of this group. Cannot be changed!
· Doman Users = global group that includes all user accounts in a domain. When you create a user account in a domain, it is added to this group automatically. But the objects might have been removed!
· Domain computers = A global group that includes all computers that have joined the domain, excluding domain controllers. But the objects might have been removed!
· Domain Controllers = A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically. But the objects might have been removed!

Removing users or computers from the domain user/computer/Controllers groups can only be done if you select another primary group for the object first.

So in many/most cases you should use self-created groups instead of the default built in ones, especially the group Authenticated Users (the default selected one) should be used with caution since it includes both users and computers (included domain controllers).


When testing the group policy a good practice is to just select one computer/users instead of a group so you can see the affect it have before implementing it on all the users. Most of the time I also test it out on smaller groups in the beginning to be sure and increase the group size gradually. Remember to link the group policy to the right OU.

The Process of creating the filters

To create filters just start the “Group Policy Management” console, browse down to the “WMI Filters” under “Domains – ‘Your Domain Name’”.
Right click and select “New…” and the wizard starts

Type in a name and press the "Add" button
There are some basic filters you might want to create or at least know about.
Operating System related
·         32-bit Operating System
Select * from Win32_Processor where AddressWidth = '32'
·         64-bit Operating System
Select * from Win32_Processor where AddressWidth = '64'
·         Workstations / Clients
Select * from WIN32_OperatingSystem where ProductType=1
·         Domain Controllers
Select * from WIN32_OperatingSystem where ProductType=2
·         Servers
Select * from WIN32_OperatingSystem where ProductType=3
·         Windows XP
Select * from WIN32_OperatingSystem where Version='5.1.2600' and ProductType=1
·         Windows Vista
Select * from WIN32_OperatingSystem where Version='6.0.6002' and ProductType=1
·         Windows 7  
Select * from WIN32_OperatingSystem where Version='6.1.7600' and ProductType=1
·         Windows 7 Service Pack 1
SELECT * from WIN32_OperatingSystem WHERE Version = '6.1.7601' and ProductType=1
·         Windows 2003 Servers and domain controllers (because the “>1”)
Select * from WIN32_OperatingSystem where Version='5.2.3790' and ProductType>1
·         Windows 2003 domain controllers only
Select * from WIN32_OperatingSystem where Version='5.2.3790' and ProductType=2
·         Windows 2008
Select * from WIN32_OperatingSystem where Version='6.0.6002' and ProductType>1
·         Windows 2008 R2
Select * from WIN32_OperatingSystem where Version='6.1.7600' and ProductType>1

NOTE!
 You can use version numbering with the wildcard % to select all versions of a certain OS, but then you cannot use the = sign, instead use the LIKE parameter
Select * from WIN32_OperatingSystem where Version LIKE '6.1%' and ProductType=1
It’s also possible to use “Caption=” instead off “Version=”, then you can skip the “ProductType” parameter.
Select * FROM Win32_OperatingSystem WHERE Caption="Microsoft Windows XP Professional"
To include Service Pack level you can add “CSDVersion=”
Select * FROM Win32_OperatingSystem WHERE Caption="Microsoft Windows XP Professional" AND CSDVersion="Service Pack 2"
Hardware related
·         Specific computer model (in this case Lenovo W510)
Select * from Win32_ComputerSystem where model = '431929G'
·         Specific hardware manufacturer (in this case LENOVO)
Select * from WIN32_ComputerSystem where Manufacturer = 'LENOVO'
·         Installed Memory equal or more than 16 GB
Select * from WIN32_ComputerSystem where TotalPhysicalMemory >= 17108062208
Etc.
·         If Application are automatic started (In this case MSN Messenger)
SELECT * FROM Win32_StartupCommand WHERE Name = 'msnmsgr'
·         Monday
Select * from Win32_LocalTime where DayOfWeek = 1
·         Tuesday
Select * from Win32_LocalTime where DayOfWeek =  2
·         Wednesday
Select * from Win32_LocalTime where DayOfWeek = 3
·         Etc…
·         Week in month (In this case first week)
Select * from Win32_LocalTime where WeekInMonth = 1
So the possibilities are many, but you should at least include the basic OS and computer types to make sure you can prevent the most basic fails done with wrong applied group policies.
When you have created set of Wmi filters you can also export, copy or edit them. Exporting is a great feature, you don’t have to remember the Wmi code the next time you need to create them, just import them. The MOF file being created is a clear text file if you just want to look at the Wmi code without importing it.

Wmi Code Creator

Wmi Code Creator is a helpful tool when working with Wmi Codes, it’s free and available for download at www.microsoft.com/downloads

It’s important to use the Wmi Code Creator on a computer with the same operative system or hardware (depending on what query you are looking for) since it loads the namespaces and classes from the running computer
Also be aware that if you use hardware related queries the results will be given with different format depending on the hardware manufacturer. Example like the “Select * from Win32_ComputerSystem where model = “query who will give you a cryptic looking result on a Lenovo like “431929G” but HP will give a great string like “HP EliteBook 8540w”. So if you are unsure or the query doesn’t seem to work use Wmi Code Creator on the computer to see what the result of the query is.
Getting started with wmi filters is not hard, just begin with the essentials and expand with more complex queries when you see the need for them, and after a while you will realize you can’t live without them.

Popular posts from this blog

Installing Android on a Hyper-V virtual machine

Quick guide on how to run BgInfo background as Group Policy login

MDT: TimeZoneName and index number list