Require an Internet connection during device setup

This week I’m going to look at a well hidden configuration option that is recently introduced and can be really useful in specific scenarios. That configuration option is to require an Internet connection during the device setup. Requiring an Internet connection during device setup can be useful when trying to prevent users from resetting the device (either accidently or on purpose) and configuring it without an Internet connection, as configuring a device without Internet connectivity would enable a user to configure the device with a local user and without enrollment. In this blog post, I’ll start with a short introduction about why this configuration option would be useful and what the options are with this configuration option. Followed by the configuration steps and the end-user experience.

Introduction

Configuring a device without Internet connectivity would enable a user to configure the device with a local user and without an enrollment to Microsoft Intune (and Azure AD). That’s often what organizations want to prevent, as it disconnects a device from the organization. Minor detail, this configuration option must be configured once. Of course it would be great if this configuration option could be a Windows default, or available via the Windows Autopilot configuration. However, to my understanding this is currently not possible due to legal requirements. At this moment it’s simply legally not allowed to require an Internet connection on a device during the initial setup. Having said that, as this setting is configured via the TenantLockdown CSP, I can imagine that, in a Windows Autopilot for existing devices scenario, this can be configured as a Windows default, via PowerShell, by using the WMI Bridge Provider.

Configuration

Before looking at the configuration, let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device must be configured once before the setting is applicable;

Now let’s continue by looking at the required configuration. The following four steps walk through the steps to get create a new device configuration profile and the specific configuration option. That device configuration profile can be assigned to an Azure AD group.

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

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Device restrictions;
  • Settings: See 3b;
3b On the Device restrictions blade, select General to open the General blade. On the General blade, select Require with Require users to connect to network during device setup and click OK to return to the Device restrictions blade. On the Device restrictions blade, click OK;
OOBE-Configure-Network

Note: This setting must be configured before it’s applicable. In other words, it’s not applicable during the initial out-of-box experience.

End-user experience

Let’s end this post by looking at the end-user experience. Once the configuration is in place and a reset is performed on the device, there will be an additional check during the device setup. When the device is not connected to the Internet, the end-user will receive a message as shown below. It requires the user to connect to the Internet. The user will not be able to continue without that connection. Once the user is connected to the Internet, the page below will show a Next button that can be used to continue with the device setup.

OOBE-Connect-Network

More information

For more information regarding the device configuration options and the TenantLockdown CSP, please refer to the following articles:

Windows Autopilot self-deploying mode

This week a new blog post about Windows Autopilot. More specifically, Windows Autopilot self-deploying mode. Autopilot self-deploying mode is really useful for devices that are function specific, like for example kiosk devices. The biggest benefit is that a device with a wired network connection (with Internet) can be completely configured without any user interaction. Simply connect the device to the wired network and power it on! Real zero touch provisioning! In this post I’ll provide the configuration steps to create that experience, followed by some known errors and the end-user experience.

Configuration

Let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device can only be Azure AD joined (Active Directory join is not supported);
  • The device must be a physical device with TPM 2.0 (virtual machine is not supported);

Now let’s continue by looking at the available configuration options. In this case I’ll look at the different available configurations options and the related impact of those configuration options. The following four steps walk through the steps to get create a new Windows Autopilot self-deploying profile (including the available settings). That deployment profile can be assigned to an Azure AD group that contains devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a

WA-SD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select Self-Deploying (preview), as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Azure AD joined is selected by default and grayed-out, as it’s the only configuration option supported for Windows Autopilot self-deploying devices;
  • Out-of-box experience (OOBE): See 4b.

Note: The Self-Deploying (preview) deployment mode, defines the available Azure AD settings and the available out-of-box experience (OOBE) settings.

4b

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

  • Language (Region): Select the Language that should be automatically configured during the Windows Autopilot self-deploying experience. This configuration will only be performed when the device is on a wired network connection (with Internet);
  • Automatically configure keyboard: Select Yes to automatically configure the keyboard based on the selected Language. This setting is only available when a Language is configured and this configuration will only be performed when the device is on a wired network connection (with Internet);
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot self-deploying experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot self-deploying experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot self-deploying experience;
  • User account type: Select Standard to only make any user on the device a standard user. With the exception of global administrators and company administrators;
  • Apply computer name template (Windows Insider Only): Create a computer name, according to the configured template, for devices at initial startup;
