Windows enrollment status page

This week is all about the enrollment status page for Windows 10, version 1803 and later, devices. Yes, I know that I’m not the first to write about this subject and I won’t be the last either, but I really thought that this feature deserves and demands a place on my blog. With the recent updates to Microsoft Intune, it’s now possible to enable the enrollment status page, as a preview feature, for Windows 10, version 1803 and later devices. This feature is often mentioned in combination with Windows AutoPilot, and it’s a great addition, but it’s good to remember that it’s actually applicable to any Azure AD joined (and Intune managed) Windows device. Not just Windows AutoPilot. In this post I’ll walk through the configuration options, followed by the end-user experience related to the configuration options.

Configuration options

Let’s start by walking through the configuration options for the Windows enrollment status page. The following 5 steps walk through those configuration options, with step 4 detailing the actual configuration options and the related behavior.

1 Open the Azure portal and navigate to Intune > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 EnrollmentStatusPageOn the Enrollment Status Page (Preview) blade, select Default to open the All Users blade;
3 On the All Users blade, select Settings to open the All Users – Settings blade;
4a

Windows-enrollment-status_Config03On the All Users – Settings blade, select Yes with Show app and profile installation progress to enable the enrollment status page during OOBE;

4b Windows-enrollment-status_Config02On the All Users – Settings blade, select Yes with Block device use until all apps and profiles are installed to prevent users from using the device before it’s completely configured and to enable further configuration options for the enrollment status page during OOBE;
4c Windows-enrollment-status_Config01On the All Users – Settings blade,

  • select Yes with Allow users to reset device if installation error occurs to enable end-users to reset the device after a failure during OOBE;
  • select Yes with Allow users to use device if installation error occurs to enable end-users to use the device after a failure during OOBE;
  • configure [number] with Show error when installation takes longer than specified number of minutes to determine how long, in minutes, an installation can take before showing a failure during OOBE;
  • select Yes with Show custom message when an error occurs to enable a custom error message that will be shown to the end-user after a failure during OOBE;
  • select Yes with Allow users to collect logs about installation errors to enable end-users to collect log files of any installation failure during OOBE;
5 On the All Users – Settings blade, click Save;

Note: At this moment I haven’t been able to see my custom error message during OOBE and I haven’t found out how to collect the log files related to the installation failures as an end-user.

Configuration results

Now let’s have a look at the effect of the different configuration options. When configuring the basics, which is simply enabling the enrollment status page (steps 4a), the end-user will get the experience as shown below. It shows the end-user the current status and enables the end-user to click Continue anyway at any point during the enrollment status page.

Windows-enrollment-status_Continue

When configuring all the available options, which is basically enabling all the options (step 4b and 4c), the end-user will get the experience as shown below. It shows the en-user the current status and only provides the end-user with options after a failure. The Reset button is available because of the Allow users to reset device if installation error occurs setting and the Continue anyway link is available because of the Allow users to use device if installation error occurs setting.

Windows-enrollment-status-page_Failure

Note: Not all components are actually tracking something yet. For an up-to-date list of the different tracked components, see the more information URL.

More information

For more information about the enrollment status page, please refer to this article about Set up an enrollment status page.

App protection policies and device management state

This week is all about creating some additional awareness for the capability of assigning app protection policies and differentiating between the management state of the devices of the user. Since recently it’s possible to assign app protection policies to either Intune managed devices or unmanaged devices. This can help with differentiating between Intune managed devices and unmanaged (MAM only) devices. For example, have more strict data loss prevention configurations for MAM only devices compared to MDM managed devices. In this post I’ll show the available configuration followed by results from an administrator perspective.

Configuration

Let’s start by having a look at the available configuration options. I’ll do that by walking through the steps for creating and configuring an app protection policy. These steps are shown below, with an extra focus on the targeted app types (see step 3a and 3b). After the creation of the app protection policy, simply assign it the applicable user group.

1 Open the Azure portal and navigate to Intune > Mobile apps > App protection policies;
2 On the Mobile apps – App protection policies blade, click Add a policy to open the Add a policy blade. Depending on the platform continue with step 3a, or step 3b;
3a

MAM-iOSOn the Add a policy blade, select iOS as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices and Apps on Intune managed devices;

Note: This enables the administrator to differentiate between MAM only devices and MDM managed devices.

