Ignite 2018 – My wrap up

First of all, what an amazing experience to attend Microsoft Ignite 2018 in Orlando. All started off with a keynote by Satya Nadella followed by general announcement sessions and technical deep dive sessions. The key message was about “Tech Intensity”. This is described by changing your cultural mindset and your processes. Ultimately leading to a better digital transformation by tearing down silos in your organization and bringing teams and technology closer together. Creating close feedback loops to generate advantage of valuable insights. Technology will cover every aspect of our life sometime and it is time now to start to align yourself to this. Time to disrupt yourself, modernize your own business model. Everyone has to find ways to leverage technology to optimize their businesses otherwise others will have a significant advantage in a short amount of time. It’s time for a culture of adoption.

The biggest announcement for me as an Enterprise Mobility MVP is by far the Win32 app support in Microsoft Intune.


Microsoft delivers the functionality to wrap your apps (all kind of installers like setup.exe etc) in a container (zip) format and allows distribution via Intune. This is a game changer for Microsoft Intune as it was one of the missing parts and blocker for customers to fully adopted the modern management approach. Customers who are wiling to modernize and are going for a full modern management approach are now able to install their Line-of-business applications directly via Intune. This functionality is powered by the Microsoft Management Extension (see my deep dives Part 1 and Part 2) which was used for PowerShell script execution with Intune already in the past. I will provide some technical deep dive insights into the Win32 capabilities in the following days.

For Windows Autopilot they announced Hybrid Azure AD join and the capability to harvest Autopilot data. The Hybrid Azure AD join might be good for some people but I really encourage everyone to check out Azure AD join as it also supports accessing local AD resources with Kerberos authentication. Harvesting Autopilot information of existing devices in an easy way is great and simplifies the steps to a modern infrastructure where all devices even in a reinstall/reset scenario are using a simplified setup powered by Windows Autopilot. For Intune they delivered great Sessions regarding the availability of Intune Security Baselines and Desktop Analytics. The Intune Security Baselines are provided to fill configuration gaps which companies currently see when transitioning from a local AD and Group Policy environment to a Azure AD/MDM environment. The goal is to have all required security settings available in the MDM environment to easily transition. In addition to the Security Baseline settings, Intune gets support for Administrative Templates to further simplify the configurations of policy settings for Office and Windows. It frees us to handle the complex way of admx ingestion by providing the most needed settings in the portal. Not only the settings administration is made simple they also released the Intune PowerShell SDK to easily automate tasks within Intune. With Desktop Analytics we get tighter integration of the telemetry data from Windows Analytics into Intune to build piloting rings based on telemetry to ensure good coverage of your LOB apps in the piloting rings.

A lot of changes happening in the IT world right now and Microsoft builds out his platforms to be even more mature to support us in every aspect. This starts with the Microsoft 365 story by bringing real cross platform functionality like Information Protection availability in every product like Outlook, Word etc. for Windows, iOS/macOS, and Android. They also announced the OneDrive feature “Files on Demand” for macOS now. There is a very big focus on Security on everything what Microsoft is doing right now. More than 3500 full time security professionals are working at Microsoft to power the security platforms also with the help of AI to generate insights for the Intelligent Security Graph. To fight the world of passwords they announced Azure AD password less sign-in. A very good simplification of the portals is coming up also to provide consistency in the handling. This simplification includes a common URL scheme like devicemanagement.microsoft.comadmin.microsoft.com, security.microsoft.com, or compliance.microsoft.com. Even a Windows Virtual Desktop in the cloud was announced. Another highlight to mention is that Microsoft will bring up a new offer called Microsoft Managed Desktop where Microsoft will completely manage your devices. In the Office world we got Microsoft Ideas which helps you to find great layouts and even the interesting data in your Excel spreadsheet powered by AI.

Beside these great announcements I’ve taken the chance to meet with a lot of the Product Group members and had great conversations with them. Also I met a lot of my fellow MVPs which was a great experience. Really looking forward for the next one in Orlando at November 4-8. If you like to pre-register follow this link.

See you in Orlando next time! 👍



Automation of gathering and importing Windows Autopilot information

Complete process automation of gathering and upload of a device Autopilot information to the Windows Autopilot service with an Azure Automation Runbook.

On one of my previous blog post Gather Windows 10 Autopilot info in azure blob storage during wipe and reload, I described the gathering of Autopilot information during operating system deployment in a wipe and reload scenario with MDT. Just a short recap of the problem and my initial solution:

If we purchase a new device, the OEM vendor takes care of installing Windows 10 with a signature edition or provisioning ready installation including all necessary drivers. If we buy new hardware the information for Autopilot can be synced into our tenant from the OEM vendor (Lenovo is already capable of doing that and others will follow). We will get the device information in Intune and we can start to assign an Autopilot Deployment Profile and start to enroll the devices.

What if we have a bunch of Windows 7 devices in the environment?

A way to handle this is that we are playing the role of the OEM vendor and do the install of a Windows 10 signature edition on the existing Windows 7 devices, gathering Autopilot information, and let Windows 10 start in the Out of Box Experience (OOBE) again for user enrollment. Depending what is available we can use ConfigMgr or MDT for this. My example uses MDT.

Now imagine a situation where a rollout team is preparing a lot of machines. We would end up in a lot of .csv files on different devices. To make this a little easier for IT to import the hardware information of new devices into the Autopilot service, we build up the following logic:

  1. Gather hardware information via PowerShell Script Get-WindowsAutoPilotInfo during wipe and reload
  2. Upload .csv file via AzCopy to an Azure Blob Storage
  3. Gather .csv files from Azure Blob Storage and combine them into a single combined.csv file
    This was a manual step in my previous solution
  4. Upload combined .csv file to Autopilot and assign Deployment Profiles
    This was a manual step in my previous solution
  5. Device can be delivered to the end user like it where shipped by the OEM vendor

You can read more about the initial solution here: Gather Windows 10 Autopilot info in azure blob storage during wipe and reload

This blog post is all about automating these two steps – gathering and upload of Autopilot information to Intune.


First, I will explain the architecture and how it works and then I’m going to describe the way to implement it. The overall architecture is based on an Azure Automation Runbook and looks like this:


The new procedure including the enhanced logic for a complete automation of the import is now as follows (modified steps for complete automation):

  1. Gather hardware information via PowerShell Script Get-WindowsAutoPilotInfo during wipe and reload scenario
  2. Upload .csv file via AzCopy to an Azure Blob Storage
  3. Gather .csv files from Azure Blob Storage and combine them into a single .csv file with the help of a scheduled Azure Runbook
  4. Upload combined .csv file information to Windows Autopilot Service via PowerShell Script WindowsAutoPilotIntune running in an Azure Automation Runbook 
  5. Cleanup Azure Blob Storage (delete all .csv files of successfully imported devices and delete all .csv files of already imported devices)
  6. Generate import notification and summary and post it to a Microsoft Teams channel
  7. Autopilot information is available for the OOBE user enrollment scenario with Autopilot. The Autopilot profile gets automatically assigned by a dynamic AzureAD device group membership.
  8. Device can be delivered to the end user like it where shipped by the OEM vendor

I’ve still chosen the copy via AzCopy of individual .csv files to the Azure Blob Storage approach as we can then limit the access quite well via shared access signature and we can easily limit permission to write blob objects only. No need to provide credentials or Blob Storage keys on the client side. Sure, we could build up a more advanced HTTP endpoint to gather device information, but this approach is quick and simple. I’m pretty sure that the complete solution of this automation task is something which we do not need in future when devices are Windows 10 migrated and we then buy Autopilot ready hardware only.


Guide to build the new solution

The Autopilot Graph API is an API with focus on batch processing. This means we import new device information into a kind of staging area and Windows Autopilot service will pick up the new device information and starts importing it. This process varies in the amount of time it takes and we have to check the status of all devices to get the import result. As soon as the devices are processed we can clean up the staging area and the import is done. Normally we would do this by wrapping the Graph API calls (REST) into some PowerShell functions and build the logic for the described process. Luckily Microsoft released a new PowerShell Module WindowsAutoPilotIntune (thx to @mniehaus) based on the Graph API to import new AutoPilot information into Intune.

In my previous blog post about Process automation for Intune and Azure AD with Azure Automation, I created a Runbook to delete old devices from Intune via Graph API and demonstrated how to do an unattended authentication within the Runbook. All the details how this can be achieved are explained there. Please follow the guide to setup the Azure Automation account. I use the same unattended authentication technique to utilize the PowerShell Module WindowsAutoPilotIntune to import the device information into Autopilot service in the following Runbook. Additionally, the Runbook is built to protect concurrent execution (thx to Tao Yang, I used his implementation for it) to ensure a sequential processing and to keep track of current running imports. If we would design this as a concurrent solution it would get much harder in terms of monitoring and reporting in the end. In addition, there is a max import of 175 devices into the staging area of the API which we are taking care of by limiting the Runbook import to 175 devices during one run.

If the requirements are implemented based on the previous blog post (especially the Intune native app and the automation service account) we simply need to extend the permissions to “Read and write Microsoft Intune configuration” of the automation account which was created during the setup of Process automation for Intune and Azure AD with Azure Automation in section Building the solution.


For the concurrent execution protection, we need our automation credential to have Reader permission and for Blob Storage access we need Contributor permissions on the subscription. As the result we grant Contributor permission to the automation account:


Finally, we can implement the complete Runbook which can be found on my GitHub account here:


The Runbook is written in PowerShell and follows the logic described in the beginning of this post – section architecture.

Create a PowerShell Runbook and paste-in the code.



To make sure the Runbook successfully runs we need to define some additional variables. I assume that the IntuneClientId and Tenant variable are defined as described in the previous blog post.


Additional variables needed for Azure Blob Storage access:

ContainerName: <your-blob-storage-containername>
StorageKey: <your-blob-storage-secret-key> * as encrypted variable

Additional variables needed for Microsoft Teams Channel notification:

SubscriptionUrl: <your-subscription-url>

The subscription URL can be found as shown below. Please do not copy the /overview end of the URL. The URL should end with the subscription GUID only (like highlighted):


TeamsWebHookUrl: <your-ms-teams-webhook-url>

Open MS Teams and choose a Channel where the Autopilot notification from the Azure Runbook should be displayed. Click on the three dots and choose Connectors:


Look for Incoming Webhook and click Configure


Type in the details and upload a icon and click Create


Finally copy the Webhook URL:


Paste it into the Azure Automation variable TeamsWebHookUrl and set encrypted value to Yes


This is necessary to get Microsoft Teams notifications with some statistics and information to troubleshoot errors. Below is an example of an import notification in Microsoft Teams:


We have some statistics, detailed error list with device information and a link to the Runbook itself in Azure. All based on Adaptive Cards JSON code. This can be easily modified to fulfill personal needs. Have a look at the Adaptive Cards Designer (https://acdesignerbeta.azurewebsites.net) for experimenting with layouts and adjust the Runbook code.


Enhanced client-side script part

I my previous blog post about Gather Windows 10 Autopilot info in azure blob storage during wipe and reload I have described how to setup the Azure Blob Storage to gather the “<hostname>.csv” files during MDT operating system installation. Please follow the previous guide to setup the Azure Blob Storage and the integration in MDT.

I have an enhanced version of the gather script now which can be found on my GitHub account and is also shown below. The enhanced version does not have the dependency on AzCopy.exe (incl. dependency files) and Get-WindowsAutoPilotInfo.ps1 in the script directory. If they are not available, they are downloaded from an additional Blob Storage container named resources. The additional container resources must be created and the AzCopy.zip and Get-WindowsAutoPilotInfo.ps1 must be uploaded there to successfully run the script:



The enhanced Get-WindowsAutoPilotInfoAndUpload.ps1 version:

Replace ZZZZ with your Blob Storage account name and ZZZZ with your SAS signature in the script above. See here Delegating Access with a Shared Access Signature for more SAS signature details.

This version can also be used to be executed via Microsoft Intune Management Extension to run it on existing Windows 10 devices. It is possible to collect all targeted device information and the Runbook will import the device information. Already imported devices will be skipped. This way we can make sure every device is imported to the Autopilot service.



Sample output of the Runbook


If a device information <hostname>.csv is successfully imported the .csv files will be deleted from the Azure Blob Storage. In case of an error it will be left there untouched but reported via Runbook output and Teams notification. There is one case where the Runbook will delete the .csv file from the Azure Blob Storage also. This is if the Runbook detects an error 806 – ZtdDeviceAlreadyAssigned. In that case we can delete the .csv as it has no consequences. In every other error situation someone needs to resolve the error manually. The Teams notification is only generated if there is some device information in the Azure Blob Storage. The normal procedure would be if operations gets an import notification it should check and in case of errors they should be resolved manually.



Important observations during testing

The Autopilot import via Graph API takes some time and it may also timeout. So, it is not a typical request response REST API in this case. Remember all device information is staged and then the devices are monitored for their success or error state. This led to situations where I had to wait up to 1 hour to get a successful import, even when the UI in Intune tells us it takes up to 15 min. So be prepared that it might take longer or fails during the run. I chose this approach as it is the same procedure as the Azure Portal does the import. In fact, we really automated the import process in Intune but did not invent a complete different process which might cause different problems of device tracking or concurrency and so on. Depending on the use case you can run the Runbook on a recurring schedule. My normal use case for this scenario is to support people who are preparing older devices when they are getting reinstalled from Windows 7 to Windows 10. If someone expects immediate availability of Autopilot information after such a reinstall this might be problematic as the API is not designed for this. Another fact is that the Autopilot Deployment Profile assignment using Intune does take some time also at the moment. I observed that it took several hours sometimes. I suggest to re-arrange the operational processes and hand out reinstalled Windows 10 devices after some additional time and not directly after reinstalling, as this increases the possibility that the Autopilot information is not imported and profile assigned yet.

To run the Runbook on a recurring schedule just go to the Runbook and add a schedule. The max recurrence is limited to every hour.


Just define a schedule (max once per hour) and monitor the recent job overview if it works:


The schedule can even be enhanced by using a simple Logic App and not using the Azure Automation Runbook schedule at all:


Please see Stefan Strangers post for detailed instructions how to implement a simple Logic App to trigger an Azure Automation Runbook:


In case something goes wrong I have created a second Runbook to clean up the staging area of the Autopilot Graph API. Get it from my GitHub account and run it in case of fatal errors where you might want to clean up the staging area:


Here is a sample output of the Cleanup Runbook:


Further information

Azure Logic Apps – Schedule your Runbooks more often than every hour

Preventing Azure Automation Concurrent Jobs In the Runbook

Post notifications to Microsoft Teams using PowerShell

importedWindowsAutopilotDeviceIdentity resource type

Autopilot profile assignment using Intune

Adaptive Cards Designer

I published the same article on SCConfigMgr in a more step-by-step guide version, meaning there are not so many cross references to my other articles:

Automation of gathering and importing Windows Autopilot information


I hope this can increase your throughput on the way to an Autopilot Windows 10 modern management environment.

When someone finds bugs or problems with the solution let me know and leave a comment. I will do my best to fix them as it should be a reliable part during preparing old devices with Windows 10.

How to “Push-button reset” Windows 10

The “push-button reset” (PBR) is the way to do a “factory reset” on Windows 10. It constructs a fresh Windows 10 installation and we can start over again.

Implementing a Microsoft 365 powered device mobility concept for a modern workplace with Windows 10, makes usage of Windows as a Service and provides new ways of self enrollment. Wherever we are, we service the OS from the cloud (Windows Update for Business) and manage it from the cloud (Intune).

In case of failure there are primarily two options:

  • Get a new device and enroll the device to Azure AD again
  • Start push-button reset to run a factory reset and start over again

In case of failure or if we want to re-purpose the device (back into stock or hand over to another employee) we use the push-button reset in this concept.


How is push-button reset triggered from the client?

First of all we need to distinguish between a device where the user is local administrator and a device where the user is standard user.

In case of local administrator the push-button reset can be triggered from Settings > Update & Security > Recovery > Reset this PC > Get started

PBR Settings Local Administrator

As shown there are two options available:

  • Keep my files
  • Remove everything

When choosing “Remove everything” we have the following two additional options:


Be aware if “Remove files and clean the drive” is chosen it will really take a long time to complete!


In case of standard user we do not have the reset option in settings available. This is relevant when using AutoPilot and a profile with “Disable local admin account creation on the device” as shown below:


As a standard user the settings are shown with no reset option in the recovery menu:


For Microsoft 365 powered devices managed by Intune we can deploy the Company Portal and use it to trigger the reset. Open the deployed Company Portal > choose device > … (menu in the upper right) > Reset




How is push-button reset triggered from Intune?

We need to open the Intune portal portal.azure.com and navigate to Intune > Devices > All Devices > pick the particular device > Factory reset


as shown in the screenshot there is the additional option to “Retain the enrollment state and user account”.

For detailed description what is retained please refer to: https://docs.microsoft.com/en-us/intune/devices-wipe#factory-reset

If the device is on and connected, it takes less than 15 minutes for a factory reset command to propagate across all device types.


What is the “Fresh Start” available in Intune?

The Fresh Start device action removes any apps that were installed on a Windows 10 PC running the Creators Update, then automatically updates the PC to the latest version of Windows. This can be used to help remove pre-installed (OEM) apps that are often delivered with a new PC. You can configure if user data is retained when this device action is issued. In this case, apps and settings are removed, but the contents of the users Home folder are retained.



If the device is on and connected, it takes less than 15 minutes for a factory reset command to propagate across all device types.


Reset in Action

When a reset is triggered the device will end up rebooting and the reset will occur.


After finishing the reset the device will start in OOBE again for new enrollment or at the logon screen when enrollment was retained.


Issues with Lenovo devices and the troubleshooting

During tests I observed Lenovo devices which ran into an error after resetting and starting into OOBE again. Shortly after language and keyboard selection I got this:


After some debugging I found out that the license.rtf file was not available in C:\Windows\System32 and this blocked the OOBE from displaying the EULA and resulted in the “Something went wrong” error screen. Click on “Try again” generated a loop.

I could solve this problem with a small customization of the PBR. The PBR has options to add a script to the PBR routine. More details see here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-script-to-push-button-reset-features

I prepared a script which copies the license.rtf file back to C:\Windows\System32 folder if it is missing after the reset. We need to prepare 2 files and we need the license.rtf from a running Windows 10 device.


rem EnableCustomizations.cmd

rem Define %TARGETOS% as the Windows folder (This later becomes C:\Windows)
for /F "tokens=1,2,3 delims= " %%A in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RecoveryEnvironment" /v TargetOS') DO SET TARGETOS=%%C

rem Define %TARGETOSDRIVE% as the Windows partition (This later becomes C:)
for /F "tokens=1 delims=\" %%A in ('Echo %TARGETOS%') DO SET TARGETOSDRIVE=%%A

rem Add back license.rtf file if missing
IF NOT EXIST "%TARGETOS%\System32\license.rtf" (
copy "%TARGETOSDRIVE%\Recovery\OEM\license.rtf" "%TARGETOS%\System32\license.rtf" /y
exit /b 0


<?xml version="1.0" encoding="utf-8"?>
<!-- ResetConfig.xml -->
 <Run Phase="BasicReset_AfterImageApply">
 <Run Phase="FactoryReset_AfterImageApply">

In the end copy EnableCustomizations.cmd, ResetConfig.xml and the license.rtf to the folder:


After deploying the custom PBR fix for the Lenovo devices the push button reset runs smoothly.


Further information

Remove devices by using factory reset or remove company data

Push-button reset

Add a script to push-button reset features


Happy resetting!


Gather Windows 10 Autopilot info in Azure Blob Storage during wipe and reload

UPDATE 22/07/2018: New blog post Automation of gathering and importing Windows Autopilot information

The Modern Management strategy is based on Enterprise Mobility + Security and additional services like Office 365. Microsoft created a new SKU called Microsoft 365 for this. To complete the big picture we need some additional services:

The idea is clear, manage the Windows 10 devices like mobile phones. No more Operating System Deployment (OSD) just provisioning and management from everywhere. Everything is powered by the cloud.

A new member in this story is a feature called Windows Autopilot. You can compare this with the Device Enrollment Program as you might know from Apple. It provides a managed way of provisioning with near zero touch. IT is able to control the experience the end user will have during enrollment process. To make all this work we need to gather some properties of the device to identify it clearly. The Autopilot needs the Device Serial Number, Windows Product ID and the Hardware Hash. This information is uploaded to the Autopilot service and then the device will be recognized during OOBE as an Autopilot device, and will show a customized enrollment experience.

The Problem

Many organizations are still using Windows 7 and are on it’s way to Windows 10.  Windows 10 is the new “baseline” in this story. It’s aligned with the complete modern management story. It provides the capability to join Azure AD and the usage of a Windows as a Service model.

How do we get to the new baseline?

If we purchase a new device, the OEM vendor takes care of installing Windows 10 with a signature edition and all necessary drivers. In future the hardware information will be synced into our tenant from the OEM vendor. We will get the device information in Intune and we can start to assign an Autopilot Deployment Profile and start to enroll the device.


What if we have a bunch of Windows 7 devices in the environment?

A way to handle this is that we are playing the role of the OEM vendor and do the install of a Windows 10 signature edition on the existing Windows 7 devices. Depending what is available we can use ConfigMgr or MDT. In the context of modern management I like to keep on-premises software as low as possible. I use MDT for that simple task now. If ConfigMgr is available we can build the following the same way.

I use MDT to create a Deployment USB media (removable drive) for that and build up a Standard Task Sequence to deploy Windows 10 for this. We take care of the right drivers and in the end we let the device start the OOBE again (sysprep.exe /oobe /reboot|shutdown). Now we have the same situation like a newly delivered device by the OEM vendor. But we can’t deliver the hardware information directly into our tenant like the OEM vendor will do in the future. Good to know that we can get the hardware information with the PowerShell Script Get-WindowsAutoPilotInfo and upload the information provided via a .csv file our self.

Now imagine a situation where a rollout team is preparing a lot of machines. We would end up in a lot of .csv files on different USB removable drives. To make this a little easier for IT to import the hardware information of new devices to Autopilot, we build up the following logic:


First of all we prepare the Blob Storage for easy csv file storage.

Login to Azure portal and click on “Storage accounts


Click Add


fill out name, Account kind: Blob storage


after creation you should see the storage account


create a container called hashes


create a shared access signature for Blob | Write | an extended expiry date/time | HTTPS only and create a SAS token. Shared Access Signature is used to limit the permission and the limit the period of time to access the account. See Delegating Access with a Shared Access Signature


Copy the SAS token as we need it in the following script.

Download PowerShell Script Get-WindowsAutoPilotInfo and AzCopy. Install AzCopy and get the files from here: C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy

Copy AzCopy files and Get-WindowsAutoPilotInfo.ps1 into MDT share e.g. C:\DeploymentShare\Scripts\CUSTOM\HardwareInfo

Create PowerShell script: Get-HardwareInformation.ps1 and copy to the MDT folder HardwareInfo as well. Replace the SAS token (ending with XXXX) in the script example with the newly created one. Replace ZZZZ with your Storage account name.

The script will look for the Get-WindowsAutoPilotInfo.ps1 script, executes it and creates a computername.csv file in C:\Windows\Temp. From here it will be copied to the blob storage account and copied to the USB removable drive folder autopilot-script-success or autopilot-script-failed. This provides the chance in case of failure (missing internet access during deployment) that the computername.csv can be gathered from the USB drive as well.


# Author: Oliver Kieselbach
# Date: 11/15/2017
# Description: Generate AutoPilot .csv file and upload to Azure Blob Storage.

# The script is provided "AS IS" with no warranties.

# Downlaod URL for AzCopy:
# http://aka.ms/downloadazcopy

# Downlaod URL for Get-WindowsAutoPilotInfo:
# https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo

Function Execute-Command
 Param([Parameter (Mandatory=$true)]
 [Parameter (Mandatory=$false)]

$pinfo = New-Object System.Diagnostics.ProcessStartInfo
 $pinfo.FileName = $Command
 $pinfo.RedirectStandardError = $true
 $pinfo.RedirectStandardOutput = $true
 $pinfo.CreateNoWindow = $true
 $pinfo.UseShellExecute = $false
 $pinfo.Arguments = $Arguments
 $p = New-Object System.Diagnostics.Process
 $p.StartInfo = $pinfo
 $p.Start() | Out-Null
 stdout = $p.StandardOutput.ReadToEnd()
 stderr = $p.StandardError.ReadToEnd()
 ExitCode = $p.ExitCode

$scriptPath = [System.IO.Path]::GetDirectoryName($MyInvocation.MyCommand.Path)
$fileName = "$env:computername.csv"
$outputPath = Join-Path $env:windir "temp"
$outputFile = Join-Path $outputPath $fileName
$autoPilotScript = Join-Path $scriptPath "Get-WindowsAutoPilotInfo.ps1"

Execute-Command -Command "$psHome\powershell.exe" -Arguments "-ex bypass -file `"$autoPilotScript`" -ComputerName $env:computername -OutputFile `"$outputFile`"" | Out-Null

$url = "https://ZZZZ.blob.core.windows.net/hashes"
$sasToken = "?sv=2017-04-17&ss=b&srt=o&sp=w&se=2019-10-16T19:47:51Z&st=2017-10-15T11:47:51Z&spr=https&sig=XXXX"
$result = Execute-Command -Command "`"$scriptPath\azcopy.exe`"" -Arguments "/Source:`"$outputPath`" /Dest:$url /Pattern:$fileName /Y /Z:`"$outputPath`" /DestSAS:`"$sasToken`""

if ($result.stdout.Contains("Transfer successfully:  1"))
 if (-not (Test-Path $(Join-Path $scriptPath "autopilot-script-success")))
 New-Item -Path $(Join-Path $scriptPath "autopilot-script-success") -ItemType Directory | Out-Null
 Copy-Item -Path $outputFile -Destination $(Join-Path $scriptPath "autopilot-script-success") -Force -ErrorAction SilentlyContinue | Out-Null
 if (-not (Test-Path $(Join-Path $scriptPath "autopilot-script-failed")))
 New-Item -Path $(Join-Path $scriptPath "autopilot-script-failed") -ItemType Directory | Out-Null
 Copy-Item -Path $outputFile -Destination $(Join-Path $scriptPath "autopilot-script-failed") -Force -ErrorAction SilentlyContinue | Out-Null

UPDATE 22/07/2018: I have an enhanced version of the gather script now which can be found on my GitHub account. The enhanced version does not have the dependency on AzCopy.exe (incl. dependency files) and Get-WindowsAutoPilotInfo.ps1 in the script directory. If they are not available, they are downloaded from an additional Blob Storage container named resources. The additional container resources must be created and the AzCopy.zip and Get-WindowsAutoPilotInfo.ps1 must be uploaded there to successfully run the script. The scrip is part of a complete automation solution – Automation of gathering and importing Windows Autopilot information

Create another PowerShell script: Download-HardwareInformation.ps1
This can be used later on to download all the .csv files from Azure Blob Storage and create the combined .csv for easy upload to Autopilot. Leave this script on your admin workstation. Replace the StorageAccountKey XXXX with one of your storage account access keys! Replace ZZZZ with your Storage account name.


# Author: Oliver Kieselbach
# Date: 11/15/2017
# Description: Gather AutoPilot .csv file from Azure Blob Storage, delete them and combine into single .csv file.

# The script is provided "AS IS" with no warranties.

#Install-Module AzureRM

$ctx = New-AzureStorageContext -StorageAccountName ZZZZ -StorageAccountKey XXXX
$path = "C:\temp"
$combinedOutput = "C:\temp\combined.csv"

$count = $(Get-AzureStorageContainer -Container hashes -Context $ctx | Get-AzureStorageBlob |measure).Count
if ($count -gt 0)
 Get-AzureStorageContainer -Container hashes -Context $ctx | Get-AzureStorageBlob | Get-AzureStorageBlobContent -Force -Destination $path
 $downloadCount = $(Get-ChildItem -Path $path -Filter *.csv | measure).Count
 if ($downloadCount -eq $count)
 Get-AzureStorageContainer -Container hashes -Context $ctx | Get-AzureStorageBlob | Remove-AzureStorageBlob
 # parse all .csv files and combine to single one for easy upload!
 Set-Content -Path $combinedOutput -Value "Device Serial Number,Windows Product ID,Hardware Hash" -Encoding Unicode
 Get-ChildItem -Path $path -Filter "*.csv" | % { Get-Content $_.FullName | Select -Index 1 } | Add-Content -Path $combinedOutput -Encoding Unicode

I assume the MDT share is build and a Standard Task Sequence for a vanilla Windows 10 installation is available. Then we add a task sequence step “Run PowerShell Script” to the folder “Custom Tasks“:


and configure the Get-HardwareInformation.ps1 script:


Now you are ready to run a MDT deployment of a Windows 10 with an automatic upload of the hardware information to the Azure Blob Storage.

After deployment of the devices you can use the Download-HardwareInformation.ps1 Script to get the combined.csv file and upload it to Microsoft Store for Business (MSfB) or Intune Portal. The upload is currently available in this portal only.


I recommend to use the MSfB to upload the combined.csv only! Management of the devices and profiles should be done in Intune. Currently the portals do not completely share their information. For example a profile created in MSfB will not be shown in Intune and vice versa. With Modern Management where Intune is used I suggest to use MSfB to upload devices and Intune for management of profiles (creation and assignment).

In the meantime you have the full functionality in Intune, see more here: Autopilot profile assignment using Intune


Happy Autopiloting!

There is another great article from Per Larsen (MVP):
How to collect hardware hash to use in AutoPilot as part of MDT OSD