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:

Running scripts on Christmas day (and any other day)

My last blog post of this year will also be about a new (pre-release) feature of Configuration Manager, version 1710. This post will be all about the ability to create and run scripts from the Configuration Manager administration console. To be correct, the ability to create and run scripts was added in Configuration Manager, version 1706, and Configuration Manager, version 1710, added the ability to use parameters with those scripts. It completed the functionality.  My Christmas day present for the community is a walkthrough through this functionality and how it runs on the client device. After reading this post you should be able to understand how your script can create the output and how you can find the correct GUIDs to follow the activity on the client device.

Introduction

Starting with Configuration Manager, version 1706, it’s possible to run PowerShell scripts, via the Configuration Manager console, directly on client devices. Configuration Manager, version 1710, completed this functionality by adding the use of parameters. The ability to run PowerShell scripts on client devices is available in the Configuration Manager administration console, via the Run Scripts option. This makes it easier to automate tasks and, in general, the scripts are understood by a large population. It really simplifies building custom tools. Think about all the custom right-click actions that can now be integrated in this functionality. The biggest advantages of using the Run Script option, are the usage of the notification channel and getting good monitoring information. That means, quick results shown in the Configuration Manager administration console. In this post I’ll show the Run Script option by using a simple PowerShell script that will restart a service on the client device. That service is provided to the script via a script parameter.

Script

Now let’s have a look at the Run Script option in the Configuration Manager administration console. I’ll start by looking at a couple of important prerequisites, followed by how to create, approve and run scripts. I’ll end this section by following the script action to the client device.

Prerequisites

Before looking into the possibilities of the Run Script option, the following prerequisites should be in place to take full advantage of the available possibilities:

  • The client device must be running PowerShell version 3.0, or later;
  • The Configuration Manager clients must be running client version 1706, or later;

Create script

Let;s start by looking at the required steps to create a PowerShell script that can become available via the Run Script option. I’ll do that by using a simple script that can restart a service on a client device, based on the provided script parameter. Based on the result, of the script, a specific script output will be returned. The administrative user, creating the script, must have at least the Create permission for SMS Scripts object class.The following six steps walk through the creation of a PowerShell script (step 3 contains the used script):

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Scripts;
2 On the Home tab, in the Create group, click Create Script to open the Create Script wizard;
3

CS_ScriptOn the Script page, provide the following information and click Next;

  • Script name: Provide a name for the script;
  • Script language: Select PowerShell, as it’s currently the only option;
  • Script: Click Import to browse to a script file and to display it in the wizard. It’s also still possible to edit the imported script;

Note: Declaring variables, as shown with number 1 on the right, will enable an additional page in the wizard for configuring script parameters. The output shown with number 2, can be returned by the client device.

4a

CS_ScriptParametersOn the Script Parameters page, an overview is shown of the provided parameters with the script and it provides the option to set a Default Value. Select the variable and click Edit to adjust the parameter properties (see step 4b). After that, click Next.

Note: This page should provide an overview of the variables as declared in step 3.

4b

CS_ScriptParameterPropertiesOn the Script Parameter Properties dialog box, the information about the name, required status, hidden status and data type is prepopulated based on the declaration of the variable (see step 3). Use this dialog box to configure the following validation properties and click OK:

  • Minimum Length: Specify the minimum number of characters;
  • Maximum Length: Specify the maximum number of characters;
  • RegEx: Specify a regular expression validation;
  • Custom Error: Specify a custom error message.
5 On the Summary page, verify the configuration and click Next;
6 On the Completion page, verify the result and click Close.

Approve script

Before the just created PowerShell script becomes available via the Run Script option, it must be approved by another administrative user with at least the Approve permission for SMS Scripts object class. That will prevent unverified scripts from running on client devices, which should decrease the possibility of running faulty scripts on client devices. The following seven steps walk through the approval of a PowerShell script:

HierarchySettings_GeneralBy default it’s not possible for a script author to approve and/or deny their own scripts. To enable script authors to approve and/or deny their own scripts, open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Site. Now open the Hierarchy Settings and remove the checkbox with Do not allow script authors to approve their own scripts.

