CHAPTER 10
Managing Compliance

Microsoft introduced compliance settings functionality to System Center Configuration Manager (ConfigMgr) with ConfigMgr 2007, at which point it was called Desired Configuration Management (DCM). ConfigMgr 2012 added some new functions and changed the name to Compliance Settings. ConfigMgr Current Branch improves the Compliance Settings feature set with an improved workflow to create configuration items, showing only settings relevant to the platform you choose, and adds new configuration items for Windows 10, Mac OS X, and Windows desktop and server systems with an installed ConfigMgr client. Current Branch also includes updated support for devices (Windows 8.1, 10, Phone, iOS, Mac OS X, Android, and Samsung Knox) managed without the ConfigMgr client through Microsoft Intune.

Compliance Settings provides the capability to manage the configuration and compliance of devices in a single pane of glass. This ConfigMgr component allows you to define, monitor, enforce, remediate, and report configuration compliance, as well as handle the following four factors that all information technology (IT) organizations must deal with:

Regulatory Compliance: Given the impact of regulatory laws in the United States that cover privacy and corporate responsibility, regulatory compliance is a key scenario for many IT organizations. Examples include the Sarbanes-Oxley (SOX) Act of 2002, the Gramm-Leach-Bliley Act (GLBA), and the Health Insurance Portability and Accountability Act (HIPAA).

These regulations require IT organizations to set specific security and privacy standards for corporate and user data, along with IT systems. The difficult part for IT is trying to enforce and report on the enforcement of these standards. Most organizations have no way to enforce these policies and rely on custom scripts or tools to provide on-demand results. As these laws are not technical in nature, the technical requirements to fulfill the standards become subject to interpretation and vary between organizations: SOX for you is not necessarily SOX for someone else.

Even if your organization is not subject to specific regulatory compliance laws, it should still be subject to internal policies and standards. Validating your infrastructure’s compliance against internal governance is the same as validating it against government standards.

Pre- and Post-Change Verification: An organization must verify the configuration of a system before and after planned changes are made. It is generally useful to verify that you are only applying changes to systems in a specific state, that the planned changes occurred, and that unintended changes did not take place.

Configuration Drift: Configuration drift starts the moment a system goes into production and is difficult to control. No matter how set in stone your build process is, systems begin to drift from the standard as soon as multiple administrators or users log in to a system to install applications, troubleshoot issues, or tweak performance. Drift for a particular system is unpredictable and, over time, has the potential to cause technical issues.

Time to Resolution: An overwhelming number of problems are due to human error. These problems ultimately become the dreaded problem tickets that every on-call administrator loathes, particularly when they occur in the middle of the night. Stopping human error is all but impossible; however, identifying human error quickly so it can be resolved is key to reducing the impact of such errors.

Settings management does not instantly fix these issues, but it helps in managing them and reducing the amount of time spent trying to achieve compliance. It also allows you to incorporate the issues into your current set of processes.

This chapter covers settings management, including compliance settings, client configuration for compliance settings, configuration items, how to create items and baselines, strategies for compliance, and troubleshooting when things go wrong.

FIGURE 10.1 Client Compliance Settings.

Enable Compliance Evaluation: Choose Yes to enable or No from the dropdown menu to disable compliance evaluation on the client.

Schedule Compliance Evaluation: Choose a simple or a custom schedule. Use a simple schedule to set how often the compliance evaluation runs, in days, hours, and minutes. A custom schedule lets you choose down to the day, hour, and minute when a compliance evaluation runs on the client.

Enable User Data and Profiles: Choose Yes or No. User data and profiles configuration items contain settings that allow you to manage folder redirection, offline files, and roaming profiles on Windows 8, 8.1, 10, Server 2012 R2, and Server 2016 clients.

The only prerequisite for Compliance Settings is that the ConfigMgr client must be installed on the machine. Compliance settings evaluation is completed by the compliance and settings management component on the client, which is installed during ConfigMgr client installation. It is then enabled on the client when the Enable compliance evaluation on clients setting shown in Figure 10.1 is set to Yes.

Configuration Items: These settings, values, and criteria are compared, checked, evaluated, and possibly remediated on the clients.

Configuration Baselines: These collections of items are put together in a group called a baseline, and the baseline is sent to the client for evaluation. Items cannot be evaluated until they are part of a baseline.

User Data and Profiles: These can manage folder redirection, offline settings, and roaming profiles for clients running Windows 8 and above.

Remote Connection Profiles: You use profiles to set up connections for devices to remotely connect to your corporate network. See https://docs.microsoft.com/sccm/compliance/deploy-use/create-remote-connection-profiles for in-depth information.

Each organization’s needs and wants around settings management vary, which is why Microsoft created and continues to tune this component so that it can handle many different situations users may need to evaluate or check on.

TABLE 10.1 Devices and Settings

Microsoft Intune allows you to greatly enhance the number of devices you can support with settings management. Information on Microsoft Intune is available at https://www.microsoft.com/cloud-platform/microsoft-intune.

A CI is a container that holds objects added to it for use in evaluations. The objects you add depend on what you want to evaluate; however, the following objects are always in a CI:

