Nov 21 2022 12:36 AM - edited Nov 21 2022 12:38 AM
Hello,
we discovered the following problem with our MTR devices in all our meeting rooms:
When does it appear?
The problem:
The "Join" button on the MTR device in the meeting room is not present. It is also not present in the Outlook calendar of RoomA.
More information:
The link to the meeting is present in the calendar entry of RoomA.
The "Join" button is present for User1 in his Outlook Calendar.
The "Join" button for RoomA appears, if the external org updates the meeting.
What we discovered so far:
Is this a known bug? I did find similar problems but not exactly the same as this. And all of the solutions did not appear to be helping my case.
Someone any ideas what we could try next?
Thank you.
Nov 21 2022 05:06 AM
Dec 01 2022 06:28 AM
SolutionDec 08 2022 02:56 AM
Thank you for your support in this case.
I looked into the MAPI properties of the invite in both calendars (the user's calendar in my organization and the calendar of the meeting room ressource) with an Outlook AddIn called OutlookSpy.
Since the one in the user's calendar is working as expected (with a Join Button present in both the Calendar and Notification windows) I figured there should be some differences.
As you mentioned, the invite in the calendar of the meeting room ressource is missing some properties which almost certainly are connected to the Join button.
I exported the MAPI properties of a functioning invite (from the ressource, after the organizer sends an update to the meeting, since the "join" button is present then and is working properly) and the faulty invite (from the ressource) and did a simple compare in Notepad++.
The following MAPI properties got added after the update (I cut the contents of the properties):
0x7D0E PT_I8
0x8275 ResponseState
0x8298 OldLocation PT_UNICODE
0x8367 PidNameCalendarTransparent PT_UNICODE
0x848E SkypeTeamsMeetingUrl PT_UNICODE ***meeting link here***
0x84A5 OnlineMeetingConfLink PT_UNICODE
0x84A7 SchedulingServiceUpdateUrl PT_UNICODE ***api.scheduler.teams.microsoft.com link here***
0x84A9 SkypeTeamsProperties PT_UNICODE ***some IDs here***
PR_HTML PT_BINARY MAPI_E_NOT_FOUND
PR_READ PT_BOOLEAN true
Many more properties got changed.
I also looked into an MAPI export of the functioning invite from the user. There is many more differences to the faulty on from the ressource but the properties above are also present there.
So it seems to have something to do with what you said, but the properties get lost when forwarding inside the internal organizazion, which is weird. Maybe it has something to do with the hybrid deployment of our organization. The room ressource got created on the local Exchange server, but licensed in O365 with the Teams Rooms license.
Anyway there surely must be a way to keep the right properties when forwarding a meeting, without the need of an update from the organizer (since this is not practical in any way). The organizer should not have to know which Conference Room I want to use imo.
I also looked into TNEF since you mentioned it. It appears TNEF is disabled or "not set" for the three remote domains in my local exchange server, which are:
1) * -> disabled ($false)
2) ###.onmicrosoft.com -> not set / blank
3) ###.mail.onmicrosoft.com -> not set / blank
Since the ressource is in the same domain "###.de" none of the above properties should impact the invite but the wildcard one (or does it?). It may has somethin to do with the hybrid deployment.
Thank you in advance