question

CloudViking86 avatar image
0 Votes"
CloudViking86 asked JrmieRioux-9976 published

Joining existing device to AAD + Intune auto-enrollment through bulk-enrollment (ppkg) = No assigned user

Hello,

Currently:

  • Non-domain joined devices running local accounts without Autopilot

  • Devices are "AzureAD-Registered"

Desired end-state (in such an automated fashion as possible):

Issue:

So I am trying to figure out the most expedient way to enroll our current devices into Intune and join them to AAD.
The devices are already "AAD-Registered" and they do NOT have an Autopilot-profile assigned to them.

I've created a provisioning package with a bulk token as described here;
https://docs.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll
which introduces the caveat that we need to hardcode a wifi-connection / SSID which in these pandemic times can be hard since users won't be at the office and are using their own network at home.

Not specifying any wireless network and to use a wired connection instead is not an option since the majority of users don't have an ethernet-adapter with their laptop and I can't assume that they have a network cable.

Well I thought about simply instructing them to setup their phone as a hotspot and therefore be able to hardcode a SSID / WPA2-PSK in the ppkg.

I tested joining my test-laptop with the ppkg and it works fine, my user is in the scoped group in Intune and gets enrolled into Intune during the AAD-Join.

However when checking the user in AAD I can see that the device is still listed as:
AzureAD-Registered (however using Intune as the MDM)
I also found a new user in AAD;
"package_<GUID>"

That user has my test-laptop listed as a device but as "AzureAD-Joined" and it is also this user which the device belongs to in Intune.
In Intune the device is lacking a "primary UPN" / "primary user" and is "enrolled by: <blank>".

Sure I get that since its not the actual user who have joined AAD but the provisioning package the device is then left unassociated with a primary user in Intune / AAD and while the local user account exist which still is "AzureAD-Registered";

MyTestUser
MyTestDevice <-- AAD-Registered (Managed by Intune)

package_<GUID> <-- Provisioning package which joined the device to AAD
MyTestDevice <-- AAD-Joined (Managed by Intune)

So is there any way I can make the device to be associated with the "actual user" who signs in to the device automatically without assigning the user manually through the Endpoint Manager console?

I guess I can script this from an admin-perspective:
https://svdbusse.github.io/SemiAnnualChat/2020/03/21/Changing-Intune-Primary-User-To-Last-Logged-On-User.html
but was just thinking if my "process" was correct or if I should change something i.e.;

  • That the user "disconnects" so their device is no longer "AAD-Registered" and then runs the provisioning package; however I don't see how this would inform AAD about which user the device belongs to but it would eliminate the duplicate "AAD-Registered"-device unless when I manually assign "MyTestUser" to the device in Intune the "AAD-Registered" and "AAD-Joined" device objects merge into the "AAD-Joined"-device?
    ^ This can't be scripted however and need to be performed manually by the user and I want to automate this as much as possible

Would appreciate your feedback regarding this





mem-intune-enrollmentazure-ad-user-provisioning
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

LuDaiMSFT-0289 avatar image
0 Votes"
LuDaiMSFT-0289 answered

@CloudViking86 Thanks for posting in our Q&A.

When you make the device is AAD joined. The old record "AAD Registered" will not disappear. It is a normal phenomenon. These two records can't be merged into one record. We can delete this record manually.

For bulk enrollment "enrolled by: <blank>", it is also a normal phenomenon. For the method to change Enrolledby, after doing more research, I didn't find it mentioned in our official article.

If you just want devices are AAD joined, it is suggested to "disconnect" the AAD registered device first and then re-enroll the device using autopilot or auto-enroll method in the following link:
https://docs.microsoft.com/en-us/mem/intune/enrollment/device-enrollment#windows-enrollment-methods

Thanks for understanding.


If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.


5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

CloudViking86 avatar image
0 Votes"
CloudViking86 answered LuDaiMSFT-0289 commented

@LuDaiMSFT-0289
Thank you.

The issue is that we want to find a easy way to do this for our current devices which are already deployed and used by our users which should be as automated and easy as possible not requiring a wipe.

So wiping the device and using Autopilot is not an option, the easiest way for the users I know of is:

  • Provisioning package which joins to AAD; this req. the users to setup a hotspot since you need to specify a wifi-network (SSID / WPA2-PSK) during the creation of the package but its either that or a wired connection and they don't have ethernet-dongles to their laptops nor might have the possibility to connect using an ethernet cable

  • When joining AAD and if the group scoped by Intune they automatically get enrolled into Intune

  • An Autopilot-profile set with the option "Convert existing devices to Autopilot" scoped to a dynamic group (which the users become a member of)

However even if it would be better if the user first disconnects their "AAD-registered"-device that can't be scripted.
There is no way programmatically to do this and the end-user needs to do this themselves and if that is the case then they can just "Join to AzureAD" themselves as well which would allow them to use their own wifi-network.

This would also solve that they themselves become the "Primary user" of the device which now is <blank> together with "Enrolled by".
"Enrolled by" is not that much of an issue, rather "Primary user" being blank is the issue since without a primary user applications and configurations does not kick in if they are scoped to a dynamic group which contains the user who should own the device.

However if the user enrolls themselves they become local admin on their device whereas using a provisioning package they do not, we would like the user not to become admin. This can of course be altered later using Intune but still.

If there was an option to through PowerShell "disconnect" the users work-email and thereby removing their "AAD-registered" device that would be great.

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@CloudViking86 Thanks for your explain.

The way that you provided can't met the requirement. Based on my experience, "Convert existing devices to Autopilot" also needs device reset.

Are these devices in on-premises domain? If yes, it is suggested to try to use co-management or GPO method.
88611-image.png


0 Votes 0 ·
image.png (43.2 KiB)

Sadly the devices are not joined to an on-premise domain.

AFAIK with the "Convert Existing Devices to Autopilot";
What I want to accomplish here is that next time the device get repurposed (wiped and assigned to a new user) then Autopilot will kick in and also for all subsequent wipes after that which I believe it will.

0 Votes 0 ·

@CloudViking86 Yes, it will make. When you configure "User account type" to Standard in the autopilot development profile, the users will not become admin.

0 Votes 0 ·
JrmieRioux-9976 avatar image
0 Votes"
JrmieRioux-9976 answered JrmieRioux-9976 published

Have you ever found how to make it work? I have the exact same scenario.

Thanks

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.