test

Sun Java System Communications Services 2005Q4 Release Notes

Compatibility Issues

This sections describes any compatibility issues that exist in the Connector for Microsoft Outlook.

Sun Java System Calendar Server Considerations

This section describes Sun Java System Calendar Server considerations for the Connector for Microsoft Outlook.

Calendar Server Installation

The latest version of Calendar Server is available at theCollaboration and Communication download site.

It is recommended that customers also install the latest set of patches, which are available at SunSolve.

For detailed installation instructions, refer to theSun Java Enterprise System 2005Q4 Installation Guide for UNIX. For configuration instructions, refer to theSun Java System Calendar Server 6 2005Q4 Administration Guide.

Note –

If you are migrating from Calendar Server 5.x to the latest version of Calendar Server, you must run the cs5migrate_recurring utility to convert the database in order to comply with the Connector for Microsoft Outlook data model. Consult technical support for information about the cs5migrate_recurring utility.

Required LDAP mail Attribute

Calendar Server 6 2004Q2 (and later) requires users to have the LDAP mail attribute for both user and resource calendars.

For clients to use Microsoft Outlook to schedule resource calendars (for example, for meeting rooms or equipment such as a notebook computer or overhead projector), each resource must have an email address, even though email is not actually needed. The LDAP mail attribute specifies this email address.

You might specifically need to add the LDAP mail attribute as follows:

5.x Installation. Before you run the cs5migrate_recurring migration utility, add the mail attribute to users for both user and resource calendars. To add the mail attribute, use the Calendar Server csattribute utility or a utility such as the Directory Server ldapmodify utility.

New Installation (6 2004Q2 or later). Provision the LDAP mail attribute for existing users for both user and resource calendars using the Calendar Server csattribute utility or a utility such as the Directory Server ldapmodify utility.

If you create new calendars or users after installation, use the required -m email option to specify an email address when you run these Calendar Server utilities:

For related information about csattribute, csresource , and csuser, refer to theSun Java System Calendar Server 6 2005Q4 Administration Guide. For related information about ldapmodify utility, refer to the Sun Java System Directory Server Resource Kit Tools Reference.

ProcedureAdding the email LDAP Attribute to a Resource Calendar

The following example adds the LDAP mail attribute for a conference room named “Room100” on the sesta.com server. This example configures Messaging Server. If you are using another email server, refer to that product’s documentation for the equivalent process.

  1. Add the mail attribute to the LDAP server using the csattribute utility:

    # ./csattribute -a mail=Room100@sesta.com add Room100

  2. To check that the attribute has been set, use the csattribute list command with the -v (verbose) option:


    # ./csattribute -v list Room100
...
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com

ProcedureSetting up the bitbucket Channel for the Resource Email (Messaging Server)

The following examples sets up the bitbucket channel for Messaging Server for the email generated for resource calendars. This example uses a resource named “Room100” on the sesta.com server. If you don’t set up the bitbucket channel (or equivalent), you will need to periodically delete the email messages sent to the resource calendar.

  1. Ensure the bitbucket channel is defined in the imta.cnf file.

  2. To direct messages to the bitbucket channel, create the email address for the resource using the csresource utility:

    # ./csattribute -a mail=Room100@bitbucket.sesta.com add Room100

    Note –

    To enable these changes, you might also need to rebuild alias tables or configurations. Refer to the documentation for Messaging Server (or your email product) as well as your site's own documentation and procedures regarding changes to mail services.

ProcedureSetting up the bitbucket Channel for the Resource Email (Sendmail)

The following example sets up the bitbucket channel for Sendmail for the email generated for resource calendars. This example uses a resource named “Room100” on the sesta.com server. If you don’t set up the bitbucket channel (or equivalent), you will need to periodically delete the email messages sent to the resource calendar.

  1. In the /etc/aliases file on the appropriate host, add an entry such as:


    # Resource/Conference room aliases
Room100: /dev/null

  2. Add the email address for the resource to the LDAP directory using the csresource utility:

    # ./csattribute -a mail=Room100@sesta.com add Room100

