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.

Great overview about the current state of the environment with Management Insights

This week I’m back in Configuration Manager again. More specifically, I’m going to look at Management Insights that is introduced with the release of Configuration Manager, version 1802.  Management Insights provides information about the current state of the environment. The information is based on analysis of data from the site database and will better understanding the state of the environment and. It also provides additional information to take action based on the insight. In this post I’ll show the different insights and were to find the information that is used for the insight.

Management Insights

Let’s go through the different insights. I’ll do that by first providing the step to get to the available insights, followed by more information per Management Insight Group Name. As the insights are all based on analyses of data from the database, the information that I provide includes the stored procedure that does the analyses. That should give an additional insight of why the information is as it is displayed. To get to the Management Insights simply follow the next step.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Management Insights > All Insights;
MI_Overview

Management Insight: Applications

The first management insight group is Applications. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Applications without deployments
Description: Lists the applications in your environment that do not have active deployments. This helps you find and delete unused applications to simplify the list of applications displayed in the console.
Stored procedure: MI_ApplicationsNotDeployed
MI_Applications

Management Insight: Cloud Services

The second management insight group is Cloud Servers. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Access co-management readiness
Description: Co-management is a solution that provides a bridge from traditional to modern management. Co-management gives you a path to make the transition using a phased approach. This rule helps you understand what steps are necessary to enable co-management.
Stored procedure: MI_EnableCoMgmt
Rule: Configure Azure services for user with Configuration Manager
Description: This rule helps you onboard Configuration Manager to Azure AD. Onboarding to cloud services creates the server web app and the native client app in Azure AD for Configuration Manager. This enables clients to authenticate with Configuration Manager site using Azure AD. When Azure services configuration is complete, the rule will turn green.
Stored procedure: MI_EnableAAD
Rule: Enable devices to be hybrid Azure Active Directory joined
Description: Modernize identity on your devices by extending your domain-joined devices to Azure Active Directory (Azure AD). Hybrid Azure AD-joined devices allow users to sign in with their domain credentials while ensuring devices meet the organization’s security and compliance standards. This rule helps identify if there are any hybrid Azure AD-joined devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_DJPlus
Rule: Update clients to the latest Windows 10 version
Description: Update Windows 10 devices to the latest version to improve and modernize the computing experience for users. This rule detects if there are any Windows 10 version 1709 or later devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_UpgradeToRS3
MI_CloudServices

Management Insight: Collections

The third management insight group is Collections. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Empty Collections
Description: List the collections in your environment that have no members. You can delete these collections to simplify the list of collections displayed when deploying objects, for example.
Stored procedure: MI_EmptyCollections
MI_Collections

Management Insight: Simplified Management

The fourth management insight group is Simplified Management. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Non-CB Client Versions
Description: This lists all clients running client versions from ConfigMgr builds before Current Branch.
Stored procedure: MI_OutdatedClientVersion
MI_SimplifiedManagement

Management Insight: Software Center

The fifth management insight group is Software Center. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Direct your users to Software Center instead of Application Catalog
Description: This rule checks if any users installed or requested applications from the Application Catalog in the last 14 days. The primary functionality of the Application Catalog is now included in Software Center. Support for the Application Catalog web site ends with the first update released after June 1, 2018. Update any end-user documentation and shortcuts to use Software Center.
Stored procedure: MI_App_AppCatalogUsage
Rule: Use the new version of Software Center
Description: Software Center has a new, modern look. The previous version of Software Center is no longer supported. Set up clients to use the new Software Center by enabling the client setting. Computer Agent > Use new Software Center.
Stored procedure: MI_App_NewSoftwareCenter
MI_SoftwareCenter

Management Insight: Windows 10

The documentation also shows a sixth management insight group, named Windows 10, that contains two rules (Configure Windows telemetry and commercial ID key and Connect Configuration Manager to Upgrade Readiness). This group and rules are not available in my environment, yet, but the stored procedures are already available (MI_TelAndCommercialId and MI_AnalyticsOnboarded).

More information

For more information about Management Insights, refer to this article named Management Insights in System Center Configuration Manager.

Default device compliance status

