This is Your Brain on Active Directory-based Group Policy

brain-on-gp

Some days things come out of my mouth and I stand (or sit) here thinking to myself “I can’t believe I just said that.” Alas, it perhaps keeps my students awake. I hope so. Just today I think I said something like “this is your brain on Group Policy Loopback Processing. Any questions?” For some reason, during the day, a commercial with sunny-side-fried (or was that scrambled) eggs in a frying pan, Blazing Saddles (“we don’t need no stinking break”), and the soup guy from Seinfeld (“no break for you”) all popped into my head and right into the microphone. Yes, the original lines, movie names, and show names are all copyright by somebody else. I think some of my students even took a break. It’s just amazing how much media is in my head despite the fact that I haven’t intentionally watched television for several years.

But the point of this article is to reflect on a few moments during a class I’m teaching today which I thought were worth sharing – it’s about Microsoft Windows and the lovely Group Policy feature. You know it’s bound to devolve into a discussion of Windows PowerShell at some point, and if that’s what you wanted, I hope you won’t be disappointed.

Although tools such as GPOtool and others let you work with properties of Group Policy Objects (GPOs), a powerful feature of using the Group Policy Management Console (GPMC) is that you can automate or script many aspects of Group Policy Management. This is not only demonstrated with a VBscript in a lab exercise in the Group Policy class I’m teaching this week, but also was the focus of a module of the PowerShell class which I taught last week.

Today I converted (not for the first time) the VBscript example into PowerShell. Here it is with a few extra modifications. Please remember that I didn’t write the original, and I did minimal modifications from VBscript to PowerShell – just enough to get it running for a quick demonstration.

# Script to identify the Group Policy version number # PowerShell version $USE_THIS_DC = 0 $strPolicyName = "TEST" $strDC = "delta.hq.local" $strDomainName = "hq.local" # Create objects for searching the domain $oGPM = New-Object -ComObject "GPMGMT.GPM" $oGPConst = $oGPM.GetConstants() $oGPSearch = $oGPM.CreateSearchCriteria() $oDom = $oGPM.GetDomain( $strDomainName, $strDC, ` $USE_THIS_DC ) $oGPSearch.Add( $oGPConst.searchPropertyGPODisplayName, $oGPConst.searchOpEquals, $strPolicyName ) $oGPSearchResults = @($oDom.SearchGPOs( $oGPSearch )) # Verify we have found a GPO. If not quit. if( $oGPSearchResults.Count -le 0 ){ "The Group Policy object " + $strPolicyName + " was not found`non Domain Controller " + $strDC return } "Got {0} GPOs back..." -f $oGPSearchResults.Count # If found policy then print out version numbers $oGPO = $oGPSearchResults[0] "The user version number from the Active Directory = " + $oGPO.UserDSVersionNumber "The computer version number from the Active Directory = " + $oGPO.ComputerDSVersionNumber "The user version number from the Sysvol = " + $oGPO.UserSysvolVersionNumber "The computer version number from the Sysvol = " + $oGPO.ComputerSysvolVersionNumber

 

This little script, called GPOPolicyVer.ps1 during the demonstration, simply takes a GPO called TEST and displays the version numbers for it. Although the GPT.INI file in a GPO has both the version number for the Computer Configuration (CC) half of policy co-mingled with version number for the User Configuration (UC) half of policy in the same 32-bit value. The UC version is the high-order 16 bits while the CC version is the low-order 16 bits. Luckily the interface we’re using here separates those values out and distinctly represents the UserSysvolVersionNumber and ComputerSysvolVersionNumber. Beside the settings and the GPT.INI file in the SYSVOL share, Active Directory-based GPOs have an LDAP-accessible facet to them. This instance of the groupPolicyContainer class also has version numbers for the CC and UC halves of the policy.

This script pulls all four version numbers. Like the GPOtool utility, this script can be used to detect conditions such as when the independent SYSVOL share replication and Active Directory database replication are not synchronized with respect to the GPO.

In another article I’ll look at some adjustments which could be made to this script.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.