WMI Filtering in Group Policy

Item level targeting is great and all, it works well for granular targeting. But with Item Level Targeting you are limited to only Active Directory components.

WMI or Windows Management Instrumentation consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification.

What if I told you you could set up policies that that allow you to target specific users, specific user names, specific hardware, and specific software. Even specific hardware types. You could deploy hardware specific drivers on your domain using WMI flitering.

It’s actually pretty slick, and far superior to anything that SNMP can offer. It is a very powerful tool set for a Sys Aadmin. The level of control for WMI filtering is absolutely amazing and robust. But is it secure? Well that depends, it can be, if you follow best practices there is no reason it shouldn’t be.

WMI filters are similar to SQL queries, for example…

select Version, ProductType from Win32_OperatingSystem where
 ((Version like "10%") and (ProductType = 1))

The above version 10 followed by the wildcard character will select Windows 10 and Server 2016 operating system versions. ProductType = 1 means the desktop OS version, where as type of 3 would mean the server OS version. Finally ProductType = 2 means that the machine is a Domain Controller.

select Version, ProductType from Win32_OperatingSystem where
 ((Version like "6.1%") and (ProductType = 1))

The above is for Windows 7.

select Version, ProductType from Win32_OperatingSystem where
 ((Version like "6.3%") and (ProductType = 3))

Finally the last one is Server 2012 R2.

Note that the name space that this is available in, is root\CIMv2.

If you want to find and query WMI you can use the official tool available from Microsoft, it’s called The WMI Code Creator tool and it’s available here. If the link is dead just search for it. An alternative to this is the NirSoft SimpleWMIView available here, and Wmi Explorer available here.

WMI Code Creator looks something like the following. It allows you to browse all the WMI possibilities and search for property values of WMI classes. For obvious reasons you will need the .NET framework installed on your machine.

 

Creating a WMI Filter is simple. Open up your Group Policy Management application, expand your domain and at the bottom you should have a folder named WMI Filters. In this folder you can also see a collection of WMI Filters and which policies they are applied to.

Right click this folder and select New…

Give your Filter a name and Description, then click Add.

Finish by clicking OK and Save. You have now created a WMI Filter for Server 2016 all versions.

Now you need to apply the filter to a policy. Locate a policy in your Manager, and in the right pane on the bottom under WMI Filtering now you can select the filter you just created.

That’s pretty much it, you can play around with the WMI Code Creator and see that you can do some very granular filtering with this. You can create filters based on OS, CPU, Disk drives anything that you can think of. This is a very powerful tool and if you’re familiar with SQL queries you should have no trouble coming up with some complex filters.

Specific Host Name:

root\CIMV2 – Win32_ComputerSystem – DNSHostName = ‘YourHostname’

 

As a side note if you are a C# .NET developer you can also benefit from WMI using the System.Management namespaces in Visual Studio. You will need to add a reference to it in your Visual Studio project. This allows you to query Microsoft Operating System hardware and retrieve statistics from said machine.

Sample C# Code:

 ManagementObjectSearcher processor = 
 new ManagementObjectSearcher("root\\CIMV2", 
 "SELECT * FROM Win32_PerfFormattedData_Counters_ProcessorInformation");
 foreach(ManagementObject query in processor.Get())
 {
 coreValues.Add((string)query["PercentProcessorTime"]);
 }
Advertisements

Deploying a WSUS environment with GPO

WSUS or Windows Server Update Services is used on a local network to approve or reject Windows updates and security fixes. The benefits of this system of delivering updates is that it allows you as much or as little control over updates as you want. It’s all about choice. So if you do not want the Windows 10 OS update rolling out to your Windows 7 desktops, you have the ability to prevent that.   

For Server 2012 R2 it’s quite easy to install WSUS. Start up the Server Manager, click Add roles and features, and under Server Roles and Windows Server Update Services select WID Database and WSUS Services. Install the WSUS server role.setup1

setup2

Once installed,start up WSUS and you should be greeted by the WSUS Server Configuration Wizard. If that is not the case you can start it manually from the WSUS Options.

There are a few things you should note before you start.setup3

Join the improvement program if you wish. I generally opt out.

Choose the upstream server. If this is your only WSUS server on the network you will synchronize your updates from Microsoft. Otherwise you can opt for another WSUS server on your network.

Set a proxy server if you need to.

Then you will connect to the upstream server by clicking Start Connecting button. This process can take a while and it can actually fail on your first try. Be patient, grab a coffee or something.setup4

