Group Policy is a many-splendored thing. Like many other aspects of Active Directory Domain Services (AD DS), Group Policy has evolved over time, partly with respect to best practices that we recommend, tools and features from Microsoft, and third-party software and solutions.

After having so much fun with Microsoft GPOAccelerator, some of my students in a Group Policy class in the Global Knowledge virtual classroom asked where we could download this tool set we had used in class. There’s bad news and good news in this regard. First, the bad news – there is no longer a download (at least not that I could find) of the GPO Accelerator package from Microsoft.

The good news? Well, the GPO Accelerator functionality is available as part of the Microsoft Security Compliance Manager (MSCM). About a year ago, the GPOAccelerator was pulled into the MSCM, and last month (April 6, 2010), Microsoft published version 2.51 of the MSCM. This version can be downloaded at <http://www.microsoft.com/downloads/details.asp?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e&DisplayLang=en>. But to really understand what the GPO Accelerator is and why it fits into the MSCM, let’s take the story back a bit further.

Once upon a time, when Group Policy was young, in the beginnings of Active Directory with Windows 2000 Server, the operating system came with a few example security templates. Anyone wanting to establish robust security policies had to start either from scratch or nearly from scratch using these rudimentary templates. Over time, Microsoft provided additional guidance with respect to security policies and released offerings such as a security guide for Windows XP, and the Windows Server 2003 Security Guide (WSSG 2003). As Microsoft had welcomed and solicited input from many organizations in developing such security guides, some organizations such as the U.S. National Security Agency (www.nsa.gov) did not publish their own separate security guide from Windows Server 2003.

Meanwhile, the Group Policy Management Console (GPMC) offered new capabilities for importing example policies, another version of the WSSG for Server 2003 came out, and eventually Windows Server Vista and Windows Server 2008 released, as did updated security guides for these newer operating systems. The Windows Server 2008 Security Guide (WSSG 2008) and Windows Vista Security Guide, along with the Windows XP Security Baseline and WSSG 2003 were available as part of the solution pack called the GPO Accelerator. Now all of this functionality and more has been wrapped up into the MSCM.

So if you’re looking for the Windows XP, Server 2003, Vista, Server 2008, 7, or Server 2008 R2 security guides, look no further than the Microsoft Security Compliance Manager (MSCM). The old Threats and Countermeasures guide, and a newer IT Infrastructure Threat Modeling Guide are available separately for download.

While the Attribute Editor in Windows Server 2008’s Active Directory Users and Computers (ADUC) doesn’t solve all directory woes, it can certainly be more convenient than firing up LDP.exe, LDIFDE, ADSIedit.msc, or one of their friends every time you want to go beyond the attributes the typical Display Specifiers have bequeathed to us in the GUI.

Someone recently sent this question:
“Is there a way to keep the “Advanced Features” view always on?”

If you start a blank management console, add the ADUC snap-in, turn on Advanced Features view, and save the console, whenever you use *that* console file, Advanced Features will be on.

1. Launch a blank Microsoft Management Console: Start-> Run… mmc.exe
2. In the MMC menus, choose File->Add/Remove Snap-in… (or Ctrl+M)
3. Select “Active Directory Users and Computers” and hit the “Add >” button in the middle.
4. Hit OK to finish adding the snap-in.
5. Back in the console, select the Active Directory Users and Computers node under the “Console Root.”
6. Right-click on that ADUC node and choose “New Window from Here” in the menu.
7. In the MMC menus, choose  View->Advanced Features (this turns on the Attribute Editor, Security, Object, and other tabs as well as several other features in menus and makes other objects visible).
8. In the MMC menus, choose  File->Save (or Ctrl+S), specify a file name folder, file name, and hit the Save button.
9. In the MMC menus, choose  File->Options… and choose “User mode – limited access, single window,” then check the “Do not save changes to this console” checkbox, and finally hit OK.
10. In the MMC menus, choose “Save As…” and save under a different file name, and choose “Yes” when warned about the single window interface option.
11. In the MMC menus, choose File->Exit
12. Launch the second console you saved (in step 10) and use it – it should always have Advanced Features turned on.
13. If you need to make changes to other settings in the console, open the first console you saved (in step 8), adjust whatever other options you want, then repeat steps 9, 10, and 11 using a different file name in step 10 this time to distinguish the new settings.

I hope that helps.

p.s. Those instructions might not be perfect – I just typed them up on the fly… (while walking through it)
p.p.s. As far as a registry setting to affect all prefabricated consoles (e.g. dsa.msc), I haven’t found such a setting yet. But I’m examining a console file to see the difference in this setting in the actual .msc file. If anyone knows or finds any general solution, please let me know.

/cast bronze drake

That was the message I received from a person who was starting into a Group Policy lab exercise. Certainly, I wouldn’t think such strong magic would need be summoned to get through the lab, but it’s good to be prepared. Then again someone in class noted earlier in the week that I looked like Jim Morrison, so perhaps there was a lizard theme going on this week. Apparently the “bronze drake” command was sent by a rogue G19 keyboard.

Group Policy isn’t usually considered rocket science, or magical, yet there can indeed be much more going on under the hood than initially meets the eye. I sometimes think that I should be satisfied with explanations others have written up and just refer people to those great references. Somehow I end up going over the architecture again, and luckily the story is a bit different every time. Hopefully better.

In order to comfortably manage Group Policy without feeling the need to call in some heavy magic, let’s take a quick review (or survey if you’re new to Group Policy) of some of the major management tools and some “big picture” tips on what to expect from Group Policy.

Group Policy is one of the major features of Microsoft’s Windows Server-based Active Directory Domain Services (AD DS). If you have Active Directory domains based on Windows 2000 Server, Windows Server 2003, Server 2008, or Server 2008 R2, you have the ability to host Group Policy. If you have administrative permissions on AD domains, you could configure policy settings which will control dozen, hundreds, thousands, or tens of thousands (maybe more) machines running Windows and the user environment on those machines.

Group Policy doesn’t really apply to groups, specifically it does not apply to Windows security groups. The major scopes of management are sites, domains, and organizational units. What that means is that if you have a collection of computers in the same Active Directory site, you could apply the same set of policies to all of them via Group Policy. Furthermore, if the computer account objects for those machines are all in the same AD domain as one another you could easily configure policies which would affect them all. Additionally, group policies can be linked to an organizational unit (OU) within a domain in order to affect all of the computers whose accounts are contained within that OU. Beside local policies on a particular computer, Active Directory’s Group Policy feature uses Sites, Domains, and OUs (SDOU) as the scopes of policy management.

For affecting a number of users, we also have local, site, domain, and OU scope for the user configuration part of policy. When a user logs on to the computer, the local policies on the computer can influence the user environment. The site-linked policies for that computer’s site also can affect the user. Typically the placement of the user account in a particular domain and hierarchy of OUs within the domain governs the additional policies which will affect the user environment. As for computers, this local, site, domain, and OU sequence is what decides the scope of management.

For computer configuration policies and user configuration policies, based in part on where the computer account and user account objects are placed in AD, it is this scope of management which specifies a sequence of policies which are combined to affect the computer and user environments. This potential sequence of policies can however be pruned by security group membership, Windows Management Instrumentation (WMI) filters, and disabling parts of policy. Thus the word “group” in Group Policy is largely anachronistic, based on an era before AD when groups were not playing a secondary role in choosing policies (only pruning now really) whilst the primary scope of management is determined by computer and user accounts in sites, domains, and OUs.

Beyond that, the rest of Group Policy may at times feel like casting spells is the best recourse. Certainly, I hope that this has helped to clarify or resolve some basic misunderstandings about what Group Policy does.