Microsoft Connected Cache in ConfigMgr with Win32 apps of Intune

This week is all about an awesome new feature that was introduced with the latest version of Configuration Manager, version 1910. That feature is that Microsoft Connected Cache now supports Win32 apps that are deployed via Microsoft Intune. Microsoft Connected Cache can be enabled on a Configuration Manager distribution point and serve content to Configuration Manager managed devices. That includes co-managed devices and now also Win32 apps, which enables a Configuration Manager distribution points to serve as a content location for Win32 apps deployed via Microsoft Intune. In this post I’ll start with a short introduction about Microsoft Connected Cache, followed with the required configuration of a Configuration Manager distribution point and the required configuration of the Configuration Manager clients. I’ll end this post by verifying the behavior on a client device.

Microsoft Connected Cache with Configuration Manager

Starting with Configuration Manager, version 1906, it’s possible to configure a Configuration Manager distribution point as a cache server that acts as an on-demand transparent cache for content downloaded by Delivery Optimization. In that version, the feature was known as Delivery Optimization In-Network Cache (DOINC). Starting with Configuration Manager, version 1910, this feature is now named Microsoft Connected Cache. Client settings can be used to make sure that the cache server is offered only to the members of the local Configuration Manager boundary group.

When clients are configured to use the Microsoft Connected Cache server, those clients will no longer request Microsoft cloud-managed content from the Internet. Those clients will request the content from the cache server installed on the Configuration Manager distribution point. The on-premises server caches the content using the IIS feature for Application Request Routing (ARR). Then the cache server can quickly respond to any future requests for the same content. If the Microsoft Connected Cache server is unavailable, or the content isn’t cached yet, clients download the content directly from the Internet.

Note: This cache is separate from the content on the Configuration Manager distribution point.

Enable distribution point as Microsoft Connected Cache server

The first step in configuring Microsoft Connected Cache in Configuration Manager for usage with Win32 apps from Microsoft Intune (or any other Microsoft cloud-managed content), is to enable a distribution point as a Microsoft Connected Cache server. However, before looking at that configuration, make sure that the on-premises distribution point meets the following configurations:

  • The server is running Windows Server 2012, or later
  • The default web site enabled on port 80
  • The IIS Application Request Routing (ARR) feature is not yet installed
  • The distribution point has Internet access to at least the Microsoft cloud

When the mentioned prerequisites are in-place, it’s time to have a look at the actual configuration steps. The following three steps walk through the process of enabling a distribution point as a Microsoft Connected Cache server.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Site Configuration Servers and Site System Roles
  2. Select {YourSiteSystemServer} select Distribution point and click Properties in the Site Role tab to open the Distribution point Properties dialog box
  3. In the Distribution point Properties dialog box, navigate to the General tab, perform the following configuration and click OK
  • Select Enable the distribution point to be used as Microsoft Connected Cache server to enable this distribution point as a Microsoft Connected Cache server and to trigger the installation
  • Select By checking this box, I acknowledge that I accept the License Terms to accept the license terms (and make sure to read them)
  • Configure with Local drive the drive that should be used to store the cache on the server
  • Configure with Disk space the maximum size of the cache on the server
  • Optionally select Retain cache when disabling the Connected Cache server to make sure that the cache will be retained on the server when the configuration is disabled

Verify the installation

After enabling the distribution point to be used as a Microsoft Connected Cache server it’s time to follow the installation process to verify a successful installation. This process can be followed in the distmgr.log, as shown below. This log keeps track of the beginning and the ending of the installation.

When looking closely on the distmgr.log, the installation is actually wrapped in a PowerShell script. That script contains all the intelligence for checking the prerequisites, making the necessary backups and starting the actual installation. That whole process of that PowerShell script is logged in DoincSetup.log. Once it completed all actions, it will be shown in the both log files.

Additional things to look at are the CacheNodeService website and the Server Farms in IIS and the DOINC folder on the selected drive. All of these created items, should be created with the same unique ID in the name. Also, in the Task Scheduler there are two tasks created for maintenance and for keeping it alive.

Enable a client to use Microsoft Connected cache

The second step in configuring Microsoft Connected Cache in Configuration Manager for usage with Win32 apps from Microsoft Intune (or any other Microsoft cloud-managed content), is to enable a client to use a Microsoft Connected Cache server as location for content download. However, before looking at that configuration, make sure that the client devices meet the following configurations:

  • The device is running Windows 10, version 1709, or later
  • The client is Configuration Manager, version 1910, or later
  • The device has 4GB, or more