WA-SD-OOBE

Note: The Autopilot settings can only be downloaded when a network connection is in place. That’s the reason why a wired network connection should be in place. When a wired network connection is not available, it’s required to configure the region, the keyboard and a Wi-Fi.

Known errors

During the testing of Windows Autopilot self-deploying, I ran into multiple errors. More information about an error can always be found in the Event Viewer, at Application and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider > AutoPilot (thank you for the reminder Sandy!). The errors that I’ve seen on screen are documented and explained in the table below. If you’ve seen errors that are not on this list, let me know and I’ll add them.


Error Description
0x800705B4 This error means that the device is either a virtual machine, or does not have TPM 2.0, and is not capable of running Autopilot self-deploying.
0x801c03ea This error means that the device is TPM 2.0 capable, but that the TPM still needs to be upgraded from 1.2 to 2.0.
0xc1036501 This error means that the device cannot do an automatic MDM enrollment, because there are multiple MDM configurations in Azure AD.

End-user experience

As always, let’s end this post by having a look at the end-user experience. The end-user experience will provide a welcome message (see below) after receiving the Autopilot deployment profile and an automatic restart. An easy differentiation between the Autopilot user-driven experience and the Autopilot self-deploying experience, besides the interaction, is the logo that’s used. At this moment the Autopilot user-driven experience uses the square logo of the Azure AD company branding and the Autopilot self-deploying experience uses the banner logo of the Azure AD company branding.

20181104_165048

Note: From and administrator perspective, an Autopilot self-deploying device can be easily recognized by the Management name of the device. It contains a GUID instead of a username.

More information

For more information about enrolling Windows devices by using Windows Autopilot self-deploying mode, please refer to the documentation named Windows Autopilot Self-Deploying mode.

Automagically convert Intune managed devices to AutoPilot

Tweet-AutoPilotThis week a short blog post about my tweet of a bit more than a week ago. In that tweet I mentioned a new easy method to automagically convert Intune managed devices to AutoPilot. That method makes some scenarios a whole lot easier. Like for example what I did in this post to get the AutoPilot device information of Intune managed devices. That type of custom scripting is not needed anymore!

As I got many reactions to that tweet, mainly related to the location of that configuration, I thought it would be good to make a short post describing the configuration option and the expected behavior. In this post I’ll provide the steps to make this configuration and I’ll describe the expected behavior. There is no real end-user or administrator experience to show for this configuration. So, no section related to that. I’ll do explain the the expected behavior in the introduction.

Introduction

Let’s start with a short introduction about the mentioned configuration option. That configuration option is the Convert all targeted devices to AutoPilot setting. By default an AutoPilot deployment profile is only applied to already existing AutoPilot devices and doesn’t apply to non-AutoPilot devices. Configuring the Convert all targeted devices to AutoPilot setting to Yes will automagically convert all devices in the assigned group to AutoPilot. This is a one-time conversion that also works for co-managed devices. That also means that removing the AutoPilot profile will not remove the converted devices from AutoPilot. After conversion the devices can only be removed by using the Windows AutoPilot devices view. Keep in mind that it can take up to 48 hours for the conversion to be completed.

Configuration

Now let’s continue by having a look at the actual configuration. And in this case only the specific Convert all targeted devices to AutoPilot setting. The following four steps walk through the steps to get to the specific setting and are not meant to create a complete the Windows AutoPilot deployment profiles.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows AutoPilot Deployment Program section to open the Windows AutoPilot deployment profiles blade;
3 On Windows AutoPilot deployment profiles blade, either select Create profile or select [existing deployment profile] > Properties to open the Create profile blade or the [existing deployment profile] – Properties  blade;
4 On the Create profile blade or the [existing deployment profile] – Properties  blade, the setting Convert all targeted devices to AutoPilot must be switched to Yes (below is an example of the the [existing deployment profile] – Properties  blade, the Create profile blade looks similar) ;
MSIS-AutoPilot-Target