Choose the language that you want all your updates in.

Choose which OS or Microsoft Software you want to receive updates for.

Pick which types of updates you want. Generally I pick critical, definition, and security updates.setup7

Configure the Sync Schedule. This sets the time at which WSUS checks for new updates and pulls them down from Microsoft. I generally set this for after business hours.setup8

You can now start the initial sync of Windows Updates for the products you selected, go ahead and grab a long lunch, this can take a while.

Now you can set a couple of other options in the WSUS application. I like to set the Automatic Approvals. This way I’m not approving hundreds of updates every week. I set the Critical and Security updates for WIndows 7 desktops to automatically approve. You can also set it up for a specific group of computers. You can set this group up either manually or via Group Policy. I will cover the group policy method later in the post.setup9

Next go to Computers in WSUS options and select Use Group Policy or registry settings on computers. This option allows you to use group policy to set the computer group membership. This is the preferred method. Close it, the next time the sync runs it should pull all the updates down. Please note that generally during initial setup, when I ran the manual sync it would more often than not fail. I had to wait for WSUS to pull the updates automatically on it’s scheduled evening run.

Now you will have to create two Group Policy Objects. One of the GPOs will be used to set the local update server and other Windows Update options. The other GPO will be used to log users off prior to the updates being applied on the computers. The reason I do this is that the computer will not restart after the updates are pushed if there are any users logged into the computer. The restart is a necessary part of the update.

Here are the things you want to consider when creating these GPOs; when will you be applying these updates, what time of day, which day of the week? These are all questions you should be asking yourself. For instance on my network I schedule my updates for every Wednesday at 10 PM or 22:00. On that same Wednesday evening at 9:30 PM all users are logged off every machine on the network. You don’t want to interfere with your employees but you also don’t want the computer to break from a bad patch or update on a Friday morning. You want to avoid spending the entire Friday and parts of the weekend fixing broken software.

Let’s create the Windows Update policy first:

Open up the Policy Manager either on the server or via Remote Administration Tools.

Create a new policy and name it something like WSUS_Desktops. This will be the desktop update policy and will reside in the OU where all the Network computers are.

Link the new policy to the appropriate OU, it is a good practice to test a policy prior to rolling it out, so maybe first link the GPU to a test OU, or set Item Level Targeting for the time being. This is how I do it on my network.

In the New GPO navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, and Windows Update.GPO1

Open up Windows Update to view the policies in there.GPO2

I only care about 5 of those policies. You can get away with using as few as 2 to push Windows Updates via WSUS using a GPO.

Configure Automatic Updates, this policy setting sets up how the updates are downloaded and how they are scheduled to install. I use option 4 – Auto download and schedule the install. I schedule the install time for every Wednesday at 22:00 or 10pm. Enable it and set the options accordingly for your environment.

Specify intranet Microsoft update service location, this policy setting points the computers to the server where you installed the WSUS application. Please input the http address of the WSUS server and port, for example http://server-name:8530. You don’t need to use a FQDN. If you need to find the port number for your WSUS instance remote into the server where WSUS resides, open IIS Manager, and select Sites, in the right pane you will see all the running websites and which port they are on.GPO3

Enable the policy and input the address in the two fields under the options pane, same address for both the intranet update service and the statistics server.

Automatic Updates detection frequency, this sets the interval at which the desktop computers check back with the WSUS server to see if there are any new windows updates. Default is 22 hours, this setting is optional.

Turn off the upgrade to the latest version of Windows through Windows Update, this will prevent the dreaded Windows 10 update from appearing on your Windows desktop. This is optional but a wise choice if you choose to enable it.

Enable client-side targeting, this policy setting has only one purpose, it is to set the target group in WSUS. Whatever you the group name, this is what the computers that apply this group policy will be sorted under in WSUS. Do not forget to change the Automatic Approvals in WSUS to this group and make sure all the auto approvals are pointing to the right computer group name. The policy will not auto generate the group in WUSUS, you need to manually create it. Once you create it the computers will be auto added to the group.

One thing to consider is that you might want to change the Security Filtering for the GPO. I changed mine to Domain Computers and removed Authenticated Users, since this policy only targets the machines and not the users this made sense. Once the policy is in place for few minutes, you can run the gpupdate command in command line on your test desktop to attempt and update the group policies on said computer.

