The calendar connector task is not quite as intelligent as the router task. The calendar connector task connects directly to the Domino server hosting the Foreign Domain. The calendar connector task will use the same order described above, the latest document modified first in order to the earliest modified document. The calendar connector task does not ‘relay’ requests like the router task. This is important to note in order to implement high availability for free busy requests to a Foreign Domain. The calendar connector task will throw the following informational warning to the console when multiple Foreign Domain documents are used in the environment every time a free busy request is made:
Warning: Multiple documents detected for domain 'BTEx' in Domino Directory for the scheduling request.
Create more than one coexistence server with identical configurations. Create multiple Foreign Domain documents and list a different Coexistence server on the Mail Server and Calendar Server tabs. The following behavior will occur.
Primary Server (last document modified):DominoA (Mail) DominoA (Calendar)
Secondary Server: DominoB (Mail) DominoB (Calendar)
All mail routing is sent is DominoA including all routable calendar forms. All free busy requests flow to DominoA. Messages are routed to Exchange by SMTP and HTTP.
When DominoA is no longer reachable via NRPC (the server must be down and not reachable, not just busy) mail is routed to DominoB. Calendar related routable messages will also be routed to DominoB. All free busy requests will flow to DominoB. Mail items and routable calendar items are routed to Exchange by SMTP. All free busy requests fail at the calendar connector.
This is due to the calendar connector task on the second Coexistence server sees that DominoA is the first loaded calendar server in the calendaring table and that server is not reachable. The calendar connector task does not ‘relay’ to any other servers and does not recognize that it too is defined to handle these requests.
Create more than one coexistence server with identical configurations. Create multiple Foreign Domain documents and list a different Coexistence server on the Mail Server and Calendar Server tabs. The following behavior will occur.
Primary Server (last document modified):DominoA (Mail) DominoA (Calendar)
Secondary Server: DominoB (Mail) DominoB (Calendar)
All mail routing is sent is DominoA including all routable calendar forms. All free busy requests flow to DominoA. Messages are routed to Exchange by SMTP and HTTP.
When DominoA is no longer reachable via NRPC (the server must be down and not reachable, not just busy) mail is routed to DominoB. Calendar related routable messages will also be routed to DominoB. All free busy requests will flow to DominoB. Mail items and routable calendar items are routed to Exchange by SMTP. All free busy requests fail at the calendar connector.
This is due to the calendar connector task on the second Coexistence server sees that DominoA is the first loaded calendar server in the calendaring table and that server is not reachable. The calendar connector task does not ‘relay’ to any other servers and does not recognize that it too is defined to handle these requests.
Using the same scenario above, a Servers Only group is created containing all mail and application servers in the organization. A Domino administrators group should also already exist. On each of the Foreign Domain documents security is enabled (creating a readers field), giving access to the Servers Only group, administration group and the individual Coexistence server. This translates into all Domino servers, excluding the Coexistence servers, are able to see both Foreign Domain documents as well as the administrators of the environmentEach coexistence server, however, will only be able to see and load the Foreign Domino document specific to itself. An additional step is required for this to function correctly. There is a field on the Foreign Domain document called ‘DocumentAccess’ that is a ‘readers’ field and contains a role that is commonly given to the group ‘LocalDomainServers’. This field must be programmatically removed. If the Foreign Domain document is ever edited this field will be added back onto the document. Appendix A contains a LotusScript agent that can be used for removing this field.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center
