Move the content library to a remote location

This week is all about moving the content library to a remote location in Configuration Manager, version 1806. Moving the content library to a remote location is an important step in making a Configuration Manager hierarchy high available. Configuration Manager, version 1806, introduced site server high availability for a standalone primary site server role by installing an additional site server in passive mode. To complete that high available configuration it’s also smart to move the content library to a remote location. That will make sure that the content library is still available when the active site server went down. This post will provide the prerequisites for moving the content library, the steps to move the content library and the flow when moving the content library.

Prerequisites

Before actually moving the content library to a remote location, make sure that the following prerequisites are in place:

  • Create a folder on a network share that will be used as the location for the content library;
  • Provide the site server account with read and write permissions to the created folder;
  • Make sure that the site server doesn’t have the distribution point role.

Move content library

Now let’s have a look at actually moving the content library. This action is actually relatively simply and can be achieved by performing the following four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2

Select the site and click Manage Content Library on the Site section of the Home tab, to open the Manage Content Library dialog box;

Note: The option will be grayed out when the site server has the distribution point role.

3

CM_MCL-NewLocationOn the Manage Content Library dialog box, provide the just created new folder and click Move;

Note: The Current Location will be empty when the current content library is divided on multiple disks.

Important to mention is that this action actually only copies the content library to the specified remote location. It doesn’t remove the content library from the old location. That would be a manual action.

Follow the flow

Let’s end this post by following the flow through the main log files and the Configuration Manager administration console. In my opinion always the most interesting part. I would like to divide this into three sections, 1) the actual trigger of the move content library action, 2) the start of the copy content action and 3) the end of the copy content action.

The trigger

The trigger of the action to move the content library to a remote location is logged in SMSProv.log. That log file shows the execution of the SetContentLibraryLocation method of the SMS_Site class. That method can also be used for automation with PowerShell. CM-MCL-SMSProvlog

The start

CM_MCL-StatusPercentage

The actual start of the action to move the content library to a remote location is logged in distmgr.log. That log file shows the source and destination location followed by the status of the action. It also shows that it will update the information in the Configuration Manager administration console, which is also shown above. At this point the location in the console is still the current location.

CM-MCL-distmgrlog

The end

CM_MCL-StatusPercentage-done

The end of the action to move the content to a remote location is also logged in distmgr.log. That log file shows that after the content is copied, the content will also be validated and once that’s completed it will state that the action is completed. It also shows that it updated the information in the Configuration Manager administration console, which is also shown above. At this point the location in the console is the new location.

CM-MCL-distmgrlog-done

More information

More information about the content library and the flowchart for managing content, please refer to the following articles:

Software Center is getting close to awesome!

It’s almost been too long ago since I’ve done my latest post about Software Center. Luckily there are enough reasons introduced with Configuration Manager, version 1806,  to devote another blog post to Software Center, as Software Center is getting close to awesome. Yes, I deliberately say close to awesome, as we always need to leave options open for improvement. In this post I’ll focus on three great new additions to Software Center: 1) infrastructure improvements, 2) a custom tab and 3) maintenance windows.

No more application catalog website point and web service point required

Let’s start with the first and, in my opinion, best improvement related to Software Center. Starting with Configuration Manager, version 1806, available user-targeted apps can be made available in Software Center without using the application catalog website point and the application web service point. Both of these roles are no longer required. Software Center now relies on management points to get the information about available user-targeted apps. This also implies that the agent must be updated to provide the new functionality.

I’ve removed both of the mentioned roles. To completely clean up the configuration, especially from a Software Center perspective, also the Open the Application Catalog web site link must be removed (or actually be hidden) from Software Center. Otherwise it will still show a gray unneeded text. To achieve this, simply follow the next four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client Device Settings and select the Software Center section, or open open the Default Client Settings and select the Software Center section;
3 In the Software Center section, select Yes with Select these new settings to specify company information and click Customize with Software Center settings to open the Software Center Customization dialog box;
4

