Group Policy Central

Approximately 2 years ago today the Group Policy Central web site went live. I am very glad to say that it has been going from strength to strength since then… I of course would like to thank all of you for visiting and coming back to my site as it is you the visitor to my site that makes all this effort worth while.

Just to show you how much this site has grown below are a few stats for this site to date:

1. 1,088,594 all time visits
2. 4,741 views on your busiest day, October 19, 2011
3. 1,631 comments
4. 256 Posts

And below is a bar graph showing the growth of the site since day one…

With a lot of Windows 8 some things coming this year I have no doubt that that there will be heaps more exciting content to come later this year… 

Microsoft has just released a report (see AppLocker Deployment at Microsoft)  describing the process they used to implementation of AppLocker via Group Policy. This was done to so that Microsoft would maintaining compliance with the U.S. Digital Millennium Copyright Act (DMCA) by preventing all their computers from running P2P software.

The report shows that after they fully rolled out the AppLocker policy setting the number of P2P cases dropped to nearly 0%. It was also interesting that the report noted that there was not a single support call regarding AppLocker for all 200,000 computers when the settings were rolled out.

Not a single support call for an AppLocker-related problem has occurred.

This document focus’s more on the process for testing and deployment of AppLocker in a large environment rather than the exact technical steps. I assume what made this a lot easier for Microsoft is that the most popular BitTorrent clients uTorrent is a digitally signed program. This makes it a lot easier for AppLocker to identify the application as it only need to look at the digital signature to determine if the program should be blocked. Meaning that they do not have to constantly update the Group Policy setting with a new hash value whenever a new version of the client is released.

Personally I certainly think BitTorrent software has a legitimate and legal place. For example check out The Tunnel Movie which was a full length movie that was released freely using BitTorrent. Rather ironically Windows has its P2P service built-in called Background Intelligent Transfer Service (BITS) which is used for distributing software updates to computers efficiently over WAN and LAN links.

However this is still good case study at the process you need to take to rollout AppLocker to prevent users from running particular programs that say may not be a secure version. e.g. Adobe Reader v9 see http://blog.stealthpuppy.com/virtualisation/dont-virtualize-adobe-reader-x/).

If you are interested for instructions for using AppLocker then check out my other blog post Best Practice: How to configure AppLocker Group Policy in Windows 7 to block third-party browsers

Today I experienced Serendipity with the error “Unable to find a default server with Active Directory Web Services running.” in PowerShell with Windows 7. This message was occurring when trying to create some new OU’s using the New-ADOrganizationalUnit command. Initially I thought it was due to not having the required Active Directory Powershell commands installed but then I realised that the “Import-Module ActiveDirectory” command was loading find so that couldn’t be the problem.

About this time I then noticed a new blog post http://jorgequestforknowledge.wordpress.com/2011/12/12/the-active-directory-web-service-adws/ about the new Active Directory Web Services (ADWS) feature with 2008 R2 which explained why I was getting this message. The environment I was dealing with was a Windows 2008 only domain environment meaning that there was no ADWS for PowerShell in Windows 7 to utilise. This article explained that both PowerShell and the the Active Directory Administrative Center (ADAC) in Windows 7/2008 R2 used the WS-* protocols and therefore needed a ADWS server somewhere in the domain to work. Not having an ADWS DC in the environment meant that these tools would not work…

So to get around this issues you will need to either need to spin up a Windows Server 2008 computer to run the commands or apply the necessary KB’s to some of the domain controllers your environment to enable ADWS.

Update: I just learnt that the AD PowerShell commands are only supported on Windows 7/2008 R2.

The moral of this story is that its always good practice to make sure that your server and client infrastructure are upgraded together due to the advantages of the tight integration the two product have with one another.

Related KB’s:

Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2003-based domain controllers

Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2008-based domain controllers

Note: ADWS was included with Windows Server 2008 Service Pack 2.

If you have ever read my Best Practice for Group Policy blog post then you will know that I encourage you to edit the default domain GPO’s sparingly. The only exception I would make to this rule is when you want to modify the default domain password policy but even then you can create a new password policy GPO linked at the domain level (See Tutorial: How to setup Default and Fine Grain Password Policy )

Even if you don’t want to take my word for it here is a reference on the TechNet web site say pretty much the same thing… 

TechNet: Establishing Group Policy Operational Guidelines

Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create a new GPO at the domain level and set it to override the default settings in the default policies.

So… Lets assume you have done everything wrong and either the Default Domain and/or the Default Domain Controller Group Policy objects have been modified and you want to reset them back. Of course you have a backup of the GPO’s which are good and you simply restore them….

BUT… You have never backed up the default GPO’s and you need to reset the setting…. Well the tool that allows you to do this is called DCGPOFIX and it can be found on any Windows Server 2003 or later windows server.

NOTE: Even though we are restoring the default domain GPO’s back to a default setting doing so may still cause more issues. Therefore make sure you have a current back of your default domain so you can easily undo this change if needed (see below).

TIP: Even if you are not going to run this command I would still make of these Default Domain GPO’s now…  right now…. Go on… Its not going to hurt and this will at least give you something to roll back if you need to in the future.

The command to restore the GPO’s to default is as simple as running the “DCGPOFIX.exe” from a command line and press “Y” twice when prompted.

Now you are done. You will notice any changes to the GPO have now been removed or reverted back to the default settings. Monitor your systems for any adverse affect and make sure that you have another backup of the GPO’s for future reference.

Note: By default this command will not run if the version of the OS does not match that of the Schema version in AD.

References:

• The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state
• Core Group Policy Tools and Settings

I just came across a video on TechNet Edge about Security Compliance Manager v2 with Jose & Jeff who work on this product. This video talks about the evolution of the product and has some great demo’s of the product.

Video Source at http://technet.microsoft.com/en-us/edge/Video/hh559198

If you would like to know more then check out one of my many SCM blog posts at http://www.grouppolicy.biz/tag/security-compliance-manager/ or learn more at http://microsoft.com/scm