Chat now with support
Chat with Support

Coexistence Manager for Notes 3.8.2 - User Guide

About the CMN Documentation Suite Introduction CMN Directory Connector
Directory Connector overview Installation and configuration DC Management Console Connector Creation Wizard Connector Advanced Settings Starting and stopping the Directory Connector service
CMN Mail Connector
Mail Connector features overview Coexistence mail routing basics Deployment of CMN Mail Connector Installation Configuration Mail Connector Management Console
CMN Free/Busy Connector The Log Viewer Appendix A: Known limitations Appendix B: Troubleshooting Appendix C: CMN Logs

Mail Connector issues

When an Exchange invitee accepts a meeting invitation from a Notes organizer, the acceptance notification appears in some versions of Notes with an "i" icon. This is a known consequence of the way some Notes versions process SMTP calendar messages, and in any case is only a harmless cosmetic artifact.
When a custom meeting invitation is sent from a Notes organizer to an Exchange invitee using an older release of Outlook 2007 (only), the attendee may mistakenly appear as the meeting organizer. This is a known Microsoft problem in Outlook 2007, which may be corrected by applying either Microsoft's Hotfix 941275, or SP2 of Office 2007.
Meeting requests originating in Notes and sent to Exchange users may be off by one hour for meetings scheduled in the period between the second Sunday in March (when daylight savings time begins) and the first Sunday in April (when DST used to begin). This is not a CMN defect, but rather an apparent issue in the way Windows processes time zone data. Microsoft offers a free time-zone update utility (downloadable from http://support.microsoft.com/kb/2443685) that will likely correct this problem. Apply the update to the Windows OS on both the Domino server and the CMN admin server hosting the Mail Connector software.
A meeting invitation from a Notes organizer to a Notes invitee, but then forwarded to an Exchange user, arrives in Outlook as an email, but not as a functional invitation that can be accepted/declined or added to the user's calendar. This appears to be an issue with how Notes/Domino forwards an invitation rather than any limitation of CMN, since the same behavior is observed when a Notes invitee forwards the invitation to another Notes user (where the invitation never passes through CMN).
For an Exchange recipient in Exchange 2007 SP0 or SP1, with Microsoft Rollup 3–7: A meeting invitation originating in Notes arrives in Exchange with the string "Invitation: " prepended to the original Subject, so accepted Calendar entries appear with the event title "Invitation: [original subject]." (Once an invitation is accepted, it is no longer an "invitation.")
When a custom meeting invitation is sent from a Notes organizer to an Exchange 2010 invitee using an Outlook 2007 12.0.4518.1014 (RTM version) client, an .ics file arrives in Outlook with a blank message body. This is a known Microsoft problem that has been found only in the particular combination of Exchange 2010 with the above-cited Outlook 2007 release. The problem may be corrected by applying either Microsoft's Hotfix 939596, or SP1 of Office 2007.
The conversion of a custom-meeting invitation from Notes to Exchange introduces meeting date/time errors. The invitation in Outlook, if accepted, does not correctly add the meetings to the recipient's Calendar, and the When field contents are inaccurate. Therefore, CMN converts custom meetings to an appropriate series (with exceptions) for Exchange and attaches an .ics file that, when opened, will correctly add the series of recurring meetings to the recipient's Calendar. CMN also appends a notice in the message body, alerting the invitee and listing the true meeting dates and times.
Exchange cannot process the case of a Notes resource being available for only a part of a meeting series organized by an Outlook user. In this case, the resource account in Notes generates two accept/decline replies for the same meeting: one listing the date(s) for which it accepts, and the other listing the date(s) for which it declines. Exchange, however, does not support partial acceptance of a series, and cannot correlate these separate accept/decline notices to its original meeting record. The Tracking tab therefore incorrectly shows all instances as accepted, even though some were actually declined. CMN does explain this limitation to the Outlook organizer, and suggests: Leave your calendar as it is, and simply note to yourself the date(s) that the resource has accepted and declined; or cancel the entire meeting series and create a new invitation rescheduled to accommodate the resource.
When a meeting with an online meeting place is rescheduled by a Notes user, the meeting URL does not appear in the Location field in the rescheduling notice in Outlook. Notes does not transmit the URL as it does when the meeting is originally scheduled, so CMN cannot insert the URL, and in Outlook the meeting appears to have a modified location and does not show the URL.
An Exchange user cannot schedule a recurring series of meetings with a Domino 6.5.x resource because Domino does not support this scenario over SMTP. (This is a limitation of Domino, not of CMN.) CMN will not relay any such attempt, and will send a brief explanatory notice back to the Outlook user.
A Notes user who declines a meeting request from an Exchange user, and who unchecks the Keep me informed of updates checkbox in the Notes reply, still receives update notifications if the Exchange organizer reschedules the meeting.
An OLE object embedded as active content in a Notes message sent to another user—whether in Notes or in Exchange—arrives in the recipient's mailbox as a read-only document. This is not a limitation of CMN, but appears to be the way Notes handles an OLE object within active content. CMN simply relays the object in that state when it passes the message to Exchange. The recipient cannot alter the document and then return or forward it, as with other forms of active content.
An Expires After value in a message originating in Exchange is lost when the message is delivered to a Notes recipient. Both Notes and Exchange permit setting an expiration date for a message, after which it is safe to delete or archive the message. That value is preserved for messages originating in Notes and delivered to an Exchange recipient, but is lost in the other direction.
When a message containing a Notes DocLink is created in Notes by selecting Copy into New Memo after opening a message containing a DocLink, the DocLink is lost upon receipt of the message in Exchange.
In some environments, when you choose to Convert to NDL Attachment (in the Mail Connector Management Console, Notes Doc Links screen), an Outlook recipient can successfully open an .ndl attachment only if the required Notes client on the user's workstation is not already running. If the Notes client is already running, the user sees an error message: Invalid directory name or device not ready. In that case, the attachment should open if the user dismisses the error message, exits from the Notes client, and re-clicks on the attachment.
A Notes user requesting a Notes resource no longer appears in the From field of the booking-request message to the resource owner after the owner has migrated to Exchange. The requestor's name does appear in the body of the message, but only in addr-spec format (the left-hand side of his/her email address). This is a known Domino issue; Domino does not send the name except within the message body.

Free/Busy Connector issues

Notes queries for free/busy information from meetings with any external users can take longer and in some cases fail to return data for internal users. This is a known issue with Notes/Domino, which places such requests in the LWPSCHEDGATEWAY queue instead of the configured queue preferred by CMN (in most cases called MAIL.BOX or MAIL1.BOX).
The Get-CmnExchangeWebServicesUrl command does not work in a single-namespace environment.

Appendix B: Troubleshooting

This Appendix describes the most common problems encountered when installing and using Quest Coexistence Manager for Notes, and provides suggestions and procedures that are most likely to resolve them. Virtually all of these issues are unique to particular CMN components—the Directory Connector vs. Mail Connector vs. Free/Busy Connector. Such component-specific issues are listed and discussed separately, grouped by CMN component, following the more general introductory notes and comments below.

Many issues can be resolved quickly by reviewing this short list of preliminary checks before calling Quest Support:

Review the component log file(s). You can find valuable information about component errors and warnings in the components’ respective log files. If you call Quest Support and a support engineer can't immediately identify the problem, typically he/she will ask for copies of your log files.
Verify system requirements. CMN problems are often traced back to inconsistences between the product’s system requirements and the host network’s hardware or software specifications. You may therefore save yourself some time and trouble by simply comparing your local system to the CMN system requirements. System requirements are documented in the RTM Release Notes.
Is this a known limitation or known issue? Check Appendix A: Known limitations in this User Guide, and the Known Issues section of the current CMN Release Notes, to see whether the problem might simply be a known limitation of the process.
What has changed since the last server restart? Configuration values are normally updated only when a service is restarted. This can hide a pending problem for weeks or longer until an administrator restarts the services and the changes are applied.

Directory Connector

Verify that all system requirements have been met (see System requirements in the RTM Release Notes).

Verify that you have a valid Quest License Key installed. For more information, see About Quest license keys in User Guide chapter 1.

A Connector definition—the information that creates and characterizes a Connector—is part of the configuration.xml file that governs the operation of the overall Directory Connector component. The Directory Connector configuration file may contain one, two or more Connector definitions. The Connector Creation Wizard does not save Connector definitions to disk; it only adds or edits them in the open Directory Connector configuration file, which then must be explicitly saved to disk in the CMN Management Console. If you do not save the overall DC configuration file, any new Connector definitions or changes to existing Connector definitions will be lost when you exit the Management Console.

For more information see, in User Guide chapter 2: Step 4: Run the DC Management Console and Connector Creation Wizard to create connector(s).

The account usernames required for access to the Domino Directory and Active Directory can take different forms in different environmental contexts (including where the Directory Connector’s host computer resides within the network, relative to the server that a DC Connector is trying to reach. It is therefore possible (but uncommon) that access will fail even if you enter the correct credentials into the Connector Creation Wizard. In this case, you can usually resolve the problem by expressing the username in some other form, such as:

For Domino

For Exchange

NotesAdmin

Domain\Admin

NotesAdmin/domain

Admin@mydomain.com

Edit the Username field in either the Source or Target Server Information screen—whichever server is denying access—and then run the Connector again.

CMN's Connector Creation Wizard is designed to scan the source and target OUs to generate lists of valid options for the source and target OUs. Ordinarily, the Wizard requires source and target OUs be selected for a connector definition based on the results of these scans. However, in the rare event the Wizard encountered a corrupt OU structure, it may be impossible to select an OU and complete the Connector configuration.

A CMN configuration parameter provides an option to bypass these OU scans and disregard the OU verifications. With this feature configured to ignore the OU scans, the Wizard can advance to the next screen whether or not the OU selection can be confirmed—so you can continue the connector definition.

To enable this feature (to disable the verifications), set this boolean parameter setting in CMN's Configuration.xml file from false to true:

NOTE: CMN automatically adds this parameter to Configuration.xml when installing the Directory Connector. The parameter is set to false by default (which leaves the Wizard's verifications intact). To enable this feature, change the value to true, as shown above. Quest recommends maintaining the false setting for this feature unless the Wizard encounters a corrupt OU structure.

Then, use the Custom Configurations tab of the connector’s Advanced Settings to configure the Directory Connector for the OU(s) you want to appear in CMN’s selectable list. You must define separate lists of available OU(s) for the Notes environment as the source and as the target.

The table in the Custom Configurations tab shows parameter names (the Key column) and their corresponding Values, as they now occur in the connector’s config.txt file. You can change the value of an existing parameter, or add a new one. Click Add to add a new parameter. A dialog box opens with two fields: Key and Value.

For Notes as the source, define this parameter and value:

Key: sourcecontext
Value: [the desired OU(s) – e.g., ou=org1,o=contoso]

For the source parameter (only), you can enter a Value with multiple containers by using vertical bars (|) to separate the containers.

Then define another parameter and its value for Notes as the target:

Key: destsubtree
Value: [the destination OU for synched data – e.g. o=contoso]
Exchange-to-Notes connector generates Empty Recipient List error

The name of the source container for an Exchange-to-Notes connector cannot begin with the letters CMN. If the source container name begins with CMN the connector will generate an Empty Recipient List error.

If resources are not extracted from Notes during a connector’s initial run, verify:

Each resource in the Notes source must have a mail address: the Mail=jon.doe@xyz.com address as seen in LDAP, which is the Internet address of the resource.
If any Notes resources are defined but not associated with an Organization, then the DC's search for resources must begin at the ROOT container, not O=NotesDomain, unless your intent is to specifically limit the scope by Organization. For example, "Room A" with no associated organization would be found in the ROOT, and "Room A/Domain" would be found in O=Domain. For this case the DC Connector could be configured for a Source OU of O=Domain.

CMN’s Directory Connector may produce a duplicate object record (sharing the same SMTP address) in Active Directory if an existing AD object had previously been added to the Domino Directory—either manually, or by some other directory tool such as Microsoft’s Transporter. In this case, the first run of a Notes-to-Exchange Connector will copy the Domino object back to Active Directory as a contact, where it may generate a duplicate record. And then the first run of an Exchange-to-Notes Connector will copy it back to Domino.

To resolve this issue, check the Domino Directory for such objects before the first CMN Directory Connector run, and:

The most likely solution is to turn off the LDAP document schema enforcement. In Domino, set Enforce schema to No for the LDAP document.

Other Directory Connector Issues

Look through your CMN Directory Connector log files for clues to help diagnose and resolve the problem.

Related Documents