SC_Customization-GeneralOn the Software Center Customization dialog box, select the General tab and provide at least the following information;

  • Select Hide Application Catalog link in Software Center;

Note: In my example I’ve only selected to hide the Application Catalog link. Below is an example of the link in Software Center that will be removed. I deliberately left the link, to show that it’s not a link anymore and to show what will be removed;

SC_InstallationStatus

Custom configurable tab available for linking to a webpage

The second, also pretty good, improvement, is the ability to add a custom tab to Software Center. The administrator can define a name for the custom tab and the administrator can specify a URL that should be opened in the custom tab. It can be an internal webpage and an external webpage. The latter option would of course require an Internet connectivity. This also implies that the agent must be updated to provide the new functionality. To achieve this, simply follow the next four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client Device Settings and select the Software Center section, or open open the Default Client Settings and select the Software Center section;
3 In the Software Center section, select Yes with Select these new settings to specify company information and click Customize with Software Center settings to open the Software Center Customization dialog box;
4

SC_Customization-TabsOn the Software Center Customization dialog box, select the Tabs tab and provide at least the following information;

  • Select Specify a custom tab for Software Center;
  • Tab name: Provide a custom name;
  • Content URL: Provide a valid URL;

Note: In my example the custom tab is named Contact and it refers to the contact page of my blog. An example of the user experience is shown below.

SC_CustomTab

Next scheduled maintenance window is shown

The third improvement is a little bit smaller, but can provide really useful information to the end-user. The third improvement is the availability of the next available maintenance window within Software Center. Previously this required a little bit of custom scripting, but now the information is available within the Upcoming section of the Installation status tab in Software Center. This also implies that the agent must be updated to provide the new functionality.

SC_InstallationStatus

More information

More information about what’s new related to Software Center in the latest current branch version, please refer to this article about What’s new in version 1806 of Configuration Manager current branch – Software Center.

Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Join us at Experts Live Netherlands in Ede

A bit more than a week from now, June 19, Experts Live Netherlands will be in Ede. Experts Live Netherlands is the biggest Microsoft community event of the BeNeLux, with over a 1000 visitors. Together with my finest colleague, Arjan Vroege, I will deliver a session about your ultimate hybrid workplace. And we hope to see you there!

EL_social_tempate_speakers_Arjan

About our session

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, MSIX and Azure AD Application Proxy. Make sure that you don’t miss this!

Additional giveaway

As my employer, KPN ICT Consulting, is one of the Gold Partners of Experts Live Netherlands 2018, we also have a partner session. During that sessions my colleagues, Arjan Vroege and Nicolien Warnars, will explain how we internally migrated to a Microsoft 365 workplace for over 12.000 users. Very interesting for organizations that are looking for a great reference case.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

Conditional access and guest users

This week back in conditional access. More specifically, the recently introduced feature to assign a conditional access policy to All guest users, which is currently still in preview. At the same time also the ability to assign to Directory roles was introduced. The idea for both is the same. The first is to specifically assign to guest users and the second is to assign to specific roles in the directory. This post will focus on the first scenario. I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

Microsoft Teams is getting really hot for collaboration. This also creates a very low bar for inviting external parties (B2B) to collaborate with. Working together. Of course this should be facilitated to enable the productivity of the end-user. However, that doesn’t mean that there shouldn’t be additional security in-place. Even if it’s just to ensure the identity of the guest user. For example, enable multi-factor authentication for guest users. The following steps walk through the simple configuration to enable multi-factor authentication for guest users on Microsoft Teams.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroupOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select Select users and groups > All guest users (preview) and click Done;
4 AAD_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Microsoft Teams and click Done;
5

AAD_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select.

6 Open the New blade, select On with Enable policy and click Create;

Note: Guest user matches any user account with the userType attribute set to guest.

End-user experience