Detection Method Information (for Windows CIs Containing Application Settings Only): Lets you determine where an application is installed on the client by detecting the Windows installer file for the application, using a custom script, or allowing you to specify that the application is always installed on the client.

Settings: Used for compliance checking. Some settings are predefined, depending on the device selected for compliance settings. A setting for Windows Phone could be the setting for password expiration. For a Windows system with the ConfigMgr client, an example might be the value of a Registry key or results of a Windows Query Language (WQL) query.

Compliance Rules: Lets you determine whether the setting meets compliance. Using the example in the previous bullet of settings with a Registry key, the compliance rule could be whether the Registry key exists on the client; if so, the client is compliant, and if not, the client is noncompliant.

Supported Platforms: Specifies the operating systems (OSs) for the devices to which you are allowed to send the CIs for evaluation. If the client is running an unsupported OS and receives the CIs, it does not evaluate them for compliance and returns a requirements not met status message.

You can create a child CI if you need to make the properties of a CI more restrictive or different in some way but want to maintain a relationship with the original CI. A child CI inherits the properties of its parent. You cannot change those properties, but you can add new information to the child CI. Create a child CI by right-clicking an existing CI and selecting Create child configuration item.

Baselines can contain software updates, which are not defined as CIs for the purpose of adding them to baselines. You can add a software update by selecting it when creating a baseline. When the client evaluates the baseline, the software update is evaluated and then installed or not installed. Consider an example of a hierarchy that receives updates in a variety of ways: via ConfigMgr, Windows Server Update Services (WSUS), and the Internet. One way to determine if a software update is installed on all your systems is by creating a configuration baseline that contains the software update and having clients evaluate the baseline.

As with CIs, there may be times when you have created so many baselines that you need to filter them. ConfigMgr’s built-in filtering and search capabilities inside the console can help limit the baselines shown or can help find a particular baseline of interest. Following are some criteria specific to filtering configuration baselines:

Revision: Indicates the highest revision number of the configuration baseline. Editing a baseline increments the revision number, which can become lost in environments with many changes. Use the revision number to confirm that you are using the correct version.

Compliance Count: Counts the systems reporting being compliant with the settings in the baseline. Choose the operator that fits best to return the correct results you need.

Noncompliance Count: Counts the systems reporting being noncompliant with the settings in the baseline. Choose the operator that fits best to return the correct results you need.

Failure Count: Counts the systems reporting failures while running or trying to run the evaluation on the baseline. Again, choose the operator that fits best to return the correct results you need.

Categories: Allows you to search by category in that baseline.

Relationships: If configuration baselines are nested inside one another, relationships can help you find those nested baselines. This is good for troubleshooting baselines nested inside each other.

When your configuration baseline is built with all the items added to it, you are ready to deploy that baseline to a collection of clients. You cannot directly deploy CIs to clients; they must be assigned to a configuration baseline to be deployed.

Use the ConfigMgr console to import and export configuration baselines. If someone has created a baseline with CIs and posted it to the Internet, you can download that baseline and import it into your console for testing. Make sure to import these baselines only into your lab until they are thoroughly tested and verified as safe for your production environment.

You might want to use these settings with a virtual desktop infrastructure (VDI) environment. Use user data and profiles to control the following settings:

Folder Redirection: You can change where files are stored for the desktop, start menu, documents, music, videos, favorites, contacts, downloads, links, searches, saved games, application data, and pictures. You can redirect these folders to remote or local devices. With remote, you can choose a specified folder or use the user’s home folder.

Offline Files: You can enable or disable the use of offline files. If enabling, you can set the background synchronization and whether to use metered network connections. You can also enable slow links and set the latency threshold and synchronization interval.

Roaming Profiles: You can specify redirection of the entire user’s profile to a file share. This occurs at user login and synchronizes all changes to the profile at logoff. Options include excluding folders from roaming profiles, managing slow links and network settings, and managing access settings.

User data and profile settings deal with user settings and thus can only be deployed to a collection of users. The target systems for these users must be Windows 8.x and above. Use any or all of these settings for the best experience for your users.

The following devices can be used to access a work computer:

Computers running Windows 7 and above; if using the company portal, Windows 8.1 and above

Devices running iOS

Devices running Android

A Windows Intune subscription along with the service connection point (SCP) is required to use iOS and Android devices.

Remote connection profiles have several prerequisites that are both internal ConfigMgr dependencies and external dependencies:

Remote Desktop (RD) Gateway Server: A connection to an RD gateway server must be in place for users outside the company network to connect to work computers.

Firewall Settings: Any host-based firewall system must be configured to allow the Mstsc.exe program through it.

Service Connection Point: ConfigMgr must have a configured connection to Microsoft Intune.

User Device Affinity: For a user to connect to a work computer, that computer must be a primary device of the user who is trying to connect.

Compliance Settings Manager Role: If using role-based management in the ConfigMgr console, the user creating the remote connection profiles must be assigned the compliance settings manager security role.

