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:

Enable Windows Automatic Redeployment from the login screen

This week a short post about enabling Windows Automatic Redeployment form the login screen. It’s a follow up on enabling password reset and PIN reset from the login screen, as it enables another feature on the login screen, and a nice addition in combination with Windows AutoPilot. Windows Automatic Redeployment might be a familiar feature, but I couldn’t find much written information about it yet. In this post I’ll provide a brief introduction to Windows Automatic Redeployment, followed by the required configuration and the end-user experience.

Introduction

Now let’s start with a brief introduction about Windows Automatic Redeployment. Starting with Windows 10, version 1709, administrators can use Windows Automatic Redeployment to quickly remove personal files, apps, and settings, by resetting Windows 10 devices from the login screen at any time. That reset will apply the original settings and device management enrollment, so the devices are ready to use once the reset is completed. The device management enrollment is related to Azure Active Directory and Microsoft Intune (or other third-party MDM-providers).

In other words, Windows Automatic Redeployment allows administrators to reset devices to a known good managed state while preserving the management enrollment. After Windows Automatic Redeployment is triggered, the devices are ready for use by standard users.

Configuration

The configuration actually only contains one specific setting. To get that specific setting, the first step explains the location of the setting and the second step explains the usage of the setting.

Step 1: Get the required setting

The first step is to get the required setting. The Policy CSP contains CredentialProvider policies. One of those policies is DisableAutomaticReDeploymentCredentials. That policy is introduced in Windows 10, version 1709, and is used to enable or disable the visibility of the credential provider that triggers the reset on a device. This policy does not actually trigger the reset. This policy enables the administrator to authenticate and trigger the reset on the device. This setting supports the following values:

  • 0 – Enable the visibility of the credentials for Windows Automatic Redeployment;
  • 1 – Disable visibility of the credentials for Windows Automatic Redeployment.

Step 2: Configure the required setting

The second step is to actually configure the required setting to enable the option to automatically redeploy Windows from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSIntune_WAROn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Vendor/MSFT/Policy/Config/CredentialProviders/DisableAutomaticReDeploymentCredentials;
  • Data type: Select Integer;
  • Value: 0.

End-user experience

Let’s end this post by looking at the end-user experience. I’ll do that by showing how to trigger Windows Automatic Redeployment, followed by a screenshot of the start of the process and a screenshot of the end of the process.

To trigger the Windows Automatic Redeployment, press the combination of Ctrl +Windows key+ R on the login screen. As shown below, this will provide the user with the option to provide an administrator account to automatically redeploy Windows.

Windows_Redeploy_01

Once administrator credentials are provided the redeployment process will be triggered. As shown below, when the process is finished a success message will be shown.

Windows_Redeploy_02

Now the device is ready to go. Keep in mind that the device is still Azure AD joined and Microsoft Intune managed with the original account. So, the main use case for this reset is for information workers and students.

More information

For more information about Windows Automatic Redeployment, please refer to this article about resetting devices with Windows Automatic Redeployment.

Conditional access and Windows 7 domain joined devices

This week is all about conditional access in combination with Windows 7 domain joined devices. I know, simple solution, migrate as fast as possible to Windows 10. Having said that, it’s not always possible to simply migrate those devices to Windows 10 and in the mean time those devices do need access to Office 365. That’s why I thought it would be good to write something about those Windows 7 domain joined devices in combination with conditional access. As Windows 7 should not be a reason to not implement conditional access. In this post I’ll provide the details about the additional configurations that need to be in place, to allow Windows 7 domain joined devices access to Office 365. So, not directly about conditional access, but about the configurations that must be in place.

Prerequisites

Before looking at the configuration, let’s start with a list of prerequisites that need to be in place. These are the general configurations that also need to be in place for Windows 10. Also, the configurations are nowadays triggered and/or mentioned during the installation of Azure AD Connect.

  • Configure service connection point – The service connection point (SCP) object is used by devices, during the registration, to discover Azure AD tenant information;
  • Setup issuance of claims – In a federated Azure AD configuration, devices rely on AD FS to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).

Configurations

Now let’s continue with the configurations specific to Windows 7, and other down-level operating systems. Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2, are considered down-level operating systems. Down-level operating systems require the following additional configurations:

  1. Configure Azure AD to enable users to register devices;
  2. Configure on-premises AD FS  to issue claims to support Integrated Windows Authentication;
  3. Add Azure AD device authentication end-point to the local Intranet zones;
  4. Install the Microsoft Workplace Join for non-Windows 10 computers package.

Configuration 1: Configure Azure AD

The first configuration, that must be in place, is that users must be enabled to register devices in Azure AD. The following 2 steps walk through that configuration. When using enrollment with Microsoft Intune, or MDM for Office 365, this configuration will be in place automatically.

1 Open the Azure portal and navigate to Azure Active Directory > Devices > Device settings to open the Device  Device settings blade;
2 On the Device – Device settings blade, select All with Users may register their devices with Azure AD and click Save;

W7_DeviceRegistration

Configuration 2: Configure on-premises AD FS

Before starting with the second configuration, it’s good to mention that it’s no longer required to have an on-premises AD FS to register domain joined computers with Azure AD. Having mentioned that, the second configuration, that must be in place, when using AD FS, is that the on-premises AD FS must support issuing the authenticationmehod and wiaormultiauthn claims when receiving an authentication request to the Office 365 relying party trust. This can be achieved by adding an issuance transform rule that passes-through the authentication method. The following 5 steps walk through that configuration by using AD FS 4.0 (Windows Server 2016).

1 Open the AD FS Management console and navigate to AD FS > Relying Party Trusts;
2 Right-click the Microsoft Office 365 Identity Platform relying party trust and select Edit Claim Issuance Policy;
3 On the Issuance Transform Rules tab, select Add Rule to open the Add Transform Claim Rule Wizard;
4 On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next;
5

W7_CustomClaimOn the Configure Claim Rule page, provide the following information and click Finish;

  • Claim rule name: Auth Method Claim Rule;
  • Claim rule: c:[Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”] => issue(claim = c);

To finish the AD FS configuration, run the following PowerShell command to allow IWA, or MFA, for the Office 365 relying party trust.

Set-AdfsRelyingPartyTrust -TargetName “Microsoft Office 365 Identity Platform” -AllowedAuthenticationClassReferences wiaormultiauthn

Configuration 3: Add end-points to local intranet zones

The third configuration, that must be in place, is that the Azure AD device authentication end-point must be added to the local intranet zones. That should avoid certificate prompts. In my case the device registration would even fail, with a clear error in the Event Viewer (Event ID: 406). That event literally provides the solution of adding the URL to the local intranet zone. The following 6 steps walk through the configuration by assuming that an existing policy is available.

1 Open the Group Policy Management console and navigate to Group Policy Management > Forest > Domains;
2 Right-click an existing GPO and select Edit;
3 In the Group Policy Management Editor, navigate to Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page;
4 Right-click Site to Zone Assignment List and select Edit;
5 In the Site to Zone Assignment List dialog box, select Enabled and click Show;
6

W7_ShowContentsIn the Show Contents dialog box, provide the following information and click OK in the open dialog boxes;

  • Value name: https://device.login.microsoftonline.com
  • Value: 1

Note: In my case I also still had to add my identity provider to the local intranet zone (which is value 1).

Configuration 4: Install Microsoft Workplace Join for non-Windows 10 computers

The fourth configuration, that must be in place, is the installation of the Microsoft Workplace Join for non-Windows 10 computers package. The installation of that package creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows and silently registers the device with Azure AD.

The following 7 steps walk through the simple creation of an application, for the Microsoft Workplace Join for non-Windows 10 computers package, in Configuration Manager. That application can then be deployed to the required devices. Before starting with the steps below, make sure to download the Microsoft Workplace join for non-Windows 10 computers package.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications;
2 Click Create Application to open the Create Application Wizard;
3 On the General page, provide the name and location of the MSI and click Next;
4 On the Import Information page, click Next;
5

W7_CAWOn the General Information page, provide at least the following information and click Next;

  • Name: Microsoft Workplace Join for Windows;
  • Installation program: msiexec /i “Workplace_x64.msi” /q
  • Install behavior: Install for system
6 On the Summary page, click Next;
7 On the Completion page, click Close;

Result

Let’s end this post by looking at the configuration results. The result should be that the Windows 7 domain joined devices are registered to Azure AD. The first place to look for a success is the Event Viewer. Open the Event Viewer and navigate to Applications and Services Logs > Microsoft-Workplace Join. As shown below, for a successful device registration this log should show Event ID 201 (Workplace join operation succeeded).

W7_EventViewer

The second place to look for a success is PowerShell. Simply use the Get-MsolDevice cmdlet. Below is an example of 1 of my devices, which clearly shows the version of the operating system and Domain Joined trust type.

W7_MsolDevice

The third place to look for a success, and last place that I’ll show, is the Azure portal. Now simply navigate to Azure Active Directory > Devices > All devices. Below is and example, in which I selected 1 of my devices, which clearly shows the version of the operating system and the Hybrid Azure AD joined join type.

W7_APDevice

Once the Windows 7 domain joined device is successfully registered with Azure AD, the device can be granted access to Office 365 by using the access control of Require domain joined (Hybrid Azure AD) in conditional access.

More information

For more information about Windows 7 and conditional access, refer to the following articles:

Testing conditional access policies couldn’t be easier!

This week is all about providing an overview of the best and easiest option for doing some initial testing of conditional access policies. The conditional access What If tool. The What If tool will help with easily  understanding what to expect from the configured conditional access policies. It provides an overview of how the different conditional access policies will impact the user(s) under various sign-in conditions. In this post I’ll provide an overview of the What If tool, followed by the available evaluation settings and the evaluation results.

Important: At this moment the What If tool is still in public preview.

Introduction

Let’s start with a short introduction about the What If tool. The What If tool allows administrators to understand the impact of the conditional access policies in the environment. Instead of testing the conditional access policies by performing multiple sign-ins manually, the What If tool enables administrators to evaluate a simulated sign-in of a user. The simulation estimates the impact that a sign-in has on the conditional access policies and generates an evaluation report. That report lists the conditional access policies that apply (and not apply) to the simulated sign-in and it shows the classic conditional access policies, if they exist.

Available settings

Overview

Now let’s continue with an overview of the What If tool. The What If tool is available in the conditional access section of the Azure portal. The following two steps walk through navigating to the What If tool, followed by an overview of the available settings.

1 Open the Azure portal and navigate to Intune > Conditional access or to Azure Active Directory > Conditional access to open the Conditional access – Policies blade;
2 On the Conditional access – Policies blade, click What If to open the What If blade;

CAWI_Overview

Settings

After looking at an overview of the What If tool, it’s time to look at the available evaluation settings. Within the What If tool the following six sections are available for testing conditional access policies.

1

CAWI_UsersWhen selecting the User section, the Users blade is opened that allows the administrator to select one or more users to mimic the Users and groups assignment of a conditional access policy.

This is the only required selection;

2

CAWI_CloudAppsWhen selecting the Cloud apps section, the Cloud apps blade is opened that allows the administrator to select one or more cloud apps to mimic the Cloud apps assignment of a conditional access policy.

This is not a required selection. When nothing is selected, the default is All cloud apps;

3

CAWI_IPThe IP address section allows the administrator to provide a single IPv4 address to mimic the Locations condition of a conditional access policy.

This is not required input. When nothing is provided, any network location is part of the network location evaluation. Also, when used, this should be the Internet facing IP address;

4

CAWI_DevicePlatformThe Device platform section allows the administrator to select one or more device platforms to mimic the Device platforms condition of a conditional access policy.

This is not a required selection. When nothing is selected, any device platform is part of the device platform evaluation;

5

CAWI_ClientAppThe Client apps section allows the administrator to select one or more client apps to mimic the Client apps condition of a conditional access policy.

This is not a required selection. When nothing is selected, any client app is part of the client app evaluation;

6

CAWI_SignInRiskThe Sign-in risk section allows the administrator to select one or more sign-in risk levels to mimic the Sign-in risk condition of a conditional access policy.

This is not a required selection. When nothing is selected, any sign-in risk level is part of the sign-in risk evaluation;

CAWI_CompOverview

Evaluation results

Let’s end this post by looking at the evaluation results of the What If tool. After making the selections, as shown above, to the settings to evaluate, and clicking the What If button, the tool What If tool generates a report of the affected conditional access policies. That report is divided into two tabs.

The first tab, which is shown below, contains the conditional access policies that apply to the selected user(s), in combination with the selected conditions. It also provides an overview of the grant controls that the user must satisfy to get access to the selected cloud apps.

CAWI_Results_PoliciesTWApply

The second tab, which is shown below, contains the conditional access policies that will not apply to the selected user(s), in combination with the selected conditions. It also provides an overview of the reasons why the conditional access policy doesn’t apply. Good to know, when there are multiple reasons for a conditional access policy to not apply, it only shows the first reason.

CAWI_Results_PoliciesTWNotApply

Note: When classic conditional access policies still exist in the environment, the orange exclamation mark is shown above the evaluation results. Even when these conditional access policies are already disabled.

More information

For more information about the What If tool, refer to this article about the Azure Active Directory conditional access what if tool – preview.