Sun Java System Calendar Server 6 2005Q4 Administration Guide

Setting up a Hosted Domain Environment

This section covers the basic tasks that you might need to perform before creating new hosted domain entries in your LDAP:

Run the database migration utilities.

If you are migrating from Calendar Server version 5, be sure that you have already run cs5migrate, csmig, and csvdmig before attempting to set up hosted domains. You can get the latest version of cs5migrate from Sun’s technical support. For more information on these migrations utilities, see Chapter 4, Database Migration Utilities.
Run comm_dsseetup.pl if you have not already done so.

It updates the ics.conf file with the parameters needed to support hosted domains.

Edit the ics.conf file to enable hosted domains.

The following table lists and describes the configuration parameters in the ics.conf file used for hosted domain support. If any of the parameters listed in this table are not in the ics.conf file, add the parameter and its associated value to the file and then restart Calendar Server for the values to take effect.

Parameter	Description
`service.virtualdomain.support`	Enables (`"yes"`) or disables (`"no"`) support for hosted (virtual) domain mode. Default is `"no"`.
`local.schemaversion`	Specifies the version of the LDAP schema: `"1"` for Sun LDAP Schema 1. See also `service.dcroot`. `"2"` for Sun LDAP Schema 2. See also `service.schema2root`. Default is `"1"`.
`service.dcroot`	Specifies the root suffix of the DC tree in the LDAP directory, if `local.schemaversion="1"`. For example: `"o=internet"`. In hosted (virtual) domain mode, Calendar Server uses the `service.dcroot` parameter and not the `local.ugldapbasedn` and `local.authldapbasedn` parameters. Conversely, in non-hosted (virtual) domain mode, Calendar Server uses the `local.ugldapbasedn` and local.authldapbasedn parameters and not the `service.dcroot` parameter.
`service.schema2root`	Specifies the root suffix underneath which all domains are found, if `local.schemaversion="2"`. For example: `"o=sesta.com"`.
`service.defaultdomain`	Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. For example: `"red.sesta.com"`.
`service.loginseparator`	Specifies a string of separators used for the `login-separator` when Calendar Server parses `"userid[login-separator]domain"`. Calendar Server tries each separator in turn. Default is `"@+"`.
`service.siteadmin.userid`	Specifies the user ID of the domain administrator. For example: `DomainAdmin@sesta.com`.
`service.virtualdomain.scope`	Controls cross domain searching: `"primary"` Search only within the domain where the user is logged in. `"select"` Search in any domain that allows the search. Default is `"select"`.
`local.domain.language`	Specifies the language for the domain. Default is `"en`" (English).

Create a default domain entry.

For Schema 2, the default domain is created by the Delegated Administrator configuration program (config-commda).

For Schema 1, create a default domain (one of your hosted domains) one or more levels under your DC tree root suffix, depending on your DC tree structure. For example, if your root suffix is o=internet, then the next level down node could be com, as shown in Sun LDAP Schema 1. However, your default domain would be one node lower, such as sesta.com. Use csdomain to create DC tree nodes, as illustrated in the example that follows:
```
csdomain -n o=com,dc=com,o=internet create comcsdomain
    -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com
```
Enable calendaring services for the default domain entry.

For Schema 1: Add the icsCalendarDomain object class to the o=sesta.com domain entry in LDAP using csattribute.

For Schema 2: After configuring Delegated Administrator, modify the default domain (created by the Delegated Administrator configuration program) to add Calendar (and Mail) services. In the following example, calendar and mail services are added to a hosted domain:

commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail
Create the hosted domains you want on your system.

For instructions on how to add a hosted domain in Schema 2 mode, see Creating New Hosted Domains.

To create a Schema 1 hosted domain, use csdomain create, as illustrated in the example that follows:
```
csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com
```
Enable calendaring services for the new hosted domains, as explained in Setting up a Hosted Domain Environment.
Create the calmaster site administrator user if it does not already exist.

For Schema 2, create the calmaster user using the commadmin user create command as illustrated in the following example:
```
commadmin user create -D admin -w passwd -F Calendar
    -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal
```
Note –
To create the calmaster using the Delegated Administrator Console's Create New User wizard, see the Delegated Administrator online help.

For Schema 1, create the calmaster user on the organization tree with csuser as illustrated in the following example:
```
csuser o=sesta.com,o=rootsuffix -d sesta.com
    -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster
```
If the calmaster site administrator user already exists from an earlier non-hosted domain environment (Schema 1), move it to the default domain by performing the following steps:
1. Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.
2. Delete the existing calmaster LDAP entry on the organization tree root suffix using ldapdelete, as follows:
```
#ldapdelete -D "cn=Directory Manager" -w password 
   uid=calmaster,ou=People,o=rootsuffix
```
3. Modify the calendar administrator’s group entry (update the uniqueMember attribute) to reflect the changes as shown in the LDIF example that follows:
  dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix changetype:modifyreplace:uniqueMember uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
  It is not necessary to move the group entry to the hosted domain.
Update any administration scripts you have so that calids in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.