When the mentioned prerequisites are in-place, it’s time to have a look at the actual configuration steps. The following three steps walk through the process of enabling a client to use a Microsoft Connected Cache server as location for content download. After creating these custom client settings, assign them to the devices like any other client settings.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration Overview Client Settings
  2. Select Create Custom Client Device Settings to open the Create Custom Client Device Settings dialog box
  3. On the General section, provide a valid name and select Delivery Optimization
  4. On the Delivery Optimization section, provide the following settings and click OK
  • Select Yes with Use Configuration Manager Boundary Groups for Delivery Optimization Group ID to make sure that the client uses this identifier to locate peers with the desired content
  • Select Yes with Enabled devices managed by Configuration Manager to use Microsoft Connected Cache servers for content download to make sure that the client can use an on-premises distribution point that is enabled as a Microsoft Connected Cache server for content download

Verify the behavior

After deploying the custom device settings to the required devices, it’s time to verify the behavior of the co-managed devices. I specifically mention co-managed devices, as I need to use Configuration Manager functionality and Microsoft Intune functionality. However, before verifying the behavior, it’s good to make sure that the following is also in-place to be able to use Win32 apps deployed by Intune on co-managed devices.

  • The co-managed device and the Microsoft Connected Cache-enabled distribution point are in the same boundary group
  • The pre-release feature Client apps for co-managed devices is enabled (often displayed as Mobile apps for co-managed devices)
  • The Client apps workload is set to Pilot Intune or Intune

When everything is available and configured, it’s time to actually look at the co-managed device. The first thing to look at is the actual configuration of Delivery Optimization on the device. Based on the custom client settings, the device will get the settings as shown below. The value DOCacheHost indicates that the distribution point is configured as Microsoft Connected Cache server, the value DODownloadMode indicates that a private group is configured and the value DOGroupId indicates the boundary group that is configured.

After verifying the settings, it’s time to look at what happens after downloading a Win32 app that’s deployed via Microsoft Intune. The easiest method to verify the required behavior is by using PowerShell. The Get-DeliveryOptimizationStatus cmdlet will provide the information to verify the behavior. The property BytesFromCacheServer indicates that the Microsoft Connected Cache server is used for the download, the property DownloadMode indicates that the correct download mode is used and the property PredefinedCallerApplication indicates that the download was an Intune app download.

More information

For more information about Microsoft Connected Cache with or without Configuration Manager, please refer to the following articles:

Expired Cloud Management Gateway server authentication certificate

Let’s start this new year with a short blog post about the Cloud Management Gateway (CMG). More specifically, about replacing an (expired) server authentication certificate on the CMG. The server authentication certificate is a required certificate for the CMG. That certificate is used to build the secure channel that is used with the created HTTPS service. The HTTPS service is were the internet-based clients connect. This certificate should come from a public provider, or from a public key infrastructure (PKI). In this post I’ll have a quick look at how to prevent the expiration of the server authentication certificate and how to replace the server authentication certificate.

Certificate expiration

The most important thing to note is – like with everything else – that prevention is better than cure. In this case: make sure that the certificate is replaced before it expires. Of course it still happens that – for whatever reason – the certificate is forgotten. In that case the Configuration Manager site will keep on working, but the clients that are managed over the Internet via the CMG, will loose their connection with the Configuration Manager site. The clients will show behavior in the CcmMessaging log that includes the messages shown below.

It includes the messages WINHTTP_CALLBACK_STATUS_SECURE_FAILURE and WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID, which both imply that something is wrong with the server certificate (see also the docs for some more details).

As mentioned, prevention is better than cure. At this moment Configuration Manager will not provide any alerts about the expiration of the CMG server authentication certificate. That doesn’t mean that there are no methods available for verifying the expiration of the certificate. When working with a solid third-party certificate provider, warnings will arrive months, weeks and days ahead of the expiration date. Ignoring those messages is nearly impossible (unless managed by a different team). When not willing to rely on a third-party, looking in the Azure portal is a very good alternative. Navigate to the cloud service of the CMG and select Certificates. That section will provide an overview of the certificates that belong to the cloud service. An example is shown below.

Of course this can also be automated by looking at PowerShell and/or the Azure Management API. That API contains the certificate URI for a resource group, which can be used for automation purposes.

Replace the certificate

The actual replacement of the (expired) CMG server authentication certificate should be pretty straight forward and can be achieved by following the next three steps.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Cloud Services Cloud Management Gateway
  2. Select {YourCMG} and click Properties in the Home tab to open the {YourCMG} Properties dialog box
  3. In the {YourCMG} Properties dialog box, navigate to the Settings tab, browse to (and select) the new certificate and click OK

Note: In my case I noticed that it wasn’t as straight forward as I thought. The deployment in Azure would fail with the message that the certificate with the new thumbprint was not found. I could address this challenge by manually uploading the certificate with the cloud service in Azure and again performing the mentioned steps. Performing those steps again will make sure that the correct actions are performed with the new certificate.

After a successful deployment of the cloud service the, earlier mentioned, Certificates section of the cloud services will show the new certificate and, in my case, show the old and expired certificate.

