Windows 10

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

Co-management configuration

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

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

ConfigMgr client behavior

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

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

Compliance policies

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

Resource access policies

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

Windows Update policies

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

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:

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.

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.

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.

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.

More information

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

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;

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

On 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);

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 ++ 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.

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.

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.

This week is about something similar as last week. This week is all about the password reset option on the login screen. In other words, the Reset password option. Starting with Windows 10, version 1709, it’s possible to enable the Reset password option from the login screen for Azure AD joined devices. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. My style and more details. In this post I’ll provide a short introduction about Azure AD self-service password reset (SSPR), followed by walking through the required configurations for SSPR and the Reset password option. I’ll end this post by looking at the end-user experience.

Introduction

Now let’s start this post with an introduction about Azure AD SSPR. With SSPR users can reset their passwords on their own when and where they need to. At the same time, administrators can control how a user’s password gets reset. That means that the user no longer needs to call a help desk just to reset their password. SSPR includes (the focus of this post is number 2):

Self-service password change: The user knows their password but wants to change it to something new;

Self-service password reset: The user is unable to sign in and wants to reset their password by using one or more of the following validated authentication methods:

Send a text message to a validated mobile phone;

Make a phone call to a validated mobile or office phone;

Send an email to a validated secondary email account;

Answer their security questions.

Self-service account unlock: The user is unable to sign in with their password and has been locked out. The user wants to unlock their account without administrator intervention by using their authentication methods.

Configuration

Let’s continue by having a look at the required configuration, to enable the Reset password option from the login screen. As the configuration of the actual settings requires SSPR to be enabled, I divided the configuration into two steps. The first step is to enable SSPR and the second step is to configure the Reset password option.

Step 1a: Enable SSPR

The first step is to enable SSPR, as it’s the starting point for enabling the Reset password option from the login screen. Without SSPR enabled, and still configuring the Reset password option, the user will receive a message that SSPR is not enabled for the user and that the user should contact the administrator. The following seven steps walk through the relatively simple configuration to enable SSPR.

1

Open the Azure portal and navigate to Azure Active Directory > Password reset;

2

On the Password reset – Properties blade, select All and click Save;

3

On the Password reset – Authentication methods blade, select the number of required methods to reset and the available methods to user and click Save;

Note: Make sure that you have at least as many methods available to users as you have required to reset.

4

On the Password reset – Registration blade, configure whether or not to require users to register when signing in and click Save;

On the Password reset – On-premises integration blade, and configure the password write back configuration and click Save;

Note: This is required when using an on-premises directory and also requires the configuration of step 1b.

Step 1b: (Optional) Configure password writeback

Another part of the first step is the optional configuration of password writeback. This should be configured to write the passwords from Azure AD back to the on-premises directory. To achieve this, use the following seven steps to reconfigure Azure AD Connect.

On the Connect to Azure AD page, provide the required credentials and click Next;

5

On the Connect Directories page, click Next;

6

On the Domain/OU Filtering page, click Next;

7

On the Optional Features page, select Password writeback and click Next;

Note: I’ve also got Device writeback configured, which causes the next page to appear.

8

(Optional) On the Writeback page, click Next;

9

On the Configure page, click Configure and once completed click Exit;

Step 2: Enable Reset password option

The second step is to configure the required setting to enable the Reset password option 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 required setting is part of the Authentication node of the Policy CSP. It’s the AllowAadPasswordReset policy. That policy allows administrators to enable the self-service password reset feature on the windows logon screen. An integer value of 0 means not enabled and an integer value of 1 means enabled.

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

On 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);

Note: For testing purposes it’s also possible to configure the Reset password option by using the HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount registry key with the value, type and data of AllowPasswordReset, REG_DWORD and 1.

End-user experience

Now let’s end this post by walking through the end-user experience. On the login screen a new option is available when selecting password as the sign-in option, the Reset password option.

When the user selects Reset password, the user will be redirected to the Azure AD self-service password reset service.

