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.

Automatically assign Windows AutoPilot deployment profile to Windows AutoPilot devices

This week another (short) blog post about Windows AutoPilot. More specifically, about automatically assigning a Windows AutoPilot deployment profile to Windows AutoPilot devices. That makes it a lot easier for administrators, as this prevents the administrators from potentially forgetting to assign the deployment profile to newly imported devices. Great improvement. Also, I have to say that this subject is documented pretty good, but it could be easier to find. This post is mainly for creating awareness regarding this subject. I’ll provide the options regarding to grouping Windows AutoPilot devices and I’ll show how those options can be used to create a dynamic group.

Options

Let’s start by having a look at the configuration options regarding the grouping of Windows AutoPilot devices. The imported Windows AutoPilot devices are pre-created in Azure AD and, during that creation process, a few values are automatically set for those devices. Below is an overview of those different values.

Value Devices Explanation
[ZTDId] All Windows AutoPilot devices A unique value assigned to all imported Windows AutoPilot devices
[OrderID]:{YourOrderId} All Windows AutoPilot devices with a specific order Id An optional Id that can be specified when importing Windows AutoPilot devices
[PurchaseOrderId]:{YourPurchaseOrderId} All Windows AutoPilot devices with a specific purchase order Id An Id that is set by the OEM when importing Windows AutoPilot devices

Those different values can be used to create dynamic device groups within Azure AD. Below is an overview of the required queries per grouping of Windows AutoPilot devices.

Devices Query
All Windows AutoPilot devices (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
All Windows AutoPilot devices with a specific order Id (device.devicePhysicalIds -any _ -eq “[OrderID]:{YourOrderId}”)
All Windows AutoPilot devices with a specifc purchase order Id (device.devicePhysicalIds -any _ -eq “[PurchaseOrderId]:{YourPurchaseOrderId }”)

Note: These values can be seen by simply using Graph Explorer, querying https://graph.microsoft.com/v1.0/devices and looking for the physicalIds value.

Configuration

Let’s continue by having a look at how to use these different values and queries for actually grouping all Windows AutoPilot devices. The following 3 steps walk through the creation of a dynamic device group that can use the different queries mentioned earlier.

1 Open the Azure portal and navigate to Intune > Groups or navigate to Azure Active Directory > Groups to open the Groups – All groups blade;;
2 On the Groups – All groups blade, click New group to open the Group blade;
3a

AAD_DD_GroupOn the Group blade, provide the following information and click Create.

  • Group Type: Select Security;
  • Group name: Provide a valid name for the group;
  • Group description: (Optional) Provide a description for the group;
  • Membership type: Select Dynamic Device;
  • Dynamic device members: See step 3b;
3b

AAD_DD_RulesOn the Dynamic membership rules blade, select Advanced rule, provide one of the mentioned queries (depending on the type of AutoPilot devices selection) and click Add query;

Note: The example on the right is showing the query for all AutoPilot devices.

Once the dynamic device group is created it can used for assigning Windows AutoPilot deployment profiles. That enables the administrator to automatically assign a Windows AutoPilot deployment profile to all Windows AutoPilot devices.

Result

Let’s end this post by having a look at the results. Below, on the left, is a quick overview, via Microsoft Graph, about the device information of CLDCLN879139238. That shows the name of the device and the value related to all imported Windows AutoPilot devices. Below on the right is an overview of that same device, showing it as a member of the earlier created dynamic device group.

AAD_DD_Example2 AAD_DD_Example1

More information

For more information regarding the latest Windows AutoPilot features and the configuration steps, please refer to the following articles:

Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

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

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Join us at Experts Live Netherlands in Ede

A bit more than a week from now, June 19, Experts Live Netherlands will be in Ede. Experts Live Netherlands is the biggest Microsoft community event of the BeNeLux, with over a 1000 visitors. Together with my finest colleague, Arjan Vroege, I will deliver a session about your ultimate hybrid workplace. And we hope to see you there!

EL_social_tempate_speakers_Arjan

About our session

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, MSIX and Azure AD Application Proxy. Make sure that you don’t miss this!

Additional giveaway

As my employer, KPN ICT Consulting, is one of the Gold Partners of Experts Live Netherlands 2018, we also have a partner session. During that sessions my colleagues, Arjan Vroege and Nicolien Warnars, will explain how we internally migrated to a Microsoft 365 workplace for over 12.000 users. Very interesting for organizations that are looking for a great reference case.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

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

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

App protection policies and device management state

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

Configuration

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

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

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

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

3b MAM-Android

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

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

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

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

Result

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

MAM-Policy-Overview

More information

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

Conditional access and guest users

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

Configuration

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

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

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

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

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

End-user experience

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

Screenshot_MFA Screenshot_Authenticator

More information

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

Rename a device via Windows 10 MDM

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

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

Overview

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

Available nodes

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

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

Configurable nodes

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

Macro Description
%RAND: <# of digits>%

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

Example: CLDCLN%RAND:6%

%SERIAL%

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

Example: CLDCLN%SERIAL%

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

Configure

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

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

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

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSI-CN-SerialOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Domain/ComputerName;
  • Data type: Select String;
  • Value: CLDCLN%SERIAL% (or use the other example of CLDCLN%RAND:6%).

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

End-user experience

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

CN-Serial-Properties CN-Serial-CMD

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

More information

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