Note: There’s not a real easy method to see which devices are converted to AutoPilot. Those devices will show as any other imported device, without enrollment state. However, as the configuration is done via an AutoPilot deployment profile, the device is immediately assigned to a profile. Again, without creating any fancy configurations, like query based dynamic device groups.

More information

For more information about enrolling Windows devices by using Windows AutoPilot, please refer to the documentation named Enroll Windows devices by using the Windows Autopilot.

Join us at Experts Live Europe in Prague

b-B6v-rUA bit less than two weeks from now, October 25-26, Experts Live Europe will be in Prague. Together with my finest colleague, Arjan Vroege, I will deliver two sessions! And we hope to see you there!

Experts Live Europe is a Microsoft community conference with a focus on Microsoft cloud, datacenter and workplace management. During this conference, top experts from around the world present discussion panels, ask-the-experts sessions and breakout sessions and cover the latest products, technologies and solutions.

About our sessions

The maybe-not-that-sexy version of modern management – A true story –

In this session, we will take you into the real world of modern management. Modern management is a great buzzword and by now we all know the lovely story of modern management. We all know how it should work, but we often lack the real-world examples of organizations using modern management. During this session, we will show you how we internally deployed Windows 10 with Azure AD join and Intune management for over 10k devices. What choices did we make? Which challenges did we run into? Did we close all the gaps? We’ll try to answer these question. To conclude will also look at the available options right now and how they could have helped us. We will also have a couple of cool demos. To provide a sneak preview, here is a small list with subjects that will be part of our session: Win32 apps, MSIX and Windows AutoPilot.

Thursday Friday 2:40 PM – 3.40 PM

Create your ultimate hybrid workplace, what options do you have?

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, Win32 apps, MSIX and Azure AD Application Proxy.

Friday 8:00 AM – 9:00 AM

Make sure that you don’t miss these sessions!

Quick tip: Location services required for enhanced jailbreak detection

This week a short blog post about an end-user experience that might be slightly unexpected when using an iOS device. That experience is the “Turn on location services” compliance message in the Company Portal app. That message is caused by the Enhanced jailbreak detection compliance policy setting, as  that setting uses the location services of the iOS device for the enhanced detection, In this post I’ll first show the mentioned end-user experience, as that’s the trigger for this post, followed by the configuration that triggers the experience.

End-user experience

Let’s start this time by looking at the end-user experience. The user will notice that the iOS device is non-complaint and after opening the Company Portal app, the user will get the message “Turn on location services” (as shown below). That message also includes the required steps to eventually enable the location services on the iOS device;

20181003_171841643_iOS

Configuration

Now let’s have a look at the configuration that triggers the mentioned end-user experience. That configuration is not part of an actual compliance policy, but is part of the overall compliance policy settings. The compliance policy settings basically describes the default behavior for compliance policies. The two steps below show how to configure the Enhanced jailbreak detection setting.

1 Open the Azure portal and navigate to Intune > Device compliance > Compliance policy settings to open the Device compliance – Compliance policy settings blade;;
2 On the Device compliance – Compliance policy settings blade, select Enabled with Enhanced jailbreak detection and click Save;
MSI-DeviceCompliancePolicySettings

Note: Keep in mind that enabling this setting impacts the battery usage of iOS devices and causes iOS devices to check-in more frequently with Microsoft Intune.

More information

For more information about compliance policy settings, please refer to the documentation about Get started with device compliance policies in Intune – Ways to deploy device compliance policies.

Deploy customized Win32 apps via Microsoft Intune

Last week Microsoft announced the ability to deploy Win32 apps via Microsoft Intune during Microsoft Ignite. That takes away one of the biggest challenges when looking at modern management and Microsoft Intune. I know that I’m not the first to blog about this subject, but I do think that this subject demands a spot on my blog. Besides that, I’ll show in this post that the configuration looks a lot like deploying apps via ConfigMgr. Not just from the perspective of the configuration options, but also from the perspective of the configuration challenges when the installation contains multiple files. In this post I’ll show the configuration steps, followed by the end-user experience, when deploying a customized Adobe Reader DC app (including the latest patch).

Pre-process Win32 app