The User ID is already prepopulated and when the user clicks on Next, the user should choose a verification method. In my case a text to my mobile phone.

When the user provides the correct mobile phone number and clicks on Next, the user must provide the actual verification code of the text message.

When the user provides the correct verification code and clicks on Next, the user must provide a new password.

When the user provides a new password and clicks Next, the user will be provided with the message that the password has been reset. When the user than clicks on Finish, the user will be redirected to the login screen.

More information

For more information about SSPR, Windows 10 and the Reset password option, please refer to the following articles:

This week I’m going for an end-user experience focused blog post. This week is all about the PIN reset option on the login screen. In other words, the I forgot my PIN option. Starting with Windows 10, version 1709, it’s now possible to enable the I forgot my PIN option from the login screen. When using Windows Hello for Business, which can be configured during the Windows enrollment, by using Microsoft Intune, the PIN is the fallback mechanism when it’s not possible to authenticate with biometrics. In other words, the PIN is really important.

In this post I’ll provide the required configuration to provide the user with the I forgot my PIN option from the login screen. I’ll do that by assuming that the user can use the Windows Hello for Business PIN recovery service to reset their PIN. I’ll end this post by looking at the end-user experience.

Configuration

Now let’s start by having a look at the required configuration to enable the I forgot my PIN option from the login screen. As the configuration of the actual settings requires the tenant ID, I divided the configuration into three steps. The first step is to find and introduce the required setting, the second step is to get the tenant ID and the third step is to use the tenant ID in the actual configuration.

Step 1: Get the required setting

The first step is to get and introduce the required setting. The PIN-related settings are part of the Windows Hello for Business settings, which can be configured by using the PassportForWork CSP. Starting with Windows 10, version 1703, that CSP contains the EnablePinRecovery node. With Windows 10, version 1703, this setting can be used to enable the I forgot my PIN option from the Settings panel and starting with Windows 10, version 1709, this setting can also be used to enable the I forgot my PIN option from the login screen.

This settings has a boolean value that enables a user to change their PIN by using the Windows Hello for Business PIN recovery service. This cloud service encrypts a recovery secret, which is stored locally on the client, and can be decrypted only by the cloud service. The default value of this setting is false. Once the administrator enables this setting, the PIN recovery secret will be stored on the device and the user can change their PIN if needed.

Step 2: Get the tenant ID

The second step is to get the tenant ID. This is super simple these days, but, as I’ve never provided the actual steps, I thought it would be smart to publish them once. To get the tenant ID, simply follow the two steps below.

1

Open the Azure portal and navigate to Azure Active Directory > Properties;

2

On the Properties blade, click Copy next to Directory ID to copy the tenant ID;

Note: Just to be clear, this should be used in the OMA-URI instead of {tenantID}.

Step 3: Configure the required setting

The third step is to configure the required setting to enable the I forgot my PIN option from the login screen. In other words, the third 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

On 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);

End-user experience

Now let’s walk through the end-user experience. On the login screen a new option is available when selecting PIN as the sign-in option, the I forgot my PIN option.

When the user selects I forgot my PIN, the user will be redirected to the login experience of the identity provider. In my case ADFS.

When the user provides a password and clicks on Sign-in, the user needs to provide an additional verification option, on an Azure AD branded page. In my case a text message.

When the user provides the additional verification and clicks on Next, the user will be provided with an additional notification to make sure that the user is aware of the impact.

When the user accept the impact of resetting the PIN and clicks Continue, the user will be provided with a dialog box to create a new PIN. Also, the user can click on PIN requirements to view the requirements for the new PIN. In my case it will show the Windows Hello for Business settings as configured in the Windows enrollment section of Microsoft Intune.

When the user provided a new PIN and clicks OK, the user will be provided with the message that it’s all set. When the user than clicks on OK, the user will be redirected to the login screen.

More information

For more information about Windows 10 and the (remote) PIN reset functionality, please refer to the following articles:

A bit more than a week ago I got the suggestion to do a blog post about the ingestion of custom and/or third-party ADMX-files. Not without a reason. The suggestion was triggered by the latest Spectre and Meltdown vulnerabilities and the ability to manage site isolation via policies for Google Chrome. That was enough motivation for me to look into it. In this post I’ll provide an introduction to ingesting ADMX-files, followed by a step-by-step overview of how to ingest custom and/or third-party ADMX-files and how to configure the related settings. As a configuration example I’ll use the manage site isolation setting for Google Chrome. I’ll end this post with showing the configuration result.

Introduction

Starting with Windows 10, version 1703, it’s possible to ingest ADMX-files and to set those ADMX-backed policies for Win32 apps and Desktop Bridge apps, by using Windows 10 MDM. The ADMX-files that define policy information, can be ingested to the device by using OMA-URI. The ingested ADMX-files are then processed into MDM policies. When the ADMX policy settings are ingested, the registry keys, to which each policy is written, are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the locations documented here.

Configuration

Now let’s have a look at the configuration. The configuration contains two important steps. The first step is to ingest the ADMX-file and the second step is to configure the required setting. I will configure both settings on the device level.

Step 1: Ingest the ADMX-file

The first step is to ingest the ADMX-file. As this post is using Google Chrome as an example, make sure to download the Chrome policies here. Before starting with ingesting this ADMX-file, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}. In this URI the following variables should be provided:

—

AppName: This should be the name of the app that will be configured, but can theoretically be anything. In this example I’ll use Chrome;

—

SettingType: This should always be policy with ingesting ADMX-files. So, in this example I’ll use Policy;

—

FileUid or AdmxFileName: This should be the name of the ADMX-file, but can theoretically be anything. In this example I’ll use ChromeADMX.

Value

The value is a lot easier. That’s simply the content of the downloaded chrome.admx, which is available in the folder policy_templates\windows\admx. So, to make this really simple, open chrome.admx in an editor and press Ctrl+A, followed by Ctrl+C.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in a Device configuration profile. To do this, simply follow the three steps below and keep in mind that the OMA-URI setting (step 3b) is nothing more than just putting together the variables as mentioned in the Setting section.

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: Windows 10 – Chrome configuration;

Description: (Optional);

Platform: Select Windows 10 and later;

Profile type: Select Custom;

Settings: See step 3b;

3b

On 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);

Step 2: Configure the required setting

The second step is to configure the required setting. Finding the correct values for configuring the required setting, is similar to finding the correct values for any other ADMX-backed policy. So, make sure to be familiar with my post about Deep dive configuring Windows 10 ADMX-backed policies. Before starting with the configuration, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/Config/{AppName}~{SettingType}~{CategoryPathFromADMX}/{SettingFromADMX}. Make sure to pay attention to the use of tildes in this URI. In this URI the following variables should be provided:

—

AppName: This should be the name of the app, as configured with the ingestion of the ADMX-file. In this example I used Chrome;

—

SettingType: This should be the same as configured with the ingestion of the ADMX-file. In this example I used Policy;

—

CategoryPathFromADMX: This should be the complete category path, which actually starts with number 3 in the picture below. That shows googlechrome as the parent category. That category should be followed until the category definition of the ADMX-file, as shown with number 1 in the picture on the right. Number 2 in that same picture, shows that there is no additional parent category;

—

SettingFromADMX: This should be the name of the setting, which is shown with number 2 in the picture on the right. That shows SitePerProcess as the actual name of the setting. Number 2 in that same picture shows the actual registry that will be configured and which we can use to verify the result.

Value

The value is again a lot easier. In this example I simply want to enable the policy, which can be done by using <enabled/>. For more complicated settings, refer to my earlier mentioned post.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in the previously created Device configuration profile. To do this, simply follow the four steps below and assign the profile to an user group. Just like with ingesting the ADMX-file, keep in mind that the OMA-URI setting (step 4) is nothing more than just putting together the variables as mentioned in the Setting section.

1

Open the Azure portal and navigate to Intune > Device configuration > Profiles;;

On 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 on the Custom OMA-URI blade and Save on the Windows 10 – Chrome configuration blade);

