Customizing Delegated Administrator

After you have installed (with commpkg install) and configured (with config-commda), you can customize your configuration to meet your particular needs.

This page describes how to add customized attributes to the Delegated Administrator console. Next, it shows how to customize additional Delegated Administrator features. Finally, it lists the locations of the configuration files and explains how to redeploy a customized file to the proper location.

You should back up any existing Delegated Administrator configuration file before you begin customizing it.

Also, customized configuration data can be lost when you upgrade Delegated Administrator. Therefore, you should preserve your customized configuration before you upgrade Delegated Administrator or rerun the Delegated Administrator configuration program. For more information, see Preserve an Existing Configuration.

This page describes the following topics:

Customizing the Delegated Administrator Console

This section describes how to add custom attributes that can be provisioned in the Delegated Administrator console in Access Manager mode only. In Direct LDAP mode, all LDAP attributes are retrieved by default. It includes the following topics:

• How Customization Works
• To create a customization file
• To edit the daconfig.properties file
• To create a Java class for the custom attributes
• Customization File Details

How Customization Works

You can customize the Delegated Administrator console to manage user attributes that are not already provided by the service packages and the Service sections (such as Mail Service or Calendar Service) of the User Properties page.

After you add the custom attributes, the Delegated Administrator console operates as follows:

• The console displays a UI field representing each custom LDAP attribute.
  
  When you create a new user, the custom attributes appear in a new page, called Custom Data Section, in the Create New User wizard. This page appears just before the Summary page.
  
  In addition, you can edit the values of these attributes for existing users. The custom attributes appear in a Custom Data Section in the User Properties page.
• You can enter a value in the UI field or check the box.
• When you click Save in the console, Delegated Administrator stores the new or updated values in the corresponding LDAP attributes in the directory.
  
  If you write business logic and validation in the Java class that implements the custom attribute, that logic is performed before the new values are saved in the directory.

In this release, you can customize attributes for users only.

Customization Tasks

To add custom attributes to the console, you need to perform the following tasks:

• Update your LDAP schema and add the new object classes and attributes to the LDAP directory. Directory Server must recognize these attributes before Delegated Administrator can successfully write attribute values to the directory.
  
  You also may add attributes that already belong to your schema and are recognized by Directory Server (attributes provided by the Directory Preparation Tool, comm_dssetup). For example, you may want to add a mail attribute that is not automatically provisioned by Delegated Administrator. In this case, you do not need to update your schema.
• Create an XML customization file that identifies the LDAP attributes and defines the UI fields to be displayed in the Delegated Administrator console.
  
  For detailed instructions, see To create a customization file.
• Edit the properties file that activates the customization and identifies the Java class.
  
  For detailed instructions, see To edit the daconfig.properties file.
• (Optional) Create a Java class that enables Delegated Administrator to respond to user input for the new attributes. The customization subsystem calls the business logic and validation you write for the attributes before new values are written to the LDAP directory.
  
  For detailed instructions, see To create a Java class for the custom attributes .

You do not need to perform these tasks in any particular sequence.

However, after you complete these tasks, you must deploy your updated configuration files to the Web container used by the Delegated Administrator console. The deploy step is described in Step 3 in To create a Java class for the custom attributes .

• (In Access Manager mode) Edit the Delegated Administrator server resource.properties file to add the custom attribute in the section userreturnattr-xx and follow the steps mentioned in the section _Deploying a Customized Configuration File_ to deploy the changes.

Provisioning Custom Attributes With the Command-Line Utilities

You also can provision custom attributes by using the Delegated Administrator command-line utility. Use the -A option with the commadmin command to add or update a value for any LDAP attribute that belongs to your schema.

For information about how to use this option, see Delegated Administrator Utility (commadmin) Reference.

To create a customization file

For information about the customization file, including guidelines for creating the file, descriptions of the XML elements, and an example, see Customization File Details.

