Madan Da Deployment

EMC ® Documentum ®
Administrator
Version 7.2
Deployment Guide
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Legal Notice
Copyright © 1999–2017 EMC Corporation. All Rights Reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Adobe and Adobe PDF
Library are trademarks or registered trademarks of Adobe Systems Inc. in the U.S. and other countries. All other trademarks
used herein are the property of their respective owners.
Documentation Feedback
Your opinion matters. We want to hear from you regarding our product documentation. If you have feedback
about how we can make our documentation better or easier to use, please send us your feedback directly at
[email protected].
Table of Contents
Preface ................................................................................................................................ 7
Chapter 1 Planning for Deployment ............................................................................. 9

Documentum Administrator ............................................................................. 9
Required and optional supporting software........................................................ 9
Typical configuration ........................................................................................ 9
Application server host requirements................................................................. 10
Customizing Documentum Administrator ......................................................... 10
Chapter 2 Preparing the Client Hosts .......................................................................... 11

Ensuring a certified JVM on browser clients ....................................................... 11
Enabling HTTP content transfer in Internet Explorer ........................................... 11
Chapter 3 Preparing the Application Server Host ........................................................ 13

Application servers ........................................................................................... 13
Setting the Java memory allocation .................................................................... 13
Turning off failover ........................................................................................... 14
Preparing environment variables for non-default DFC locations .......................... 14
Configuring Apache Tomcat .............................................................................. 14
Disabling HttpOnly Property ........................................................................ 16
Preparing JBoss ................................................................................................ 16
Deploying multiple applications on JBoss ...................................................... 17
Enabling HTTPOnly Cookies Support ........................................................ 18
Configuring VMware vFabric tc Server .............................................................. 19
Preparing IBM WebSphere ................................................................................ 19
Supporting failover in a cluster ...................................................................... 20
Applying policies for IBM WebSphere security ............................................... 20
Preparing Oracle WebLogic ............................................................................... 22
Disabling HttpOnly property ........................................................................ 22
Preparing the application server for Java 2 security ............................................. 22
Preparing to use an external web server ............................................................. 23
Chapter 4 Deploying Documentum Administrator ....................................................... 25

Deploying the WAR file .................................................................................... 25
Enabling DFC connections to repositories .......................................................... 26
Enabling DFC memory optimization.................................................................. 28
Configuring UCF .............................................................................................. 28
Forcing UCF to install a configured JRE ............................................................. 28
EMC Documentum Administrator Version 7.2 Deployment Guide 3

Table of Contents
Enabling presets and preferences repositories..................................................... 29

Configuring encrypted password for presets and preferences
repositories .................................................................................................. 29
Enabling retention of folder structure and objects on export ................................ 30
Enabling external searches ................................................................................ 30
Configuring the connection to the search server .............................................. 31
Configuring the connection to the backup search server .................................. 31
Fully-qualified domain name for full-text indexing ............................................. 32
Resource Management availability..................................................................... 32
Enable presets for Administrator Access and Resource Management ................... 32
Modal popup ................................................................................................... 32
Configuring the modal popup ....................................................................... 33
Chapter 5 Post-Deployment Tasks ............................................................................... 35

Configuring IBM WebSphere ............................................................................. 35
Configuring Oracle WebLogic class loading behavior .......................................... 35
Configuring UCF on Oracle WebLogic Server 11g ............................................... 36
Configuring single sign-on for security servers ................................................... 36
Configuring IBM WebSEAL single sign-on (SSO) authentication .......................... 39
Prerequisites ................................................................................................ 39
Configurations in custom/app.xml file to enable IBM WebSEAL
authentication .............................................................................................. 39
Configuring Kerberos authentication ................................................................. 40
Kerberos-based single sign-on authentication in Documentum
Administrator .............................................................................................. 40
Prerequisites ............................................................................................ 40
Configurations in custom/app.xml file to enable Kerberos
authentication .......................................................................................... 41
Enabling Kerberos SSO authentication in Documentum
Administrator ...................................................................................... 41
Configuring the Kerberos domain name ................................................. 41
Configuring Kerberos fallback ............................................................... 41
Sample Kerberos configuration in app.xml ............................................. 42
Preparing Documentum Administrator and the browser to meet
Kerberos SSO setup requirements .................................................................. 42
Create user account for Documentum Administrator in the
active directory......................................................................................... 42
Define a Service Principal Name for Documentum Administrator
and create KeyTab file ............................................................................... 43
Configuring the client browser to use the SPNEGO protocol ....................... 44
Creating JAAS configuration file .................................................................... 45
Creating a configuration file for the application server to connect to
the KDC server ............................................................................................. 47
Application Server-specific configurations...................................................... 48
Tomcat ..................................................................................................... 48
WebLogic ................................................................................................. 48
WebSphere ............................................................................................... 48
Cross-frame scripting configuration ............................................................... 49
Setting secure attribute to cookies .................................................................. 49
Starting Documentum Administrator................................................................. 49
Testing Documentum Administrator samples ..................................................... 50
Maintenance and procedures............................................................................. 51
Logs to monitor ............................................................................................ 51
4 EMC Documentum Administrator Version 7.2 Deployment Guide

Table of Contents
Application Server .................................................................................... 51

Content Server repository ......................................................................... 51
Java Method Server................................................................................... 52
Index Server ............................................................................................. 52
Disk space management ................................................................................ 52
Jobs ............................................................................................................. 52
DQL queries ................................................................................................. 53
Network connectivity interruption................................................................. 53
RAM and CPU Utilization maxed out ............................................................ 53
Sessions to monitor ....................................................................................... 54
Security and Server access maintenance ......................................................... 54
Improving Performance .................................................................................... 54
Action Implementation ................................................................................. 55
Documentum Object Creation ....................................................................... 55
String Management ...................................................................................... 55
Paging ......................................................................................................... 56
Java EE Memory Allocation ........................................................................... 56
HTTP Sessions ............................................................................................. 58
Preferences................................................................................................... 58
Browser History ........................................................................................... 58
Value Assistance ........................................................................................... 59
Search Query Performance ............................................................................ 59
High Latency and Low Bandwidth Connections ............................................. 59
Qualifiers and Performance ........................................................................... 60
Import Performance ...................................................................................... 61
Load Balancing............................................................................................. 61
Modal Windows and Performance ................................................................. 62
Chapter 6 Troubleshooting Deployment ...................................................................... 63

Wrong JRE used for application server ............................................................... 63
No global registry or connection broker ............................................................. 63
No connection to repository .............................................................................. 63
Login page incorrectly displayed ....................................................................... 64
Slow performance............................................................................................. 64
Out of memory errors in console or log .............................................................. 64
Slow display first time ...................................................................................... 64
DFC using the wrong directories on the application server .................................. 65
Tag pooling problem ......................................................................................... 65
UCF client problems ......................................................................................... 65
Connection issues between a Federated Search server and IPv6 clients ................. 66
Max Sessions error ............................................................................................ 66
Appendix A Pre-Installation Checklist ............................................................................ 67

Table of Contents
List of Tables
Table 1. Preferences configuration elements ........................................................................ 29

Table 2. Authentication elements (<authentication>) ............................................................ 38
Table 3. Preinstallation tasks .............................................................................................. 67

Preface
This guide describes how to deploy the Documentum Administrator application.
Intended Audience
This guide is intended for administrators who are deploying Documentum Administrator. Readers
are expected to be familiar with the Windows, UNIX, or Linux operating systems and are able to
install and configure a J2EE application server.
Revision History
Revision Date Description
February 2017 Updated the Configuring IBM WebSphere, page 35 section.
January 2017 Updated the Enabling presets and preferences repositories, page 29
section.
December 2016 • Updated the procedure To disable the WDK compression filter in
the section Configuring Apache Tomcat, page 14.
• Updated the section Preparing JBoss, page 16.

August 2015 Updated the section, Preparing Oracle WebLogic, page 22.
April 2015 Updated the following sections:
• Configuring Apache Tomcat, page 14
• Preparing JBoss, page 16
• Configuring VMware vFabric tc Server, page 19
• Preparing IBM WebSphere, page 19.

Preface
Revision Date Description
• Preparing Oracle WebLogic, page 22

February 2015 Initial publication.

Chapter 1
Planning for Deployment
Documentum Administrator
Documentum Administrator is a Content Server and repository administration tool. Documentum
Administrator runs on an application server host.
The EMC Documentum Content Server Administration and Configuration Guide and the Documentum
Administrator online help contain information on how to use Documentum Administrator to administer
and configure Content Server and Documentum repositories.
Required and optional supporting software

Before deploying Documentum Administrator, the following components must be installed:
• Content Server and its associated database
• Content Server global repository
• Connection broker
• J2EE application server or servlet container
Typical configuration
When deployed on a single application server, a Documentum Administrator requires the following
network components:
• Application server host on which to deploy Documentum Administrator
• Separate Content Server host with a repository and one or more Content Servers
• Global registry repository
• Client hosts that run a supported web browser
Documentum Administrator can be deployed in supported clustered environments. The EMC
Documentum Environments and System Requirements Guide contains the information on the supported
clustered server configurations.
Caution: For security and performance reasons, do not install the Content Server and
Documentum Administrator on the same host. Also, do not deploy web applications to the
internal application server embedded in the Content Server.

Planning for Deployment
Application server host requirements

The application server host used for Documentum Administrator requires the following:
• Directory name restriction
Java does not allow directories containing the following characters, which must not appear in the
directory names or paths of Documentum applications:
! \ / : * ? " < > |
• Content transfer directory permissions

The content transfer directory on the application server host is used to store files temporarily
when they are transferred between the repository and the client machine. The default content
transfer directory is specified in the app.xml file as the value of <server>.<contentlocation>.
The application server instance owner must have write permissions on this temporary content
transfer location.
Some application servers require policies that grant permissions to write to these directories. Refer
to deployment information for your application server to see Documentum policy settings.
• DNS resolution
The Domain Name Server (DNS) must be configured to resolve IP addresses properly based on
the URL used to access the server.
Customizing Documentum Administrator

Customization of Documentum Administrator is not supported.

Chapter 2
Preparing the Client Hosts
Ensuring a certified JVM on browser clients

Browser client hosts require a certified version of the Java virtual machine (JVM or VM) to initiate
content transfer in Documentum Administrator. The EMC Documentum Environment and System
Requirements Guide contains the information on the supported JVM product versions.
For UCF content transfer, UCF downloads a lightweight applet to the browser when the client makes
the first content transfer or preferences request. If the JVM required for UCF is not present on a
Windows client, UCF uploads a private JVM that does not affect the browser JVM.
Enabling HTTP content transfer in Internet

Explorer
Internet Explorer version has a default security setting that prevents the display of the file download
dialog. To perform checkout, view, or edit in HTTP mode, add the Documentum Administrator
URL to the list of trusted sites in the browser.
If the browser security settings are disabled for Automatic prompting for file downloads and File
download, nothing happens when a user exports as CSV. These settings are disabled by default in
Internet Explorer. The user must enable them.
To enable HTTP file download in Internet Explorer:

1. In Internet Explorer, navigate to Tools > Internet Options and click the Security tab.
2. Select Trusted sites and click Custom level.
3. Scroll to the Downloads section and enable Automatic prompting for file downloads and File
download.
Click OK twice to save the settings.
4. Close all browser windows and restart the browser.

Preparing the Client Hosts

Chapter 3
Preparing the Application Server Host
Application servers
Before deploying Documentum Administrator, ensure that your J2EE application server or servlet
container is a supported version that serves sample JavaServer Pages successfully. Your selected
application server and optional external web server must be certified for Documentum Administrator.
EMC does not provide support for installing or running application servers. The documentation for
each application server contains instructions on how to install, stop, start, and run the application
server. Contact the application server vendor for technical support.
Setting the Java memory allocation

The Java memory allocation affects the application server performance. We recommend using the
following settings:
• Minimum memory allocation
The minimum recommended Java memory allocation values for application servers on a small
system are:
-Xms1024m -Xmx1024m
• MaxPermSize
Application servers can slow down, throw exceptions, or crash with an application that has many
JavaServer Pages. Set the MaxPermSize parameter to 128 or higher to avoid these problems.
• Session caching
Document caching can consume at least 80 MB of memory. User session caching can consume
approximately 2.5 MB to 3 MB per user. Consequently, 50 connected users can consume over 200
MB of VM memory on the application server. Increase the values to meet the demands of the
expected user load.
To achieve better performance, add these parameters to the application server startup command
line:
-server
-XX:+UseParallelOldGC
The first parameter on the command line must be -server.
Performance improves because the Java client VM is not suitable for long running server jobs.
The default Java garbage collector cannot clean up the heap quickly enough, especially when the
application server machine runs on multiple CPUs.

