Finally. Now that we covered the provisioning package and how our device will migrate to Tenant B with no user affinity, let’s talk about the task that sets the primary user for Intune.

After migration, when you navigate to the PC in Intune, the “Primary user” attribute should be empty. Take a look:

This is because it was enrolled by the provisioning package, and while it has a principal in Azure AD, it is not a user. We can further verify this in the registry of the newly migrated PC.

Navigate to HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo. Select the GUID and you should see plenty of information about the recent Azure AD join. Notice the UserEmail entry:

At this point, Intune or Azure AD will not be updating the primary user, because it doesn’t exist. So let’s do it ourselves.

SET PRIMARY USER (TRIGGER: 10 MIN AFTER LOGON)

The logic in this task is fairly simple. We need to figure out who is using the PC, and then tell Intune to make that user the “Primary user”. Let’s break down the process and start with some things we will need:

• App registration for Tenant B with the following permissions:

  • Device.ReadWrite.All

  • DeviceManagementManagedDevices.ReadWrite.All

  • DeviceManagementManagedDevices.PrivilegedOperations.All

  • DeviceManagementServiceConfig.ReadWrite.All

  • User.ReadWrite.All

• Serial number of PC

• Intune object

• Current, logged in user

• User Azure AD object

We need the PC serial number to get the Intune device object. You can get the serial number by using the PowerShell cmd…

…or retrieve it from our MEM_Settings.xml file. Either way will work fine.

Just like in the GroupTag script, we’ll use that serial number to query the graph for our Intune object ID.

Now we’ll need the current logged in username. But wait- how do we get that if we just said that the provisioning package was the primary user to the device? Let’s check somewhere else.

Open up the registry again and navigate to HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI. The entry for LastLoggedOnDisplayName should match our user display name in Tenant B.

Let’s get the value and search the graph for it:

That should return the Azure user object, from which we can pull the ID from. Store that in a variable.

This is where things get weird. We need to post the user ID to the Intune object in the graph, but there’s a unique endpoint for that. We can refer to it as the “deviceUsersUri”:

Think of this as the endpoint that contains that device’s users. That will be the endpoint we make our POST call to.

Now we’ll construct the JSON value. This will be the user object endpoint, so we can concatenate the users endpoint with our ID:

All that’s left is to POST the json value to the “deviceUsersUri” endpoint.

After a few minutes, take a look at the device again in Intune.

We did it! And it’s not just the Intune object that has the value. When you navigate to entra.microsoft.com and look up the device, you’ll see the Owner and User principal name are linked to the correct ID.

Next time…

You can get the full SetPrimaryUser script and task files from the repo. Only two more tasks to go…