Result

Let’s end this post with the result of the device configuration. The easiest location to look for a success would be Google Chrome itself, but instead I would like to show that the configuration actually arrived on the device. Below on the left is a screenshot of the Settings panel (Accounts > Access work or school > {tenant} > Info). That screenshot clearly shows the custom policy of Chrome~Policy~googlechrome. The applied custom policy doesn’t get any clearer than that. Below on the right is a screenshot of the Registry Editor. That screenshot clearly show the applied configuration, which can be matched with the registry setting in the ADMX-file (see number 2 in the picture with SettingFromADMX).

This week I’m going through the required steps for configuring Windows AutoPilot. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. Also, the attentive reader might have noticed that I’m specifically using Microsoft Intune in the title of my blog, for the first time in over a year. That’s with a reason. This post is focused on configuring Windows AutoPilot via Microsoft Intune and will show that, at this moment, the Microsoft Store for Business is also required to complete the Microsoft Intune configuration.

In this post I’ll provide a short introduction about Windows AutoPilot, followed by walking through the required configurations. I’ll end this post by quickly looking at the result, from the end-user perspective and from the administrator perspective.

Introduction

Before looking at the configuration, let’s start with a short introduction about Windows AutoPilot. The Windows AutoPilot deployment program simplifies device provisioning. With Microsoft Intune and Windows AutoPilot, it’s possible to give new devices to end-users without the need to build, maintain, and apply custom operating system images to the devices. Windows AutoPilot covers the provisioning of the devices and Microsoft Intune makes it possible to manage policies, profiles, apps, etc. on the devices after they are enrolled. Once devices are registered for Windows AutoPilot, the following OOBE customization options are available for Windows 10, starting with version 1703:

Add sign-in experience with company or school brand (optional configuration);

Prevent the account used to set-up the device from getting local administrator permissions (optional configuration).

Configuration

Now let’s have a look at the required configurations to create the full Windows AutoPilot experience. That includes looking at the prerequisites, adding devices and adding a company branding. To get this full experience, simply walk through the six steps below.

Prerequisites

Before walking through the required configuration steps, make sure that the following prerequisites are in-place. Everything else will be covered in this post.

Devices have to be pre-installed with Windows 10, version 1703 or later;

Step 1: Get device information

The first step is to get the device information, as the devices must be registered to the organization. At this moment, it’s still required to acquire the device serial number, the Windows product ID and the hardware ID of the devices and to register the devices. Microsoft is actively working with various hardware vendors to enable them to provide the required information to organizations, or upload it on their behalf. To capture the required information, use the Get-WindowsAutoPilotInfo PowerShell script, by performing steps similar to the following four steps.

Run Install-Script -Name Get-WindowsAutoPilotInfo to install the PowerShell script;

4

Run Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\Windows\Temp\MyComputer.csv to get the required device information;

—

Step 2: Add devices

The second step is to add the gathered device information. This cannot be achieved by using Microsoft Intune, at this moment, but can be achieved by using the Microsoft Store for Business or by using the Partner Center. To use the Microsoft Store for Business, perform the following three steps.

On the Add devices to an AutoPilot deployment group, select No, thanks as I want to use Microsoft Intune for assigning a deployment profile.

—

Step 3: Synchronize devices

The third step is to synchronize the added device information into Microsoft Intune. That will enable me to use Microsoft Intune for assigning a deployment profile to those devices. To synchronize the devices into Microsoft Intune, perform the following three steps.

On the Windows AutoPilot devices (Preview) blade, click Sync to synchronize the devices to Microsoft Intune.

—

Step 4: Create deployment profile

The fourth steps is to create a deployment profile in Microsoft Intune. The deployment profiles are used to configure the AutoPilot devices. To create a deployment profile in Microsoft Intune, perform the following four steps.

On the Windows AutoPilot devices (Preview) blade, select the just imported device and click Assign profile to open the Assign profile blade.

4

On the Assign profile blade, select the just created deployment profile and click Assign;

—

Step 6: Add company branding

The sixth step is the finishing touch, by making the company branding appear during the OOBE. This cannot be achieved by using Microsoft Intune, at this moment, but can be achieved by using the Azure AD. To configure the company branding, perform the following steps.

1

Open the Azure portal and navigate to Azure Active Directory > Company branding;

2

On the Company branding blade, click Configure to open the Configure company branding blade;

3

On the Configure company branding blade, provide the following information and click Create.

Note: I’ve only configured a couple of items that will clearly show that the Windows AutoPilot deployment is part of my company.

Result

Now let’s end this post by looking at the result of the configurations. Let’s start by looking at the end-user experience. Yes, I can show the remaining screens during the OOBE, but I thought that was not that exciting. Instead, I’ve got the main enrollment screen that includes the company branding.

From an administrator perspective, the most interesting place, to look for the end result, is the Azure portal. When navigating Intune > Device enrollment > Windows Enrollment > Devices, the overview of devices won’t show any difference. However, the administrator can filter on Enrolled devices to get a list of devices that are successfully enrolled via the Windows AutoPilot deployment. Also, when selecting a device, it provides a list of interesting information. The most important one of that is the Enrollment State. As shown on the right, this will be set to Enrolled after the device is successfully enrolled via the Windows AutoPilot deployment.

More information

Fore more information about Windows AutoPilot, in combination with Microsoft Intune and the different configuration options, please refer to:

Let’s start the New Year with a quick tip about the Intune Management Extension, which is used for running PowerShell scripts, in combination with a 64-bit platform. The Intune Management Extension is 32-bit and will run PowerShell scripts in a 32-bit environment. This is not always the desired behavior. Actually, many activities and/or cmdlets, require a 64-bit environment. In this blog post I’ll provide a simple workaround, to run the PowerShell scripts in a 64-bit environment, and I’ll show the behavior of that simple workaround.

The (example) script

Now let’s start by looking at that simple workaround. That workaround is actually a simple addition to a script that starts the same script, by using the 64-bit environment of PowerShell. This is achieved by starting with the following assumptions:

The script doesn’t have to deal with parameters – This saves me from doing difficult with providing parameters to it;

The script should only switch on a 64-bit platform running a 32-bit process – This makes sure that it won’t break on a 32-bit platform. That can be achieved by using $ENV:PROCESSOR_ARCHITEW643. That environment variable is set when running a 32-bit process on a 64-bit platform;

The script needs the right location of PowerShell – This makes sure that this time the 64-bit environment of PowerShell will be started. That can be achieved by using SysNative. That alias is used to point a 32-bit process to C:\Windows\System32;

The script needs the right location of the script – This makes sure that the same script is started again. That can be achieved by using $PSCOMMANDPATH. That automatic variable contains the full path and file name of the script that is being run.

These four assumptions bring me to the following small script snippet that can be added to the top of any script. For looking at the results, I’ve added an additional line at the beginning and the ending of the script snippet. Those additional lines write the environment of the process to a file.

Important: The Intune Management Extension will only report over the initial script. To also report over the newly started script, you might want to look into building something smart that will monitor the newly start script before exiting the initial script. The example above simply exits the initial script.

The (example) results

Let’s end this post by looking at the example script, mentioned above, when deployed via Microsoft Intune. The example script writes, at the beginning and the ending, an entry to a file named Test.txt. After a successful execution, it contains the following three entries:

The first entry is related to the beginning of the initial script, which is triggered by the Intune Management Extension. At that moment it’s started as a 32-bit process;

The second entry is related to the beginning of the newly started version of the script, which is triggered by the initial script. At that moment it’s started as a 64-bit process;

The third entry is related to the ending of the newly started version of the script. At that moment it successfully went through the complete script as a 64-bit process.

