Windows Autopilot

Random news of the week: New white glove fix, updated Intune module

By on • ( 4 Comments )

In the category of “stuff probably not worth a separate blog” category, I’ll combine some notes together into a single post.  Let’s go through those one at a time.

New white glove fix

Windows Autopilot white glove scenarios have always supported the provisioning of all device-targeted apps, policies, certs, etc.  And if there is a user assigned to the device, it would also install any user-targeted Win32 device-context apps.  (It can’t do user-targeted policies, certs, etc. because the user needs to actually sign on and create a user profile so that there’s a place to put those policies and certs.) 

There was a change made a few months back where we added the ability to specify a device name on each Autopilot device, as well as to edit the group tag assigned to that device.  How is this related to white glove?  Well, at the same time, the logic to assign the white glove user was moved into a new method that can set all of those values (assigned user, user friendly name, group tag, device name).  That new method had an issue, so while the user’s UPN was set, it didn’t set an internal ID that Intune used to find that use later.  The net result: no user-targeted apps would be installed.

I added a workaround to the WindowsAutopilotIntune module (adding a Set-AutopilotDeviceAssignedUser) that used the old method while we fixed the new method.  Now that the latest Intune monthly release has rolled out, that is now fixed, so the previous workaround was removed (so you can set the assigned user correctly via the Intune UI, companion app, or Set-AutopilotDevice cmdlet without any issues now). 

More changes to the WindowsAutopilotIntune module

Since I was making changes anyway, I made some additional tweaks to the ConvertTo-AutopilotConfigurationJSON cmdlet to add some additional properties and to make it more efficient (it was querying the tenant details for each profile, even though those tenant details don’t change).  Maybe you can notice the additional properties:

image

Reminders

There are plenty of additional blogs out there that talk about the WindowsAutopilotIntune module.  But pay particular attention to this one if you haven’t used the module in a while:

https://oofhours.com/2019/11/02/whats-new-with-the-windowsautopilotintune-powershell-module/

This module now builds on top of the Microsoft.Graph.Intune module for authentication and all Graph queries, so you need to understand how to authenticate with Intune.  And if you use one of the scripts that I’ve published to the PowerShell gallery (e.g. this one) that also uses Graph to talk to Azure AD using a different module, just be aware that you’ll authenticate twice.  (I suspect there’s a way around that, but I haven’t had a chance to investigate.)

Categories: Windows Autopilot

4 replies »

  1. To avoid the double authentication thing, you can do this:

    $intuneId = Connect-MSGraph
    $aadId = Connect-AzureAD -AccountId $intuneId.UPN

    Instead of:

    $intuneId = Connect-MSGraph
    $aadId = Connect-AzureAD

    Like

  2. You can use the Invoke-MSGraphRequest command from the Microsoft.Graph.Intune module to replace the Invoke-RestMethod command in your original scripts. This has the advantage of using the SDK’s authentication framework, removing the requirement to authenticate twice or to manage token and token refresh. One issue I did have is that I had to do [uri]::escapestring() on some of the uri’s I was passing; they worked without that step when using invoke-restmethod. I’ve used this method to collapse scripts towards using the SDK exclusively. EX: Adding an intune enrolled device to a AZgroup for targeting is not something you can natively do with the SDK, but the REST commands are available in a script in the PowerShell Intune Script sample repository and you can craft those to use the SDK for incorporation into your automation scripts.

    Like