Have you ever visited a city and tried to find the General Post Office so you could mail a package? Or have you ever wondered what your Government Pension Offset might be when you reach your retirement age? Or if you are writing some application code and you want to route the output of a command into General Purpose Output, what should you do? And that old Corvette sitting around gathering dust in your garage — maybe you should bite the bullet and haul it down to the scrap shop and have it cut up and sold as Good for Parts Only. I think you get the idea. Clearly since this is a tech site we’re not talking about any old GPO here. Nope, I’m talking about a Group Policy Object (GPO), something that any Windows Server administrator should be familiar with.
GPOs are basically containers that are used to store policy information related to different objects (for example users, groups, computers, folders, printers, and so on) in an Active Directory forest. Administrators use GPOs to control the configuration of these AD objects and to control how they work and how users or devices are able to access them. GPOs are thus a key component of how Group Policy works in an Active Directory environment.
All this is well known and well understood by any Windows admins worth their salt. The problem, however, is that GPOs are a lot like rabbits. What I mean is, they tend to multiple and proliferate until they start to become a pest and a nuisance for managing your organization’s Windows Server-based network. A typical enterprise with multiple sites and many hundreds or thousands of computers can end up having dozens and dozens of GPOs or perhaps even many hundreds as the weary administrator tries to control or lock down user access to different aspects of the network in an ever-increasingly granular game of whack-a-mole. The result can quickly end up being a Great Pile Of you know what where the admin no longer knows, for example, which client computers at a given site have Folder Redirection configured for redirecting the saving of the user’s documents to a central file repository. I recently came across just such a problem that a friend of mine who administers a large AD infrastructure was experiencing. In other words, his pressing question was this: Which GPOs in my AD environment are being used to configure Folder Redirection for users?
Finding a GPO
His solution was to query Active Directory for the globally unique identifier (GUID) of the Client-Side Extension (CSE) for Folder Redirection in Group Policy. The tool he used for doing this was the Dsquery command, which is a command-line tool built into Windows Server 2008 and later. This command is available on any Windows Server that has the Active Directory Domain Services (AD DS) server role installed. Dsquery comes in a whole bunch of flavors such as Dsquery computer, Dsquery user, Dsquery group, and so on, but the particular flavor needed here was the most general one: Dsquery *, which can be used to find objects in the directory based on criteria specified using a Lightweight Directory Access Protocol (LDAP) query.
To use this command, my friend first needed the GUID for the Folder Redirection CSE. This information could be found in a very old but still accurate Microsoft Knowledge Base article KB216357 and this told him that the GUID for the Folder Redirection component of a GPO is 25537BA6-77A8-11D2-9B6C-0000F8080861. He then simply ran the following Dsquery * command:
dsquery * <Object DN> -scope base -attr objectGUID
Here the parameter <Object DN> can be forestroot if you want the search to start at the root of your Active Directory forest; domainroot if you want to start off with the current domain; or the distinguished name (DN) of some specific container node in Active Directory. The -scope base portion indicates that the scope of the search is for the single object being specified. The remaining portion -attr objectGUID is used to indicate that the objectGUID attribute is the specific Active Directory attribute being searched for. Once the command was run he filtered the results for the specific GUID of 25537BA6-77A8-11D2-9B6C-0000F8080861 and was able to use this to find all GPO objects in Active Directory that had the Folder Redirection extension.
Switching to PowerShell
Dsquery * is an extremely useful tool you can pull out of your Active Directory toolbox when you need it. For example, let’s say you quickly wanted to find out how many security groups you have created in your Active Directory environment. A simple command like this can tell you this info:
dsquery * -filter "(&(groupType:1.2.840.1135188.8.131.523:=-2147483646))"
The string “(&(groupType:1.2.840.1135184.108.40.2063:=-2147483646))” in this example follows the format for an LDAP search filter. This MSDN article explains in detail the LDAP search filter syntax and I highly recommend reading it if you find you have insomnia.
Of course, Windows PowerShell can also be used to squeeze this kind of information out of Active Directory, and the particular PowerShell cmdlet you would want to use here would be Get-ADObject, which can be used either to extract a particular object out of Active Directory for you or to perform a search of Active Directory that retrieves multiple objects. Unfortunately, if you want to retrieve multiple objects from Active Directory, you’re still going to need to specify some syntax for doing this. But with Get-ADObject you now have two choices of sleep medication. You can either use specify an LDAPFilter using the same kind of syntax you’ve learned from using Dsquery * or you can use the newer PowerShell Expression Language (PEL) to write query strings you can use for query Active Directory.
The PowerShell Expression Language is explained more fully in the about_ActiveDirectory_Filter help page for the Get-ADObject cmdlet and can be found on this TechNet page.
Well actually it isn’t — that page just points you to another help page called about_Regular_Expressions, which is found on this MSDN page. I always find it fascinating how Microsoft keeps moving documentation around like this from TechNet to MSDN to who knows where in the future.
In any case, if you have trouble sleeping and the LDAP search filter syntax doesn’t help, you can always take a PEL.
Photo credit: Shutterstock