Email Alias (mailalternateaddress Attribute)

If you need to setup an email aliases for a calendar user, use the LDAP mailalternateaddress attribute. The LDAP mail attribute provides the primary mail address, and the LDAP mailalternateaddress attribute is used for email aliases. Both attributes map the mail addresses to the user’s calendar ID (calid).

For example, to add the mailalternateaddress attribute for a user named John Smith with these values:

Use these Calendar Server utility commands:


# ./csuser -g John -s Smith -y password -l en -m john.smith@sesta.com 
\ -c johnsmith create johnsmith
# ./csattribute -a mailalternateaddress=johns@sesta.com add johnsmith
# ./csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith

Shared Calendar LDAP Lookup Configuration

If Directory Server requires authentication for the Shared Calendar LDAP lookup then the service.wcap.userprefs.ldapproxyauth parameter must be set in the ics.conf file as follows:

If service.wcap.userprefs.ldapproxyauth is “yes”, you must also set the appropriate LDAP ACI for the calmaster entry. For example, to set the calmaster ACI for proxy authentication for the sesta.com domain, use the ldapmodify tool as follows:

dn:  o=usergroup
changetype: modify
add: aci
aci: (targetattr="icscalendar || cn || givenName || sn || uid ||
mail")(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl
"Allow calendar administrators to proxy -
product=ics,class=admin,num=2,version=1"; allow (proxy) groupdn =
"ldap:///cn=Calendar Administrators,ou=Groups,o=usergroup";)

For the domain basedn node, the following example shows the correct ACI:

dn:  o=sesta.com,o=usergroup
changetype: modify
add: aci
aci:(targetattr="icscalendar || cn || givenName || sn || uid || mail")
(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl "Allow 
calendar users to read and search other users - 
product=ics,class=admin,num=3,version=1"; allow (search,read)
userdn = "ldap:///uid=*, ou=People, o=sesta.com, o=usergroup";)

If there is no domain, add this ACI to the root suffix itself by removing the o=sesta.com part on the dn: line.

The Calendar Server configuration program, csconfigurator.sh, adds these ACIs. If you are upgrading from Java Enterprise System Release 1, you must rerun the configuration program to get these updated ACIs.

Outlook Free-Busy Lookup and SSL

The Microsoft Outlook Free/Busy Lookup option is not supported for users who access Calendar Server in SSL mode. To use both SSL and non-SSL mode for the same Calendar Server instance, users must specify different port numbers, as follows:

For information about SSL, refer to Chapter 8, Configuring SSL, in Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Calendar Server Delete Log Database

Calendar Server 6 2004Q2 or later includes the Delete Log database (ics50deletelog.db) to store deleted events and todos (tasks). For information, refer to Chapter 18, Administering the Delete Log Database, in Sun Java System Calendar Server 6 2005Q4 Administration Guide.

System Folder Mapping Interoperability With Communications Express

While IMAP protocol defines only one system folder for incoming mail (INBOX), mail clients such as Outlook and Sun Java System Communications Express define their own system folders for drafts, sent mail, and deleted mail. The mail clients have no way of distinguishing those folders. These system folders are created by different preferred names and localized names according to locale and client software. This causes multiple physical IMAP folders that are created for a system folder if a single email account is accessed by more than one email client (or same email client, but accessed by a different locale machine).

In Outlook the folder naming is:

In Communications Express the folder naming is:

Defining the System Folders for Outlook

A new Sun Java System Connector for Microsoft Outlook mail system mapping file is available to provide better interoperability between Outlook and Communications Express. This solution allows the administrator to configure how system folders are mapped. The uwc_folders.map file contains the system folder mapping definitions for Communications Express. The outlook_folders.map file contains the system folder mapping definitions for Connector for Microsoft Outlook.

You can choose one of the mapping folders files to use as the default system folder mapping definition files in the Deployment Configuration Program (under the Mail tab). Select either Outlook style or Communications Express style to indicate which of these two standards the user program should use to name users’ IMAP folders. Your selection here determines which of two map files, outlook_folders.map or uwc_folders.map, will be used to map users’ IMAP folder names. An administrator may, before running this program, edit these files to suit local requirements, as long as the original filenames remain the same.