The first step in deploying Win32 apps via Microsoft Intune is using the Microsoft Intune Win32 App Packaging Tool to pre-process Win32 apps. Wrap the Win32 app. The packaging tool wraps the application installation files into the .intunewin format. Also, the packaging tool detects the parameters required by Intune to determine the application installation state.  After using this tool on apps, it will be possible to upload and assign the apps in the Microsoft Intune console. The following six steps walk through wrapping the Adobe Reader DC app, including some customizations and the latest patch.

1 Download the Microsoft Intune Win32 App Packaging Tool. In my example C:\Temp;
2 Create a folder that contains the Adobe Reader DC installation files (including the latest MSP and the MST that contains the customizations). In my example C:\Temp\AdobeReader;
3 Create an installation file that contains the complete installation command and place that file in the directory with the installation files. In my example I created an Install.cmd in C:\Temp\AdobeReader that contains msiexec /i “%~dp0AcroRead.msi” TRANSFORMS=”%~dp0AcroRead.mst” /Update “%~dp0AcroRdrDCUpd1801120063.msp” /qn /L*v c:\InstallReader.log ;
MSI-Win32-Explorer
Note: This method is similar to an easy method in the ConfigMgr world to make sure that the installation process would look at the right location for the additional files.
4 Open a Command Prompt as Administrator and navigate to the location of IntuneWinAppUtil.exe. In my example that means cd \Temp;
5 Run IntuneWinAppUtil.exe and provide the following information, when requested

  • Please specify the source folder: C:\Temp\AdobeReader;
  • Please specify the setup file: AcroRead.msi;
  • Please specify the output folder: C:\Temp
MSI-IWAU-start
Note: Even though I will use a command file to trigger the installation, it’s important to specify the MSI as setup file. That will make sure that, during the configuration in Microsoft Intune, the information will be preconfigured based on the information of the MSI.
6 Once the wrapping is done. The message Done!!! will be shown. In my example a file named AcroRead.intunewin will be created in C:\Temp.
MSI-IWAU-end

Note: It’s possible to use something like 7-Zip to open the created AcroRead.intunewin file. Besides content, that file contains a Detection.xml file that shows the detected information of the installation file.

Configure Win32 app

Now let’s continue by looking at the actual configuration steps, within Microsoft Intune, to configure the Win32 app. The following 17 steps walk through all the steps to configure the Win32 app, by using the .intunewin file. After configuring the app, make sure to assign the app to a user group.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3 On the Add app blade, select Windows app (Win32) – preview to show the configuration options and select App package file to open the App package file blade.
4 MSI-Win32-AppPackageFileOn the App package file blade, select the created AcroRead.intunewin as App package file and click OK to return to the Add app blade;
5 Back on the Add app blade, select App information to open the App information blade;
6

MSI-Win32-AppInformationOn the App information blade, provide at least the following information and click OK to return to the Add app blade;

  • Name: Adobe Acrobat Reader DC is pre-provisioned as name of the app;
  • Description: Provide a description of the app;
  • Publisher: Provide the publisher of the app;

Note: The remaining information regarding the Information URL, the Privacy URL, the Developer, the Owner, the Notes and the Logo is optional.

7 Back on the Add app blade, select Program to open the Program blade;
8 MSI-Win32-ProgramOn the Program blade, change the Install command to “Install.cmd”, verify the Uninstall command and click OK to return to the Add app blade;
9 Back on the Add app blade, select Requirements to open the Requirements blade;
10

MSI-Win32-RequirementsOn the Requirements blade, provide at least the following information and click OK to return to the Add app blade;

  • Operating system architecture: Select the applicable platforms;
  • Minimum operating system: Select a minimum operating system version;
11 Back on the Add app blade, select Detection rules to open the Detection rules blade;
12 On the Detection rules blade, select Manually configure detection rules and click Add to open the Detection rule blade.
13 MSI-Win32-DetectionRuleOn the Detection rule blade, select MSI as Rule type, verify the pre-provisioned MSI product code and click OK to return to the Detection rules blade;
14 Back on the Detection rules blade, click OK to return to the Add app blade;
15 Back on the Add app blade, select Return codes to open the Return codes blade;
16 MSI-Win32-ReturnCodesOn the Return codes blade, verify the preconfigured return codes and click OK to return to the Add app blade;
17 Back on the Add app blade, click Add to actually add app.