Then you can check to see which update server the computer is pointing to by running the following command with elevated privileges on the test desktop…

REG QUERY “HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate”

This will show you the WUServer property, which is the Windows Update server address.

If this value or property is not present then then the group policy has not been applied yet, you might need to reboot. Alternatively you can try to manually register the computer with the server using the following command, wuauclt /detectnow.

Once you have that working, now you can create a group policy to log users off before the updates roll out each week. This is necessary as the computers might not reboot if users are still logged on to the desktops during the update process. Users need to log off so that the policy can reboot the PCs and roll out subsequent Windows Updates.

Create a new policy and name it something along the lines of Users Log Off. Link this GPO to the appropriate OU, one where all the network users reside. Again you might want to test the policy first before deploying it to everyone in your Domain. Open the GPO to User Configuration, Preferences, Control Panel Settings, Scheduled Tasks.

Create a new task and call it something along the lines of “Log Off Notify”. This task will notify users 15 minutes prior to logging them off to have them save their work as not to lose it. The task should look similar to the following.

Note the Action for this task is Display a message the message reads “You will be logged off in 15 minutes. Please save and close all your work if you do not wish to lose it.“

In the same Group Policy create another task and call it something along the lines of “Windows Log Off”. This task will log the users off their computers prior to the Windows Updates being applied. It should look like the following.

Note that the Action for this task is Start a program and you are running a force log off command using cmd.exe and switches.

That is it! Run some tests on your test computer to see if the Tasks are being pushed to your workstation. Test the tasks, make sure they work. 

Use GPO to set user as a local administrator on a single computer.

This is a revision of a previous post I did. In this version there are fewer steps that need to be performed in the policy. The key here is Item Level targeting, it allows you to apply policies to specific targets in your Active Directory. In this case the target would be a specific computer.

Open up your group policy managment console. Via the run command if you’re on the server, gpmc.msc. I run my policy manager from a Win 7 desktop on the domain, for this you need to install and setup the Remote Server Administration Tools, and run them with Domain Admin credentials. Once you have this open navigate down through your forest and domain to the right organizational unit (ou) where your new admin policy will sit. Generally you want to apply this in the computer OU, as the policy will be affecting desktops on your domain.

Right click on the OU and select “Create a GPO in this domain, and Link it here…“. Give the new Group Policy Object a new name and click OK. Now right click the new GPO and select “Edit…“, this will bring up the GPO editor.

GPEDIT

Since this policy applies to a specific computer we will select the Computer Configuration, Preferences, Control Panel Settings, and Local Users and Groups. On the right pane of this option right click and select New, Local Group. In the properties of this for Action: select Update. Group name: will be Administrators (built-in), this is the local Administrators group on all PCs. Rename to: renames the Administrators group on the target PC. Description: is just a description you might want to put in here “Administrators for computer X”. Next click Add under the Members: pane. This will bring up the Local Group Member prompt. In the Name: field type in %DomainName%\userid , where the userid is a specific logon ID and in my case tuser or my domain Test User account. %DomainName% is a variable and in this case it is the domain that the GPO resides in. If you want to see all the available variables hit F3 in the Name: field.

Click OK on the Local Group Member prompt.

AdminAdd

Now click the Common tab in the New Local Group Properties window. Here is where we target which computer that this policy will be applied to. On the Common tab check off Item-level targeting and click the Targeting… button.

common

In the target editor on the top left select New Item and Computer Name. the NetBIOS computer name is should appear. In the pane below click the “” button, here is where you select the computer this policy will apply to. Type in a computer name and click Check Names, it should underline the computer name if found correctly.

computername

 

cpname

Click OK, OK, and OK. Congratulations you have successfully assigned a user to the local administrator group on a single computer on the domain.

GPOM

You can also rename this to reflect more closely what the Action does. Highlight it and press F2, then rename.

GPOM2

 

Go ahead, close the Group Policy Management Editor, you’re done.

NOTE: If you want to add a single user on the network as an Administrator on all the network computers your best bet for Item Level targeting is to create a Security Group and make all Domain computers members of this group. One you’ve done that use Item Level targeting and target this said group.

Application deployment! Group Policy vs Push Software.

In the last few months I have had the chance to play with a lot of group policies at work. Not only have I tightened the security for users and workstations, but I started rolling out applications over the network.

