This week I’m going to show an example of how to collect the Windows AutoPilot device information of existing Microsoft Intune managed (Windows 10) devices. That could be useful, for example, when an organization wants one similar deployment experience for all devices. For now and in the future. In that case it can be very useful to gather the device information and upload that information. That will provide future deployments of those existing devices with the same company branded deployment experience as new devices. Also, another reason for this post is the simple fact that I’ve received this request multiple times now.
This example will use an Azure storage account that will be used to store the Windows AutoPilot device information and it will use the Get-WindowsAutoPilotInfo script to collect the information. In this post I’ll show high over the steps to create the Azure storage account, followed by an overview of the PowerShell script to collect the information and write the information to the storage account. I’ll end this post with the Microsoft Intune configuration and a quick peak at the results. After that simply collect the information and upload it via Microsoft Intune or the Microsoft Store for Business (or the Partner portal).
Create storage account
The first step is to create a storage account in Azure. The following four steps walk through the high over steps to create a storage account including a file share. That file share will be used to store the Windows AutoPilot device information.
1 | Open the Azure portal and navigate to Storage accounts; |
2 | Add a storage account of the Storage (general purpose v1) kind and make sure that Secure transfer required is enabled (remember the storage account name); |
3 | Navigate to Files and add a file share (remember the file share name); |
4 | Navigate to Access keys and view the available keys (remember the key) ; |
Note: Be aware that not every ISP allows access from port 445 to Azure (for an overview see: https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx).
Create PowerShell script
The second step is to create a PowerShell script to upload the Windows AutoPilot device information to the file share in the just created storage account.
Script variables
This PowerShell script is created for usage within Microsoft Intune. Currently the PowerShell script functionality within Microsoft Intune can’t work with input variables, which means that the values of the different variables have to be available in the script. That means that in the variables block on top of the script (see script snippet section) the following values should be adjusted.
- <StorageAccountKey>: This should be the access key of the created storage account (step 4);
- <StorageAccountName>: This should be the name of the created storage account (step 2);
- <ShareName>: This should be the name of the share of the created storage account (step 3).
Script actions
The PowerShell script contains a few actions that it should perform to complete the required activities. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).
- Create a drive with the created Azure storage account;
- Download the available script from PowerShell Gallery;
- Set the location to the location of the downloaded script;
- Install the downloaded script;
- Run the installed script and use the created drive for the output;
- Remove the downloaded script and the created drive.
Script snippet
The PowerShell script is shown below.
[gist https://gist.github.com/pvanderwoude/09f4e1354a41a40e5a6f98bd826333c7 /]
Note: Be aware that downloading PowerShell Gallery items requires PowerShellGet and that PowerShellGet requires the NuGet provider to work with the PowerShell Gallery (for more information see: https://docs.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted).
Configure PowerShell script
The third 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 | ![]()
Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode). |
4 | ![]()
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 results. The share in the created storage accounts will start filling with CSV-files of the different Windows 10 devices that are managed by Microsoft Intune. That means that it will start to look like something as shown below.
As the required device information is available now, within the file share of the storage account, it can be downloaded and imported via for example Microsoft Intune. Of course it’s possible to use PowerShell to merge these CSV-files into one big CSV-file. This is relatively easy by simply using something like Get-Content and always grab the second line of the CSV-files.
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Nice and good for customers that want to migrate to a modern workplace concept. I used a similar construction for deploying custom software, scripts and executables. Found at another Peter 🙂 blog @ https://blog.peterdahl.net/2017/12/12/deploy-exe-file-from-microsoft-intune-using-azure-blob-storage/
Its always debatable to supply a name and key in a script file cause it will be in the PS Management Extensions log files plain text. But sometimes we have no choice
Correct, RKast. It’s all about choices. Here I’m just providing an example 🙂
Yes sir and thanks for these great ideas and blog posts 🙂 !!
The eventual goal is to eliminate the need for something like this: If you’ve already got a device enrolled in Intune, we can automatically add it to AutoPilot. Stay tuned.
That’s great to hear, Michael! I already was hoping for something like that 🙂
Hi, I’ve tried to import the CSV file into Intune and returned an error saying the device is already member of AAD and couldn’t be imported into the AutoPilot :\
Hi Eduardo,
Can you provide some more details, like if you already previously added that device to AutoPilot?
I just successfully uploaded device information of a device that already existed in AAD.
Regards, Peter
Hi Peter,
I haven’t added that device to autopilot before but I have registered and joined it to Azure AD manually.
Under Device Enrollment – Windows Enrollment, I click on Manage Windows Autopilot Devices, select import, choose the csv file – that parts works but the import process comes back with the following error:
Internal error
ERROR CODE:
814 – ZtdDeviceAlreadyAadRegistered
CSV LINE NUMBERS AFFECTED:
1
Thanks,
Eduardo
Hi Eduardo,
I just heard that the behavior recently changed for importing AutoPilot devices. At this moment the import will fail when the device is already available in Azure AD.
Regards, Peter
that is good, so I know the error is not related to my tenant or something that I’ve missed.
It is a shame this change in behavior. I came across your article because of this statement “That will provide future deployments of those existing devices with the same company branded deployment experience as new devices. ” but at least your article is great showing us how to export the necessary information from existing machines. 🙂
Thanks,
Eduardo
Thanks, Eduardo. Make sure that you keep on trying this now and then, as there might be a new adjustment regarding this behavior.
Regards, Peter
As the warning states about using port 445, is there an alternative port to utilize?
Not at this moment. For more information see also: https://feedback.azure.com/forums/217298-storage/suggestions/15001032-allow-access-to-file-storage-configuration-to-use
Peter,
I am able to get this to run manually if I run my PS session as an admin (elevated rights) so I know the script works. However, when I push this to my Intune machines it fails since all teammates are users on their machines and not admins. I have this running in system context but that does not seem to help. Any ideas on a resolution?
Thanks,
Mike M.
Hi Michael,
Running a script as admin is not the same as running a script as SYSTEM, which is what Intune does. Having said that, keep in mind that you can now also easily targeted already Intune managed devices without separately importing those devices.
Regards, Peter
Hello,
Like Michaels comment, my script will fail if run through Intune, but it will run with admin permissions locally and show up in my storage account, although there were a couple prompts where I had to accept.
I noticed the note:
Note: Be aware that downloading PowerShell Gallery items requires PowerShellGet and that PowerShellGet requires the NuGet provider to work with the PowerShell Gallery (for more information see: https://docs.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted).
Could this be causing the failure?
I’m also wondering if the execution policies of the machine could be causing the error? If I run locally it will prompt to allow a couple of times, and script works, ID sends to my blob storage.
I’ve tried as currentuser and system in intune and script has been failing. I even set the execution policy to bypass on the currentuser and localmachine to test and still no go.
Hi Dylan,
Yeah, make sure that your package provider is also up-to-date.
Regards, Peter
Hi Peter
And to who should this script be assigned? i choosed an AD Group where all Users are Member !? is this the right way?
thanks
Hi Kaya,
Doesn’t matter, as long as you’re targeting the required devices. Also, keep in mind that there are easier methods to get the required devices in Autopilot.
Regards, Peter
Peter,
I followed your steps one by one but I get:
FAILED to connect to Azure storage
Can you think any reason why? I believe you had a script to check access to the store share but can’t find it…
Hi Ed,
Did you adjust the script with the information of your storage blob?
Regards, Peter
Peter,
I did, I also ran several scripts to identify if port 445 was being blocked (I found the ones that check the port) and the port in my case actually is blocked so it would not work for me….
Ah okay. Yes, in that case this solution won’t help you.
Regards, Peter
How about using Blob Storage Rest instead? https://rzander.azurewebsites.net/upload-file-to-azure-blob-storage-with-powershell/
That will overcome your 445 issue, and well blobs are cheaper 🙂
Hi Jeff,
It’s just about the storage location. You can use whatever you want, but it might require some adjustments to the script.
Regards, Peter
I receive on some devices a timeout error and dont understand why
What i noted so far:
– When i run the script manually with Admin rights on the target device, it is working straight ahead, but it fails when i run it as standard user (System context) via Intune it returns in intune an error (target: device)
– it is also working, when i run this with a task scheduler in System contex on the target device (standard user)
Any ideas what else i can do? Is the script still up to date?
Hi Fabian,
I haven’t used it recently, but it has always worked well for me. SYSTEM context == SYSTEM context. So, running it from Intune within SYSTEM context should be fine.
Regards, Peter
If you are just looking to move existing managed computers into Intune so next factory reset they get the OOBE.
Simply create a new deployment profile. Mark the Convert all targeted devices to Autopilot as Yes. Deploy to a group with the device you want moved.
Next time they check in the data will now be in Autopilot devices.
Hit the Wipe button when you want them to go back to OOBE.
Correct, Jeff. That’s indeed applicable and usable for most scenarios. There might, however, still be scenarios where alternatives are needed (think about a tenant migration for example).
Regards, Peter