Important: It’s strongly advised to only do this in test and/or lab environments.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Scripts;
2 Select the just created script and click Approve/Deny, in the Scripts group, on the Home tab, in the Create group, to open the Approve or deny script wizard;
3

ADS_ScriptOn the Script page, verify the script and click Next;

4

ADS_ScriptParametersOn the Script Parameters page, verify the parameters and click Next;

Note: To verify the details of a parameter, select a parameter and click Details. That will show the script parameter properties, as configured during the creation of the script.

5

ADS_ApproveScriptOn the Approve or deny script page, select Approve, provide an Approver Comment (optional) and click Next;

Note: I know this is stating the obvious, but only approve scripts once you’re certain about their behavior. The ability to run scripts on client devices is just really strong and once the script is triggered it will run almost instantly.

6 On the Summary page, verify the configuration and click Next;
7 On the Completion page, verify the result and click Close.

Run script

After approving the just created PowerShell script, it becomes available via the Run Script option. The administrative user, that will run the script, must have at least the Run permission for SMS Scripts object class and the script will be executed in SYSTEM context on the client device. The following six steps walk through running a PowerShell script:

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2

Open a device collection and right-click a client device and select Run Script to open the Run Script wizard;

Note: It’s also possible to start the Run Script wizard by right-clicking a device collection.

3

RS_ScriptOn the Script page, select the just created script and click Next;

Note: The script GUID is interesting for monitoring the script execution.

4

RS_ScriptParametersOn the Script Parameters page, provide a value for the available parameters and click Next.

5 On the Summary page, verify the details and click Next;
6

RS_MonitoringOn the Monitoring page, verify the script output and click Close.

The script output, on the Summary tab, shows the output as provided in the initial script. Within this summary it’s also possible to look at the exit codes and to look at different chart forms. The Script Details tab shows the general information about the script, like the name, version and parameters and the Run Details tab shows the details about the results, like the device name, execution status, exit code and script output.

Monitor script

Now let’s end this post by looking at the monitoring options for the initiated script. This can be done in real-time, as shown in the step 6, and this can be done by looking at the Script Status node in the Monitoring workspace. Below is on overview of the just triggered script and I’ve included the following highlighted numbers:

  • Number 1 highlights the Show Status button that can be used
    to get the script details, as shown in step 6 of the Run script
    section;
  • Number 2 highlights the Client Task ID that can be used to
    follow the script through the server log files (bgbserver.log) and the client
    log files (ccmnotification.log and script.log), as shown below;
  • Number 3 highlights the Script Guid, as also shown in step
    3 of the Run script section, that can be used to follow the script
    activity in the client log files (script.log), as shown below;
  • Number 4 highlights the Script Output that can be used to
    verify the results. It should refer to the scripted output, as shown in step 3
    of the Create script section.

ConfigMgrConsole_ScriptMonitoring

Let’s continue by following the initiated script through the log files. At least the three log files below are related to this action and together those log files provide a lot of information. As there is some overlap with the log files of last week, I won’t provide the generic information about the log files this time.

BgbServer.log: When initiating a script to run on a client device, this log file shows the information about pushing the script action to the client device, followed by information about the generation of the BGB task status report (.BTS) in the bgb.box inbox (see below). The processing of the BGB task status report can be followed through the bgbmgr.log.

Script_bgbserver

CcmNotificationAgent.log: When initiating a script to run on a client device, this log file shows the arrival of the script action on the client device (see below).

Script_ccmnotification

Script.log: When initiating a script to run on a client device, this log file will show the details about the script that will be executed. That includes the earlier mentioned IDs and the command line that will be used.

Script_script

Let’s end this section by looking at the executed command line in more detail. Below is the highlighted version of the executed command line. That command line clearly shows that the script on the client device is signed, that it uses parameters and that it’s stored locally. The script is stored in C:\Windows\CCM\ScriptStore, which is a hidden folder on the client device. By default only the SYSTEM account has permissions on the script files in that folder.