Now let’s end this post by looking at the end-user experience. Once the (external) user is invited for using Microsoft Teams, it will first have to configure MFA (see screenshot on the left). After that the user will be able to access Microsoft Teams by using its favorite MFA option. In my example I picked the Microsoft Authenticator app, as it will clearly show that an external account was used (see screenshot on the right). It clearly shows #EXT and onmicrosoft.com.

Screenshot_MFA Screenshot_Authenticator

More information

For more information about conditional access and assignments, please refer to this article about Conditions in Azure Active Directory conditional access | Users and groups.

Great overview about the current state of the environment with Management Insights

This week I’m back in Configuration Manager again. More specifically, I’m going to look at Management Insights that is introduced with the release of Configuration Manager, version 1802.  Management Insights provides information about the current state of the environment. The information is based on analysis of data from the site database and will better understanding the state of the environment and. It also provides additional information to take action based on the insight. In this post I’ll show the different insights and were to find the information that is used for the insight.

Management Insights

Let’s go through the different insights. I’ll do that by first providing the step to get to the available insights, followed by more information per Management Insight Group Name. As the insights are all based on analyses of data from the database, the information that I provide includes the stored procedure that does the analyses. That should give an additional insight of why the information is as it is displayed. To get to the Management Insights simply follow the next step.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Management Insights > All Insights;
MI_Overview

Management Insight: Applications

The first management insight group is Applications. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Applications without deployments
Description: Lists the applications in your environment that do not have active deployments. This helps you find and delete unused applications to simplify the list of applications displayed in the console.
Stored procedure: MI_ApplicationsNotDeployed
MI_Applications

Management Insight: Cloud Services

The second management insight group is Cloud Servers. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Access co-management readiness
Description: Co-management is a solution that provides a bridge from traditional to modern management. Co-management gives you a path to make the transition using a phased approach. This rule helps you understand what steps are necessary to enable co-management.
Stored procedure: MI_EnableCoMgmt
Rule: Configure Azure services for user with Configuration Manager
Description: This rule helps you onboard Configuration Manager to Azure AD. Onboarding to cloud services creates the server web app and the native client app in Azure AD for Configuration Manager. This enables clients to authenticate with Configuration Manager site using Azure AD. When Azure services configuration is complete, the rule will turn green.
Stored procedure: MI_EnableAAD
Rule: Enable devices to be hybrid Azure Active Directory joined
Description: Modernize identity on your devices by extending your domain-joined devices to Azure Active Directory (Azure AD). Hybrid Azure AD-joined devices allow users to sign in with their domain credentials while ensuring devices meet the organization’s security and compliance standards. This rule helps identify if there are any hybrid Azure AD-joined devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_DJPlus
Rule: Update clients to the latest Windows 10 version
Description: Update Windows 10 devices to the latest version to improve and modernize the computing experience for users. This rule detects if there are any Windows 10 version 1709 or later devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_UpgradeToRS3
MI_CloudServices

Management Insight: Collections

The third management insight group is Collections. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Empty Collections
Description: List the collections in your environment that have no members. You can delete these collections to simplify the list of collections displayed when deploying objects, for example.
Stored procedure: MI_EmptyCollections
MI_Collections

Management Insight: Simplified Management

The fourth management insight group is Simplified Management. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Non-CB Client Versions
Description: This lists all clients running client versions from ConfigMgr builds before Current Branch.
Stored procedure: MI_OutdatedClientVersion
MI_SimplifiedManagement

Management Insight: Software Center

The fifth management insight group is Software Center. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Direct your users to Software Center instead of Application Catalog
Description: This rule checks if any users installed or requested applications from the Application Catalog in the last 14 days. The primary functionality of the Application Catalog is now included in Software Center. Support for the Application Catalog web site ends with the first update released after June 1, 2018. Update any end-user documentation and shortcuts to use Software Center.
Stored procedure: MI_App_AppCatalogUsage
Rule: Use the new version of Software Center
Description: Software Center has a new, modern look. The previous version of Software Center is no longer supported. Set up clients to use the new Software Center by enabling the client setting. Computer Agent > Use new Software Center.
Stored procedure: MI_App_NewSoftwareCenter
MI_SoftwareCenter