1. Open the sample XML customization file, sampleCustom.xml, in a text editor.
   
   The sampleCustom.xml file is located by default in the following directory:
   
   da-base/data/da/jsp/users
2. Remove the comment markers from the XML entries.
   
   The sampleCustom.xml file shows the DTD definition and a skeleton sample:

   <?xml version="1.0" encoding="UTF--8" ?>
   <!---- DTD DEFINITION: PLEASE DO NOT EDIT THE FOLLOWING LINES  
   ---->
   <!DOCTYPE property--list [
       <!ELEMENT property--list (property)+ >
       <!ELEMENT property EMPTY>
       <!ATTLIST property
             label CDATA #REQUIRED
             attr  CDATA #REQUIRED
             uifield (text | textarea | checkbox)  #IMPLIED
             syntax (string | number)  #IMPLIED>
   ]>
   <!---- END DEFINITION  
   ---->
   <!---- Pls uncomment and edit below for customization
   <property--list>
      <property label="Customized label1" attr="custattr1" />
      <property label="rsrc.key.label2" attr="custattr2" uifield="text" />
   </property--list>
   ---->

   To see an example of a customization file containing three attributes, see Sample Customization File.

3. Edit the section of the file that starts with the <property-list> element.
   
   Add the XML elements to define the custom attributes. Add one entry, beginning with the property element, to define each attribute.
   
   For instructions on how to define the attributes and their corresponding UI fields in the console, see Guidelines for Creating a Customization File.
   
   For definitions of the XML elements, see XML Elements Used in a Customization File.
4. (Optional) Rename the customization file to a name suitable for your installation.
5. Save the customization file in the following directory:
   
   da-base/data/da/jsp/users
   
   The customization file must be in this location.

To edit the daconfig.properties file

This task explains how to activate the customization and identify the Java class.

1. Open the daconfig.properties file in a text editor.
   

The daconfig.properties file is located by default in the following directory:

da-base/data/da/WEB-INF/classes/com/sun/comm/da/resources

1. Find the following properties in the file:

   users.custom.plugin.exist=false
   users.custom.plugin.class=com.sun.comm.da.common.ReferenceCustomUIPluginImpl
   users.custom.plugin.separator=, \n\r

2. Change the value of the users.custom.plugin.exist property from false to true.
   
   By default, this value is false.
   
   For example:
   
   users.custom.plugin.exist=true
   
   Setting this value to true activates the task of customization in Delegated Administrator (which includes enabling the customization plug-in).
   
   Even if you do not write a Java class for customized business logic (as described in To create a Java class for the custom attributes ), you must set the users.custom.plugin.exist property to true to enable the customization to work.
3. (Optional) Modify the Java class name for the customization plug-in.
   
   By default, the fully qualified Java class name is
   
   com.sun.comm.da.common.ReferenceCustomUIPluginImpl
   
   To modify the Java class name, edit the name in the following property:

   users.custom.plugin.class= 
   com.sun.comm.da.common.ReferenceCustomUIPluginImpl

   If you want to use the default name, you do not have to modify this property.

4. (Optional) Specify additional separators for multi-valued attributes.
   
   If you add a multi-valued LDAP attribute, line separators are needed to distinguish multiple entries for attribute. By default, four common separators are configured in the following property:
   
   users.custom.plugin.separator=, \n\r
   
   To add to or modify the separators, edit the values in this property.

To create a Java class for the custom attributes

This task explains how to write a Java class that implements the Java interface for adding business logic to handle the custom attributes.

This task is optional. If you do not change the default Java class name and do not need to add business logic and validation for the custom attributes, you do not need to perform this task.