Defining the System Folders for Communications Express

Next, the system folders for Communications Express need to be defined. The i18n.js file defines the system folder names for Communications Express. This file is located in the /var/opt/SUNWmsgsr/config/html/ lang directory, where lang is the specific localized language (for example fr for French). This file needs to be modified so that the mapping entries are similar to the entries in the sjoc_folders.map file.

For example, by default folder mappings in the French i18n.js file are:

i18n[’INBOX’] = ’Inbox’
i18n[’trash folder’] = ’trash’
i18n[’draft folder’] = ’draft’
i18n[’sent folder’] = ’sent’
...
fldr[’INBOX’] = ’French Inbox’
fldr[’trash’] = ’French Trash’
fldr[’draft folder’] = ’French Draft Folder’
fldr[’sent folder’] = ’French Sent Folder’

The values for i18n[x ] are used to create system folders in the IMAP store. For example, if i18n[’trash folder’]= ’trash’, then a folder with folder name trash will be created in the IMAP store. The values for fldr[y] are used for displaying the system folder names in the client interface.

In the sjoc_folders.map file, the similar folder mappings are:

[fr]
INBOX=’Boîte de réception’
Deleted Items=’Éléments supprimés’
Drafts=’Brouillons’
Sent Items =’Éléments envoyés’

So, the French i18n.js folder mappings should be modified to match the sjoc_folders.map file:

i18n[’INBOX’] = ’Boîte de réception’
i18n[’trash folder’] = ’Éléments supprimés’i18n[’draft folder’] = ’Brouillons’
i18n[’sent folder’] = ’Éléments envoyés’
...
fldr[’INBOX’] = ’Boîte de réception’
fldr[’trash’] = ’Éléments supprimés’
fldr[’Drafts’] = ’Brouillons’
fldr[’Sent’] = ’Éléments envoyés’

You will need to modify each language represented by a i18n.js file.

Note –

Because the i18n.js files are written in UTF8 code, you will need to use and editor that will preserve the UTF8 code.

This new folder mapping definition is only effective for new users.

Before users log into Communications Express, the users' preferred language needs to be set. To do this, set the preferredLanguage or preferredLocale attribute using the ldapmodify command.

New users should see only one set of system folders, except in the following case:

A user logs into Outlook with the locale set to French. Later, the same user logs into Communications Express with the preferred language set to English. This user sees system folders trash, draft, sent, Éléments supprimés, Brouillons, and Éléments envoyés in both Outlook and Communications Express.

LDAP Configuration in Clients

All the client products that are released with Sun Java System Communications Services allow users to search the corporate directory and their own address books. While this does work, some LDAP tuning might improve the user experience.

This section discusses:

Setting up International Searches

Whether using Communications Express or Connector for Microsoft Outlook, performing search in your personal contacts or the public address book for a particular string is a locale-specific operation. For example, a French user searching for “Gaelle” expects to get back entries containing the string “Gaelle” but also any entry containing the string “Gaëlle.”

The various rules driving the way entries are presented to a user based on locale are called collation rules or collation order. The collation order provides language and cultural-specific information about how the characters of a given language are to be sorted. It identifies things like the sequence of the letters in the alphabet, how to compare letters with accents to letters without accents, and if there are any characters that can be ignored when comparing strings. The collation order also takes into account culture-specific information about a language, such as the direction in which the language is read (left to right, right to left, or up and down).

The Sun Java System Directory Server supports a large variety of locales and collation rules (See “Identifying Supported Locales” in the Sun Java System Directory Server 5 2005Q1 Administration Reference). Depending on your user base, you first need to choose the locale that makes the most sense in your environment. In the following, we will use the English (US) locale (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1) as an example.

To specify which locale to use when performing a search, use the matching rule filter syntax, described in “Searching an Internationalized Directory” in the Sun Java System Directory Server 5 2005Q1 Administration Reference. This syntax lets you to specify the locale as well as the type of search (equality, substring, and so on).