Note: The Intune Management Extension will be used for installing the Win32 app. That also means that the process regarding detection, download and installation, of the Win32 app, can be followed in the IntuneManagementExtension.log file.

End-user experience

Let’s end this post by looking at the end-user experience. The user will receive a notification that changes are required, followed by a notification that a download is in progress, followed by a notification about a successful installation. All three stages are shown below. After the last message, the Start Screen shows the newly installed Adobe Reader DC app. Also, in this case, the Desktop doesn’t show the default desktop icon, which I removed using the customization file (MST).

MSI-AAR-Desktop

More information

For more information about the Microsoft Intune Win32 App Packaging Tool, please refer to the GitHub location here.

Assign a user to a Windows AutoPilot device

This blog post uses capabilities that are added in Windows 10, version 1809, which is currently still in preview.

This week a short blog about another relatively new Windows AutoPilot feature. This week is all about assigning a specific user to a specific Windows AutoPilot device. That enables an administrator to directly assign a user to a Windows AutoPilot device. Assigning a user to a Windows AutoPilot device will make sure that the username will be pre-filled during Windows setup. It also lets the administrator set a custom greeting name, which will also be added during the Windows setup. In this post I’ll show the actual configuration steps, followed by the end-user experience.

Configuration

Before starting with the actual configuration steps, it’s important to name a few prerequisites.

  • Azure AD company branding is configured;
  • Device is running Windows 10, version 1809 or later;
  • User is Microsoft Intune licensed

When the prerequisites are in place, it’s time to start looking at the actual configuration. The following five steps walk through assigning a user to a Windows AutoPilot device.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, click Devices to open the Windows AutoPilot devices blade;
3 On the Windows AutoPilot devices blade, select the specific device (make sure to check the box) and click Assign user to open the Select user blade;
AP-AssignUser
4 On the Select user blade, select the specific user and click Select, which will open the Properties blade of the device;
5

AP-UserFriiendlyNameOn Properties blade of the device, provide the User Friendly Name and click OK to return to the Windows AutoPilot devices blade.

Note: This will provide a message like in this case “Awesome dude has ben successfully assigned to 3008-9109-1000-6969-987…

End-user experience

Now let’s end this post by looking at the end-user experience when using a user-driven deployment. After configuring the location and the keyboard, the user will get a personal welcome message. The message includes the configured custom user friendly name and the username will be preconfigured (as shown below). The user only needs to provide a password and click Next.

AP-UserExperience

Note: This experience does not work when used in combination with ADFS.

More information

For more information about assigning a user to a Windows AutoPilot device, please refer to the documentation Enroll Windows devices by using the Windows AutoPilot | Assign a user to a specific Autopilot device.

Configure email profile for the Outlook app

This week is all about configuring an email profile for the Outlook app. Actually preconfiguring an email profile for the users, making sure that the users only need to provide their password. Depending on the exact infrastructure, this can save a lot of (adaption) work in providing guidelines to the users. Some even want to look at this for preconfiguring an email profile for Exchange Online. I’m not that sure about that specific use case. Having said that, I do use that configuration as an example configuration. Simply because I’ve got that available in my lab. In this post I’ll show the available keys for configuring an email profile and I’ll show the configuration steps. I’ll end this post by showing the end-user experience, which will also show why I think that the added value for Exchange Online might be minimal.

Available keys and values

Let’s start by having a look at the available keys and values for configuring an email profile for the Outlook app. Below is an overview of the available keys, the value types, the default value, a short description of the accepted value and if the key is required. All the mentioned keys start with com.microsoft.outlook.EmailProfile.. I removed that prefix to make the table a bit more readable.

Key Value type Default value Accepted value Required
EmailAccountName String <blank> Display name Yes
EmailAddress String <blank> Email address Yes
EmailUPN String <blank> UPN or username Yes
ServerAuthentication String “Username and Password” Authentication method No
ServerHostName String <blank> Hostname Yes
AccountDomain String <blank> Domain name No
AccountType String BasicAuth Authentication model No

Note: Please don’t forget that all of these keys start with com.microsoft.outlook.EmailProfile..

Configuration

Now let’s continue by having a look at the configuration of the actual email profile. The following 7 steps walk through the configuration of the app configuration policy that configures an Exchange Online profile for the Outlook app on iOS.