1. Create the Java class file.
   
   The class implements the following two methods:
   • public String getCustomFilename();
     
     In the getCustomFilename method, you should return the name of the XML customization file that you created in To create a customization file.
   • public String performBusinessLogic(DAObjectContext ctx);
     
     In the performBusinessLogic method, you can implement any business logic and validation you want to perform.
     
     The customization subsystem calls the performBusinessLogic method before it saves the custom attribute values in the LDAP directory. It passes the DAObjectContext object as a parameter. Developers can get information from this object via the following methods:

     public String getOrganizationDN();
     public DAUser getUserObject();

     The DAUser class is part of the Java Delegated Administrator API (JDAPI) library bundled with Delegated Administrator.
     To see a simple example of how to implement this plug-in class, examine the default Java class file, named ReferenceCustomUIPluginImpl and located in the following path:
     
     da-base/WEB-INF/classes/
     
     This sample file is a fully working class for the default settings in the sample customization file, sampleCustom.xml. If you do not need to implement your own business logic and validation, you can use the sample Java class without modifying it. (Of course, if you change the name of the customization file, you also must change it in the getCustomFilename method in the Java class.)

2. Copy the Java class file to the following directory:
   
   da-base/WEB-INF/classes/Java class
   
   where Java class is the fully qualified Java class name.
   
   The Java class file must be in this location.
3. Redeploy the edited files to the Web container used by the Delegated Administrator console.
   
   All the files you have created or updated in this task and in the preceding task, To create a customization file, are located in the Delegated Administrator configuration path. These files include:
   • The XML customization file
   • The daconfig.properties file
   • The Java class file
     Before the changes you have made can take effect, you must run the script that deploys the customized files to your Web container.
     
     For instructions on how to perform this task, see To Deploy a Customized Configuration File

Top

Customization File Details

The customization file provides the Delegated Administrator console with the information it needs to do the following:

• Display a field in the Delegated Administrator console that represents the LDAP attribute in the directory
• Accept user input in a text box, text area, or check box in the console
• Save the new or modified input as the value of the LDAP attribute in the directory.

The customization file is defined in XML format.

Top

Guidelines for Creating a Customization File

When you create a customization file, follow these rules and guidelines:

• You can define multiple attributes in a customization file.
• Each attribute is defined on a separate line.
• One element, property, identifies each attribute defined in the file.
  
  The property element appears at the beginning of each attribute definition (each line in the file). If you define multiple attributes, the property element appears repeatedly in the file.
• For each attribute, you must define a label to be displayed in the Delegated Administrator console, that describes the attribute.
• For each attribute, you must provide the name of the LDAP attribute whose value the console field represents.

Top

XML Elements Used in a Customization File

Table 4-1describes the XML elements in the customization file.

Elements used to define a Delegated Administrator console field derived from an LDAP attribute

Top

Sample Customization File

The following sample customization file defines three attributes:

In this example, the first line defines an LDAP attribute, custldapattr1, with the following label in the console: Custom label 1. Next to the label, the console will display a text box that accepts an alphanumeric string as input.

For the second attribute defined in this example, the console displays a label and a text area that accepts a number as input.

For the third attribute, the console displays a label and a check box. Delegated Administrator returns a value of “true” (if the check box is checked) or “false” (if it is unchecked) to be stored with the LDAP attribute in the directory.

Top

Customizing the Access Mode

You can run Delegated Administrator in the following modes:

• Direct LDAP mode
• Access Manager mode

To change from one mode to another, you will have to run the config-commda command.

To know which mode Delegated Administrator is running in, you need to look at the serverconfig.properties file for the access-mode value which could be directldap or accessmanager. This file needs to be added to the Configuration and Log Files Deployed by the config-commda Program in Configuration Files that belongs to the Delegated Administrator server.

To be able to modify the SERVICES file, you need to do the following:

• For Access Manager mode, use the <object><service>Service.xml files in <da_base>/lib/services. For example UserMailService.xml, and the amadmin command to remove the existing service and load the modified xml file.
• For Direct LDAP, modify the daAllServices.ldif in <da_base>/lib/services, and load the modifed ldif file using ldapmodify command.

Top

Configuring the Preferred Mail Host Using the Server-Wide Default

If you want the Preferred Mail Host and Preferred Mail Store to be set using the server-wide default, you can perform the tasks described in this section.