Initially when I started to ask around what the best method to push software over the network is, someone pointed me to PDQ deploy. Nice thing about PDQ is that it is completely free. Yes, the free version does not contain some of the features the paid version does, but one can still deploy applications over the network. I tried the software and quickly dismissed it because I wanted everything group policy. So set on my quest to learn Group Policy, in the end I now have a greater understanding of it and am a more competent IT system admin. I ran into so many walls and hurdles playing with the settings trying to push software, that now I have a greater understanding of the features it offers and the features it does not. 

Some of the limitations of deploying software via GPO are a bit annoying. First you need an MSI, if you do not have an MSI you can find MSI wrapper applications online such as the likes of MSI Wrapper or AppDeploy Repackager. These do not always work. You can also wrap applications in msiexec. Orca is a good application to edit MSI packages once you have created them. Creating these packages can be a painful process and I found that MSI Wrapper did a better job than AppDeploy. 

Then came Oracle database. I could not for the life of me wrap this installation in an MSI. At this point I had fixed the ailing Group Policies at work and I was creating software groups in AD to push applications to computers. For Oracle however, this is where I had to go back to PDQ Deploy. Two full days of work and I had created a respectable Oracle deployment, albeit one problem, this was an executable not an MSI. Manual silent installation worked, so I proceeded to add this package to PDQ and test it. Surely enough it was working and I was pushing Oracle database client installations over the network. This is where I made the switch from Group Policy to PDQ deploy.

Group Policy is a bit limited in scope. It can only push applications when the computer is rebooted and each package needs to be wrapped into an MSI. Another problem with this method is that when your software collection grows, your users log on times can increase. So there is no on demand installation, computer needs to be rebooted provided the policy on the computer refreshed, and package needs a special wrapper which may or may not work. Also a lot of applications I deal with I was not able to wrap in MSIs.

PDQ Deploy on the other hand, can push out software on demand and you can watch the progress as it is happening.

Image

You do not need an MSI package and you can run command line arguments, it also uses Active Directory to list computers on the network.

Image

If you purchase the basic or advanced subscription level PDQ already provides some pre packaged applications. Common application packages like Java and PDF reader are available. You can also add multiple steps to your deployment, so you could check for and remove a previous version of an application before deployment.

Image

 

You can schedule deployments as well. It’s very robust.

PDQ Inventory is worth a mention as well. It is the companion application to PDQ Deploy and in the paid version it allows you to remotely remove software from networked computers. Both very useful applications, to get the full benefit of these you need to purchase the licenses. Try them for free and if you like them purchase the license.

Use GPO to add a single admin user to only one computer on the domain.

UPDATE: This post has some great ideas, however if you’d like an easier way to accomplish this with Item-level targeting navigate to this new post.

This post I’m going to detour from the usual Home Theatre write up. I still have more Home Theatre to go through, however I though I would give this topic a little attention. So recently I embarked on locking down my companies computer systems and what better way to do it with than Group Policy. Well I ran into a little problem when I tried to assign a single user as a local administrator on a single domain computer, it seemed impossible to accomplish with Restricted Groups as they encompass the entire OU no one single computer.

I searched the dark recesses of the internet and I thought I had found a link on social.technet, but as it turned out this did not allow me to do all the work remotely and I had to add additional groups to the computers. Then further looking over what Alan Burchill wrote I concluded that with his implication of the policy local administrators would be able to add other network users as local administrators, this did not work for me. I want to rule with an Iron Fist!!!

Either way what Allan had set out for me in black and white was a very good start and it really helped . Some of the comments in the post also shone some light on the behaviour of the Policy. You can find Allan’s blog post in regards to this here: http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/.

What’s nice about this method is that it will also clean up your policy each time it gets updated or anyone logs on to the computers in the OU. So if anyone adds another admin user to the group they will be removed. Also if you have some old administrators on PCs that were added manually in the past and have since left this will remove them.

Well let’s get on with it then, shall we.

My environment consists of Server 2008 R2 and Windows 7 machines.

I run my policy editor on my local machine, however I recommend you run it off your server since you can run gpupdate /force from there as it propagates faster this way.

1. Start the policy editor  on your server by going to Start > Run > gpmc.msc

Create a new policy under the OU in which you have your domain computers.

12. Edit the policy and navigate to Local Users and Groups, Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups.

3. Right click in the right pane of the window and select New > Local Group, you will be prompted with a New Local Group Policy window.

4. The Action heading should be set to Update,  from the Group name drop down list select “Administrators (built-in)”, check off  “Delete all member users” and “Delete all member groups”. Only use these options on the first Order policy as these are the options used to clear any previously assigned users and groups to the Local Administrators group.

