I wanted to follow up that reconfiguring the directory structure according to shared domain hosting, with branches for ISW-synchronized accounts as one of the sub-organizations which share the domain, and manually created OUCS-only accounts being in another sub-organization. This works for both messaging components and the DA, as long as UIDs are in ou=People in their organization. Somewhat unfortunately, ISW config seems to allow only one DSEE target branch and puts groups (CN) there as well. Well, for our needs to edit user attributes and service packages via DA, this suffices. Sometimes there are hiccups (Can not save changes), but they are intermittent and harder to trace debug; usually go away with restart of the DA web container. The DSEE LDAP instances are configured with plugins to enforce uid uniqueness across the organization and uniqueness of values of messaging email address attributes (mail, mailAlternateAddress, mailEqiuvalentAddress) to avoid mixups between user accounts in different branches.
Also, we had a problem with Calendar server after migrating the LDAP entries: since our deployment used the nsUniqueID for calendar user identification, relocation of entries (the way we did it) generated new values for new entries and users got new empty caledar databases. On this POC this was not a major problem, and newer OUCS releases with a davUniqueID attribute should specifically be immune to this problem. However, for others trodding this path I can suggest that they export the LDAP database into LDIF including the unique IDs, recreate the suffixes as needed (the ISW target organization in DSEE should be a separate LDAP database suffix), change the LDIF entry pathnames, and import the LDIF anew. This would wipe old LDAP data and should add old nsUniqueIDs to relocated entries (unlike recreation via ldapadd or relocation via ldapmodrdn).
We have also hit a problem with DA refusing to render the list of accounts (returning 0 or 25 empty entries in a table). The LDAP logs showed that on the LDAP side all is ok, and expected amount of replies was located. Pattern searches often produced the proper table with a subset of users in DA. Ultimately, we linked the problem to ISW binary base64-encoded attributes (dspswuserlink et al; some of those values also garbaged output of commadmin queries in a terminal) and created an LDAP ACI which forbade our DA-admin user to read,search,compare these attributes. This solved the problem for us. I wonder if a more generic solution is possible, so as to apply this ACI not to an explicitly named admin user but to any users with DA admin privileges (by group or role? which string, to cover them all in advance)? Or, perhaps, nobody except the ISW user account should see these ISW attributes?
Hope this report helps others who would try to pioneer this path of messaging integration