1 Open the Azure portal and navigate to Intune > Client apps > App configuration policies;
2 On the client apps – App configuration policies blade, click Add to open the Add configuration policy blade;
3 On the Add configuration policy blade, provide a Name, select Managed devices with Device enrollment type, select iOS with Platform and select Associated app to open the Associated app blade;
4 On the Associated app blade, select Outlook and click OK to return to the Add configuration policy blade;
5 On Add configuration policy blade, select Configuration settings to open the Configuration settings blade;
6 On the Configuration settings blade, select Use configuration designer with Configuration settings format, provide the following information and click OK to return to the Add configuration policy blade;

com.microsoft.outlook.EmailProfile.EmailAccountName {{username}}
com.microsoft.outlook.EmailProfile.EmailAddress {{mail}}
com.microsoft.outlook.EmailProfile.EmailUPN    {{userprincipalname}}
com.microsoft.outlook.EmailProfile.ServerHostName https://outlook.office365.com/
com.microsoft.outlook.EmailProfile.AccountDomain petervanderwoude.nl

Note: The mentioned key and value pairs are sufficient to set the required settings for Office 365, including an additional setting to set a value to all configurable fields.

iOS-mail-app-configuration
7 On the Add configuration policy blade, click Add to add the app configuration policy.

Note: This configuration requires a managed device to apply the configuration to the app.

End-user experience

Let’s end this post with the end-user experience. Below on the left is the first screen of the Outlook app, after the app configuration policy is applied. This shows an Exchange configuration, even though this configuration will enable Exchange Online (Office 365). Basically every profile configured via these settings will be shown as an Exchange profile. Below on the right is the second screen of the Outlook app, after the user clicked on Add Account. It only requires the user to provide a password and to click on Sign-in. This also works in combination with a conditional access rule that blocks other clients (legacy authentication).

IMG_0149 IMG_0150

Note: As mentioned earlier, this email configuration prevents the user from typing the UPN. That makes it easier for the user. However, instead, it provides the user with a configuration screen that can be more confusing. A decision to make. I do see a big use case for Exchange on-premises infrastructure.

More information

For more information about configuring the Outlook app, refer to the following documentation:

Block access to company resources if certain apps are installed

This week is all about device compliance. More specifically, this week is all about the just introduced capability to block access to company resources if certain apps are installed. This enables organizations to truly blacklist specific apps that are not allowed when using devices to access company resources. In this case it’s not about the apps used for accessing the company resources, but it’s really about the apps installed on the device. In this post I’ll provide the configuration steps, by using OWA for iPad as an example, followed by the end-user experience.

Configuration

Before starting with the actual configuration, it’s important to get the bundle ID of the iOS app that cannot be installed. These steps are very clearly documented here. I will use OWA for iPad as an example, which has the following bundle ID: com.microsoft.exchange.ipad.

Now let’s continue by having a look at the configuration steps. The following five steps walk through the creation of a device compliance policy with at least the configuration of OWA for iPad as a restricted app. Within a device compliance policy a restricted app is what was earlier described, in this post, as blacklisted apps. After the creation of the device compliance policy, simply assign it to the applicable user group.

1 Open the Azure portal and navigate to Intune > Device compliance > Policies;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3

On the Create Policy blade, provide a Name, select iOS with Platform and select Settings to open the iOS compliance policy blade;

Note: This is currently an iOS only configuration. Android is expected a bit later.

4 On the iOS compliance policy blade, select System Security to open the System Security blade;
5

On the System Security blade, navigate to the Device Security section, provide the App name, the App Bundle ID and click Add, followed by and clicking OK, OK and Create.

Note: The provided App name will be mentioned in the potential non-compliance message to the end-user and the App Bundle ID is in this example the id of the OWA for iPad app.

MSI-RestrictApp

Note: To complete this configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post with the end-user experience. Let’s do that by looking at the end-user experience on an iOS device with OWA for iPad installed. On the left is the default message that is displayed to the end-user when trying to access company data on a non-compliant device. On the right is the message that the end-user will receive in the Company Portal app related to the compliance state of the device. In this case it will provide the end-user with a list of disallowed apps that should be uninstalled. The list shows the name of the app, as provided in the compliance policy.

