SOLVED

External connectivity not working for older Azure AD users

Brass Contributor

Hello everyone,

 

As title says we have issues with external connectivity for Azure AD users.

 

Some time ago we switched to MS Teams, and to make user life a bit easier we integrated on-prem AD with O365, so users can use same password everywhere.

 

The issue is that accounts made in Active Directory are unable to IM external users (message, add, call basically anything). Those users also does not show up in Teams admin center, only users made in O365 (how long we should wait for the accounts to propogate?). Search user externally dont show up when searching external users.

 

O365 accounts dont have that issue and connectivity is fully functional. Both types use MS Teams commercial cloud licenses. We tried to manage licenses from Azure (take off Teams license from O365 and add it from Azure). Can anyone advise?

 

Any additional information can be provided if needed.

 

EDIT: We created few test onprem accounts that were synced to AzureAD. They are working, for some reason it looks like only fresh accounts work (and show up in Teams admin center). Older dont.

Also we are using onpremise Exhange server.

 

18 Replies
Do the AD synced users have the same UPN suffix as cloud-only users? e.g. are all users signing into 365 with username@company.com - or do the synced users have username@company.onmicrosoft.com userids?

Hello @Rob Ellis , thank you for the reply.

 

Synced users show up with onmicrosoft.com. After they show up we changed the suffix and add the licenses.

We made a test account on whom we left the default suffix, it does not work aswell.

I assume you changed the suffix in on-premises AD, then waited for another sync?

@Rob Ellis Suffix on our AD is .local, we left it like that. Should that be changed aswell?

If you are trying to external chat with people in other tenants and you set it up in yours, and Teams is working etc. you just can't external chat, I would suggest checking what your Teams upgrade coexistence mode is set to.

In order to use External chat from Teams, you must be in Teams Only mode, you can change individual users to Teams Only as well, but either way, the user initiating must be in Teams Only mode in order to use External chat. Make sure you aren't set to Islands, and or one of the Skype modes. Obviously, only change it if you know the risks involved of changing. If no one is using Skype in your org then just change to Teams Only should be fine :).

Hello @Chris Webb , thank you for your reply.

 

External connectivity is enabled and Coexistence to Islands but we are testing connectivity with external Teams users.

As per @Rob Ellis suggestion we created a new AD user and set the routable logon suffix (not .local like it was before) and external connectivity started to work (a few hours later). We changed the logon suffix for some users but for now only the first account is working, so we are waiting for the External connectivity to appear if thats the case (due propagation).

 

I have a question - why on-prem domain logon suffix fixed connectivity for the first account?

Other thing - when we set routable suffix to other users they still dont appear in the users list in Teams Admin center. First account showed up with status DirSyncTeamsUser.

I suspect it might be because external federation (e.g. the ability to chat with other organisations) is not supported for users with a company.onmicrosoft.com SIP address - only for those with company.com SIP addresses.

@Rob Ellis, Looks like that is not the case, we tried one of out company.onmicrosoft.com accounts. External connectivity works on it.

For now I guess we should wait for users with changed suffixes to show up (hopefully). If they dont then it looks like only new on-prem AD accounts show up for some reason.

That user that is working might be set to Teams Only coexistence. External chat will only work when in Teams Only. It’s possible the policy for that person didn't get full pushed correctly and it’s allowing it but islands mode won’t allow it.


How are you testing? I’m assuming you are trying to chat with someone from these accounts outbound and not testing inbound?

It looks like the policy is not fully pushed.

Yesterday we made 2 test accounts in on-prem AD. One with .local suffix which was changed to company.onmicrosoft.com and .com suffix which remained like that after Azure AD sync.

 

Both accounts can IM external Teams users. Coexistence mode is set to Org-wide which is Islands. Very strange because these are only accounts that can IM external users (theres actually third account that we made for our new user). So it looks like it only works for the new users (these users also show up Teams admin center). Old onprem AD accounts dont work.

 

Accounts with changed logon name .com still dont work. And we test using external O365 Teams user who also integrated Onprem AD with O365.

Why would you not be Teams Only mode? if you aren't using Skype for Business, you want to change that, it will spare you headaches going forward unelss there is a reason to be in islands.

Hello @Chris Webb, changed it to Teams only yesterday. Still is not working.

Also we are using on premise Exchange, when making those 2 test accounts we didnt create an email box for them. Could Exchange interfiere with the setup?

It shouldn't. It will restrict features in Teams itself but shouldn't matter with External Chat. Due to the fact it's not provisioning your users in Teams seems like there is an attribute somewhere on the old accounts keeping it from being created. Assume your old accounts are changed from .local like you did the new accounts?

Also if you haven't checked yet, make sure your old users have Skype for Business Online licenses assigned. Since you were onprem you may not have had those activated. Those are required for Skype Online accounts to generate and also required for External chat. It's still a requirement for Teams deployment as well.

@Chris Webb Thanks for the answer, I will look into it.

 

Account logon suffix has been changed from .local to .com. Any idea why new accounts work without SFB online licenses? We only have MS Teams Commercial cloud licenses.

 

One other thing - before teams there was a SFB 2019 in our domain from which we first removed SIP accounts and then deleted the servers. Could that interfiere with old AD accounts and external connectivity?

Yeah. You probabaly have some kind of AD attributes preventing creation on cloud side on old accounts. What to check I’m not sure. I’ll have to poke around. I haven’t messed with many onprem to cloud moves. If it wasn’t removed clean it might still think via AD it is.

Hello @Chris Webb . It looks like that is the case. In order to enable them in teams we need to migrate accounts from SFB to Teams. Im having some issues with that but I will try to solve it.

best response confirmed by James1 (Brass Contributor)
Solution

Hello and thanks to everyone that contributed to this post.

 

I managed to find the issue. It was indeed related to previously used Skype for Business. When a SFB user is created, a certain attributes are added. And those stay until they change (for example if user migration are used ((didnt work for us since SFB servers were deleted)) or until they are removed.

 

What happened was there was a conflict with those attributes. Teams "thought" that we still use SFB due to these previous SFB msRTC attributes. Once removed after a while External connectivity appeared.

1 best response

Accepted Solutions
best response confirmed by James1 (Brass Contributor)
Solution

Hello and thanks to everyone that contributed to this post.

 

I managed to find the issue. It was indeed related to previously used Skype for Business. When a SFB user is created, a certain attributes are added. And those stay until they change (for example if user migration are used ((didnt work for us since SFB servers were deleted)) or until they are removed.

 

What happened was there was a conflict with those attributes. Teams "thought" that we still use SFB due to these previous SFB msRTC attributes. Once removed after a while External connectivity appeared.

View solution in original post