You’ve probably noticed by now that a lot of the action about the Intune device migration solution is happening on the GetRubix YouTube channel. It’s not because I don’t love rambling here, but a lot of these concepts are just easier to show, rather than tell.

Since we’ve been flinging updates out to this solution faster then you can say “bulk provisioning”, it seemed appropriate to put together a list of all the new features and components that have been added since the V1 solution. So here you go.

*Most of these are either already available in our GitHub repo or will be added shortly.

Premigration

In the V1, the entire migration process is run in one shot. This generally works for situations where user data is not an issue and we’re just moving between Azure (Entra) environments. However, there has been a demand to solve for the device existing in various source states, and the need to move larger amounts of user data. In order to plan the best workflows for different device scenarios, we needed a way collect data and analyze prior to performing the migration.

Now, we run a ‘premigration’ script that does just that. We’re using Azure blob storage to capture device information, determine the current device state, and calculate how much user data needs to be migrated. Then, if need be, we can use that blob storage to back up the user data so we’re not taking up additional storage on the device.

New Hardware

When I first heard the ask to migrate between tenants with a new PC, I thought, “why”? In theory, that should be the easiest path as you can just deploy a brand new Autopilot device and have the user sign in with destination tenant credentials.

But wait- ah yes, the user data. We would need a streamlined way to maintain files, folder, and most importantly, application data like preferences and settings. So using the blob storage method, we can pull down the information on a new device and restore the data to the new user profile. Unless…

Peer-to-Peer

Two months ago, I was asked if there’s a way to migrate user data directly to a new PC in the destination tenant from the old PC in the source tenant over the user’s local network. This was intriguing.

We would have to take advantage of our premigration script and stage a file share with brand new credentials on the local machine that have read rights to that data. Once captured, we store the information in blob storage. When the new PC is deployed through Autopilot, it can retrieve the old device info, and then proceed to create a mapped network drive and move over the user data. And as long as the user left the original PC on and connected to the network, it worked!

The Ghost Account

Not all updates are sunshine, rainbows, and cotton candy. We have to fix the things that are broken. And the most broken part of the solution was after the migration. When all was moved over, if you peak in the account settings, you would most likely still see the source account just sitting there like this.

Even though it was harmless and not really connected to anything, we couldn’t just leave it there. That’s gross.

The solution ended up being fairly simple. You see, those are considered MSAL accounts, and they are stored in a very special file located at %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_*s0meR3alLyl0ngGU!dG03Shere.

We tried deleting this file in between tenants, but no luck. The answer turned out to come from a suggestion by one of our Discord community members, @Karlmit. Since it lives in one of the AppData locations we backup, all that had to be done was exclude it from the robocopy function:

Domain Unjoin

While the V1 only accounted for Azure AD joined devices, we can now remove devices that are domain joined. This is handled via a check for DomainJoined status via dsregcmd /status output, and then we just inject temporary credentials so the script can perform the unjoin.

Toast

I love toast. Not just the crunchy bread with butter or jelly, but the Windows toast notifications. Toast notifications have always been a struggle to run as system, because they really need to be executed in user context. But now, with the help of the RunAsUser and BurntToast PowerShell modules, we can build in some custom toast notifications to key areas of the process where we want to communicate with our end users.

What’s next?

This is just the start. The more we use this solution, the more needs we uncover, which then leads to more features. Here’s a look at our short term list that we’re working on next:

• Improved migration logging

• Migrating from MECM (SCCM) and co-managed device states

• Alternate security options for source code, including secrets stored in key vaults and device certificates

• Real time progress tracking visible in the toast notifications

• Premigration data stored in an active Cosmos DB database for review

If you’ve been testing this solution, then thank you and let us know what feedback you have and ideas you’d like to see implemented in the future.

And if you want to chat, come see us over at the new GetRubix Discord server.