Wednesday Jun 27, 2007

Connector for Outlook: Updated Technical Note

The technical note titled "Configuring Calendar Server for Connector for Microsoft Outlook" has been re-released to include new information about limiting directory browsing. The document is available at the following location:

The following information was added to the section titled Configuring Shared Calendar LDAP Lookup:

The above ACI may pose a security issue if restricted user information is stored in certain attributes, for example, dn, givenName, sn, uid, or mail. To restrict the browsing of the directory to only people making the queries from a specific Calendar Server, change the above ACI to something like:

aci:(targetattr="icscalendar || cn || givenName || sn || uid || mail") (targetfilter=(|(objectClass=icscalendaruser)(objectclass=icscalendarresource))) (version 3.0; acl "Allow calendar users to read and search other users - product=ics,class=admin,num=3,version=1"; allow (search,read) (ip=",,")and (userdn="ladp:///uid=\*,ou=People,,o=usergroup");)

The IP addresses listed in the above ACI example (,, and are the IP addresses from which the Calendar Server makes the queries.

Monday Apr 16, 2007

Comms Suite 5 - Docs to Go (Installing on Linux)

Unfortunately, our internal pubs processes are very weighty. That's not always a bad thing, we need to ensure quality, technical accuracy, and so on. But for some docs, it doesn't make sense to make you wait while the wheels of Sun Pubdom grind slowly on.

But I'm starting to look at this blog as the ultimate cheepo publishing system, for some information at least: a docs-to-go kind of place.

Bottom line: Customers want information quickly. So I'll experiment a bit with a doc that a support expert has readied: Deployment Example: Sun Java Communications Suite 5 on a Single Host (Linux). I know some of you have requested this already, (the doc is really an updated version of the same example on Solaris) and so I'm making a decision: rather than pipe this through the normal (slowww) pubs channels and wrap the info in near-Nirvanic Sun formatting, I'm redirecting it as is to this blog.

Doc Summary: This deployment example describes how to install Sun Java Communications Suite 5 software on one Linux computer for a functioning deployment. This document is intended for any evaluator, system administrator, or installation technician who wants to install and evaluate the services delivered by these components.

Get the Deployment Example

As an experiment, I'll leave it up to this community to let me know if you find any corrections and I'll take the responsibility to keep the doc up-to-date if you find something that needs fixing. Who knows, perhaps this could become a new and faster way to get certain kinds of information into your hands.

Sunday Mar 25, 2007

New Communications Suite Technical Note: Comparing LDAP Schema Modes

Our Calendar Server writer just produced a rather interesting technical note titled "Technical Article: Comparison of Sun Java System LDAP Schema Modes for Communications Suite Products," which should go a long way towards filling the information gap that currently exists around this topic. You can get this technical note here:

Short description of this doc:

This article compares the Sun Java System LDAP schema modes used by the Sun Java Communications Suite products. It includes an overview and history of both modes, an example of domain and user LDAP entries for both schema modes, and a discussion on how to decide which mode is appropriate for you.

Shorter article, for those who don't have the time to digest it all:

  • You should use the same schema version for all Communications Suite products sharing the same LDAP directory.
  • If you require Sun Java System Access Manager to share the same LDAP user directory with Communications Suite products, use one of the Schema version 2 modes.
  • You should not use Schema version 1 mode unless you satisfy all of the following criteria.
    • You have an earlier version of one of the Communications Suite products already installed using Schema version 1.
    • And, you don't want to use Access Manager.
    • And, you don't want to migrate your LDAP database to either mode of Schema version 2.
  • If Sun Java Communications Suite Delegated Administrator does not have the features you require, but iPlanet Delegated Administrator does, use Schema version 1 mode.
  • If you are installing Communications Suite products for the first time, choose the Schema version 2 mode that integrates most easily with your current DIT structure. You can choose between Schema version 2 native mode or compatibility mode. The two modes are defined in Schema Version 2 Background Information.
UPDATE, May 2, 2007

As one astute commentator noted to me offline, once you are convinced that you ought to migrate your deployment from V.1 to V.2, what next? Apologies, we neglected to include a pointer in this article to the Schema Migration Guide, which "describes how to migrate Sun Java System LDAP Directory data from LDAP Schema 1 to LDAP Schema 2 for Sun Java Communications Suite, specifically Sun Java System Messaging Server and Sun Java System Calendar Server."


Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.


« July 2016