Automating Migration from AD to AAD (Non-Hybrid)

Brass Contributor

I promise I've Googled as hard as I can and can't find the answers to what seem like some pretty simple questions...

 

I've got a bunch of digital signage and point-of-sale devices that I want to migrate from AD/SCCM to AD/Intune. They log in with local accounts. I don't want to mess around with hybrid, I just want to cut them straight over with as little effort as possible.

 

Manual method I'm pretty sure will work:

1. RDP into each one

2. Disjoin it from AD (have to enter a domain account with disjoin privs)

3. Uninstall the SCCM client

4. Use a bulk enrollment provisioning package to join to AAD

5. AAD automatic enrollment to Intune

6. Done

 

This will be a pain though, so I'd like to automate it. I think I can use SCCM to install the AD-join bulk enrollment provisioning package and it shouldn't be a problem using SCCM to uninstall itself and I should be able to configure SCCM's AD discovery to exclude these devices so SCCM doesn't try to re-absorb them while I'm working on disjoining them. Then, finally, I think I can use some powershell remoting and the remove-Computer cmdlet to disjoin the devices and pass in the creds that have privileges. I'd disjoin with SCCM but I don't want to put those disjoin creds in a script.

 

Question:

1. Can I join an AD-joined device to AAD? Can they exist simultaneously for a few days without any hybrid configuration?

 

2. Is there a better way to do this?

 

Thanks,

Dan

 

 

 

3 Replies

@365vCloudas mentioned, I want to avoid hybrid. I don't want to connect anything that I'll have to disconnect and tear down later when on-prem gets taken out back.

 

FWIW - I do have a working model for automated AD disjoin and AAD re-join. Basically, I'm doing an invoke-command and a script block to send a few commands to the device which builds a scheduled task to join AAD on next reboot via a bulk deploy provisioning package then a remove-computer command with domain creds to remove the device. I'd do all this with SCCM but I don't want to put any credentials in the script or pipeline for this.

 

So on migration night, I run this script on each device which sets up the scheduled task to join AAD after it disjoins AD and reboots. I had to use the scheduled task because it's really hard to do any kind of powershell remoting once it's disjoined from the domain... lots of WinRM errors that got ugly trying to work past. 

@DanWheeler 

I swear there's not enough documentation out there and whatever bits there are, it's mostly only very specific to that one step and not as a whole migration. To answer your questions:

  1. Joining an AD device to AAD IS by definition a hybrid setup (Hybrid join). They can co-exist indefinitely. I've done a couple and the devices have been hybrid for years. I'm not a big fan but if the business is saying it wants to move to the cloud while at the same time not wanting to upgrade its legacy and on-prem apps, you have no choice.
  2. See below.

This is the method that I've used on a few environments and works well:

  1. Create an Intune dynamic device group with the ZTDId rule (Google this)
  2. Setup a user driven Autopilotot profile and assign it to the group in step 1
  3. Do this (again, why this isn't common knowledge is beyond me):
    https://euc365.com/enrol-devices-to-autopilot-unattended/
  4. Push the script out to all your devices. I used our RMM tool to push the script to all our devices but you could use GPO
  5. Send a wipe command to all devices. I used this command and pushed it with RMM:
    https://techcommunity.microsoft.com/t5/windows-deployment/factory-reset-windows-10-without-user-inte...
  6. Let the user enrol and sign into the device themselves. This might come as a shock to some but if you want to move forward, this is how it will be done (almost like zero touch on mobile). If Outlook breaks again, it's not worth spending hours trying to fix it, just send a blat command with Intune and let the user re-enrol from home.