A bit more than a week ago the Intune Management Extension was added to Microsoft Intune to facilitate the ability to run PowerShell scripts on Windows 10 devices that are managed via MDM. That addition opens a whole new world for managing Windows 10 devices via MDM. Looking at app deployment specifically, this enables the administrator to look at something like Chocolatey for deploying packages. That would make the app deployment via Microsoft Intune suddenly flexible. In this blog post I’ll start with a little introduction about the Intune Management Extension and Chocolatey, followed by the configuration of a PowerShell script to install Chocolatey packages. I’ll end this post by looking at the end result.

Introduction

Let’s start with a short introduction about the awesome Intune Management Extension. The Intune Management Extension supplements the out-of-the-box MDM capabilities of Windows 10. It will be installed automatically on Windows 10 devices, that are managed via MDM, and it simply enables administrators to run PowerShell scripts on Windows 10 devices. Those PowerShell scripts can be used to provide additional capabilities that are missing from the out-of-the-box MDM functionality. The first scenario that the Intune Management Extension enabled, for me, is super easy app deployment via Chocolatey.

Chocolatey is a global PowerShell execution engine using the NuGet packaging infrastructure. Think of it as the ultimate automation tool for Windows. Chocolatey is a package manager that can also embed/wrap native installers and has functions for downloading and check-summing resources from the Internet. Super easy for installing application packages on Windows 10 devices.

Configuration

Now let’s have a look at the configuration. The configuration contains 3 steps. The first step is to create the required PowerShell script, the second step is to upload the PowerShell script to Intune and the third step is to assign the PowerShell script to an Azure AD group.

Step 1: Create PowerShell script

The first step is to create a PowerShell script that will check for the installation of Chocolatey, and that will install Chocolatey if it’s not yet installed. Once Chocolatey is installed the PowerShell script will install the required Chocolatey packages. Now let’s walk through the PowerShell script that I’ll use to do exactly that. The first thing that the script uses, are 2 variables. The first variable $ChocoPackages contains an array with the required Chocolatey packages and the second variable, $ChocoInstall, contains the default installation directory of Chocolatey (see below).

The second thing that the PowerShell script does is verifying the existence of the installation of Chocolatey. This is done by simply testing for the existence of choco.exe by using the $ChocoInstall variable. When choco.exe is not found, the online installation of Chocolatey will be triggered (see below).

The third and last thing that the PowerShell script does is triggering the installation of the Chocolatey packages. This is done by running through the Chocolatey packages in the $ChocoPackages variable. For every package the installation will be triggered by using Chocolatey (see below).

On the Device configuration – PowerShell scripts blade, select the uploaded PowerShell script and click Assignments to open the {ScriptName} – Assignments blade;

3

On the {ScriptName} – Assignments blade, select the required Azure AD group and click Save.

Note: Keep in mind that the Intune Management Extension synchronizes to Intune once every hour.

Result

Now let’s end this post by looking at the end result. Yes, I can show the installed applications, but it’s better for understanding the process to look at some log files. From an Intune Management Extension perspective, the most interesting log file is IntuneManagementExtension.log. That log file is located at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Below is an example, in which I would like to highlight 2 sections:

The first section shows that the first time a PowerShell script arrives on a device, as a policy, the complete script is shown in the log file;

The second section clearly shows the configuration of the PowerShell script, by showing the configuration of the signature check and the context (as configured in step 2.4);

From a Chocolatey perspective, the most interesting log files are choco.log and choco.summary.log. These log files are located at C:\ProgramData\chocolatey\logs. To show the most interesting information, I would like to highlight 2 sections from the choco.summary.log below:

The first section shows the detection of a Chocolatey packages that is already installed;

The second section shows the installation of a Chocolatey package;

The nice thing about Chocolatey is that it already contains a lot of intelligence. A simple example of that is that it checks for the installation of the packages, before starting the installation. That enables me to use one script for installing the packages by simply adding new packages to the $ChocoPackages variable. When the script runs on the client, only the newly added packages will be installed.

Note: Keep in mind that you can also use Chocolatey for updating the installed packages.

More information

For more information about the Intune Management Extension and Chocolatey, please refer to the following articles:

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.

When 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

Select 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;

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.

Event 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”.

Task 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 – 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.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!