Create a WQL query setting for a Configuration Item in ConfigMgr 2012 via PowerShell

Before I start with this blog post I have to give some (read: a lot) of credits to Dexter. He helped me a lot with understanding the SDMPackageXML of a Configuration Item (CI) and also blogged about that experience. Also, this blog post won’t go into the details he already mentioned about modifying the XML and writing it to a CI.

Now let’s really start with this blog post. This blog post will be about creating a WQL query setting for a CI and more specifically the road to creating a WQL query setting for a CI.

Step 1: Locate the method to create the WqlQuerySetting

WqlQuerySettingThe first step is to locate the method that can be used to create the WqlQuerySetting. During the installation of the Configuration Manager Console many files are installed and registered including a DLL named Microsoft.ConfigurationManagement.DesiredConfiguration.dll. This specific DLL contains the functions that are needed to create settings and compliance rules for a CI. Opening this DLL with something like the Object Browser of Visual Studio will show the different methods and parameters included. This will show the following information about creating the setting WqlQuerySetting(Microsoft.ConfigurationManagement.DesiredConfiguration.Rules.DataType settingDataType, string logicalName, string name, string description).

Step 2: Locate and set the object information for the WqlQuerySetting

WqlSettingXMLThe second step is to set the information to different input parameters that are required to create the setting. Based on the information, found in the DLL, it’s clear what information is needed and based on an existing SDMPackageXML it’s also clear what it should look like. Specifically for setting the logicalName it’s good to know the prefix of the GUID (as it differs per setting type). Another thing to look at is the settingDataType. The easiest method to find correct values for this is by browsing to the object in Visual Studio. Together this brings me to the following input variables for creating the WqlQuerySetting:

#Set the WqlQuerySetting object information $WqlQuerySettingDataType = ([Microsoft.ConfigurationManagement.` DesiredConfiguration.Rules.ScalarDataType]::Int64) $WqlQuerySettingLogicalName = "WqlSetting_$([Guid]::NewGuid())" $WqlQuerySettingName = "$WqlQuerySettingClass"+"_"+"$WqlQuerySettingProperty" $WqlQuerySettingDescription = "Scripted setting"

Step 3: Create the WqlQuerySetting and set the properties

The third step is to really create the WqlQuerySetting object and to set the properties for the new object. Again the easiest method to find the available properties is by browsing the class. Together this brings me to the following code for creating the setting and setting the properties:

#Create the WqlQuerySetting object and set the properties $WqlQuerySetting = New-Object -TypeName Microsoft.ConfigurationManagement.` DesiredConfiguration.Settings.WqlQuerySetting -ArgumentList ` $WqlQuerySettingDataType,$WqlQuerySettingLogicalName,` $WqlQuerySettingName,$WqlQuerySettingDescription $WqlQuerySetting.Class = $WqlQuerySettingClass $WqlQuerySetting.Namespace = $WqlQuerySettingNamspace $WqlQuerySetting.Where = $WqlQuerySettingWhere $WqlQuerySetting.Property = $WqlQuerySettingProperty

One might notice that I used all variables to fill these properties. That’s because I use this as part of a complete method that requires the values to those properties as input, so it can be reused. An example for these properties would be something like the following:

#Set the WqlQuerySetting properties $WqlQueryClass = "Win32_OptionalFeature" $WqlQueryNamespace = "root\cimv2" $WqlQueryWhere = "Name='BITS'" $WqlQueryProperty = "InstallState"

Step 4: Write the WqlQuerySetting to the Configuration Item

CI_WqlSettingXMLThe fourth, and last, step is to add the WqlQuerySetting to a CI. To do this it is important to add it to the correct element of the SDMPackageXML. This is also were it differs from what Dexter did and by that also the reason why I’m mentioning it. The setting needs to be added to the RootComplexSetting element and the tricky part is that it’s an empty element at the beginning. The following code gets the right part of the WqlQuerySetting and adds it to the SDMPackageXML.

#Import the WqlQuerySettingXML node to the SDMPackageXML of the CI $ImportNodeXML = ` $CISDMPackageXML.ImportNode($WqlQuerySettingXML.SimpleSetting,$true) #Add the imported node to the SDMPackageXML of the CI $CISDMPackageXML.DesiredConfigurationDigest.OperatingSystem.Settings.` ChildNodes[0].AppendChild($ImportNodeXML)

