The first thing you’ll notice is that the Summary tab on RSoP is completely different, as shown here:

RSOP Summary Tab in Windows 8 GPMC

The Summary tab is a troubleshoot assistant that gives you clue as to where problems may lie during the last GP processing cycle on the targeted machine. In the case of the screenshot above, it shows any errors during computer or users processing. And, if you click on the errors link (I have 9 errors for Computer processing) it displays a window that contains all of the GP operational event log errors from that remote system related to this failure!

GP Related Error Events

For more benign errors, such as what link speed was detected and that the OU where my computer and user reside have the block inheritance flag set, they mark them in yellow and link out to MS KB articles related to that topic. This is far more useful for quick troubleshooting than the sometimes obscure “Component Status” information given in previous versions of RSoP.

If you click on the Details tab within Group Policy Results, you’ll notice that they’ve combined what used to be in the Summary tab in previous versions with the Settings tab–providing component status along with the actual settings that should have been delivered to user and computer. However, you will note some interesting additions, as shown below:

The New RSOP Component Status

Notably, they now include the time taken for each Client Side Extension to run. As you’ll notice in the figure above, they also provide more detailed information when either Core processing (the part of the GP Processing cycle that reads AD to determine which GPOs apply) or Client Side Extension (CSE) processing fails. If you click one of the “Last Process Time” entries, a useful dialog pops up with additional information about the processing cycle, including whether it was background or foreground, whether loopback was enabled on the computer, and which DC was used to process policy (see Figure below)!

Additional GP Processing Details

Great stuff and very similar to what we return in our own PowerShell-based Group Policy Health Cmdlet. Finally, if you click a “View Log” Link within one of the component status items, the filtered view of the GP Operational Log on that system related to that CSE or Core processing event will appear, showing you all events related to the success or failure of the component. Double-cool!

You might wonder if all this new goodness is available against downlevel versions of Windows. The answer is, “kinda” . For example, the Summary data that shows existing and possible problems works as expected on Win7 targets, for example. However, the individual CSE timings are not exposed in those downlevel OS versions because they simply aren’t logged before Windows 8. Not terrible but something to keep in mind.

You might also ask if GPResult.exe–the command line version of RSOP–includes these new features. Alas, it does not appear to. In testing I did with the version on Windows 8 Consumer Preview, GPResult seems to return the same data is always did. That’s too surprising since some of the data in the GPMC version is context-specific to a GUI. But still it would have been nice if some of the timings data would get returned through gpresult.exe. Since this is a beta, who knows how it may change before RTM.

Finally, you may also wonder if the PowerShell version of RSOP–Get-GPResultantSetOfPolicy– also supports these new data.  Interestingly enough–it does seem to support most of the new data presented in the GUI, including timings for each CSE or Core Processing, as well as the event details associated with the GP Processing event. The Summary screen information does not appear to be captured anywhere in the output of the cmdlet, which I expected, as it’s probably analyzed within the GUI rather than collected as part of RSoP data. Nevertheless the cmdlet does seem to have the important pieces wired in, which is good for those of us who are command-line junkies.

Overall, I think Microsoft made some good improvements to RSoP in Windows 8, and I hope you find them useful once you start deploying this version of the OS!

Darren

IE's Popup Blocker Configuration

This allow list is configurable via Group Policy, and is configurable in one of three ways–either through Administrative Templates, IE Maintenance Policy or GP Preferences. From an end-user functionality perspective, IE Maintenance and GP Preferences are nearly identical.  I summarize each of the behavior in the table below. The key thing to recognize is that if you manage the Popup Allow List using Administrative Templates, the user will not see the domains that you’ve added via the policy, but they will be able to add and remove their own. This is unlike the other two, which let the user add and remove both their own and the policy managed sites. Note that all of my testing was using IE9. Other versions of IE could behave differently (it would not surprise me!)

Of course, IE Maintenance comes with its own set of baggage, as some of you who have used it know. If it were me, I would stick to either Admin Templates or GP Preferences to configure the allow list, depending upon your needs.

Darren