25. Next we will add a single member to this new Local Admin policy. Click Add and you will be prompted with Local Group Member window, in the Name: section type in “BuiltIn\Administrator” this adds the Administrator account present on all machines to the Administrators group. For Action: select Add to this group.

6. Your Local Group Properties window should look like the following image. If yours looks the same go ahead and click OK.

3

7. This will take you back to the Group Policy Management Editor and you will have one policy with Order 1. The order is the order in which these policies get applied in. Since we’ll be adding more policies you may want to rename this policy in the Editor to something more descriptive like “Built in Local Admin”, highlight the policy and press F2 to do so.

4

In Allan’s blog he groups  the assignment of the Built in Admin account and Domain Administrators group in one Local Group. What I have found to be the case is that if you have more than one member that is to be added to the Local Group and one of these members does not exists or the spelling is incorrect the Local Group policy will stop processing as soon as it encounters and error and refrain from processing any further Member assignments. As a good practice try and assign one member per Order.

8. Let’s create a new policy. This time we will add the Domain Admins group as Administrators to all the OU computers. Follow steps 3 & 4 again, with one exception, do not check off  “Delete all member users” and “Delete all member groups” leave these unchecked otherwise when this policy is processed it will remove the previous members from policy Order 1  (Built in Local Admin).

9. When adding the member as in step 5, click in the Name: field and hit F3. You will be prompted with a Select a Variable window, select “DomainName” and make sure Resolve Variable is checked off then proceed and click Select. This will populate the Name field in the Group Member window add “\Domain Admins” to this so you have “%DomainName%\Domain Admins” in the Name field and click OK.

5

Your new policy should look something like the following image. You may not have a Domain Admins group on your domain, and if that is the case substitute the name of the group to the one that matches up with your domain administrators group. Now you should have two groups, go ahead and rename the second one as well. I renamed mine to Domain Admins.

6

10. In my 3rd order policy, since by default all local Administrator accounts are disabled, I ended up adding a local user account named “User” to all computers in the OU. Right click and select New User. It’s very similar to creating a new user on the domain.

7

11. In my 4th order policy I assign the User account to the Administrators (built-in) group. The only difference between this step and step 9 is instead of using the %DomainName% variable I’m using the %ComputerName% variable. Also to note you don’t need to hit F3 to select the variable you can type the information in manually ie. “%ComputerName%\User”. It should look like the following image. Click ok and rename the policy.

8

12. Now this is where the magic happens and we create an individualized local admin policy for a single computer. Before we create the policy we need to rename the Administrator group on each computer to something unique, after pondering this for a while I came up with the following solution. Create a new Local Group policy. Action: Update, Group Name: Administrators (built-in), Rename to: %ComputerName%.ADMIN. Do not Add any members leave this portion blank and click OK. Rename the policy if you would like.

9

The key here is the %ComputerName%.ADMIN, each computer will rename the Administrators group locally to something unique to that computer in this case it will use it’s name. For example a computer named DMCL-00203 will rename the local admin group to DMCL-00203.ADMIN. As seen below.

13

Once you have this in place you are able to add individual local administrators by creating new Local Group policies with higher orders than the policy which renames the local admin group.

13. To add a local administrator to computer DMCL-00203 create a new Local Group policy, Action: Update, Group name: DMCL-00203.ADMIN add a member using %DomainName%\UserId, UserID being a valid domain account.

11

You can add more member accounts to this policy just know that if it errors out or the account is invalid there is a possibility that the policy will not be applied to the computer. That is it, now you should have 6 policies in place depending on how many computers need local admin users. The order of the policies are important, for example you can not assign a local user to the admin group in order 6 if the user account gets created in order 7. Keep this in mind when designing your policy.

12

IMPORTANT UPDATE: So it seems the Active Directory likes to show all the computer admin groups created with in the policy on one single computer (see below). However that does not mean that the users in these groups have admin access to all computers on the network, having tested this they only have access to the computer they are assigned to. This is purely aesthetic.

adminoooIn order to avoid this purely asthetic replication to other computers except the target machine use “Item-Level Targeting”, it is available under the common tab. So at the end of step 13. click the common tab, and check item level targeting and click the Targeting button. Then in the Targeting Editor select New Item and Computer Name, then Type in the computer name or look it up in the Domain using the … button.

14 15