Meetings I create from Outlook as Teams meetings sometimes (not always) reuse the same 48-character alphanumeric hash, found in each meeting URL. Via MS Audio Conferencing, they also reuse 7-9 digit numeric conference ID. The meetings are always new Teams appointments, not forwarded or manually recycled in any way by me. Is there a way to prevent this happening?
@TomDarlingFernley-6005 we found out a file which contains the next meeting id is stored for each user in C:\Users[username]\AppData\Roaming\Microsoft\Teams\meeting-addin\Cache.
When you create a Teams meeting in Outlook or in Teams this file is renewed and will contain the new Meeting ID.
Problems with the synchronization of the user profile probably causes issues with the renewal of this file. This could explain why the same meeting id is used in other meetings. We are currently fixing the synchronization issues in our company, I will post an update if this fixed the issues with the meeting ID for us.
Thank you very much! I'll watch for updates. Our IT did discover that quotas weren't being applied correctly to user profiles, which in turn meant they weren't synchronising correctly. This fault was fixed about 1 month ago and in parallel this meeting ID problem hasn't recurred, at least for me.
I just created a new Teams meeting in Outlook and watched the file in the folder you've cited regenerate a new file with a new hash.
Have marked this as Accepted because it seems to be the correct diagnosis. Not definitive, but confident. Thanks again.
I am a colleague of @MauriceKleinWoolthuis-9171 and can confirm that our issues were solved after we stopped roaming the Teams part of the roaming profile.
Looks a bit silly the developers decided to store "the next meeting-id" in a file that is cached and moved between network and computer.
You can reproduce your issues by editing the meeting-id in that file and enter an old one, you will see your meeting being re-used.
Hello,
From Teams Admin center, change the settings as shown below and see it helps. Suggest you to set as Replace Caller ID with 'Anonymous'
Regards,
Manu
Thanks Manu. I don't think I was clear - this isn't connected with caller IDs or the anonymity of meeting participants.
When I create a New Teams Meeting (in my examples via the Outlook calendar), a hyperlink is inserted into the invitation message body. This long link contains a 48-character hash, e.g. NWNhMTNmNzYtODFiDS00MTg2LWFkNjItMjdlMzk3MmRiNDRi. The link is used by participants to click to join the meeting, and also relates to the Join Teams Meeting in the Teams Meeting group on the Meeting ribbon of an Outlook appointment. Over the past few months, on six occasions, Teams has assigned the same hash to unconnected meetings.
For example, I may create and send 'Team Meeting' on 1 April. Then, on 5 April, I create and send 'Client Conference' as an entirely separate appointment at a different time and involving different people, but it somehow picks up the same hash/link as 'Team Meeting'.
Hello,
Thanks for explaining it better. I don't find a way to set something like 'Generate Random Link always'. Teams doesn't have much PowerShell support to check these kind of settings.
If you finds this an issue, probably you may need to raise a ticket with Microsoft. If it really happens, I am sure that it is a Teams Bug :(
Regards,
Manu
Hi TomDarlingFernley-6005,
The conference ID is set to Dynamic by default. You can reset the conference ID for a user in Microsoft Teams admin center. For more information, you can refer to this link: https://docs.microsoft.com/en-us/MicrosoftTeams/reset-a-conference-id-for-a-user-in-teams.
@TomDarlingFernley-6005 at our organisation we also face this issue. We started using MS Teams last March (using Islands mode) and users have been reporting the same issue since. In every case the Teams meeting was created in Outlook365. As it only occurs sometimes it is difficult to reproduce. We have reported the issue to Microsoft and we also got the instruction to record the issue with the Steps Recorder. So far we have not been able to record the issue when it happened. Due date of providing evidence of this issue to Microsoft is set to July 2.
Also check 1180135 for this issue
4 people are following this question.
