Cross-Tenant migration and integration projects increasingly use Azure B2B guest users as part of Microsoft Business-to-Business (B2B) account functionality to provide a richer collaboration experience during the coexistence stage of a migration project.
During a Merger and Acquisition (M&A) event, Enterprise organizations will allocate some users as B2B Guest accounts so teams from both organizations may share and manage information during the business and technology integration.
During these events, administrators or internal users will invite different people from the acquired organizations to participate in discussions, schedule meetings, and share data from Microsoft Teams, Groups, and SharePoint sites. These external users which now have B2B Guest accounts in their directory will eventually need to be migrated. But before that, licenses will be needed in order to create their mailboxes and OneDrive containers in SharePoint before any data can be migrated.
This is a problem for B2B Guest accounts as they don’t recognize being licensed and can’t own a mailbox in Exchange Online. The guest account could be removed, and a new account created and licensed, but all the permissions previously assigned to files and shared resources would be lost, which causes other problems with email reply-ability and cached identities. And if the account is recreated, the end-user will be forced to manage two sets of credentials until they are fully migrated if they want to keep collaborating with the team members in the acquiring organization.
So how do we preserve permissions, keep collaborating without managing two sets of credentials while preparing the user account for data migrations?
The simple answer is conversion! This blog outlines how to convert your existing invited guest accounts to a standard member account to maintain the current assigned permissions, update the UPN and license the accounts to prepare for data migrations. And lastly, I’ll demonstrate how the access and collaboration experience for the user remains the same until the migration is finalized.
How to Convert to Azure B2B Guest Users to B2B Members
Microsoft presently supports inviting internal users to B2B collaboration where they remain as a member user type. Essentially, that is what I will demonstrate here, but in a different order. Instead of starting out as a Member User then sending an invite, we are going to start as a Guest Invited User but end up as a Member User that was originally invited to B2B collaboration; we will refer to this type of user as a B2B Member.
The conversion process is a multi-step process that can be executed through PowerShell, and the script you construct should consist of the key actions outlined in the remainder of this article. The commands below are only examples of how to execute these actions against a single user. Ensure you have the proper permissions and have installed the appropriate PowerShell modules, AzureAD, and MSOnline to complete these steps.
Start by logging into your target Microsoft 365 tenant with PowerShell where the Guest account currently resides. Before you get started you will want to get the Object ID for the specific Guest account you are going to convert to a B2B member.
Get the Guest Object ID
To find the external directory object ID of the given guest user, run this command:
Get-User -UserPrincipleName "JaneDoe_contoso.com#EXTemail@example.com" | select ExternalDirectoryObjectId
Update User Type
To modify the User Type from Guest to Member, run this command:
Set-AzureADUser -objectid <ExternalDirectoryObjectId> -UserType “Member”
To modify the login ID from the Guest format to a standard format, run this command:
Set-MsolUserPrincipalName -UserPrincipalName "JaneDoe_contoso.com#EXTfirstname.lastname@example.org" -NewUserPrincipalName "email@example.com"
Set the Usage Location
Before assigning a subscription plan the account must have a usage location assigned. To do so, run this command:
Set-MsolUser -UserPrincipalName firstname.lastname@example.org -UsageLocation "US"
Set a Default Password
To generate a random default password and force the user to change it at the next login, run this command:
Set-MsolUserPassword -UserPrincipalName "email@example.com" - ForceChangePassword $true
*Tip – This action may be run during the final cutover event if so desired. If your organization utilizes hybrid identity management, then I recommend you synchronize your Active Directory passwords to make the process easier for your users during the transition event.
To set a subscription plan for a user, in this example an E3 Enterprise Pack, run this command. Most contemporary migration solutions require the user to be licensed prior to data migrations, with some exceptions using native tooling.
Set-MsolUserLicense -UserPrincipalName "firstname.lastname@example.org" -AddLicenses "contoso:ENTERPRISEPACK"
Once the above actions are completed against the designated users, they are almost ready to begin migrations. The mailbox must finish being procured by Exchange Online and the OneDrive container must be provisioned either manually or using your chosen migration tool.
The Before & After Shots
Next, let’s take a look at the changes made to the user account from the Azure AD perspective. During my testing, I used a cloud-only Guest account, not hybrid, although the principle is the same in both cases.
Figure 1 displays the Guest account that has been invited to participate in B2B collaboration and the invitation was accepted. Also note the User Type is set to Guest and the User Principal Name is formatted based on how the account was initiated:
Figure 2 illustrates the same user account after the conversion has been run. The User Type has been updated, the UPN has been standardized and the invitation state remains the same:
What Does the User Experience Look Like?
To illustrate how a user’s access to shared resources between Microsoft 365 tenants is not interrupted during this process, let’s use an example of a Guest user collaborating in Teams.
Figure 3 shows our example user, Jane Doe as a Guest wherever her name is displayed. Jane can easily switch between organizations as illustrated in the right panel. Presently she is in a Team located in the target Microsoft 365 tenant where eventually she will be migrated. If Jane wants to connect back to her source Teams, then she can easily switch back between organizations:
In figure 4 Jane has been converted from an Azure B2B Guest User to a B2B Member. To her not much is different, she won’t see the word, “Guest” next to her name anymore but other than that she’ll be unaware of the changes that were made to her new target account.
Jane has retained all her access, all her chat history and lost zero functionality. In fact, when Jane is finally migrated to the target, all her access and history will remain intact, making her migration experience as smooth as possible while retaining previously granted permissions.
Things to Consider
Below are some questions around this process I hear asked frequently, along with my response:
1. Before the migrations are final could the user login to the target with their new account if they have the credentials?
Yes, it is possible. However, as with any Cross-Tenant migrations that is not recommended. Do not communicate or provide the user the means to do so until the correct time.
2. After migrations are final how do I prevent the source account from authenticating with the target tenant?
Disable, Delete, Delicense, or Deny Access to the source account as part of your migration workflow process. You could replace the account with a Mail Contact for mail routing purposes and delete the original account if possible. Otherwise, you may prevent the user from sign-in then decide how to deal with GAL visibility and mail routing.
3. After converting and licensing the target account, won’t I need to set a Mailbox forwarding for messages to route to the active mailbox in the source?
Yes, in most cases you will want to set a mailbox forwarding so any inbound mail for this account is delivered to the source mailbox while the user is still active over there.
Microsoft B2B functionality is here to stay, changing the range of options for setting up coexistence between tenants during an integration migration project. Before B2B came along, to grant access to shared resources in Teams and SharePoint, an administrator had to create a new set of credentials and the user had to manage switching between identities when needed – not an ideal situation.
Additionally, using your own source credentials to access target resources prior to the migration is a spectacular option for any future integration project and a great bonus.
However, I am not suggesting that you plan for all your Azure B2B guest users to be set up this way – I would only selectively use this method. Isolate it to power users that require this level of rich collaboration. But it is nice to know when this use case does come up, there is a method you can now use to easily manage the account to meet your needs.