Core Infrastructure and Security Blog

12 MIN READ

How To Detect Changes In MECM Environments

Microsoft

May 17, 2021

Hi, Jonas here!

Or as we say in the north of Germany: "Moin Moin!"
I am a Senior Customer Engineer based in Germany and over the years I created several configuration items I use as part of a Microsoft Endpoint Configuration Manager (MECM / ConfigMgr) baseline to detect configuration changes in the environment.

In this blog post I will describe each config item and how you can benefit from them to detect changes before significant issues arise.

TL;DR

If you are just looking for the download link for the ConfigMgr baseline and items, here you go: LINK

If you are familiar with configuration items and baselines you might want to skip the next section and start with “Why use a baseline for site systems?”.

Or jump to each item directly:

Item1: CI-Validate-HINV-MaxMIFSize
Item2: CI-Validate-SINV-MaxFileSize
Item3: CI-Validate-SINV-ExceedSizeLimit
Item4: CI-Validate-HINV-ExceedSizeLimit

Item5: CI-Validate-DP-Pxe-Settings
Item6: CI-Validate-LegacyCardinality
Item7: CI-Validate-Configuration.mof
Item8: CI-Validate-IIS-Logfiles
Item9: CI-Validate-WSUS-AppPoolConfig
Item10: CI-Validate-DefaultClientSetting-HINV-Classes
Item11: CI-Validate-WSUS-Subscription

Feel free to check out my other articles at: https://aka.ms/JonasOhmsenBlogs

How does a ConfigMgr baseline work?

ConfigMgr configuration items and baselines are around for a while and most customers use them to detect and or remediate issues on ConfigMgr clients.

If you are not familiar with the concept of a configuration item and baseline, let me give you a brief introduction.

A configuration item will test a certain state, either by checking the existence of a file, folder, registry entry or registry value for example (not a complete list of options).

A configuration item can also contain a custom script to test more complex states which extends the functionality of the default tests.

In addition each item can contain a remediation step to revert a state back to a desired state. Setting a registry value to 1 in case a test detected a 0 for example.

It can also contain a detection method to only run the test if a certain condition has met. Like a condition for the existence of a specific service for example.

Each configuration item needs to be part of a baseline which can be deployed to a collection and then evaluated on ConfigMgr clients.

The test results / compliance state will be sent back to the ConfigMgr site and the results can either be seen in the console or via different reports.

If you want to know more you will find the documentation here: LINK

Why use a baseline for site systems?

There are good reasons to use a baseline for all the changes you do to your ConfigMgr site systems:

Each configuration item could be seen as a documentation entry
Newly added servers will be tested and any missing changes will be visible via the baseline
Any configuration drifts can be detected before they result in bigger issues
Some default settings might get reset after a ConfigMgr upgrade and a configuration item can help to detect such changes

Rule of thumb:

Whenever you configure something outside the ConfigMgr console create a configuration item for the reasons above.

How to import

Either download the baseline and the items from the GitHub repository or clone the repository or use the ConfigMgr Community hub to import the items.
Imported from the Community hub the baseline and items can be used directly.
When downloaded from Github first unpack the files and use the ConfigMgr console to import the cab file.

Open the ConfigMgr console and navigate to: “Assets and Compliance”, “Compliance Settings” and ”Configuration Baselines”.

Click on “Import Configuration Data” and add the cab file.
Accept the publisher message and follow the wizard to import the baseline and items.

Prerequisites to use the baseline and items

There are three prerequisites to use the described configuration items.

First:

Compliance settings needs to be enabled via a client setting by setting "Enable compliance evaluation on clients" to "Yes"

Second:

PowerShell scripts should be able to run without signing except you want to sign each script of each item yourself. In that case you can leave the setting in its default state: “All Signed” otherwise it needs to be set to “Bypass”.

Third:

Whenever you add one of the configuration items described below to a configuration baseline make sure to set the “Purpose” to the value “Optional”.

That setting ensures the correct reporting of the detection part of each item.

(See section Detection of each item for more details)

List of configuration items

In this section I describe a list of items I often use.

Each item has a detection script and will only run tests on systems where a test makes sense or where a certain test is possible at all. Each item has a “Detection” section with more details about the detection logic.

The detection logic means you can simply deploy a baseline with all items to all ConfigMgr servers and the detection makes sure each test runs only on the right systems.

Adjust each item as needed for your environment and as described in the “Customizations” sections of each item description.

Item1: CI-Validate-HINV-MaxMIFSize

This item is one of the simpler ones and makes use of the default test for registry values to test the “Max MIF Size” for hardware inventory (HINV) files. If the HINV file exceeds 5MB the file cannot be imported by default. If the setting has been changed to support bigger file sizes use the item to make sure it stays that way.

Item1: Detection:

The item will only run its test if the registry path exists.

Item1: Remediation:

The item can also remediate the setting if desired.

Item1: Customizations:

Change the “Compliance Rule” to the value you use in your environment.

Item2: CI-Validate-SINV-MaxFileSize

This item does the same as: "CI-Validate-HINV-MaxMIFSize" but for Software Inventory files. Detection, remediation and customizations are also identical but specific to Software Inventory.

Item3: CI-Validate-SINV-ExceedSizeLimit

This item will compare each file size of files in folder: "\inboxes\auth\sinv.box\bad" with the maximum allowed file size set here: "HKLM:\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_SOFTWARE_INVENTORY_PROCESSOR" - "Max File Size".

In case the item detects any large files there are three options to reduce the file size:

Try to reduce the number of folders to be scanned by Software Inventory
Exclude specific folders via the Skpswi.dat file. More details can be found here: LINK
Or increase the max file size value (should be the last option)

Item3: Detection:

The item will only run its test if the registry path exists.

Item3: Remediation:

The item can also remediate the setting if desired.

Item3: Customizations:

No customizations required.

Item4: CI-Validate-HINV-ExceedSizeLimit

This item does the same as: "CI-Validate-HINV-ExceedSizeLimit" but for Hardware Inventory files. Detection, remediation and customizations are also identical but specific to Hardware Inventory.

In most cases some WMI classes on some machines hold more data than normal which can lead to larger files.
Terminal servers with multiple loggon on users for example might report more user specific data.

In that case try to exclude some WMI classes for specific systems to limit the amount of Hardware Inventory data.

To exclude a certain Hardware Inventory classe from specific systems you would need to disable the class in the "Default Client Setting". Then enable the one class via a custom setting for all systems except the ones you don't need the class from.

(Item10 might help to stay compliant with what you have defined in your environment)

Item5: CI-Validate-DP-Pxe-Settings

This item can be used to validate the registry settings to manipulate TFTP window and block size.

Item6: CI-Validate-LegacyCardinality

This item will validate the setting to use legacy cardinality for ConfigMgr console queries by testing the value of “UseLegacyCardinality” located at: “HKLM\SOFTWARE\Microsoft\SMS\Providers”

Item7: CI-Validate-Configuration.mof

This item can be used to detect changes to the configuration.mof file.

The file can be used to extend the hardware inventory (HINV) and is often used for customer specific scenarios.

A script will calculate the file hash and the item will compare the hash with a known value. That helps to detect any changes to the file.

Keep in mind that the file can also change during a ConfigMgr update.

Item7 Detection:

The item will only run on servers on which the configuration.mof exists.

Item7 Remediation:

The item does not contain any remediation parts.

Item7 Customizations:

Run the following script on a site server to get the hash of the file in your environment and change the value of the compliance rule accordingly.

$configPath = "{0}{1}" -f (Split-Path -Path $env:SMS_LOG_PATH -Parent), "\inboxes\clifiles.src\hinv\configuration.mof"
$fileHash = Get-FileHash -Path "$configPath" -Algorithm SHA256
Write-Output $fileHash.Hash

Item8: CI-Validate-IIS-Logfiles

This item will test for IIS logfiles older than seven days and can be used to also delete them by using the remediation part of the item.

The embedded script will test

Item8 Detection:

The item will only run on servers with an installed IIS webserver.

Item8 Remediation:

The remediation script can delete files older than seven days.

Item8 Customizations:

Change the discovery and remediation script via the “Edit Script” button and change the value of variable $logFileMaxAgeInDays to the desired value.

Item9: CI-Validate-WSUS-AppPoolConfig

This item will run several tests against the WSUS website and is intended to make sure each WSUS server follows the best practices.

The WSUS best practices documentation can be found HERE

Item9 Detection:

The item will only run on servers with an installed WSUS server role.

Item9 Remediation:

The item does not contain any remediation parts.

Item9 Customizations:

Not every test might be needed in your environment. The WSUS-Content… tests for example are only needed when WSUS is configured to use a shared database and shared content storage.
Simply delete the tests/settings you might not need and adjust the compliance rules or each test to your needs.

Item10: CI-Validate-DefaultClientSetting-HINV-Classes

This item is the most complicated one and can be used to validate the activated hardware inventory (HINV) classes of the default client setting or any custom setting.

The idea is to detect any removed or added classes to the HINV part of a client setting. Like the added “Battery” class as shown in the screenshot below for example.

Keep in mind that any ConfigMgr upgrade might also change/extend the HINV part of the default client setting.

Item10 How it works

The config item will run a script to compare a known HINV class state with the current HINV class state of a given client setting. If it detects any differences it will report each added or removed item as a critical change.

If you want to test multiple client settings you would need to copy the configuration item and change the settings as described in the following section.

Item10 Configuration item setup

The following steps are necessary to adjust the configuration item and script to your environment.

Step 1

Copy the script out of the configuration item or from the Github repository and save it on a CAS or Primary Site server.

In most cases it will be necessary to change the script to be able to compare the settings of the given environment. It is therefore designed to run as part of a configuration item or as a standalone script.

Step 2

Run the script with administrative rights and without any parameters to compare a known list of active HINV classes of the “Default Client Setting”.

Note: Do not run the script in the PowerShell ISE you might get strange results when changing some parameters.

It should either return the word “Compliant” or a list like this:

The script should contain the default classes of a ConfigMgr 2010 installation.

So, “Compliant” would mean you have not changed anything and the default classes are selected.

A list like the one shown above would mean you are either not on ConfigMgr 2010 or you changed the settings in the past or my initial known class list of the script is simply not complete.

Step 3

If the output of the script is the word “Compliant” you could use the script and therefore the configuration item without any changes to detect future changes of HINV classes.

But if you get a list back, the script needs to be changed to compare what has been set in your environment.

You do that by running the script with the parameter -OutPutMode 'CreateScript'.

That will copy the script to the same location as the original script but will change the known HINV class list to the state of your environment.

It will have a name like this:

[original script name]-[client setting name]-[Date].ps1

Note: I could have used an external configuration file to read the data for comparison, but I didn't want to rely on external data. That’s why everything is part of the script and the reason for the “CreateScript” option.

Step 4

Run the new script without any parameters to test it. It should output the word “Compliant” since it now contains the current state.

Step 5

Copy the contents of the new script and replace the existing script of the configuration item as shown in the screenshot below.

Click on “Settings”, “Edit Script…” and “Clear” to clear the existing script.

“Open...” the new script and add it to the configuration item.

Step 6

If you would like to compare HINV classes of custom client settings run the script with the parameters -ClientSettingsName 'Name of custom client setting' and the parameter -OutPutMode 'CreateScript'.

The script will then generate a new script containing all the classes of your custom client setting. It will also change the default value of the parameter:

-ClientSettingsName to the name of the custom client setting to be able to run without the need to provide extra parameter values.

Item10 Detection:

The item will only run on site servers.

Item10 Remediation:

The item does not contain any remediation parts.

Item10 Other parameters:

As mentioned before the script can also be used as a standalone script for documentation purposes for example.

The following actions are possible via the -OutputMode parameter:

“CompareData”

CompareData is the default value and will output the difference between the known classes and the current active classes of a given client setting.

“ShowData”

ShowData will open two GridViews. One for all available inventory classes and one with the active classes for the selected client setting.

“ExportAsCSV”

Will create two csv files in the same directory as the script.

One for all available inventory classes and one with the active classes for the selected client setting.

“CreateScript”

Creates a new script with the current HINV Class state for a given client setting.

Run "Get-Help .\Compare-ClientSettingHINVClasses.ps1 -Detailed" to get more help with the available options.

Item11: CI-Validate-WSUS-Subscription

This item works the same way as the one before (CI-Validate-DefaultClientSetting-HINV-Classes) but is intended to compare a known list of activated WSUS update categories and products as shown in the screenshot below.

The item will detect any changes and can therefore help you either activate a newly synched product or revert any unwanted changes.

Item11 Detection:

The item will only run site servers.

Item11 Remediation:

The item does not contain any remediation parts.

Item11 Customizations:

The script has a limited set of update categories and products and will therefore output a long list of differences when you run it on a primary or CAS without any parameters.

But the script has also the option to use the -OutPutMode 'CreateScript' parameter to create a new script with the settings of your environment.

Use the same method to import the new script (containing your settings) into the configuration item as described in Step 5 of “CI-Validate-DefaultClientSetting-HINV-Classes”

Run "Get-Help .\Compare-WSUSSubscriptions.ps1 -Detailed" to get more help.

Monitoring

Like any other deployment each baseline deployment can be viewed via “Monitoring” and “Deployments”.

For any uncompliant systems the exact values can be viewed via the “More Details” button on the right side of the screen.

Corresponding reports can be found in the report folder called: “Compliance and Settings Management”.

Another option to view compliance is the compliance report on a local system via the ConfigMgr client applet.

Conclusion

Whenever changing anything outside of the ConfigMgr console create a configuration item to document and monitor each setting.

I hope the article was worth reading and I hope the items will help you get a better understanding of the changes which might happen to your ConfigMgr environment before any real issues arise.

Have fun detecting any changes in your ConfigMgr environment and let me know what you think.

Jonas Ohmsen

Microsoft Germany