Also, it’s good to know that when the CMG server authentication certificate was actually expired, the clients will automatically start communicating again once the certificate is replaced.

More information

For more information about the certificates for the CMG, please refer to the documentation Certificates for the cloud management gateway.

Enabling the ConfigMgr administration service through the cloud management gateway

This week is all about the administration service in Configuration Manager. More specifically, about enabling the Configuration Manager administration service via the cloud management gateway (CMG) to make it available over the Internet. The administration service provides API interoperability access to WMI over HTTPS via the SMS Provider. This REST API can be used in place of a custom web service to access information of the Configuration Manager site. Some really good information and starting points about this subject can be found at this blog post by Adam Gross. In this post I’ll skip the basics and specifically look at making the administration service available over the Internet. I want to provide in my own style what the configuration requirements are and why they are needed. I’ll start this post by showing the required configurations in Configuration Manager and in Azure AD and I’ll end this post by retrieving the most common parameters for scripting.

Before starting with the actual configurations, I want to post a little thank you message: Thank you Sandy for answering my (dumb) questions while I should simply read better.

Configuring the SMS Provider properties

The administration service is available with the installation of the SMS Provider. Every site system with an SMS Provider has the administration service. Before being able to enable the SMS Provider over the CMG, the following prerequisites should be in-place:

  • The server that hosts the SMS Provider role requires .NET 4.5.2 or later
  • Enable the SMS Provider to use a certificate, by either using Enhanced HTTP or by manually binding a PKI-based certificate on the server that hosts the SMS Provider role
  • A running CMG (as I’m not going through that installation)

When those prerequisites are in-place, the SMS Provider can be configured to allow CMG traffic for the administration service by following the next three steps.

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Servers and Site System Roles
  2. Select the server that hosts the SMS Provider role, select the SMS Provider role and click Properties in the Site Role tab to open the Provider role properties dialog box
  3. On the Provider role properties dialog box, select Allow Configuration Manage cloud management gateway traffic for administration service and click OK

Register a new app with Azure AD

For accessing the administration service via the CMG, two apps must be created within Azure AD, 1) a Web app (also known as a Server app within Configuration Manager) that is used for making the administration service available and 2) a Native app (also known as a Client app within Configuration Manager) that is used for obtaining an access token for the user. That access token can be sent in a request to the Web app, which authorises the user and returns the administration service.

During the creation of the cloud services within Configuration Manager a Web app and a Native are already created. I need to (and can) access the administration service via that created Web app, but I don’t want to reuse the existing Native app as I need to make some adjustments and I don’t want to interfere with existing functionalities. The following steps walk through the registration and configuration of a new Native app with the required configurations to obtain and access token for the user and be able to sent that token in a request to the Web app.

  1. Open the Azure portal and navigate to Azure Active Directory  > App registrations to open the App registrations blade
  2. On the App registrations blade, click New registration to open the Register an application blade
  3. On the Register an application blade, provide the following information (as also shown below) and click Register
  • Name: Provide a valid name for the Web app (in this post: ConfigMgrAdminService)
  • Supported account types: Select Accounts in this organisational directory only ({yourTenant} only – Single tenant)
  • Redirect URI (optional): Select Public client/native (mobile & desktop) and provide https://login.microsoftonline.com/common/oauth2/nativeclient as Redirect URI

Note: The mentioned redirect URI, is the latest recommended value for desktop applications running on Windows (see also: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-app-registration).

  1. After the registration of the app, navigate to Authentication to open the Authentication blade
  2. On the Authentication blade, navigate to the Default client type section and select Yes with Required for the use of the following flows where a redirect URI is not used (as shown below) and click Save
  1. Navigate to API permissions to open the API permissions blade
  2. On the API permissions blade, click Add a permission to open the Request API permissions blade
  3. On the Request API permissions blade, select APIs my organisation uses and select the Web app – the standard name of that app is ConfigMgrService (as shown below) – that was initially created during the setup of the cloud services to open the specific API permissions blade
  1. On the specific API permissions blade, select Delegated permissions, select user_impersonation and click Add permissions (as shown below) to return to the API permissions blade
  1. On the API permissions blade, select Grant admin consent for {yourTenant} (as shown below

Retrieve the parameters to start with PowerShell

After configuring the SMS Provider properties, registering and configuring the Native app, the administration service is available via the CMG. The next step is to actually externally connect with the administration service. However, this might be an open door, but before doing that it’s good to understand that the user that is authentication and connecting with the administration service must have sufficient permissions within Configuration Manager.

At this moment I won’t provide an example, that might be something for a future post, but for now I’ll refer to this great post by Zeng Yinghua (also known as Sandy) and this repository about the Microsoft Graph (as the idea for retrieving a token is the same). The main challenge in any of those scripts is getting the token. To successfully achieve that, the following information is often required.

  1. Application (client) ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 1).
  2. Tenant ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 2).
  3. Redirect URI of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 3) or copying the information that was provided in step 3 during the registration of Native app in Azure AD.
  1. Application ID URI of the Web app that is named by default ConfigMgrService. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrService > Overview (shown in the figure below with number 4)
  1. External URL of the administration service. That information can be the easiest retrieved in SQL by using the query below on the ConfigMgr database
select ExternalEndpointName, ExternalUrl from vProxy_Routings
where ExternalEndpointName = 'AdminService'

More information

For more information about Configuration Manager administration service, please refer to the documentation about the SMS Provider.

Device compliance based on custom configuration baselines

This week is all about the new feature to include a custom configuration baselines as part of a compliance policy assessment. That’s a new feature that is introduced in Configuration Manager, version 1910. That will also make this a followup on the post I did earlier this year about using the power of ConfigMgr together with Microsoft Intune to determine device compliance. This will be added functionality, as it’s now possible to make custom configuration baselines part of the device compliancy check. For both, Configuration Manager managed devices and co-managed devices. Even when the workload is switched to Microsoft Intune.

Introduction

This option that makes it possible to use a custom device configuration baseline part of a compliancy policy, opens up a whole new world of possibilities. Especially when knowing that this can also be used when co-managing devices. This enables organisations to create a custom device configuration baseline for specific business requirements that cannot be captured by using the default functionalities that are available for Configuration Manager and Microsoft Intune.

This provides a lot of flexibility for devices that are either managed by Configuration Manager, or that are co-managed by using a combination Configuration Manager and Microsoft Intune. In the latter scenario, that even still provides that flexibility when the compliance policies workload is switched to Microsoft Intune. In that case Microsoft Intune can be configured to take the ConfigMgr compliance assessment result as part of the overall compliance status. The info gets sent to Azure AD and can be used for conditional access. In this post I’ll show how to correctly configure the device compliance policy, the configuration baseline and (optionally) the Configuration Manager compliance.

Before starting with the different configurations it’s good to keep in mind that if the compliance policy evaluates a new baseline that has never been evaluated on the client before, it may report non-compliance at first. This occurs if the baseline evaluation is still running when the compliance is evaluated.

Configure device compliance policy

The first configuration that should be in place is the device compliance policy. The device compliance policy is used to determine the compliance status of the device. Within the device compliance policy, a new rule is available that will enable the evaluation of configuration baselines as part of the compliance of the device. The following steps walk through the creation of a new device compliance policy including the required rule. The device compliance policy can be deployed like any other device compliance policy.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies
  2. Click Create Compliance Policy to open the Create Compliance Policy Wizard
  3. On the General page, provide the following information and click Next
  • Name: Provide a valid name for the compliance baseline
  • Description: (Optional) Provide a description for the compliance baseline
  • Select Compliance rules for devices managed with Configuration Manager client
  1. On the Supported Platforms page, select Windows 10 and click Next
  1. On the Rules page, perform the following actions and click Next
  • Click New to open the Add Rule dialog box
  • On the Add Rule dialog box, select Include configured baselines in compliance policy assessment and click OK
  1. On the Summary page, click Next
  2. On the Completion page, click Close

Configure configuration baseline policy

The second configuration that should be in place is the configuration baseline policy. The configuration baseline policy is used to configure, or verify, specific configuration on a device. Within a configuration a new settings is available that will make the evaluation of the configuration baseline a part of the compliance evaluation. The following steps will walk through the process of creating a new configuration baseline including the new setting. In my example I’m adding a configuration item that will verify if the local administrators comply the the organisation defaults. The configuration baseline can be deployed like any other configuration baseline.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines
  2. Click Create Configuration Baseline to open the Create Configuration Baseline dialog box
  1. On the Create Configuration Baseline dialog box, provide the following and click OK
  • Name: Provide a valid name for the configuration baseline
  • Description: (Optional) Provide a description for the configuration baseline
  • Configuration data: Select the required configuration items that should be part of this configuration baseline
  • Select Always apply the baseline even for co-managed devices
  • Select Evaluate the baseline as part of compliance policy assessment

The combination of these settings will make sure that the configuration baseline is applied to co-managed devices and that the configuration baseline will be evaluated as part of the compliance. Keep in mind that any baseline with the second option selected, that is deployed to the user, or to the user’s device, is evaluated for compliance.

(Optional) Configure Configuration Manager Compliance

An optional configuration is to configure Microsoft Intune to also look at information of Configuration Manager for determining the compliance. In my scenario that is a required configuration as I’m using it in combination with co-managed devices. Within a compliance policy a setting is available that will require compliance from Configuration Manager. The following steps walk through the configuration of that setting in a device compliance policy. Nothing more, nothing less. The device compliance policy can be assigned like any other device compliance policy.

  1. Open the Microsoft 365 Device Management portal and navigate to Devices Windows > Compliance policies to open the Windows – Compliance policies blade
  2. On the Windows – Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the compliance policy
  • Description: (Optional) Provide a description for the compliance policy
  • Platform: Select Windows 10 and later
  • Settings: See step 4 and 5
  • Actions for noncompliance: Leave default (for this post)
  • Scope (Tags): Leave default (for this post)
  1. On the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade
  2. On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade and click OK

Experience

Now let’s end this post by having a look at the end-user experience. In my scenario I’ve created a custom configuration baseline that will verify the number of local administrators on the device. When it’s above a specific number of local administrators, the device is considered not compliant as the device might be compromised. In that case the end-user will receive a message in the Company Portal app as shown below. It explains the end-user that the security settings should be updated and to look for more information in Software Center.

When looking at Software Center it actually provides exactly the same message to the end-user. It provides the end-user with the message that the security settings should be updated. For more information the end-user should contact the support department. So make sure that the requirements are clear to the end-user.

More information

For more information see the Include custom configuration baselines as part of compliance policy assessment section of the Create configuration baselines doc.

Real-time application installation for devices

This week a new blog post again! During my vacation, I’ve been looking at some statistics of my blog and I noticed that my posts about app deployment related subjects are getting a lot of traction lately. That was a trigger for to make this post about a really nice application deployment feature that’s introduced in Configuration Manager, version 1906. That feature is to install applications for a device. The really nice part of this is that it uses the client notification channel to create a real-time application installation experience. In this post I’ll quickly go through the prerequisites, followed by the application deployment configuration. I’ll end this post by looking at the application installation trigger and the corresponding application requests.

Optional feature

Let’s start with the first prerequisites that should be in place to install applications for devices. That prerequisite is to enable the optional-release feature Approve application request for users and device. That can be achieved by simply following the next 2 steps:

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features
  2. Select Approve application request for users and device and click Turn on in the Home tab

Application deployment

The second prerequisite that should be in place is that the application should be deployed as available, with administrator approval, to a device collection. That can be achieved by following the next x steps for deploying an application: .

  1. Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications
  2. Select the an app and click Deploy in the Home tab to open the Deploy Software Wizard
  3. On the General page, browse to a device collection and click Next

This can be a generic collection, as the correct configuration will not result in a policy that is sent to the client.

  1. On the Content page, verify that the content is on a distribution point and click Next
  2. On the Deployment Settings page, select Install as Action, select Available as Purpose, select An administrator must approve a request for this application on the device and click Next

This is the most important configuration that should be configured in the deployment. This configuration will make sure that the application is available for installation on a device, without it being available for installation by the user.

  1. On the Scheduling page, click Next
  2. On the User Experience page, click Next
  3. On the Alerts page, click Next
  4. On the Summary page, click Next
  5. On the Completion page, click Close

Note: This feature can help with reducing the need for separate collections for every application.

Install application for device

Before looking at the actual actions, make sure that the required permissions are in place. The (administrative) user, performing the application installation trigger, needs at least the following permissions:

  • Application: Read, Approve
  • Collection: Read, Read Resource, Modify Resource, View Collected File

Now let’s have a look at the most interesting part, the actual application installation trigger. When using an administrative user account, with the required permissions, simply open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices. The administrative user can now right-click the device and click Install Application (see Figure 3).

That will provide the administrative user with an overview of the available apps for that specific device (see Figure 4). Selecting an application and clicking OK, will trigger the application installation by using the client notification channel.

Note: The application installation trigger and process can be monitored by following the logs related to client notification and application management.

Application requests

Let’s end this post by having a look at the application requests. Every triggered application installation will resolve into an approved application request that can be found in the Configuration Manager administration console by navigating to Software Library > Overview > Application Management > Application Requests (see Figure 5). It’s registered as an application request for all users on that specific device. An administrative user can also deny this request again, as shown in the same figure below. Doing this will trigger the uninstall of the application, when an uninstall command is defined in the configuration of application.

More information

For more information about installing applications for devices, please refer to the doc Install applications for a device.

Another new discovery method: Meet the Azure Active Directory Group Discovery!

This week is back to the world of Configuration Manager. With the release of Configuration Manager, version 1906, a lot of new features are introduced. Even a few very nice pre-release features. One of these pre-release features is the subject of this post, the Azure Active Directory Group Discovery. The Azure Active Directory Group Discovery can be used to discover user groups and members of those groups from Azure AD. In case there are users found in Azure AD user groups that haven’t been previously discovered, those users will be added as user resources in Configuration Manager. A user group resource record is created when the group is a security group. In this post I’ll briefly show the prerequisites, followed by the configuration steps. I’ll end this post by showing the administrator experience.

Prerequisites

Let’s start with the prerequisites that should be in place to configure the Azure Active Directory Group Discovery. The following 2 prerequisites should be configured.

1 Enable pre-release feature: The pre-release feature must be enabled. That can be achieved by simply doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features. Select Azure Active Directory user group discovery and click Turn on in the Home tab;
CM-AADUGD-Prerelease
2 Enable cloud management: The cloud management Azure service must be added. That can be achieved by doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services. Click Configure Azure Services in the Home tab and follow the documented instructions here;

Configuration

When the prerequisites are in place it’s time to look at the actual configuration steps. The following 7 steps walk through the required configuration steps for enabling Azure Active Directory Group Discovery.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 Select the Cloud Management Azure service and click Properties in the Home tab, to open the Cloud Management Properties dialog box;
CM-AADUGD-Properties
3

CM-AADUGD-CMPropertiesOn the Cloud Management Properties dialog box, select the Discovery tab, select Enable Azure Active Directory Group Discovery and click Settings to open the Azure AD Group Discovery Settings dialog box.

Note: The Settings button will be disabled when Enable Azure Active Directory Group Discovery is not selected.

4

CM-AADUGD-AADGDSOn the Azure AD Group Discovery Settings dialog box, select the Discovery Scopes tab and click Add to open the Select Azure Active Directory Objects dialog box.

Note: Once an Azure AD group is added, it will be shown in the overview of this dialog box.

5

CM-AADUGD-SAADOOn the Select Azure Active Directory Objects dialog box, (optionally add a name in the Name starts with text box) click Search to find the specific Azure AD group(s), select the Azure AD group and click OK.

Important: The search results will show cloud only Azure AD groups for both users and devices. Also, credentials will be requested when searching for Azure AD groups for the first time.

Note: Repeat this step for all applicable Azure AD groups.

6

CM-AADUGD-CMPropertiesPSBack on the Azure AD Group Discovery Settings dialog box, select the Poling Schedule tab. Use this tab to make adjustments to the discovery schedule.

Note: At this moment delta discovery is disabled.

7 Back on the Cloud Management Properties dialog box, click OK.

Note: Keep in mind that this is currently still a preview features.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 Discovery method: One of the most interesting items is the new Azure Active Directory Group Discovery itself. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, and selecting the Azure Active Directory Group Discovery Agent Type, provides the option Run Full Discovery Now.
CM-AADUGD-Overview
2 Log file: One of the most important items is the log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery and about the full discoveries of the Azure Active Directory Group Discovery (as shown below). The nice part is that the log file also provides information about the Microsoft Graph requests that it uses for the different discoveries.
CM-AADUGD-Log
3 CM-AADUGD-GroupPropCloud-only user groups: The most useful item is the availability of the cloud-only user groups in the on-premises environment. These user groups can be recognized by only having the Agent Name of SMS_AZUREAD_USER_GROUP_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only user groups in the Configuration Manager environment, and the availability of the new attributes for existing user groups, enables a whole lot of new scenarios. Most of these scenarios are related to co-managing Windows 10 devices with Configuration Manager and Microsoft Intune.
4 Group properties: The overall most interesting, most important and most useful item is the information in the database. The main user group tables and views now contain additional fields for cloud-related information. Some nice information can be found below, were I used a simple query to get some basic information about user groups. That information shows a few important differences with normal user groups. The group contains Azure AD information.
CM-AADUGD-SQL

More information

For more information about the Azure Active Directory Group Discovery, please refer to the Configure Azure Active Directory user group discovery section in the documentation about configuring discovery methods for Configuration Manager

Quick tip: Configure primary device via Software Center

This week a relatively short blog post about a recently introduced feature in Configuration Manager, version 1902. That feature is the option for the user to select a device as a primary device, by using Software Center. Previously the Application Catalog was still required to provide users with that specific option. That was also practically the only reason to still use the Application Catalog. From that perspective, this also provides a clear path for further simplifying the Configuration Manager hierarchy. In this post I’ll show how to enable the option for the user to configure a primary device via Software Center, followed by the end-user experience.

Configuration

Now let’s have a look at the configuration that enables the option for the user to configure a device as a primary device, by using Software Center. That configuration can be achieved by using Client Settings. The 3 steps below show how to enable this option for the users.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client User Settings and select the Software Center section, or open open the Default Client Settings and select the User Device Affinity section;
3

SCPU-UserSettingsIn the User Device Affinity section, select Yes with Allow user to define their primary devices and click OK;

Note: When using the Default Client Settings this setting is available in the separate section of User Settings. When using Custom Client User Settings this setting is the only available setting. Also, when using Custom Client User Settings, make sure to deploy the Client Settings to a user collection.

Note: Theoretically, when Automatically configure user device affinity from usage data is set to No, the administrator must still approve the affinity request. However, my experience is that the primary user configuration is immediately processed.

End-user experience

Let’s end this post by having a quick look at the end-user experience. When the user now opens Software Center and navigates to the Options section, the user will find a new checkbox named I regularly use this computer to do my work. When that checkbox is selected, the user will be marked as the primary user of that specific device.

SCPU-UserExperience

More information

For more information about lettings users create their own device affinity, refer to this article about User device affinity (section Let users create their own device affinities).

Join us at Experts Live Netherlands in Den Bosch

EXPERTSLIVE.6015_email-signature_spreker_ENG_200x200A bit less than a week from now, June 6, Experts Live Netherlands will be in Den Bosch. Experts Live Netherlands is one of the biggest Microsoft community events, with over 1200 visitors. I’m proud to be part of the speaker lineup again. Together with my finest colleague, Arjan Vroege, I will deliver a session about moving to a modern managed workplace at your own pace! And we hope to see you there!

About our session

During our session we will discus (and show) how to migrate to a modern managed workplace at your own pace. As many organizations want to make the switch to a modern managed workplace, but are currently unable to make the complete switch. Often this is related to missing specific management features, like limited control over updates and missing rich app deployment features. The good news is that it’s not required to directly make the complete switch. This can be achieved in steps, by using Configuration Manager and Microsoft Intune. In this session we will present and show you how to use these tools in combination with Windows 10 to make a smooth transition.

Always apply baseline to co-managed devices

Like the last couple of weeks, this week is also about co-management. This week is all about another nice detail that can be really useful, in specific use cases. That detail is the ability to always apply a configuration baseline to co-managed devices. Even when the Device configuration workload is switched from Configuration Manager to Microsoft Intune. That can be useful for configurations that are not available yet via Microsoft Intune, or for compliance checks that need to be performed and consolidated in one location. In this post I’ll provide a short introduction about the different configuration options, followed by the steps to configure a configuration baseline to co-managed devices when the workload is switched to Microsoft Intune. I’ll end this post with the end-results.

Introduction

When looking at the evaluation of baselines, co-management provides the administrator with 3 different configuration options (of which the third options is the main subject of this post):

  1. Apply Configuration Baselines via Configuration Manager when the Device configuration workload is set to Configuration Manager:
  2. Apply Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune:
  3. Apply Configuration Baselines via Configuration Manager as an exception to Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune

Configuration

Let’s start by having a look at the configuration. I’ll do that by going through an example that will create a baseline to verify the update compliance of co-managed devices. That will provide an easy method to verify compliance and consolidate the results. Below are 4 steps that walk through the process.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Baselines;
2 On the Home tab, click Create Configuration Baseline to open the Create Configuration Baseline dialog box;
3a

AlwaysApply-Step01On the Create Configuration Baseline dialog box, provide the following information and click OK to create the configuration baseline.

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description; 
  • Configuration data: See step 3b;
  • Select Always apply this baseline even for co-managed clients;

Explanation: The check Always apply this baseline even for co-managed clients in the baseline will make sure that the baseline is always applicable to co-managed devices. Even when the Device configuration workload is set to Microsoft Intune.

3b

AlwaysApply-Step02On the Create Configuration Baseline dialog box, click Add > Software Update to open the Add Software Updates dialog box. On the Add Software Updates dialog box, find the required software update and click OK.

Explanation: This configuration will make sure that this baseline will verify the compliance of all co-managed devices for the latest cumulative update.

4

AlwaysApply-Step03Right-click the just created baseline and click Deploy to open the Deploy Configuration Baselines dialog box. Leave everything default, select the collection for this baseline deployment and click OK.

Explanation: This configuration will make sure that this baseline is deployed to the required collection and will make sure that this baseline is only used for compliance and not for remediation.

Note: The setting Always apply this baseline even for co-managed clients in the baseline, as mentioned in step 3a, can be used to make sure that the baseline is always applied on co-managed devices.

End-results

Now let’s continue by having a look at the results on a co-managed device. Below are two examples of one of a co-managed device. First an overview of the Configuration Manager Properties, followed by a look in the DCMAgent.log file. Both are client-side details, as the server-side will provide status information similar like for any other device.

1 AlwaysApply-ConfigMgrPropertiesThe first example that I would like to show, is the Configurations tab in the Configuration Manager Properties. The Configurations tab shows the deployed baseline, including the last evaluation time and the compliance state. Similar to the evaluation of a baseline when the Device configuration workload is still set to Configuration Manager;
2 The second example that I would like to show, is the DCMAgent.log file. That log file records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications. Specifically to this post, this log file provides information about the status of the Device configuration workload (first arrow below) and provides information about specifically enabled baselines (second arrow below);
AlwaysApply-DCMAgent

More information

For more information about co-managed devices and configuration baselines, please refer to this article about creating configuration baselines in System Center Configuration Manager.

Switching the Office Click-to-Run apps workload

This week is all about the Office Click-to-Run apps workload. More specifically, this week is all about what’s happening, from a Configuration Manager perspective, when switching the Office Click-to-Run apps workload to Microsoft Intune. Switching the Office Click-to-Run apps workload to Microsoft Intune will make sure that the Office Click-to-Run app will be installed via Microsoft Intune and no longer via Configuration Manager. In this post I’ll show how to switch the Office Click-to-Run apps workload to Microsoft Intune, followed by what is actually making sure that Configuration Manager will no longer install Office Click-to-Run apps. I’ll end this post with a summary.

Configuration

Let’s start with the easy part, in this case, the configuration. Assuming that co-management is already configured, the following 3 steps will walk through the process of switching the Office Click-to-Run apps workload to Microsoft Intune.

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, to open the Properties dialog box;
3

O365W-ComanangementPropertiesOn the Properties dialog box, navigate to the Workloads tab. On the Workloads tab, move the slider with Office Click-to-Run apps to Intune.

Note: When there is a need to first test this configuration with a pilot group, simply move the slider with Office Click-to-Run apps to Pilot Intune. In that case make sure to configure a Pilot collection on the Staging tab of the Properties dialog box. 

Note: This configuration change will update the configuration baseline that is used to apply the co-management configuration to Configuration Manager clients. That baseline is shown on Configuration Manager clients as CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot).

Effect of the configuration

Now let’s continue by looking at the effect of this configuration, from a Configuration Manager perspective. I’ll do that by showing the Global Condition that is used, I’ll do that by showing how that Global Condition is used and I’ll do that by showing what happens on the client device.

1 The first thing that I want to look at is the Global Condition that is used. Starting with Configuration Manager, version 1806, the Intune O365 ProPlus management condition is created as a Global Condition in Configuration Manager. That condition is used to make sure that the Configuration Manager client can no longer install the Office Click-to-Run app on co-managed devices, as the condition will be added as a requirement to the app. That is achieved by a VBScript, in the condition, that queries SELECT * FROM DeviceProperty WHERE DeviceIsO365IntuneManaged=TRUE in the root\ccm\cimodels namespace. Based on the results of the query, the VBScript will either return true or false. That return value will be used to evaluate the requirement of the app.
O365W-ConfigMgrConsole
2 O365W-AppRequirementThe second thing that I want to look at is the default configuration of the Office Click-to-Run app that is created when walking through the Microsoft Office 365 Client Installation Wizard. More specifically, the Requirements tab of the created Deployment Type. After a new Office Click-to-Run app is created, the Intune O365 ProPlus management condition is added as requirement to the Deployment Type. The value is configured to False, to make sure that the Office Click-to-Run app is not installed when the Office Click-to-Run apps workload is switched to Intune (or to Pilot Intune).
3 O365W-WbemTestThe third thing that I want to look at is the change on a co-managed device after the Office Click-to-Run apps workload is switched to Intune. Starting with Configuration Manager, version 1806, the Configuration Manager client has a new DeviceProperty named DeviceIsO365IntuneManaged in the root\ccm\cimodels namespace.Based on the configuration of the Office Click-to-Run apps workload, this property is configured to either TRUE or FALSE. That is done during the evaluation of the CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot) baseline on Configuration Manager clients.

Note: Together these 3 things will make sure that the Configuration Manager client will no longer install any deployed Office Click-to-Run apps when the Office Click-to-Run apps workload is switched.

Summary

Let’s end this post with a summary of what is happening from a Configuration Manager perspective.

  • A relatively new Global Condition, named Intune O365 ProPlus management, is available in Configuration Manager;
  • The Intune O365 ProPlus management condition is used to verify if the co-managed device should use Configuration Manager or Intune for installing the Office Click-to-Run app;
  • The Intune O365 ProPlus management condition is added by default to to Office Click-to-Run apps created through the Microsoft Office 365 Client Installation Wizard;
  • A relatively new DeviceProperty, named DeviceIsO365IntuneManaged, is available in the Configuration Manager client configuration in WMI;
  • The DeviceIsO365IntuneManaged property is used to contain the status of the co-managed device, regarding whether Configuration Manager or Intune should be used to install the Office Click-to-Run app;
  • The DeviceIsO365IntuneManaged property is configured based on the status of the Office Click-to-Run apps workload in the co-management configuration;
  • The Office Click-to-Run app is deployed via Configuration Manager and the Configuration Manager client verifies the status of the DeviceIsO365IntuneManaged property by using the Intune O365 ProPlus management condition.

More information

For more information regarding the Office Click-to-Run apps workload, please refer to this article about Co-management workloads.