Group Policy

Script to modify the defaultSecurityDescriptor attribute on the Group-Policy-Container schema class object

by

Last week I published an article about the changes in the behavior of Group Policy processing after the deployment of security update MS16-072 under KB3163622. It included a script to assist with the remediation of Group Policy permissions: Script to report on and remediate the Group Policy security change in MS16-072.

Of course that’s not where it ends. What about new Group Policies? Do you create a procedure that requires you to add “Domain Computers” with Read permission every time you create a new Group Policy Object (GPO)? No…of course not!

What we need to do now is change the defaultSecurityDescriptor attribute on the Group-Policy-Container schema class object so that new GPOs are created with Domain Computers having Read permissions by default. Microsoft didn’t released an official script or method to do this, so here’s the next best thing.

Read more

Script to report on and remediate the Group Policy security change in MS16-072

by

Computer can read again!

On June 14th 2016 Microsoft released security update MS16-072 under KB3163622 that changes the behavior of Group Policy processing so that user group policies are now retrieved by using the machine’s security context instead of the user’s security context. This is a by-design behavior change from Microsoft to protect computers from a security vulnerability.

Update 23/06/2016: Microsoft finally released an official response to this patch via the Directory Services team: Deploying Group Policy Security Update MS16-072 \ KB3163622

This is a problem for people that implement security filtering on their Group Policy Objects (GPOs), as it removes the default Authenticated Users group not only from the “Apply group policy” permission, but also from the “Read” permission.

Read more

Script to Create, Import and Export Group Policy WMI Filters

by

This PowerShell script will Create, Import and Export Group Policy WMI Filters.

I wrote this script to cover a number of different scenarios:

  • To create a default set of GPO WMI Filters for new builds.
  • To document existing WMI filters for health checks and audits.
  • To provide a mechanism to migrate WMI filters between Dev, Test, QA and Prod.

Read more

Script to Generate a Group Policy Object (GPO) Version Report

by

Is there a version match between your Group Policy Object (GPO) containers and templates?

This PowerShell script will check that the version of each GPO is consistent in the Active Directory Group Policy Container (GPC) and on each Domain Controller in the Group Policy Template (GPT).

All Windows Operating Systems (since Windows 2000) will apply the GPO regardless of a version mismatch. However, a version mismatch will typically mean that some settings will simply not be applied because they haven’t been replicated correctly across the environment. Replication issues with good old flaky FRS and perhaps (but rarely) the newer DFS-R is often the reason that the GPT gets out of sync and lags behind the GPC. This is such a common problem.

Read more

Active Directory Health Check, Audit and Remediation Scripts

by

PowerShell Logo

I’ve been doing Active Directory work for many years and as such have a library of hundreds of scripts to assist with health checks, audits, and remediation tasks that I would like to share with the community.

But it’s not just a case of providing a script that creates a CSV or screen output, etc, as the output needs to be thoroughly explained so that the results are correctly understood and interpreted. The last thing I want is for someone to take the output of one of my scripts and start looking for a problem that does not exist, or making unnecessary modifications to their environment. This means that each script requires a separate article of it’s own. I have been doing this to date, but wanted to create a post to list all scripts used for health checks, audits and remediation tasks; linking them in as I blog about each one. I will also link out to other peoples scripts and articles that I use and find valuable.

I hope you find this a valuable source of information.

Read more

Script to Create the ADMX Central Store

by

I find it amazing how many Active Directory environments I review that do not have an ADMX Central Store set up. It’s been a best practice since the release of Windows Vista/2008 some 7 years ago now. What I find is that there tends to be ADMX sprawl across management servers and even the workstations of the IT Pros, which creates challenges when determining where to edit certain GPOs from. This is just down to lack of understanding and perhaps even laziness.

This PowerShell script will create the ADMX Central Store for you by copying the ADMX files from several source locations, such as a master source on an Administrative share and/or several management servers, including IT Pro workstations.

I use to do this via a batch script using xcopy, but the batch script needed some re-work before I was prepared to share it, so I took this opportunity to re-write it using PowerShell.

Read more

An improved and enhanced version of the famous LaunchApp.wsf

by

Have you ever wondered why your logon script fails to map network drives when an Administrative user logs onto a computer with User Account Control (UAC) enabled; even though the drive mapping process completes successfully?

To understand this you need to read the section from “Group Policy Scripts can fail due to User Account Control” here: http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx

Read more

Finding Orphaned Group Policy Objects

by

Group Policy Objects (GPOs) are stored in two parts:

  1. GPC (Group Policy Container). The GPC is where the GPO stores all the AD-related configuration under the CN=Policies,CN=System,DC=… container, which is replicated via AD replication.
  2. GPT (Group Policy Templates). The GPT is where the GPO stores the actual settings located within SYSVOL area under the Policies folder, which is replicated by either File Replication Services (FRS) or Distributed File System (DFS).

This script will help find GPOs that are missing one of the parts, which therefore makes it an orphaned GPO.

Read more

Using a Group Policy WMI filter to test for a registry value

by

I wanted a clean and simple way to prevent group policies applying during an automated build process. This is because it can potentially cause some of the components of the build process to fail. One of the last tasks to run on all servers built using my unattended build method will stamp the registry with the build version and date, so I was pretty eager to implement a WMI filter that would read the build version to determine whether or not the policy should apply. Easier said than done! I found a great article on WMI Filters that went into the requirements and gave an example, but I found that I still needed to do a considerable amount of research in order for everything to start making sense.

Copy the below MOF file to…

%SystemRoot%\System32\wbem

Compile it by typing…

Mofcomp -class:forceupdate BuildInfo.mof

Test it by typing…

Wmic path BuildInfo WHERE (BuildVersion Like “2.%”) get BuildVersion

This will return the build number from the registry for all 2.x builds

WMI Filter will be…

select * from BuildInfo where (BuildVersion Like “2.%”)

This will return True for all version 2.x builds

Please review the MOF file below. It is fully documented, and will help anyone who wants to implement the same process.

Enjoy!

Read more

Scripting updates to the GPT.ini for the Local Group Policy

by

Updated on 27th October 2010.

I came across a challenge whilst working on a big XenApp deployment in a Novell environment. I needed to make changes to the Local Group Policy Object on all Terminal / Citrix servers. This was specifically required for implementation of a logoff script, as logoff scripts are not supported via Zen Polices in a Terminal Services environment.

As always, I wanted to automate it and found that there was a real lack of information about how this can be easily achieved. Anyway, I thought that modifying the Local Policy on all XenApp servers would be a pain, but it ended up being very simple indeed.

Admittedly, I could have just copied a new gpt.ini and scripts.ini into place, but then it would not have respected any previous changes and settings that had already been made to the gpt.ini. So this script checks existing configuration settings before making any changes to the gpt.ini file.

Enjoy!!

Read more