Coex: Users in outlook add room as participant - invitation does not arrive in resource database in Domino

We have a Lotus Notes and Exchange Online coexistance and are migrating users step by step to EXO. The resources (rooms) are still on Domino and have been provisioned as contacts.

The Outlook users have to add a room as participant to a meeting, free/busy is working. On the Domino side the resources are owned and the owners have to respond to accept the invitation.

But the owners are not notified about the invitations and the invitations do not show up in the resource calendar.

What types of resource ownership / response on Domino are supported in coexistance? Only automatic processing? Or other variations as well? If so, are we missing a config detail?

We are on the most current version of Quest software.

Thank you!

Parents Reply Children
  • Hi, the resources have an smtp address and that is the one which is used in outlook. We invite the room as participant to have free/busy, we also invite as room. The invitation arrives in the resource database but it is not processed. We noticed it has the format notice instead of invitation.

    We also ran the repair tools, no improvement.

    In the log we find the following (names are xxed)

    [2778303:000021-00007F35DD7EB700] 28.04.2021 17:20:17   SMTP Server: quest-cmn01.xxx.com (192.168.198.52) disconnected. 1 message[s] received

    [2778237:000037-00007F43E0862700] 28.04.2021 17:20:18.07 [C&S]> ERROR | Release 11.0.1FP3 | csauto.cpp(452) : Invalid or nonexistent document (0x227)

    [2778237:000037-00007F43E0862700] 28.04.2021 17:20:18   Router: Error autoprocessing message 9D5B445B to Raum A 337/Berlin: Invalid or nonexistent document

    [2778237:000037-00007F43E0862700] 28.04.2021 17:20:18   Router: Message 00544178, 9D5B445B delivered to Raum A 337/Berlin from xxx@xx.com Size: 13K Time: 00:00:00 Hop Count: 1

  • Hi, the CMN Mail Connector configuration includes a "Resource Mapping" file - did you list the resource there?

  • Hello Anja,

    Thanks for the reply. It sounds like we are going to need to investigate this issue in greater depth than is available via this community forum. We would suggest creating a Service Request so that a Quest Support Engineer can investigate this issue with you. You can create a new Service Request using this link.

    Regards,

    Trevor Taegder
    Senior Technical Support Engineer
    Quest | Support

  • Hi, I did a while ago already but am stuck with the SR. SR Number:4880923

  • Hello Anja,

    Thanks for the update. I have reached out to the Support Engineer you are working with for Service Request 4880923 and requested some additional information be gathered. We will review this requested information and let you know what we find as soon as possible.

    Regards,

    Trevor Taegder
    Senior Technical Support Engineer
    Quest | Support

     

  • Hi   and  , I don't suppose you could shed any light on what was done to resolve this? We appear to be getting a very similar message in our log.

       , not sure if this may help us?

  • Hello  ,

    Typically, this type of issue is caused by the Resource Mapping file that is configured in the Coexistence Management Console | Mail Connector. The SMTP address defined in the resource mapping should match the "targetaddress" or "ExternalEmailAddress" of the Exchange/Office 365 contact that represents the Domino room or resource. Even when the resource mapping file is setup correctly, in the Domino Console, you will still see the first email come in to book the Domino room and fail, then the CMN Mail Connector will then automatically generate a second follow-up email that should book the room successfully. 

    If you continue to experience issues booking Domino rooms and resources with CMN, then you may want to create a Service Request, as each environment is unique and may require a unique configuration. You can create a Service Request using this link.

    Regards,

    Trevor Taegder
    Senior Technical Support Engineer
    Quest | Support

  • It was indeed the resource mapping file. After we had fixed it everything worked fine.