10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time

To move from a non- or single domain environment to a multiple domain environment, you might need to perform the following tasks before creating any LDAP entries:

Run the database migration utilities.

If you are migrating from Calendar Server version 5, be sure that you have already run csmig, csvdmig, cs5migrate, and cs5migrate before attempting to set up multiple domains. For more information on these migrations utilities, see Chapter 3, Database Migration Utilities for Calendar Server 6.3.
Run the comm_dsseetup.pl if you have not already done so.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.

Edit the ics.conf file to enable multiple domains.

The following table lists and describes the configuration parameters in the ics.conf file used for multiple 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"`) support for multiple domains. Default is `"yes"`. Note – Do not change this parameter to `“no”` even if you are going to operate in a single domain. The current version of Calendar Server requires this to be `“yes”`.
`local.schemaversion`	Specifies the version of the LDAP schema: `"1"` for 10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3. See also `service.dcroot`. `"1.5"` or `"2"` for 10.3.2 Sun LDAP Schema Version 2 for Calendar Server Version 6.3. See also `service.schema2root`. Default is `"2"`.
`service.dcroot`	For multiple domain support, this replaces `local.ugldapbasedn` and `local.authldapbasedn`. If `local.schemaversion="1"` or `local.schemaversion="1.5"`, specifies the root suffix of the DC tree, underneath which all domains are found. For example: `"o=internet"`.
`service.schema2root`	if `local.schemaversion="2"`, specifies the root suffix of the Organization Tree, underneath which all domains are found. 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 version 2, the default domain is created by the Delegated Administrator configuration program (config-commda).

For Schema version 1, create a default domain (one of your multiple domains), placing it 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 10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3. 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 version 1: Add the icsCalendarDomain object class to the o=sesta.com domain entry in LDAP using csattribute.

For Schema version 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 domain:

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

For instructions on how to add a domain in Schema version 2 mode, see 13.2 Creating New Calendar Server Domains.

To create a Schema version 1 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
```
Add calendar (and mail, if wanted) services for the new domains.
Create the calmaster site administrator user if it does not already exist.

For Schema version 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 version 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-domain environment (Schema version 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 administrator's group entry to the domain.
Update any administration scripts you have so that all calendar IDs (calid) in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.