When remote connection profiles are first deployed to a client system and evaluated, the Remote PC Connect local security group is created on that machine. This security group is populated with the primary users of the computer to which the profile is deployed. Members of the local administrators group can add or remove users to the group; however, when the ConfigMgr client next evaluates the remote connection profile (by default every seven days on a simple schedule), it removes any users that are not primary users of the machine and adds any users previously removed that are primary users of the machine, as defined by ConfigMgr.

If the device affinity relationship between a user and the device changes, ConfigMgr disables the remote connection profile and Windows Firewall settings to prevent connecting to the computer.

FIGURE 10.2 General page of the Create Configuration Item Wizard.

The pages of the wizard differ depending on the type of CI you are creating; however, the General page is the same for all types. Provide a name that describes what the CI is about and optionally add a description. If there are many CIs, it is easier to find the correct one if the name is descriptive. Then choose between the following types of CIs:

Settings for Devices Managed with the ConfigMgr Client: This type of system has an installed ConfigMgr client—typically desktops and server type operating systems. There are several different types:

Windows 10: This option allows you to leverage the mobility features built in to Windows 10. It does not provide the full set of options you find for Windows workstations and servers.

Mac OS X (Custom): Use this option to check compliance with Mac OS X preferences for an application or to run a custom shell script on a Mac.

Windows Desktops and Servers (Custom): The most used option to create a CI, this is for Windows 7, 8.x, and 10, and Server 2008 R2, 2012 R2, and 2016.

This Configuration Item Contains Application Settings: This check box that goes with the Windows Desktops and Servers option lets you check settings for an application using the product code.

Settings for Devices Managed Without the ConfigMgr Client: For these mobile systems, such as iPads, phones, tablets, and so on, you can access the mobility settings on the devices using Microsoft Intune.

Windows 8.1 and Windows 10: Use this option for tablets running Windows 8.1 and 10; it allows you to check mobility settings for these tablets.

Windows Phone: This option is for Windows Phone versions 8.0 and 8.1.

iOS and Mac OS X: Use this option to access the settings for any of the iOS devices, such as an iPad or iPhone, as well as Mac OS X mobility profiles.

Android and Samsung Knox: This option is for mobility settings for Android tablets and phones and the Samsung Knox family of devices.

Use the Supported Platforms section of the Create Configuration Item Wizard to choose Windows 10 64-bit, 32-bit, or both operating systems. The Device Settings page of the wizard displays next; Figure 10.3 shows the available options.

Each option you select creates a new menu item in the Create Configuration Item Wizard. Each item has several different settings; for in-depth information on these settings, see https://docs.microsoft.com/sccm/compliance/deploy-use/create-configuration-items-for-windows-10-devices-managed-with-the-client#windows-10-configuration-item-settings-reference.

FIGURE 10.3 Device Settings options for Windows 10 devices.

The last option listed in Figure 10.3 is Windows Information Protection (WIP), formally known as Enterprise Data Protection. WIP includes new settings found only on Windows 10 version 1607 and above and Windows 10 Mobile. WIP settings help combat accidental data leakage, which occurs when employees send corporate data from personal email accounts or save corporate documents out to a public cloud; basically, this is when corporate-owned data is transmitted on networks outside the corporate enterprise network. WIP provides the following benefits:

Separation between personal and corporate data, without requiring employees to switch environments or apps

Additional data protection for existing line-of-business apps without a need to update the apps

Ability to wipe corporate data from devices while leaving personal data untouched

Audit reports for tracking issues and remedial actions

Integration with your existing management system (Microsoft Intune and ConfigMgr Current Branch)

Figure 10.4 shows the many properties that you can set for WIP:

FIGURE 10.4 Windows Information Protection properties.

App Rules: Use this section of the wizard page to create rules that set the enterprise data protection mode for an application. You can set a rule to allow protection for the application or make it exempt. You can use wildcards for the product name, binary name, or version.

Paste/Drop/Share Restriction Mode: Set the mode you want enforced for apps that meet the criteria previously defined in the App Rules section. There are four modes to choose from:

Block: When inappropriate data sharing is found, the employee is blocked from completing the action.

Override: Blocks inappropriate data sharing but allows the user to override the block and share the data. If a user chooses to override the block, the action is logged into the audit log.

Silent: Runs in the background and logs inappropriate actions in the audit log.

Off: Turns off the restriction mode and does not protect your data or log any information in the audit logs.

Corporate Identity (Required): Use this field to define your domain or domains. If you have multiple domains, the first one defined is considered your corporate identity and the others as being owned by the first one. Use a | as a separator between domains.

Corporate Network Definition: Use this box to define the network boundaries for WIP to protect. You can define boundaries in several ways:

Enterprise cloud resources

Enterprise network domain names

Enterprise proxy servers

Enterprise internal proxy servers

Enterprise IPv4 ranges

Enterprise IPv6 ranges

Neutral resources

Enterprise Proxy Servers List Is Authoritative (Do Not Auto-Detect): Use this dropdown to treat the list of proxy servers defined in the corporate network definition box as the complete list of proxy servers. If not configured, Windows searches the immediate network for additional servers.

