This document summarizes the features in Oracle Communications Unified Communications Suite 7 Update 2 that are new or have been enhanced since Oracle Communications Suite Unified Communications Suite 7 Update 1 for the following components:
|Oracle Communications Messaging Server||7 Update 4 (Patch 23)|
|Oracle Communications Instant Messaging Server||9|
|Convergence||2 (Patch 2)|
|Oracle Communications Calendar Server||7 Update 2|
|Delegated Administrator for Oracle Communications Unified Communications Suite||7 (Patch 4)|
|Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite||7.3 Update 1 (Patch 13)|
|Indexing and Search Service for Oracle Communications Unified Communications Suite||1 Update 3|
|Messaging Server HA Agent (MS_SCHA)||7|
|Instant Messaging HA Agent (IM_SCHA)||7.3|
|Dssetup for Oracle Communications Unified Communications Suite (comm_dssetup)||6.4 (Patch 23)|
Check Communications Suite Component Patches for current patches that have shipped since the initial Communications Suite 7 Update 2 release.
Where appropriate, What's New information for those patches is also included in this document.
This document contains the following sections:
- What's New in Communications Suite 7 Update 2
- What's New in Convergence 2
- What's New in Messaging Server 7 Update 4
- What's New in Calendar Server 7 Update 2 and Update 3
- What's New in Indexing and Search Service 1 Update 3 and Update 4
- What's New in Instant Messaging 9
- What's New in Delegated Administrator 7
- What's New in Connector for Outlook 7.3 Update 1
- What's New in DSsetup 6.4
Communications Suite 7 Update 2 includes the following new feature:
Support for Oracle Linux 64-bit version 5.5 and greater has been added to Communications Suite 7 Update 2. Only Redhat compact kernel version is supported at this time.
Convergence 2 includes the following new features:
- Convergence 2 Patch 2 New Features
- Convergence 2 Patch 3 New Features
- Convergence 2 Patch 4 New Features
- Convergence 2 Patch 5 New Features
The following new features were introduced in Convergence 2 Patch 2:
Customizing Address Book Search Capability contains instructions on customizing search attributes in Address Book.
A new configuration parameter has been introduced: IgnoreURLDomain (true/false), which prevents using the URL domain for resolving the user.
Default setting in configuration parameter:
The following new features were introduced in Convergence 2 Patch 3:
- S/MIME Support for Use with Firefox Browsers
- Calendar Server 7 Update 2 Patch 5 Integration
- Display Name Enhancement
- Customizing Font Display
- Japanese Yen (¥) Printing and Display Enhancements
Beginning with Convergence 2 Patch 3, S/MIME support for use with Firefox is available. Specifically, S/MIME is supported on:
- Firefox 8 on Windows 7 platforms
- Firefox 7 on Windows XP platforms
With Calendar Server 7 Update 2 Patch 5 integrated with Convergence 2 Patch 3, the following new privacy setting options are available to users in the Convergence UI:
- Users have the ability to manage and to grant privileges to other users
- Users can only add invitees to an invitee list if those invitees have granted scheduling privileges
- Users have the ability to check scheduling privileges before inviting other users
Specifically, in setting Privacy Settings, a user is able to select the Manage option to grant other users Manage permissions for privacy settings. From the corporate address book, a user can select the user who has granted privileges to manage privacy settings. If a user attempts to add another user to an invitee list who has not granted scheduling privileges, or if a user views the privacy settings of a user who has not authorized Manage permissions for privacy settings, the following error is displayed: "You do not have permission from this user to perform this action."
For more information, see: Managing Calendar Permissions and Calendar Privacy Settings in Convergence.
This display name enhancement changes the mapping of the Convergence Display Name from the cn attribute to the LDAP displayName attribute.
- With the new mapping, Convergence uses the LDAP displayName value in the Welcome screen, in the Compose Mail panel, and so on.
- If the LDAP displayName is not populated with a value, Convergence uses the cn attribute as a fall back. When a user modifies the Convergence display name, the LDAP displayName attribute is populated.
- The Convergence UI Address Book search field includes the Display Name while performing a search.
- Users are able to change their display names in the Options -> Mail -> Identities -> Local Account panel of the Convergence UI.
To configure Convergence display name and to configure Address Book display name search see Administering Convergence Display Name to Map to LDAP displayName.
The following customization examples were added to customize font and symbol display:
To add and remove fonts in the Editor menu, see: Customization Example - Adding and Removing Fonts in the Editor Menu.
While the the ASCII equivalent of the backslash keyboard entry (\) in a Japanese environment should display the Japanese Yen (¥) symbol, on some fields in the Convergence UI (such as the Subject or Body of a Mail message), the backslash (\) is mistakenly displayed. The following customization examples explain how to customize the Convergence UI so that the Japanese Yen symbol (ASCII equivalent of the backslash keyboard entry (\) in a Japanese environment) is printed properly.
The following new features were introduced in Convergence 2 Patch 4:
- Firefox 9 Support
- Displaying Attachment Progress Indicator
- New Customization Examples
- Updated Convergence Configuration Reference
Beginning with Patch 4, Convergence is supported on Firefox 9 on Windows Vista and on Windows 7 platforms. See: Convergence Browser Requirements.
For web browsers that support HTML 5 file objects, you can enable or disable the attachment progress indicator for mail attachments. A calendar attachment progress indicator is not available at this time. HTML5 web browsers include most web browsers except for Internet Explorer 8 and 9. For information on enabling the attachment progress indicator, see client.uploadfilemethod in Convergence Configuration Properties Reference.
Beginning with Convergence 2 Patch 4, use the following customization examples to:
Additional customization examples have been added, but they are not specific to Convergence 2 Patch 4. See Convergence Customization Guide for recently added customization examples.
Default values have been added or updated in the Convergence Configuration Properties Reference.
The remaining changes to Convergence 2 are bug fixes only.
The following new features were introduced in Convergence 2 Patch 5:
Convergence supports Google Chrome browsers, starting with Convergence 2 Patch 5.
The Convergence cal.autoprovision configuration parameter is now off by default, beginning with Convergence 2 Patch 5.
Convergence treats any entered search string as a 'starts with' search in the Corporate Address Book. For example, if a user enters foo, results beginning with foo are listed.
In addition, an asterisk ('*') in a search string acts as a wildcard and allows you to perform a "contains search" or a "substring-any" search. For example, *foo matches strings ending in 'foo'.
To look up numeric error codes related to SSL/TLS, see: http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html. For more information, see: Certificate Based Authentication for Messaging Server.
This remaining changes to Messaging Server 7 Update 4 are bug fixes only.
Calendar Server 7 Update 2 shipped as part of Communications Suite 7 Update 2. Calendar Server 7 Update 3 is a patch (patch 8) that shipped after the Communications Suite 7 Update 2 release.
Calendar Server 7 Update 2 includes the following changes and new features:
- Support for Oracle Database
- Apple iCal Delegation
- Apple iCal Private/Confidential Reconciliation
- Certificate Authentication Support
- Virus Scanning Capability
- Connector for Outlook Support
- davadmin Security Enhancements
- Enhanced Error Logging for Calendar Data Import
- Log File Name Change
- Notifications for Calendar Sharing
- Notification Templates Customization
- Domain ACLs
- Disabling Attachments
- Purging Collections
- Blocking Certain Clients
- Tool to Support Email Address Change
- Scheduling Logging for Specific Users
Calendar Server 7 Update 2 provides support for the Oracle Database as the calendar server back end (calendar store). This release of Calendar Server has been certified with Oracle Database 11g Release 2.
Calendar Server 7 Update 2 adds support for Apple iCal style delegation. Using this feature, users grant read or write access to their calendar directly from Apple iCal (by using the Accounts pane of iCal Preferences). Unlike with WCAP-based clients (such as Convergence and Connector for Microsoft Outlook), where privileges can be granted at each individual calendar level, Apple iCal delegation works at the account level. Thus, when you grant a user delegation privilege you give that user access to all of your calendars.
Calendar Server 7 Update 2 enables a form of per-calendar event access control by using the PUBLIC/PRIVATE/CONFIDENTIAL classification properties. Apple iCal exposes a similar functionality but uses a proprietary mechanism. Starting with Calendar Server 7 Update 2, the server supports both types of classifications.
The Apple caldav-privateevents extension is equivalent except for the following differences:
- It offers four levels of granularity.
- The classification information is not stored in the iCalendar CLASS property, but rather in the X-CALENDARSERVER-ACCESS private property, located at the VCALENDAR component level.
While the private events extension allows for four values (PUBLIC/CONFIDENTIAL/RESTRICTED/PRIVATE), only the PUBLIC and CONFIDENTIAL values are currently used and set by Apple iCal.
The following table shows the mappings from the CLASS to the X-CALENDARSERVER-ACCESS property.
CLASS to X-CALENDARSERVER-ACCESS Mapping
|PUBLIC||PUBLIC|| All of the calendar data is visible.
|PRIVATE||CONFIDENTIAL|| None of the calendar data is visible.
|CONFIDENTIAL||CONFIDENTIAL|| Only the start and end times of each instance is visible.
Because Apple iCal only uses PUBLIC and CONFIDENTIAL, the reverse mapping from X-CALENDARSERVER-ACCESS to CLASS is a direct mapping.
Calendar Server 7 Update 2 supports certificate-based authentication. In certificate-based authentication, clients request access to a protected resource, such as the Calendar Server. The server presents its certificate to the client, which the client verifies. If the verification succeeds, the client then sends its certificate to the server and the server verifies the client's credentials. As long as the client's credentials are verified, the server grants access to the protected resource.
Currently, only Connector for Microsoft Outlook supports certificate authentication. For more information, see How to Configure Oracle Communications Sun Calendar Server Client Authentication.
Calendar Server 7 Update 2 enables attachments virus scanning by making use of the Messaging Server MTA and its capability to interface to many different AVS systems. Calendar Server packages the calendar event and attachment and sends it by using SMTP to the Messaging Server MTA, where the scanning takes place on the configured AVS system. Messaging Server relays the result of the scan to Calendar Server. Calendar Server can be configured to test and optionally reject incoming data, as well as scan (and optionally delete) existing data by using the davadmin vscan utility. For more information, see Configuring and Administering Virus Scanning in Calendar Server.
Calendar Server 7 Update 2 supports Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite as a calendar client. End users can use Connector for Microsoft Outlook to view and update their Calendar Server 7 calendars. For more information, refer to the Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite online help. You must use at least Connector for Microsoft Outlook 7.3 Update 1 patch 13.
The davadmin command has been made more secure in Calendar Server 7 Update 2 by the removal of the capability to "pass in" passwords by using a password file. All davadmin passwords must now be entered by typing in to a no-echo prompt.
Calendar Server 7 Update 2 provides enhancements to calendar data import through the davadmin import command and the import.wcap command to log errors for incorrect data then continue processing.
The Calendar Servers 7 Update 2 error log file name has been changed from calendar.* to errors.*.
How do you know if users have shared their calendars with you? Email notifications let you know.
Calendar Server 7 Update 2 generates email notifications when users share their calendar or account with another user or users. After receiving the email notification, the shared-with user can then subscribe to the sharer's calendar or account.
Sharing at the account level is also referred to as "delegation." Apple iCal implements delegation or sharing at the account level.
Calendar ACLs range from no permission, to read, write, and all. When users modify their calendar ACLs, and add at least read permission to another user or a group, Calendar Server sends an email notification to the user or the group. Calendar Server sends the notification to the email address that is associated with the user or group that is being granted sharing permission in the ACL list.
A share notification email is sent only if a user changes an ACL from a privilege of none to the granting of a read, write, or all privilege. A share notification email is not sent if a user later changes ACL permissions to allow more privileges, for example, from read to all.
Shared calendar to a user:
Shared calendar to a group:
Shared account to a user:
Calendar Server 7 Update 2 provides preformatted notification messages to be sent to calendar owners when changes occur in calendar resources and properties. You can customize these files for your own deployment. Calendar Server 7 Update 2 contains a number of these preformatted message files. For example, the request.fmt file is for scheduling request notification email messages, and the sms.fmt file is for alarm SMS messages.
For more information, see Using Calendar Server 7 Notifications.
Starting with Calendar Server 7 Update 2, domain ACLs control calendar operations that span multiple domains. Calendar Server 7 combines domain ACLs with the calendar and scheduling ACLs to grant or deny levels of access to any calendaring or scheduling operation. All operations within a single domain rely strictly on the calendar and scheduling ACLs.
For more information, see Managing Domain Access Controls.
Calendar Server 7 Update 2 enables you to globally disable storage of attachments in the document store by using the davcore.attachment.enable parameter. When set to false, the davcore.attachment.enable turns off attachment storing. You do not need to restart Calendar Server for this parameter to take effect.
Calendar Server 7 Update 2 enables you to purge events and todos that are older than a certain date in all calendar collections of a given user. This utility is useful for reclaiming disk space.
To run the utility, use the davadmin account delcomponent command. For more information, see davadmin account.
Calendar Server 7 Update 2 includes the capability to block requests from certain versions of CalDAV clients and WCAP clients that are known to be problematic. The HTTP 403 status is returned for such clients that are blocked. This capability helps to prevent denial of service attacks by blocking rogue clients that can inundate the server with requests. For more information, see the service.dav.blacklist and service.wcap.blacklist configuration parameters.
Calendar Server 7 Update 2 includes a new davadmin account repair -a account command for email address changes. When a change in a user's email address occurs, run this command to fix notification addresses, organizer addresses, attendee addresses, and alarm addresses.
Tracking calendar scheduling issues can be a complex task. To ease debugging of such issues, Calendar Server 7 Update 2 offers the ability to turn on scheduling logging on a per user basis.
In Calendar Server 7 Update 2, for scheduling, FINE level logging is done to the errors.0 file for all scheduling actions of a specific user if that user's email address is in the davcore.scheduling.schedulinglogfilter configuration parameter. Of course, if the log level is set to FINE or higher, all scheduling logging is done regardless of the value of the schedulinglogfilter
Calendar Server 7 Update 2 Patch 5 includes the following features:
- Allow Double Booking by Resource Calendar Owners
- List and Manage Resource Accounts of a User
- Support for gzip Compression
- Improved Command Logging
- Support for Mac OS 10.7 and Apple iOS 5
- Ability to Define an LDAP Entry as a Valid Calendar Account Based on Custom Provisioning
Patch 5 has special privileges for resource owners to double book a resource even if the resource calendar attendant flag is set to prevent it. This is controlled by the davcore.scheduling.allowownerdoublebooking configuration parameter. If set to true, davcore.scheduling.allowownerdoublebooking enables double booking.
In Patch 5, the list.wcap command has been modified to list a user's owned resource account calendars in addition to the user's calendars. The davadmin command has also been updated to list calendars belonging to resource accounts owned by a user.
Patch 5 implements gzip content-encoding in Calendar Server on HTTP responses.
The Calendar Server commands log file contains entries that help monitor requests to the server to diagnose problems. In Patch 5, commands logging is enhanced to pass additional information, including the principal account that authenticated and what operations were performed from that account.
Patch 5 provides support for devices running Mac OS 10.7 and Apple iOS 5.
Patch 5 enables you to define what LDAP object class is required to consider an entry as a valid calendar user entry by using the davcore.ldapattr.userobject configuration parameter. By default the value is empty, which means all users are considered valid calendar users. If you want to restrict calendar access to users decorated with a certain object class, typically icsCalendarUser, set the davcore.ldapattr.userobject parameter to icsCalendarUser. You can set it to your own object class if you use custom provisioning.
Calendar Server 7 Update 3 includes the following changes and new features:
- Authenticating Against a Directory External to the Calendar Server Environment
- Booking Window for Calendars
- Changes to the davadmin Command
- Enable and Disable Account Autocreation
- LDAP Pools
- New Configuration Parameters
- New Languages
- New populate-davuniqueid Utility
- New Schema Objects
- Non-active Calendar Accounts Are No Longer Searched or Fetched
- Remote Document Store Authentication
Calendar Server 7 Update 3 enables authentication against a separate, LDAP directory external to the Calendar server environment. Such a configuration is useful in hosted environments for delegating one administrative aspect to a provider (managing the Calendar Server front- and back-end hosts and LDAP directory with non-sensitive data), while maintaining control over the LDAP user passwords in the internal, corporate network. In this setup, Calendar Server would use the external directory for authentication.
For more conceptual information on Calendar Server and external authentication, see Calendar Server and Directory Server Integration. To configure Calendar Server for authentication against an external Directory Server, see Configuring External Authentication.
Calendar Server 7 Update 3 supports the use of a system-wide minimum booking window for calendars through the use of the new davcore.scheduling.minbookingwindow configuration parameter. This new parameter compliments the existing maximum booking window support (davcore.scheduling.maxbookingwindow) parameter. In addition, starting in Calendar 7 Update 3, you can set account-level minimum and maximum booking window properties through the davadmin account command or clients that use the WCAP set_accountprops command. The minimum and maximum booking window values define a window of time relative to current time, between which Calendar Server allows the account to be scheduled. Calendar Server enforces the booking window by returning a busy response to the freebusy check done by the scheduling agent if the requested time is outside the booking window. In addition to setting the booking window, you should also set the account's scheduling flag to "decline on conflict" for the window to take effect. The booking window setting also affects calendars configured to auto accept invitations. In the case where auto decline is also configured, it takes precedence over auto accept.
To configure both the minimum and maximum booking windows for accounts, you can use either the davadmin command or the set_accountprops.wcap interface. In absence of an account property, Calendar Server defaults to using the corresponding system-wide booking window configuration.
Upfront Freebusy Check for Control of Doublebooking and Booking Window During Scheduling
A scheduling attempt requested for an account that has its attendance flag set to "decline on conflict" (the attendance flag is set either by a set_accountprops.wcap command or davadmin account command), triggers Calendar Server to perform a special freebusy check. This check happens as part of the scheduling process for both CalDAV and WCAP clients. Because scheduling is an asynchronous process, the event organizers are made aware of an error only after they have made the booking. However, for clients that use the WCAP protocol, the same check is performed upfront if the scheduled attendee is a resource. This enables the organizer to get an immediate error if the event request results in a conflict for the resource.
In Calendar Server 7 Update 3, the davadmin command has been updated with the following changes:
- The passfile option has been updated to accommodate setting a password on the remote document store and corresponding password entry in Calendar server front end that needs to communicate with the document store.
- A new command, davadmin ldappool, has been added to support LDAP pools, which are used in configuring external Directory Server authentication.
- The davadmin account list command now displays a list of all users in the database and their details.
For more information, see Calendar Server 7 Command-Line Utilities.
Calendar Server 7 Update 3 provides the capability to enable or disable, on a system-wide basis, the calendar account autocreation, either on login or invite. For more information, see the davcore.autocreate.enableautocreate parameter in Calendar Server 7 Configuration Parameters.
Starting with Calendar Server 7 Update 3, you can create LDAP pools for use in authenticating against an external directory. For more information, see the davadmin ldappool command and also Configuring External Authentication.
Calendar Server 7 Update 3 introduces the following configuration parameters:
- davcore.autocreate.rescalcomponents: Assigns the default autocreation setting for supported calendar components for a new resource calendar
This parameter enables migrated resource calendars to allow the VEVENT and VTODO components that were permitted in Calendar Server 6. (The default value for this parameter is VEVENT.) To ensure that Calendar Server 6 resource calendars correctly have all their VEVENT and VTODO information migrated to Calendar Server 7, set this parameter to VEVENT VTODO before doing the migration, if your deployment has resource calendars that contain more than just events. For more information, see [Calendar Server 7 Configuration Parameters].
- davcore.scheduling.allowownerdoublebooking: If set, owners of resource calendars can double book even if the resource account prevents doublebooking
- davcore.scheduling.minbookingwindow: Specifies the start of a booking window, in days, from the time of scheduling, from which a calendar can be booked in advance
For more information, see Calendar Server 7 Configuration Parameters.
Calendar Server 7 Update 3 also includes the service.host parameter for the document store ashttpd.properties file.
For Calendar Server 7 Update 3, the product configuration program and all notifications that are sent by the server have been localized into the following additional languages: German, Spanish, Korean, Simplified Chinese, and Traditional Chinese.
Calendar Server 7 Update 3 introduces a new LDAP attribute named davUniqueId. This attribute replaces the problematic nsUniqueId attribute, whose value is lost when an LDAP entry is deleted and then recreated. (See Changing User uuid for more information about the issues with the nsUniqueId attribute.)
To set the value of the davUniqueId attribute to the current value of the nsUniqueId attribute for existing LDAP entries, use the new populate-davuniqueid utility.
For more information, see Calendar Server Unique Identifier.
The following LDAP schema objects are added to Calendar Server 7 Update 3 to support authentication against an external Directory Server:
- externalAuthPreUrlTemplate: This attribute is used for authentication by using external Directory Servers. Its value is an LDAP URL that defines how users must be searched for in the external Directory Server against which authentication is performed.
- externalAuthPostUrlTemplate: This attribute is used for finding the internal Directory Server entry for a user who authenticated by using external Directory Servers. Its value is an LDAP URL that must be used to map the external Directory Server authenticated user to a user in the internal Directory.
The following LDAP schema attribute is also added:
- davUniqueId: This attribute can be used to define a unique ID for any davEntity user, group, and resource object, much like the operational attribute nsUniqueId. It is recommended that davUniqueId be used as the value of the davcore.uriinfo.permanentuniqueid configuration parameter.
These new elements are required by Calendar Server 7 Update 3. Schema changes are applied to Directory Server when you run the comm_dssetup script. When upgrading to Calendar Server 7 Update 3, you need to first apply the comm_dssetup 6.4 patch (at least 6.4-24.02) and run the updated comm_dssetup script against your Directory Server instances. See Upgrading to Oracle Communications Calendar Server 7 Update 3 for more information.
Starting with Calendar Server 7 Update 3, if a calendar account's LDAP icsStatus attribute is populated and is not set to active, the account is not searched nor are any results fetched for that account when running Calendar Server davadmin or WCAP commands. That is, Calendar Server returns search results only for active accounts and does not return unusable data such as inactive calendars.
Calendar Server 7 Update 3 provides enhanced security for remote document stores. A remote document store now requires password authentication for the connection between the Calendar Server and the remote document store server. The password needs to be known by both the document store client (which runs in the Calendar Server itself) and the remote document store server (which runs on the remote host where the store is located). The password is stored in a password file (called a wallet) on each of the hosts.
For information on configuring the remote store password, see To Configure Remote Document Store Authentication.
Indexing and Search Service 1 Update 3 brings performance improvements including increased indexing speed and more efficient memory utilization of the Index Service.
The following features, first made available in the ISS 1 Update 2 patch, are also part of ISS 1 Update 3:
- Refreshing the Configuration
- New and Extended Command Options
- Cluster Search Service and High Availability
- Recovery After Service Outage
- Reduction in IndexSvc Memory Footprint and Other Scalability Improvements
- New Tools
- setup.sh Name Change
- Tools Moved to the examples Directory
- What's New in Indexing and Search Service 1 Update 4
You can now "refresh" the ISS configuration without having to restart services. The new --refresh command option to issadmin.sh causes ISS to read the configuration file and apply configuration changes that have been made since ISS was started (or a previous --refresh command was run). ISS makes the configuration changes without restarting any of its services, as long as the particular parameter is allowed to be refreshed.
Run issadmin.sh --help --refresh to view the list of refreshable configuration options.
The following table shows the new options for the issadmin.sh command.
New Options for issadmin.sh Command
|--altoutput FILE||Used with --accountlist option to provide an alternate output file for the results. Normally results appear on stdout and stderr only after the entire issadmin.sh command finishes. Directing the output by using the --altoutput option causes incremental results to appear while the command completes.|
|--backup||Creates a backup of the dIndex directory.|
|--bootstrap||Creates index for accounts. Replaces indexSvcBootstrap.sh and indexSvcFork.sh commands.|
|--checkconfig||Checks for changes to the configuration file that have not yet been applied. It is useful to run --checkconfig when you are making multiple changes.|
|--checkstore||Checks the status of the store after an outage or when problems with index corruption are suspected.|
|--loglevel LEVEL||Specifies level of logging information for commands. You must first stop the ISS services to use this option.|
|--refresh||Enables some configuration parameters to be updated without having to restart the services. Use the issadmin.sh --help --refresh command to display a list of parameters that apply.|
|--runoptimizer [true | false ]||Used with --bootstrap to specify whether to optimize the index after indexing. This option is equivalent to the option of the same name from the now obsolete indexSvcBootstrap.sh command.|
|--skipfolder FOLDER||Used with --bootstrap to specify a folder to be skipped during indexing. This can be useful if you are having problems with a particular folder during bootstrap. This option is equivalent to the option of the same name from the now obsolete indexSvcBootstrap.sh command.|
The following options have been extended to new uses:
- --help: Additional command options can be specified with this option to get more detail. Examples are --bootstrap and --refresh, which provide more detailed information specific to these options.
- --detail: Additional values for this option are used with the --checkstore command to provide more extensive checking. New values include dIndex and store.
The configure_etc.pl command has been enhanced to include the -C option, to generate a copy of the jiss.conf file for cluster configurations. See configure_etc.pl Usage.
New in Indexing and Search Service 1 Update 2 is the highly available Cluster Search Service. The Cluster Search Service requires that you configure the deployment to make the index available to the ISS web hosts over NFS. See Configuring Indexing and Search Service for High Availability for more information.
Indexing and Search Service 1 Update 2 addresses the following service outages:
- Index service process failure, which might cause dIndex corruption
- Interruption of JMQ and index services, which might cause the account index data to become out of sync
ISS 1 Update 2 attempts automatic recovery from these situations by:
- Utilizing automated backups of the dIndex
- Synchronizing recently modified accounts after a service outage
Additionally, ISS 1 Update 2 reduces the severity of failure by shutting down processing if the disk containing the store becomes too full. See the new configuration option, iss.store.diskfullpercent.limit, for more information.
In cases where a service outage has corrupted index data, which the automated recovery procedures could not correct, you can use tools to identify the index parts, user accounts, and main dIndex that need repair. See the new issadmin.sh commands --backup and --checkstore for more information.
The recovery improvements in ISS 1 Update 2 focus primarily on analyzing and fixing the dIndex, since it can become a single point of failure.
The dIndex is the global "directory index" that controls the ISS store. It is a single, unique Lucene index directory that contains the following information:
- Each account's location in the group index directories
- Account state information
- Various details about accounts such as folders and counts
- All information needed to manage the system
In contrast, the account group index directories contain all the indexing information for searching emails organized by account, with the various fields that can be used to search, such as subject, to, from, body, attachments, and so on.
ISS contains a single dIndex (with periodic backup copies) but many group index directories. Thus a failure in the dIndex might prevent ISS from working, while a failure in one (or even a group of) the group index directories only affects a limited number of accounts on the system.
Indexing and Search Service 1 Update 2 reduces its in-memory footprint and its use of Java heap and direct memory, resulting in improvements in overall scalability. For example, these improvements should enable you to bootstrap a larger amount of data in parallel by using less memory than previous releases.
Indexing and Search Service 1 Update 2 provides the following two new utilities:
- factorymgr.sh: Used to manage JNDI lookup attributes in LDAP or a file-based store. See factorymgr.sh for more information.
- csearchmgr.sh: Adds and removes Cluster Search Services for one or many indexing nodes. See csearchmgr.sh for more information.
The setup.sh initial configuration script has been rewritten and renamed to setup to better support deploying the ISS HA configuration.
ISS tools have been moved from the unsupported directory to the examples directory. The ISS 1 Update 2 release contains the following tools:
- createuserlist: Converts a list a users one per line to an ISS account list.
- initializeindex: Runs issadmin.sh --createaccount on a user list to initialize the index.
- issbootstrapstats: Displays statistics of ongoing bootstrapping progress.
- parallelbootstrap: Runs bootstrap in parallel.
- removeindex: Stops ISS, removes all indexes, attachment, and log files, and restarts ISS with a fresh index.
- isscollect: Collects log files for support purposes.
- issrehostprep.sh, issrehostfini.sh, and issrehost.template: Rehosts a single user.
Refer to the iss-base/examples/README file for more information on these commands.
Indexing and Search Service 1 Update 4 is available as a patch (delivered after the release of Communications Suite 7 Update 2), and includes the following features:
- Periodic ISS Account Check and Synchronization with Messaging Server
- Recovery after Messaging Server reconstruct Command
- Watcher Service and High Availability Improvements
- Performance Improvements
- Java 7 Support
This feature checks every ISS account against Messaging Server accounts at regular intervals to detect differences, for example, from a reconstructed folder or lost event notifications, that ISS can then automatically correct.
Two items control this periodic check:
- Periodic auto-sync: A periodic scan to check that all active ISS accounts are in sync.
- Periodic auto-bootstrap: A scan for accounts unknown to ISS and adding these accounts to a list to be automatically bootstrapped. It is the bootstrap action that is periodic, not the error scanning. The scanning for accounts that need to be bootstrapped occurs continuously as new events arrive and errors are detected. ISS adds the unknown accounts to the auto-bootstrap "to-do" list whenever trigger conditions are met. The periodic nature of the auto-bootstrap prevents too many accounts from being bootstrapped simultaneously, should many errors show up at once. This process enables the workload to be spread out among the Messaging Server and ISS hosts, instead of trying to correct every such error immediately.
For more information, see Administering Periodic Automatic Synchronization for Indexing and Search Service Accounts.
This feature fixes an issue where ISS becomes out-of-sync when a folder has been reconstructed on Messaging Server. When the reconstruct command runs, it may cause the UID validity value and/or UIDs assigned to emails in a folder to change, but does not trigger event notifications to notify ISS of the change. ISS now detects the UID validity mismatch while processing events and re-bootstraps the folder to get it back in sync.
This feature is designed for the implementation of highly available (HA) ISS nodes, however the service itself is useful even when you do not use HA (which is why it is included in this release). The watcher service provides local host monitoring of ISS services and alerts you, with log file messages and email warnings, when it detects a service outage. Once alerted, you can take the appropriate corrective action, such as restarting a service. The services that are monitored are dependent on the type of ISS installation on which the watcher is running. The iss.cluster.install parameter in the jiss.conf configuration file defines the ISS installation type:
For more information, see Administering the ISS Watcher Service.
Additionally, one of the HA improvements is to enable the cluster search service to run on the back-end nodes, making exposing NFS to the web tier unnecessary. For more information, see Configuring Indexing and Search Service for clusterv2.
The following performance improvements for this release are targeted at both general memory and time reductions, and to speed up specific styles of search queries:
- Search service: Email folder manager optimization reduces the number of indexReaders opened during search
- jmqconsumer process: Candidate file write optimization reduces the IO overhead during event processing of candidate file writing
- Index service: folderflag optimization reduces the average size of flag records for folders containing a large number of emails
Starting with this release of Indexing and Search Service, Java 7 is recommended, as Java 6 is entering end of life. If you generated your ISS indexes while on Java 6, once you upgrade to Java 7, you should regenerate the indexes. See Upgrading Indexing and Search Service for more information.
Instant Messaging 9 includes the following changes and new features:
- XML Configuration
- Facebook Gateway
- SIP/SIMPLE Support
- Notification System Using XMPP Pub-Sub
- IPv6 Support
- Calendar Server 7 Support
- MySQL Server Database
- Cluster Support for External Gateways
- What's New in Instant Messaging 9 Patch 1
Beginning with this release, Instant Messaging uses an XML-based configuration. Instant Messaging stores configuration settings in the iim.conf.xml file (located by default in the /opt/sun/comms/im/config directory). Beginning with Instant Messaging 9, you use the imconfutil command to make configuration changes. You no longer edit the iim.conf file in a text editor. Using an XML-based configuration reduces configuration errors caused due to manual edits and simplifies the overall system configuration.
Note the following:
- Instant Messaging 9 merges its multiple configuration files into one file, the iim.conf.xml file.
- A set of "common" properties is used across the Instant Messaging deployment or instance, including instancedir, installdir, and so on.
- Each component has its own configuration section in the file, for example, a server section, mux section, and so on.
- Some configuration properties are "complex," in the sense that they have more than one instance, and each instance has one or more keys.
- When you run the imconfutil command, the iim.conf.xml file is updated. You must refresh the Instant Messaging server for the new configuration settings to take effect.
Instant Messaging 9 users are now able to interact with the Facebook Instant Messaging Service. The Instant Messaging 9 Facebook Gateway enables Instant Messaging 9 users, who have a Facebook Instant Messaging account, to chat with their buddies on that network and share presence updates.
At a high-level, Instant Messaging 9 communicates with Facebook as follows:
- Facebook gateway is exposed to users as a service.
- Users register with the service by providing their Facebook Instant Messaging service credentials.
- Facebook gateway logs in users to their Facebook Instant Messaging account.
- The Facebook gateway performs the necessary work to transfer packets to and from the Facebook Instant Messaging Server.
Instant Messaging 9 implements SIP/SIMPLE federation and translation between the two protocols, and interoperation between XMPP and SIP/SIMPLE servers (for example, OpenSER and Microsoft Lync). SIP/SIMPLE provides presence subscriptions, basic roster management, text chat (pager mode), whitelist and blacklist federation, and privacy preferences. SIMPLE, the Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, is based on Session Initiation Protocol (SIP). Like XMPP, SIMPLE is an open standard.
Specifically, Instant Messaging 9:
- Provides a way for Instant Messaging server users to subscribe to the presence of contacts on an external SIP/SIMPLE network
- Enables messaging between users on the Instant Messaging server and their contacts on an external SIP/SIMPLE network
- Enforces the privacy preferences of the XMPP Instant Messaging Server users
Instant Messaging 9 supports XMPP Pub-Sub, which is a building block for applications that require real-time push notifications and data services. publish-subscribe activities. XMPP defines a protocol extension for generic Publish-Subscribe (Pub-Sub) functionality (see XEP-0060). Pub-Sub serves as a transport for applications that require event notifications such as newsfeeds, content-syndication, rich presence, and the like. Instant Messaging Server has included support for an early version of this protocol, which was used for the News feature of the now deprecated Instant Messaging client.
Specifically, Instant Messaging 9 provides a rewritten pub-sub implementation, which brings it up-to-date with the current specification
Instant Messaging 9 supports Internet Protocol Version 6 (IPv6), a version of the Internet Protocol that is designed to succeed Internet Protocol version 4 (IPv4).
Instant Messaging 9 provides support for event alarms in Calendar Server 7. See Configuring Instant Messaging 9 Calendar Agent with Calendar Server 7.
Instant Messaging 9 supports MySQL Server database as a data store for external gateways.
Starting with Instant Messaging Server 9, you can configure cluster support for gateways along with a shared storage support by using MySQL Server. By using gateway clusters, you provide for the ability to better scale the external gateways. Users no longer have to connect to a specific gateway in a pool of gateways. The client session remains "sticky" in the event of being disconnected.
Instant Messaging 9 Patch 1 includes the following changes and new features:
- Group Messaging
- Offline Messaging
- Default Password Changed
- Manually Configuring httpbind
- Protecting Deployed Instant Messaging Components
- New Configuration Parameter
Group Messaging in Instant Messaging is primarily related to You can configure Instant Messaging so that end users can send a message to an LDAP group, which can be either dynamic or static.
- LDAP dynamic group: Membership, rather than being maintained explicitly in a list, is determined by search criteria using an LDAP URL. Dynamic groups use the groupOfURLs object class and the memberURL attribute to define LDAP URLs with the criteria (search base, scope, and filter) to be used for determining members of the group.
- LDAP static group: A static group is one whose entry contains a membership list of explicit DNs. You can define a static group by using the groupOfUniqueNames object class and by explicitly specifying the member DNs using the member attribute.
To enable end users to view dynamic and static LDAP groups in search results and add them to their instant messaging client contact list, you need to include groupOfUrls objects in search results.
For more information about Group Messaging, see Managing Instant Messaging's LDAP Access Configuration.
When the offline chat message delivery feature is enabled on the Instant Messaging Server, regular instant messages (chat messages) that are sent to offline users are not discarded. They are available on the Instant Messaging Server, and delivered to the user when the user comes online. This feature can be enabled at deployment level or at domain level using the whitelisting facility. This feature can be disabled using the blacklisting facility.
However, Instant Messaging alerts are managed differently. The feature is enabled or disabled at the user level. Similar to offline chat messages, the Instant Messaging Server stores the alerts for the offline recipient, and delivers them when the user logs in next time. This is, if the user has configured to receive offline alerts during the next login.
If you install Calendar Server with Instant Messaging, you can configure your deployment such that you receive Instant Messaging alerts about your calendar todos and events, as pop-up messages. As long as you are logged in to Instant Messaging (you are online), you receive Calendar Server HTML pop-up reminders on your desktop. If you are offline, you receive the alerts the next time you login, if you have configured to receive offline alerts during the next login.
For more information about Offline Messaging, see Managing Instant Messaging Messages for Offline Users.
Starting with Instant Messaging 9 Patch 1, the default value for password configuration properties is random.
Starting in Instant Messaging Server 9 Patch 1, you can manually configure httpbind connections to "follow through" by using this command:
Starting with version 9 Patch 1, Instant Messaging deployments are more secure. In previous versions of Instant Messaging, the server listened to connections on the port defined by the iim_server.port parameter (the default value is port 5269) in various situations. These situations include a peer in a server pool, components such as external gateways, cal-agent, sms-agent, httpbind, and so on. In Instant Messaging 9 Patch 1, the server now listens to this port only when at least one of these options is configured.
The gwdomain-id.multihosting parameter in the httpbind.conf file, if set to true, allows a packet destined to a domain, which is not pre-configured in httpbind.conf, to be sent to Instant Messaging Server. You use this parameter for a hosted domain setup. The default value for this parameter is true. For more information, see Gateway Domain ID Key Parameters for httpbind.
The commadmin command has been made more secure by the removal of ability to specify the administrative password on the command line or to use a password file. All commadmin passwords must now be typed by using a no-echo prompt.
Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite 7.3 Update 1 Patch 13 enables end users to view and update their Calendar Server 7 Update 2 calendars. For more information, refer to the Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite online help.
Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite 7.3 Update 1 Patch 17
Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite 7.3 Update 1 Patch 17 supports the following feature:
In Connector for Microsoft Outlook 7.3 and earlier versions, it was required to create a new profile to modify or upgrade user profiles linked to Connector for Microsoft Outlook 7.1 and later versions.
Solution: A new hidden configuration parameter, ModifySun71PlusProfile, has been created in the setupfilename.ini file to enable or disable the conversion of Connector for Microsoft Outlook 7.1 (and later versions) user profiles. To not modify the Connector for Microsoft Outlook 7.1 (or later version) user profile, set the ModifySun71PlusProfile parameter equal to 0. To modify the user profile with the configured values, set the ModifySun71PlusProfile parameter equal to 1
The ModifySun71PlusProfile=0/1 parameter is not enabled if the Create new user profile without conversion/upgrade option is chosen in the user profile settings of the Connector for Microsoft Outlook configuration program.
In this release of DSsetup new attributes and object classes have been added.
The following attributes were added for Calendar Server to authenticate against an external Directory Server:
- externalAuthPreUrlTemplate and externalAuthPostUrlTemplate, added to the inetDomainAuthInfo object class
The following object class was added for Calendar Server unique identifier:
- davUniqueId, added to the davEntity object class
New attributes and object classes have been assigned for future use with Network Address Book:
- attributes: nabStatus, nabDomainAcl, nabDomainNames, and nabStore
- objectclasses: nabUser and nabDomain
In addition, Dssetup no longer automatically removes 71sun-am.ldif if Access Manager schema is found in 99user.ldif.