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!

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.

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.

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.

Create a local user account 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, which is currently available as Insider Preview build.

This week is all about creating local user accounts via Windows 10 MDM. That can for example make life a bit easier with troubleshooting an offline device. A fallback account. In this post I’ll show how this can be achieved by using the Accounts CSP. I’ll show the available nodes and I’ll show how to configure them. I’ll end this post by showing the end-user experience. Also, spoiler alert, it’s good to note that this is not a pretty administrator experience at this moment, but I’m pretty sure that will be fixed when it’s a built-in configuration in Microsoft Intune.

Overview

Let’s start by having a look at the tree of the Accounts CSP.

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 user accounts, 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;
  • Users – Defines the interior node for the user account information;
  • [UserName] – Defines the username of the new local user account;
  • Password – Defines the password for the new local user account;
  • LocalUserGroup – Defines the local user group for the new local user account.

Configurable nodes

There are basically two configurable nodes related to the creation of a local user account. The Password node and the LocalUserGroup node. The [UserName] node should contain the username and can be anything. The table below provides an overview of the configurable nodes.

Node Value Description
Password

String

This required setting allows the administrator to set the password for the new local administrator account.
LocalUserGroup Integer
1 – (Default) Users
2 – Administrators
This optional setting allows the administrator to control the local user group of the new local administrator account.

Note: The password value can be any valid string and is visible as plaintext in the Azure portal.

Configure

Now let’s continue by having a look at the required and optional configuration to create a local user account on the device. In other words, create a device configuration profile with the previously mentioned custom OMA-URI settings. 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 and 3c.
3b

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

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Users/TestUser/Password;
  • Data type: Select String;
  • Value: P@ssw0rd!.
3c

LU_GroupOn 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/Users/TestUser/LocalUserGroup;
  • Data type: Select Integer;
  • Value: 2.

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’s actually not that much to be shown. Only the created account. Below on the left is a screenshot of the default configuration of the created user account, including the full name, and below on the right is a screenshot of the group memberships of the created user account.

TestUser01 TestUser02

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

More information

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