This week I’m going to look at the recent introduction of the feature to configure the default compliance state for devices when no compliance policies are targeted. This enables additional security for all devices, as it enables administrators to mark devices as non compliant when no compliance policies are targeted to the device. In this post I’ll start with a short introduction about this security feature, followed by a walk through the configuration. I’ll end this post by looking at the end-user experience.

Introduction

As should be known by now, compliance policies are basically rules, such as requiring a device PIN, or requiring encryption. These device compliance policies define rules and settings that a device must follow to be considered compliant. The recently introduced security feature enables administrators to determine the default compliance state of devices when no compliance policies are targeted. The default state (for new tenants) is that devices are marked as compliant. From a security perspective it can be required to switch this to non complaint, as this will make sure that all devices that have access are actually compliant with the company requirements.

Configuration

Let’s have a look at the required configuration. This configuration is actually quite simple. To make sure that the default compliance status is switched to non compliant, simply follow the next 3 steps.

1 Open the Azure portal and navigate to Intune > Device compliance to open the Device compliance blade;
2 On the Device compliance blade, click Compliance policy settings to open the Device compliance – Compliance policy settings blade;
3 DC_SettingsOn the Device compliance – Compliance policy settings blade, click Non Compliant with Mark devices with no compliance policy assigned as;

Note: Compliant means the security feature is off and Non Compliant means that the security feature on.

End-user experience

Now let’s end this post by having a look at the end-user experience on the different platforms. The first platform is Windows 10. In a co-management configuration the compliance state can be seen in the Company Portal app and Software Center. So I’ll show them both. Below on the left is an example of Software Center and below on the right is an example of the Company Portal app.

NoCompliancePolicy01 NoCompliancePolicy02

The next platforms are iOS and Android. Nothing too fancy for these platforms. Below on the left is an example of the Company Portal app (latest update) on iOS and below on the right is an example of the Company Portal app on Android.

20180411_182037518_iOS Screenshot_20180411-205045_Company Portal

More information

For more information about compliance policies and Microsoft Intune, refer to this article named Get started with device compliance policies in Intune.

Get Windows AutoPilot device information of Microsoft Intune managed devices

This week I’m going to show an example of how to collect the Windows AutoPilot device information of existing Microsoft Intune managed (Windows 10) devices. That could be useful, for example, when an organization wants one similar deployment experience for all devices. For now and in the future. In that case it can be very useful to gather the device information and upload that information. That will provide future deployments of those existing devices with the same company branded deployment experience as new devices. Also, another reason for this post is the simple fact that I’ve received this request multiple times now.

This example will use an Azure storage account that will be used to store the Windows AutoPilot device information and it will use the Get-WindowsAutoPilotInfo script to collect the information. In this post I’ll show high over the steps to create the Azure storage account, followed by an overview of the PowerShell script to collect the information and write the information to the storage account. I’ll end this post with the Microsoft Intune configuration and a quick peak at the results. After that simply collect the information and upload it via Microsoft Intune or the Microsoft Store for Business (or the Partner portal).

Create storage account

The first step is to create a storage account in Azure. The following four steps walk through the high over steps to create a storage account including a file share. That file share will be used to store the Windows AutoPilot device information.

1 Open the Azure portal and navigate to Storage accounts;
2 Add a storage account of the Storage (general purpose v1) kind and make sure that Secure transfer required is enabled (remember the storage account name);
3 Navigate to Files and add a file share (remember the file share name);
4 Navigate to Access keys and view the available keys (remember the key) ;

Note: Be aware that not every ISP allows access from port 445 to Azure (for an overview see: https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx).

Create PowerShell script

The second step is to create a PowerShell script to upload the Windows AutoPilot device information to the file share in the just created storage account.

Script variables

This PowerShell script is created for usage within Microsoft Intune. Currently the PowerShell script functionality within Microsoft Intune can’t work with input variables, which means that the values of the different variables have to be available in the script. That means that in the variables block on top of the script (see script snippet section) the following values should be adjusted.

  1. <StorageAccountKey>: This should be the access key of the created storage account (step 4);
  2. <StorageAccountName>: This should be the name of the created storage account (step 2);
  3. <ShareName>: This should be the name of the share of the created storage account (step 3).

Script actions