Enterprise IP Ranges List Is Authoritative (Do Not Auto-Detect): Use this dropdown to treat the list of IP ranges in the corporate network definition box as the complete list of ranges. If not configured, Windows searches for additional IP ranges on any domain-joined devices connected to your network.

Show the WIP Icon Overlay on Your Allowed Apps That Are WIP-Unaware in the Windows Start Menu and on Corporate File Icons in the File Explorer: Use this dropdown to overlay an icon on the corporate files or Start menu so the user knows that they are not WIP-aware applications or files.

Upload a Data Recovery Agent (DRA) Certificate to Allow Recovery of Encrypted Data (Required): Once your WIP policy is deployed to clients, Windows begins encrypting corporate data on the local device. If the local encryption keys are lost or revoked, the data is unrecoverable. Use this option to include a public key for encrypting the data while you hold the private key in case it is needed for decryption.

Show the Personal Option in the “File Ownership” Menus in the Windows File Explorer and the Windows Save As Dialogs: Use this dropdown to allow a user to choose whether a file is for personal or work use when it is saved. Not Configured is the same as Yes. Selecting No turns off the setting and does not provide the user with an option to save the file as personal.

Prevent Corporate Data from Being Accessed by Apps When the Device Is Locked (Applies Only to Windows 10 Mobile): Use this option to add a PIN code on a Windows 10 mobile locked device that protects the key used to encrypt the enterprise data on the device. Yes turns this on, and No or Not Configured turns it off.

Allow Windows Search to Search Encrypted Corporate Data and Store Apps: Use this option to toggle the ability for Windows Search to index encrypted data and Windows Store apps. Yes turns this on, and No or Not Configured turns it off.

Revoke Encryption Keys on Un-enroll: This option allows you to revoke the user’s local encryption keys from the device when it is removed from WIP. When the keys are revoked, the user cannot access that data. Yes is the same as Not Configured and turns on the process of revoking the keys.

Selecting Mac OS X (custom) on the General tab opens the Supported Platforms page, where you have the option to select what version of the OS applies to this CI. You next are presented with the Settings page, which is blank by default. Click New to add a setting. Figure 10.5 shows the page that appears, which includes the following settings:

FIGURE 10.5 Create Setting page.

Name: (Required) Provide a meaningful name so when you are reviewing the results, you know from the name what the setting is for.

Description: Explain the setting in detail.

Setting Type: (Required) The dropdown has two options to choose from:

Mac OS X Preferences: Set the keys within property lists for an application.

Script: Use this to run a script. Choosing this option changes the bottom part of the page so that it offers two options:

Discovery Script: (Required) This shell script is used to find and return the value of a setting you want to view. This usually occurs in two steps: Find the current user and store in a variable for later use and then gather the current setting of the value that you want to change.

Remediation Script: Once the values are compared and a machine is determined to be noncompliant, the remediation script can be run to fix the value and return the machine to compliance. This is a shell script.

Data Type: (Required) Identify the type of data for the value you want to compare. The dropdown menu choices are as follows:

String

Date and time

Integer

Floating point

Boolean

Application ID: (Required) Points to the location of the plist file to use.

Key: (Required) The name of the item holding the value you will check for.

The Compliance Rules tab defines the conditions used to determine compliance or noncompliance. Click New to open the Create Rule page, which allows you to create a rule to define your conditions. Figure 10.6 shows the Create Rules page, which offers the following settings:

FIGURE 10.6 Mac Create Rule page.

Name: Name the condition rule you are creating. Make it meaningful.

Description: Explain what the condition rule is for.

Selected Setting: Automatically filled out, based on the values in the General page.

Rule Type: Define the type of rule. You have two choices:

Value: Sets up the rule to compare the value returned by the CI or script against a value you specify.

Existential: Creates a rule that evaluates the setting, depending on whether it exists on the device. Choose one of two comparison settings:

The setting must exist on client devices

The setting must not exist on client devices

The Setting Must Comply with the Following Rule: Set the operator you want to use for the comparison.

The Following Values: Enter the value to use for comparison.

Remediate Noncompliant Rules When Supported: Turn on or off remediation of the value if the rule determines that the value is noncompliant.

Report Noncompliance if This Setting Instance Is Not Found: Check to tell the compliance setting engine to return a value of noncompliance if the value is not found on the device.

Noncompliance Severity for Reports: Choose the type of error code returned if the CI is determined noncompliant:

None

Information

Warning

Critical

Critical with event

The Compliance Rules tab allows you to create new rules, edit rules, and delete rules. If you created a rule as part of the Settings page, it shows up in this page.

The next page is the Summary page. Once you verify that everything looks correct, the last pages are the Progress and Completion pages.

Always Assume Application Is Installed: When this option is selected, the client assumes that the application is installed and does not check for the application.

Use Windows Installer Detection: You can select to use information inside an MSI file known as the globally unique identifier (GUID) and version number for the application. To obtain this information, click Open and select the MSI file for the application to automatically populate the fields.

This Application Is Installed for One or More Users: Select this check box to detect each user profile on the computer. Use when multiple users using the same computer have installed the same application.

wmic product where "name like '%Configuration Manager Client%'" get Name, IdentifyingNumber, version

Get-WmiObject -Class Win32_Product | Sort-object Name | select Name | where  { $_.Name -match "Configuration Manager Console"}

Figure 10.7 shows the Detection Methods page with some sample information.

FIGURE 10.7 Detection Methods page.

Name: Specify the name of the setting you are creating.

Description: Explain in detail what the setting is for.

Setting Type: Choose from a dropdown menu the type of setting you want to use in the condition statement.

Active Direction Query: Create an AD query, using the following parameters:

LDAP Prefix: The prefix to use for your AD query, which would be either LDAP:// or GC:// for a global catalog search.

Distinguish Name (DN): The DN of the object you want to query. This is the full DN of the object you want to use. An example would be OU=Unleashed, DC=Odyssey, DC=com.

Search Filter: Specify an additional filter to refine results from the Active Directory Directory Services (ADDS) query. To return all results from the query, enter (objectclass=*). More information about search filters is available at https://msdn.microsoft.com/library/aa746475(v=vs.85).aspx.

Search Scope: Choose the scope of your search:

Base: Queries only the specified object. In the example using the DN item in a previous bullet, this queries the Unleashed OU and nothing below it.

One Level: Not used in ConfigMgr.

Subtree: Queries the object you specified and anything below it. In the previous example using the DN item, this queries the Unleashed OU and any OU under it.

Property: Use to define the property of the object you want to query; an example would be pwdLastSet. Find a list of properties at https://msdn.microsoft.com/library/ms675090(v=vs.85).aspx.

Query: Automatically filled in from the previous items. For the example in this section, the query would read LDAP://OU=Unleashed, DC=Odyssey, DC=com;(objectclass=*);pwdLastSet.

Assembly: This is a piece of code that can be shared between applications. An assembly has the filename extension .dll or .exe. The global assembly cache (GAC) is a folder named %systemroot%Assembly on client computers, where all shared assemblies are stored.

Use Assembly name to enter the name of the assembly for which you want to search. The name cannot be the same as other assembly objects of the same type and must be registered in the GAC. The name can be up to 256 characters long. An example would be Microsoft.VisualBasic.

File System: Allows you to set a file or folder to be used for compliance.

Type: Choose either File or Folder for this option.

Path: Define the full path to the location where the file or folder is located. You can use environment variables. Be aware that if you use the %USERPROFILE% variable, all user profiles on the machine are searched, which may result in multiple instances of the file or folder being found. UNC paths are not supported.

File or Folder Name: You can use environment variables and the wildcards * and ? for the file or folder name. Note that using wildcards can cause high resource usage on the client machine.

Include Subfolders: Enables the search of subfolders under the path destination.

This File or Folder Is Associated with a 64-Bit Application: If this option is checked, only 64-bit locations like %ProgramFiles% are searched on 64-bit systems. If it is unchecked, both 64-bit and 32-bit locations are searched.

IIS Metabase: Use to query settings in the IIS metabase and check for compliance. This requires that the IIS 6 metabase compatibility feature be installed.

Metabase Path: Define the path to the metabase. An example is /LM/W3SVC/1/ROOT.

Property ID: IIS metabase properties are identified by numbers. An example is 3001, which would be the property ID of the path of the website, c:inetpubwwwroot.

Registry Key: Check to see if a certain Registry key exists on devices.

Hive Name: You can use this dropdown to manually choose a hive, or you can select Browse to browse the Registry, looking for the hive and key you want to use for compliance. The following are the hive names:

Click here to view code image

HKEY_CLASSES_ROOT
HKEY_CURRENT_CONFIG
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS

Key Name: Manually enter the path to the Registry key you want to use for compliance. If you selected Browse, this may already be filled in.

This Registry Value Is Associated with a 64-Bit Application: Specifies whether to search the 64-bit Registry keys in addition to 32-bit Registry keys when clients are running a 64-bit OS. If the same key exists on both 64-bit and 32-bit Registry hives, both keys are returned.

Registry Value: Check to see if a certain value in the Registry exists.

Hive Name: Choose hives from a dropdown menu. Use the dropdown to manually choose the hive or click Browse to browse the Registry, looking for the hive and key you want to use for compliance. The following are the hive names:

Click here to view code image

HKEY_CLASSES_ROOT
HKEY_CURRENT_CONFIG
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS

Key Name: Specify the path to the Registry key you want to use for compliance. If you selected Browse, this may already be filled in.

Value Name: Specify the Registry key value you want to use for compliance. If you selected Browse, this may already be filled in.

This Registry Value Is Associated with a 64-Bit Application: Specify whether to search 64-bit Registry keys in addition to 32-bit keys when clients are running a 64-bit OS. If the same key exists on both 64-bit and 32-bit Registry hives, both keys are returned.

Script: Execute a script to return the results needed for the compliance check.

Discovery Script: This can be a PowerShell, VBScript, or a Microsoft JScript. Click Open or just paste in your script. The script must return a value used in the compliance evaluation. For example, if you wanted to check if a service is stopped, your script would return Stopped.

Remediation Script (Optional): Use to fix a noncompliant client. This can be a PowerShell, VBScript, or Microsoft Jscript script. ConfigMgr can pass the compliant value to the script as a parameter, if needed.

Run Scripts by Using the Logged On User Credentials: Allow the script to be run by the current logged on user instead of using the local system.

Run Scripts by Using the 32-Bit Scripting Host on 64-Bit Devices: Use the 32-bit script engine to run a script when on a 64-bit device, fixing some issues when trying to run a script with the 64-bit engine.

SQL Query: Run a SQL query and use the results as a value for compliance evaluation. You might use this option to determine if all SQL servers are running the same version of SQL:

SQL Server Instance: The instance of SQL Server to use: the default instance, all instances, or a provided instance name.

Database: The SQL Server database to run the query against.

Column: The column containing the value you want to use for the compliance evaluation.

Transact-SQL Statement: The SQL query to use to return the value for compliance evaluation. Paste in your query or click Open to open an existing query.

WQL Query: Use to run a query against the local machine’s WQL database:

Namespace: The namespace to use to build out your query. An example would be rootcimv2.

Class: The name of the class to use to build your query. An example would be Win32_Service.

Property: The name of the property to use to build your query. An example would be Name.

WQL Query WHERE Clause: A condition added to the query. An example would be Name=CCMEXEC and StartMode=Auto.

XPath Query: Use to query data inside an eXtensible Markup Language (XML) file to use for compliance evaluation:

Path: The path of the XML file. ConfigMgr supports the use of all Windows system environment variables and the %USERPROFILE% user variable in the pathname.

XML Filename: The filename containing the XML query used to assess compliance on the client computers.

Include Subfolders: Search subfolders under the specified path.

This File Is Associated with a 64-Bit Application: Choose if the 64-bit system file location (%windir%System32) should be searched in addition to the 32-bit system file location (%windir%Syswow64).

XPath Query: Specify a valid full XML path language (XPath) query used to assess compliance on the client computers.

Namespaces: Open the XML Namespaces dialog box to identify namespaces and prefixes to be used during the XPath query.

Data Type: Choose the format of the data the condition returns before the compliance evaluation is made. Certain settings do not have data types, and some settings may not have all of the data types:

String

Date and time

Integer

Floating point

Version

Boolean

String array

Integer array

Name: Name the rule you are creating.

Description: Explain in detail what the condition rule is for.

Selected Setting: Pick the setting for which you want to create a compliance rule. Click Browse to open the Select Setting dialog box and then select the setting. If the setting you want to use is not there, select New Setting. When you are finished, click Select. You can also select Properties to view a read-only page of the properties of that setting.

Rule Type: Define what type of rule this will be. You have two choices:

Value: Sets up the rule to compare the value returned by the configuration item or script against the value that you specify.

Existential: Creates a rule that evaluates the setting depending on whether it exists on the device. If you use this, choose one of three settings:

The setting must exist on client devices

The setting must not exist on client devices

The setting occurs the following number of times

The Setting Must Comply with the Following Rule: Set the value to make the device compliant. Select an operator to use when the value is assessed for compliance. You can use the following operators:

Equals

Not equal to

Greater than

Less than

Between

Greater than or equal to

Less than or equal to

One of

None of

Remediate Noncompliant Rules When Supported: Select this option, and ConfigMgr may be able to automatically remediate the following rule types:

Registry Value: The Registry value is remediated if it is noncompliant and created if it does not exist.

Script: If you added a remediation script when the settings item was created, the script is run to remediate the issue.

WQL Query: The WQL value is set to the value to make it compliant, but only if the operator used is equals.

Report Noncompliance if This Setting Instance Is Not Found: Select this option to cause the CI to report noncompliant if the setting is not found on the client system.

Noncompliance Severity for Reports: Select this option to create a severity for report purposes when a device is noncompliant. The following severities can be used:

None

Information

Warning

Critical

Critical with event

Windows application CIs have an additional option at the bottom of this page: This application runs only on computers that have 64-bit hardware. This indicates that the application is 64-bit and will not run on a 32-bit version of Windows, preventing the CI from being applicable and evaluated on 32-bit versions of Windows.

Click Next, and you see the Progress page. This page flashes very quickly as the choices made in the wizard are written to the database.

The Completion page shows a success or failure for each item created in the wizard. Pay attention to this page to be sure all items were created successfully. If a failure is shown, review those settings and fix the issue that caused the failure.

FIGURE 10.8 Windows 8.1 and Windows 10 Device Settings page.

The bottom of the Devices Settings page, displayed in Figure 10.8, shows a check box for some additional settings not included in the default settings groups. If this box is checked, an additional settings page is added. This page is blank by default with an Add option that allows you to choose from several settings. Because the list includes settings from all devices, you may want to sort the list by the supported platforms to narrow down to the setting for which you are looking.