The Java documentation contains more information on these settings. More information on application
server performance tuning and benchmarking for Documentum products is available from your EMC
Documentum SE or EMC Documentum Consulting.
Turning off failover

If your application server and environment combination does not support failover, you can turn off
failover in app.xml. The product release notes or the EMC Documentum Environment and System
Requirements Guide contains information to determine whether failover is supported for your
environment.
If you do not turn off failover, you see failover validation messages in the application server log,
but these validations do not interfere with operations. Do not use the application in a failover
environment that is not certified.
To turn off failover for the application, open app.xml in the custom directory and add the following
element:
<failover>
<enabled>false</enabled>
</failover>
Preparing environment variables for

non-default DFC locations
The DFC environment variable dfc.data.dir specifies the base location for content transfer on
the application server host. This location is specified as the value of the key dfc.data.dir in the
dfc.properties file located within the application WAR file in WEB-INF/classes. If this variable
is not set in the environment for the application server, the default location is the Documentum
subdirectory of the current working directory. (The current working directory contains the application
server executable.) For example, in Apache Tomcat the location is <CATALINA_HOME>/bin. On
Oracle WebLogic, it is <BEA_HOME>/domains/wl_server/documentum.
By default, the checkout and export directories are subdirectories of the dfc.data.dir directory,
and the user directory is the same as dfc.data.dir. If you wish to use non-default locations for
these directories, create environment variables for dfc.checkout.dir, dfc.export.dir, and
dfc.user.dir, respectively. The default value of dfc.registry.mode, which corresponds to the
key dfc.registry.mode in the dfc.properties file, is file. By default, the full path to this file is
dfc.user.dir/documentum.ini. For a non-default file name or location, specify it as the value of
the environment variable dfc.registry.file.
Configuring Apache Tomcat

This section describes how to configure Apache Tomcat.

In Apache Tomcat, the HttpOnly property of cookies is enabled by default and causes the
jsessionid cookie to be unavailable to the client side script and applets. Hence, perform the
following:
1. Add the following line in the catalina.properties file located at <APACHE_TOMCAT_
HOME>\conf:
org.apache.jasper.compiler.Parser.STRICT_WHITESPACE=false
jnlp.com.rsa.cryptoj.fips140loader=true
2. Disable tag reuse in Apache Tomcat in the web.xml file of the /conf directory. Find the JSP servlet
entry in the web.xml file. Add the enablePooling initialization parameter and disable pooling:
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>enablePooling</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>fork</param-name>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
3. Restart the application server.

When deploying Documentum Administrator on Tomcat 8, compression must be set to the
application server’s compression mode. For better performance on Tomcat 8.x, do the following:
• Enable web application server’s compression
• Disable the WDK compression filter
To enable the web application server compression

1. Navigate to <Tomcat Home>/conf.
2. Locate and open server.xml.
3. Search for Connector port=”8080”. It contains,
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="24000" redirectPort="8443"/>
4. Append the following entry to the Connector tag:
compression="on"
compressionMinSize="2048"
compressableMimeType="text/html,text/xml,application/xml,text/plain,text/css,text/
javascript,text/json,application/x-javascript,application/
javascript,application/json"
useSendfile="false"
The updated Connector tag is:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
compression="on"

compressionMinSize="2048"
compressableMimeType="text/html,text/xml,application/xml,text/
plain,text/css,text/javascript,text/json,application/
x-javascript,application/javascript,application/json"
useSendfile="false"/>
To disable the WDK compression filter

1. Open wdk/app.xml and navigate to the end of the document.
2. Search for the <compression_filter_enabled> tag and set it to false. The default value is true.
<compression_filter_enabled>false</compression_filter_enabled>
Disabling HttpOnly Property

Modify the <Context> element in the context.xml file located at <APACHE_TOMCAT_
HOME>\conf:
From
<Context>
To
<Context useHttpOnly="false">
Preparing JBoss
Configuring JBoss
1. If available, delete the dfc.keystore and wdk.keystore files in <JBoss Home>\bin
(Windows) and <JBoss Home>/bin (Linux). This will not be present in case of a fresh
installation. If present, this will be from any previous WDK application that was deployed
on JBOSS.
2. To configure the dfc.properties file for the application, refer to the section .
3. To configure encrypted passwords in the app.xml file using TrustedAuthenticatorTool, refer
to the section .
4. Encrypting the password using TrustedAuthenticatorTool creates the dfc.keystore and
wdk.keystore in the WEB-INF/classes folder.
5. Move the keystore files from <WebApp Root>\WEB-INF\classes (Windows) and <WebApp
Root>/WEB-INF/classes (Linux) to the bin folder of the <JBoss Home> directory.
6. Copy the contents of the classes folder from <WebApp Root>\WEB-INF\classes (Windows)
and <WebApp Root>/WEB-INF/classes (Linux) to a temporary location (for example,
Temp-Loc).
Execute the following command at Temp-Loc to create a web-inf-classes jar file:
jar -cvf web-inf-classes.jar *

7. Copy the web-inf-classes.jar file to <WebApp Root>\WEB-INF\lib (Windows) and

<WebApp Root>/WEB-INF/lib (Linux).
8. Delete the classes folder from <WebApp Root>\WEB-INF (Windows) and <WebApp
Root>/WEB-INF (Linux).
9. Add the configuration entry (in bold) to the subsystem tag in the standalone.xml
file in <JBoss Home>\standalone\configuration (Windows) and <JBoss
Home>/standalone/configuration (Linux) to disable tag pooling:
<subsystem xmlns="urn:jboss:domain:web:2.1"
default-virtual-server="default-host" native="false">
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
<configuration>
<jsp-configuration tag-pooling="false"/>
</configuration>
</subsystem>
10. Configure the binding address by replacing 127.0.0.1 with the application server host IP address
in <wsdl-host> and <interfaces> tags in standalone.xml
11. Execute the following command at <WebApp Root> to repackage the Webtop WAR file:
jar –cvf webtop.war *
Deploying multiple applications on JBoss

JBoss requires the DFC and WDK keystores in the JBOSS/bin folder. If multiple applications with
different preset or preference repository passwords are deployed, then the WDK and DFC keystore
files in the JBOSS/bin folder should have the encryption keys to decrypt both the encrypted
passwords present in the app.xml files of both the applications.
1. Create an XML file with the file name jboss-deployment-structure.xml and add the
following tags to the file:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.apache.log4j"/>
</exclusions>
</deployment>
</jboss-deployment-structure>
2. Add the jboss-deployment-structure.xml file in the WEB-INF folder.

3. To configure the dfc.properties file for the application, refer to the section .
4. To generate the keystores for both the applications, perform either of the following options:
Option 1
1. For application 1, configure encrypted passwords in the app.xml file using
TrustedAuthenticatorTool. For more information, refer to the section .
2. Encrypting the password using TrustedAuthenticatorTool creates the dfc.keystore and
wdk.keystore files in the WEB-INF/classes folder.

3. Copy the DFC and WDK keystores from application 1 to the application 2 (classes folder) and
encrypt the preference repository password of application 2 using TrustedAuthenticatorTool.
For more information, see .
This updates the same keystore file with the encryption keys to decrypt the password for the
second repository as well.
4. Move the updated keystore files from application 2 to the JBOSS/bin folder.
Option 2
1. Encrypt the preference repository passwords for multiple applications in the same location.
For example, navigate to the <WebApp Root>\WEB-INF\classes folder of application 1
and encrypt the preference repository passwords for both the applications. The app.xml
files of both the applications are updated with the respective encrypted password generated
for the global repository mentioned in the dfc.properties file of the application. For more
information, refer to the section .
2. Move the keystore file which has both the encryption keys from <WebApp
Root>\WEB-INF\classes (Windows) and <WebAppRoot>/WEB-INF/classes (Linux)
to the bin folder of the <JBoss Home> directory.
5. For application 1 and application 2, copy the contents of the classes folder from
\WEB-INF\classes (Windows) and /WEB-INF/classes (Linux) to temporary locations. For
example, Temp-Loc1 and Temp-Loc2.
Execute the following command at Temp-Loc1 and Temp-Loc2 to create a web-inf-classes jar
files for the respective applications file:
jar -cvf web-inf-classes.jar *
6. For application1 and application 2, copy the respective web-inf-classes.jar file to <WebApp
Root>\WEB-INF\lib (Windows) and <WebApp Root>/WEB-INF/lib (Linux) folder
structure.
7. For application1 and application 2, delete the corresponding classes folder from <WebApp
Root>\WEB-INF (Windows) and <WebApp Root>/WEB-INF (Linux) folder structure.
8. If you are configuring the JBOSS application server for the first time, add the configuration entry
(in bold) to the subsystem tag in the standalone.xml file and configure the binding address as
mentioned in the steps 9 and 10 of section.
9. For both the applications execute the following command at <WebApp Root> to repackage
the Webtop WAR file:
jar –cvf webtop.war *
Enabling HTTPOnly Cookies Support
For the HttpOnly cookies support, navigate to \WEB-INF\web.xml and perform the following:
1. Update the web-app header specification from version 2.4 to 3.0:

From
<web-app version="2.4" xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

To
<web-app version="3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
metadata-complete="true"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
2. Add the following entry in <session-config>:

<cookie-config>
<http-only>true<http-only/>
</cookie-config>
Configuring VMware vFabric tc Server

This section describes how to configure VMware vFabric tc Server.
In VMware vFabric tc Server, the HttpOnly property of cookies is enabled by default and causes
the jsessionid cookie to be unavailable to the client side script and applets. To fix this issue,
perform the following:

Modify the <Context> element in the context.xml file located at <VMware_vFabric_tc_Server_
HOME>\conf:
From
<Context>
To
<Context useHttpOnly="false">
1. Add the following line in the catalina.properties file located at <VMware_vFabric_tc_

Server_HOME>\conf:
org.apache.jasper.compiler.Parser.STRICT_WHITESPACE=false
Preparing IBM WebSphere

Running Documentum Administrator on an IBM WebSphere application server requires the
following:
• Preparing the application server to support failover in a cluster
• Applying policies for Java 2 security
• Supporting non-default content transfer locations


Deselect Set session cookies to HTTPOnly to help prevent cross-site scripting attacks from the
location Application servers>server1>Session management>Cookies.
Note: If there are multiple applications deployed in the same application server and if you require to
set the flag HttpOnly just for WDK application, then perform the following steps:
1. Deselect Set session cookies to HTTPOnly to help prevent cross-site scripting attacks from
All Applications>da>Session management>Cookies.
2. Check Override the session management from All Application >da>session
management.
Supporting failover in a cluster

Failover in a clustered environment requires that you set the NoAffinitySwitchBack custom property
to true in the WAS cluster. The IBM WebSphere documentation contains more information on this
setting. The product release notes contains information on the failover support.
Applying policies for IBM WebSphere security

If IBM WebSphere global security is enabled for the application server, by default it enables Java 2
security. Java 2 security requires security policies. Apply the policies in the Documentum files
app.policy, library.policy, and was.policy. EMC Documentum provides these files on
the download site in the compressed archive PolicyFiles.zip. These files contain the minimum
set of policies that are required for the application to run without error. Add these policies to your
existing files.
Set up the environment variables that are referenced in these policies. The application server instance
owner must have write permission on these directories. Define the following environment variables:
• dfc.data.dir
By default, the dfc.data.dir directory is the Documentum subdirectory of the directory that
contains the application server executable.
• webtop.content.xfer
Specifies the temporary content transfer directory on the application server. Must match
the value in app.xml of the element <contentxfer>.<server>.<contentlocationwindows> or
<contentlocationunix>.
The policy files in PolicyFiles.zip contain the minimum required policies for the dfc.data.dir
directory. To add policies for non-default content transfer locations, add the following lines to
library.policy. For each policy that you add, set up an environment variable that specifies the
non-default location.
Policy for Documentum Administrator —

permission java.io.FilePermission "${da.content.xfer}${/}-", "read, write, delete";
permission java.io.FilePermission "${da.content.xfer}", "read, write, delete";