Paul was talking about the recent revelation that the upcoming Windows-on-ARM (WoA), at least so far (it is still in Beta after all),  will not be joinable to AD, and of course, will not process Group Policy. This continues a trend that Microsoft has been following with respect to configuration management of Windows systems–blurring the lines of responsibility that each of the various configuration management solutions they provide serve.  Let’s take a look at all the ways that Microsoft provides configuration management today:

1. Group Policy: My favorite of course–Group Policy has been around since 2000 and requires AD to take full advantage of all it’s features. Group Policy handles everything from software deployment (albeit weakly) to security configuration, desktop lockdown, browser lockdown and drive/printer mapping, and that’s just the short list.
2. System Center Configuration Manager (SCCM): SCCM (nee SMS) has been around for a long time–since about 1994– and has always been the go-to tool for enterprise software distribution (i.e. deploying software to Windows devices). More recently SCCM continues to morph and blur the lines between it’s sweet spot and what Group Policy is good at. Of course, Group Policy is “in-the-box” and SCCM costs additional money, but with the recent release of SCCM 2012, the previous read-only, desired configuration management (DCM) feature now also has the ability to set (i.e. write) the kinds of settings that most shops manage with Group Policy.
3. Windows Intune: Is a cloud-hosted endpoint monitoring, software distribution and configuration management solution for small and medium-sized businesses, that also blurs the lines of responsibility in terms of what Group Policy is used for and what Intune does. The nice thing about Intune is that it’s not tied tightly into AD, and so can handle managing endpoints that aren’t necessarily under AD management (or aren’t on the corporate network, such as roaming PCs). Interestingly Intune uses a completely different mechanism for configuring Windows than does Group Policy.
4. As yet unspecified WoA Managment Infrastructure: We don’t know much about this yet, except what folks like Paul and Microsoft themselves have written. Will it be a self-hosted version of Intune? Add-on to SCCM? Something else? Suffice it to say that if you’re deploying WoA devices in the future, you may need something besides what you’re doing now (especially if Group Policy is your configuration management tool of choice now).

The bottom line here is that, depending upon your needs and your targets, you could have up to 4 different mechanisms for doing configuration management in Windows. Choice is good, right? Well, yes and no. The problem is that each of these solutions (at least the ones we know about) keeps it’s own idea of what desired state is. Each one describes configuration differently and each one keeps track of configuration state on endpoints differently. This means you have to make some very conscious choices about what Configuration Items (CIs) you will manage with each mechanism that you use in-house, or, restrict the mechanisms you use. Why?

Well, the worst case scenario is that you have multiple configuration systems managing the same CIs. I can envision a scenario where the group that is managing SCCM decides to implement a DCM baseline on all your Windows servers that enforces a security setting to a particular value that is in conflict to what you happen to be setting via Group Policy. And then each time GP refreshes, it undoes the DCM baseline value, which DCM then comes along and fixes, and so on.

The bottom line here is that over time, it is likely you will have multiple configuration management capabilities depending upon the segment of your Windows environment. As a result, you’ll need to think about “domains of configuration management” where a particular technology is only responsible for the CIs that it is good at managing and for the devices that it is best suited to manage.

Where is Windows Configuration Paradise?

Where I’d like to see all of this go, is that the underlying plumbing for describing, enforcing and reporting on configuration within Windows becomes the same, regardless of whether it’s SCCM, Intune, Group Policy or any other mechanism. Once you have that, then the management of conflicts can become inherent in the plumbing rather than the responsibility of the tooling (i.e. SCCM or Group Policy, etc.) and you can use the tooling that is best for your scenario. Each of the current mechanisms has strengths and weaknesses. Wouldn’t it be cool if it didn’t matter which tool we used and that we could mix and match or “trade up” over time without re-work? I think so. What do you think?

Darren

Today we’ll be showing more stuff, like an early version of our Group Policy Health Compliance Reporter! Should be fun.

Stop by if you’re at MMS and say hi!

Darren

import-module SDM-GPOHealth and you’ll be good to go!

And for more info on using the Health cmdlet, check out my previous posting on the topic.

Thanks and enjoy!

