Configuring shared multi-user devices

This week is all about a recently introduced profile in Microsoft Intune to configure shared PC mode on a Windows 10 device. That profile is named Shared multi-user device profile. Something similar has been available already for a while via Intune for Education. The main use case for this profile are school devices that are shared between multiple students. In this post I’ll provide a brief introduction regarding shared PC mode, followed by the configuration (and the configuration options) of the Shared multi-user device profile. I’ll end this post by looking at the end-user experience.

Introduction

Let’s start with a short introduction about shared PC mode and immediately address the main use case. Shared PC mode s designed to be management- and maintenance-free with high reliability. A good example of devices that benefit from shared PC mode are school devices. These devices are typically shared between many students. By using the Shared multi-user device profile, the Intune administrator can turn on the shared PC mode feature to allow one user at a time. In that case, students can’t switch between different signed-in accounts on the shared device. When the student signs out, the administrator can also choose to remove all user-specific settings.

End-users can sign in to these shared devices with a guest account. After users sign-in, the credentials are cached. As they use the shared device, end-users only get access to features that are allowed by the administrator. For example, the administrator can choose when the shared device goes in to sleep mode, the administrator can choose if users can see and save files locally, the administrator can enable or disable power management settings, and much more. Administrators also control if the guest account is deleted when the user signs-off, or if inactive accounts are deleted when a threshold is reached.

Configuration

Now that it’s known what the main use case is of the the Shared multi-user device profile, let’s have a look at the configuration of the Shared multi-user device profile. The following four steps walk through the creation of the Shared multi-user device profile, including a short explanation with the different configuration options. After the creation of the profile, it can be assigned to a user and/or device group (just like any other profile).

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 SMUD-CreateProfileOn the Create profile blade, provide the following information and click Settings to open the Shared multi-user blade;

  • 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 Shared multi-user device;
  • Settings: See step 3b;
3b On the Shared multi-user device blade, provide the following configuration and click OK to return to the Create profile blade (see screenshot below);

  • Share PC mode: Select Enable to turn on shared PC mode. In shared PC mode, only one user can sign in to the device at a time. Another user can’t sign in until the first user signs out;
  • Guest account: Select Guest to create a guest account locally on the device that will be shown on the sign-in screen. These guest accounts don’t require any user credentials or authentication. Each time this account is used, a new local account is created;
  • Account management: Select Enable to turn on automatic deletion of accounts created by guests. These accounts will be deleted based on the account deletion configuration;
  • Account deletion: Select Immediately after log-out to make sure that created guests accounts are deleted immediately after log-out;
  • Local Storage: Select Disabled to prevent users from saving and viewing files on the hard drive of the device;
  • Power Policies: Select Disabled to prevent users from turning off hibernation, overriding all sleep actions, and changing the power settings;
  • Sleep time out (in seconds): Enter 60 (or any other value between 0 and 100) as the number of inactive seconds before the device goes into sleep mode;
  • Sign-in when PC wakes: Select Disabled to make sure that users don’t have to enter their username and password (they can use the guest account);
  • Maintenance start time (in minutes from midnight): Can be used to enter the time in minutes (0-1440) when automatic maintenance tasks, such as Windows Update, run.
  • Education policies: Select Enabled to use the recommended settings for devices used in schools, which are more restrictive. These settings are documented here;
SMUD-ShareMultiUserDevice.
4 Back on the Create profile blade, click Create.

Note: Besides configuring Windows Update, it is not recommended to set additional policies on devices configured with shared PC mode. The shared PC mode is optimized to be fast and reliable over time with minimal to no manual maintenance required.

End-user experience

Let’s end this post by looking at the end-user experience after assigning the Shared multi-user device profile. The first thing the end-user will notice is that it can click on the guest user account icon and simply click sign-in. No password will be required.

SMUD-Example01

Once logged on to the device, there are many places to look for a limited experience and specific configurations. I choose to show an important configuration related to the guest account and and few configurations related to available options to the end-user. Below on the right is an example of the guest accounts that are created. Every time the user logs off, the account will be disabled and a new account will be created. Below on the left and on the bottom are two examples related to permissions. It shows that the guest user can’t access the local C-drive and the Control Panel. It also confirms a statement at the beginning of this post; the main use case is schools. It clearly shows in the messages.

SMUD-Example02

More information

For more information regarding Windows 10 shared multi-user devices and configuring those devices in Microsoft Intune, please refer to the following articles:

Simply enabling Windows Sandbox

This blog post uses Containers-DisposableClientVM, to enable the Windows Sandbox feature on Windows 10 devices. This is available in Windows 10 Insider build 18305 or later.

This week is all about enabling a recently introduced Windows Feature. That Windows Feature is Windows Sandbox. Windows Sandbox is a lightweight desktop environment that is specifically created for safely running applications in isolation. It provides an isolated, temporary, desktop environment where users can run untrusted software without the fear of lasting impact to their device. Any software installed in Windows Sandbox stays in the sandbox and cannot affect the host. The installed software is permanently deleted, once Windows Sandbox is closed. Windows Sandbox is part of Windows 10 (Pro and Enterprise) Insider build 18305 or later. In this post I’ll show how to use Microsoft Intune to enable Windows Sandbox, followed by the end result.

Script

Let’s start  by looking at the PowerShell script that can be used to enable the Windows Sandbox feature. The following PowerShell script can be used to basically enable any Windows Feature, but will be used in this post to specifically install the Windows Sandbox feature.

Note: When using a virtual machine, nested virtualization must be enabled for that virtual machine. That can be achieved by using the following PowerShell cmdlet on the host machine: Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true.

Configuration

The next step is to configure the PowerShell script in Microsoft Intune. The script must run in SYSTEM context to easily install new Windows Features. To upload the script, follow the five steps below. After uploading the script, simply assign the script to the required devices. I deliberately mentioned devices, as I’m using a security group that filters on the version of Windows 10. The good thing is that nowadays these scripts can be assigned to devices and that users are not required to be logged on first.

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;
3a EWS-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;
  • Description: (Optional) Provide a description for the PowerShell script;
  • Script location: Browse to the created PowerShell script;
  • Settings: See step 3b;

Note: The script must be less than 200 KB (ASCII) or 100 KB (Unicode).

3b EWS-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;
4 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. To verify a success, simply start Windows Sandbox. That Windows Feature should be available now. To verify a success from a Microsoft Intune perspective, either check the status of the PowerShell script in the Azure portal , or look at the AgentExecutor.log and IntuneManagementExtension.log on the device.

EWS-Example

Note: By using PowerShell, at this moment, Windows Sandbox can also be enabled on not supported devices (devices without virtualization capabilities), .

More information

For more information regarding Windows Sandbox and PowerShell scripts in Microsoft Intune, please refer to the following articles:

Easily controlling the Office update channel by using administrative templates

Let’s start this new year about a specific use case for the recently introduced feature to configure administrative template settings via Microsoft Intune. That specific use case is to easily control and configure the Office update channel by using the Administrative Templates profile type within Microsoft Intune. Before, this configuration would require ingesting a custom ADMX and creating custom OMA-URI settings, for configuring the Office channel, based on the information in the ingested custom ADMX. That’s not necessary anymore, as Microsoft Intune now provides a built-in list of available administrative template policy settings. In this post I’ll show the configuration steps, followed by the configuration results on a Windows 10 device.

Configuration

Before looking at the actual configuration steps, it might be good to first refresh memories by looking at the naming of the update channels in the different locations. The following table shows the naming of the different channels in Microsoft Intune (and the Office apps) and in the actual ADMX. Good news! This is actually the last time that it’s really required to look at this information. As this post will show, it wasn’t even necessary for the configuration in this post. It will be useful for verifying the results. Microsoft Intune will now provide an easy method for configuring many ADMX-backed settings, without going through the actual ADMX anymore.

Azure portal ADMX setting
Monthly Channel FirstReleaseCurrent
Monthly Channel (Targeted) Current
Semi-Annual Channel Deferred
Semi-Annual Channel (Targeted) FirstReleaseDeferred
Insider Fast InsiderFast

When this would be a configuration of an ADMX-backed settings, the information in the table above would be really relevant during the configuration. Since recently Microsoft Intune contains a new profile type, named Administrative Templates. These profiles take care of the heavy work. In case of Office settings, which will be used in this post, these profiles even take care of ingesting the correct ADMX-files. The following six steps walk through the creation of an Administrative Templates profile type that will be used to configure the Office update channel. After the creation of the policies it can be assigned to a user and/or device 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;
3

OfficeUpdates-CreateProfileOn the Create profile blade, provide the following information and click Create to open the <Name> blade;

  • 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 Administrative Templates (Preview);
4 On the <Name> blade, select Settings to open the <Name> – Settings blade;
5 On the <Name> – Settings blade, type Updates in the Search to filter items… field to filter the available settings to only update related settings and select Update Channel (as shown below) to open the Update Channel blade.
OfficeUpdates-Settings
6

OfficeUpdates-UpdateChannelOn the Update Channel blade, select Enabled to enable the setting, select the required update channel with Channel Name and click OK.

Note: Keep in mind that enabling a setting and clicking OK will directly save the change to the created device configuration profile. This is a similar experience to how changes are managed when working with normal group policies.

Note: In my device configuration profile I’ve also configured Enable Automatic Updates and Hide option to enable or disable updates to make sure that Office automatically checks for updates without an option for the user to disable Office updates.

Result

Now it’s really interesting to look at the result of the created configuration. For that, let’s first have a look at the registry. Below on the left is an overview of the registry key of the policy manager that contains the created Office configuration. It clearly shows the settings that should be configured, including the update branch. The update branch contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is an overview of the registry key of the policy manager that contains the ingested Office ADMX.

OfficeUpdates-Registry01 OfficeUpdates-Registry02

Another interesting location is the standard location in the registry that contains policy settings. Below on the left is an overview of the configured update branch. The update branch also contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is the actual configuration of an Office app shown. That clearly shows the Monthly Channel configuration.

OfficeUpdates-Registry03 OfficeUpdates-Outlook01

Offline Windows Autopilot deployment profile

This week is all about Windows Autopilot. More specifically, about offline Windows Autopilot deployment profiles. The use case for an offline Windows Autopilot deployment profile is simple, a migration from Windows 7 to Windows 10 for existing devices. It enables organizations to reimage devices for one last time and provide those devices with an offline Windows Autopilot deployment profile. That will make sure that those devices will contact the Windows Autopilot deployment service, without first being registered. In this post I’ll look at getting the offline Windows Autopilot deployment profile, followed by a look at the explanation of the attributes in the offline Windows Autopilot deployment profile. I’ll end this post by looking at the usage of the offline Windows Autopilot deployment profile and a method to group the devices that are deployed via an offline Windows Autopilot deployment profile.

How to get the offline deployment profile

Let’s start by having a look at how to get the offline Windows Autopilot deployment profile. The following five steps walk through the process of downloading the required PowerShell cmdlets, connecting to the correct services and saving the Windows Autopilot deployment profile as a JSON-file.

1 Open a Windows PowerShell command box, as an administrator, on an Internet connected device
2 Install the Azure AD module by using Install-Module AzureAD -Force
3 Install the Windows Autopilot module by using Install-Module WindowsAutopilotIntune -Force
4a Connect to the Intune service by using Connect-AutopilotIntune
4b Provide the user principle name of a user with enough administrative rights and provide the password in the Sign in to your account window
5

Export the Windows Autopilot deployment profile (Get-AutoPilotProfile), convert the deployment profile to JSON-fornat (ConvertTo-AutoPilotConfigurationJSON) and save the output as AutoPilotConfigurationFile.json (Out-File) by using Get-AutoPilotProfile | ConvertTo-AutoPilotConfigurationJSON | Out-File -FilePath $env:userprofile\desktop\AutoPilotConfigurationFile.json -Encoding ASCII