Policy for local user directory (non-default location) — This policy is required if the user directory
for the application server host machine is a non-default location. The default location is the same as
the location specified by the dfc.properties key dfc.data.dir.
permission java.io.FilePermission "${dfc.user}${/}-", "read, write, delete";
permission java.io.FilePermission "${dfc.user}", "read, write, delete";
Policy for checkout and export directories (non-default location) — These environment variables
must specify the same location as the value of the dfc.properties keys dfc.checkout.dir and
dfc.export.dir. The default locations for these directories are checkout and export subdirectories
of dfc.data.dir.
permission java.io.FilePermission "${dfc.checkout}${/}-", "read, write, delete";
permission java.io.FilePermission "${dfc.checkout}", "read, write, delete";
permission java.io.FilePermission "${dfc.export}${/}-", "read, write, delete";
permission java.io.FilePermission "${dfc.export}", "read, write, delete";
Policy for DFC registry file (non-default location) — The value of the dfc.registry
environment variable must match the location specified in the dfc.properties file for the key
dfc.registry.file.
permission java.io.FilePermission "${dfc.registry}${/}-", "read, write, delete";
permission java.io.FilePermission "${dfc.registry}", "read, write, delete";
Policy for Webtop temporary content transfer directory (non-default location) —

permission java.io.FilePermission "${webtop.content.xfer}${/}-", "read, write,
delete";
permission java.io.FilePermission "${webtop.content.xfer}", "read, write,
delete";
Policy for non-Webtop WDK-based temporary content transfer (non-default location) — You can
use this policy for TaskSpace or another application that is not based on Webtop:
permission java.io.FilePermission "${wdk.content.xfer}${/}-", "read, write, delete";
permission java.io.FilePermission "${wdk.content.xfer}", "read, write, delete";
Policy for documentum applications directory (non-default location) — The default location is
dfc.data.dir.
permission java.io.FilePermission "${documentum}${/}-", "read, write, delete";
permission java.io.FilePermission "${documentum}", "read, write, delete";
Policy for DFC class cache directory (non-default location) — The default location is
dfc.data.dir/cache.
permission java.io.FilePermission "${dfc.cache.dir}${/}-", "read, write, delete";
permission java.io.FilePermission "${dfc.cache.dir}", "read, write, delete";
Policy for Content Intelligence Services —

permission java.io.FilePermission "${cis.content.xfer}${/}-", "read, write, delete";
permission java.io.FilePermission "${cis.content.xfer}", "read, write, delete";

Preparing Oracle WebLogic

If you are deploying in a Oracle WebLogic Managed Server environment and use UCF to perform
large content operations, set the WLIOTimeoutSecs parameter for the web server plug-in to a large
value. UCF requires a sticky session for a single operation. The Oracle WebLogic documentation on Web
Server Plug-ins parameters contains additional details.
When deploying Documentum Administrator along with D2 application on the same application
server, add the following lines to the weblogic.xml present in <DA>\WEB-INF folder.
<session-descriptor>
<cookie-path>/DA</cookie-path>
</session-descriptor>
Disabling HttpOnly property

1. Modify the <session-descriptor> element in the WebLogic.xml file located at
\da\WEB-INF:
From
To
<session-descriptor> <cookie-http-only>false</cookie-http-only>
Preparing the application server for Java 2

security
If you plan to use Java 2 security for securing access to available system resources in your
Documentum Administrator installation, then use the java policy configuration file that is bundled
with your application server. The java policy configuration file of the application server specifies the
permissions granted to the classes, in your Documentum Administrator installation. To help you
update the java policy configuration file of the application server, an example policy template file is
included in the Documentum Administrator installation (Webtop.example.java.policy file).
The file specifies the permissions required to access the Documentum Administrator classes. The
Webtop.example.java.policy file is included in the da.war file, and gets extracted into the
<da_app_root> folder.
Caution: Do not omit any permission specified in the Webtop.example.java.policy file

while incorporating the permissions in the application server java policy configuration file.
Otherwise, Documentum Administrator might fail to start or some features might fail to work.

Note:
• The documentation for each application server contains instructions on adding or updating
permissions in the security policy file of the application server.
• The Webtop.example.java.policy file contains a default set of permissions that are required
for Documentum Administrator functionality.
To enable Java 2 security in the application server:

1. Navigate to <da_app_root>\Webtop.example.java.policy and identify the permissions
that must be incorporated into the application server security policy file.
2. Navigate to the policy file of your application server.
Based on the syntax and locations specified in the application server documentation, add or
update the permissions (identified in the Webtop.example.java.policy file) in the policy file
of the application server.
3. Configure your application server to pick the security policy files.
Preparing to use an external web server

External web servers are sometimes used as a front end to the application server. For example, an
external web server can be used for balancing the loads on a collection of application servers or used
as a forward or reverse proxy server.
UCF content transfer uses chunked transfer encoding, a standard of the HTTP 1.1 specification. Many
proxy web servers implement chunked transfer encoding in a way that does not work properly
with UCF. If the external server does not support HTTP 1.1 chunked encoding, configure UCF to
use an alternative chunked encoding.
If you are deploying in a manager server or network deployment environment, the external web
server must provide session affinity support.


Chapter 4
Deploying Documentum Administrator
Deploying the WAR file

Download the Documentum Administrator software. You can find the location of the software
(including language packs) and instructions for downloading it in the EMC Documentum Administrator
Release Notes or in the instructions you received through email on how to download products from
the EMC download site.
Language packs are available to localize (translate) Documentum Administrator. A language pack
is a language-specific archive file. The file contains a graphical user interface (GUI) and user
documentation that has been localized into a language other than the default application language,
U.S. English.
To deploy Documentum Administrator:

1. Unpack the WAR file and modify the dfc.properties file by following the instructions in
Enabling DFC connections to repositories, page 26. Perform this procedure before attempting to
connect to Documentum repositories.
2. Enable the optional presets and preferences repositories in the dfc.properties file by
following the instructions in Enabling presets and preferences repositories, page 29.
3. (Optional) Add language packs to and configure them in the DA WAR file.
a. Unpack the language pack zip file into the root DA WAR directory.
b. Add the required locale under <supported_locales> in da/custom/app.xml.
For example, for the Japanese language pack, add <locale>ja_JP</locale> to
da/custom/app.xml as follows:
<supported_locales>
<locale>en_US</locale>
<locale>ja_JP</locale>
<supported_locales>
4. Re-archive the WAR file.

5. Deploy the WAR file according to the deployment instructions in your application server
documentation.
6. (Optional) If you have installed the Japanese language pack and the repository is on a
non-Japanese operating system, then you must populate the data dictionary with the Japanese
data dictionary files by running dd_populate.ebs on a Japanese operating system. The EMC
Documentum Content Server Administration and Configuration Guide contains more information
about populating the data dictionary in a repository from a non-English host.

Note:
• If you have created a repository on a Japanese operating system, then the data dictionary is
automatically populated with the Japanese data dictionary files.
• Non-xCP Documentum applications (such as Documentum Administrator, Webtop) cannot
be deployed on the application server instance where xCP runtime is hosted because of
conflicting dfc.jar instances on the classpath. Do not deploy Documentum Administrator
on the same application server where xCP is deployed.
Enabling DFC connections to repositories

Before Documentum Administrator can connect to repositories, provide connection broker and global
registry values in the dfc.properties file.
Documentum Administrator requires a Content Server version 6 or later global registry. The global
registry is a central repository that serves several purposes:
• Deploys service-based business objects (SBOs)
• Stores network location objects
• Stores application presets, unless another repository is configured in app.xml
• Stores persistent user preferences, unless another repository is configured in app.xml
The EMC Documentum Content Server Installation Guide contains information about enabling a
repository as a global registry.
You can copy information from the dfc.properties file that the Content Server installer generated
onto your global registry host. The generated dfc.properties file contains the connection broker
address and the encrypted global registry user login information.
To locate dfc.properties file values:

1. On the global registry repository host, locate the Content Server installation directory. On
Windows hosts, the default installation directory is C:\Documentum. On UNIX hosts, the
$DOCUMENTUM environment variable specifies this directory.
2. Open config\dfc.properties.
3. Copy the following keys and their values from the file:
dfc.docbroker.host[0]=address
dfc.docbroker.port[0]=port_number
dfc.globalregistry.repository=repository_name
dfc.globalregistry.username=username
dfc.globalregistry.password=encrypted_password
dfc.crypto.repository=repository_name
dfc.session.secure_connect_default=try_secure_first
To configure connections in dfc.properties file before deployment:

1. Unpack the application WAR file.
2. Open WEB-INF/classes/dfc.properties.

3. Add the fully qualified host name for the connection broker to the following key. You can
increment the index number within brackets to add backup hosts.
dfc.docbroker.host[0]=host_name
4. To use a port for the connection broker other than the default of 1489, add a port key to the
dfc.properties file:
dfc.docbroker.port=port_number
5. Add the global registry repository name to the following key:

dfc.globalregistry.repository=repository_name
6. Add the user name of the dm_bof_registry user to the following key:
dfc.globalregistry.username=dm_bof_registry_user_name
The global registry user, who has the user name dm_bof_registry, has read access only to objects
in the /System/Modules and /System/NetworkLocations.
7. Add an encrypted password value for the following key:
dfc.globalregistry.password=encrypted_password
You can either copy the username and encrypted password from the dfc.properties file on
the global registry Content Server host or you can select another global registry user and encrypt
the password using the following command:
java -cp dfc.jar com.documentum.fc.tools.RegistryPasswordUtils
password_to_be_encrypted
Note: The directory containing the javaw.exe file must be on the system path.
8. If the Content Server, connection broker, and the repository are configured in the non-anonymous
SSL mode then provide these parameters in the dfc.properties file:
a. Add the secure connection mode and set it to secure first.
dfc.session.secure_connect_default = try_secure_first
b. Add the trust store path.

dfc.security.ssl.truststore=<dfc truststore path>
c. Add the trust store password.

dfc.security.ssl.truststore_password=<password>
d. Specify whether to use the existing trust store.

dfc.security.ssl.use_existing_truststore=<false/true>
e. Specify the crypto repository to connect.

dfc.crypto.repository=repository_name
9. Save the dfc.properties file.

Note: If you create a WAR file from this application directory, ensure that any paths that you
specify in the dfc.properties file are valid directories on the application server. Also ensure
that the application server instance owner has write permission on the specified directories.

Enabling DFC memory optimization

The DFC diagnostics are enabled by default. To free up memory resources, disable the
dfc.diagnostics.resources.enable parameter in the dfc.properties file. Add the following line to
your dfc.properties file:
dfc.diagnostics.resources.enable=false
Configuring UCF
The Web Development Kit 6.8 Development Guide contains the following procedures:
• How to configure different content transfer mechanisms (UCF or HTTP) for roles.
• How to configure the UCF client content transfer directories, including client path substitution.
• How to support self-signed or unsigned SSL certificates.
• How to configure the UCF server for forward and reverse proxy servers and alternative chunking.
Note: The web server associated with an application server must support chunked requests.
The web server forwards HTTP requests using chunked transfer encoding, as described in the
HTTP/1.1 protocol, to the back-end application server. If chunked requests are not supported
then the client must use the UCF alternative chunking mode.
Forcing UCF to install a configured JRE

If DA uses UCF content transfer, it is mandatory that the browser has a JRE installed. By default, the
UCF installer uses the JRE that is installed in the browser if its version is the same as or later than
the version of JRE in the UCF installer. A later version of JRE sometimes introduces problems in
an application.
If you do not want to allow multiple JRE versions, you can configure the UCF installer to use
or install only the version that is configured in the installer configuration file. If that version is
already installed, the UCF installer uses it. If it is not present, the UCF installer installs and uses the
configured version. You must add an enforceJreInstallation attribute to the runtime java
element in the file ucf.installer.config.xml to use the configured JRE version. This file is
located in your web application directory, wdk/contentXfer. Change the runtime java element
by adding the enforceJreInstallation attribute as follows:
platform os="windows" arch="x86">
<runtime type="java" version=1.7.0_72 href="win-jre1.7.0_72.zip"
exePath="jre1.7.0_72\bin\java.exe" enforceJreInstallation="true">
If users have already installed UCF, force an update of the UCF configuration every time you change
the UCF configuration on the application server. Ensure that you append a new character to the app
element’s version attribute to force the update. In the following example, 7.2.223 is changed:
<app id="shared" version="7.2.223" compatibilityVersion="7.2"/>

Enabling presets and preferences repositories

By default, presets and persistent preferences are stored in the global repository. For better
performance, you can configure your Documentum Administrator to use different repositories for
presets and persistent preferences.
Add your preferences repository settings to app.xml in the /custom directory of the
application. Copy the entire <preferencesrepository> element from /custom/app.xml into
/custom/app.xml and then specify your repository.
Table 1. Preferences configuration elements
Element Description
<preferencesrepository> Contains a <repository> element. If this element
is not present, user preferences are stored in
the global repository, which can slow down
performance.
<repository_path> Specifies the path within the preference
repository in which to store preferences. If the
path does not exist at application startup, then it
is created.
<repository> Specifies the repository in which to store
preferences, preferably not the global repository.
To enable users to create presets using the presets editor, assign those users the
dmc_wdk_presets_coordinator role.
Configuring encrypted password for presets and

preferences repositories
To configure the password in presets and preferences repositories, perform the following steps:
1. Login to IAPI as an administrator to change the default passwords of dmc_wdk_presets_owner

and dmc_wdk_preferences_owner users in Content Server.
• To change the password for the dmc_wdk_presets_owner user, run the following command:
retrieve,c,dm_user where user_name='dmc_wdk_presets_owner';
set,c,l,user_password
<enter new password>
save,c,l
• To change the password for the dmc_wdk_preferences_owner user, run the following
command:
retrieve,c,dm_user where user_name='dmc_wdk_preferences_owner';
set,c,l,user_password
<enter new password>
save,c,l
2. Encrypt the passwords in DA using TrustedAuthenticatorTool located at WEB-INF/classes.

On Windows — Run the following command:

java TrustedAuthenticatorTool <password>.
The utility sends the encrypted password to the standard output. For example,
C:\DA\WEB-INF\classes>java -cp .;../lib/dfc.jar;../lib/commons-io-1.2.jar;
../lib/certj.jar;../lib/jsafeFIPS.jar TrustedAuthenticatorTool trusted
Encrypted: [5P54fOKuCKM=], Decrypted: [trusted]
On Linux — Perform the following steps:

1. Navigate to the WEB-INF/classes folder.
2. Set the classpath for the referenced jars:
export JAR_PATH=.:../lib/dfc.jar:../lib/
commons-io-1.2.jar:../lib/certjFIPS.jar:../lib/jsafeFIPS.jar
3. Execute the Java command to generate the encrypted password:

java -cp $JAR_PATH TrustedAuthenticatorTool trusted
3. Update the encrypted passwords in DA app.xml. Search for <presets> and update the
<password> attribute with the encrypted password. For example,
<presets>
...
<password>5P54fOKuCKM=</password>
...
</presets>
Search for <preferencesrepository> and update the <password> attribute with the encrypted
password. For example:
<preferencesrepository>
...
<password>5P54fOKuCKM=</password>
...
</preferencesrepository>
Enabling retention of folder structure and

objects on export
To enable retaining the same folder structure (as the one in the repository) and the contained objects
on the local file system when the parent folder is exported, add the following element to your
app.xml in the custom directory:
<deepexport>
<enabled>true</enabled>
</deepexport>
The default is false.
Enabling external searches

To allow users to search external sources, an administrator must configure a connection to a Federated
Search server. (The Federated Search server is a separate product that is purchased separately from

Documentum Administrator and Content Server.) If this connection has not been configured, you
cannot include external sources in your search.
Configuring the connection to the search server

The following procedure describes how to enable the Federated Search server to query external
sources. The Federated Search Services documentation provides more information on how to configure
the Federated Search server itself.
To configure the connection to a Federated Search server:

1. Unpack the client application WAR file.
2. Open the file dfc.properties in WEB-INF/classes.
3. Enable the Federated Search server by setting the following:
dfc.search.ecis.enable=true
4. Specify the RMI Registry host for the Federated Search server by setting the following:
dfc.search.ecis.host=host_IP
dfc.search.ecis.port=port
where
• host_IP is IP address or machine name of the Federated Search server.
• port is the port number that accesses the Federated Search server. The default port is 3005.
Configuring the connection to the backup search server

You can set a backup server in case the primary Federated Search server is unreachable. If a
DFC-application cannot connect to the primary Federated Search server to query external sources,
the backup server is contacted. You can define the time period after which the application tries to
connect again to the primary server. To define the backup server, specify the RMI host and port in
the dfc.properties file:
• dfc.search.ecis.backup.host: Host of the backup Federated Search server. Default value is:
localhost.
• dfc.search.ecis.backup.port: Port of the backup Federated Search server. Default value is: 3005.
• dfc.search.ecis.retry.period: Waiting period before retrying to connect to the primary Federated
Search server. This time is in milliseconds. Default value is: 300000.

Fully-qualified domain name for full-text

indexing
If you use Documentum Administrator to administer full-text indexing, a fully-qualified domain
name must identify where the application server is installed. For example, the host name
tristan.documentum.com is acceptable, but an IP address (for example, 123.45.6.789) is not acceptable.
Resource Management availability

If Resource Management is installed, the RMI port used to manage the resources must be open. If a
firewall separates the machine hosting Documentum Administrator from the remote resource, the
RMI port must be open and not obstructed by the firewall. Also, the Domain Name Server must be
configured to resolve IP addresses properly based on the URL used to access the server.
Enable presets for Administrator Access and

Resource Management
When deploying Documentum Administrator, the Enable/Disable Presets flag in the application
custom app.xml file must be set to True, as it impacts the following functionality:
• Administrator Access: If the preset flag is disabled, the Administrator Access functionality in
Documentum Administrator is disabled.
• Resource Management: If the preset flag is disabled, the ability to dynamically access or modify
the resource agent information in the global registry is disabled. Resource Management still
functions for resource agents defined in the static configuration file, but administrators cannot
add, modify, or delete resource agents using Documentum Administrator.
Note: The Enable/Disable Presets flag in the custom app.xml file for Documentum Administrator
overrides the presets flag in WDK.
Modal popup
When you invoke a component that has been configured for modal popup, the user interface for the
component is displayed in a modal popup window. This modal popup window is placed on top of
the current window. The title of the modal popup window shows the title of the component page
followed by — Webpage Dialog. You can resize the modal popup window but cannot access the
parent window until you dismiss the popup window (also known as child window). When you try
to close a modal popup window by clicking the [X] button on the window, the framework treats
it as a canceling an action.
When you invoke another component that is configured for modal popup from the child window,
another modal popup window is placed on top of the child window to show the component user

interface. With stacked modal windows, you cannot access a parent window until you dismiss the
child window.
Modal popup is only supported in Internet Explorer, but in the 508 accessibility mode.
Configuring the modal popup

You can configure a nested component to display in a modal popup. If a component is tied to an
action, you can modify the action definition by adding the <invocation> element.
<action id="about">
<params>
<param name="enableTools" alias="CtrlKeyPressed" required="false"
</params>
<execution class="com.documentum.web.formext.action.LaunchComponent">
<component>about</component>
</execution>
<invocation>
<modalpopup>
<windowsize>small</windowsize>
<refreshparentwindow>never</refreshparentwindow>
</modalpopup>
</invocation>
</action>
This configuration is added to the action definition because the modal popup behavior is tied to how
a component is invoked. The idea is to have the modal popup configuration in the action definition.
In the invocation element, you can specify the size of the modal popup and whether the framework
must refresh the parent window when the child window is closed. All action controls read the
configuration. If the configuration indicates that the component tied to this action displays in a modal
popup, it opens a modal popup window and submits the request to the component during action
invocation. The response is displayed in the modal popup window.


Chapter 5
Post-Deployment Tasks
Configuring IBM WebSphere

To complete the Documentum Administrator deployment on IBM WebSphere:
1. Navigate to Application Servers > Server1 > Web container > Custom Properties in Admin
console and set the com.ibm.ws.webcontainer.invokefilterscompatibilitycustom property to True.
2. Add the dfc.diagnostics.resources.enable=false parameter in the dfc.properties file of
Documentum Administrator.
3. Change the classloader setting for the WDK-based application module in IBM WebSphere in the
Manage Modules section of the administration console.
a. Select the WAR file.
b. For Classloader order, choose Classes loaded with local class loader first (parent last).
c. Click Save.
Configuring Oracle WebLogic class loading

behavior
Oracle WebLogic classloader precedence can cause SSL validation to fail. Configure the Oracle
WebLogic class loading behavior to load the application level classes first, instead of the Oracle classes.
To configure the class loading behavior:

1. Navigate to the .\WEB-INF\classes folder and open the weblogic.xml file.
2. Modify the file as follows:
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//
DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/
dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
<description>Weblogic Webapp</description>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>
3. Save your changes.

Configuring UCF on Oracle WebLogic Server

11g
Oracle WebLogic Server 11g and later requires a modification in the weblogic.xml file to configure
UCF clients. Without the modification, the Content Server throws an exception when users attempt to
view the server log file in Documentum Administrator.
To configure UCF on Oracle WebLogic Server 11g

1. Navigate to the .\WEB-INF\classes folder and open the weblogic.xml file.
2. Add the following lines:
<cookie-http-only>false</cookie-http-only>
3. Save your changes.
Configuring single sign-on for security servers

Content Server supports authentication plug-ins, SSO using RSA Access Manager (formerly known
as ClearTrust), or CA SiteMinder.
RSA Access Manager users must have the same login names as the Content Server repository. User
names are case sensitive for the Content Server, so Access Manager user names must be at least 8
characters in length and have the same case as the repository login. Errors in authentication are
logged in the /Documentum/dba/log/dm_rsa.log file.
For CA SiteMinder, set up a SiteMinder realm to perform authentication for Documentum
Administrator. The dm_netegrity plug-in installed in the Content Server decodes the
SMSESSION token sent from Documentum Administrator for authentication. The plug-in
contacts the CA server to verify that the token is valid. Errors in authentication are logged in the
/Documentum/dba/log/dm_netegrity.log file.
To enable single sign-on (SSO):

1. Configure the RSA Access Manager or CA SiteMinder security server to authenticate repository
users. (The security server documentation contains more information.)
2. Configure the web application server to use an external HTTP Server supported by the security
server. (The RSA or CA security server documentation contains more information.)
3. Configure the Content Server plug-in. (The EMC Documentum Content Server documentation
contains more information.)
4. Configure Documentum Administrator in the app.xml file.
5. RSA only: Create a directory named rsaConfig under the Documentum Administrator root
directory. Copy two files: aserver.conf from the Access Manager server and webagent.conf
from the RSA web agent. Paste them into the rsaConfig directory.
If you change the original files, copy them to your Documentum Administrator rsaConfig
directory. The RSA documentation contains more information.

6. Locate the file AuthenticationScheme.properties in WEB-INF/classes/com/documentum/

web/formext/session. The SSO authentication scheme classes. Modify the properties
file to make your preferred SSO authentication scheme (SSOAuthenticationScheme or
RSASSOAuthenticalScheme) first in the list of authentications that are attempted during login.
If the repository login scheme is listed before the SSO scheme, the user is presented with a login
screen instead of single sign-on.
To configure app.xml for a security server single sign-on:

The WDK SSO Authentication Scheme for CA SiteMinder needs three pieces of information to
authenticate an HTTP session against a repository:
• Name of the authentication plug-in that is used in the Content Server.
• Name of the ticket to retrieve from a vendor-specific cookie.
• User name, which is retrieved from a vendor-specific HTTP requests header or remote user.
1. Open the app.xml file in your applications /custom directory.
2. Copy from app.xml the <authentication> element and its entire contents, and paste into your
custom app.xml file.
3. Update the <sso_config> element under the existing <authentication> element as shown in the
following example:
<authentication>
<domain/>
<docbase>secure_docbase</docbase>
<service_class>
com.documentum.web.formext.session.AuthenticationService
</service_class>
<sso_config>
<ecs_plug_in>dm_rsa</ecs_plug_in>
<ticket_cookie>CTSESSION</ticket_cookie>
<user_header>HTTP_CT_REMOTE_USER</user_header>
</sso_config>
</authentication>
Note: This example is for RSA.

The following table describes the authentication elements.

Table 2. Authentication elements (<authentication>)
Element Description
<docbase> Specifies default repository name. When SSO
authentication is enabled but a repository
name is not explicitly spelled out by
the user nor defined in this element, the
sso_login component is called. In this
case the component prompts the user for the
repository name.
<domain> Specifies Windows network domain name.
<service_class> Specifies fully qualified name of class that
provides authentication service. This class
can perform pre- or post-processing of
authentication.
<sso_config> Contains SSO authentication configuration
elements.
<sso_config> Specifies name of the Content Server
authentication plug-in (not the authentication
<ecs_plug_in> scheme name). Valid values:
• RSA: dm_rsa
• CA: dm_netegrity
<sso_config> Specifies name of vendor-specific cookie that
holds the sign-on ticket. Valid values:
<ticket_cookie>
• RSA: CTSESSION
• CA: SMSESSION
<sso_config> Specifies name of vendor-specific header that
holds the username. Valid values:
<user_header>
• RSA: HTTP_CT_REMOTE_USER.
• CA: The user_header value is dependent on

the settings in the webagent configuration
object in the policy server. The default is
either SMUSER or SM_USER, depending
on whether the LegacyVariable flag is
set to true or false. If true, use SM_USER. If
false, use SMUSER.

Configuring IBM WebSEAL single sign-on

(SSO) authentication
IBM WebSEAL is a high-performance, multi-threaded web server that applies fine-grained security
policy to a protected network. IBM WebSEAL incorporates back-end web application server resources
into its security policy, and can provide single sign-on (SSO) solutions. IBM WebSEAL acts as a reverse
web proxy by receiving HTTP or HTTPS requests from a web browser and delivering content from its
own web server or from back-end web application servers. IBM WebSEAL’s authorization service
evaluates requests to determine whether the user is authorized to access the requested resource.
EMC Documentum can integrate with IBM WebSEAL, its SSO solution, or any other SSO solution
supported by IBM WebSEAL.
The IBM WebSEAL documentation contains more information on installing and configuring the IBM
WebSEAL server. The Development Guide or Installation Guide of your applications contains
more information about configuring Documentum applications to enable IBM WebSEAL SSO
authentication.
Prerequisites
• Set the precedence of authentication schemes in the com.documentum.web.formext.
session.AuthenticationSchemes.properties file. The Web Development Kit Development
Guide contains more information.
• Install the IBM WebSEAL server on a machine, and create an HTTP or HTTPS junction that links
the IBM WebSEAL server to Documentum Administrator.
The IBM WebSEAL documentation contains more information on installing and configuring the
IBM WebSEAL web server.
• Deploy Documentum Administrator on the application server machine, and connect to a Content
Server that has been configured for IBM WebSEAL SSO authentication. The Chapter 4, Deploying
Documentum Administrator section contains more information to deploy Documentum
Administrator on an application server. The EMC Documentum Content Server Installation Guide
and the EMC Documentum Content Server Administration and Configuration Guide contains more
information on configuring Content Server for IBM WebSEAL SSO authentication.
Configurations in custom/app.xml file to enable IBM

WebSEAL authentication
Set the value of the user_header tag to iv-user, within the authentication tag:
<authentication>
<webseal_config>
<user_header>iv-user</user_header>
</webseal_config>
</authentication>
Note: Copy the user_header element into the authentication tag of the custom/app.xml file.

Configuring Kerberos authentication

Kerberos SSO authentication scheme is used to authenticate the user who wants to log in to the DA
web application from a computer that is in the Kerberos domain.
If a user accesses the Documentum Administrator URL the first time, the Documentum Administrator
application prompts the user to select a repository in the Repository list of the Documentum
Administrator Login screen. The user can select a repository and click OK to log in to Documentum
Administrator. The user does not need to select a repository during subsequent access to the same
repository, unless the browser cache is cleared.
EMC Documentum supports Kerberos secure Single-Sign-On (SSO) using Microsoft Active Server
Domain Services for Kerberos Key Distribution Center (KDC) services in the following ways:
• In a single domain.
• In one-way and two-way trusts between multiple domains in the same forest only; that is,
cross-forest trusts are not supported.
Kerberos-based single sign-on authentication in

Documentum Administrator
Kerberos is a network authentication protocol. The Kerberos protocol is designed to provide a strong
mutual authentication mechanism between a client and a server or between multiple servers on an
open network that usually does not have a security method implemented in it. Kerberos was created
as a solution to the problem of network insecurity. In the context of single sign-on, because SSO relies
on a centralized and trusted authentication mechanism, Kerberos is a natural fit. A well-designed
implementation confidently authenticates users to the Kerberos server and communicates those
credentials securely to all applications participating in the Kerberos implementation.
When Kerberos-based Single Sign-On Authentication is enabled on Documentum Administrator,
users of Documentum Administrator are automatically authenticated and logged in to the repository
using their credentials stored in the user’s private credential area on the Windows platform. Unlike
other SSO solutions where users must specify username and password to validate their credentials on
the Policy Server, the Kerberos-based single sign-on authentication does not pose any authentication
challenge to the user. The only time when the user’s credentials are authenticated is when the user
logs in to the local machine using the Windows domain credentials. In this manner, the user can log
in to DA having logged in to the local computer.
Prerequisites
• Deploy Documentum Administrator on the application server machine, and connect to a Content
Server that has been configured for Kerberos SSO authentication. The EMC Documentum Content
Server Installation Guide, and the EMC Documentum Content Server Administration and Configuration
Guide contains more information on configuring Content Server for Kerberos SSO authentication.
• Install a supported browser on the client machine.

• Register Documentum Administrator as a Service Principal in the Key Distribution Center (KDC).
The Create user account for Documentum Administrator in the active directory, page 42 section
contains more information on registering Documentum Administrator as a Service principal in
the KDC.
• On a Windows Server host, ensure that the following key and value have been added to the
registry for Java to use to acquire additional service tickets:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01
Configurations in custom/app.xml file to enable Kerberos

authentication
Carry out the configurations specified in this section, in the <enabled>, and <domain> tags within the
<authentication> tag, and copy the configurations into the custom/app.xml file.
Enabling Kerberos SSO authentication in Documentum Administrator
An application level setting is provided in custom/app.xml within the <authentication> tag to

enable or disable Kerberos-based SSO authentication. The default value defined for the <enabled>
tag in the <kerberos_sso> element is "false". Set the <enabled> tag to true to enable Kerberos SSO
authentication.
<kerberos_sso>
</kerberos_sso>
Configuring the Kerberos domain name
An application level tag is provided to specify the Kerberos domain, within the <authentication> tag.
Enter the domain name in the <domain> tag.
<kerberos_sso>
<domain><domain_name></domain>
</kerberos_sso>
Configuring Kerberos fallback
The Kerberos SSO Authentication Scheme provides the option to fall back to the default login
mechanism to the web-application, on failure conditions. Set the <docbase_login_fallback> tag in
the <kerberos_sso> tag in custom/app.xml, to support the default login to the web-application,
as follows:
<docbase_login_fallback>true</docbase_login_fallback>
The default value of the <docbase_login_fallback> tag is false.

Copy the <docbase_login_fallback> element into the <kerberos_sso> tag in custom/app.xml.
Sample Kerberos configuration in app.xml
The following code snippet is an example of the final configuration for Kerberos in app.xml.
Example 5-1. Code snippet in custom/app.xml file to enable Kerberos authentication

<authentication>

<kerberos_sso>
<browsers>
<windows>
<ieversions>8.0,9.0,10.0,11.0</ieversions>
<firefoxversions>10.0</firefoxversions>
</windows>
</browsers>

<docbase_login_fallback>false</docbase_login_fallback>

<domain>WDKBLR.COM</domain>
</kerberos_sso>
</authentication>
Copy the <authentication> tag from the custom/app.xml file into the custom/app.xml file.
Preparing Documentum Administrator and the browser

to meet Kerberos SSO setup requirements
This section discusses the setup requirements to enable Kerberos single sign-on authentication in
Documentum Administrator. Ensure that the client machine is already configured to use Kerberos
authentication before you prepare the system for enabling Kerberos-based authentication.
Create user account for Documentum Administrator in the active

directory
You must register Documentum Administrator as a Kerberos principal in the active directory to enable
the Documentum Administrator application to participate in Kerberos authentication. A Kerberos
principal is a regular account on an Active Directory. The name of the principal can be something like
this "[email protected]". The realm name follows the "@" character in the principal. The principal
represents the Documentum Administrator application service in the Kerberos realm.
To create a user in active directory:

1. Choose Start > Administrative Tools > Active Directory Users and Computers.
The Active Directory Users and Computers console is started.
2. Click a domain name and expand the contents.

3. Right-click Users and select New > User.

4. Type the user name in the Full Name field and in the Logon Name field and click Next.
5. Enter the password. Ensure that none of the password options are selected and click Next.
6. Click Finish.
7. Choose the Users node in the left navigation bar of the Active Directory Users and Computers
console.
8. Choose and right-click the user that you created, and select Properties.
9. Choose one or both of the following encryption algorithms under Account options, in the
Account tab, based on the encryption algorithms you require:
• Use DES encryption types for this account
• This account supports Kerberos AES 128 bit encryption
10. To enable delegation for a Documentum Administrator user account, see To enable delegation for
a Documentum Administrator user account:, page 44.
The Delegation tab appears when you select Properties in the context menu of a user account, in
the Active Directory Users and Computers console, only after you register the Documentum
Administrator SPN to the user.
Define a Service Principal Name for Documentum Administrator

and create KeyTab file
A Service Principal Name (SPN) is a unique name that identifies an instance of a service and is
associated with the login account under which the service instance runs. Windows 2008 account
names are not multi-part as Kerberos principal names. As a result, administrators cannot directly
create an account of the name HTTP/hostname.dns.com. Such a principal instance is created using
service principal name mappings. In this case, an account is created with a meaningful name and
hostname, and a service principal name mapping is added for HTTP/hostname.dns.com.
To use Kerberos after defining the SPN for the application server (on which Documentum
Administrator is deployed), the administrator must create a keytab (key table) file for Documentum
Administrator. Documentum Administrator requires the keytab file to authenticate itself to the Key
Distribution Center (KDC).
The administrator must use the ktpass command-line tool to register the SPN as a security principal
in the Windows Server Active Directory and to create a KeyTab file on the KDC. This ktpass.exe
is bundled with Windows 2008 Resource Toolkit package and must be installed separately. Run
ktpass.exe on the Active Directory Server machine and when the keytab file is generated move it to
the da_installation/WEB-INF folder on the application server machine.
ktpass /pass <password> -out <user-name>.keytab -princ <SPN> -crypto
AES128-SHA1 +DumpSalt -ptype KRB5_NT_PRINCIPAL
/mapOp set /mapUser <user-name>
Example 5-2. You can run the ktpass command with the following parameters:
ktpass /pass <password> -out da.keytab –princ
HTTP/[email protected] –crypto AES128-SHA1 +DumpSalt
-ptype KRB5_NT_PRINCIPAL /mapOp set /mapUser da

This command generates the da.keytab file on the Active Directory machine. Copy this file to the
da_installation/WEB-INF folder on the application server machine.
To enable delegation for a Documentum Administrator user account:

1. Choose the Users node in the left navigation bar of the Active Directory Users and Computers
console.
2. Choose and right-click the user created according to the procedure specified in the Create user
account for Documentum Administrator in the active directory, page 42 section, and select
Properties.
3. Choose Trust this user for delegation to any service (Kerberos only) in the Delegation tab.
Configuring the client browser to use the SPNEGO protocol
You can configure your browser to use the SPNEGO protocol.
To configure Internet Explorer:

1. Log in to the Windows active directory domain.
2. Open the Internet Explorer browser.
3. Choose Tools > Internet Options.
The Internet Options dialog box is displayed.
4. Click the Security tab.
5. Choose the Local intranet icon, and click Sites.
The Local intranet dialog box is displayed.
6. Ensure that all settings are selected and click Advanced.
The Local intranet dialog box is displayed.
7. In the Add this Web site to the zone field, specify the web address of the host name to enable
single sign-on (SSO) and add it to the Web sites list, and click OK twice.
8. Click the Advanced tab and scroll to Security settings.
9. Ensure that the Enable Integrated Windows Authentication (requires restart) option is selected
and click OK.
10. Restart your Internet Explorer to activate this configuration.
To configure Firefox:
1. Log in to the Windows active directory domain.
2. Open the Firefox browser.
3. In the Address field, type about:config and press Enter.
4. In the Filter field, type network.n.
All Preferences are listed.

5. Double-click the network.negotiate-auth.trusted-uris and network.negotiate-auth.delegation-

uris preferences.
These preferences list the sites that are permitted to engage in SPNEGO Authentication with
the browser.
6. Enter a comma-delimited list of trusted domains or URLs.
For example, type http://da.dctmlabs.com.
Click OK. The preference is updated in the Preferences list.
7. Restart the Firefox browser to activate the configuration.
In Windows, the Data Encryption Standard (DES) encryption type (security settings) for Kerberos
is disabled by default. If you log in to Documentum Administrator from a client computer having
Windows as the operating system, you should enable the following:
• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC_MD5
• AES128_HMAC_SHA1
• AES256_HMAC_SHA1
The Microsoft Windows documentation contains the instructions.
Creating JAAS configuration file

