Microsoft Teams Room migration: on-prem AD and existing O365 room mailboxes

DerN 1

Hey everyone,

We're in the process of upgrading our meeting rooms to Microsoft Teams Rooms and are running into a question when it comes to where the 'room' accounts live.

We have current Room/Resource mailboxes set up for all of our rooms - those live in O365. But we also have on-prem AD.
As we understand it, in order to make use of MS Teams rooms, those room mailboxes now need passwords assigned to them.
As we have on-prem AD which syncs to Azure AD via AAD Sync, we know we have to create the room mailboxes with passwords in our on-prem AD and then sync them to O365.
The problem then becomes that we have 2 room objects.

In our testing, O365 seems to have "linked" the 2 identical accounts together in one case but in another case, there was a "duplicate attribute" sync error.
As you can see, we've had mixed results and could use some clarification.

Can the room accounts somehow live both in on-prem AD AND in Exchange Online and will O365 sort this out automatically?
Or will the O365 room account need to be deleted in favour of the on-prem AD account and all calendar entries migrated to the new room account syncing from on-prem AD?
What is the "recommended" way of setting up Teams Rooms accounts when you have on-prem AD but online everything else? (and when the room accounts already exist in O365)

We've been following these 2 KBs but neither fit our scenario perfectly.
https://learn.microsoft.com/en-us/microsoftteams/rooms/with-exchange-online
https://learn.microsoft.com/en-us/microsoftteams/rooms/with-exchange-on-premises

Any insight would be appreciated!

Yuki Sun-MSFT 40,871 Reputation points

2022-01-26T06:21:09.417+00:00

Hi @DerN ,

What is the "recommended" way of setting up Teams Rooms accounts when you have on-prem AD but online everything else? (and when the room accounts already exist in O365)

From your description, you already have room mailbox accounts set up on Exchange Online, right? If this is the case, per my understanding, the first KB you mentioned above fit your scenario better. So basically you would need to change the settings for the existing room mailbox, add an email address for your on-premises domain account, run a directory synchronization and verify that the two accounts have merged via the user's page, then assign an Office 365 license.

As regards to the mixed results in your testing, as mentioned above, theoratically the 2 accounts would be merged after the directory synchronization completes, this is the expected behavior. For the case where you saw the "duplicate attribute" sync error, could you double confirm if you were following the steps correctly? If there are more detailed error message, you can also share it here after removing all private information.
DerN 1 Reputation point

2022-01-27T23:08:16.74+00:00

@Yuki Sun-MSFT thanks for the response!

Just got a chance to confirm the process and it looks like the accounts are not merging properly.

It's getting tripped on the 'assign Microsoft License step'

I run the powershell command but then it complains about proxyaddresses.

(Screenshot attached)

Any idea how I can force the 2 accounts to merge?

Any more info that you would find helpful?

And yes, I'm aware I am assigning an E3 license to the account and there is a better license for this but for now, I am using an E3 license.
Other rooms we have are also using E3 without issue.
Yuki Sun-MSFT 40,871 Reputation points

2022-01-31T06:09:20.977+00:00

Hi @DerN ,

Just got a chance to confirm the process and it looks like the accounts are not merging properly.

May I know how you confirmed that the accounts were not merging properly?

As stated in the KB article, a directory synchronization needs to be run after creating the on-premise account. So have you run the Set-MsolDirSyncConfiguration command in PowerShell to force the synchronization?
DerN 1 Reputation point

2022-01-31T22:05:15.23+00:00

May I know how you confirmed that the accounts were not merging properly?

There are 2 objects of the same name appearing in our Azure AD. One is listed as 'directory synced' and one is listed as 'cloud'.
If they had merged, there would be 1 object present, not 2.
Both user objects in the O365 admin panel as well.

As stated in the KB article, a directory synchronization needs to be run after creating the on-premise account. So have you run the Set-MsolDirSyncConfiguration command in PowerShell to force the synchronization?

Yes, a sync from our AAD server has been run. We know this sync has run properly as the on-prem user object is appearing in Azure.

At this point, I have no idea what could be going on. We are running the steps exactly as stated in the KB article but it's not behaving as expected.
We may be forced to delete all objects and create fresh rooms however that is less than ideal.
DerN 1 Reputation point

2022-02-02T16:30:39.773+00:00

May I know how you confirmed that the accounts were not merging properly?

Yes, there are 2 objects of the same name in Azure whereas if the accounts had merged, there would be 1 object, as observed when doing this previously.

As stated in the KB article, a directory synchronization needs to be run after creating the on-premise account. So have you run the Set-MsolDirSyncConfiguration command in PowerShell to force the synchronization?

Yes, a directory sync has been run from our AAD server.
Yuki Sun-MSFT 40,871 Reputation points

2022-02-04T00:28:43.603+00:00

Hi @DerN ,

Thanks for the clarification. Sounds like for the problematic accounts, something went wrong during the synchronization and merging process.

Then I tried searching further regarding this issue but hardly find additional information about how to deal with this situation occurred when deploying Teams Rooms with Exchange Online. This document includes some potential solutions for object sync issues, while room mailboxes are not explicitly mentioned in the article, I assume you can have a check and see if it can help solve the duplicated proxyaddress issue. In case the problem remains, considering that it could be quite time consuming to troubleshoot, personally I suppose it might be more efficient to delete the problematic objects and deploy new room mailboxes.