Note: When there are multiple deployment profiles configured in the tenant, there should be an additional filter being used to only export a specific deployment profile.

OWADP-JSON

Explanation of the attributes in the offline deployment profile

The JSON-file contains a few different attributes and it’s good to understand the usage of those attributes. The following table contains the different attributes and a short explanation.

Attribute Explanation
CloudAssignedTenantId This GUID is a required attribute and specifies the GUID of the Azure AD tenant that should be used.
CloudAssignedDeviceName This string is an optional attribute and specifies the naming pattern for devices that should be used.
CloudAssignedForcedEnrollment

This number is a required attribute and specifies if the device should require AAD Join and MDM enrollment. This can be one of the following values:

  • 0 = not required,
  • 1 = required.
Version This number is an optional attribute and specifies the version that identifies the format of the JSON file. For Windows 10, version 1809, the version must be 2049.
Comment_File This string is an optional attribute and specifies a comment that by default contains the name of the profile.
CloudAssignedAadServerData This encoded JSON string is a required attribute and specifies the branding configuration (this requires Azure AD branding to be enabled) that should be used.
CloudAssignedOobeConfig

This number is a required attribute and specifies a bitmap that shows which Autopilot settings should be configured. This can include the following values:

  • SkipCortanaOptIn = 1,
  • OobeUserNotLocalAdmin = 2,
  • SkipExpressSettings = 4,
  • SkipOemRegistration = 8,
  • SkipEula = 16
CloudAssignedDomainJoinMethod This number is a required attribute and specifies the domain join method that should be used. Both hybrid AAD join and AAD join should be set to 0.
ZtdCorrelationId This GUID is a required attribute and specifies a unique GUID that will be provided to Intune as part of the registration process. This GUID can be used to group the devices in a dynamic Azure AD security group.
CloudAssignedTenantDomain This string is a required attribute and specifies the name of the Azure AD tenant that should be used.

How to use the offline deployment profile

The offline Windows Autopilot deployment profile can be used on Windows 10, version 1809, or later. The only other requirements are that the file is named AutoPilotConfigurationFile.json and that the file is available in C:\Windows\Provisioning\Autopilot\. Below are a few example processes that can be used to prepare a device with an offline Windows Autopilot deployment profile.

1 Manual copy the file to the required location and SYSPREP the device,
2 Use a USB-stick to install Windows and in the same process copy the file to the required location and SYSPREP the device.
3 Use MDT to install Windows and in the same process copy the file to the required location and SYSPREP the device.
4 Use Configuration Manager to install Windows and in the same process copy the file to the required location and SYSPREP the device.
5 Use a third-party product to install Windows and in the same process copy the file to the required location and SYSPREP the device.

How to group devices based on the offline deployment profile

The last thing that is good to mention, is that it’s also possible to group devices based on the fact that it was deployment via an offline Windows Autopilot deployment profile. Devices that are enrolled by using an offline Windows Autopilot deployment profile, will have the Azure AD device attribute enrollmentProfileName set to “OfflineAutopilotprofile-<ZtdCorrelationId>”. The ZtdCorrelationId is available in the offline Windows Autopilot deployment profile as shown and mentioned above. That would make a dynamic query for an Azure AD device group like this: (device.enrollmentProfileName -eq “OfflineAutopilotprofile-7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC”).

More information

For more information regarding offline Windows Autopilot profiles, please refer this article about Windows Autopilot for existing devices.

Block access to a device until specific apps are installed

ESP-BlockApps-TweetThis week a short blog post about a recently introduced feature in the Enrollment Status Page (ESP). The ability block access to a device until specific apps are installed. I also tweeted about that feature recently and I thought it would be good to document the use case, the configurations and the end-user experience.

Introduction

Let’s start with a short introduction. The ESP is strongly recommended with Windows Autopilot. The idea of the ESP, is to block the device until the device is ready for usage by the user. This new feature enables an administrator to only block the device until the most important apps are installed for the user. That enables the user to be earlier productive. The administrator simply chooses which apps are tracked on the ESP and until those apps are installed, the user can’t use the device.

With the recent updates to Microsoft Intune, the ESP can track the following apps:

  • Licensed Microsoft Store for Business apps;
  • Line-of-business apps (APPX, MSIX, single-file MSI)
  • Office 365 ProPlus apps

Note; Keep in mind that there are difference between the user context and the system context. For the exact up-to-date details see the links in section More information.

Configuration

Now let’s continue by looking at the available configuration options. The following three steps walk through adjusting the default ESP. Those steps will show which configurations are required to get to the available configuration options for tracking specific apps. Similar steps are applicable when configuring custom ESPs.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 On the Enrollment Status Page (Preview) blade, select Default > Settings to open the All users and all devices – Settings blade;
3a On the All users and all devices – Settings blade, select Yes with Show app and profile installation progress and Yes with Block device use until all apps and profiles are installed to enable the Block device use until these required apps are installed if they are assigned to the user/device setting (see step 3b);
3b When the Block device use until these required apps are installed if they are assigned to the user/device setting is enabled, select Select apps to open the Select apps blade. On the Select apps blade, select the required apps and click Select to return to the All users and all devices – Settings blade and click Save;
ESP-BlockApps-Config

Note: Keep in mind that if the ESP is configured to track Office 365 ProPlus apps, other large apps, or just many apps, it might be required to also increase the timeout as documented in this Support Tip.

End-user experience

Now let’s end this post by looking at the end-user experience. The good thing is that the user will not notice any big differences. The user will still get the same screens and the same experiences. Only users that pay attention to details will notice the small differences. As shown below, the user will see a list of apps that is equal to the number of configured apps by the administrator. That list is most likely shorter then it was before. That’s also the reason why the user might notice that it’s possible to get productive sooner, as the device will be available for use sooner.

ESP-BlockApps-EUE

More information

For more information regarding blocking devices until certain apps are installed, please refer to the following articles:

Hybrid Azure AD join with Windows Autopilot

This week is all about a very often requested feature, which is the ability to hybrid Azure AD join a device when using Windows Autopilot. The combination of the latest updates to Microsoft Intune with Windows 10, version 1809, provides just that! The ability to hybrid Azure AD join a device when using Windows Autopilot! In other words, the device will join the on-premises Active Directory and register in Azure Active Directory. In this blog post I’ll start with a short introduction about the hybrid Azure AD join with Windows Autopilot, followed by the most important configurations. I’ll end this post by looking at the experience.

Introduction

Let’s start with a little introduction about the hybrid Azure AD join through Windows Autopilot. A short summary would be that Intune uses an on-premises connector to create an offline domain join (ODJ) blob for the device that will be provided to the device during enrollment. Now lets go through the high-level Autopilot flow for this scenario and see how that fits.

  • The hardware ID of the device is registered with the Windows Autopilot service;
  • The device is sent to the employee and the employee unboxes the device and turns it on;
  • The device connects to the Windows Autopilot service;
  • The Windows Autopilot service delivers the Autopilot profile to the device;
  • The device performs a MDM-enrollment with Microsoft Intune;
  • Microsoft Intune will use the on-premises connector to generate a machine object in Active Directory, which will generate an ODJ blob;
  • The connector sends the ODJ blob to Microsoft Intune;
  • Microsoft Intune sends the ODJ blob to the device;
  • The MDM-enrollment is completed;
  • The user logs on to the device to complete the domain join;
  • The device receives any targeted group policies;

Configuration

Now let’s continue by looking at the configurations that are required to enable the hybrid Azure AD join scenario via Windows Autopilot. I’ll do that by going through the new Intune-related configurations. That means, I’ll show how to install the Intune connector, I’ll show how to configure the Autopilot deployment profile and I’ll show how to configure the domain join profile.