Apache Tomcat, Oracle WebLogic, and VMware vFabric tc Server use the JAAS configuration
file to obtain the Login context. The KerberosSSOAuthenticationScheme class uses the Java
JAAS and GSS-API to perform Kerberos authentication. The administrator must create the
JAAS configuration file in the da_app_root_directory/WEB-INF folder; for example,
da_app_root_directory/WEB-INF/krb5Login.conf.
Create the JAAS configuration file as follows:
<loginContext>
{
<LoginModule> required
principal="<SPN>"
realm="<REALM>"
refreshKrb5Config=true
noTGT=true
useKeyTab=true
storeKey=true
doNotPrompt=true
useTicketCache=false
keyTab="<DAuser_keytab_path>";
};
where:

<loginContext> Corresponds to the DA SPN. You replace

separator characters with hyphen characters
and omit the @REALM segment in the SPN.
For example, the following LoginContext is
derived from the corresponding SPN:
• LoginContext:
HTTP-wdkapps-wdkblr-com
• SPN:
http/[email protected]
Note: Make sure that the SPN in the JAAS

configuration matches the SPN defined in
web.xml.
<LoginModule> Specify the Kerberos login module to be used to
perform user authentication:
• For single-domain support only:
com.sun.security.auth.module.
Krb5LoginModule
• For both multi- and single-domain support:

com.dstc.security.kerberos.jaas.
KerberosLoginModule
Note: This module is the Quest

KerberosLoginModule.
<SPN> The DA SPN.
For example, for single-domain support:

http/[email protected]
For multi-domain support, instead of appending

the domain name to the SPN, use the realm
property to specify the domain name.
<REALM> (Multi-domain support only) The realm name.
For example: WDKBLR.COM
<DAuser_keytab_path> The path to the DA user account’s *.keytab
file in the WEB-INF folder of Apache Tomcat.
For example:<da_app_root>/WEB-INF/xxx.
keytab

Creating a configuration file for the application server

to connect to the KDC server
To specify the KDC server to which the application server connects, create a configuration file in the
%WINDIR% directory of the Windows operating system or the /etc folder of the UNIX and Linux
operating systems. The names of the configuration files are krb5.ini (Windows) and krb5.conf
(UNIX and Linux) respectively. Refer to the following examples.
Example 5-3. Create the configuration file with the following contents to specify Data Encryption
Standard (DES) as a permitted encryption type:
[libdefaults]
default_realm = WDKBLR.COM
forwardable = true
ticket_lifetime = 24h
clockskew = 72000
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1

default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
[realms]
WDKBLR.COM= {
kdc = WDKWIN5175.WDKBLR.COM
admin_server = WDKWIN5175.WDKBLR.COM
}
The following example is to specify the Advanced Encryption Standard (AES) as a permitted
encryption type along with the DES.
Example 5-4. Create the configuration file with the following contents to specify both DES and AES as
permitted encryption types:
[libdefaults]
default_realm = <Kerberos_domain_name>
forwardable = true
clockskew = 72000
default_tkt_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc

default_tgs_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
[realms]
<Kerberos_domain_name>= {
kdc = <KDC_server_address>
admin_server = <KDC_server_address>
}
Modify the Windows configuration file with the following details:

• Specify the Kerberos domain name as the default_realm.
• The realms section points to the KDC server.

Application Server-specific configurations

While configuring the application servers for Kerberos authentication the following application
server-specific configurations are a prerequisite. Carry out the following configurations that are
specific to your application server, on which Documentum Administrator is deployed as described in
the following sections:
• Tomcat, page 48
• WebLogic, page 48
• WebSphere, page 48
Tomcat
In Tomcat_home_directory/bin/Catalina.bat or catalina.sh, set the following JAVA

options:
set JAVA_OPTS=% JAVA_OPTS % -Djava.security.krb5.conf=<location of krb5.ini>
-Djava.security.auth.login.config=<location of krb5Login.conf>
-Djavax.security.auth.useSubjectCredsOnly=false
WebLogic
In WebLogic_home_directory\user_projects\domains\your_
domain\bin\setDomainEnv.cmd file or the setDomainEnv.sh, set the following JAVA options:
set JAVA_OPTIONS=%JAVA_OPTIONS% -Xms256m -Xmx1024m -Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
-Djava.security.krb5.conf=<location of krb5.ini>
-Djava.security.auth.login.config=<location of krb5Login.conf>
-Djavax.security.auth.useSubjectCredsOnly=false
Note: The default location of the krb5.ini file is %WINDIR% (Windows).
WebSphere
• In WebSphere_home_
directory\AppServer\profiles\AppSrv01\properties\wsjaas.conf, add the
following configuration:
HTTP-hostName-realm_Name { com.ibm.security.auth.module.Krb5LoginModule
required debug=true credsType="both" useKeytab="file:fullPathToKeytabfile"
principal="HTTP/hostName.realmName"; };
• Create a configuration file to specify the KDC server to which the application server should
connect, in the %WINDIR% (Windows) or in /etc/krb5 (AIX). The names of the configuration
files are krb5.ini (Windows) and krb5.conf (AIX). To support Advanced Encryption
Standard (AES) in the Websphere Application Server, specify aes128-cts-hmac-sha1-96 as a
permitted encryption type.

Example 5-5. Both DES and AES as permitted encryption types

[libdefaults]
default_realm = WDKBLR.COM
forwardable = true
clockskew = 72000
default_tkt_enctypes = aes128-cts aes128-cts-hmac-sha1-96 des3-cbc-sha1

des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes128-cts aes128-cts-hmac-sha1-96 des3-cbc-sha1
permitted_enctypes = aes128-cts aes128-cts-hmac-sha1-96 des3-cbc-sha1
[realms]
WDKBLR.COM= {
kdc = WDKWIN5175.WDKBLR.COM
admin_server = WDKWIN5175.WDKBLR.COM
}
Cross-frame scripting configuration

To resolve the issue of cross-frame scripting, perform the following:
1. Open <DA_DEPLOYMENT_ROOT>/custom/app.xml and enable <x_frame_option>.

<x_frame_option>
</x_frame_option>
2. Also, enable <frame_bursting>.

<frame_bursting>
</frame_bursting>
Setting secure attribute to cookies

To set the secure attribute to cookies, open <DA_DEPLOYMENT_ROOT>/custom/app.xml and
perform the following:
<secured_cookies_for_https_only>
</secured_cookies_for_https_only>
Starting Documentum Administrator

Before you test the deployment, ensure that Documentum Administrator is started in the application
server. The documentation on each web application server contains information on starting the
application.

To verify Documentum Administrator deployment and configuration:

1. Open a browser window and type the following URL:
http://host_name:port_number/virtual_directory
where:
• host_name is the host where the application server is installed. If the browser is on
the application server machine, substitute localhost for host_name. For example:
http://localhost.
• port_number is the port where the application server listens for connections.
• virtual_directory is the virtual directory for your application.
For example, if the application server host is named iris, the port number is 8080, and the
application virtual directory is da, the URL is http://iris:8080/da.
2. Use Documentum Administrator to log in to a repository.
If the login succeeds, the application is correctly deployed and configured.
Testing Documentum Administrator samples

After deploying Documentum Administrator, you can view sample pages after logging in to a
repository. The sample JavaServer Pages, component definitions, and supporting compiled class files
are provided in a zip file along with the product download. Unzip them to your application root
directory, preserving the folder hierarchy in the zip file.
To view the Documentum Administrator samples:

1. Ensure that the application server is running.
2. Open a browser and type the following URL:
http://host_name:port_number/virtual_directory/component/login
where:
• host_name is the host where the application server is installed.
• port_number is the port where the application server listens for connections.
• virtual_directory is the virtual directory for the application.
A login dialog box appears.
3. Log in to a test repository.
The login dialog box reappears with the status message Login Successful.
4. Type the following URL:
http://host_name:port_number/virtual_dir/wdk/samples/index.jsp
This page displays a list of the available samples.
5. Click Session Zoo and type a valid repository username, password, repository name, and domain
(if necessary), then click Create Connection.
The repository is listed in the All Connected Repositories section of the page. The Status
message line starts with Successfully connected to repository repository_name.

6. Experiment with other samples, especially Menu Zoo, Tree Control, and FX Control Pens.
Some samples have Create Test Cab and Destroy Test Cab buttons. Click these buttons to create
and delete a test cabinet in the repository and require Create Cabinet privileges.
Maintenance and procedures

After the installation, it is essential to follow a maintenance/procedure checklist for maximum system
performance and stability.
Many of the maintenance procedures and jobs are configured or accessed through Documentum
Administrator:
• Server and Repository configurations
• LDAP configuration
• Users, Groups, Roles
• Security (ACLs)
• Storage (Locations, Storage, and Filestores)
• Index Agent’s failed index list should be understood and resubmitted, if necessary
Logs to monitor
It is highly recommended to check all logs periodically for errors and warnings.
Application Server
• Name: stdout_yyyymmdd.log (for example, stdout_20090218.log)

• Location: Application Server logs directory
• Purpose: Warnings and errors from Documentum Administrator and TBOs
Content Server repository
• Name: DocbaseName.log
• Location: $DOCUMENTUM\dba\log
• Purpose: Repository startup output and any warnings or errors

Java Method Server
• Name: access.log and DctmServer_MethodServer_DocbaseName.log

• Location: %JBOSS_HOME%\server\DctmServer_MethodServer\logs
• Purpose: Access and status of the Java Method Server
Index Server
• Name: access.log and DctmServer_IndexAgent.log

• Location: %JBOSS_HOME%\domains\DctmDomain\servers\DctmServer_
IndexAgent\logs
• Purpose: Access and status of index agent
Disk space management

The Content Server has a state of the repository job (dm_StateOfDocbase) which monitors this.
Also, the data drive should be monitored.
Monitor the following:
• SQL Server transaction log
• Webtop cache files
• Index data drive
• Database maintenance and logs
• Disk space
• Transaction logs
• CPU and RAM usage patterns
Jobs
Some of the jobs discussed in this section are not active OOTB. They have to set to active and started
on a schedule. Ensure to set the run times so that they do not conflict other jobs and backup schedules.
• dm_ContentWarning: Provides warnings for low availability on DM content/fulltext disk
devices.
• dm_LogPurge: Removes outdated server/session, and job/method logs method.
• dm_StateOfDocbase: Lists the repository configuration and status information. Also, displays
the number of documents and total size of content.
• dm_AuditMgt: Removes old audit trail entries A key parameter is the cutoff in days, basically
how many days worth of audits to keep.

• dm_QueueMgt: Deletes dequeued items from dm_queue.

• dm_UpdateStats: Updates RDBMS statistics and reorganizes tables (if RDBMS supports).
• dm_ConsistencyChecker: Checks the consistency and integrity of objects in the repository.
• dm_DataDictionaryPublisher: Publishes the data dictionary information.
• dm_LDAPSynchronization: Used for one-way synchronization of LDAP users and groups
to Docbase Method.
• dm_FTStateOfIndex: State of Index dm_FTIndexAgentBoot Boot Index Agents Method.
• dm_GwmTask_Alert: Sends email alert if task duration exceeds.
• dm_GwmClean: Cleans all the orphan decision objects.
DQL queries
This section discusses the DQL queries to be run to check on audit trails and dmi_queue_items.
The following statements are some of the DQLs to determine the number of audit trails and queue
items that were in the repository:
Select count(*) from dmi_queue_item
Select count(*) from dm_audittrail
Network connectivity interruption

If any network interruption occurs, then service logs should be checked for compromised activity.
The Content Server and Tomcat server may need to be restarted. The logs of the application and
Content Servers should be periodically monitored for errors and warnings.
RAM and CPU Utilization maxed out

If RAM is filled or CPU utilization is maxed out then the service responsible should be checked. If
the service is a Documentum service, it should be restarted and root cause should be determined.
Utilization should be monitored and any anticipated spikes in use or additional services need to be
load tested and analyzed. If the application server’s performance is slow and the concurrent users
reach EMC’s limit of 20, EMC recommends adding a second application server.

