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.

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?

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.

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.

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.

Thanks JVG,

Must have been a typo in the publication transfer. Thanks for calling it out.

Hi Peter,

I honestly do not know, I would say it is a gray zone that would need to be tested.