Management Insight: Windows 10

The documentation also shows a sixth management insight group, named Windows 10, that contains two rules (Configure Windows telemetry and commercial ID key and Connect Configuration Manager to Upgrade Readiness). This group and rules are not available in my environment, yet, but the stored procedures are already available (MI_TelAndCommercialId and MI_AnalyticsOnboarded).

More information

For more information about Management Insights, refer to this article named Management Insights in System Center Configuration Manager.

Default device compliance status

This week I’m going to look at the recent introduction of the feature to configure the default compliance state for devices when no compliance policies are targeted. This enables additional security for all devices, as it enables administrators to mark devices as non compliant when no compliance policies are targeted to the device. In this post I’ll start with a short introduction about this security feature, followed by a walk through the configuration. I’ll end this post by looking at the end-user experience.

Introduction

As should be known by now, compliance policies are basically rules, such as requiring a device PIN, or requiring encryption. These device compliance policies define rules and settings that a device must follow to be considered compliant. The recently introduced security feature enables administrators to determine the default compliance state of devices when no compliance policies are targeted. The default state (for new tenants) is that devices are marked as compliant. From a security perspective it can be required to switch this to non complaint, as this will make sure that all devices that have access are actually compliant with the company requirements.

Configuration

Let’s have a look at the required configuration. This configuration is actually quite simple. To make sure that the default compliance status is switched to non compliant, simply follow the next 3 steps.

1 Open the Azure portal and navigate to Intune > Device compliance to open the Device compliance blade;
2 On the Device compliance blade, click Compliance policy settings to open the Device compliance – Compliance policy settings blade;
3 DC_SettingsOn the Device compliance – Compliance policy settings blade, click Non Compliant with Mark devices with no compliance policy assigned as;

Note: Compliant means the security feature is off and Non Compliant means that the security feature on.

End-user experience

Now let’s end this post by having a look at the end-user experience on the different platforms. The first platform is Windows 10. In a co-management configuration the compliance state can be seen in the Company Portal app and Software Center. So I’ll show them both. Below on the left is an example of Software Center and below on the right is an example of the Company Portal app.

NoCompliancePolicy01 NoCompliancePolicy02

The next platforms are iOS and Android. Nothing too fancy for these platforms. Below on the left is an example of the Company Portal app (latest update) on iOS and below on the right is an example of the Company Portal app on Android.

20180411_182037518_iOS Screenshot_20180411-205045_Company Portal

More information

For more information about compliance policies and Microsoft Intune, refer to this article named Get started with device compliance policies in Intune.

Co-management and the ConfigMgr client

This blog post is a follow-up on this earlier post about deploying the ConfigMgr client via Microsoft Intune. In this post I want to look more at the behavior of the ConfigMgr client in a co-management scenario. I want to show the available configurations and, more importantly, I want to show the behavior of the ConfigMgr client. I want to show the corresponding configuration and the messages in the different log files.

Co-management configuration

Now let’s start by looking at the different configuration options of co-management and the configuration values. To look at the available configuration options, simply follow the next three steps (assuming the initial co-management configuration is already created).

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management;
2 Select CoMgmtSettingsProd and click Properties in the Home tab;
3

ComanagementPropertiesNavigate to the Workloads tab, which provides the option to switch the following workloads from Configuration Manager to Intune:

  • Compliance policies;
  • Resource access policies (this contains VPN, Wi-Fi, email and certificate profiles);
  • Windows Update policies.

Note: Looking at the current Technical Preview version, the number of available workloads will quickly increase.

ConfigMgr client behavior

