Try our new Certificate Revocation List Check Tool
CRLcheck.exe is a tool developed to verify digital signatures of executable files. It collects files from known paths on your client, checks their signature, and checks Certificate Revocation Lists (CRL) and OCSP download. This helps avoid delays in launching files.
Category published:  Exchange 2016 Exchange 2019 M365,AZURE,INTUNE Microsoft Exchange   Click on the Category button to get more articles regarding that product.

M365/Azure, Full Hybrid Mode, M365 user unable to see free/Busy Room/meeting or book on-premise

Posted by admin on 22.06.2023

This post was published to Butsch.ch at 15:06:54 22.06.2023

M365/Azure, Full Hybrid Mode, M365 user unable to see free/Busy Room/meeting or book on-premise

 

 

Account    www.butsch.ch

 

Category    Exchange 2016 ; Exchange 2019 ; M365,AZURE,INTUNE ; Microsoft Exchange

 

PROBLEM: The test.M365 (cloud) users are unable to access free/busy info from the on-premise room mailbox and part two are unable to book it

In hybrid environment that combine on-premises and Microsoft 365 (M365) accounts, organizations may encounter difficulties when attempting to add conference rooms to meetings. This issue affects not only Outlook Web App (OWA) but also the Outlook desktop client (outlook.exe).

Problem Overview

The problem arises when attempting to book conference rooms from the room list in Outlook. In both OWA and Outlook desktop client, users may find that conference rooms are missing or unavailable for selection during the meeting scheduling process. This issue is particularly prevalent in hybrid environments where room mailboxes are synchronized between on-premises Exchange Server and M365.

Root Cause

The root cause of this problem lies in the configuration of the RoomList distribution group, which is responsible for organizing and displaying room mailboxes. In hybrid environments, the RoomList distribution group needs to be properly synchronized and maintained between on-premises and M365.

Inaccurate recipientTypeDetails

One potential cause is the incorrect recipientTypeDetails property associated with room mailboxes during synchronization. When on-premises room mailboxes are synchronized to M365, the recipientTypeDetails property may be set as “MailUser” instead of the expected value, “RoomMailbox”. This discrepancy prevents the room mailboxes from being recognized as valid conference rooms in M365.

 

What is wrong again in detail:

In a Full hybrid Exchange <> M365 Setup with Room resources on on-premise side you see following effect.

Error #1:

The test.M365 users are unable to access free/busy info from the on-premise room mailbox as example Audi_A3_OST_179602@butschlab.ch.

Error#2.

The test.M365 users can see the calender and free/busy but they are unable to BOOK the room effective (No permission changed and users was in on-premise side before migration)

 

We have following users:

User on-premise

User M365

test.onpremise@butschlab.ch

test.m365@butschlab.ch

 

room all on-premise Exchange

room M365 (Make one new M365 if you dont have for solution)

Audi_A3_OST_179602@butschlab.ch

room.m365@butschlab.ch

 

This is also valid for:

In a hybrid deployment of on-premises Microsoft Exchange Server and Exchange Online, assume that Exchange Online users select add room in a meeting request in Outlook Web App. In this situation, on-premises room mailboxes aren’t displayed in the list as expected. Therefore, Exchange Online users can’t add an on-premises conference room to a meeting request.

 


This is kind of unsupported solution as some people say at MS in Forum. On the other hand there is a KB which clearly explains part of the solution.

But only parts of it? Here is the full working solution:

 

Error #1:

The M365 users are unable to access free/busy info from the on-premise room mailbox.

  1. You have to generate a ROOMLIST or lets say NEW Distribution List with the option –roomlist
  2. In that room list you make all existing on-premise rooms member (Their object)
  3. You already have OR newly generate a ROOM on the M365 Side m365.room@butschlab.ch (Make a DUMMY room on Cloud side)
  4. You make the new m365.room ROOM also member of that Room List (Distribution group) < Most important STEP

 

Error#2.

The M365 users can see the calender and free/busy but they are unable to BOOK the room effective (No permission changed and users was in on-premise side before migration)

Here is how to see which rooms are affected:

Get-Mailbox -RecipientTypeDetails RoomMailbox | Get-CalendarProcessing | ?{!$_.ProcessExternalMeetingMessages}

You have to enable the flag -ProcessExternalMeetingMessages $true for the on-premise accounts. We never touched this in on-premise ONLY because it was rather dangerous if you did it wrong. If you did not follow compliance and enabled some things like INLCUDE/SHOW subject or BODY from meetings and ACTIVATE that wrong external people could you see conf. Data from inide the org.

 

Powershell Exchange on-premise

# V1.0, 23.06.2023, Mike Butsch, Solution to see on-premise ROOM Resources from M365 side

 

# Solve Error #1:

 

# Generate a Distribution Group with paramter –roomlist in your favorite OU.

