Today is a blog post about Windows Autopilot device preparation and registering the Windows corporate device identifiers.
Many companies these days use Microsoft’s Windows Autopilot solution to enroll their corporate devices in Microsoft Intune. For this solution we need to register the devices by uploading the hardware hash to the Autopilot service.
The big OEMs provide a solution to handle the registration of the newly purchased devices for their customers so that we don’t have to manually upload the hashes to our tenants.
With the earlier announced Autopilot Device Preparation solution, registering these hardware hashes is no longer necessary. We only need to register the Corporate Device Identifiers and we’re good to go. This is a big approvement, certainly when devices are repaired and must be registered again.
But for new devices, I like that our OEM does the registration of our devices, and I don’t need to take care of this process. For the new device preparation, I might get an overview of the devices we ordered, and then I need to prepare a sheet that I can upload to Intune to perform the device registration.
I don’t like that idea, thus I thought about creating an automated way to upload the device identifiers to our Intune tenant, which I share in this blog post.
The solution in short
My thought is that we will receive an Excel sheet with information about the ordered devices, including manufacturer, model, and serial number. That information is enough to register the devices in Intune for device preparation.
If we receive that information in a mailbox (as an attachment), we can create a Logic Apps flow with permission to read e-mails from that mailbox and trigger the flow when an e-mail is received.
Depending on the type of Excel sheet and if it already contains a table, we first might need to store the sheet on SharePoint to add a table to it or can directly process the information of the sheet.
We pull the needed information out of the sheet, put it in a Graph call, and via Microsoft Graph we register our devices in Intune.
We can add some error handling in the flow, by checking the registration status of our device and sending an e-mail to our IT department if the registration fails.
It’s as simple as that 😊
This whole flow is just an example of automatically registering the identifier. If you, for example, receive such a sheet via another way, you can save the sheet yourself on SharePoint and start the flow at that part of the flow.
Requirements
We have some requirements that need to be in-place before we start creating our Logic Apps flow.
We need a (service) account with permission to the mailbox in which we receive the Excel sheet (and depending on if you also want to use that same mailbox to send error messages, don’t forget to assign that permission as well ).
We need to (temporarily) store the Excel sheet on SharePoint, thus the account needs permission to store a file in a SharePoint library.
To register our devices for Device Preparation via Microsoft Graph, we need to have permission to do that. There are different options to authenticate to MS Graph and assign permissions, but I prefer an Azure Managed Identity.
The required Graph (Application) permission to retrieve the EPM elevation request is:
DeviceManagementServiceConfig.ReadWrite.All
Setup the Logic App flow
When the requirements are in place, we can start building our solution.
Sign in to the Azure portal and open the Logic App service. Create a Logic App of type Consumption.
When the Logic Apps is created, we first assign the Managed Identity. This is done on the Identity tab, under Settings.
Browse to the Overview tab and click on Edit.
The first thing we need to add to the flow is a Trigger.
With the trigger, we configure what triggers the flow to start. In this case, an e-mail is received (in a shared mailbox) which should trigger the flow, thus we choose When a new email arrives in a shared mailbox.
We need to sign in with an account with permissions on the mailbox.
We need to specify the Original Mailbox Address, which is the mail address from the mailbox in which the e-mails are delivered with the attachment that contains the device identifiers.
We can also specify the From address and Subject filter. By filling in this information we would avoid processing e-mails that do not contain device identifiers.
And as last we configure the Recurrence. In the recurrence, we configure how often the flow runs to check on new e-mails.
Next, we add our first action by clicking the plus sign under the trigger. We need to (temporarily) store the attachment on SharePoint, to add a table to the file. For this, we add a Create file action, which can be found when we search for SharePoint.
Also, for the SharePoint action, we need to sign in with our service account.
After we are signed in, we need to select the Site Address from the site on which we store the attachment. In case the site address isn’t shown in the drop-down list, we can manually copy the address after we select Enter custom value.
Besides the Site address, we need to select a Folder Path.
We need to add the attachments File name and File Content. We do this by selecting the lightning sign, after which we can select the items.
Search for attachments and select Attachments Name. Do the same for Attachments Content.
Our Create file action is added to a For each action. This is automatically done because, in theory, there could be multiple attachments added to the e-mail.
We need to create a table in the Excel file, for that, we add a Create table action. This is an Excel action.
Select the location and document library, and add the ID of the Create file action in the File field.
We also need to add a table range. Which range depends on the number of columns the table needs to store its data in and how many rows are expected to be filled maximum. My table will be limited to three columns and I set the number of rows to 100. Empty rows will be removed by the flow later.
As last, we need to add Column names, which should match the names in the sheet received from the vendor.
To make use of the data in the sheet, we need to use a List rows present in a table action.
Select the Location and Document library where the sheet is stored. We need to add the ID of the file to the File field to identify the previously created file. Search for ID (via the lightning icon) in the list of dynamic content. Do the same for the Table name.
As written above, we filter out the empty rows in the flow. This can be done with a Filter array action, which is a Data Operations action.
Add value of the List rows action to the From field.
In the left field under Filter query we add Manufacturer via an Expression. For this select the fx button next to the left field and add this expression:
item()?[‘Manufacturer’]
This will select the manufacturer column and add that data to the left field when running the flow.
From the drown-down list select is equal to and leave the right field empty.
Until now we have processed the data we received as an attachment from our vendor in an Excel sheet, added a table, and removed the empty rows. If we want to import the Corporate device identifiers to Intune, we need to select the information (values) from the data we currently have in our flow and prepare these values for importing.
We pull out these values with a Select action, which is again a Data Operations action.
In the From field, we add Body which can be selected from the dynamic content list (lightning icon). To be able to further process the data we need to select values and map these. In the left field enter Manufacturer, in the right field, we add an Expression like we used in the Filter array action.
Add the same expression as in the Filter array action;
item()?[‘Manufacturer’]
Repeat these steps for Model and Serial;
item()?[‘Model’]
item()?[‘Serial’]
The last step before we can import the identifiers is parsing the output of the select action.
For this, we add a Parse JSON action to our flow.
Add Output to the Content field.
The schema we need to add can be written by ourselves, but it’s much easier to use a sample payload. We can get this sample payload by running the flow once (without the Parse JSON action) and selecting the output from the Select action (see the run history for this).
Add this to the Parse JSON action via the example payload option.
This will create the schema for us, and this is our action.
The first part of our flow is ready!
Setup the Logic App flow – part 2
We’re finally adding the action that will import our device identifiers. We use an HTTP action for this.
Add the HTTP Action to the flow.
Select POST as Method.
Next, select Authentication under Advanced parameters
As Authentication type select Managed identity.
Select your Managed identity from the list.
And add https://graph.microsoft.com as Audience.
Add this URI to the flow;
https://graph.microsoft.com/beta/deviceManagement/importedDeviceIdentities/importDeviceIdentityListAdd this information to the Body field;
{
"importedDeviceIdentities": [
{
"importedDeviceIdentifier": ",,",
"importedDeviceIdentityType": "manufacturerModelSerial"
}
],
"overwriteImportedDeviceIdentities": false
}We need to add the Manufacturer, model and serial number to the body as this is the information we need to import corporate device identifiers.
We add this information by using dynamic content. These dynamic content values come from the Parse JSON action and need to be separated by commas.
Adding those values automatically adds the HTTP action to a For each action.
I want to add a control mechanism to the flow to check if the identifier is registered successfully. But it takes some time to register the identifier, therefore I add a Delay action to the flow. The delay action delays the flow from moving to the next step. During my testing, adding a delay of one minute was enough to check if the identifier was registered successfully after this time.
We add a second HTTP action to the flow, this one to search for the imported identity (identifier).
Select POST as Method and add Authentication under Advanced parameters again. Fill in the required authentication information.
Fill in this URI:
https://graph.microsoft.com/beta/deviceManagement/importedDeviceIdentities/searchExistingIdentitiesAdd this to the Body field:
{
"importedDeviceIdentities": [
{
"importedDeviceIdentifier": ",,",
"importedDeviceIdentityType": "manufacturerModelSerial"
}
]
}In the Body field, we add the dynamic content again for manufacturer, model and serial number.
After the HTTP action, we add a Parse JSON action. This makes it a little easier to check with the next action if the identifier is registered or not.
Add Body (of the HTTP action) to the Content field and use the example payload option to generate the scheme.
This is the second part of our flow until now.
To determine if the identifier is registered, we check if the value of the latest Parse JSON action is filled with data or is empty. When registration of the identifier failed, we would get no information back from the searchExistingIdentities query.
This is an example of a Parse JSON that returned no data. Value is empty.
We use a Condition action to check the value. We can check on the length of the value, if that’s not equal to zero, it returns data and the identifier is found.
We first add an Expression to the left field:
Length()
We can switch to the Dynamic content tab and select Body of the last Parse JSON action.
We need to select the value, to add this to the expression, we switch back to the Expression tab which now looks like this.
Add this to the expression before the last closed bracket sign:
?[‘value’]
From the drop-down menu, select is not equal to and add 0 to the right field.
I want to get informed when one of the corporate device identifiers is not registered. Therefore, I add an action to the flow under False to send a notification. The type of action could for example be one that sends a notification via Teams, but in this case, I choose one that sends an e-mail.
Add a Send an email from a shared mailbox action to the flow.
Fill in an Original mailbox address and To address. Fill in a Subject and text to the body field. We can use values from previous steps in the subject and text to make clear which identifier is not registered.
And we have the second part of our flow completed, thus completed our import solution!
End-result
When we now receive an e-mail from our hardware vendor with information about our ordered devices, those machines are automatically registered in Microsoft Intune. In this example my sheet contains two Dell devices that are automatically registered in Intune.
And in case the registration of a device fails, we receive an e-mail to inform us about the failure of the registration.