The PowerShell script contains a few actions that it should perform to complete the required activities. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).

  1. Create a drive with the created Azure storage account;
  2. Download the available script from PowerShell Gallery;
  3. Set the location to the location of the downloaded script;
  4. Install the downloaded script;
  5. Run the installed script and use the created drive for the output;
  6. Remove the downloaded script and the created drive.

Script snippet

The PowerShell script is shown below.

Note: Be aware that downloading PowerShell Gallery items requires PowerShellGet and that PowerShellGet requires the NuGet provider to work with the PowerShell Gallery (for more information see: https://docs.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted).

Configure PowerShell script

The third step is to configure the PowerShell script in Microsoft Intune. To upload the script, follow the next five steps. After uploading the script, simply assign the script to the required users and/or devices.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3 GWAI_AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script policy;
  • Description: (Optional) Provide a description for the PowerShell script policy;
  • Script location: Browse to the PowerShell script.

Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode).

4 GWAI_ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;

Note: Configure Run the script using the logged on credentials to No means that the PowerShell script will run in SYSTEM context;

5 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. The share in the created storage accounts will start filling with CSV-files of the different Windows 10 devices that are managed by Microsoft Intune. That means that it will start to look like something as shown below.

GWAI_AzureStorage

As the required device information is available now, within the file share of the storage account, it can be downloaded and imported via for example Microsoft Intune. Of course it’s possible to use PowerShell to merge these CSV-files into one big CSV-file. This is relatively easy by simply using something like Get-Content and always grab the second line of the CSV-files.

Import Windows AutoPilot devices in Microsoft Intune

This week I’m going to show the import experience of Windows AutoPilot devices in Microsoft Intune. About three months ago, this wasn’t possible yet and it was still required to use the Windows Store for Business (see this blog post). Even up until a few weeks ago it was still required to perform additional steps with the formatting. Now the experience is really straight forward.

I was planning on showing that experience during my session last week, at the Microsoft Tech Summit, but after speaking to many people onsite I noticed that it would be better to spent more time on explaining what Windows AutoPilot is and what Windows AutoPilot is not. Setting the expectations. An easy comparison with car and aircraft functionality helped a lot (together with some statements about what Windows AutoPilot does and what Windows AutoPilot does not do).

Now, back to the subject of this post, let’s have a look at the latest import experience by getting the device information and than importing that information in Microsoft Intune.

Get device information

To get the required device information, I’m using the latest version of the Get-WindowsAutoPilotInfo PowerShell script. That script is the easiest method to get the required information, especially for testing purposes. An alternative could be the Windows AutoPilot Device Information report in Configuration Manager, version 1802 or later. The script can create a CSV with a column for the Device Serial Number, the Windows Product ID and the Hardware Hash of the device. With the latest version of the script the value for the Windows Product ID will be skipped. Simply follow the next four steps.

1 Open Windows PowerShell as an Administrator;
2 Run Save-Script -Name Get-WindowsAutoPilotInfo -Path C:\Windows\Temp to inspect the PowerShell script;
3 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;
WA_MyComputer

Note: Keep in mind that the script can also run with a Partner switch, which will make sure that also the Manufacturer name and Device model are collected and reported.

Import device information

Now import the Windows AutoPilot device information into Microsoft Intune. The import process in Microsoft Intune can now also handle a header row in the CSV and an empty column for the Windows Product ID. This wasn’t possible until a couple of weeks ago. To import the device information, simply follow the next five steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Devices below Windows AutoPilot devices (Preview) to open the Windows AutoPilot devices (Preview) blade;
3 On the Windows AutoPilot devices (Preview) blade, click Import to open the Add Windows AutoPilot devices blade;
4 WA_AddWAdevicesOn the Add Windows AutoPilot devices blade, select the just created CSV (MyComputer.csv) and click Import to trigger the import process;

Note: Selecting the CSV will immediately trigger a check on the formatting of the CSV.

5* Back on the Windows AutoPilot devices (Preview) blade, click Sync followed by Refresh to speed up the process to show the devices in Microsoft Intune;
WA_WAdevices

*At this moment the Microsoft Intune experience might still be a bit out of sync (it’s still preview) with the Windows AutoPilot deployment service, which is why I’ve added this step to manually trigger the sync.

Join me at the Tech Summit in Amsterdam

