Tenant to Tenant Intune Device Migration Part 7: Go Time

Today we’re going through the entire migration process, step-by-step. If you’ve been following along, you should have all the required files including the scripts, tasks, and provisioning package. We’re going to deploy the migration app with Intune in Tenant A, and then watch the migration to Tenant B.

All the files are now available in the Intune migration repository, here.

Wrap it up

Place all of your migration files in one directory, and then use the Microsoft Win32 Content Prep Tool to create the .intunewin app package.

Upload the app to Intune in Tenant A and use the following for the install command:

powershell.exe -executionpolicy bypass .\StartMigrate.ps1

For the detection rule, just use the flag we create in the StartMigrate script.

Set the assignment as available to a user group. In my case, I’m using a user group called “Migration Users” and just adding members manually.

*For step by step instructions on packaging an Intune Windows app, read here.

The existing device

Let’s take a look at the state of our current device in Tenant A, logged in as steve.weiner@rubixdev.com.

Click on each image for more info.

Essentially, you can see the lock screen, signed in account, desktop shortcuts, and app settings- all things you would expect from a PC in use. To begin the migration, we’ll launch the Company Portal.

An end user can click “Install” to start the process. At this point, the StartMigrate script will run, unpacking it’s contents and going through the pieces we’ve compiled. When it’s finished, the user will see a notification about being signed out, followed by an automatic reboot.

We’re not in Tenant A anymore…

When it starts back up, the device will sit for 30 seconds, followed by another automatic reboot. Notice the lock screen image has been reset to default.

Once the device comes back after the 2nd reboot, you can see all of the Tenant B policy coming over from Intune. We’re still keep the “Other user” setting so there’s no mistake that a user has to log in with Tenant B credentials. I’m now signing in as steve.weiner@stevecapacity.com.

At the desktop, more things are already kicking in. We can see the new user credentials in the account settings along with the updated desktop background image. Even though all my user data has not come over yet, I can get right to work with Microsoft 365 apps like Outlook.

Before the next step, we’ll check Intune in Tenant B. It shows us the device is enrolled in, but the primary user is empty- this is because our script didn’t run yet.

Bringing it all back…

After the RestoreProfile script runs, we will see the prompt for the last reboot. But before that happens, check out the desktop folder which has been restored from the original profile.

*I scrapped the wallpaper so it would be easier to see everything, as the awesome 80’s vibe makes things a little busy.

After the last reboot, you can see we’ve re-enabled allowing the last signed-in user to be displayed at the lock screen.

From here on out, things are pretty smooth. All the files have returned, including the AppData folders. When I launch VS Code and Chrome, all settings have come back. You can even see the account still present in Chrome, the sync will just be paused until I sign in again.

After a bit, we can go back to Intune and see the primary user has been updated, the BitLocker recovery key is there, and we’re registered in Tenant B Autopilot with the proper group tag.

You can even log into the Azure portal and see the device associated with the appropriate user and Intune device objects.

Check the logs…

This process was fairly painless, but things can go wrong. If a script didn’t run, or something didn’t behave the way it should, navigate to C:\ProgramData\IntuneMigration and you should see a migration.log and post-migration.log file.

The migraiton.log covers everything leading up to the Tenant A exit. Post-migration is created the moment after the first reboot. In here, you can see everything happening including the tasks running, data migration, Azure leave, etc.

Are we done?

So is that it? Well, yes and no. As of now this process works great for migrating a PC from Azure AD to Azure AD. But there are some more things in the works, including:

  • Hybrid Azure AD to Azure AD

  • Domain Joined to Azure AD

  • Co-Managed to Intune

  • SCCM only to Intune

  • Tenant to Tenant migration WITH new hardware

And that’s just to name a few. I’m also working on a video walkthrough that should be on our YouTube channel in the next week or so.

Also, you’ll notice in most of the screen grabs from my Virtual Machine, I left the time visible. We started at about 6:51pm and ended by 7:12pm. From an end-user perspective, that’ just about 20 minutes; not too shabby.

Thanks for following me through this and have fun migrating!

Steve Weiner