# The OU has to be synced to Azure/M365. So include the OU in your Azure Connector Setup.

# ————————————————————

New-DistributionGroup -Name Autos -roomlist -OrganizationalUnit “OU=Azure_SYNC,OU=Gruppen_AG,DC=butsch,DC=local”

New-DistributionGroup -Name Raeume -roomlist -OrganizationalUnit “OU=Azure_SYNC,OU=Gruppen_AG,DC=butsch,DC=local”

# ————————————————————

Add-DistributionGroupMember Autos -member Audi_A3_OST_179602

Add-DistributionGroupMember Autos -member Peugeot_508_OST_162117

Add-DistributionGroupMember Raeume -member m365.room

# ABOVE most important step you NEED to add a M365 ROOM or DUMMY Resource as member

# ————————————————————

Add-DistributionGroupMember Raeume -member OST_Sitzungszimmer_Vogebank

Add-DistributionGroupMember Raeume -member Sitzungszimmer_EG654

Add-DistributionGroupMember Raeume -member Sitzungszimmer_121_OG

Add-DistributionGroupMember Raeume -member FAT_Raum_2_OG

Add-DistributionGroupMember Raeume -member Konferenzraum_3_OGE

Add-DistributionGroupMember Raeume -member Sitzungszimmer_3_OGE

Add-DistributionGroupMember Raeume -member m365.room

# ABOVE most important step you NEED to add a M365 ROOM or DUMMY Resource as member

 

 

# Solve Error#2.

 

# ————————————————————

set-CalendarProcessing OST_Sitzungszimmer_Vogebank -ProcessExternalMeetingMessages $true

set-CalendarProcessing Sitzungszimmer_EG654 -ProcessExternalMeetingMessages $true

set-CalendarProcessing Sitzungszimmer_121_OG -ProcessExternalMeetingMessages $true

set-CalendarProcessing FAT_Raum_2_OG -ProcessExternalMeetingMessages $true

set-CalendarProcessing Konferenzraum_3_OGE -ProcessExternalMeetingMessages $true

set-CalendarProcessing Sitzungszimmer_3_OGE -ProcessExternalMeetingMessages $true

set-CalendarProcessing Audi_A3_OST_179602 -ProcessExternalMeetingMessages $true

set-CalendarProcessing Peugeot_508_OST_162117 -ProcessExternalMeetingMessages $true

————————————————————

 

GUI, notive that the user accounts of ROOM resources are always disabled. Keep them seperated so nobody (Azure Admin)

Does delete them when he has his cleaning day and want’s to be a good employee.

 


 

 

Since you are in Hybrid Mode also check shortly both sides on-premise and M365 if you have the same settings there:

Set-OrganizationRelationship | fl


 

 

The KB was written for the OWA / WEAPP but we proof it’s also valid for outlook.exe

Please notice that the KB does NOT contain the full solution as we provide in our Butsch KB.

https://learn.microsoft.com/en-US/exchange/troubleshoot/calendars/cannot-add-conference-rooms-to-meeting-in-owa#more-information

 

Maybe it’s the TOKENS and AUTHENTICATION also so Check ANYTHING related to 4001 if you have OAUTH oder DAUTH:

https://www.butsch.ch/post/M365Exchange-Hybrid-OAuth-Testing-command-OAuth-Cert-out-of-sync-4001-IIS-VDIR-OAuth-wrong

 

EventID which may be related if you have OAUTH active

 

Event ID 1003: This event indicates successful OAuth authentication requests. It confirms that the authentication process between Microsoft 365 and on-premises Exchange was successful.

 

Event ID 1004: This event indicates failed OAuth authentication requests. It can provide details about the reason for the authentication failure, such as incorrect credentials or authorization issues.

 

Event ID 1022: This event is logged when an OAuth token is issued to a client application. It confirms that the token was successfully issued for the authentication process.

 

Please note that these specific event IDs are not guaranteed to be available in all versions of Exchange Server or in every configuration. The availability of events and their IDs can vary based on your Exchange Server version and the specific logging settings enabled.

 

Additionally, it’s important to understand that the Application log on the Exchange server may not provide comprehensive logging specifically for OAuth access from Microsoft 365 to on-premises Exchange. As mentioned earlier, monitoring the client-side logs in Outlook and the logs in Microsoft 365 (such as audit logs and trace logs) will provide more detailed information for troubleshooting OAuth-related issues.

 

If you encounter specific error messages or need more specific guidance on troubleshooting OAuth access, I recommend referring to Microsoft’s official documentation, reaching out to Microsoft Support, or consulting with an Exchange Server specialist for further assistance.

 

 

 


 Category published:  Exchange 2016 Exchange 2019 M365,AZURE,INTUNE Microsoft Exchange   Click on the Category button to get more articles regarding that product.