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.

Move the content library to a remote location

This week is all about moving the content library to a remote location in Configuration Manager, version 1806. Moving the content library to a remote location is an important step in making a Configuration Manager hierarchy high available. Configuration Manager, version 1806, introduced site server high availability for a standalone primary site server role by installing an additional site server in passive mode. To complete that high available configuration it’s also smart to move the content library to a remote location. That will make sure that the content library is still available when the active site server went down. This post will provide the prerequisites for moving the content library, the steps to move the content library and the flow when moving the content library.

Prerequisites

Before actually moving the content library to a remote location, make sure that the following prerequisites are in place:

  • Create a folder on a network share that will be used as the location for the content library;
  • Provide the site server account with read and write permissions to the created folder;
  • Make sure that the site server doesn’t have the distribution point role.

Move content library

Now let’s have a look at actually moving the content library. This action is actually relatively simply and can be achieved by performing the following four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2

Select the site and click Manage Content Library on the Site section of the Home tab, to open the Manage Content Library dialog box;

Note: The option will be grayed out when the site server has the distribution point role.

3

CM_MCL-NewLocationOn the Manage Content Library dialog box, provide the just created new folder and click Move;

Note: The Current Location will be empty when the current content library is divided on multiple disks.

Important to mention is that this action actually only copies the content library to the specified remote location. It doesn’t remove the content library from the old location. That would be a manual action.

Follow the flow

Let’s end this post by following the flow through the main log files and the Configuration Manager administration console. In my opinion always the most interesting part. I would like to divide this into three sections, 1) the actual trigger of the move content library action, 2) the start of the copy content action and 3) the end of the copy content action.

The trigger

The trigger of the action to move the content library to a remote location is logged in SMSProv.log. That log file shows the execution of the SetContentLibraryLocation method of the SMS_Site class. That method can also be used for automation with PowerShell. CM-MCL-SMSProvlog

The start

CM_MCL-StatusPercentage

The actual start of the action to move the content library to a remote location is logged in distmgr.log. That log file shows the source and destination location followed by the status of the action. It also shows that it will update the information in the Configuration Manager administration console, which is also shown above. At this point the location in the console is still the current location.

CM-MCL-distmgrlog

The end

CM_MCL-StatusPercentage-done

The end of the action to move the content to a remote location is also logged in distmgr.log. That log file shows that after the content is copied, the content will also be validated and once that’s completed it will state that the action is completed. It also shows that it updated the information in the Configuration Manager administration console, which is also shown above. At this point the location in the console is the new location.

CM-MCL-distmgrlog-done

More information

More information about the content library and the flowchart for managing content, please refer to the following articles:

Software Center is getting close to awesome!

It’s almost been too long ago since I’ve done my latest post about Software Center. Luckily there are enough reasons introduced with Configuration Manager, version 1806,  to devote another blog post to Software Center, as Software Center is getting close to awesome. Yes, I deliberately say close to awesome, as we always need to leave options open for improvement. In this post I’ll focus on three great new additions to Software Center: 1) infrastructure improvements, 2) a custom tab and 3) maintenance windows.

No more application catalog website point and web service point required

Let’s start with the first and, in my opinion, best improvement related to Software Center. Starting with Configuration Manager, version 1806, available user-targeted apps can be made available in Software Center without using the application catalog website point and the application web service point. Both of these roles are no longer required. Software Center now relies on management points to get the information about available user-targeted apps. This also implies that the agent must be updated to provide the new functionality.

I’ve removed both of the mentioned roles. To completely clean up the configuration, especially from a Software Center perspective, also the Open the Application Catalog web site link must be removed (or actually be hidden) from Software Center. Otherwise it will still show a gray unneeded text. To achieve this, simply follow the next four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client Device Settings and select the Software Center section, or open open the Default Client Settings and select the Software Center section;
3 In the Software Center section, select Yes with Select these new settings to specify company information and click Customize with Software Center settings to open the Software Center Customization dialog box;
4

SC_Customization-GeneralOn the Software Center Customization dialog box, select the General tab and provide at least the following information;

  • Select Hide Application Catalog link in Software Center;

Note: In my example I’ve only selected to hide the Application Catalog link. Below is an example of the link in Software Center that will be removed. I deliberately left the link, to show that it’s not a link anymore and to show what will be removed;

SC_InstallationStatus

Custom configurable tab available for linking to a webpage

The second, also pretty good, improvement, is the ability to add a custom tab to Software Center. The administrator can define a name for the custom tab and the administrator can specify a URL that should be opened in the custom tab. It can be an internal webpage and an external webpage. The latter option would of course require an Internet connectivity. This also implies that the agent must be updated to provide the new functionality. To achieve this, simply follow the next four steps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client Device Settings and select the Software Center section, or open open the Default Client Settings and select the Software Center section;
3 In the Software Center section, select Yes with Select these new settings to specify company information and click Customize with Software Center settings to open the Software Center Customization dialog box;
4

SC_Customization-TabsOn the Software Center Customization dialog box, select the Tabs tab and provide at least the following information;

  • Select Specify a custom tab for Software Center;
  • Tab name: Provide a custom name;
  • Content URL: Provide a valid URL;

Note: In my example the custom tab is named Contact and it refers to the contact page of my blog. An example of the user experience is shown below.

SC_CustomTab

Next scheduled maintenance window is shown

The third improvement is a little bit smaller, but can provide really useful information to the end-user. The third improvement is the availability of the next available maintenance window within Software Center. Previously this required a little bit of custom scripting, but now the information is available within the Upcoming section of the Installation status tab in Software Center. This also implies that the agent must be updated to provide the new functionality.

SC_InstallationStatus

More information

More information about what’s new related to Software Center in the latest current branch version, please refer to this article about What’s new in version 1806 of Configuration Manager current branch – Software Center.

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:

Prevent users from ending tasks via Windows 10 MDM

This blog post uses the TaskManager node of the Policy CSP, to prevent the end task functionality on Windows 10 devices. This node is added in Windows 10, version 1809, which is currently still in preview.

This week a short blog post about a newly introduced setting in Windows 10, version 1809, which is currently still in preview. That’s the setting to prevent non-administrator users from ending tasks via Task Manager. That can be a useful addition to a Windows AutoPilot deployed device on which the users are configured as standard users. Simply preventing users from performing activities that an administrator might not like them to do. In this post I’ll show the available settings, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the available settings. The TaskManager area is a new node within the Policy CSP. That area currently contains only one policy setting, which is AllowEndTask. That policy setting can be configured to an Integer value of 0, which means that the end task functionality is blocked in Task Manager, or to an Integer value of 1, which means that the end task functionality is available in Task Manager. By default, the end task functionality is available. Also, keep in mind that this configuration is only applicable to non-administrator users.

Configuration

Now let’s continue by having a look at the configuration to prevent non-administrator users from ending tasks via Task Manager. In other words, create a device configuration profile with the previously mentioned custom policy setting. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or 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

EndTask-ConfigOn 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/Policy/Config/TaskManager/AllowEndTask;
  • Data type: Select Integer;
  • Value: 0.

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 looking at the end-user experience. Below is an example of a Windows 10 device running the latest available Windows Insider Preview build and deployed via Windows AutoPilot. In that example it’s visible on the left that the TaskManager policy is configured and it’s visible on the right that the end task option is actually grayed out for the user. In other words, the user is unable to end a task via Task Manager.

EndTask-MSIntune

More information

For more information about the available Task Manager settings in the Policy CSP, please refer to the documentation about Policy CSP – TaskManager.

Block app access for unapproved device manufacturers or device models

This week is all about app protection. More specifically, this week is all about the just introduced capability to block app access for Android devices with unapproved device manufactures , or for iOS devices with unapproved device models. That capability actually has two separate actions to choose from, 1) block app access and 2) selective wipe of corporate data within the app. This capability will help with preventing access from untrusted devices to corporate data. Really useful, as we all can think of some low-end devices (loaded with malware, almost for free) that should not be used for accessing corporate data. In this post I’ll show the available configuration options, followed by the end-user experience.

Configuration

Now 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 policy settings (see step 5a and 5b). 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;
3

On the Add a policy blade, select iOS or Android with Platform and select Yes with Target to all app types.

Note: The main configuration of this post can be used in combination with managed devices and unmanaged devices.

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. Depending on the platform continue with step 5a, or step 5b;
5a

On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, and having iOS selected with Platform, navigate to Access Action and select Device model(s) on a new line as SETTING. As a VALUE specify the allowed models, select as ACTION to either Allow specified (Block non-specified) or Allow specified (Wipe non-specified) and click OK;

Note: The iOS model identifier can be found under the “Device Type” column in HockeyApp’s support documentation and to specify multiple allowed device models, use a semi-colon (;) to separate them.

MSIS-App-Protection-iOS
5b

On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, and having Android selected with Platform, navigate to Access Action and select Device manufacturer(s) on a new line as SETTING. As a VALUE specify the allowed manufacturers, select as ACTION to either Allow specified (Block non-specified) or Allow specified (Wipe non-specified) and click OK;

Note: To specify multiple allowed device manufacturers, use a semi-colon (;) to separate them.

MSIS-App-Protection-Android
6 On the Add a policy blade, click Create;

Note: On iOS devices, this feature requires the participation of applications (such as WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for this feature to be enforced with the targeted applications. On Android, this feature requires the latest Company Portal app.

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the end-user behavior on an iOS device. For experiencing the different messages, I made sure that my iPad would not be allowed. Below on the left is an example of the App Access Blocked message in the Outlook app, which clearly explains to the end-user that the iOS model is not allowed. Below on the right is an example of the Org Data Removal message in the Outlook app, which clearly explains to the end-user that the iOS model is not allowed and that associated data will be removed.

IMG_0139 IMG_0140

More information

For more information about blocking access for unapproved device vendors or models, refer to this article about Selectively wiping data using app protection policy access actions in Intune.

Factory reset, Fresh start, AutoPilot reset, so many options?!

This week something completely different. This time no technical configurations, this time I’ll try to provide some guidance about different Windows 10 features to remotely reset a Windows 10 device by using Microsoft Intune. With the introduction of the remote AutoPilot reset their are now 3 similar features to remotely reset a Windows 10 device: Factory reset , Fresh start and AutoPilot reset. In this post I’ll try to answer questions like “What are the differences between these reset options?” and “When can I use which reset option?”.

Factory reset

Introduction

The Factory reset action returns the device to its factory default settings. This removes all personal and company data and settings from this device. The drive will be securely erased. When triggering this remote action it is possible to select the Retain enrollment state and user account checkbox, to keep the device enrolled and the user account associated with this device. This action cannot be reverted.

By using the Factory reset action, it’s possible to get devices to a factory default state. Also, just like the Remove company data action, it enables administrators to simply remove devices from Microsoft Intune that are no longer needed, being repurposed, or missing.

Win10-Int-FactoryReset

Summary

Retain enrollment state and user account* Retain Intune enrollment Summary of performed actions
Factory reset Not checked No
  • Removes user accounts;
  • Removes user data;
  • Removes MDM policies;
  • Removes non-default settings;
  • Removes user-installed apps;
  • Retains OEM-installed apps;
  • Resets the operating system to its default state and settings.
Factory reset Checked Yes
(Also retains Azure AD join)
  • Retains user accounts
  • Retains user data;
  • Removes MDM policies;
  • Removes non-default settings;
  • Removes user-installed apps;
  • Retains OEM-installed apps;
  • Resets the operating system to its default state and settings.

*Retain enrollment state and user account requires Windows 10, version 1709 or later.

Fresh start

Introduction

The Fresh start action literally gives the user a fresh start. This removes any apps that are installed on the device. Then, it automatically updates the device to the latest version of Windows. This action helps with removing pre-installed (OEM) apps that are typically installed with a new device. When triggering this remote action it is possible to select the Retain user data on this device checkbox, to keep the user data, and only remove apps and settings.

By using the Fresh start action, it’s possible to get devices to an clean state by removing all bloatware and updating to the latest version of Windows 10 at the same time.

Win10-Int-FreshStart

Summary

Retain user data on this device Retain Intune enrollment Summary of performed actions
Fresh start*

 

Not checked No
(Retains Azure AD join)
  • Removes user accounts;
  • Removes user data;
  • Removes MDM policies
  • Removes settings;
  • Removes Win32 apps;
  • Retains Windows Store apps;
  • Updates to the latest version of Windows.
Fresh start* Checked Yes
(Also retains Azure AD join)
  • Retains user accounts
  • Retains user data;
  • Removes MDM policies;
  • Removes settings;
  • Removes Win32 apps;
  • Retains Windows Store apps;
  • Updates to the latest version of Windows.

*Fresh start requires Windows 10, version 1703 or later.

AutoPilot reset

Introduction

The AutoPilot reset action returns the device to a fully configured and/or IT-approved state. This removes personal files, apps, and settings, and applies the original settings and management settings, so the devices are ready to use. The management settings are coming straight from Azure AD ​and Intune device management.

By using the AutoPilot reset action, it’s possible to get the device to a known, good, managed and synchronized state while preserving the management enrollment.

Win10-Int-AutoPilotReset

Summary

Retain Intune enrollment Summary of performed actions
AutoPilot reset* Yes
(Also retains Azure AD join)
  • Retains user accounts;
  • Removes user data;
  • Removes MDM policies;
  • Removes settings;
  • Removes installed apps;
  • Returns the device to the original settings and management settings.

*Remote AutoPilot reset requires Windows 10 Insider Preview Build 17672 or later.

More information

For more information related to Fresh start, Factory reset and AutoPilot reset in combination with Microsoft Intune, please refer to the following articles:

Simply installing the Windows 10 Accounts extension for Google Chrome by using PowerShell

This week is all about simply automatically installing the Windows 10 Accounts extension for Google Chrome. About a year ago I showed that the extension is required when using conditional access and I also showed earlier that it’s possible to use ADMX ingestion to configure Google Chrome. However, the latter is always the easiest method. It actually might be a bit complicated for a simple configuration. That’s why I’m going a different road this time. This time I’m going for a small PowerShell script that will create a registry key and value. In this post I’ll show how to create the PowerShell script, how to assign it by using Microsoft Intune and the end result in Google Chrome.

Create PowerShell script

As I’ve decided to use a PowerShell script to install the Windows 10 Accounts extension for Google Chrome, together with Google Chrome, this section will explain the variables and actions used in the script. For installing Google Chrome, I’ll reuse a PowerShell script that I explained in this post about Combining the powers of the Intune Management Extension and Chocolatey.

Script variables

The PowerShell script contains a few variables that are used to make sure that the Windows 10 Accounts extension will be installed. Those variables together are actually a registry key and value. That means that the variables block on top of the script (see script snippet section) at least contains the values as shown below. The registry key and value will trigger the installation of the Windows 10 Accounts extension and is the same registry key and value that would otherwise be created by the ADMX configuration.

Path HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist
Name 1
Type REG_SZ (String)
Data ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Script actions

The PowerShell script contains a few actions that it should perform to complete the required activities of installing Google Chrome and the required Windows 10 Accounts extension. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).

  1. Install Chocolatey if it’s not installed;
  2. Install Google Chrome by using Chocolatey (it will automatically check if it’s already installed);
  3. Create the required registry path if it doesn’t exist;
  4. Create the required registry key if it doesn’t exist.

Script snippet

The PowerShell script is shown below and should pretty much explain itself.

Configure PowerShell script

The next 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 ChromeExtension-PowerShell-IntuneOn 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 ChromeExtension-ScriptSettings-IntuneOn 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 end result. I’ll do that by showing a screenshot of Google Chrome. Below is a screenshot of Google Chrome showing the policy page, which shows the configured policy, and it also shows the installed Windows 10 Accounts extension (blue Windows icon on the top right).

ChromeExtension

More information

Fore more information related to conditional access and the requirements for Google Chrome, please refer to this article about Conditional Access Technical Reference | Client apps condition.

Remote Windows AutoPilot Reset

This blog post uses remote Windows AutoPilot Reset, to remotely trigger a device reset on Windows 10 devices. This capability is added in Windows 10, Insider Preview Build 17672 and later.

This week it’s all about (remote) Windows AutoPilot Reset. That might sounds like something really cool and really new, but it’s actually not that new. Remember my post about Windows Automatic Redeployment? Well, that functionality still exists, but with the addition to trigger the redeployment (read: reset) remotely via Microsoft Intune, this feature is rebranded to (remote) Windows AutoPilot Reset. That means that Windows Autopilot Reset removes personal files, apps, and settings, by resetting Windows 10 while still maintaining the Azure AD Join and the Microsoft Intune enrollment. In this post I’ll show the required configuration to enable Windows AutoPilot Reset, followed by the steps to trigger a remote Windows AutoPilot Reset. I’ll end this post by looking at the end-user experience.

Configure automatic redeployment

Before actually looking at the required configuration, it’s good to keep in mind that WinRE must be enabled on the device to use Windows AutoPilot Reset. Now let’s continue with the configuration to enable Windows AutoPilot Reset (previously know as Windows Automatic Redeployment). The previous time I configured it by using a custom OMA-URI, while the configuration already became available through the UI. So this time I’ll simply show the UI-setting. The following three steps walk through the creation of a new device configuration profile, including configuring the required setting. After that simply assign the created profile to a user or device group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device 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 for the profile;
  • Description: (Optional) Provide a description for the profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Device restrictions;
  • Settings: See step 3b;
3b On the Device restrictions blade, select General, select Allow with Automatic Redeployment and click OK and OK;
Intune-Automatic-Redeployment

Note: Remember that it’s not a requirement to create this as a separate new profile. This setting can also be added to an existing device restrictions profile.

Trigger remote reset

Based on my previous post about Windows Automatic Redeployment, I showed how to trigger the reset locally from the device. Now let’s continue this post by looking at how to actually trigger the remote reset by using Microsoft Intune. The following three steps walk through the actions.

1 Open the Azure portal and navigate to Intune > Devices > All devices to open the Devices – All devices blade;
2 Intune-AutoPilot-ResetOn the Devices – All devices blade, select the target device and click More > AutoPilot Reset (preview);
3 On the AutoPilot Reset (preview) – [computer name] confirmation box, click Yes;
Intune-AutoPilot-Reset-Confirmation

Note: After confirming the action will show as Action automaticRedeployment with the Status Pending. Once the action is completed the status will change to Completed.

End-user experience

Let’s end this post by looking at the end-user experience. Once the remote Windows AutoPilot is triggered the end-user will receive a notification message, as shown below. That message will tell the end-user that the system needs to restart for automatic redeployment and that the restart is scheduled in 45 minutes.

Intune-AutoPilot-Reset-Experience

More information

For more information about remote Windows AutoPilot Reset, please refer to the documentation about Reset devices with AutoPilot Reset.