If you need to remove the Preferred Mail Host field from the console (specifically, from the New Organization Wizard and Organization Properties screens), you must perform the following steps:

• Edit the Security.properties file. This step is described in this section.
• Enable the MailHostStorePlugin. This step is described in the following section, Adding Plug-ins for Delegated Administrator.

The Security.properties file lets you customize the Delegated Administrator console for all or for individual roles.

To remove the Preferred Mail Host from the console

1. Add the lines shown below to the Security.properties file.

   # Remove Preferred Mail Host from UI
   *.NewOrganizationPage6.PreferredMailHostProperty=INVISIBLE
   *.NewOrganizationSummaryPage.PreferredMailHostSummaryProperty=INVISIBLE
   *.OrgProperties.MailHostName=INVISIBLE
   *.OrgProperties.MailHostNameText=INVISIBLE
   *.OrgProperties.MailHostValue=INVISIBLE

   The Security.properties file is located in the following directory:
   
   da-base/data/da/WEB-INF/classes/com/sun/comm/da/resources
   
   CAUTION: You may add lines to this file for your own customization, but do not edit the lines already present. Editing existing lines could result in exceptions being thrown on the console.

2. Redeploy the edited Security.properties file to the Web container used by the Delegated Administrator console.
   
   Before the change can take effect, you must run the script that deploys the customized Security.properties file to your Web container.
   
   For instructions on how to deploy a customized properties file to a particular Web container, see To Deploy a Customized Configuration File.

Top

Syntax and Values for Security.properties File Properties

The properties in the file are of the form: Security Element Name=Permission

A Security Element Name is of the form:Role Name.Container View Name.Console Element Name

A Security Element specifies the Console element and role for which the permission is being defined. If you do not know an element name, view the source of a page to match the name on the page to the Console element you are interested in.

The names on the page are fully qualified names. You need to pick up only the last two elements of the name, which form Container View Name.Console Element Name.

Valid role names for Delegated Administrator are as follows:

“ProviderAdminRole” (SPA) For information about this role, see [Service Provider Administrator and Service Provider Organizations FIX].

“OrganizationAdminRole” (OA)

“Top-levelAdminRole” (TLA)

“*” (applies a permission to all roles unless it is overridden for a specific role)

A permission must be one of the following strings:

• EDITABLE-- indicates that the security element is editable.
• NONEDITABLE-- indicates that the security element is read-only.
• VISIBLE-- indicates that the security element is visible and read-only.
• INVISIBLE-- indicates that the security element is invisible.

Top

Adding Plug-ins for Delegated Administrator

You can customize Delegated Administrator to support the following plug-ins:

• MailHostStorePlugin
  
  By default, this plug-in is disabled. If no preferredmailhost is supplied when a business organization is created, an exception will be raised. If the plug-in is enabled, values from the flat file (described later in this section) will be used only if the corresponding attribute is absent.
• MailDomainReportAddressPlugin
  
  Uses the domain value to return the desired DSN address. The default implementation is to return the string MAILER-DAEMON@<domain>.
• UidPlugin
  
  Generates a unique id string. The default implementation generates a GUID to return to the caller.

Top

Enabling the Plug-Ins

To enable these plug-ins, edit the commcli servlet resource.properties file, located in the following directory:

(By default, da-base for Solaris and Linux is /opt/sun/comms.)

The plug-ins are located in the resource.properties file in a section headed as follows:

Each has "plugin" as the suffix. The current list looks like:

After you edit the resource.properties file, redeploy it to the Web container used by the Delegated Administrator server.

Before the changes can take effect, you must run the script that deploys the customized resource.properties file to your Web container.

For instructions on how to deploy a customized properties file to a particular Web container, see To Deploy a Customized Configuration File.

Top

Plug-In Format

Each plug-in has at least two lines, which take the following form:

• jdapi-<name>plugin= “enabled” | “disabled”

• jdapi-<name>pluginclass=sun.comm.cli.server.util/ \
  <java class name>

To enable a plug-in, change “disabled” to “enabled”.

Plug-in classes are supplied for all the plug-ins listed in this section. The classes are located in the following directory:

da-base}/data/WEB-INF/classes/sun/comm/cli/server/util

You do not need to do anything with these classes.

Top

Additional Flat File Required for MailHostStorePlugin

The MailHostStorePlugin requires a flat file, which is included in a third line for the plug-in. The plug-in reads the value in the flat file and uses it to set attribute values. If the plug-in is enabled, the file must be present, or an error will occur.

• jdapi-mailhoststoreplugin
  o jdapi-mailhoststoreplugininf=<full file name>
  o file has one line
  o value is that for :
  o preferredmailhost attribute
  o preferredmailmessagestore attribute
  o form
  o <mailhost>:<mailpartition>

Top

Adding a Custom Object Class When You Create an LDAP Object

You can enable Delegated Administrator to add a custom object class to the LDAP entry of a new user, group, resource, or organization. To accomplish this task, you customize the appropriate object-creation template installed in the directory by Access Manager.

For example, the BasicUser creation template determines which object classes and attributes are added to a user entry when you create a new user. You can update the BasicUser creation template with your custom object class. Thereafter, the custom object class will be added to each new user entry together with the standard object classes.

The following procedure describes how to customize the BasicUser template. You can follow the same procedure to customize the BasicGroup, BasicResource, and BasicOrganization creation templates.

To add a custom object class to the user-creation process

1. Make sure your custom object class is defined in the directory schema.
2. Locate the following directory entry:

   ou=basicuser,ou=creationtemplates,ou=templates,ou=default,
   ou=globalconfig,ou=1.0,ou=dai,ou=services,
   o=$Root_Suffix

   where $Root_Suffix is the root suffix of your directory.

3. Add the following attribute:value to the entry:

   sunkeyValue:required=objectClass=$Your_Custom_Objectclass.

   where $Your_Custom_Objectclass is your custom object class.

Top

Customizing the User Log-In

When you run the Delegated Administrator configure program (config-commda), the value you use to log in to Delegated Administrator is set to be a uid.

For example, if you intend to log in as the TLA, and the TLA’s uid is john.doe, you would use john.doe to log in to Delegated Administrator.

You can customize Delegated Administrator to enable you to use additional values for the user log-in. For example, you could add the mail address (mail).

Top

How the User Log-In Value Is Set

The config-commda program sets this value to uid with the loginAuth-idAttr property in the resource.properties file, as shown in the following example:

where <$rootSuffix> is the root suffix in your directory.

Top

Adding a User Log-In Value

You can set additional values for the user log-in by editing the resource.properties file.

The resource.properties file is located in

For example, to enable you to use a mail address (such as john.doe@sesta.com) to log in, you could add the following line to the resource.properties file:

where <$rootSuffix> is the root suffix in your directory.

Note that you must add an increment to the loginAuth-idAttr property for each new value. In this example, a second value is added, so you add -2 to loginAuth-idAttr.

You can add multiple instances of the loginAuth-idAttr property:

After you edit the resource.properties file, redeploy it to the Web container used by the Delegated Administrator server.

Before the changes can take effect, you must run the script that deploys the customized resource.properties file to your Web container.

For instructions on how to deploy a customized properties file to a particular Web container, see To Deploy a Customized Configuration File.

Top

Requiring Service Packages for New Users

By default, Delegated Administrator lets you create a new user without assigning a service package to the user.

You can change the default setting so that all new users must have at least one service package assigned to them.

To require new users to have a service package assigned to them

1. Open the daconfig.properties file in a text editor.
   
   The daconfig.properties file is located by default in the following directory:
   
   da-base/data/da/WEB-INF/classes/com/sun/comm/da/resources
2. Change the value of the user.atleastOneServicePackage property from false to true.
   
   By default, this value is false.
   
   For example:
   
   user.atleastOneServicePackage=true
   
   After you set this value to true, when you use the Create New User wizard in the Delegated Administrator console, you must assign at least one service package to successfully create the new user.
3. Redeploy the edited daconfig.properties file to the Web container used by the Delegated Administrator console.
   
   Before the change can take effect, you must run the script that deploys the customized daconfig.properties file to your Web container.
   
   For instructions on how to deploy a customized properties file to a particular Web container, see To Deploy a Customized Configuration File.

Top

Adding a New Calendar Time Zone

You can customize Delegated Administrator by adding a new Calendar Server time zone. Delegated Administrator can then provision organizations, users, groups, and resources with the new time zone.

To add a new time zone, perform the following tasks. To administer the new time zone with the Delegated Administrator utility, you must perform only the first task. To administer the new time zone through Delegated Administrator console, you must perform both tasks.

• To add a new time zone in Delegated Administrator
• To display and administer the new time zone in the Delegated Administrator console

Once the time zone has been added, you can set it as the default time zone for newly created users by performing the following task:

• To change the default time zone in Delegated Administrator

To add a new time zone in Delegated Administrator

You must perform this task before you can use either the commadmin utility or the Delegated Administrator console to provision users with the new time zone. This task updates Access Manager with the new time zone value. After this task is completed, you can use commadmin to assign the new time zone to users.

1. Add the time zone in Calendar Server.
   
   To accomplish this step, you must edit the timezones.ics file and other Calendar Server files. For instructions, see “Adding a New Time Zone” in the chapter, “Managing Calendar Server Time Zones” in the Sun Java System Calendar Server Administration Guide.
2. Back up the UserCalendarService.xml and DomainCalendarService.xml files.
   
   The xml files are located by default in the following directory:
   
   da-base/lib/services
3. Edit the UserCalendarService.xml and DomainCalendarService.xml files to add the new time zone in Delegated Administrator.
   • In both the UserCalendarService.xml and DomainCalendarService.xml files, find the following entry heading:

     <AttributeSchema name="icstimezone"
                                 type="single choice"
                                 syntax="string"
                                 any="optional|adminDisplay">
                                 <ChoiceValues>

   • Add the new time zone value to the list of <ChoiceValues>.
4. Run the Access Manager amadmin utility to delete the current service and add the updated service.
   
   For both the UserCalendarService.xml and DomainCalendarService.xml files, run the following amadmin commands:

   ./amadmin -u <admin> w <password> -r CalendarService

   ./amadmin -u <admin> -w <password> 
   --s da_base/lib/services/CalendarService.xml

   where CalendarService is either UserCalendarService or DomainCalendarService.

   Note If you also intend to make the new time zone your default, you can run these amadmin commands after you have performed both tasks. For details, see To change the default time zone in Delegated Administrator.

5. Restart your Web container to enable the changes to take effect.
6. To enable the Delegated Administrator console to show the new time zone, see To display and administer the new time zone in the Delegated Administrator console.

To display and administer the new time zone in the Delegated Administrator console

This task adds the new time zone to the list of time zones displayed in the console. Next, the task enables the time zone value to be saved in the directory.

To display the time zone in the console, you must add the new value to the Resources.properties file.

To allow the console to store the time zone in the directory, you must add the new value to two lists in the daconfig.properties file. The first list specifies the actual value stored in the LDAP directory. The second list enables the console to map the (possibly localized) display value of the time zone to the stored value.

1. Edit the Resources.properties file, located under your Delegated Administrator data directory.
   
   The Resources.properties file is located by default in the following directory:

   da-base/data/da/WEB--INF/classes/com/sun/ 
   comm/da/resources

   To edit Resources.properties, search for the rsrc.Timezone property and add the new time zone to the appropriate list. You can localize this display value of the new time zone.