Now let’s make it a bit more interesting and look at the behavior of the ConfigMgr client. By that I mean the configuration changes of the ConfigMgr client that can be noticed in the log files. The co-management configuration related log file is the CoManagementHandler.log (as shown below). That log file shows the processing of the configuration and the MDM information related to the device.

Log_ComanagementHandler

The values in the CoManagementHandler.log are shown, after a configuration change, in both hex and decimal. These values relate to the following workload distribution.

Value Configuration Manager Microsoft Intune
1 (0x1) Compliance policies, Resource access policies, Windows update policies
3 (0x3) Resource access policies, Windows Update policies Compliance policies
5 (0x5) Compliance policies, Windows Update policies Resource access policies
7 (0x7) Windows Update policies Compliance policies, Resource access policies
17 (0x11) Compliance policies, Resource access policies Windows Update policies
19 (0x13) Resource access policies Compliance policies, Windows Update policies
21 (0x15) Compliance policies Resource access policies, Windows Update policies
23 (0x17) Compliance policies, Resource access policies, Windows Update policies

Compliance policies

When co-management is enabled, the ConfigMgr client will verify if it should apply compliance policies. Before applying them. That information is shown in the ComplRelayAgent.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the compliance policies. After that it will perform an action on the policy. In this case it won’t report a compliance state.

Log_ComplRelayAgent

Resource access policies

When co-management is enabled, the ConfigMgr client will also verify if it should apply resource acces policies. Before applying them. That information is shown in the CIAgent.log (as shown below). As that log file is used for a lot more operations, it might be a bit challenging to find the information. It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the resource access policies. After that it will perform an action on the policy. In this case it will skip the related CI.

Log_CIAgent

Windows Update policies

When co-management is enabled, the ConfigMgr client will also verify if it should apply Windows Update for Business policies. Before applying them. That information is shown in the WUAHandler.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the Windows Update for Business policies. After that it will perform an action on the policy. In this case it will look for assigned policies.

Log_WuaHandler

Deploying the ConfigMgr client via Microsoft Intune

This week is all about deploying the ConfigMgr client via Microsoft Intune. Like last week, this is also a nice addition in combination with Windows AutoPilot. The idea is to install the ConfigMgr client next to the MDM agent and to create a co-management scenario. The main use case to do something like this is when an organization is making the transition from traditional management to modern management. In that scenario the organization can use co-management to make a phased move to the cloud. For example, use ConfigMgr for patch management and use Microsoft Intune for configurations and compliance. In this post I’ll provide a short introduction to co-management, followed by the prerequisites for the ConfigMgr client installation and the end result.

Introduction

Starting with Configuration Manager, version 1710, co-management enables organizations to concurrently manage Windows 10, version 1709, devices by using both Configuration Manager and Microsoft Intune. There are two main paths to reach to co-management:

  1. Configuration Manager provisioned co-management where Windows 10 devices managed by Configuration Manager and hybrid Azure AD joined get enrolled into Microsoft Intune;
  2. Microsoft Intune provisioned devices that are enrolled in Microsoft Intune and then installed the Configuration Manager client to reach a co-management state (focus of this post).

I can continue with a long story about co-management and the capabilities that it provides, or how co-management is the bridge between traditional management and modern management, but the following picture shows close to all of that.

CoManagement

Note: Picture is coming from this co-management overview article.

Prerequisites

Now let’s start by having a look at the prerequisites that must be in place to enable the second path to co-management, which is deploying the ConfigMgr client to Microsoft Intune enrolled devices. The following technical prerequisites must be in place:

  • MDM authority set to Microsoft Intune;
  • Device is Azure AD joined;
  • Windows 10, version 1709 or later;
  • Configuration Manager, version 1710 or later;
    • Cloud Management Gateway (CMG);
    • Cloud Distribution Point (CDP);
    • Co-management enabled;
    • Management Point (MP) set to HTTPS;
    • Synchronization of Azure AD users enabled;

Configuration