>> The complete function is available via download here on the TechNet Galleries! <<

Share

Verify SQL version via Compliance Settings in ConfigMgr 2012

This time I will do a short post about verifying the SQL version(s) via Compliance Settings. I think everybody knows the inventory post for SQL version by Sherry Kissinger, but what if you simply want to know if all your devices are compliant with the company standard (of for example SQL Server 2012 SP1 CU5). Well, this blog post will provide a simple answer to that question, by providing a SQL query –type Configuration Item.

Configuration Item

The configuration is actually quite simple, as I can simply take advantage of the SELECT @@VERSION query statement. One small thing to take into account, is the fact that the configuration item requires a column to be specified and this queries doesn’t use/ create a named column. The easiest way to work with this is a simple adjustment of the query statement to SELECT @@VERSION AS Version. Now version can be used as the column name. To complete the configuration of the item, the following settings can be used (on the left the general settings and on the right the compliance rule settings).

General Compliance rule
Name: Version
SQL Server instance: All instances
Database: master
Column: Version
Transact-SQL statement: Select @@VERSION AS Version
The setting must comply with the following rule: Version Begins with Microsoft SQL Server 2012 (SP1) – 11.0.3373.0 (X64)
SQLVersion SQLVersion_CR

Results

Now lets take a look at the compliancy results of a server running SQL Server 2012 SP1. Of course it’s not really exiting to look at a compliant server, so I picked a non-compliant server with SQL Server 2012 SP1 (and KB2793634). The nice thing about a non-compliant server is that the results are more detailed. It will show the configuration, the expression and the current value. Note that this is the client-side report. SQLVersion_Result

Share

Verify SSL Configurations of Site Roles via Compliance Settings in ConfigMgr 2012

This will be a short blog post about the locations in the registry where the SSL configurations are stored for the different site roles. This can be very useful in larger environments, with many sites, site systems and multiple administrators. These registry keys can be used as Configuration Items in a Configuration Baseline. This makes it easier to keep track of the SSL configuration of the environment.

Registry

Before providing the different locations, I think it’s good to note that the most site roles simply use 0 or 1 as values for a SSL configuration. Exceptions on this are the management point and the distribution point. These site roles can have different values based on the connection configuration (intranet and Internet, intranet-only, Internet-only) and CRL checking configuration. For all roles 0 stands for HTTP and everything greater than 0 stands for HTTPS.

Application Catalog web service point
Hive Name: HKEY_LOCAL_MACHINE
Key Name: SOFTWARE\Microsoft\SMS\AWEBSVC
Value Name: UseSSL
Compliance: UseSSL Equals 1 (UseSSL must exist)

Application Catalog website point
Hive Name: HKEY_LOCAL_MACHINE
Key Name: SOFTWARE\Microsoft\SMS\PORTALWEB
Value Name: UseSSL
Compliance: UseSSL Equals 1 (UseSSL must exist)

Distribution point
Hive Name: HKEY_LOCAL_MACHINE
Key Name: SOFTWARE\Microsoft\SMS\DP
Value Name: IISSSLState
Compliance: IISSSLState Greater than 0 (IISSSLState must exist)

Management point
Hive Name: HKEY_LOCAL_MACHINE
Key Name: SOFTWARE\Microsoft\SMS\MP
Value Name: SSLState
Compliance: SSLState Greater than 0 (SSLState must exist)

Software update point
Hive Name: HKEY_LOCAL_MACHINE
Key Name: SOFTWARE\Microsoft\Update Services\Server\Setup
Value Name: UsingSSL
Compliance: UsingSSL Equals 1 (UsingSSL must exist)

Share

Verify local administrators via PowerShell and Compliance Settings in ConfigMgr 2012

Everybody probably knows the inventory posts for local administrators by Sherry Kissinger, but what if you want to know the compliance of your devices. What if you “just” want to know if a device is compliant to company defaults for the local administrators. This blog post will provide an answer to that question. It will provide a script, including explanation, that can be used for compliance checks. This blog post won’t go into details about creating the Configuration Item and the additional Configuration Baseline.