For example, the following filter will perform a substring comparison (.6) on the CN attribute, using the English (US) collation rules (1.3.6.1.4.1.42.2.27.9.4.34.1). The filter looks at the CN for strings starting with “Gae”

cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*

Updating the Indexes

When performing an LDAP search, most performance problems are due to the fact that indexes are not present or are not properly configured. By default, the Directory Server is configured so that lookups issued by Communications Express or by Connector for Microsoft Outlook are indexed and should return in a reasonable amount of time. Nevertheless, the Directory Server is not set up for international searches. So one need to alter the existing indexes so that they take into account the collation rules that have been chosen. This is described in the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

For example, the CN attribute is indexed by default in the userRoot suffix:

# ldapsearch -D "cn=Directory manager" -b 
"cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" 
"objectclass=*" 
cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config 
objectClass=top objectClass=nsIndex 
cn=cn 
nsSystemIndex=false 
nsIndexType=pres 
nsIndexType=eq 
nsIndexType=sub

To enable it for international searches using the English (US) collation rules, add one nsMatchingRule attribute with the English (US) OID. The clients perform substring searches so it is necessary to add the substring suffix (“.6”) to the OID :

#ldapmodify -D "cn=Directory manager"
dn: cn=cn,cn=index,cn=userRoot,cn=ldbm database, 
 cn=plugins,cn=config
changetype: modify
add: nsMatchingRule
nsMatchingRule: 1.3.6.1.4.1.42.2.27.9.4.34.1.6
Note –

Do not add any space, tab, or other non-visible characters at the beginning or at the end of the value.

Note –

The nsMatchingRule is a multivalued attribute. Different types of searches for the same OID, or different OIDs can be added.

One must then run the db2index.pl script located under serverroot/slapd-instance:

# perl db2index.pl -D "cn=Directory Manager" -w \ 
secret -n userRoot -t cn

This operation is run online and may take some time to finish. Alternatively the suffix can be reinitialized. See “Reinitializing a Suffix” in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

The console can also be used to add the nsMatchingRule (see the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide).

In the following sections, the list of indexes that need to be modified is provided. Ensure that no non-indexed searches are performed. This can be done by looking at the Directory Server access log file (and looking for a notes=U in the search results entries).

Setting up the Search Filter in Communications Express