2. Locate the list of time zone values in the daconfig.properties file, located under your Delegated Administrator data directory.
   
   The daconfig.properties file is located by default in the following directory:

   da-base/data/da/WEB--INF/classes/com/sun/ 
   comm/da/resources

   To find the list of time zone values, search for the following line:

   #Timezone values -- only English

   These are the values stored in the LDAP directory. The new time zone must be in English; this is the required format for the values stored in the directory.

3. Add the new time zone to the list.
   
   For example, to add America/Miami to the list, assuming Timezone1 currently has 24 values, you would add

   rsrc.Timezone1--25=America/Miami

   This value would be the 25th time zone displayed in the Americas drop-down list in the console. Note that the time zone may be displayed in another language, depending on what you specified in the Resources.properties file in the preceding task.

4. Locate the reverse-time zone mappings list in the daconfig.properties file.
   
   This list keys the localized time zone value (displayed in the console) to the actual value, which you specified in Step 2, above.
   
   To find the list of reverse mappings, search for the following line:

   #reverse timezone mappings -- used by DA in getting localized tz value

5. Add the new value to the reverse-mapping list.
   
   For example, to add America/Miami to the list, you would add

   rsrcKey-AmericaMiami=rsrc.Timezone1-25

6. Redeploy the edited daconfig.properties and Resources.properties files to the Web container used by the Delegated Administrator console.
   
   Before the change can take effect, you must run the script that deploys the customized daconfig.properties file to your Web container.
   
   For instructions on how to deploy a customized properties file to a particular Web container, see To Deploy a Customized Configuration File.
   
   After you edit and redeploy the daconfig.properties and Resources.properties files, the new time zone will appear in the appropriate list boxes in the Delegated Administrator console. It will be saved in the directory whenever you select the time zone in the Delegated Administrator console and click Save.

To change the default time zone in Delegated Administrator

1. In the UserCalendarService.xml and DomainCalendarService.xml files, edit the following value:

   <DefaultValues>
                   <Value>America/Denver</Value>
   </DefaultValues>

   You can find <DefaultValues> under the following entry in the xml files:

   <AttributeSchema name="icstimezone"

2. Run the Access Manager amadmin utility to delete the current service and add the updated service.
   
   For both the UserCalendarService.xml and DomainCalendarService.xml files, run the following amadmin commands:

   ./amadmin -u <admin> w <password> -r DomainCalendarService

   ./amadmin -u <admin> -w <password> 
   --s da_base/lib/services/DomainCalendarService.xml

3. Restart your Web container to enable the changes to take effect.

Top

Deploying a Customized Configuration File

When you configure Delegated Administrator with the config-commda program, config-commda places the configuration files in a standard location for configuration data in the Delegated Administrator installation directory. The config-commda program then deploys the configuration files to the application repository of the Web container where you have deployed Delegated Administrator.

Thus, the deployed location of the configuration files varies, depending on which Web container you are using.

At runtime, Delegated Administrator uses the property values of the configuration files in their deployed locations------that is, in the Web container repository to which Delegated Administrator has been deployed.

To customize a configuration file, you will take these steps:

1. Edit the original configuration file located in the Delegated Administrator installation directory.
2. Use a script provided by Delegated Administrator to redeploy the configuration file to the Web container.

When you customize a configuration file, the new values do not take effect until the file has been redeployed to the Web container.

The remainder of this section describes the following topics:

• Original (Standard) Locations of the Configuration Files
• Deployed Locations of the Configuration Files
• To Deploy a Customized Configuration File
• Configuration File Deploy Scripts

Original (Standard) Locations of the Configuration Files

When Delegated Administrator is configured (after you run the config-commda program), the configuration files are located in the following directories:

• Delegated Administrator console:
  • logger.properties
  • Resources.properties
  • Security.properties
  • logger.properties
    
    Location: da-base/data/da/WEB-INF/classes/com/sun/comm/da/resources/

• Delegated Administrator server:
  • resource.properties
  • serverconfig.properties (only Delegated Administrator 7)
    
    Location: da-base/data/WEB-INF/classes/sun/comm/cli/server/servlet/

Deployed Locations of the Configuration Files

After you run the config-commda program, the configuration files are deployed to the following locations, depending on which Web container you have chosen to deploy Delegated Administrator.

Deployed Location of Delegated Administrator Server File (resource.properties)

The resource.properties file is deployed to one of the following default locations:

Web Server 6.x

/opt/SUNWwbsvr/https-hostname/webapps/https-hostname/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/

Web Server 7.x

/var/opt/SUNWwbsvr7/https-hostname/webapps/hostname/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/

Application Server 7.x

/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee--modules/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/

Application Server 8.x

/var/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/commcli/WEB-INF/classes/sun/comm/cli/server/servlet/

Top

Deployed Location of Delegated Administrator Console Configuration Files

The following files are deployed to the same default location:

• daconfig.properties
• logger.properties
• Resources.properties
• Security.properties

These properties files are deployed to one of the following default locations, depending on the Web container you have chosen to deploy Delegated Administrator:

Web Server 6.x

/opt/SUNWwbsvr/https-hostname/webapps/https-hostname  /da/WEB-INF/classes/com/sun/comm/da/resources

Web Server 7.x

/var/opt/SUNWwbsvr7/https--hostname/webapps/hostname  /da/WEB--INF/classes/com/sun/comm/da/resources

Application Server 7.x

/var/opt/SUNWappserver7/domains/domain1/server1  /applications/j2ee--modules  /Delegated_Administrator/WEB--INF  /classes/com/sun/comm/da/resources

Application Server 8.x

/var/opt/SUNWappserver/domains/domain1  /applications/j2ee--modules  /Delegated_Administrator/WEB--INF  /classes/com/sun/comm/da/resources

To Deploy a Customized Configuration File

1. Log in as (or become) root and go to the following directory:
   
   da-base/sbin
2. Run the appropriate deploy script to redeploy your customized configuration file to the Web container used by Delegated Administrator.
   
   You must redeploy the configuration file to the Web container where you deployed Delegated Administrator the last time you ran the Delegated Administrator configuration program (config-commda).
   
   Use the deploy script that applies both to your customized configuration file and to the correct Web container.
   
   For example, to redeploy the resource.properties file to Web Server 6, run this command:

   # ./config-wbsvr-commcli

   For a list of the deploy scripts, see Configuration File Deploy Scripts.

Top

Configuration File Deploy Scripts

There are two deploy scripts for each Web container. One script deploys the Delegated Administrator server files. The other deploys Delegated Administrator console files:

• Delegated Administrator server configuration file: resource.properties.
• Delegated Administrator console configuration files: daconfig.properties, Security.properties, Resources.properties , and logger.properties.

The deploy scripts are as follows:

Web Server 6

Deploy script for Delegated Administrator server file (resource.properties): config-wbsvr-commcli Deploy script for Delegated Administrator console files: config-wbsvr-da To run the scripts, enter these commands: # ./config-wbsvr-commcli # ./config-wbsvr-da

Web Server 7.x

Deploy script for Delegated Administrator server file (resource.properties): config-wbsvr7x-commcli Deploy script for Delegated Administrator console files: config-wbsvr7x-da To run the scripts, enter these commands: # ./config-wbsvr7x-commcli # ./config-wbsvr7x-da

Application Server 7.x

Deploy script for Delegated Administrator server file (resource.properties): config-appsvr-commcli Deploy script for Delegated Administrator console files: config-appsvr-da To run the scripts, enter these commands: # ./config-appsvr-commcli deploy # ./config-appsvr-da deploy You must use the argument deploy with these commands.

Application Server 8.x

Deploy script for Delegated Administrator server file (resource.properties): config-appsvr8x-commcli Deploy script for Delegated Administrator console files: config-appsvr8x-da To run the scripts, enter these commands: # ./config-appsvr8x-commcli deploy # ./config-appsvr8x-da deploy You must use the argument deploy with these commands.