Today’s Challenge
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?
Today’s Solution
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.
Read More: Getting Exchange Online Distribution List Membership Counts with PowerShell
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#EXT#@contoso.onmicrosoft.com" | select
ExternalDirectoryObjectIdUpdate User Type
To modify the User Type from Guest to Member, run this command:
Set-AzureADUser -objectid <ExternalDirectoryObjectId> -UserType “Member”Update UPN
To modify the login ID from the Guest format to a standard format, run this command:
Set-MsolUserPrincipalName -UserPrincipalName
"JaneDoe_contoso.com#EXT#@contoso.onmicrosoft.com" -NewUserPrincipalName
"janedoe@contoso.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 janedoe@contoso.com -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 "janedoe@contoso.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.
License Account
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 "janedoe@contoso.com" -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.
My Conclusions
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.
I was so informed today that due to constant updates to the Microsoft 365 substrate, that if one follows the process outlined in the article in 2023, then there is a potential that the converted accounts won’t work with shared channels in Teams. We are unsure why at this time. Potentially synchronization of properties between Entra ID directory and Teams. So I caution using this process further since it is almost 2 years old now.
This caused big problems if you want to use a shared channel within your org as the concerted members aren’t seen a true members so cannot be invited, as it’s not supported by Microsoft they won’t offer any solutions, has anyone been able to resolve this problem?
Considering an M&A scenario, have you deleted the originating identity after converting the guest to a member? When you do that your converted identity will be deleted. Right?
It doesn’t delete the account if you delete the source account from the source tenant. The account remains in the target tenant and remains useable.
My concern is, if you leave Federated-ExternalAzureAD on the migrated account, are there any limitations or drawbacks to that configuration. Will it bite the org in the future!?
Cheers,
Bobby.
Hi Rich
I’m curious how supported and viable this method is since the account will remain as an “external federated account”. I’ve done everything I can to clear this with no joy. The idea of this is great and would save a lot of hassle. But my worry would be the linkage back to the source account.
Ignoring the fact that teams doesn’t support the conversion
If I was performing a migration with say quest on demand. I could
1. Convert target azureAD user to member and licence
2. Match accounts src/trg with questOD
3. Soft match the account with the migrated onPrem AD (optional if using ADDS)
4. Migrate and switch mailbox with questOD
With the migrated account as source being ExternalAzureAD surely this will have some long term consequences
1. Would deleting the source remove the target converted guest?
2. Resetting password in portals is blocked as it’s seen as a federated account. Does that mean SSPR would fail?
You can reset the user’s redemption status which will clear the federated “ExternalAzureAD”.
https://learn.microsoft.com/en-us/azure/active-directory/external-identities/reset-redemption-status
However, the user can always re-accept the invitation.
It would be nice to be able to clear the following attributes, Userstate and creationtype
PS C:\> get-AzureADUser -ObjectId 5e2cjb26-hc1790-0e1-ad23-0e5825aac74e | select Userstate,creationtype,UserType
UserState CreationType UserType
——— ———— ——–
Accepted Invitation Member
Running;
Set-AzureADUser -ObjectId 5e2cjb26-hc1790-0e1-ad23-0e5825aac74e -CreationType $null -UserState $null
does nothing.
Thanks Richard for the write up.
A few things to mindful of after converting guest to member account:
If the guest account accepted the invite, the converted member account will still have the federated “ExternalAzureAD” as the issuer.
From graph, https://graph.microsoft.com/v1.0/users/user@domain.com?$select=identities
“@odata.context”: “https://graph.microsoft.com/v1.0/$metadata#users(identities)/$entity”,
“identities”: [
{
“signInType”: “federated”,
“issuer”: “ExternalAzureAD”,
“issuerAssignedId”: null
},
{
“signInType”: “userPrincipalName”,
“issuer”: “domain.onmicrosoft.com”,
“issuerAssignedId”: “user@domain.com”
}
This means the user can authenticate with two different credentials.
Check out … https://docs.microsoft.com/en-us/azure/active-directory/external-identities/b2b-direct-connect-overview
Azure Active Directory (Azure AD) B2B direct connect is a feature of External Identities that lets you set up a mutual trust relationship with another Azure AD organization for seamless collaboration. This feature currently works with Microsoft Teams shared channels.
Be careful, this is not supported for Teams. Please check the note below from this article: https://docs.microsoft.com/en-us/microsoftteams/guest-access#licensing-for-guest-access
Note
Converting a guest account into an Azure AD member account or converting an Azure AD member account into a guest is not supported by Teams.
Hi Josue,
Thanks for the documentation from MS. When this article was written there was no such statement published. And to my knowledge while this may not be officially supported, I believe it continues to work as stated. I believe I even stated in the article, “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.”
I also suggest to any reader they also look into a new preview feature from MS that may solve some of their collaboration issues during M&A called B2B Direct Connect.
https://docs.microsoft.com/en-us/azure/active-directory/external-identities/b2b-direct-connect-overview
Great article, but what about the hybrid scenario where we have users synced from AD to AzureAD? Besides converting the user, should I create the same account on-prem and set-remotemailbox to the converted user’s mailbox?
Hi Michal,
During my original testing, I used a cloud-only Guest account, not hybrid, although the principle is the same in both cases. Start out with a hybrid guest user then convert it.
B2B Member is that really supported via the 1-5 ratio guest account license model? Or is this a grey zone when it comes to be compliant?
Hi Peter,
I honestly do not know, I would say it is a gray zone that would need to be tested.
I believe you have a typo on your first command get-user versus get-msoluser plus the ExternalDirectoryObjectId doesn’t exist as an attribute.
Thanks JVG,
Must have been a typo in the publication transfer. Thanks for calling it out.
Great write up. How about licensing the guest before conversion so that mailbox data can be prestaged? I believe we can license the guest for a mailbox and import data via impersonation.
The last time I tried this, the mailbox never was provisioned. Unless something has changed.
Great article Richard. Thanks for this!