When performing an Office 365 Tenant-To-Tenant Migration, the goal should be to migrate everything possible with minimal user disruption, including devices. Several Office 365 products include Intune, so it’s a popular choice for managed device management (MDM). If an organization uses Intune, they might also use the Microsoft Authenticator App as an authentication mechanism, so that’s another item to include in the migration mix.

Authentication Tokens and Timeouts

Whenever an app connects to Office 365, they authenticate against Azure AD. Following successful authentication, Azure AD issues a security (access) token. When the access token expires or an Azure AD critical event occurs (like a password change), the user must re-authenticate.

Long-lasting tokens allow users to open Outlook on their mobile device and not need to re-enter credentials. Because tokens can last a long time, it is important to protect apps with multi-factor authentication (MFA).

Another important concept for tokens is refresh periods. The refresh period acts as a check-in process to ensure that the user’s token remains valid. Events like a password change and certain authentication settings can trigger the refresh process to invoke re-authentication.

The default session timeouts for different apps are documented by Microsoft. Durations differ depending on the connection method. Some of these defaults can be changed and are outlined in the documentation link above.

During a tenant-to-tenant migration, access tokens should be revoked to avoid the possibility that user devices continue to connect to the source tenant. This avoids the possibility of user frustration and help desk tickets caused by connecting to the wrong tenant.

Azure AD’s refresh token process can catch some of these situations if you change the user’s password or take other actions to force reauthentication. However, many administrators, particularly if they are moving a domain from one tenant to another, do not change user passwords at first. The reasoning for this is to give the user a fallback path to the source tenant. In a week or two, they will block access to the old accounts, but not right away. Administrators should force users into the new tenant during an Office 365 tenant-to-tenant migration.

Migration Steps

The reality is you will not migrate Intune Devices. Instead, you remove devices from the source tenant and enroll them into the new tenant. While not ideal, the setup process for Mobile Devices is usually very intuitive.

While this concept is simple, the timing of when to force users to reconfigure is critical to avoid issues. The options also depend on your project design.

How To Revoke Sign-In Tokens

Revoking sign-in tokens is the same as selecting the “Initiate Sign-Out” option in the Microsoft 365 admin center. This invalidates all tokens for the user and prompts the user to log in. This includes desktop apps, browsers, and mobile devices. Revoking access is often used when a user is terminated, or an account is suspected of being compromised. In these situations, HR & Investigations teams are often involved to protect the organization.

If you are migrating users in a Tenant-To-Tenant migration, the migration software likely has a reconfiguration agent for desktops. I still recommend using the Initiate Sign-Out command in conjunction with desktop reconfiguration applications. This acts as a backup method in case the desktop reconfiguration application is not on their device, and it will cover mobile devices which typically do not have a reconfiguration option.

If you are moving users from one tenant to another as part of a Domain Migration, you should perform the steps below before you remove the domain from the source tenant.

After the command below is run, users are prompted to log in again. The user simply puts in their credentials, and the “first run” experience will go from there. If you use other security products or enrolment options, the enrolling user will be treated as if they were a new employee.

In terms of user communications, you can inform the user that at the start of the migration window, they will be forced out of all applications. At the end of the migration window, they can follow the very similar directions that new employees follow in the target tenant.

You can force the initiating sign-out / revoke tokens in the Microsoft 365 Admin console, via the Graph API, and in Powershell.

RevokeSignInSessions Graph API Command

The use of the Microsoft Graph RevokeSignInSessions API is outlined in Microsoft’s Documentation. This is the preferred method for revoking tokens/ forcing sign-out in bulk.

For example, to revoke all login sessions for Mary@contossos.com, you could run this command:

POST https://graph.microsoft.com/v1.0/users/mary@contoso.com/revokeSignInSessions

You can also run the same command using the ID of the Azure AD user account, which is a 25-character GUID:

POST https://graph.microsoft.com/v1.0/users/[GUID]/revokeSignInSessions

Another way to revoke a user’s access token is to use the Invoke-MgInvalidateUserRefreshToken cmdlet from the Microsoft Graph PowerShell SDK. Here’s how the command works. The Graph SDK is a good way to run Graph commands in PowerShell without having to get too involved in the minutiae of how Graph API and requests work.

$UserId = (Get-MgUser -UserId Mike.Weaver@Practical365.com).Id
Invoke-MgInvalidateUserRefreshToken -UserId $UserId

After Azure AD revokes their access token, users must sign in to secure a new access token. Any new controls that exist are applied at that time.

Microsoft Authenticator Impacts

For firms that are ”all-in” on Microsoft, including Intune & Microsoft MFA with the Authenticator app, users will need to set up their MFA profiles again. For firms that have different MFA providers in their source tenant than their target tenant, they will find additional complexity with user communications. In this section, we will cover Tenant-To-Tenant impacts for firms leveraging Microsoft Authenticator for their MFA solution in their source & target environments.

For firms in a tenant-to-tenant migration, you need to decide when the right time is for users to set up their profiles again. Many will take an approach depending on if they are moving the user’s domain over the weekend or not.

If you are not migrating the domain, it is a great option to ask users to set up their Authenticator App before the migration weekend. This will allow them to set their password and have a major barrier out of the way. This will reduce help desk volume spikes on Monday morning and allow users to set up their accounts slowly in the weeks prior to the migration.

If you are migrating the domain, then this pre-setup can be a bit more complicated. Users can enroll with temporary user names, including the MOERA address (commonly referred to as the .onmicrosoft.com address). This is not the most friendly method, but it will allow the password to be set. When the domain is moved, you can change the UPN of the users, and it will not impact their Authenticator enrollment. For firms that think their users can tolerate this temporary domain issue, they will significantly reduce the amount of help desk tickets on Monday regarding password resets.

Both of these methods may cause some confusion as the old tenant will still appear in the authenticator app until it is removed.

Conclusion

Mobile devices are some of the most requested help desk items in a Tenant-To-Tenant Migration. It is often just as important to our users as their desktops, particularly for employees on the go or in hybrid working environments. Solutions like Microsoft Intune give organizations a lot more control and options. In a Tenant-To-Tenant Migration, it adds another aspect to the migration.