Sessions to monitor
This section discusses the different ways to monitor sessions.
• Documentum Administrator: Administration > User Management > Session
• DQL:
— execute show_sessions: To display all active and inactive sessions
— execute list_sessions: To display active sessions
• DocBasic ebs script: Set this script at a command line prompt to output how many active and
inactive sessions are current on the Content Server. Set the interval between output and how
many loops to run.
Security and Server access maintenance

You can perform the following for the security and server access maintenance:
• Test users and test content should be deleted out of production.
• The database schema owner account should be locked down.
• The Documentum install owner dmadmin should be locked down.
• Only scheduled, authorized access to the production should be allowed for all servers of the
system.
• Repository audit trails should be configured for certain events, such as deleting of content.
Improving Performance
There are several application guidelines that can significantly improve performance of your web
application. These interventions are described in the following topics.
Follow these recommendations for performance:
• Event handling
Server event handling provides code reuse across the application, state management, and better
performance.
• Queries
Set <showfolderpath> to false in the search component to speed queries.
• Tracing
Turn off tracing to improve performance. Navigate to the page wdk/tracing.jsp and deselect
all tracing flags.

Action Implementation
By default, arguments in multiple selection are passed in a query string. One query string is
created for selected object. Alternatively, you can cache arguments in the container class. The EMC
Documentum Web Development Kit Development Guide contains more information.
The states of all actions associated with dynamic action controls are evaluated when the
actionmultiselect control is rendered. A large number of selectable items or associated actions can
degrade performance. For example, if there are 10 selectable items and 100 associated actions, 1000
states will be evaluated.
Preconditions are called for each item in a list component or actionmultiselect control. The action
service checks preconditions for each control, and the control tag class renders JavaScript to
dynamically show, disable, or hide the controls based on the state of checkboxes. For 10 multiselect
items and 50 dynamic actions, this results in a possible 500 precondition calls before page rendering.
Action precondition classes must be optimized to manage performance. The actionmultiselect control
in particular should not have too many selectable items or associated actions.
You can configure the application to test action preconditions only when they are executed instead of
on page rendering. Set the onexecutiononly attribute of the precondition element to true as follows:
<precondition onexecutiononly="true" class=.../>
To reduce the query time for preconditions, you may be able to use a dm_sysobject with a custom
a_content_type attribute instead of a custom object type for type-specific actions.
Another strategy to improve action precondition performance is to cache custom attributes that are
used by the precondition by means of a custom attribute data handler. The EMC Documentum Web
Development Kit Development Guide contains more information.
Documentum Object Creation

Whenever possible, do not call IDfSession.getObject(), which performs a fetch of the object. Most
attribute arguments can be retrieved without a call to getObject(), because they are cached by the
initial query on the page rather than from a getObject() call. For example, if the page has a databound
control to r_lock_owner, that attribute value is cached. Your component can check for the existence of
the argument value and query only if the argument was not passed.
Queries inside an action class queryExecute() method can seriously degrade performance.
String Management
The following coding practices can enhance the performance of your application:
• Replace string concatenation using "+" with string buffers, and initialize the string buffer to an
appropriate size.
• Strip white space and comments from JSP pages to reduce their size. WDK provides a utility to strip
white space and comments: CommentStripper, in WEB-INF/classes/com/documentum/web/tools.

The EMC Documentum Web Development Kit Development Guide contains more information on
using this tool.
Paging
The paged attribute on the datagrid control provides links that enable the user to jump between pages
of data within the enclosing data container. You should page your data for better performance and
display. If you set the paged attribute to true, the data provider or data container will render the
appropriate links only if the provider has returned multiple pages of data from the query.
Controls can retrieve any number of rows from a data provider unless you limit the cache size or
apply paging to the datagrid. The memory cache continues to grow as the user pages through entries,
because all attributes for displayed columns are cached in memory. An optimization setting will
limit the caching to object IDs only.
The cache size for the number of objects returned by a query is configurable in Databound.properties,
in WEB-INF/classes/com/documentum/web/form/control. This value defaults to 100, which will
cache the values for page sizes up to 100. If you increase the available page size in your application,
you should increase the cache size to match the largest page size. Paging is configured on a JSP
page that contains a datagrid. Limit the choices for page sizes by setting the pagesizevalues of the
datapagesize JSP tag.
The cache optimization setting useOptimizedResultCache in the properties file Databound.properties
located in WEB-INF/classes/com/documentum/web/form/control/databound limits caching to
object IDs only. This value is set to true by default, and object IDs are cached and data rows are
retrieved only for the current page in a listing display. An optimized cache is used for the Cabinet,
HomeCabinet, and MyFiles components. If your listing component extends objectlist, myfiles_classic,
or homecabinet_classic, you will inherit the optimization support.
To add optimization support to a listing component, you must construct an alternative,
simplified query that does not query all of the display attributes. Pass your query to the
DocbaseQueryService method buildObjectListFindByIDQuery(). Refer to the source code for DocList
in webcomponent/src/com/documentum/webcomponent/navigation/doclist for a detailed example.
Java EE Memory Allocation

If the memory allocated to the Java EE server Java virtual machine (VM) is not correctly set, the VM
will spend a lot of time destroying Java objects, garbage collecting, and creating new objects. To
change the memory allocation, use a setting similar to the following in the Java arguments in the Java
EE server start script that you use to start your application server:
-Xms512m -Xmx512m -verbose:gc
Element Description
-Xms512m Starting memory heap size, in megabytes. In general, increased heap
size increases performance up until the point at which the heap begins
swapping to disk.

Element Description
-Xmx512m Maximum Heap size. For a single VM, Sun recommends that you set
maximum heap size to 25% of total physical memory on the server
host to avoid disk swapping. Increased heap size will increase the
intervals between garbage collection (GC), which thus increases the
pause time for GC.
-verbose:gc Turns on output of garbage collection trace to standard output.
Increased Java memory settings will increase the amount of time
before a major garbage collection takes and will also increase the
amount of time that garbage collection takes to execute. Garbage
collection is the greatest bottleneck in the application, and all
application work pauses during garbage collection.
Garbage collection tracing has the following syntax:

[GC 776527K->544591K(1040384K), 0.4283872 secs]
The trace can be interpreted as follows:
Element Description
GC GC indicates minor garbage collection event, Full GC indicates full
garbage collection
776527K Amount of total allocated memory at start of minor collection
544591K Amount of total allocated memory at end of minor collection
1040384K Amount of total memory on host
0.4283872 secs Time in seconds to run garbage collection
Monitor memory usage by the Java process in the Windows task manager to determine whether your
memory allocations are optimum. Allocated memory as shown in consecutive GC traces continues
to grow until full garbage collection occurs. Full garbage collection takes much longer than minor
garbage collection, often on the order of 10 times as long.
The following table describes some memory troubleshooting inferences that can be drawn from
garbage collection.
Symptom Reason
Frequent full GC, starting point higher after Total memory too small, or memory leak
each full GC, decreasing number of GC between
full GC
Garbage collections take too long (GC 1 sec, full Too much memory allocated to JVM
GC 5 sec), server cannot create new threads
Java EE servers also have configurable settings for thread management which can significantly
affect performance. The symptom of insufficient threads is that, as the number of users increases,
performance degrades without increased CPU usage. Some users will get socket errors. In Tomcat,
the log catalina.log shows that all threads up to maxProcessors have been started, and new requests
are rejected with "Connection Reset By Peer". In WebLogic, the execute queue shows waiting threads
(0 idle threads, with queue length growing).

The symptom of too many threads is excessive context switching between live threads and degraded
response time.
Your application server documentation contains more information on these settings.
HTTP Sessions
Set the maximum number of HTTP sessions for your application in the custom/app.xml element
<application>.<session_config>.<max_sessions>. When the maximum number of sessions is reached,
subsequent requests return a serverBusy JSP page. A value of -1 indicates that there is no limit
on the number of sessions.
You can also override the normal Java EE session timeout when the top browser frame is unloaded,
such as when the user navigates to another website. Instead of the usual 60 minute HTTP timeout,
the timeout setting <client_shutdown_session_timeout> is set to 60 seconds when the main (top)
window has been closed.
Preferences
User preferences are stored as cookies and written to the repository. Since cookies are passed back
and forth with every request and response, there is a small increase in network traffic.
The configuration lookup methods lookupString, lookupInteger, and lookupBoolean have an optional
parameter consultPreference. Set to false to look up a configuration value from the component
definition and bypass a lookup of the user preference when the lookup is not needed.
Browser History
The number of history pages maintained on the server for each window or frame is set by
the requestHistorySize flag in the file FormProcessorProp.properties, which is located in
WEB-INF/classes/com/documentum/web/form. The default value is 3. If the value is empty or zero,
then history is maintained indefinitely. This setting could significantly affect performance. Decrease
the memory footprint per user by setting this value lower. If you set it higher, it will consume
more memory.
Too many form history objects can use up memory. Set the upper limit for the number of objects
as the value of maxNoOfFormHistoriesThreshold in FormProcessorProp.properties. The default
value is 50. A message will be displayed if the user tries to navigate past the maximum number of
pages in history.
Memory that is allocated to maintaining browser history is managed more efficiently on the Java EE
server if you generate framesets and frames using the <dmf:frameset> and <dmf:frame> tags. The
EMC Documentum Web Development Kit Development Guide contains more information.

Value Assistance
Performance is affected by the number of value assistance queries to be displayed in the properties
component and in other components that display a set of properties. Do the following to enhance
this performance:
• For each value assistance query, use Documentum Application Builder to turn on the option to
allow caching.
• Turn on client persistent caching in dfc.properties, which is located in WEB-INF/classes:
dfc.cache.enable_persistence = T
• Index the associated attributes in Content Server.
Search Query Performance

Set <displayresultspath> to false in your custom search component definition to speed all queries.
This suppresses the query for folder path of each object.
In advanced search, you can add a checkbox for case-sensitive search for non-indexed repositories.
Set the casevisible attribute on the search controls to true. Set the default match case as the value
of the element <defaultmatchcase> (true | false) in wdk/config/advsearchex.xml. Case-sensitive
queries perform faster.
High Latency and Low Bandwidth Connections

Two filters are available to improve performance in high latency or low bandwidth networks.
The filters are defined as servlet filters in WEB-INF/web.xml. They are turned on by default. The
filters are as follows:
• Response compression filter (CompressionFilter)
Compresses text responses by mapping requests for *.jsp, *.css, *.js, *.htm, *.html, and the
component dispatcher servlet. If the request accept- header indicates that the browser accepts
compression, the filter swaps the output stream for a compressed stream in either gzip or deflate
compression formats, depending on which format is accepted by the browser as indicated by
the Accept- request header.
The configurable value for this filter, init-param compressThreshold, is a size in KB or MB
thatsets the threshold file size at which output will be compressed. Compression does not
decrease the size of the stream for small inputs. Additional, high-bandwidth networks may
show improvement for only very large files (hundreds of KB). A value of 3kb indicates that files
3 KB or larger will be compressed.
Additionally there are init-params for turning on compression filter debugging and excluding
specific JSP pages from compression filtering.
Limitation: There is an unknown CPU cost for the compression.
• Cache control (ClientCacheControl)

Limits the number of requests by telling the client browser and any intermediary caches such as
caching proxies to cache static elements such as *.gif, *.js, and *.css files, by adding a Cache-Control
response header. After the browser has received a response with this header, it will not re-get the
content until the maximum age or until the content is cleared manually from the browser cache.
The configurable value for this filter, init-param Cache-Control, is the maximum age in seconds of
the static content before revalidation, for example, max-age=86400 (one day).
Add URL patterns to specify the file types that will be cached. In the following example, *.gif
files are cached for up to two days:
<filter>
<filter-name>ClientCacheControl</filter-name>
<filter-class>com...ResponseHeaderControlFilter</filter-class>
<init-param>
<param-name>Cache-Control</param-name>
<param-value>max-age=172800</param-value>
</init-param>
</filter>
</filter>
<filter-mapping>
<filter-name>ClientCacheControl></filter-name>
<url-pattern>*.gif</url-pattern>
</filter-mapping>
Note: Safari browser does not apply this header. IE does not support both the cache-control and
compression mechanisms at the same time.
Tracing for these filters can be enabled through the standard tracing mechanism
(TraceProp.properties) or by adding the debug <init-param> element to the application deployment
descriptor (WEB-INF/web.xml).
Example 5-6. Enabling tracing of filters in WEB-INF/web.xml

<filter>
<filter-name>CompressionFilter</filter-name>
<filter-class>com.documentum.web.servlet.CompressionFilter</filter-class>
<init-param>
<param-name>compressThreshold</param-name>
<param-value>3kb</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
</filter>
Qualifiers and Performance

