none
Convert AAD-registered devices to AAD-joined? RRS feed

  • Question

  • In reading about Windows Autopilot and exercising its basic green-field scenario, that seems almost simple enough

    https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm

    but I am struck by how difficult it has been to find any documentation that details on the brown-field scenario of converting a group of existing AAD-registered devices to AAD-joined. This should be a fairly common scenario, as organisations would usually slowly step up with small increments the level of sophistication they'd operate and manage their devices. (And we don't even need to deal with the hybrid scenario since we don't operate our own internal AD domains/forest.)

    What is the official procedure to handle these conversions for deeper device management?

    PS - I can't find any Azure AD forum in this TechNet site, and Microsoft Intune seems to be closest related.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Monday, December 2, 2019 7:20 AM grammar
    Tuesday, November 26, 2019 9:25 AM

Answers

  • To clarify the reality of the situation, our company originally only had Office 365 and Azure AD Premium. Computers were issued to staff and they complete setup by signing in with their personal Microsoft accounts, then later adding their work account; thus the majority of them are AAD-registered with no MDM authority, since of course we hadn't subscribed for Intune back then. That's why the goal is to eventually join them to AAD and enroll with Intune, so they can be brought back inline with the future fresh computers which have the benefit of Windows Autopilot to streamline that setup process. Obviously we want to carry out the change with as little disruption and pain as possible for our colleagues.

    So after much fiddling around different test cases with the Windows 10 clients + Azure AD + Intune, I think finally got a handle of what needs to be done.

    Starting point

    • Computer AAD-registered, with Office 365/AAD user.
    • No MDM authority.
    • No entry in Intune (naturally).

    Finish point

    • Computer AAD-joined, with Office 365/AAD user. (Same record)
    • MDM authority = Intune.
    • Listed in Intune devices (Windows).

    To get to starting point,

    1. Let user sign into physical computer with own personal Microsoft account.
    2. Connect Office 365/AAD account at [Access work or school]. This results in the AAD-registered record for that user/computer.

    To get to finish point,

    1. Assign Intune license to user.
    2. Connect same Office 365/AAD account at [Access work or school], but opt for [Join this device to Azure Active Directory] path. This is important because it will tie back to the existing AAD-registered record with the same device ID and thus edit that record. Another user initiating the join will result in a new record with a different device ID.
    3. Initiate [Enroll only device management] path at [Access work or school] with same Office 365/AAD account. (This step can be skipped if user included in AAD group marked for auto-MDM-enrollment).

    Thank you all for the information to piece the puzzle together.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    • Marked as answer by icelava Monday, December 9, 2019 11:07 AM
    Monday, December 9, 2019 11:07 AM

All replies

  • Can you expand on your scenario here, please?

    If you are using AutoPilot, there is no conversion as AutoPilot is an initial device provisioning solution that requires the device to be a clean Windows 10 install or a Windows 10 device that was reset meaning that it is neither AAD hybrid domain joined or AAD domain joined at all.

    If you are referring to existing systems and simply converting them without using AutoPilot, why?

    There is no "deeper device management" with AAD domain joined systems. From an Intune perspective, there is no difference between the two management-wise.

    If your organization has no internal AD infrastructure, then it's impossible to hybrid domain join a system in the first-place as that requires an internal AD.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, November 26, 2019 2:39 PM
  • Yes, I know Windows Autopilot is for setting up new computers/devices.

    But, we have a platoon worth of existing computers already in operation that weren't setup with Autopilot. With their previous setup, these older computers were only AAD-registered. The plan for the future is to gradually convert them to AAD-joined, since they are company property and not BYOD. Then we group them up and apply the relevant policies.

    I mention we don't have an existing traditional AD domain, so that we can completely ignore the complexity of that hybrid scenario. Just need to convert existing devices from AAD-registered to AAD joined.

    Surely there are differences between registered and joined; otherwise why have two different classifications in the first place?

    https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-register

    https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral



    • Edited by icelava Wednesday, December 4, 2019 10:25 AM format
    Tuesday, November 26, 2019 7:53 PM
  • OK, I misread your your question slightly, thank you for clarifying.

    Ultimately, there is no automatic movement between these two AAD "join" types as one is user-centric and one is machine-specific. The user that registered the system will need to unregister the system from AAD and then a local admin will need to join it to the Azure domain.

    I can't say that I've tried, but a user that did not register the system (and is a local admin) may be able to join the device to AAD. That would result in two objects in AAD for the same system though and so may not be allowed.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, November 26, 2019 9:23 PM
  • Hello,

    To convert the registered devices to Azure AD joined devices, you need to unregister the devices, and then join them in Azure AD.

    To unregister the devices, you can retire the devices from Intune portal, and then delete the device records in the Azure AD.

    By the way, the website link for the Azure AD forum is as below.

    https://social.msdn.microsoft.com/forums/azure/en-US/home?forum=windowsazuread

    Best regards,

    Andy Liu


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 27, 2019 8:21 AM
  • Andy, what of devices that were registered but also not enrolled to MDM (Intune)?

    We've only recently added on Intune to test Windows Autopilot, so only the test computers that ran through the Autopilot procedure got domain joined and managed by Intune. The rest are defined with "None", and they don't show up at Intune.

    Additionally, what cost to productivity would happen if we were to just straight up unregister the devices from Azure AD portal? Or even to initiate a disconnect (even if temporary) from the client OS side? I am not able to piece together a whole picture of the consequences.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Wednesday, November 27, 2019 2:45 PM addition
    Wednesday, November 27, 2019 10:06 AM
  • To my knowledge, Intune auto-enrollment only works at the time the system is registered with or domain joined to Azure AD thus there's nothing you can do automatically here but will need to manually enroll the systems in Intune.

    As for productivity, that depends on what you are expecting to happen. If the users will now be logging in with Azure AD accounts, they will need new Windows profiles just like they would when converting a workgroup system to a domain-joined systems because that's exactly what happens when you Azure AD Domain join a system.

    https://docs.microsoft.com/en-us/intune/remote-actions/devices-wipe#windows shows what happens if you retire the registered Windows device in Intune.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, November 27, 2019 9:44 PM
  • This may be the wrong method, but I tested with a reset Windows 10 for one of the VMs; create a local admin account first, then add Microsoft work account (Office 365/AAD) as a secondary account. This act puts the computer as an AAD-registered device in Azure AD.

    (Side note: After adding that device into the test Autopilot group we defined, it appeared to be able to push the app definitions we assigned to that group (e.g. Office 365 suite). But over time I noticed this computer installing way more Office apps than what was selected in Intune. Unselected apps like Publisher, OneNote 2016, Skype for Business) got installed as well; unsure where this directive came from. However Microsoft Teams, which was declared for installation, hasn't appeared. Neither has the custom Win32 app PuTTY appeared. Unsure too if those are or not still in the installation pipeline that will happen later.)

    Subsequently, I tried to connect again in [Access work or school] section, using the very same user account already connected but this time with the [Join this device to Azure Directory] path. This sequence will fail client side with "This device is already enrolled."

    However, at Azure AD side, the device became Azure AD joined.

    This should not be considered a success, I believe, because from Intune perspective the device remains as personal ownership.

    From the available info, I suspect that at a raw Azure AD level, the computer did change to joined status. However, the enrollment to Intune did not fully succeed thus the ownership still stuck at personal and the client side error message.

    I have yet to test a wipe action (without retaining enrollment state) on this device to see what exactly will happen to it (will ownership change?). Obviously I can't do that for colleagues' existing computers since they don't actually have enrollment with Intune (and neither should I even if it could be done). I will however need to test another AAD join action on a colleague's computer to observe any difference in outcome. The good news is I've learnt that these older computers run Windows 10 Pro which let them sign in with personal Microsoft accounts first, then connecting later with Office 365 work accounts.

    Conjecture tells me they'd still need to disconnect first, allowing us to clear the AAD-registered entries, then perform a clean AAD join in order to gain corporate ownership.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Monday, December 2, 2019 7:23 AM info
    Thursday, November 28, 2019 9:28 AM
  • Ok regarding device ownership, I see it can be changed by looking at the individual device's Properties config blade.

    I performed a retaining wipe on the test computer, and looks like the aftermath is the local admin user has lost the connection to my AAD account. After reconnecting with my AAD account, I noticed the ownership reverted back to personal in Intune's device list.

    On the other hand, this time round the PuTTY app package got pushed to the computer and installed fairly quickly. Office 365 suite - ProPlus instead of Business is already installing as it should. I am unsure what conditions cause which apps and sub-app groups to get installed. Perhaps it's because this time round the device's already AD joined instead of AD registered? I cannot confirm.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Thursday, November 28, 2019 10:44 AM
  • Hello,

    1. Basically, Intune automatically assigns corporate-owned status to devices that are:

    Since your devices are Azure AD register, they'll be marked as personal. You should join the devices in Azure AD. Please refer here for joining in Azure AD.

    Please click here for more details about corporate identifiers.

    • Enrolled with a device enrollment manager account (all platforms)
    • Enrolled with the Apple Device Enrollment Program, Apple School Manager, or Apple Configurator (iOS only)
    • Identified as corporate-owned before enrollment with an international mobile equipment identifier (IMEI) numbers (all platforms with IMEI numbers) or serial number (iOS and Android)
    • Joined to Azure Active Directory with work or school credentials. Devices that are Azure Active Directory registered will be marked as personal.
    • Set as corporate in the device's properties list

    2. For the app deployment, it depends on the assignment of the apps. The apps can be assigned either to the user groups or device groups. 

    Either the Azure AD register or join doesn't affect the app deployment.

    Best regards,

    Andy Liu


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, December 2, 2019 3:00 AM
  • Andy, the join steps as documented is exactly what I did. The difference is that the OS was already connected with my AAD account initially, without a join (thus an AAD-registered state). I then perform those steps a second time to go with the join path, which resulted in the "This device is already enrolled." error.

    In Azure AD, it regards the computer as AAD-joined. Locally, dsregcmd does not regard the OS joined to AAD. (Although I'm running that as the local admin user, since there's no visible way for me to declare to the OS that my AAD account can sign in direct into the OS; only the local admin or my personal Microsoft account added through [Add someone else to this PC] option can sign in. My AAD account is only associated in [Access work or school] and that's all it extends to.)

    C:\Users\autopilot>dsregcmd /status

    +----------------------------------------------------------------------+
    | Device State                                                         |
    +----------------------------------------------------------------------+

                 AzureAdJoined : NO
              EnterpriseJoined : NO
                  DomainJoined : NO
      
    +----------------------------------------------------------------------+
    | User State                                                           |
    +----------------------------------------------------------------------+

                        NgcSet : NO
               WorkplaceJoined : YES
              WorkAccountCount : 1
                 WamDefaultSet : YES
           WamDefaultAuthority : consumers
                  WamDefaultId : https://login.microsoft.com
                WamDefaultGUID : {D7F9888F-E3FC-49B0-9EA6-A85B5F392A4F} (MicrosoftAccount)

    +----------------------------------------------------------------------+
    | SSO State                                                            |
    +----------------------------------------------------------------------+

                    AzureAdPrt : NO
           AzureAdPrtAuthority : NO
                 EnterprisePrt : NO
        EnterprisePrtAuthority : NO

    My AAD account is already a DEM as well. But as I understand it, I don't need DEM since I'm already the Intune administrator.

    UPDATE

    Last week this device became AAD-joined, but today I see that it has reverted back to AAD-registered. I'm not sure what is happening with this computer.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral



    • Edited by icelava Monday, December 2, 2019 9:22 AM update status
    Monday, December 2, 2019 7:18 AM
  • Putting the test Windows 10 Enterprise computer aside, some good news (and confusing) when I implement a test scenario with Windows 10 Pro and another dummy user (since my own account has gained a significant number of roles and privileges).

    Since Windows 10 Pro setup allows signing in with personal Microsoft account, I sign in with that first, then connect with the dummy work account. The computer shows up as AAD-registered device (with no MDM since the user didn't have Intune license yet). Next I add another work account (my real account) + join AAD path. This enrollment succeeds, with the AAD entry showing it has AAD-joined and Intune as MDM authority.

    The confusion is, it shows up as two separate entries now. They are the same physical computer with different device IDs.

    The second entry is the state that we want. But why is it regarded as two separate devices? At this point, should we simply delete off the first entry? But, the reality is for our colleagues they operate based on the first entry, no? I suspect there'll be repercussions if we remove their entry, am I wrong?

    The behaviour for registering then joining, between Windows 10 Enterprise and Pro, have been significantly different. Or, perhaps it breaks because for the Windows 10 Enterprise situation, it's the same user account performing both the register and the join? We tested out by performing a join using that dummy account instead of my pre-existing account, and it succeeded. So it appears that the AAD/Office 365 account used to register previously cannot be used to join later. This action, however, also results in two entries; however the MDM picture is reversed because only my user in the group with Intune licenses and set for enrollment to Intune.

    So this particular scenario's challenge would be how to bring the AAD-joined entry under the MDM coverage of Intune. It is fairly easy to grant the dummy user an Intune license and inclusion into the group that is marked for MDM enrollment in [Mobility (MDM & MAM)] config section. But are those all that is necessary? Or other administrative actions needed elsewhere?


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Monday, December 2, 2019 10:02 AM
    Monday, December 2, 2019 10:01 AM
  • > But why is it regarded as two separate devices?

    Because AAD-registered is not the same as AAD-joined. As noted in my previous reply AAD-registered is user-centric while AAD-joined is machine-centric. AAD-joined changes the actual state of the system, AAD-registered does not.

    > At this point, should we simply delete off the first entry?

    No, you need to unregister the system from the user's account that registered also as noted in my previous reply. This can be done manually or using the retire option.

    As noted, because this changes the machine state the same way that joining an on-prem domain does, it's more than simply an object in AAD.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, December 2, 2019 3:01 PM
  • So for our colleagues operating using their personal account and having their computers AAD-registered only with no Intune management, The official way is for them return to [Access work or school] and disconnect their work account, then we can delete the entry in Azure AD (if that's not automatically done). There is nothing to retire from Intune side they had nothing to enroll previously. The path is then cleared for them to perform AAD join (after assigning Intune license) with their work accounts; whereby they become joined and enrolled to Intune. 

    A few others have a more-complicated state of already having the computer AAD-joined but also no Intune management. Based on the facilities explored so far, there also appears to have no fast method to simply enroll it direct to Intune, so we have to AAD-unjoin and delete the entry, then perform a rejoin after the Intune license assignment. Is that correct?


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Tuesday, December 3, 2019 7:32 AM typo
    Tuesday, December 3, 2019 7:28 AM
  • > having their computers AAD-registered only with no Intune management

    First, just to clarify, these two are not mutually exclusive in any way. AAD registered systems can be managed by Intune just fine. To force them to enroll in Intune, use Conditional Access.

    Correct on the rest of the first paragraph although I don't think this is an official way or path necessarily, just the path that works.

    > Based on the facilities explored so far, there also appears to have no fast method to simply enroll it direct to Intune, so we have to AAD-unjoin and delete the entry, then perform a rejoin after the Intune license assignment. Is that correct?

    That works but isn't required necessarily. Users that have local admin permissions can enroll their devices in Intune and using Conditional Access, you can force them to do so by blocking their access to cloud resources like O365.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, December 3, 2019 5:13 PM
  • Yes I am aware a device can be AAD-registered and enrolled with Intune. That is exactly the reverse test case I tried with computer WIN10E-UNAUTO as illustrated above, by using my AAD account that is member of a group marked for MDM enrollment with Intune. The subsequent user who performed the AAD join did not have an Intune license nor inclusion into that group, thus no follow-up enrollment.

    The biggest thing that bites me is why a user who previously AAD registered and enrolled MDM with Intune cannot perform an AAD join at a later point of time, as with the above "This device is already enrolled." error. Furthermore, Azure AD did think the device became AAD-joined (as illustrated above), even though the client Windows 10 certainly knew it wasn't. It took a couple of days for Azure AD to eventually "realise its mistake" and revert it back as an AAD-registered device. It was necessary to use another account to perform the AAD join. These action paths are pretty counter-intuitive. Windows also doesn't make it clear the difference between the AAD join step and MDM enrollment step, thus no indication which sequence they happen.

    To clarify the reality of the situation, our company originally only had Office 365 and Azure AD Premium. Computers were issued to staff and they complete setup by signing in with their personal Microsoft accounts, then later adding their work account; thus the majority of them are AAD-registered with no MDM authority, since of course we hadn't subscribed for Intune back then. That's why the goal is to eventually join them to AAD and enroll with Intune, so they can be brought back inline with the future fresh computers which have the benefit of Windows Autopilot to streamline that setup process. Obviously we want to carry out the change with as little disruption and pain as possible for our colleagues.

    On further sifting, I learnt there is a method to perform an enroll-only action from a Windows 10 computer (although I did not find any specific doc page that lays out the exact steps to do so; only mentioning "MDM only enrollment"). I found at [Access work or school account] settings, there's a side option [Enroll only in device management]. Strange thing is, if I type "enroll" in the settings search bar, there's an [Enroll in MDM only] option that leads to nowhere when clicked on. I think it's a bug with Windows 10 not realising it should goto [Enroll only in device management]. I am planning to conduct test cases involving this procedure to see what exactly it can achieve.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral





    • Edited by icelava Wednesday, December 4, 2019 9:28 AM typo
    Wednesday, December 4, 2019 7:50 AM
  • [Enroll only in device management]

    Ok, I took a previously-retired test computer (no longer existing in Intune and a stale entry in Azure AD) to initiate the enroll-only action. It took a really long time for both Azure AD and Intune to show up the proper status of such a new device; Azure AD initially show it as Windows 1.0, while Intune couldn't determine the version. But the successful aftermath of that enrollment turns out as

    Azure AD

    Intune

    So a computer can "slip" into Azure AD without being registered nor joined; not related to any user, even though I used my AAD account to make the enrollment. Interesting. And enrolled to Intune with corporate ownership. Interesting. No compliance enforcement. Guessing such a device state is not very useful to work with; so gonna retire it, and test the pre-AAD-registered and pre-AAD-joined scenarios by a non-Intune user (not enrolled), then performing the enroll-only action.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Wednesday, December 4, 2019 10:52 AM
  • > So a computer can "slip" into Azure AD without being registered nor joined;

    No. Enrolling a system in Intune also registers it with Azure AD because Intune uses AAD for all directory operations.

    Don't confuse these three items: AAD domain join, AAD domain register, Intune enrollment.

    Intune enrollment requires AAD domain join or AAD domain register but is not the same as either of these.

    Also, to you point about there possibly being an issue with moving from AAD registered to AAD joined, possibly. I wouldn't call it a bug necessarily but possible a design flaw. Once again, this is not an intended scenario so just because you are facing this challenge doesn't mean it's something the products were intended to handle -- at least not directly. Thus the reason you need to unregister the device first and clean the slate.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, December 4, 2019 1:57 PM
  • Well as evidenced from the screen captures above, I managed to enroll the computer to Intune without AAD register or AAD join. Thus the entry in Azure AD has blank join type, while Intune side could manage it like other device under Intune's charge; could retire, wipe, restart, etc except not being able to fully evaluate the device's configuration for compliance.

    However, regardless of whether it can be done, it's apparent rather quickly that was not a useful device state to work with, so a raw enroll-only action to MDM/Intune without first registering or joining AAD is highly discouraged. I think Windows or Intune side should apply some stoppage to this particular procedure to prevent ending up in that state.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Thursday, December 5, 2019 6:53 AM
  • > I managed to enroll the computer to Intune without AAD register or AAD join.

    Not really. This is where things get a bit mottled and defintions become a bit flexible. The system is in fact registered, just not to a specific user. Intune registered it in AAD for you.

    > so a raw enroll-only action to MDM/Intune without first registering or joining AAD is highly discouraged.

    Nope, this is not a valid conclusion. There's nothing wrong explicitly with doing this. It's just a different path, but its still valid.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, December 5, 2019 5:14 PM
  • Ok, so we had AAD-registered, a user-centric state. And there's AAD-joined, a device-centric state. Now pops out another AAD-registered derivative that is not user-centric. If that is a valid use case, then AAD needs to write that down clear and proper in the Join type column, and make explicit mention of such possibilities in the docs. And even so, I am unsure of the particular scenario this state is designed for, otherwise I don't see any special benefit to being different from the usual AAD-registered+enrolled or AAD-joined+enrolled states.

    On a separate note, if AAD-join is device-centric, is it that important to list down the user who performed the join? (other than for record purposes)

    And as with the above test VM WIN10E-UNAUTO, it was registered with my Intune user, then joined with a non-Intune user. At that point, the computer name had a typo error "WIN10E-UNATUO", of which I can only perform an admin-side rename at Intune side. The computer received the directive and restarted itself with the new name. The outcome was Intune lists the new name, the AAD-registered record in AAD lists the new name, the the AAD-joined record retains the old name. Since AAD side has no facility to change name, it remains out of sync with the actual computer and Intune.

    I believe this is due to the AAD-registered record being the one enrolled to Intune as MDM authority. And AAD is unaware of the relationship between the joined and registered record since they sport different device IDs. This frankly does not seem proper; the services at that point could be smarter since they can tell from the HWID/serial number and realise it's the same physical computer.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Friday, December 6, 2019 11:13 AM word
    Friday, December 6, 2019 11:12 AM
  • On a separate note, if AAD-join is device-centric, is it that important to list down the user who performed the join? (other than for record purposes)

    No. As noted, this is no different than an on-prem domain join.

    I have no idea what's going on with the rename as that's not anything I've explored before and I think has changed over time.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, December 6, 2019 3:13 PM
  • To clarify the reality of the situation, our company originally only had Office 365 and Azure AD Premium. Computers were issued to staff and they complete setup by signing in with their personal Microsoft accounts, then later adding their work account; thus the majority of them are AAD-registered with no MDM authority, since of course we hadn't subscribed for Intune back then. That's why the goal is to eventually join them to AAD and enroll with Intune, so they can be brought back inline with the future fresh computers which have the benefit of Windows Autopilot to streamline that setup process. Obviously we want to carry out the change with as little disruption and pain as possible for our colleagues.

    So after much fiddling around different test cases with the Windows 10 clients + Azure AD + Intune, I think finally got a handle of what needs to be done.

    Starting point

    • Computer AAD-registered, with Office 365/AAD user.
    • No MDM authority.
    • No entry in Intune (naturally).

    Finish point

    • Computer AAD-joined, with Office 365/AAD user. (Same record)
    • MDM authority = Intune.
    • Listed in Intune devices (Windows).

    To get to starting point,

    1. Let user sign into physical computer with own personal Microsoft account.
    2. Connect Office 365/AAD account at [Access work or school]. This results in the AAD-registered record for that user/computer.

    To get to finish point,

    1. Assign Intune license to user.
    2. Connect same Office 365/AAD account at [Access work or school], but opt for [Join this device to Azure Active Directory] path. This is important because it will tie back to the existing AAD-registered record with the same device ID and thus edit that record. Another user initiating the join will result in a new record with a different device ID.
    3. Initiate [Enroll only device management] path at [Access work or school] with same Office 365/AAD account. (This step can be skipped if user included in AAD group marked for auto-MDM-enrollment).

    Thank you all for the information to piece the puzzle together.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    • Marked as answer by icelava Monday, December 9, 2019 11:07 AM
    Monday, December 9, 2019 11:07 AM
  • Does this process keep the AAD-registered User's User Profile?  Most of my users are currently AAD-registered but in order to use Enterprise State Roaming you need to be AAD-joined, I'd like to do so with minimal loss of profile data during the transition.
    Monday, February 24, 2020 8:39 PM
  • Yes, but it doesn't migrate or convert it as it's truly a different user logging into the system from a different realm/domain.

    but in order to use Enterprise State Roaming you need to be AAD-joined

    No. They can be hybrid Azure AD-domain joined as well but not simply registered.

    There is no built-in mechanism to transfer user profiles when changing the domain membership of a system to Azure Ad domain joined. Have you explored using Hybrid Azure-AD domain join for your systems?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, February 24, 2020 8:58 PM
  • Does this process keep the AAD-registered User's User Profile?  Most of my users are currently AAD-registered but in order to use Enterprise State Roaming you need to be AAD-joined, I'd like to do so with minimal loss of profile data during the transition.

    If you have AAD-registered computers, then it's likely your colleagues initially sign into Windows with their personal Microsoft accounts, then subsequently linked their Office 365 accounts. Those user profiles are based on their personal Microsoft accounts.

    After they've officially joined the computers to AAD, they should sign out of their personal Microsoft account sessions, and sign into Windows direct as Office 365 users. This will of course setup new user profiles (treated as new user in OS). Whatever data files they were working on should be placed in commonly-accessible locations and not in personal user folders. e.g. Corporate OneDrive, C:\common\


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Tuesday, February 25, 2020 9:22 AM
  • I'm disappointed I didn't find this thread earlier...though I see some new insightful responses from just this week. You'd think more would be in a similar scenario as ours particularly. We had Office 365 Business plan and just moved to M 365 + EMS. We took over administration of this so we didn't really know that every Office 365 tenant included AAD. So at first I was confused how we had most of our Windows users already registered but then came to the conclusion like you did that the end-users must have setup their devices with personal Microsoft accounts and then linked their work accounts. Not all are registered so I suspect the rest (just a handful) are setup with only local admin accounts...

    The whole AAD registered vs AAD joined is quite confusing especially when MVPs admit "things get a bit mottled and definitions become a bit flexible" and a general confusion when asking in other resources like the Intune channel in the Windows Admins Discord. I was misinformed and thought our transition from AAD registered would be a simple "flip the switch" - changing the MDM & MAM scope to the appropriate group. I never got a definite answer to some questions in the Windows Admin Discord so I wanted to test different scenarios that my end-users would experience:

    • Those that set up their devices with a Microsoft account
    • Those that set up their devices with a local admin account

    I did run across the issue when using a Microsoft account and then trying to join it. Someone suggested I try to company portal and that failed with the following flow once signed into the portal: "This device hasn't been setup for corporate use yet. Select this message to begin setup" then after selecting that message > "Your device is already being managed by an organization". 

    I'm just now testing the process/experience for those setup with a local admin account but I do think @icelava's steps are the best path forward.


    Thursday, February 27, 2020 9:52 PM