The search filter used by Communications Express needs to be changed to accommodate the matching rule syntax. This is achieved by enabling the collation rule parameters specified in the db_config.properties file (which resides under deployed-path/WEB-INF/ldappstore (for personal store) and deployed-path/WEB-INF/corp-dir (for corporate directory).

The parameters are:

# Collation Rule
# Uncomment below to apply collation rule

# collation_rule=en-US

# Search Fields for which collation rule should be applied.
# The fields provided here should be disambiguator formatted fields
# e.g. entry/displayname, person/givenname etc.
# Uncomment below to supply the comma-separated fields

# search_fields=entry/displayname

Uncomment the collation_rule and search_fields parameters to enable the collation rule. In order to specify a separate set of field or fields in the search, change the value of search_fields to the desired values. The collation_rule can contain either the language tag or the OID corresponding to that language (in the example 1.3.6.1.4.1.42.2.27.9.4.34.1) without the suffix specifying the type of search. The Web Container Instance needs to be started after making the change.

The following attributes should be indexed on the LDAP Server for international search against Communications Express:

Allowing Anonymous Access to the corporate Directory

The Connector for Microsoft Outlook can be configured to bind using a DN and password or to bind as anonymous. To enable anonymous access to the corporate directory, add an ACL at the root level of the ou=people/ou=group sub-trees.

For example, if the root level is dc=red,dc=sesta,dc=com, do the following:

#ldapmodify -D "cn=Directory manager" 
dn: dc=red,dc=sesta,dc=com 
changetype: modify 
add: aci 
aci: (targetattr != "userPassword") 
  (version 3.0;acl "Anonymous access"; 
  allow (read,compare,search)
  (userdn = "ldap:///anyone");)

Allowing Directory Browsing

New in this 7 2005Q4 release, Connector for Microsoft Outlook now allows the end user to browse directories. When bringing up the address book page, the first 10 entries in the directory are shown. The user may then scroll up and down, or type a few characters and see the results automatically refreshed. This is a change from previous versions of Connector for Microsoft Outlook where the user was only able to search for one particular user.

To enable this feature while keeping good performance, the connector relies on two LDAP control extensions called Virtual List View (VLV) and Server Side Sorting of Search Results (RFC 2891). The following ldapsearch example returns the list of supported controls:

# ldapsearch -s base "objectclass=*" supportedControl 
supportedControl=2.16.840.1.113730.3.4.2 
supportedControl=2.16.840.1.113730.3.4.3 
supportedControl=2.16.840.1.113730.3.4.4 
supportedControl=2.16.840.1.113730.3.4.5 
supportedControl=1.2.840.113556.1.4.473  ------> Server Side Sort Control 
supportedControl=2.16.840.1.113730.3.4.9 ------> VLV Control 
supportedControl=2.16.840.1.113730.3.4.16 
supportedControl=2.16.840.1.113730.3.4.15 
supportedControl=2.16.840.1.113730.3.4.17 
supportedControl=2.16.840.1.113730.3.4.19 
supportedControl=1.3.6.1.4.1.42.2.27.9.5.2 
supportedControl=1.3.6.1.4.1.42.2.27.9.5.6 
supportedControl=2.16.840.1.113730.3.4.14 
supportedControl=1.3.6.1.4.1.1466.29539.12 
supportedControl=2.16.840.1.113730.3.4.12 
supportedControl=2.16.840.1.113730.3.4.18 
supportedControl=2.16.840.1.113730.3.4.13

The Sun Java System Directory Server does support both controls. Nevertheless, the VLV control is by default only available to authenticated users:

ldapsearch -D "cn=Directory Manager" -b \
"oid=2.16.840.1.113730.3.4.9,cn=features,cn=config" \
"objectclass=*" aci oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \
aci=(targetattr != "aci")(version 3.0; acl "VLV Request Control"; \
allow( read, search, compare, proxy ) userdn = "ldap:///all";)

To allow anonymous access to the VLV control, add the corresponding ACI:

#ldapmodify -D "cn=Directory Manager" \
dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \
changetype: modify add: aci aci: (targetattr !="aci")\
(version 3.0; acl "VLV Request Control"; allow (compare,read,search) \
userdn = "ldap:///anyone"; )

To improve the performance of searches requiring VLV plus Sort, create a Browsing Index in the Directory Server (as described in “Managing Browsing Indexing” in the Sun Java System Directory Server 5 2005Q1 Administration Guide). Each Browsing Index is specific to one base DN, search filter, scope, and sorting attribute. The VLV settings can be tuned on the client side using the deployment configuration tool.

In that particular case, a Browsing Index needs to be created for a base dn equal to dc=red,dc=iplanet,dc=com, a filter equal to (&(mail=*)(cn=*)), using a sort on the cn attribute. The Browsing Index information is added into the configuration containing the base dn (in this case userRoot):

#ldapmodify -D "cn=Directory Manager" 
dn: cn=Browsing red.sesta.com,cn=userRoot, 
cn=ldbm database,cn=plugins,cn=config 
changetype: add 
objectClass: top 
objectClass: vlvSearch 
cn: Browsing red.sesta.com 
vlvbase: dc=red,dc=sesta,dc=com 
vlvscope: 2 
vlvfilter: (&(mail=*)(cn=*)) 
aci: (targetattr="*") 
(version 3.0; acl "VLV for Anonymous"; 
allow (read,search,compare) 
userdn="ldap:///anyone";) 
dn: cn=Sort by cn, cn=Browsing red.sesta.com,cn=userRoot, 
cn=ldbm database,cn=plugins,cn=config 
changetype: add 
objectClass: top 
objectClass: vlvIndex 
cn: Sort by cn 
vlvSort: cn

Next run the vlvindex command located under serverroot/slapd-instance:

# ./vlvindex -n userRoot -T "Sort by cn"