IMG_0143 IMG_0144

More information

For more information about blocking access if certain apps are installed, refer to the documentation about adding a device compliance policy for iOS devices in Intune.

Single full-screen Kiosk Browser app in kiosk mode

This week is all about configuring a single full-screen app in kiosk mode and more specifically, configuring the Kiosk Browser app as a single full-screen app in kiosk mode. A couple of years ago, I also did a post about setting up kiosk mode on Windows 10. This time it’s not about using OMA-URI’s, this time is all about using the available options within the portal. Spoiler alert, it became a whole lot easier! Deployment scenarios that this adds on to are, for example, AutoPilot self-deploying mode and enrollment via a device enrollment manager. In this post I’ll go through a few prerequisites for the configuration, followed by the actual configuration of the Kiosk Browser app in kiosk mode. I’ll end this post by looking at the end-user experience.

Prerequisites

Before being able to configure kiosk mode with the Kiosk Browser app, the following prerequisites must be in place and available.

  • Deploy the de Kiosk Browser app. The best method to deploy the app is by using the Microsoft Store for Business integration with Microsoft Intune. That combination will enable the ability to assign the app as a required app to devices and users;
  • Get the Application User Model ID (AUMID) of the Kiosk Browser app. The easiest method is using the provided PowerShell script, which will provide the following AUMID for the Kiosk Browser app: Microsoft.KioskBrowser_8wekyb3d8bbwe!App;

Configuration

Now that the prerequisites are known, it’s time to look at the actual configuration. Within this configuration I will show the steps to create a kiosk profile that will create a full-screen Kiosk Browser app with an autologon user. The following four steps will walk through the required configuration. After that simply assign the created profile to a user (for example the device enrollment manager) or device group (for example the AutoPilot self-deploying devices).

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

KioskProfileOn 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 Kiosk (Preview);
  • Settings: See step 4a and 4b.
4a

KioskMode-AddRowOn the Kiosk (Preview) blade, select Kiosk to open the Kiosk blade. On the Kiosk blade, 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 Kiosk (Preview) blade);

  • Kiosk configuration name: Provide a valid name;
  • Kiosk Mode: Select Single full-screen app kiosk;
  • Universal Windows Platform (UWP) app identifier: Select Enter UWP app AUMID;
  • Application user model ID (AUMID) of app: Microsoft.KioskBrowser_8wekyb3d8bbwe!App;
  • User account type: Select Autologon.
4a

KioskBrowser-ConfigOn the Kiosk (Preview) blade, select Kiosk web browser to open the Kiosk web browser blade. On the Kiosk web browser blade, provide the following information and click OK;

  • Default home page URL: https://petervanderwoude.nl;
  • Home button: Select Not configured;
  • Navigation buttons: Select Not configured;
  • End session button: Select Not configured;
  • Refresh browser when user exceeds idle time limit: (Optional) Provide a time limit;
  • Blocked websites: (Optional) Add blocked websites;
  • Website exceptions: (Optional) Add excluded websites.

Note: As I’m not providing any buttons, there is no real use for blocking any websites.

Note: Even though the configuration was a success, the device configuration would always show the status Failed on the setting Full screen kiosk app status.

End-user experience

Now let’s end this post by looking at the end-user experience. The first thing I would like to show, is the default user that is created when using autologon as the user account type. That user is a local user named Kiosk and that local user not configured with a password. Once that user is automatically logged on and somebody would press Ctrl+Alt+Del, the person would see the screen as shown below.

MSI-KioskUser

The second thing that I would like to show is the end result of the complete configuration. When the configuration is applied to the device, the Kiosk user will autologon to the device and the Kiosk Browser app will start with the configured home page and without the ability to navigate or any other interaction, as shown below.

MSI-KioskBrowserLD

The third and last thing that I would like to show is the end result when the configuration is changed. Changed in a way that the navigation buttons are shown, the home button is shown and the end session button is shown. That result is shown below. With that configuration is might be useful to create a list with blocked websites.

MSI-KioskBrowser

More information

For more information related to configuring kiosk mode on Windows 10 and the KioskBrowser area in the Policy CSP, please refer to the following articles: