Yesterday’s changes (described in this blog) were probably bigger, but after a couple of suggestions in response to that update have caused me to publish another new version.
For the first change, you can now build a CSV file with the UPN of the user that should be assigned to the device. Just specify the -AssignedUser parameter like so:
Get-WindowsAutoPilotInfo.ps1 -GroupTag Blah -AssignedUser email@example.com -OutputFile c:\mydevice.csv
That CSV can then be imported into Intune directly (it won’t work with Microsoft Store for Business or Partner Center).
The next change adds an -AssignedComputerName parameter that can be used to specify the computer name that should be assigned when Autopilot deploys the device. This only works for Azure AD Join (sorry), and because you can’t import a CSV file to Intune with this value it has to be done after the import is complete, hence it is dependent on the -online switch. Here’s the syntax:
[-GroupTag <String>] [-AssignedUser <String>] [-Append] [-Online] [-AddToGroup <String>] [-AssignedComputerName <String>] [-Assign]
Here’s an example:
I specified a computer name of “TEST-091” along with other values (group tag, assigned user, etc.). You can see the timings for this as well, with it taking about three minutes to import the device into Autopilot and sync it back into Intune (which happens automatically), and then another three minutes to assign the Autopilot profile (a feat that isn’t often duplicated – many of my tests took closer to 10 minutes to do that).
So download (from Get-WindowsAutopilotInfo, now up to version 2.5) or install (using “Install-Script Get-WindowsAutopilotInfo”) the new version to try it out.
Categories: Windows Autopilot
MICHAEL, as a Tier 1 support technician, is there any guide I can follow to quickly whiteglove a new machine (store bought) for a user in our organization?
The first time I tried it was many months ago, I had to use an ethernet cable, prep a USB stick with a script so that I could add the hash to Azure, had to set up policies and make custom .msi packages with a program so that I could install the common apps in the organization. Had to edit XML files to get the start screen, assign licenses.
During the actual whiteglove process I was met with red screens, first it was the TPM module, then it was the wrong windows version, then as it turns out it was the wrong language of the OS.. so you had to install windows on a USB (with prebaked updates).. the headaches conintued and at that point I got frustrated and went back to good ol ‘ restore from within Windows.
Yes, I continue to configure the machines for users manually, and I take pride in that fact.
Most of your posts are too “hacky” and convoluted for your average layman. Has intune evolved, should i give it another chance..?
So I decided to give it another go. Enrolled a device and it got stuck on installing some client app (Which, I do not know). So I had to do a reset and went to remove the configuration policy in intune. Repeat the process and now stuck on MDM registration with error 0x80180022.
I’m guessing this is because the device is already registered. So what? Should still work anyways.
This is great!
Question: is there a way that I can assign the serial number for the computer name like we use %Serial% in Intune?
You can pass a variable on the command line, so something like this should work:
$serial = (gwmi Win32_Bios).SerialNumber
Get-WindowsAutopilotInfo -Online -AssignedComputerName $serial etc…
You are the man!! Thanks so much Michael. You make our job so much more manageable. 🙂
Great Michael. Thank you. I’m using a similar script. I will give a try at this one.
Is the simple way for this script to consume method described here: “App-based authentication with Intune”
When I authenticate/authorize as described in the App-based… the Get-WindowsAutoPilotInfo.ps1 script does not seem to recognize the authenticated context.
So I assume the way used by @truciw may be the answer to my noob question.
We’re just starting to use Autopilot to provision devices for certain scenarios- these devices are new but we have them on-site so are having to perform the provisioning process ourselves.
We’ve run into an issue twice this past week where we tried running the script with the -online switch to speed up the import process and assign a computername and group tag. The end result on both occasions was that the script started to iterate through all of our existing Autopilot registered devices and assigned them all with the same name. Unfortunately due to distance working etc. I wasn’t there and the engineer who was performing the operation failed to gather logs or even take screenshots… but I’ve pulled the audit log out of Intune. For now we will revert to using the script to generate a csv but I thought I’d raise it here. Is there any reason you can think of for this happening?
Weird, can’t reproduce that one. I did add additional logging and validation in that section of the script, so try out the new version – if you see the same thing happen capture the log output.
Any way to make this automated during the AutoPilot process? Or does it only work when doing this manually? Cause if this could be automated to all devices then it would solve the lack of something more than just %serial% considering we can get whatever info we want from wmic.
The automated way would be to have the OEM or reseller take care of it for you. Then you don’t need to do it at all.
Bug which you can easily reporduce in windows 1909/2004: Take a new device, and set up a local account. Then sign in to the desktop, and run the script. Device will enroll and apply autopilot policy. If you sign out, you can’t sign in to any other work or school account. You’re stuck having to restore the device.
In your video demo of the -online option the result showed registration failure information(806 ZTDDeviceAlreadyAssigned). (https://youtu.be/Wo-E8dF39n4)
When running the published script, no such feedback is presented for either 806 ZTDDeviceAlreadyAssigned or 808 DeviceAssignedToOtherTenant.
Any pointers on how to enable this output?
V2.3 script content (FileList) appears to be V1.3 with Package details correct at 2.3. This resulted in content comparison between 2.3 (1.3) and 2.4 being a dead end.
By pure chance I installed script (Install-Script -Name Get-WindowsAutoPilotInfo -RequiredVersion 2.3 -force) and noted that this was different behaviour.
LikeLiked by 1 person