Set the allowed Management Points via a Configuration Item in ConfigMgr 2012

This blog post will be about a new functionality that got introduced in Cumulative Update 3. This is the ability to configure a Management Point (MP) affinity on a client. Justin Chalfant wrote a nice post about this functionality. That post describes the functionality in detail and also shows how it can be configured. The only thing left open is an automated method to configure the MP affinity. This post will fill that small gap by providing a Configuration Item (CI) that contains the scripts to configure the MP affinity.

Configuration Item

General_AllowedMPsNow let’s start with the details about the CI. Personally I really like this CI, as it’s created in such a way that it doesn’t need any script modifications any more. The discovery script and the remediation script, both interact in a way with the compliance rule. The discovery script makes sure that it puts the data of the AllowedMPs value in a readable format to compare it with the value of the compliancy rule and the remediation script makes sure that it uses the value of the compliance rule as an input parameter for the remediation. Now let’s go through these scripts and the compliancy rule in a bit more detail.

Discovery script

The discovery script does nothing really fancy, but it does something important that I need for checking the data of the current AllowedMPs value. Basically the script performs the following four actions:

  • First, it checks if the registry key HKLM:SOFTWARE\Microsoft\CCM exists and if it does not exist it sets the compliance variable to “Key does not exist”. Actually, this check should always pass, as this registry key is created during the installation of the ConfigMgr client;
  • Second, it gets the data of the AllowedMPs value, when the registry key does exist .
  • Third, it checks if the AllowedMPs value exists and if it does not exist it sets the compliance variable to “Value does not exist”.
  • Fourth, it reads the data of the AllowedMPs value, adds it to a string separated by comma’s (“,”) and sets the compliance variable to that string. This makes sure that the compliance variable can be used to verify the server names configured in the compliance rule.

This all comes together in the following script:

try { $strKeyPath = "HKLM:SOFTWARE\Microsoft\CCM" if (!(Test-Path -Path $strKeyPath)) { $Compliance = "Key does not exist" } else { $strAllowedMPs = (Get-ItemProperty ` -Path $strKeyPath).AllowedMPs if ($strAllowedMPs -eq $null) { $Compliance = "Value does not exist" } else { $Compliance = $strAllowedMPs -join "," } } } catch { $Compliance = $Error.Exception $Error.Clear() } finally { $Compliance }

Remediation script

The remediation script also does nothing really fancy, but it does something really important for configuring the data of the AllowedMPs value. Basically the script performs the following two actions:

  • First, it checks if the registry key HKLM:SOFTWARE\Microsoft\CCM exists and if it does not exist it will create it. Actually, this check should always pass, as this registry key is created during the installation of the ConfigMgr client;
  • Second, it loops through the input arguments of the script and creates the AllowedMPs value with the input arguments as data. These input arguments are the server names configured in the compliance rule.

This all comes together in the following script:

try { $strKeyPath = "HKLM:SOFTWARE\Microsoft\CCM" if (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } foreach ($arg in $args) { New-ItemProperty $strKeyPath -Name AllowedMPs ` -Value $arg -PropertyType MultiString -Force } } catch { $Error.Exception $Error.Clear() }

Compliance rule

Rule_AllowedMPsThe compliance rule is where it all comes together. In both, the discovery script and the remediation script, I mentioned the link with the compliance rule. In the compliance rule I can configure the MPs that I would like to be configured as data for the AllowedMPs value. In this compliance rule there are two core configurations to make this CI work:

  1. The The value returned by the specified script setting is configured to Equals the following value servername1,servername2. The key here is that the server names are separated by only a comma (“,”).
  2. The Run the specified remediation script when this settings is noncompliant box is checked. This is to make sure that the remediation script is used.

Usage

To make it really easy for everyone, I exported the CI and made it available for download via the TechNet Galleries. Simply download this CI and import it in ConfigMgr. After that there is only one important step left. That step is to configure the server names as mentioned in the compliance rule section. Currently it’s set to server names from my lab environment. Simply change these server names to the server names required for the specific environment. Keep in mind that it should be noted as servername1,servername2 and that those server names should be the FQDN of those servers. Also note that I would advise to specify at least two server names, to provide some sort of a fallback scenario for the ConfigMgr client.

>> The complete configuration item is available via download in the TechNet Galleries! <<

Result

Now it’s time to take a look at the compliancy results of a client. Basically all clients should show compliant, simply because they will be remediated when they’re not. The first time this CI will run on the client, it will show the old value and the remediated value in the reports. As that will show a nice overview of the actions that are performed, I used that to show the results below. Also, I picked the client-side report instead of the server-side report. The only reason for that is its size, this report is more compact.

Result_AllowedMPs

Leave a Comment