Script

The script that will be the core of this Configuration Item consists of three key parts. Basically, it first finds the members of the local administrators group on the device, then verifies these members and in the end it returns the compliance of the device. Per key part this means the following:

  1. The first part is finding the members of the local administrators group. There are multiple methods to find the members of the local administrators group and those methods are described in detail, in this great post by the Scripting Guys. I prefer to go for using WMI, which means I have to look at two things.
    1. The first thing is finding the users that are a member of the local administrators group.
      $LocAdmGroupMembers = (Get-WmiObject -Query "ASSOCIATORS OF ` {Win32_Group.Domain='$($env:COMPUTERNAME)',Name='Administrators'} ` WHERE ResultClass = Win32_UserAccount").Caption

    2. The second thing is finding the groups that are a member of the local administrators group.
      $LocAdmGroupMembers += (Get-WmiObject -Query "ASSOCIATORS OF ` {Win32_Group.Domain='$($env:COMPUTERNAME)',Name='Administrators'} ` WHERE ResultClass = Win32_Group").Caption

  2. The second part is comparing the members of the local administrators group with a list of what the members of the local administrators group should be. This piece will count every corresponding member and will write every illegal member to a specific variable. Both local and domain users and groups can be added to the check-list.

    foreach($Member in $LocAdmGroupMembers) { switch ($Member) { "$($env:COMPUTERNAME)\<UserName>" ` {$MemberCount = $MemberCount + 1; break;} "$($env:COMPUTERNAME)\<GroupName>" ` {$MemberCount = $MemberCount + 1; break;} "<DomainName>\<UserName>" ` {$MemberCount = $MemberCount + 1; break;} "<DomainName>\svcServiceMgr-SVC" ` {$MemberCount = $MemberCount + 1; break;} default {$IllegalMember += "$Member`n"} } }

  3. The third and last part is to check for compliance. In case the corresponding members match the number of the member count. and there are no illegal members found. the script will return Compliant. In case there is mismatch the script will return the illegal members (if applicable).
    if (($MemberCount -eq 4) -and ($IllegalMember -eq "")) { $Compliance = "Compliant" } else { $Compliance = $IllegalMember } Return $Compliance

Putting the pieces together make the complete script to look like this:

$MemberCount = 0 $IllegalMember = "" $LocAdmGroupMembers = (Get-WmiObject -Query "ASSOCIATORS OF ` {Win32_Group.Domain='$($env:COMPUTERNAME)',Name='Administrators'} ` WHERE ResultClass = Win32_UserAccount").Caption $LocAdmGroupMembers += (Get-WmiObject -Query "ASSOCIATORS OF ` {Win32_Group.Domain='$($env:COMPUTERNAME)',Name='Administrators'} ` WHERE ResultClass = Win32_Group").Caption foreach($Member in $LocAdmGroupMembers) { switch ($Member) { "$($env:COMPUTERNAME)\<UserName>" ` {$MemberCount = $MemberCount + 1; break;} "$($env:COMPUTERNAME)\<GroupName>" ` {$MemberCount = $MemberCount + 1; break;} "<DomainName>\<UserName>" ` {$MemberCount = $MemberCount + 1; break;} "<DomainName>\svcServiceMgr-SVC" ` {$MemberCount = $MemberCount + 1; break;} default {$IllegalMember += "$Member`n"} } } if (($MemberCount -eq 4) -and ($IllegalMember -eq "")) { $Compliance = "Compliant" } else { $Compliance = $IllegalMember } Return $Compliance

Usage

This script can be used as a Discovery script in a Configuration Item. The Compliance Rule for this Configuration Item has to be configured to The value returned by the specified script: Equals Compliant.

Result

Now lets take a look at the compliancy results of a device. Of course it’s not really exiting to look at a compliant device, so I picked/ created a non-compliant device. This will also show the results of the illegal members of the local administrators group. 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.

CheckLocalAdministrators

Share

Installing Windows Features via Compliance Settings in ConfigMgr 2012

