Use Group Policy to Configure Windows Firewall to allow WMI

Using Group Policy to enable WMI (Windows Management Instrumentation) remote requests through the Windows Firewall

It is always a good idea to enable the Windows firewall under the domain profile. Enabling the firewall can prevent needed functionality as well.  For example, in some scenarios it may be required to be able to interact with client workstations or servers via WMI (which would be a type of unsolicited DCOM request on port 135).  Windows firewall will block this functionality unless you explicitly allow it.  To allow WMI remote requests through the windows firewall using Group Policy,  the “Allow Remote Administration Exception” policy needs to be enabled in the group policy object being applied to the workstations and / or servers requiring this access in the environment.  In order to set this, open up Group Policy Manager, and browse to the following location: Computer Configuration\Administrative Template\Network\Network Connections\Windows Firewall\Domain Profile(if setting this for the domain profile).  The same policy can be found in the “Standard Profile” as well.

Once you enable “Allow Remote Administration Exception” (and the computer objects refresh their policies usually 4 hours), WMI traffic should be allowed.

If you are impatient like me, sometimes it is best to just issue a command from the commmand line and be done.  The following are examples of commands that can be used to enable the same functionality as above.

Allow WMI through the Windows Firewall from the command line

 

If a connect attempt using wbemtest.exe fails – follow these steps to allow the requests through the firewall.

From the local machine command line, if the platform is Windows XP / Server 2003 (Below are three commands each providing different options)

 c:\> netsh firewall set service remoteadmin enable
 c:\> netsh firewall set service remoteadmin enable subnet
 c:\> netsh firewall set service remoteadmin enable custom 192.168.1.1,LocalSubnet

Windows7 / Server 2008 (Two commands below provide 2 ways to set the firewall to allow WMI)

 c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

You should see something like the following if successful.

Updated X rule(s) (where X is the number of rules updated)
Ok.

  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

Again, you will see something like the following if successful.

Updated X rule(s).
Ok.

This should be all that is required to allow WMI remote requests through the Windows Firewall.  The name of the Group Policy Object setting prevented me from getting this to work for quite a while.

Group Policy Filtering using WMI

Purpose

The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied.  WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly.  Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure.  While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator.  With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually.  So WMI filtering can reduce management overhead and prevent errors in policy application.

A couple of things to note when designing Group Policy using WMI filters:

  • The WMI query syntax is similar to an SQL query
  • Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
  • The more filters are used and the more complex the queries, the greater the length of the logon time
  • Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled.  Every configuration that is processed will add time to the logon process even if it is not being used

Process

By default no WMI filters exist in Active Directory.  The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.

To create a new filter, right click the WMI Filters container and select “new” from the list.

This will open the WMI filter dialog window.  (shown below)

Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)

This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed).  It should be defaulted to root\CIMv2.  It will also have a big box to type the query you want to run in.  This is where you put the following:

select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"

When you click “OK” on the WMI dialog window you will see the following:

Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery.  Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times.  Click the “Save” button to save your new filter.

If everything worked out, you will now see something similar to the following:


Where a new filter will be listed under the WMI Filters container.  The last step before testing is associating the filter with the GPO.  To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window.  Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).

Troubleshooting

There really isn’t too much that can go wrong with these.  A couple of things that should be verified are the following:

  • Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
  • Make sure that the group policy is applied to the correct OU and that it is enabled
  • Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
  • Run the following command from a command prompt to verify that the GPO is applied as expected
gpresult /r

This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.