Each qualifier that is defined in the application slows performance the first time a component is
called. Navigation components must evaluate qualifiers for each action in the component JSP page.
To improve performance, remove from your custom app.xml file the qualifiers that your application
does not need. (The application qualifier is required.) In the following example from an app.xml file
in the custom directory, only the type qualifier is used by a custom application. The app qualifier is
required for all applications. No components or actions can be scoped to role in this example, because
the role qualifier is not defined for the application.

<qualifiers>
<qualifier>com.documentum.web.formext.config.DocbaseTypeQualifier
</qualifier>
<qualifier>com.documentum.web.formext.config.AppQualifier
</qualifier>
</qualifiers>
For better performance, your qualifier should implement the IInquisitiveQualifier interface. At
startup, this interface is used to inform the qualifier of all relevant scopes defined in the action and
component definitions. The qualifier can return an empty scope value that is cached, when the
runtime context is not relevant.
Import Performance
You can limit the number of files that can be imported by a user during a single import operation.
This configuration setting is the <max-import-file-count> element with a default of 1000 in the
importcontainer component. Extend this component definition to configure a different maximum
value.
Certain environments have forward or reverse proxy web servers that do not support HTTP 1.1
chunking, which is used by UCF for content transfer. For those environments, you must configure
UCF to use alternative chunking, and you can tune the chunk size for the web server. In general, the
default chunk size works best for large file transfers. Smaller chunk sizes may enhance performance
for small (less than 1MB) files but degrade performance for large files. The EMC Documentum Web
Development Kit Development Guide contains more information.
Load Balancing
WDK applications can be load balanced using network load balancers. Session "stickiness" (or
affinity) must be used. That is, once a session has been established between a browser and a back-end
application server then all subsequent traffic from that browser must be routed to that server by the
load balancer for the duration of the session. The affinity can be done by IP address or by session
cookie depending on the available settings in the load balancing software.
Because content transfer is disk-intensive, best performance spreads the I/O of the WDK content
directory over a striped disk volume.

Modal Windows and Performance

Modal windows provide a performance enhancement in web applications that use several frames.
With a modal window, other frames do not need to refresh after the modal frame closes. The EMC
Documentum Web Development Kit Development Guide contains more information.

Chapter 6
Troubleshooting Deployment
Wrong JRE used for application server

If the application server host has multiple JREs on the system, the application server can use
the wrong JRE. Check your application server documentation for instructions to use the correct
JRE with your application server. For example, the Apache Tomcat application server uses a
JAVA_HOME environment variable. This variable value is specified in the application startup batch
file catalina.bat or in the service.bat file for Windows services.
If the application server uses the wrong JRE, Apache Tomcat displays the following error:
ERROR [Thread-1]
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/da]
- Error configuring application listener of class
com.documentum.web.env.NotificationManager
java.lang.UnsupportedClassVersionError:
com/documentum/web/env/NotificationManager
(Unsupported major.minor version 49.0)at
java.lang.ClassLoader.defineClass0(Native Method)
No global registry or connection broker

Global registry information must be configured in the dfc.properties file. The application server
must be able to download the required BOF modules from the global registry repository. If the
information in the dfc.properties file is incorrect, the application server cannot download the
appropriate BOF modules, and the following exception is thrown:
ERROR...Caused by: DfDocbrokerException:: THREAD: main; MSG:
[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker "10.8.3.21:1489" failed;
ERRORCODE: ff; NEXT: null
To fix this error, provide the correct BOF registry connection information in the dfc.properties
file or do not provide any connection information at all. The EMC Documentum Content Server
Installation Guide contains information on enabling a repository as a global registry.
No connection to repository
If a connection broker is not specified in the dfc.properties file of the Documentum Administrator
WAR file, the application server log contains the following error during application initialization:
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: DfDocbrokerException:: THREAD: main; MSG: [DFC_DOCBROKER_REQUEST_FAIL
ED] Request to Docbroker "10.8.3.21:1489" failed; ERRORCODE: ff; NEXT: null

To establish a connection to repositories, Documentum Administrator must have information about

the available connection broker. The Enabling DFC connections to repositories, page 26 section
contains information on enabling the connection in the dfc.properties file.
If the repository that is specified as the global repository is down, the following message appears:
Caused by: DfNoServersException:: THREAD: main; MSG:
[DM_DOCBROKER_E_NO_SERVERS_FOR_DOCBASE]error: "The DocBroker running on host
(10.8.3.21:1489) does not know of a server for the specified docbase
(wtD6winsql)"; ERRORCODE: 100; NEXT: null
Login page incorrectly displayed

If the login page displays several login buttons, the browser does not have the Java plug-in installed.
Download and install the Java plug-in for the browser.
If the login page displays several controls with the same label, you have not turned off tag pooling
in the application server. The Tag pooling problem, page 65 section contains the troubleshooting
information on this problem.
Slow performance
A system sizing guide is on EMC Online Support (https://support.emc.com).
Set dfc.diagnostics.resources.enable to false in the dfc.properties file unless you are
using the DFC diagnostics. This setting uses a significant amount of memory.
Out of memory errors in console or log

Verify that you have allocated sufficient RAM for the application server VM. The Setting the Java
memory allocation, page 13 section contains more information.
The following error is common when MaxPermSize is set too low: java.lang.
OutOfMemoryError: PermGen space
Slow display first time

The application server must compile a JSP the first time it is accessed. It is much faster on subsequent
accesses. If you have tracing turned on, or if you have a large log file (of several megabytes), the
browser response time decreases dramatically.

DFC using the wrong directories on the

application server
If you have not specified content transfer directories in the dfc.properties file, DFC looks first for
global environment variables that set directory locations.
Tag pooling problem

If you have not properly disabled tag pooling in the application server, you see several instances of
the same control on the login page.
Caution: After you disable tag pooling, clear the cached JSP class files which can still contain
pooled tags. Refer to your application server documentation to find the location of the generated
class files. For example, Apache Tomcat displays the following error message:
com.documentum.web.form.control.TagPoolingEnabledException: JSP tag
pooling is not supported.
UCF client problems

If the error message Compatible Java Run time environment is not installed is
displayed on a non-Windows client, verify that you have installed a certified version of the JRE
on the client. UCF uses this version, which does not interfere with the browser VM. It is used for
non-UCF applets.
If a UCF error is reported on the client, the following troubleshooting steps can help:
• For UCF timeouts, check whether anti-virus software on the application server is monitoring port
8080 or the application server port that is in use. Turn off monitoring of the application server port.
• For slow UCF downloads, ensure that virus scanning within zip files is not turned on.
• Ensure that the user has a supported JRE version on the machine to initiate UCF installation. To
verify the presence and version of a JRE, you can point the client browser to a Java tester utility
such as Javatester utility.
• Verify if the process from the launch command is running: Open the browser Java console look
for invoked runtime: ... connected, uid: ... A UID indicates successful connection to
the UCF server.
• Check the application server console for errors on the UCF server.
• Restart the browser and retry the content transfer operation.
• Kill the UCF launch process and retry the content transfer operation.
• If UCF operations still do not launch, delete the client UCF folder located in
USER_HOME/username/Documentum/ucf.
• Search the client system for files that start with ucfinit.jar- and delete them.

Connection issues between a Federated

Search server and IPv6 clients
Federated Search server uses the RMI protocol to communicate with the client applications. When
the client application launches a request against the Federated Search server, it indicates the IP
address that the Federated Search server must use to respond. However, it can happen that the client
sends a link-local address instead of a global address. To avoid any connection issue, update the
catalina.bat script that launches DA. The following setting forces the RMI IP to connect:
set JAVA_OPTS=%JAVA_OPTS% -Djava.rmi.server.hostname=<global IPv6 address>
Max Sessions error

Before restarting the application server, use the Documentum Administrator to find the current
"active" and "inactive" users sessions in the repository. Try reducing the session timeout value in the
application server to see if the inactive sessions get cleared out faster.

Appendix A
Pre-Installation Checklist
Use the following checklist to verify that you have performed all required tasks when you install or
upgrade a DA.
Table 3. Preinstallation tasks
Requirement For more information Completed?

Review the release notes for the EMC Documentum Administrator Release
release you are installing or to Notes
which you are upgrading.
Validate your hardware EMC Documentum Environment and System
configuration. Requirements Guide
Validate your application server EMC Documentum Environment and System
and clients operating systems. Requirements Guide
Create required operating Network administrators
system accounts.
Verify that the application Network administrators
server instance owner has write
permissions on the temporary
content transfer directories.
Determine the repositories to Network administrators
which end users connect.
Determine the connection Network administrators
brokers to which the
repositories project.
Determine which repository Network administrators
on the network is the global
registry repository, and obtain
the global registry user name
and password.
Determine which repositories Network administrators
are used to store presets and
user preferences.
Determine whether language EMC Documentum Administrator Release
packs are required. Notes

Pre-Installation Checklist
Requirement For more information Completed?

Prepare the application server Specific requirements are described in
host and application server Chapter 3, Preparing the Application
software according to the Server Host.
vendor’s requirements.
Disable the IP Helper service EMC Documentum Content Server
from the Windows Services Installation Guide
console and restart the machine.
This method disables the Teredo
Tunneling Pseudo-Interface.

Madan Da Deployment

Uploaded by

Copyright:

Available Formats

Madan Da Deployment

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Madan Da Deployment

Uploaded by

Copyright:

Available Formats

EMC ® Documentum ®

Chapter 1 Planning for Deployment ............................................................................. 9

Chapter 2 Preparing the Client Hosts .......................................................................... 11

Chapter 3 Preparing the Application Server Host ........................................................ 13

Chapter 4 Deploying Documentum Administrator ....................................................... 25

EMC Documentum Administrator Version 7.2 Deployment Guide 3

Enabling presets and preferences repositories..................................................... 29

Chapter 5 Post-Deployment Tasks ............................................................................... 35

4 EMC Documentum Administrator Version 7.2 Deployment Guide

Application Server .................................................................................... 51

Chapter 6 Troubleshooting Deployment ...................................................................... 63

Appendix A Pre-Installation Checklist ............................................................................ 67

EMC Documentum Administrator Version 7.2 Deployment Guide 5

Table 1. Preferences configuration elements ........................................................................ 29

6 EMC Documentum Administrator Version 7.2 Deployment Guide

This guide describes how to deploy the Documentum Administrator application.

• Updated the section Preparing JBoss, page 16.

• Preparing JBoss, page 16

• Configuring VMware vFabric tc Server, page 19

• Preparing IBM WebSphere, page 19.

EMC Documentum Administrator Version 7.2 Deployment Guide 7

Revision Date Description

• Preparing Oracle WebLogic, page 22

8 EMC Documentum Administrator Version 7.2 Deployment Guide

Required and optional supporting software

EMC Documentum Administrator Version 7.2 Deployment Guide 9

Application server host requirements

• Content transfer directory permissions

Customizing Documentum Administrator

10 EMC Documentum Administrator Version 7.2 Deployment Guide

Ensuring a certified JVM on browser clients

Enabling HTTP content transfer in Internet

To enable HTTP file download in Internet Explorer:

EMC Documentum Administrator Version 7.2 Deployment Guide 11

12 EMC Documentum Administrator Version 7.2 Deployment Guide

Setting the Java memory allocation

EMC Documentum Administrator Version 7.2 Deployment Guide 13

Turning off failover

Preparing environment variables for

Configuring Apache Tomcat

14 EMC Documentum Administrator Version 7.2 Deployment Guide

3. Restart the application server.

To enable the web application server compression

EMC Documentum Administrator Version 7.2 Deployment Guide 15

To disable the WDK compression filter

3. Restart the application server.

Disabling HttpOnly Property

16 EMC Documentum Administrator Version 7.2 Deployment Guide

7. Copy the web-inf-classes.jar file to <WebApp Root>\WEB-INF\lib (Windows) and

Deploying multiple applications on JBoss

2. Add the jboss-deployment-structure.xml file in the WEB-INF folder.

EMC Documentum Administrator Version 7.2 Deployment Guide 17

Enabling HTTPOnly Cookies Support

1. Update the web-app header specification from version 2.4 to 3.0:

18 EMC Documentum Administrator Version 7.2 Deployment Guide

2. Add the following entry in <session-config>:

Configuring VMware vFabric tc Server

Disabling HttpOnly Property

1. Add the following line in the catalina.properties file located at <VMware_vFabric_tc_

2. Restart the application server.