This weeks’ post will be about Installing Windows Features via Compliance Settings. In most cases the normal route for installing Windows Features will be the application model But what if checking for the installation of a Windows Feature is part of a Configuration Baseline, is it than possible to make the installation of a Windows Feature also part of the baseline? The answer to this question is, yes.

In my case, I have a Windows 8.1 Configuration Baseline and one of the Configuration Items in the baseline checks for the installation of the Telnet Client. When the Telnet Client is not installed a script will start to remediate that by installing the Telnet Client. This way I get the complete compliance of a device, to my Windows 8.1 baseline, in one overview.

The rest of this post will describe in three steps, how to create the Configuration Item, how to create the Configuration Baseline and how to deploy the Configuration Baseline.

Step 1: Create the Configuration Item

Now lets start with the first step of creating a Configuration Item that will check and remediate the installation of the Telnet Client. Both, the check and the remediation will be done by firing a PowerShell script.

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items.
  • On the Home tab, in the Create group, click Create Configuration Item and the Create Configuration Item Wizard will popup.
  • On the General page, fill in with Name <aCIName> and click Next.
  • On the Supported Platforms page, select Windows 8.1 and click Next.
  • TelnetClientSettingOn the Settings page, click New, fill in the following information and click Next.
    • On the General tab, fill in the following information and click OK.
      • Fill in as Name <aSName>.
      • Select as Setting Type Script.
      • Select as Data Type String.
      • Click with Discovery script Edit Script… and in the Edit Discovery Script popup add the following script and click Ok.
        $FeatureName = "TelnetClient" If (Get-WindowsOptionalFeature -Online | Where {$_.State ` -eq "Enabled" -and $_.FeatureName -eq $FeatureName}) { $Compliance = "Compliant" } Else { $Compliance = "NonCompliant" } Return $Compliance

      • Click with Remediation script (optional) Edit Script… and in the Edit Discovery Script popup add the following script and click OK.
        $FeatureName = "TelnetClient" Enable-WindowsOptionalFeature -Online -FeatureName $FeatureName

    • TelnetClientRuleOn the Compliance Rules tab, click New, fill in the following information and click OK.
      • Fill in as Name <aRName>.
      • Select as Rule Type Value.
      • Select with The settings must comply with the following rule: Equals.
      • Fill in with the following values Compliant.
        • Note: This value is important for it to function, as it is “hardcoded” in the script.
      • Select Run the specified remediation script when this setting is noncompliant.
      • Select with Noncompliance severity for reports: Information.
  • On the Compliance Rules page click Next.
  • On the Summary page click Next.
  • On the Completion page click Close.

Step 2: Create the Configuration Baseline

The second step is to create a Configuration Baseline that will allow the new Configuration Item to be evaluated for compliance.

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines.
  • TelnetClientBaselineOn the Home tab, in the Create group, click Create Configuration Baseline and the Create Configuration Baseline popup will show.
  • On the Create Configuration Baseline popup, fill in with Name <aCBName> and click Add > Configuration Item and the Add Configuration Items popup will show.
  • On the Add Configuration Items popup select the new Configuration Item <aCIName>, click Add, click OK and back on the Create Configuration Baseline popup click OK.

Step 3: Deploy the Configuration Baseline

The third and final step is to deliver the Configuration Baseline to the client devices by deploying it.

  • TelnetClientDeploymentIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines.
  • Select the new Configuration Baseline <aCBName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Configuration Baselines popup will show.
  • On the Deploy Configuration Baselines popup, select Remediate noncompliant rules when supported, Browse to <aCollection> and click OK.

Conclusion

Even though a Configuration Baseline is not the most conventional way for installing Windows Features, it’s a good possibility for specific use cases. In case the check for existence of a feature is part of the baseline, then it would be an option to put the remediation in the same baseline. That way there is one view to check for the baseline compliance and not a specific view with deployment states. In most cases a normal application deployment, or task sequence deployment, will fit the needs. Don’t use this because it’s possible, but because it fits the needs.

Share

Go to Desktop on Sign In on Windows 8.1 via Compliance Settings in ConfigMgr 2012

This weeks’ post will be about Going to the desktop, instead of Start, when signing on Windows 8.1 via Compliance Settings. I will write about the scripts for discovering and remediating this setting, either on a user based, or a computer based configuration, via a Configuration Item. Keep in mind that it won’t be a walkthrough. For a complete step-by-step example, about using scripts in Compliance Settings, take a look at my post about Allowing Direct Installation of Windows 8 Apps via Compliance Settings in ConfigMgr 2012.

Of course, in the most situations, the preferable way for configuring this settings is via a Group Policy (as described in this great post of Sander Berkouwer). There are a only a few reason not to use a Group Policy, and to start looking at Compliance Settings, like when the device is not a member of the domain, or when the company likes one way to configure a setting for all devices.

Computer based configuration

Now lets start with the first scenario. In this case we want to configure it for every user that logs in to a device. The best way to configure this is via HKEY_LOCAL_MACHINE. For this we need to create a discovery and remediation script for the existence and value of the value GoToDesktopOnSignIn in the key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer.

Discovery script

The discovery script has only one purpose and that’s to find find the mentioned registry key and its value. When the script finds the registry key, it will return Compliant, otherwise it will return NonCompliant. The Compliance Rule of the Configuration Item should check on the returned value of Compliant.

$strKeyPath = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $strKeyPath).GoToDesktopOnSignIn -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

Remediation script

Also the remediation script has only one purpose and that’s to find find the remediate registry key and its value. This script will create registry key and when needed also the path to the registry key.

$strKeyPath = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } New-ItemProperty $strKeyPath -Name GoToDesktopOnSignIn -Value 1 -Force

User based configuration

Now lets go on with the second scenario. In this case we want to configure it for specific users on any device. The best way to configure this is usually via the HKEY_CURRENT_USER, but this introduces the following problems when managed via ConfigMgr:

  • By default, ConfigMgr will run the discovery and remediation scripts with the SYSTEM account. In this situation this means that actions written to HKEY_CURRENT_USER will actually be written to HKEY_USERS\.DEFAULT.
  • Running the discovery and remediation scripts by using the logged on user credentials will end-up in an Access Denied message. As a normal user can’t write in the policy registry keys under HKEY_CURRENT_USER.
    • Note: This is a good option when the targeted users are administrators on their devices.

So we need to get creative. The registry keys that we CAN edit, per user, with the SYSTEM account, are under HKEY_USERS. This means that the way to workaround this, is to use the value GoToDesktopOnSignIn in the key HKEY_USERS\<CurrentUserSID>\SOFTWARE\Policies\Microsoft\Windows\Explorer.

Discovery script

The discovery script has only one purpose and that’s to find find the mentioned registry key and its value.The first thing this script does is determining the current logged on user and the corresponding SID. That information will be used with searching the registry key under the HKEY_USERS. When the script finds the registry key, it will return Compliant, otherwise it will return NonCompliant. The Compliance Rule of the Configuration Item should check on the returned value of Compliant.

$strCurrentUser = (Get-WmiObject Win32_ComputerSystem -Computer ".").UserName $objCurrentUser = New-Object System.Security.Principal.NTAccount($strCurrentUser) $strCurrrentUserSID = ($objCurrentUser.Translate([System.Security.Principal.SecurityIdentifier])).Value New-PSDrive HKU Registry HKEY_USERS $strKeyPath = "HKU:\$strCurrrentUserSID\Software\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $strKeyPath).GoToDesktopOnSignIn -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

Remediation script

Also the remediation script has only one purpose and that’s to find find the remediate registry key and its value. Like the discovery script, the first thing this script does is determining the current logged on user and the corresponding SID. That information will be used with creating the registry key, and when needed also the path to the registry key, under the HKEY_USERS.

$strCurrentUser = (Get-WmiObject Win32_ComputerSystem -Computer ".").UserName $objCurrentUser = New-Object System.Security.Principal.NTAccount($strCurrentUser) $strCurrrentUserSID = ($objCurrentUser.Translate([System.Security.Principal.SecurityIdentifier])).Value New-PSDrive HKU Registry HKEY_USERS $strKeyPath = "HKU:\$strCurrrentUserSID\Software\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } New-ItemProperty $strKeyPath -Name GoToDesktopOnSignIn -Value 1 -Force

Conclusion

It is very doable to use a Configuration Item to configure Going to the desktop, instead of Start, when signing on Windows 8.1, in either a user based, or a computer based configuration. The user based configuration needed some creative scripting, but the computer based configuration is very straight forward.

Share

Allow Direct Installation of Windows 8 Apps via Compliance Settings in ConfigMgr 2012

This weeks’ post will be about Allowing Direct Installation of Windows 8 Apps via Compliance Settings and can be seen as either a stand-alone post as well as a follow-up on my last post about Deploying Certificate Profiles with ConfigMgr 2012 . As there are two real requirements to deploy Windows 8 Apps:

  • The Certification Authority (CA), that is used to sign the App, is trusted by the Windows 8 device.
  • Allow Direct Installation of Windows 8 Apps is configured on the Windows 8 device.

Of course these settings are configurable via Group Policies (as described in this post ), but, to use Group Policies, the device needs to be a member of the domain. So when either the device isn’t domain joined, or the company likes one way to configure a setting for all devices, see part 1 of this post for deploying a root certificate and read the rest of this post for Allowing Direct Installation of Windows 8 Apps .

Create the Configuration Item

Now lets start with creating a Configuration Item that will check and remediate the existence and value of the value AllowAllTrustedApps in the key HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx .

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items .
  • On the Home tab, in the Create group, click Create Configuration Item and the Create Configuration Item Wizard will popup.
  • On the General page, fill in with Name <aCIName> and click Next .
  • On the Supported Platforms page, select Windows 8 and Windows 8.1 Preview and click Next .
  • AllowAllTrustedAppsOn the Settings page, click New , fill in the following information and click Next .
    • On the General tab, fill in the following information and click OK .
      • Fill in as Name <aSName> .
      • Select as Setting Type Script .
      • Select as Data Type String .
      • Click with Discovery script Edit Script… and in the Edit Discovery Script popup add the following script and click Ok .
        $Path = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Appx" If (!(Test-Path -Path $Path)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $Path).AllowAllTrustedApps -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

      • Click with Remediation script (optional) Edit Script… and in the Edit Discovery Script popup add the following script and click OK .
        $Path = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Appx" If (!(Test-Path -Path $Path)) { New-Item -Path $Path -Force } New-ItemProperty $Path -Name AllowAllTrustedApps -Value 1 -Force

    • AllowAllTrustedApps_CompliantOn the Compliance Rules tab, click New , fill in the following information and click OK .
      • Fill in as Name <aRName> .
      • Select as Rule Type Value .
      • Select with The settings must comply with the following rule: Equals .
      • Fill in with the following values Compliant .
        • Note : This value is important for it to function, as it is “hardcoded” in the script.
      • Select Run the specified remediation script when this setting is noncompliant .
      • Select with Noncompliance severity for reports: Information .
  • On the Compliance Rules page click Next .
  • On the Summary page click Next .
  • On the Completion page click Close .

Create the Configuration Baseline

The second thing to do is to create a Configuration Baseline to allow the new Configuration Item to be evaluated for compliance.

  • ConfBaseIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines .
  • On the Home tab, in the Create group, click Create Configuration Baseline and the Create Configuration Baseline popup will show.
  • On the Create Configuration Baseline popup, fill in with Name <aCBName> and click Add > Configuration Item and the Add Configuration Items popup will show .
  • On the Add Configuration Items popup select the new Configuration Item <aCIName> , click Add , click OK and back on the Create Configuration Baseline popup click OK .

Deploy the Configuration Baseline

The last thing to do is to deliver the Configuration Baseline to the client devices by deploying it.

  • DeplConfBaseIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines .
  • Select the new Configuration Baseline <aCBName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Configuration Baselines popup will show.
  • On the Deploy Configuration Baselines popup, select Remediate noncompliant rules when supported , Browse to <aCollection> and click OK.

Results

As always, now it is time to take a look at the results! There is a lot to show, like log files, the checked and/or created registry key and even the compliance information. I think the nicest one, in this situation, is the DcmWmiProvider.log , as it will show the information about running the different scripts. The log will show the result of running the discovery script, followed by the remediation script and their results. DcmWmiProvLog

Share

Deploying Certificate Profiles with ConfigMgr 2012

This week I want to devote a post to something new in ConfigMgr 2012 R2, which is still in a preview state, called Certificate Profiles. These profiles integrate directly with Active Directory Certificate Services (ADCS), and the Network Device Enrollment Service (NDES) role, to provision managed devices with authentication certificates. This means that another Group Policy setting is coming to ConfigMgr AND, maybe even bigger, this creates a possibility to automatically deploy certificates to non-domain devices. 

Prerequisites

Even though this sounds, to me, really promising for the future of ConfigMgr, there is a small catch. That small catch is the third bullet of the prerequisites, following now:

  • Configuration Manager 2012 Service Pack 1 R2
  • Install and configure the Certificate Registration Point (which requires the NDES for ADCS). For a great installation guide see: http://technet.microsoft.com/en-us/library/dn270539.aspx
    • Note: The Certificate Registration Point doesn’t have to be installed on the NDES server.
  • Windows (RT) 8.1, iOS or Android clients

Part 1 – Root Certificate

When all the prerequisites are met, let’s start with configuring. The deployment of Certificate Profiles always consist out of two parts, deploying a root certificate followed by deploying a client certificate. So lets start with the first part, the configuration and deployment of a Certificate Profile for the root certificate:

  • RootCertPropIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Company Resource Access > Certificate Profiles.
  • On the Home tab, in the Create group, click Create Certificate Profile and the Create Certificate Profile Wizard will popup.
  • On the General page, fill in with Name <aCPName>, select Trusted CA certificate and click Next.
  • On the Trusted CA Certificate page, browse (by clicking on Import) to the exported root certificate, select Computer certificate store – Root and click Next.
  • On the Supported Platforms page, select Windows 8.1 Preview and click Next.
    • Note: All the other supported platforms are iPhone/ iPod/ iPad 5 and 6 and all Android devices.
  • On the Summary page click Next.
  • On the Completion page click Close.

Now the configuration is created it’s time for the deployment. An important step of this deployment is the remediation. So to deploy and remediate the Certificate Profile follow the next steps:

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Company Resource Access > Certificate Profiles.
  • Select the new item <aCPName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Trusted CA Certificate Profile popup will show.
  • On the Deploy Trusted CA Certificate Profile popup, browse to a device collection, select Remediate noncompliant rules when supported and click Ok.

Part 2 – Client Certificate

After the Certificate Profile for the root certificate is deployed, it’s time to start with the configuration and deployment of a Certificate Profile for the client certificate. It’s important to note that a root certificate has to be deployed to enable a successful client certificate deployment. Also a Certificate Profile for the deployment of the root certificate is a prerequisite for a Certificate Profile for the deployment of a client certificate:

  • ClieCertProp1In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Company Resource Access > Certificate Profiles.
  • On the Home tab, in the Create group, click Create Certificate Profile and the Create Certificate Profile Wizard will popup.
  • On the General page, fill in with Name <aCPName>, select Simple Certificate Enrollment Protocol (SCEP) settings and click Next.
  • On the SCEP Enrollment page, select Install to Trusted Platform (TPM) if present, then select Allow certificate enrollment on any device and click Next.
  • ClieCertPropOn the Certificate Properties page select with Certificate template name <aCertificateTemplate>, select with Root CA certificate the previously created Certificate Profile and click Next.
    • Note: All the other settings will be filled automatically, but are customizable, based on the selected template, but Read rights on the selected template are necessary for the user. Also the selected template has to be configured on the Network Device Enrollment Service server, in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP.
  • On the Supported Platforms page, select Windows 8.1 Preview and click Next.
    • Note: All the other supported platforms are iPhone/ iPod/ iPad 5 and 6 and all Android devices.
  • On the Summary page click Next.
  • On the Completion page click Close.

Now the configuration is created it’s again time for the deployment. And again an important step of this deployment is the remediation. So to deploy and remediate the Certificate Profile follow the next steps:

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Company Resource Access > Certificate Profiles.
  • Select the new item <aCPName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Trusted CA Certificate Profile popup will show.
  • On the Deploy Trusted CA Certificate Profile popup, browse to a device collection, select Remediate noncompliant rules when supported and click Ok.

Result

These Certificate Profiles are handled via the Compliance Settings (see the standard compliancy log files). As soon as a device is non-compliant, AND Remediate noncompliant rules when supported is configured, the CCM Certificate Enrollment Agent will kick in. The Enrollment Agent will then communicate directly with NDES to do a certificate request via the Simple Certificate Enrollment Protocol (SCEP). The success and/ or failures of this process can be followed in a new log file named CertEnrollAgent.log. This log file will show information like this snippet of a successful enrolment on my workgroup device: CertEnroAgen

Another good place to look is a MMC with the Certificates snap-in, on the enrolled device. This will immediately show whether, or not the the Certificate Profile provided a successful enrollment of the a certificate: MMCCertSnapIn

The last good place to check, that I want to show, is the Certification Authority. A successful request should be visible with the Issued Certificates. This request will show as requester the service account of NDES:CertAuthIssuCert

Share

Managing User Data and Profiles with ConfigMgr 2012

This week I want to devote a post to something new in ConfigMgr 2012 SP1, which is still in BETA, called User Data and Profiles Configuration Items. These configuration items contain settings that can manage folder redirection, offline files and roaming profiles via ConfigMgr 2012! This means that another Group Policy setting is coming to ConfigMgr.

Prerequisites

ComSetUseDatProEven though this sounds, to me, really promising for the future of ConfigMgr, there is a small catch. That small catch is the second bullet of the prerequisites, following now:

  • Configuration Manager 2012 Service Pack 1
  • Windows 8, or Windows Server 2012
  • Configure Enable User Data and Profiles to Yes in the Compliance Settings, via either Default Client Settings or a Custom Client Device Settings (see picture).

Configure

UseDatProProWhen all the prerequisites are met, let’s start with configuring. In my configuration I tested it with configuring Folder Redirection (see picture) and Offline files. These settings will be the input for the next steps:

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > User Data and Profiles.
  • On the Home tab, in the Create group, click Create User Data and Profiles Configuration Item and the Create User Data and Profiles Configuration Item Wizard will popup.
  • On the General page, fill in with Name <aName>, select with Select user data and profiles to configure Folder Redirection and Offline files and click Next.
  • On the Folder Redirection page, select On any device, select with Folder Documents as Action Redirect to remote, select Redirect to users home folder and click Next.
  • On the Offline Files page, select Enable offline files and click Next.
    • Note: There is also a Roaming Profiles page, but that will only show when on the General page with Select user data and profiles to configure Roaming user profiles was also selected.
  • On the Summary page click Next.
  • On the Completion page click Close.

Deploy

DepUseDatProNow the configuration item is created, it can be deployed. By the deployment there is one important thing to keep in mind and that’s that by default these settings are “just” compliancy settings. So to deploy and remediate the configuration item follow the next steps:

  • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > User Data and Profiles.
  • Select the new item <aName> and on the Home tab, in the Deployment group, click Deploy and the Deploy User Data and Profiles Configuration Item popup will show.
  • On the Deploy User Data and Profiles Configuration Item popup, browse to a user collection, select Remediate noncompliant rules when supported (see picture) and click Ok.

Check

Then how does ConfigMgr handles these settings? Well, partly via Compliance Settings (during logon!) and partly via Local Policies. There are lots of log files and registry keys to look for a success of the deployed configuration item. Most of the log files are still the old “DCM” –named log files, but there is one important new log file named CcmUsrCse.log. This log files will show important information about the actions during logon:CcmUsrCse

Another good place to look is a Resultant Set of Policy (Rsop.msc). This will immediately show whether, or not the Enable User Data and Profiles –setting is done via a local policy:UseStaLocPol

The last obvious place to check, that I want to show, is the registry. The following key will show the new location of the redirected folder: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell FoldersPerRegKey

Result

Now there is only one thing left to show, the end result of the folder redirection and offline folders settings via ConfigMgr. It might be surprising, probably not, but it looks exactly the same as with group policies.

Before After
DocBefore DocAfter
Share