What are BADMIFs?

First a bit of context…what exactly are BADMIFs?  In fact, what are MIFs?  The acronym MIF stands for Management Information File and these files are used by SCCM clients to submit hardware inventory to their site’s database.  When a MIF is submitted by a client, it is processed by the client’s chosen Management Point (MP) and if nothing is wrong with it, the data gets added to the ConfigMgr database.  This happens all the time (depending on the frequency of hardware inventory in the environment) and usually there is no need to intervene or even be aware of this process.

Sometimes, however, MIF files cannot be processed for one reason or another.  In these cases, the MP will drop the MIF files into a folder called BadMifs.  This is located within Inboxes\auth\dataldr.box\BadMifs and depending on how you’ve structured your ConfigMgr folders, it may be in different places on your MP.  For example, on an MP that is remote from the Site Server itself, this may be located at  C:\Program files\SMS_CCM\Inboxes\auth\dataldr.box\BadMifs.

Below is an example of what the BadMifs folder might look like in a production environment:

Within the BadMifs folder, there will be subfolders indicating the sort of issue that the MIF file had.  The purpose of this is to categorize the reasons for these files not being submitted in order to make analysis and troubleshooting easier.  You can read about the different categories of subfolders that might be created in the BadMifs folder by reading this excellent blog by Umair Khan.

One thing to note about MIFs that make their way into the BadMifs folder…just because you see files in here (maybe a lot of files here), this does not necessarily indicate there is a problem.  Over time, you should expect to see MIFs fail to be processed and be placed in the BadMifs folder.  For example, if a MIF is submitted after a delta sync has occurred and the ConfigMgr database does not have a record of the machine’s previous delta sync for some reason (maybe there was a network glitch for a short time, for instance, and the previous MIF never arrived), it will redirect the MIF to the BadMifs folder and request the client to send a full inventory.  This is very normal and not an indication of a problem.  I say this because I don’t want anyone reading this and deciding their environment has big problems when things are completely normal.

I’ll say it again…just because you have MIFs (maybe a lot of MIFs) in your BadMifs folders does not mean there is an issue.  Yes, you want to take a look and see what’s up.  But the presence of these files should not cause anyone to panic.

Now that we’ve gotten that out of the way, we can proceed.

Understanding MIFs

While it’s useful to explain what a MIF is, I always find it helpful to actually see what we’re talking about.  To do this in my lab (don’t try this in production), I turned off my SQL Server so that my Site Server would not be able to submit the MIF to the database.  If I hadn’t done that, I could see the MIFs appear and disappear too rapidly to do anything.

If you are working in a lab environment and want to replicate what I’ve done, here are the steps:

1. Turn off the SQL Server database.  This might be stopping the SQL Server service or turning off the SQL VM itself.  But regardless, do not attempt this in a production environment
2. Open a ConfigMgr client and navigate to the Control Panel
3. Open the Configuration Manager app and select the Action tab
4. Choose Hardware Inventory Cycle and select ‘Run Now’

Below is a screenshot of the Configuration Manager app’s Actions tab

After clicking ‘Run Now’ navigate to the auth\dataldr.box folder and after a short time you should see a .MIF file appear, as the screenshot below shows:

MIF files are readable with Notepad, so feel free to open it and have a look.  Below is what the MIF from the screenshot above looks like when I open it:

As can be seen, there is a great deal of information in a MIF (and much more than this screenshot can capture).  This is the information that is destined for the ConfigMgr database.  What interests us, however, is the computer name that I’ve highlighted in red.  In this case, my computer is named PRI and I can see its name listed next to the NetBIOS Name above.  This is how we tell which client submitted a particular MIF.

Conducting Large Scale Analysis of the BadMifs Folders

While it’s easy to look at a single MIF to identify the computer that submitted it, what if you’re working in an environment where there are hundreds or even thousands of MIFs in the BadMifs folders?  I recently worked with a customer that had nearly 40,000 files in his BadMifs folders and we needed to determine whether there were certain computers that were producing all of the MIFs or if this was normal for his environment (and as of this writing, this does appear to be normal behavior).

The rest of this blog describe the analysis process and shows how to identify which computers are submitting MIFs that end up in the BadMifs folders.  Not only that, but I show a way to count the number of MIFs from each client.  This is useful to determine if a specific computer is sending more than its share of MIFs into the BadMifs folders.

Using PowerShell to Extract NetBIOS Names

The first step in identifying whether there is a problem with certain clients is to identify all of the clients that have submitted bad MIFs to the BadMifs folders in the first place.  If you have only a few of these, opening them manually might be fine.  But if you have more than a few files to go through, this quickly becomes untenable.  What’s needed is a programmatic way to extract these computer names.

As I searched, I found a blog that seems to do the trick with LogParser.  However, since everything is going to PowerShell I wanted to see if I could find a similar script to extract these names using it instead of relying on additional software.  I did a bit of searching around and found the following script that I tested and confirmed works great in my lab to extract the NetBIOS name from MIF files in every BadMifs folder:

$ConfigMgrBoxPath = "<file path>"
Get-ChildItem -Path $ConfigMgrBoxPath -Include *.MIF -Recurse -Force -ErrorAction SilentlyContinue | ForEach-Object {
    $File = $_.FullName ;
    try {
        (
            Get-Content -ReadCount 1 -TotalCount 6 -Path $_.FullName -ErrorAction Stop  |
            Select-String -Pattern "//KeyAttribute<NetBIOS\sName><(?<ComputerName>.*)>" -ErrorAction Stop
        ).Matches.Groups[-1].Value
    } catch {
        Write-Warning -Message "Failed for $File"
    }
}

FULL DISCLOSURE: This is not my script.  I found it here and have used it as part of my analysis.  It does an excellent job of extracting the data I need, so hopefully others will find it useful as well.

The results of running this script in my lab can be seen below:

This list represents a series of MIFs I configured in my lab for this test.  As can be seen, I have several instances of each device and there is no organization around it.  The script above prints to the screen, so if I have a large number of computers, I may have difficulty grabbing them and manipulating them further.  But at the outset, I can already use the script to manually review my list and see if anything jumps out.  For my example, it seems that DM-AA is represented more than  other devices, and this may bear some further scrutiny.

If I am dealing with more than just this small list of machines (as we often are in a production environment), the output can easily be sent to a text file by adding the following at the end of the script above:

| out-file –FilePath “<file path>”

In my lab, the complete script looks like this:

$ConfigMgrBoxPath = "C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS"
Get-ChildItem -Path $ConfigMgrBoxPath -Include *.MIF -Recurse -Force -ErrorAction SilentlyContinue | ForEach-Object {
    $File = $_.FullName ;
    try {
        (
            Get-Content -ReadCount 1 -TotalCount 6 -Path $_.FullName -ErrorAction Stop  |
            Select-String -Pattern "//KeyAttribute<NetBIOS\sName><(?<ComputerName>.*)>" -ErrorAction Stop
        ).Matches.Groups[-1].Value
    } catch {
        Write-Warning -Message "Failed for $File"
    }
} | out-file -FilePath "c:\test\output.txt"

One final note here…it is entirely possible to export the list of clients directly to a .csv or an Excel file.  I have chosen to export to a .txt and then copy/paste the results into Excel.  But there is no need to do this extra step unless it’s your preference.

Parsing the Data

Now that we’ve extracted the data, we want to work with it a bit to find out how many times each client name shows up in the list.  As you can see, the list above is not in any particular order and while this may be fine for small environments, we’ll need a better way if we’re dealing with larger environments (or at least larger lists).

I investigated various ways to parse the list of computers generated from the PowerShell script, but eventually came up with the following (and in my lab, I am using Excel 2013, though this same technique should work with earlier versions of Excel):

• We start by taking the list of clients and getting them into Excel (I copied/pasted out of my .txt file, but that’s certainly not the only way).  I also added a header in Excel called Computers.  The header becomes important in a later step.  The resulting screenshot below shows this step:

• Select the entire column and navigate to the Insert option on the menu bar.  From here, select Pivot Table.  A pop-up box will appear as follows:

• In here, ensure the buttons in the screenshot are selected and click ‘OK’
• Another screen will open and on the right-hand side you will see the following (Note: your column header may be different depending on what you selected for the header of your column containing the computer names)

• At this point, select the checkbox to the left of your column header (Computers, in my case) and also drag/drop the column header down to the Values area as shown below

• After doing this, the left-hand side of the spreadsheet will populate with a count of each computer name (seriously, it’s almost like magic) as shown here

Not only do we see a count of each computer that is in our list, we see the grand total telling us how many MIFs are located in our BadMifs folders in the first place.

From here, you can copy the table and paste it else where if you want to manipulate it (I wanted to filter my list so I could see the computers showing up the most frequently at the top of my list, for instance).  This is Excel 101 stuff and I won’t bore you with those details.  But hopefully this technique proves useful if you ever find yourself having to answer questions about which computers are sending MIFs to the BadMifs folder (and how many times).

Summary

This brief article’s purpose has been to show a technique I came up with to answer a very specific customer question.  It seems to be the sort of question that might come up frequently enough that I felt it would be helpful to document it.  Even if you’re not troubleshooting MIFs being sent to your BadMifs folders, it’s always a good idea to keep track of how many files are in your BadMifs folders.  This technique should help in that effort.

Tracing Hardware Inventory

Every ConfigMgr admin knows that the best way to figure out what’s happening within their hierarchy is to review the extensive log files available to them.  We’ll start this blog with a walk-through of the relevant log files for Hardware Inventory.

To start with, Hardware Inventory involves the client machine, its chosen Management Point, and the Site Server itself (and if the database is remote from the Site Server, the SQL Server is also involved to ensure that Hardware Inventory is put into the database).  To walk through the process of conducting Hardware Inventory, we will take a look at the following logs:

• Client:
  • InventoryAgent.log
• Management Point:
  • MP_Hinv.log
• Site Server:
  • Dataldr.log

NOTE: If your Management Point resides on your Site Server, both the MP_Hinv.log and Dataldr.log files will be on the same machine, though in different directories.

Before the client can ever begin to report its Hardware Inventory, it must receive a policy telling it to do so (and the frequency with which it’s expected to do so).  Rather than repeat myself on how to configure Hardware Inventory for your clients in this blog, I’ll simply note that I discussed this in a previous blog and folks who are interested can review that information here.

To get policies, the CCM client will have to be installed on the client machine which can be confirmed by looking in the Admin Console under Assets and Compliance\Devices.  Ideally we want to see the following:

Note here that the machine named ‘DC’ has the client installed and is marked as active.

Once we have the client installed on the machine and it’s active (which means it’s sending in discovery information), the CCM client should receive policy from its chosen Management Point.  If it’s necessary to know which MP the client is using, this can be determined by looking on the Configuration Management app in Control Panel as shown below:

In my lab there is only a single MP, so the question of which Management Point my clients are using is a pretty simple one to answer.  But if the site contains multiple MPs and it’s important to know which one is being used, this is a good technique to determine that.

So now we have a client that is active and talking to its Management Point.  This means it will get the policy telling it how often it needs to run Hardware Inventory (as well as what specific information it needs to gather and send).  Once it receives the policy, the client will begin sending its Hardware Inventory and the log files should begin to reflect this.

Understanding Synchronization Types and Versioning

Each time a client sends in its Hardware Inventory, there are 3 possible ways it can do this:

• Full Synchronization – this occurs the very first time the client sends in its Hardware Inventory.  At this point, no inventory has ever been reported and the client must send everything ConfigMgr has asked for.
• Delta Synchronization – once a full sync has been processed, the client will always run delta syncs from that point on.  This causes the client to send up any changes since the previous sync, but doesn’t burden ConfigMgr with the entire inventory sent during a full sync
• Re-Synchronization – this happens if ConfigMgr can’t process the delta sync for some reason and needs the client to re-sync all of its hardware inventory.  An example of when this might happen is if one of the delta syncs failed to be processed.  Each sync specifies a version # so that ConfigMgr knows where in the sequence it belongs.  We can think of delta syncs like pages in a book.  The delta sync will send the next page, but if ConfigMgr does not have the previous page it will realize it has incomplete data and request the client to send everything it has.  The process of doing this is known as a re-sync, though functionally it’s essentially the same thing as a full sync

It’s very easy to determine what sort of sync is happening.  All that’s needed it to look in InventoryAgent.log on the client and search for a line similar to the following:

Inventory: Action=Hardware, ReportType=Delta, MajorVersion=1, MinorVersion=1

Note that this line tells us it’s about inventory and the Action specifies that we’re looking at hardware inventory.  The ReportType shows that the client is performing a delta synchronization and we can see both the MajorVersion and MinorVersion are 1 in this case

To quickly clarify what is meant by MajorVersion and MinorVersion:

• MajorVersion – this value increments every time a full synchronization or a resync is run.  As stated above, once the initial full synchronization occurs, all future syncs will be delta syncs unless there is a problem that causes ConfigMgr to ask for a resync.  Note also that even if the specific policy for Hardware Inventory is changed (adding a new class to collect, for instance) the major version will not change.  If you want to test this, there is a good link that walks you through forcing a full synchronization for hardware inventory.  You can read about that here.
• MinorVersion – every time a delta sync runs, the minor version is incremented.  The only exception to this is when a resync runs and increases the major version, the minor version is reset to zero as shown below:

Delta before Resync:

Delta after Resync:

In our example below, we’ll be looking at a delta sync.  But it’s good to understand the specifics of what we’re looking at, so hopefully this explanation is helpful.

Log File Review

InventoryAgent.log

The first log we want to look at when tracing hardware inventory is the InventoryAgent.log file.  Here, we can see several interesting details about hardware inventory.  Because the amount of data provided to us in a single hardware inventory cycle can be lengthy, I am taking the liberty of excerpting information to draw out specific points.

Here we see the initiation of a hardware inventory cycle, which is denoted by the line saying ‘Start of message processing’.  In this snippet, we can see several important things:

• The time that the inventory cycle started (this will be important later as we check to see how long it took inventory to run)
• The WMI store for the gathered hardware inventory (located in InventoryActionStatus class within the root\ccm\invagt namespace).  In our case, we’re using store {00000000-0000-0000-0000-000000000001}
• The client is running hardware inventory (Action=Hardware)
• A full synchronization has only been run once, which is the initial time the client ran the inventory (MajorVersion=1)
• This is the 7th time a delta synchronization has run (MinorVersion=7)
• The classes being collected are enumerated, with two being listed in the screenshot above.  Though the screenshot doesn’t show this, the fully query for the first line starting with ‘Collection: Namespace=’ is below:

Collection: Namespace = \\.\root\cimv2; Query = SELECT __CLASS, __PATH, __RELPATH, Availability, Caption, Description, DeviceID, Drive, Manufacturer, MediaType, Name, SCSITargetId, SystemName, VolumeName FROM Win32_CDROMDrive; Timeout = 60

Note that Win32_CDROMDrive is in blue.  This is the class being queried and we can see that this class was requested if we go into the Admin Console and navigate to Administration\Client Settings and open the Client Settings we are applying to our managed devices.  By selecting Hardware Inventory from the list, look for the ‘Set Classes’ button and a pop-up will appear.  In my lab machine, doing this shows me that I do include the Win32_CDROMDrive class as one of the classes I want to gather information on.  The screenshot below illustrates this:

Not only is the class selected, but by expanding it I can see which specific attributes of the class are of interest to me.

At this point, the hardware inventory should run, gathering data from every class we’ve asked the client to check.  During this process, it may encounter errors as it attempts to check a class that is not relevant for it.  This is not indicative of a problem, though in some environments the choice may be made to set up additional Client Settings policies in order to gather inventory only from classes that are relevant to the managed device being targeted.  The choice is entirely optional.

After inventory wraps up, InventoryAgent.log will show something like the following:

This snippet represents the end of the hardware inventory cycle and we can see a few interesting things:

• The ending timestamp, which tells us that on my lab machine, hardware inventory took approx. 25 seconds.  Note that because hardware inventory is set to the lowest possible priority, it will likely take considerably longer to run in a production environment.  This is because hardware inventory is set to use CPU cycles only when other activities are not ongoing. 
• The temp report created (Temp report =)
• How long the Reporting Task took to complete (in our case 0.344 seconds)
• Whether the report was successfully sent or not (Successfully sent report. Destination:mp:MP_HinvEndpoint)

So we can see that the client ran inventory, how long it took, which classes it enumerated, and whether it sent its report successfully.  At this point, we can have confidence that the client has done its part.  Our next step is to check the MP to find out if it received what the client sent.

MP_Hinv.log

By looking on the Management Point (and if you have several MPs, you’ll need to locate the one your client is sending data to) and mapping the timestamp in InventoryAgent.log, we can see that MP_Hinv.log shows my client files arriving and being processed.

In this snippet, we see a few things:

• The report being sent in was a delta report and was from the computer PRI (Delta report from client PRI)
• The .xml file from the client arrived in dataldr.box and was found to be hardware inventory (description = Hardware)
• The .xml was converted to a .MIF file for sending further on to the site server database
• The name of the MIF file being created (in this case HC3HFXZ1.MIF)

At the Management Point, it’s possible for the hardware inventory to fail to be added to the database for some reason.  One of the most common is known as a Nonexistent Row.  This can happen when the following occurs:

1. Delta synchronization happens on the client
2. It sends the .xml reporting the MajorVersion and MinorVersion (in this example, let’s say MinorVersion=7)
3. The site server database notes that it never received the delta synchronization with MinorVersion=6, thus it is missing a row that corresponds with the previous delta sync
4. The client is told to send a fully synchronization (a re-sync)

One of the interesting things about hardware inventory is how bad MIF files are categorized.  Depending on the reason that a MIF is rejected (as in the Nonexistent Row example), a folder will be created on the MP within the inboxes\auth\dataldr.box\BADMIFS folder structure.  The screenshot below from my lab shows a sub-folder that was created when one of my clients began presenting bad MIF files.  If MIFs cannot be processed for a different reason and must be placed in this folder structure, additional sub-folders will be created to indicate why the MIF was not processed.

Within this folder will be the MIFs that were rejected, and it’s often helpful to review them (you can open them with notepad) to see the reason for the problem.  For further information about BADMIFs errors, a very helpful blog article by Umair Khan goes into some depth.  That article can be found here.

Dataldr.log

In our case, there was no error when submitting hardware inventory, so the next place to look is the Dataldr.log file.  As I mentioned above, this file is located on the site server itself even if the MP is on another machine.  The following snippet shows the next step in the process of submitting hardware inventory:

Note that in the snippet above, I have highlighted the line starting with “Moving MIF file”.  The full content for that line is listed in the gray window at the bottom of the screenshot.

Looking at this, we can see a number of interesting things:

• At 12:18:49, Data Loader checked to see if any MIFs needed to be processed.  It found one and moved it to the dataldr.box\process subfolder
• It started a worker thread and indicates “Blocking until completion”.  This indicates that the table or tables in the ConfigMgr database that are being updated have been reserved exclusively for this process.  Anything else attempting to update this table during this interval will have to wait its turn
  • Blocking is a very common concept in SQL.  Sometimes it can be a problem, but in this case blocking is quite normal.  If you are interested in further information about blocking, you can check out this link.
• We can see that the version of hardware inventory being processed is 1.7 and when it was generated.  Version 1.7 directly maps to the MajorVersion and MinorVersion that we discussed above.  In this case, it’s MajorVersion=1 and MinorVersion=7
• We see the process of adding the inventory information to the database starting (Begin transaction), successfully committing the information (Commit transaction), and then we see it remove the block from the database table (Don blocking until completion)
• We see that no more MIFs need to be processed, and finally we see that Dataldr indicates it’s done processing the MIF

Locating Hardware Inventory in the ConfigMgr Database

At this point, we have a complete chain from the client all the way to the database itself.  As to which table is updated, there are many different tables that contain the hardware inventory data.  Everything is not deposited into one table, but is distributed based on the information provided.  The following is an example of how we can locate the information on the processor being used by our test machine.

NOTE: The following information is offered to help in understanding this process.  You should never make changes in your database unless guided to do so by a Microsoft engineer.  Always back up your SQL database and ensure it is recoverable before making any changes to it.

To start with, we need to find the Machine ID for our client.  To do this, we can run the following query against the system_DISC table in the ConfigMgr database:

select ItemKey, Name0 from system_DISC where Name0 = ‘<computer name>’

In our case, the computer name is ‘PRI’ so we end up with the following result:

As it happens, the ItemKey value in system_DISC is the Machine ID we will need when checking the other tables to find out our Processor information.

Now that we have this, we need to find the table where the Processor information is held.  In ConfigMgr, there is a table known as Groupmap that identifies the tables where we can locate our desired information.  By running the following query, we can locate the table we’re interested in:

select * from dbo.groupmap where SpecificTableName like '%Processor%';

Running this, we get the following result:

Note that the specific table name is Processor_DATA.  Now that we have this, we can query it for our information.  The following query will get us what we need:

select MachineID, TimeKey, Manufacturer00, Name00 from Processor_DATA where MachineID = '<MachineID>';

At this point, we will need to enter the ItemKey value from the system_DISC query since this value is the MachineID of our client and will allow us to bring up the information we care about.  Doing this generates the following result:

I have selected only a couple of columns here and certainly more are available.  But what we can see from my chosen query is:

• The MachineID that maps to our chosen client (PRI, in this case)
• The TimeKey indicating when this information was successfully added to the database
• The manufacturer and name of the processor this client machine is using

As I say, this information is good to know.  But you should never dig around in the database or make modifications to it unless there is an important reason to do so.  And if you’re going to make a change, wait for someone from Microsoft to give you direction before you do (and ALWAYS make sure you have a verified healthy backup before you do anything).

Using Resource Explorer

So is there a better way to get this information than going to the database?  The answer is ‘yes’.  ConfigMgr provides a very robust (and safer) method to gather hardware information for any managed device.  To get the information we need, all we have to do is nagivate in the Admin Console to Assets and Compliance\Devices and select the client we are interested in.

Right-click the managed device and choose Start\Resource Explorer as shown below:

By opening Resource Explorer, we can se a consolidated list of all the hardware inventory information gathered about this client.  Below, I’ve chosen to look up the processor information (the same information we looked for in the database above).  As we can see, we get the same information:

The moral of the story is that we never need to look in the database itself for hardware inventory information.  It’s nice to know it’s there.  But ConfigMgr gives us a way to see all of this information from the Admin Console and that’s how we should be doing it.

Summary

In this blog (which will be the first of two parts), I have walked through the process of tracing hardware inventory from a client, through its Management Point, and finally shown the inventory being added to the ConfigMgr database on the site server.  Hardware inventory is a very important component of what ConfigMgr does and understanding this process is important for engineers tasked with running a healthy infrastructure.

In the next part of this series, I’ll talk about how we can learn (and configure) when hardware inventory will run.  Much of the confusion around hardware inventory deals with a lack of information on when clients should run and will run inventory.  I hope to clear this up a bit, and also provide some guidance to those who might need to customize how hardware inventory is processed in their environment.

• Whether its own Local GPO is configured with settings it should apply
• Which site it belongs to (for site-level policies)
• Which domain it belongs to (for domain-level policies)
• Where in the OU structure it resides (for OU policies)

As we said previously, the client identifies which GPOs are assigned to it from within Active Directory by looking at the gPLink attribute of the various containers where it belongs.  From the gPLink attribute on each of its container objects, the client is able to assemble a list of the GPOs it will need to apply, including the order it should apply them (based on location of the GPO, filtering, and Enforcement/Blocking rules).  The previous post in this series discussed these things, so I'll refer you there for further explanation.

Once the client has its list of GPOs, it checks the Group Policy Container (GPC) in Active Directory for each one and gets information on where the GPO contents can be located.  You'll remember that the GPO contents are located in the Group Policy Template (GPT) within the SYSVOL share.  The first time the client does this, it has all new policies to apply and will go through each to apply what's needed.  But a client doesn't just apply a GPO once and never again.  It's an ongoing process.  With that in mind, we need to understand how GPO Processing works on an ongoing basis.

GPO Versions

As I said above, a client doesn't just process a GPO once and never again.  It will continually check to see if there are any changes in those GPOs assigned to it (or if there are new GPOs, GPOs that have been removed, etc.).  The way a client knows whether it has new settings to apply is through a GPO's version number.  Every change that is put into a GPO causes its version number to increase.  If a client checks the GPO and sees that there is a newer version number than the one it is aware of, that GPO is processed.

To see the GPO version numbers, you can look in several places.  First, the GPMC contains the information as shown below:

You can see from this screenshot that there is a different version for the User and Machine nodes.  This allows clients to decide on which of the nodes the changes have occurred so it only processes the necessary portions of the policy (and also, if the client is a user or a group it likely won't have any use for the Machine node policies).

The GPMC also records the SYSVOL version number as well as the AD version number.  This can be very important in troubleshooting.  If the AD portion (the GPC) of the GPO is showing one version number and the portion of the GPO in SYSVOL (the GPT) is showing another, this means the GPO is not fully synchronized and the client may be applying the wrong settings.  Under Windows 2000, a GPO wouldn't even apply if these version numbers were different.  This produced some problems, so starting with Windows 2003 a GPO will still apply if the AD and SYSVOL versions are different.  But this doesn't change the fact that we always want these to be as much in sync as possible.  As for why they may be out of sync, it's possible that this is only due to replication latency.  We'll discuss that in a moment.

Another way to see the version of a GPO is to look within the GPC itself.  In the following screenshot I've used ADSI Edit to navigate to the System/Policies container of my domain and I've selected one of my GPOs and opened its properties.  Here is what it shows me:

As you can see, there is a versionNumber attribute for the GPO (you need to look at the GPO itself and not the machine or user nodes).  You can see that the number is a fairly large one.  In this case it's ‘131078’.  But I know that if I look at the GPO version for this same GPO through the GPMC I'll see the following:

Why this difference?  The difference is that in ADSI Edit, you'll see the raw information that is interpreted before it's displayed in the GPMC.  This is also the information you see displayed in LDP if you choose to use that tool, as shown below:

So how do we interpret the versionNumber ourselves?  Surprisingly it's pretty simple.

First, versionNumber represents both the User and Machine node version numbers.  The versionNumber attribute `contains a 32-bit number stored as a decimal.  The way this single number stores both version numbers is for it to store the User node as the first 16 bits and the Machine node as the last 16 bits.  This can be represented as follows:

versionNumber = {User Node: upper 16 bits}{Machine Node: lower 16 bits}

To actually see the numbers the way that they are represented by the GPMC, you can take the following steps:

1. Convert versionNumber to a hexadecimal number (you can easily do this with a scientific calculator)
2. Take the first four digits of your converted number as your User version and the final four digits as your Machine version (if necessary, append the number with leading zeros until you get 8 digits)
3. Convert each of these four-digit segments back to decimal separately
4. The resulting number will be the version number you see in the GPMC.

Based on the versionNumber of 1313078, I can see the following using the built-in calculator tool:

First I start with 131078 represented in decimal:

Then I convert this to hexadecimal (notice that the leading zeroes are missing so I need to pad the number out until I get ‘00020006):

From here, I take each number (0002 for the User-side version of the policy and 0006 for the Computer-side version) and convert them back to decimal.  In my case because I’m working in a lab environment the numbers convert back to 2 and 6 respectively.  But this won’t typically be the case in a production environment.

NOTE: The versionNumber attribute will only show you the version number of the part of the GPO stored within the GPC.

As just noted, the versionNumber attribute won't show the version number as reflected in the GPT (which will be the version from the perspective of the GPO content that’s replicated by DFS-R in SYSVOL).  For this, we need to look within the Group Policy Template itself.  When looking there, we also need to drill down to the GPO that interests us.  In our case, we want the following GPO (found in C:\Windows\SYSVOL\sysvol\cert.local\policies):

Here we will find a file called GPT.INI.  This is the file responsible for recording the version number of the GPO from the perspective of the GPT (or, if you prefer, from the perspective of SYSVOL).  GPT.INI is a very simple file as you can see from this screenshot:

As you can see, the GPT.INI file tells us that the version of the GPO from its perspective is also 131078.  It should not be surprising to learn that this number represents both the User and Machine node version number in the same way it did within the GPC, or that you should follow the same procedure to convert this number to see what the version number is for each node.

In fact, even if you don't convert this number, just the fact that it agrees with the versionNumber attribute in the GPC is a very good sign.  It tells us that the GPO from the perspective of SYSVOL is the same as it is from the perspective of AD.

AD Replication/FRS Replication

I mentioned earlier that the GPC and GPT might be out of sync when it comes to GPO Version number.  While this could mean that you have a problem in your environment, this isn't necessarily the case.  The reason is that SYSVOL and AD replicate in different ways and at different times.  Going into a full discussion of these two types of replication would take a long time and is beyond the scope of our present discussion.  Instead, I'll just give a brief thumbnail of each.

FRS Replication

FRS uses a form of replication known as change notification.  Within SYSVOL, if a change is made to a file the underlying mechanism notifies its partners 3 seconds after the change is made and the partner immediately begins requesting those changes.  For this reason, the GPT content should be replicated very quickly between Domain Controllers after you've made a change to a GPO.

AD Replication

In contrast to FRS Replication, the replication engine responsible for Active Directory is schedule-based.  Depending on whether the Domain Controllers receiving updates are within your Active Directory site or not, replication can take awhile.  Within Active Directory, there are two types of replication.  These are known as Intrasite and Intersite.

When two Domain Controllers belong to the same Active Directory site, replication will be quite fast.  A change on one DC will begin replicating 15 seconds later to other DCs within the same site.  With DCs in remote sites, the default wait period before replicating a change is 3 hours, though this can be configured and shortened to as little as 15 minutes.

So what does this mean for your client attempting to process a GPO?  If it belongs to the same site as the Domain Controller (typically the PDC Emulator) where the GPO was configured, it will most likely get the latest version of both the GPC and the GPT at nearly the same time.  If, on the other hand, it belongs to a remote site, it may attempt to process its GPOs before both the GPT and GPC are fully updated.  In Windows 2000, GPOs that weren't fully synchronized were not processed, but beginning with Windows 2003 that was no longer the case.  But if your client isn't getting all of the settings you expect them to, this could potentially be one of the reasons why.

NOTE: Intersite replication latency is one of the reasons to limit the number of your Active Directory sites and only build a new site when it's necessary.  Sites are well-connected groupings of computers and as long as you have sufficient bandwidth, it makes sense to leave them all within one site.  The only time you'll typically want to create a new site is if you have a slower WAN link that the data must traverse, or if you have a special business need to replicate data only at specifically scheduled intervals.

A good article that goes into depth about Active Directory replication can be found here.

Clients and GPOs – Comparing Version Numbers

So now we know how GPOs store version numbers and a bit about how that information is replicated throughout your Active Directory infrastructure.  But the question that still remains to be answered is "how does a client know if its copy of the GPO is older than the current one?"  We know it's tied to version numbers, but how does the client even know if it has the current version number?  Where does it maintain this information?  For the client to know whether it's processed a particular version of a GPO already, it needs to have its own copy of the GPO version to reference.

To see the GPOs that your client is currently aware of as well as the versions it has applied of each, you will need to look at the following location in its registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State

Within this registry key, you'll see two nodes.  These are:

• Machine - this key contains the GPOs that apply machine-side settings to your client
• User SID - this key is the user's security identifier and contains the GPOs that apply user-side settings to your client

Both the Machine and SID keys have a node called GPO-List.  Within this key you'll find a listing of every GPO that has been applied.

In this screenshot, you can see that the Machine node has 5 GPOs listed under its version of GPO-List.  The expanded User SID does as well.  By looking at the details of one of the GPOs in the Machine node's list, you can see that a great deal of information is available about that GPO, including its DisplayName, the GPO ID, etc.  What interests us, however, is the Version value.  This value works much like the Version number as seen through ADSI Edit or within the GPT.INI file.  However, as you can see, it also does the first step for us by converting the decimal number to hexadecimal.

In the case of the Version value, what you see is not the user node and machine node version.  Instead, you see the GPT and GPC versions.  In this case, the first four digits record the version as found in the GPT and the last four digits reference the GPC's version.

Looking at the information from the screenshot above, we see the following:

Looking at this, we can see that the most recent version of this GPO that has been applied on the client is version 12 of both the GPT (the first 4 digits of the hexadecimal number) and GPC (the last 4 digits of the hexadecimal number).  If it checks again and finds that the machine node of the GPO is still at version 4, it will know that no changes have been made and it won't need to process anything.

NOTE: There is one caveat when it comes to processing security settings, since these will always be processed again after a defined interval regardless of whether a change has occurred.  This is to make sure no one has made any manual security changes that were enforced by the GPO, but which have been undone by a malicious or unwitting user or application.  More on this is discussed under the next section.

Foreground and Background Processing

There are several different ways that a client will process GPOs, and different parts of the GPO will be applied depending on what type of processing is happening.

The two types of processing are known as Foreground and Background processing.  These are defined below:

• Foreground Processing - occurs during computer startup/shutdown and user login/logoff.  All policies are processed during this time.
• Background Processing - occurs at a regular interval in the background while the computer is online.  The processing interval is 90 minutes + up to 30 minutes offset (in other words, every 90 - 120 minutes) for client machines and every 5 minutes on Domain Controllers (due to the need for DCs to have a higher level of security).

To understand how it may impact what you see when applying policies in your environment, a bit of history is necessary.  When Windows 2000 came out, GPOs actually were processed differently than they are today.  Every time the computer started up, it would go through the following process:

• Apply any local settings configured in its local GPO
• Contact its Domain Controller in Active Directory and learn which Site, Domain and OU it belonged to
• Pull any GPOs linked to those locations and process them in the order previously described
• When the machine policies were finished applying, the Ctrl+Alt+Delete logon prompt was presented to the user
• When the user logged in, the same process repeated to check where the user object was located, discover which policies were linked to that location, and process those GPOs in the standard order

From the standpoint of knowing what's happening during login and making sure that the correct settings are being applied, this was very clean.  However, customers complained about slow logon times, so changes were made starting with Windows XP:

1. If the computer is booting for the first time and and this is the user’s initial login to an Active Directory domain, it processes GPOs as mentioned above.  This is known as initial startup.  During this time, the client locates all GPOs it needs to apply and pulls every setting that is needed, applying them synchronously.  By synchronously, I mean that the settings are applied before clients are allowed to logon.
2. After the initial startup, processing of GPOs occurs in the background only.  Even when you're restarting your computer, it won't go through the initial startup phase as it did the first time.  Instead, it will process any GPO changes it finds asynchronously (after the user has been allowed to login).  This allows the user to log in faster (known as Fast Boot), but it may also result in policies not applying as quickly as you need.

There are some categories of Group Policy that only apply during Foreground processing.  These are:

• Logon/Logoff and Startup/Shutdown scripts
• Folder Redirection
• Software Installation
• Disk Quotas

The logic behind these categories not applying during background refresh is solid.  Imagine if you were logged on and using a piece of software, but your administrator decided to swap it for another version.  If this new version were to be automatically pushed to your desktop during background processing, it might corrupt the files you were working on.  For reasons like these, the settings listed above are only applied during Foreground processing.

The problem is that, as I said above, after initial startup the first time you log into your new device, there won't be any foreground processing.  So how do these settings ever get applied.  What happens is that when one of these settings must be applied, your client will switch briefly to allow foreground processing until these settings are applied.  The way it happens can be a bit confusing, so let me describe it briefly:

1. When a GPO is processed, your client checks to see whether any settings have been configured which require foreground processing.
2. If it finds any of these settings configured, it makes a note of this and schedules these settings to be applied the next time the client reboots or logs in (depending on what is required for the particular setting)
3. The next time a startup or login occur, the settings identified are processed using foreground processing rules

What this means is that in order for some settings to apply, it may take 2 or even 3 restarts to your system.  This can be confusing and certainly may be painful in your environment (getting your client to boot faster seems to have its price!).

You can make a change on your clients to cause them to use the old Windows 2000 way of processing GPOs.  This will eliminate the need for multiple reboots to get a setting to apply, but it could also slow down your users' login time and result in complaints.  The way to make this change is described below.

1. Create a new GPO or edit an existing one (it will need to be linked to either the Domain, Site or OU where your targeted clients can be affected).
2. Within the GPMC Editor, expand the Computer Configuration Node and go to Policies/Administrative Templates/System/Logon
3. Within the Logon settings, choose Always wait for the network at computer startup and logon.
4. Enable this setting to cause your clients to process GPOs synchronously at startup/logon

This screenshot gives you an idea of what you should see when you're configuring this setting:

To confirm what this setting does, check out the details of this setting by double-clicking it.  Below is a screenshot of what this looks like in my lab (as can be seen, the description of the GPO specifies the potential need for multiple reboots to apply certain policy settings):

NOTE: If you decide to make this change, it's a good idea to test it in a lab first so that you know how much slower your login times are likely to be.  There are new tools that allow you to assess the time it takes to process GPOs on a client device.  Look for details on that in a future blog post, or if you prefer take a look at the Group Policy Results component of GPMC (this requires either Windows 2012 or Windows 8)

Security Settings in GPOs

One final note about GPO processing is important before we move on.  Though I've already mentioned that your client will only apply GPO settings if they've been changed (why apply something that hasn't been changed, after all?), there is one exception and this is Security settings in your GPOs.  Microsoft recognizes that unscrupulous people may be able to get onto a client or server machine and manually undo the security settings your GPO has put in place.  In this case, the GPO will not have changed, and if the client only updates GPOs when they've changed, this could leave the bad guys in charge of your client or server.

To prevent this from happening, all security settings in GPOs are re-applied at a regular interval even if they haven't changed.  This enforcement mechanism is used to protect clients and servers by re-applying security settings that may have been undone in the meantime.  The refresh interval for client machines is every 16 hours, and for Domain Controllers it's every 5 minutes (due to the heightened security concerns when it comes to DCs).  You can configure this mandatory refresh interval, but unless you have a compelling reason to do so it's probably better to leave it at the defaults.

NOTE: There will be times when you need to update a GPO immediately on a client.  In these cases, Microsoft provides a tool called GPUpdate to allow for this.  On Windows 2012, it’s also possible to right-click a node in the GPMC and select ‘Group Policy Update’ which causes GPUpdate /force to be run at every device within the scope of the node you’ve selected.  These tools are discussed in more depth at the end of this post.

Client-Side Extensions (CSEs)

Now we've reached the final point.  We know how clients identify which GPOs belong to them.  We know how they process GPOs (and how often).  Now we just need to know how they take the information in the GPOs and apply them.  To do this, they need a series of files known as Client-Side Extensions, or CSEs.

A Client-Side Extension is nothing more than a  file (in most cases it's a .dll file, but not always) that has been installed on the client machine which has the ability to interpret and process certain of the settings in a GPO.  Because there are many different types of settings, there are different Client-Side Extensions.  In order for your client to process a portion of a GPO, the CSE associated with that portion of the GPO will need to be present on the client machine.  An example of this is the security settings that are found under Policies/Windows Settings/Security Settings on both the Machine and User nodes of a GPO.  To process any settings that have been configured within these containers, your client will need the scecli.dll file.

You can see the various Client-Side Extensions that are loaded on your client by checking your registry.  The following screenshot illustrates where this is located:

As you can see from the screenshot, the Registry key GPExtensions contains the list of CSEs installed on your client device.  To see this key, navigate to the following location in your client's Registry:

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/GPExtensions

Each of the keys located beneath GPExtensions represents a different CSE.  Looking just at the one shown in the screenshot above, we can see that this CSE is used with Security settings.  We also see that the file used to process the security settings in the GPO is named scecli.dll.  As new settings for your GPOs are released, the number of CSEs may end up growing as well.  Typically you won't have to do anything with these, but it's good to know nonetheless.

So, in summary, we see that when a client pulls its list of GPOs it follows a well-defined process as described above.  And once it gets the settings that it should apply, it relies on the various files that are collectively known as Client-Side Extensions.  Like I've said, in most cases this all happens behind the scenes and you don't even need to be aware of it.  But it's nice to know how the process works "under the hood".

Group Policy tools

Finally, let's wrap up with a discussion of a couple of administrative tools that are useful in managing your GPO environment.  These tools certainly aren't the only ones you'll want to know about to manage your GPO infrastructure, and I'm not going to cover every possible thing you can do with each of these tools.  But the information below should prove helpful when trying to troubleshoot the sorts of issues we've covered as part of this topic.

Group Policy Status

In earlier environments, there was a tool named GPOTool that allowed us to verify the health of our GPOs.  It was command-line based and may still work in Windows 2012 R2 (it did in Windows 2008).  But with Windows 2012, there is a new and preferred way to verify the status of GPOs that’s known as GPO Status.

Remember that a GPO consists of two components, one found in Active Directory and replicated via AD replication and the other found in SYSVOL and replicated via (hopefully, by this point) DFS-R.  These two components replicate in different ways and at different times, and if there is a problem with one of these it is possible that your GPOs will be inconsistent.  This could mean that you might see your GPOs showing one version for AD and a different one for SYSVOL.

Within the GPMC for Windows 2012, there is now a way to determine whether your GPOs are fully replicated throughout your environment.  And the nice thing is that you can do this on a per-GPO or per-Domain basis (sorry but Sites and OUs do not have this feature).  If you want to know whether a specific GPO has fully replicated, check the GPO itself.  And if you want to know whether all of your GPOs have replicated, check the domain.

To check the status of a specific GPO, select the GPO (either the link or the GPO itself under Group Policy Objects) and choose the Status tab.  By selecting the ‘Detect Now’ button, you can tell what the status of the GPO is on each of the DCs to which this GPO replicates:

Note in the case above, I have 1 DC to which I am replicating the ‘Access this Computer from the Network – NAA’ GPO.  If it were still in the process of replicating, this would be noted.  But in my case, replication is in sync, which is why DC2 is showing in the bottom drop-down category.

To check replication for the entire domain is essentially the same thing.  Simply select the domain node itself in the GPMC, go to the Status tab and take the same steps mentioned just above.  Below is what this looks like in my lab:

Since I have just finished promoting DC2 to be a domain controller, several of the GPOs are still replicating.  I have also taken the extra step of ensuring that all categories are reported on by right-clicking the details pane and selecting every category.  This is shown below:

By doing this, I get additional detail and can look at things like the date that both the Active Directory and SysVol portions of my GPOs were last modified.  All I need to do is select the ‘Modified date’ hyperlink as shown above and I’ll get a nice pop-up like the one below:

This sort of information can be invaluable when attempting to troubleshoot why a policy might not have replicated to each of the DCs in your domain.  Sometimes this is merely a function of the time needed to allow replication to complete.  But if your domain has not converged within the expected timeframe, it may be necessary to look into it further.

NOTE: If you are checking the entire domain, be prepared for some additional network traffic.  Every GPO will be checked against every DC to make sure what all of them report.  While this additional traffic shouldn’t be a problem, it’s something to at least be aware of.

GPUpdate

As I mentioned above, there will almost certainly be times when you need to make a change to a GPO and have it update immediately on a client.  With GPUpdate, you can force the background refresh on a client to kick in immediately (note: you cannot force the foreground process through GPUpdate).  GPUpdate runs only on the local client since it's telling the client to pull updates immediately and to do this, we need to be on the client that initiates the request.

GPUpdate is a command-line tool and it has a number of parameters that are of interest to us:

• /Target: {Computer|User} - this switch allows your client to request only the machine or user-side settings from its GPOs.  If this switch is not used, both user and computer settings are updated
• /Force - this switch causes your client to re-apply all of the policies assigned to it, though it only assigns policies that have been changed (it won't cause the client to re-apply every setting if some of them have not been changed since the last update)
• /Logoff - using this switch, you can force a logoff which will allow policies that process in the foreground to be processed
• /Boot - this switch causes your client to reboot after the policies are applied (again, to allow for processing of policies that only apply after a reboot)

Here is an example of what this might look like in your environment:

As you can see, the interface doesn't tell you much.  In this screenshot, I have asked my client to pull the settings for its GPOs and I've selected /force to ensure that the policies are refreshed.  This caused background processing to start immediately and we can see that it finished successfully.  If I had configured a particular setting on a GPO, I could run a tool like the Resultant Set of Policies (RSOP) to find out if that setting had taken effect.  If I prefer, I could also run Group Policy Results from the GPMC and get the GPO results of remote computers (this is a much better way of getting RSOP data as it will provide significant additional detail that will help to troubleshoot any issues found on a client system). 

GPUpdate works great if you’re troubleshooting a single device (or even a handful of devices if you don’t mind using this tool on each one).  But if you make a policy change and need to have all client devices impacted by this change apply the policy immediately, the better way to do this in Windows 2012 is to select the parent OU (no domains or sites, unfortunately) where the clients reside and choose ‘Group Policy Update…’ as shown below:

By selecting this, a pop-up will be invoked to verify that you do want to update the computers that are within the scope of that OU.  By selecting ‘Yes’, the GPMC runs GPUpdate /force against every machine in the scope of the OU you’ve selected.  Below is a screenshot of the confirmation pop-up itself.  Note that it states that you’ve chosen to force a Group Policy update and will tell you the scope where this will occur.  Read this carefully to make sure this is, indeed, the desired scope before selecting ‘Yes’.

Group Policy Update isn’t a new tool so much as a way to run GPUpdate /force across multiple machines without requiring you to log into each one (or write some sort of script).  While it’s not essential that you ever use this, it’s nice to know it’s there if needed.

Summary

And with that, we come to the end of this series on GPO basics.  I know this has been a very long post (and the end of several other very long posts), and I apologize for packing in so much.  I felt it was necessary to be thorough and finish covering the core details necessary to understand GPOs and how they are processed within your environments.  Now that we've got the basics covered, we should be in good shape to move forward with other, more focused topics related to Group Policies.

How Does a Client Know Which GPOs to Apply?

There are two types of GPOs.  There are GPOs that are configured locally on the client machine and are always processed, and there are GPOs linked within the Active Directory structure itself.  While the client knows that it needs to process its local GPO, it's not as clear as to which GPOs in the directory structure apply to it.  Within the directory, GPOs can be linked to the following levels:

• Site
• Domain
• Organizational Unit

Depending on where the client object is located determines which GPOs it applies.  For example, consider the following scenario:

Here we see that the workstation named Win8 is within the Computers OU that is part of the cert.local domain.  This is represented by the following distinguishedName: CN=Win8,OU=Computers,OU=Lab,DC=cert,DC=local. Though we don't see it on this screenshot, the Win8 client also belongs to the Active Directory site known as 'Default-First-Site-Name'.  Given this, which GPOs need to be considered by our client machine?  We already know that any local settings on the client itself will need to be processed.  And if we look at the GPMC, we can see that two additional GPOs exist that the client must consider:

These two GPOs are the Default Domain Policy linked at the domain level and the Event Log Size linked to the Computers OU.  We can also see that there are no GPOs linked to any sites.  So we know that our possible list of GPOs includes:

• Local GPO (known as the Local Policy)
• Default Domain Policy
• Event Log Size

The way the client actually sees these is a bit different.  In order for your workstation or server to determine whether it needs to process any policies, it looks for the gPLink attribute that exists within certain Active Directory objects.  This attribute, when populated, points to the name and location of the GPO that the client must consider.  Take a look at an example of this below:

Using the LDP tool, we can see that the gPLink attribute is populated for the Computers OU.  Looking at it closely, we can also see that it is pointing the client to the Group Policy Container for a specific GPO (which we already know is the Event Log Size GPO).  In the previous post, we've already seen how the GPC functions so I won't cover that again.  Instead, it's just enough to know that this is how the client learns which GPO it needs to look up.

Sticking with our scenario, we learn that gPLink is also populated on our domain object, but that it isn't populated on the site where our client belongs.  So we end up with the list of GPOs already enumerated above.  Now what do we do with them?

Processing GPOs: Precedence

Because it's possible (and even likely) that you may have multiple GPOs to apply, there is always the possibility that these GPOs will have conflicting settings.  In this case, how do we know which GPO will win and have its settings applied?  The simple rule to remember is that the last GPO applied will overwrite any settings applied earlier.  And the GPOs closest to the client location in the directory structure will be applied last.  The order goes as follows:

• Local
• Site
• Domain
• Organizational Unit

What this means is that if you've set something on your Local GPO but your domain administrators require a different setting, your local setting will be overwritten.  The same thing applies to situations where the domain may have a default policy but your business unit may have more specific needs.  In this case, a default setting can be configured and your business unit can override this setting to apply the one your group requires.

In our example above, suppose that the Default Domain Policy GPO set a disk quote for the domain at 50 MB.  However, your business unit requires that your workstations have 100 MB quotas.  Your administrators could set a policy at the OU level to allow these settings for your group.  Your directory structure might look like this:

Note here that we are still using the Computers OU that we leveraged before, but now we have created a new GPO called Disk Quota (Accounting) that we've linked to it as well.  At this point, objects within the Computers OU will have the following GPOs to apply:

• Local GPO
• Default Domain Policy
• Event Log Size
• Disk Quota (Accounting)

Briefly, let’s look at the Disk Quota settings in both the Default Domain Policy and the newly created Disk Quota (Accounting) policy.

First, on the Default Domain Policy, we can see that we have assigned a value of 50MB which applies to the entire domain.

By contrast, here are the settings applied to the Disk Quota (Accounting) OU.

In this case, if the Default Domain Policy assigns a value of 50 MB as the default disk quota for the domain, the Disk Quota (Accounting) policy should overwrite it because it's applied last.  But can we confirm that?  To do so, it’s as easy as logging into a client machine within the scope of both of these policies to see which one has taken effect.

By using the MMC Snap-in known as the Resultant Set of Policy (RSOP), we can see what the currently applied settings are for our test computer as well as which GPO provided the settings:

When I ran RSOP from my Win8 device, I was able to verify that my Disk Quota settings did, in fact, come from the Disk Quota (Accounting) GPO and that the effective setting was 100 MB.

One final point about precedence and which GPO will apply in what order.  What if you have configured two GPOs at the same OU level, as we have in the Computers OU?  How do we know which GPO will apply first and which one will win if they have competing settings (in our examples, the GPOs do not have competing settings, but in the real world this is always a possibility)?  In this case, you must rely on the GPMC to tell you this.  You can also configure the order in which these GPOs will be processed if needed.  The following screenshot shows two GPOs that will be applied at the Computer OU level:

From looking at the screen, you can see that these two GPOs are numbered.  The way in which GPOs  are applied is from the highest number to the lowest number.  So in this case, the Disk Quota (Accounting) GPO will apply before the Event Log Size GPO.  If you want to alter this order, all that’s needed is to select the GPO you want to move and use the arrows on the left-hand side of the screen to move it up or down in the list.

Filtering a GPO

Before we go any further, we need to look at two more concepts that will determine whether GPO settings are applied to your client.  The first is GPO Filtering.  This feature allows further granularity in the way that GPOs are applied in your environment.  Even when a GPO is linked within a part of your directory (say, an OU) you may not want that GPO to apply to every object within that container.  You can control this by assigning permissions for who can process your GPO.  This is known as filtering.

When you filter a GPO, you specifically designate which users, groups and computers are allowed to apply a GPO.  For example, you may only want the team leads within the Accounting group to get 100 MB of disk space for their disk quota, so you decide to configure a group called Team Leads and filter the GPO on that group.  If you did this, it would look like the following:

You'll notice that in the Security Filtering pane we now have only the Team Leads group.  This means that even if an object is within the Computers OU, it will not apply the Disk Quota (Accounting) settings unless it belongs to the Team Leads group.

NOTE: It is easy to allow your GPOs to become VERY complicated very quickly through the use of security filtering.  Use of security filters should be carefully planned beforehand (as should everything with your Group Policy infrastructure).

Security Filtering Under the Hood

Though we can certainly add and remove users, computers and groups from the security filtering window in the GPMC, it's also helpful to know what's actually happening under the hood when we do this.

In order for a GPO to apply to an object, that object must have two rights over that GPO.  These are:

• Read
• Apply Group Policy

When a user, computer or group is added to the security filtering window, it is being granted these two rights (and vice versa).  To see the exact permissions being applied via security filtering (and to get to the security properties of a GPO in general, do the following:

1. Within the GPMC, select the GPO you're interested in and choose the Delegation tab in the right-hand pane.
2. Within the Delegation tab, select the Advanced... button in the lower right-hand corner.
3. Select the object of interest in the Group or user names: pane and look at the permissions assigned in the lower pane.

The following shows an example of what I'm talking about:

You can also manage permissions directly in this window (and that's how we used to have to do it before the GPMC came along).  But unless you have some specific need to make changes here, it's generally better to simply add/remove objects in the Security Filtering window.

WMI Filtering

WMI stands for Windows Management Instrumentation and it's been created as a way to specify and act on computers based upon chosen characteristics.  WMI is not a Microsoft-specific thing, but is an industry standard that Windows leverages.  Within Windows computers, there are thousands of management settings which an admin may want to access.  WMI provides a central repository for that information to allow easy (well, somewhat easy) access.  From within the repository, standardized ways exist to locate and leverage the available management data.

Examples of the type of data stored in the WMI Repository would be information relating to a computer’s BIOS, its physical disk layout, aspects of its desktop or the services it has running.  GPOs can leverage WMI filtering so that only computers meeting certain criteria (running a specific motherboard, for example) will process a GPO.  In short, it's a way to say "I am only interested in these specific computers".  Group Policies allow you to use WMI queries to specify in a very granular way which GPOs will apply to which computers.  You'll need to learn how to write a WMI query (using the WMI Query Language, or WQL, which is similar in structure to the SQL language), but if your environment has a need for this level of granularity, the functionality is present.

To write your own WMI Filter, you'll need to create the filter and then apply it to your GPO of choice.  To do this, take the following steps:

• In the GPMC, right-click the WMI Filters node and select New... as shown below

• Give your WMI Filter a name and a description and then select Add.

• Most of the time you will want your Namespace to be root\CIMv2, though many different namespaces exist within the WMI Repository depending on the individual computer’s configuration.  You can see this by clicking the browse button and scrolling through the various namespaces present in your WMI Repository

• Once you have selected the Namespace, type your query in the Query window as shown below

Note that this WQL Query will find Windows 8 Computers and filter out anything that does not meet this criteria.  If you don’t know WQL (and most don’t, which is why WMI Filters aren’t used that much), I highly recommend the book PowerShell and WMI by Richard Siddaway.  This is an excellent way to learn about WMI and how to manipulate it with PowerShell.

After you have completed these steps, save your query.  The query will appear in the right-hand pane as well as beneath your WMI Filters node on the left of the GPMC as shown below:

Now that the WMI Filter has been created, you can apply it to the GPO of your choice by doing the following:

• Select the GPO and choose the Scope tab in the right-hand pane
• At the bottom of the Scope pane, locate the WMI Filtering section
• Select the drop-down box entitled This GPO is linked to the WMI filter you just created

The screenshot below illustrates this:

At this point, the WMI filter is assigned to your GPO and only those computers meeting the specifications of this filter will receive the GPO.  Because WMI filtering can become very complex, it is always a good idea to thoroughly test these settings before applying them in production.  If the computers which are the target of your filter aren't receiving the GPOs they should, it's likely that the filter has been written wrong.

NOTE: Even if you write a WMI query to include a particular computer object, it will still need to have 'Read' and 'Apply Group Policy' permissions over the GPO in order to apply its settings.

Inheritance, Blocking and Enforcement

The second concept that we need to address is the idea of GPO inheritance and the ways administrators can control whether a higher-level GPO is applied to the objects further down in the directory.  This can become especially relevant when you have a large number of GPOs and you don't need the clients within a particular OU to apply all of those settings (applying all of those settings requires more time for your client to start, after all).

To extend our example above, let's assume we have a child OU under the Computers OU.  Lets call it Executives, and let’s say we’ve decided to move our Win8 computer object into this OU (it belongs to our CEO and needs to be handled more carefully).  We have made a decision that the members of the Executives OU should not have the Event Log Size GPO apply to their client machines for some reason.  Unless something is done to prevent it from applying, its settings will go into effect on client machines in the Executives OU.  You could make the decision to create a second GPO to overwrite the settings in the Event Log Size GPO, but then your clients have two GPOs to process, one applying some settings and the other removing those same settings.  It seems a bit cumbersome.  Thankfully, there's a better way.

Instead of creating yet another GPO whose purpose is to undo the settings of a higher-level GPO, administrators have the ability to block higher-level GPOs so that they don't apply to your OU.  It's important to note that when you choose to block higher-level GPOs, you are blocking all of them.  So any GPO that is inherited will no longer apply.  Only those GPOs that you configure directly on your local object will apply (if you create child OUs, inheritance will apply to these, starting at the parent OU where the blocking is in effect).

A couple of screenshots should help explain this.

In this screenshot, you can see how to block inheritance of higher-level GPOs.  All that is required is for you to right-click the OU (in this case, the Executives OU) and select Block Inheritance.  A check will appear beside it and all higher-level GPOs will be blocked from applying within your OU or any child OUs you might configure.

Below, we see a before/after picture of the GPOs that will apply to the Executives OU:

Before we block inheritance at the Executives OU, we can see that 3 policies will be applied (starting with the bottom and working up).  These are:

• Event Log Size
• Disk Quota (Accounting)
• Default Domain Policy

As already mentioned, these policies apply from the bottom to the top.  So, for example, if a setting in Default Domain Policy conflicts with a setting in Disk Quota (Accounting), then the setting in Disk Quota (Accounting) will win.

By contrast, after we set Block Inheritance, we can see that the higher-level GPOs no longer apply to the Executives OU:

As can be seen from the screenshot above the previous policies in the Group Policy Inheritance tab are missing.  I have also created a new GPO called Audit Accounting Events and linked it directly to the Executives OU (if I had not created this new GPO linked directly to the Executives OU, the Inheritance tab would have been blank.

Now that blocking is in place, only the policies specifically defined for the Executives OU will be applied (again in bottom-to-top order if more than one GPO is linked directly to this OU).  You will also note that there is now a blue circle with an exclamation point showing next to the Executives OU.  This is how the GPMC notifies you that Block Inheritance is in effect.

For the sake of clarity, let's look at one final screenshot to clear away any lingering questions.  We've said that any inherited GPOs are blocked when Block Inheritance is set.  But even with this setting in place, child OUs created beneath the blocking point will still inherit everything from that point on down.  In our example, this means that if we create a child OU under the Accounting OU, it will inherit the policies created at the Accounting OU as well as any GPOs linked directly to the child OUs.  We can see this in the following screenshot:

Here you can see that I've created a child OU beneath Executives called Executives - Europe along with a new GPO called Retain Security Events (maybe we've got a security investigation going on in our European office and we have to be sure that security log isn't overwritten).  You can see from this screenshot above that, even with Block Inheritance set, the GPO from the Executives OU (though none above the Executives OU) still inherit to the Executives - Europe OU and are applied from bottom to top so that the GPO linked directly to the Executives – Europe OU takes precedence.

Finally, to throw one more bit of complexity into the mix, let's assume that you're the domain administrator and you want to make sure that none of the admins responsible for any of your child OUs is able to block a particular GPO (you’re not a big fan of them choosing to block your GPOs at the Executive OU level).  It turns out that you have the ability to force all of your clients to receive your policies even if they want to block them.  This process is called Enforcing.

Looking at the screenshot below, we can see that if we want to enforce a particular policy, we just need to right-click it and choose the Enforce option (note, this is done on a per-policy level so every policy you wish to be enforced will have to be configured this way individually).  When we do this, a small lock symbol will appear beside that GPO to let us know it's being enforced.

Once a GPO is enforced, it overrides any attempts to block it, as we can see below.  Here, the Executives OU still has blocking set but we can now see that the Default Domain Policy is once again being processed within that OU.  To help us to understand why it's being processed even when blocking is in place, the GPMC notifies us that it's being (Enforced).

Before leaving the topic, here are a couple of additional notes about enforcement.  First, when a policy is enforced, its settings will be applied last as the screenshot above shows.  This means that it will override even GPOs that are created and linked closer to where the user or computer object is located.  If it contains a setting and a GPO closer to the client object contains a conflicting setting, the enforced setting will win.

Second, if you have multiple enforced policies the one higher up the OU tree will have its settings enforced over ones lower in the tree structure.  To illustrate this, look at the following screenshot.

In the screenshot, you can see that the order of precedence is actually reversed from what you would expect (where the GPO closest to the client object is applied last).  Instead, these rules apply:

1. GPOs without enforcement set are applied first, using the normal precedence rules
2. GPOs with enforcement set are applied last, with their precedence rules reversed

For our example, the Executives – Europe OU applies its GPOs as follows:

1. Audit Accounting Events (inherited from the Executives OU)
   1. Note that due to blocking being in place we do not start with GPOs higher than the Executives OU in this case
2. Retain Security Events (linked directly to the Executives – Europe OU)
3. Event Log Size (linked to the Computers OU)
4. Default Domain Policy (linked at the domain level)

The normal order of precedence  is in effect until the enforced GPOs are considered and then the order is reversed for each enforced GPO (note the GPOs above the point of blocking which are not enforced are never processed).

Resultant Set of Policy

Resultant Set of Policy is the phrase that is used to indicate which policies apply to client machines and users.  When the settings of all your GPOs have been sorted out and the system knows which policies need to be applied based on the rules you've put in place, the Resultant Set of Policies is that list of settings.  In this section, we're going to spend a bit of time talking about two tools that will help show you what policies will apply to a particular client.  One of them even allows you to model which settings will apply before you put them into production, so it serves as a great planning and troubleshooting tool.

GPRESULT

I'll start with GPRESULT because it's been around longer and is the command-line tool you'll use to see which policies are applying to your clients.  GPRESULT was originally included as part of the Windows 2000 Resource Kit, but is present by default starting in Windows 2003 and continuing in Windows 2008/R2 and 2012/R2.  You can read about the various things you can do with this tool by opening a command prompt and typing

gpresult /?

While GPRESULT can be used for multiple purposes, our need here is to generate Resultant Set of Policy data.  Specifically, we're going to look at the following combinations of commands:

gpresult /R

By using the /R switch with nothing else, summary data for the various policies and settings will be printed to your command prompt.

gpresult /V

This is the same as the /R command, only the results will be verbose.

If you don't want all of the settings, you can set the /SCOPE option and choose either USER or COMPUTER, which will result in only the User or Computer node settings being returned.

If you want to save the results to a file, you can do so by either piping the results to a text file using a command similar to gpresult /R>c:\gpresult.txt.  Another option is to create your output in HTML format by typing gpresult /H <filename.html>.

To get the Resultant Set of Policy (RSOP), I will run the following:

gpresult /R>c:\scripts\gpresult.txt

I will also run it a second time and specify the output should be HTML format using the following:

gpresult /H>c:\scripts\gpresult.html

Below are sample outputs in both the .txt and .html formats

GPResult.txt

GPResult.html

Resultant Set of Policy (RSOP)

The newer tool that's been created specifically to see Resultant Set of Policy for your client is called, oddly enough, Resultant Set of Policy.  You access this tool by taking the following steps:

1. From your client machine, go to Start/Run and open a blank MMC by typing mmc.exe.
2. Within the blank MMC console go to File and choose Add/Remove Snap-in....
3. From the Add or Remove Snap-ins window, scroll down until you see the Resultant Set of Policy snap-in.  Highlight it and select the Add button.

Select OK and you'll be looking at the Resultant Set of Policy tool.  Not much shows in the window at first, but we'll quickly change that.  To see policy settings, the tool will need to gather data.  It does this through a wizard that is started when you select Action from the menu bar and choose Generate RSoP Data...

When generating your RSoP Data, you can choose Logging or Planning mode.  If you choose Planning mode, the system will show you what settings would apply if an object were located at a particular place in your directory structure.  This is a great "what if" tool in cases where you're considering migrating objects to new containers within Active Directory and you want to know what effect this will have on them from a Group Policy perspective.  Planning mode is also great in a test environment where you've configured the directory and GPO structure that you think will do what you need.  Using this tool, you can generate the resultant set of policy which will show you the settings that will take effect on your client objects.  If the settings aren't what you expect, you can make the necessary changes and test again.

The other way to use the Resultant Set of Policy tool is in Logging mode.  This mode will review the settings currently being applied to a particular computer or user (or both).  You can select either the local computer or a remote device and when the wizard runs the results will display the resultant policy settings that are applying to that device.  This is especially useful when you're trying to understand whether a particular setting should be applying to a computer or user.  If RSOP doesn't show the setting, it may mean something has happened in your GPO implementation that is preventing that setting from taking effect.

A screenshot of what the RSOP tool looks like is below:

Resultant Set of Policy is a powerful tool that is especially useful in understanding ahead of time what settings will apply to objects before you make modifications to your directory.  It is also very useful as a diagnostic and troubleshooting tool (though I personally prefer GPRESULT since I don't have to drill down through as many containers if I'm looking at the report in the command line or a text file).

Summary

So now you should understand how a GPO determines which GPOs it should process and how to find them (through the gPLink attribute).  You should also understand the order in which they are processed, how decisions are made about which policy settings to apply when there are conflicts, and how to block and enforce settings within your environment.  I also showed how to use a couple of tools to see which policies should be applying to your GPOs, which will be helpful to you when understanding and troubleshooting policies in your environment.

In the next post I'll finally get to Client-Side Extensions (CSEs) and we'll try to wrap this series up.

As a Windows administrator, you almost certainly have used Group Policies to control the settings deployed to the clients of your Active Directory infrastructure.  But with Group Policies getting such heavy use, not as many administrators fully understand how Group Policy Objects (GPOs) are structured.  In this post, I will discuss the structure of GPOs in order to help bring greater understanding to this topic.  When you're troubleshooting Group Policies in your environment, it's helpful to understand how they're structured, and hopefully this post will clear up a bit of that mystery.

Group Policy Objects are actually composed of two parts, the Group Policy Container (GPC) which exists in Active Directory and the Group Policy Template (GPT) where the actual content of your GPOs resides.  A third component, known as Client-Side Extensions (CSEs) can be found on client devices and are necessary for them to properly process the Group Policies assigned to them.

Before we go through these individual pieces, take a look at how GPOs show up when viewed through the Group Policy Management Console (GPMC).

In the early days of Active Directory, the only real way to get to a GPO was to open the location where it was linked (a domain, organizational unit, or site).  This made it appear that the GPOs existed at those place in the directory when they were actually only linked to those locations so that their settings would apply to the specified objects they contained (such as the computer objects within a particular OU).  With the GPMC, it's much clearer to see that GPOs do not reside at these different points of the directory but instead exist separately and are only linked to these different levels.

To see an example of where a GPO is linked, you can check the Scope tab of your selected GPO within the GPMC, as shown below.

You can see from this picture that the GPO I created named Event Log Size is linked to the Computers OU within the cert.local domain.  You can further see that the link is enabled (meaning the policy will apply), but it is not enforced (meaning that the policy can be blocked if the administrator of the Computers OU wishes to prevent the policy applying).

But even the GPMC's view of where GPOs reside is a bit misleading as there really is no Group Policy Object container in Active Directory.  Instead, the actual structure of the GPO is laid out as follows.

Group Policy Container (GPC)

The first piece of the GPO, while not within a container called Group Policy Objects, is still found within Active Directory.  In order to see it, there are several options.  The most common is to use Active Directory Users and Computers.  If you choose this tool, you'll need to take the following steps to see the appropriate folder:

1. Open Active Directory Users and Computers (you can do this by typing DSA.MSC at Start/Run)
2. Select View from the menu bar and ensure Advanced Features is selected (if not, select it)
3. Expand the System container and navigate to the Policies container

If you don't enable Advanced Features, you won't see the System container.  But after this is enabled, you should have a screen similar to the one below:

Notice that there are three containers, each with a string of numbers.  Each of these represents a different GPO (the string of numbers is the Globally Unique Identifier, or GUID, of each GPO).  Within each of these containers you'll see a Machine and User container.  These contain specific information related to the User and Machine nodes of the GPO itself (as you might expect, the Machine node refers to computer settings and the User node refers to user settings).

NOTE: To be clear, a GPO can apply settings to both computer and user objects in Active Directory.  It is customary to have a GPO apply to one, but not both, of these.  There are separate groupings for users and computers available in each GPO as we will see later.

Another tool that you can use to view these folders is LDP.  To use LDP to see these folders, take the following steps:

1. Start LDP by typing LDP.EXE at Start/Run
2. Select Connections from the menu bar and select Connect... to connect to the Domain Controller of your choice.  Select OK
   1. enter the fully qualified domain name of the Domain Controller
   2. enter port 389 since you're doing an LDAP query
3. Select Connections again and choose Bind...
   1. Make sure you are binding to the directory with an account that has sufficient permissions to do an LDAP query
4. Select View and choose Tree.  Enter the distinguished name of your domain (for example: dc=cert,dc=local).  Select OK
5. In the left-hand column, expand the directory tree and navigate to Policies under the System container

There is one big difference when using LDP, which becomes immediately obvious after selecting one of the GPO nodes.  When you double-click it, you will suddenly see a great deal of information in the right-hand pane.  This is the critical directory information that client machines use when processing GPOs.  These settings allow clients to understand where the content of the policy is, which Client-Side Extensions will be needed to process the GPO content, etc. (all of this will be explained as we proceed, so if you don’t understand any of this yet, don’t worry)

Here is a screenshot of what you'll see within the LDP window:

Looking at the details of our selected GPO, there are several attributes which are of special interest to us:

• displayName: This attribute is the human-friendly name of your GPO
• gPCFileSysPath: This attribute points clients to the location where the GPO content can be found.  Collectively, this is known as the Group Policy Template, which is housed in a share known as SYSVOL
• gPCMachineExtensionNames: Here is the list of Client-Side Extensions (CSEs) that will be needed by the client in order to process all of the machine-side settings configured for this GPO
• gPCUserExtensionNames: This attribute contains the list of CSEs that will be needed to process the user-side settings.  As there are no user-side settings configured in this GPO, the attribute is not populated (and thus not displayed)

Another important attribute is gPLink and while it's not found as part of the GPO itself, you can find this attribute everywhere that the GPO is linked.  This allows objects within these other containers to know that there is a GPO it needs to process.  In the screenshot below (just showing the right-hand pane of LDP), you can see that the gPLink attribute points to a single GPO found within the policies container of the system partition:

From this, we can see that we are looking at the attributes of the Computers OU which is a child of the Lab OU (OU=Computers,OU=Lab).  By checking the GUID of the GPO(s) listed in gPLink, we can easily tell which GPOs are linked to this OU.

So now we've seen the Active Directory portion of the Group Policy object.  It contains settings so that the client can learn which GPOs it must process, which tools it will need to process them (which Client Side Extensions), and how to locate the GPO contents in order to process them.  From here, let's take a look at how and where the GPO content itself is stored.

Group Policy Template (GPT)

The Group Policy Template is where the meat of the GPO resides.  By way of comparison, think of how Active Directory represents a computer object.  It lists all the relevant attributes of the computer, but the object in Active Directory is not the computer itself.  In a similar way, the portion of the GPO in Active Directory merely represents the attributes relevant to the GPO content.  The content itself is known as the Group Policy Template, or GPT, and it resides in a share known as SYSVOL.  This share, like the portion of the GPO stored in Active Directory, is replicated to every DC in the domain.  This way, when a client queries for the GPOs it needs to process, it can locate the contents of those GPOs on the same (in most cases) DC where it's conducting the query.

NOTE: The only exception to this rule is cross-domain GPOs where a GPO is defined in another domain, but is linked in such a way that clients from neighboring domains need to apply them (a Site-level GPO is an example, since Active Directory Sites can span multiple domains).  In the case of a cross-domain GPO, the client will need to pull content from a DC in the neighboring domain which can be a very slow process.  For this reason, cross-domain GPOs are not generally recommended.

To see the content of your GPOs, you'll want to look at the SYSVOL share on one of your DCs.  You can find the SYSVOL share by navigating to %windir%/sysvol/sysvol (yes, there is a shared SYSVOL folder within a parent SYSVOL folder).  The actual sysvol share is set to \\<servername>\sysvol  as can be seen if you type NET SHARE within a command prompt window:

Within the SYSVOL folder, you will see the same list of GPOs that appear within Active Directory's System/Policies container.  These folders are where the actual settings of your GPO are contained.  Depending on the number of settings you've put in place, there will be more or less of them present in each folder.  Regardless, you are guaranteed to have at least the following folders/files within each of your GPOs:

• %windir%
  • sysvol
    • sysvol (shared as \\servername\sysvol)
      • <domain name>
        • Policies
        • scripts

Within the policies folder, you'll find the various GPOs and their configured settings.  Again, the following folders/files are guaranteed to be present for every GPO in your domain:

• Policies
  • <GPO GUID>
    • Machine (folder containing the computer-side settings of the GPO)
    • User (folder containing the user-side settings of the GPO)
    • GPT.INI (file containing the GPO's configuration settings)

Depending on what you've configured, the Machine and User folders may or may not contain additional content.  As an illustration, lets take a look at the contents of a GPO I've configured to set the various Event Logs on my clients to their maximum size.  First, here is the Group Policy Management Editor showing the settings I've configured.  This is the tool you'll be working with when you configure the settings for your own environment.

If you need to know how to launch this tool, you do so from within the Group Policy Management Console by right-clicking your GPO and selecting Edit... as shown below.

So now that you understand how to make these changes, what does the GPT look like once you've made them?  Below is a series of screenshots to answer that question.

First, here is the file structure of the GPT, showing the GPO I've edited with its top level folders visible in the right-hand pane

You'll notice the file called GPT (it's actually GPT.INI, though the screenshot hides the file extension).  This file contains the configuration settings for this GPO, which includes its current version number (which is updated every time a change to the GPO is made) and the default GPO display name (which is the same for every GPO you create, so don't worry that it's not the name you gave it in the GPMC).  Here is how that file looks (NOTE: You can open GPT.INI with Notepad, but make sure you don't accidentally save it as a .txt file or it will impact your GPOs ability to do its job)

To see the actual settings we've configured for this GPO, we need to expand the Machine folder (because this is a computer-side setting), which reveals the following:

You'll notice that there is a folder called SecEdit, which contains the security-specific settings of this GPO.  The file within the SecEdit folder is GptTmpl.inf.  It's this file that contains the specific information that your client needs to configure its settings.  Because we've configured this GPO so that its Event Logs are set at the maximum size, we would expect that this file would contain information directing the client to make this change.  By opening the file we can see that its contents do exactly as we would expect, as shown below (NOTE: you can edit it with Notepad, but make sure you don't accidentally save it [or GPT.INI] as a .txt file after looking at it!).

We can see from this picture that GptTmpl.inf has clear instructions for our client machine to set its Application, Security and System Event Logs to the size we have specified.

Summary

In the present article, I have attempted to outline the first steps that an administrator needs to know in or to get his hands around administering Group Policies in Active Directory Domain Services.  In part 2 of this series, we'll look at details of GPO processing, with an emphasis on Client-Side Extensions (CSEs).  We'll also discuss how GPOs are replicated, and how a client knows it's getting the latest version of its GPO (including knowing whether the GPC and GPC are synchronized with each other).

In my earlier post, I showed how to add an attribute to the Partial Attribute Set (PAS) in Active Directory.  But how can you tell which attributes are already part of the Partial Attribute Set in the first place?  You can certainly check each one manually, but that will take forever.  Is there any other way that's more convenient?

In fact, let me show two ways to do it that will make life a great deal easier.

USING LDP

The LDP utility is a graphical LDAP tool for use with Active Directory that allows us to perform very granular searches against Active Directory.  It was first made available in the Windows 2000 Support Tools, but is included with Windows 2008/2012 and is available if you have Active Directory Domain Services installed as a role on your server.

To use LDP to list the attributes in our Schema that belong to the Partial Attribute Set, we want to take the following steps:

• Open the LDP utility by going to Start and entering LDP in the initial search window.  By default, it will look like this (not much, right?):

• Connect to a Domain Controller by selecting Connection and choosing Connect...
  • In the Server field, type the fully qualified domain name of the Domain Controller we are connecting to.
  • In the Port field, enter 389 (since we are doing an LDAP query, not a Global Catalog query)

At this point, the information we have entered looks like the following:

Once we select OK, we will see the RootDSE information on the right-hand screen.  This information contains the top-level information about AD DS for our local domain controller and can be useful in understanding the basics of our directory structure.  The screenshot below shows my lab DC after I’ve connected.  On the right-hand side is the RootDSE information:

At this point, we've connected, but we still need to authenticate to Active Directory.  To do this, we'll do an LDAP Bind.

• Select Connection again in the menu bar and this time choose Bind...
• Choose how we want to bind to Active Directory.  The screenshot below shows the choices I made for my example:

Note that in my case, I’ve chosen to bind with the credentials I’ve used to log on.  It is also possible to bind with other credentials, perform a simple bind, etc.  Another thing that is recommended is that after binding, all further traffic is encrypted (the default).  Though this is not strictly required, it is the more secure option so we’ll leave it checked and select ‘OK’.

Once we have successfully bound to the directory, we will see information similar to this on the right-hand pane:

If any other type of message is returned, we likely have not used the right credentials and will need to get that resolved before proceeding.

At this point, we have connected to our DC and have successfully completed an LDAP bind to authenticate against the directory.  Now it's time to do what we came for.

To use LDP to find out which attributes belong to the Partial Attribute Set, take the following steps:

• Go to Browse in the menu bar and select Search (Ctrl+S)
• In the resulting Search window, enter the top of the search tree (where our search will begin) in the Base DN field.  This will take the form of: CN=Schema,CN=Configuration,DC=<domain component>,DC=com
• We will also enter our query into the Filter field as follows: (&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))
• In the Scope, we want to select Subtree.  In Attributes we will select whichever attributes we wish to be displayed (for example, if we want only the name of the attribute displayed in your list, enter 'name').

The resulting window is what we come up with after entering this information:

• If we want to increase the default page size, you can select Options and enter 9999 in the Page size field of the resulting Search options window.

• Select Run to execute your query.

When your query runs, every object that is part of the Partial Attribute Set (which has its attribute of isMemberOfPartialAttributeSet set to TRUE) will be displayed as shown by the sample of my output below:

USING LDIFDE

For those that prefer to work from the command line or within PowerShell (yes, we can run LDIFDE from the PowerShell console), we can also use the LDIFDE tool to query Active Directory for this information (personally, I like LDP but I admit that getting around in it can be a bit challenging at time).  When using LDIFDE, the actual content of the query is largely the same as outlined above, though we'll need to know how to get LDIFDE to give us the output we desire.  And if we’re dealing with a lot of information that we need to work with over time, LDIFDE is the preferred method of gathering this information.

To query Active Directory via LDIFDE, open a command prompt or PowerShell console (we'll once again need to make sure we’re using elevated credentials) and type the following:

LDIFDE -s <fully qualified server name> -d <Base DN> -r <search criteria> -l <list of attributes to export> -f <file name where the query will be written>

On my server, the command looks as follows:

A couple of comments about running LDIFDE:

• -s is not a required parameter if we are querying the local computer.  It is always an option, but is typically used if we are querying remote instances of Active Directory
• -d is the distinguishedName that I am searching.  In this case, I am searching the entire Schema container (and note that while cn=Schema makes it appear that it is a child of the Configuration container, it is actually a separate partition and does not replicate as a component of the Configuration partition)
• -r provides us the search criteria for the information we’re seeking.  In my example, I have specified only objects of the ‘attributeSchema’ class (yes, there is an object type that specifies attributes…a little confusing, maybe, but necessary).  I have also specified which particular attribute of the attributeSchema objects I am interested in.  In this case, I want only those where the attribute ‘isMemberOfPartialAttributeSet’ is equal to TRUE
• -l lists the attributes I want returned.  So in my present example, if I find an object of the attributeSchema class with the attribute ‘isMemberOfPartialAttributeSet’ equal to TRUE, I want to list its CN value
• -f specifies the file where my output will be stored

As can be see from the screenshot above, running this command returned 196 entries.  Below is a screenshot of a sample of those entries as found in the pas.txt file created by LDIFDE:

Note that this information contains the distinguishedName of the attribute even though I did not specifically ask for it.  The output also takes the form of an LDF file, which is used to update and modify Active Directory objects.  The ‘changetype’ entries for each of the returned objects specifies what LDIFDE would do if I attempted to import this file.  It would attempt to add these objects into Active Directory (since they are already present in AD DS, the operation would fail, but the export assumes I might want to use this file to do an import later, so it sets this value for me).

Summary

Either way that we choose to determine which attributes are members of the Partial Attribute Set, we'll find that both LDP and LDIFDE have numerous uses in our day-to-day work as an Active Directory Administrator.  This is just one example of how much value these tools can provide.  Even if we don’t ever want to look up or modify the Partial Attribute Set, every AD DS administrator would be very wise to know both of these tools if we're to optimize our efforts in supporting our Active Directory infrastructures.

In the past, while working with a customer who was trying to understand why a Global Catalog query might be taking longer than expected, a question came up regarding the Partial Attribute Set (or PAS as it’s often called) and what it is exactly.  Because not everyone understands this concept, I thought I'd write up a quick post about it.

To begin, Active Directory is designed so that the objects you need (users, groups, computers, printers, etc.) don't just sit on one computer.  Instead, they are replicated throughout the Active Directory domain so that users in California can access a Domain Controller in Los Angeles and see the same objects as the user logging into a Domain Controller in New York.  If you have only a single Active Directory domain, these objects will be replicated to every Domain Controller in that domain automatically.

Having said that, the Active Directory forest for many large companies comprises more than one domain.  And if you have a large enterprise with multiple domains, an added layer of complexity is introduced that administrators must be aware of.  Because the amount of data within an AD DS domain can be quite extensive (hundreds of thousands, or even millions of objects), Active Directory is designed to replicate these objects only to Domain Controllers within the same domain.  If another domain exists, the Domain Controllers for that other domain will not receive a copy of that information.

Partitions and Directory Replication

Before I proceed, let me clarify that last statement a bit.  Active Directory (AD DS) is based on something called the multi-master model.  This means that every Domain Controller within the replication scope of the objects it contains will all receive a copy of those objects.  These objects will be identical (once replication completes) on every Domain Controller receiving a copy of the object.  Because the potential exists for large directories to consume a great deal of network bandwidth (not to mention dramatically growing the size of the NTDS.DIT database on each Domain Controller), Active Directory limits replication of its directory.

To make replication more manageable, AD DS breaks its directory up into categories of data.  Depending on which category the data belongs to, its replication scope will either be Domain or Forest-wide.  The following table explains this:

If you ever want to see these partitions directly  to determine what each contains, the ADSI Edit tool is a good way to view this.  From a Domain Controller or an admin workstation where the AD Tools are installed, open ADSI Edit as shown below:

From here, right-click the ADSI Edit icon in the left-hand pane and select ‘Connect to…’ option and the following window will open:

By choosing the drop-down list under ‘Select a well known Naming Context’, you can connect to the Domain, Configuration and Schema partitions residing on the DC you’ve chosen (though it’s hidden by the window in the picture, you can also use this window to select either the DC to which you are currently logged on or another DC in your forest)

NOTE: The Naming Context known as RootDSE is not a specific partition as such.  Instead, it represents the root of the Directory Information Tree (the DIT) for a Domain Controller.  It contains basic information about the directory server, its capabilities and configuration.

To see the information in one of these naming partitions, select it and it will be populated into ADSI Edit.  From there, left-click the parent node and it will be possible to expand the partition to see and manipulate the data within it.  In the screenshot below, I have selected the Default naming context (the Domain partition) for my local DC:

For those familiar with Active Directory Users and Computers (ADUC) or the newer Active Directory Administration Center (ADAC), this structure will look familiar.  One essential difference, however, is that ADSI Edit represents all directory objects using their distinguishedName format (for example, OU=Lab versus just Lab in ADUC).

Note: We can also use ADSI Edit to connect to the application partitions as well, but that takes a few more steps than the ones listed above.  For those interested, I will include those details in an upcoming blog so stay tuned.

Searching for Objects in Multiple Domains

As I’ve mentioned above, in order to reduce the size of the Active Directory database and limit bandwidth due to replication, the objects within the Domain partition (also known as the Domain Naming partition) are only replicated within their own domain.  So if you have two domains, USA and EUROPE, the users in the USA domain won't appear in the EUROPE domain and vice versa.  Configuration and Schema objects will be replicated into both of these domains because their replication scope of forest-wide, and depending on how the Application partition is defined it can also be replicated between forests.  But for our present discussion, we care about information in the Domain partition.

What happens if a person in the EUROPE domain needs to look up a user residing in the USA domain?  If she is an administrator, she has the choice of connecting to a Domain Controller in the USA domain, which could result in a slower response time (and this is not something average users will know how to do).  But if she is not an admin and is using standard search tools (such as her contacts list in Outlook) and has only domain controllers in her local domain to query, all she will get is the users in her own domain.

The Solution: Global Catalogs

The Global Catalog in Active Directory Domain Services (AD DS) a specialized type of Domain Controller that contains the full copy of the objects from its own domain, just like any other Domain Controller in the domain.  In addition, however, Global Catalogs also contain a read-only copy of the objects belonging to the Domain Naming partition from every other domain in the forest (there is no need to do this with the Forest and Configuration partitions as these are already replicated forest-wide, and each Application partition is replicated based on what you specify).  Given this, the user in EUROPE could simply query the Global Catalog (using port 3268 versus the standard LDAP port 389) in order to see the user object from the USA domain (applications such as Outlook do this by default so there is no need to take special steps in most cases).

So far so good.  This is a well-understood concept by most Active Directory administrators.  But what if this user in EUROPE wants to look up a particular attribute about the user in USA and she finds that the attribute she's interested in is not there?  If she looks up this attribute for users in EUROPE she can find it, but she can't see it if she's querying the user in the USA domain.  This is where the Partial Attribute Set (PAS) comes in.

Remember how I said that the Domain Naming partition is only replicated within the domain to preserve space and bandwidth?  As it turns out, the PAS is also used to help preserve space on the Global Catalogs in the forest.  To do this, AD DS designates only certain attributes to replicate to each Global Catalog.  To clarify, every Global Catalog contains a full writeable copy of the Domain Naming partition from its own domain.  This includes every attribute of every object in the Domain Naming partition.  But when it comes to the objects in the Domain Naming partition from other domains, only certain attributes (those belonging to the Partial Attribute Set) are replicated between domains.  This list includes the majority of attributes that your users will ever want, but it won't include things like certain system attributes, custom attributes defined by your business, etc.

To give an example of the difference when querying an object residing on the local domain controller versus the read-only copy of the same object as seen from a Global Catalog in another domain, consider the following list of attributes:

ATTRIBUTES FROM A STANDARD LDAP QUERY

dn: CN=scott,OU=Users,OU=Lab,DC=cert,DC=local
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: scott
givenName: scott
distinguishedName: CN=scott,OU=Users,OU=Lab,DC=cert,DC=local
instanceType: 4
whenCreated: 20150226135445.0Z
whenChanged: 20150226140527.0Z
displayName: scott
uSNCreated: 12733
memberOf: CN=Domain Admins,CN=Users,DC=cert,DC=local
memberOf: CN=Enterprise Admins,CN=Users,DC=cert,DC=local
memberOf: CN=Schema Admins,CN=Users,DC=cert,DC=local
uSNChanged: 12837
name: scott
objectGUID:: UDm/YKSQU0qG8Uvq6Is8xA==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 130695726274467027
pwdLastSet: 130694324858513594
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAoDvDG0e5tebi0eW1UAQAAA==
adminCount: 1
accountExpires: 9223372036854775807
logonCount: 12
sAMAccountName: scott
sAMAccountType: 805306368
userPrincipalName: scott@cert.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=cert,DC=local
dSCorePropagationData: 20150226140527.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130694326252478417

Now, compare this to the list of attributes when querying the same object on a Global Catalog.

ATTRIBUTES FROM A GLOBAL CATALOG QUERY

dn: CN=scott,OU=Users,OU=Lab,DC=cert,DC=local
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: scott
givenName: scott
distinguishedName: CN=scott,OU=Users,OU=Lab,DC=cert,DC=local
instanceType: 4
whenCreated: 20150226135445.0Z
whenChanged: 20150226140527.0Z
displayName: scott
uSNCreated: 12733
memberOf: CN=Domain Admins,CN=Users,DC=cert,DC=local
memberOf: CN=Enterprise Admins,CN=Users,DC=cert,DC=local
memberOf: CN=Schema Admins,CN=Users,DC=cert,DC=local
uSNChanged: 12837
name: scott
objectGUID:: UDm/YKSQU0qG8Uvq6Is8xA==
userAccountControl: 66048
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAoDvDG0e5tebi0eW1UAQAAA==
sAMAccountName: scott
sAMAccountType: 805306368
userPrincipalName: scott@cert.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=cert,DC=local
dSCorePropagationData: 20150226140527.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130694326252478417

The difference in these lists is that only the attributes belonging to the Partial Attribute Set for user objects is populated in the Global Catalog's copy of the Administrator account.  And if you want to try this test yourself, all that’s needed is to run the LDIFDE command line tool that is present on every Domain Controller and can be added to administrator workstations.

For the standard LDAP Query (the one connecting to the writeable Domain Naming partition in my local domain), I used the following LDIFDE command:

ldifde -f c:\scripts\output-389.txt -d "CN=scott,OU=Users,OU=Lab,DC=cert,DC=local" –t 389

When doing a Global Catalog query, my LDIFDE command line looked like the following: 

ldifde -f c:\scripts\output-3268.txt -d "CN=scott,OU=Users,OU=Lab,DC=cert,DC=local" –t 3268

To understand the parameters I used, consider the following:

• -f is the parameter which allows me to specify the filepath where I will store the output of the query.  The name I chose is entirely up to me.  In each case, I specified which port I was connecting to so that review of the results would be easier to interpret.
• -d is the distinguished name I queried (known as the RootDN in the help files).  If I had instead chosen to query a higher-level portion of the directory tree (such as OU=Lab,DC=cert,DC=local) I would have gotten the information for that object plus every object beneath it.  In my case, I only wanted a single object (CN=scott) so I queried that object specifically.  Since there are no child objects beneath CN=scott, only one object is returned.
• -t is where I specify the port I am querying.  In the first query, I specify the standard LDAP port (389) and in the second query I specify the GC port (3268).  This allows me to see the full set of populated attributes versus the list of attributes replicated to the read-only copy of the Domain Naming partition contained by the Global Catalog

NOTE: In my test, I used a single Domain Controller for both queries.  My lab has only a single domain and I was still able to see the differences between querying the writeable copy of the Domain Naming partition and the read-only copy present in the Global Catalog.

Extending the Partial Attribute Set

So now we understand the difference between the Domain Naming partition and the read-only copy sent to all Global Catalogs.  But what if we need to include some additional attributes in the Partial Attribute Set? For example, what if there is an essential attribute needed by our employees in every domain of our forest?  How do we get that attribute to replicate to the Global Catalog?  In this case, if we need additional attributes to be replicated as part of the PAS, we can make this change fairly easily in the Active Directory Schema (NOTE: Do not make any changes in the AD Schema without thoroughly testing it in a non-production environment). 

Below is a step-by-step description of how to tell whether an attribute is part of the Partial Attribute Set and how to change it if needed.  To do this, we will need to use an account that is a member of the Schema Administrators group.

• Connect to the Domain Controller that houses the Schema Master role for the forest (all Schema changes must be made on the DC housing the Schema Master FSMO role)
• Before doing anything else, make sure that the Active Directory Schema snap-in is available.
  • Open a blank MMC window by typing mmc.exe from the Run window.
  • Within the MMC that opens, select File and then Add/Remove Snap-in.
  • From the resulting list, look for Active Directory Schema as shown below:

• If the snap-in is not present (as is the case in the screenshot above), type the following in a an elevated command prompt:

regsvr32 schmmgmt.dll

• If successful, the following window will be displayed:

• Once this has been run, check again under Add/Remove Snap-in and Active Directory Schema will now be available:

• From within the Active Directory Schema snap-in, navigate to the Attributes folder and scroll down on the right to find the desired attribute.  In our example, perhaps the ‘drink’ attribute is considered essential (it’s a bit unusual, I admit, but never overestimate what may be considered essential to a company)

• Right-click the attribute and select Properties.
• In the resulting window, select the check box that says Replicate this attribute to the Global Catalog and select OK to close the window.

Selecting this checkbox adds the attribute to the Partial Attribute Set so that it is now included when an object is replicated to the Global Catalog

• Repeat this process with any additional attributes that need to be added to the Partial Attribute Set

Once these changes have been made, we will need to allow time for replication to complete (remember that the Schema must replicate to every Domain Controller in the forest and depending on the scope of the forest, the replication topology, etc. this may take some time).  Once replication is completed, we will want to use LDIFDE to query again as we did above to verify that the new attribute is now part of the Partial Attribute Set.

Summary

In this article, I have outlined how Global Catalogs provide read-only access to the Domain Naming partition for every domain in an Active Directory (AD DS) forest.  I have shown how to identify the differences between querying the Domain Naming partition with LDAP and the read-only partition of the GC via port 3268.  I have also shown how it’s possible to add (or remove) attributes from the Partial Attribute Set.  Typically, these changes are not needed, but if there is a compelling business reason to make such a change, the functionality is available.

Always remember when making Schema changes, it is essential to use precautions and test thoroughly in a non-production environment before implementing in production.

Compliance Reporting

First of all, let’s talk briefly about Compliance reporting in ConfigMgr 2012.  I include this only for those who are unsure what I’m talking about when I use this term.  If you're familiar with Compliance reporting, feel free to skip to the next section.

For those of you who are still reading this section, ConfigMgr comes with a fairly extensive set of pre-configured reports to provide information about the state of your infrastructure.  There are different types of reports to become familiar with, but the ones we care about here can be found under Monitoring\Reports\Software Updates A - Compliance as shown below:

If you don’t see this in your environment, it’s likely you are either viewing a Site Server that is not set up with the Reporting Service Point role.  If this role is set up on another Site Server in your environment, target the Admin Console there instead.  If not, the following article goes through the process of setting up Reporting Services in your ConfigMgr hierarchy:

Configuring Reporting in Configuration Manager

Once reporting is set up correctly, it’s trivially easy to select one of the Compliance reports, fill out the requested information, and get the desired results.  Sometimes, however, the results in the report might not reflect what you know to be the case in your environment.  As an example, suppose that you have devices that are candidates for Office 2013 Service Pack 1.  The Compliance reports should show this to help you plan for rolling out this update as needed.

In cases like this, the very first thing to do is determine whether the issue is restricted to reporting when viewed through ConfigMgr.  To verify this, the following test can be done:

Open Internet Explorer on the Reporting Services Point and navigate to https://<servername>/reports as shown below:

Select the parent folder (in my lab, ConfigMgr_PR1) to see a complete list of available reports:

If so desired, you can choose the ‘Details View” on the right-hand side.  I find this to be helpful when navigating reports in Internet Explorer, though it’s only my preference:

Select the folder containing the report of interest, which in our case is Software Updates A – Compliance and choose the report of interest:

By selecting the individual report, it is possible to see whether the discrepancy noted in ConfigMgr is also showing when viewed through the native reporting view.  If the discrepancy is limited to ConfigMgr, then other methods of troubleshooting may be necessary.  But in our case, the same information should be showing regardless of how we view the report.

The Reason for the Problem

Reports in ConfigMgr can only tell about things they know.  The way ConfigMgr determines what should be in a report is through state messages sent by its managed devices.  The state messaging system is fairly complicated, though an excellent blog that goes into this in some depth can be found here (full disclosure, this blog is about SCCM 2007, though the process is very similar).

The idea is that for some reason or other (network hiccup, etc.) the state messages relating to a particular compliance setting did not make it to the Site Server, which has resulted in the Compliance report showing inaccurate information.  By default, state messages should be resent every 30 days from all managed devices so any issues detected should resolve themselves over time.  But in practice, I have found that sometimes it’s necessary to give the state message system a jump start in order to resolve the reporting discrepancy.

The Traditional Solution

It’s a fairly straightforward idea to resolve the reporting discrepancy.  Somehow, we need to tell the managed devices which are showing incorrect information to resend their state messages and hopefully resolve the issue.  Traditionally, this has been done through a script available via MSDN:

How to Refresh the Compliance State

In reading the article, we can see that it was written for SCCM 2007 but I can personally attest that the script it contains (at least the VBScript, since I have not tested the C# code) still works in ConfigMgr 2012 R2.  As the article also explains, the purpose of the script is as follows:

“In Microsoft System Center Configuration Manager 2007, you refresh the client compliance state by creating an instance of the UpdatesStore COM class and by using the RefreshServerComplianceState method. This causes the client to resend a full compliance report to the Configuration Manager 2007 server.”

The script which is typically used is as follows (taken directly from the MSDN article with only the comments removed):

Sub RefreshServerComplianceState()
   dim newCCMUpdatesStore
   set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
   newCCMUpdatesStore.RefreshServerComplianceState
   wscript.echo "Ran RefreshServerComplianceState."
End Sub

To run it manually, all that’s needed is to give the script a name, save it, then open a command prompt as an Administrator and type:

CSCRIPT <PATH>

In my lab, this looks like the following:

CSCRIPT C:\SCRIPTS\VBSCRIPT\RESYNCSTATE.VBS

NOTE: Depending on the architecture of the managed device, you will want to make sure you are running the correct version of cscript.  There is a version under both the System32 and SysWOW64 directories.  In my testing, I needed the version of cscript in System32, but if this causes problems test also with the version in the SysWOW64 directory.

The VBScript is very short and easy to use (and, indeed, can be used in testing scenarios when we want to manually send state messages from a managed device).  And in many cases, this is the final solution which leads to case closure.  In some cases, however, there is still work to be done.

The Problem – Packing the VBScript for ConfigMgr

Maybe some of you have figured out how to get this VBScript to run as a package in ConfigMgr.  But while there is a good bit of information on how this script can solve the reporting discrepancy, there is virtually nothing published on how to package it in ConfigMgr so that it runs automatically on managed devices.  And if you have hundreds or even thousands of devices that need to run this script, doing so manually on every one simply isn’t practical.

In the recent case I had, I worked for several hours to try and get the VBScript listed above to deploy and run successfully as a ConfigMgr package.  I did many different variations including setting permissions, specifying the starting folder, and leveraging both versions of cscript.  While I could get the script to install properly and while it would run successfully when I invoked it manually, I could never get it to run automatically regardless of the variations I tried.

PowerShell to the Rescue

After many frustrating hours, I decided there must be a better way.  The VBScript itself was not hard.  All it was doing was creating an instance of UpdatesStore in the WMI Repository on the managed client and then invoking the RefreshServerComplianceState method.  Surely this could be done with PowerShell.

Rather than try to re-invent the wheel I did a quick search on the Internet and came up with a two-line PowerShell equivalent that claimed to do what the VBScript does (and it turns out, it did!).  The article where I located the code can be found here.  The author’s refresh script is two lines long, and there is also a 1-line version listed in the reply section.  Both work, but I stuck with the 2-line version for ease of understanding.

Additionally, in order to provide a way for clients to see that the script ran successfully, I added a reporting piece to create an event in the Application log of each managed device.  The full code is below:

$SCCMUpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$SCCMUpdatesStore.RefreshServerComplianceState()
New-EventLog -LogName Application -Source SyncStateScript -ErrorAction SilentlyContinue
Write-EventLog -LogName Application -Source SyncStateScript -EventId 555 -EntryType Information -Message "Sync State ran successfully"

Note that the first two lines are taken directly from the blog referenced immediately above.  Line 3 is used to create the source that will be used when the events are written.  The –ErrorAction SilentlyContinue is there because if the source has already been created, PowerShell will throw an error.  Adding –ErrorAction allows the following to happen:

• Check to see if the source SyncStateScript has already been added to the managed device
• If not, add it
• If added already, suppress the error and continue with the script

The lines starting with New-EventLog and Write-EventLog are not strictly necessary as ConfigMgr contains log files that will tell if the state messages have been re-sent.  But for those who prefer to see Event Log entries showing if and when the script ran successfully, this is one way to achieve that goal.

Verifying the Script

One possibility when running the script that I needed to test was to find out if the state messages were actually being resent.  Sure, the Event Logs were being updated, but how did I know for sure the state messages were also being sent?  I had a pretty good idea that no errors were being thrown (I didn’t have any language in the script to suppress errors in the first two lines of the script and I also had tested running it before adding the EventLog portion).  But could I confirm that the state messages were actually sent?  The answer is yes.

As an administrator in ConfigMgr, it is essential to become familiar with the way logs are created to report important information.  For our present case, the log file we want is found under CCM\Logs (or SMS_CCM\Logs if you’re looking on a client machine that is also a Management Point).  In my lab, the folder of interest is C:\Program Files\SMS_CCM\Logs.  Within this folder, the log file to find is UpdatesStore.log as shown below:

Opening the log file after running the script, we should see the following:

Initiated refresh of update compliance to site server.    UpdatesStore    2/23/2015 6:03:10 AM    7332 (0x1CA4)
Successfully called refresh of update compliance from automation object.    UpdatesStore    2/23/2015 6:03:10 AM    13484 (0x34AC)
Message received to resend all update status, processing...    UpdatesStore    2/23/2015 6:03:10 AM    14184 (0x3768)
Successfully raised Resync state message.    UpdatesStore    2/23/2015 6:03:11 AM    14184 (0x3768)
Resend status completed successfully.    UpdatesStore    2/23/2015 6:03:11 AM    14184 (0x3768)

If this information is found at the same time as the script has run, we can say with confidently that it has done what we asked.

From here, the only thing left to do is verify the Compliance report is now reporting correct information, which can be easily done by re-running the report.

Creating the Package

This part is something I have had difficulty locating online, so I thought I’d provide a step-by-step of how I configured the package in my own lab.  Note that I am creating a package and not an application.  To do this, navigate in the ConfigMgr admin console to Software Library\Application Management\Packages and right-click the Packages node.  Select Create Package and enter the following information (note that I am not entering any optional information, though you will likely want to do this when working in your production environment).

On the initial page, I specified the following:

NOTE: In order to use the PowerShell script I had to do the following prior to creating the package:

• Create the script itself (copying the code above and saving as a .ps1 file is sufficient)
• Create a share (in my case \\s12-pr1\PowerShell)
• Set the share with appropriate permissions (in my case I granted the Everyone group ‘Read” permission)

It is important to use the network location when choosing the source folder.  This way, remote devices can access the folder successfully.

On the next page, select ‘Standard Program’ (assuming we are using a client computer and not a device such as a Windows phone):

After selecting the Standard Program, we need to enter information on the script and how we want to run it.  The following screen provides that detail:

Note that I have set the program to run whether the user is logged on or not.  This automatically sets the Run mode to “Run with administrative rights”.  To set the command line, all I did was browse to the folder which opens automatically (because I specified it in the previous screen when I set the network share) and select the Resync.ps1 script.  If you don’t see the script when you open the folder, look in the lower left-hand corner of the window and make sure “All Files (*.*)” is selected:

On the next page, choose whether to run another program first, and also which platforms can run the program.  In my lab I left this blank as I did not want to run any other programs first and I was okay with the script running on any platform.

From here, confirm the settings on the next page and close the wizard.

The wizard will run and create both the package and the program.  From here, you’ll want to distribute the package to your desired distribution points and then deploy the program.

Deploying the Program

This is the final step of deploying the PowerShell script, but it’s essential.  First, you’ll right-click either the package or the program and select ‘Deploy’.  Then you’ll do the following:

On the first page of the deployment wizard, select the Collection to which this program will be deployed.  As can be seen below, I have created a collection in my lab called Resync Test and added my test devices to it.

From here, ensure that the desired distribution points (or distribution point groups) are selected and select Next:

On the next screen, I selected ‘Required’ (I did not want my users to determine whether the script should run or not) and left the defaults as shown:

The next page is where I specified the script to run on a schedule.  Because I don’t want to flood my environment with too many state messages, I set this to run immediately when installed and then after that on a weekly basis.  I also specified that the script should re-run only if the previous attempt failed:

I left everything else at the defaults and then refreshed the Machine Policy for my test clients.  Because this is ConfigMgr 2012 R2, I was able to go to my collection under Assets and Compliance and the admin console, right-click and select Client Notification\Download Computer Policy as shown below.  This sends a notification via the “Fast Channel Notification” process to managed devices in the collection instructing them to refresh their machine policy as soon as possible.

From there it was a matter of monitoring my test clients to see that the script ran.  Because I had enhanced the script, I was able to watch the Event Logs as well as the UpdatesStore.log file to ensure the script ran successfully.

Summary

While the process of running a compliance script to clear up reporting discrepancies has been known for some time, there has been very little documentation on doing this with PowerShell or using ConfigMgr packages to deploy and run the script.  My goal in this blog has been to enhance the existing information with this extra detail for those seeking further information.

Because there can be a discrepancy in reporting from time to time, it is not a bad idea to deploy a script such as the one in this blog to all of your clients and have them refresh their state messages on a regular basis.  I chose once a week for my lab, but you’ll want to configure settings that make sense for your own environment.  And as always, you should thoroughly test this solution before ever running it in production.  What works in my lab may not work as easily in your own, and testing is the only way to avoid preventable issues when pushing scripts like this into production.

Package Priorities

First, lets look at the package itself, located in the ConfigMgr console within the Software Library context (navigate to Overview\Application Management\Packages).  When created, every package has a priority of ‘Medium’ by default.  While this doesn’t show up in the wizard when the package is being created, you can easily see it by opening the package properties and checking the Distribution Settings tab as shown below:

The options for distribution priority are High, Medium and Low.  As you would expect, the higher the priority of a package, the higher the priority in sending that package over other packages with lower priorities.  If you have a package that needs to be sent more urgently than some others, going this tab and seeing the priority to High will help ensure this happens.

Distribution Point Schedules

Beyond setting the priority on the package itself, it’s possible to specify which package priorities are allowed to be sent to a distribution point at a given time.  For example, you may decide that during the workday only high priority packages can be sent to distribution points due to the limited availability of bandwidth in your environment.

To configure this on a per-distribution point basis, navigate to the Administration context in the ConfigMgr admin console.  Expand Overview\Site Configuration\Servers and Site System Roles and select the distribution point you want to work with in the middle window.  From here, look at the Site System Roles window to see the roles installed on the selected computer.  Right-click the Distribution Point role and choose properties.  From here, you can choose the ‘Schedule’ tab as shown below.

In this tab, it is possible to select blocks of time and specify which package priorities are allowed during that time period.  As you can see from my screenshot, I have decided that the distribution point I’m configuring can only receive high priority packages between 8 a.m. and 6 p.m. on workdays, and it can’t receive packages at all between 10 p.m. and 2 a.m. on Saturdays and Sundays (this is our maintenance window).

The schedule for your distribution points is fully customizable and setting the schedule for one distribution point does not affect the schedule of another.  So if you are trying to ensure that a high priority package doesn’t have any competition from medium or low priority packages during a particular timeframe when being distributed to one of your distribution points, set the schedule to only allow high priority packages and you should see only that package being distributed.  Note that setting this priority after a package starts to distribute should not cause it to stop in midstream.  The scheduling should be worked out ahead of time if you are to achieve the desired effect.

Using DP Job Manager

The third thing I wish to discuss is a great new tool that comes with the System Center 2012 R2 Configuration Manager Toolkit.  This tool allows you to work with the packages being distributed to your distribution points in a variety of ways and every ConfigMgr admin needs to know how to use it.

To start using this tool once you’ve downloaded the toolkit, select the General tab and enter the name of your Primary Site server and select Connect.  If things work as they should, you will see a message in the lower-left that tells you the connection was made successfully.

Below, I’ve offered a quick summary of each tab for completeness, but my main focus will be on the ‘Manage Jobs’ tab:

Overview

On this tab, every distribution point that belongs to the site will be listed.  Here will be summary information on currently running jobs being processed by each distribution point, as well as the total jobs and current retries (packages that have failed to be distributed and that the distribution point is trying to distribute again).  As shown below, my lab has 3 distribution points with one of them in retry mode for the two jobs being distributed to it.

The Refresh button allows manually refreshing this view, while the Start Auto Refresh button causes DP Job Manager to start providing regular refreshes at the interval set (the minimum refresh interval is 2 minutes).

Distribution Point Info

This tab is where more granular detail can be seen about each distribution point, including the software being distributed, the Package ID, its size (assuming the size is included in the package), what % complete the package distribution is, and the start time (and restart time) of each package distribution.  There is also a view on the number of retries for each specific package.  And as always, there is the Refresh and Auto Refresh buttons.

Help

The Help tab outlines the specific features and elements of DP Job Manager.  For example, it gives a description of the various icons we might encounter when working with package jobs.  Referring back to the Distribution Point Info tab, for instance, we see a circular arrow to the left of the Software column.  This might not be immediately obvious, but the Help tab explains this for us as shown below:

If there is a need for further information, the Help tab has every useful information to better understand DP Job Manager

Manage Jobs

Circling back to the Manage Jobs tab, we can see that DP Job Manager provides us an ability to see and interact with package jobs in order to better control what goes on in our ConfigMgr environment.  The screenshot below shows us what the Manage Jobs tab looks like:

One thing that’s immediately obvious is that the columns for the Manage Jobs tab are identical with those for specific jobs in the Distribution Point Info tab.  The difference here is that we have the ability to interact with the jobs while on the Distribution Point Info tab we couldn’t (we could right-click a specific job and select ‘Manage Job(s)’ but this would just send us to the Manage Jobs tab.  We could also copy the specific job and paste the information somewhere like a Notepad file, but this was about all we could do on that tab).

To interact with a distribution point job, select the package of interest and right-click as shown below:

Here, we can see that we have many options:

• Run – this allows us to manually start the job, which may be useful when troubleshooting why a package is not distribution properly.
• Move – this is one of the nicer things about DP Job Manager.  If you have a large number of packages and want to re-prioritize them so that certain ones are processed sooner than others, all that needs to happen is to right-click the job of interest and move it either up or down in the list.  This gives a great deal of control over the jobs that are being distributed, especially since you can do this on a per-distribution point basis.  Notice in the screenshot below that I have chosen to distribute the DTC Ping software to a 2nd distribution point and setting the priority of this package is entirely independent based on which distribution point I’m sending it to.  I could choose to prioritize all of my packages destined for EX-MB1 before S12-OSD or any other way I choose (maybe I want all distribution points to receive a specific package first before any others, so I prioritize every instance of that package regardless of which distribution point it’s destined for)

• Copy – this is the same functionality as on the Distribution Point Info tab.  If you copy the package, the details listed on the table will be available for pasting to Notepad, an Excel spreadsheet, etc.  This can be useful for reporting or for evaluating trends over time (% complete of a package, for example)
• Cancel – if the distribution of a package needs to be canceled altogether, this can be done from the Manage Jobs tab.  When choosing to cancel a job, the following pop-up provides a warning and then allows us to either confirm or decline to cancel the job we’ve selected.

NOTE: You can select multiple jobs at once in the Manage Jobs tab, but the move commands will be grayed out.

Summary

There are various ways to configure and work with job priority when it comes to distributing package via ConfigMgr 2012.  This blog has attempted to provide a bit more detail on the options available through the graphical interface and when using DP Job Manager.  Bottom line, if you are ever in a position where you’ve distributed jobs that need to be re-prioritized or stopped altogether, ConfigMgr provides tools to help you accomplish that task.

Monitoring

One of the nice things in ConfigMgr 2012 is the Monitoring context.  In here, most things can be monitored to determine their health, their deployment state, etc.  Distributions Points are no different.  To validate the status of a newly added Distribution Point, take the following steps:

• In the ConfigMgr Admin Console, select the Monitoring context
• On the left-hand side, expand Overview and Distribution Status
• Within Distribution Status, look for Distribution Point Configuration Status as shown below

• Select the Site Server where the Distribution Point has been added and select the Details tab

If all is well, everything should read green.  If not, this will provide an opportunity to troubleshoot what may not be working as expected.

If there is something besides a green checkbox next to the site server, it’s also possible to look at the state messages by navigating (still within the Monitoring context) to System Status\Site Status and right-clicking the site server of interest, as shown below.

By selecting Show Messages, admins are enabled to choose the types of status messages they want to see.  By selecting them, a pop-up window with additional detail is provided to assist with troubleshooting tasks.  Below is an example of this from the one of the site servers in my lab:

NOTE: In order to show the Status Message Viewer with actual content, I had to select a different device in my lab.  The majority, if not all, of these errors are due to the fact that I have deliberately isolated my lab from the internet, so it provides a good illustration of what sorts of errors might show up in a production environment that needs admin attention.

Manual Review of the Distribution Point

Beyond monitoring the install in the ConfigMgr Admin Console, it’s possible (and often helpful) to check the new Distribution Point itself to see if the components that are necessary for its functioning are being added successfully.

Below is an outline of what you can look for on your Distribution Points to verify that they are healthy:

• Check the Content Library: this is the location where packages are stored and made available to clients in ConfigMgr.
  • Navigate (by default) to: C:\SCCMContentLib
  • Expand SCCMContentLib and make sure it contains 3 folders (as shown below):
    • DataLib
    • FileLib
    • PkgLib

NOTE: To read an excellent blog about the structure of the Content Library and how to verify your packages, I recommend the article ConfigMgr 2012 Content Library Overview.  There is also an excellent tool called the Content Library Explorer that every ConfigMgr admin should know about.  Check both of these out to understand more about the details of the Content Library.

• Review Scheduled Tasks: Every Distribution Point is configured with scheduled tasks that run regularly
  • Content Usage – This scheduled tasks runs the executable smsdpusage.exe and is present on every distribution point
  • Content Validation – This scheduled task runs smsdpmon.exe and will be present on a Distribution Point if you’ve set it to validate its content on a schedule

NOTE: To view the results of these scheduled tasks, navigate to SMS_DP$\sms\logs on the Distribution Point and review the log files associated with the scheduled task (the log names map to the executable that each scheduled task runs).  If you want to validate the results of your scheduled task immediately, right-click the task in Task Scheduler and select ‘Run’.  Then navigate to the log files shown below to review the results.  If there are errors or other issues requiring attention, they should be listed in these files.

• Review the Content of SMS_DP$: This share contains the log files for the Distribution Point and is where pre-staged content will go, among other things.  This folder should have the following structure:
  • sms\bin – contains various binary files (.dlls, etc.) necessary to the functioning of the Distribution Point
  • sms\logs – contains the log files used by the Distribution Point to report information (such as scheduled task results, per our conversation above)
  • sms\Tools – contains extractcontent.exe which is used to prestage content that should reside on the Distribution Point

• Confirm IIS: Each Distribution Point uses the two virtual directories shown below to download content via BITS.  If you have installed BITS on your DP (and Pull Distribution Points require BITS), the virtual directories SMS_DP_SMSPKG$ and SMS_DP_SMSSIG$ should be present in IIS as shown below.

If any of this information is missing, you’ll need to figure out why.  With the exception of the optional Content Validation task mentioned above and the virtual directories in IIS, every Distribution Point should have all of these components.

Summary

There are obviously other tasks that you’ll want to keep track of with your Distribution Point.  In the case of my lab, my Distribution Point is PXE enabled, which allows me to provide operating system images to clients participating in Operating System Deployments (OSD).  Additionally, I will want to ensure that the packages I push to my Distribution Point are present and available to clients.  This can involve many possible methods of confirmation, including reviewing SQL database tables, walking through the Content Library (either with or without the Content Library Explorer), etc.

What I have tried to do here is to give a basic set of tasks to allow administrators of all levels to validate their Distribution Points contain the components necessary to participate as site system roles in Configuration Manager 2012.