Let’s continue by having a look a the configuration. I’ve divided the configuration in three steps. The first step is to get the required command line, the second step is to explain the command line (and add some additional parameters) and the third step is to actually deploy the ConfigMgr client.

Step 1: Get the command line

The first step is to get the required command line. The following three steps walk through the easiest method to get the required command line.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management;
2 Select CoMgmgtSettigsProd and click Properties in the Home tab, to open the Properties;
3 CMClient_PropertiesOn the Enablement tab, click Copy to copy the command line. On dialog box click OK;

Step 2: Explain the parameters

The second step is to look at the command line and to explain the parameters that are used. The following parameters are used in the command line.

  • /mp: The download source, which can be set to CMG, to bootstrap from internet;
  • CCMHOSTNAME: The name of the Internet management point, which can be set to CMG;
  • SMSSiteCode: The site code of the Configuration Manager site;
  • SMSMP: The name of the lookup management point (can be on the intranet);
  • AADTENANTID: The ID of the connected Azure AD tenant;
  • AADCLIENTAPPID: The ID of the client app in Azure AD;
  • AADRESOURCEURI: The URI of the server app in Azure AD;
  • SMSPublicRootKey: Specifies the Configuration Manager trusted root key.

Note: As I’m using certificates from my internal PKI-environment, and I’ve not published my CRL on the Internet, I also needed to use the following parameters.

  • /nocrlcheck: The client should not check the certificate revocation list;
  • CCMHTTPSSTATE: Specify 31 to prevent certificate revocation list check.

Step 3: Deploy the ConfigMgr client

The third step is to actually deploy the ConfigMgr client via Microsoft Intune. Simply follow the next three steps and assign the created app to a group.

1 Open the Azure portal and navigate to Intune > Mobile apps > Apps;
2 On the Mobile apps – Apps blade, click Add to open the Add app blade;
3a

On the Add app blade, provide the following information and click Add;

  • App type: Select Line-of-business app;
  • App package file: See step 3b;
  • App information: See step 3c;
3b

CMClient_APFOn the App package file blade, select ccmsetup.msi and click OK.;

Note: ccmsetup.msi is available at %ProgramFiles%\Microsoft Configuration Manager\bin\i386 on the primary site server.

3c

CMClient_AIOn the App information blade, provide the following information and click OK;

  • Name: Provide the name of the app. It should be prepopulated based on the MSI;
  • Description: Provide the description of the app;
  • Publisher: Provide the publisher of the app;
  • Category: (Optional) Select a category for the app;
  • Select No with Display this as a featured app in the Company Portal;
  • Information URL: (Optional) Provide the information URL of the app;
  • Privacy URL: (Optional) Provide the privacy URL of the app;
  • Command-line arguments: Provide the command from the co-management settings (step 1);
  • Developer: (Optional) Provide the developer of the app;
  • Owner: (Optional) Provide the owner of the app;
  • Notes: (Optional) Provide the notes of the app;
  • Logo: (Optional) Select a logo of the app.

Note: As I’m using certificates from my internal PKI-environment, I also needed to deploy the root certificate of my environment to the Trusted Root Certification Authorities store of the devices. That could be easily achieved by using a Device configuration profile and using the Trusted certificate profile type option.

Result

Now let’s end this post by looking at the end result. The first place to look, after the ConfigMgr client installation, is Microsoft Intune. Below is an overview of my Azure AD joined devices that are managed by MDM and ConfigMgr. By looking at the compliance state, it’s clear that my workload for compliance policies is set to Intune.

CMClient_Intune

The second place to look, after the ConfigMgr client installation, is the Configuration Manager console. Below is an overview of the same devices from a ConfigMgr perspective. By looking at the device online information, it’s clear that those devices are connecting over the Internet via CMG.

CMClient_ConfigMgr

More information

For more information about deploying the ConfigMgr client via Microsoft Intune, please refer to the following articles.

For more information about the installation of the prerequisites (CMG, CDP, Co-management) there are some nice step-by-step guides available, see
for example: