Unfortunately, ”custom” doesn’t guarantee that it’s a deny ACE,  which means that you have to drill into it further using the Advanced button in the lower right of the delegation tab, to ensure that it is, indeed a Deny ACE. The effects of an unwanted or unknown Deny ACE on a GPO, perhaps set by someone who is no longer managing your GPOs long ago, is that it can prevent GPO from processing in ways that are not obvious (at least on the surface). Usually you spend hours trying to troubleshoot why a GPO setting isn’t working for a given computer or user, only to run an RSoP report and discover that the GPO appears in the “Denied GPOs” list as “Access Denied (Security Filtering)”. You look at the Delegation and Scope tabs again in GPMC, scratch your head and wonder what’s up!

Well, after spending enough time over the years with this issue, I wrote a little utility that helps shine a light on this problem once and for all. It’s called the GPO Deny Finder, and it’s job is simple. When it starts up, you can enter an AD domain name (or it finds your current domain). You press the “Submit” button and away it goes, trolling your domain GPOs for Deny ACEs. Once it find a GPO that has one, it adds it to the list. When it’s done, you can select a given GPO, and it will show you what Deny ACEs exist for that GPO, as seen below:

Finding GPO Deny ACEs with GPO Deny Finder from SDM Software & GPOGUY.COM

You can also export the list of GPOs and their Deny ACEs to CSV if you need to document them further. That’s all there is to the GPO Deny Finder. Simple but powerful! You can download the tool at our SDM Software Freeware Page or you’ll also find it in the GPOGUY.COM Free Tools Library. I’ve also recorded a quick video that you can watch to see how to use the tool.

Enjoy!

Darren

• Ability to now compare up to 4 GPOs or GPO backups, for comparing GPOs or backups against a baseline GPO
• Support for comparing GPO Exporter Snapshots, to quickly and easily find what settings have changed within a GPO environment
• Support for showing settings that are same as well as different
• Added support in the PowerShell GPO Compare cmdlet for up to 4 GPOs and/or backups
• Improved menu navigation and grid view makes comparing settings easier.
• Customizable Report titles for generating PDF or Excel-based comparison reports
• New Comparison Options feature lets you customize delimiters, GPO metadata, Domain Controllers used for reporting and custom ADMX template paths
• Ability to customize colors used to display differences

Check out more information in the video demo within this post, or, visit http://www.sdmsoftware.com/products/group-policy-compare/ to register for a trial!

Darren

2011 also marked an interesting change in the use of Group Policy. Increasingly our customers are looking at their Group Policy deployments, which in some cases have grown organically over the years, and are looking for ways to help streamline and consolidate those GPOs to improve Windows server and desktop security, as well as improve desktop performance. SDM Software continues to provide powerful, best-in-market tools and expertise to help with these streamlining and consolidation tasks and they’re only going to get better in the coming year.

For 2012, you can expect more changes from the larger Group Policy world, as well as in SDM Software’s product offerings. In 2012, we will likely see Microsoft ship Windows 8. And while the Group Policy changes coming in that new version are mostly incremental, we can expect that Group Policy will continue to play a key role in configuring and securing Windows desktops, servers and, with Windows 8, Windows tablet devices as well.

And despite the lack of big revolutionary changes for Group Policy in Windows 8, I  am personally excited about SDM Software in 2012. Shortly after the new year, we’ll be shipping a major update to our GPO Reporting Pak, that will add some cool new capabilities around GPO reporting, comparison, conflict analysis and consolidation as well as key features that our customers have been asking for. Shortly thereafter, you will see some reporting capabilities from us that will finally give IT Pros leveraging Group Policy far better insight into their Group Policy deployments than ever before. Beyond that, expect to see us give you more powerful tools for reporting, migrating and consolidating GPOs as well enhancements to our Group Policy Automation Engine–still the only way to automate changes to Group Policy settings, using PowerShell.

Finally, we have some changes afoot that I am really excited about. As many of you know, the “Cloud” is the latest buzzword to hit the IT world. And while I think much of it can be excused as hype, the promise of cloud-like technologies as a way of dynamically provisioning, configuring and scaling both private and public virtualized computing resources is something that all IT shops will benefit from eventually.

To that end, 2012 will see us deliver our first releases of some exciting technology around cloud-based management of resources.

So, with that, I will end with a brief but heartfelt thank you to our customers for finding value in our products and for helping to make 2011 so succcessful. And I look forward to working with you all to develop some truly exciting technologies in the years ahead! As always, if you have any input on our products or the services we provide, feel free to contact us and I will personally make sure you get a response.

Sincerely,

The key is that the query has to evaluate to either true or false when evaluated by the client system. This limits what you can do with WMI Filters, within the universe of all the things that are supported in WMI. For example, you cannot query for the presence of a particular registry value because of the way WMI exposes these, by default.  The query itself executes at the time that GP is processed by the client. This is an important point because some WMI queries can be expensive, from a processing perspective (check out our WMI Filter Test utility as a way of seeing how a proposed WMI filter will perform) and can elongate GP processing time, if you’re not careful with the query you choose.

Another point to note is that, unlike security group filtering, which is specific to per-computer or per-user settings (e.g. you need to use a user security group to filter per-user settings, etc.) a WMI filter that evaluates against “per-user” WMI criteria (e.g. who is logged into a system currently) can be used for per-computer settings or per-user settings. This is a subtle and sometimes confusing point, but important to remember.

Now let’s talk about how WMI Filters are stored and attached to GPOs.

 WMI Filter Structure and Linking

WMI Filters themselves are stored within AD.  Specifically, they are stored under the CN=SOM, CN=WMIPolicy,CN=System container within the domain naming context of a given domain, as shown in Figure 1 below

WMI Filter storage in AD

What you’ll notice in the image above, is a number of GUID-Named folders which have an object class of msWMI-Som. These are the actual WMI filters defined within the domain. The attributes on these objects contain the various aspects of the WMI filter, as shown in Figure 2 below:

Figure 2: Viewing the attributes on a WMI Filter

As you can see, the msWMI-Parm2 attribute holds the actual WQL query that was defined for this WMI filter, along with some other metadata, as well as the name and description of the filter. Once a WMI filter is defined, the next step is linking it to a GPO. A given GPO can have only one WMI filter linked to it at a time. This linking happens by modifying an attribute on the GPO object within AD. You might know, if you’ve followed previous postings of mine, that these objects exist under the CN=Policies, CN=System container within the domain naming context of a given AD domain and are of objectClass groupPolicyContainer. When you link a WMI filter to a GPO, you are actually modifying the gPCWQLFilter attribute on the GPC object in AD, as shown in Figure 3 below:

Figure 3: Viewing the attribute that stores a WMI Filter Link

So, now we know where WMI filters stored, and how they are linked to GPOs. Now let’s look at how you can automate management of WMI filters with PowerShell.

Automating WMI Filter Management with PowerShell

Let’s start off by figuring out what is available as far as PowerShell support of WMI Filters. Unfortunately, the GroupPolicy PowerShell module that Microsoft shipped in Win7/Server2008-R2 did not include any suppor for managing WMI filters. The good news is that there is some help. Our SDM Software freeware GPMC cmdlets (www.sdmsoftware.com/freeware) include 3 cmdlets that provide some PowerShell support, including:

Get-SDMWMIFilter, Add-SDMWMIFilterLink and Remove-SDMWMIFilterLink

Get-SDMWMIFilter retrieves information about a specific WMI filter (or all of them at once). Add- and Remove- SDMWMIFilterLink, as the name implies, lets you add or remove a particular WMI filter from a GPO.

The only thing that is currently not supported in the SDM cmdlets is the ability to create WMI filters using PowerShell. One reason for this is that the GPMC APIs actually don’t provide an interface for this task (a curious omission). But fortunately, there is some precedent for doing this and armed with the information above about how WMI filters are stored in AD, it is possible to script this as well. The following TechNet article does a pretty good job of providing a template for this:

http://gallery.technet.microsoft.com/scriptcenter/f1491111-9f5d-4c83-b436-537eca9e8d94

Armed with all this information, hopefully you have a better sense of how to take full advantage of WMI filters and what’s going on behind the scenes when you do!

Darren

The first line calls Compare-SDMGPO and compares a GPMC backup of a Baseline GPO  (indicated by the -BackupIDA and -LocationA parameters) to a live GPO called “Desktop Policy” that was created from the backup and we assign the results of the comparison to the variable called $diff. In the second line, we test to see if $diff is not equal to null (meaning that there are differences). If we find it has differences, we call Send-MailMessage to send an email to a distribution list and we put the  $diff object into the body of the email.

Darren

As a long-time IT pro as well as a software guy, I’ve been historically skeptical of new buzzwords and technology trends (I’m sure I’m not alone here). “Cloud” is the latest phenomenon to come out of the energetic minds of software marketing folks, but for once, I’m embracing the word, if not the concept!

Many of you are well down the road of virtualizing your data centers and server environments. I know companies that have gotten as high as 90% virtualized–and those are big companies. Of course, with every new technology trend that promises to solve important problems, there is generally a reluctance on the part of IT shops to change their processes to take full advantage of the technology. This is just natural, of course. People establish ways of doing things over years. Rapid technology changes, in and of themselves, typically don’t force change. It takes recognizing what the new technology can mean for you if you DO change, that helps drive that change. That brings me to private cloud. What is it? What does it mean for IT shops? Simply this — a better way of managing your virtualized server resources that forces those process changes. Here’s a common scenario that illustrates this concept.

How many of you, once making the move to virtualized servers, have yet to change your processes for how your provision and manage your server VMs? In other words, how many of still manage your virtual servers like your physical servers? Still have 2 week turn-arounds on requests for new servers that include manual reviews by server admins or capacity people, manual kickoffs of server-builds, etc. If you answered “yes I do” for any of those then you probably need a private cloud (or more specifically, your users need it). Not because it’s the latest buzzword, but because it helps you evolve your processes to catch up with the technology.

That being said, at a panel discussion at Cloud Expo, one analyst mentioned that poll of IT shops they conducted, showed that fully 70% of respondents had “no plans” around private cloud. Does that mean it has no value? No. I suspect a lot of that is mixed up in the natural challenges around IT–that folks don’t know what the cloud means (does it mean I have to put my servers at Amazon?), don’t have time to think about it and don’t have budget for it. Ok, I’ve talked around it long enough–what exactly is the private cloud? Here’s some of the characteristics of a private cloud that I’ve come to after having built one, and surveyed what vendors are talking about with respect to it. A private cloud is:

• A management layer on top of your virtualized environment that is agnostic to underlying hypervisor technology. That is, it can work across multiple hypervisors, in multiple geographic regions
• Provides Self-service provisioning and automation for your end users–no more server requests with manual intervention by server admins
• Charge-back or “Show-back” of virtualized resource usage, akin to what Amazon Web Services does
• Policies/automated rules for providing elastic capacity for server applications that require more resources based on real-time usage (e.g. automatically adding more front-end web servers, for example, if the applications starts to get busy).

There are a probably a few more things that could be thrown into there, but by and large, those are the big things that folks hope to get out of evolving from “a bunch of virtualized servers” to a private cloud.

Of course, the next logical step, as vendors would have you believe, is the “hybrid cloud”, which is essentially a private cloud that has the ability to burst workload out to a public cloud provider (e.g. Amazon, Rackspace, etc.) when application needs require it. While hybrid clouds are all the rage amongst vendors providing solutions in this space, I’m still not convinced that this is a slam dunk, given the complexities of doing such bursting of typical enterprise applications to a public provider. This was echo’d on that same panel discussion at Cloud Expo, where all of the participants were skeptical of the reality of hybrid clouds. But I suspect we will get there eventually, as this whole thing matures. Today, we are probably in year 2 or 3 of a 10 year cycle that has yet to reach even adolescence.

One final point I’ll make. Perhaps it was being in Silicon Valley (the home of the “we hate Windows” fan club) or perhaps its just the nature of a new industry, but it’s interesting to see how marginalized Windows is as a part of the cloud story. Many of vendors displaying their wares talk to you first about Linux support and various other open source technologies (not to mention that most of these solutions are built on Linux, Ruby, Java, Python, MySQL etc.) before getting to a discussion of Windows–that despite the fact that I would guess that most enterprises typically run anywhere from 30-75% of their infrastructures on Windows server. Is Windows being left behind by the cloud? Hard to say. Microsoft would certainly have you believe otherwise, with big investments in their Platform-as-a-Service (PaaS) solution — Azure — and their investment in some cloud-management capabilities in System Center 2012. But Amazon, not Azure, is the 800lb Gorilla in the public cloud space, and many of the solutions that provide private cloud management are Linux-centric and pretty dumb about managing virtualized Windows systems. I do see this market and these vendors moving past Microsoft at a great rate, and so it will be interesting to see if Windows 8 helps make Windows a more cloudy platform, or just perpetuates the current trend of technology rendering what is going on in Redmond as an afterthought. As a Windows guy, I’m hoping for the former rather than the latter!

What do you think? Are you doing “cloudy things” in your own shop and how is it helping you better manage your systems (and especially your Windows systems)?

Darren

My test scenario was as follows. I wanted to deliver some Restricted Groups policy to a test Win7 machine. This policy would simply add the “GPO Admins” AD global group to the local “Administrators” group on my test machines. I created two GPOs for this test. The first one, called RestrictedGroups-Test, delivered the restricted groups policy. It was linked to my test OU, which contained a Win7 and XP system. It also had a WMI Filter associated with it, with the following filter query:

Select * from Win32_Environment WHERE Name=’ILT1′ AND VariableValue=’FileWin7′

This filter tested for an environment variable on the target system called ILT1 and for it to have a value of “FileWin7″

I had 2nd GPO, also linked to the same test OU. This GPO contained a single setting– a GP Preferences per-computer Environment variable setting that delivered–you guessed it–and environment variable called ILT1, if it met the ILT filter attached to that setting, which is shown below:

This ILT filter shown above is testing that the OS is Windows 7 and that there is a particular file present on that system in a particular path. But frankly, it could have been any ILT that tested for a up to 26 different criteria supported by ILT. The point is that if the system that processes this GPO meets the ILT criteria, an environment variable called “ILT1″ will be created on the system with its value set to “FileWin7″. Once this environment variable is in place, then the RestrictedGroups-Test GPO, with it’s WMI filter looking for this environment variable, will pass once it applies and deliver the restricted groups settings. And, when it gets to my XP machine, it will simply fail to find that environment variable and will not apply.

And indeed, when I tested this, it worked as expected–the Win7 machine got the restricted groups policy and the XP machine did not. In your case, you might have to wait for a 2nd Group Policy update for the restricted groups policy to apply, because the first time through, the environment variable needs to created before the restricted groups policy can apply. However, in my testing, I linked the GPO with the ILT filter higher in precedence than the restricted groups GPO on the OU and it appeared that the ILT filter and environment variable processed first and then the restricted group policy was applied within the same cycle, so that was good!

So you might be asking at this point–why go to all this trouble to get ILT for “legacy” policy? Well, there are some things that ILT supports that are difficult to impossible to do with WMI filters. What I just did in this example scenario–testing for both OS and the presence of a particular file, can be challenging in WMI and, in the case of looking for a file, downright painful.

But this approach essentially proxies the ILT testing process into the environment variable, which is something that is easy to get at with WMI filters. You could imagine creating an “ILT GPO” that contains different named sets of test criteria that you’d like to use, and delivering different environment variables for each test criteria. And then, you can use those environment variables within your legacy GPOs to indirectly take advantage of ILT filtering!

Well, that’s today’s Epiphany Hack for Group Policy!

Would love to hear about folks that use this successfully! We’ll call it “gpoguy filtering”

Darren

http://social.technet.microsoft.com/wiki/contents/articles/4976.aspx

Enjoy!

Darren

Thanks!

Darren

Regardless of what we call it, Group Policy has two main jobs in life:

1. The first job is to help you configure Windows OS security. Those are things like user rights assignment, password policy and file system or registry permissions are squarely in the domain of configuring Windows security. These security items, once configured, cannot be “worked around” unless the user has sufficient permissions on the system (e.g. is a member of the local Administrators group or other privileged group)
2. The second job is to help configure and lock down applications. These “applications” range from things like the Windows Explorer process (i.e. remove the ability to launch cmd.exe or removing icons from the desktop) to Internet Explorer, to Microsoft Office, to 3rd party apps that “policy-enabled” themselves. This last point is key. The thing that makes these types of policy settings able to “lock down” the application, is that the application has been coded explicitly to look for the policy settings, and to configure and/or grey out that element of the application UI to prevent the user from changing it. It’s not “real” security in the strict sense, because it’s subject to the application itself obeying the policy. The key here is that it’s NOT the Windows security model that enforces the lockdown–it’s the application itself. And, what that means is that if I could find a way to get access to a locked down feature in a different way, the policy may or may not stop me. A good example of this is the fact that the policy to prevent me from launching cmd.exe does not prevent me absolutely from getting at a command prompt–it only prevents me from doing it through Explorer. This is usually good enough for most users but an intrepid coder with some time on their hands could work around this.

OK, so how does this all relate to “policies” vs. “preferences”? The bottom line is that the distinction between the two is mostly marketing, in my opinion. They needed a name to call the features that were included from the acquisition of the DesktopStandard PolicyMaker product and Preferences sounded good, because many of the things you can configure in Group Policy Preferences — the user is able to change. Take for example, drive mappings. I can define a GPP drive mapping for a given set of users, but there is nothing to stop the user from going into My Computer and removing that mapping. GPP can certainly be configured to re-apply the mapping when GP updates in the background, but there is nothing you can do to prevent the user from deleting the mapping, because Explorer was not explicitly coded to have that feature locked down when delivered by GPP.  On the other hand, there are plenty of per-Computer GPP settings (e.g. system environment variables, device restrictions, registry changes to HKLM) that a non-administrative user cannot work around by virtue of basic Windows security permissions.

So, as we can see, the distinctions are blurry and do roughly fall based on whether the setting we’re talking about is delivered per-computer, for which Windows security does not typically allow normal users to change, or per-user, which a user typically has access to modify, and whether the setting is being enforced by Windows security, or a particular application.

Here’s my bottom line. Regardless of whether you call it a policy or a preference, if it relies on Windows security to keep it enforced, then it won’t be worked around (unless the user is given privileged access to their system). If it relies on an application to keep the setting enforced, and Windows security allows the user to modify or work around the setting, then all bets are off. This holds true for both the official “policies” as well as GP “Preferences”.

Darren