And just a reminder that if you’re at MMS 2012 in Las Vegas this coming week, don’t forget to visit us in Booth 129 on the exhibit floor.

Darren

“Show me all the Restricted Groups settings across all my GPOs”

“Filter just the settings across all my GPOs that contain a particular AD group name”

“Search for all occurences of the word ‘password’ in my GPOs”

But what we’ve added in 1.5 is a lot of exciting stuff, including the following:

• Filter export results and snapshot views to display only those settings that contain your keyword
• View a variety of pre-defined reports for precision reporting with the Report Portal. Reports include Unlinked GPOs, GPO by Policy Area, Duplicate/Conflicting Settings, Empty/Unlinked GPOs and more.
• Easily save and import Exporter Snapshots for an organized view into point-in-time exports
• Perform exports across multiple domains in a forest, allowing a full reporting of settings across multiple domains
• Export specific policy areas faster and more accurately

I’m most excited about the Report Portal, which provides a set of pre-defined reports that give you unprecedented visibility into your GP environment. We have reports that tell you where all the unlinked and empty GPOs are, and reports that show you which GPO implement which policy areas, but the two reports I’m most excited about are the Duplicate and Conflicting Settings reports (see an example below).

Group Policy Conflicting Settings Report

In the image above, the conflicting settings report analyzes all your GPOs in your domain and reports any settings that are in conflict and where they are linked. In environments with 100s or 1000s of settings, this is hugely beneficial because it gets you quickly to some actionable steps where you can start reducing those conflicts. The same holds true for the duplicate settings report, which shows settings that are set identically across multiple GPOs–a common occurence in larger environments that causes undue GP processing and, ultimately, slower desktop performance.

So, if GPO reporting, consolidation or, ultimately, optimization, are your goal, have a look at GPO Exporter 1.5–visit our website and click on the Trial link to give it a spin!

Thanks,

Darren

In addition, I’m going to be presenting a session (http://www.mms-2012.com/topic/details/SV-B315) at MMS on managing Group Policy with PowerShell on Thursday morning of that week. If you are still around, please stop by and check it out. I’ll be demo’ing not only what’s in the Microsoft Group Policy module and what’s changing in Windows 8, but also some of our free SDM Software and GPOGUY.COM Powershell cmdlets for additional GP functionality.

Thanks!

Darren

Mapping Drives with GP Preferences

GP Preferences also supports “Item-level targeting”–which is the ability to target individual settings, like drive mappings, using a variety of criteria, from group membership, to IP address range, to disk space availlable–in fact, up to 24 different criteria. And, GP Automation Engine (GPAE) supports all of them. Let’s look at how this works. The following script leverages the GPAE and PowerShell to map 4 drives to 4 different shares, each one permissioned to a different user group using GP Preferences Item-Level Targeting. To make it more interesting, I pass the drive letters, share names and group names to the script using a CSV file, as shown here, and the import-csv PowerShell cmdlet:

CSV File used as input to a drive mapping GPAE script

Now here’s the script that used to create the drive mappings–as shown in the PowerGUI script editor:

Script using GPAE and PowerShell to create GP Preferences Drive Mappings

The main work of this script is a function called MapDrives that uses the GPAE get-sdmgpobject cmdlet to create the new drive mapping and attach a security group-based item-level target to each mapping. Cool!

Just to show how easy it is to run this script, I recorded the attached video that let’s you watch the script running, and see the results in GPMC! Note that even though my video sample only includes one GPO and 4 drive mappings, I could just as easily populate 200 drive mappings across 50 GPOs if I wanted to, all within the same script.

Another scenario that the GPAE enables is the ability to update existing drive mappings. So for example, if a file server name is changing and I need to update 50 drive mappings with the new name, GPAE can handle that as well, simply by modifying the Location property on existing drive mappings. And of course, GPAE works across not only all the various GP Preferences areas, but also against “traditional” GP policy areas like Software Installation, Administrative Templates, Folder Redirection, Security policy, etc.

For more information and to get a evaluation of the GPAE, visit the product site at www.sdmsoftware.com/products.

Enjoy!

Darren

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