Many settings are common to Windows 8.x devices and Windows 10 devices. Microsoft provides in-depth information on Windows 8.1 and Windows 10 CI settings at https://docs.microsoft.com/sccm/compliance/deploy-use/create-configuration-items-for-windows-8.1-and-windows-10-devices-managed-without-the-client#windows-81-and-windows-10-configuration-item-settings-reference.

FIGURE 10.9 iOS Device Settings page.

iOS has some of the same settings as the other devices, and it has many more as well. View the full list of settings at https://docs.microsoft.com/sccm/compliance/deploy-use/create-configuration-items-for-ios-and-mac-os-x-devices-managed-without-the-client#ios-and-mac-os-x-configuration-item-settings-reference.

Use the Certificates page to import a certificate to push down to the device. Selecting Import allows you to choose the certificate and the destination store to which you want to import the certificate.

Each page has the check box Remediate noncompliant settings; this allows you to automatically remediate the setting when it is noncompliant. There is also a dropdown for noncompliance severity for reports, which you use to choose the severity to report when the item is noncompliant.

The Platform Applicability page points out settings not supported by all platforms chosen on the Supported Platforms page. These settings are not assessed for compliance on the unsupported platforms. Select Export report to export the settings to a comma-separated values (.csv) file.

The Summary page displays a complete summary of the choices made in the Create Configuration Item Wizard. Review this page to confirm that each item is correct.

Click Next, and the Progress page flashes by very quickly as the choices made in the wizard are written to the database.

The Completion page shows a success or failure for each item created in the wizard. Pay attention to this page to be sure all items were created successfully. If a failure is shown, review those settings and resolve the issue that caused it to fail.

To create a baseline, navigate to Assets and Compliance -> Compliance Settings -> Configuration Baselines. Select Create Configuration Baseline from the ribbon bar or from the right-click context menu to open the Create Configuration Baseline page. Figure 10.10 shows the default page for creating a new baseline.

FIGURE 10.10 Create Configuration Baseline page.

Add a name and description for the new baseline at the top of this dialog and pick the desired categories at the bottom by clicking Categories. CIs and baselines share the same set of categories from which to choose. Categories have no specific functional purpose outside console organization.

The primary activity when creating a baseline is choosing the configuration data it contains—collectively called evaluation conditions. Use the Add menu under the Configuration data list box, which has three choices when selected:

Configuration Items

Software Updates

Configuration Baselines

Each choice results in an object picker dialog, where you select the corresponding type of object to include in the baseline.

Application configuration items can have one of the following purposes:

Required: The application defined in the CI must exist on the target system in order to be compliant. All settings in the CI are also evaluated for compliance.

Optional: Settings in the CI are evaluated for compliance only if the application defined in the CI exists on a target system.

Prohibited: The application defined in the CI must not exist on the target system in order to be compliant. All settings in the CI are ignored.

Change the configuration item revision included in the baseline by selecting the CI in the Configuration data list box and selecting from the Change Revision dropdown menu. This allows you to modify and test a CI without affecting the baselines to which it belongs. The latest revision is included by default. Software updates and baselines always use the latest revision.

Software updates are always set to Required, meaning they must exist on the target system. Baselines are also set to Required, although this has no real substantive meaning other than that the CIs in the baseline will be evaluated according to the evaluation conditions set in that baseline.

To modify a baseline, including its evaluation conditions, select the baseline and choose Properties from the ribbon bar or right-click the baseline and choose Properties to see its properties dialog box. The Details pane appears at the bottom of the page when any baseline is selected. The Summary tab lists basic information about the baseline, including deployment status and the following compliance statistics:

Compliance Count

Noncompliance Count

Failure Count

Disabling a baseline prevents its evaluation on target systems even if it is deployed, as discussed in the next section. To disable a baseline, select it and choose Disable from the ribbon bar or from the right-click context menu. Choose Enable from the same locations to enable it later.

FIGURE 10.11 Deploy Configuration Baseline dialog box.

Configure the following properties for the deployment:

Selected configuration baselines

Remediation for noncompliant rules when supported and remediation is outside maintenance windows

Console alert generation, based on the compliance percentage after a defined date and time

System Center Operations Manager alert using the same criteria

Target collection

Baseline evaluation schedule

You can target baselines to device or user collections. When a baseline is targeted at a user collection, user settings contained in the baseline are evaluated against the currently logged in user. Each baseline chosen has its own deployment created. To view all deployments for a specific baseline, select the baseline in the console. The Details pane has two tabs, one of which is a Deployments tab, which you can select for a list of all deployments for the selected baseline.

To examine or modify baseline deployments, navigate to Monitoring -> Deployments, which lists all deployments, not just baseline deployments. Use the console search and filtering capabilities to list or find the deployment you want to view or modify. You cannot delete a baseline deployment from the Monitoring workspace; you must select it in the Assets and Compliance workspace and then delete its deployments from the Deployments tab of the Details pane of the baseline.

To modify a deployment, select it and choose Properties from the ribbon bar or from the right-click context menu. You see a dialog nearly identical to the Deploy Configuration Baselines dialog shown in Figure 10.10, where you can refine any of the deployment properties except the targeted collection. To change the targeted collection, you must create a new deployment for the baseline.

Do not expect immediate results after developing the process to create your CIs and deploying the baselines. Clients must receive policies for these deployments, evaluate them on the schedule assigned to them, and report the results back to ConfigMgr. Be aware of this time-consuming process so that you are not put in the position of needing results right away.

FIGURE 10.12 Configurations tab of the ConfigMgr Control Panel applet.

The list box in Figure 10.12 shows each baseline deployed to that client. Clicking Evaluate at the bottom of the page lets users trigger evaluation of selected baselines, enabling you to evaluate baselines in an on-demand environment and get almost instantaneous results when needed. By clicking View Report, you can let administrative users display a report that shows the most current evaluation results of the selected baseline. This lets you look at the compliance of a single machine; however, it is not intended be used as a report but rather as a tool to verify that your CIs and baselines are working correctly.

ConfigMgr has two built-in strategies for auto-remediation:

Using Built-in Remediation: For supported Windows CI setting types, WMI, Registry values, and scripts, you can enable remediation in the compliance rules referencing those settings. All settings in mobile device CIs support remediation, with a similar option in their configurations. Enabling this option causes a baseline evaluation to modify the settings value on the target system to the expected value.

Creating Collections: For settings that do not support built-in remediation or require more than correcting a single value, you can build a collection and deploy a program, an application, or a software update to that collection. ConfigMgr conveniently creates the query rule and the collection for you. Perform the following steps:

1. Select the desired baseline from the console.

2. From the Details pane at the bottom, select Deployments.

3. Select the appropriate deployment and choose Create New Collection from the ribbon bar or from the right-click context menu.

4. From the fly-out menu that appears, with the four compliance statuses as options, choose the desired compliance status for the new collection. The Create Device Collection Wizard appears, offering the same options as when you manually create a new collection except that all of the information, including a query membership rule, is provided.

5. Complete the wizard to create the new collection. After creating the collection, deploy a package, an application, or a software update to correct the issue. The actual actions performed are up to you and should correct any noncompliant issues the baseline can identify. Systems that fail compliance checks in the baseline automatically populate the collection, which in turn deploys your corrective action to those systems, correcting the issue.

Microsoft provides 22 reports out of the box for compliance settings. Figure 10.13 shows these reports.

FIGURE 10.13 Compliance Settings reports.

You can access the reports from two places:

ConfigMgr Console: Navigate to Monitoring -> Reporting -> Reports -> Compliance and Settings Management.

SQL Server Reporting Services (SSRS): SSRS uses the built-in reporting services of Microsoft SQL Server to provide access to the same reports you can see in the ConfigMgr console, plus access to any customized reports that may have been created outside the ConfigMgr reports folder in SSRS.

If you need to view the reports on a regular basis, you can create a subscription to a report either in the ConfigMgr console or SSRS, specifying whether the report should be delivered via email or pulled from a common network location. After you set up the subscription, the process is automatic; this saves an administrator the work of delivering the report.

Troubleshooting compliance settings, like troubleshooting the rest of ConfigMgr, is largely a log file review exercise. Because compliance settings evaluation is a client activity, the logs for compliance setting processing are on the client in the client logs folder (%SystemRoot%CCMLogs). Five log files are used by compliance settings to store activity; Table 10.2 describes these files. A complete list of log files is available in Appendix A, “Configuration Manager Log Files.”

TABLE 10.2 Compliance Settings Log Files

The Rules and errors summary of configuration items in a configuration baseline for an asset report is another tool to use when troubleshooting an issue, as it should clearly point out why the client is having problems.

In addition, issues involving ConfigMgr’s ability to evaluate a baseline or CI are reported through the ConfigMgr status message reporting mechanism. To view these status messages, follow these steps:

1. In the console, navigate to Monitoring -> System Status -> Status Message Queries.

2. From the list of status message queries on the right, select All Status Messages and then Show Messages from the ribbon bar or from the right-click context menu.

3. In the All Status Messages dialog box, enter the desired time frame for which you would like to see status messages.

4. Review the displayed messages, looking for any message IDs listed in Table 10.3.

TABLE 10.3 Compliance Settings Client Status Messages

Using the message IDs listed in Table 10.3 can help narrow down the issues but can also add questions and necessitate research as the message IDs are not user friendly. In these cases, it is useful to gather the client logs referred to in Table 10.3 and find the status message number in the log file. This can help show you what was occurring right before the status message was created and right after it was created. The error or problem may be in that small section of the log files.

These status messages also provide the ability to track and monitor the evaluation status of baselines in your site.

Compliance Settings seamlessly integrates with the rest of ConfigMgr, providing a “single pane of glass” to manage all your systems and devices. Just having the ability to provide consistent and timely compliance reports to auditors is critical for any type of review.

ConfigMgr’s compliance settings feature efficiently fills a major blind spot in most organizations—configuration and compliance verification and enforcement—without requiring implementation of any additional enterprise tools. Microsoft keeps enhancing this area of ConfigMgr, so look for more great capabilities and supported devices in the future.