Executing command line: “C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell.exe” -NoProfile -ExecutionPolicy RemoteSigned -File “C:\Windows\CCM\ScriptStore\D5FF9FBE-D25B-45DB-9771-946076A9FFAD_EB1AA60AF73737F0B342AEED2C5ECB15A9956654BDA4D30263178B3A79E79DD4.ps1” -ServiceName “Group Policy Client”

More information

For more information about the Run Script option, please refer to this article about creating and running PowerShell scripts from the Configuration Manager console.

Restarting a computer couldn’t be easier!

This week I’m still staying in the new features of Configuration Manager, version 1710. This time it’s all about how easy it became to restart a client device. Restarting a client device became a right-click action! It simply couldn’t be easier! This opens up a whole new world for managing client devices with a pending restart. In this blog post, I’ll start with a short introduction about restarting a client device, followed by the simple actions to trigger a restart for a client device. I’ll end this post by following the activity through the log files.

Introduction

Starting with Configuration Manager, version 1710, it’s possible to use the Configuration Manager console to identify client devices that require a restart, and then use a client notification action to restart those client devices. When the restart notification is received by a client device, a notification window opens to inform the user about the restart. By default, the restart occurs after 90 minutes. That might sound like a long period, but that’s related to the configuration of the Client Settings. The restart simply honors the restart behavior, as configured in the Computer Restart tab of the Client Settings.

Trigger a restart

Now let’s have a look at triggering a restart of a client device. The easiest method to trigger a restart, of a client device, is to first identify client devices that are pending a restart, followed by right-clicking those devices and selecting restart. To perform these activities, simply follow the next steps:

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices;
2

Open a device collection and add the new Pending Restart column (see below);

PendingRestart_All

3

RC_RestartRight-click a client device, with a pending restart, and select Client Notification > Restart;

Note: Of course it’s not required for a client device to have a pending restart, before the restart option becomes available. The restart option is available for every client device.

4

PendingRestart_NotificationOn the Configuration Manager dialog box, select OK to confirm the restart action for the client device.

5

SC_RestartOn the client device, a Software Center notification window opens to inform the user about the restart. This notification can not be ignored. It provides a countdown and the option to RESTART or HIDE.

Follow the restart

The best method to follow the restart, of the client device, is by using the log files. At least the following three log files are related to this action and together those log files provide a lot of information:

BgbServer.log: This log file records the activities of the notification server, such as client-server communication and pushing tasks to clients. It also records information about the generation of online and task status files to be sent to the site server. When triggering a restart of the client device, this log file shows the information about pushing the restart task to the client device, followed by information about the generation of the BGB task status report (.BTS) in the bgb.box inbox (see below).

bgbserver

CcmNotificationAgent.log: This log file records the activities of the notification agent, such as client-server communication and information about tasks received and dispatched to other client agents. When triggering a restart of the client device, this log file shows the arrival of the restart task on the client device (see below).

ccmnotificationagent

bgbmgr.log: This log file records details about site server activities related to client notification tasks and processing online and task status files. When triggering a restart of the client device, this log file will show information about processing the created BGB task status report (.BTS) from the bgb.box inbox.

bgbmgr

Note: The log snippets above show how quick the notification arrives on the client device. In my test environment that was within the same second.

More information

For more information about the restart client device option, please refer to this article about How to manage clients.

The awesome world of child task sequences

Like last week I’m staying in the world of new features of Configuration Manager, version 1710. This time it’s all about the awesome world of child task sequences. Awesome. To be a bit more specific, the awesome world of child task sequences, which refers to the newly introduced task sequence step Run Task Sequence. This opens up a whole lot of options, from using specific standards throughout all deployments until enabling different administrators from maintaining their own child task sequence. In this post I’ll go through a short introduction about the Run Task Sequence step, followed by the configuration options for the Run Task Sequence step. I’ll end this post with the end result of running a child task sequence, by showing how it’s logged.

Introduction