3b MAM-Android

On the Add a policy blade, select Android as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices, Apps on Intune managed devices and Apps in Android Work Profile;

Note: This enables the administrator to differentiate between MAM only devices, MDM managed devices and MDM managed devices with Android Enterprise.

4 On the Add a policy blade, select Apps to open the Apps blade. On the Apps blade, select one or more apps from the list to associate them with the policy and click Select;
5 On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, configure the policy settings related to data relocation (data movement in and out apps) and access (access apps in work context) and click OK;
6 On the Add a policy blade, click Create;

Note: This post is focused on iOS and Android devices, but for Windows 10 it’s also possible to differentiate between devices with enrollment and devices without enrollment.

Result

Now let’s end this post by looking at the results of the configuration. There are many things to look at, but it will be hard to show the difference in behavior via screenshots. That’s why an overview of my policies is the easiest way to show the difference in policies. Below is an overview of the different platforms and the different management types.

MAM-Policy-Overview

More information

For more information about app protection polices in combination with device management state, please refer to this article How to create and assign app protection policies – Target app protection policies based on device management state.

Conditional access and guest users

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

Configuration

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

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

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

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

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

End-user experience

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

Screenshot_MFA Screenshot_Authenticator

More information

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

Rename a device via Windows 10 MDM

This blog post uses the Accounts configuration service provider (CSP), to create a local user account on Windows 10 devices. This area was added in Windows 10, version 1803.

This weeks blog post is a follow up on last weeks post about creating a local user account via Windows 10 MDM. This week is also about the Accounts CSP, but this this time I’ll use the Accounts CSP for renaming a Windows 10 device. This can be useful with maintaining a specific naming convention. I’ll show the available nodes, I’ll show how to configure them and I’ll end this post by showing the end-user experience. Also, I’m pretty sure this will be possible via Windows AutoPilot at some point in time, but, even then, this can be useful for existing devices.

Overview

Like last week, let’s start by having a look at the tree of the Accounts CSP. That enables everybody to use this post without switching between this post and my previous post.

Available nodes

The Accounts CSP contains nodes for renaming a computer account and for the creation of a user account. To get a better understanding of the different nodes, it’s good to walk through the available nodes. Specifically those related to the device name, as those are the subject of this post. Let’s go through those related nodes.

  • .Device/Vendor/MSFT/Account – Defines the root node for the Accounts CSP;
  • Domain – Defines the interior node for the domain account information;
  • ComputerName – Defines the name of the device.

Configurable nodes

There is basically only one configurable node related to the naming of the device. The ComputerName node. The ComputerName node can be any string within the standard requirements for a device name. Besides that, it also allows a couple of macros. The table below provides an overview of them.

Macro Description
%RAND: <# of digits>%

This macro can be used to generate a random number with the specified number of digits, as part of the device name.

Example: CLDCLN%RAND:6%

%SERIAL%

This macro can be used to set the serial number of the device, as part of the device name.

Example: CLDCLN%SERIAL%

Note: The random number macro can create pretty bizarre behavior when targeted at devices (or users). It will keep on renaming the device. In that case make sure to use a Dynamic Device group filtered on disaplayName (for example filtered on Starts With DESKTOP). That will prevent constant renaming of the devices, as the devices will eventually loose the membership of the group.

Configure

Now let’s continue by having a look at the configuration to rename a device. In other words, create a device configuration profile with the previously mentioned custom OMA-URI setting. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a device 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

MSI-CN-SerialOn 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: ./Device/Vendor/MSFT/Accounts/Domain/ComputerName;
  • Data type: Select String;
  • Value: CLDCLN%SERIAL% (or use the other example of CLDCLN%RAND:6%).

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by having a quick look at the end-user experience. There is not that much to be shown, besides the actual device name. However, it’s good to see that it automatically generates a name within the restrictions of a device name. Below on the right is a screenshot of the serial number of the device and below on the left is a screenshot of the generated device name. It contains the specified prefix with the added serial number. When the serial number is too long, it will use the maximum number of characters that are allowed for a device name. It uses the characters starting from the back.

CN-Serial-Properties CN-Serial-CMD

Note: The reporting in the Azure portal still provides me with a remediation failed error message, while the actual rename of the device was a success.

More information

For more information about the Accounts CSP, refer to this article named Accounts CSP.