Requirements

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

  • The hybrid Azure AD join environment configurations must be in place;
  • The device must run Windows 10, version 1809 or later;
  • The device must have Internet access;
  • The device must have direct access to Active Directory;
  • Automatic enrollment must be configured (Azure AD > Mobility (MDM and MAM));
  • The server hosting the Intune connector must have delegated permissions to create computer accounts in the specified OU;
  • The server hosting the Intune connector must be Windows Server 2016, or later;
  • The server hosting the Intune connector must have Internet connectivity;

Intune connector

The first configuration that should be in place is the installation of the Intune connector. Multiple connectors can be installed to increase scale and availability (or even to support multiple Active Directory domains). The following nine steps walk through the steps to install the Intune connector.

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 Intune Connector for Active Directory (Preview) to open the Intune Connector for Active Directory (Preview) blade;
3 On the Intune Connector for Active Directory (Preview) blade, select Add connector to open the Add connector blade;
4 On the Add connector blade, click the Download the on-premises Intune Connector for Active Directory to download the connector for Active Directory (ODJConnectorBootstrapper.exe);
5 On the server that should be running the Intune connector for Active Directory, run ODJConnectorBootstrapper.exe;
6 On the Intune Connector for Active Directory Setup dialog box, select I agree to license terms and conditions and click Install;
7 On the Intune Connector for Active Directory Setup dialog box, after the installation completed, select Configure Now ;
8 On the Intune connector for Active Directory dialog box, select Sign In to sign in with a global administrator account to enroll the connector in the tenant and close the dialog box;
9 Back on the Intune Connector for Active Directory (Preview) blade, it should now show an entry for the added connector with the name of the server that is running the connector;
ICforAD

Note: At this moment, make sure that a language pack is installed and configured as described in the Intune Connector (preview) language requirements.

Autopilot deployment profile

The second configuration that should be in place is the Windows Autopilot deployment profile. The following four steps walk through the steps to create the deployment profile. That deployment profile can be assigned to an Azure AD group that contains the required Autopilot 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 WADP-HAADJOn 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 User-Driven, as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Select Hybrid Azure AD joined (Preview), as that will trigger the on-premises domain join with device registration in Azure AD;
  • Out-of-box experience (OOBE): See 4b

Note: The hybrid Azure AD join is only available for user driven deployments.

4b

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

  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot hybrid Azure AD join experience;

  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot hybrid Azure AD join experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot hybrid Azure AD join experience;
  • User account type: Select Standard to only make any user on the device a standard user;
  • Apply computer name template (Windows Insider Only): Not applicable, as the computer name standard is defined in the Domain Join profile (see next section);
WADP-HAADJ-OOBE

Domain Join profile

The third configuration that should be in place is the domain join profile. The following four steps walk through the steps to create the domain join profile. That domain join profile can be assigned to an Azure AD group that contains the required Autopilot devices.

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 domain join profile;
  • Description: (Optional) Provide a description for the domain join profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Domain Join (Preview);
  • Settings: See 3b;
3b On the Domain Join (Preview) blade, provide the following information and click OK;

  • Computer name prefix: Provide a computer name prefix. The remaining characters of the 15 characters of a computer name will be random;
  • Domain name: Provide the domain name that the device will join;
  • Organizational unit: (Optional) Provide the OU that the computer account is created in;
WADP-HAADJ-DJP

Note: When no OU is specified, the well known computer object container is used.

End-user experience

Let’s end this post by looking at the end-user experience. The beginning of the out-of-box-experience (OOBE) is similar to any other Windows Autopilot deployment. The difference is happening in the background, as explained during the introduction, and can be noticed during the Network configuration. The configuration will take longer than with a Azure AD join. Another thing that an administrator might notice is that the device will be available within Intune before it’s available within the Active Directory. That makes perfect sense as the domain join profile must come via Microsoft Intune.

WADP-HAADJ-CORP

Note: From an administrator perspective the Event Viewer, on the server running the connector, will show Event ID 30140 in the log ODJ Connector Service from the source ODJ Connector Service Source, with a successful creation of the computer object.

More information

For more information regarding Windows Autopilot and hybrid Azure AD join, 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!

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.