Starting with Configuration Manager, version 1710, it’s possible to add a new task sequence step that runs another task sequence. That is the Run Task Sequence step. This creates a parent-child relationship between the task sequences. Child task sequences are enablers for creating modular and re-usable task sequences. Before starting with using child task sequences, make sure to be familiar with the following:

  • The parent and child task sequences are combined into a single policy;
  • The task sequence environment is global;
  • The status messages are sent for a single task sequence operation;
  • The child task sequence writes entries to the same smsts.log file (like a group);

Note: Make sure to go through the information mentioned in the More information section, as the second link provides useful information about the abilities.

Configuration

Now let’s have a look at the available configuration options for using the Run Task Sequence step. The four steps below walk through those configuration options. After that, the parent task sequence can be deployed like any other task sequence. However, when deploying a parent task sequence, be aware that the criteria for showing the “high-impact” warning is not detected in Software Center when the child task sequence contains the “high-impact” steps. In that case, use the User Notification properties of the parent task sequence to force the “high-impact” warning.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Operating Systems > Task Sequences;
2 Now either create a new task sequence by using Home > Create > Create Task Sequence, or select an existing task sequence and select Home > Task Sequence > Edit to open the Task Sequence Editor;
3 In the Task Sequence Editor, select Add > General > Run Task Sequence;
4

TS_RunTaskSequenceIn the Run Task Sequence step, it’s as simple as browsing to the task sequence and selecting it.

Note: It’s not possible to select a task sequence that contains a boot image reference. The boot image reference has to be on the parent task sequence.

Note: Keep in mind that any chain containing a disabled task sequence will fail and that the Continue on error won’t work for that step containing the disabled task sequence.

Result

Let’s end this post by having a look at the end result. I’ll do that by looking at the smsts.log file and by looking at the deployment status in the Configuration Manager administrator console. When looking at the deployment status, see screenshot below, the first section shows the start of the parent task sequence and the second section shows the start of the child task sequence, like a group within a normal task sequence.

TS_StatusMessage

When looking at the smsts.log, something similar is shown, see screenshot below. The start of the child task sequence is shown like the start of a group within the parent task sequence.

TS_SMSTSLOG

More information

For more information about the Run Task Sequence step, please refer to the following articles:

Super easy customizing Software Center

This week it’s time for a short blog post about customizing Software Center. And not without reason. About two years ago I did a post about setting the company logo in the new Software Center. I received many reactions on that post about why a Microsoft Intune subscription configuration was required to set a company logo in Software Center. I had no answer. Now that time is over! Starting with Configuration Manager, version 1710, it’s super easy to customize Software Center with Client Settings. Including the company logo! In this post I’ll walk through the available configuration options and I’ll show the end-user experience. Including an additional bonus about the Software Center icons.

Configuration

Starting with Configuration Manager, version 1710, it’s super easy to add company branding elements to Software Center and it’s super easy to specify the visibility of tabs in Software Center. An administrator can now add a Software Center specific company name, set a Software Center configuration color theme, set a company logo in Software Center, and set the visible tabs in Software Center. The following three steps walk through the available easy configuration options.

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, it’s possible to configure the following settings;

  • Select these new settings to specify company information: Set to Yes to enable the Software Center customization settings;
  • Company name: Provide a valid company name;
  • Color scheme for Software Center: Select a valid color;
  • Select a logo for Software Center: Browse to the company logo;
  • Enable Applications tab: Set to Yes to enable the Application tab;
  • Enable Updates tab: Set to Yes to enable the Updates tab;
  • Enable Operating Systems tab: Set to Yes to enable the Operating Systems tab;
  • Enable Installation Status tab: Set to Yes to enable the Installation Status tab;
  • Enable Options tab: Set to Yes to enable the Options tab;

SC_ClientSettings

Note: The logo must be a JPEG or PNG of 400×100 pixels with a maximum size of 750 KB.

End-user experience

Now let’s have a look at the end-user experience. To show how the Software Center configuration relates to the actual look-and-feel, I would like to highlights the three sections as shown below.

1 The first section shows the configured Company name, the configured Color scheme and the configured Logo. This relates to the first section of the Client Settings shown above;
2 The second section shows the enabled tabs. This relates to the second section of the Client Settings shown above;
3 BONUS: The third section shows the updated Software Center icons experience. Software Center will no longer distort icons that are larger than 250×250. Administrators can now set an icon with a pixel dimensions of up to 512×512, and it displays without distortion.