Next week, March 28-29, the Microsoft Tech Summit will be in Amsterdam and I will be there. On Wednesday (March 28) I will be available at the Ask the Experts Reception and on Thursday (March 29) I will be speaking about Manage Windows AutoPilot via Microsoft Intune. I hope I will see you there!

pvanderwoude

About my session

In this session, I will pull you into the world of Windows AutoPilot. Learn what Windows AutoPilot is and also, learn what Windows AutoPilot is not. In this demo-rich session I will show you how to use Windows AutoPilot, together with Microsoft Intune, to simplify device provisioning.

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.

Testing conditional access policies couldn’t be easier!

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

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

Introduction

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

Available settings

Overview

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

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

CAWI_Overview

Settings

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

1

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

This is the only required selection;

2

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

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

3

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

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

4

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

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

5

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

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

6

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

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

CAWI_CompOverview

Evaluation results

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

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

CAWI_Results_PoliciesTWApply

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

CAWI_Results_PoliciesTWNotApply

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

More information

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

Manage Windows AutoPilot via Microsoft Intune

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:

  • Skip the Work or Home usage selection page (default behavior);
  • Skip Cortana, OneDrive and OEM registration setup pages (default behavior);
  • Skip privacy settings page (optional configuration);
  • Skip EULA page (optional configuration, staring with Windows 10, version 1709);
  • 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;
  • Devices must have access to the Internet;
  • Azure AD Premium subscription;
  • Automatic enrollment is enabled.

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.

1 Open Windows PowerShell as an Administrator;
2 Run Save-Script -Name Get-WindowsAutoPilotInfo -Path C:\Windows\Temp to inspect the PowerShell script ;
3 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;
WA_DeviceInformation

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.

1 Open the Microsoft Store for Business and navigate to Manage > Devices;
2 Click Add devices and browse to the just created CSV file;
3 WA_MSfB_AddOn the Add devices to an AutoPilot deployment group, select No, thanks as I want to use Microsoft Intune for assigning a deployment profile.
WA_MSfB_Devices

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.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Devices below Windows AutoPilot devices (Preview) to open the Windows AutoPilot devices (Preview) blade;
3 On the Windows AutoPilot devices (Preview) blade, click Sync to synchronize the devices to Microsoft Intune.
WA_MSIntune_Devices

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.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Deployment Profiles below Windows AutoPilot devices (Preview) to open the Windows AutoPilot deployment profiles (Preview) blade;
3 On the Windows AutoPilot deployment profiles (Preview) blade, click Create profile to open the Create profile blade;
4a

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

  • Name: Provide a valid name;
  • Description: (Optional) Provide a valid description;
  • Join to Azure AD as: Select Azure AD joined;
  • Out-of-box experience (OOBE): (See step 4b).
4b

WA_MSIntune_OOBEOn the Out-of-box experience (OOBE) blade, provide the following information and click Save;

  • Privacy Settings: Select Hide to hide the Privacy Settings page during the OOBE;
  • End user license agreement (EULA): Select Hide to hide the EULA page during the OOBE;
  • User account type: Select Standard to make the user a standard user on the device.

Note: The last setting does not apply to global administrators or company administrators. These users cannot be standard users as they have access to all administrative features in Azure AD.

WA_MSIntune_WADP

Step 5: Assign deployment profile

The fifth step is to assign the just created deployment profile to the just synchronized devices in Microsoft Intune. This can be achieved by performing the following four steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Devices below Windows AutoPilot devices (Preview) to open the Windows AutoPilot devices (Preview) blade;
3 On the Windows AutoPilot devices (Preview) blade, select the just imported device and click Assign profile to open the Assign profile blade.
4 WA_MSIntune_APOn the Assign profile blade, select the just created deployment profile and click Assign;
WA_MSIntune_APS

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

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

  • Sign-in page background image: Specify a background image that meets the specified format;
  • Banner logo: Specify a banner logo that meets the specified format;
  • User name hint: Provide a user name hint;
  • Sign-in page text: Provide a sign-in page text;
  • Sign-in page background color: Provide a background color that will be used for slow connections;
  • Square logo image: Specify a square logo image that meets the specified format;
  • Square logo image, dark theme: Specify a square logo image that meets the specified format;
  • Show option to maintain signed in: Select Yes.

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. 

WA_MSIntune_Experience

WA_MSIntune_EnrolledFrom 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: