This chapter provides information and guidelines to help you manage the day-to-day operation of Oracle Communications Contacts Server.
Oracle Communications Contacts Server 8.0.0.4.0 and previous releases were deployed on GlassFish Server, which is no longer supported by Oracle. For that reason, Contacts Server 8.0.0.5.0 and beyond are only supported on Oracle WebLogic Server. Oracle strongly recommends that you upgrade your Contacts Server environments to release 8.0.0.5.0 or higher and migrate to WebLogic Server to receive full Oracle support.
Contacts Server depends on Oracle GlassFish Server or Oracle WebLogic Server deployed as a web container. You monitor Contacts Server by using tools and commands of an application server.
For more information on administering GlassFish Server, see the Oracle GlassFish Server 3.0 documentation.
Administering system security in GlassFish Server Security Guide.
The asadmin utility subcommands in GlassFish Server Reference Manual.
Overview of GlassFish Server administration in GlassFish Server Administration Guide.
For more information on administering Oracle WebLogic Server, see the Oracle WebLogic Server documentation.
Configuring Keystores in Administering Security for Oracle WebLogic Server 12.1.3.
Configure keystores in Oracle Fusion Middleware Administration Console Online Help for Oracle WebLogic Server 12.2.1.3.0.
Administration Console Online Help in Oracle Fusion Middleware Administration Console Online Help for Oracle WebLogic Server 12.2.1.3.0.
Creating, exporting, and importing SSL Certificates in Calendar Server Security Guide. (The same concepts that apply to Calendar Server also apply to Contacts Server.)
Monitoring Contacts Server includes:
You can monitor GlassFish Server and WebLogic Server JDBC connection pools.
If you use GlassFish Server JDBC connection pools, the following GlassFish Server statistics for JDBC Connection Pools are helpful in monitoring Contacts Server:
numConnFailedValidation (count): Number of connections that failed validation.
numConnUsed (range): Number of connections that have been used.
numConnFree (count): Number of free connections in the pool.
numConnTimedOut (bounded range): Number of connections in the pool that have timed out.
To get the statistics:
Check whether the JDBC connection pool service module is enabled:
asadmin get "server.monitoring-service.module-monitoring-levels.*"
...
server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=OFF
If it is not enabled, start the JDBC connection pool service module, setting the monitoring level to HIGH to retrieve all statistics:
asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
Command set executed successfully.
Get statistics for all connection pools:
asadmin get --monitor "server.resources.*"
You can monitor a variety of statistics for each data source instance in your domain, such as the current number of database connections in the connection pool, the current number of connections in use, and the longest wait time for a database connection.
To view the current statistics for a JDBC data source:
In the Domain Structure tree, expand Services, then select Data Sources.
On the Summary of JDBC Data Sources page, click the data source name.
Select the Monitoring tab and then select the Statistics tab.
Statistics are displayed for each deployed instance of the data source.
For more information about these statistics, see Configuration Options.
(Optional) Click Customize this table to change the columns displayed in the statistics table. To make changes, you must select the Lock & Edit option. After the modifications, click Activate Changes.
For more information on Monitoring WebLogic JDBC Resources, refer to Administering JDBC Data Sources for Oracle WebLogic Server.
You can use either the application server's Administration Console or the command-line utilities to check the Contacts Server status.
Log in to the GlassFish Server host as root.
Start the GlassFish Server Administration console.
Navigate to Web Applications under the Applications tab.
Ensure that the process nabserver is deployed and enabled.
Log in to the GlassFish Server host as root.
Change to the GlassFish_home/bin directory.
Obtain the name of the nabserver component:
asadmin list-components -p admin-port nabserver <ejb,web> Command list-components executed successfully.
Show the status of the nabserver component:
asadmin show-component-status -p admin-port nabserver Status of nabserver is enabled. Command show-component-status executed successfully.
To check Contacts Server status with the WebLogic Administration Console:
Log in to WebLogic Administration Console.
Navigate to Deployments under the domain.
Ensure that the nabserver process is deployed and enabled.
Under Deployments, ensure that Health of the nabserver deployment is OK.
Managing logging includes:
Contacts Server maintains the following log files:
commands: Stores information about requests that are sent to the server and information related to each operation performed that satisfies those requests. The commands log file contains servlet and core operation class entries that are designed to help you monitor requests to the server and help diagnose problems.
errors: Stores error and debug-level information that is supplied by the server for use in diagnosing problems.
telemetry: Stores entire Contacts Server servlet request and response transcripts.
scan: Stores information on virus scanning actions.
Each log file has its own configuration parameters that controls the log file location, maximum size, log level, and number of files allowed.
Log files are created with a suffix of .number, for example, commands.0, commands.1, and so on. The log file numbered .0 is the newest, the log file numbered .1 is next newest, and so on. When a log file is filled to its maximum configured size, the logging system increments each of the existing log file suffixes to the next higher number, starting with the highest. If the number of log files reaches the configured maximum, the highest numbered log file is deleted and the next higher takes its place.
For example, Contacts Server is started for the first time and you have configured the maximum number of log files at 10. The logging system begins writing messages to the log file with the .0 suffix. When the .0 log file is filled to capacity, the logging system increments its suffix to the next higher number and the file becomes .1. The logging system then creates a new .0 log file and begins writing messages to it. When the .0 file become full, the logging system increments the .1 file to .2, increments the .0 file to .1, and creates a a new .0 file. This process continues until the maximum number of configured log files is reached. When that happens, the logging system deletes the highest numbered (oldest) log file, .9, increments each of the lower numbered files' suffixes, and creates a new .0 log file.
The Contacts Server log files are kept separate from the application server log files.
The GlassFish Server log files are stored in the GlassFish_home/domains/domain_name/logs directory, for example, /opt/glassfish3/glassfish//domains/domain1/logs.
The WebLogic Server log files are stored in the Weblogic_Domain/servers/managed_server_name/logs directory.
Even though the container's log file is the root log file, by default, information that is stored in the Contacts Server's log files is not logged to the container's log file.
By default, the Contacts Server logToParent flag is set to false. It prevents logging of information to the application server log file.
To log the Contacts Server information to the application server log file (server.log for GlassFish Server and managed_server_name.log for WebLogic Server) and the Contacts Server log file (commands.0), set the log.dav.commands.logtoparent parameter to true:
davadmin config -u admin -o log.dav.commands.logtoparent -v true
Use the davadmin command to configure Contacts Server logging parameters as shown in Table 4-1.
name can be commands, errors, scheduling, telemetry, or scan, depending on the type of logging you want to configure; use error to configure Contacts Server error logging. SEVERE and WARNING messages need immediate attention. FINE, FINER, and FINEST messages are usually informational only, but can provide more context for troubleshooting when accompanying SEVERE and WARNING messages.
Table 4-1 Contacts Server Log File Configuration Parameters
| Parameter | Description |
|---|---|
|
log.dav.name.logdir |
Specifies the log file directory path |
|
log.dav.name.loglevel |
Specifies the log level:
|
|
log.dav.name.logtoparent |
Enables or disables logging of the application server log file. When set to true, messages are stored in the application server log file and the Contacts Server log file. Set this parameter to false to disable logging to the application server log file. |
|
log.dav.name.maxlogfiles |
Specifies the maximum number of log files |
|
log.dav.name.maxlogfilesize |
Specifies the log file's maximum size |
For more information about the logging configuration parameters and their default values, see "Contacts Server Configuration Parameters."
The document store logs are named astore.number, and are located in the ContactsServer_home/logs directory. Change to this directory to view the log files.
Modifying the Contacts Server configuration involves changing items such as LDAP operations, how Access Control List (ACL) entries are cached, automatic account creation, whether notifications are generated, and so on. You use the davadmin config modify command with configuration parameters to implement configuration changes. See "Contacts Server Configuration Parameters" for more information on individual parameters.
To modify the Contacts Server configuration:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin config modify -o configuration_parameter -v value
Where:
configuration_parameter is a specific Contacts Server configuration parameter.
value is an allowed value for the specific configuration parameter.
For example, to modify error logging to use the FINE level:
davadmin config modify -o log.dav.errors.loglevel -v FINE
Use the davadmin config list command to view Contacts Server configurations.
To view a configuration:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin config list -o configuration_parameter
Where:
configuration_parameter is a Contacts Server configuration parameter.
For example, to view the current setting for the log.dav.errors.loglevel parameter:
davadmin config list -o log.dav.errors.loglevel
A standard Contacts Server installation consists of a single default back-end database that contains contact data. Perform the procedures in this section to add or modify back-end databases within your deployment.
Each back-end database must have its own document store. When you use multiple front-end hosts, all document stores must be available to all front-end hosts. You cannot make a document store local to a front-end host in a multiple front-end deployment. For more information, see the topic on configuring Contacts Server with multiple hosts in Contacts Server Installation and Configuration Guide.
Managing Contacts Server back-end databases includes:
A standard Contacts Server installation consists of a default back-end database that contains user data. Over time, you might want to add additional back-end user databases to your deployment.In the case of multiple Contacts Server front ends, configure each to use the same initial default database back end. Then, you add additional back ends to each front end.
To add a new Contacts Server back-end database:
Install the database software on each back-end host.
See either the topic on installing a MySQL database or the topic on installing and creating an Oracle Database instance in Contacts Server Installation and Configuration Guide.
If you installed a MySQL database, do the following:
If the Contacts Server software is not installed on the back-end host, copy the config-mysql and Util.pm scripts from an installed Contacts Server host and adjust the path to those scripts as shown in Steps b and c accordingly.
Do one of the following:
If this is first database on the host, set up the database instance, and create the user and database by running the following command.
ContactsServer_home/tools/unsupported/bin/config-mysql -s -u -c
If there is already a database on the host, just create the contact database by running the following command.
ContactsServer_home/tools/unsupported/bin/config-mysql -c
If you installed Oracle Database 11g Release 2 or Oracle Database 12c not pluggable (non-CDB), do the following:
If the Contacts Server software is not installed on the back-end host, copy the config-oracle and Util.pm scripts from an installed Contacts Server host and adjust the path to those scripts as shown in Steps b and c accordingly.
To create the Oracle database user and schema, run the following command.
ContactsServer_home/tools/unsupported/bin/config-oracle -c
If you installed Oracle Database 12c Container Database (that is, one that uses a pluggable database), see the topic on preparing Oracle Database 12c container database in the Contacts Server Installation and Configuration Guide. You cannot use the config-oracle script and must manually create the database user and schema.
Run the config-backend script on each front-end host.
Note:
If you use WebLogic Server, you cannot run the config-backend script. See the discussion about installing and configuring multiple Contacts Server back-end hosts for WebLogic Server manually in Contacts Server Installation and Configuration Guide.This script creates a JDBC connection pool and a JDBC resource on the GlassFish Server, and a nabserver attributed back-end configuration.
ContactsServer_home/sbin/config-backend
If current deployment is using MySQL, you are prompted for the following information:
Remote database server host name Remote database server port Contact db name on remote server Contact db user name Contact db user password Verifying the database input... Database input is verified Backend identifier for the remote db Document store directory (leave blank if store is remote) Document store host (leave blank if store is local) Document store port (leave blank if store local) Application Server admin user password
Make sure the value for "Contact db name on remote server" is the one that you used for the config-mysql -c command.
If current deployment is using Oracle Database, you are prompted for the following information:
Remote database server host name Remote database server port Oracle database service name on remote server Contact db user name Contact db user password Verifying the database input... Database input is verified Backend identifier for the remote db Document store directory (leave blank if store is remote) Document store host (leave blank if store is local) Document store port (leave blank if store local) Application Server admin user password
Enter Y when prompted to perform the tasks for creating the JDBC connection pool and resource, and nabserver back-end identifier.
The system responds that the database back-end configuration is configured successfully.
Restart the application server.
The init-config script creates the JDBC connection pool and resource, and adds the information to the davserver.properties file, for the one back-end host specified during the front-end host configuration. The JDBC resource for the back-end database is defaultbackend.
To rename this JDBC resource, to match other naming conventions, do the following on each front-end application server:
Create a JDBC resource associated with the nabPool connection Pool.
For example, you might use db1 as the resource name.
Save this change, and restart the application server.
Add the following two lines to each front-end host's ContactServer_home/config/davserver.properties file.
store.dav.db1.backendid=JDBC_resource store.dav.db1.jndiname=jdbc/JDBC_resource
For example, if your resource name is db1, then you would add:
store.dav.db1.backendid=db1 store.dav.db1.jndiname=jdbc/db1
The new resource name can be used in nabStore attribute values.
Note:
Once your Contacts Server deployment is up and running, do not change the user back-end ID as defined by the nabStore attribute.Use the davadmin backend list command to view the back ends configured for your Contacts Server deployment.
To list the back-end databases:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin backend list -u id
Where:
id is the application server administrator user name.
The davadmin backend purge command immediately purges contact data marked for expiration from Contacts Server back-end database(s).
To purge a back-end database:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin backend purge -n name
Where:
name is the name of the back-end database.
For example, to purge a Contacts Server back end named defaultbackend:
davadmin backend purge -n defaultbackend
Items that Contacts Server caches include ACLs, domain maps, LDAP authentication information, and URIs. Clear this cache if you made changes to your Directory Server, and you want Contacts Server to reflect those changes. Or, clear the cache so that any changes to ACLs immediately take effect.
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin cache clear
You can configure a group of Directory Server hosts for use with Contacts Server. This group is referred to as an LDAP pool. Use the davadmin ldappool command to create, modify, delete, and list Contacts Server LDAP pools.
Managing LDAP pools includes:
Use the davadmin ldappool create command to create an LDAP pool of Directory Servers.
To create an LDAP pool:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin ldappool create -n poolname -y property
Where:
poolname is the name of the LDAP pool.
property is a comma-separated list of all property=value options for the specified LDAP pool.
For example, to create an LDAP pool named myldap and the property=value options ldaphost=host1.example.com, ldapport=389, binddn='cn=Directory Manager' ,bindpassword=mypassword:
davadmin ldappool create -n myldap -y "ldaphost=host1.example.com,ldapport=389,binddn='cn=Directory Manager',bindpassword=mypassword"
Use the davadmin ldappool delete command to remove an LDAP pool.
To delete an LDAP pool:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin ldappool delete -n poolname
Where:
poolname is the name of the LDAP pool.
For example, to delete an LDAP pool named myldap:
davadmin ldappool delete -n myldap
Use the davadmin ldappool list command to view LDAP pools.
To list existing LDAP pools:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin ldappool list
You might need to modify properties of an existing LDAP pool, for example, if a host name or port changes. Use the davadmin ldappool modify command to change the properties of an existing LDAP pool.
To modify an LDAP pool:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin ldappool modify -f file
Where:
file is the local input file containing the modifications. You use one line for each account, for batch operation. Lines are in the form pool_name:property_list. The properties are the same ones available for the -y option. For delete operations, only pool_name is used. For more information, see the description of the ldappool -y property option in Calendar Server System Administrator's Guide.
For example, to modify an LDAP pool by using the file /tmp/update_pool.input:
davadmin ldappool modify -f /tmp/update_pool.input
The remote document store mechanism provides storage of contact data on remote hosts. If you add additional document stores to your deployment, you must configure password authentication of the connection between the remote document store server (which runs on the remote host where the store is located), and the document store client (which runs on every Contacts Server front end). The password must be known by both the document store client and the remote document store server. The password is stored in a password file (called a wallet) on both the local and remote hosts.
Managing the document store passfile includes:
Use the davadmin passfile create command to create a passfile.
To create a passfile:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin passfile create
Respond to the password prompts.
For more information, see the topic on remote document store authentication in Contacts Server Installation and Configuration Guide.
Use the davadmin passfile list command to list the passwords stored in a passfile.
To list a passfile:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin passfile list
Use the davadmin passfile modify command to modify the passwords in a passfile.
To modify a passfile:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the following davadmin command:
davadmin passfile modify
Respond to the password prompts.
To enhance security within your deployment, you can use Contacts Server virus scanning of files, such as photos, attached to a contact. Contacts Server virus scanning can examine files in real time to test and optionally reject incoming infected data. You can also choose to scan and optionally delete infected existing data on demand.
Virus scanning is not performed by Contacts Server itself. Instead, you configure an Oracle Communications Messaging Server's Message Transfer Agent (MTA) to filter the contact data. You can configure Contacts Server to share an existing MTA that has already been configured for Messaging Server virus scanning. Or, you can configure a standalone MTA that functions only for Contacts Server virus scanning.
Contacts Server reports all virus scanning activities and detected viruses in its log file for both real-time and on-demand scanning.
Managing virus scanning includes:
The high-level steps to prepare your deployment to perform virus scanning for Contacts Server include:
It is possible that your deployment alread includes Messaging Server and an MTA for performing email virus scanning. If so, you can reuse the existing MTA to also scan contact attachments for viruses. If you do not have an existing MTA, you can install and configure a standalone MTA.
The general steps to install an MTA include:
Installing the Messaging Server software
Running the Messaging Server configure script
Disabling the Message Store and Webmail Server
For details, see the topic on installing a Messaging Transfer Agent in Unified Communications Suite Installation and Configuration Guide.
When configuring Messaging Server, the "configure" step requires a valid LDAP host that is used to include configuration data such as the default mail domain and messaging administrator account. The LDAP host that you specify must be available during virus scanning operations. However, due to MTA caching of LDAP data, this server is not heavily utilized.
The MTA itself does not check for viruses. You configure the MTA to communicate with the desired virus scanning software, also referred to as the AVS. For instructions, refer to the vendor-specific sections in the topic on integrating spam and virus filtering programs in Messaging Server System Administrator's Guide.
The filter should use a Sieve rule to "refuse" the message from Contacts Server if a virus is found by the virus scanning software. The Sieve rule should return FilterVerdictPositive. Contacts Server checks SMTP return values for this exact string, which is defined in the Messaging Server option.dat file. For more information, see the topic on MTA configuration for virus scanning in Calendar Server System Administrator's Guide.
Note:
You configure the MTA to perform a Sieve refuse action if there is a virus, which returns an SMTP code 5xy and the MTA-configured target string FilterVerdictPositive. Contacts Server responds to the target string, where other errors are considered failures in service.After you configure the MTA to communicate with the desired virus scanning software, you create a new incoming SMTP port in Messaging Server's dispatcher.cnf file, strictly for Contacts Server virus scanning use. In this way, Contacts Server traffic is tracked. In addition, a separate SMTP port makes it easier to destroy all data being scanned. You associate this incoming SMTP port with a new MTA channel in the imta.cnf file. Finally, you configure the receiving channel to use the sourcespamfiltern that is configured with the desired virus scan software, so that incoming contact data is tested.
After creating the SMTP channel, you configure the MTA to detect the chosen email address. (The Contacts Server host sends the attachment data as an email with a user recipient email address.) The email address is set up to use the MTA's host name and domain, so that the MTA does not need to perform a lookup for the domain. The user email address itself is not significant because incoming data is not actually delivered.
For instructions on configuring the Messaging Server MTA, refer to Messaging Server System Administrator's Guide.
Use the davadmin config modify command to configure Contacts Server parameters for virus scanning. Some parameters are required; others are optional.
To configure Contacts Server for virus scanning:
Use the davadmin config modify command to configure each of the following required parameters:
davcore.virusscan.emailaddress
davcore.virusscan.host
davcore.virusscan.port
davcore.viruscan.onlineenable
davcore.virusscan.onlinevirusaction
For example:
davadmin config modify -o "davcore.virusscan.emailaddress" -v "myvirususer@mymachine.example.com"
The email address' domain must match the MTA's domain. The user name itself is not significant.
Configure optional davcore.virusscan.* parameters.
See "Contacts Server Configuration Parameters" for more information on the optional davcore.virusscan.* parameters.
To scan for viruses, use the davadmin vscan scan command. This command operates through the application server, and therefore, it can operate on any of the Contacts Server back-end hosts.
To list the back ends:
davadmin backend list
Normally you would want to scan the defaultbackend because that is where Contacts Server user's attachments are stored.
To scan the entire default back end:
davadmin vscan scan -n defaultbackend
To scan a single user's data given their Contacts Server registered email address:
davadmin vscan scan -a user@domain
To use an LDAP base (the distinguished name of the search base object) and filter to specify one or more users to scan:
davadmin vscan scan -B "o=dav" -R "(|(uid=caluser222)(uid=caluser111))"
Finished Virus Scan Set of 2 Users.
User Login issues or data not found: 0
Scanned = 0
Virus hits = 0
Scan Service Failures = 0
See scan log for more information.
Note:
In this example, using only a uid filter might not be specific enough when there are multiple domains. You can use the ldapsearch command to test the specificity of the filter.To scan data at or after February 14th, 2015, 1 am Zulu:
davadmin vscan scan -n defaultbackend -T 20150214T010000Z
Specifying a -T scans data only at the specified time and later,. Additionally, -T saves time by ignoring older data already scanned. In the scan log, the time just before the scan began is printed after the run so it can be used with the -T option in the next scan if no new virus rules are relevant.
Note:
The davadmin vscan command uses the same virus scan configuration as when online virus scan is enabled (davcore.virusscan.onlineenable is set to true). However it does not use the onlineenable variable. Thus, you can run command-line scans without needing to affect incoming data.Virus scan activity for both online scanning and scanning from the command line is printed in the Contacts Server scan log. Found viruses are reported in the log. If actions against viruses are configured, those actions taken are reported in the log. Accounts that reference data that is found to be a virus are reported. The time just before a davadmin vscan scan command is started is printed after a scan. This can be used with the -T option in future scans.
Because the davadmin vscan scan command runs on the application server and not the davadmin client, most useful information is printed in the Contacts Server scan log, not always in the standard output of the davadmin command. The scan log also provides a central repository for all historical virus scan-related information and tracking.
For information about managing logging for the MTA, see Messaging Server System Administrator's Guide.
To view and test channel traffic, add the keyword logging to the defaults channel in the imta.cnf file. Add LOG_CONNECTION=255 and LOG_FILTER=1 to the Messaging Server option.dat file. Refer to the MTA documentation to interpret channel operations such as "E" enqueue and "D" dequeue, "O" open connection, "C" close connection. View messages coming in on the tcp_vscan channel, and dequeue onto the bitbucket channel.
Contacts Server uses a proxy user to bind to the Directory Server when making requests to search the directory. The LDAP entry for this user resembles the following:
uid=nab-admin-hostfqdn-timestamp,ou=People,orgdn
This user typically belongs to the cn=Contacts End User Administrators Group group. This special Contacts Server user makes Directory Server requests on behalf of the end user for whom the request is being carried out. The proxy process takes into account the Directory Server Access Control Instructions (ACIs) for that particular end user. The DN (Distinguished Name) of this newly created user is added to the server configuration as the base.ldapinfo.ugldap.binddn. For information on sample ACIs that show the attributes that Contacts Server needs for granting end users permission to search the LDAP directory, see Contacts Server Security Guide.
Contacts Server supports the use of a corporate directory, that is, a company-wide listing of user information made available to all Communications Suite users.
Managing the corporate directory involves:
To configure Contacts Server to use the corporate directory:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Use the davadmin config modify command to set the following configuration parameters:
davadmin config modify -o davcore.ldapattr.corpdirectoryurl -v corpDirectoryUrl davadmin config modify -o store.corpdir.useldapproxyauth -v true davadmin config modify -o store.corpdir.enablecorpdir -v true davadmin config modify -o store.corpdir.defaultcorpdirectoryurl -v 'ldap://ugldap/??sub?(objectclass=*)?vlv'
If you need access to multiple corporate directories, or need a corporate directory that is different from the server-wide default, use the multi-valued corpdirectoryurl LDAP attribute in the domain entry.
To configure Contacts Server to use a domain-specific corporate directory:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
If you have not already done so, use the davadmin ldappool create command to create an LDAP pool, if the corporate directory resides on a different host than the one configured for the default user/group LDAP pool.
See "Creating an LDAP Pool" for more information.
Add a corpdirectoryurl value to the LDAP attribute in the domain entry.
For example, the following ldapmodify command adds the corpdirectoryurl value for an LDAP pool named varriuspool:
ldapmodify -h ugldap.example.net -D "cn=Directory Manager" -w ugadminpass dn: o=varrius.com,o=dav changetype: modify add: corpdirectoryurl corpdirectoryurl: ldap://varriuspool/??sub?(objectclass=*)?proxyauth=true
To have the change take effect immediately, clear the server domain cache:
cd ContactsServer_home/sbin
davadmin cache clear -t domainmap
To disable the corporate directory for a specific domain:
Add a corpdirectoryurl value to the LDAP attribute in the domain entry with the enabled=false URL extension.
For example, the following ldapmodify command adds the corpdirectoryurl value for an LDAP pool named varriuspool:
ldapmodify -h ugldap.example.net -D "cn=Directory Manager" -w ugadminpass dn: o=varrius.com,o=dav changetype: modify add: corpdirectoryurl corpdirectoryurl: ldap://varriuspool/??sub?(objectclass=*)?enabled=false
Note:
If you have already defined the corpdirectoryurl attribute for a domain, then for each value that should be disabled, add the enabled=false to the LDAP URL extension.To have the change take effect immediately, clear the server domain cache:
cd ContactsServer_home/sbin
davadmin cache clear -t domainmap