SC_Custom

Auto-enroll Windows 10 devices using Group Policy

This week is all about creating awareness for the automatic MDM enrollment feature, using ‘Group Policy, that is introduced in Windows 10, version 1709. In some scenarios that might not sounds very interesting. Especially when looking at cloud only scenarios. However, this feature is very interesting in scenarios when organizations want to move to the cloud. Think about co-management. Co-management helps organizations to slowly move their device management capabilities to the cloud, by allowing multiple device management agents on a single device. Microsoft just released co-management in Microsoft Intune and co-management is also available in the latest Technical Preview releases of Configuration Manager. So, imagine a scenario in which a currently Configuration Manager managed device can receive a Group Policy setting to also auto-enroll the device in Microsoft Intune. Very helpful in the transition to the cloud.

In this post I’ll provide a short introduction to auto-enrollment for Windows 10 devices, followed by an overview of the requirements to enable auto-enrollment for Windows 10 devices. I’ll end this post with how to verify the results of a successful auto-enrollment.

Introduction

Let’s start by looking at an introduction to automatic MDM enrollment of Windows 10 devices. Well, actually more describing what will happen when configuring automatic enrollment. Automatic enrollment relies on the presence of an MDM service in Azure Active Directory and the Azure Active Directory registration of a Windows 10 device. Starting with Windows 10, version 1607, once an organization has registered its Active Directory with Azure Active Directory, a Windows 10 device that is Active Directory domain joined is automatically Azure Active Directory registered.

SchedTask_AutoMDMWhen the auto-enroll Group Policy is enabled, a scheduled task is created that initiates the MDM enrollment. That scheduled task will start deviceenroller.exe with the AutoEnrollMDM parameter, which will use the existing MDM service configuration, from the Azure Active Directory information of the user, to auto-enroll the Windows 10 device. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is completed, the scheduled task will be removed and a folder will be created with the “standard” MDM-related tasks.

Note: In Windows 10, version 1709, when the same setting is configured via Group Policy and via MDM, the Group Policy setting wins. This might change in future releases of Windows 10.

Requirements

Before starting with the configuration, let’s start by having a look at the list of requirements that must be in place to facilitate the auto-enroll configuration.

  • Active Directory is integrated with Azure Active Directory;
  • MDM service is configured in Azure Active
    Directory;
  • Device is running Windows 10, version 1709, or later;
  • Device is Active Directory joined;
  • Device is Azure Active Directory registered.

As in my posts the main focus is at the management of the devices, let’s highlight the configuration requirement of the MDM service in Azure Active Directory.

1 Open the Azure portal and navigate to Azure Active Directory > Mobility (MDM and MAM);
2 On the Mobility (MDM and MAM) blade, click Add application to add the applicable MDM app. As I’m using Microsoft Intune, the MDM app was already added and preconfigured;
3 IntuneMDMConfigSelect the MDM app, in my case Microsoft Intune, and make sure the settings are configured.

Configuration

Now let’s have a look at the main configuration of this post, the configuration of the required Group Policy setting. It’s actually quite simple, but it’s all about being aware. Simply install the latest ADMX-files for Windows 10, version 1709, or later and perform at least the following 3 steps.

1 Create a new GPO, or open an existing GPO, in the Group Policy Management Editor and navigate to Administrative Templates > Windows Components > MDM;
2

GPO_AutoMDMOpen the Auto MDM Enrollment with AAD Token setting, select Enabled and click OK;

3 Make sure the GPO is linked to the correct OU.

Result

Once the configuration of the Group Policy is done, and the policy is enabled and linked, it’s time to look at the results. The following 3 locations, are the easiest locations, on the local Windows 10 device, to look for a success of the auto-enrollment.

EventView_AutoMDMEvent Viewer – The first place to look for a success is the Event Viewer. The Event Viewer contains a specific location for device management related events. That location can be found at Microsoft > Windows > DeviceManagement-Enterprise > Diagnostics > Provider > Admin. That location should show Event ID: 75, with the message “Auto MDM Enroll: Succeeded”.
TaskSched_AutoMDMTask Scheduler – The next place to look for a success is the Task Scheduler. The Task Scheduler contains a specific location for device management tasks. That location can be found at Microsoft > Windows > EnterpriseMgmt. That location previously contained a task named “Schedule created by enrollment client for automatically enrolling in MDM from AAD Properties”. After a successful auto-enrollment, that task should be gone and a folder with a guid name should show.
Settings_AutoMDMSettings – Another place to look for a success is the Settings panel.  The Settings panel contains a location that provides information about the connected work and school environments. That location can be found via Start > Settings > Accounts > Access work or school. Without a successful auto-enrollment it simply shows a connected Active Directory domain. Once the auto-enrollment is successful, the connected Active Directory domain can be selected and the Info button can be used to see the MDM enrollment information.

Note: The Windows 10 device can also be located in the Azure Active Directory. However, I thought that providing the information above provides more insights in what’s actually happens. Besides that, a screenshot of a Windows 10 device in Azure Active Directory, is simply boring.

More information

For more information about automatically enrolling Windows 10 devices using GPO, please refer to this article of Enroll a Windows 10 device automatically using Group Policy.

MDM Migration Analysis Tool

This week something completely different compared to the last few weeks, maybe even months. This week is all about creating awareness for the MDM Migration Analysis Tool (MMAT). MMAT is created to make the transition to MDM easier. At Ignite it also got some attention and I thought it would be good to add some more attention to it. Even though it already exists for a while. I’ll start this post with an introduction to MMAT, followed by the usage of MMAT. I’ll end this post with example results of MMAT.

Introduction to MMAT

Before looking at the technical transition to MDM policies, via Microsoft Intune (hybrid or standalone), or any third-party MDM, start with MMAT. MMAT is a tool created by Microsoft to help with the technical transition from Group Policies to MDM policies. It’s mainly created to save administrators time, as there is not a one-on-one mapping available for MDM policies with Group Policies. MMAT will determine which Group Policies have been set for a targeted user/computer and cross-reference against its built-in list of supported MDM policies. MMAT will then generate both XML and HTML reports indicating the level of support for each Group Policy in terms of MDM equivalents. In a bit more detail MMAT basically works in the following three stages:

  1. In the first stage it determines which GPOs have been applied to the targeted user/computer, by using RSOP (via WMI). After that It will filter out GPOs that are marked as not enabled, or with access denied;
  2. In the second stage it uses PowerShell, for each GPO, from the first stage, to get the GPO XML from the server. It will store that information in GPOReport-{GPOGuid}.txt files, which are stored in, by default, the current directory;
  3. In the third stage it invokes MdmMigrationAnalysisTool.exe. That consumes the
    GPOReport-* files and compares them against MDMPolicyMapping.xml. At the end it generates the final XML and HTML reports.

Note: MMAT only does a best-effort analysis.

Using MMAT

Now let’s have a look at how easy it is to use MMAT. However, before doing that let’s first have a look at the prerequisites. The Remote Server Administration Tools (RSAT) must be installed on the device running MMAT. RSAT is available via the following URLs:

After installing RSAT, use the following steps to “install” and run MMAT.

1 Download MMAT as ZIP from: https://github.com/WindowsDeviceManagement/MMAT;
2 Unzip MMAT to C:\Temp (example location);
3 Open Windows PowerShell and use Run as administrator;.
4 Adjust the directory: Set-Location C:\Temp\MMAT-master;
5 Adjust the execution policy: Set-ExecutionPolicy Unrestricted -Scope Process;
6 Adjust the verbose preference: $VerbosePreference=”Continue”;
7a Run MMAT:  .\Invoke-MdmMigrationAnalysisTool.ps1 -collectGPOReports -runAnalysisTool;
7b

Additional parameters for running MMAT:

  • gpoReportOutputDirectory: Directory to store the intermediate GPOReport-*.xml;
  • analysisToolOutputDirectory: Directory to store the generated reports and logs;
  • targetUser: Name of the user to target;
  • targetComputer: Name of the computer to target;
  • targetDomain: Fully Qualified Domain Name of domain to query.

