Several previous articles on this blog have outlined the required configuration of Exchange mailboxes for use with native Microsoft meeting room solutions for Microsoft Teams and Skype.  There are also some articles which cover the configuration for mailboxes for use with standards-based video conferencing solutions from Poly and Cisco which support Microsoft Exchange to display and join scheduled Skype and Teams meetings.

All of these articles share a common and often overlooked configuration setting that is worth spending a little more time on: the DeleteComments parameter as defined on Exchange mailboxes via the Set-CalendarProcessing PowerShell cmdlet.  This parameter must be set to a value of “$false” in order for most conferencing solutions to properly process the various type of meeting invitations.  Yet the default value on this parameter for mailboxes in Exchange is ‘$true‘.

What this means is that Exchange will delete the entire contents of the message body when it arrives in this destination mailbox.  That can prevent various meeting room solutions from joining the meetings from the calendar.  In these scenarios the resolution is to simply run the Set-CalendarProcessing cmdlet against the affected resource mailbox to disable the DeleteComments parameter.

Set-CalendarProcessing -Identity vtc1@msteams.net -DeleteComments $false

As this change only applies to inbound messages then a new meeting will need to be created and booked with the updated resource mailbox in order to see any improvement.  Existing meetings in the mailbox’s calendar, individual or reoccurring, would still be missing the previously-stripped information in the body of the message.

Background

This is a critical configuration parameter which is often times the only thing preventing various meeting room solutions from successfully connecting to Microsoft Teams or Skype meetings.  Issues are typically more prevalent when using standards-based video conferencing systems with Cloud Video Interop (CVI) or other on-premises interoperability solutions, like RealConnect for Clariti, but native endpoints can also sometimes be negatively impacted.

The root of the issue is that Skype and Teams invitations includes important meeting information that is used by various clients and services differently.  Information can be stored in the body of the invitation, where it can be seen by people and machines alike, and/or in the header of the email where it is hidden away from people, but not machines.  And as meeting invitations are forwarded, both internally and externally between different organizations, some of this information can often be modified or even stripped completely from the message.  This could prevent meeting rooms from joining scheduled meetings.

One example is in the earlier days of Microsoft Lync many of the native software clients and devices like Lync Phone Edition would provide the single-click join experience by looking for information stored in a specific parameter in the invitation’s header.  But, if that invitation came from a different organization then the ‘Join’ button would not appear on those meetings in the calendar.  This was due to fact that external delivery of that message would usually strip the needed MAPI properties in the header as the sender organization’s SMTP platform typically had Transport Neutral Encapsulation Format (TNEF) disabled.  This was problematic as the workaround was something which must be applied in the sender’s environment, not on the receiving end so asking every other organization to apply these changes is not very scalable.  Microsoft eventually addressed this issue in the various Lync clients by adding support for parsing additional information in the meeting invitations to correctly locate and join the scheduled meeting when the header information was lost.  This was done by simply looking at the body of the message to identify the Skype meeting URL (e.g. https://meet.domain.com/user/ID) that is embedded in the “Join Skype Meeting” link.

Other solutions are also programmed to look at meeting information that is provided in the body of the message.  Poly Trio is one endpoint example and the Poly One Touch Dial (OTD) service is another.  Retaining the body of the meeting invitation is especially important when dealing with the various CVI solutions as their companion message processing services will look for information which they expect to see in the body.

To illustrate this take note of just how much different information is provided in the body of a Skype meeting or Teams meeting invitation.  Embedded URLs for native clients, audio conferencing IDs which several third-party solutions can leverage, and video conferencing details provided for accessing the various CVI solutions.

When a client or device needs to leverage any of the information above it obviously needs to be available in the invite.  Just because it was included in the original invitation though does not necessarily mean that it will still be intact by the time a recipient sees it, which brings the discussion back to the Exchange mailbox configuration.

Regular user mailboxes (which do not normally include automatic processing rules like resource mailboxes) will typically not have any issues seeing this information, thus when devices are using a regular user account everything seems to work fine.  But when tested with an existing resource mailboxes in an organization is when issue can occur, most often because when the resource mailbox was originally created for a regular conference room there was no device using that mailbox and no additional custom configuration was applied.  The mailbox was only setup to perform standard resource booking duties, and typically no one ever looks at the invitation details in the rooms account, it is only used as a placeholder for reserving the room.  The default behavior in Exchange Server and Exchange Online has always been to trim the amount of unneeded data on every invite sent to a resource mailbox.

The configuration can be verified by looking at specific Calendar Processing parameters on mailboxes which were created using different methods.  Mailboxes created using basic process like the Room & equipment section of the Microsoft 365 admin center or using “New-Mailbox –Room” in PowerShell will be setup by default to wipe the body of any emails sent to those mailboxes.

• Use the following Exchange PowerShell cmdlet to review the related parameters on a standard resource mailbox in the organization (e.g. room1@msteams.net).

Get-CalendarProcessing -Identity “room1@msteams.net” | fl Add*,Delete*,Remove*

Note that DeleteComments is set to True in the output above.

But when a resource mailbox is created using the correct process it should have had the DeleteComments parameter specifically disabled, along with a few other required and optional changes.

• Use the following Exchange PowerShell cmdlet to review the related parameters a customized resource mailbox in the organization (e.g. vtc1@msteams.net).

Get-CalendarProcessing -Identity “vtc1@msteams.net” | fl Add*,Delete*,Remove*

Because this second mailbox was created using the suggested approach then meetings sent to it will not have the invitation details removed as DeleteComments is set to False.

Other recommended settings for resource mailboxes used by meeting devices are covered in the Microsoft documentation, but most of them are optional changes as they apply to features like meeting conflict handling, automated responses, and privacy options which all may vary based on an organization’s requirements.