Results of MMAT

After running MMAT it’s time to have a look at the results. By default the reports and logs are stored in the same directory as MMAT. The actual readable results are available in MDMMigrationAnalysis.html. Below on the left is an example of the high-over policies listed in MDMMigrationAnalysis.html for the computer and the user. Below on the right is an example of some more details about, in this example, supported and not supported security account polices. Especially the example on the right clearly shows that these results are only an initial check to see which Group Policies can be configurable via MDM policies. Nothing more.

MMAT_Overview MMAT_Results

Note: Before interpreting the results, make sure to be fully aware of the documented caveats and warnings.

More information

For more information about MMAT, please refer to the documentation about MMAT on GitHub.

Conditional access and terms of use

This week more about conditional access. More specifically, the ability to require end-users to consent to a terms of use, which is currently still in preview and was also highlighted during a couple of sessions on Microsoft Ignite. In this post, I’ll provide more information about the terms of use requirement and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

It’s now possible to require an end-user in a tenant to consent to a terms of use before being granted access to a resource. Something like this was already possible for Microsoft Intune hybrid enrollment and Microsoft Intune standalone enrollment. However, that is Microsoft Intune only. This new requirement can be applied to any configurable Cloud app within a conditional access policy. Including Microsoft Intune enrollment. As an administrator, it’s now possible to configure and customize a terms of use by uploading a PDF document. If an end-user falls in scope of this control they will only be given access to the Cloud app if they agree, or have previously agreed, to the terms presented.

Configuration

Now let’s have a look at the configuration of a terms of use requirement in a conditional access policy. To configure a terms of use requirement in a conditional access policy. it actually requires two configurations 1) the actual terms of use and 2) the conditional access policy. The two configurations can be configured together at the same time, as shown below, or in two separate actions. To configure them together, follow the next 6 steps (of which the last 2 actually simply provide some overviews).

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Terms of use;
2 On the Conditional access – Terms of use blade, click New to open the New terms of use blade;
3 NewTouOn the New terms of use blade, provide the following information and click Create;

  • Name: Provide a name for the policy;
  • Display name: Provide a display name for the policy. This is shown to the end-user;
  • Upload document: Upload a PDF document that contains the terms of use,of the organization, for the applicable cloud apps;
  • Select Create a policy, to automatically create a conditional access policy based on the selected Policy template.
4 NewTouCA01Navigate to Azure Active Directory > Conditional access > Policies and select the just created conditional access policy. Based on the Access to cloud apps template a conditional access policy will be created as shown on the right. This policy might need some tuning as it applies to All users and All cloud apps. At least the All users assignment needs some adjustments. With the default configuration it will also be applicable to the account used by Azure AD Connect during the directory synchronization. Either change the included group, or exclude the account that is used by Azure AD Connect.

Note: This is the error that will be generated by the directory synchronization, GetADALToken: interactive authentication error [unspecified] – Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.

5 NewTouCA02The just created conditional access policy contains the ability to select created terms of use in the Grant control.

Note: Every created terms of use will be selectable in the Grant control of the conditional access policy. An additional terms of use, will be an additional line like the one shown on the right.

6 NewTouCA03Navigate back to Azure Active Directory > Conditional access > Terms of use and select the just created terms of use. That provides an overview of the terms of use, the users that accepted and declined and the ability to preview the uploaded PDF.

Note: Specifically related to Microsoft Intune enrollment, think about which configuration to use. Both, the Microsoft Intune specific configuration and the Azure AD conditional access configuration, can be applied during Microsoft Intune enrollment.

End-user experience

Like last week, let’s end this post with the end-user experience. The first time the end-user falls within the assignment of the conditional access policy, the end-user will be prompted to accept the terms of use. Below are examples of an iOS device. On the left is an iOS device using the browser and on the right is an iOS device using a mobile app.

IMG_0115 IMG_0116

More information

For more information about conditional access and requiring end-users to consent to a terms of use, please refer to this article about Controls in Azure Active Directory conditional access.